기술 글쓰기를 통해 개인 브랜딩을 구축하는 나만의 방법

약 2주 전에 글쓰기 매니페스토 라는 이름의 문서를 만들었습니다. 2018년부터 지금까지 기술 블로그를 운영하면서 추구해온 가치들을 별도의 매니페스토 형태로 제작한 것이죠. 약간 오글거릴 수 있긴 한데(?), 뭐 목표 좀 웅장하게 쓸 수도 있고 그런 거 아니겠습니까.

아무튼 매니페스토 페이지를 통해 저의 글쓰기 원칙들을 언급했는데, 이것이 가치 에 포커스를 맞추다 보니 구체적인 실천 방법 에 대한 내용을 언급하지는 않았습니다. 사실 이것은 의도적인 것인데, 가치를 실현하기 위한 행동은 사람마다 달라질 수 있다고 생각했기 때문이거든요. 하지만 제가 저렇게 원칙만 선언해놓고 정작 어떤 방법으로 실천하고 있는지를 설명하지 않는다면 매니페스토는 그냥 빛 좋은 개살구일 뿐이겠죠.

그래서 오늘은 매니페스토에 언급된 원칙을 실천하고 이것을 개인 브랜딩으로 연결시키기 위한 방법을 소개해드리려 합니다. 이번에는 실천 방법에 초점을 맞춰서 보다 실용적인 내용을 위주로 다뤄봅니다. 아이디어를 떠올리는 것에서부터 하나의 포스트가 발행되기까지, 저의 전반적인 글쓰기 루틴을 한 번 훑어보는 방식으로 말이죠.

이번 글을 통해 기술 글쓰기를 처음 시도하시는 분, 또는 기술 글쓰기가 익숙하지 않거나 어렵게 느껴지는 분들께 도움이 되기를 바랍니다.

TL;DR

글 쓰기 전

글을 쓰기 전에도 계획과 설계가 필요합니다. 마치 인테리어를 하기 전 설계도를 미리 그리는 것처럼요. 그래야 헤메는 시간 없이 계획대로 글을 쓸 수 있겠죠?

글 쓸 시간을 따로 마련하기

글은 시간이 날 때 쓰는 것이 아닙니다. 글을 쓰기 위해 시간을 내야 합니다.

첫 번째로 해야 할 일은 글을 쓸 시간을 먼저 마련하는 것 입니다. 제가 지난 3년 동안 약 80여 개의 포스트를 작성하면서 체득한 나름의 빅데이터(?)가 있는데요, 그것은 바로 하나의 글을 발행하기까지 최소 이틀의 시간이 필요하다는 것 입니다. 이것도 10분 미만의 분량일 때 얘기고, 글이 길어지거나 주제가 어려울수록 걸리는 시간은 더 늘어나는 편입니다. 그래서 저는 글을 써야겠다고 마음먹으면 주말 일정을 통째로 비워두곤 합니다.

사실 회사를 다닐 때에는 평일에 업무가 끝나고 나서 글을 써보려고도 해봤는데… 저에게는 잘 안 맞는 방법이었습니다. 아무래도 방전된 상태에서 글을 쓰려니 체력적으로 힘이 들고 집중도 잘 안 되더라구요. 그래서 차라리 주말에 좋은 컨디션으로 글을 쓰는 게 좋을 것 같다고 생각했고, 이게 제게는 잘 맞아서 지금까지도 이 루틴을 유지하는 중입니다.

이처럼 글을 쓰기 위한 시간을 따로 내다보니, 한 번 글을 쓸 때 최대한 집중해서 효율을 뽑아내려고 합니다. 일반적으로 점심 먹고 카페에 가서 저녁 시간이 될 때까지 있는데, 앉은자리에서 4~5시간 정도를 온전히 집중하여 글을 씁니다. 이렇게 해도 글 하나를 마무리 짓는 것이 쉽지 않기 때문에, 저녁 먹고 집에 돌아와 글을 조금 더 살펴보다가 하루를 마무리하곤 하죠. 그리고 이 패턴을 주말 동안 유지합니다.

