글쓰기 100일 — 우리 셋이 배운 것

100일이 쌓이는 방식 — 의식에서 구조로

처음 한 달은 의식적 노력이었다. 달력에 표시하고, 슬랙 채널에서 "이번 주 누가 뭘 쓸지" 조율했다. 두 달째 중반쯤, 그 조율이 사라졌다. 작업을 마치고 PR을 올리는 순간, 자동으로 "이거 글 하나 나오겠다"는 생각이 먼저 들었다. 습관이 외부 규칙에서 내부 반사로 전환되는 시점이 그즈음이었다.

이게 단순한 자기계발 이야기처럼 들릴 수 있다. 그런데 우리 팀의 일상 — 결제 실패 추적, 정산 배치 자동화, 외부 PG사 연동 — 을 들여다보면 이 전환의 의미가 달라진다. 우리가 다루는 시스템은 "나중에 문서화하면 되지"가 통하지 않는 영역이다. 6개월 전에 왜 소수점을 버림 처리했는지, 왜 특정 상태 코드에서 재시도를 막았는지 — 그 결정의 맥락이 사라지면 장애가 난다. 글쓰기 습관은 그 맥락을 팀 안에 살아있게 만드는 구조였다.

결제·정산 팀에서 글쓰기가 유독 중요한 이유

일반 소프트웨어 개발과 결제·정산 자동화 사이에는 결정적인 차이가 있다. 일반 기능은 버그가 나면 고치면 된다. 정산 로직의 버그는 돈이 잘못 계산된 채 거래가 쌓인 뒤에야 발견된다. 우리 팀이 운영하는 일 배치 정산 작업은 하루에 수천 건의 거래를 처리하고, 오류 하나가 복구에 수 시간이 걸리는 구조다. 이 환경에서 "코드를 보면 알겠지"는 위험한 태도다.

슬렉스가 100일 동안 깨달은 것이 여기서 정확히 맞닿는다. "글을 쓰면 코드를 짤 때 더 신중해진다. 나중에 이 결정을 어떻게 설명할지 의식하게 된다." 우리 팀에서 이 말을 구체적으로 번역하면 이렇다: 정산 로직에 예외 처리를 추가할 때, 그 예외가 왜 존재하는지 한 문단으로 설명할 수 없다면 코드가 덜 된 것이다. 글쓰기 훈련이 바로 그 검증 루프를 내면화시킨다. PR 리뷰 코멘트가 아니라, 코드를 짜는 순간 스스로 "이걸 어떻게 설명하지?"를 묻게 된다.

셋이 배운 것 — 코드, 비용, 그리고 불편함

밍스는 100일 동안 짧게 쓰는 훈련을 했다고 정리했다. 처음에는 2,000자 이상 써야 '한 편'이라는 느낌이 들었다. 지금은 1,000자 이내에 핵심만 담는 게 더 어렵고 더 가치 있다는 걸 안다. 이건 팀 운영에서 직접적인 효과로 이어졌다. 밍스가 인프라 비용에 대해 쓴 글 — 특정 클라우드 스케줄러 비용이 예상보다 월 30% 높게 나온 이유와 대안 — 을 읽고 나서, 개발자가 기능 구현 시 컴퓨팅 리소스 선택 기준을 바꿨다. 그 글이 없었다면 코드 리뷰나 스프린트 회의에서 그 맥락이 전달될 경로가 없었다. 인프라 담당자와 기능 개발자는 같은 슬랙 채널에 있어도 서로의 고민을 공유할 자연스러운 접점이 없기 때문이다.

나는 다른 걸 배웠다. 틀린 내용을 공개적으로 올리면 불편하다. 그 불편함이 조사를 더 철저하게 만든다. 한 번은 특정 PG사의 웹훅 재시도 정책을 잘못 이해한 채 글을 올렸다가 수정을 해야 했다. 그 이후로 외부 연동 관련 글을 쓸 때는 반드시 공식 문서와 실제 테스트를 병행한다. 이 루틴이 없었다면 그 오해는 코드 속에 그냥 남아 있었을 가능성이 높다. 공개 글쓰기는 사실 검증 비용을 치르게 만드는 구조적 장치다.

예상보다 좋았던 것 — 블로그가 코드 리뷰를 대체한 순간

팀이 작을수록 코드 리뷰는 얕아지기 쉽다. 모두가 바쁘고, 리뷰어가 배경 맥락을 모르면 "LGTM"이 디폴트가 된다. 우리 팀에서 블로그가 예상치 못하게 그 공백을 채웠다. 코드 리뷰나 회의에서 나오기 어려운 맥락 — 왜 이 아키텍처를 선택했는지, 어떤 대안을 검토했는지, 실패한 접근법은 무엇이었는지 — 이 글에서 나왔다.

