Chapter 8 · Human-Agent Interaction Patterns

누가 누구를 부르는가

『Agentic Architectural Patterns for Building Multi-Agent Systems』 8장 — Ali Arsanjani, Juan Pablo Bustos, Thomas Kurian

앞선 장들이 시스템을 조율되고 준수하고 견고하게 만드는 법이었다면, 8장은 가장 결정적인 관계를 다룬다. AI 에이전트와 사람 사용자 사이의 관계다. 에이전틱 시스템이 백엔드 자동화를 넘어 지식 노동자를 실제로 증강하려면, 사람과의 상호작용이 직관적이고 믿을 만하고 효과적이어야 한다. 그리고 이 장의 패턴 다섯은 전부 하나의 질문으로 이름 지어져 있다. 누가 누구를 부르는가.

00

A strategic guide · map before the journey

전략 지도 — 다섯 갈래의 호출

이 장의 패턴을 아는 것이 첫걸음이라면, 다음은 강력하면서도 믿을 만한 시스템을 짓도록 전략적으로 적용하는 것이다. 7장과 마찬가지로 모든 패턴을 한꺼번에 구현할 필요도, 그럴 이유도 없다. 시스템의 복잡도와 정교한 협업 워크플로에 대한 요구가 자라는 데 맞춰 점진적으로 채택하는 것이 옳다.

그런데 이 다섯 패턴에는 다른 장에 없는 특징이 있다. 이름 자체가 호출의 방향이라는 것이다. 사람이 부르는가 에이전트가 부르는가, 짧게 부르는가 통째로 맡기는가, 안에서 넘기는가 바깥으로 나가는가. 그래서 지도부터 그린다.

UI TIER ORCHESTRATION SPECIALIST SECURITY / PROXY EXTERNAL 사람 사용자 HUMAN USER 주 에이전트 · 오케스트레이터 TravelPlannerAgent 전문 에이전트 A FlightBookingAgent 전문 에이전트 B HotelBookingAgent 프록시 에이전트 유일하게 자격증명을 쥔다 외부 시스템 · 제3자 API P3 · 부른다 단발 · 요청·응답 P2 · 위임한다 목표를 통째로 P1 · 에스컬레이션 멈추고 묻는다 P4 · 에이전트 간 위임 P5 · 프록시 경유 주황 화살표는 사람이 관여하는 경로 · 초록은 시스템 내부 경로

〈관계도〉 다섯 패턴은 다섯 개의 화살표다. 위쪽 셋이 사람과 맞닿고, 아래쪽 둘은 시스템 안쪽에서 일어난다.

다섯 단계의 성숙도

단계역량가능해지는 패턴요약
1 · 거래형 시스템직접적인 단일 턴 상호작용사람이 에이전트를 부른다시스템이 반응하는 도구로 작동한다. 단순하고 잘 정의된 명령과 질의를 빠르고 정확하게 처리한다.
2 · 보조된 자동화기본적 위임과 에스컬레이션사람이 에이전트에 위임한다 · 에이전트가 사람을 부른다단순한 다단계 과업을 맡을 수 있지만 자기 한계를 안다. 모호함이나 승인이 필요할 때 사람에게 안정적으로 넘긴다.
3 · 협업형 시스템내부 멀티 에이전트 워크플로에이전트가 에이전트에 위임한다내부 전문 에이전트 팀을 조율해 복잡한 문제를 푼다. 그 과정은 사용자에게 감춰진다.
4 · 안전한 상호운용 생태계안전한 외부 상호작용에이전트가 프록시를 부른다제3자 시스템과 안전하고 안정적으로 상호작용해 기업 간 협업을 가능하게 한다.
5 · 능동적·개인화된 동반자예측적·맥락 인지적 협업모든 패턴 + 장기 기억시스템이 도구에서 동반자로 진화한다. 사용자 선호를 배우고 복잡한 목표를 능동적으로 돕는다.

〈표 8.1〉 인간·에이전트 상호작용 패턴 채택을 위한 성숙도 모델

어디에 놓을 것인가 — 네 계층

Tier 1 · UI

사용자 인터페이스 계층

