AI 에이전트 승인 요청 병목 — 응답 속도가 아니라 유입량이었다

무엇이 문제였나 — 줄지 않는 AI 에이전트 승인 요청

AI 에이전트 승인 요청이 쌓인 원인은 사람의 응답 속도가 아니라 사람에게 올라오는 요청의 양이었습니다. 이 결론에 닿기까지 우리는 반대 방향의 가설부터 세웠고, 그 가설을 따라 만든 장치가 숫자로 반증당했습니다. 아래에서 처음 잰 숫자, 틀린 가설, 진짜 원인, 고친 방법, 다시 잰 숫자 순서로 적습니다.

우리 회사는 대표 한 명과 여러 AI 에이전트로 굴러갑니다. 에이전트는 코드 수정, 문서 작성, 데이터 수집처럼 되돌릴 수 있는 일은 혼자 끝냅니다. 하지만 돈이 나가는 일, 고객에게 메일을 보내는 일, 가격이나 타깃을 바꾸는 일은 혼자 끝내지 않습니다. 그런 일을 만나면 결정 큐에 요청을 한 줄 적고, 대표가 승인할 때까지 그 일을 멈춥니다.

설계 의도는 단순했습니다. 사람은 꼭 사람만 내릴 수 있는 결정에만 손을 대고, 나머지는 에이전트가 알아서 처리합니다. 그런데 운영해 보니 결정 큐가 줄지 않았습니다. 대표는 어느 날 이렇게 적었습니다. 「내가 지시·결정의 병목이다, 완전 위임 시스템을 만들어라」. 승인 요청이 밀리면 에이전트도 그 뒤에서 멈추니, 결정 큐의 길이가 곧 회사 전체의 속도 상한이었습니다.

내가 지시·결정의 병목이다, 완전 위임 시스템을 만들어라.

이 문제는 사람에게 승인을 받는 AI 에이전트를 운영하는 팀이라면 어디서나 생길 수 있습니다. 승인 게이트를 촘촘하게 두면 안전하지만 사람이 병목이 되고, 느슨하게 두면 빠르지만 되돌릴 수 없는 실수가 밖으로 나갑니다. 우리가 승인 게이트의 범위를 어떻게 정했는지는 AI 에이전트 승인 게이트를 줄인 기록에 따로 적었습니다. 이 글은 그 범위를 정한 뒤에도 남은 문제, 즉 범위 안으로 들어오는 요청의 양을 다룹니다.

처음 잰 숫자 — 응답 0.67시간, 생성 하루 9.7건

감으로 판단하지 않으려고 결정 큐 목록 파일 전체를 다시 셌습니다. 측정 대상은 세 가지였습니다. 사람이 요청을 받은 뒤 답하기까지 걸린 시간, 하루에 새로 생기는 요청 수, 하루에 사람이 닫는 요청 수입니다. 목록 파일에는 요청이 생긴 시각과 해소된 시각, 해소한 주체가 한 줄씩 남아 있어서, 이 값들을 기록에서 바로 뽑을 수 있었습니다.

결과는 예상과 달랐습니다. 사람의 결정 응답 중앙값은 0.67시간이었습니다. 한 시간도 안 걸려 답한다는 뜻이니, 사람이 늦장을 부려서 밀린 게 아니었습니다. 반면 결정은 하루 9.7건씩 새로 생겼고, 사람이 하루에 닫는 결정은 1.87건이었습니다. 들어오는 양이 나가는 양을 크게 웃돌았으니 큐가 줄 수 없는 구조였습니다.

해소된 결정의 내역도 뜯어봤습니다. 해소된 390건 가운데 사람이 실제로 거절한 건은 21건으로 5%였습니다. 취소되거나 만료된 건은 153건으로 39%였습니다. 사람이 내용을 보고 「아니다」라고 판단한 경우보다, 시간이 지나 의미가 없어졌거나 애초에 결정할 거리가 아니었던 경우가 훨씬 많았습니다.

