바보야, AI한테 다 맡기고 루프를 닫으면 어떡해

올해 사내에서 가장 신경 써서 다듬어 온 도구 중 하나는 버그 트리아지다. 버그 트리아지는 버그 신고 채널에 새 제보가 올라오면 🐛 이모지로 트리거되어, 직접 해결을 시도하거나 분석 결과와 해결 방안을 팀원에게 제안해주는 아주 유용한 자동화 워크플로우였다.

분명 처음에는 사용률도 나쁘지 않았고, 결과물도 나쁘지 않았지만 5개월이 지난 지금 이상한 일이 벌어지고 있다. 팀원들이 더 이상 버그 트리아지를 사용하지 않는다 😭

처음에는 버그 트리아지의 속도나 신뢰도 문제로만 보였기에, 하네스를 가다듬으면 다시 회복될 줄 알았다. 그런데 돌아보니 그게 전부는 아니었던 것 같다. 다음에 비슷한 도구를 만들 때 같은 실수를 반복하지 않으려면, 한 번은 정리해두는 게 좋을 것 같아 이 글을 작성해본다.

도구의 시작과 결과

우리 팀에는 단순 UI 이슈부터 시작해 로직 버그, 데이터 정합성 문제, 정책 충돌 등등 하루에도 매일 몇 건씩의 버그 제보가 올라온다.

간단한 이슈는 누구나 쉽게 대응 가능하지만, 구조가 조금이라도 복잡하거나 도메인 정책 간 충돌 혹은 의사결정이 필요한 영역에서는 버그를 추적하고 해결하는 과정에서 많은 사람의 리소스가 사용되었다.

그래서 나는 버그 발생 경로 파악부터 재현, 원인 추적, 해결안 도출까지의 시간을 AI로 단축하고, 팀원들이 빠르게 대응할 수 있도록 도움을 줄 수 있는 도구를 만들고 싶었다.

그렇게 시작한 게 Bug Triage (버그 트리아지) 라는 워크플로우다. 슬랙 채널에 🐛 이모지가 달리면 Slack Workflow가 트리거되고, Github Actions가 호출된다. 그리고 그 안에서 Claude Code가 헤드리스 모드로 돌면서 코드베이스를 탐색하고 트리아지 리포트를 작성한 다음 슬랙 스레드에 코멘트로 결과를 달아주는 흐름이다.

당시에는 실제 코드베이스가 존재하고 에이전트가 작업 후 PR을 올리기 쉬운 환경이 Github Actions라고 생각했기에 그렇게 구성했었다. 처음에는 이렇게 구성된 워크플로우의 결과물이 생각보다 나쁘지 않았다.

1월부터 5월까지의 결과물을 수치화해보면 월별로 20건 이상 버그 트리아지가 호출되고 있었고, 전체 90개의 버그 건 중 버그 트리아지의 효과율이 55.6%(Fixed 20% + Helpful 35.6%)로 기대 이상의 수치를 달성했다.

4월까지만 보더라도 성공적인 수치처럼 보인다. 그런데 이상하게도 50% 이상의 타율을 가진 버그 트리아지의 호출이 5월이 되어서 크게 줄어들기 시작했다.

사라진 호출

같은 기간 버그의 수 자체가 줄어든 건 아니었다. 그저 사람들이 버그 트리아지 호출 없이 버그에 대응하고 있었을 뿐이었다.

왜 그랬는지 곰곰이 생각해보니 신뢰도가 깨진 패턴이 있었다. 트리아지가 제안한 해결 방안이 실제 해결 방법과 다른 경우가 종종 있었고, 10~20분을 기다렸는데 결정타가 없는 경우도 있었다. 그러다 보니 자연스럽게 버그 트리아지를 경험한 사람의 입장에서는 "그냥 직접 해야겠다"가 되고 다시 호출하지 않게 되는 것 같았다.

사실 나부터가 그랬던 것 같다. 어느 순간부터 트리아지 봇의 응답을 기다리는 대신 슬랙 링크를 Claude Code에 던지고 직접 대화하기 시작했다. 그게 빨랐고, 결과도 더 좋았다. 다른 사람들도 대부분 비슷했다. 슬랙 버그 제보 링크를 복사해서 로컬 Claude Code나 Codex에 컨텍스트로 주입한 다음, 거기서 대화로 풀어내고 있었다. 내가 만든 도구를 정작 내가 안 쓰고 있다는 사실이 좀 멋쩍긴 했지만, 시대의 변화에 맞춰 우리가 AI를 다루는 방식도 빠르게 바뀌고 있는 것 같았다.

