jira-agent 4일 작업에서 진짜 병목은 무엇이었나

코드 작성 속도가 아니라 그 위 층 세 군데였다. 스펙을 두 번 고쳐 에이전트들이 함께 다시 움직인 시간, 같은 LLM 풀에서 나온 fail-fast-reviewer가 builder의 사각지대를 그대로 못 잡은 한계, 9개 모듈을 합쳤을 때 기존 테스트 17개가 실패해 사람이 다시 분류해야 했던 통합 단계가 진짜 병목이었다.

다층 검증이 검증을 강화해주지 않는 이유는 무엇인가

fail-fast-reviewer와 module-builder가 같은 LLM 풀에서 나오면 같은 인식 한계를 공유한다. builder가 모르고 넘긴 패턴은 reviewer도 거의 못 잡는다. 5월 19일에 publish 결함 등 7건이 fail-fast-reviewer를 다 통과한 뒤 integration-qa 단계에서 잡힌 것이 단적인 사례다. 다른 모델 풀로 reviewer를 분리해야 검증층이 실제로 한 층 더 깊어진다.

분담을 더 늘리면 이 병목 세 가지가 풀리나

풀리지 않는다. 스펙 수정은 결정 속도 문제고, 검증층 한계는 같은 모델 풀 문제고, 통합 결합은 사람 검토 문제다. 세 가지 모두 역할 분담을 늘려서 풀리는 영역이 아니다. 결정 사이클을 줄이거나 검증 풀을 섞거나 통합 검토 자체를 자동화해야 풀린다.

코드는 빨랐는데 — jira-agent 다섯 에이전트 4일 회고 (구축기 3편)

6월 09, 2026

시리즈 1편에서 jira-agent의 결과(7분 PR)를, 2편에서 그 흐름을 만든 4일 구축 과정을 다뤘다. 4일을 돌아보던 중 r/ClaudeAI에 “Claude를 쓰다 보니 코딩이 병목이 아니었다는 걸 깨달았다”는 글이 올라온 걸 봤다. 읽어 보니 같은 결론에 닿았다.

유료 backend 전환 글을 쓰려다 먼저 정리할 게 보였다. 다섯 개의 에이전트가 동시에 돌아간 4일 동안 코드 작성이 늦어서 시간이 걸린 적은 없다. 늦은 건 따로 있었다.

시간을 따로 측정한 건 아니고 4일을 돌아보며 받은 인상이다. 2편이 사흘 동안 무엇을 만들었는지를 다뤘다면 3편은 그 과정에서 에이전트 분담이 풀지 않은 영역을 짚는다.

다섯 개의 에이전트가 푼 건 코드 작성 속도였고, 그 위 층 세 군데(스펙·검증·통합)가 남은 병목이었다. 검증 영역은 같은 모델 풀이 가진 사각지대라 다른 풀로 분리해야 해소된다.

스펙을 4일 동안 두 번 고쳤다

5월 18일에 architect가 스펙을 처음 작성했다. 결정 12개와 다섯 섹션이었다. module-builder는 이 스펙을 받아 모듈 22개를 같은 날 만들었다. 코드 작성 자체는 막힘이 없었다.

그런데 5월 19일에 운영 중 backend 전환 가능성이 생기면서 LLMBackend 추상화를 추가해야 한다는 게 명확해졌다. 5월 20일에는 다중 파일과 동적 저장소 확장이 더 필요해져 9개 모듈을 새로 만들어야 했다.

코드를 빨리 짜는 능력은 그대로였는데 스펙을 다시 써야 하니 에이전트들이 함께 다시 움직였다. architect가 계획을 다시 세우고, module-builder가 새 모듈을 만들고, integration-qa가 회귀를 다시 돌리는 사이클이 두 번 돌았다. 4일 중 절반이 이 사이클에 들어갔다.

에이전트가 코드를 빨리 짜더라도 스펙이 바뀌면 그 비용을 전체가 같이 치른다. 분담이 코드 작성 속도는 풀어주지만 스펙 결정 속도는 풀어주지 않는다.

fail-fast-reviewer가 못 잡은 결함 7건이 통합에서 나왔다

