[에이전트 파트3] Spotify 코딩 에이전트의 피드백 루프 설계

요약

Spotify Fleet Management 팀이 수천 개 컴포넌트에 자동 코드 변경을 돌리며, 가장 막기 어려운 실패는 PR 미생성도 CI 실패도 아닌 CI 통과 + 기능 오류로 정의. pom.xml 같은 파일 감지로 자동 활성화되는 검증자, diff와 프롬프트를 비교하는 LLM 판사, 권한 최소화 샌드박스로 예측 가능성을 확보.

내용

1편에서 Fleet Management로 1,500여 PR을 머지한 흐름, 2편에서 마이그레이션 프롬프트의 컨텍스트 엔지니어링을 다룬 시리즈의 Part 3. 이번 글의 질문은 단순함 — 사람 감독 없이 도는 에이전트가 매번 정확한 결과를 내려면 어떤 환경이 있어야 하는가.

수천 컴포넌트를 동시에 수정할 때 신경 쓰는 실패 모드는 셋. PR 자체를 못 만들면 가벼운 짜증, CI에서 떨어지면 사람이 반쯤 깨진 코드를 손봐야 해서 부담, CI까지 통과했는데 기능이 어긋나 있으면 자동화 신뢰 자체가 무너지고 프로덕션 장애로 이어짐. 세 번째가 가장 위험하다는 진단이 설계의 출발점.

CI 통과 + 기능 오류가 자주 일어나는 배경: 대상 컴포넌트의 테스트 커버리지가 낮거나, 에이전트가 프롬프트 범위를 넘어 리팩토링·플레키 테스트 비활성화 같은 짓을 하거나, 빌드·테스트 실행 자체를 제대로 못 하거나. 신뢰를 회복하려면 에이전트 안쪽이 아니라 바깥에서 가드레일이 필요.

해결 / 접근

독립 검증자(Verifier) — 에이전트는 검증 내부를 모름

• 검증자는 에이전트와 분리된 컴포넌트. 에이전트는 검증을 호출만 하고 그 안이 무엇을 하는지 모름
• 컴포넌트 내용에 따라 자동 활성화 — 루트에 pom.xml이 있으면 Maven 검증자가 켜짐
• 실패 시 정규표현식으로 관련 에러만 추출해 에이전트에 전달, 성공 시 짧은 메시지만 — 컨텍스트 윈도우 절약
• 도구 호출(MCP tool)로도 부르고, PR 생성 직전 자동 실행도 함. Claude Code에서는 stop hook으로 PR 열기 전에 모든 검증자 가동

LLM 검수(Judge) — 결정적 검증자 위 보호층

• diff와 원본 프롬프트를 함께 LLM에 넘겨 "프롬프트 의도에 맞는 변경인가" 평가
• 모든 검증자 통과 후 마지막에 실행
• 수천 세션 중 약 25% 거부, 거부된 것의 50%는 에이전트가 자체 수정. 가장 흔한 거부 사유는 프롬프트 범위 이탈 — 시키지 않은 리팩토링, 플레키 테스트 비활성화 등

샌드박싱으로 포커스 유지

• 에이전트 권한: 코드 열람, 파일 편집, 검증자 실행만
• 코드 푸시·Slack 상호작용·프롬프트 작성은 외부 인프라 담당
• 컨테이너 내 제한된 권한, 바이너리 최소, 주변 시스템 접근 차단 — 예측 가능성 + 보안 부수 효과

결과 / 참고

• LLM 판사 거부율 약 25%, 거부 후 자동 수정 성공률 약 50% (수천 세션 기준 내부 지표)
• 검증자 + 판사 도입 후 에이전트가 더 복잡한 작업도 안정적으로 처리
• Future Works
  • 검증자 인프라를 macOS·ARM64까지 확대 (현재 Linux x86 한정 → iOS·일부 백엔드 커버 필요)
  • GitHub PR의 CI 체크에 반응하는 outer loop 통합 — 검증자가 inner loop, CI 결과가 outer loop
  • Judge용 evals 구축 — 시스템 프롬프트·아키텍처·LLM 공급자 비교 위해
• 시리즈: Part 1(도입과 1,500+ PR 머지), Part 2(컨텍스트 엔지니어링), Part 3(피드백 루프 — 본 글)
• 원문: https://engineering.atspotify.com/2025/12/feedback-loops-background-coding-agents-part-3/