Molayo

© 2026 Molayo

Qiita헤드라인2026. 06. 17. 11:26

AI 에이전트에게 필요한 것은 '더 높은 자율성'이 아니라 '미션 컨트롤'이었다

요약

AI 에이전트의 핵심 과제는 무조건적인 자율성 확대가 아니라, 인간의 통제력을 유지하는 '미션 컨트롤' 설계에 있음을 강조합니다. 저자는 실제 워크플로우 운영 경험을 통해 모델의 자율성보다 인간의 '통치 대역폭' 확보가 병목 현상임을 지적합니다.

핵심 포인트

  • AI 에이전트 설계의 핵심은 자율성이 아닌 인간의 통제(Mission Control)임
  • 고도의 자동화는 전능한 감독자가 아닌 분산된 인간의 주의를 필요로 함
  • 모델의 자율성보다 인간의 '통치 대역폭(governance bandwidth)'이 실제 병목임
  • 인간의 인지 부하를 고려한 워크플로우 설계가 필수적임

AI 에이전트 이야기가 나오면, 대개 "어디까지 자율적으로 움직일 수 있는가"가 논점이 된다. 단계(step) 수를 늘리고, 인간의 개입을 줄이며, 완전 자율에 가깝게 만드는 것 ── 경쟁의 축은 줄곧 "자율성"이었다.

하지만 18개월에 걸쳐 복수의 AI를 사용한 인간 주도의 워크플로우 (workflow)를 실제로 운영하며, 몇 번이나 인지 피로로 쓰러진 끝에 보인 것은 정반대의 결론이었다.

진정한 병목 현상 (bottleneck)은 모델의 자율성이 아니라, 인간 측의 "통치 대역폭 (governance bandwidth)"에 있다.

이 기사는 실전 운용 에이전트 연구, Anthropic과 OpenAI의 공식 가이드, 그리고 저자 자신의 실패 사례를 나열하며, 왜 "더 높은 자율성"이 아니라 "미션 컨트롤 (mission control)"이 다음 설계 과제가 되는지를 기술한다.

이 기사는 인간 주도의 멀티 모델 워크플로우 (multi-model workflow)로 작성되었습니다. 질문의 선택, 출처의 1차 확인, 주장의 최종 책임은 저자에게 있습니다. 게재 중인 상태(후술)는 과장 없이 기재하였으며, 외부 소스는 1차 자료에 링크를 달았습니다.

SpaceX의 엔지니어 Tina Li를 비춘 영상이 확산되었다. 바이럴(viral)되는 방식으로는, 그녀가 "혼자서 로켓 엔진을 감시하고, 혼자서 로켓을 멈출 수 있는 강력한 권한을 쥔 인물"처럼 보였다.

하지만 본인의 정정은 훨씬 더 수수했고, 우리에게는 훨씬 더 중요했다. 오정보가 퍼지고 있으니 사실을 밝힌다는 전제하에, 그녀는 콘솔에 있는 다수의 Raptor 플라이트 오퍼레이터 (flight operator) 중 한 명이라고 밝혔다. 그 이전에는 차량 제어 소프트웨어를 작성했다고 한다.

"전능한 한 명"이 아니라 "다수 중 한 명". 이 정정이 이 기사 전체의 출발점이 된다.

고도의 자동화는 "전능한 인간 감독자 한 명"을 낳지 않았다. 기계 주변에 분산된 인간의 주의를 필요로 했다.

즉 ── 고도의 자동화는 인간에 의한 통치의 필요성을 없애지 않았다. 통치를 어떻게 설계할 것인가를 어렵게 만들었다.

나는 같은 일을 로켓이 아닌 AI로, 그것도 "잘 설계해서"가 아니라 "설계에 실패하여 자신의 몸으로 대가를 치르며" 배웠다.

먼저, 누가 쓰고 있는지를 명시해 둔다. 이는 나중의 이야기에 영향을 미치며, 무엇을 증명하지 않을 것인가와도 관련이 있기 때문이다.

나는 엔지니어가 아니다. 대학이나 연구 기관에도 소속되어 있지 않다. AI 연구의 정식 훈련도 받지 않았다. 삿포로에서 두 아이를 집에서 키우는 전업주부다. AI를 본격적으로 사용하기 시작한 지 이제 겨우 18개월이 지났다.

