AI 에이전트 프로토콜 및 아키텍처 개발자 가이드

홈 » Python » AI 에이전트 프로토콜 및 아키텍처 개발자 가이드

AI 에이전트는 소프트웨어를 수동적인 비서에서 능동적인 존재로 변화시키고 있습니다. 자율적인 협력자들 주변 환경을 인지하고, 복잡한 목표에 대해 추론하며, 우리를 대신하여 행동을 취할 수 있는 모델입니다. 개발자에게 이러한 변화는 모든 것을 바꿔놓습니다. 정적인 워크플로우를 LLM에 맞춰 구성하는 대신, 모델 자체가 제어 흐름을 주도하고, 도구를 조율하며, 다른 에이전트 및 서비스와 협력하는 시스템을 설계하게 됩니다.

진지한 관계를 구축하고 싶다면, 생산 등급 에이전트 시스템새로운 프로토콜을 이해하는 것은 더 이상 선택 사항이 아닙니다.에이전트가 도구에 접근하는 표준화된 방식(MCP), 에이전트 간 통신(A2A), 자연어를 통한 웹 상호작용(NLWeb)은 "에이전트 생태계"의 핵심 기반으로 빠르게 자리 잡고 있습니다. 이와 동시에, 에이전트 자체의 핵심 구성 요소인 모델, 도구, 명령어, 오케스트레이션 패턴 및 가이드라인을 숙달해야 합니다.

AI 에이전트란 ​​정확히 무엇이며, 일반 LLM과는 어떻게 다른가요?

AI 에이전트는 단순히 모델 자체가 아니라 LLM을 중심으로 구축된 완전한 시스템으로 이해하는 것이 가장 좋습니다.학계에서 통용되는 정의(예: 스탠포드 CS221)에 따르면, 에이전트는 환경에 위치하여 센서를 통해 환경을 인지하고 액추에이터를 통해 환경에 작용하여 특정 목표 달성 가능성을 극대화할 수 있는 계산 개체입니다.

실질적인 소프트웨어 관점에서 볼 때, 최신 AI 에이전트는 네 가지 요소를 결합합니다.: a 대형 언어 모델 추론 능력, 외부 도구 및 API 접근 권한, 시간 경과에 따른 맥락을 추적할 수 있는 메모리, 그리고 명확하게 정의된 목표 또는 역할이 필요합니다. 단순히 질문에 답하는 챗봇과 달리, 에이전트는 계획을 세우고, 도구를 호출하고, 그 결과에 반응하며, 목표 달성까지 워크플로를 반복적으로 진행할 수 있습니다.

흔히 혼동되는 부분은 "모델"과 "에이전트"를 혼동하는 것입니다.GPT-4나 Llama 3 같은 모델은 강력하지만 수동적인 "두뇌"입니다. 사용자가 명령을 내리기 전까지는 아무런 동작도 하지 않으며, 스스로 이메일을 보내거나 API를 호출하거나 데이터베이스를 업데이트할 수 없습니다. 반면 에이전트는 인지, 추론, 행동의 순환 고리 안에 모델을 담아냅니다. 에이전트는 모델의 예측을 바탕으로 어떤 도구를 사용할지, 언제 사용자에게 설명을 요청할지, 언제 작업을 중단할지 결정합니다.

핵심적인 차이점은 누가 워크플로를 통제하는가입니다.기존 소프트웨어에서는 코드가 실행 순서를 결정합니다. 즉, A이면 B, 그다음 C와 같이 말이죠. 하지만 에이전트에서는 LLM(로컬 라이프 매니저)이 현재 상태를 기반으로 다음 단계를 결정합니다. LLM은 동일한 상위 레벨 요청을 기반으로 주문 조회, 지원 티켓 생성, 또는 다른 상담원에게 사례 인계 등 다양한 조치를 취할 수 있습니다.

에이전트의 정교함 또한 단순한 반응형 시스템부터 학습 및 목표 지향적 아키텍처에 이르기까지 다양합니다.러셀과 노르빅의 고전적인 분류 체계는 여전히 이 분야를 이해하는 데 유용합니다. 여기에는 단순 반응형 에이전트(순수한 if-then 규칙), 모델 기반 반응형 에이전트(최소한의 내부 상태를 가짐), 목표 기반 에이전트(원하는 결과를 향해 계획을 세움), 효용 기반 에이전트(다양한 가능한 결과에 대해 수치적 점수를 최적화함) 및 학습 에이전트(피드백을 기반으로 정책을 조정함)가 포함됩니다.