사람 사용자와 맞닿는 직접적 접점. 모든 상호작용이 여기서 개시된다.
가능한 패턴 — 사람이 에이전트를 부른다(직접 명령), 사람이 에이전트에 위임한다(복잡한 목표)

Tier 2 · Orchestration

오케스트레이션·주 에이전트 계층

사용자가 상호작용하는 주 에이전트가 있는 곳. 상위 계획, 목표 분해, 전체 워크플로 관리를 책임진다.
가능한 패턴 — 위임받은 과업을 받고 전문가 계층에 다시 위임한다. 에스컬레이션도 여기서 처리한다

Tier 3 · Specialist

전문·작업자 에이전트 계층

핵심 업무 로직을 수행하는 기능적·세밀한 에이전트들(FlightBookingAgent, NewsSentimentAgent).
가능한 패턴 — 위임받은 과업을 실행하고, 필요하면 보안 계층을 통해 외부 요청을 개시한다

Tier 4 · Security

보안·프록시 계층

모든 외부 통신을 책임지는 특수하고 격리된 계층.
가능한 패턴 — 제3자 API로 가는 안전한 관문 역할의 프록시 에이전트가 여기 산다. 바깥세상과 상호작용할 자격증명과 로직을 가진 유일한 계층이다

다섯이 한 줄로 엮인다 — 출장 예약

한 가지 기업 업무를 따라가 보면 다섯 패턴이 어떻게 맞물려 복잡한 목표를 이루는지 보인다. 그리고 시스템이 자기 운영 한계에 이르렀을 때 매끄럽게 사람에게 넘어가는 대목이 이 사슬의 핵심이다.

P2 · 사람이 위임“다음 주 뉴욕 사무실 출장을 잡아 줘. 3분기 기획 회의다. 환불 가능한 항공권과 회사 제휴 호텔 객실로.”
P4 · 에이전트 간 위임오케스트레이터가 목표를 분해한다. “다음 주 JFK행 환불 가능 항공편을 찾아라” → 항공 예약 에이전트. “다음 주 뉴욕 제휴 호텔 객실을 찾아라” → 호텔 예약 에이전트
P5 · 프록시 경유항공 예약 에이전트가 회사의 보안 출장 포털(Concur)을 써야 한다. ConcurProxyAgent를 호출해 조건을 넘긴다. 프록시만이 Concur API 키를 갖고 있다.
P1 · 에스컬레이션호텔 예약 에이전트가 제휴 호텔이 만실임을 발견한다. 승인된 다른 호텔 둘을 찾았지만 스스로 결정할 수 없다. “제휴 호텔이 불가합니다. 호텔 A(사무실에 더 가까움)와 호텔 B(부대시설이 나음) 중 어느 쪽이 좋으십니까?” 워크플로가 멈춘다.
P3 · 사람이 부른다사용자가 알림을 받고 답한다. “호텔 A로 예약해.” 모호함을 해소하는 직접적이고 거래적인 명령이다.
완료오케스트레이터가 사람의 결정을 받아 호텔 에이전트에 진행을 지시하고, 모든 전문가의 최종 확인을 모아 완성된 일정을 사용자에게 제시한다.

왜 지표가 필요한가

5장과 6장이 에이전트 조율과 관찰 가능성의 내부 논리에 집중했다면, 7장과 8장은 시스템이 현실 세계와 맞닿는 결정적 접점을 다룬다. 인간·에이전트 상호작용에서 “성공”은 흔히 주관적으로 인식된다. 그러나 기업 등급 시스템이 되려면 일화적 피드백을 넘어 사용자 경험을 객관적이고 측정 가능한 데이터로 바꿔야 한다.

패턴지표계측 방법
에이전트가 사람을 부른다에스컬레이션율 / 해결 시간모든 에스컬레이션 이벤트를 기록한다. 에스컬레이션에서 사람 응답까지, 그리고 이후 과업 재개까지의 시간을 측정한다.
사람이 에이전트에 위임한다과업 성공률 / 사용자 만족도위임된 목표의 종단 간 완수율을 추적한다. 간단한 사용자 설문(CSAT·NPS)으로 후속 확인한다.
사람이 에이전트를 부른다1차 접촉 해결률 / 평균 응답 시간한 턴에 해결된 질의의 비율을 측정한다. 사용자 입력에서 최종 응답까지의 종단 간 지연을 추적한다.
에이전트가 에이전트에 위임한다오케스트레이션 부담 / 하위 과업 실패율에이전트 간 위임과 응답마다 타임스탬프를 기록해 추가된 지연을 잰다. 전문 에이전트가 반환한 오류를 추적한다.
에이전트가 프록시를 부른다외부 API 오류율 / 보안 사고프록시 에이전트의 로그에서 실패하거나 타임아웃된 API 호출을 모니터링한다. 프록시의 격리 환경에 보안 모니터링을 구현한다.