사람마다 글을 쓰는 패턴이 다를 수 있기에 이 부분은 직접 경험해가며 본인에게 최적화된 방법을 찾는 것이 필요합니다. 조금씩 꾸준히 쓰는 방식이 맞을 수도 있고, 한 번에 휘몰아치는 방식이 맞을 수도 있습니다. 중요한 것은 남는 시간에 글을 쓰는 것이 아니라, 글을 쓰기 위한 시간을 따로 마련해야 한다는 것입니다. 인간은 게으른 동물이기 때문에 남는 시간에 글을 쓰겠다는 생각으로는 절대 꾸준히 글을 쓸 수 없습니다.

쓸만한 글감은 미리 메모해두기

글감들을 노션에 보드 형태로 정리해두는 편이다

글쓰기를 위한 시간을 마련했다 하더라도 주제를 미리 생각해두지 않았다면 무엇부터 적어야 할지 선뜻 감이 오지 않을 수도 있습니다. 글감을 고민하는 과정이 생각보다 시간을 많이 잡아먹기 때문이죠. 따라서 정해진 시간 동안 글쓰기에 최대한 집중하기 위해서는 어떤 주제로 글을 쓸 것인지를 미리 생각 해두어야 합니다.

저는 쓸만한 글감은 미리 메모해두는 편입니다. 평소에 브레인스토밍을 하듯 주제의 실용성은 따지지 않고 떠오르는 글감들을 일단 다 기록해둡니다. 괜찮은 글감이 바로 떠오를 때도 있지만, 기록한 글감들 속에서 새로운 아이디어가 떠오를 때도 있거든요.

메모 도구로는 주로 노션을 쓰고 있습니다. 웹, 앱이 모두 지원되어 접근성이 좋았을 뿐만 아니라 이들 간의 동기화도 잘 지원되기 때문입니다. 왠지 모르겠지만 저는 특히 대중교통을 타고 지나갈 때 멍 때리면서 이런 글감 생각들을 많이 하는데, 뭔가 생각이 날 때마다 노션 앱을 켜서 바로 기록해두는 편입니다. 글감들은 칸반 보드(kanban board) 형태로 관리하고 있어서 아이디어와 완성한 글감들은 따로 구별합니다.

글감을 최대한 많이 떠올리기 위해서는 정보를 얻을 수 있는 창구를 최대한 많이 알아두어야 합니다. 물론 공부나 업무 하면서 생긴 궁금증을 글감으로 쓸 수도 있겠지만, 반복되는 일상 속에서는 신선한 주제를 찾기가 쉽지 않거든요. 그래서 저는 각종 개발 관련 뉴스레터를 구독하고, 인플루언서 개발자들의 SNS 계정을 팔로우합니다. 개발 유튜브나 팟캐스트, IT 회사의 기술 블로그 같은 것도 종종 찾아보고 개발자 커뮤니티 활동도 하고 있네요.

즉, 자기 자신의 일상을 개발이라는 주제에 지속적으로 노출시킬 수 있는 환경을 구축하여야 합니다. 꾸준히 영감을 얻을 수 있는 상태를 유지해야 글감을 얻기가 쉽습니다.

한편으로는 글감을 찾으면서 다음과 같은 추가적인 고민을 해보는 것도 좋습니다.

• 어떤 메시지를 독자에게 던지고 싶은 것인지
• 주제를 어느 정도로 깊게 파고들 것인지
• 어쩌다가 이 주제를 글감으로 선택했는지
• 왜 이 주제를 깊게 파고 들어가려 하는지
• 어떤 부분에 나의 생각을 덧붙일 수 있을지
• 이미 이 주제로 다른 사람이 쓴 글이 있는지

글의 장르 별 템플릿을 떠올리기

대충 글의 머리, 가슴, 배를 나누는 느낌이랄까?

