개발자의 글쓰기

전공 개발자로써 어떻게 글을 쓰는가에 대하여

1. 책소개

2. 이 책을 선택한 계기

어느날, 서점을 들렀을 때 IT계열 분야에서 이 책을 보았다. 책의 중요 내용으로는 개발자가 가장 어려워하는 변수 네이밍, 릴리스 노트 작성법, 보고서 등 글쓰기가 어려운 개발자들을 위한 책으로 소개가 되어 있었다. 여태껏 나는 글쓰는게 어렵다고 느껴본 적은 없었다. 하지만, 영어를 잘 모르는 나에게는 이름짓기란 너무나 어려웠고, 현재까지도 그렇다. 항상 번역기로 돌려서 어수룩한 이름 짓는 것에 고민이 되었던 나는, 이 책을 읽고 조금이라도 도움이 되었으면 했다. 사실상, 대부분의 프로그래밍 관련 도서들은 해당 언어에 대한 기술 방법들을 서술해둘 뿐, 사소하면서도 까탈스러운 이런 네이밍 짓는 것에 대한 도서는 찾아 보기 힘들었다. 그래서 나는 이 도서를 선택했고, 이 도서를 읽고서 핵심 줄거리와 느낀점들을 서평한다.

3. 핵심파악

1) [프롤로그] 개발자의 글쓰기는 달라야한다 19p ~ 23p

• 개발자 글쓰기의 특징

• 정확성 : 틀림이 없이 확실한 것, 글로 쓰인대로 개발하면 버그 없이 실행되야함.

• 간결성 : 간단하고 깔끔한 것, 핵심만 써야함.

• 가독성 : 쉽게 읽히는 것, 쉬운 용어 및 그림/도표를 활용, 문단과 문서 전체 체계와 위계가 갖추어져야 함.

• 코드 밖 글쓰기

• 릴리스 노트, 장애 보고서, 개발 가이드 잘 쓰는 방법 소개

2) [1장] 개발자가 알아야할 글쓰기 기본 26p ~ 43p

• 문장을 구조화 하는 법

• 간단한 문장 구조로 핵심 소개, 필요에 따라 부가 설명

• 서술식, 개조식, 도식의 차이

• 서술식 → 무엇을 설명하거나, 논증할 때 주로 사용하는 방식 → 신문기사처럼 개발 가이드 문서는 대부분 서술식으로 작성. → 줄거리가 있는 설명 또는 이야기 때 사용.

• 개조식 → 신문의 헤드라인을 쓰거나 어떤 사항 을 나열할 때 사용하는 방식 → 릴리스 문서나 장애 보고서를 쓸 때 개조식으로 작성. → 여러사항이 유사한 패턴으로 반복될 때 사용.

• 도식 → 사물의 구조나 관계, 상태를 그림이나 서식으로 보여주는 방식 → 항목, 사항의 관계를 명확히 규정하고 싶을 때 사용.

• 글의 진술 방식

• 설명, 묘사, 논증, 서사 네 가지가 있음.

  • 설명 : 내용을 구체적으로 설명하거나 나열할 때, 하위요소로 갈수록 중요도가 낮고 들여쓰기 사용 (■, □, ○, -, *, ※, √)
  • 묘사 : 그림 안에 어떤 요소나 영역을 표시하기 위해 사용 (ⓐ, ⓑ, ⓒ, ①)
  • 논증 : 논리관계(귀납,연역, 인과, 유추, 비교, 단계 등) 구성 될 때 (∴, →, ☞)
  • 서사 : 순서나 단계를 나타낼 때 사용 (1, 2, 3, 가, 나, 다)

• 띄어쓰기 원칙

// 안 좋은 예
wordSpacing( arg1, arg2 )

// 좋은 예
wordSpacing(arg1, arg2)

• 문장 부호
• 개발 언어 기준마다 다름, C에서 작은 따옴표는 단일 문자(single character) 에 사용.
• 큰따옴표는 문자열(string literal)에 사용.

// 잘못된 예
char str[] = 'HELLO WORLD';
str[0] = "A";

// 좋은 예
char str[] = "HELLO WORLD";
str[0] = 'A';

• 단어 선택
• 개발할 때 반대되는 영어 단어를 선택할 때,
  • 중단 : stop
  • 완전히 중단되어 재시작할 가능성이 없을 때 : end
  • 끝장을 본 상태 : finish
  • 아주 잠시 일시적으로 중단된 상태 : pause
  • 다음 단계의 시작을 중단 상태 : suspend
  • 어떠한 의도가 있어 중단한 상태 : hold
  • 행동이 필요한 함수 : do + 단어

