사람에게 더 많이 물어볼수록 덜 안전해진다 — 감시 용량(oversight capacity)을 다룬 연구들

▶ 동영상 개요 — 사람에게 더 많이 물어볼수록 덜 안전해진다 — 감시 용량(oversight capacity)을 다룬 연구들

5분 12초 — 사람의 판단력을 부하에 따라 닳는 자원으로 모델링하면 실현된 안전성이 escalation 비율에 대해 역U자를 그린다 — 승인 게이트를 더 촘촘히 걸수록 리뷰어… — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 사람에게 더 많이 물어볼수록 덜 안전해진다 — 감시 용량(oversight capacity)을 다룬 연구들

17분 56초 — 사람의 판단력을 부하에 따라 닳는 자원으로 모델링하면 실현된 안전성이 escalation 비율에 대해 역U자를 그린다 — 승인 게이트를 더 촘촘히 걸수록 리뷰어…. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

에이전트를 여러 대 굴리기 시작하면 어느 시점부터 하루가 이렇게 흘러간다. 알림이 뜬다. "이 파일을 지워도 될까요?" "예." "이 명령을 실행할까요?" "예." "이 메일을 보낼까요?" "예." 스무 번쯤 반복되면 나는 더 이상 읽고 있지 않다. 화면에 뜬 문장의 모양만 보고 예를 누르고 있다. 그리고 그 상태로 스물한 번째를 눌렀을 때, 그게 진짜 위험한 것이었다면 나는 그걸 승인한 사람이 된다.

여기서 보통은 "게이트를 더 촘촘히 걸자"는 결론으로 간다. 그런데 최근 나온 연구 하나가 정확히 그 결론을 반박한다. 사람의 판단력을 고정된 자원이 아니라 부하에 따라 닳는 자원으로 모델링하면, 시스템의 실현된 안전성은 "사람을 부르는 비율"에 대해 역U자 곡선을 그린다. 즉 안전을 최대로 만드는 지점은 "전부 물어보기"가 아니라 그보다 낮은 어딘가에 있다. 이 글은 그 주장을 중심으로, 사람의 주의력을 유한한 예산으로 놓고 배분 문제를 푸는 학계·오픈소스 커뮤니티의 논의를 정리한다.

참고로 이 글은 언제 사람을 부를 것인가를 다룬다. 어떻게 실제로 멈추게 할 것인가(런타임이 실행을 일시정지하고 상태를 보존하는 문제)는 별개의 주제라 여기서는 다루지 않는다.

전체 지도 — 주의력을 예산으로 놓고 보면 그림이 달라진다

다이어그램 설명. 이 그림이 보여주는 것은 한 가지다 — "사람에게 넘긴다"는 화살표에는 값이 매겨져 있다는 것이다. "에이전트가 하려는 행동"이 "가드"를 통과하면서 자동 실행과 사람 호출로 갈라지는데, 대부분의 설계는 여기까지만 그린다. 그 뒤에 달린 "사람의 주의력"과 "총량을 넘기면 같은 사람이 더 나쁘게 판단한다"가 이 글의 주제다. 흔한 오해는 사람을 외부에 고정된 정답기로, 그러니까 부르면 언제나 같은 품질로 답하는 오라클로 보는 것이다. 그렇게 보면 "많이 부를수록 안전하다"가 자연스럽게 따라 나온다. 하지만 사람이 시스템 안에 있고 부하에 따라 상태가 변하는 요소라면, 호출 횟수는 공짜가 아니라 다른 호출의 품질을 갉아먹는 비용이 된다.

깨진 전제 하나 — "위험한 행동"에 정답 라벨이 있다

2026년 6월에 나온 「Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human」(arXiv 2606.08919, Emre Turan)이 이 문제를 정면으로 짚는다. 논문의 첫 문장은 도발적이다. 게이트를 다는 건 쉬운 부분이고, 어려운 건 어떤 행동을 멈춰 세울지를 정하는 판단이라고 못박는다.

연구진은 적대적으로 편향되게 고른 에이전트 행동 125건에 사람이 직접 위험도 라벨을 붙였다. 결과는 Fleiss' kappa = 0.52였다. Fleiss' kappa(여러 평가자가 같은 대상에 얼마나 일치하는 판정을 내리는지 재는 통계량 — 1이면 완전 일치, 0이면 우연 수준)에서 0.52는 관례적으로 "보통 수준의 일치"로 읽힌다. 뒤집으면, 무엇이 위험한지에 대한 단일한 정답이 없다는 뜻이다.