글감을 선택했다면 내가 쓰고자 하는 글의 템플릿을 떠올려봅니다. 템플릿이라는 게 사실 별 건 아니고 비슷한 장르의 글을 계속 쓰다 보면 내가 쓴 글의 형태에서도 규칙을 발견할 수 있는데, 이것을 머릿속에서 규격화시킨 것입니다.

이렇게 장르마다 템플릿을 생각해두면 내 글의 일관성을 유지하고, 초안을 작성할 때 걸리는 시간을 절약할 수 있다는 장점이 있습니다.

저 같은 경우, 큰 틀에서 글의 형태는 항상 서론 → 요약 → 본론 → 결론 → 참고자료 순을 유지합니다. 제가 작성한 다른 글들을 살펴보면 대부분 위 형태를 유지하고 있는 것을 확인하실 수 있을 거예요. (물론 장르에 따라 생략할 때도 있긴 합니다.)

본문의 경우, 장르에 따라 세부적인 접근 방법을 다르게 가져가는 편입니다. 대표적인 장르와 접근 방법을 아래에 리스트로 요약해두었습니다. 예외로 기술 포스트 같은 경우는 글의 콘셉트와 분위기에 따라 템플릿을 유동적으로 가져가는 편입니다.

• 회고: 지난 목표 달성 평가 → 회고 기간 동안 거둔 성과 되돌아보기 → 새로운 목표 세우기
• 서평: 책 소개 → 인상 깊었던 부분 인용 & 소감 → 반복
• 번역: 원문 번역 → 어색한 부분 의역 → 자료 부족하거나 추가할 수 있는 부분 보충
• 에세이: 내 생각에 달릴 수 있는 질문들을 미리 FAQ 형식으로 정리 → 답변 달기

이처럼 특정 장르의 글을 어떤 형태로 구성할지 미리 생각해두는 것, 이것이 템플릿을 떠올려 활용하는 이유입니다.

글의 초안을 작성하기

이렇게 주제와 템플릿을 떠올렸다면 이를 바탕으로 초안을 작성합니다. 저는 리스트 형식으로 작성하는데, 본 포스트의 초안을 소개드리자면 다음과 같습니다.

- 서론
  - 약 2주 전에 [글쓰기 매니페스토](/manifesto) 라는 이름으로 블로그에 별도의 페이지를 만듦
  - 지켜야 할 원칙에 대해 소개함
    - 그런데 이게 다소 추상적이죠?
  - 그래서 이번에는 이러한 원칙을 지키기 위한 나의 실제 노력들을 소개하고자 함
    - 하드 스킬 위주로 소개
  - 글 쓰는 방법과 루틴이 익숙하지 않은 분들 대상
- 본론
  - 글을 쓸 시간을 따로 마련하기
    - 나는 보통 2주에 하나씩 글 발행하고, 평균적으로 이틀 걸림
    - 주말에 시간 내고 몰아서 쓰는 편, 다른 방법도 해봤는데 나한텐 맞지 않음
    - 이건 사람마다 다를 수 있기 때문에 직접 경험해서 본인에게 맞는 방법 찾자
    - 중요한 것은 시간 날 때 글 쓰는 것이 아니라 시간 내서 글 쓰는 것
  - 글의 초안을 작성하기
    - ...
- 결론
  - ...

초안은 어차피 글의 큰 틀을 잡는 과정이고, 불필요한 문장이나 읽기 불편한 비문은 나중에 다 쳐낼 것이기 때문에 형식에 구애받지 않고 자유로이 작성합니다.

글 쓰는 중

초안이라는 큰 틀이 완성되었기 때문에 이제 앞부분부터 빼곡히 내용을 채워나가면 됩니다. 저는 마치 뜨개질을 하듯이 앞부분부터 차곡차곡 내용을 채워나가는 편입니다.

제목으로 독자의 호기심을 끌기

의문형, 숫자, 밈으로 제목을 지은 예시

