쓰기

📀 머리말

---

좋은 글을 쓰는 방법에 대해 다룬다.
좀 더 넓게 생각한다면, 생각을 쉽게 정리하고 잘 전달할 수 있는 방법.

📀 핵심

---

• 글의 주제를 파악 (출제자의 의도)
• 결국 알고 싶은 /결과는 주장
  • 주장, 요약을 앞에 (먼저)
• 설명/근거/내용은 뒤에
  • 주장을 쉽게 공감할 수 있는 자료, 숫자, 표 ,그래프
  • 생략 가능한 것은 생략 (심플하게, 화려하지 않게)
• 전체적으로
  • 전체량, 진행도 알 수 있게 (1/n) 처럼
  • 눈에 보이는 진척도
• 그리고
  • Ref는 몰아넣지말고 연관된 내용이 있는 곳에
  • 이해도 몇 %

📀 문장과 단락의 구조화

---

💿 문장을 구조화 하기

간단한 문장 구조로 핵심만 말한 뒤, 필요에 따라 설명을 하면 된다.
첫 문장의 주어를 가져다가 소제목으로 만들면 자연스럽게 문단을 구성할 수 있다.

색상 RGB 값을 각각 사용하기 때문에 입력 데이터는 3차원 벡터다.

-> ‘색상 RGB 값을 사용한다’와 ‘입력 데이터는 3차원 벡터다’를 모두 떠올린 다음, 두 문장의 관계를 연결 (~때문에) 하는 것까지 생각해야 한다.
-> 주어를 앞으로

입력 데이터는 색상 RGB를 각각 사용하기 때문에 3차원 벡터다.

-> 인과 관계가 있는 복문이므로, 두 문장으로 나눌 수 있다.

입력 데이터는 색상 RGB 값을 각각 사용한다. 그래서 입력 데이터는 3차원 벡터다.

-> 먼저 머릿속에서 본인이 잘 아는 내용을 바로 쓴다.

입력 데이터는 3차원 벡터다.

-> 그리고 필요하다면 그것을 더 자세하게 설명한다.

입력 데이터는 3차원 벡터다. 이는 색상 RGB 값을 각각 사용하기 때문이다.

💿 서술식, 개조식, 도식

• 서술식 : ‘~다’로 끝나는 완전한 문장으로 구성된 글
  • 줄거리가 있는 설명이나 이야기 (소설, 신문), 개발 가이드 같은 문서
• 개조식 : 명사나 용언의 명사형으로 끝나는 문장으로 구성된 글
  • 여러 가지 종류의 항목과 내용이 반복되거나 서술식에서 강조가 필요한 내용
  • 릴리스 문서나 장애 보고서, 설치 가이드 같은 문서
  • 내용의 중복과 누락이 있다 -> 도식으로 정리
  • 논증/논리관계에 대해 기호를 사용 (→, ∵, ∴, >, <, = 등)
  • 간락을 구조화하는 위계
    • 위계 : 2차원 평면의 좌표 - 급이 낮은 문장을 더 들여쓰기
    • 계층 : 3차원 입체의 높이 - 굵기, 모양, 밑줄, 줄 간 거리 등
• 도식 : 사물의 구조나 관계, 상태를 그림이나 서식으로 보여주는 것
  • 가장 간단한 형태의 도식은 행과 열로 이뤄진 표 (Table),
  • 그림이 있으면 도표 (Graph/Chart)
  • 각 항목이나 사항의 관계를 명확히 규정하고 싶다면

💿 가장 쉬운 띄어쓰기 원칙

• 조사, 순서, 숫자, 하다, 기호만 붙이고 나머지는 띄어 쓴다.
  • 조사 : 쉼표
  • 기호 : 괄호 붙여 쓰기

💿 오해하기 쉬운 문장 부호(큰따옴표, 작은따옴표)

📀 개발 블로그

---

기교를 집어넣기
유키피디아 대신 나무위키 처럼
내 이야기를 쓰자
내 수준에서 쓰자

• 저 : 직접 경험하고 실험한 과정이나 결과 | 개발기, 도입기, 적용기
• 술 : 어떤 것을 분석하여 의미를 풀이하고 해석한 것 | 기술 소개, 용어분석, 에러 해결 방법 등
• 편 : 산만하고 복잡한 자료를 편집해 질서를 부여한 것 | 프로그램 설치/설정 방법, 튜토리얼, 세미나 후기, 책 리뷰
• 집 : 여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것 | 명령어 모음, 팁, @@가지 규칙

개발자의 기술 블로그는 어떤 경우에도 모두 통용되는 완벽한 답이나 공식을 낼 수 없다.
단지 특정 상황에 적합한 방법을 찾아내고 추천할 뿐이다.
즉, 기술 블로그를 쓰는 개발자는 ‘경전’을 쓰는 사람이 아니라 경전을 자기 방식으로 풀이하는 사람이다.
옳고 그름의 문제가 아니라 특정 상황에서 이렇게 하는 것이 낫다는 정도로만 쓴다고 생각하면 부담이 덜할 것이다.

💿 저

개발기는 목차를 잘 잡아서 본문부터 쓰자

목차는 1차원 단방향, 하지만 개발자의 경험은 2차원 양방향
이걸 써보려다 실패하고, 다른 걸 써보려다 실패해서 다시 돌아오고..

핵심은 최종적으로 성공한 루트와 중간에 실패한 루트를 구별하는 것
최종 루트를 기준으로 목차를 쓰고, 갔던 길을 돌아가거나 빙 둘러간 루트는 최종 루트 다음에 문제 해결이나 팁으로 정리해 덧붙인다.