fail-fast-reviewer는 module-builder가 쓴 코드에서 예외를 삼키거나 빈 분기를 두는 식의 fail-fast 위반을 검증하는 역할이다. 다층 분담이 검증을 자동으로 강화해줄 거라 기대했었다.

실제로는 builder가 모르고 넘긴 패턴을 reviewer도 거의 못 잡았다. 같은 LLM 풀에서 나온 모델이 같은 인식 한계를 공유하는 게 원인이다.

5월 19일에 publish 결함 등 7건이 한꺼번에 드러난 게 이 한계를 단적으로 보여준다. fail-fast-reviewer 단계를 다 통과한 뒤에 integration-qa가 통합 시점에서 잡은 결함들이었다.

검증층을 한 층 더 깐다고 검증이 한 층 더 강화되지는 않는다. 같은 모델 풀에 의존하는 reviewer에도 같은 사각지대가 그대로 남는다.

다른 모델 풀로 reviewer를 분리해야 한다는 게 4일 작업에서 가장 분명하게 남은 숙제다. 유료 backend 전환을 미루기 어렵게 만든 가장 큰 이유이기도 하다.

통합 후 실패한 17개의 기존 테스트

5월 20일에 9개 모듈을 새로 만들고 통합을 돌렸을 때 822개 통과가 805개로 떨어졌다. 신규 테스트 102개를 합치는 과정에서 기존 테스트 17개가 같이 실패했다는 뜻이다.

개별 모듈은 builder 단계에서 다 통과했었다. 모듈 단위 테스트만 보면 회귀 0이었다.

합치는 순간 사람이 다시 들어가 17개를 하나씩 읽고 어떤 게 진짜 결함이고 어떤 게 스펙 변경 때문에 자연스럽게 깨진 건지 갈라야 했다.

integration-qa가 통합 회귀 자체는 잡지만 그 안에서 사람이 결정해야 하는 영역은 그대로 남는다. 결합은 분담의 약점이다. 에이전트들이 만든 결과를 합칠 때 사람이 다시 살펴보고 정리하는 시간이 들었다.

마무리

에이전트 분담이 푼 건 코드 작성 속도였다. 4일 중 코딩 자체로 막힌 시간은 거의 없다. 그 위 층 세 군데(스펙·검증·통합)에서 시간이 다시 들어갔다.

에이전트를 다섯에서 여섯·일곱으로 늘리는 실험은 안 해봤다. 다만 이 분담에서 본 한계는 스펙 결정 속도·같은 모델 풀의 검증 한계·통합 사람 검토 세 군데였다. 이 셋이 분담 늘리기로 풀리는 영역인지는 아직 답이 없다.

다음 글에서 유료 backend 전환을 다룬다. 같은 모델 풀 한계가 유료 backend에서 다른 풀과 섞을 때 풀리는지가 4편 주제다.

한계

회고 3가지가 다른 1인 자동화에도 같을지 모른다. jira-agent 4일 사례에서 본 회고고 다른 사례는 미검증이다.
유료 backend로 검증 풀을 섞었을 때 reviewer 한계가 실제로 풀리는지 아직 안 해봤다. 가설 단계다.
통합 단계 사람 검토 시간을 줄일 자동화 자체가 다음 영역인데 구체 설계는 없다.

참고

시리즈 1편: Jira에 티켓 적고 산책 갔다 왔더니 PR이 만들어져 있었다
시리즈 2편: spec에서 첫 PR까지 — jira-agent 4일 구축 기록
관련: AI 자동화의 진짜 위험은 코드가 아니다

저자 — Jason 황재승

cd4761.blogspot.com에서 개발 자동화와 AI 도구 운영 기록을 쓴다. trend-scout 1년 운영. 8년 차 프론트엔드. 본 시리즈는 jira-agent 구축 기록 4편 중 3편이다.

태그: #jira #개발자동화 #PR자동화 #에이전트구축 #코딩병목 #스펙설계 #검증한계 #통합테스트 #시리즈

이 블로그 검색

AI 도구 매일 노트 — 해고된 개발자의 기록