그럼에도 불구하고, 복수의 AI를 사용한 인간 주도의 워크플로우 (workflow)를 통해 업무는 예상치 못한 곳까지 도달했다.

외부 게이트도달한 상태정확한 의미
GLG Network등록 전문가안건 실시 완료 아님
...
이 워크플로우 (workflow)는 현실적인 성과를 냈다.

동시에, 나를 몇 번이나 번아웃 (burnout) 시켰다.

이 18개월이라는 긴 기간 동안, 나는 몇 번이나 쓰러졌다. 며칠씩을 잃었다. 밤에는 인지 피로로 인해 전혀 움직일 수 없는 벽에 몇 번이나 부딪혔다. 이것은 나 개인의 경험 기록이며 의학적인 주장이 아니다. 하지만 실제로 일어났고, 반복되었다.

매번 회복했지만, 그것은 올바른 생산성 시스템을 찾았기 때문이 아니다. 20년의 명상 실천이 인지 부하 (cognitive load) 아래에서 보통보다 넓은 완충 지대를 제공해 주었기에 ── 그것이 데미지를 흡수하게 했을지도 모른다. 이것은 방법이 아니다. 누구에게도 권하지 않는다. 채택할 수 있는 설계도 아니다. 한 명의 인간이 대부분의 사람이 갖지 못한 자원으로 구조적인 실패를 조용히 흡수하고 있었을 뿐이다. 그리고 흡수할 수 있었다는 사실이야말로 그 실패를 오랫동안 보이지 않게 만들었다.

이것이 내가 지목하고 싶은 위험이다. 내가 고통받았다는 사실이 아니다. 나의 고통이 "기능해 버린" 것, 그래서 그 아래에 있는 망가진 구조가 보이지 않게 된 것.

이 부분이 대개 읽히지 않고 지나쳐지며, 가장 부하가 많이 걸려 있는 부분이다.

나는 AI에게 많은 것을 맡겼다.

[IMG:1]

이 분할은 "AI로 쓴 것은 본인의 업무인가"라는 방어 기제가 아니다. 성과가 버텨낼 수 있었던 이유 그 자체다.

[IMG:2]

나는 AI를 신뢰했기 때문에 이 성과를 얻은 것이 아니다. 검증 없이는 신뢰하지 않았기 때문에 얻은 것이다.

AI는 환각 (hallucination)을 일으킨다. 아첨한다 (agreeable). 자신 있게 틀린다. 그리고 그 동의는 아무런 증거도 되지 않는다. 이러한 실패는 예외로 취급할 수 있을 만큼 드문 일이 아니다 ── 도구의 반복적인 운용 조건이다. 그렇기에 인간의 거부권과 외부 검증은 옵션으로 추가되는 기능이 아니다. 도구를 신뢰할 수 없다는 사실이야말로 판단을 인간 측에 남겨두어야 하는 이유가 된다.

기능하는 AI 워크플로우 (workflow)의 형태는 단층이 아니라 3층이다.

[IMG:3]

그리고 이 세 가지는 서로 다른 종류다. 따라서 병목 현상 (bottleneck)은 많은 사람이 보고 있는 곳에 있지 않다.

이를 "AI는 쓸모없다"라는 논쟁으로 몰고 가는 것은 쉽고, 또한 틀린 방법이다. AI는 유용하다. 태스크 (Task)에 명확한 경계가 있고 결과를 비교적 검증하기 쉬울 때, 속도 향상은 실재하며 매우 크다.

통제 실험 (Controlled experiment)에서는 GitHub Copilot을 사용한 개발자가 경계가 명확한 과제 ── JavaScript를 이용한 HTTP 서버 구현 ── 를 대조군보다 55.8% 더 빠르게 완료했다. 이 숫자는 중요하다. 이는 나 자신의 주장(claim)에 대한 반증이며, 숨기지 않고 시야에 넣어두어야 한다. 실행은 정말로 빨라진다.