〈표 8.2〉 패턴별 평가 지표 표본

P1

Agent → Human

에이전트가 사람을 부른다 — 멈출 줄 아는 것이 능력이다

P1

Agent Calls Human · Human-in-the-Loop Escalation

에이전트가 사람을 부른다

LV 2에이전트 → 사람

문제의 배경

에이전틱 시스템의 목표가 자동화 극대화라 해도, 설계상 또는 필요에 따라 에이전트가 멈추고 사람의 도움을 청해야 하는 상황이 있다. 결정에 대한 확신이 결정적 임계치 아래로 떨어질 때, 몹시 모호한 데이터를 만났을 때, 또는 회사 정책이 사람의 승인을 요구하는 판돈 큰 결정일 때다.

맥락

자율 에이전트가 작동 중에 스스로 해결할 수 없는 상황을 만난다. 시스템은 효율을 위해 자동화를 극대화해야 하지만, 안전을 보장하고 에이전트 역량 밖의 경계 사례를 다루려면 사람의 감독도 허용해야 한다.

문제

에이전트가 자율 작동을 우아하게 멈추고 사람에게 결정을 넘기려면 어떻게 해야 하는가. 맥락을 제대로 포착하지 못하거나 사람의 응답을 올바로 담아내지 못하면 워크플로 전체가 무너진다.

해법

흔히 human-in-the-loop 검문소라 부르는 정식 에스컬레이션 기제를 구현한다. 사람의 개입이 필요한 상황을 식별하면 에이전트가 현재 상태와 관련 맥락 전부를 구조화된 요청으로 포장한다. 이 요청은 전용 UI나 과업 대기열을 통해 사람 운영자에게 전달된다. 사람이 결정을 내릴 때까지 에이전트의 워크플로는 멈춰 있고, 그 결정이 시스템에 되먹여지면 에이전트가 사람이 검증한 새 정보로 과업을 재개한다.

사례 — 대출 신청의 모호함을 푼다

LoanApprovalAgent의 목표는 확신이 95% 아래로 떨어지지 않는 한 신청을 자율 처리하는 것이다. 사람 심사역의 목표는 에스컬레이션된 모호한 건을 검토해 최종 판단을 내리는 것이다.

01촉발 — 소득과 신용점수는 성공적으로 검증했다. 그런데 감정평가서를 분석하다가 감정 면적(1,800 sq. ft)과 재산세 기록(1,500 sq. ft) 사이의 유의미한 불일치를 발견해 확신이 떨어진다
02맥락 포장 — 신청인 ID, 충돌하는 문서 링크, 요약을 담은 검토 패키지를 만든다. “감정평가와 세금 기록 사이 면적 불일치 발견. 부동산 가치 검증을 위해 사람 검토 필요.”
03에스컬레이션HumanReviewTool을 호출해 패키지를 사람 심사역 대시보드로 밀어 올린다
04일시 정지 — 이 신청 건에 대한 워크플로가 검토 결과를 기다리며 멈춘다
05사람의 결정 — 심사역이 문서를 검토해 세금 기록 쪽의 사무 착오임을 판단하고 UI로 결정을 준다. VALIDATE_APPRAISAL
06재개 — 구조화된 결정을 받아 내부 상태를 갱신하고, 승인 절차의 다음 단계로 나아간다

장점

  • 안전과 신뢰 — 안전하고 믿을 만한 시스템을 짓는 근본 패턴이다. 결정적이거나 모호한 판단이 사람의 검증을 거치게 해 값비싼 자동화 오류의 위험을 줄인다.
  • 경계 사례 처리 — 에이전트가 학습하지 않았을 수 있는, 필연적으로 나타나는 경계 사례와 새로운 상황을 다루는 견고한 기제를 제공한다.