인공지능 에이전트 시대에 프로토콜이 중요한 이유

에이전트의 기능이 향상되고 보급이 확대됨에 따라 통합 비용, 상호 운용성 및 보안이라는 세 가지 문제가 빠르게 나타납니다.각 API 또는 파트너 시스템마다 임시로 작성하는 연결 코드는 확장성이 떨어집니다. 독자적인 일회성 형식은 서로 다른 공급업체의 도구와 에이전트 간의 협업을 방해합니다. 또한 새로운 통합이 추가될 때마다 보안 취약점이 증가합니다.

에이전트 중심 프로토콜은 바로 이러한 문제점들을 해결하는 것을 목표로 합니다. 호스트가 LLM에 도구와 컨텍스트를 노출하는 방식(모델 컨텍스트 프로토콜, MCP), 에이전트가 조직 및 기술적 경계를 넘어 다른 에이전트와 통신하는 방식(에이전트 간 통신, A2A), 그리고 웹사이트가 사람과 에이전트 모두를 위해 자연어 우선 방식으로 콘텐츠와 활동을 노출하는 방식(자연어 웹, NLWeb)에 대한 개방형 표준을 정의함으로써 이를 실현합니다.

개발자에게 이러한 프로토콜은 에이전트와 서비스를 위한 "범용 어댑터"이자 "명함"과 같은 역할을 합니다.수십 개의 통합 로직을 하드코딩하는 대신, MCP 서버, A2A 호환 피어 또는 NLWeb 사이트와 한 번만 통합하면 프로토콜이 검색, 기능 및 인증을 처리합니다. 이를 통해 사용자 지정 통합 로직이 크게 줄어들고, 모든 기본 코드를 다시 작성하지 않고도 모델이나 도구를 변경할 수 있습니다.

동시에 프로토콜 수준의 보안이 필수적이 된다.프로토콜 계층에서의 접근 제어, 표준화된 인증, 그리고 명확한 기능 설명은 누가 어디서 어떤 제약 조건 하에 무엇을 할 수 있는지 파악하는 것을 훨씬 쉽게 만들어 줍니다. 이는 에이전트가 재고, 결제 또는 민감한 고객 데이터에 접근할 수 있는 기업 환경에서 매우 중요합니다.

모델 컨텍스트 프로토콜(MCP): 도구 및 데이터를 위한 범용 어댑터

모델 컨텍스트 프로토콜(MCP)은 애플리케이션이 LLM 기반 에이전트에 도구와 컨텍스트 데이터를 제공하는 방법을 정의하는 개방형 표준입니다.개념적으로 MCP는 상담원과 기존 시스템(데이터베이스, SaaS API, 내부 서비스) 사이에 위치하여 이러한 시스템들을 통합되고 검색 가능한 기능 세트로 전환합니다.

MCP는 세 가지 주요 역할을 가진 클라이언트-서버 아키텍처를 따릅니다.: 연결을 시작하는 호스트(IDE, 채팅 클라이언트 또는 에이전트 런타임과 같은 LLM 애플리케이션), 해당 호스트 내에서 MCP 서버와 일대일 연결을 유지하는 클라이언트 구성 요소, 그리고 특정 기능을 제공하는 경량 프로그램인 서버 자체로 구성됩니다.

MCP 내부에서 서버는 세 가지 핵심 기본 요소를 광고합니다. 상담원들이 일관된 방식으로 사용할 수 있는 요소로는 도구, 리소스, 프롬프트가 있습니다. 도구는 "날씨 가져오기", "제품 구매", "항공편 검색"과 같이 이름, 설명, 입력/출력 스키마를 가진 개별적인 작업입니다. 리소스는 파일, 데이터베이스 행, 로그와 같은 읽기 전용 데이터 항목으로, 텍스트 또는 바이너리 형식일 수 있습니다. 프롬프트는 프롬프트 설계 패턴이나 다단계 흐름을 캡슐화하는 미리 정의된 템플릿입니다.

동적 도구 검색은 MCP의 가장 큰 성과 중 하나입니다.여행 도우미에 특정 서명을 가진 "searchFlights" 함수가 있다고 하드코딩하는 대신, 에이전트는 항공사의 MCP 서버에 연결하여 기능 목록을 요청합니다. 서버는 도구, 해당 인수 및 예상 응답에 대한 기계 판독 가능한 설명을 반환합니다. 항공사가 "upgrade_booking" 도구를 추가하면 MCP 계약을 준수하는 한 코드 변경 없이 에이전트가 해당 도구를 찾을 수 있습니다.

