AI 버그 수정 에이전트의 신뢰도를 높이기 위해 프롬프트가 아닌 워크플로우를 설계하다

저희는 Sherlock라는 전용 버그 수정 에이전트를 구축했습니다. 이 에이전트는 Slack을 통해 버그를 수신하고, Sharkly.ai의 구조화된 작업(structured task)으로 처리합니다.

최근 15일 동안 Sherlock는 회사 전체 작업의 13%를 완료했습니다. 최근 할당된 100개의 작업 중 90개가 정상적으로 완료되었습니다.

중요했던 점은 단순히 모델을 개선하는 것이 아니라, 에이전트의 실행 프로세스 자체를 제어하는 것이었습니다.

역할 프롬프트가 아닌, 10단계 스테이트 머신(State Machine)
'당신은 유능한 엔지니어입니다'와 같은 프롬프트에만 의존하지 않고, Sherlock는 고정된 10단계의 단계를 따릅니다. 단계 건너뛰기가 불가능하며, 진단 단계에서는 제품 코드를 변경할 수 없습니다.
명시적인 두 가지 승인 토큰(Approval Token)
초기 워크플로우에는 7개의 승인 지점이 있었는데, 이 부분이 병목 현상을 일으켰습니다. 따라서 다음 두 가지로 줄였습니다.

[START DEVELOPMENT] — 코드 변경 허용
[SUBMIT FOR TESTING] — push/merge 허용

'Looks good'이나 'continue' 같은 문구는 승인으로 간주하지 않습니다.

각 단계별 산출물 필수화
필수적인 파일은 diagnosis.md, idea.md, plan.md, review-report.md입니다. 단순히 채팅 메시지로 'diagnosis complete'라고만 하는 것은 완료로 인정되지 않습니다.
채팅 기록이 아닌 state.json에서 복구
모든 상태를 state.json에 저장합니다. 세션이 중단된 경우, 다음 실행은 디스크에서 상태를 읽어옵니다. 대화 기록을 통해 진행 상황을 재구성하는 과정에서는 에이전트가 진행 상황을 잘못 생성하는 문제가 있었습니다.
최대 6회의 셀프 리뷰(Self-Review)
구현 후, Sherlock는 독립적인 검토자처럼 diff를 확인합니다. 중대한 문제가 발견되면 수정하고 다시 검토하지만, 최대 6회에서 멈추고 사람에게 에스컬레이션됩니다.
UI 변경 전후 스크린샷
UI 변경 시에는 단순히 파일 경로로만 스크린샷을 전달하는 것이 아니라, 대화 내에 직접 표시합니다.

실제 사례

'리스트가 스크롤되지 않는다'는 버그는 Slack → 구조화된 작업(structured task) → 14분간의 자율 진단 → 사람에 의한 3번의 판단 → 승인 → 37분간의 구현 → PR, 미리보기 URL, 스크린샷이라는 흐름으로 처리되었습니다.

사람에 의한 판단은 총 2회였습니다.

참고로, 90/100이라는 결과는 Sherlock에게 할당된 작업에 한정됩니다. 모든 버그에 대한 성공률은 아닙니다. 또한, 재오픈율(re-open rate) 데이터는 아직 공개하지 않았습니다.

요약