단점

  • 병목 — 고리 안의 사람이 성능 병목이 될 수 있다. 시스템 전체 속도가 사람 운영자의 가용성과 응답성에 제한된다.

구현 지침

사람을 향하는 인터페이스를 신중히 설계하라. 맥락을 간결하게 제시하고, 모호함을 최소화하도록 구조화된 입력 방식(버튼, 폼)을 제공해야 한다. 에이전트의 “멈춤” 상태를 관리하는 견고한 기제도 갖춰야 한다. 여기에는 타임아웃과, 사람이 일정 시간 안에 응답하지 않을 경우의 기본 행동이 포함된다.

A reframing

에스컬레이션은 실패가 아니라 기능이다

지능적 시스템은 자기 한계를 알아야 한다. 이 패턴은 안전을 보장하고 모호함을 다루는 근본 기제이며, 고리 안의 사람을 아키텍처의 핵심 부품으로 만든다. 멈추는 것은 고장이 아니다.

P2

Human → Agent · long handoff

사람이 에이전트에 위임한다 — 명령에서 동반으로

P2

Human Delegates to Agent

사람이 에이전트에 위임한다

LV 2사람 → 에이전트

문제의 배경

에이전틱 AI는 단순한 문답을 넘어 복잡한 목표를 향해 자율적으로 작동하는 능력으로 정의된다. 이 패턴이 그 능력의 본질을 포착한다. 단계별 지시를 주는 대신, 사람이 상위의, 흔히 모호한 목표를 에이전트에 위임한다. 인간과 AI의 관계가 근본적으로 바뀐다. 직접 명령·통제에서, 사람이 전략적 방향을 정하고 에이전트가 전술적 실행을 관리하는 동반 관계로.

Note

이것이 널리 퍼진 AI “개인 비서”, “코파일럿”, “코사이언티스트” 상(像)에 가장 가까운 패턴이다. 최소한의 감독으로 전체 과업을 완수한다. 시간이 오래 걸리거나, 반복적이거나, 여러 시스템과 데이터 원천을 오가야 하는 과업에 특히 유용하다.

맥락

사람에게 상위 목표나 복잡한 다단계 과업이 있지만, 각 단계를 수동으로 실행하고 싶지 않거나 할 수 없다. 전 과정을 유능한 자율 시스템에 넘기고 싶다.

문제

사용자가 복잡한 목표를 AI 에이전트에 어떻게 효과적으로 넘길 것인가. 시스템은 상위 지시에서 사용자 의도를 정확히 포착하고, 오랜 기간 자율적으로 작동하며, 끊임없는 사람의 안내 없이도 원래 목표와 정렬된 상태를 유지해야 한다.

해법

상호작용을 명확한 인계로 구조화한다. 사용자가 상위 목표를 제시하면 에이전트가 자율 루프에 들어간다. 먼저 그 목표를 이룰 상세 계획을 세워 작고 실행 가능한 하위 과업으로 쪼갠다. 그다음 도구와 추론 능력으로 각 단계를 실행한다. 주기적 갱신을 제공하거나 복구 불가능한 모호함을 만나면 해명을 요청할 수 있지만, 그 외에는 최종 목표를 이룰 때까지 독립적으로 움직인다.

사례 — 시장 조사를 위임한다

"유럽 시장에서 'ProWidget X'의 주요 경쟁사에 관한 보고서를 만들어 줘. 가격, 핵심 기능, 최근 고객 반응이 필요해. 내일까지 초안이 있어야 해."

에이전트가 세운 계획

a경쟁사 식별 — 웹 검색 도구로 유럽의 'ProWidget X' 주요 경쟁사를 찾는다
b가격 조사 — 경쟁사별로 금융 데이터 API를 써서 제품 가격을 찾는다
c반응 분석 — 제품 리뷰 집계 도구로 최근 6개월 고객 반응을 요약한다
d보고서 종합 — 수집한 모든 데이터를 구조화된 보고서 문서로 통합한다
e전달 — 최종 보고서를 이메일로 매니저에게 보낸다