MCP는 또한 의도적으로 모델에 구애받지 않습니다.이 프로토콜은 특정 벤더의 API가 아닌 기능과 컨텍스트에 관한 것이므로, 동일한 MCP 서버를 다양한 LLM 또는 에이전트 프레임워크에서 사용할 수 있습니다. 이를 통해 통합을 다시 구축하지 않고도 모델 교체 또는 멀티 모델 전략(예: 간단한 흐름에는 작고 저렴한 모델을 사용하고 복잡한 추론에는 강력한 모델을 사용)을 실험해 볼 수 있습니다.

또 다른 이점은 표준화된 보안입니다.MCP는 일관된 인증 메커니즘을 포함할 수 있으므로, 모든 타사 API에 대해 맞춤형 인증 흐름을 관리하는 것보다 훨씬 유지 관리가 용이합니다. 기업의 경우, 이는 "스테이징 환경의 단일 통합"에서 "프로덕션 환경의 수백 개의 MCP 서버"로 확장하더라도 키와 권한에 대한 제어권을 잃지 않고 깔끔하게 확장할 수 있음을 의미합니다.

구체적인 사례를 통해 MCP의 역할을 더욱 명확히 알 수 있습니다.예를 들어, 사용자가 AI 여행 도우미에게 "포틀랜드에서 호놀룰루까지 가는 항공편을 찾아 예약해 줘"라고 요청한다고 상상해 보세요. MCP 클라이언트 역할을 하는 도우미는 항공사의 MCP 서버에 연결하여 "search_flights" 및 "book_flight"와 같은 도구를 열거하고, 올바른 매개변수를 사용하여 "search_flights"를 호출하고, JSON 형식의 검색 결과를 받아 사용자에게 표시한 다음, 사용자가 선택한 옵션에 따라 "book_flight"를 호출합니다. 도우미는 항공사의 내부 API를 직접 호출하지 않고, 단순히 MCP 프로토콜을 사용하여 작동합니다.

에이전트 간(A2A): 다중 에이전트 협업을 위한 프로토콜

MCP가 에이전트를 도구 및 데이터에 연결하는 데 중점을 두는 반면, 에이전트 간 프로토콜은 에이전트들을 서로 연결하는 데 중점을 둡니다.단일체적인 "슈퍼 에이전트"를 넘어서는 순간, 전문 에이전트의 생태계 (여행, 청구, 물류, 지원 등) 각 부서 담당자들이 서로를 알아보고, 상황을 공유하며, 공동 작업을 위해 협업할 수 있는 깔끔한 방법이 필요합니다.

A2A는 이러한 분산형, 조직 간 오케스트레이션을 지원하도록 설계되었습니다.이를 통해 서로 다른 회사, 기술 스택 및 호스팅 환경의 에이전트들이 사전에 모든 상호 작용 경로를 고정할 필요 없이 사용자의 요청에 대해 협업할 수 있습니다. A2A 호환 "여행사 에이전트"는 완전히 다른 팀에서 개발한 "항공사 에이전트", "호텔 에이전트" 및 "렌터카 에이전트"에 전화를 걸 수 있습니다.

모든 A2A 에이전트는 기계 판독이 가능한 에이전트 카드를 제공합니다. 이는 MCP의 기능 목록과 유사한 역할을 하지만, 도구 수준이 아닌 에이전트 수준에서 작동합니다. 에이전트 카드에는 에이전트 이름, 담당 업무에 대한 자연어 설명, 해당 스킬을 호출해야 하는 시점에 대한 설명이 포함된 스킬 목록, 현재 엔드포인트 URL, 버전 정보, 그리고 스트리밍 응답이나 푸시 알림 지원 여부와 같은 플래그가 포함됩니다.

발신자 측에서는 에이전트 실행기가 컨텍스트를 전달하고 상호 작용을 관리하는 역할을 담당합니다.로컬 에이전트가 하위 작업을 위임하기로 결정하면 해당 실행기는 현재 대화, 관련 상태 및 제약 조건을 패키징하여 A2A를 통해 원격 에이전트로 전송합니다. 원격 에이전트는 자체 내부 도구와 LLM 루프를 실행한 다음 호출자가 내부 작동 방식을 알 필요 없이 결과를 반환합니다.

