주식앱을 만들면서 개발 자동화에 꽤 진심이었다. 구현하는 에이전트랑 검증하는 에이전트를 나누고, 둘이 알아서 주고받게 하고, 문서로 컨텍스트를 넘기고, 워크트리를 여러 개 띄워서 병렬로 돌렸다. 깔린 가정은 단순했다. 사람이 덜 끼면 빨라진다.
결과만 먼저 말하면, 다섯 군데에서 데였다. 대부분 AI가 못해서가 아니라, 내가 도구를 다룰 줄 몰라서 자초한 거였다. 그리고 이 다섯 번의 데임이, 다음 프로젝트에서 일하는 순서를 통째로 바꿨다.
1. 구현과 검증을 갈랐는데, 그게 잘못이었다
검증이 오래 걸린다고 느껴서 구현하고 검증을 갈랐다. 발산(의견 교환·우선순위)은 메인 세션이, 수렴(코드 변경·테스트)은 백그라운드 세션이 맡게. 한 세션에서 두 모드를 섞으면 컨텍스트가 오염되니까. 거기서 한 발 더 나가서, Worker가 작업을 끝내고 발행하는 순간 hook이 Tester 세션을 백그라운드로 자동으로 띄우게 만들었다. 매번 “테스터야” 하고 부르지 않아도 다음 사이클이 굴러가게.
지금 보면 이건 내가 잘못 짚은 거였다. 구현과 검증은 원래 한 사이클이다. 한 호흡에 짜고, 돌려보고, 고치는 게 한 덩어리인데 그걸 억지로 둘로 갈라놨다. 가르는 순간 “둘을 다시 잇는 일”이 새로 생겼고, 자동으로 연결하겠다고 매달릴수록 그 연결 자체가 더 번거로워졌다.
게다가 e2e는 자동으로 안 돌렸다. 토큰이 비싸서. 그래서 화면이 실제로 도는지는 결국 내가 눈으로 한 번은 봐야 했다. 검증을 떼어낼수록 그 “눈으로 보는 차례”를 기다리는 시간만 길어졌다. 나누는 게 답이 아니었다.
2. 문서가 컨텍스트인데, 그 문서가 자꾸 어긋났다
Claude 세션은 세션 간 메모리가 없다. 한 세션의 결정과 발견은 파일로 옮기지 않으면 다음 세션에서 그냥 사라진다. 그래서 파일이 세션 간 상태 전달자, 그러니까 state carrier 역할을 했다.
이걸 지키려고 의례를 세 개 정해뒀다. 결정이 나면 즉시 정책이나 task 문서에 적기, Phase 하나 끝나면 구현 결과를 task에 누적하기, plan 모드 산출물을 task로 옮겨 적기. 이 셋 중 하나라도 빠지면 세션 간 인계가 깨졌다. 문제는 작업하다 보면 그게 누락된다는 거였다. 스킬이라는 개념이 없던 때라 문서 최신화는 매번 손으로 시켰고, 손으로 하니 빠졌다.
더 답답했던 건 따로 있었다. 인덱스도 만들고 구조도 잡아놨는데 정작 에이전트가 그 문서를 잘 참조하지 못했다. Gemini는 @로 폴더를 직접 짚어주지 않으면 경로를 아예 몰랐다. 구조가 깊어질수록(docs/tasks/<도메인>/, docs/process/feeds/<역할>.feed.md, 자동 생성 인박스까지) 못 찾았고, 인덱스가 최신이 아니면 찾아도 안 믿었다. 원인은 둘이었다. 인덱스 현행화 실패, 그리고 너무 깊은 문서 구조.
3. 4~5개씩 동시에 돌리니 머지가 지옥이었다
백그라운드 세션은 워크트리를 따로 쓰는 게 정석이었다. 한 워크트리에 한 세션, 한 task. 한 디렉토리에서 두 세션을 돌리면 git 상태가 race를 일으켰으니까.
그런데 나는 에이전트 뷰에 4~5개씩 띄워놓고 눈에 보이는 대로 돌렸다. 거기다 1번에서 말한 것처럼 구현이랑 테스트까지 다 끊어놨으니, 한 화면에 굴러가는 세션이 더 늘었다. 계획 없이 건바이건으로 던지다 보니 같은 데를 여러 에이전트가 건드렸고, dev 머지는 직렬로만 안전한데 병렬로 자꾸 쌓이니 병합에서 시간을 까먹었다. 한마디로 정신없었다.
결국 둔 규칙이 단일 작성자였다. docs/todo랑 로그는 드라이버(메인 세션)만 갱신하고, 검증 에이전트는 파일을 직접 안 건드리고 결과만 보고하게. 그제서야 충돌이 0이 됐다. 병렬은 공짜가 아니었다. 의존관계를 먼저 끊어놔야 병렬이 이득이 됐다.
4. 마무리는 AI가 못 했다, 주식이라 더
주식은 마무리가 무겁다. 포폴별 손익이랑 수익을 맞춰야 하고, 계좌를 동기화해야 하고, 앱 밖에서 낸 주문까지 끌어와서 맞춰야 한다. 신경 쓸 게 한둘이 아니다.
특히 계산이 문제였다. 한 번에 맞은 계산이 하나도 없었다. 손익이든 수익이든 평가금액이든, 처음 뽑은 숫자는 늘 어딘가 틀렸다. 에이전트는 정책·계약·스키마 판단이 필요해지면 멈추게 해뒀으니, 계산 기준이 애매한 채로는 더 못 나갔다.
결국 내가 docs/product/policy/ 밑에 정책 문서를 못박고 나서야 숫자가 맞기 시작했다. 원가 기준, 주문 방식, 계좌, 종목 같은 걸 “결정: 무엇. 사유: 한 줄” 형식으로 적었다. 기준이 정해진 마무리는 AI가 했다. 기준 자체를 만드는 마무리가 내 몫이었다.
그래서 다음엔 순서를 깔고 시작했다
이 다섯을 정리해서, 다음 프로젝트(위키)에선 순서를 강제했다.
먼저 주요 기능 퍼블리싱 화면이랑 요구사항 파일부터 있어야 한다. 그다음 docs-init으로 문서 구조를 미리, 빡세지 않게 잡는다(로그랑 인덱스는 각각 파일 하나로). 그다음 docs-spec으로 기준 문서를 만든다. 요구사항, 화면 피처, 백엔드 API 정책, 기술 스택. 무엇을 왜까지만 정하고 어떻게는 안 정한다. 마지막에 build-plan으로 todo를 짠다. 한 세션에서 처리할 작업량 기준으로, 작업 단위 의존관계를 표시하고, 병렬 가능한 건 병렬로, auto랑 plan 모드를 구분해서.
신기하게도 데인 자리가 그대로 순서가 됐다. 1번이랑 3번(한 호흡인 일을 억지로 쪼갠 것)은 build-plan으로 들어갔다. 어디서 끊고 어디서 안 끊을지, 의존관계랑 병렬을 미리 정하는 일. 2번(문서가 어긋난 것)은 docs-init으로, 구조를 얕게. 4번(마무리가 안 된 것)은 docs-spec으로, 기준부터.
효과는 분명했다. 정신없는 게 사라졌다. 지금은 다른 세션에서 노가리 까면서 개발하는 수준이다. 아직 마무리 단계가 아니라서 그런 것도 있겠지만, 그래도 첨보단 훨씬 낫다.
자동화 자체가 문제는 아니었다. 원래 한 호흡인 일을 잘게 갈라놓고, 그걸 자동화로 도로 잇겠다고 매달린 게 문제였지.