에이전트가 각 하위 과업을 순차 실행하고 중간 발견을 기억에 저장한다. 추가적인 사람의 입력은 없다. 초안이 완성되면 문서를 첨부해 이메일을 보내며 원래 위임 목표를 이행한다.

장점

  • 효율 — 사람이 복잡하고 시간 많이 드는 과업을 자율 시스템에 떠넘길 수 있게 해, 생산성에 극히 강력하다.
  • 역량 — 단일 프롬프트 상호작용으로는 너무 크거나 복잡한 문제를 풀 수 있게 한다.

단점

  • 어긋남의 위험 — 주된 위험은 에이전트가 최초의 상위 목표를 잘못 해석해, 사용자의 진짜 의도와 맞지 않는 계획을 실행하는 데 상당한 자원을 쓰는 것이다.

구현 지침

어긋남의 위험을 완화하려면 계획 확인(Plan Confirmation) 단계를 넣는 것을 고려하라. 에이전트가 초기 계획을 생성한 뒤, 자율 실행을 시작하기 전에 그 계획을 사용자에게 제시해 “진행할까 말까” 승인을 받는 것이다. 이 작은 검문소 하나면, 사용자가 매 단계를 감독하지 않고도 에이전트의 목표 해석이 옳은지 확인할 수 있다.

P3

Human → Agent · short call

사람이 에이전트를 부른다 — 가장 단순하고 가장 흔한 것

P3

Human Calls Agent

사람이 에이전트를 부른다

LV 1사람 → 에이전트

문제의 배경

모든 상호작용이 길고 복잡한 위임인 것은 아니다. 사용자는 흔히 특정한 정보 한 조각을 원하거나 잘 정의된 행동 하나를 즉시 수행하기를 바란다. 이런 거래적이고 직접적인 질의에 사용자가 기대하는 것은 빠르고 정확하고 간결한 응답이다.

맥락

상호작용이 거래적이며, 사용자는 불필요한 대화 단계 없이 빠르고 정확한 응답을 기대한다.

문제

거래적 질의에 직접적이고 반응적이며 정확한 답을 어떻게 제공할 것인가. 에이전트는 사용자의 직접 명령을 빠르게 이해하고, 적절한 도구로 정보를 얻거나 행동을 수행한 뒤, 결과를 간결하게 돌려줘야 한다.

해법

상호작용을 직접적인 요청–응답 주기로 구조화한다. 사용자의 질의를 직접 호출로 다룬다. 에이전트의 주 로직은 의도를 분류하고, 그 의도를 충족할 단 하나의 최적 도구를 고르고, 질의에서 추출한 매개변수로 도구를 실행하고, 결과를 대화적 군더더기 없이 돌려주는 것이다. 챗봇·음성 비서를 비롯한 직접 상호작용 도구를 짓는 기초 패턴이다.

사례 — 주문 상태 확인

01사용자 질의 — “내 주문 ABC-123 어디쯤 왔어?”
02매개변수 추출 — LLM이 주문 ID ABC-123을 도구에 필요한 매개변수로 뽑아낸다
03도구 실행getOrderStatusTool(order_id="ABC-123"). 내부적으로 배송 DB에 질의해 구조화 데이터를 반환한다. {"status":"In Transit","location":"Denver, CO","estimated_delivery":"2025-09-22"}
04응답 생성 — 도구 출력을 받아 명확하고 간결한, 사람이 읽을 수 있는 응답으로 다듬는다
05반환 — “주문 #ABC-123은 현재 콜로라도 덴버를 통과 중이며, 예상 배송일은 9월 22일입니다.”

장점

  • 속도와 효율 — 속도에 최적화돼 있어 반응성 높은 거래형 비서를 짓는 데 이상적이다.
  • 단순함 — 로직이 직관적이라 구현과 디버깅이 가장 쉬운 에이전틱 패턴 중 하나다.

단점

  • 제한된 범위 — 복잡한 다단계 과업이나 장기 실행 목표에는 잘 맞지 않는다. 잘 정의된 단일 목적 상호작용에서 빛난다.

구현 지침