이게 왜 중요한가? 우리가 가드를 평가할 때 쓰는 언어는 대개 "이 가드는 위험한 행동을 몇 퍼센트 잡아냈는가"다. 그 문장은 정답표가 존재한다는 전제 위에 서 있다. 정답표가 없다면 그 숫자는 "가드가 특정 라벨러 한 명과 얼마나 비슷한가"를 잰 것에 불과하다. 논문은 그래서 가드를 정확도 문제가 아니라 선택적 분류(selective classification) 문제로 다시 세운다 — 모든 입력에 답하는 대신 "나는 이 건을 자신 있게 판정할 수 없다"고 기권할 수 있는 분류기를 말한다. 여기에 비용 비대칭(위험한 걸 통과시키는 손해가 안전한 걸 막는 손해보다 훨씬 크다)을 얹으면 가드의 작동 한계를 측정할 수 있게 된다. 그리고 측정해 보니, 어려운 입력에서는 가드가 안전하게 자동 판정할 수 없다는 결론이 나왔다.

깨진 전제 둘 — 그리고 여기서 곡선이 뒤집힌다

두 번째 전제는 더 크다. 사람은 무한히 가용한 완벽한 오라클이라는 가정이다. 논문은 이 자리에 "피로해지는 리뷰어" 모델을 넣었다. escalation(사람에게 넘기는 것) 부하가 커질수록 판단 품질이 떨어지는, 시스템 내부 변수로서의 사람이다. 그러자 결과가 뒤집혔다.

다이어그램 설명. 사람을 부르는 비율이 낮을 때와 높을 때 양쪽 다 사고로 끝난다는 게 이 그림의 전부다. "너무 낮다" 쪽은 직관적이다 — 안 물어봤으니 위험한 게 통과한다. 문제는 "너무 높다" 쪽이다. 다 물어보긴 하는데, 리뷰어가 지쳐서 판단 품질이 떨어지기 때문에 통과시켜서는 안 될 것을 통과시킨다. 그래서 실제로 얻어지는 안전성은 중간에서 최대가 되는 뒤집힌 U자 모양이 된다. 여기서 놓치기 쉬운 함정은 이 곡선이 사람의 성실성 문제가 아니라는 것이다. 부하가 늘면 판단이 나빠지는 건 심리학적으로 잘 확립된 현상이고, 열심히 하려는 의지로 상쇄되지 않는다. 설계로 상쇄해야 한다.

논문이 여기서 한 걸음 더 나간 대목이 특히 실무적이다. 부하를 인지하는 정책은 밀어넣기 공격(flooding attack)에도 저항한다. 공격자가 무해해 보이는 행동을 대량으로 발생시켜 리뷰어를 지치게 만든 다음, 그 틈에 악의적인 행동 하나를 끼워 넣는 시나리오다. 부하를 보지 않는 가드는 이 공격을 감지할 방법이 없다 — 각 건은 개별적으로 보면 다 정상이니까. 부하를 상태로 들고 있는 가드만이 "지금 이 리뷰어는 신뢰할 수 있는 상태가 아니다"를 판단할 수 있다.

왜 이게 중요한가. 우리가 에이전트 안전 설계를 이야기할 때 거의 항상 "무엇을 막을 것인가"만 논의한다. 이 연구가 보여주는 건 얼마나 자주 부를 것인가가 그 자체로 독립적인 설계 변수라는 점이다. 그리고 그 변수의 최적값은 최대값이 아니다.

학계의 처방 — "언제 넘길까"를 최적화 문제로 세운다

사실 "AI가 판단할지 사람에게 넘길지"를 학습 대상으로 삼는 연구 계보는 LLM 에이전트보다 훨씬 오래됐다. Learning to Defer(L2D, 넘김을 학습하기)라 불리는 흐름이고, 최근 몇 년 사이 이 계보가 정확히 "사람의 용량"을 향해 진화해 왔다.

다이어그램 설명. 이 계보가 향한 방향은 하나다 — 사람을 점점 더 현실적으로 모델링하는 쪽. "2017 Predict Responsibly"(Madras·Pitassi·Zemel, arXiv 1711.06664)는 모델이 어떤 건을 하위 결정자에게 넘길지를 학습 목표에 넣었다. 이때 사람은 여전히 고정된 성능을 가진 블랙박스다. "2022 Beyond Learning to Defer"(Leitão 외, arXiv 2206.13202)는 이 계열이 현장에 안 맞는 이유를 정리했는데, 그중 하나가 용량 관리(capacity management)의 부재였다. "2024 DeCCaF"(Alves 외, arXiv 2403.06906)는 전문가마다 다른 오류 비용과 처리 한도를 제약 조건으로 넣고 제약 프로그래밍으로 배분을 푼다. "2026 FALCON"(Zhang 외, arXiv 2604.00904)은 마지막 가정까지 걷어낸다 — 같은 사람의 성능이 누적 업무량에 따라 달라진다고 본다.