처음 팀원들에게 피드백을 받았을 때는 트리아지가 가져오는 맥락이나 도구가 부족하다고만 생각했다. 그래서 Sentry MCP를 연동해 로그도 같이 볼 수 있게 했고, Runbook 레포를 만들어 정책과 운영 지식을 모았다. 더 많은 도구가 생겼고, 더 많은 것을 할 수 있게 되었지만 그럼에도 호출은 계속해서 줄어들었다.

이쯤 되니까 지금까지 받았던 피드백들은 표면적인 내용이었고, 본질은 닫힌 루프의 한계였다는 사실을 알게 되었다.

닫힌 루프의 한계

내가 만든 워크플로우는 버그 신고 채널에 제보가 올라오면 🐛 이모지가 부착되고, 에이전트가 호출되어 버그 제보 내용을 이해하고 분석하여 해결하는 철저히 단방향으로만 흐르는 닫힌 루프다.

단방향 흐름에서 오는 문제가 정확하게 이 지점에서 발생했다.

• 버그 제보에 잘못 기입된 내용이 존재한다면?
• 만약 현재 버그와 전혀 관련 없는 모듈을 분석하고 있었다면?
• 이 버그를 해결하기 위해 필요한 정책이 주입되어야 한다면?

대부분의 루프에서는 AI와의 대화를 통해 요구사항을 좁히고, 의도와 다르게 어긋나면 Steering이나 Follow-up 메시지로 방향을 다시 잡기 마련이다. 그런데 닫힌 루프는 그런 사이클 자체를 허용하지 않았다. 위와 같이 인간의 개입이 필요한 영역이 오더라도, 개입할 수 없기에 에이전트가 스스로 판단하고 결과를 내야 했다.

특히 해결하기 어려운 버그에서 또 다른 문제가 있었는데, 닫힌 루프 안의 AI는 한 모듈에 대해 가설을 세우고 관심 영역을 한 번 좁히고 나면, 그 영역에서만 깊게 탐색할 뿐이다. 그 외 영역으로 시선을 돌려 탐구하려는 Self-guidance가 부족했다.

그러다 보니 외부에서 도울 수 있는 일이 사라졌다. Sentry를 붙이고, Runbook을 모으고, 프롬프트를 더 다듬어도 그건 결국 AI가 판단을 내리기 전에 줄 수 있는 도움일 뿐이었다. 막상 AI가 가설을 좁히고 한 영역에 들어간 뒤로는 그 안에서 답이 안 나와도 다른 곳을 한 번 보라고 말해줄 방법이 없었다.

그러니까 결국 닫힌 루프의 한계는 인터페이스의 한계였던 셈이었다.

마치며

이 회고가 닫힌 루프는 무조건 틀렸다고 말하려는 건 아니다. 분명히 도움이 됐고, 자동으로 PR까지 만들어준 사례도 있었다. 다만 어떤 종류의 문제에 어떤 인터페이스가 어울리는지는 5개월 전보다 훨씬 또렷해진 것 같다.

AI에게 모든 걸 위임하고 한 번에 답을 받는 자동화는 분명 매력적이다. 그런데 사람이 중간에 개입해 가설을 의심하거나 방향을 다시 잡아줘야 풀리는 문제에는 잘 맞지 않았다. 버그는 안타깝게도 대부분 그런 종류였다.

다음에도 비슷한 도구를 만들게 된다면, AI에게 모든 걸 위임하기보다 사람이 중간에 끼어들 수 있는 자리를 먼저 설계할 것 같다. 결과가 빗나갔을 때 방향을 다시 잡아줄 사이클이 있는지, AI가 가설을 좁힌 뒤에도 외부에서 도와줄 방법이 있는지를 먼저 묻게 될 것 같다. 결국 인터페이스가 도구의 한계를 결정한다는 게 5개월간의 가장 큰 배움이었다.

이 바보야, AI한테 다 맡기고 루프를 닫으면 어떡해!