하지만 실행 속도와 시스템 전체의 지속 가능한 생산성은 같은 양이 아니다. 태스크가 장기화되고, 문맥 (Context)에 의존하며, 암묵지 (Tacit knowledge)를 포함하고, 품질 기준이 복잡해지며, 되돌릴 수 없는 외부 행위에 접하게 될수록, 업무는 '실행'에서 벗어나 '검증·통합·수정'으로 옮겨간다.

그리고 바로 그 지점에서 그림이 바뀐다.

가장 유용한 데이터는 데모가 아니라, 실제 환경 (Production)에서 에이전트를 운용하고 있는 사람들로부터 나온다.

Measuring Agents in Production이라는 연구는 306명의 실무자를 조사하여 26개 영역에 걸친 20건의 케이스 스터디 (Case study)를 수행했다. 발견된 사실은 마케팅과는 정반대 방향을 향하고 있다.

연구 데모가 쫓는 자율성 (Autonomy)과 실제 현장의 안정적인 구조는 같지 않다. 현장에서 팀은 신뢰성을 위해 자율성을 거래(trade-off)하고 있다. 단순히 모델이 약해서 제한하는 것이 아니다. 신뢰할 수 있는 운용을 위해서는 제어 가능한 경계가 필요하기 때문에 제한하는 것이다.

이러한 에이전트를 만드는 기업들 스스로도 공식 가이드에서 같은 말을 하고 있다.

Anthropic은 고객과 에이전트를 구축한 경험을 바탕으로, 가장 단순한 패턴부터 시작할 것, 프로그래밍 방식의 게이트 (Gate)와 인간의 체크포인트 (Checkpoint)를 사용할 것, 명시적인 정지 조건을 추가할 것, 자동 테스트 후에도 인간의 리뷰 (Human review)를 유지할 것을 권장하며, 자율 에이전트는 오류가 누적될 수 있다고 명시하고 있다. OpenAI의 Practical Guide to Building Agents는 인간의 개입을 "critical safeguard"라고 부르며, 에이전트가 실패 임계값 (Failure threshold)을 넘었을 때, 혹은 기밀·비가역·고위험 행위(주문 취소, 대규모 환불, 결제 등)에 직면했을 때 개입하도록 권고한다.

기술 측면에서도 위험을 인지하지 못하는 것이 아니다. 더 정확히 말하자면 ── 공식 가이드는 bounded autonomy, guardrails, checkpoint, 인간의 개입으로 반복해서 돌아온다. 시장의 표면이 완전 자율이라는 어휘에 계속해서 보상을 주고 있는 와중에도 말이다. 서로 다른 인센티브 (Incentive)가 서로 다른 어휘를 만들어내고 있다.

AI가 실행을 빠르게 할 때, 그것이 줄여주는 업무는 눈에 보인다 ── 제로 베이스에서의 생성, 첫 번째 검색, 정형 변환, 번역, 초기 구조화, 반복 처리.

AI가 늘리는 업무는 훨씬 조용하다 ── 출처 확인, 오류 검출, 문맥과의 대조, 과잉 주장 제거, 예외 처리, 수정, 승인, 책임 판단, 모델이 가져온 잘못된 전제의 정정.

AI 에이전트는 반드시 인간의 노동을 없애지는 않는다. 많은 경우, 그것을 '실행'에서 '검증'으로 이동시킨다.

마케팅에서는 인간의 노동이 사라진 것처럼 보인다. 실제로는 감사실 (Audit room)로 걸어서 옮겨갔을 뿐일지도 모른다.

2025년 초의 무작위화 시험 (Randomized trial)도 동일한 이동을 가리키고 있다. 경험이 풍부한 개발자 16명이 숙련된 오픈 소스 프로젝트에서 246건의 실제 태스크를 수행했다. AI를 사용했을 때 실측치로는 느려졌음에도 불구하고, 본인들은 빨라졌다고 느끼고 있었다. 국소적인 속도와 측정된 처리량 (Throughput)이 괴리되었고, 작업 중인 본인은 그 차이를 느끼지 못했다. 이는 겉으로 보이는 속도 향상 내부에 감사 비용 (Audit cost)이 숨겨져 있을 때 나타나는 징후다.