FALCON의 방법이 특히 앞의 역U자 논의와 정확히 맞물린다. 이 연구는 심리학에서 확립된 피로 곡선을 L2D에 집어넣고, 문제를 제약 마르코프 결정 과정(Constrained Markov Decision Process)으로 세운다. 마르코프 결정 과정은 "현재 상태에서 어떤 행동을 고를지"를 반복해서 결정하는 문제 틀이고, 여기에 제약을 얹으면 "정해진 예산 안에서" 최적을 찾는 형태가 된다. 핵심은 상태에 무엇을 넣었느냐다 — 이 건의 난이도(task features)뿐 아니라 지금까지 사람이 처리한 누적량이 함께 상태로 들어간다. 그래서 정책은 같은 난이도의 건이라도 하루 초반이냐 후반이냐에 따라 다르게 배분할 수 있다.

왜 이게 중요한가. "사람에게 물어볼까 말까"를 매번 그 건만 보고 결정하면, 아무리 잘 설계해도 하루 끝 무렵의 판단 품질 저하를 반영할 수 없다. 이 계보가 말하는 것은 배분 결정에 시간과 누적량이 들어가야 한다는 것이다. 개인 작업으로 옮기면 이런 형태가 된다 — 위험한 작업일수록 내 집중력이 남아 있는 시간대에 몰아 두고, 늦은 시간에는 되돌릴 수 있는 것만 자동으로 흘려보낸다.

커뮤니티의 처방 — 질문을 줄이는 대신 한곳에 모은다

오픈소스 쪽의 대응은 결이 다르다. 학계가 "몇 건을 넘길지"를 최적화한다면, 커뮤니티는 넘긴 건을 사람이 처리하는 방식 자체의 비용을 깎는 쪽으로 갔다. 가장 널리 퍼진 형태가 인박스다.

LangChain의 langchain-ai/agent-inbox(깃허브 별 1,082개, 2026년 8월 24일에도 커밋이 올라오는 활성 저장소)가 대표적이다. 이름 그대로 사람의 승인을 기다리는 에이전트들의 요청을 메일함처럼 한 화면에 모아 놓는 UI다. 알림이 오는 대로 하나씩 응답하는 대신, 쌓아 두고 한 번에 훑는다. 여기서 중요한 것은 응답의 종류다.

다이어그램 설명. 이 네 갈래는 agent-inbox가 정의한 HumanResponse 타입이 그대로다(accept, edit, response, ignore). 눈여겨볼 것은 ignore가 일급 응답이라는 점이다. 승인/거부 두 갈래만 있는 설계에서는 "이 건은 판단할 가치가 없다"를 표현할 자리가 없어서, 사람이 어쨌든 둘 중 하나를 고르게 된다 — 그게 곧 무의미한 주의력 소모다. 또 하나는 요청마다 allow_ignore·allow_respond·allow_edit·allow_accept 플래그를 따로 켤 수 있다는 점인데, 이건 요청을 만든 쪽이 "이 건에서 사람이 할 수 있는 일"을 미리 좁혀 준다는 뜻이다. 선택지를 좁히는 것 자체가 판단 비용을 줄인다.

같은 방향의 더 급진적인 형태가 「Overhearing LLM Agents」(arXiv 2509.16325)가 정리한 계열이다. 이 논문은 대화에 끼어들지 않고 주변 활동을 계속 듣고 있다가 도움이 될 수 있을 때만 개입하는 에이전트를 하나의 독립된 패러다임으로 놓고 분류 체계를 세웠다. 진료 상담이 오가는 동안 조용히 관련 정보를 준비해 두거나, 교사들이 수업 계획을 논의하는 사이에 자료를 미리 모아 두는 식이다. 채팅 인터페이스가 사람의 주의를 요구하는 것을 기본값으로 삼는 데 반해, 이쪽은 침묵을 기본값으로 삼는다.

개입 시점을 아예 계산의 대상으로 삼은 사례도 있다. ProMemAssist(arXiv 2507.21378)는 사용자의 작업 기억(working memory) 상태를 모델링해서 도움의 가치와 방해의 비용을 견주어 개입 시점을 고른다. "지금 말을 걸면 무엇이 끊기는가"를 변수로 들고 있는 것이다.

