글 쓰는 개발자의 갈피, 글쓰기 파이프라인
아이디어만 준비해서, 그대로 따라하면 글 한 편이 나옵니다
여는 말: 쉽게쉽게 갑시다
개인차가 있겠지만, 필자는 글쓰기가 고된 일이라고 생각한다. 무엇에 관해서 쓸지, 제목은 어떻게 정할지, 분량은 얼마나 쓸지, 어디까지 설명해야 할지, 어떤 뉘앙스로 써야 할지… 고민할 거리가 너무나도 많다 보니, 창작의 고통이란 이런 데에서 오는 것인가, 하는 생각을 한다.
필자가 느끼기에 글쓰기를 잘 하게 되는 가장 쉽고 빠른 방법은 글쓰기를 많이 하는 것이다(…). 이 무슨 등산장비가 산꼭대기에 있는 소리인가 싶지만, 반복 숙달의 힘은 어디에서나 통한다고 느낀다. 결코 많은 글을 썼다고 할 수 없는 필자조차도 처음 글을 쓰기 시작할 때보다 한결 쉽게 글을 쓸 수 있다고 느낄 정도면 의외로 그 효과는 빨리 나타난다고 할 수 있겠다. 처음 몇 번 글을 쓰다 보면 어떻게 써야 할지 요령도 조금씩 생기고, 무엇보다 글쓰기에 관한 심리적 장벽이 많이 사라진다.
그렇다면 관건은 “처음 몇 번 글을 쓸 때” 를 어떻게 무난히 넘기느냐일 것이다. 이번 글에서는 필자가 가지고 있는 나름의 글쓰기 파이프라인을 소개하고자 한다. 미리 정해진 파이프라인이 있다면, 글을 쓰는 것 자체가 좀 더 쉬워진다. 근데 이제 뭐함? 하고 망설일 시간에 미리 정해진 매뉴얼을 따를 수 있기 때문이다. 아무리 숙련된 작가라도 방황하는 순간이 있다고 생각한다. 하물며 필자와 같은 비숙련 라이터는 방황의 가능성이 더 높다. 글쓰기 파이프라인은 이러한 방황의 시간을 줄이고, 이로 인해 글쓰기에 걸리는 시간을 한층 절약해 주며, 궁극적으로 글쓰기에 소모하는 자원을 줄여 심리적 진입 장벽을 낮추고 더 쉽게 글을 쓸 수 있다. 일종의 이정표, “갈피”를 잡을 수 있게 해 준다.
In a nutshell
글쓰기 파이프라인 뜯어보기
도식화한 필자의 글쓰기 파이프라인은 다음과 같다.
소재 탐색 및 아이디어 산출 — 목차 작성 — 디깅 및 자료조사 — 실험 프로젝트 작성 — 글 작성 — 퇴고 및 배포의 순서로 이루어져 있다. 디깅 및 자료 조사 과정에서 목차 세부 조정을 할 수 있고, 실험 프로젝트 과정에서 목차를 세부 조정하며 실전적인 팁을 추가할 수 있다. 또한 퇴고 및 배포 후에도 오탈자 교정과 업데이트를 지속적으로 진행한다.
소재 탐색 및 아이디어 산출
필자는 주로 오래 남겨두면서 생각하고 알아가고자 하는 것에 대해 글을 쓴다. 또한 이 과정에서 다른 사람도 필자가 쓴 글의 덕을 보기를 원한다. 이러한 생각은 소재를 탐색할 때 대전제가 된다. 한편 예상 독자 설정도 이 과정에서 큰 영향을 끼친다. 필자가 보통의 경우 생각하는 독자층은 다음과 같다.
- 이 주제에 대해 관심이 있고 적극적으로 도입해보고자 하는 의지가 있지만 막상 아직 써 보지는 않은 사람
- “미래의 나”
그래서 필자의 글은, 누구나 쉽게 따라할 수 있고 생각해볼 수 있는 기술적 주제에 대해 쓰는 경우가 많다. 하나하나의 스텝에 설명이 따라붙는 것은 이 때문. 한편 한 번 익힌 기술적 주제도 계속 연마하지 않으면 잊기 마련이다. 잊어버린 미래의 자신을 위해, 배운 것이 가장 따끈따끈할 때 기록하는 것이다. 필자와 같은 관심사를 가진 독자분이시라면 그래서 좀 더 편하게 읽을 수 있을지도.
목차 작성
아이디어는 갖추었다. 그럼 어떻게 써야 할까? 상술한 창작의 고통이 엄습한다.
예를 들어 얼마 전 필자가 작성했던 Tuist에 관해 쓴다고 가정해 보자. Tuist에 대해 필자가 모든 것을 망라하는 것은 불가능하다. 하지만 일정한 방식의 모듈화 방법론, 그리고 그 실제 적용에 관해서는 적어볼 수 있다. A to Z까지는 아니더라도, A to C 정도는 적어볼 수 있다. 이 때 선택한 바로 그 길을 따라가기 위해 목차를 먼저 작성한다! 그 결과 실제로 필자가 적은 Tuist 글에는 모듈화를 처음 시작했을 때 세팅 방법과 각각의 과정이 갖는 의미, 그리고 흔히 접할 수 있는 문제 상황에 대해 적혀 있다.
미리 목차를 작성해두는 것은 이렇게 집중하고자 하는 Use Case에 집중하고, 글이 다른 곳으로 새지 않게 도와준다. 쓰기도 더 쉬워지고, 결과물의 질도 높아진다. 이쯤 되면 목차를 왜 먼저 작성하지 않는가, 라고 물어봐야 할 정도.
글을 다 쓰고 나서도 목차는 쓸모가 있다. 글의 초반부에 삽입함으로써 독자분들로 하여금 글을 모두 읽지 않아도 대략의 내용을 파악할 수 있게 하는 것. 필자의 글이 생각한 내용과 영 다르다 싶은 분은 여기서 뒤로가기를 누르실 수 있게끔 설계한다 — 다음에 다시 찾아주세요 — . 또 계속 읽으시려는 분도 어디쯤 가면 원하는 내용이 나오겠구나, 알 수 있게끔 한다. 주로 필자가 Obsidian에 메모해 둔 목차를 그대로 스크린샷으로 따서 글에 붙인다. Raw한 느낌이 나서 개인적으로 좋아하는 방법. 다만 전통적으로 쓰이는 TL;DR이라는 표현은 쓰지 않는데, 큰 이유는 없고 어감이 부정적이어서 그렇다. 글을 요약해서 보여준다는 의미로 In a nutshell이라는 말을 대신 쓰고 있다.
사실 이러한 방법론을 사용하게 된 데에는 재그지그님의 “기술 글쓰기를 통해 개인 브랜딩을 구축하는 나만의 방법” 포스트의 영향이 컸다. 더 많은 사람이 더 편하게 작가의 글을 볼 수 있게 하는 방법이라고 생각했고 크게 공감했기 때문에, 글쓰기의 체계를 잡고자 할 때 많이 참고하고 영향을 받았다.
디깅 및 자료 조사
요즘은 디깅이라는 말이 제법 많이 쓰인다고 들었다. 원래 디깅이란 DJ들이 자신의 라이브러리를 채울 음악을 “발굴”하는 것을 말한다. 기술 포스트를 쓰고자 하는 사람 입장에서는 글 쓸 때 사용할 자료를 마찬가지로 발굴해 북마크에 추가하는 것을 말한다. 결국 자료 조사와 디깅이 같은 말인 셈.
쓰고자 하는 기술적 주제가 있고, 그것에 대한 필자의 생각이나 예상은 이미 준비되어 있다. 그렇다면 여러 자료를 통해 그것에 힘을 더해 주는 작업이 필요하다. 이를 자료 조사를 통해 수행한다. 주제에 대한 다양한 시선이 담긴 자료를 많이 참고하고자 한다.
하지만 인터넷에 있는 정보는 무조건 믿을 수 없는 법! 그래서 필자는 공신력 있는 레퍼런스를 통해 쓰고자 하는 내용을 검증한다. 대표적으로 공식 문서나 공식 사이트, Github Repository 등이 있다. 필자가 쓰는 글에 들어가 있는 필자의 생각은 둘째치더라도, 정보 전달에 있어 틀린 부분이 없어야 한다는 생각 때문에 이렇게 한다.
이러한 자료 조사 과정을 거쳐서, 쓰고자 해서 목차에 적어 두었던 방향성이 잘못되었거나 쓰기 곤란하다는 것을 탐지할 수도 있다. 이 경우는 목차를 조금씩 수정하며, 글의 뼈대를 유지한다.
실험 프로젝트 작성
상술했듯 필자가 상정하는 예상 독자 중에는 관심이 있지만 해 보지 않은 사람이 있다. 그리고 글을 쓰려는 시점에서, 그것은 필자 자신에게도 해당되는 말이다(…). 개발자이신 독자분이라면 백 번 자료를 보는 것보다 한 번 해 보는 것이 훨씬 효과적이라는 것을 아시리라 생각한다. 그래서 필자도 일단 그냥 한다. 자료 조사를 통해 파악한 방법을 토대로 먼저 따라해 본다. 실제로 따라하면서 작동시키다 보면 글로만 볼 때보다 훨씬 잘 이해된다.
단순히 따라 치는 것만 가지고는 그 기술을 사용할 줄 안다고 말할 수 없다. 그래서 필자는 따라해 보면서도, 각각의 과정이 가지는 의미에 대해 최대한 파악하고자 노력한다. 기존에 알고 있던 지식과 결부시켜 아 이게 이건가? 하는 의문을 끊임없이 갖고자 노력하며, 글의 흐름을 해치지 않는 선에서 이를 첨언하기도 한다. 한편 처음 사용자가 되어 봄으로써 처음 사용자가 겪을 수 있는 예기치 못한 문제 상황에 대해서도 진하게 겪어 본 다음 목차에 추가하기도 한다. 이것이 바로 야전의 팁이라고 할 수 있지 않을까?
필자의 글이 그저 공식 문서 및 여러 블로그 아티클의 요약본이 되기보다는 독자분에게 생각할 거리를 던져 주는 글이기를 원한다. 그래서 필자 역시도 “생각할 거리”를 알아채기 위해 계속 생각하는 것. 실험 프로젝트를 통해 실습함으로써 생각할 거리를 더 빨리 알아챌 수 있다.
글 작성
여러분이 보고 계시는 이 글!
디깅과 실습을 통해 얻은 인사이트를 바탕으로 목차에 살을 덧대어 글을 완성한다. 필자는 주로 생각이 났을 때 빠르게 글을 적는 편. 가장 글이 쓰고 싶을 때 글을 쓴다. 한편 글 쓰는 시간을 정하고 해당 시간을 루틴으로 지키는 분도 꽤 많다. 둘 다 좋은 방법이라고 생각한다.
배포 및 퇴고
필자는 지금 적는 글의 내용이 영원히 같은 가치를 가질 것이라고 생각하지 않는다. 그렇기 때문에 일단 공개한다(!!). 필자는 자신이 만든 것을 굉장히 좋아하는 편이라, 자기 글을 꽤 많이 다시 보곤 한다. 이 과정에서 발견한 오탈자나 부적절한 문장 호응 등에 대해 체크하고 자주 수정한다. 한편 글을 쓸 때는 잘 몰랐던 중요한 포인트나, 필자가 틀리게 설명한 부분, 이런 것들이 있을 수도 있다. 이런 부분들에 대해서는 인지하는 즉시 업데이트한다.
닫는 말: 저항에 저항하기 그리고 그냥 하기
저항에 저항하기
우리의 뇌는 의외로 본체에게 저항하곤 한다. 뇌는 편안한 것을 추구한다. 하지만 모두가 알듯 편안한 것이 항상 올바른 것은 아니다. 올바른 것을 수행하고자 할 때, 뇌는 한편으로 편안한 것을 추구하기 때문에 저항한다. 예를 들면 써야 하는 글이 있을 때, 퇴근 후밖에 시간이 없다면, 글쓰기고 나발이고 그냥 눕고 싶다는 충동이 강하게 들 것이다. 이것이 저항이다. 한편 글쓰기가 처음이라 글을 쓰는 손가락이 천근만근 무거울 수 있다. 또 공개하는 것이 두려울 수 있다. 이 경우 글을 쓰지 않으면 쓰느라 고생할 일도 없고, 공개할 일도 없으니까, 애시당초 글쓰기는 나한테 맞지 않는 방법이었어, 라고 생각하게 된다. 이 또한 저항이다.
필자가 몸담고 있는 글또의 대장님, 성윤님께서 “저항에 저항해야 한다”라고 말씀하신 것에서 큰 영감을 얻었다. 꾸준히 글쓰기라는 어려운 작업을 해 내려면, 어떤 식으로든 저항에 저항할 수 있어야 한다.
- 고정적으로 시간을 내는 것은 저항에 저항하는 데 도움이 된다. 시간이 없다는 핑계에 대한 정당성을 확보하는 데 실패하기 때문이다.
- 일단 글이 쓰고 싶을 때 빠르게 쓰는 것은 저항에 저항하는 데 도움이 된다. 쓰고 싶을 때 쓴다면, 글 쓰는 손이 무겁지 않을 것이다.
- 다 써 놓고 일단 배포하기로 정하는 것은 저항에 저항하는 데 도움이 된다. 공개하고 나면, 세상 사람들은 나에게 관심이 없구나 라는 점을 체감할 수 있다. 이는 미래에 글을 쓸 때 한층 두려움 없이 쓸 수 있는 계기가 된다.
필자가 생각하기에, 사실 이러한 충동을 “저항”이라고 이름붙이는 것 자체가 저항에 저항하는 데 도움이 된다. 실체가 없는 것에 대응하기보다는 이름붙여 인지하고 있는 것에 대응하는 것이 더 쉽다. 저항을 저항이라고 이름붙이는 순간 저항으로서의 힘을 일정 부분 상실하는 것이다. 노자의 “도가도 비상도” — 도를 도라고 이름붙이면 그것은 더이상 도가 아니다 — 라는 말이 언뜻 생각나는 대목.
그냥 하기
자신이 하는 행동에 의미를 부여하는 것은 행동하는 원동력이 되기도 하지만, 자신을 짓누르는 무게가 되기도 한다. 가령 지금까지 매주 한 편씩 글을 쓰는 사람이 있다고 하자. 그런데 이번 주에 불가피한 사정이 생겨서 글을 못 쓰게 됐다. 그렇다면 이 사람은 이제 “매주 글을 쓰는 사람”은 아니게 되지 않는가? 한편 취업을 준비하는 사람이 자신을 “블로그를 써야 하는 사람”으로 정의하고 산다면, 매일매일 글을 써내야 한다는 압박감에 시달리지 않을까?
매주 글을 쓰는 사람, 글을 써야 하는 사람, 이런 의미를 부여하지 않고 그냥 하는 것이 글을 쓰는 데 좀 더 편안해질 수 있다고 생각한다. 글을 쓰기 위해 기술적 주제에 대해 조사하고 생각해보는 것만으로도 이미 도움이 된다. 거창한 의미를 부여하는 것은, 이 글 내내 우리가 낮추고자 했던 글쓰기에 대한 심리적 진입장벽을 높이고, 저항이 발생할 가능성을 높인다.
그저 마음이 이끄는 대로 궁금했던 것에 대해 면밀히 알아보고 글을 써 보자. 중요한 것은 꺾이지 않는 마음… 도 맞지만! 아이디어에 대해 항상 열려 있는, 예민한 감각이 아닐까 싶다. 아이디어만 잘 모아 두고, 문득 글이 쓰고 싶어질 때 파이프라인을 통과시키면 글 한 편이 짜잔~ 나올 것이다. 글을 씀으로써 현재의 독자, 그리고 미래의 자신과 대화하고자 하는 모든 분을 응원한다.