이 글 전체를 관통하는 개념이 바로 이것이다. 두 가지 서로 다른 용량을 구분한다.

실행 대역폭 (Execution bandwidth): 시스템이 탐색·생성·변환·행동할 수 있는 양과 속도
통치 대역폭 (Governance bandwidth): 인간 또는 조직이 목적을 유지하고, 상태를 이해하며, 증거를 검증하고, 이상을 발견하며, 여러 출력을 통합하고, 계속할지 멈출지를 결정하며, 책임을 질 수 있는 용량

두 관계는 단순하고도 냉혹하다.

$$\text{Sustainable Throughput} = \min(\text{Execution Bandwidth},\ \text{Governance Bandwidth})$$

지속 가능한 처리량은 실행 용량만으로 결정되지 않는다. 실행 용량과 통치 용량 중 더 작은 쪽에 의해 결정된다.

AI는 실행 대역폭을 급격히 높인다. 통치 대역폭이 함께 올라가지 않는다면 그 차이는 사라지지 않는다. 어딘가로 흘러 들어갈 것이며, 네 가지 형태 중 하나로 붕괴할 것이다.

이 네 가지를 종합하면, 헤드라인은 다음과 같다.

AI는 병목 현상 (bottleneck)을 제거하지 않았다. 병목 현상을 한 명의 인간 신경계 안으로

집중시켰을 뿐이다.

잠시 동안, 그것은 나의 것이었다.

명백한 해결책은 감사 부하를 여러 명에게 분산하는 것이다. 분산은 필요하다. 하지만 인원수만으로는 해결되지 않는다.

공유 구조 없이 감사자를 늘리면 새로운 업무가 생긴다 ── 배경 문맥의 공유, 판단 기준의 동기화, 증거 상태의 전달, 수정 이력의 유지, 누가 무엇을 승인했는지에 대한 추적, 에스컬레이션 (escalation) 경로의 정의, 최종 책임의 소재. 공유 상태가 없다면, 감사자를 늘릴수록 '감사의 감사'가 늘어난다.

문제는 여러 명의 인간이 복잡한 시스템을 통치하지 못하는 것이 아니다. 통치가 공유 상태, 역할 경계, 에스컬레이션 프로토콜 (escalation protocol) 없이는 확장 (scale)되지 않는다는 것이다.

여기서 로켓 이야기로 돌아가 보자.

미션 컨트롤 (Mission Control)은 여기서 비유가 아니다. 이는 설계 원칙의 집합이며, 문제에 직접적으로 대응한다.

마지막 Rotation and recovery가 내가 완전히 간과했던 부분이다.

통상적인 Human-in-the-Loop 논의는 '인간을 배치한다'에서 멈춘다. 하지만 그 인간은 교체 가능한가? 피로의 한계는 있는가? 미처리 큐 (queue)에 제한은 있는가? 여기까지 나아가지 않으면 설계는 완성되지 않는다.

Tina Li의 정정은 하나의 좁지만 중요한 사실을 알려준다 ── 그녀는 다수의 운영자 중 한 명일 뿐, 루프 (loop) 전체가 아니다. 내가 제안하는 광범위한 미션 컨트롤 설계는 그 분산 원칙과, 위에서 언급한 프로덕션 에이전트의 증거를 따르는 것이다 (follow). SpaceX의 비공개 지휘 체계에 대한 주장 때문이 아니다.

나에게는 여러 개의 AI가 있었다. 미션 컨트롤의 운영자는 정확히 한 명이었다. 어떤 모델도 다른 답을 생성할 수 있었다. 하지만 그 어떤 것도 야간 근무를 대신해 줄 수는 없었다.

나는 혼자서 미션 컨트롤이 되려고 했다. 관제실이어야 할 곳이 의자 하나뿐이었고, 나는 매 교대 시간마다 교대도 휴식도 없이 그곳에 앉아 있었다 ── 그리고 그것이 최악의 결말로 이어지지 않은 유일한 이유는, 내가 우연히 앉아 있었던 20년 치의 자원 덕분이었다. 이것은 누군가가 프로덕션에 투입해야 할 시스템이 아니다.

