- 현재 위치
- home > 컴퓨터·ICT·어학 > 컴퓨터·IT 도서 > IT에세이 > 개발자를 위한 글쓰기 가이드[로드북]
;)
개발자가 코딩만 잘하면 된다? 고객의 요구사항 분석을 제대로 글로 옮기지 못한다면 무슨 일이 발생할까? 장애 발생 시 공지문을 작성해야 하는데, 빠짐없이 정확하게 작성할 수 있을까? 오류와 확인 메시지는 제대로 쓸 수 있을까? UI에 들어가는 텍스트는? 소프트웨어 제품 출시 후 사용자 가이드는 어떻게 만들어야 할까?
개발자는 코딩 영역 외에도 이렇게 수많은 글쓰기 문제에 직면한다. 이를 위해 저자는 테크니컬 라이터로서 20년 이상 개발자와 함께하며 얻는 핵심 노하우를 이 책 한 권에 정리하였다. 옆에 두고 항상 참고할 수 있는 개발자만을 위한 글쓰기 가이드이다.
개발자는 코딩 영역 외에도 이렇게 수많은 글쓰기 문제에 직면한다. 이를 위해 저자는 테크니컬 라이터로서 20년 이상 개발자와 함께하며 얻는 핵심 노하우를 이 책 한 권에 정리하였다. 옆에 두고 항상 참고할 수 있는 개발자만을 위한 글쓰기 가이드이다.
저자: 유영경 (지은이)
저자의 말
1부 테크니컬 라이팅 시작하기
1장 테크니컬 라이팅
테크니컬 라이팅과 기술 문서
테크니컬 라이팅과 일반 글쓰기의 차이
테크니컬 라이팅 5단계
2장 개발자와 테크니컬 라이팅
개발자와 테크니컬 라이팅
그냥 쓰는 것이 아니라 제대로 쓰기
2부 테크니컬 라이팅 45가지 원칙
3장 문서 작성 계획 세우기
01 대상 독자를 정한다
02 설명할 기술의 깊이를 조절한다
03 분위기를 좌우할 어조를 정한다
04 주제를 구체적으로 정한다
05 작성할 문서의 종류를 정한다
4장 초안 작성
06 일단 쓴다
07 명확성, 간결성, 일관성의 3원칙
08 핵심부터 쓴다
09 제목에 요점을 담는다
10 문장 하나에는 주제를 하나만 쓴다
11 객관적인 근거를 댄다
12 전문 용어는 독자에 맞게 사용한다
13 용어와 약어를 쓸 때는 풀이를 쓴다
14 용어는 일관되게 사용한다
15 쉽게 쓴다
5장 시각화 요소로 가독성 높이기
16 적합한 시각 자료를 활용한다
17 목록을 사용해 정리한다
18 스크린숏으로 이해도를 높인다
19 정보를 비교할 때는 표를 활용한다
20 데이터 성격에 맞는 차트를 사용한다
21 시각 자료를 쓰기 전에 소개부터 한다
22 시각 자료를 설명하는 캡션을 활용한다
6장 검토와 재작성
23 객관적으로 문서를 검토한다
24 맥락에 맞는 적확한 단어를 선택한다
25 은어는 형식적인 표현으로 바꾼다
26 대명사는 일반 명사로 바꾼다
27 고유한 이름은 정확히 쓴다
28 숫자와 단위를 정확하게 쓴다
29 단정적인 어조로 확신 있게 쓴다
30 글꼬리를 뚜렷하게 쓴다
31 주어와 서술어를 일치시킨다
32 문장은 짧게 줄인다
33 군더더기 표현을 없앤다
34 의미가 같은 표현은 한 번만 쓴다
35 피동태보다 능동태로 쓴다
36 복잡한 번역체를 다듬는다
37 ‘통해’는 명확한 표현으로 바꾼다
38 ‘무엇은 ~ 무엇이다’ 형식으로 쓰지 않는다
39 ‘~해 주다’ 대신 ‘~하다’를 쓴다
40 조사를 덜어낸다
41 재작성한 문서를 동료와 검토한다
42 자주 틀리는 맞춤법
43 자주 틀리는 외래어 표기법
44 자주 틀리는 띄어쓰기
45 자주 틀리는 문장 부호
3부 유형별 테크니컬 라이팅 사례로 본 작성의 원칙
-메일ㆍ회의록ㆍ장애 발생 공지문ㆍ사용자 가이드
7장 메일 작성
46 받는 사람이 궁금해할 내용을 쓴다
47 인사말과 맺음말은 과하지도 부족하지도 않게 쓴다
48 받는 사람을 명확하게 지정한다
49 첨부 파일을 확인한다
8장 회의록 작성
50 회의록 구성 요소를 확인한다
51 회의록 작성 원칙을 기억한다
9장 오류와 확인 메시지 작성
52 확인 메시지 작성법
53 오류 메시지에서 중요한 것은 해결 방법
54 메시지에서도 제목을 활용한다
55 직관적인 버튼 텍스트를 만든다
10장 장애 발생 공지문 작성 1부
56 장애 발생 공지문의 기본 요소: 장애 발생 직후
57 장애 해결 공지문의 기본 요소: 장애 해결 후
58 장애 보고서 작성: 내부 보고와 기록용
11장 사용자 가이드 작성
59 사용자에게 맞는 가이드 종류를 선택한다
60 개념과 목적을 설명하는 개요를 추가한다
61 사용법은 순차적으로 설명한다
62 퀵스타트 가이드로 제품과 빠르게 친숙해지게 한다
참고 자료
1부 테크니컬 라이팅 시작하기
1장 테크니컬 라이팅
테크니컬 라이팅과 기술 문서
테크니컬 라이팅과 일반 글쓰기의 차이
테크니컬 라이팅 5단계
2장 개발자와 테크니컬 라이팅
개발자와 테크니컬 라이팅
그냥 쓰는 것이 아니라 제대로 쓰기
2부 테크니컬 라이팅 45가지 원칙
3장 문서 작성 계획 세우기
01 대상 독자를 정한다
02 설명할 기술의 깊이를 조절한다
03 분위기를 좌우할 어조를 정한다
04 주제를 구체적으로 정한다
05 작성할 문서의 종류를 정한다
4장 초안 작성
06 일단 쓴다
07 명확성, 간결성, 일관성의 3원칙
08 핵심부터 쓴다
09 제목에 요점을 담는다
10 문장 하나에는 주제를 하나만 쓴다
11 객관적인 근거를 댄다
12 전문 용어는 독자에 맞게 사용한다
13 용어와 약어를 쓸 때는 풀이를 쓴다
14 용어는 일관되게 사용한다
15 쉽게 쓴다
5장 시각화 요소로 가독성 높이기
16 적합한 시각 자료를 활용한다
17 목록을 사용해 정리한다
18 스크린숏으로 이해도를 높인다
19 정보를 비교할 때는 표를 활용한다
20 데이터 성격에 맞는 차트를 사용한다
21 시각 자료를 쓰기 전에 소개부터 한다
22 시각 자료를 설명하는 캡션을 활용한다
6장 검토와 재작성
23 객관적으로 문서를 검토한다
24 맥락에 맞는 적확한 단어를 선택한다
25 은어는 형식적인 표현으로 바꾼다
26 대명사는 일반 명사로 바꾼다
27 고유한 이름은 정확히 쓴다
28 숫자와 단위를 정확하게 쓴다
29 단정적인 어조로 확신 있게 쓴다
30 글꼬리를 뚜렷하게 쓴다
31 주어와 서술어를 일치시킨다
32 문장은 짧게 줄인다
33 군더더기 표현을 없앤다
34 의미가 같은 표현은 한 번만 쓴다
35 피동태보다 능동태로 쓴다
36 복잡한 번역체를 다듬는다
37 ‘통해’는 명확한 표현으로 바꾼다
38 ‘무엇은 ~ 무엇이다’ 형식으로 쓰지 않는다
39 ‘~해 주다’ 대신 ‘~하다’를 쓴다
40 조사를 덜어낸다
41 재작성한 문서를 동료와 검토한다
42 자주 틀리는 맞춤법
43 자주 틀리는 외래어 표기법
44 자주 틀리는 띄어쓰기
45 자주 틀리는 문장 부호
3부 유형별 테크니컬 라이팅 사례로 본 작성의 원칙
-메일ㆍ회의록ㆍ장애 발생 공지문ㆍ사용자 가이드
7장 메일 작성
46 받는 사람이 궁금해할 내용을 쓴다
47 인사말과 맺음말은 과하지도 부족하지도 않게 쓴다
48 받는 사람을 명확하게 지정한다
49 첨부 파일을 확인한다
8장 회의록 작성
50 회의록 구성 요소를 확인한다
51 회의록 작성 원칙을 기억한다
9장 오류와 확인 메시지 작성
52 확인 메시지 작성법
53 오류 메시지에서 중요한 것은 해결 방법
54 메시지에서도 제목을 활용한다
55 직관적인 버튼 텍스트를 만든다
10장 장애 발생 공지문 작성 1부
56 장애 발생 공지문의 기본 요소: 장애 발생 직후
57 장애 해결 공지문의 기본 요소: 장애 해결 후
58 장애 보고서 작성: 내부 보고와 기록용
11장 사용자 가이드 작성
59 사용자에게 맞는 가이드 종류를 선택한다
60 개념과 목적을 설명하는 개요를 추가한다
61 사용법은 순차적으로 설명한다
62 퀵스타트 가이드로 제품과 빠르게 친숙해지게 한다
참고 자료
개발자가 코딩만 잘하면 된다? 고객의 요구사항 분석을 제대로 글로 옮기지 못한다면 무슨 일이 발생할까? 장애 발생 시 공지문을 작성해야 하는데, 빠짐없이 정확하게 작성할 수 있을까? 오류와 확인 메시지는 제대로 쓸 수 있을까? UI에 들어가는 텍스트는? 소프트웨어 제품 출시 후 사용자 가이드는 어떻게 만들어야 할까?
개발자는 코딩 영역 외에도 이렇게 수많은 글쓰기 문제에 직면한다. 이를 위해 저자는 테크니컬 라이터로서 20년 이상 개발자와 함께하며 얻는 핵심 노하우를 이 책 한 권에 정리하였다. 옆에 두고 항상 참고할 수 있는 개발자만을 위한 글쓰기 가이드이다.
샘플원고 ☞ https://roadbook.co.kr/246
_대상 독자
--------이런 고민을 하는 독자-----------
고객의 요구사항을 정리하는 데 어려움을 겪는 개발자
협업 미팅을 해야 할 때 나의 보고서가 부끄러운 개발자
장애 보고서는 어떻게 써야 할지 난감한 개발자
회의록을 기록하며 업무를 해야 하는 개발자
버튼 텍스트, 오류 메시지 작성 등에 고민이 많은 개발자
남들이 나의 글을 제대로 이해하지 못한다고 생각하는 개발자
전문 테크니컬 라이터가 없는 중소규모의 소프트웨어 기업
"테크니컬 라이팅:
기술이나 과학 분야에서 정보를 정학하게 전달하기 위한 글쓰기"
Microsoft, NAVER, NHN에서 20년
베테랑 테크니컬 라이터의 글쓰기 비법
"개발자 나길동 씨는 아침에 출근해 오늘 할 일을 메모하는 글쓰기로 하루를 시작합니다. 서비스 출시 회의 내용을 정리하는 것도, 관련 부서에 회의 결과와 남은 버그를 공유하는 메일을 쓰는 것도 글쓰기입니다. 다음 주부터 출근하는 신입사원이 봐야 할 코딩 컨벤션도 작성해야 합니다. 출시한 서비스의 버그로 보고된 오류 메시지도 추가로 써야 합니다.
회사 기술 블로그에 JavaScript 성능을 최적화한 경험과 사례를 공유하는 글을 쓰기 시작할 때면 머리가 아파져 옵니다. 한 줄 쓰고 지우고, 한 줄 쓰고 지우고. 몇 시간째 한 페이지를 넘기지 못합니다. 바람이나 쐐야지. 덮어두고 다른 일을 시작하지만, 마음 한켠이 점점 더 무거워집니다."
[이 책이 제시하는 개발자 나길동 씨를 위한 고민 해결책]
_쉽게 실천할 수 있는 테크니컬 라이팅 기본 규칙
이 책에서 소개하는 기본 규칙만 잘 이해하고 실천한다면 개발자 나길동 씨도 누구나 이해하기 쉽고 빠른 글쓰기를 할 수 있습니다.
_수많은 사례의 예시문을 통한 반복 연습
규칙을 이해했다면 이제는 다양한 사례의 예시문을 반복해서 고쳐보며 연습해야 합니다. 연습 없이 결코 글을 잘 쓸 수 없습니다.
_오랫동안 개발자와 함께한 테크니컬 라이터의 핵심 비법
저자는 오랫동안 개발자와 함께 해왔습니다. 글쓰기 교육, 소프트웨어 관련 테크니컬 라이팅 업무를 하며 익힌 핵심 비법의 정수를 담았습니다.
이 책을 통해 클린 코드 못지않은 클린 테크니컬 라이팅 능력도 갖추길 바랍니다.
편집자 코멘트
개발자는 고객의 요구사항을 정확하게 정리해내고, 협업 과정에서 문제없이 의사소통을 할 수 있어야 하며, 사용자가 코딩의 결과물을 불편 없이 사용하게 해주어야 한다. 이것은 코딩 외적인 능력에 속하며, 이를 위해 가장 기본적으로 필요한 소양이 바로 기술적 글쓰기, 테크니컬 라이팅 능력이다.
대기업에 속한 개발자들은 전문 테크니컬 라이터에게 필요한 지원을 받을 수 있지만, 수많은 개발자들은 스스로 해결해야 하는 경우가 많다. 이 책은 회사의 지원을 받지 못하는 개발자들을 위해 가장 기본이 되는 기술적 글쓰기의 규칙과 사례를 정리하여 언제나 참고할 수 있는 가이드이다.
바쁜 개발자들을 위해 넘치거나 부족하지 않은 책이 나온 것 같아 편집자로서 정말 기쁘다. 기술서적을 기획, 출간하고 있는 편집자도 이 책을 항상 옆에 끼고 참고하려고 한다.
개발자는 코딩 영역 외에도 이렇게 수많은 글쓰기 문제에 직면한다. 이를 위해 저자는 테크니컬 라이터로서 20년 이상 개발자와 함께하며 얻는 핵심 노하우를 이 책 한 권에 정리하였다. 옆에 두고 항상 참고할 수 있는 개발자만을 위한 글쓰기 가이드이다.
샘플원고 ☞ https://roadbook.co.kr/246
_대상 독자
--------이런 고민을 하는 독자-----------
고객의 요구사항을 정리하는 데 어려움을 겪는 개발자
협업 미팅을 해야 할 때 나의 보고서가 부끄러운 개발자
장애 보고서는 어떻게 써야 할지 난감한 개발자
회의록을 기록하며 업무를 해야 하는 개발자
버튼 텍스트, 오류 메시지 작성 등에 고민이 많은 개발자
남들이 나의 글을 제대로 이해하지 못한다고 생각하는 개발자
전문 테크니컬 라이터가 없는 중소규모의 소프트웨어 기업
"테크니컬 라이팅:
기술이나 과학 분야에서 정보를 정학하게 전달하기 위한 글쓰기"
Microsoft, NAVER, NHN에서 20년
베테랑 테크니컬 라이터의 글쓰기 비법
"개발자 나길동 씨는 아침에 출근해 오늘 할 일을 메모하는 글쓰기로 하루를 시작합니다. 서비스 출시 회의 내용을 정리하는 것도, 관련 부서에 회의 결과와 남은 버그를 공유하는 메일을 쓰는 것도 글쓰기입니다. 다음 주부터 출근하는 신입사원이 봐야 할 코딩 컨벤션도 작성해야 합니다. 출시한 서비스의 버그로 보고된 오류 메시지도 추가로 써야 합니다.
회사 기술 블로그에 JavaScript 성능을 최적화한 경험과 사례를 공유하는 글을 쓰기 시작할 때면 머리가 아파져 옵니다. 한 줄 쓰고 지우고, 한 줄 쓰고 지우고. 몇 시간째 한 페이지를 넘기지 못합니다. 바람이나 쐐야지. 덮어두고 다른 일을 시작하지만, 마음 한켠이 점점 더 무거워집니다."
[이 책이 제시하는 개발자 나길동 씨를 위한 고민 해결책]
_쉽게 실천할 수 있는 테크니컬 라이팅 기본 규칙
이 책에서 소개하는 기본 규칙만 잘 이해하고 실천한다면 개발자 나길동 씨도 누구나 이해하기 쉽고 빠른 글쓰기를 할 수 있습니다.
_수많은 사례의 예시문을 통한 반복 연습
규칙을 이해했다면 이제는 다양한 사례의 예시문을 반복해서 고쳐보며 연습해야 합니다. 연습 없이 결코 글을 잘 쓸 수 없습니다.
_오랫동안 개발자와 함께한 테크니컬 라이터의 핵심 비법
저자는 오랫동안 개발자와 함께 해왔습니다. 글쓰기 교육, 소프트웨어 관련 테크니컬 라이팅 업무를 하며 익힌 핵심 비법의 정수를 담았습니다.
이 책을 통해 클린 코드 못지않은 클린 테크니컬 라이팅 능력도 갖추길 바랍니다.
편집자 코멘트
개발자는 고객의 요구사항을 정확하게 정리해내고, 협업 과정에서 문제없이 의사소통을 할 수 있어야 하며, 사용자가 코딩의 결과물을 불편 없이 사용하게 해주어야 한다. 이것은 코딩 외적인 능력에 속하며, 이를 위해 가장 기본적으로 필요한 소양이 바로 기술적 글쓰기, 테크니컬 라이팅 능력이다.
대기업에 속한 개발자들은 전문 테크니컬 라이터에게 필요한 지원을 받을 수 있지만, 수많은 개발자들은 스스로 해결해야 하는 경우가 많다. 이 책은 회사의 지원을 받지 못하는 개발자들을 위해 가장 기본이 되는 기술적 글쓰기의 규칙과 사례를 정리하여 언제나 참고할 수 있는 가이드이다.
바쁜 개발자들을 위해 넘치거나 부족하지 않은 책이 나온 것 같아 편집자로서 정말 기쁘다. 기술서적을 기획, 출간하고 있는 편집자도 이 책을 항상 옆에 끼고 참고하려고 한다.
