인간과 에이전트의 협업

기술적으로 완벽한 에이전트를 만들어도, 사람이 안 쓰면 의미 없고, 사람이 잘못 쓰면 사고 나잖아. 결국 인간-에이전트 협업의 설계가 시스템 성패를 가르는 거야.

1장에서 인간 개입 지점 설계를 설계 원칙으로 꼽았었는데, 13장에서 이걸 본격적으로 풀어내지.

저자는 인간의 역할을 세 가지 모델로 구분해:

• Human-in-the-Loop(HITL) — 에이전트가 매 의사결정마다 인간 승인을 받는 구조야. 가장 안전하지만 가장 느려. 금융 거래 승인, 의료 진단 확인 같은 고위험 시나리오에 적합하지
• Human-on-the-Loop(HOTL) — 에이전트가 일단 자율적으로 실행하되, 인간이 모니터링하면서 필요할 때 개입하는 거야. 대부분의 프로덕션 에이전트가 여기 해당해
• Human-out-of-the-Loop — 완전 자율. 인간은 결과만 확인하지. 현재로서는 극히 제한된 저위험 영역에서만 가능해

핵심은 이 세 가지가 택일이 아니라 스펙트럼이라는 점이야. 하나의 에이전트 시스템 안에서도 태스크마다 자율성 레벨이 달라야 하거든. 이메일 초안 작성은 자율로 돌려도 되지만, 이메일 발송은 승인을 거쳐야 하는 식이지.

저자가 강조하는 건 자율성은 시간이 지나면서 올라가야 한다는 거야. 처음엔 HITL로 시작해서 에이전트가 충분한 신뢰를 쌓으면 점차 HOTL로 전환하고, 특정 반복 태스크에 대해서만 완전 자율을 허용하는 점진적 접근이지. 이게 1장에서 말한 "점진적 설계" 원칙의 자율성 버전이야.

에이전트가 초당 수백만 건의 결정을 내리는 시대에, 인간이 모든 결정을 하나하나 감독하겠다는 건 이미 현실적이지 않거든. 그래서 인간의 역할이 결정자에서 감독자로, 다시 설계자로 진화해야 한다는 거야. 직접 승인하는 게 아니라, 승인이 필요한 조건을 설계하는 쪽으로.

기술이 준비되어도 조직이 안 받아들이면 소용없지. 저자는 에이전트 도입의 가장 큰 장벽이 기술이 아니라 사람이라고 봐.

이해관계자를 세 그룹으로 나눠:

• 실무 사용자 — 에이전트를 직접 쓰는 사람들이야. 이들의 관심사는 "내 일이 줄어드나, 늘어나나". 에이전트가 자기 일을 대체한다고 느끼면 저항하고, 보조한다고 느끼면 환영하지
• 기술 팀 — 에이전트를 만들고 유지하는 개발자/ML 엔지니어. 이들의 관심사는 기술적 타당성과 유지보수 비용이야
• 경영진/의사결정권자 — ROI와 리스크에 관심이 있어. "이걸 도입하면 뭐가 좋아지냐, 사고 나면 누가 책임지냐"

저자의 전략은 작은 성공부터 만들어서 증거를 쌓아라야. 처음부터 "AI가 모든 걸 바꿀 겁니다" 하면 실패하거든. 구체적인 태스크 하나에서 명확한 개선을 보여주고, 그 증거로 범위를 넓혀가는 게 맞다고.

도입 과정에서 저자가 경고하는 함정이 있어: 자동화 편향(Automation Bias). 에이전트가 잘 돌아가기 시작하면 사람들이 에이전트 출력을 무비판적으로 수용하는 경향이 생기거든. 이때 에이전트가 틀려도 사람이 못 잡아. 그래서 에이전트가 신뢰를 얻을수록 오히려 검증 체계를 강화해야 한다는 역설이지.

에이전트를 한 팀에서 쓰다가 조직 전체로 확장하면 완전히 다른 문제가 생겨. 저자는 이걸 범위(Scope)의 문제라고 불러.

