배경 코딩 에이전트의 신뢰성을 만드는 피드백 루프 (Honk Part 3)

Spotify의 배경 코딩 에이전트 Honk 시리즈 3편으로, 에이전트가 만든 PR의 신뢰성을 검증 루프로 확보하는 방법을 다룬다. 특히 CI를 통과하지만 기능적으로 틀린 PR이 가장 위험하며 이를 막는 검증기와 LLM 심사관 구조가 핵심이다.

핵심 포인트

실패는 PR 생성 실패와 CI 실패 PR, CI를 통과하지만 기능이 틀린 PR 세 가지이며 마지막이 수천 컴포넌트에서 검토로 잡기 어려워 프로덕션 장애를 부를 수 있다.
검증기를 MCP 도구로 노출하고 컴포넌트 내용에 따라 자동 활성화해 pom.xml이 있으면 Maven 검증기가 포맷과 빌드와 테스트를 돌린다.
LLM 심사관이 diff와 원본 프롬프트를 비교해 범위를 벗어난 변경을 걸러내며 수천 세션 중 약 25%를 거부하고 거부된 것의 절반은 에이전트가 스스로 궤도를 수정한다.
검증기는 노이즈를 요약해 에이전트의 컨텍스트 윈도우를 아껴준다.

상세 정리

문제 정의: PR 생성 실패는 경미하고 CI 실패는 리뷰 부담을 주지만 CI를 통과하는 기능 오류 PR이 가장 위험하다.
근본 원인: 테스트 커버리지 부족과 에이전트의 과도한 창의성으로 인한 범위 밖 변경, 빌드와 테스트 실행 실패가 겹친다.
검증 루프 원리: 에이전트는 검증기가 뭘 하는지 몰라도 호출만 하며 검증기는 컴포넌트 파일에 따라 자동 활성화된다.
검증기 구현: MCP 도구로 노출하고 정규식으로 관련 에러만 추출해 성공 시 짧은 메시지를 주며 Claude Code의 stop hook으로 PR 개설 전 관련 검증기를 모두 돌린다.
LLM 심사관: 다른 검증기가 끝난 뒤 diff와 원본 프롬프트를 시스템 프롬프트로 평가해 프롬프트 지침 위반을 잡는다.
심사관 성능: 수천 세션 중 약 4분의 1을 거부하고 거부되면 절반은 에이전트가 스스로 고치며 가장 흔한 거부 사유는 프롬프트 지침 위반이다.
에이전트 범위 제한: 에이전트는 프롬프트를 받아 코드 변경만 하도록 설계되고 편집 도구와 검증기만 쓰며 프롬프트 작성과 푸시와 Slack 연동은 외부 인프라가 맡는다.
보안: 컨테이너 샌드박스와 제한 권한과 최소 바이너리로 격리한다.
한계: 검증기는 Linux x86만 지원해 백엔드와 웹만 커버하고 iOS는 macOS 호스트가 없어 미지원이며 ARM64도 아직 안 된다.
한계 2: 심사관에 대한 정식 평가가 없어 경험적 관찰에만 의존하며 향후 하드웨어와 OS 확대와 GitHub PR CI 통합과 구조화된 평가 체계를 계획한다.