프로덕션에서 에이전트가 스스로 복구하는 방식

GTM Agent를 배포한 뒤 문제가 생기면 사람이 나서기 전에 시스템이 먼저 감지하고 고치도록, 자가 복구 배포 파이프라인을 만들었다. 핵심은 배포 후 로그를 살피고, 실제 회귀인지 판별한 다음, 필요할 때만 Open SWE를 호출해 수정 PR까지 자동으로 여는 흐름이다.

배포 직후의 자동 검사는 두 갈래로 나뉜다.

• Docker build 실패: 빌드 로그와 직전 커밋의 git diff를 바로 Open SWE에 넘겨 수정한다.
• 서버 측 회귀: 배포 전 7일간의 에러 로그를 기준선으로 모으고, 배포 후 60분 동안의 에러를 같은 방식으로 정규화해 비교한다.

에러 비교는 단순한 카운트 차이가 아니라 Poisson test로 게이트를 둔다. UUID, 타임스탬프, 긴 숫자 문자열을 지운 뒤 200자로 잘라 동일한 에러를 같은 시그니처로 묶고, 기준선에서 기대한 시간당 발생률과 비교해 p < 0.05면 회귀 후보로 표시한다. 기준선에 없던 새로운 에러는 모니터링 창에서 반복적으로 나타날 때만 경고한다.

숫자만으로는 원인을 구분하기 어렵기 때문에, 그 다음에는 triage agent가 개입한다. 이 에이전트는 diff와 에러를 받아 변경 파일을 runtime, prompt/config, test, docs, CI 등으로 분류하고, runtime 변경일 때만 특정 코드 라인과 에러 사이의 인과관계를 설명해야 한다. 출력은 결정, 신뢰도, 근거, 그리고 변경에 귀속된 에러 시그니처를 담은 구조화된 verdict다.

이렇게 걸러진 문제만 Open SWE로 넘어가므로, 에이전트는 모든 에러 덤프를 받는 대신 좁혀진 조사 프롬프트를 받는다. 이 구조는 특히 눈에 띄게 죽지 않는 silent failure, 설정 불일치, 다음 배포에서야 드러나는 연쇄 회귀를 잡는 데 유용하다.

앞으로는 더 넓은 lookback window를 적용해 이전 버전에서 심어진 버그까지 추적하는 방안, 에러 메시지를 vector space에 임베딩해 클러스터링하는 방안, 더 작은 모델로 에러를 분류한 뒤 그 결과를 Open SWE에 전달하는 방안이 검토되고 있다. 또 Ramp처럼 PR merge 시점에 미리 모니터를 생성하는 접근도 대안으로 제시한다.

마지막으로, 지금은 항상 fix-forward 방식이라 깨진 배포를 그대로 둔 채 PR로 고치지만, 실제 운영에서는 심각도, 에러율, triage 신뢰도에 따라 즉시 rollback할지 패치로 앞으로 밀어갈지 결정하는 편이 더 낫다는 점도 짚는다. 결국 목표는 배포, 모니터링, triage, 수정의 루프를 자동화해 사람의 개입을 최소화하는 것이다.