Docs: Update Writing_for_Developers/Chapter06~07.md

Writing_for_Developers/Chapter06.md

@@ -0,0 +1,9 @@
+## 6장: 수주를 돕는 SI 제안서 쓰기
+
+*SI부분은 최대한 요약해서 작성, 나중에 필요하면 다시 읽어보기*
+
+### 개발자가 알아야 할 제안서 작성 원칙
+
+#### 개발자와 제안 PM의 차이
+
+개발자라고 코드만 작성하지 않는다. 업계에 따라 개발자도 제안서를 많이 작성해야 한다.

Writing_for_Developers/Chapter07.md

@@ -0,0 +1,71 @@
+## 7장: 기술 블로그 쉽게 쓰고 운영하기
+
+### 기술 블로그를 쉽게 쓰는 방법 3가지
+
+#### 개발자가 기술 블로그를 잘 못 쓰는 이유
+
+개발자가 기술 블로그를 잘 못 쓰는 이유 중 하나는 블로그에 글을 쓰는 방법이 학생이었을 때 배운 글쓰기 방법과 다르기 때문이다. 학생이었을 때 배운 글쓰기 방법은 주로 논설문이나 설명문을 쓰는 방법이었다. 논설문이나 설명문은 목적이 분명해야 해서 다음 질문에 먼저 답할 수 있을 때 비로소 글쓰기를 시작할 수 있다.
+
+- 이 글을 왜 쓰는가?
+- 이 글을 읽는 독자는 누구인가?
+- 이 글을 읽는 독자에게 무엇을 말하려고 하는가?
+- 이 글이 주장하는 바가 무엇인가?
+- 이 글이 주장하는 바의 근거가 분명한가?
+
+이런 질문에 대답해야 하니 글쓰기는 자연스럽게 문제해결 과정이 되었다. 글쓰기를 문제해결 과정으로 배운 것이다. 문제해결 과정의 핵심은 문제를 충분히 고민하여 해결 방안을 전략적으로 선택하는 것이다. 이를 글쓰기에 대입하면, 글을 쓰기 전에 계획을 세우는데, 이 계획 단계에 시간을 충분히 할애해야 한다.
+
+무턱대고 글부터 쓰면 안 되고, 충분히 생각해서 주제를 정하고 주제 의식을 확립한 후 글을 쓸 때 자료나 아이디어를 구해야 한다. 그러고 나면 독자를 분석해서 글의 수준이나 방향을 정해야 한다.
+
+기술 블로그를 읽는 독자의 수준은 일정하지 않다. 개발자 블로그를 보는 사람은 대부분 개발자이지만, 개발자의 폭과 깊이가 천차만별이다. 개발자의 블로그는 딱히 주장도 없다. 단지 개발자가 했던 선택과 몇몇 상황에서 더 좋은 방법을 제시할 수 있을 뿐이다. 독자에게 그렇게 하라고 주장해서 설득하고 싶은 마음을 가진 개발자는 전혀 없다.
+
+저자가 추천하는 블로그에 글 쓴느 적합한 3가지 방법을 소개한다. 첫째 소재 우선 글쓰기, 둘째 자기 수준 글쓰기, 셋째 재미있는 글쓰기다.
+
+#### 첫째, 주제 의식을 버리고 소재 의식으로 쓰자
+
+소재 우선 글쓰기는 주제 의식이 아니라 소재 의식을 갖고 쓰는 것이다. 주제 의식이 민족이나 권선징악, 자존감이나 자본주의와 같은 추상적 가치를 기반으로 한다면 소재 의식은 특정한 대상이나 상황에 대한 자기만의 관점이나 생각, 해결 방안을 뜻한다.
+
+- ex) 소재 의식: 데이터베이스의 자동증가 값을 기본키로 사용할 수 없을 때는?
+
+이러한 점에서 기술 블로그는 일상을 다룬 수필이나 에피소드와 비슷하다. 수필을 평가하는 평론가나 국어 선생님들이 수필의 주제를 찾는 것이지, 수필을 쓰는 사람은 그저 일어난 이야기를 할 뿐이다.
+
+#### 둘째, 독자 수준이 아니라 자기 수준으로 쓰자
+
+글쓰기 전문가들은 다른 글을 쓸 때 초등학생도 이해할 수 있도록 쉽게 풀어서 쓰라고 한다. 하지만 직장에서 하는 일을 초등학생에게 풀어서 설명하기는 어렵다.
+
+면접에서 정말 많이 나오는 질문인 초등학생, 중학생 수준이라고 생각하고 기술을 설명해달라는 질문이 있다. 이 질문에 대한 답변은 대부분이 비유를 하여 쉽게 설명한다.
+
+개발자가 기술 블로그를 쓸 때는 독자를 생각해서 굳이 어려운 용어를 해석해 풀어쓰거나 쉬운 용어로 바꿀 필요가 없다. 원래 사용하는 용어로 표기하되, 필요하다면 그 용어를 설명하는 링크를 걸어두면 된다. 기술 블로그란 것은 결국 실력이 비슷한 독자를 위한 것이다. 독자에게 설명하는 것이 아니라 핵심만 쓰고 나머지는 독자가 공부할 수 있게 길만 터놓는 것이 현명한 방법이다.
+
+그래야 개발자도 자기가 쓰려는 글의 본질에 집중할 수 있다.
+
+#### 셋째, 재미있는 글을 쓰자
+
+논문이나 기술 메뉴얼, 사용 설명서를 쓸 때는 자신의 경험을 녹여내거나 글의 기교를 부릴 여지가 별로 없다. 이런 글은 군더더기 없이 깔끔하지만, 글 쓰는 재미나 읽는 재미가 별로 없다.
+
+글쓰기 기교는 글을 아름답게 만들고 쉽게 읽히게 한다. 기교를 부리다 보면 글쓰기가 재미있고 글도 재미있어진다. 글에 재미가 있으면 독자가 활발히 반응하고 독자의 반응이 활발하면 블로거는 글을 계속 쓸 동력을 얻는다. 글쓰기 기교는 이렇게 선순환을 만든다.
+
+### 글의 종류별로 목차 잡는 법 1 - 저술
+
+#### 기술 블로그의 4종류, 저, 술, 편, 집
+
+개발자가 기술 블로그에 쓰는 종류는 매우 다양하다. 직접 개발한 과정, 튜토리얼, 개발 가이드, 에러나 버그를 해결하는 방법, 세미나 후기나 책 리뷰, 스스로 깨달은 교훈, 각종 레퍼런스, 개발 상식 등 수도 없이 많다. 하지만 이런 글은 모두 4가지로 분류할 수 있다.
+
+|구분|내용|종류|
+|---|---|---|
+|저|직접 경험하고 실험한 내용이나 결과|개발기, 도입기, 적용기|
+|술|어떤 것을 분석하여 의미를 풀이하고 해석한 것| 기술 소개, 용어 분석, 에러 해결 방법 등|
+|편|산만하고 복잡한 자료를 편집해 질서를 부여한 것|프로그램 설치/설정 방법, 튜토리얼, 세미나 후기, 책 리뷰|
+|집|여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것|명령어 모음, 팁, 00가지 규칙|
+
+#### 저: 개발기는 목차를 잘 잡아서 본문부터 쓰자
+
+저는 직접 경험한 것을 쓴 것이다. 개발 과정과 결과를 쓴 개발기가 여기에 해당한다.
+
+- 맵 절차적 생성기를 활용한 게임 개발기
+- 유니티 게임 고도엔진으로 포팅하기
+
+개발 과정과 결과를 다룬 개발기를 쓸 때는 무엇보다 목차를 잘 구성해야 한다. 목차만 제대로 잡으면 다른 종류의 글보다 쓰기 쉽다. 다시 말하면, 많은 개발자가 개발기 목차를 구성하지 못해서 개발기를 잘 못 쓴다.
+
+개발기 목차는 1차원 단방향이다. 1장 다음에는 2장이 이어지고, 2장 다음에는 3장이 순서대로 이어진다. 하지만 개발자의 경험은 2차원 양방향이다. A문제를 해결하려고 했지만, 다시 E문제가 생기고 F코드를 썼는데 G 버그가 생겨서 한참을 복기하다가 H 코드로 바꾸는 식으로 경험한다. 그래서 개발자 머릿속에는 자신의 경험이 길을 잃고 헤매다 겨우 목적지에 도착한 모습으로 남아 있다. 이렇게 복잡한 2차원 양방향 개발 경험을 1차원 단뱡향 목차로 바꾸어야 하니 어렵다.
+
+2차원 양방향 경험을 1차원 단방향 목차로 바꾸는 핵심 방법은 최종적으로 성고한 루트와 실패한 루트를 구별하는 것이다.