우선 글의 제목과 부제목을 짓습니다. 담백하게 짓는 것도 좋지만, 독자의 눈길을 끌기 위해서는 어그로를 잘 끌어야 합니다. 사실 글의 제목을 잘 짓는 방법은 검색하면 많이 나옵니다만, 너무 과하면 오히려 눈살이 찌푸려질 수 있으니 조심하여 사용합니다.

저는 주로 의문형 제목을 쓰는 것을 선호합니다. 제일 무난하고 독자의 눈길도 잘 끌죠. 한편으로는 구체적인 숫자를 활용하기도 하고, 뭔가 적당한 밈을 갖다 붙여서 쓰기도 합니다.

근데 변수명 짓기도 마찬가지지만, 제목을 맛깔나게 짓는 것이 진짜 어렵습니다. 그냥 타고난 센스가 중요한 부분이라… 😇 저 역시 글감만 보고 번뜩이는 제목이 떠오를 때도 있지만, 어떨 때는 아무리 생각해도 제목이 안 떠오르는 경우도 있습니다. 이럴 때는 눈물을 머금고 노잼 제목(…)을 씁니다.

서론으로 독자를 공감시키기

글을 쓰게 된 동기가 잘 나온 예시

다음으로는 글의 서론을 작성합니다. 저는 주로 서론에서 글을 쓰게 된 동기 를 설명합니다. 기술 포스트라면 왜 해당 글감을 선택했는지, 서평이라면 왜 그 책을 읽었는지, 에세이라면 왜 그런 생각을 하게 됐는지를 적는 것이 적절합니다. 글을 쓰게 된 동기가 언급되어 있다면 독자의 공감을 얻기가 더 쉽기 때문입니다.

간단한 브리핑으로 동기를 대체한 예시

마땅한 동기가 떠오르지 않는다면 글감과 관련된 최근의 이슈 등을 간단하게 뉴스처럼 브리핑하는 것도 좋습니다.

대상 독자와 도움이 되는 점을 언급한 예시

또한 이 글이 어떤 독자에게 어떤 형태로 도움을 줄 수 있는지를 명시적으로 언급합니다. “그런 건 제목만으로도 알 수 있지 않나요?” 라고 생각할 수 있지만, 제목은 핵심만 짧고 간결하게 담고 있기 때문에 내가 쓴 글의 원래 목적을 온전히 표현하기에는 다소 부족할 수밖에 없습니다.

따라서 대상 독자를 명확히 하고 해당 독자에게 이 글이 어떤 점에서 도움이 될 수 있는지를 서론에서 언급해줍니다. 만약 독자가 기대했던 것과 글의 방향이 같은 목적이라면, 독자는 확신을 갖고 글을 계속해서 읽을 수 있습니다. 그렇지 않은 경우에는 독자가 헛걸음할 시간을 아낄 수 있어서 좋구요.

우리가 쓰는 글은 문학으로서의 글이 아니라 정보 전달 목적의 글이라는 걸 잊지 말아야 합니다. 다소 장황해 보이더라도 암묵적인 것보다는 명시적인 것이 훨씬 더 낫습니다.

글 초반부에 요약 써두기

본문 시작 전에 요약이 잘 제공된 예시

논문을 작성할 때 초록(Abstract)을 작성하는 것처럼, 기술 포스트에 있어서도 요약이 필수적이라고 생각합니다. 포스트에 요약이 있으면 독자가 글에서 전달하고자 하는 바를 빠르고 쉽게 파악할 수 있기 때문입니다.

저는 서론과 본론 사이에 요약을 배치합니다. 예전에는 글을 마무리한다는 느낌으로 결론 부분에 요약을 달았었는데, 글의 요약을 먼저 읽고 본문을 읽었더라면 이해하기가 더 좋았을 것 같다 는 피드백을 받은 적이 있기 때문입니다. 피드백을 반영하여 요약 위치를 본론 윗부분으로 옮겼더니, 다른 독자로부터 요약 덕분에 글의 내용을 더 쉽게 파악할 수 있었다는 긍정적인 피드백을 얻을 수 있었습니다.