왜 이게 중요한가. 인박스·침묵 기본값·개입 시점 계산은 서로 다른 기법처럼 보이지만 같은 것을 노린다 — 맥락 전환 비용. 승인 요청 20건을 20번의 알림으로 받는 것과 한 화면에서 20줄로 받는 것은, 결정의 개수는 같아도 소모되는 주의력이 전혀 다르다.

그리고 감시 자체가 주의력을 먹는다

마지막으로 반대편 증거를 하나 보자. 「Dark Patterns Meet GUI Agents」(arXiv 2509.10723)는 다크 패턴(사용자를 속이도록 설계된 인터페이스) 16종에 대해 사람·에이전트·사람+에이전트 팀이 각각 어떻게 반응하는지를 실험했다. 결과가 흥미롭다. 사람과 에이전트는 서로 다른 이유로 무너졌다 — 사람은 인지적 지름길과 습관적 순응 때문이었고, 에이전트는 절차적 맹점 때문이었다. 그리고 사람의 감시를 붙이면 회피율은 올라갔지만, 주의 터널링(attentional tunneling)과 인지 부하라는 비용이 새로 생겼다. 논문의 결론은 "협업이 새로운 취약점을 만든다"였다.

이건 앞의 역U자 곡선과 같은 이야기를 다른 각도에서 하고 있다. 감시는 공짜로 얹히는 안전장치가 아니다. 사람을 감시자 자리에 앉히는 순간 그 사람의 주의력 예산에서 돈이 빠져나간다. 어딘가를 열심히 보게 만들면 다른 곳을 못 보게 되고(주의 터널링이 정확히 그것이다), 그 다른 곳이 진짜 문제였을 수 있다.

정리 — 승인 버튼의 개수가 아니라 예산을 설계한다

흩어져 있던 논의들이 결국 한 문장으로 모인다. 사람의 주의력은 시스템 밖에 있는 무한 자원이 아니라, 시스템 안에서 소모되고 회복되는 유한한 상태 변수다. 그렇게 보기 시작하면 설계 질문이 통째로 바뀐다.

지금까지의 질문은 "무엇을 막을 것인가"였다. 바뀐 질문은 이렇다 — 내 하루치 주의력을 어떤 결정들에 쓸 것인가. 이건 안전 문제가 아니라 자원 배분 문제다. 그래서 학계는 이걸 제약 조건이 붙은 최적화로 풀고(FALCON의 CMDP), 커뮤니티는 단위 결정의 비용을 깎는 인터페이스로 푼다(agent-inbox의 인박스와 ignore).

개인 작업에 옮길 때 가장 먼저 할 일은 최적화가 아니라 측정이라고 생각한다. 오늘 에이전트가 나를 몇 번 불렀는지, 그중 내가 실제로 읽고 판단한 건 몇 번인지. 그 두 숫자가 벌어져 있다면, 게이트를 더 거는 것은 상황을 악화시킨다. 나머지를 자동으로 흘려보내도 되게 만들거나, 스무 개의 알림을 한 화면으로 합치는 쪽이 먼저다. 승인 버튼을 하나 더 다는 것과 내가 그걸 실제로 읽을 여력을 남겨 두는 것은 전혀 다른 일이다.

---

참고한 공개 자료:

• Emre Turan, 「Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human」 (2026-06) — arxiv.org/abs/2606.08919
• David Madras, Toniann Pitassi, Richard Zemel, 「Predict Responsibly: Improving Fairness and Accuracy by Learning to Defer」 (2017-11) — arxiv.org/abs/1711.06664
• Diogo Leitão 외, 「Human-AI Collaboration in Decision-Making: Beyond Learning to Defer」 (2022-06) — arxiv.org/abs/2206.13202
• Jean V. Alves 외, 「Cost-Sensitive Learning to Defer to Multiple Experts with Workload Constraints」 (2024-03) — arxiv.org/abs/2403.06906
• Zheng Zhang 외, 「Fatigue-Aware Learning to Defer via Constrained Optimisation」 (2026-04) — arxiv.org/abs/2604.00904
• 「Overhearing LLM Agents: A Survey, Taxonomy, and Roadmap」 (2025-09) — arxiv.org/abs/2509.16325
• 「ProMemAssist: Exploring Timely Proactive Assistance Through Working Memory Modeling in Multi-Modal Wearable Devices」 (2025-07) — arxiv.org/abs/2507.21378
• 「Dark Patterns Meet GUI Agents: LLM Agent Susceptibility to Manipulative Interfaces and the Role of Human Oversight」 (2025-09) — arxiv.org/abs/2509.10723
• LangChain Agent Inbox — github.com/langchain-ai/agent-inbox

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.