Skip to content

Instantly share code, notes, and snippets.

@ElonPark
Forked from longfin/writing.md
Created August 2, 2022 11:39
Show Gist options
  • Save ElonPark/fbddf078beb28170c38dafc60f11420c to your computer and use it in GitHub Desktop.
Save ElonPark/fbddf078beb28170c38dafc60f11420c to your computer and use it in GitHub Desktop.
엔지니어를 위한 글쓰기

이 글은 Heinrich Hartmann 님이 작성하신 글을 한국어로 번역한 것입니다. 원문은 https://www.heinrichhartmann.com/posts/writing/ 에서 확인하실 수 있습니다.


글쓰기는 큰 조직에서 영향력을 발휘하는 데 중요합니다. 경력 있는 소프트웨어 엔지니어로서의 글쓰기는 직무 범위를 확장하고 경력을 발전시키기 위해 획득해야 하는 가장 중요한 기술입니다.

글쓰기는 어렵습니다. 많은 소프트웨어 엔지니어들이 글쓰기와 씨름하죠. 저도 개인적으로 문학에 대한 관심이 없기 때문에 글쓰기가 자연스럽지 않았습니다. 저는 긴 글을 써야 할 때 고민하고 미루는데 며칠이나 몇 주씩 고민하고 미루기도 했습니다. 그리고 지금까지도 마감에 맞춰 수준 높은 글을 준비하는 압박감 때문에 악몽에 시달립니다.

이 글은 지난 15년에 걸쳐 제가 보다 생산적인 글을 쓸 수 있게 도와준 몇 가지 배운 점들을 담고 있습니다. 저는 여기서 여러분이 유용한 부분을 찾길 바라며 이를 공유합니다. 하지만 저조차도 이 조언을 항상 따를 수 없으니 이해해주세요😅. 저도 배워야 할 게 많답니다.

개요

시작하기 전에

글감을 정하세요

이 문장은 꽤 명백해 보이지만 의외로 자주 문제가 되곤 합니다. 글쓰기의 목표는 독자들에게 메시지를 효과적인 방법으로 전달하는 것입니다. 만약 당신이 좋은 메시지를 가지고 있지 않다면, 쓸모 있는 글을 적는 데 고생하게 될 것입니다.

대학에 다니는 동안, 저는 EU 프로젝트에 대한 긴 리포트를 적을 일이 몇 번 있었습니다. 주요 목표가 그저 멋지게 보이는 페이지를 채우는 것이었기에, 아주 끔찍한 경험이었습니다. 일반적으로 도메인에 대한 좋은 아이디어를 가지고 있었지만, 명확한 메시지나 충분한 깊이를 가지고 있지 않았기 때문이죠. 저에게는 이 사실이 뭔가 적는 걸 엄청나게 어렵게 만들었습니다. 지금 생각해보면, GPT-3가 EU 프로젝트 보고서 작성에는 굉장히 유용할 것 같습니다.

제 블로그 게시물 중 가장 성공적인 것 중 하나(뒤에 자세히 다루겠습니다)는, 호텔 방에서 3시간 동안 작성되었고 다음 날 게시되었습니다. 이건 같은 날, SRECon EMEA 2018에서 몇 명의 구글 SRE들과 나눈 토론의 후속 조치였죠. 저는 제가 무엇을 이야기하고 싶은지, 그리고 누구에게 전달하고 싶은지가 명확했습니다. 덕분에 글쓰기도 엄청나게 쉬웠죠.

머리에 명확한 메시지가 아직 없다면, 당신은 아직 글 쓸 준비가 되지 않은 것입니다. 먼저 해야 할 일은 주제를 조사해서 당신의 메시지를 찾는 것입니다. 그리고 이 작업이 각각 다른 작업이라는 것을 깨닫는 것이 중요합니다. 여기에는 각종 메모나 일지를 쓰는 것이 포함될 수는 있지만, 최종 문서에 직접 사용할 자료는 아닙니다.

글쓰기와 배우는 것을 혼동하지 마세요