3) [2장] 개발 시간을 줄여주는 이름 짓기와 주석 쓰기 47p ~ 90p

• 이름 짓기는 창조가 아니라 조합

• 정해진 원칙으로 적절한 단어를 선택해 조합하는 과정

• 자바 네이밍 컨벤션을 철저히 준수한다.

• 클래스는 UpperCamelCase

• 함수와 변수는 lowerCamelCase

• 상수는 UPPER_DELIMITER_CASE

• 네이밍은 보통 16글자, 3단어를 조합한다.

• 클래스 : 3.18 단어

• 함수 : 3.36 단어

• 변수 : 2.57 단어

• 품사는 주로 명사, 동사, 형용사의 조합이다.

• 명사 + 명사 + 명사

• 동사 + 명사 + 명사

• 형용사 + 명사 + 명사 등

• 코드의 네이밍 컨벤션은 영어 표기법을 상속받았다.

• 대소문자를 구별하는 파스칼 표기법

• 영어의 대문자 표기 원칙은 카멜 표기법

• 파스칼 표기법

// 잘못된 예
interface menu
class coffeemenu implements menu

// 좋은 예
interface Menu
class CoffeeMenu implements Menu

→ 메뉴는 앞으로 나올 모든 음료나 빵 종류를 포함하는 가장 큰 개념

→ 클래스는 단어의 첫 글자를 모두 대문자로 작성

→ View 클래스 계층도를 그릴 때는 클래스 이름의 첫 글자는 어디에 위치하든 모두 대문자 사용

• 카멜 표기법

// 잘못된 예
int TotalCount = 0;
void OrderCoffee()

// 좋은 예
int totalCount = 0;
void orderCoffee()

• 상수는 모두 대문자로 사용

static final int COFFEE_MAX = 10;

• 패키지와 모듈은 모두 소문자로 사용

// 안좋은 예
kr.co.wikibook.android.DeveloperWriting
import DeveloperWriting

// 좋은 예
kr.co.wikibook.android.developerwriting
import developerwriting

• BEM 표기법
• CSS에서 사용하며, BEM 표기법은 ‘대상—요소__상태’를 의미

.form ()
.form__button ()
.form__button--disabled ()

• i는 변수 이름이지만 d는 아니다
• i는 정수를 뜻하는 integer와 지수를 뜻하는 index의 첫 글자로 간주됨.
• a, d 와 같이 아무런 의미가 없는 글자를 변수로 쓰는 것은 좋지 않다.

// 안 좋은 예
int d
int m
int y

// 좋은 예
int someday
int today
int thisMonth
int finalYear

• 중요한 단어를 앞에 쓴다.

• 총 방문자 수를 나타내는 변수를 보통 totalVisitor로 그대로 번역하여 쓰지만, total이라는 수식어보다는 본래 의미를 뜻하는 visitor을 앞에 쓰는 것을 추천한다.

• 좋은 이름이 가진 5가지 특징

1. easy to Search 검색하기 쉽고
2. easy to Mix 조합하기 쉽고
3. easy to Agree 수긍하기 쉽고
4. easy to Remember 기억하기 쉽고
5. easy to Type 입력하기 쉽고

• 이름을 잘 지으면 주석을 줄일 수 있다.

// 안 좋은 예
int h = 480 // 스크린 최대 높이를 480으로 지정

// 좋은 예
int screenHeightMax = 480

• 주석이 필요한 때도 많다.

• 영어 실력이 낮은 개발자들에게 한글 주석으로 한 번 더 설명함으로써, 잘못된 영작문이나 실수를 줄일 수 있따. 주석이 코드의 정확성을 높이고 버그를 줄이는 계기가 된다. 주석이 제 역할에만 충실하다면 많고 적고는 상관이 없다.

• 코드는 의미를, 주석은 의도를

• 같은 주석이라도 반복해서 사용하는 것이 좋다.

• 주석의 악순환에서 벗어나는 가장 좋은 방법은, 주석도 코드라고 생각하는 것.

4) [3장] 사용자와 소통하는 에러 메시지 쓰기 93p ~ 117p

