HITL을 어디에 둘 것인가

복잡도 기반 위험분류로 인간 검증을 설계하는 법

---

"AI에 다 맡길 수는 없으니 사람이 검토해야 한다."

여기서 끝나면 시스템이 동작하지 않는다. 어디서, 얼마나 자주, 어떤 강도로 사람을 부를지 — 이 결정 자체는 어떻게 내려야 하는가? 직감으로? 그건 위험하다.

리서치하다 보니 답이 그래프 안에 있었다. 네 단계로 정리한다.

---

1. 왜 일단 사람을 부르긴 해야 하는가

흔한 오해: "AI가 잘 못하니까 사람이 봐야 한다."

데이터는 정확히 반대를 말한다. AI가 잘할수록 사람이 못 보게 된다.

자동화가 일관되게 신뢰할 때 인간 오류 탐지율은 약 30%. 자동화가 가끔 눈에 띄게 실패할 때는 약 75%. 자동화가 잘 동작할수록 사람의 감시 능력이 구조적으로 저하된다는 게 대규모 문헌 리뷰의 결론이다.¹

AI 코드 생성에서는 더 구체적이다. 개발자 96%가 "AI 코드를 신뢰하지 않는다"고 답하지만, 커밋 전에 실제로 검증하는 비율은 48%에 그친다.² 자격증명(credential) 노출은 비AI 개발자 대비 약 2배.³

그러니까 진단은 이렇다. "검증이 필요하다"가 아니라 "검증 능력 자체가 자동화에 의해 침식된다." 그래서 HITL(Human-in-the-Loop)이 필요하다 — 시스템 차원에서 인간 검증을 강제로 끼워넣지 않으면, 사람은 자기도 모르게 그 검증을 건너뛰게 되어 있다.

---

2. 그래서 어디에 사람을 부를까

전부 다 검증시키면 처리량이 안 나온다. 그렇다고 "여기는 위험해 보여"라는 직감으로 정하면, 자동화 편향이 그 직감을 오염시킨다. 위에서 본 30%의 늪에 빠진다.

해법은 측정이다. 코드와 문서 시스템을 노드와 연결선으로 그려놓고 — 어떤 부분이 다른 부분에 얼마나 영향을 미치는지 — 네 가지 지표로 위험을 정량화한다.

• 분기 경로 수(Cyclomatic Complexity). 한 모듈 안의 가능한 실행 경로 수. McCabe(1976)이 제안한 고전 지표로, V(G) > 20이면 고위험으로 분류한다.⁴
• 얽힘 덩어리 크기(SCC). 서로 영향을 주고받는 코드 클러스터의 노드 수. 5개 이상이면 데드락이나 무한 루프 위험이 커진다.
• 교통 허브 지표(Betweenness Centrality). 시스템 내 통신 경로의 중심에 있는 노드. 상위 5% 노드가 전체 전파 경로의 60% 이상을 매개하면 단일 장애점(SPOF)으로 본다.
• 결함 도달 범위(BFS Impact). 한 노드의 결함이 전체 시스템 몇 %에 도달하는가. 30%를 넘으면 격리 설계가 필요하다.

이 지표들이 실제로 작동한다는 검증도 있다. 대형 오픈소스 프로젝트(Findbugs, Hibernate, Spring Framework)의 20개 이상 연속 릴리즈를 분석한 연구에서, "허브 역할을 하는 클래스"일수록 버그가 더 멀리 퍼지는 패턴이 분명하게 나타났다.⁵

여기서 HITL의 위치가 결정된다. 지표 임계값을 초과하는 노드 = 사람이 봐야 하는 자리. 임계값 미만 = AI에 위임해도 되는 자리.

---

3. 부르되, 어떤 강도로

위치를 정했다고 끝이 아니다. 사람을 부른다 해도, 모든 결정에 매번 승인을 받으면 처리량이 다시 무너진다.

그래서 HITL 자체도 4단계로 차등 설계한다.⁶

매핑은 단순하다. High Risk → HITL. Medium Risk → HITLFE + Property-based Testing 자동 + 결과 인간 검토. Low Risk → HOTL + 멱등성 자동 검증. 그리고 실패 시 자동으로 한 단계 위로 에스컬레이션한다(Cascading Fallback).

