Human-in-the-Loop — 사람이 끼어드는 타이밍

Claude Code를 쓰다 보면 "이 파일을 수정해도 되나요?"라고 물어보는 순간이 있다. 이게 Human-in-the-Loop이다.

왜 필요한가

에이전트가 자율적으로 행동하는 게 전부 좋은 건 아니다. 돌이킬 수 없는 행동을 에이전트가 독단으로 하면 문제가 된다.

• git push --force로 커밋 히스토리 날리기

• 프로덕션 DB에 직접 DELETE 쿼리 실행

• 고객에게 이메일 발송

• 결제 처리

이런 건 사람이 확인해야 한다. 근데 매 단계마다 확인을 받으면 에이전트를 쓰는 의미가 없다.

개입 레벨 설계

레벨 0 — 완전 수동: 매 행동마다 사람 승인. 에이전트의 의미가 없음.

레벨 1 — 위험 행동만 승인: 읽기는 자유, 쓰기는 확인. 대부분의 코딩 에이전트가 이 수준.

레벨 2 — 정책 기반 자동: 미리 정의된 규칙 내에서 자율, 규칙 밖은 승인 요청. "이 디렉토리 내 파일 수정은 OK, 다른 건 물어봐."

레벨 3 — 완전 자율: 모든 행동을 에이전트가 결정. 위험하지만, 명확한 범위에서는 유효. (예: 샌드박스 테스트 환경)

좋은 개입 요청의 조건

에이전트가 "이거 해도 돼요?"라고 물어볼 때:

• 맥락 제공: 왜 이 행동이 필요한지 설명

• 영향 범위: 이 행동이 뭘 변경하는지 구체적으로

• 대안 제시: "이렇게 할 수도 있고, 저렇게 할 수도 있는데 어느 쪽?"

• 기본값 제안: "이렇게 하려는데, 괜찮으면 진행합니다"

"파일을 수정합니다" (나쁨) vs "src/auth.ts의 validateToken 함수에서 만료 시간 체크를 추가합니다. 기존 로직은 변경하지 않고 조건문만 추가합니다." (좋음)

에스컬레이션 vs 중단

에스컬레이션: "이 부분은 제가 판단하기 어렵습니다" → 사람에게 결정을 넘기고, 결정을 받으면 계속 진행.

중단: "이 작업을 계속하면 위험할 수 있습니다" → 작업 자체를 멈춤.

Ralph Wiggum Loop을 방지하는 가장 확실한 방법이 에스컬레이션이다. 루프에 빠졌으면 솔직하게 "막혔습니다"라고 말하는 에이전트가 좋은 에이전트다.