100번째 글 — 블로그가 우리에게 주는 것

세 명이 100편을 쌓는 동안 실제로 일어난 일

HEDVION은 결제·정산·자동화를 직접 운영하는 세 명짜리 팀이다. 블로그를 시작한 건 콘텐츠 마케팅이 목표가 아니었다. 12월 첫 글을 올릴 때 100편이 어떤 숫자인지 체감도 없었다. 주 2-3편 페이스라면 약 9-10개월. 그게 빠른 건지 느린 건지도 몰랐다.

숫자는 결국 쌓였다. 그런데 돌아보니 우리가 실제로 얻은 건 "블로그 글 100편"이 아니었다. 결정의 로그, 사고의 외부화, 그리고 회의실 밖에서 이뤄진 수십 번의 합의였다. 이 글은 그 100편이 세 명의 결제·정산·자동화 개발자에게 실질적으로 무엇을 남겼는지 정리한 것이다. 거창한 회고가 아니라, 실제로 반복해서 쓰게 된 이유에 대한 보고서다.

글쓰기는 우리 팀에서 설계 도구다

소프트웨어 개발에서 러버덕 디버깅(rubber duck debugging)은 잘 알려진 개념이다. 코드가 막히면 코드를 설명하는 행위 자체가 문제를 드러낸다. 결제·정산 시스템에서는 이 효과가 특히 강하게 작동한다. 이 도메인의 결정들은 대부분 엣지케이스의 합이고, 그 엣지케이스를 글로 쓰다 보면 설계의 구멍이 노출되기 때문이다. 빠르게 말로 합의할 때는 "그 케이스는 나중에"가 되지만, 글에서는 문장이 완성되지 않으면 다음으로 넘어갈 수가 없다.

구체적인 사례가 있다. 배포 자동화 방식을 놓고 우리 셋이 한 달 넘게 슬랙과 회의를 반복했다. 블루-그린 배포와 카나리 배포 사이에서 결론이 나지 않았던 이유는 기술적 판단 차이가 아니었다. 정산 배치 작업이 실행 중일 때 배포가 겹치면 어떻게 되는지, 아무도 그 전제를 언어화하지 않고 있었기 때문이다. slecs가 "일단 써볼게"라고 했고, 그 글을 쓰는 과정에서 "T+1 정산 배치 실행 중에 신규 버전 컨테이너가 동일 결제 레코드를 이중 처리할 수 있다"는 문장이 나왔다. 그 문장 하나로 방향이 정해졌다. 카나리 배포를 선택하고, 정산 배치 윈도우 외 시간대에만 트래픽 분할을 허용하는 조건을 달았다. 회의 세 번을 못 낸 결론이 글 한 편에서 나왔다.

결정의 맥락을 잃으면 정산 로직이 무너진다

결제·정산 시스템을 운영하는 팀에서 기억의 외부화는 선택이 아니라 리스크 관리다. 개발팀은 하루에도 여러 번 결정을 내린다. "왜 이 필드를 nullable로 뒀는가", "왜 재시도 로직에 지수 백오프를 쓰지 않았는가", "왜 특정 PG사 응답은 별도 파싱 레이어를 거치는가". 이 결정의 맥락이 기억 속에만 있으면 6개월 뒤 팀원이 합리적으로 보이는 '개선'을 하다가 시스템이 조용히 망가진다. 결제·정산은 실수의 비용이 즉각적이고 수치로 나온다.

실제로 그런 일이 있었다. 작년 특정 결제 수단의 환불 처리 방식을 변경하려 할 때 누군가 예전 블로그 글을 링크했다. slecs가 그 시점에 쓴 글에 "이 방식으로 처리한 이유는 해당 PG사의 partial refund API가 멱등성을 보장하지 않기 때문"이라는 문장이 있었다. 덕분에 변경 전에 멱등성 처리 로직을 추가하는 방향으로 수정했다. 그 글이 없었다면 우리는 같은 실수를 반복했을 것이고, 최소한 몇 건의 이중 환불이 발생했을 가능성이 있다. 우리 팀 기준으로 이중 환불 한 건의 처리 비용은 CS 대응·수작업 정정·PG사 협의를 합쳐 4-6시간이다. 블로그 글 한 편이 그 비용을 막았다.

회의 vs 글: 수치로 본 트레이드오프

