기술 블로그를 시작한 이유는 거창하지 않았다. 면접 준비하려고. 이직을 결심하고 나서 "프론트엔드 면접 질문" 리스트를 쭉 훑어봤는데, 대답을 머릿속으로는 할 수 있는데 입으로 말하려니 두서가 없었다. 그래서 면접 단골 주제를 하나씩 글로 정리하기 시작했다.

그 과정에서 예상치 못한 일이 벌어졌다.

설명하려면 진짜 이해해야 한다#

React의 Virtual DOM이 왜 빠른지 설명하는 글을 쓰려고 했다. "실제 DOM 조작을 줄여서 빠르다" — 면접에서는 이 정도면 넘어간다. 근데 글로 쓰려고 하니까 바로 막혔다. "줄인다"는 게 정확히 무슨 뜻이지? diffing 알고리즘은 어떻게 동작하지? reconciliation이랑 rendering의 차이는 뭐지? 그리고 "빠르다"는 기준이 뭐지? 실제로 항상 빠른 건가?

면접에서 30초짜리 답변으로 넘어갈 수 있었던 주제를, 글로 쓰려니까 구멍이 수십 개 보였다. 한 문단 쓰고 멈추고, 공식 문서 읽고, 다시 쓰고, 지우고. Virtual DOM 글 하나 쓰는데 이틀이 걸렸다.

Richard Feynman이 말한 학습법이 정확히 이거다. 개념을 누군가에게 설명할 수 있으면 이해한 거고, 설명하다가 막히는 지점이 모르는 부분이다. 나는 Virtual DOM을 "안다"고 생각했는데, 글쓰기가 그 착각을 깨줬다.

이 경험이 반복됐다. closure를 설명하려다 execution context를 다시 공부했고, useEffect의 cleanup function을 설명하려다 JavaScript의 garbage collection까지 파고들었다. 하나를 쓸 때마다 세 개를 새로 배웠다.

지금도 글을 쓸 때 자주 하는 테스트가 있다. 쓴 문장을 소리 내서 읽어본다. 읽다가 "이게 맞나?"라는 느낌이 0.5초라도 들면, 거기가 내가 아직 100% 이해하지 못한 부분이다.

PR description이라는 기술 문서#

글쓰기 습관이 업무에서 가장 먼저 효과를 보인 건 PR description이었다.

예전에는 PR 설명을 이렇게 썼다.

장바구니 쿠폰 로직 수정

이게 끝이었다. 리뷰어가 PR을 열면 파일 diff부터 봐야 했고, 왜 이 변경이 필요한지, 어떤 접근 방식을 선택했는지를 코드에서 역으로 추론해야 했다. 리뷰가 오래 걸렸고, 핵심이 아닌 부분에서 코멘트가 달리는 경우가 많았다.

블로그를 쓰면서 "독자의 머릿속에 맥락을 먼저 깔아줘야 한다"는 걸 배운 뒤로, PR description을 바꿨다.

## 배경
쿠폰 적용 시 할인율 계산이 상품 옵션별로 다르게 적용되어야 하는데,
현재는 전체 주문 금액 기준으로 일괄 계산되고 있음

## 변경 사항
- 쿠폰 할인 계산 로직을 CartItem 단위로 분리
- 옵션별 할인율 매핑 추가
- 기존 테스트 케이스 수정 + edge case 3건 추가

## 참고
- 기획 문서: [링크]
- 관련 이슈: #142

이렇게 바꾸고 나서 리뷰 시간이 체감상 절반으로 줄었다. 리뷰어가 "이거 왜 바꾼 거야?"라고 묻는 일이 거의 없어졌다. 한번은 팀 리드가 다른 팀원에게 "PR 쓰는 거 이 사람 거 참고해봐"라고 한 적이 있다. 코드 실력에 대한 칭찬보다 이게 더 기억에 남는다.

시니어의 업무량에서 문서가 차지하는 비중#

3년 차를 넘기면서 깨달은 게 있다. 경력이 쌓일수록 코드를 짜는 시간보다 글을 쓰는 시간이 길어진다.

장애 보고서를 써야 한다. 새벽 2시에 서비스가 터져서 대응하고 나면, 다음 날 아침에 보고서를 작성해야 한다. 타임라인, 원인 분석, 영향 범위, 재발 방지 대책. 이걸 비개발 직군도 이해할 수 있게 써야 한다. 장애 대응 자체보다 보고서 쓰기가 더 어려울 때도 있다.

RFC(Request for Comments)도 써야 한다. 새로운 기술 도입이나 아키텍처 변경을 제안할 때, "그냥 이게 좋을 것 같아요"로는 안 된다. 현재 문제가 뭔지, 제안하는 방식이 뭔지, 대안은 뭐가 있고 왜 이 방식이 낫다고 생각하는지를 구조적으로 정리해야 한다. 팀원 7명이 읽고 의견을 줄 수 있을 만큼 명확해야 한다.

기술 스펙 문서, 온보딩 가이드, API 변경 공지, 마이그레이션 플랜...

우리 팀의 시니어를 관찰하면 하루 업무 중 60% 이상이 문서 작업인 날이 꽤 있다. Slack 메시지조차 짧은 글쓰기다. "이 기능은 A 방식으로 구현하려고 합니다. 이유는 X이고, 리스크는 Y인데 Z로 커버할 계획입니다"라는 한 줄 메시지가 30분짜리 회의를 대체한다.

코드만 잘 짜서 시니어가 되는 시대는 지났다. 생각을 글로 명확하게 전달하지 못하면, 아무리 좋은 기술적 판단도 팀에 녹아들지 못한다.