확장 시 고려해야 할 차원들:

• 수평 확장 — 같은 에이전트를 더 많은 팀이 쓰는 거야. 팀마다 업무 맥락이 다르니까 프롬프트 커스터마이징, 도구 접근 권한 분리가 필요하지
• 수직 확장 — 에이전트가 담당하는 업무의 깊이와 복잡도를 늘리는 거야. 단순 조회에서 의사결정 보조로, 다시 실행까지
• 조직 확장 — 여러 부서, 여러 시스템을 넘나드는 크로스펑셔널 에이전트지. 이건 데이터 거버넌스, 권한 경계 문제가 폭발적으로 커져

조직 역할도 새로 정의해야 해. 저자는 에이전트 시스템이 성숙하면 기존에 없던 역할이 필요하다고 봐:

• 에이전트 오퍼레이터 — 에이전트의 일상적 운영과 모니터링 담당이야. SRE의 에이전트 버전이지
• 에이전트 큐레이터 — 에이전트의 지식 베이스와 도구를 관리해. 에이전트가 쓰는 정보가 최신이고 정확한지 책임
• 에이전트 거버너 — 정책, 컴플라이언스, 윤리적 가드레일 설정

멀티 에이전트 시스템에서 가장 미묘한 문제 중 하나가 메모리를 얼마나 공유할 것인가야.

저자는 메모리를 두 계층으로 나눠:

• 개인 메모리(Private Memory) — 특정 에이전트 혹은 특정 사용자와의 상호작용에서만 접근 가능한 정보야. 사용자 선호, 대화 이력, 개인화 데이터
• 공유 메모리(Shared Memory) — 여러 에이전트가 접근할 수 있는 공통 지식이지. 조직 정책, 프로세스 문서, 과거 의사결정 기록

문제는 경계를 어디에 그을 것이냐야. 너무 많이 공유하면 프라이버시 침해와 컨텍스트 오염이 생기고, 너무 적게 공유하면 에이전트 간 협업이 안 되거든.

저자가 제안하는 원칙: 필요한 만큼만 공유하되, 출처를 추적하라(Share on a need-to-know basis with full provenance). 모든 공유 메모리 조각에는 누가 생성했는지, 언제 생성됐는지, 어떤 에이전트가 접근했는지의 메타데이터가 붙어야 해.

컨텍스트 경계도 중요하지. 에이전트 A가 고객 정보를 알고 있다고 해서 에이전트 B가 그 정보에 접근할 수 있어야 하는 건 아니야. 직원도 다른 부서 데이터에 함부로 접근 못하는데, 에이전트라고 다를 이유가 없잖아.

저자는 이걸 컴퓨터 아키텍처의 메모리 계층 구조에 비유해. CPU 캐시(개별 에이전트의 워킹 메모리), RAM(팀 레벨 공유 메모리), 디스크(조직 전체 지식 베이스)처럼 접근 속도와 범위에 따라 계층을 나누는 거지. 각 계층 간 데이터 이동에는 명시적인 접근 제어가 필요하고.

멀티 에이전트 시스템에서 에이전트 간 컨텍스트 핸드오프도 설계 포인트야. 에이전트 A가 작업하다가 에이전트 B한테 넘길 때, 어떤 컨텍스트를 같이 넘기고 어떤 건 빼야 하는지. 전부 넘기면 B의 컨텍스트 윈도가 터지고, 너무 적게 넘기면 B가 맥락을 못 잡지. 이 압축과 선별의 기술이 멀티 에이전트 협업의 핵심 과제라고.

신뢰는 한 번 구축하면 끝이 아니라 계속 관리해야 하는 거라고 저자는 강조해. 에이전트에 대한 신뢰도 라이프사이클이 있어:

