지난 기사에서는 GitHub Issue를 작성하면 AI가 구현·리뷰·수정하여 PR을 보내오는 자동 개발 루프를 소개했습니다. 실측치도 제시했습니다. "약 7할의 Issue는 무인으로 완주한다", "머지(Merge)까지 이어진 Issue는 루프 횟수의 중앙값이 2, 꼬여버린 Issue는 중앙값이 8.5". 이번에는 그 후속편으로 — 왜, 어떻게 Issue는 꼬이는가를 기록과 데이터를 통해 파헤쳐 봅니다.

제목의 "38회"는 실제로 존재했던 한 Issue에서 기록된 페이즈(Phase) 실행 횟수의 합계입니다. 다만 이는 후술할 "루프(Loop)"의 정의에 따른 왕복 횟수는 아닙니다. 어떤 숫자를 센 것인지는 케이스 스터디 1에서 해부하겠습니다.

전제: 수정 루프와 캡(Cap)의 메커니즘

지난 내용을 한 단락으로 요약합니다. 루프의 실체는 다음과 같습니다. AI(Claude Code)가 구현하고, 다른 AI(Codex)가 리뷰합니다. 차단(Blocking)되는 지적이 나오면 자동으로 수정 모드로 되돌아갑니다. 이 "구현 → 리뷰"의 왕복을 1 루프로 계산합니다. 제어 장치는 연속 5회 — 이 횟수에 도달하면 캡(Cap)에 걸려 인간에게 에스컬레이션(Escalation)됩니다. 인간 측은 카운터를 리셋하여 재개할 수도 있고, 수동으로 개입할 수도 있습니다.

인간에 의한 리셋은 캡 도달 → 인간이 리셋 → 다시 도달하는 과정을 몇 번이고 반복할 수 있습니다. 제목의 "38"은 그 반복 과정 속에서 기록에 남은 실행 횟수의 합계입니다. 구현 → 리뷰의 왕복 수 그 자체가 아니라는 점을 포함하여, 세부 내역은 케이스 스터디 1에서 설명하겠습니다.

캡에 몇 번 도달했을 때 포기해야 하는가

먼저 전체 데이터입니다. 종료된(Closed) Issue에 대해, 캡 도달 횟수별 PR 머지(Merge)율을 집계했습니다.

집계 전의 가설은 "두 번째 캡에 도달하면 거의 회수 불가능할 것이다"였습니다. 이 가설은 틀렸습니다. 실제로는 절벽이 아니라 경사였으며, 캡 3회 이상이라도 인간이 리셋하며 버티면 절반 이상은 머지까지 도달합니다.

그렇다고 해서 95% → 55%까지 떨어지는 것도 사실입니다. 이 추이를 통해 "1~2회의 리셋은 정상 범위. 3회째에 접어들면 버티기보다 Issue를 나누는 방식을 의심하라"가 실용적인 기준이라고 할 수 있습니다.