무엇부터 쓸까?

보통 처음부터 쓰려고 하지만, 개발자가 가장 잘 쓰는 것은 본문.
목차를 정했으면 머리말부터 쓰지 말고 본문부터 쓰자.
아키텍처나 알고리즘, 모델이나 플로 같은 산출물 이미지를 먼저 붙여넣고 글을 쓰면 단번에 몇 단락을 쓸 수 있다.

그렇게 해서 본문을 쓰고 나면 맺음 말을 쓰고, 머리 말은 맨 마지막에 블로그에 올릴 때 생각나는 대로 간략히 쓰면 된다.

💿 술

어떤 것을 분석하여 의미를 풀이하고 해석한 것

인문학에서 술은 경전을 해설한 글을 말한다
개발에도 원전, 즉 원서나 원문, 프로토콜이나 레퍼런스가 있다.

술에 해당하는 기술 블로그를 쓸 때는 본래 내용을 바탕으로 자기 생각이나 분석, 해설을 덧붙이는 방식을 쓰는 것이 좋다.

사람은 어떤 사물을 그 자체로 인식하기보다는 다른 사물과 비교하면서 인식할 때 더 잘 이해한다.
하지만 원전은 사물 하나하나를 설명할 뿐이지 두 사물 사이의 공통점이나 다른 점을 뚜렷이 밝히지는 않는다.
그래서 원전의 두 용어나 대상을 비교하면서 풀이하는 것이 바로 술의 역할이다.

• HTTP : 상위 범주
• GET : 원전 HTTP 프로토콜 참조
• POST : 원전 HTTP 프로토콜 참조
• GET과 POST의 차이점
• 참고

이렇게 원전의 내용를 먼저 쓰고 비교한 내용을 추가하는 것만으로 기술 블로그를 쉽게 쓸 수 있다.

위 예시는 개발자가 자기 생각을 이론적으로 펼친 것이다.
그런데 원전의 내용을 직접 실험해 비교한 뒤 그 내용을 정리해 풀이할 수도 있다.
실제로 기업에서는 서비스 성능을 높이기 위해 여러 가지 실험을 많이 하므로 그 결과를 잘 정리하기만 해도 좋은 글이 된다.

• 용어 정리
• 배경
• 이유
• 이유
• 영향
• 기준 (팁)

💿 편

순서를 요약하여 쓰자

산만하고 복잡한 자료를 편집해 질서를 부여한 것
우리나라 역사 교과서를 집필하는 곳이 ‘국사편찬위원회’인데, 여기서도 ‘편’이라는 글자를 사용한다.
그 이유는 역사를 고대사부터 현대사까지 시간 순서로 설명하기 때문이다.

그래서 보통 편은 시간 순서로 일어난 일이나 해야 할 일을 쓴 것을 통칭하기도 한다.
프로그램 설치나 설정 순서, 개발 방법, 튜토리얼, 개발자 컨퍼런스 후기 같은 것이 여기에 해당된다.

시간 순서로 하나씩 나열해 내용을 쓴 다음, 단계로 묶어서 요약하기만 하면 글이 완성된다.
장황하게 일단 나열하고, 단계를 만들어서 묶은 뒤 하위 내용을 간략히 요약한다.
국사 교과서처럼 질서가 잡힌다.

💿 집

글쓰기가 두렵다면 자료를 모아 핵심을 엮어서 쓰자.

여러 사람의 견해나 흩어진 자료를 한데 모아 정리하는 것이다.
자료가 아니라 비슷한 여러 책을 한데 모아 출간한 것을 전집이라고 하는데,
이때 ‘집’은 단순히 여러 책을 모은 것이고, 지금 얘기하는 ‘집’은 자료를 모아 하나의 책으로 엮은 것을 뜻한다.

집은 여러 자료를 책 한권에 모은 것이니 내용을 이것저것 아무렇게나 다 집어넣을 수가 없다.
그래서 자료나 견해에서 요점이 되는 것만 모아야 하는데,
그렇게 해서 쓴 책을 집요하고 한다.

집은 내용을 많이 쓰는 것이 아니라 핵심만 간결하게 정리한 것이다.
그래서 글 전체가 길지 않고 내용이 각각 나열되어 있다.

기술 블로그에서는 명령어 모음, 팁, @@가지 규칙 같은 것이 집에 해당한다.

• 자바스크립트 정규표현식 코딩팁
• 스크롤과 관련된 CSS 속성 3가지
• 좋은 코딩을 위한 13가지 간단한 규칙
• 데이터 사이언스 인터뷰 질문 모음집

집이라고 해서 반드시 여러 사람의 견해나 자료를 모아야만 하는 것은 아니다.
본인이 경험에서 터득한 것을 핵심만 정리해서 나열해도 좋은 집이 될 수있다.

📀 메모

---

💿 메모

• 두괄식 : 머리에 글의 주제가, 핵심/정리/쉬운
• 미괄식 : 꼬리에 글의 주제가, 줄거리/서사/과정/부끄러운
• 부사 많이 쓰지 않기

줄바꿈은 말이 끊어지는 곳에서.

길면 나눠라
(만화의 경우) 말풍선 하나에 4줄이상이면 가독성이 급격하게 떨어진다. 적당한 곳에서 나누는 것이 좋다.

절대로/반드시,꼭 (Like 너무/아주)
분명하게 적기 (능동/수동)
짧은 단어, 쉬운 말

💿 참고

• 개발자의 글쓰기