• 개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자.

  • 개발자용 에러 메시지 : code404, 501, 505 등.
  • 사용자용 에러 메시지 : 에러의 내용, 에러의 원인, 해결 방법이 포함되어있어야 한다.
    1. [에러 해결 방법] 3초 후에 다시 시도하십시오.
    2. [에러 원인] 아이템을 인계받을 상대방에게 다른 사용자가 인계중입니다.
    3. [에러 내용] 요청하신 아이템의 인계를 시간 내에 처리하지 못했습니다.
  • alert와 confirm을 구별하고, 버튼 메시지
  • 가능하다면 ‘취소’라는 말보다 더 구체적인 행동을 말로 전하는 것이 좋다. Q. 편집한 내용을 삭제하고 다른 페이지로 이동하시겠습니까? A. btn1 : 예 btn2 : 아니오

  Q. 편집한 내용을 삭제하고 다른 페이지로 이동하시겠습니까? A. btn1 : 이 페이지에 나가기 btn2 : 이 페이지에 머물기

• 사용자의 반복 에러를 막는법

  • 같은 메시지가 반복될 때는 사용자는 무시하기 일쑤다. 이런 경우, 사용자에게 앞으로 남은 횟수를 메시지로 보여주면 된다. ex) 0회 남았습니다.

• 에러 메시지 대신 예방 메시지를 쓰자.

  • 사용자가 입력할 때 자주 실수하는 것을 파악하고 개발하자.
  • 에러 메시지를 보여주기 전에 개발자 스스로 사용자를 어떤 관점으로 보는지 생각해야한다.

5) [4장] 독자 관점에서 릴리스 문서와 장애 보고서 쓰기 120p ~ 159p

• 체인지 로그의 양과 만족도의 관계

  • 일을 보고할 때 글을 지나치게 줄여 쓰면 일을 안 한 것처럼 보이고,
  • 일의 내용을 하나씩 구체적으로 다 쓰면 아무도 읽지 않는다.
  • 읽기좋게 적절한 양일 때가 가장 좋다.

• 체인지 로그 잘 쓰는법

  • 1단계 : 선정하기
  • 2단계 : 분류하기
  • 3단계 : 요약하기
  • 4단계 : 종합하기

• 1단계 : 선정하기

  • 개발자는 보통 자기가 오랜 시간 들여 노력한 것을 쓰고, 그렇지 않은 것을 뺴는 경향이 있다. 이런 기준으로 체인지 로그를 선정해서는 안된다.
  • 개발자의 노력과 독자의 관심을 기준으로 표를 만들어 체인지 로그 우선순위를 전략적으로 선정한다.

• 2단계 : 분류하기

  • 첫 번째 : 개발 관점에서 비슷한 작업으로 묵는 방법, 릴리스 문서에서 사용하는 새로운 기능 추가, 기능 개선, 오류 수정 등
  • 두 번째 : 사용자 관점에서 비슷한 것 끼리 묶는 방법, 준비, 진행, 종료 등

• 3단계 : 요약하기

  • 문장 단위로 요약한다. 서술식 문장을 개조식 문장으로 바꾸는 방법을 쓰면 좀 더 자연스럽다.
  • 불필요한 부사나 형용사, 조사나 어미를 없애고, 정확하고 적절한 단어로 대체.

• 4단계 : 종합하기

  • 릴리스 내용 전체를 종합해서 한 문장으로 만들고 그것을 체인지 로그 첫줄에 적는다.
  • 전체를 종합하는 방법은 분석과 반대다.

• 체인지 로그는 개발자가 변경한 내용을 적는 것이다. 하지만, 체인지 로그를 보는 독자가 ‘개발자’가 아닌, ‘사용자’라면 사용자 관점에서 써야 한다.

• 사용자의 관점에서 해결될 약속, 잡은 버그, 새 기능은 어떠한 것이 있는지 적는게 좋다.

• semantic Versioning(유의적 버전)

  • 업데이트 내용에 따라 버전을 올리자.
    • 버전 1.2.2 → 1.2.3 : 간단한 패치를 의미
    • 버전 1.2.2 → 1.3.0 : 새로운 기능 추가를 의미, 세 번째 자리는 0으로 초기화.
    • 버전 1.2.2 → 2.0.0 : 전면적인 업그레이드, 이전 버전과는 거의 호환 불가능.

• 문제와 문제점을 구별하자.

  • 문제, 문제점, 해결책, 후속 계획 순으로 적자.
    • 문제 : 사용자가 급증하면서 서버가 정지
    • 문제점 : 잘못된 시스템 설정, 프로그램 비 최적화, 잘못된 DB 설계
    • 해결책 : 시스템 설정 변경
    • 후속 계획 : 프로그램 최적화, DB 재설계