독자는 앞으로 펼쳐질 글의 내용을 전혀 모르는 상태이기 때문에, 긴 글의 호흡을 따라가며 읽어야 하는 상황이 부담스럽게 느껴질 수도 있습니다. 독자는 되도록 짧은 시간 내에 원하는 정보가 있는 부분만 골라서 읽고 싶어 하거든요. 내용을 모르는 긴 글을 읽는 것은 마치 자욱한 안갯속을 헤쳐나가는 여정처럼 느껴질 것입니다.

따라서 독자에게 지도를 제공해줄 필요가 있는데 요약이 이러한 역할을 합니다. 이 글을 통해 내가 하고 싶은 말이 무엇이며, 어떤 근거로 그렇게 생각하는지를 먼저 언급해주는 것이죠. 이 덕분에 독자는 글의 구조를 미리 파악한 채 본문으로 진입할 수 있게 되고, 긴 글을 읽기 싫어하는 사람들의 거부감도 쉽게 허물 수 있습니다.

문단 수준에서 글 다듬기

초안에서 적은 틀을 바탕으로 본문 분량을 어느 정도 채웠다면 이제는 글을 다듬어야 할 차례입니다. 글을 바라보는 관점은 넓은 수준에서 좁은 수준으로 접근합니다. 따라서 문단 → 문장 → 단어 수준으로 다듬어봅시다.

문단 구분이 잘 적용된 예시

문단 수준에서 글을 다듬을 때, 저는 문단을 잘 나누는 것에 집중합니다. 문단을 분리하면 글의 호흡을 적절하게 끊고, 적당한 여백을 두어 가독성을 높일 수 있다는 장점이 있습니다. 즉, 문단만 잘 나누어도 여유있는 글을 작성할 수 있죠.

그렇다면 문단을 나누는 기준은 무엇일까요? 저는 크게 두 가지 관점에서 문단을 구분합니다.

첫 번째는 문단의 길이입니다. 저는 보통 한 문단을 2~4 문장 정도로 구성하려고 노력하고 있습니다. 이것보다 문장이 더 많으면 글이 빽빽하게 느껴지기 때문에, 여유가 없어 보이고 독자로 하여금 피로감을 불러일으키기 때문입니다.

두 번째는 문단의 분위기입니다. 글을 쓰다 보면 분위기의 흐름이 생기게 되는데, 이러한 분위기의 변화를 기준으로 문단을 나누는 것이죠. 제가 주로 문단을 나누는 포인트들은 아래와 같습니다.

• 분위기 반전: 앞 문단의 내용이 뒷 문단에서 반박될 때
• 병렬 구조: 앞 문단의 내용이 하위 항목으로 분리하여 설명할 때
• 요약 정리: 앞 문단의 내용을 다시 요약하고자 할 때
• 인과 관계: 앞/뒤 문단의 내용이 뒤/앞 문단의 근거가 될 때
• 예시 및 가정: 앞 문단의 내용을 바탕으로 예시를 들 때

문장 수준에서 글 다듬기

글의 길이와 분위기에 맞춰 문단을 나누었다면, 문장 수준에서 신경을 쓸 차례입니다. 문장의 길이를 짧게 유지하는 것도 중요하지만, 저는 주로 문장 간의 연결이 잘 맞물려있는지 를 신경 써서 봅니다.

한 문단 내의 문장들끼리도 서로 연관된 관계가 있다

위의 사진에서 볼 수 있듯이, 문단 내 각 문장은 인접한 다른 문장들과 또 다른 관계를 맺습니다. 이처럼 각 문장을 매끄럽고 자연스럽게 연결하기 위해서는 문장 간의 흐름이 파도처럼 서로 다른 높낮이를 가지게 만들어야 합니다.

이를 위해서는 문장 간의 연결 관계를 단조롭지 않게 구성하고, 경우에 맞는 접속사를 적절히 활용하여야 합니다.