완료된 원격 작업의 결과는 아티팩트 형태로 반환됩니다.일반적으로 아티팩트는 작업 결과물, 수행된 작업에 대한 간략한 설명, 그리고 프로토콜을 통해 전달된 텍스트 컨텍스트를 포함합니다. 아티팩트가 전달되면 A2A 연결이 종료되어 각 상호 작용의 범위를 제한하고 비용을 절감하면서도 풍부한 협업을 가능하게 합니다.

장시간 실행되거나 비동기적으로 수행되는 작업의 경우, A2A는 종종 이벤트 큐를 사용합니다.원격 에이전트가 데이터를 처리하거나 외부 시스템을 기다리는 동안 연결을 몇 분 동안 유지하는 대신, 이벤트 큐가 메시지 전달 및 업데이트를 처리합니다. 이는 네트워크 복원력, 재시도 및 백프레셔가 중요한 프로덕션 수준의 다중 에이전트 시스템에서 특히 중요합니다.

A2A의 이점은 MCP의 이점과 유사하지만 생태계 수준에서 적용됩니다.이를 통해 다양한 공급업체의 에이전트 간 협업이 향상되고, 에이전트별로 최적의 LLM 또는 세부 조정 전략을 선택할 수 있는 유연성이 제공되며, 에이전트 간 통화의 보안과 감사 가능성을 보장하는 내장 인증 기능을 활용할 수 있습니다. 모든 기능을 단일 모놀리식 시스템에 억지로 집어넣으려는 대신, 여러 공급업체의 제품을 활용하는 "에이전트 팀"을 구축하는 것이 현실화됩니다.

자연어 웹(NLWeb): 웹 에이전트 친화적으로 만들기

웹은 문서와 HTML을 기반으로 구축되었지, 대화나 에이전트를 기반으로 구축된 것이 아닙니다.사용자들은 오랫동안 메뉴와 검색창을 통해 웹사이트에서 정보를 추출해 왔으며, 자동화된 접근 방식은 일반적으로 취약한 스크래핑이나 맞춤형 API에 의존해 왔습니다. NLWeb은 이러한 기존 방식과는 다른 모델을 제시합니다. 바로 사람과 AI 에이전트 모두를 위해 자연어를 기본적으로 지원하는 웹사이트입니다.

NLWeb 배포는 중앙 NLWeb 애플리케이션을 중심으로 이루어집니다.—자연어 질문을 입력받아 스토리지 및 모델에 연결하고 구조화된 답변을 반환하는 핵심 서비스 코드입니다. 사이트의 "언어 엔진"이라고 생각하시면 되며, 임베딩, 벡터 검색 및 LLM 추론을 조율합니다.

NLWeb 프로토콜 자체는 이러한 자연어 상호작용에 대한 기본 규칙을 정의합니다.NLWeb은 질문을 전송하고 답변을 받는 방식을 표준화하며, 일반적으로 Schema.org와 같은 어휘를 사용하여 JSON 형식으로 답변을 제공합니다. HTML이 문서 공유를 표준화한 것처럼, NLWeb은 언어 기반의 사이트 콘텐츠 및 작업 접근 방식을 표준화하여 "AI 웹"의 시대를 열고자 합니다.

모든 NLWeb 인스턴스는 MCP 서버 역할도 수행합니다.즉, MCP를 통해 외부 AI 시스템에 도구(예: "질문" 메서드)와 데이터 리소스를 노출할 수 있다는 의미입니다. 상담원 관점에서 보면, 여러분의 사이트는 또 다른 MCP 엔드포인트가 됩니다. 질문을 통해 "질문"을 호출하고, 카탈로그의 실제 항목과 연결된 구조화된 응답을 받아, 존재하지 않는 제품이나 페이지를 잘못 표시하는 오류를 방지할 수 있습니다.

NLWeb은 내부적으로 임베디드 모델과 벡터 데이터베이스를 적극적으로 활용합니다.사이트 콘텐츠(제품 목록, 호텔 설명, 블로그 게시물 등)를 입력하면 NLWeb은 이를 벡터 임베딩으로 변환하여 Qdrant, Milvus, Azure AI Search, Snowflake 또는 Elasticsearch와 같은 호환 가능한 벡터 저장소에 저장합니다. 쿼리 시에는 가장 유사한 항목을 검색하여 사용자의 질문과 함께 LLM(Learning Language Model)에 전달하고, LLM은 실제 콘텐츠를 기반으로 답변을 생성합니다.