이 패턴의 성패를 가르는 열쇠는 견고한 도구 정의다. 에이전트가 쓸 수 있는 도구는 명확한 설명으로 잘 문서화돼야 하고, 매개변수는 강하게 타입이 정해져야 한다. 곧 각 매개변수가 문자열·정수·불리언처럼 자기 데이터 타입을 명시적으로 정의해야 한다. LLM이 올바른 도구를 정확히 고르고 사용자의 대화적 질의에서 필요한 인자를 뽑아낼 수 있는 것은 바로 이 메타데이터 덕분이다.

P4

Agent → Agent

안에서 벌어지는 일 — 사용자는 몰라도 되는 협업

앞의 셋이 사용자와 시스템 사이의 주된 인터페이스를 정의한다면, 나머지 둘은 그 매끄러운 경험을 가능하게 하려고 무대 뒤에서 에이전트들이 협업하는 방식이다.

P4

Agent Delegates to Agent

에이전트가 에이전트에 위임한다

LV 3에이전트 → 에이전트

문제의 배경

사용자가 복잡한 과업을 주 에이전트 하나에 위임하지만, 성공적으로 완수하려면 그 에이전트가 갖지 못한 여러 전문 기술이 필요한 경우가 흔하다. 시스템은 사용자의 상위 목표를 쪼개어 그 결과인 하위 과업을 올바른 전문가에게 보내되, 사용자에게는 매끄러운 하나의 경험으로 남겨야 한다.

맥락

주 에이전트(오케스트레이터)가 사용자로부터 여러 전문 기술이나 지식 영역을 요구하는 복잡한 과업을 받았다.

문제

단일 “제너럴리스트” 에이전트를 압도하지 않으면서, 그리고 사용자가 여러 전문 에이전트와 직접 상호작용하도록 요구하지 않으면서, 어떻게 복잡한 요청을 이행할 것인가.

해법

흔히 감독자(오케스트레이터) 구조를 써서 위계를 구현한다. 사용자는 단일 주 에이전트와만 상호작용한다. 그 에이전트가 요청을 분석해 프로젝트 관리자처럼 행동하며 전체 목표를 작은 하위 과업으로 분해한다. 그리고 각각을 처리할 도구와 지식을 가진 적절한 전문 작업자에게 위임한다. 주 에이전트가 결과를 모아 최종 응답을 종합함으로써 내부 협업을 보이지 않게 만든다.

사례 — 종합 재무 분석

"CompanyCorp에 대한 전체 분석을 줘. 최근 실적 발표 요약, 주가 차트의 기술적 분석, 그리고 최근 부정적 뉴스 점검이 필요해."
01분해 계획 — 1분기 실적 발표 녹취록 요약 · 3개월 주가 차트의 지지·저항 수준 분석 · 최근 7일 뉴스에서 부정적 반응 탐색
02에이전트 간 위임 — 요약은 EarningsCallSummarizerAgent, 차트 분석은 TechnicalChartAgent, 뉴스 탐색은 NewsSentimentAgent
03전문가 실행 — 각자 전용 도구로 과업을 수행해 오케스트레이터에 결과를 돌려준다
04종합과 응답 — 분석 조각들을 모아 하나의 일관된 보고서로 종합해 분석가에게 제시한다

장점

  • 모듈성과 전문화 — 유능하고 유지보수 가능한 시스템을 만든다. 각 에이전트가 자기 영역의 전문가가 될 수 있고, 독립적으로 개발·시험·갱신할 수 있다.
  • 역량 강화 — 여러 전문가의 기술을 결합해, 어떤 단일 에이전트도 감당할 수 없는 훨씬 복잡한 문제를 푼다.

단점

  • 오케스트레이션 부담 — 시스템의 성능과 신뢰성이 오케스트레이터에 크게 의존한다. 과업 분해·위임·결과 종합의 로직을 설계하는 일이 복잡도를 더하고 지연을 만들 수 있다.

구현 지침

이 패턴에서 가장 결정적인 부품은 오케스트레이터의 계획 능력이다. 더 단순하고 예측 가능한 워크플로라면 분해 계획을 정적이고 사전 정의된 에이전트 호출 순서로 둘 수 있다. 더 복잡하고 동적인 과업이라면 오케스트레이터 자신이 LLM을 써서 다단계 계획을 생성해야 할 수도 있다.

P5