블로그가 면접에서 만든 차이#

이직 면접 이야기로 돌아오자.

블로그를 3개월 정도 운영하고 나서 면접을 보러 갔다. 이력서에 블로그 URL을 넣었는데, 면접관이 블로그를 실제로 읽고 온 경우가 두 번 있었다. 그 중 한 번이 결정적이었다.

기술 면접 중반쯤, 면접관이 "블로그에 useEffect cleanup 관련 글 쓰셨던데, 그때 겪은 메모리 릭 케이스 좀 더 자세히 설명해줄 수 있어요?"라고 물었다. 내가 직접 쓴 글이니까 당연히 기억이 생생했다. WebSocket 연결을 unmount 시점에 끊지 않아서 발생한 문제, 재현 과정, 해결 방법을 막힘 없이 이야기할 수 있었다. 면접관도 비슷한 경험이 있었는지 대화가 자연스럽게 이어졌다.

그 면접은 "시험"이 아니라 "기술 토론" 같았다. 긴장이 확 풀렸다.

일반적인 면접에서는 준비된 답변을 암기해서 말한다. 면접관은 "진짜 아는 건지 외운 건지"를 구분하려고 꼬리 질문을 던진다. 근데 내가 직접 경험하고 글로 정리한 내용은 다르다. 꼬리 질문이 와도 대답할 수 있다. 왜냐하면 글을 쓸 때 이미 꼬리 질문을 스스로에게 던져본 상태니까.

블로그의 글 하나하나가 "나는 이 주제에 대해 이만큼 생각해봤다"는 증거물이 된다. 이력서에 "React 숙련"이라고 적는 것보다 React에 대해 쓴 글 5편이 훨씬 강력하다.

Writing is thinking#

Paul Graham이 한 유명한 말이 있다.

"Writing about something, even something you know well, usually shows you that you didn't know it as well as you thought."

글을 쓰는 건 생각을 기록하는 행위가 아니다. 생각을 만드는 행위다.

코드도 마찬가지 아닌가. 머릿속에서는 완벽한 설계가, 실제로 코드를 치기 시작하면 구멍이 드러난다. 글쓰기도 그렇다. "나는 이 개념을 안다"는 생각이, 글을 쓰기 시작하면 흔들린다. 그 흔들리는 지점을 붙잡고 파고드는 과정이 진짜 학습이다.

나는 블로그를 통해서 글쓰기를 시작했지만, 글쓰기의 효과가 발현되는 곳은 블로그 밖이었다. PR description, Slack 메시지, 장애 보고서, 기술 제안서, 면접 답변. 글을 쓰면서 훈련된 "구조적으로 생각하는 능력"이 이 모든 곳에서 작동했다.

첫 글은 아무도 안 읽는다#

여기까지 읽고 "나도 블로그 시작해볼까"라는 생각이 들었다면, 한 가지 미리 말해두고 싶은 게 있다.

첫 글은 아무도 안 읽는다. 두 번째 글도. 세 번째 글도.

내 첫 번째 글의 조회수가 3이었는데, 그 중 2개는 내가 다른 기기에서 확인한 거고, 1개는 아마 검색 엔진 크롤러였다. 한 달 동안 꾸준히 글을 올렸는데 총 조회수가 50을 넘지 않았다. 그때 그만둘 뻔했다. "이걸 왜 하고 있지?"라는 생각이 매일 들었다.

근데 거꾸로 생각하면, 아무도 안 읽는다는 건 기회다. 못 쓴 글이 들킬 일이 없다. 완벽하지 않아도 괜찮다. 틀린 내용이 있으면 나중에 고치면 된다. 첫 글이 부끄럽다면 6개월 뒤에 지우면 된다. 실제로 나도 초기 글 몇 개는 삭제했다.

중요한 건 잘 쓰는 게 아니다. 쓰는 행위 자체가 중요하다. 10편을 쓰면 1편에서 안 보이던 게 보인다. 30편을 쓰면 자기만의 글쓰기 패턴이 생긴다. 50편을 쓰면 글 하나에 걸리는 시간이 절반으로 준다. 근육이 붙는 거다.

오늘 당장 할 수 있는 것#

글쓰기를 시작하는 가장 좋은 방법은 작게 시작하는 것이다.

오늘 업무하면서 배운 것 하나를 500자로 정리해보자. "오늘 Array.prototype.at() 메서드를 처음 알았다. 음수 인덱스로 배열 끝에서부터 접근할 수 있다. arr[arr.length - 1] 대신 arr.at(-1) 쓸 수 있다. IE는 지원 안 한다." 이 정도면 된다. TIL(Today I Learned) 형식으로 올리면 부담도 적다.

플랫폼도 중요하지 않다. 티스토리든 velog든 개인 블로그든 노션 페이지든 상관없다. 형식도 중요하지 않다. 완벽한 튜토리얼을 쓸 필요 없다. 에러 로그 하나 붙여넣고 "이렇게 해결했다" 한 줄이면 충분하다.

완벽한 글을 쓰겠다는 생각이 드는 순간, 그게 시작을 막는 가장 큰 장벽이 된다. 첫 글을 publish 하는 데 필요한 건 실력이 아니라 Enter 키를 누르는 용기 하나뿐이다.

나도 지금 이 글을 쓰면서 두 번이나 다 지우고 처음부터 다시 썼다. 완성된 글만 보면 술술 쓴 것 같지만 과정은 항상 지저분하다. 그래도 쓴다. 왜냐하면 쓰기 전의 내 생각과 쓴 뒤의 내 생각이 다르다는 걸 매번 확인하니까.