솔직히 말해 저는 AI가 코드를 짠다는 것에 거부감이 심했습니다. 코드는 자산이 아니라 관리해야 할 부채인데, 그 부채를 기계가 초고속으로 찍어낸다니 끔찍했으니까요. 하지만 시대의 흐름을 거스를 순 없더군요. 팀 생산성을 위해 Cursor와 같은 도구를 도입했고, 실험적으로 AI 에이전트에게 CI 에러 수정과 리뷰 반영을 맡겨보았습니다.
그날은 유독 피곤한 금요일 오후였습니다. AI 에이전트에게 "CodeRabbit 리뷰 반영하고 CI 통과하면 머지해줘"라고 지시한 뒤 잠깐 눈을 붙였죠. 그게 화근이었습니다.
30분 뒤, 슬랙 알람이 미친 듯이 울렸습니다. 장애였습니다. 원인은 간단했습니다. AI 에이전트가 중요하지 않은 '칭찬'성 리뷰 코멘트를 '해결해야 할 이슈'로 착각해 엉뚱한 코드를 수정했고, CI가 돌고 있는 도중에(Pending) "수정 완료"라고 판단해 강제로 머지 버튼을 눌러버린 겁니다.
운영 서버를 롤백하고 식은땀을 닦으며 뼈저리게 느꼈습니다. AI는 코드를 짤 줄은 알지만, '언제 일이 끝났는지'는 전혀 모른다는 사실을요.
이 문제는 저만 겪는 게 아니었습니다. AI 에이전트에게 작업을 시키면 가장 흔하게 발생하는 패턴이 두 가지 있습니다. 첫째는 무한 폴링(Infinite Polling)입니다. "CI 끝났니?"라고 10초마다 물어보며 아까운 API 토큰을 태워버립니다. 둘째는 성급한 종료입니다. 리뷰어가 "이 변수명은 고민해 보세요"라고 쓴 제안(Suggestion)을 차단(Blocking) 이슈로 오해해 엉뚱한 대답을 하거나, 반대로 치명적인 지적을 단순 정보로 넘겨버리고 작업을 끝냅니다.
이런 멍청한 상황을 해결할 방법을 찾다가, 꽤 흥미로운 도구를 하나 발견했습니다. 이름부터 직관적인 'Good To Go(gtg)'입니다.
이 도구의 철학은 제가 지향하는 '방어적 코딩'과 정확히 일치합니다. 모호함을 배제하고 결정적(Deterministic)인 상태만을 반환합니다. AI가 "음, 이 정도면 된 것 같아요"라고 추측하게 두는 게 아니라, 기계적으로 "된다/안 된다"를 판별해주는 겁니다.
Good To Go는 크게 세 가지 기준을 엄격하게 검사합니다.
첫째, CI 상태의 통합입니다. GitHub Actions나 Jenkins가 여러 개 돌고 있을 때, 하나라도 실패하거나 진행 중이면 절대 'READY' 사인을 주지 않습니다. AI가 "대충 통과하겠지"라고 넘겨짚는 걸 원천 봉쇄합니다.
둘째, 지능적인 코멘트 분류입니다. 이게 물건입니다. CodeRabbit이나 Claude 같은 자동화 리뷰어가 남긴 코멘트를 분석해서, 이것이 반드시 고쳐야 할 'ACTIONABLE'인지, 무시해도 되는 'NON_ACTIONABLE'인지, 아니면 사람의 판단이 필요한 'AMBIGUOUS'인지를 구분합니다. "Good job!"이라는 코멘트 때문에 AI가 코드를 수정하려 드는 촌극을 막아줍니다.
셋째, 스레드 해결 추적입니다. 깃허브 상에서는 'Unresolved'로 떠 있지만, 실제 커밋 내역을 보면 이미 수정된 경우들이 있습니다. 이 도구는 그런 맥락까지 파악해 불필요한 수정을 방지합니다.
사용법은 허무할 정도로 간단합니다. 터미널에 gtg <PR 번호>를 입력하면 끝입니다. 결과는 READY, ACTION_REQUIRED, CI_FAILING 같은 명확한 상태 값으로 떨어집니다. AI 에이전트가 이 JSON 출력을 파싱해서 행동하게 하면, 더 이상 토큰을 낭비하며 CI 창을 들락거릴 필요가 없습니다.
저는 이 도구를 CI 파이프라인의 문지기(Gatekeeper)로 세웠습니다. gtg가 'READY'를 뱉지 않으면, 그 어떤 에이전트도, 심지어 사람도 머지할 수 없게 말이죠.
기술은 화려한 생성 능력에만 있는 게 아닙니다. 진짜 기술은 '언제 멈춰야 할지'를 아는 절제력에 있습니다. AI에게 코딩을 시키는 건 주니어 개발자에게 일을 맡기는 것과 같습니다. 그들이 사고 치지 않게 막는 건 결국 시니어의 몫이고, 그 수단은 모호한 격려가 아니라 명확한 '시스템'이어야 합니다.
여러분의 AI 에이전트는 지금 어디서 헤매고 있나요? 혹시 칭찬 댓글을 버그 리포트로 착각해 밤새 코드를 고치고 있지는 않은지, 한번 들여다보시길 바랍니다.
