Defining an agent
자율성의 위계 — 셋은 같은 것이 아니다
정의부터 다시 못 박자. AI 에이전트는 흔히 LLM으로 구동되며, 환경을 지각하고 결정을 내리고 행동해 특정 목표를 달성하도록 설계된 시스템이다. 단순히 프롬프트에 응답하는 것을 넘어, 지속되는 목적을 가지고 작동하는 더 자율적인 실체다.
그것을 기본적인 LLM 상호작용과 가르는 특성은 넷이다.
- 자율성 — 일정한 자기 통치력을 가진다. 목표가 주어지면 거기 이르는 단계를 스스로 정한다. 사람이 계속 개입하지 않아도 된다.
- 반응성(감지) — 운영 환경을 지각하고 그 안의 변화나 사건에 대응한다. 이 “감지”가 에이전틱 행동의 핵심이다.
- 능동성(목표 지향) — 반응만 하지 않는다. 먼저 움직인다. 목표를 향해 복잡한 계획을 세우고 시간에 걸쳐 실행한다.
- 사회성(선택적이나 흔함) — 특히 멀티 에이전트 시스템에서 다른 에이전트나 사람과 상호작용한다. 합의된 언어와 프로토콜로 협업하고 협상하고 조율한다.
〈그림 4.1〉 자율성의 위계. 아래층이 위층의 재료가 되지만, 아래층이 위층인 것은 아니다.
1.1LLM과 MMM — 지각하되 행동하지 않는다
LLM은 에이전트의 기초적 추론 중추이자 “뇌”다. 이 책은 LLM과 MMM(멀티모달 모델)을 같은 뜻으로 쓰지만, 구분은 기술적으로 유의미하다.
현대의 MMM은 텍스트만이 아니라 코드·이미지·오디오·비디오의 방대한 데이터로 학습된다. 서로 다른 양상을 공유된 의미 공간에 투사해 입력들을 가로질러 네이티브로 추론한다. 대시보드 스크린숏을 분석해 시스템 오류를 진단하거나, 오디오 파일을 들어 감정을 뽑아내는 일을 별도의 번역 모델 없이 해낸다.
The crucial distinction
그러나 MMM은 에이전트가 아니다
지각 능력이 아무리 뛰어나도 모델 자체는 본질적으로 무상태이고 수동적이다. 입력을 처리해 출력을 예측할 뿐, 스스로 행동을 개시하지 않고, 자기 의지로 장기 기억을 유지하지 않으며, 독립적으로 목표를 추구하지 않는다. 프롬프트를 받을 때만 응답한다. 모델이 원재료 지능을 제공한다면, 그 수동적 잠재력을 능동적이고 목표 지향적인 행동으로 바꾸는 것은 그것을 둘러싼 에이전트 아키텍처다.
1.2자동화 워크플로 — 행동하되 사고하지 않는다
자동화 워크플로, 곧 AI 오케스트레이션은 일련의 과업이다. 일부는 미리 정해진 결정론적 단계이고, 일부는 의도 해석과 함수 호출에 기대는 비결정론적 단계일 수 있다. if-this-then-that 단계를 실행하는 스크립트라고 생각하면 된다. 행동은 하지만 결정론적이고 경직돼 있어 고정된 경로를 따른다. 추론하거나, 동적으로 계획하거나, 예기치 못한 상황에 행동을 조정하는 능력이 없다.
1.3셋의 차이를 한 문장으로
LLM은 프롬프트를 받으면 이메일 초안을 쓴다.
자동화 워크플로는 매주 월요일 오전 9시에 미리 써 둔 이메일을 보낸다.
AI 에이전트는 받은편지함 전체를 관리한다.
메일을 능동적으로 분류하고, 내용에 따라 도구로 회의를 잡고, 긴급한 사안을 알린다.
그 와중에 사용자의 선호를 시간에 걸쳐 배운다.
| 특성 | LLM | 자동화 워크플로 | AI 에이전트 |
|---|---|---|---|
| 핵심 기능 | 프롬프트에 근거해 텍스트를 생성하고, 질문에 답하고, 정보를 종합한다. | 사전 정의된 정적 과업 순서를 실행한다. | 특정 목표를 자율적으로 달성한다. |
| 의사결정 | 패턴 매칭과 확률적 텍스트 생성. 결정을 내리지 않는다. | 하드코딩된 if-this-then-that 논리에 근거한다. 추론하지 않는다. | 추론하고 계획하고 동적으로 결정해 복잡한 문제를 헤쳐 나간다. |
| 상태와 기억 | 무상태. 매 상호작용이 새롭다(맥락을 넣어 줄 수는 있다). | 대체로 무상태. 과거 실행을 기억하지 않는다. | 상태 보유. 단기·장기 기억을 유지해 배우고 적응한다. |
| 적응성 | 미세조정하거나 새 프롬프팅 기법을 쓰지 않으면 적응하지 않는다. | 경직. 프로세스를 바꾸려면 워크플로를 다시 프로그래밍해야 한다. | 고도로 적응적. 경험에서 배우고 환경 변화에 반응한다. |
| 상호작용 모델 | 프롬프트를 받고 응답을 돌려준다. | 이벤트로 촉발돼 고정된 스크립트를 실행한다. | 목표를 좇아 감지–추론–계획–행동의 연속 루프로 작동한다. |
| 실패 처리 | 수동적·부재. 그럴듯하지만 틀린 정보를 실패 자각 없이 생성할 수 있다(환각). | 경직·취약. 특정 규칙이 깨지면 그대로 실패하거나 사전 설정된 예외 경로(“중단하고 관리자에게 알림”)를 탄다. | 회복력·자기수정. 오류를 감지하고 원인을 성찰해 다른 전략이나 도구로 자율적으로 재시도한다. |
〈표 4.1〉 LLM·자동화 워크플로·AI 에이전트의 비교
요컨대 에이전트는 나머지 둘의 능력을 통합하고 격상시킨 시스템이다. 추론력은 LLM에서 빌려 오되, 정적인 워크플로가 할 수 없는 자율적이고 목표 지향적인 실행이 가능한 구조 안에 그것을 앉힌다.
The anatomy of an agent
에이전트의 해부학 — 일곱 부품과 하나의 고리
앞선 장들이 개념 수준의 개관이었다면 여기서는 아키텍처의 관점으로 같은 해부학을 다시 본다. 이 부품들을 개념이 아니라 기능하는 구성 블록으로 보는 것이다. 환경을 지각하고, 추론해 계획을 세우고, 목표를 향해 행동하는 연속 루프를 가능하게 하는 블록들이다.
〈해부도〉 일곱 부품과 그것들을 잇는 하나의 고리. 붉은 선은 외부와 미래로 이어지는 경로다.
에이전트가 달성하려는 목적이나 결과. 지시를 통해 지정된다. 아키텍처상으로는 에이전트의 목적함수를 정의하고 상위 계획을 이끈다. 설정 매개변수나 갱신 가능한 동적 상태로 구현된다.
환경(디지털이든 물리적이든)에서 정보와 데이터를 모은다. 입력 계층 노릇을 한다. API 리스너, 데이터 스트림 처리기, 또는 MCP 같은 표준 프로토콜로 구현된다.
감지된 정보를 분석하고 해석하는 핵심 처리 단위. 에이전트 준비된 LLM이 통합되는 인지 중추다. 입력을 해석하고, 목표에 비추어 평가하고, 상위 전략을 수립한다.
추론으로 얻은 통찰에 근거해 행동의 순서를 짠다. 역시 LLM이 구동하는 전술 계층이다. 추론 부품이 세운 상위 전략을 구체적이고 순서 있는 실행 단계 또는 도구 호출로 분해한다.
가용 도구로 계획된 행동을 환경에 실행한다. 출력 계층이다. 외부 API 호출, 코드 실행, 액추에이터로의 명령 전송, 응답 생성으로 구현된다.
지식·경험·상태를 저장해 결정에 맥락을 제공한다. 상태를 관리한다. 현재 과업을 위한 단기 변수와, RAG용 벡터 데이터베이스나 사용자 선호 같은 장기 영속 저장소로 구현된다.
다른 에이전트와 상호작용해 행동을 정렬하고 공동 목표를 향해 협업한다. 에이전트 간 통신 계층이다. 과업의 전 생애를 관리하며 submitted·working·input-required·completed 같은 표준 A2A 상태를 추적한다. Agent2Agent 프로토콜로 구현되며, 분산 경계를 가로질러 작업을 위임하고 상태를 결정론적으로 동기화한다.
〈표 4.2〉 에이전트 구성요소의 아키텍처상 역할
이 블록들은 정적이지 않다. 연속된 주기로 작동한다. 환경을 감지하고, 목표와 기억의 맥락에서 새 정보를 추론하고, 계획을 세우고, 환경에 행동한다. 그 행동의 결과가 다음 반복에서 다시 감지되어 강력한 피드백 루프를 만든다. 이 루프가 있어 에이전트는 시간에 걸쳐 배우고 행동을 조정한다.
Case study 1 · Single agent
여행 계획 에이전트 — 부품이 실제로 맞물리는 모습
해부학을 추상에서 실무로 옮기기 위해 이 장은 두 사례를 든다. 먼저 단일 에이전트 사례다. 목표·감지·추론·계획·행동·기억이 어떻게 협연해 하나의 요청을 처음부터 끝까지 이행하는지 보여준다.
| 해부 부품 | 여행 계획 에이전트의 실제 |
|---|---|
| 목표 Goals | 사용자의 요청을 이행하는 것이 일차 목적이다. 이 목표는 동적이어서 사용자가 마음을 바꾸거나 새 제약을 주면 갱신될 수 있다. |
| 감지 Sense | 사용자의 자연어 요청을 처리해 초기 정보를 모은다. 이후에도 항공사 API가 돌려주는 가용 항공편 목록, 호텔 예약 서비스의 가격 정보 같은 외부 시스템의 응답을 받으며 계속 “감지”한다. |
| 추론 Reason | LLM 중추가 명시적 선호(“파리”, “4성급”, “5박”)와 암묵적 의도를 분석한다. 항공·호텔 검색의 구조화 데이터를 해석하고, 예산 제약에 비추어 선택지를 비교하며, 최적 일정을 판별하는 복잡한 추론을 수행한다. |
| 계획 Plan | 요청을 하위 과업(항공 예약, 호텔 예약)으로 분해 → 항공 검색 실행 → 호텔 검색 실행 → 모든 제약을 만족하는 유효한 조합 탐색 → 최종 일정을 사용자에게 제시해 확인 → 최종 예약 실행. |
| 행동 Act | 가용 도구로 계획을 실행한다. search_flights(destination="CDG", month="next")와 find_hotels(city="Paris", rating=4, nights=5)를 호출한다. 확인 후에는 예약 함수를 호출하고 최종 확인 메시지를 생성하며, 사용자의 장기 프로필에 이번 선호를 갱신해 둔다. |
| 기억 Memory | 단기 기억으로 사용자의 선호, 찾아낸 항공·호텔 선택지, 현재 과업의 대화 이력을 저장한다. 장기 기억으로 과거 상호작용에서 확인한 선호 항공사나 호텔 체인을 떠올려 다음 제안을 개인화할 수 있다. |
| 조율 Coordinate | 멀티 에이전트 시스템이라면, 본 여행 예약 후 “루브르 박물관 입장권을 찾아 예매하라”는 메시지를 Excursion Agent에 보내 위임할 수 있다. 여행 전체를 계획한다는 공동 목표를 향한 협업이다. |
〈표 4.3〉 하나의 용례로 본 에이전트 구성요소
Case study 2 · Multi-agent
대출 처리 시스템 — 여럿이 나누어 맡을 때
한 금융기관이 대출 신청 과정을 자동화·최적화하려고 멀티 에이전트 시스템을 배치한다. 워크플로는 최초 고객 접촉에서 최종 실행까지 걸쳐 있고, 데이터 검증·신용 평가·위험 점수화·규제 점검·최종 승인을 포함한다. 각 에이전트는 파이프라인의 서로 다른 국면을 전담하며, A2A 프로토콜로 소통·조율하고 공유 메모리 계층에 접근해 일관된 맥락을 유지한다.
Agent 01
접수 Intake
신청인 데이터를 빠짐없이 수집한다.
Agent 02
신용 조회 Credit Check
신용 이력을 검증하고 이상을 플래그한다.
Agent 03
위험 평가 Risk
신청인의 위험 프로필을 점수화한다.
Agent 04
규제 준수 Compliance
규제 규칙 준수 여부를 검증한다.
Agent 05
승인 Approval
종합 입력에 근거해 최종 대출 결정을 내린다.
Agent 06–07
이의 Appeals · 실행 Disbursement
거절 시 대체 상품(예: 담보대출)을 제안하고, 승인 시 자금을 집행하며 백엔드를 갱신한다.
| 부품 | 대출 처리 시스템의 실제 |
|---|---|
| 감지 Sense | 접수 양식(자연어와 구조화 데이터), 신용평가기관 API 호출, 사내 CRM과 KYC 데이터베이스, 문서 OCR, 변동금리 대출을 위한 실시간 시장 피드. 각 에이전트는 MCP로 정형·비정형 데이터에 맥락적으로 일관되게 접근한다. |
| 추론 Reason | LLM이 구동하며 급여명세서·거래내역 같은 금융 문서의 의미, 정책 규칙과 위험 지침, 신청인 질의에서 추론한 의도, 그리고 데이터 간 모순(예: 소득 불일치)을 놓고 추론한다. 인지 중추가 입력을 에이전트 목표에 비추어 평가한다. |
| 계획 Plan | 접수 에이전트는 누락 정보의 후속 확인을 계획한다. 신용 조회 에이전트는 어느 평가기관(Equifax, TransUnion)을 어떤 순서로 조회할지, API 실패나 데이터 불일치를 어떻게 다룰지 전략을 세운다. 위험 에이전트는 대출 유형에 따라 점수 모델을 고르고, 규제 에이전트는 관할에 따라 필요한 점검을 선택하며, 승인 에이전트는 나머지의 출력을 통합하는 의사결정 트리를 세운다. |
| 행동 Act | 확인 이메일 발송, CRM의 대출 상태 갱신, 데이터 조회·기록을 위한 API 호출, 규제 감사 추적 생성, 과업 완료 시 하류 에이전트 촉발. |
| 기억 Memory | 단기는 신청인별 세션 기억. 장기는 축적된 사기 패턴, 과거 결정, 규제 변경 이력. 기억이 있어 학습 기반 개선이 가능하다. 새 위험 지표에 맞춰 조정하는 식이다. |
| 조율 Coordinate | Google의 A2A 프로토콜이 통신 계층 노릇을 한다. 과업 위임과 정보 교환을 위한 안전하고 표준적인 채널을 제공하고, 과업 상태(working·completed·failed)를 위임한 에이전트에 보고하게 하며, 서로 다른 플랫폼에서 만들어진 에이전트들이 내부 기억이나 논리를 공유하지 않고도 협업하도록 상호운용성을 보장한다. |
〈표 4.4〉 대출 처리에서의 에이전틱 해부 구성요소
4.1대출 신청의 생애주기
- 고객이 대출을 신청한다 → 접수 에이전트가 파싱해 공유 메모리에 저장한다.
- 신용 조회 에이전트가 촉발되어 API로 FICO 점수와 신용 이력을 가져온다.
- 위험 에이전트가 신용·소득·대출액을 놓고 추론해 위험 점수를 매긴다.
- 규제 에이전트가 KYC·AML·GDPR과 현지 은행 규정을 점검한다.
- 승인 에이전트가 입력을 통합하고 충돌을 추론해 승인 여부를 결정한다.
- 거절되면 이의 에이전트가 담보대출 같은 대체 상품을 제안할 수 있다.
- 실행 에이전트가 자금을 집행하고 백엔드 시스템을 갱신한다.
4.2A2A를 통한 조율 — 감사 가능한 위임의 사슬
에이전트들은 A2A 같은 정의된 프로토콜로 구조화된 과업을 서로에게 보내 협업한다. 이것은 직접 통신의 한 형태다. 보내는 에이전트가 특정 수신 에이전트에게 명시적으로 일을 위임한다.
예컨대 점수를 범용 버스에 publish 하는 대신, 오케스트레이터가 먼저 위험 에이전트에 과업을 보내고, 결과를 받으면 그 위험 점수를 페이로드에 담아 승인 에이전트에 새 과업을 보낸다. 이렇게 하면 명확하고 감사 가능한 위임의 사슬이 만들어진다. 경계선상의 신용점수 같은 분쟁이나 예외는 제안과 역제안을 주고받거나 다른 에이전트 또는 사람에게 에스컬레이션하는 A2A 메시지 연쇄, 곧 숙의 루프로 처리한다.
Benefit 01
응답성
신용점수 변동 같은 실시간 데이터 변화에 즉각 반응한다.
Benefit 02
설계에 의한 준수
모듈화된 규칙이 각 에이전트와 공유 정책 계층에 내장된다.
Benefit 03
투명성
기억 로그와 추론 추적이 감사와 규제 점검을 돕는다.
Benefit 04
적응성
에이전트가 독립적으로 진화한다. 위험 에이전트만 더 새로운 LLM으로 갈아 끼울 수 있다.
Data stores and environment context
데이터 저장소와 환경 맥락 — 지능은 안에서만 오지 않는다
앞선 절이 보여준 지능은 내부 설계에서만 나오지 않는다. 환경에서 끌어올 수 있는 데이터의 풍부함과 관련성에 결정적으로 의존한다. 1장에서 강조한 “맥락이 왕이다”는 원칙이 여기서 다시 걸린다. 그리고 그 원칙이 지켜지느냐 아니냐가 다음 두 갈래를 만든다.
Scenario A · Rich context
Scenario B · Grounding failure
〈그림 4.3〉 맥락 입력 대 그라운딩 실패. 두 흐름은 세 번째 단계에서만 갈린다.
5.1디지털 업무 맥락 네 가지
01
비정형 데이터
보고서·이메일·기사 같은 텍스트 문서와 이미지·오디오·비디오 파일. LLM은 특히 비정형 텍스트를 처리하고 이해하는 데 능하다.
02
벡터 스토어
임베딩에 대한 효율적 유사도 검색을 가능하게 하는 특수 데이터베이스. 키워드가 아니라 의미에 근거한 빠른 검색을 지원한다. 많은 RAG 시스템의 핵심이다. 자체 통제를 위한 오픈소스(FAISS, Weaviate, Chroma)와 확장성·관리 편의를 위한 상용 관리형 서비스(Pinecone, Vertex AI Vector Search)로 나뉜다.
03
정형 데이터
관계형 데이터베이스나 스프레드시트의 조직된 데이터. 고객 기록이나 제품 정보 조회처럼 특정 과업을 위해 질의할 수 있는 잘 정의된 데이터 지점을 제공한다.
04
지식 그래프
정보를 개체와 그 관계의 네트워크로 표현해 도메인에 대한 구조화된 의미 이해를 제공한다. 서로 얽힌 개념에 대한 복잡한 추론이 필요한 에이전트에 특히 유용하다.
5.2물리 환경 맥락
Sensors
센서
카메라, 마이크, 온도 센서, GPS 측위기 등이 물리적 주변에 대한 데이터를 제공한다.
Actuators
액추에이터
로봇 팔, 모터, 스위치 같은 구성요소가 물리적 행동을 수행하거나 환경의 대상을 조작하게 한다.
5.3공급망 관리 에이전트로 본 여섯 층위
| 맥락·저장소 | 공급망 관리 에이전트의 실제 |
|---|---|
| 비정형 데이터 | 선적 명세서(PDF), 이메일로 온 공급사 지연 통지, 항만 파업이나 기상 사태에 관한 뉴스 기사를 처리해 잠재적 교란을 파악한다. |
| 벡터 스토어 | 새로운 지정학적 사건이 감지되면, 비슷한 과거 사건이 해운 항로에 어떤 영향을 주었는지 다룬 사내 백서를 의미 기반으로 검색해 가장 관련성 높은 역사적 맥락을 가져온다. |
| 정형 데이터 | 관계형 데이터베이스에 질의해 특정 SKU의 현재 재고 수준, 예상 납기일, 창고 수용 능력을 확보한다. |
| 지식 그래프 | 공급사·제조공장·물류센터·최종 소매지 사이의 복잡한 다층 관계를 파악한다. 덕분에 단일 부품 공급사의 지연이 특정 제품군 셋에 영향을 준다는 추론이 가능해진다. |
| 센서 | 배송 트럭의 GPS 추적기, 냉장 컨테이너의 온도 센서, 창고 하역장의 RFID 스캐너에서 연속적인 데이터 스트림을 받는다. |
| 액추에이터 | 주요 경로에 큰 교란이 예상되면 스마트 창고의 컨베이어 벨트나 로봇 팔을 자동으로 작동시켜, 영향받는 팰릿을 대체 운송 경로용 다른 하역장으로 돌린다. |
〈표 4.5〉 데이터 저장소와 환경 맥락의 예
Architectural features
아키텍처가 낳는 다섯 특성
잘 설계된 에이전틱 아키텍처는 유연성과 견고성과 지능에 기여하는 몇 가지 특성을 낳는다. 개념을 다시 정의하는 대신, 앞의 공급망 관리 시스템을 하나의 일관된 예로 삼아 그것들이 실무에서 어떤 이익으로 번역되는지 보자.
| 아키텍처 특성 | 공급망 관리 시스템에서의 사례 |
|---|---|
| 모듈성 | 선적 송장에 대한 사기 탐지를 강화해야 한다. 기존 InventoryAgent를 재구축하는 대신 새로운 전문 InvoiceFraudAgent를 개발해 워크플로에 추가한다. 사기 탐지 모델을 갱신해야 할 때도 그 에이전트만 영향을 받는다. |
| 확장성 | 연말 성수기에 배송 트럭의 GPS 데이터가 폭증하면 LogisticsAgent 인스턴스를 병렬로 여러 개 동적 배치해 감당한다. 로드밸런서가 경로 최적화 과업을 인스턴스들에 분산해 시스템의 응답성을 유지한다. |
| 적응성 | SupplierCommsAgent가 “Supplier-X”에서 온 “production delay”라는 문구가 담긴 이메일이 늘 심각한 재고 부족에 선행한다는 것을 관찰한다. 이 학습된 상관을 써서 앞으로 그 키워드가 담긴 이메일을 자동으로 “긴급”으로 격상하고 즉시 InventoryAgent에 알리도록 행동을 스스로 바꾼다. |
| 멀티모달 상호작용 | 창고의 ReceivingDockAgent가 먼저 텍스트 기반 선적 명세서(PDF)를 처리하고, 이어 카메라로 입고된 팰릿의 파손 여부를 시각 검사한다(이미지 데이터). 그리고 시각 검사 결과가 명세서 기술과 일치할 때만 재고 시스템을 갱신한다. |
| 협업 | DisruptionMonitoringAgent가 뉴스 피드에서 항만 폐쇄를 감지해 공유 데이터베이스의 상태를 갱신한다. InventoryAgent가 이 변화를 감지하고 LogisticsAgent에 직접 메시지를 보내 대체 운송 경로를 요청하며, 두 에이전트 사이의 협업적 해결이 시작된다. |
〈표 4.6〉 공급망 관리 에이전트의 아키텍처 특성
Interaction models and the agentic stack
상호작용 모델과 에이전틱 스택 — 세 층으로 쌓인다
여러 에이전트가 같은 환경에서 작동할 때 어떻게 상호작용하느냐가 설계의 결정적 대목이 된다. 선택한 모델이 에이전트들이 어떻게 조율하고 정보를 나누고 공동 목표를 향해 일하는지를 규정한다. 기본 모델은 둘이다.
Model 01
직접 통신 · Direct communication
공통 언어와 프로토콜을 써서 에이전트들이 서로에게 명시적으로 메시지를 보낸다.
Model 02
간접 통신 · 스티그머지 Stigmergy
데이터베이스 같은 공유 환경을 관찰하고 변경함으로써 간접적으로 상호작용한다. 서로에게 말을 걸지 않는다. 환경에 흔적을 남길 뿐이다.
7.1신흥 에이전틱 스택 — 세 계층
이 개념적 모델이 실제로 구현되려면 기술 스택이 필요하다. 이 스택은 서로를 보완하는 세 계층으로 이뤄져 있다.
〈그림 4.5〉 신흥 에이전틱 스택. 위로 갈수록 경계를 넘는 범위가 넓어진다.
에이전트의 LLM이 로컬 도구를 촉발하는 근본 상호작용 계층이다. 어떤 도구를 언제 어떤 매개변수로 쓸지 지능적으로 판단하되, 모두 하나의 애플리케이션 런타임 안에서 이뤄진다. LLM을 텍스트 생성기 이상으로 만든 첫 도약이었다. 한계는 명확하다. 개발자가 같은 환경 안에서 도구의 호스팅·실행·보안을 모두 책임져야 한다.
예 — LogisticsAgent의 LLM이 가장 효율적인 배송 경로를 찾아야 한다고 판단해 내부 calculate_optimal_route() 함수 호출을 생성한다.
에이전트가 외부 도구를 상호운용 가능한 서비스로 발견하고 사용하는 표준화된 방법이다. MCP 같은 프로토콜은 도구의 호스팅과 실행을 에이전트에서 분리한다. LangChain의 ToolExecutor나 LangGraph 라우터 같은 프레임워크 종속 해법에서 크게 진화한 것이다. 그런 도구들은 특정 애플리케이션 런타임 안에서 실행을 관리하며 흔히 의존성 공유를 요구한다. 반면 MCP는 도구를 스키마로 정의하고 독립적으로 호스팅하게 해, 어떤 호환 시스템이든 프로세스와 네트워크 경계를 넘어 발견하고 호출할 수 있게 한다. 도구를 REST API처럼 이식 가능한 서비스로 바꾸는 셈이다.
예 — 날씨를 반영하려고 LogisticsAgent가 도구 프로토콜로 제3자 기상 서비스 API를 발견해 연결하고, 그 API 구현에 강하게 결합되지 않은 채 실시간 폭풍 데이터를 경로 계산에 끌어온다.
가장 높은 계층. 서로 다른 프레임워크나 서로 다른 기업에서 돌아갈 수 있는 독립 에이전트들 사이의 협업에 초점을 둔다. 독점적이거나 프레임워크 종속적인 위임 방식도 있지만, A2A 같은 프로토콜은 에이전트 협업의 보편 표준을 지향한다. 구조화된 과업의 위임, 비동기 워크플로 관리, 복잡한 멀티 에이전트 조율을 위한 표준을 제공한다. 사실상 보편 번역기, 곧 “AI 에이전트를 위한 SMTP” 노릇을 한다.
예 — 경로를 계산한 뒤 LogisticsAgent가 해상 운송을 예약해야 한다. A2A 프로토콜로 제3자 물류회사가 운영하는 완전히 별개의 FreightForwarderAgent에 구조화된 과업을 보낸다.
In practice
정교한 시스템 다수는 혼합 방식을 쓴다. 내부 행동에는 함수 호출을, 외부 협업에는 상위 프로토콜을 쓴다.
Technical considerations
기술 과제를 부품에 매핑하기 — 어디서 터지는가
1장에서 운영 전환의 난제를 개괄했다. 여기서는 그것을 되풀이하는 대신, 방금 뜯어본 해부학에 직접 연결한다. 각 기술 과제가 어느 아키텍처 부품에서 주로 터지는지 짚어 두면 설계할 때 어디를 보강해야 할지가 분명해진다.
| 기술적 고려사항 | 주로 영향받는 아키텍처 부품 |
|---|---|
| 데이터 처리와 통합 | 감지 Sense · 기억 Memory |
| 지식 표현 | 추론 Reason · 기억 Memory |
| LLM 통합과 오케스트레이션 | 추론 Reason · 계획 Plan · 조율 Coordinate |
| 신뢰할 만한 도구 사용 기제 | 행동 Act |
| 상태 관리와 기억 | 기억 Memory |
| 에이전트 개체군의 확장성 | 조율 Coordinate · 시스템 아키텍처 전반 |
| 에이전트 간 통신 효율 | 조율 Coordinate |
| 보안과 거버넌스 | 추론(프롬프트 인젝션) · 행동(샌드박싱) · 기억(프라이버시) · 조율(인증·인가) |
〈표 4.7〉 기술 과제를 에이전트 부품에 매핑
보안 항목을 눈여겨볼 만하다. 보안만 유일하게 네 부품에 걸쳐 있다. 추론에는 프롬프트 인젝션이, 행동에는 샌드박싱이, 기억에는 프라이버시가, 조율에는 인증과 인가가 걸린다. 한 군데를 막는다고 끝나지 않는다는 뜻이다.