때로는 한참 글을 쓰는 중에서야 메시지를 가지고 있지 않다는 사실을 깨달을 수 있습니다. 좋은 펀치 라인(punch-line)을 찾는 것이나, 명확한 표현을 하는 것이 어려워 질때 우리는 이걸 알 수 있죠. 사실 글쓰기는 주제에 대해서 잘 알고 있는지, 해당 주제의 어휘를 확실하게 이해하고 있는지에 대한 훌륭한 테스트이기도 합니다. 다음과 같은 말도 있죠.

글쓰기는 당신의 생각이 얼마나 불완전한지를 보여주는 최선의 방법이다.

또한 비슷하게는 이런 말도 있습니다.

논쟁에서, 말을 하는 것은 잘해야 절반 정도의 가치가 있다.

당신이 이 문제에 부딪친다면, 무언가를 배우고 있다는 의미이기도 합니다. 일반적으로 글쓰기는 좋은 학습 방법이지만, 당신이 깨달아야 하죠. 학습은 느리고 인내가 필요합니다. 그저 화면 앞에서 괴로워하며 다른 문장을 짜내려고 하는 것은 도움이 되지 않습니다. 책이나 블로그, 논문 등을 읽고 메모해가며 해당 주제에 대해 더 많은 조사를 하는 것이 더 나은 시간 투자일 수 있습니다.

독자에 대해서 파악하세요

독자를 더 잘 알고 이해할수록, 그들에게 메시지를 전달하는 것이 더 쉬워집니다. 의도된 독자들은 당신이 쓸 수 있는 용어나 가정할 수 있는 문맥(Context), 그리고 문체에 영향을 줍니다.

일반적으로, 저는 글을 작성할 때 글이 목표로 하는 구체적인 사람을 시각화합니다. 이것은 주로 초안을 읽을 첫 번째 사람이기도 합니다. 일반적으로 허공에 대고 이야기하는 것보다는 “누군가에게” 이야기하는 것이 훨씬 쉽죠.