• 분위기 반전: 하지만, 허나, 그러나, 그런데, 한편으로는, …
• 병렬 구조: 그리고, N번째로, 먼저, 다음으로, 우선, 또한, 게다가, …
• 요약 정리: 즉, 다시 말해, 이러한, 정리하자면, 이처럼, …
• 인과 관계: 따라서, 때문에, 덕분에, 그러므로, …
• 예시 및 가정: 가령, 예를 들어, ~의 경우, …

하지만 글을 쓰다 보면 피치 못하게 비슷한 문장 구조와 어휘가 반복되는 경우가 발생하곤 합니다. 이럴 때에는 동일한 의미를 가져가면서 문장 구조의 표현 방식을 다양하게 하는 방식으로 단조로움을 피하곤 합니다. (한글의 위대함…?)

• HTML은 프로그래밍 언어가 아닙니다. 문서의 구조를 설명하는 마크업 언어이기 때문입니다.
• HTML은 프로그래밍 언어가 아닌데, 문서의 구조를 설명하는 마크업 언어이기 때문입니다.
• HTML은 문서의 구조를 설명하는 마크업 언어이기 때문에 프로그래밍 언어가 아닙니다.
• 문서의 구조를 설명하는 마크업 언어인 HTML은 프로그래밍 언어라고 할 수 없습니다.
• 문서의 구조를 설명하는 언어는 마크업 언어입니다. 즉, HTML은 프로그래밍 언어가 아닙니다.

단어 수준에서 글 다듬기

문장 간의 연결이 자연스러운지 확인했다면 단어 수준에서 글을 다듬을 차례입니다. 이 때는 일관된 용어를 사용하는 것에 집중합니다. 여기에는 제 나름대로의 규칙이 있는데, 절대적으로 맞고 틀린 것이 아니기 때문에 필요에 따라 적용하면 됩니다.

• 한글/영어 명칭 중에서는 한글을 선호
  • ❌ : Pure function, First-class citizen, IIFE, Virtual DOM
  • ✅ : 순수 함수, 일급 시민, 즉시 실행 함수, 가상 DOM
• 고유 명사는 가능한 원문 이름 그대로 부르기
  • ❌ : 자바스크립트, 파이썬, 리액트, 뷰
  • ✅ : JavaScript, Python, React, Vue
• 다만 업계에서 이미 영어 명칭이 더 많이 통용되는 경우는 영어를 한글 발음으로 표기
  • ❌ : 저지르기, 밀기, 당기기, 합치기
  • ✅ : 커밋, 푸시, 풀, 머지
• 한 번 사용한 단어를 다른 이름으로 혼용하여 부르지 않기
  • ❌ : 웹을 이루는 언어 중 JS가 있습니다. 자바스크립트는 동적 기능을 추가하는 데 사용됩니다.
  • ✅ : 웹을 이루는 언어 중 JavaScript가 있습니다. JavaScript는 동적 기능을 추가하는 데 사용됩니다.
• 약자가 등장할 때는 원문을 병행 표기하기
  • ❌ : IIFE, SEO
  • ✅ : IIFE(Immediately Invoked Function Expression), SEO(Search Engine Optimization)
• 보그체 피하기:
  • ❌ : Object에 속한 여러 method를 단일 구문으로 연쇄 호출하는 Pattern을 Chaining이라고 합니다.
  • ✅ : 객체에 속한 여러 메서드를 단일 구문으로 연쇄 호출하는 패턴을 체이닝(chaining)이라고 합니다.
• 본문 어조는 높임말(해요체, 합쇼체)을 유지하기
  • ❌ : HTML은 프로그래밍 언어가 아니다. JavaScript는 프로그래밍 언어임.
  • ✅ : HTML은 프로그래밍 언어가 아닙니다. JavaScript는 프로그래밍 언어죠.

미디어를 적절히 활용하기

이미지 넣을 게 없으면 움짤을 적극 활용하자