산업 사례도 같은 방향이다. Google의 Gemini 트리아지 에이전트는 보안 분류를 위험 등급별로 자동 격리/에스컬레이션하는 구조로 동작한다. Netflix는 실패 이력과 정적 분석 기반 PR 위험 트리아지로 폭발 반경을 약 50% 줄였다.⁷ FDA는 2025년 CSA 가이드에서 위험 기반 검증을 공식 권장한다.

---

4. 그런데 임계값은 누가 정하는가

여기가 가장 까다롭다.

"V(G) > 20이면 고위험"의 그 20은 누가 정하나? 사람이다. 그런데 그 사람이 이미 1번에서 본 자동화 편향 상태라면? 실제보다 낮은 위험으로 분류하게 된다.

그래서 임계값 자체를 주기적으로 재검토하는 메타 루프가 필요하다. 흐름은 이렇다.

코드가 바뀐다 → 그래프 지표를 재계산한다 → 재계산된 분포가 임계값을 재조정하라고 알린다 → 인간이 새 임계값을 검토한다 → 새 임계값으로 HITL 배치가 재구성된다.

이게 구글의 PageRank가 작동하는 방식과 같다. "많이 링크된 페이지가 중요하다 → 중요한 페이지에서 링크받은 페이지가 더 중요하다." 순환처럼 보이지만 계속 반복하면 안정적인 순위가 수렴한다. 위험 분류도 마찬가지다.

한 번 정하고 끝이 아니다. 반복이 정밀도를 만든다.

---

정리

HITL 설계의 흐름을 한 줄로 요약하면:

시스템을 그래프로 → 복잡도·전파 지표로 노드별 위험 정량화 → 위험 등급에 HITL 단계 매핑 → 임계값 자체는 주기적으로 인간이 재검토.

"AI에 어디까지 맡길지"의 답은 직감이 아니라 측정에서 나와야 한다. 그래야 자동화 편향이 그 결정을 오염시키지 못한다. 그리고 측정 자체가 자동화 편향에 오염되지 않도록, 임계값 재검토라는 메타 루프가 필요하다.

지금 운영 중인 에이전트 시스템에서 HITL이 어디에 배치되어 있는지 한 번 살펴볼 만하다. 거기가 정말 그래프 위험이 높은 곳인가? 아니면 "왠지 중요해 보여서" 둔 자리인가? 그 차이가 시스템의 실제 신뢰도를 결정한다.

---

참조 노드: [[concept__automation-bias]], [[concept__risk-based-verification]], [[concept__state-transition-complexity]], [[concept__error-propagation-graph]], [[concept__idempotency-verification]], [[technique__hitl-checkpoint]], [[boundary-layer-model]]

Footnotes

1. Parasuraman, R. & Manzey, D. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3). https://journals.sagepub.com/doi/10.1177/0018720810376055 ↩

2. SonarSource (2024). Developer Survey on AI-Generated Code Trust and Verification. ↩

3. Apiiro (2024). AI Code Risk Report — credential exposure in AI-assisted development. ↩

4. McCabe, T.J. (1976). A Complexity Measure. IEEE Transactions on Software Engineering, SE-2(4). ↩

5. Wen, W. et al. (2014). Network-Based Analysis of Software Change Propagation. PLoS ONE. https://pmc.ncbi.nlm.nih.gov/articles/PMC3984771/ ↩

6. HITL 4단계 모델(HITL/HITLFE/HOTL/HOOTL)은 LangGraph interrupt, Claude Agent SDK hooks 등 주요 에이전트 프레임워크의 confidence_score 기반 자동화 단계 구분에서 공통적으로 채택된다. 참조: Permit.io HITL 가이드(2024). https://www.permit.io/blog/human-in-the-loop-for-ai-agents-best-practices-frameworks-use-cases-and-demo ↩

7. Google Gemini 트리아지 에이전트, Netflix 실패 이력 기반 PR 트리아지(Engineering 블로그), FDA Computer Software Assurance Guidance (2025). ↩