글쓰기가 개발 실력에 미치는 영향

글쓰기와 코딩이 무슨 관계인가

처음에 이 둘이 관련 있다는 말을 들었을 때 "무슨 소리야"라고 생각했다. 개발자한테 중요한 건 알고리즘이지, 국어 능력이 아니잖아. 근데 블로그를 2년 쓰면서 생각이 바뀌었다. 글쓰기를 하면 생각을 구조화하는 능력이 생긴다. 이게 코드 구조를 잡는 것과 놀라울 정도로 비슷하다.

코드도 결국 읽는 사람을 위한 글이다

변수명을 잘 짓는 것, 함수를 적절히 분리하는 것, 주석을 명확하게 다는 것. 전부 "읽는 사람"을 위한 행위다. 글쓰기에서 독자를 고려하는 것과 같다. 내가 이해하는 코드가 아니라, 6개월 뒤의 내가 이해할 코드, 다른 팀원이 이해할 코드를 짜야 한다.

블로그를 쓰면서 "이 문장이 독자한테 명확한가?"를 계속 고민하다 보니, 코드 짤 때도 "이 함수명이 다른 개발자한테 명확한가?"를 자연스럽게 고민하게 됐다.

PR 설명이 달라졌다

글쓰기 전 나의 PR 설명: "로그인 기능 수정". 끝.

글쓰기 후 나의 PR 설명: "세션 만료 시 자동 로그아웃되지 않는 버그 수정. 원인: 토큰 갱신 로직에서 만료 시간 비교가 UTC가 아닌 로컬 타임으로 되어 있었음. 변경사항: 시간 비교를 UTC 기준으로 통일."

이 차이가 코드 리뷰 속도를 완전히 바꿨다. 리뷰어가 맥락을 바로 파악하니까 피드백이 빨라졌다. 팀 전체의 개발 속도에 기여한 셈이다.

(근데 처음부터 이렇게 쓴 건 아니다. 팀장이 "PR 설명 좀 자세히 써봐"라고 3번은 말한 것 같다.)

사내 문서화의 힘

온보딩 문서, 아키텍처 결정 문서(ADR), 장애 보고서. 이런 문서를 쓰면서 기술적 판단을 글로 정리하는 습관이 생겼다. "왜 이 기술을 선택했는가"를 글로 쓰면, 내 사고 과정의 허점이 보인다.

한번은 새 라이브러리 도입을 제안하는 문서를 쓰다가 "근거가 부족하네"라고 느꼈다. 벤치마크를 돌려보니까 기존 라이브러리보다 오히려 느렸다. 글을 안 쓰고 구두로만 제안했으면 그냥 통과됐을 수도 있다. 글쓰기가 잘못된 결정을 막아준 거다.

실수: 너무 길게 쓴다

내 약점은 글이 길어지는 거다. Slack 메시지도 5줄 이상 쓰면 읽는 사람이 줄어든다. 기술 문서도 핵심을 먼저 쓰고 세부사항은 뒤에 붙여야 하는데, 배경 설명부터 장황하게 쓰는 버릇이 있다.

이걸 고치려고 "BLUF (Bottom Line Up Front)" 원칙을 적용하고 있다. 결론을 먼저 쓰고, 그다음에 이유를 쓴다. 아직 완전히 체화되진 않았지만, 의식하니까 조금씩 나아지고 있다.

블로그가 커리어에 도움이 됐나

솔직히 직접적인 도움은 기대보다 적었다. 블로그 때문에 이직에 성공했다거나, 유명해졌다거나 하는 건 없다. 방문자 수도 글당 평균 127명 정도.

근데 간접적인 효과가 크다. 글을 쓰면서 기술을 더 깊이 이해하게 됐고, 표현력이 좋아지면서 회의에서 내 의견을 설득력 있게 전달하게 됐다. 이건 숫자로 측정이 안 되는 변화인데, 체감은 확실하다.

글쓰기가 개발 실력에 직접적으로 미치는 영향이 있느냐고 물으면, 있다고 생각한다. 근데 이건 내 경험이고, 글쓰기 없이도 훌륭한 개발자는 많다. 다만 글쓰기를 시작하면 손해 볼 건 없다.