1. 초기 회의(Initial Skepticism) — 에이전트가 처음 도입될 때야. "이거 진짜 되나?" 단계지. 여기서는 작고 검증 가능한 태스크로 실력을 증명해야 해
2. 점진적 수용(Gradual Acceptance) — 에이전트가 반복적으로 좋은 결과를 내면서 사용자들이 신뢰하기 시작하는 거야. 자율성 범위를 조금씩 늘릴 수 있는 시점이지
3. 과신 위험(Overreliance Risk) — 앞서 말한 자동화 편향이 나타나는 구간이야. 사람들이 에이전트를 너무 믿기 시작하면서 검증을 게을리하지
4. 성숙한 신뢰(Calibrated Trust) — 에이전트의 강점과 한계를 정확히 이해하고, 적절한 수준의 감독을 유지하는 상태야. 여기가 목표지
5. 신뢰 유지(Trust Maintenance) — 모델 업데이트, 데이터 드리프트, 환경 변화에 따라 신뢰를 재검증하는 지속적 과정

4번까지 가는 것도 어렵지만, 5번이 진짜 어려워. 모델이 업데이트되면 이전에 쌓은 신뢰가 리셋될 수 있거든. "GPT-4o에서 잘 됐는데 GPT-5로 바꿨더니 이상해졌다" 같은 상황이지. 모델 변경 시 신뢰 재검증 프로세스가 필요한 이유야.

저자가 인용하는 원칙이 있어 — 신뢰하되 검증하라(Trust but verify). 에이전트에게 자율성을 주면서도 그 결과를 지속적으로 모니터링하는 구조를 말하지. 단순히 "믿자"도 아니고 "못 믿겠다"도 아닌, 검증 가능한 신뢰야.

에이전트가 잘못된 결정을 내렸을 때, 누구 책임인가의 문제도 있어. 에이전트는 법적 주체가 아니니까 결국 사람이 책임져야 하는데, 누구?

저자는 책임의 계층을 이렇게 정리해:

• 개발자 책임 — 에이전트의 설계, 학습 데이터, 가드레일에 대한 책임이야. "이 에이전트가 왜 이런 행동을 하는지"에 답할 수 있어야 하지
• 운영자 책임 — 에이전트의 배포, 모니터링, 유지보수에 대한 책임이야. 이상 징후를 감지하고 대응하는 의무
• 사용자 책임 — 에이전트의 출력을 최종적으로 수용하거나 거부하는 판단에 대한 책임이지. HITL에서 승인 버튼을 누른 사람
• 조직 책임 — 에이전트 도입 결정, 정책 수립, 거버넌스 체계에 대한 포괄적 책임

이 네 계층이 명확해야 사고가 났을 때 "에이전트가 한 거니까 아무도 모른다" 같은 상황이 안 생기지.

저자가 특히 강조하는 건 **설명 가능성(Explainability)**의 의무야. 에이전트가 왜 그런 결정을 내렸는지 사후에라도 추적 가능해야 해. 이게 12장에서 다룬 관찰 가능성(Observability)과 연결되는 지점이지. 로그, 추론 과정 기록, 의사결정 근거 저장이 기술적 요구사항이 아니라 책임성 요구사항이 되는 거야.

에이전트가 문제를 일으켰을 때 어떻게 대응할 것인가. 저자는 기존 인시던트 대응 프레임워크를 에이전트 맥락에 맞게 확장해:

1. 감지(Detection) — 에이전트의 비정상 행동을 어떻게 잡을 것인가야. 출력 품질 모니터링, 사용자 피드백, 자동화된 이상 탐지. 에이전트는 비결정적이니까, "정상" 범위를 정의하는 것 자체가 도전이지
2. 분류(Triage) — 문제의 심각도 판단이야. 단순 품질 저하인지, 가드레일을 뚫은 심각한 문제인지, 데이터 유출이 발생한 건지. 심각도에 따라 대응 속도와 범위가 달라져
3. 격리(Containment) — 문제 에이전트를 즉시 중단하거나 자율성을 낮추는 거야. 전체 시스템을 내릴 필요 없이 해당 에이전트만 HITL 모드로 전환하거나 트래픽을 차단
4. 근본 원인 분석(Root Cause Analysis) — 왜 이런 일이 생겼는지 파야 해. 프롬프트 문제인지, 도구 오작동인지, 모델 환각인지, 데이터 오염인지. 앞서 말한 설명 가능성 인프라가 여기서 빛을 발하지
5. 복구와 개선(Recovery & Improvement) — 문제 해결 후 시스템 복구, 그리고 재발 방지야. 가드레일 추가, 테스트 케이스 보강, 모니터링 기준 조정