지시 쪽도 같은 방식으로 셌습니다. 대표가 에이전트에게 내리는 지시는 하루 53건이었는데, 그중 대표만 내릴 수 있는 고유 몫은 8%였습니다. 나머지는 「계속해」, 「이어서」처럼 에이전트가 스스로 판단해도 되는 진행 신호였습니다. 숫자는 한쪽을 가리켰습니다. 사람이 느린 게 아니라, 사람에게 너무 많은 것이 올라오고 있었습니다.

처음 세운 가설은 무엇이었나 — 알림을 늘리면 빨리 닫힌다

숫자를 보기 전, 우리는 정반대로 생각했습니다. 결정이 밀리는 이유는 사람이 결정 큐를 열어 보지 않아서이고, 그러니 요청을 사람 눈앞에 더 자주 들이밀면 닫힌다고 봤습니다. 이 가설에 따라 만든 장치가 대화 릴레이입니다. 사람이 에이전트와 대화하는 화면 끝에, 밀린 결정을 한 건씩 꺼내 붙여 보여 주는 방식입니다.

두 번째로 떠올린 방법은 대시보드 버튼이었습니다. 승인·기각을 한 번의 클릭으로 끝낼 수 있게 하면 사람의 수고가 줄어 처리량이 늘어난다고 봤습니다. 세 번째는 외부 도구였습니다. Symphony나 OpenHands 같은 에이전트 작업 조율 도구를 들이면 일 분배가 정리된다는 생각이었습니다. 네 번째는 가장 과격한 안으로, LLM이 승인 요청을 읽고 자동으로 승인하게 하는 방법이었습니다.

• **알림·릴레이 강화** — 밀린 결정을 사람 눈앞에 더 자주 보여 준다
• **대시보드 버튼** — 승인·기각을 클릭 한 번으로 끝낸다
• **외부 조율 도구 도입** — Symphony·OpenHands로 일 분배를 정리한다
• **LLM 전자동 승인** — 모델이 요청을 읽고 스스로 승인한다

네 가지 모두 공통 전제를 깔고 있었습니다. 큐에 올라온 요청은 전부 정당하게 올라온 것이고, 문제는 그걸 처리하는 출구 쪽에 있다는 전제입니다. 이 전제를 따로 의심하지 않았다는 점이 나중에 드러난 실수의 출발점이었습니다.

가설은 어디서 틀렸나? — 148번 보여 주고 해소 0

가장 먼저 무너진 건 알림 가설이었습니다. 릴레이는 실제로 돌고 있었고, 기록을 보니 밀린 결정 19건을 사람에게 148번 보여 줬습니다. 그 결과 해소된 건은 0이었습니다. 사람은 보고 있었지만 닫지 않았습니다. 보여 주는 횟수를 늘려도 닫히지 않는다면, 문제는 사람이 못 봐서가 아니라 그 요청이 사람이 닫을 이유가 없는 요청이라는 데 있었습니다.

대시보드 버튼도 같은 이유로 접었습니다. 대표가 「이어서」를 누적 8회 입력한 기록이 있었는데, 이건 결정이 아니라 진행 신호였습니다. 클릭 한 번이라도 결정은 결정입니다. 버튼을 만들면 사람이 하는 판단 횟수는 그대로이고 손가락 움직임만 줄어듭니다. 우리가 줄여야 하는 건 클릭 수가 아니라 판단 횟수였습니다.

외부 조율 도구는 필요가 없었습니다. 이미 돌고 있는 백로그 처리기가 94% 완료율로 일을 소화하고 있었습니다. 에이전트가 일을 못 나눠서 막힌 게 아니니, 조율 도구를 들여도 결정 큐의 길이는 그대로였을 겁니다. LLM 전자동 승인은 위험 쪽에서 막혔습니다. 외부 실험 Project Vend 2에서 모델이 관대하게 승인하는 경향이 8배로 나왔고, 돈·외부 발송·사업 방향 같은 승인 게이트 1~3번 범주는 사람 몫으로 남겨야 했습니다.

네 대안을 모두 기각하고 나서야 공통 전제가 보였습니다. 우리는 출구만 보고 있었습니다. 숫자는 입구를 가리키고 있었는데도 말입니다.