• 장애 보고서의 특징

  • 첫째, 장애 보고서는 개발자가 원할 때 쓸 수 없다.
  • 둘째, 장애의 1차 원인은 대부분 다른 원인의 결과다.
  • 셋째, 장애 보고를 받는 윗사람은 대부분 개발자가 아니다.
  • 넷째, 장애를 해결했다고 해서 100% 해결한 것은 아니다.
    • 신뢰할 만한 결단을 정치적으로 내려야하며, 정치적 글쓰기가 필요하다.
      1. 질문에 대답하는 신속한 글쓰기
      2. 원인과 이유를 찾는 분석적 글쓰기
      3. 상사를 고려하는 비즈니스 관점의 글쓰기
      4. 원하는 것을 얻는 정치적 글쓰기

• 1.질문에 대답하는 신속한 글쓰기

  • 글을 빨리 쓰는 방법 중에 대화를 글로 옮기는 방법이 있다.
  • 가까운 동료와 대화할 때처럼 이 방법을 글쓰기에 그대로 적용하면 신속하게 쓸 수 있다.

• 2.원인과 이유를 찾는 분석적 글쓰기

  • 문제 해결 기법중에 5Whys가 있다.
    • 어떤 문제의 원인을 찾을 때, 근본적인 원인을 찾는 기법이다. 문제의 원인이 되는 인과 관계를 탐색할 때 다섯 번 반복해서 원인이 무엇인지 질문하는 방식이다.
    • 5Why의 why는 두 가지로 이해해야한다.
      • 사물이나 현상, 동작이 문제를 초래하는 원인
      • 사람이 문제를 초래한 이유다.

• 3.상사를 고려하는 비즈니스 관점을 글쓰기

  • 개발자 관점 : 장애로 인해 사용자가 1시간 동안 결제하지 못함
  • 비즈니스 관점 : 장애로 인해 00억 원의 매출 손실이 발생함
    • 개발자 관점은 결제 기능이 작동하지 않은 것이지만, 비즈니스 관점은 기대 매출의 손실이 발생한 것이다.
  • 비즈니스 관점으로 쓴 예시
    • 네트워크 장애로 24시간 동안 홈페이지 접속이 안 됐음
    • 홈페이지 접속 장애로 네팆는 100명가량이 접속할 수 없었음
    • 홈페이지 접속 장애로 100명의 고객이 접속하지 못해 기대 매출 손실 100만원, 비용 손실 10만원으로 총 110만원의 손실 발생함.

• 4.원하는 것을 얻는 정치적 글쓰기

  • 장애는 보통 예상하지 못한 데서 발생한다. 그러니 장애를 해결했다고 해서 다시는 그 장애가 발생하지 않는다고 볼 수 없다. 그래서 보고를 할 때 개발자는 애매할 수 밖에 없다. 그렇기 때문에 개발자는 좀 더 정치적으로 확정해서 말할 필요가 있다.
  • 재발 가능성을 도식화 하여 보고서를 쓰는 것이 좋다.
    • 1% ~ 99%, 절대 재발하지 않는다부터 반드시 재발한다 까지.
  • 정확한 단어와 문장으로 현상과 사실을 있는 그대로 표현하는 것이다.

6) [5장] 설명, 묘사, 논증, 서사로 개발 가이드 쓰기 164p ~ 199p

• 서비스 개념을 범주, 용도, 특징으로 설명하자.

  • 개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징순으로 쓰는 것이 좋다.

• 범주를 정확하고 적절하게 선택하자.

• 용도를 범주의 핵심 기능으로 기술하자.

• 특징을 장점과 강점에서 뽑아 쓰자.

  • 개발자에게 차별화는 서비스의 장점과 강점이다.

  • 장점 : 자기 기준에서 잘하는 것.

  • 강점 : 경쟁 서비스와 비교해서 나은 것.

  • 서비스 개념에서 특징을 쓸 때, 장점이자 강점인 것을 쓰는 것이 좋다.

  • 장점이자 강점인 것이 없다면 장점과 강점을 합쳐서 한 문장으로 쓰는 것도 좋은 방법이다.

    • 장점이자 강점인 것 하나를 쓴 예
    • 장점과 강점을 한 문장에 같이 쓴 예

• 글에 묘사를 더하면 이해가 빠르다.

  • [시각 묘사] : 상다리가 부러질 뻔한 워크숍
  • [청각 묘사] : 소곤소곤 깊은 대화를 나눈 워크숍
  • [후각 묘사] : 코끝을 톡 쏘는 화이트와인과 함께한 워크숍
  • [미각 묘사] : 씹고 뜯고 워크숍
  • [촉각 묘사] : 온몸으로 부대끼며 열정을 태운 워크숍