독자에게는 열 줄의 글보다 하나의 이미지가 더 이해하기 쉽게 느껴집니다. 따라서 주제와 관련된 이미지, 비디오 등의 자료가 있다면 적극 활용하도록 합니다. 위 이미지처럼 캡션을 달아 보완 설명을 할 수도 있구요.

특히 기술 관련 글을 쓰다 보면 글의 분위기가 너무 진지해지거나 딱딱해질 수 있습니다. 또한 본문에 글보다 코드 블록이 더 많아지는 경우도 있고, 글의 양이 너무 많아지기도 합니다.

이럴 때에는 중간중간에 움짤이라도 넣어서 독자에게 쉬어가는 타임을 만들어주세요. 저는 글의 특정 부분의 레이아웃이 너무 빽빽해 보인다 싶으면 GIPHY에서 대충 적절한 움짤을 넣습니다.

글 쓴 후

본문을 마무리했다면 발행 전 최종 점검을 할 시간입니다. 저는 크게 두 가지 방법으로 퇴고합니다.

글을 소리내어 읽기

포풍래핑

가장 단순하지만 효과적인 방법입니다. 내가 쓴 글을 눈으로만 훑어보면 잘못된 부분을 쉽게 찾을 수 없습니다. 우리의 뇌가 잘못된 부분을 보정한 채 슥~ 넘겨버리기 때문이죠.

따라서 저는 글을 완성한 후에는 항상 전체를 소리 내어 읽어봅니다. 잘 작성된 글은 그 본문 자체를 읽는 것만으로 발표 대본이 될 수 있어야 한다는 마음가짐으로 말이죠.

이 방법을 쓰면 특히 글의 호흡이 적당한지를 잘 파악할 수 있기 때문에 애용하고 있습니다. 문장이 너무 길거나, 논리적으로 말이 안 되는 부분도 쉽게 찾을 수 있죠.

다만 혼자서 말을 주절주절 해야 하다 보니 집 밖에서 하기엔 좀 어렵고 목이 좀 멜 수 있다는 단점(…)이 있습니다. 가능하다면 물 한 잔 떠놓고 집에서 하세요.

주의를 환기시킨 후에 퇴고하기

좀 쉬었다가 스마트폰, 태블릿으로 다시 본다

한 자리에 오래 앉아서 글을 쓰다 보면 그 글에 뇌가 익숙해진 상태가 됩니다. 이런 관점으로는 내 글에서 어떤 문제가 있는지를 쉽게 찾기 어렵죠. 그래서 주의를 한 번 환기하고 퇴고하는 과정이 필요합니다. 좀 쉬었다가 글을 다시 보는 것도 좋고, 글을 보는 장소와 환경을 바꾸어보는 것도 좋습니다.

저는 주로 산책을 하고 오거나, 밥을 먹고 오거나, 잠을 자고 옵니다. 글을 읽는 도구도 스마트폰, 태블릿으로 바꿔서 읽어보죠. 만약 카페에서 글을 썼다면 집에 돌아와서는 침대에 누워서 글을 읽어보기도 합니다. 글에 깊게 집중해버린 내 뇌를 완전히 리셋한 후에 퇴고할수록 효과가 좋습니다.

예전에 책을 쓸 때 교정을 기다리면서 거의 한 달(!) 동안 원고를 보지 않았던 적이 있는데요, 분명히 원고를 완성시켰을 당시에는 더 이상 고칠 데가 없어 보였는데 나중에 원고를 다시 살펴보니 고칠 점 투성이어서 놀랐던 기억이 납니다. 이처럼 주의를 환기시키고 글을 다시 보면 기존 시각에서 놓친 부분을 찾기가 더 쉽습니다.

글 발행 후

이렇게 글을 발행했다면 내 글을 독자들에게 소개할 차례입니다. 어렵게 쓴 글인데 독자가 많이 읽어줘야 뿌듯하겠죠?

글을 공유하고 나의 구독자를 만들기

좌측 상단부터 시계 방향으로 링크드인, 커리어리, 페이스북, 메일리