진짜 원인은 무엇이었나 — 출구가 아니라 입구

방향을 바꿔 당시 대기 중이던 100건을 한 건씩 분류했습니다. 질문은 하나였습니다. 「이 요청은 애초에 사람에게 올라와야 했나?」 답은 100건 중 38건이 오지 말았어야 했다는 것이었습니다. 처리 속도가 아니라 입구에서 거르지 않은 것이 진짜 원인이었습니다.

38건의 내역은 이랬습니다. 같은 제목의 요청이 중복으로 올라온 것이 18건이었습니다. 판정을 요청하지 않는 공지가 결정 큐에 섞인 것이 5건, 오래 멈춘 백로그 작업을 계속할지 판정해 달라는 요청이 5건이었습니다. 나머지는 코드 구조 같은 기술 판정과 주간 요약 브리프였습니다. 기술 판정은 에이전트가 내려야 하는 결정이고, 요약은 애초에 결정이 아닙니다.

이 분류에서 앞서 본 숫자들이 설명이 됐습니다. 해소 390건 중 취소·만료가 153건이나 된 이유는, 그중 상당수가 처음부터 결정 거리가 아니었기 때문입니다. 릴레이를 148번 보여 줘도 닫히지 않은 이유도 같습니다. 사람은 중복이나 공지를 보고 「이건 내 일이 아닌데」라고 넘겼을 뿐입니다.

구체 사례도 하나 있었습니다. 설계 문서를 다른 에이전트가 비평한 결과 중 조건부 통과 판정이 결정 큐로 올라오고 있었는데, 과거 17건은 전부 기술 담당 에이전트와 전략 담당 에이전트가 처리했고 사람이 해소한 건은 0건이었습니다. 또 문의 회신 초안 9건 중 7건은 카페24, KCP, 소프트웨어산업협회 같은 곳의 자동 통지였고, 초안 작성기 스스로 첫 줄에 「회신하지 않는다」고 적어 둔 상태였습니다. 같은 종류의 과거 13건도 에이전트와 시스템이 손으로 닫았습니다.

조치 — LLM 없이 규칙만 쓰는 입구 필터

원인이 입구였으니 입구에 필터를 달았습니다. 에이전트가 결정 큐에 요청을 올리는 함수가 하나 있는데, 그 함수가 요청을 적은 직후 필터를 한 번 부르도록 연결했습니다. 필터는 요청을 다섯 갈래 중 하나로 판정합니다.

• **병합(merge)** — 같은 제목·같은 내용의 대기 요청이 이미 있으면 기존 건에 주석을 달고 새 건은 취소
• **종결(close)** — 결정이 아니라 공지·요약이면 취소만
• **손 작업 이관(handover)** — 서명·방문처럼 판정이 아니라 사람이 손으로 할 단계면 할 일 목록으로 이관
• **위임(delegate)** — 정체 백로그 판정, 설계 비평 조건부 통과, 회신이 필요 없는 자동 통지처럼 에이전트 영역이면 작업 목록으로 이관
• **사람에게(기본값)** — 그 외 전부. 승인 게이트, 돈, 외부 발송, 신원, 판정 불가

판정에는 LLM을 쓰지 않았습니다. 정규식과 요청의 종류 필드만 봅니다. 이유는 오판 비용이 비대칭이기 때문입니다. 사람에게 오지 않아도 될 요청이 올라오면 대표가 몇 초 낭비할 뿐이지만, 사람이 꼭 봐야 할 결정이 사라지면 돈이 나가거나 잘못된 메일이 고객에게 갑니다. 그래서 모호하면 사람 쪽으로 보내고(fail-safe), 필터 자체가 오류를 내면 요청을 그대로 통과시킵니다(fail-open). 결정이 사라지는 것보다 올라오는 쪽이 안전합니다.

위임할 때도 안전장치를 하나 걸었습니다. 요청을 작업 목록으로 옮기는 명령이 성공해야만 결정을 닫습니다. 이관이 실패했는데 결정만 닫히면 일감이 통째로 사라지기 때문입니다. 그리고 판정 하나하나를 기록 파일에 남겨, 나중에 무작위로 표본을 뽑아 오판을 점검할 수 있게 했습니다.