여행 예약 사이트는 NLWeb이 실제로 어떻게 작동하는지 보여주는 훌륭한 사례입니다.항공편, 호텔, 패키지 상품에 대한 구조화된 데이터(이상적으로는 Schema.org 또는 RSS 피드 사용)를 수집하고, 임베딩을 생성하여 저장합니다. 사용자가 채팅창에 "다음 주 호놀룰루에서 수영장이 있는 가족 친화적인 호텔을 찾아주세요"라고 입력하면, NLWeb은 벡터 저장소에서 관련 호텔을 검색하고, LLM이 "가족 친화적" 및 기타 세부 제약 조건을 해석하도록 한 후, 실제 재고 정보를 기반으로 자연어 답변을 반환합니다. 동일한 NLWeb 인스턴스는 MCP 인터페이스를 통해 외부 여행사가 해당 호텔 근처의 비건 레스토랑에 대해 문의하고 일관되고 기계가 사용할 수 있는 JSON 형식의 답변을 받을 수 있도록 합니다.

인공지능 에이전트를 구축하는 것이 과연 합리적인 시점은 언제일까요?

모든 문제에 에이전트가 필요한 것은 아닙니다. 때로는 단순하고 결정론적인 서비스가 더 나을 수 있습니다.에이전트는 워크플로를 엄격한 규칙 집합으로 쉽게 정의할 수 없을 때, 비정형 데이터에 대한 의존도가 높을 때, 또는 예외 및 경계 사례가 많아 규칙 유지 관리가 어려울 때 진가를 발휘합니다.

에이전트에 특히 적합한 세 가지 유형의 사용 사례가 있습니다.복잡한 의사 결정(예: 미묘한 정책에 따라 고객 환불을 승인할지 여부 결정), 유지 관리가 어려운 규칙 집합(예: 복잡한 공급업체 보안 검토 또는 규정 준수 확인), 자연어 처리가 주를 이루는 흐름(클레임 처리, 자유 형식 고객 요청, 조사 작업) 등이 여기에 해당합니다.

유용한 발견적 방법은 끝없는 패치와 특수한 경우 규칙을 통해 성장해 온 시스템을 살펴보는 것입니다.숙련된 엔지니어조차 행동을 예측하거나 다른 부분을 손상시키지 않고 새로운 정책 변경 사항을 인코딩하는 데 어려움을 겪는다면, 근본적인 문제는 순전히 논리적인 것이 아니라 의미론적인 문제일 가능성이 높습니다. 바로 이런 상황에서 텍스트, 정책 및 예제를 기반으로 추론할 수 있는 LLM 기반 에이전트가 제 역할을 다할 수 있습니다.

반면, 입력과 출력이 명확한 매우 결정론적인 작업의 경우, 기존 방식이 일반적으로 더 저렴하고 빠르며 안정적입니다.만약 당신의 업무가 "이 숫자를 다른 형식으로 변환"하거나 "이 SQL 쿼리를 실행하고 행을 반환"하는 것이라면, 그 위에 에이전트 루프를 추가하는 것은 불필요한 복잡성을 초래할 가능성이 높습니다.

AI 에이전트의 핵심 구성 요소

과장된 홍보와는 달리, 잘 설계된 에이전트의 내부 구조는 상당히 간단합니다.거의 모든 패턴은 세 가지 핵심 요소로 요약됩니다. 추론을 수행하는 모델, 외부 세계와 연결하는 도구, 그리고 행동을 제약하고 안내하는 지침입니다.

이 모델은 의사결정 엔진입니다.LLM(로지스틱 회귀 모델)은 추론 품질, 지연 시간 및 비용 측면에서 장단점이 있습니다. 일반적이고 실용적인 전략은 다음과 같습니다. 먼저 성능이 뛰어난 모델로 품질 기준을 설정하고 해당 도메인에서 "좋은" 성능이 무엇인지 파악한 다음, 최고 수준의 추론이 필요하지 않은 분류 또는 검색과 같은 하위 작업에 대해 더 작거나 저렴한 모델을 점진적으로 테스트하는 것입니다.

도구를 사용하면 에이전트의 기능을 순수 텍스트 기반을 넘어 확장할 수 있습니다.에이전트가 호출할 수 있는 함수, API 또는 서비스입니다. 예를 들어 데이터베이스 쿼리, 이메일 전송, 웹 검색, 컴퓨터 사용 모델을 통한 기존 UI와의 상호 작용 등이 있습니다. 잘 설계된 도구는 문서화되어 있고, 에이전트 간에 재사용 가능하며, 이상적으로는 MCP와 같은 표준 프로토콜을 통해 노출됩니다.