Agent → Proxy → External

에이전트가 프록시를 부른다 — 열쇠는 한 곳에만 둔다

P5

Agent Calls Proxy Agent

에이전트가 프록시 에이전트를 부른다

LV 4에이전트 → 프록시 → 외부

문제의 배경

에이전트가 제3자 파트너 API나 민감한 내부 DB처럼 다른 보안 맥락에 있는 외부 시스템과 상호작용해야 하는 경우가 흔하다. 접촉할 수 있는 모든 외부 시스템의 자격증명을 주 에이전트에 주는 것은 중대한 보안 위험이자 통합의 악몽이다.

맥락

에이전트가 사용자 요청을 이행하는 과정에서 외부 시스템과 상호작용해야 한다. 보안 정책, 네트워크 경계, 또는 외부 시스템의 복잡성을 추상화하려는 의도 때문에 주 에이전트의 직접 접근은 허용되지 않는다.

문제

에이전트가 외부 시스템에 강하게 결합되지 않으면서, 그리고 보안을 훼손하지 않으면서 어떻게 안전하고 안정적으로 상호작용할 것인가.

해법

안전하고 표준화된 관문 역할을 하는 전문 중개 에이전트, 곧 프록시를 둔다. 주 에이전트는 외부 시스템을 직접 부르지 않는다. 대신 프록시에 단순한 내부 요청을 보낸다. 프록시는 외부 시스템과 통신하는 데 필요한 자격증명과 로직을 가진 유일한 부품이다. 주 에이전트의 요청을 외부가 요구하는 특정 형식으로 번역하고, 안전하게 상호작용한 뒤, 흔히 복잡한 응답을 단순하고 표준화된 형식으로 다시 번역해 돌려준다.

사례 — 기업 간 로열티 프로그램

AirlineBookingAgent가 항공 예약 워크플로를 관리하고, HotelBonanzaProxyAgent가 외부 HotelBonanza API와의 모든 통신을 안전하게 관리한다.

01사용자 요청 — “런던행 항공편 예약하고 내 HotelBonanza 로열티 할인 적용해 줘.”
02주 에이전트의 판단 — 자신은 HotelBonanza 시스템에 직접 접근할 수 없음을 안다
03프록시 호출 — 단순한 내부 요청을 보낸다. {"action":"validate_discount","user_id":"user123","loyalty_code":"HB-XYZ"}
04프록시 실행비밀 API 키를 가진 유일한 에이전트가 요청을 받아, 외부가 요구하는 특정 API 호출 형식을 만들어 안전하게 보낸다
05외부 응답 — HotelBonanza API가 할인을 확인하는 복잡한 JSON 객체를 반환한다
06프록시 번역 — 응답을 파싱해 핵심 정보(일회용 할인 코드)만 뽑아 표준 형식으로 돌려준다. {"status":"success","discount_code":"APPLIED123"}
07과업 완료 — 주 에이전트가 단순한 응답을 받아 코드를 적용한다. 외부 자격증명이나 복잡한 API 로직을 한 번도 다루지 않은 채 요청이 완결된다

장점

  • 보안 — 외부 시스템 접근을 중앙화하고 격리해 보안을 크게 높인다. 주 에이전트는 민감한 자격증명을 결코 다루지 않으므로 공격면이 줄어든다.
  • 결합 해체와 유지보수성 — 주 에이전틱 시스템을 외부 API의 복잡성에서 떼어 놓는다. 파트너의 API가 바뀌어도 프록시만 고치면 되고 주 에이전트는 손대지 않는다.

단점

  • 지연 — 통신 사슬에 홉 하나가 더해져 지연이 붙는다. 극도로 낮은 지연이 요구되는 상호작용에는 덜 적합하다.

구현 지침

이 패턴으로 내부 에이전트 시스템과 바깥세상 사이에 명확한 보안 경계를 강제하라. 프록시 에이전트가 특정 외부 서비스에 도달할 네트워크 접근과 자격증명을 가진 유일한 부품이어야 한다. 주 에이전트와 프록시 사이의 내부 통신 프로토콜은 단순하고 표준화되게 만들어, 사실상 외부 복잡성을 추상화하는 내부 API를 만드는 셈이 되게 하라.