저자의 포인트는 이 절차가 있으면 좋은 것이 아니라 없으면 안 되는 것이라는 거야. 에이전트는 비결정적이고, 어디서 문제가 터질지 예측 불가능하니까 대응 절차가 사전에 설계되어 있어야 하지. 소프트웨어 장애 대응이랑 비슷하지만, 비결정성 때문에 원인 추적이 훨씬 어렵다는 차이가 있어.

에이전트가 다루는 데이터에 따라 규제 환경이 완전히 달라지거든. 저자는 주요 규제 프레임워크와 에이전트의 관계를 정리해:

• EU AI Act — 2025년부터 본격 시행됐지. AI 시스템을 위험도 기반으로 분류하고, 고위험 시스템에 대해 인간 감독, 투명성, 기술 문서화를 의무화해. 에이전트 시스템은 자율적으로 행동하기 때문에 대부분 상당한 규제 대상이야
• GDPR — 개인정보 처리에 관한 규제지. 에이전트가 사용자 데이터를 메모리에 저장하고 학습에 사용한다면, 명시적 동의, 삭제 권리, 데이터 최소화 원칙을 지켜야 해
• NIST AI RMF — 미국 NIST의 AI 위험 관리 프레임워크야. Govern-Map-Measure-Manage의 반복적 라이프사이클로 AI 위험을 관리하지. 자율적 에이전트에 대한 지속적 모니터링과 자동화된 알림을 핵심 요구사항으로 두고 있어

저자가 지적하는 현실적 문제가 있어: 에이전트의 메모리와 규제의 충돌. 13.2에서 다룬 공유 메모리에 개인정보가 들어가면 GDPR의 "삭제 권리(Right to be Forgotten)"를 어떻게 보장할 거야? 에이전트가 학습한 패턴에서 특정 개인의 데이터를 지우는 게 기술적으로 가능한가?

또 하나, 설명 요청권. GDPR은 자동화된 의사결정에 대해 설명을 요구할 수 있는 권리를 보장하는데, 에이전트가 멀티스텝 추론을 거쳐 내린 결정을 인간이 이해할 수 있는 수준으로 설명하는 게 현실적으로 가능하냐의 문제지.

저자의 조언: 규제는 계속 강화될 것이고, 2025년 현재 55% 이상의 기업이 이미 AI 거버넌스 위원회를 설치했어. 이미 와 있으니 지금 대응하라야. 거버넌스를 나중에 붙이려 하면 아키텍처를 뜯어고쳐야 하지만, 처음부터 설계하면 비용이 훨씬 적거든.

---

정리

13장 읽고 기억할 거 세 가지:

1. 자율성은 스펙트럼이야. HITL에서 시작해서 신뢰가 쌓이면 점진적으로 자율성을 올려. 절대 한 번에 완전 자율로 가지 마
2. 공유 메모리에는 출처 추적이 필수야. 에이전트 간 컨텍스트를 공유할 때, 뭘 공유하고 뭘 안 할지의 경계를 명확히 설계하고, 모든 공유에 출처 메타데이터를 붙여야 해
3. 책임 구조를 먼저 정해. 에이전트가 사고 치면 누가 책임지는지, 어떻게 대응하는지가 사전에 정의되어 있어야 하지. 거버넌스는 나중에 붙이는 게 아니라 처음부터 설계하는 거야