반복 패턴을 배우는 장치도 넣었습니다. 사람이 직접 해소한 결정을 종류별로 모아, 「내 결정 아님」으로 취소한 건이 4건 이상이고 거절이 0이며 취소 비율이 75% 이상인 종류는 위임 판례로 올립니다. 승인 쪽은 학습하지 않습니다. 사람이 자주 승인했다고 그 종류를 자동 승인하기 시작하면, Project Vend 2에서 본 관대 승인 문제를 우리가 직접 재현하는 셈입니다.

재측정 결과 — 100건이 68건으로, 그리고 숨은 유출 13건

필터를 당시 대기 중이던 결정에 소급 적용했습니다. 대기 100건이 68건으로 줄었습니다. 숫자만 보면 성공이었습니다. 하지만 이 결과를 그대로 믿지 않고, 이 작업의 맥락을 전혀 모르는 새 에이전트에게 필터 코드와 결과를 넘겨 적대적으로 공격하게 했습니다. 만든 쪽은 자기 판정이 맞다고 믿기 쉬우니, 맥락이 0인 검토자가 필요했습니다.

적대 검토자는 가장 심각한 등급(P0)의 결함 4건을 찾았습니다. 그 결과 사업 방향을 다루는 승인 게이트 3번 결정 13건이 큐에서 빠져 있었습니다. 필터가 사람이 꼭 봐야 할 결정을 「중복」이나 「공지」로 판정해 치워 버린 것입니다. 100건에서 68건으로 줄인 숫자 안에 이 13건이 섞여 있었습니다.

사업 방향 결정 13건이 큐에서 빠져 있었다(제목만 보고 판정 · 병합/종결이 승인 게이트 검사보다 먼저).

원인은 두 가지였습니다. 첫째, 제목만 보고 판정했습니다. 오래 멈춘 백로그 판정 요청은 「사업 방향」 표지가 제목이 아니라 본문 데이터 안에만 들어 있었는데, 필터는 제목만 검사했습니다. 둘째, 판정 순서가 틀렸습니다. 병합과 종결 판정이 사람 몫 표지 검사보다 먼저 돌았습니다. 그래서 사업 방향 결정이라도 제목이 다른 건과 같으면 먼저 병합으로 빠져 버렸습니다.

작은 결함도 같이 나왔습니다. 제목을 비교하기 전에 숫자를 지우는 정규화를 했더니, 위시켓 공고 번호 158742와 158743처럼 서로 다른 두 건이 같은 요청으로 합쳐졌습니다. 또 주간 사업 결정 브리프를 요약으로 보고 종결 목록에 넣었는데, 과거 기록을 보니 대표가 그 브리프의 안건을 실제로 승인한 적이 있었습니다. 요약처럼 생겼어도 결정을 담고 있었습니다.

수리 뒤 다시 잰 숫자는 어땠나 — 공격 25건, 과거 420건, 유출 0

빠진 13건부터 큐에 되살렸습니다. 그다음 필터를 세 군데 고쳤습니다. 사람 몫 표지 검사를 다른 모든 판정보다 앞으로 옮겼습니다. 표지 검사 범위를 제목에서 요청 본문 데이터 전체로 넓혔습니다. 병합은 제목이 글자 그대로 같고 본문 내용까지 같을 때만 하도록 좁혔고, 숫자를 지우는 정규화는 없앴습니다. 주간 사업 결정 브리프는 종결 목록에서 뺐습니다.

수리 뒤에는 같은 적대 검토를 다시 돌렸습니다. 검토자가 필터를 속이려고 만든 공격 사례 25건과, 결정 큐에 쌓인 과거 결정 420건을 새 필터로 재판정했습니다. 승인 게이트 표지가 붙은 결정이 사람 쪽이 아닌 다른 갈래로 빠진 경우는 0건이었습니다. 결정 기록 시점의 대기 건수는 81건이었습니다. 1차 결과 68건에 되살린 13건을 더한 값과 같습니다.

