저희 팀은 봇들이 남긴 실패 log에서 개선 항목을 자동으로 뽑아 처리하는 자가 개선 pipeline을 dashboard에서 운영합니다. 예를 들어 어느 봇이 한 관측 창에서 같은 거부를 120번 낸 기록은, 이 pipeline을 거쳐 다음 날 시스템 정책 변경으로 반영됐습니다. 그 과정에서 사람이 한 일은 승인 한 번뿐입니다. 이 글은 이 pipeline의 구조와 실제 운영 3주 치 데이터(총 41건)를 정리한 dev log입니다.
🧵 개선안 하나가 구현되는 흐름
구체적인 항목 하나로 설명하겠습니다. 수집기가 봇 세션 log의 실패 신호를 묶어 하나의 cluster를 만듭니다. 예를 들어 특정 검증 hook이 한 관측 창에서 125번 거부를 낸 cluster입니다. pipeline은 이 cluster를 하나의 “제안”으로 변환합니다. 제안에는 제목 외에 세 가지가 함께 붙습니다. 실제 log 발췌인 증거, 코드·문서·설정 가운데 무엇을 고치는지 나타내는 패치 종류, 그리고 위험도와 확신도입니다. 사람(팀의 최종 결정권자)이 dashboard에서 제안을 확인하고 승인합니다. 승인된 항목은 담당 봇에게 자동으로 dispatch되고, 봇은 수정을 구현한 뒤 commit 해시와 함께 마감을 보고합니다. 마지막으로 다른 봇이 그 diff를 읽고 테스트를 재현해야 항목이 닫힙니다.
이 항목의 실제 마감 기록은 두 부분입니다. 거부 log에 거부된 본문 앞 60자를 남기도록 hook을 고친 commit, 그리고 “reviewer — diff 읽음, 테스트 6/6 재현”이라는 확인 기록입니다. 제안부터 마감까지 사람이 개입한 지점은 승인 한 번입니다.
⚙️ pipeline의 5단계 구조
pipeline은 다섯 단계로 구성됩니다.
- 수집·clustering: 세션 log의 실패 신호(hook 거부, 도구 오류, 중단)를 유형별로 묶습니다.
- 제안 생성: cluster마다 증거·패치 종류·위험도·확신도가 채워진 제안을 만듭니다. 증거 필드가 비면 제안은 생성되지 않습니다.
- 사람 gate: 승인과 반려를 사람이 판단합니다. 거버넌스급 항목은 자동 실행이 차단된 검토 차선으로 분리됩니다. 41건 중 17건이 이 차선으로 분류됐습니다.
- 자동 dispatch: 승인 항목을 스케줄러가 담당 봇에게 작업 지시로 전달합니다.
- 검증 마감: commit 참조와 독립 reviewer의 재현 확인이 모두 있어야 “구현됨” 상태가 됩니다.
📊 3주 운영 데이터 (41건)
운영 DB 기준 총 41건입니다. 구현 17건, reviewer 반려 19건, 미검토 대기 4건, 승인 후 dispatch 대기 1건입니다. 실패 유형 상위는 검증 hook 계열입니다. 멘션 규율 hook 두 종이 합쳐 15건, 언어 검증 계열이 7건입니다. 패치 종류는 코드 수정뿐 아니라 문서 개정, commit 없는 설정 변경, 코드 변경 없이 조사만으로 마감된 항목까지 포함합니다.
| 상태 | 건수 | 비고 |
|---|---|---|
| 구현 완료 | 17 | commit 참조 + 독립 reviewer 재현 확인 |
| reviewer 반려 | 19 | 전건 사유 코드 부착 — FAIL(a)/(b)/(c) |
| 미검토 대기 | 4 | 사람 gate 앞 대기열 |
| 승인 후 dispatch 대기 | 1 | 승인됐으나 아직 봇 배정 전 |
구현 17건의 패치 종류는 hook 수정 10건, 코드 3건, 독스트링 1건, SOP 1건, 인프라 설정 1건, 조사만으로 마감 1건입니다.
💡 주목할 숫자는 구현 17건이 아니라 반려 19건입니다. 제안의 46%가 reviewer gate에서 반려됐습니다. 저희는 이 반려율을 결함이 아니라 gate가 작동하는 지표로 봅니다.
🚪 reviewer gate가 걸러내는 것
반려에는 모두 사유 코드가 붙습니다. 분포는 세 종류입니다.
- FAIL(a) — 실행 불가능한 목표: 제안이 지목한 파일이 코드베이스에 존재하지 않는 경우입니다. clustering이 지어낸 경로를 reviewer가 파일 시스템 검색으로 확인합니다.
- FAIL(b) — 증거 불일치: 인용된 log를 열어 보면 제안의 설명과 어긋나는 경우입니다.
- FAIL(c) — 베이스라인 노이즈: 거부 수치는 크지만 전부 정상 동작인 경우입니다.
이 gate는 “그럴듯하지만 틀린” 제안을 걸러냅니다. 증거 필드를 강제해도 증거를 잘못 읽은 제안은 생성되며, 이를 걸러내는 것은 증거를 다시 확인하는 독립 reviewer입니다.
🔍 실제 사례 4건 (성공 3, 반려 1)
사례 1 — 문서 자동 생성. 이미지 생성 도구의 설명문이 모델 catalog와 어긋난다는 제안에 대해, 봇은 설정 파일에서 모델 힌트 블록을 생성해 도구 설명 네 곳에 주입하는 코드를 구현했습니다. 이후 catalog가 바뀌면 문서가 자동으로 갱신됩니다.
사례 2 — 코드 변경 없는 마감. 외부 플랫폼 업그레이드 후 발생한 dispatch 버그는 “고치기 전에 원인부터 특정하라”는 방침으로 승인됐습니다. 격리 클론에서 4-호출 최소 재현으로 실패 지점을 특정한 뒤 코드 변경 없이 마감했습니다. 재업그레이드 gate에 “클론 재현 통과” 조건을 추가했습니다.
사례 3 — 규율 시스템 자체 수정. 봇 간 대화 종료 마커에도 답장을 강제하던 hook에 침묵 면제를 추가한 항목입니다. pipeline이 자기 규율 시스템을 수정한 사례입니다.
사례 4 — 반려. 어느 hook의 거부 120건 cluster는 log 절단이 원인이라는 제안으로 올라왔으나, reviewer가 인용된 log를 확인하니 제안 설명과 반대되는 값이 기록돼 있었습니다. FAIL(b)로 반려했습니다. 이 반려 기록은 같은 cluster가 다시 올라올 때 우선 확인할 검증 항목으로 남습니다.
🌏 외부 사례: 같은 문제의 다른 해법
이 pipeline이 겨냥하는 실패 모드는 회고 개선 항목이 처리되지 못하고 누적되는 문제입니다. 업계 조사에서 회고 아이디어의 구현율은 4분의 1 미만이며, 추적 장치만 붙여도 완료율이 오른다는 보고가 있습니다. SRE 분야는 더 강제적입니다. incident 도구는 action item을 이슈 tracker로 자동 내보내고, 심각도에 따라 action item이 닫히기 전에는 incident를 닫지 못하게 막습니다. AI 에이전트 연구에는 반대 방향의 근거도 있습니다. 외부 피드백이 없는 LLM의 자기 교정은 성능을 떨어뜨린다는 ICLR 2024 결과입니다. 세 분야는 같은 조건을 가리킵니다. 개선 항목에는 소유자, 실제 작업과의 연결, 재점검 주기, 명확한 마감 기준이 필요하다는 것입니다.
🤔 이 방식의 한계 3가지
한계를 세 가지 기록합니다. 첫째, 프로세스가 형식만 남을 위험입니다. 반려율 46%는 현재 gate가 작동한다는 지표이지만, 반려율이 0에 가까워지면 제안 품질이 완벽해진 것이 아니라 gate가 형식적 승인으로 굳었다는 신호일 수 있습니다. 둘째, 검증자의 혈통 문제입니다. 마감 검증은 독립 reviewer의 diff 읽기와 테스트 재현이지만, reviewer도 같은 계열의 모델입니다. 외부 oracle 없는 자기 교정이 퇴화한다는 연구를 적용하면, 사람 gate와 교차 혈통 리뷰는 선택이 아니라 구조적 요건입니다. 셋째, 사람 gate는 의도된 병목입니다. 하루 수십 건 규모에서는 승인이 형식이 될 수 있습니다. 현재 규모(3주 41건)에서 작동하는 설계가 10배 규모에서도 작동한다고 보장할 수 없습니다.
🧭 이식할 만한 3가지
전체 시스템을 옮길 필요는 없습니다. 핵심은 세 가지입니다. 첫째, 개선 제안은 근거와 함께 제출하도록 강제합니다. 제안 양식에 근거 항목을 필수로 두면 근거 없는 제안이 생성되지 않습니다. 둘째, 반려 시 사유를 함께 기록합니다. 반려 이유가 남으면 같은 실수를 다시 검토하는 일이 줄어듭니다. 셋째, 완료 기준을 자기 보고가 아니라 재현된 결과로 정의합니다. 다른 사람이 재현해 확인한 것을 완료 조건으로 두면, 처리했다고만 하고 누적되는 미완 항목이 생기지 않습니다.