• 글과 그림의 내용을 일치시키자

• 객관적 묘사와 주관적 묘사 둘 다 하자

  • 주관적 묘사 : “저기 앞에 큰 사거리에서 오른쪽으로 돌아서 5분쯤 가면 기차역이 보여요.”
  • 객관적 묘사 : “두 번째 사거리에서 10시 방향으로 돌아서 300미터 가면 우측에 기차역이 있어요.”

• 의견을 쓰려면 근거를 대자

• 거칠게도 공손하게도 쓰지 말자

  • ‘~할 수 있지만, ~하기 어렵다, ~할 수 있지만 안 쓰는 것이 낫다, ~하면 된다.’ 식의 문장은 피하자.
  • ‘~해야 합니다 반드시 해야 하는 것은 아닙니다’를 ‘~하십시오, ~하지 마십시오’로 바꾸자.

• 주장과 이유의 거리를 좁혀서 쓰자

• 문제와 답의 거리를 좁혀서 쓰자

• 개발과 서사

  • 서사는 사실을 있는 그대로 순서대로 적는 것을 말한다.
  • 독자의 수준 대신 기술의 범용성을 기준으로 쓰자.
  • 순서에서 단계를, 단계에서 목차를 만들자.
    • 각 단계에는 반드시 목표가 있어야한다.

7) [6장] 수주를 돕는 SI 제안서 쓰기 205p ~ 227p

• 개발자와 제안PM의 차이

  • 제안서에서 개발자는 주로 기술 부문을 작성한다.
  • 개발자가 기술 부문에서 쓰기 어려운 것은 목적, 목표, 전략, 방안, 기대효과 같은 것이다.
  • 시스템 구성도의 본질은 그림이 아니다.

• 개발자가 제안서를 잘 쓰는법

  • 첫째, 제안요청서 분석
    • 제안 PM은 제안요청서에 문제와 답이 다 있다고 생각한다.
    • 개발자는 제안요청서를 다 읽지 않고 기술과 관련된 요구사항만 읽고 제안서를 쓰는 경향이 있다.
    • 개발자가 제안요청서에서 힌트를 잘 찾아내기만 하면 더 전략적으로 쓸 수 있다.
  • 둘째, 논리적 완결성
    • 항목을 논리적으로 완결하는 것이다.
    • ‘시스템 구성도’라는 항목을 작성한다면, 이 항목 안에는 시스템 구성에 관련한 고객의 요구, 고려사항, 구성 전략, 구성 목표, 구성 방안, 구성의 특장점, 기대 효과가 들어가야 한다. 그래야만 시스템 구성도를 그린 이유를 논리적으로 납득할 수 있다.

• 문제 인식과 문제 해결 능력

  • 경쟁사와 비교하여 제안하라
  • 일단 동감하고 다른 방안을 제시하라
  • 고객이 문제를 중대하게 인식하게 만들어라
  • 경쟁사의 전략을 확인해서 대처하라

• 고객의 요구사항은 변할 수 밖에 없다.

  • 개발은 고객 요구 실형
  • 요구사항을 분석하지 말고 제시하라
    • 고객에게 요구사항을 제시해서 고객이 선택하게 만들어야 하고, 그 선택에 따라 개발해야 한다.
  • 변화하는 요구사항에 대비하라

• 고객의 총 만족도를 높이자

  • 요구라고 다 같은 요구가 아니다.
    • 요구사항은 개발자 관점과 고객 관점이 다르다.
  • 카노 모델로 본 요구의 세가지 종류
    • 기본 기능은 요구를 충족하지 못하면 고객이 불만족하지만, 요구를 충족했다고 해서 고객 만족도가 크게 오르지 않는 유형이다.
    • 기능의 성능은 요구를 충족할수록 고객이 만족하고, 충족하지 않으면 고객이 불만족하는 유형이다.
    • 특별한 기능은 고객이 그다지 기대하지 않았던 것이어서 충족하지 못해도 불만족 스럽지 않는데, 만약 충족하면 크게 만족하는 유형이다.
    • 카노 모델에서 중요한 것은 같은 요구 충족이라도 시간이 자나면서 고객의 만족도가 달라진다는 것이다.
  • 개발자는 기본적으로 기본 기능 요구는 모두 수용 해야 한다. 하지만 기능의 성능 요구는 한계를 정해야만 한다.