안내 사항은 에이전트에게 있어 가장 과소평가되는 부분입니다.단순히 "도움을 주는 것"만으로는 부족합니다. 양질의 지침은 작업을 분해하는 방법, 정보가 부족할 때 어떻게 대처해야 하는지, 어떤 상황에서 어떤 도구를 사용하는 것이 좋은지, 성공의 기준은 무엇인지, 그리고 무엇을 피해야 하는지를 구체적으로 설명합니다. 많은 팀들이 기존의 표준 운영 절차(SOP), 헬프센터 문서 또는 내부 플레이북을 LLM 모델이 따를 수 있는 번호가 매겨진 지침으로 변환하여 성공적으로 활용하고 있습니다.

LLM 자체를 사용하여 지침을 자동으로 생성하거나 개선하는 것이 점점 더 일반화되고 있습니다.예를 들어, 도움말 센터 문서를 메타 프롬프트에 입력하여 모델이 해당 문서를 명확하고 번호가 매겨진 에이전트 지침 세트로 다시 작성하도록 요청할 수 있습니다. 여기에는 예외 상황에 대한 명시적인 처리도 포함됩니다. 이렇게 하면 문서가 발전함에 따라 동작이 문서와 일관되게 유지됩니다.

오케스트레이션 패턴: 단일 에이전트 시스템 vs 다중 에이전트 시스템

내부적으로 에이전트는 루프 내에서 실행됩니다.현재 상태를 관찰하고, 수행할 작업을 결정하고, (종종 도구를 통해) 실행하고, 컨텍스트를 업데이트하고, 종료 조건(목표 달성, 오류 발생, 사용자 개입 또는 안전장치 작동)이 충족될 때까지 이 과정을 반복합니다. 이러한 "에이전트 루프"가 일회성 LLM 호출을 지속적인 워크플로 엔진으로 전환하는 핵심입니다.

가장 간단한 아키텍처는 도구를 갖춘 단일 에이전트입니다.이 모델은 사용자 메시지를 수신하고, 메시지를 분석하여 어떤 도구를 호출할지 결정한 후 답변을 반환합니다. 프레임워크는 종종 특정 종료 기준(예: "더 이상 유용한 도구 호출이 없음" 또는 "구조화된 출력이 생성됨")이 충족될 때까지 모델을 계속 호출하는 실행기 구성 요소를 제공합니다. 이 패턴은 초기 버전 개발이나 범위가 명확한 문제에 적합합니다.

복잡성이 증가함에 따라 팀은 종종 멀티 에이전트 토폴로지로 전환합니다.크게 두 가지 유형이 있습니다. 관리자형 패턴에서는 중앙 "조정자" 에이전트가 전문 에이전트(예: 여러 언어로 번역하는 에이전트, 연구 에이전트, 비평가)에게 하위 작업을 위임합니다. 관리자는 전체적인 통제권을 유지하고 모든 것을 통합합니다.

두 번째 패턴은 더욱 분산형입니다.여기서 상담원들은 요청이 자신의 담당 영역을 벗어난다고 판단되면 동료에게 업무를 인계합니다. 예를 들어, 초기 상담원은 고객 메시지를 기술 지원, 영업 또는 주문 관리 상담원에게 전달할 수 있으며, 각 상담원은 고유한 지침과 도구를 사용합니다. 이러한 제어 흐름은 단일 중앙 계획자 없이 여러 상담원 간에 이루어집니다.

두 패턴 모두 더 큰 규모에서 A2A와 자연스럽게 결합될 수 있습니다.제품 또는 마이크로서비스 경계 내부에서는 오케스트레이터와 전문가를 결합한 모델을 사용할 수 있지만, 회사 또는 부서 간에는 A2A를 통해 외부 에이전트와 소통하며, 이 에이전트들은 에이전트 카드를 통해 자신들의 역량을 홍보합니다.

안전장치: 자율 에이전트의 안전성과 신뢰성 유지

에이전트에게 자율성을 부여한다는 것은 새로운 위험을 감수하는 것을 의미하기도 합니다.에이전트는 민감한 데이터를 유출하거나, 무단으로 변경하거나, 재정적 또는 평판에 부정적인 영향을 미치는 행동을 취할 수 있습니다. 가드레일은 에이전트의 유용성을 저해하지 않으면서 이러한 위험을 관리하는 보호 장치입니다.

