3주 커밋 0에서 재가동: 가장 작은 한 바퀴만 남기고 나머지를 얼렸다

6월 12일에 프로젝트를 스스로 점검했다. 여섯 축이 얼마나 채워졌는지 표로 매겨 보니 결과는 냉정했다.

축	상태	채움
재무	분석·실데이터 있음, 화면은 표뿐	70%
연결	미구현, 장식용 그림	5%
병목	미구현	5%
시간	미구현	5%
서사	미구현	5%
리스크	키워드 개수만 셈	20%

재무만 끝까지 돌았다. 화면의 연결망과 타임라인은 실데이터가 아니라 모양만 그려 둔 고정 그림이었다. “구조를 시각화한다”는 프로젝트가 정작 구조 시각화를 하나도 갖고 있지 않았다.

멈춘 게 아니라 빌드가 멈췄다

더 큰 문제는 그다음이었다. 7월 2일에 다시 들여다보니 마지막 커밋이 6월 11일이었다. 3주 동안 커밋이 0이었고, 마지막 코드 수정도 6월 18일이었다. 그런데 시스템은 6월 27일까지 멀쩡히 돌았다. 일곱 개 종목 분석이 정상적으로 끝났다. 시스템이 죽은 게 아니라 만드는 일이 멈춘 것이다.

그 빈자리를 채운 것은 설계 문서였다. 분석 파이프라인 문서, 병목 파이프라인 설계, 산업 지식 노드 두 개. 커밋하지 않은 파일이 101개 쌓여 있었다.

멈춘 원인 셋: 출하 단위가 사라지고, 범위가 불고, 보상이 기울었다

원인은 세 가지로 모였다.

• 출하 단위가 사라졌다. 다음 할 일이 “텍스트에서 구조를 뽑는 추출기”였는데, 이게 작업 명세가 아니라 비전 문단이었다. 손을 대려 하면 곧바로 설계 질문으로 번졌다.
• 범위가 불었다. 추출기 하나이던 전제가 64개 노드짜리 지식 위키와 다섯 모델 병렬 딥리서치 체계로 자랐다. 전제가 커질수록 첫 줄의 코드는 멀어졌다.
• 보상이 기울어 있었다. 설계 문서와 조직 꾸미기는 스스로 완료를 선언할 수 있다. 코드는 데이터가 실패를 판정한다. 혼자 하는 일에서 작업은 자연히 판정이 너그러운 쪽으로 흘렀다.

이 셋 중 어느 것도 구조의 결함이 아니었다. 전부 일을 정의하는 방식의 결함이었다.

재설계 대신 재가동

그래서 다시 설계하지 않기로 했다. 재설계는 이 프로젝트를 멈추게 한 바로 그 행동, 코드 대신 설계의 가장 큰 버전이기 때문이다.

대신 철학이 참이 되는 가장 작은 한 바퀴를 정했다. 종목을 넣으면 이미 있는 수집, 분류, 재무 분석을 거쳐, 연례 보고서에서 이름이 명시된 고객과 공급사만 뽑는 연결 추출기로 가고, 그걸로 연결망 그래프 한 장을 그려 웹에 올린다. 완료 조건은 품질이 아니라 출력이다. 화면에 그래프가 뜨면 끝이다.

그리고 이 한 바퀴 위에 없는 것은 전부 얼렸다. 스프라이트와 페르소나 같은 사무실 꾸미기는 한 바퀴를 두 번 돈 뒤까지, 지식 위키 새 노드는 병목 분석을 시작할 때까지 멈췄다. 새 설계 문서는 직전 작업이 커밋된 뒤에만 쓰기로 했다.

규칙은 두 개를 더 붙였다. 작업 하나에 커밋 하나. 그리고 매 바퀴의 끝은 남이 볼 수 있는 화면이다. 스스로 완료를 선언하는 대신 공개된 화면이 완료를 증명하게 했다. 며칠 쉬었다 돌아올 때 전체 문서를 다시 읽지 않는다는 규칙도 적었다. 지금 주차의 할 일만 보고 바로 시작한다.

그날 쌓여 있던 파일 101개를 한 번에 커밋했다. 이 커밋은 일회성 사면으로 선언했다. 지난 3주에 선을 긋는 것이지, 앞으로의 커밋 방식이 아니다.

배운 것

혼자 하는 프로젝트는 시작보다 멈춘 뒤 돌아오는 데서 죽는다. 멈춤의 신호는 코드가 안 도는 게 아니라, 코드는 도는데 문서만 늘어나는 것이었다. 설계가 진척을 대신하기 시작하면 설계를 늘리는 게 아니라 줄여야 한다. 한 바퀴를 작게 정하고, 그 바깥은 과감하게 얼리는 것. 3화는 그 한 바퀴가 실제로 돈 이야기다.