저는 작성한 글을 개발 커뮤니티 혹은 개인 SNS 계정에 공유하는 편입니다. 글은 쓰지만 공유에는 소극적인 분들이 생각보다 많더라구요. 보통 글에 대한 자신감이 없거나, 부정적인 피드백을 받기가 두렵거나, 이런 것까지 공유해야 하나? 싶은 생각 때문에 망설이시는 것 같았습니다.

일단 한 번 해보세요. 이 글을 왜 썼고, 왜 여러분께 도움이 될지를 잘 포장해서 정성스러운 멘트와 함께 공유해보세요. 잘 쓴 글이라면 분명히 입소문을 타고 여기저기 공유될 것입니다. 다만 글을 공유하는 빈도가 너무 잦거나 멘트에 문제가 있다면… 오히려 광고처럼 느껴져 불쾌감을 유발할 수도 있으므로 주의합니다.

이렇게 커뮤니티에 “내 글을 읽어주세요” 라고 전단지 뿌리듯 홍보를 할 수도 있지만, 더 좋은 방법은 내 글을 꾸준히 읽어줄 구독자 를 늘리는 것입니다. 구독자는 일단 내가 쓴 글에 대한 호감이 있는 사람들 이기 때문에 글을 읽을 뿐만 아니라 나를 홍보하고 다른 곳에 2차 공유해줄 가능성이 더 높습니다.

저는 이를 위해 각종 SNS 계정(페이스북 페이지, 링크드인, 커리어리)에 글을 공유하고, 블로그에는 뉴스레터 기능을 추가해놓은 상태입니다.

일관성을 유지하여 개인 브랜딩 구축하기

일관성을 갖고 꾸준히만 하면 커리어는 무조건 우상향 하게 되어 있다

마지막으로 위 모든 과정을 인내심을 갖고 꾸준히 반복합니다. 내가 쓴 글의 콘셉트를 일관성 있게 유지하고, 여러 곳에 공유하며 구독자를 쌓으세요. 잘 쓴 글은 다른 웹사이트에서 참고 자료로 쓰이기도 하고, 이 덕분에 구글 검색에서 최상위에 노출되기도 합니다. 시간이 충분히 흐르면 SNS를 통해 유입된 사람들보다 검색을 통해 유입된 사람들이 더 많아질 것입니다.

마블 유니버스가 하루아침에 만들어진 게 아닌 것처럼, 나만의 기술 유니버스도 하루아침에 만들어지지는 않습니다. 오랜 시간 동안 글을 꾸준히 써야 하고, 퀄리티도 잘 챙겨야 하죠. 결코 쉬운 과정은 아니지만 이것이 누적되면 어느 순간부터 나의 글 자체가 하나의 브랜드가 됩니다. 그리고 우리는 이것을 개인 브랜딩이라고 부르죠.

마무리

긴 글 읽느라 고생하셨습니다

이렇게 제가 글을 쓰는 과정을 한 번 정리해보니, 스스로의 글쓰기 패턴을 돌아볼 수 있어서 재밌었던 것 같습니다. 이게 바로 메타인지…? 다만 그만큼 평소에 비해 글을 쓰는데 시간이 엄청 오래 걸려서 힘들었네요.

기술 글쓰기는 결코 쉽지 않습니다. 시간도 오래 걸리고 지치는 일입니다. 그러다 보니 꾸준히 글을 쓰는 것은 더욱 어려운 일처럼 느껴집니다. 하지만 한 번 습관을 들이면 관성이 붙어서 생각보다는 할 만합니다. 따라서 여러분이 글쓰기를 통해 추구하는 가치가 무엇인지를 먼저 생각해보고, 그것에 맞는 글쓰기 루틴을 한 번 찾아보세요. 그리고 이 패턴을 꾸준히 유지한다면 개인 브랜딩은 저절로 따라올 것입니다.

아무튼 이렇게 제 글쓰기 루틴을 공유해보았습니다. 여러분도 각자에게 맞는 글쓰기 루틴을 한 번 찾아보고 글로 정리해보세요!