"글 쓰는 데 시간이 더 걸리지 않나?" 측정해보면 아니다. 우리 팀 기준으로 기술적 결정을 담은 글 한 편 작성에 평균 90-120분이 걸린다. 반면 같은 주제로 합의에 이르는 회의는 평균 3회, 회당 45-60분이고, 결론이 문서화되는 경우는 거의 없다. 회의 방식의 총 비용은 3명 × 3회 × 50분 = 450인분. 글 방식의 총 비용은 작성자 120분 + 읽는 사람 2명 × 15분 = 150인분. 정확히 3배 차이다. 그리고 글에는 기록이 남고, 회의에는 남지 않는다.

트레이드오프도 분명히 있다. 글은 비동기라서 즉각적인 피드백 루프가 없다. 빠른 전술적 결정(오늘 배포를 막을 것인가 말 것인가)에는 회의가 옳다. 하지만 방향을 정하는 전략적 결정, 특히 결제·정산처럼 실수의 비용이 높은 도메인에서는 글이 낫다. 글로 쓰면 논리의 허점이 노출되고, 읽는 사람도 자신의 생각을 정리할 시간이 생기며, 결정이 문서로 남는다. 이 세 가지는 회의가 줄 수 없다.

외부 독자가 드러내는 우리의 맹점

블로그를 운영하면서 예상치 못한 수확이 있었다. 어떤 글은 조회수가 높았고, 어떤 글은 조용히 잠들었다. 처음엔 단순한 인기 지표로 봤다. 그런데 패턴을 보면 다른 이야기가 나온다. 결제 실패 재시도 로직을 다룬 글이 팀 내부에서 중요하게 여긴 배포 자동화 글보다 5-8배 더 읽혔고, 정산 타이밍 엣지케이스를 다룬 글에는 외부 개발자 질문이 달렸다. 반면 우리가 공들여 쓴 아키텍처 방향 글은 조용했다.

이 신호는 명확하다. 우리가 "너무 구체적이라서 안 쓰는 게 낫겠다"고 판단한 영역에서 외부 수요가 높다. 결제·정산 도메인은 공개된 구체적 자료가 극히 적다. PG사 공식 문서는 포괄적이고 추상적이며, 개발 블로그 대부분은 사례가 없다. 실제 운영하면서 부딪힌 엣지케이스를 그대로 적은 글이 가장 유용하다. 이걸 확인한 뒤 우리는 의도적으로 "너무 구체적인 것"을 더 쓰기로 방침을 바꿨다. 팀 내부에서만 중요해 보이는 내용이 외부에서는 가장 희귀한 자료가 된다.

101번째부터 바로 써먹을 것들

100편을 쌓으며 정리된 실행 원칙이다. 팀 블로그를 운영하거나 기술 블로그를 시작하려는 사람이라면 그대로 가져가도 된다.

결정의 ADR을 블로그 형태로 써라. Architecture Decision Record를 별도 포맷으로 관리하는 것보다 블로그 글로 쓰는 게 실제로 더 잘 유지된다. 읽힌다는 사실이 관리 동기를 만들기 때문이다. "왜 이렇게 결정했는가"를 묻는 질문이 생길 때마다 블로그 링크로 답하면, 온보딩과 리뷰 코멘트가 모두 단축된다.

결론이 안 나는 회의가 두 번 반복됐다면 글을 먼저 써라. 글을 쓰면 불명확한 전제가 드러난다. 특히 결제·정산처럼 암묵적 가정이 많은 도메인에서는 이 과정이 필수다. 작성자가 스스로 설득되는 것과 읽는 사람이 동의하는 것이 동시에 일어난다.

"너무 구체적인 것"을 더 써라. 우리 경험에서 외부 반응이 가장 좋았던 글은 특정 PG사 엣지케이스나 실제 운영 장애 사례였다. 수치와 맥락이 있는 구체적 경험이 없는 글은 이미 인터넷에 넘친다. 내부에서만 의미 있어 보이는 것이 외부에서는 가장 귀하다.

결론이 안 난 것도 올려라. 정리가 안 된 문제를 올리는 게 불편하다면, 그 불편함이 신호다. "아직 모르겠다"로 끝나는 글이 가끔 가장 정직하고 유용한 글이 된다. 우리가 이미 여러 번 확인했다. 101번째 글도 그 기준으로 쓰인다.