코드는 빨랐는데 — jira-agent 다섯 에이전트 4일 회고 (구축기 3편)
시리즈 1편에서 jira-agent의 결과(7분 PR)를, 2편에서 그 흐름을 만든 4일 구축 과정을 다뤘다. 4일을 돌아보던 중 r/ClaudeAI에 “Claude를 쓰다 보니 코딩이 병목이 아니었다는 걸 깨달았다”는 글이 올라온 걸 봤다. 읽어 보니 같은 결론에 닿았다. 유료 backend 전환 글을 쓰려다 먼저 정리할 게 보였다. 다섯 개의 에이전트가 동시에 돌아간 4일 동안 코드 작성이 늦어서 시간이 걸린 적은 없다. 늦은 건 따로 있었다. 시간을 따로 측정한 건 아니고 4일을 돌아보며 받은 인상이다. 2편이 사흘 동안 무엇을 만들었는지를 다뤘다면 3편은 그 과정에서 에이전트 분담이 풀지 않은 영역을 짚는다. 다섯 개의 에이전트가 푼 건 코드 작성 속도였고, 그 위 층 세 군데(스펙·검증·통합)가 남은 병목이었다. 검증 영역은 같은 모델 풀이 가진 사각지대라 다른 풀로 분리해야 해소된다. 추천 독자 1편·2편을 보고 “에이전트 분담만 잘 짜면 빠른가” 궁금한 사람 코딩 자동화 도구를 쓰면서 코드 작성 속도는 늘었는데 결과 시간이 안 줄어 답답한 사람 AI 에이전트 다층 검증이 검증을 강화해주는지 의심이 드는 사람 한 줄로 요약하면, 코드 작성은 에이전트들이 빠르게 풀었고 스펙·검증·통합 세 군데에서 시간이 다시 들어갔다 . 스펙을 4일 동안 두 번 고쳤다 5월 18일에 architect가 스펙을 처음 작성했다. 결정 12개와 다섯 섹션이었다. module-builder는 이 스펙을 받아 모듈 22개를 같은 날 만들었다. 코드 작성 자체는 막힘이 없었다. 그런데 5월 19일에 운영 중 backend 전환 가능성이 생기면서 LLMBackend 추상화를 추가해야 한다는 게 명확해졌다. 5월 20일에는 다중 파일과 동적 저장소 확장이 더 필요해져 9개 모듈을 새로 만들어야 했다. 코드를 빨리 짜는 능력은 그대로였는데 스펙을 다시 써야 하니 에이전트들이 함께 다시 움직였다. architect가 계획을 다시 세우고, module-buil...