방어적인 설계에는 일반적으로 여러 겹의 안전 난간이 포함됩니다.일부는 입력에 대해 작동하고(악의적이거나 범위를 벗어난 요청을 차단하거나 검증), 일부는 중간 모델 결정에 대해 작동하며(작업을 실행하기 전에 허용되는지 확인), 일부는 출력에 대해 작동합니다(응답이 시스템을 떠나기 전에 안전, 규정 준수 또는 데이터 유출 여부를 필터링).

많은 구현에서 안전장치는 에이전트의 낙관적인 진행과 "병렬로" 실행됩니다.에이전트 루프는 계속 진행되지만, 데이터를 수정할 수 있는 도구 호출과 같은 특정 단계는 안전장치 검사로 묶입니다. 안전장치가 위반 사항을 감지하면 작업을 중지하거나 예외를 발생시키거나 담당자에게 보고할 수 있습니다.

일부 안전장치는 LLM에 집중함으로써 마련되기도 합니다. 한계 및 위험 또는 심지어 에이전트예를 들어, 고객 이탈 감지 에이전트를 운영하여 수신되는 고객 메시지를 평가하고 해지 위험이 높은 메시지를 표시할 수 있습니다. 그러면 상위 수준의 가이드라인에서 이 신호를 사용하여 고객 유지 워크플로를 실행하거나 상호 작용을 종료하기 전에 담당자의 필수 검토를 요구할 수 있습니다.

운영 안전장치에는 엄격한 제한과 비상 탈출구도 포함됩니다.무한 루프를 방지하기 위한 최대 단계 수 제한, 민감한 작업에 대한 사람의 승인을 강제하는 위험 기반 임계값 설정, 모델의 신뢰도가 낮을 ​​때를 대비한 명확한 대체 방안 등은 모두 실제 환경에서의 안전한 배포에 기여합니다.

이론에서 실천까지: 주문 지원 에이전트의 단계별 설계

이러한 아이디어를 구체화하기 위해 온라인 쇼핑몰의 주문 지원 시스템 발전 과정을 살펴보겠습니다.초기 버전은 일반적으로 단순히 반응형 엔드포인트입니다. 주문 ID가 주어지면 데이터베이스에서 주문 상태를 가져와 반환합니다. 추론 기능, 메모리, 워크플로가 없으므로 아직 에이전트라고 할 수 없습니다.

첫 번째 에이전트적 단계는 모델이 워크플로를 제어하도록 하는 것입니다.주문 ID가 있다고 가정하는 대신, 전체 대화를 모델에 전달하고 모델이 어떻게 처리할지 결정하도록 합니다. 사용자가 ID를 제공하지 않고 "내 패키지는 어디 있나요?"라고 묻는 경우, 모델은 "주문 ID 요청" 액션을 선택하고 사용자에게 추가 정보를 입력하도록 요청할 수 있습니다.

다음으로, 이러한 추론 과정을 반복문으로 감싸고 상태를 도입합니다.사용자 메시지 또는 도구 호출이 있을 때마다 상담원은 상황을 재평가합니다. 주문을 조회하거나, 컨텍스트를 업데이트하거나, 응답하기에 충분한 정보가 있는지 확인하거나, 추가 질문을 할 수 있습니다. 이 과정은 명확한 응답이 전송되거나 종료 조건에 도달할 때까지 계속됩니다.

범위가 상태 확인을 넘어 확장됨에 따라 에이전트는 의도에 따라 도구를 동적으로 선택하기 시작합니다.배송 문제는 "open_incident"로, 환불 요청은 "initiate_refund"로, 간단한 주문 상태 조회는 "get_order_status"로 전달될 수 있습니다. 고정된 if-else 분기 트리를 직접 코딩하는 대신, 모델은 사용자가 정의했거나 MCP를 통해 발견된 도구 메뉴에서 적절한 작업을 선택합니다.

이 시점에서 민감한 도구에 대한 안전장치와 위험 평가를 도입해야 합니다.읽기 전용 작업은 직접 실행될 수 있지만, 상태를 변경하는 모든 작업(환불 처리, 주문 취소, 주소 변경 등)은 위험도를 고려한 안전장치를 거쳐야 합니다. 위험도가 높은 작업은 사람의 승인이 필요하고, 중간 위험도의 작업은 추가 확인 절차를 거칠 수 있으며, 위험도가 낮은 작업은 자동으로 진행될 수 있습니다.