8) [7장] 기술 블로그 쉽게 쓰고 운영하기 231p ~ 268p

• 개발자가 기술 블로그를 잘 못 쓰는 이유

  • 인문학적으로 배운대로 글쓰기는 방법이 다르기 때문이다.

• 개발자가 기술 블로그를 잘 쓰는 방법 3가지

  • 첫째, 주제 의식을 버리 고 소재 의식으로 쓰자.
    • 주제 의식은 많은 사람에게 보편적인 주제를 선택해서 더 많은 사람에게 주제의식을 퍼뜨리는 것이지만, 소재 의식은 독자와 상관없이 대상이나 상황에 마주했을 때부터 벗어날 떄까지 겪은 일을 정리한 것이다.
  • 둘째, 독자 수준이 아니라 자기 수준으로 쓰자.
    • 무조건 쉽게만 쓴 글을 읽는 독자가 그 내용을 얼마나 활용할 수 있을지 알 수 없다. 그러므로 기술 블로그를 쓸 때는 독자 수준이 아닌 작성자 수준으로 쓰는 편이 낫다.
  • 셋째, 재미있게 글을 쓰자.
    • 좋은 기술 블로그는 개발자의 경험에서 우러나오는 내용을 적절한 글쓰기 기교로 녹아낸 것이다.

• 기술 블로그의 4종류, (저, 술, 편, 집)

  • 저 : 개발기는 목차를 잘 잡아서 본문부터 쓰자.
    • 아키텍처나 알고리즘, 모델, 플로우 등이 된다.
  • 술 : 원전을 비교하고 실험해 풀이해서 쓰자.
    • 원전의 두 용어나 대상을 비교하면서 풀이하는 것이 바로 술의 역할이다.
    • 원전의 내용을 먼저 쓰고 비교한 내용을 추가하는 것만으로 기술 블로그를 쉽게 쓸 수 있다.
  • 편 : 순서를 요약하여 쓰자.
    • 산만하고 복잡한 자료를 편집해 질서를 부여한 것이다.
    • 할 일을 순서대로 하나씩 얘기하는 것이 아닌, 적정한 단계로 나눠서 설명하는 것이다.
  • 집 : 글쓰기가 두렵다면 자료를 모아 핵심을 엮어서 쓰자.
    • 여러 사람의 견해나 흩어진 자료를 한데 모아 정리하는 것이다.
    • 내용을 많이 쓰는 것이 아닌, 핵심만 간결하게 정리한 것이다.

• 기술 블로그는 회사의 가치를 높인다.

• 기술 블로그도 투자를 해야 살아난다.

• 개발자의 글쓰기 는 회사의 문화를 반영한다.

• 협업해서 글쓰기, 짝 글쓰기를 해보자

9) [에필로그] 회사가 개발자 글쓰기 교육을 하자 272 p ~ 276p

• 회사가 개발자에게 글쓰기를 체계적으로 교육해야 개발자들의 글쓰기 수준이 높아진다.

4. 내 생각 비교하기

해당 도서를 읽기 전, 이 책을 모두 읽고나면 개발할 때의 레벨이 한층 더 성장해 있을 것 같다라는 생각을 했었다. 하지만 이 책의 여러 서평을 읽고서 나의 생각도 그리 다르지만은 않았다. 책의 제목대로 개발자의 글쓰기는 코딩의 관련된 내용 보다 더 인문학적인 내용이 더 많다는 것을 알 수 있었다. 내가 원했던 건 좀 더 세분화된 변수 네이밍을 어떻게 짓는가 혹은, 그런 관련 사이트들의 대한 내용이나 확실하게 내가 모르고 있던 것이나 새로이 알게되어 더 써먹을 수 있는 것 이러한 내용들을 기대했지만 조금의 실망감을 가졌다. 그렇다고해서 이 도서의 내용이 잘 못 됐다 라고 하기보다, 기술 블로그나 제안요청서와 같은 현재는 나에게 그리 필요하지않은 내용이었지만, 이것을 알아둠으로써 내 자신이 언젠가는 쓰게될지도 모르는 것들을 미리 예습한다 라고 생각하니 괜찮은 편이였다. 기존에 알고있던 내용들도 한번 더 반복함으로써 더 명확하게 알게되었고 관심 밖이였던 기술블로그, 제안요청서, 릴리스 노트 작성 법 등 해당 도서를 통해 이런 내용을 접함으로 추후 내가 더 성장했을 때, 필요함을 느꼈을 때 해당 도서를 다시 찾을 수 있는 그러한 책이였다.