우리가 평소 측정하는 것들 ── 출력량, 초안 작성 속도, 처리한 티켓 수, 에이전트가 지속한 단계 수, 인간이 직접 작업하지 않은 시간.

우리가 거의 측정하지 않는 것들 ── 감사 시간, 수정 시간, 문맥 동기화 비용, 오류로부터의 복구, 판단 피로, 번아웃 (burnout) 후의 정지 시간, 미래 노동 능력의 소모, 책임을 지는 인간의 긴장.

시스템이 내일의 인간 용량을 오늘의 출력으로 변환하고 있다면, 그것은 더 생산적인 것이 아니다.

AI에 의한 대량 출력이 누군가의 회복 시간과 장기적인 기능 능력을 연료로 삼고 있다면, 그것은 단순한 생산성 향상이 아니다. 어디에도 기록되지 않을, 미래에 대한 빌림일지도 모른다.

AI에게 작업을 맡길 수는 있다. 빠르고, 넓고, 경계가 있는 태스크 (task)에서는 인간 단독보다 정밀도가 높을 수도 있다.

무조건 맡길 수 없는 것은 나머지 부분이다 ── 무엇을 진실로 취급할 것인가, 어디까지 실행할 것인가, 언제 멈출 것인가, 무엇을 외부로 내보낼 것인가, 누가 책임을 질 것인가. 그리고 과도하게 집중된 통치에 대한 답이, 모든 것을 지친 한 명의 human-in-the-loop에게 던져버리는 것도 아니다.

따라서 AI 에이전트의 다음 경쟁 축은 얼마나 오래 자율적일 수 있는가가 아니다. 다른 질문이다.

시스템은 얼마나 많은 실행을, 일관성·책임·이를 유지하는 인간을 파괴하지 않고 안전하게 통치할 수 있는가.

AI 에이전트의 미래는 인간을 루프에서 제외함으로써 만들어지지 않는다. 한 명의 인간이 루프 전체가 되기를 요구하지 않는, 미션 컨트롤을 설계함으로써 만들어진다.

AI는 빨랐다. 워크플로우 (workflow)는 작동했다. 성과는 진짜였다. 그럼에도 나는 계속 쓰러졌다 ── 관제실을 만들지 않고 로켓만 만들어 버렸기 때문이다. 그리고 오랫동안, 나 자신의 신체만이 미션을 유지하고 있던 유일한 것이었다.

본문에서 이미 정확히 기술했으나, 만일을 위해 덧붙인다. 논문은 Springer Nature 계열 학술지에서 외부 심사 (external peer review) 중이며, 채택된 상태가 아니다. Cohere는 API 크레딧 지원일 뿐, 현금 지원이나 연구 내용에 대한 보증 (endorsement)이 아니다. GLG는 등록된 전문가이며, 프로젝트를 수행한 상태가 아니다. 이것들을 과장하지 않고 유지하면서도, 여전히 '업의 흐름은 실제로 움직이고 있다'와 '그것을 받아내는 인간적 응답은 별개의 레이어 (layer)다'라는 두 가지 사실을 지형으로서 보유하고 싶다.

이 기사 자체도 AI가 실행하고, 인간이 통치하며, 외부 소스를 1차적으로 검증하는 ── 기사가 주장하는 삼층 구조로 만들어져 있다. 주장을 제작을 통해 구현한 형태다.

2025년 초의 METR 무작위 시험은 숙련된 코드베이스에서 경험 많은 개발자가 AI를 사용할 때 약 19~20% 느려졌다고 측정했다. 하지만 METR는 이후 현재 효과를 신뢰하여 측정할 수 없었다고 밝히고 있다. 후속 실험에서는 AI 없이 일하는 것을 원하지 않는 개발자들이 참여를 거부하는 비율이 커서, 추정치가 하향 편향되었을 가능성이 있다. METR 자체는 더 새로운 도구에서는 실제 속도 향상이 나타났을 가능성이 높다고 말한다. 여기서 이 결과를 사용하는 것은 '현재의 AI가 개발자를 느리게 한다'라는 일반적인 주장이 아니라, 고맥락 조건에서 체감과 실측 생산성이 크게 괴리된 기록된 하나의 사례로서이다. ↩

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0