마지막으로 운영 범위와 인계 규칙을 설정합니다.에이전트가 최대 실패 횟수에 도달하거나, 모순된 정보를 접하거나, 자신의 권한 범위를 벗어난 고위험 결정을 내려야 하는 경우, 누적된 모든 컨텍스트 정보를 가지고 인간 지원 상담원에게 인계합니다. 이러한 하이브리드 접근 방식을 통해 예외적인 상황에 대한 제어권을 유지하면서 자율성을 안전하게 배포할 수 있습니다.

고급 추론 프레임워크 및 최신 에이전트 도구

이러한 기본적인 아키텍처 외에도, 고급 추론 프레임워크는 LLM이 블랙박스 오라클보다는 의도적인 에이전트처럼 작동하도록 돕습니다.널리 사용되는 두 가지 패턴은 사고 연쇄(Chain-of-Thought, CoT)와 반응(ReAct, 추론 + 행동)입니다.

사고 연쇄 기법은 모델에게 단계별로 생각하도록 요청하는 것입니다.복잡한 질문을 최종 답변을 도출하기 전에 중간 추론 단계로 분해하는 방식입니다. 연구에 따르면 이러한 방식은 대규모 모델에서 추론이 많이 필요한 작업의 성능을 크게 향상시킬 수 있으며, 에이전트 루프에 자연스럽게 적용됩니다. 즉, 각 도구 호출은 더 넓은 추론 과정에 부합합니다.

ReAct는 추론과 도구 사용을 긴밀하게 연결합니다.에이전트는 생각, 행동, 관찰을 명시적으로 번갈아 수행합니다. 즉, 무엇을 하려고 하는지 설명하고, 도구를 호출하고, 출력을 검토하고, 계획을 업데이트합니다. 이러한 패턴은 AutoGPT나 BabyAGI와 같은 초기 자율 에이전트 시스템의 기반이 되며, 이러한 시스템들은 사용자의 목표를 향해 할 일 목록을 동적으로 생성하고 우선순위를 재조정합니다.

최신 프레임워크와 SDK는 이러한 개념들을 개발자 친화적인 추상화 형태로 제공합니다.LangChain, LangGraph, CrewAI 또는 더 작은 "smolagents" 스타일의 툴킷과 같은 라이브러리는 도구 호출, 그래프 기반 워크플로, 다중 에이전트 오케스트레이션 및 영구 메모리를 위한 구성 요소를 제공합니다. 이러한 툴체인 중 상당수는 또한 다음과 같은 지침도 포함합니다. VS Code의 사용자 지정 에이전트클라우드 공급업체와 OpenAI 같은 기업들이 제공하는 독점 플랫폼은 에이전트, 안전장치 및 평가를 위한 고급 구조를 추가합니다.

중요한 점은 이러한 프레임워크들이 MCP, A2A, NLWeb과 같은 프로토콜들과 점점 더 통합되고 있다는 것입니다.에이전트는 일회성 커넥터를 내장하는 대신 표준화된 기능 계층에 연결하고, 에이전트 카드를 통해 외부 에이전트와 통신하며, NLWeb 지원 사이트를 일급 자연어 API로 처리할 수 있습니다. 이러한 프로토콜과 도구의 융합이 대규모의 상호 운용 가능한 에이전트 생태계를 가능하게 합니다.

이 모든 것은 노코드 솔루션부터 하이코드 솔루션에 이르는 연속선상에 놓여 있습니다.노코드 환경의 시각적 플랫폼을 사용하면 개발자가 아닌 사용자도 드래그 앤 드롭 인터페이스와 자연어 설정을 통해 에이전트 워크플로 및 도구를 구성할 수 있습니다. 반면, 하이코드 환경은 엔지니어에게 오케스트레이션, 평가 및 배포에 대한 정밀한 제어 권한을 제공하며, 종종 프레임워크와 AWS, Azure 또는 유사한 클라우드의 사용자 지정 인프라를 결합합니다.

이러한 스펙트럼 전반에 걸쳐, 성공하는 조직은 단순히 에이전트를 소비하는 것이 아니라 에이전트를 설계하는 방법을 배우는 조직입니다.프로토콜, 패턴 및 가이드라인을 이해하면 단순히 "챗봇을 사용해 보는" 실험을 넘어 견고하고 확장 가능한 자동화를 구현할 수 있습니다. 내부 분석 에이전트와 개발자 보조 시스템부터 재고, 결제 및 고객 경험을 실시간으로 관리하는 다중 에이전트 시스템에 이르기까지 모든 단계에 적용할 수 있습니다. 에이전트가 더욱 발전함에 따라 이러한 설계 기술은 진정한 경쟁 우위 요소가 됩니다.