개발자의 기술 글쓰기, 어떻게 시작할까

글쓰기를 시작한 이유

3년 차 때 기술 블로그를 시작했다. 이유는 별거 없었다. 삽질한 내용을 기록해두면 나중에 같은 문제를 만났을 때 쓸모 있을 거라고 생각해서. 자기 마케팅이나 영향력 같은 거창한 목표는 없었다. 그냥 미래의 나를 위한 메모장이었다.

2년이 지난 지금, 글 83개를 썼다. 방문자 수는 글당 평균 143명. 대단한 숫자는 아니다. 근데 글쓰기가 내 커리어에 미친 영향은 방문자 수보다 훨씬 크다.

첫 글을 쓰는 데 일주일이 걸렸다. "Next.js App Router에서 데이터 페칭하기"라는 주제였는데, 이미 비슷한 글이 수백 개 있으니까 "내가 이걸 써서 누가 읽겠어?"라는 생각이 계속 들었다.

근데 쓰고 나니까 깨달았다. 같은 주제라도 내 삽질 과정, 내가 막힌 부분, 내 해결 방식은 유일하다. 공식 문서를 읽고 바로 이해한 사람의 글과, 삽질 3시간 끝에 이해한 사람의 글은 다르다. 오히려 후자가 같은 처지의 독자한테 더 도움이 된다.

(첫 글에 댓글이 하나 달렸을 때의 기쁨을 아직도 기억한다. "도움이 됐습니다. 감사합니다." 이 한 줄이 두 번째 글을 쓰게 만들었다.)

20번째 글까지 걸린 가장 큰 장애물은 완벽주의였다. 틀린 내용이 있으면 어쩌지, 댓글에서 지적받으면 창피하지 않을까. 이런 걱정 때문에 글 하나를 5번씩 고치고, 그래도 게시 버튼을 누르기 어려웠다.

어느 순간 깨달은 거다. 기술 블로그는 논문이 아니다. 틀리면 수정하면 된다. 실제로 댓글에서 오류를 지적받아서 수정한 적이 7번 있다. 그때마다 나도 배우고, 글도 정확해졌다.

내가 쓰는 글은 크게 세 종류다. 삽질 기록, 학습 정리, 경험 공유.

삽질 기록이 가장 쓰기 쉽고 반응도 좋다. "이 에러 메시지로 3시간 삽질한 뒤 해결한 방법" 같은 글. 이런 글은 검색 유입이 많다. 나와 같은 문제를 만난 사람이 구글에서 찾아오니까.

학습 정리는 내 성장에 도움이 된다. 새로운 기술을 공부하면서 정리하면 이해가 깊어진다. 근데 시간이 오래 걸린다. 한 편에 4~5시간.

경험 공유는 쓰기 가장 어렵지만 가장 보람 있다. 기술적 내용이 아니라 일하면서 느낀 점, 실패한 경험, 배운 교훈. 이런 글은 방문자는 적지만 공감 댓글이 달린다.

한때 "매주 1편"을 목표로 잡았는데, 2개월 만에 번아웃이 왔다. 퀄리티가 떨어지는 게 느껴졌다. 결국 "한 달에 2~3편, 쓰고 싶을 때" 페이스로 바꿨다. 꾸준함은 중요하지만, 무리한 꾸준함은 오히려 해롭다.

내가 83개를 쓰면서 정리한 실용적인 팁들.

오늘 삽질한 걸 쓴다. 주제 고민을 줄이는 가장 쉬운 방법이다. 에러 해결, 설정 삽질, 라이브러리 비교. 이미 겪은 걸 쓰니까 자료 조사가 필요 없다.

글의 구조를 먼저 잡는다. 서론, 문제 상황, 해결 과정, 결론. 이 골격을 먼저 써놓고 살을 붙이면 막막함이 줄어든다.

초안은 빠르게, 퇴고는 천천히. 처음부터 완벽한 문장을 쓰려 하면 한 글자도 못 쓴다. 일단 생각나는 대로 쓰고, 다음 날 다시 읽으면서 다듬는다.

블로그 플랫폼 고민은 나중에. 처음에 Notion에 써도 되고, GitHub에 마크다운으로 써도 된다. 플랫폼보다 글 자체가 중요하다. 나는 처음에 벨로그에 쓰다가 개인 블로그로 옮겼는데, 어디에 쓰든 쓰는 행위 자체가 중요하다.

아무도 안 읽어도 괜찮다. 첫 달 방문자가 7명이었다. 근데 가장 큰 독자는 미래의 나다. 실제로 6개월 전에 쓴 글을 다시 참고한 적이 여러 번 있다.