2차 검토에서도 놓칠 뻔한 경계가 나왔습니다. 회신이 필요 없는 자동 통지를 거르는 규칙을 다듬으면서, 피싱이나 스팸이라는 판단은 LLM이 내린 추정이지 사실 확인이 아니라는 점을 반영했습니다. 그런 표지가 있으면 거르지 않고 사람에게 보냅니다. 플랫폼 발신 전용 메일이라도 첫 줄이나 제목에 의뢰·주문·견적 같은 말이 있으면 실제 주문일 수 있으니 역시 거르지 않습니다. 판정은 초안의 첫 줄 200자 안에서만 보고, 작성기가 실제로 판정을 첫 줄에 적는다는 점은 14건 중 14건에서 확인했습니다.

남는 한계 — 감소폭은 작고, 판정은 아직이다

이 필터로 결정 큐 문제가 풀렸다고 말하기는 이릅니다. 첫째, 감소폭이 작습니다. 모호하면 사람 쪽으로 보내는 보수적 설계라, 대기 100건이 최종적으로 81건이 됐을 뿐입니다. 처음 분류에서 오지 말았어야 할 요청은 38건이었으니, 필터는 그중 일부만 걸렀습니다. 안전을 택한 대가로 감소폭을 내줬습니다.

둘째, 들어오는 속도 자체는 아직 다시 재지 않았습니다. 결정이 하루 9.7건 생기고 사람이 1.87건 닫는 구조가 필터 뒤에 얼마나 바뀌었는지는, 필터가 며칠 이상 돌아야 나옵니다. 그래서 완료 판정일을 2026년 10월 13일로 미리 정해 두었습니다. 그날 새 결정 수, 필터 처리 수, 필터가 닫았다가 다시 살아난 건수를 세어 판정합니다.

셋째, 오판을 사람 판단이 아니라 관측으로 세는 장치가 아직 짧은 기록만 가지고 있습니다. 필터가 닫은 결정이 나중에 다시 올라오면, 그건 필터가 틀렸다는 뜻이므로 오판 1건으로 셉니다. 이 숫자가 0이 아니면 해당 규칙을 좁히는 것이 원칙입니다. 다만 기록이 쌓이기 전까지는 무작위 표본 점검에 기댈 수밖에 없습니다.

마지막으로, 이번에 가장 크게 배운 건 필터 자체보다 검증 방식이었습니다. 만든 쪽이 잰 100건에서 68건이라는 숫자는 성공처럼 보였지만, 그 안에 사업 방향 결정 13건이 섞여 있었습니다. 맥락이 없는 검토자에게 공격을 맡기지 않았다면 이 유출은 다음 사고가 날 때까지 보이지 않았을 겁니다.

다른 팀이 가져갈 수 있는 것은 무엇인가

사람 승인을 받는 AI 에이전트를 운영하고 있다면, 승인 대기가 쌓일 때 알림부터 늘리기 전에 두 숫자를 먼저 재 보길 권합니다. 사람의 응답 중앙값과, 하루 생성 대비 하루 해소 비율입니다. 응답이 빠른데 큐가 불어난다면 문제는 출구가 아니라 입구에 있습니다. 우리 경우 응답은 0.67시간이었고, 생성은 하루 9.7건, 해소는 1.87건이었습니다.

입구 필터를 만든다면 판정 순서를 가장 먼저 설계해야 합니다. 사람 몫 표지 검사는 병합·종결·위임 같은 다른 모든 판정보다 앞에 와야 하고, 검사 범위는 제목이 아니라 요청 전체여야 합니다. 그리고 필터가 줄인 숫자를 믿기 전에, 맥락 없는 검토자에게 「사람이 봐야 할 결정이 새는 경우」를 찾게 하십시오. 우리 필터는 그 단계에서 13건을 토해 냈습니다.

회사 업무에 AI 에이전트를 들이면서 어디까지 맡기고 어디부터 사람이 쥐어야 할지 고민하고 있다면 상담으로 상황을 알려 주십시오. 우리가 직접 겪은 실패 기록을 바탕으로 같이 따져 보겠습니다.