구체적인 예시 하나. 자동화된 환불 처리 로직을 개발할 때, 담당자가 "왜 큐를 쓰지 않고 동기 처리로 구현했나"를 글로 정리했다. 이유는 단순했다 — 환불 요청 건수가 일 평균 50건 미만이고, 큐 도입 시 운영 오버헤드가 이득보다 크다는 판단이었다. 이 글 덕분에 6주 뒤 다른 팀원이 비슷한 기능을 구현할 때 같은 고민을 다시 하지 않았다. 트레이드오프가 문서화되어 있었기 때문이다. 이런 결정 기록은 Notion 문서나 코드 주석보다 글 형식에서 훨씬 잘 살아남는다 — 맥락이 서술 구조 안에 있기 때문이다.

예상보다 힘들었던 것 — 시간 비용과 현실적인 트레이드오프

솔직하게 쓴다. 시간이 문제였다. 글 하나에 빠르면 40분, 느리면 두 시간 넘게 걸린다. 정산 마감이 몰리는 월말이나 PG사 연동 이슈가 터진 주에는 글을 쓰고 싶지 않았다. 몇 번은 밀렸다. 이때 우리가 선택한 건 규칙 강제가 아니라 부담 없이 밀리는 것이었다. 연속성 강박을 만들지 않은 게 100일을 채울 수 있었던 이유 중 하나다.

여기서 현실적인 트레이드오프를 짚어야 한다. 글 한 편에 평균 1시간을 쓴다고 치면, 세 명이 100일 동안 쓴 시간은 약 300시간이다. 작은 팀에게 이건 결코 작은 숫자가 아니다. 그 시간을 다른 데 쓰는 게 나았을까? 우리 판단은 아니다 — 다만 조건이 있다. 글이 실제로 팀 내 지식 전달로 이어지고, 코드 결정의 질에 영향을 미칠 때만 그 시간이 정당화된다. 이걸 측정하긴 어렵지만, 우리가 체감한 변화는 분명했다. 온보딩이 빨라졌고, "왜 이렇게 짰지?"라는 질문이 줄었다.

다음 100일을 위한 실행 가능한 시사점

회고는 여기서 끝내지 않는다. 독자가 바로 가져갈 수 있는 것들을 정리한다.

1. 완성된 생각만 기다리지 마라. 결제·정산 영역에서 "아직 모르겠다"는 글이 오히려 더 유용하다. "웹훅 중복 수신 처리를 어떻게 해야 할지 아직 결론 못 냈다"는 글이 팀 안에 문제를 가시화하고, 다른 사람의 경험을 끌어낸다. 우리는 다음 100일에 이런 미완의 글 비중을 늘릴 생각이다.

2. 결정 로그는 글로 남겨라. ADR(Architecture Decision Record) 형식이 있지만, 실제로 읽히지 않는다. 같은 내용을 블로그 글로 쓰면 팀원이 자연스럽게 읽는다. 특히 외부 시스템 연동 결정, 정산 로직의 예외 처리 근거, 인프라 비용 판단 — 이 세 영역은 글로 남기는 게 나중에 가장 큰 레버리지를 만든다.

3. 공개 불편함을 사실 검증 도구로 써라. 내부 위키보다 공개 블로그에 쓸 때 사실 확인을 더 철저히 하게 된다. 이 심리적 메커니즘을 의도적으로 활용해라. 불확실한 내용일수록 공개적으로 쓰는 게 검증 품질을 높인다.

4. 강제 연속성은 버려라. "매주 1편"을 목표로 삼되, 놓쳤을 때 벌칙이 없어야 한다. 압박이 강해지면 내용이 얕아지고, 결국 쓰기 자체를 그만두게 된다. 우리 팀이 100일을 버틴 건 유연한 규칙 덕분이었다.

5. 팀 내 다른 역할의 글을 구독하는 습관을 만들어라. 인프라 비용 글을 기능 개발자가 읽는 것, 자동화 로직 판단을 인프라 담당자가 읽는 것 — 이 크로스 리딩이 없으면 블로그는 개인 기록으로 끝난다. 우리는 슬랙에 새 글 알림 채널을 만들어 이를 구조화했다.

100일은 숫자가 아니라 확인이다. 이 습관이 실제로 팀의 의사결정 품질과 지식 전달에 기여한다는 걸 확인했다. 그래서 계속한다.

— by slecs