시작하며 — 글은 생각의 결과가 아니라 도구다
많은 사람이 글쓰기를 이렇게 이해합니다. 머릿속에서 생각이 다 정리된 뒤, 그 완성된 생각을 종이에 옮겨 적는 일. 이 순서대로라면 글쓰기는 단순한 받아쓰기에 가깝습니다. 생각이 먼저고, 글은 그 그림자라는 것이죠.
그런데 실제로 무언가를 진지하게 써 본 사람은 압니다. 그 순서가 거꾸로일 때가 훨씬 많다는 것을. 쓰기 전에는 다 안다고 느꼈던 주제가, 막상 문장으로 옮기려는 순간 와르르 무너집니다. "나는 이 문제를 이해하고 있다"는 느낌과 "나는 이 문제를 한 문장으로 설명할 수 있다"는 능력 사이에는 생각보다 큰 간극이 있습니다.
이 글은 그 간극에 관한 이야기입니다. 글쓰기를 표현의 기술이 아니라 사고의 도구로 다루는 방법, 그리고 그것을 일상의 루틴으로 만드는 구체적인 방법을 다룹니다. 자기계발서식의 과장("글쓰기가 인생을 바꾼다")은 최대한 걷어내고, 실제로 책상 앞에서 무엇을 어떻게 하면 되는지에 집중하겠습니다.
> "글로 쓸 수 없다면, 당신은 그것을 충분히 이해하지 못한 것이다. 글쓰기는 당신의 생각이 얼마나 엉성한지 드러낸다."
> — 폴 그레이엄, 에세이 "Putting Ideas into Words"
1. 왜 쓰면 생각이 명료해지는가
머릿속 생각은 생각보다 흐릿하다
머릿속에서 생각은 빠르고 매끄럽게 흘러갑니다. 그런데 이 매끄러움은 종종 착각입니다. 우리는 개념들을 정확히 연결한 게 아니라, 대충 뭉뚱그린 채 "이해했다"는 느낌만 가지고 넘어갑니다. 인지과학에서는 이를 "설명의 깊이에 대한 착각(illusion of explanatory depth)"이라고 부릅니다. 지퍼나 변기처럼 매일 쓰는 물건조차, 작동 원리를 자세히 적어 보라고 하면 대부분 막힙니다.
글쓰기는 이 착각을 깨는 장치입니다. 문장은 선형적입니다. A 다음에 B, B 다음에 C를 놓아야 합니다. 머릿속에서는 동시에 떠다니던 개념들을 강제로 한 줄로 세우는 순간, 빠진 연결 고리가 드러납니다. "그래서 A가 B로 이어진다"고 쓰려는데 그 "그래서"가 설명되지 않으면, 거기에 구멍이 있는 것입니다.
글쓰기는 외장 메모리이자 디버거다
작업 기억(working memory)은 좁습니다. 한 번에 다룰 수 있는 항목이 몇 개에 불과합니다. 복잡한 문제를 머릿속에서만 굴리면, 한쪽을 붙잡는 순간 다른 쪽을 놓칩니다. 글은 이 작업 기억을 종이 위로 확장합니다. 일단 적어 두면 그 항목은 더 이상 머리로 붙들 필요가 없고, 남은 자원으로 다음 단계를 생각할 수 있습니다.
또한 글은 디버거처럼 작동합니다. 코드를 한 줄씩 실행하며 어디서 틀어졌는지 보듯, 생각을 한 문장씩 적으며 어디서 논리가 어긋나는지 봅니다. "쓰다 보니 내가 틀렸다는 걸 알았다"는 흔한 경험은, 글쓰기가 사고의 오류 검출기라는 증거입니다.
명료한 글과 흐릿한 글 — 같은 내용, 다른 사고
같은 주제를 두고 두 가지로 적어 보겠습니다.
흐릿한 버전:
> 우리 서비스가 느려진 것 같다. 트래픽도 많아진 것 같고, DB도 좀 문제가 있는 것 같아서, 캐싱 같은 걸 좀 해 보면 나아지지 않을까 싶다.
명료한 버전:
> 지난주 응답 시간 p95가 800ms에서 2.1초로 늘었다. 같은 기간 요청량은 1.4배 증가했고, 느려진 요청의 92%가 상품 상세 API에 집중돼 있다. 이 API는 매 요청마다 상품/재고/리뷰 세 테이블을 조인한다. 재고와 리뷰는 30초 캐싱해도 무방하므로, 우선 이 둘을 캐싱해 조인을 줄이는 방안을 제안한다.
두 글의 차이는 글솜씨가 아닙니다. **사고의 해상도**입니다. 흐릿한 버전을 쓴 사람은 아직 문제를 모릅니다. 명료한 버전을 쓰려면 숫자를 확인하고, 원인을 좁히고, 해결책을 특정해야 합니다. 즉 명료하게 쓰려는 시도 자체가 생각을 명료하게 만듭니다.
2. 페인만 기법 — 가르치듯이 써라
물리학자 리처드 페인만은 어떤 개념을 제대로 이해했는지 확인하는 방법으로, 그것을 처음 배우는 사람에게 설명해 보라고 했습니다. 흔히 "페인만 기법"이라 불리는 이 방법을 글쓰기로 옮기면 이렇습니다.
1. 설명할 개념 하나를 고른다.
2. 전문 용어를 쓰지 않고, 아무것도 모르는 사람에게 가르치듯 글로 풀어 쓴다.
3. 막히는 지점, 즉 "이건 그냥 그런 거야"로 얼버무리게 되는 지점을 표시한다.
4. 그 지점이 바로 당신이 모르는 부분이다. 자료로 돌아가 다시 채운다.
5. 설명이 매끄러워질 때까지 반복한다.
핵심은 3번입니다. 전문 용어는 종종 모름을 가리는 가면입니다. "이건 비동기로 처리됩니다"라고 쓰면 그럴듯하지만, "요청을 보낸 뒤 답을 기다리지 않고 다음 일을 하다가, 답이 오면 그때 처리합니다"라고 풀어 쓰려는 순간 내가 정말 아는지 드러납니다.
페인만식 글쓰기 체크리스트
- [ ] 중학생도 이해할 만한 단어로 썼는가?
- [ ] "왜?"라고 한 번 더 물었을 때 대답할 수 있는가?
- [ ] 비유를 하나 들 수 있는가? (비유가 안 떠오르면 아직 이해 못 한 것일 수 있다)
- [ ] 설명하다 슬쩍 넘어간 부분이 있는가? 그곳을 따로 적었는가?
- [ ] 다 쓴 글을 읽으며 "그래서 결국 뭐?"에 답할 수 있는가?
3. 도구별 글쓰기 — 어디에 무엇을 쓰는가
생각을 위한 글쓰기는 한 가지 형식이 아닙니다. 목적에 따라 적합한 그릇이 다릅니다.
비교표 — 사고를 위한 글쓰기 형식
| 형식 | 주목적 | 길이 | 독자 | 쓰는 시점 |
| --- | --- | --- | --- | --- |
| 데일리 메모 | 그날의 생각 비우기 | 짧음 | 나 자신 | 매일 |
| 디자인 문서 | 결정 전 설계 정리 | 김 | 팀 | 일을 시작하기 전 |
| 의사결정 기록 | 왜 그렇게 정했는지 보존 | 중간 | 미래의 우리 | 결정 직후 |
| 회고 | 무엇을 배웠는지 추출 | 중간 | 나와 팀 | 일이 끝난 뒤 |
| 공개 글 | 배운 것을 나누고 검증 | 김 | 불특정 다수 | 정리가 된 뒤 |
표가 말하는 핵심은, 글쓰기를 한 가지 무거운 행위로 보지 말라는 것입니다. 매일의 짧은 메모와 분기마다의 긴 회고는 둘 다 사고를 위한 글쓰기지만, 부담의 크기가 전혀 다릅니다.
디자인 문서 — 만들기 전에 써라
코드를 짜기 전에 디자인 문서를 쓰는 습관은, 사고를 위한 글쓰기의 가장 실용적인 사례입니다. 핵심은 "구현"이 아니라 "왜"와 "무엇"을 먼저 적는 것입니다.
[디자인 문서 골격]
1. 문제 (Problem)
- 지금 무엇이 불편하고, 누가 영향을 받는가?
- 이 문서가 풀려는 것과 풀지 않는 것(Non-goals)
2. 배경 (Context)
- 현재 어떻게 동작하는가?
- 관련된 제약(시간, 자원, 기존 시스템)
3. 제안 (Proposal)
- 어떻게 풀 것인가? 핵심 설계
- 데이터 흐름 / 인터페이스
4. 대안 (Alternatives)
- 고려했지만 택하지 않은 안과 그 이유
5. 위험 (Risks)
- 무엇이 잘못될 수 있는가? 어떻게 대비하나?
6. 미해결 질문 (Open questions)
이 골격을 채우다 보면, 키보드를 한 글자도 두드리기 전에 설계의 허점이 드러납니다. "대안" 항목을 채우다가 더 나은 방법을 발견하는 일도 흔합니다. 디자인 문서의 가치는 문서 자체가 아니라, **그것을 쓰는 동안 강제되는 사고**에 있습니다.
의사결정 기록(ADR) — 미래의 나를 위해
결정을 내린 직후, 짧게라도 "왜 이렇게 정했는가"를 적어 두면, 6개월 뒤 "도대체 왜 이렇게 했지?"라는 질문에 답할 수 있습니다. 의사결정 기록은 보통 이렇게 짧습니다.
제목: 세션 저장소로 Redis를 선택
상태: 채택
맥락: 다중 서버 환경에서 세션 공유가 필요. 후보는 DB, Redis, 쿠키 기반.
결정: Redis 사용.
이유: DB는 조회 부하가 크고, 쿠키 기반은 크기 제한과 보안 우려가 있음.
결과: 운영할 캐시 서버가 하나 늘어남. 장애 시 세션 유실 대비 필요.
4. 매일 쓰기 — 부담 없이 지속하는 루틴
작게, 그러나 매일
사고를 위한 글쓰기에서 가장 흔한 실패는 "거창하게 시작했다가 사흘 만에 그만두는 것"입니다. 해법은 단순합니다. 기준을 우스울 만큼 낮추는 것. 하루 세 문장이면 충분합니다.
- 오늘 가장 오래 붙잡은 문제는 무엇이었나?
- 그 문제에 대해 지금 내가 아는 것과 모르는 것은?
- 내일의 나에게 한 문장 남긴다면?
이 세 줄은 5분이면 됩니다. 중요한 건 완성도가 아니라 "생각을 머리 밖으로 꺼내는 동작"을 매일 반복하는 것입니다. 근육처럼, 글쓰기는 빈도가 강도를 이깁니다.
모닝 페이지 vs 저녁 회고
| 비교 항목 | 아침 글쓰기 | 저녁 글쓰기 |
| --- | --- | --- |
| 목적 | 하루를 설계, 머리 비우기 | 하루를 정리, 배움 추출 |
| 분위기 | 발산적, 자유로움 | 수렴적, 평가적 |
| 좋은 점 | 우선순위가 또렷해짐 | 그날의 교훈이 남음 |
| 주의점 | 자칫 공상으로 흐름 | 피곤하면 건너뛰기 쉬움 |
정답은 없습니다. 자신의 리듬에 맞는 한쪽을 골라 먼저 습관으로 만든 뒤, 필요하면 다른 쪽을 더하면 됩니다.
지속을 돕는 작은 장치들
- 같은 장소, 같은 시간에 쓴다. 결정 비용을 없앤다.
- 빈 화면 대신 질문이 적힌 템플릿에서 시작한다.
- 맞춤법과 문장은 신경 쓰지 않는다. 초고는 원래 엉성하다.
- "오늘은 한 줄만"이라는 최소 기준을 둔다. 컨디션이 나쁜 날을 위한 안전망이다.
- 며칠 빠져도 자책하지 않는다. 끊긴 날이 아니라 다시 시작한 날을 센다.
5. 공개 글쓰기 — 배우면서 나누기
왜 굳이 공개하는가
써 둔 글을 서랍에만 두지 않고 공개하면, 사고에 새로운 압력이 더해집니다. "누군가 이걸 읽고 반박할 수 있다"는 가능성은, 대충 넘어가던 부분을 다시 보게 만듭니다. 이것이 흔히 말하는 "공개적으로 배우기(learning in public)"입니다.
공개 글쓰기의 효용은 과장하기 쉽습니다. 그래서 솔직하게 적습니다. 대부분의 글은 거의 읽히지 않습니다. 댓글로 인생이 바뀌는 일도 드뭅니다. 그럼에도 공개가 가치 있는 이유는 독자의 반응 때문이 아니라, **공개를 전제로 쓸 때 사고가 더 엄밀해지기 때문**입니다. 독자는 한 명, 미래의 당신일 수도 있습니다.
공개 글쓰기의 현실적 장단점
| 측면 | 좋은 점 | 감수할 점 |
| --- | --- | --- |
| 사고 | 엄밀해짐, 빈틈을 메우게 됨 | 시간이 더 든다 |
| 피드백 | 가끔 값진 교정과 인연 | 대체로 반응은 적다 |
| 기록 | 검색 가능한 외장 두뇌 | 틀린 글이 남는 부끄러움 |
| 평판 | 꾸준하면 신뢰가 쌓임 | 단기 성과는 거의 없음 |
틀릴까 봐 두려울 때
공개를 막는 가장 큰 벽은 "틀리면 어쩌지"라는 두려움입니다. 두 가지를 기억하면 도움이 됩니다. 첫째, 틀린 글을 공개하면 친절한 누군가가 고쳐 주기도 합니다. 침묵하면 영영 틀린 채로 남습니다. 둘째, "지금의 내 이해"라고 솔직히 밝히고 쓰면, 그것은 거짓이 아니라 정직한 기록이 됩니다. 글 끝에 "더 나은 방법을 아시면 알려 주세요"라고 덧붙이는 것만으로 부담이 크게 줄어듭니다.
6. 편집의 힘 — 초고는 생각의 재료일 뿐
쓰기와 고치기를 분리하라
초보일수록 첫 문장을 완벽하게 쓰려다 한 줄도 못 나아갑니다. 쓰기와 고치기는 다른 작업입니다. 쓰기는 발산이고 고치기는 수렴입니다. 두 가지를 동시에 하면 둘 다 망칩니다.
권하는 순서는 이렇습니다. 먼저 판단을 끄고 머릿속을 쏟아냅니다(초고). 그다음에 비판자의 모자를 쓰고 자릅니다(편집). 헤밍웨이가 했다고 흔히 인용되는 말처럼, 모든 초고는 형편없어도 괜찮습니다. 초고의 임무는 좋은 글이 아니라, 고칠 재료를 만드는 것입니다.
편집은 두 번째 사고다
편집은 단순한 다듬기가 아닙니다. 문장을 자르고 순서를 바꾸는 동안, 생각의 구조가 다시 보입니다. "이 문단이 정말 필요한가?"라는 질문은 곧 "이 논점이 정말 필요한가?"라는 질문입니다. 좋은 편집은 글을 짧게 만들 뿐 아니라, 사고를 한 번 더 거릅니다.
편집 전후 예시
편집 전:
> 사실 이 부분에 대해서 여러 가지로 생각을 좀 해 봤는데, 기본적으로 우리가 지금 하고 있는 방식이 그렇게까지 나쁜 건 아니지만 그래도 약간의 개선의 여지는 분명히 있다고 생각이 들어서, 한번 정리를 해 보려고 합니다.
편집 후:
> 지금 방식도 나쁘지 않지만, 개선할 여지가 있어 정리해 봤습니다.
군더더기를 걷어내자 메시지가 또렷해졌습니다. "사실", "기본적으로", "약간의", "그렇게까지" 같은 표현은 대부분 자신 없음의 흔적입니다.
자가 편집 체크리스트
- [ ] 첫 문장이 핵심을 말하는가, 아니면 변명으로 시작하는가?
- [ ] 한 문단은 한 가지 생각만 담고 있는가?
- [ ] 지워도 뜻이 통하는 단어를 지웠는가? ("사실", "정말", "약간" 등)
- [ ] 수동태를 능동태로 바꿀 수 있는가?
- [ ] 한 문장이 두 줄을 넘으면 끊을 수 있는가?
- [ ] 마지막 문단을 첫 문단으로 옮기면 더 나은가? (결론이 묻혀 있지 않은가)
7. 구조화 — 생각에 뼈대를 세우기
먼저 뼈대, 그다음 살
긴 글일수록 처음부터 문장을 쓰면 길을 잃습니다. 먼저 항목만 나열해 뼈대를 세우고, 그 뼈대를 보며 순서를 바꾸고, 마지막에 살을 붙입니다. 글쓰기의 어려움 대부분은 사실 "무엇을 어떤 순서로 말할지"라는 구조의 문제입니다. 문장이 안 풀린다면, 십중팔구 아직 구조가 안 잡힌 것입니다.
글의 흐름을 다이어그램으로 보기
머릿속 생각 (흐릿, 비선형)
|
v
[쏟아내기] 초고 ── 판단 끄기, 발산
|
v
[구조화] 뼈대 잡기 ── 항목 나열 → 순서 정하기
|
v
[편집] 살 붙이고 깎기 ── 비판 켜기, 수렴
|
v
[공개/보관] 검증과 기록
|
v
더 명료해진 생각 (선명, 선형)
|
+────────────┐
| (다음 주제로 순환)
v
새로운 질문 발견
이 흐름의 핵심은 한 방향이 아니라 순환이라는 점입니다. 명료해진 생각은 거의 항상 새로운 질문을 낳고, 그 질문이 다음 글의 출발점이 됩니다.
한 문단의 구조
좋은 문단에는 보통 이런 뼈대가 있습니다. 주장 한 문장으로 시작하고, 근거나 예시로 받치고, 한 문장으로 정리합니다. 이 단순한 틀만 지켜도 글이 또렷해집니다. 모든 문단을 "그래서 이 문단의 한 줄 요약은?"이라고 자문하며 점검해 보세요.
8. AI 시대의 글쓰기 — 더 중요해진 능력
AI가 대신 써 주는데 왜 직접 쓰나
생성형 AI는 그럴듯한 문장을 순식간에 만들어 냅니다. 그렇다면 글쓰기 능력은 한물간 기술일까요? 저는 오히려 반대라고 봅니다. 이유는 이 글의 첫머리에 있습니다. 글쓰기의 진짜 가치는 결과물이 아니라 **쓰는 동안 일어나는 사고**에 있습니다. AI에게 글을 시키면 결과물은 얻지만, 그 사고 과정은 건너뛰게 됩니다.
비유하자면 계산기와 같습니다. 계산기가 있어도 수 감각은 여전히 중요합니다. 답이 터무니없을 때 알아채려면 직접 어림하는 능력이 필요하니까요. AI가 쓴 글이 그럴듯하지만 틀렸을 때 그것을 알아채는 힘은, 직접 써 본 사람에게서 나옵니다.
AI 시대에 더 중요해진 글쓰기 능력
| 능력 | 왜 더 중요해졌나 |
| --- | --- |
| 질문을 정확히 적기 | 흐릿한 요청은 흐릿한 결과를 부른다 |
| 결과를 비판적으로 읽기 | 그럴듯한 오류를 가려내야 한다 |
| 구조를 설계하기 | 큰 그림은 여전히 사람의 몫이다 |
| 자기 생각을 갖기 | AI는 평균을 말한다, 관점은 당신이 더한다 |
AI를 사고의 파트너로 쓰는 법
AI를 글쓰기에서 배제할 필요는 없습니다. 다만 순서가 중요합니다. 먼저 스스로 초안과 골격을 만든 뒤, AI를 편집자나 반론자로 씁니다. "이 주장의 약점은?", "내가 놓친 반례는?", "이 문단을 더 짧게 줄인다면?" 같은 질문은 AI가 잘 돕습니다. 반대로 빈 화면을 통째로 AI에게 맡기면, 결과물은 평균적이고 당신의 사고는 자라지 않습니다. AI는 생각을 대신하는 도구가 아니라, 생각을 비추는 거울로 쓸 때 가장 유용합니다.
9. 사례 — 글쓰기가 일을 바꾼 순간들
사례 1. 막힌 버그가 메모 한 장에 풀리다
원인을 못 찾아 반나절을 헤맨 버그가 있었습니다. 동료에게 도움을 청하려고 상황을 글로 정리하기 시작했습니다. "이 함수는 이런 입력을 받아서, 이렇게 처리하고, 그래서..." 그 "그래서"를 쓰는 순간, 처리 순서가 제 가정과 다르다는 걸 깨달았습니다. 동료에게 보내기도 전에 문제가 풀렸습니다. 이것이 흔히 말하는 "고무 오리 디버깅"입니다. 설명하려는 행위 자체가 답을 끌어냅니다.
사례 2. 회의 대신 문서
매번 같은 논쟁을 반복하던 팀이, 결정 전에 한 페이지짜리 제안서를 먼저 쓰기로 했습니다. 회의는 그 문서를 읽고 시작했습니다. 놀랍게도 회의 시간이 줄었습니다. 글로 적는 동안 논점이 정리되니, 말로 빙빙 도는 시간이 사라졌기 때문입니다. 글은 말보다 느리지만, 그 느림이 생각을 강제합니다.
사례 3. 공개 글이 불러온 교정
어떤 개념을 정리해 블로그에 올렸습니다. 며칠 뒤 한 독자가 댓글로 미묘하지만 중요한 오해를 짚어 주었습니다. 혼자 노트에만 적었다면 영영 틀린 채로 남았을 부분입니다. 공개의 가치는 박수가 아니라 이런 교정에 있습니다.
10. 오늘부터 시작하는 7일 루틴
거창한 계획은 대개 실패합니다. 그래서 작게 제안합니다.
- [ ] 1일차: 오늘 가장 오래 고민한 것을 세 문장으로 적는다.
- [ ] 2일차: 어제 글에서 가장 흐릿한 문장 하나를 골라 다시 쓴다.
- [ ] 3일차: 요즘 다루는 개념 하나를 페인만식으로, 용어 없이 설명한다.
- [ ] 4일차: 곧 할 작업의 디자인 문서 뼈대(문제/제안/대안)를 적는다.
- [ ] 5일차: 지난 글 하나를 편집한다. 군더더기 단어만 지운다.
- [ ] 6일차: 짧은 글 하나를 공개한다. "지금의 제 이해입니다"로 시작한다.
- [ ] 7일차: 일주일을 돌아보며, 무엇이 명료해졌는지 한 문단 쓴다.
7일 뒤에 인생이 바뀌지는 않습니다. 다만 한 가지는 분명해질 것입니다. 쓰기 전과 쓴 후의 생각이 다르다는 사실. 그 차이를 한 번 체감하면, 글쓰기를 그만두기가 오히려 어려워집니다.
11. 막힐 때 — 빈 화면을 이기는 법
막힘은 게으름이 아니다
글이 안 써질 때 우리는 흔히 자신을 의지박약이라 탓합니다. 그러나 대부분의 막힘은 의지의 문제가 아니라 정보나 구조의 문제입니다. 쓸 내용이 머릿속에 충분히 모이지 않았거나, 모였어도 순서가 잡히지 않은 상태입니다. 막힘을 신호로 읽으면, 자책 대신 다음 행동이 보입니다.
막힘의 종류와 처방
| 막힘의 신호 | 진짜 원인 | 처방 |
| --- | --- | --- |
| 첫 문장이 안 나온다 | 완벽하게 시작하려 함 | 아무 문장이나 적고 나중에 지운다 |
| 중간에서 길을 잃는다 | 구조가 없음 | 글쓰기를 멈추고 뼈대만 다시 짠다 |
| 쓸 내용이 없다 | 입력이 부족함 | 자료로 돌아가 다시 읽고 메모한다 |
| 다 별로로 느껴진다 | 쓰기와 고치기를 동시에 함 | 판단을 끄고 끝까지 쏟아낸다 |
| 시작 자체가 두렵다 | 분량 부담 | 타이머 10분만 쓰기로 약속한다 |
막힘을 푸는 구체적 동작
- 가장 쉬운 부분부터 쓴다. 글은 순서대로 쓸 필요가 없습니다. 결론이 명확하면 결론부터, 예시가 또렷하면 예시부터 적습니다.
- 자신에게 말하듯 음성으로 먼저 설명한 뒤, 그 말을 받아 적습니다. 입으로는 술술 나오는 설명이 손으로는 막히는 경우가 많습니다.
- "내가 지금 쓰려는 건 한마디로 ___다"라는 빈칸을 채웁니다. 이 한 줄이 안 채워지면, 아직 쓸 준비가 안 된 것입니다.
- 10분 타이머를 켜고, 그 시간만큼은 멈추지 않고 손을 움직입니다. 엉망이어도 괜찮습니다. 목표는 좋은 글이 아니라 관성을 만드는 것입니다.
> "글쓰기에 관한 가장 큰 거짓말은, 영감이 와야 쓸 수 있다는 것이다. 사실은 거꾸로다. 쓰기 시작해야 영감이 온다."
12. 협업과 글쓰기 — 함께 일하는 사람을 위한 사고
비동기 시대의 글쓰기
원격 근무와 분산된 팀이 늘면서, 말보다 글로 일하는 시간이 길어졌습니다. 이슈, 풀 리퀘스트 설명, 채팅, 문서. 이 글들은 단순한 보고가 아니라, 읽는 사람의 머릿속에 같은 그림을 그려 주는 일입니다. 잘 쓴 글 한 편은 회의 한 번을 없애고, 못 쓴 글 한 편은 회의 세 번을 부릅니다.
풀 리퀘스트 설명 — 무엇을 적을 것인가
코드 변경을 설명하는 글은 협업 글쓰기의 작은 본보기입니다. 좋은 설명은 "무엇을 바꿨다"가 아니라 "왜 바꿨고, 어떻게 검증했는가"를 담습니다.
[좋은 변경 설명의 뼈대]
배경: 어떤 문제 때문에 이 변경이 필요한가?
변경: 무엇을 어떻게 바꿨는가? (큰 그림 먼저)
검증: 어떻게 동작을 확인했는가?
영향: 무엇이 함께 바뀌는가? 주의할 점은?
대안: 다른 방법은 없었나? 왜 이걸 골랐나?
읽는 사람은 코드만 보고는 의도를 알기 어렵습니다. "왜"가 빠진 변경 설명은, 리뷰어에게 추리를 강요합니다. 한두 문단의 맥락이 리뷰 시간을 절반으로 줄입니다.
리뷰와 피드백도 글쓰기다
다른 사람의 글이나 코드에 남기는 피드백 역시 사고의 글쓰기입니다. "이거 이상한데요"는 감정이고, "이 경우에 입력이 비어 있으면 어떻게 되나요?"는 사고입니다. 좋은 피드백은 결론이 아니라 질문의 형태를 띨 때가 많습니다. 질문은 상대의 생각을 닫지 않고 여는 까닭입니다.
협업 글쓰기 체크리스트
- [ ] 읽는 사람이 누구인지 한 명 떠올리고 썼는가?
- [ ] 결론이나 핵심 요청을 맨 앞에 두었는가?
- [ ] 배경을 모르는 사람도 따라올 수 있는가?
- [ ] 상대가 무엇을 해 주길 바라는지 분명한가?
- [ ] 비난이 아니라 질문과 사실로 적었는가?
13. 흔한 오해 — 글쓰기에 관한 거짓말들
사고를 위한 글쓰기를 가로막는 것은 종종 잘못된 믿음입니다. 자주 듣는 오해를 짚어 둡니다.
| 흔한 오해 | 현실 |
| --- | --- |
| 타고난 사람만 잘 쓴다 | 잘 쓰는 사람은 대개 많이 고치는 사람이다 |
| 영감이 와야 쓸 수 있다 | 써야 영감이 온다, 순서가 거꾸로다 |
| 한 번에 잘 써야 한다 | 초고는 원래 엉성한 게 정상이다 |
| 길게 써야 잘 쓴 것이다 | 짧게 줄이는 데 더 큰 사고가 든다 |
| 공개하면 망신만 당한다 | 대개 무반응이고, 가끔 값진 교정이 온다 |
이 표가 말하려는 바는 하나입니다. 글쓰기의 어려움 대부분은 능력의 문제가 아니라, 글쓰기를 어떤 일로 여기느냐의 문제라는 것입니다. 결과가 아니라 과정으로, 재능이 아니라 반복으로 보는 순간, 시작의 문턱은 크게 낮아집니다.
도구는 거들 뿐
마지막으로 도구 이야기를 짧게 덧붙입니다. 어떤 메모 앱, 어떤 에디터를 쓰느냐는 생각보다 덜 중요합니다. 화려한 도구를 고르느라 정작 쓰기를 미루는 일이 더 흔합니다. 텍스트 파일 하나, 종이 한 장이면 충분합니다. 중요한 것은 손에 익은 도구를 하나 정해 두고, 마찰 없이 곧바로 쓰기 시작할 수 있게 만드는 것입니다. 도구를 바꾸는 데 쓰는 에너지를, 한 문장이라도 더 쓰는 데 쓰는 편이 거의 항상 낫습니다.
마치며 — 명료함은 재능이 아니라 습관이다
명료하게 생각하는 사람은 타고난 것이 아닙니다. 대개 그들은 명료해질 때까지 쓰고 고치는 사람입니다. 머릿속의 흐릿함을 부끄러워할 필요는 없습니다. 누구의 머릿속이든 처음에는 흐릿합니다. 차이는 그것을 글로 끌어내 다듬느냐에 있습니다.
오늘 세 문장을 써 보세요. 잘 쓰려 하지 말고, 그저 머릿속에 있던 것을 밖으로 꺼내 보세요. 거기서부터 생각은 비로소 만져지는 것이 됩니다.
참고 자료
- 폴 그레이엄, "Putting Ideas into Words" — [https://www.paulgraham.com/words.html](https://www.paulgraham.com/words.html)
- 폴 그레이엄, "Writing, Briefly" — [https://www.paulgraham.com/writing44.html](https://www.paulgraham.com/writing44.html)
- 페인만 기법 (위키백과) — [https://en.wikipedia.org/wiki/Richard_Feynman](https://en.wikipedia.org/wiki/Richard_Feynman)
- 고무 오리 디버깅 (위키백과) — [https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)
- 설명 깊이의 착각 (위키백과) — [https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth](https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth)
- Will Larson, "Writing engineering strategy" — [https://lethain.com/](https://lethain.com/)
- 의사결정 기록(ADR) 소개 — [https://adr.github.io/](https://adr.github.io/)
- HBR, "The Writing Skills You Need" — [https://hbr.org/](https://hbr.org/)
- 윌리엄 진서, "On Writing Well" (위키백과) — [https://en.wikipedia.org/wiki/On_Writing_Well](https://en.wikipedia.org/wiki/On_Writing_Well)
- 작업 기억 (위키백과) — [https://en.wikipedia.org/wiki/Working_memory](https://en.wikipedia.org/wiki/Working_memory)
- 아마존의 6페이지 내러티브 문화 — [https://www.amazon.jobs/en/landing_pages/about-amazon](https://www.amazon.jobs/en/landing_pages/about-amazon)
- 폴 그레이엄, "The Age of the Essay" — [https://www.paulgraham.com/essay.html](https://www.paulgraham.com/essay.html)
- 학습을 공개적으로 하기 (learning in public) — [https://www.swyx.io/learn-in-public/](https://www.swyx.io/learn-in-public/)
현재 단락 (1/191)
많은 사람이 글쓰기를 이렇게 이해합니다. 머릿속에서 생각이 다 정리된 뒤, 그 완성된 생각을 종이에 옮겨 적는 일. 이 순서대로라면 글쓰기는 단순한 받아쓰기에 가깝습니다. 생각이 ...