요구·화면만 잡고 dispatch로 밀어 올린 뒤, 중간 리뷰 없이 비대해진 프로젝트의 비용
B1부터 B16까지가 며칠 만에 돌아갔다. E·R·G 시리즈는 /goal이랑 dispatch 무인 루프로 green이 됐다. 결과물은 돌아가는데, 손으로 한 줄씩 쌓은 느낌이 안 났다.
시점은 대략 지난주 무렵이다. 날짜를 달력에 찍어 두진 않았다. 그 기간 second 위키를 손보느라 시간이 많이 갔고, 마이위키는 요구사항과 화면 구성까지 잡아 둔 뒤로는 거의 확인 없이 무인으로만 밀어 올렸다. 완성됐다는 말이 나온 뒤에야 제대로 열어봤다.
고칠 게 너무 많았다.
green인데 손이 안 감
무인으로 쌓인 코드는 테스트가 통과해도 “내 코드” 체감이 얇다. 2026-07-04 myWiki 세션에서 그 이야기를 그대로 했다. 재작성 욕구의 상당 부분은 사실 이해하고 싶다는 쪽이라고.
문제는 이해하려는 타이밍이 늦었다는 거였다. 이미 프로젝트가 비대해져 있었다. 중간에 요구사항도 바뀌었고, 바꾸려면 시간이 오래 걸렸다. 한 줄 수정이 한 줄 수정이 아니었다.
그래서 실제 코딩 시간보다 리뷰랑 요구사항 재정렬에 시간이 갔다. 위키 쪽 손질도 같이 쌓여 있었고, 들고 있어야 할 컨텍스트가 커져서 손이 안 가는 구간이 있었다. 구현이 안 되는 게 아니라, 어디부터 손댈지 정리가 안 되는 쪽이었다.
예전에 큰 작업을 구간으로 나누는 이야기를 쓸 때, 한 번에 다 맡기면 생기는 문제 세 가지를 적었다. 컨텍스트 한계, 오류 상속, 사람이 끼어들 지점이 사라지는 것. 그중 세 번째를 내가 스스로 건드린 셈이다. 다 끝나고 나서야 “이건 내가 원한 게 아닌데”를 발견하는 패턴.
무인의 병목은 생성 속도가 아니었다
dispatch로 밀어 올리면 생성은 빠르다. green도 빨리 나온다. 그런데 중간 확인이 없으면, 틀린 가정 위에 다음 기능이 쌓인다. 앞 단계에서 조금 틀어져도 그 위에 올린 게 전부 그 오류를 물려받는다. 빌드플랜 글에서도 계약 레이어가 잘못된 상태로 구현으로 흘러가면 고치는 비용이 처음부터 다시 하는 것보다 클 수 있다고 썼다. 이번에는 그게 제품 규모로 왔다.
요구가 유동적인 상태에서는 더하다. 세션마다 컨텍스트를 다시 깔아야 하고, 문서 여러 곳에 같은 사실이 중복으로 쌓이면 읽는 비용도 커진다. myWiki 세션에서 “조사한 컨텍스트를 재사용 못 하고 계속 재조사하는 느낌”이라고 했던 그 감각이, 리뷰 대기 상태가 길 때랑 같은 축이다. 1을 쓰기 위해 100을 읽는 물리랑도 맞닿아 있다.
리뷰가 밀린 상태를 게으름으로 읽지 않기로 했다. 들고 있는 상태가 이미 한계라는 신호에 가깝다. 그때는 구현을 더 넣는 게 아니라, 중간 조정 게이트를 넣는 쪽이 맞다.
중간 확인을 게이트로
무인 완주 자체를 버리자는 말은 아니다. 요구랑 화면까지 잡고 auto로 쳐내는 흐름은 여전히 쓸 만하다. 다만 구간 경계마다 사람이 한 번 보는 자리가 없으면, 나중에 고치는 비용이 처음에 만드는 비용보다 커진다.
위키 쪽 정비도 아직 끝나지 않았다. 손질을 꽤 넣었는데도 구조 자체를 다시 짜야 할 수 있겠다는 생각이 든다. 그건 별 이야기고, 이 글에서 가져갈 건 하나다. 중간 리뷰와 중간 조정이 없으면 무인 완주는 부채로 돌아온다.
결국 병목은 모델이 느린 게 아니었다. 확인 없이 커진 코드베이스를 나중에 손으로 되감는 쪽이었다.