케이스 스터디 1: "38"의 해부(#498)

꼬여버린 실례로서, 최다 기록을 세운 Issue를 살펴보겠습니다. 내용은 "semantic conflict의 문맥을 conflict-resolution 프롬프트에 전달하기" — 즉, 머지 컨플릭트(Merge Conflict) 대응을 똑똑하게 만들기 위한 Issue였습니다. 후술하듯, 이 Issue 자체가 최종적으로 컨플릭트와 관련되어 난항을 겪게 됩니다.

이벤트 로그를 요약하면 다음과 같습니다(시각은 일부 반올림함):

7/3 15:16 최초 구현 → PR 생성
15:31~ 리뷰 지적 → 수정 → 재리뷰,를 약 10분 간격으로 핑퐁
16:50 캡 1회차(5/5) → 인간에게 전달
...

최종적으로 캡 통산 6회. 이 사이에 실행된 페이즈 실행 횟수는 구현 18회·리뷰 19회·컨플릭트 해결 1회의 합계 38회였습니다(전제에서 정의한 "구현 → 리뷰의 왕복" 1 루프와는 계산 방식이 다릅니다). 컨플릭트 대응을 개선하기 위한 Issue 자체가, 컨플릭트 해결 시의 검증 실패로 인해 머지되지 못한 채 종료되었습니다.

이 38회의 내용을 보면, "AI의 구현력 부족으로 같은 곳을 고치지 못하는 것"이 아님을 알 수 있습니다. 골(Goal) 자체가 계속 움직이고 있었던 것입니다. 리뷰할 때마다 지적의 각도가 바뀝니다. 수정 중에 main 브랜치가 진행되어 전제가 어긋납니다. 도중에 환경 요인(dirty tree, 허가되지 않은 명령어)에 의한 사고까지 끼어듭니다. 다가가면 튕겨 나가는 것을 반복한 끝에, 마지막에는 본 주제 그 자체(컨플릭트)에 발이 묶였습니다.

에이전트 루프의 패턴 모음인 loop-engineering의 Failure Mode Catalog에서는, 동일한 PR에 자동 수정이 5회 이상 실행되어도 수렴하지 않는 증상을 Infinite Fix Loop로 정의하고 있습니다.

케이스 스터디 2: 4연패한 Issue 군을 잘게 나누었더니 9승을 거두다

Issue마다 독립된 git worktree에서 구현을 실행한다 — 이러한 기반 변경을 4개의 Issue(#441~#445)로 진행하려 한 적이 있습니다. 결과는 4연패였습니다. 각각 5~12 루프를 소비했지만, 어느 것도 머지(Merge)에 이르지 못했습니다. 구현 페이즈(Implementation Phase), 리뷰 페이즈(Review Phase), 클린업(Cleanup), 권한 조작이 얽힌 변경으로, 하나의 Issue가 제어 흐름(Control Flow) 전체를 건드리는 구조였던 것이 원인이었습니다.

그래서 방침을 바꾸어, 실패한 4개의 Issue를 10개의 작은 Issue로 다시 나누었습니다. 첫 번째 것은 제목부터가 「Split #441: minimal implementation worktree execution」 — 원본 Issue의 최소 슬라이스(Slice)입니다. 하나의 Issue가 바꾸는 것은 단 하나의 동작뿐이며, 기존의 동작은 바꾸지 않고, 이전 Issue 위에 쌓아 올린다는 방식으로 나누었습니다.

결과는 10개 중 9개 머지 성공. 동일한 기능, 동일한 AI, 동일한 루프에서 Issue를 나누는 방식만 바꿨더니 통과했습니다. 지난 기사에서 "Issue의 질이 구현의 질을 거의 결정한다"라고 썼지만, 질이란 작성 방식뿐만 아니라 **사이즈(Size)**를 의미하기도 합니다. 꼬여버린 Issue에 대한 대응은, 분할하여 스코프(Scope)를 축소하는 것이었습니다.

꼬여버린 Issue를 분류하니 4가지 패턴이었다

머지되지 못하고 끝난 Issue(24건)를 전부 다시 살펴보고 분류하니, 깔끔하게 4가지로 나뉘었습니다.

나머지는 단발적인 사고(환경 요인 등)입니다. 이번에 확인한 사례에서 공통적으로 나타난 것은, 어떤 유형도 "AI의 구현 능력" 문제는 아니었다는 점입니다. 목표의 정의가 가변적·모호·너무 크다는 Issue 측의 성질이 루프를 공전시키고 있었습니다. 반대로, 목표가 고정되어 있고 검증을 테스트로 작성할 수 있는 Issue는, 지난번에 썼듯이 중앙값 2 루프 내에 담담하게 통과합니다.

Issue를 작성하는 시점에서 할 수 있는 것

이 데이터를 바탕으로 제가 실제로 운영 방식을 바꾼 점입니다.

• 기반·제어 흐름을 가로지르는 변경은 처음부터 분할한다. "1 Issue = 하나의 동작 변경" 수준까지 잘게 나눈다. 나누는 방법이 고민될 정도로 크다면, 먼저 "사양을 확정하는 Issue"를 먼저 세운다.
• "판정의 타당성"이 결과물인 태스크는 자동 리뷰 루프에 태우지 않는다. AI 리뷰는 기준이 없는 대상에 대해 무한히 개선점을 생성할 수 있다. 이런 종류의 태스크는 인간의 리뷰 게이트(Review Gate)로 직행시킨다.
• 캡(Cap)은 기울기(Gradient)로 취급한다. 1~2회의 리셋은 정상 운전 범위다. 3회차에 접어들면 리셋을 연타할 것이 아니라 Issue를 다시 나누는 것을 검토한다.

"Issue에 적히지 않은 의도는 AI의 자신만만한 추측으로 채워진다" — 이 문제를 Addy Osmani는 Intent Debt(의도 부채)라고 부릅니다. 이번 4가지 유형 중 적어도 설계 판단 계열과 캘리브레이션 계열은 이 부채가 표면화된 것이라고 할 수 있습니다.

마치며

꼬임의 주된 원인이 Issue 측에 있다는 것은, 뒤집어 말하면 루프 본체를 건드리지 않고도 성적을 올릴 수 있다는 뜻이기도 합니다. 한편으로 루프 측의 개선 여지도 명확하여, 리뷰에 Issue 본문을 전달해 "요구를 충족했는가"를 확인하게 하거나, 캡에 도달했을 때 분할을 제안하게 하는 것 등이 다음 단계라고 생각합니다. 이 부분은 나중에 별도의 기사로 쓸지도 모르겠습니다.

질문이나 지적은 환영합니다.

본 기사의 집계 및 이벤트 로그 조사는 AI에게 지시하여 수행했습니다. 숫자는 2026년 7월 시점·기록에서 확인할 수 있는 범위 내의 것입니다.

Discussion