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

Spotify가 수천 개 저장소에 걸친 대규모 코드 마이그레이션을 수행하는 배경 코딩 에이전트(Honk)의 신뢰성을 어떻게 확보했는지를 다룬다. 검증 루프와 LLM 판사를 통해 에이전트가 프롬프트 범위를 벗어나거나 CI는 통과하지만 실제로 틀린 코드를 만들어내는 가장 위험한 실패 유형을 잡아낸다.

핵심 포인트

에이전트 실패 유형 중 가장 위험한 것은 CI를 통과하지만 기능이 잘못된 경우로, 자동화 신뢰 자체를 훼손한다.
검증 루프는 독립적인 여러 verifier로 구성되며, 소프트웨어 컴포넌트 내용(예: pom.xml)에 따라 자동 활성화된다.
LLM 판사가 diff와 원본 프롬프트를 비교해 에이전트가 범위를 벗어난 변경을 했는지 판정한다.
수천 세션 중 약 1/4이 판사에게 거부되며, 거부된 경우의 절반은 에이전트가 스스로 방향을 수정할 수 있다.
에이전트의 도구 접근을 파일 편집과 검증자 실행으로 제한하고 컨테이너 샌드박싱으로 보안을 확보한다.

상세 정리

세 가지 실패 모드: PR 생성 실패(수동 대체 가능), CI 실패(반쯤 망가진 코드 수정 필요), CI 통과 + 기능 오류(가장 위험, 자동화 신뢰 훼손).
실패 원인: 테스트 커버리지 부족, 에이전트가 프롬프트 범위 밖으로 변경, 빌드/테스트 실행 실패.
검증 루프 설계 원칙: 에이전트는 검증자 내부 동작을 알 필요 없이 verify 도구를 호출하기만 한다.
검증자 자동 활성화: Maven 검증자는 pom.xml 발견 시 활성화되는 방식으로 저장소 특성에 맞게 적절한 검증자가 선택된다.
검증자의 이점: 에이전트에게 점진적 피드백을 주고, 빌드 시스템 세부사항을 숨기며, 정규식으로 관련 오류 메시지만 추출해 컨텍스트 윈도우를 절약한다.
Claude Code 통합: stop hook으로 PR 오픈 전 모든 검증자를 실행해 CI 제출 전 문제를 조기에 잡는다.
LLM 판사 도입 배경: 에이전트가 리팩토링이나 불안정한 테스트 비활성화처럼 프롬프트 범위 밖의 변경을 시도하는 문제를 해결하기 위해 도입했다.
판사 동작: diff와 원본 프롬프트를 LLM에 전송, 모든 다른 검증자 완료 후 마지막에 실행한다.
실제 수치: 수천 세션 중 약 1/4이 거부, 거부 중 절반은 에이전트 스스로 방향 수정 성공. 가장 일반적 거부 이유는 프롬프트 지침 이탈.
에이전트 집중 유지: 관련 코드베이스 접근, 파일 편집, 검증자 실행만 허용. 코드 푸시, Slack 상호작용, 프롬프트 작성은 범위 밖이다.
보안 구성: 컨테이너 샌드박싱, 제한된 권한, 최소 바이너리로 프로덕션 환경과 격리한다.
향후 계획: Linux x86에서 macOS(iOS)/ARM64로 검증자 인프라 확장, GitHub PR CI 체크를 외부 루프로 활용, 체계적 eval 프레임워크 도입.

왜 읽나대규모 코드베이스에서 자율 코딩 에이전트의 신뢰성을 확보하는 검증 루프와 LLM 판사 설계를 찾는 AI/플랫폼 엔지니어에게 실전 참조 자료다.

Spotify Engineering 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

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

이 글과 비슷한

에이전틱 SDLC를 QA 엔지니어링 마인드셋으로 구축하기

보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계

실리콘투의 사내 지식 MCP 게이트웨이 구축기