제 블로그의 수학(#math) 게시물들은 좋은 독자들이 실제로는 부족합니다. 그 글들은 추상 수학(Abstract Mathematics)에 능숙한 사람들이나 읽을 수 있는데, 소프트웨어에서 일하는 사람들에게만 흥미가 있고, 이 두 그룹의 교집합은 작기 때문이죠. 그렇기에 저는 그들에게 많은 반향(resonance)이나 영향을 기대하진 않습니다. 그 글들은 내가 스스로 배우고 싶은 것들에 대한 기록이죠.

분위기를 존중하세요

글쓰기는 오랜 시간 동안 집중이 필요합니다. 이상적으로는, 몇 시간 동안 계속해서 작업에 몰두하고 있는 몰입 상태(Flow state)에 들어가고 싶을 것입니다. 적어도 저에게는, 이건 내러티브나 블로그 게시물을 작성하는 데 있어 가장 효율적인 방법입니다.

글쓰기는 이미 고된 일입니다. 하이킹하듯이 쓰기 작업을 준비하세요. 앉을 수 있는 편안한 공간을 찾고, 마음에 드는 음료와 간식을 곁에 두세요. 가장 중요한 건, 휴식을 취하고 집중할 수 있는지 확인하는 것입니다. 유용한 글이 나올 리 없으니 피곤할 때 쓰기 작업을 시작하지 마세요.

또한, 가능한 한 주의를 산만하게 하는 것을 피하세요. 가장 중요한 건 채팅 음소거(Mute)입니다. 글쓰기를 위해 당신의 일정에서 최소 3시간은 차단 해 두세요. 만약에 제가 업무를 위해 더 긴 글을 써야 한다면 오후 전체를 차단할 것입니다. 제 경험으론, 가장 효과적인 글쓰기는 회의가 전혀 없는 주말이나 방학에 가능했습니다.

뜨거울 때 다리미질하세요

프로그래밍처럼, 글쓰기는 당신의 단기 기억(short term memory)에 많은 맥락(Context)를 저장해야 하는 작업입니다. 당신은 당신이 쓰고 있는 주제에 대한 많은 세부 사항, 핵심 내용 그리고 현재 상태를 기억해야만 하죠. 이 모든 상태는 메모리에 로드하는 데 시간이 걸리며, 집중을 놓치거나 문맥 전환(Context switching)등으로 쉽게 사라지기도 합니다.

유용한 문맥 정보를 많이 떠올렸다면, 그 시점에 그들을 잘 활용할 수 있는 일들을 하세요. 지금 당신의 주제에 대해 쓰기 효과적인 때라는 걸 깨닫는 즉시 그 타이밍을 놓치지 말고 글 쓸 준비를 하세요.

다리미를 미리 데워두세요

반대로 지금 당장 당신이 필요한 맥락을 가지고 있지 않다면, 2가지 선택지가 있습니다. (1) 쓰지 않거나, (2) 맥락을 떠올리거나

맥락을 놓치는 건 많은 괴로움과 미루기로 이어집니다. 당신의 할 일 목록에서 “회의 이야기 작성”과 같은 일감을 선택하는 것만으론 올바르게 작업이 되기를 기대하긴 어렵죠. 그 어떤 문장을 쓰기에 앞서, 맥락을 당신의 머리속에 불러오는데 시간을 투자해야 합니다.

맥락을 떠올리는 데 좋은 방법으로는 아래와 같은 것들이 있습니다.

  • 주제에 대해 작성한 메모를 살펴보세요.
  • 동료/가족/낯선 사람들과 주제에 관해 토론하세요.
  • 주제에 관한 책/블로그/논문을 읽으세요.

HackerNews나 유튜브는 맥락을 되살리는데 좋은 방법이 아닙니다.

글을 쓰기 전에

시작이 아닌 정상에서 시작하세요

이것은 사람들이 범하는 가장 일반적이고 해로운 실수입니다. 많은 사람은 글의 시작 부분을 다음과 같이 시작합니다.

옛날 옛적, 아주 먼 은하계에서...

여러분은 이게 조지 루커스가 스타워즈 3부작을 집필할 때 처음 가져온 단어라고 생각하시나요?

한 페이지가 넘어가는 글은 하향식(Top-Down) 접근으로 개요부터 시작해야 합니다. 개요는 종종 글머리 기호와 함께 영역의 핵심 내용을 메모처럼 작성한 목록입니다. 예를 들어, 이 글의 첫 번째 개요는 다음과 같았습니다.

# 어떻게 쓸 것인가?

- 독자: 경력 있는 소프트웨어 엔지니어
- 목표: 글쓰기 실력의 향상 및 막히는 문제 없애기

## 하고 싶은 이야기

- 목표: 독자에게 메시지를 전달
- 메시지 없는 글쓰기는 괴롭습니다: 돌에서 물을 짜내는 것과 같음

## 독자에 대해서 파악하세요

## 뜨거울 때 다리미질하세요

- 두뇌 상황을 인식하세요.
- 적절한 맥락을 갖추고 있을 때 작업을 시작/유지
- 시작하기 전에 맥락을 떠올릴 것

## 편집, 출판, 쓰기의 분리

- 작성 전에 git/emacs를 만지작거리고 있다면, 당신은 뭔가 잘못하고 있는 것입니다.
...

참고로, 영역 제목은 서론/본론/결론과 같은 일반적인 순서 대신, 글의 의미와 내용을 포함해야 함을 유의하세요.

내용을 적기 전에 줄거리를 정하세요

집을 지을 때 여러분은 페인트를 칠하기 전에 벽돌 작업을 끝냅니다. 글을 쓸 때도 글을 다듬기 시작하기 전에 전체 글에 적합한 줄거리를 찾아내길 바라죠. 개요는 작성 중인 글의 첫번째 이정표가 되어야 합니다. 이 개요는 주요 메시지를 전달하고, 독자들이 당신의 주장을 따라올 수 있도록 안내하는 “빨간 실”을 제공하는 것이죠.

컨설팅 회사에서 일하던 시절, 선배들이 세부 사항을 작업하기에 앞서 발표 자료의 구조를 다듬고 반복하는 데 많은 시간을 보내는 것을 보았습니다. 그들은 발표 자료의 슬라이드들을 종이에 인쇄하여 벽에 고정한 다음, 줄거리에 만족할 때까지 계속 재배열했습니다. 이 슬라이드들은 벽에 남은 채로 자료가 완성될 때까지 다시 배치되었습니다.

글의 줄거리를 고치는 것은, 이미 단락에 살이 붙인 다음에는 훨씬 어려워집니다. 어떤 경우엔, 글을 작성하기 전에 전체 내용을 내려두고 개요로 돌아가는 것이 가장 좋은 방법일 때도 있습니다.

다듬기 전에 내용을 완성하세요

제가 흔히 발견한 함정은, 내러티브를 만들기 전에 꼭 필요하진 않은 다른 작업에 주의가 산만해지는 것입니다. 다음은 이런 다른 작업의 예입니다.

  1. 편집: 철자를 고치고, 문구나 단락을 수정하거나 재구성
  2. 출판: 서식을 지정하고 WordPress를 튜닝하고 git / hugo /heroku 등으로 배포를 자동화
  3. 그림 만들기: 시각 표현을 위한 이미지를 만들기 위해 종이에 스케치하고 웹을 검색

기억하세요 - 글의 첫 번째 이정표는 개요입니다. 이 목표에 직접 관련 없는 모든 것은 그저 주의를 산만하게 만들 뿐입니다.

개요가 만족스럽다면, 두 번째 이정표는 모든 메모를 단락으로 바꾼 구체적인 줄글입니다. 줄글들은 의도한 내용을 포함해야 하지만, 세련되거나 잘 쓰일 필요는 없습니다.

이 시점에 다다르면, 세련미에 대한 걱정이 시작됩니다. 오타를 제거하고, 단어를 개선하며, 문단을 재배치하세요. 또한 표현을 도울 시각적 이미지나 배포에 관련된 작업은 이 이정표 이후로 미룰 수 있습니다.

문장을 훑어볼 수 있게 만드세요

인터넷의 누군가에 따르면,

8초, 웹사이트 사용자가 주의를 집중할 수 있는 시간은 단 8초뿐입니다.

이 8초 안에, 당신의 글은 독자에게 앞으로 실제로 글을 다 읽는 데 필요한 시간을 투자하고 싶게끔, 충분한 가치를 제공해야 합니다.

당신의 목소리가 들리게끔 그리고 글이 더 쓸모 있게 하려면, 글 전체를 “훑어볼 수 있게” 만들어야 합니다. 독자가 실제로 글을 다 읽지 않더라도, 전체 분량을 가늠할 수 있게끔 기준점을 제공하는 것으로 이를 달성할 수 있습니다. 당신은 개요와 핵심 주장이 글의 가장 마지막 버전까지 눈에 띄게끔 띄길 원합니다.

구역 제목과 목록은 이 목표를 달성하기 위해 사용할 주요 기준입니다. 또한 도표, 인용문 그리고 강조 역시 이런 훑어보기 중 주의를 집중시킬 수 있는 요소들입니다.

당신이 발표 자료를 만드는 동안, 훑어보기 기능을 보장하는 좋은 방법은 작업 제목(Action Title)을 사용하는 겁니다. 작업 제목은 슬라이드의 내용을 완전한 문장으로 요약한 슬라이드의 제목입니다. 이를 통해, 독자는 제목만 읽어도 글의 요지를 바로 파악할 수 있습니다. 인터넷에서 매우 시끄러운 이 사람은, 여기에서 그에 대한 개념과 아이디어를 잘 설명하고 있습니다.

요약 영역을 제공하세요

요약 영역은 문서 서식이나 학술 문서 등에서 흔히 찾을 수 있습니다. 그들은 급한 독자를 위해 내용에 대한 높은 수준의 개요를 제공하는 편의 기능입니다. 많은 독자가 오로지 이 요약만을 읽을 것이라고 예상하세요.

초록(Abstract) / 요약 / TL;DR. 이 영역은 의도적으로 정보를 중복해서 글의 내용을 간추립니다. 일반적으로 이는 글의 가장 처음 영역이며, 아직 글을 다 읽지 않은 독자들을 위한 것입니다. 좋은 초록은 맥락을 잘 설명하고 글에 동기를 부여하여 결과를 요약하지만, 계속 읽기 위한 동기를 부여하기 위해서 약간의 중단점을 남겨둡니다.

결론. 이 영역은 내용을 간추리고 정리한다는 점에서 초록과 비슷합니다. 차이점은, 결론은 글의 마지막 영역으로 결과에 초점을 맞추고 의도적으로 내용을 다시 언급한다는 것입니다. 이 기본 아이디어는, 독자가 여기 도착하기 전에 글을 다 읽었을 위치지만, 실제로는 거의 그렇지 않다는 것이죠.

이러한 요약 영역은 주요 줄거리와 독립적이므로, 따로 준비할 수 있는 작업물이라는 걸 유의하는 것이 중요합니다. 일반적으로 초록/결론과 같은 요약 영역들은 글쓰기 작업의 마지막에 시작하는 것이 좋습니다. 그 때 가서야 글이 실제로 다루는 내용을 확신할 수 있기 때문이죠.

글쓰기의 요령

계속 쓰세요

글쓰기 기술을 향상하는 유일한 방법은, 바로 글을 써보는 것입니다. 대부분의 많은 연습이 그렇듯이, 질보다 양을 중시하는 건 보통 좋은 생각입니다. 비교적 짧은 수준의 글을 매주 꾸준히 작성하는 것으로 쓰기 근육을 단련하면, 고도로 세련된 글을 1년에 한 번 쓰는 것보다는 훨씬 나은 작가가 될 수 있습니다.

학교에서 저의 영어 선생님은 이렇게 말씀하셨습니다. “글쓰기. 오로지 글쓰기만이 축복을 가져온다.” 저는 이 슬로건 자체에 대해선 별생각이 없었지만, 한편으론 제 마음에 꽂힐 만큼 매력적이었습니다. 그리고 지금 저는 그것에 깊게 동의하며 상기하기 위해 제 블로그 맨 위에 남겨두었습니다.

짧은 글들을 활용하세요

기술 문서나 블로그 글, 논문과 같이 긴 글을 쓰기 위해 필요한 대부분의 규칙은, 대부분 이메일이나 이슈 티켓 같이 짧은 글을 쓸 때도 똑같이 적용됩니다. 이러한 짧은 글들을 구조화하고 다듬어서 쓸모 있게 만들어 보는 것으로, 당신의 글쓰기 기술을 연습해볼 수 있습니다.

개요에 대한 피드백을 빨리 받으세요

당신이 글의 개요를 정하고 줄거리를 다듬고 나면, 이는 당신의 글에 대해 초기 피드백을 받기 아주 좋은 시점입니다. 이를 통해 줄거리의 결함을 조기에 발견하고 글의 목표에 부합하는지도 확인할 수 있죠. 또한 개요를 읽는 건 매우 빠르게 할 수 있는 일이라, 다른 사람이 이를 검토하는 데 그리 많은 수고가 들지 않습니다.

이는 이해 관계자(관리자)의 요청에 따라 작성하는 긴 문서들에선 가장 중요합니다.

검토자들에게 글의 초안을 돌리세요

내용을 구체화하고 눈에 띄는 문법 오류 및 오탈자를 고치고 나면, 이제 대상 독자로 생각되는 소수의 독자에게 이를 먼저 보여줄 수 있습니다.

이 방법에는 세 가지 이점이 있습니다.

  1. 글에 남아 있는 몇 가지 문법 오류나 오탈자를 잡아줄, 신선한 시각을 얻게 됩니다.
  2. 피드백을 받을 때까지 글쓰기를 잠시 멈추고 자신의 글을 새롭게 살펴볼 수 있습니다.
  3. 너무 오랫동안 소홀했던 오랜 친구에게 연락할 좋은 구실입니다.

힌트: “감사의 말”에서 검토자들에게 감사를 표하는 걸 잊지 마세요.

감사의 말

이 글의 이전 버전에 대한 피드백을 제공한 제 여동생 Johanna Hartmann과 Andrew Howden에게 감사드립니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment