HITL — 제안 후 커밋(Human-in-the-Loop: Propose-Then-Commit)

2026년 사람 개입 검토(Human-in-the-Loop; HITL)에 대한 합의는 매우 구체적입니다. 이는 "에이전트가 묻고 사용자가 Approve를 클릭한다"는 형태가 아니라, 제안 후 커밋(propose-then-commit) 형태입니다. 제안된 동작(action)은 멱등성 키(idempotency key)와 함께 영속 저장소(durable store)에 저장됩니다. 검토자(reviewer)에게는 의도(intent), 데이터 출처(data lineage), 건드리는 권한(permissions touched), 영향 반경(blast radius), 롤백 계획(rollback plan)이 함께 표시됩니다. 명시적 승인(positive acknowledgement)이 있을 때에만 커밋(commit)되고, 실행 뒤에는 부수 효과(side effect)가 실제로 발생했는지 검증(verify)합니다. LangGraph의 interrupt()와 PostgreSQL 체크포인팅(checkpointing), Microsoft Agent Framework의 RequestInfoEvent, Cloudflare의 waitForApproval()은 모두 같은 형태를 구현합니다. 대표적 실패 양상(failure mode)은 형식적 승인(rubber-stamp approval)입니다. "Approve?"가 실질적 검토 없이 그대로 클릭되는 상황입니다. 문서화된 완화책(mitigation)은 명시적 체크리스트(checklist)를 갖춘 챌린지-응답(challenge-and-response) 흐름입니다.

유형: Learn 언어: Python (stdlib, 멱등성을 갖춘 제안 후 커밋 상태 기계(state machine)) 선수 지식: Phase 15 · 12 (Durable execution), Phase 15 · 14 (Tripwires) 예상 시간: 약 60분

문제

에이전트가 어떤 동작을 수행하려 합니다. 사용자는 결정해야 합니다. 승인할 것인지, 말 것인지. 결정이 즉각적으로 이루어진다면 그것은 사실상 검토가 아닐 가능성이 큽니다. 결정이 구조화된 절차를 거친다면 느리지만 신뢰할 수 있습니다. 엔지니어링의 질문은 결국, 어떻게 하면 구조화된 검토(structured review)를 가장 저항이 적은 경로(path of least resistance) 로 만들 수 있는가 입니다.

2023년 무렵의 HITL 패턴은 동기 프롬프트(synchronous prompt)였습니다. "에이전트가 X에게 본문 Y인 이메일을 보내려 합니다 — 승인하시겠습니까?"라는 형태로, 사용자는 Approve 버튼을 클릭합니다. 모두가 시스템이 안전하다고 느낍니다. 하지만 실제로 이 화면은 형식적 승인으로 흐르기 쉽습니다. 사용자는 빠르게 승인하고, 승인 자체는 사후 결과를 거의 예측해 주지 못하며, 에이전트가 잘못된 행동을 했을 때 감사 기록(audit trail)에는 사용자가 거의 기억하지 못하는 긴 승인 이력만 남습니다.

2026년의 패턴인 제안 후 커밋은 HITL을 영속 기반(durable substrate) 위로 옮기고, 구조화된 메타데이터(structured metadata)를 붙이며, 명시적 커밋(positive commit)을 요구합니다. 관리형 에이전트 SDK들은 모두 자기만의 버전을 제공합니다. LangGraph는 interrupt(), Microsoft Agent Framework는 RequestInfoEvent, Cloudflare는 waitForApproval()로 부릅니다. API 이름은 다르지만 형태는 동일합니다.

개념

제안 후 커밋 상태 기계(state machine)

1. Propose(제안). 에이전트가 제안된 동작을 생성합니다. 이는 영속 저장소(PostgreSQL, Redis, Durable Object 등)에 저장됩니다. 저장 시 다음 정보를 포함합니다.
   • 의도(intent): 에이전트가 왜 이 동작을 하려고 하는가
   • 데이터 출처(data lineage): 어떤 원천 데이터가 이 제안으로 이어졌는가
   • 건드리는 권한(permissions touched): 어떤 스코프(scope), 파일(file), 엔드포인트(endpoint)를 건드리는가
   • 영향 반경(blast radius): 최악의 경우 무엇이 일어나는가
   • 롤백 계획(rollback plan): 커밋된 뒤에 어떻게 되돌릴 수 있는가
   • 멱등성 키(idempotency key): 제안마다 고유한 값으로, 같은 제안의 재제출(resubmission)은 같은 레코드를 반환합니다.
2. Surface(노출). 검토자는 모든 메타데이터와 함께 제안을 봅니다. 검토자는 반드시 사람이어야 하며, 에이전트가 자기 자신을 검토(review)해서는 안 됩니다.
3. Commit(커밋). 명시적 승인입니다. 이 단계에서 동작이 실제로 실행됩니다.
4. Verify(검증). 실행 뒤 부수 효과를 다시 읽어 확인합니다. 검증 단계가 실패하면 시스템은 알려진 비정상 상태(known bad state)에 들어가며 알림(alerting)이 작동합니다.

멱등성 키(idempotency key)

멱등성 키가 없으면, 일시적 장애(transient failure) 뒤의 재시도(retry)가 이미 승인된 동작을 두 번 실행해 버릴 수 있습니다. 구체적인 예를 보겠습니다. 사용자가 "A에서 B로 100달러 이체"를 승인합니다. 네트워크 끊김(network blip)이 발생합니다. 워크플로우가 재시도를 수행합니다. 사용자는 한 번만 승인했지만 이체는 두 번 실행되어 버립니다. 멱등성 키는 하나의 승인을 단 하나의 고유한 부수 효과에 묶어 줍니다. 두 번째 실행은 아무것도 하지 않는 동작(no-op)이 됩니다.

이는 Stripe와 AWS API가 사용하는 멱등성 패턴과 동일한 것입니다. 이 패턴을 에이전트 승인에 그대로 재사용하라는 가이드는 Microsoft Agent Framework 문서에도 명시되어 있습니다.

영속성(durability): 승인이 프로세스보다 오래 살아남는 이유

승인 대기실(approval waiting room)은 에이전트가 소유하지 않는 상태(state)입니다. 워크플로우는 일시 정지됩니다(Lesson 12 참고). 승인이 도착하면 워크플로우는 정확히 그 지점에서 재개(resume)됩니다. LangGraph가 interrupt()를 단순한 메모리 내 상태(in-memory state)가 아니라 PostgreSQL 체크포인팅과 함께 사용하는 이유가 바로 이것입니다. 이틀 뒤에 도착한 승인도 워크플로우를 온전한 상태로 다시 찾을 수 있어야 합니다.

형식적 승인(rubber-stamp approval)과 챌린지-응답 완화책

HITL의 기본 UI(Approve / Reject 버튼)는 실질적인 검토 없이 빠른 승인이 남발되는 결과를 만듭니다. 문서화된 완화책은, Approve 버튼이 활성화(enable)되기 전에 검토자가 특정 질문들에 대해 명시적으로 답하도록 요구하는 챌린지-응답 체크리스트입니다. 구체적 형태는 다음과 같습니다.

• "이 동작이 어떤 자원(resource)을 건드리는지 이해했습니까? [ ]"
• "영향 반경(blast radius)이 수용 가능한 수준임을 확인했습니까? [ ]"
• "실패 시를 위한 롤백 계획이 마련되어 있습니까? [ ]"

이는 관료주의(bureaucracy)를 위한 형식이 아니라, 강제적 사고 유도 장치(forcing function)입니다. 체크박스를 채울 수 없는 검토자는 추가 설명을 요청하거나(에스컬레이션, escalation), 거절(decline)을 택합니다(안전한 기본값, safe default). Anthropic의 에이전트 안전성 연구(agent-safety research)에서도 체크리스트 기반 HITL을 형식적 승인 패턴에 대한 완화책으로 명시적으로 언급합니다.

무엇이 결과가 큰(consequential) 동작인가

모든 동작에 제안 후 커밋이 필요한 것은 아닙니다. 2026년의 가이드는 다음과 같습니다.

• 결과가 큰 동작(consequential actions, 항상 HITL): 되돌릴 수 없는 쓰기(irreversible write), 금융 거래(financial transaction), 외부 커뮤니케이션(outbound communication), 운영 데이터베이스 변경(production database change), 파괴적 파일 시스템 동작(destructive file-system operation).
• 되돌릴 수 있는 동작(reversible actions, 때때로 HITL): 로컬 파일(local file) 편집, 스테이징 환경(staging-env) 변경, 명확한 롤백을 갖춘 되돌릴 수 있는 쓰기(reversible write).
• 읽기와 점검(reads and inspections, HITL 불필요): 파일 읽기, 자원 목록 조회, 읽기 전용 API 호출.

사후 검증(post-action verification)

"커밋이 실행되었다"는 말은 "부수 효과가 실제로 발생했다"는 말과 같지 않습니다. 네트워크 분할(network partition)이나 경쟁 상태(race condition)는, 워크플로우는 성공했다고 믿지만 백엔드(backend)에는 변경이 실제로는 영속되지 않은 상황을 만들 수 있습니다. 검증 단계는 커밋 뒤에 대상 자원(target resource)을 다시 읽어 결과를 확인합니다. 이는 RETURNING 절을 사용하는 데이터베이스 트랜잭션(database transaction)이나, PutObject 뒤에 GetObject를 호출하는 AWS의 패턴과 동일합니다.

EU AI Act Article 14

EU AI Act 제14조(Article 14)는 EU의 고위험 AI 시스템(high-risk AI system)에 대해 효과적인 사람 감독(effective human oversight)을 요구합니다. 여기서 "효과적(effective)"이라는 표현은 단순한 장식이 아닙니다. 규제 문구는 형식적 승인 패턴을 명시적으로 배제합니다. 챌린지-응답을 갖춘 제안 후 커밋은 Microsoft Agent Governance Toolkit의 컴플라이언스(compliance) 문서에서 Article 14의 심사를 통과할 수 있는 형태로 제시됩니다.

사용해보기

code/main.py는 stdlib Python만으로 제안 후 커밋 상태 기계를 구현합니다. 영속 저장소로는 JSON 파일을 사용합니다. 멱등성 키는 (thread_id, action_signature)의 해시(hash)입니다. 드라이버(driver)는 세 가지 사례를 시뮬레이션합니다. 깨끗한 승인 흐름(clean approval flow), 일시적 장애 뒤의 재시도(같은 동작을 두 번 실행하지 않아야 함), 그리고 형식적 승인과 챌린지-응답 흐름의 비교입니다.

산출물 만들기

outputs/skill-hitl-design.md는 제안된 HITL 워크플로우가 제안 후 커밋의 형태를 갖추었는지 검토하고, 메타데이터, 멱등성, 검증, 챌린지-응답 계층 중 빠진 항목을 표시하도록 도와주는 스킬(skill)입니다.

연습문제

1. (쉬움) code/main.py를 실행하세요. 승인된 제안의 재시도가 영속 레코드(durable record)를 사용하고 다시 실행되지 않는지 확인하세요. 그런 다음 멱등성 키가 타임스탬프(timestamp)를 포함하도록 바꾸고, 재시도가 두 번 실행(double-execute)되는 결과를 보여주세요.

2. (중간) 제안 레코드에 rollback 필드를 확장하세요. 검증 단계가 실패하는 실행을 시뮬레이션하고, 롤백이 자동으로 발동(firing)되는 모습을 보여주세요.

3. (중간) Microsoft Agent Framework의 RequestInfoEvent 문서를 읽으세요. 본 예제 엔진(toy engine)에 빠져 있는 API 메타데이터 필드 하나를 찾아내세요. 그것을 추가하고, 그 필드가 무엇으로부터 우리를 보호해 주는지 설명하세요.

4. (어려움) 특정 동작(예: "공개 Twitter 계정에 글을 게시하기")에 대한 챌린지-응답 체크리스트를 설계하세요. 검토자가 답해야 할 세 가지 질문은 무엇이며, 왜 그 세 가지여야 하는지 설명하세요.

5. (어려움) 동기 Approve? 프롬프트만으로 충분한 사례 하나를 고르세요(즉, 영속 저장소가 필요하지 않은 경우). 왜 그 경우에는 충분한지 설명하고, 그 결정으로 수용하게 되는 위험 분류(risk class)에 이름을 붙여 보세요.

핵심 용어

더 읽을거리

• Microsoft Agent Framework — Human in the loop — RequestInfoEvent와 영속 승인(durable approvals)을 다룹니다.
• Cloudflare Agents — Human in the loop — waitForApproval()와 Durable Objects를 다룹니다.
• Anthropic — Measuring agent autonomy in practice — 장기 호라이즌(long-horizon) 위험 완화책으로서의 HITL을 다룹니다.
• EU AI Act — Article 14: Human oversight — 고위험 시스템에 대한 규제 기준선(regulatory baseline)을 제공합니다.
• Anthropic — Claude's Constitution (January 2026) — 감독(oversight)을 둘러싼 헌법적(constitutional) 프레이밍을 다룹니다.