AI 에이전트: 에이전틱 AI 아키텍처와 거버넌스 가이드

엔터프라이즈 AI는 고립된 프롬프트의 시대를 지나고 있습니다. 불과 1년 전만 해도 많은 AI 이니셔티브는 직원에게 챗봇 액세스를 제공하는 데 초점을 맞췄습니다. 파일을 업로드하고, 요약을 요청하고, 질문하는 식이었습니다. 이제 조직은 데이터, 도구, 코드베이스, 비즈니스 워크플로우 전반에서 작동하고, 다단계 작업을 완료하는 데 필요한 충분한 컨텍스트와 제어를 갖춘 에이전틱 AI 시스템을 원합니다.

그러나 AI 에이전트를 단순히 권한이 더 많은 챗봇처럼 다뤄서는 안 됩니다. 컨텍스트에 대한 액세스는 필요하지만, 모든 시스템에 대한 무제한 액세스가 허용되어서는 안 됩니다. 도구에 대한 액세스는 필요하지만, 어떤 도구든 어떤 방식으로든 사용할 수 있는 자유가 주어져서는 안 됩니다. 작업을 수행할 만큼의 자율성은 필요하지만, 조직이 에이전트가 무엇을 했고, 어떤 데이터를 사용했으며, 왜 특정 행동을 취했는지 확인할 수 있을 만큼의 제어도 함께 필요합니다.

Gartner는 2028년까지 엔터프라이즈 소프트웨어 애플리케이션의 33%가 에이전틱 AI를 포함할 것으로 예측합니다. 이는 2024년 1% 미만에서 크게 증가한 수치입니다.¹ 에이전트가 엔터프라이즈 소프트웨어 계층의 일부가 되면서, 실질적인 과제는 여러 벤더에 걸쳐 작동하고 권한을 유지하며 작업을 감사 가능하게 만드는 거버넌스 계층을 통해 에이전트를 데이터, 도구, 워크플로우와 연결하는 방법입니다.

AI 에이전트는 AI를 사용해 목표를 추구하고, 의사 결정을 내리며, 애플리케이션이나 다른 시스템을 통해 행동을 수행하는 소프트웨어 시스템입니다. 먼저 요청을 해석하고 컨텍스트를 수집한 뒤, 다음에 무엇을 할지 결정하고 적절한 도구를 호출하며 결과를 확인합니다. 그리고 원하는 결과에 도달하거나 작업을 사람 또는 다른 시스템에 넘길 때까지 계속 진행합니다.

현재 대부분의 엔터프라이즈 에이전트는 추론 계층으로 대규모 언어 모델(LLM)을 사용합니다. 하지만 AI 에이전트는 모델 그 자체를 훨씬 넘어서는 개념입니다. 여기에는 모델을 둘러싼 오케스트레이션 로직이 포함됩니다. 즉, 동작을 규정하는 지침, 다음 단계를 결정하는 계획 루프, 참조할 수 있는 메모리 또는 작업 상태, 승인된 도구와 데이터 소스를 호출하게 해주는 커넥터입니다.

에이전틱 AI vs. 생성형 AI vs. ML

기존 머신러닝(ML)은 자동화된 워크플로우 안에 포함될 수 있고 생성형 AI는 도구와 연결될 수 있지만, 그 자체만으로 에이전틱하다고 볼 수는 없습니다. AI 시스템을 에이전틱하게 만드는 것은 모델을 둘러싼 목표 지향적 루프입니다. 즉, 컨텍스트, 연결성, 도구 사용, 상태, 그리고 다단계 작업을 수행할 만큼의 충분한 자율성이 결합되어야 합니다.

• 기존 ML은 예측하거나 분류합니다. 머신러닝 시스템은 일반적으로 데이터의 패턴을 인식하도록 훈련되며, 예측, 분류, 점수 또는 추천을 반환합니다. 모델의 출력은 워크플로우에 참고 신호를 제공할 수 있지만, 워크플로우 자체는 모델 외부에서 정의됩니다.
• 새로운 콘텐츠를 생성하는 생성형 AI 생성형 AI 모델은 프롬프트나 입력을 바탕으로 텍스트, 이미지, 코드, 오디오 등 다양한 결과물을 만들어냅니다. 사용자가 질문을 하거나 요약을 요청하거나 지시를 제공하면 모델이 응답을 생성합니다. 상호작용은 대화형일 수 있지만, 일반적으로 시스템의 역할은 사용자를 위한 결과물을 생성하는 데 그칩니다.
• 목표를 향해 행동하는 에이전틱 AI 에이전틱 AI는 컨텍스트를 검색하고, 다음 단계를 선택하며, 도구를 호출하고, 결과를 관찰한 뒤 원하는 결과에 도달하거나 작업을 넘길 때까지 계속 진행할 수 있는 더 큰 시스템 안에서 모델을 활용합니다. 모델이 추론이나 생성을 담당할 수는 있지만, 에이전틱 시스템은 그 모델에 컨텍스트에 대한 액세스, 행동을 실행할 경로, 다음에 무엇을 할지 결정하는 프로세스를 제공합니다.

AI 에이전트와 데이터 에이전트의 차이

데이터 에이전트는 데이터 업무에 특화된 AI 에이전트입니다. 자연어, 비즈니스 컨텍스트, 데이터 시스템을 연결해 사람들이 여러 도구를 수동으로 오갈 필요 없이 질문하고, 쿼리를 생성하고, 메타데이터를 검토하고, 품질을 확인하고, 데이터 세트를 요약하거나 이상 징후를 조사할 수 있게 합니다.

데이터 에이전트에는 거버넌스가 적용된 데이터 액세스가 필요합니다. 또한 지표 정의, 테이블 최신성, 컬럼 수준 계보, 소유권, 액세스 정책, 승인된 쿼리 경로를 이해해야 합니다. 예를 들어 사용자가 지역별 고객 이탈률을 묻는다면, 에이전트는 어떤 이탈 정의가 승인됐는지, 어떤 고객 테이블이 최신인지, 해당 사용자가 행 수준 세부 정보를 볼 수 있는지, 답변을 집계 형태로 제공해야 하는지를 알아야 합니다.

Snowflake의 CoWork & Agents 제품 책임자인 William Allen은 “지금 가장 중요한 승부처는 컨텍스트를 추가하는 방식입니다.”라고 설명합니다. “핵심은 에이전트가 부담을 느끼거나 임의의 경로로 흐르지 않도록 하면서, 매 순간 필요한 컨텍스트를 어떻게 제공하느냐입니다.”

데이터 에이전트는 다양한 유형의 데이터 전반에서 작동할 수 있어야 합니다. 매출을 조사하려면 SQL 테이블, 계약 PDF, 지원 상담 기록, 대시보드 정의가 함께 필요할 수 있습니다. AI 데이터 에이전트는 거버넌스가 적용된 인터페이스를 통해 이러한 오브젝트를 한데 모아, 모델이 액세스 제어를 우회하지 않고도 비즈니스 질문을 추론할 수 있게 합니다.

기업의 AI 에이전트 도입이 데이터 아키텍처에 관한 의사결정을 수반하는 이유도 여기에 있습니다. 에이전트의 답변은 기초 데이터의 품질, 최신성, 시맨틱, 권한에 좌우됩니다.

AI 에이전트가 독립 실행형 모델보다 더 큰 가치를 제공하는 이유는 단계를 계획하고, 컨텍스트를 유지하거나 검색하며, 도구를 사용해 모델 자체를 넘어서는 정보에 기반해 행동할 수 있기 때문입니다.

• 수동 오케스트레이션 감소 사용자는 컨텍스트를 검색해 프롬프트에 붙여넣고, 요약을 요청하고, 답변을 다른 시스템에 복사하고, 빠진 내용이 있으면 다시 프롬프트를 입력하고, 모든 단계를 수동으로 확인할 필요가 없습니다. 에이전트는 워크플로우 안에서 검색, 추론, 실행, 검증 루프의 더 많은 부분을 처리합니다.
• 질문에서 데이터 기반 답변까지의 경로 단축 파이프라인 비용이 왜 증가했는지 묻는 사람이 사용량 이력이 어느 테이블에 저장되는지, 승인된 비용 배분 로직이 어느 뷰에 있는지, 어떤 대시보드 소유자가 계산 방식을 변경했는지까지 알아야 할 필요는 없습니다. 거버넌스가 적용된 데이터 에이전트는 질문을 데이터 작업으로 변환하고, 적절한 컨텍스트를 검색해, 비즈니스 언어로 답을 제시할 수 있습니다.
• 반복적인 의사결정 지점의 일관성 강화 티켓 분류, 데이터 품질 검사, 로그 검토, 계정 위험 요약은 모두 대량의 작업에 동일한 추론 프로세스를 적용하는 데 달려 있습니다. 사람의 검토는 여전히 중요하며, 예외 상황에서는 특히 그렇습니다. 다만 반복 가능한 부분은 에이전트가 일관된 경로로 처리합니다.
• 적응형 자동화 구현 규칙 기반 워크플로우는 입력이 예상과 다르게 바뀌면 중단됩니다. 에이전트는 새로운 조건을 검토하고, 계획을 수정하며, 승인된 다른 경로를 선택할 수 있습니다. 이러한 적응성이야말로 에이전트가 유용한 이유이며, 동시에 거버넌스가 실행 계층 가까이에 자리해야 하는 이유입니다.

AI 에이전트의 초기 사용 사례로 가장 적합한 것은 반드시 가장 화려한 사례가 아닙니다. 대개 반복적이고 컨텍스트가 많으며 여러 시스템에 걸쳐 수행되는 워크플로우가 여기에 해당합니다.

고객 서비스

고객 서비스와 지원 영역에서 에이전트는 티켓을 선별하고, 계정 컨텍스트를 검색하며, 이슈를 분류하고, 응답 초안을 작성하고, 예외 사항을 사람 검토자에게 라우팅합니다. 에이전트가 에스컬레이션 경로를 대체하는 것은 아닙니다. 반복적인 컨텍스트 수집과 1차 해결 업무를 처리해, 에스컬레이션이 필요한 경우를 더 선별적으로 좁혀줍니다.

소프트웨어 개발

소프트웨어 개발에서 코딩 에이전트는 코드베이스 전반에서 계획을 세우고, 작성하고, 테스트하고, 수정합니다. 자동 완성과의 차이는 범위에 있습니다. 코딩 에이전트에는 리포지토리 컨텍스트, 이슈 컨텍스트, 종속성 정보, 테스트 결과, 프로젝트별 지침이 필요합니다. 또한 어떤 코드를 변경할 수 있는지, 어떤 명령을 실행할 수 있는지, 어떤 작업에 사람의 승인이 필요한지에 대한 가드레일도 필요합니다.

데이터 운영

데이터 운영에서 에이전트는 파이프라인을 모니터링하고, 데이터 품질 문제를 점검하며, 계보를 추적하고, 영향을 받는 다운스트림 자산을 식별합니다. 최신성 검사가 실패했을 때도 에이전트가 어떤 소스 테이블이 변경됐는지, 어떤 변환이 여기에 의존하는지, 어떤 대시보드가 영향을 받는지, 해당 워크플로우의 소유자가 누구인지 보여줄 수 있다면 훨씬 더 유용한 정보가 됩니다.

영업 운영

영업 및 매출 운영에서 에이전트는 고객 관계 관리(CRM) 데이터, 통화 녹취록, 계정 이력, 제품 사용 현황을 종합해 위험 계정을 식별하거나 고객 접촉 초안을 작성합니다. 유용한 출력은 일반적인 계정 요약이 아닙니다. 현재 고객 컨텍스트에 기반하고, 근거가 된 소스 신호까지 확인할 수 있는 추천이어야 합니다.

IT 및 보안 운영

IT 및 보안 운영에서 에이전트는 로그를 검토하고, 알림 간 상관관계를 분석하며, 자산 컨텍스트를 검색하고, 인시던트 분류를 지원합니다. 이러한 워크플로우에는 엄격한 거버넌스가 필요합니다. 에이전트가 민감한 시스템, 보안 텔레메트리, 영향도가 큰 작업에 관여할 수 있기 때문입니다. 초기 배포 단계에서 가장 안전한 방식은 에이전트를 활용해 컨텍스트 수집 시간을 줄이면서도 사람을 승인 루프 안에 두는 경우가 많습니다.

선도적인 AI 연구자 Andrew Ng가 AI 에이전트와 에이전트형 추론의 부상을 설명하는 영상을 확인해 보세요.

대부분의 AI 에이전트는 감지, 추론, 계획, 조정, 실행, 개선으로 이어지는 루프를 따릅니다. 프레임워크마다 명칭은 다를 수 있지만, 이 시퀀스가 설명하는 운영 패턴은 동일합니다.

감지

에이전트는 먼저 환경을 감지합니다. 이는 사용자 프롬프트를 읽거나, 문서를 검색하거나, 테이블을 점검하거나, 워크플로우 시스템에서 이벤트를 수신하거나, 도구 호출의 출력을 관찰하는 것을 의미할 수 있습니다. 입력은 단순한 문장에 그치는 경우가 드뭅니다. 엔터프라이즈 워크플로우에서는 메타데이터, 권한, 소스 컨텍스트, 비즈니스 규칙, 이전 작업 상태가 함께 포함되는 경우가 많습니다.

추론

그다음 에이전트는 목표와 사용 가능한 컨텍스트를 바탕으로 추론합니다. 어떤 정보가 중요하고, 무엇이 부족하며, 어떤 제약 조건이 적용되는지 판단합니다. 데이터 에이전트라면 여기에는 메트릭의 의미, 테이블의 최신성, 사용자의 액세스 권한, 요청된 답변에 민감 데이터 조인이 필요한지 여부 등이 포함될 수 있습니다.

계획

계획 수립은 이러한 추론을 실행 경로로 전환합니다. 에이전트는 어떤 단계를 수행할지, 어떤 도구를 호출할지, 어떤 순서를 따를지 결정합니다. 고정된 워크플로우에서는 경로가 사전에 정의될 수 있습니다. 더 자율적인 워크플로우에서는 에이전트가 이미 관찰한 내용을 바탕으로 다음 단계를 선택합니다.

조정

여러 도구, 에이전트 또는 승인 단계가 관여할 때는 조정이 중요해집니다. 한 에이전트가 관련 문서를 검색하는 동안 다른 에이전트는 정책 제약 조건을 확인할 수 있습니다. 감독 에이전트는 하위 작업을 위임하고, 결과를 비교하며, 다음 작업에 사람 검토자의 승인이 필요한지 판단할 수 있습니다.

실행

그다음 에이전트는 실행에 옮깁니다. 함수를 호출하고, 쿼리를 실행하며, 티켓을 업데이트하고, 메시지를 보내고, 코드 초안을 작성하고, 워크플로우를 트리거하거나 답변을 반환합니다. 거버넌스가 적용되는 환경에서는 어떤 일이 발생했는지 재구성할 수 있을 만큼 충분한 세부 정보가 작업 로그에 남아야 합니다. 여기에는 요청, 액세스한 데이터, 사용된 도구, 반환된 출력, 그리고 그 결과에 이르게 된 의사결정 경로가 포함됩니다.

개선

마지막으로 에이전트는 운영 관점에서 학습합니다. 피드백을 반영하고, 작업 상태를 업데이트하며, 승인된 메모리를 저장하거나 이후 단계를 조정합니다. 이러한 학습이 반드시 파운데이션 모델의 재학습을 의미하는 것은 아닙니다. 대부분의 경우 모델 주변 시스템을 개선하는 것을 뜻합니다. 메모리 업데이트, 평가 결과, 프롬프트 변경, 정책 튜닝, 더 나은 도구 라우팅 등이 여기에 해당합니다.

AI 에이전트는 다양한 방식으로 추론하고 실행하도록 설계될 수 있습니다. 어떤 워크플로우는 모델이 응답하기 전에 문제를 먼저 깊이 검토하도록 요구합니다. 또 다른 워크플로우는 에이전트가 도구와 상호 작용하고, 결과를 관찰한 뒤, 다음 단계를 수정할 수 있게 합니다. 적합한 패턴은 작업의 예측 가능성, 환경이 제공하는 피드백의 수준, 조직이 워크플로우에 대해 필요로 하는 통제 수준에 따라 달라집니다.

• 단계별 추론 초기 에이전트 설계는 LLM을 위해 개발된 프롬프팅 기법에서 많은 부분을 차용했습니다. 그 선행 개념 중 하나가 단계별 추론입니다. 이는 모델이 답변을 생성하기 전에 문제를 중간 단계로 나누도록 프롬프트를 제공하는 방식입니다. 이 설정에서는 최종 응답이나 실행 전에 추론이 먼저 이루어집니다. 워크플로우가 추가 실행 기회를 제공하지 않는 한, 모델은 외부 피드백을 반영해 경로를 수정하지 않습니다.
• ReAct: ReAct는 reasoning and action의 약자로, 작업 시퀀스를 바꿉니다. 처음에 한 번만 추론하는 대신, 에이전트는 추론, 행동, 관찰을 번갈아 수행합니다. 예를 들어 테이블을 쿼리하고, 결과를 검토한 뒤 지표 정의가 모호하다는 점을 파악하고, 메타데이터를 조회한 다음 다음 단계를 수정할 수 있습니다. chain-of-thought와의 차이는 단순히 “더 많이 추론”하는 데 있지 않습니다. 핵심은 에이전트가 도구나 환경과 상호 작용한 뒤 추론이 달라진다는 점입니다.
• 반영: 리플렉션은 또 하나의 검증 단계를 더합니다. 에이전트는 출력을 확정하거나 워크플로우를 계속 진행하기 전에 자신의 답변, 계획 또는 도구 결과를 검토합니다. 코딩 에이전트라면 테스트를 생성하고 실행한 뒤, 실패 지점을 확인하고 자신이 작성한 코드를 비판적으로 검토할 수 있습니다. 데이터 에이전트라면 SQL 쿼리를 생성하고 결과를 사용자 요청과 비교한 다음, 지표 정의상 트랜잭션 날짜를 사용해야 하는데 쿼리가 예약 날짜 기준으로 필터링되었다는 점을 식별할 수 있습니다.
• 계획 기반 및 반응형: 계획 기반 에이전트와 반응형 에이전트는 또 다른 구분 기준을 제시합니다. 계획 기반 에이전트는 행동에 앞서 다단계 계획을 수립하며, 이 과정에는 체크포인트와 종속성이 포함되는 경우가 많습니다. 반응형 에이전트는 조건이 바뀔 때마다 한 단계씩 선택합니다. 아키텍처에 정의된 계획 모듈은 에이전트가 시작하기 전에 어느 정도의 구조가 마련되는지, 그리고 경로를 수정할 자유도가 얼마나 주어지는지를 결정합니다.
• 프롬프트 체이닝: 프롬프트 체이닝은 하나의 작업을 더 작은 프롬프트의 시퀀스로 분해합니다. 하나의 프롬프트가 엔터티를 추출하고, 다음 프롬프트가 컨텍스트를 조회하며, 이어지는 프롬프트가 결과를 요약하고, 마지막 프롬프트가 최종 답변의 형식을 구성합니다. 체이닝은 일반적으로 ReAct보다 더 고정적이고 순차적입니다. 워크플로우가 사전에 명확히 정의되어 있고 각 단계의 결과가 다음 단계의 입력으로 이어질 때 유용합니다.

대부분의 프로덕션 에이전트는 이러한 패러다임을 조합해 사용합니다. 하나의 워크플로우는 계획에서 시작해 ReAct로 누락된 정보를 수집하고, 고위험 출력 전에는 리플렉션을 적용하며, 승인된 함수, API, 워크플로우 노드 또는 Model Context Protocol(MCP) 연결 시스템을 호출하기 위해 구조화된 도구 호출에 의존할 수 있습니다. 설계에서 중요한 질문은 어떤 패러다임이 가장 우수한지가 아니라, 해당 작업에 필요한 유연성, 피드백, 제어 수준이 어느 정도인지입니다.

AI 에이전트는 일반적으로 단순 반사 에이전트, 모델 기반 반사 에이전트, 목표 기반 에이전트, 유틸리티 기반 에이전트, 학습 에이전트라는 다섯 가지 대표 유형으로 설명됩니다. 이러한 분류는 초기 AI 연구에서 비롯되었지만, 현대적인 에이전트 시스템의 설계 선택을 이해하는 데 여전히 유용합니다.

• 단순 반사 에이전트는 사전에 정의된 규칙에 따라 현재 상태에 반응합니다. 조건이 참이면 그에 맞는 행동을 수행합니다. 이 설계는 조건이 안정적인 좁은 범위의 작업에는 적합하지만, 세계에 대한 모델을 유지하거나 향후 결과까지 추론하지는 않습니다.
• 모델 기반 반사 에이전트는 환경에 대한 내부 표현을 유지합니다. 현재 입력에만 반응하는 대신, 저장된 상태를 활용해 상황을 판단합니다. 예를 들어 운영 에이전트는 어떤 경고를 발생시킬지 결정하기 전에 파이프라인의 마지막으로 확인된 상태, 가장 최근의 스키마 변경, 영향을 받는 테이블에 연결된 소유자를 추적할 수 있습니다.
• 목표 기반 에이전트는 원하는 결과를 기준으로 작업을 평가합니다. 조건을 단순히 대조하는 데 그치지 않고, 시스템을 목표에 더 가깝게 이동시키는 단계를 선택합니다. 청구 분쟁을 해결하려는 고객 지원 에이전트라면 계정 이력을 수집하고, 정책 규칙을 비교하고, 답변 초안을 작성한 뒤 작업이 권한 범위를 넘어설 때만 에스컬레이션할 수 있습니다.
• 유틸리티 기반 에이전트는 서로 다른 결과를 비교해 가중치를 판단합니다. 작업을 선택하기 전에 속도, 비용, 신뢰도, 위험, 비즈니스 가치를 비교할 수 있습니다. 엔터프라이즈 환경에서는 가장 빠른 답이 반드시 가장 안전한 답은 아닐 때, 또는 더 비용이 큰 추론 경로가 고위험 의사결정에서만 정당화될 때 유틸리티가 중요해집니다.
• 학습 에이전트는 피드백을 통해 개선됩니다. 이 피드백은 사용자, 평가자, 모니터링 시스템 또는 이전 작업 결과에서 나올 수 있습니다. 프로덕션에서는 기본 모델을 지속적으로 재학습시키기보다 프롬프트, 메모리, 라우팅 로직, 정책 규칙, 평가 세트를 업데이트하는 방식으로 개선이 이루어지는 경우가 많습니다.

엔터프라이즈 워크플로우에서는 특히 두 가지 고급 에이전트 유형이 중요합니다.

• 계층형 에이전트는 작업을 여러 레벨로 나누고, 감독 에이전트가 전문 에이전트에 하위 작업을 위임합니다.
• 멀티 에이전트 시스템은 여러 에이전트를 조율해 순차적으로, 병렬로 또는 공통 오케스트레이터 아래에서 작업하도록 합니다.

실무에서는 많은 엔터프라이즈 배포가 자율성 수준에 따라 에이전트를 분류하기도 합니다. 완전 자율 에이전트는 사람의 개입을 제한적으로 받으며 작업을 수행하는 반면, 반자율 에이전트는 고위험 작업 전에 승인을 요청합니다. 도메인별 에이전트는 작업 범위를 더 좁힙니다. 예를 들어 데이터 에이전트, 코딩 에이전트, 보안 에이전트, 영업 운영 에이전트가 여기에 해당합니다.

AI 에이전트에는 파운데이션 모델 외에도 실행을 거버넌스하는 오케스트레이션 계층, 계획 모듈, 메모리 아키텍처, 도구 통합, 제어 영역이 필요합니다.

파운데이션 모델

파운데이션 모델은 유연한 해석, 추론, 생성을 제공합니다. 현재 많은 시스템이 LLM을 사용하지만, 에이전트가 반드시 언어 모델에만 한정될 필요는 없습니다. 모델은 유연한 추론을 제공하고, 이를 둘러싼 아키텍처는 에이전트가 무엇을 알 수 있는지, 어떤 도구를 사용할 수 있는지, 작업이 변경될 때 어떤 일이 일어나는지를 결정합니다.

모델 선택은 유연하게 유지되어야 합니다. 기업이 다양한 워크플로우 전반에 에이전트를 구축할 때 모든 사용 사례를 단일 파운데이션 모델에 고정하면 성능, 비용 제어, 적응성이 제한될 수 있습니다. “특정 공급업체 하나에 종속되면 몇 달 뒤 문제가 생길 수 있습니다.”라고 Allen은 말합니다. “어느 순간 다른 공급업체가 놀라운 혁신을 들고 등장할 수도 있는데, 그러면 그 기회를 놓치게 됩니다. 모델 라우팅의 선택권은 필수적인 기반이라고 생각합니다.”

오케스트레이션 계층

오케스트레이션 계층은 에이전트 루프를 관리합니다. 모델에 컨텍스트를 전달하고, 도구 호출을 라우팅하며, 중간 상태를 저장하고, 재시도를 처리하고, 워크플로우를 계속할지, 중단할지, 에스컬레이션할지, 다른 에이전트로 인계할지 결정합니다.

계획 모듈

계획 모듈은 목표를 더 작은 단계로 나눕니다. 예를 들어 “동북부 지역의 매출이 감소한 이유를 찾아줘”라는 요청이 들어오면, 에이전트는 관련 지표 정의를 식별하고, 세그먼트별 최근 매출을 쿼리하고, 이전 기간과 비교하고, 파이프라인 최신성을 점검하고, 소스 테이블 변경 여부를 확인하는 계획을 세울 수 있습니다. 더 단순한 에이전트에서는 계획이 한 단계씩 진행될 수 있습니다. 더 복잡한 에이전트는 처음부터 다단계 계획을 수립하고, 도구 결과가 돌아올 때마다 이를 수정합니다.

메모리 아키텍처

메모리는 에이전트에 연속성을 부여합니다. 단기 메모리는 사용자의 요청, 도구 출력, 제약 조건, 검색된 문서, 이전 대화 턴 등 즉시 수행 중인 작업 상태를 보관합니다. 장기 메모리는 사용자 선호도, 이전 의사결정, 조직별 정의, 해결된 문제와 같이 재사용 가능한 지식을 저장합니다. 메모리 아키텍처는 무엇을 저장할지, 어떻게 검색할지, 얼마나 오래 유지할지, 메모리의 어느 부분을 어떤 에이전트가 사용할 수 있는지를 결정합니다.

도구 통합

도구 통합은 에이전트를 실제 작업이 이루어지는 시스템과 연결합니다. 이러한 도구에는 데이터베이스, 검색 인덱스, 코드 리포지토리, 티켓팅 시스템, CRM 애플리케이션, 워크플로우 엔진, 문서 저장소, 내부 API가 포함될 수 있습니다. 함수 호출은 모델이 이러한 도구를 구조화된 방식으로 호출할 수 있게 해주며, MCP 같은 표준은 에이전트가 외부 기능을 탐색하고 사용하는 방식을 표준화하기 위해 부상하고 있습니다.

제어 영역

제어 영역은 데이터, 모델, 도구, 엔터프라이즈 워크플로우를 연결하는 거버넌스 적용 플랫폼 계층입니다. 동시에 권한을 적용하고, 작업을 라우팅하고, 활동을 로깅하며, 에이전트가 여러 시스템 전반에서 작동하는 방식을 관리합니다. 또한 비용과 지연 시간 한도를 설정하고 사람의 승인을 관리합니다. 에이전트가 Snowflake와 같은 플랫폼 내부의 거버넌스가 적용된 데이터에서 작동하더라도, 검색된 콘텐츠, 사용자 프롬프트, 도구 출력은 모델이 맹목적으로 따라야 하는 지시가 아니라 에이전트형 워크플로우의 입력으로 취급해야 합니다.

엔터프라이즈 AI 에이전트에서 이 계층은 선택 사항이 아닙니다. 모델 기반 워크플로우를 조직이 신뢰하고 관리할 수 있는 체계로 전환하는 핵심입니다.

평가 및 최적화 하니스

평가 및 최적화 하니스는 실제 업무에서 에이전트가 어떻게 수행되는지 테스트하고, 실패 지점을 추적하며, 일회성 수동 튜닝에 의존하지 않고 팀이 시스템을 개선하도록 지원합니다. 에이전트의 최종 답변만 판단하는 대신, 하니스는 계획, 검색된 컨텍스트, 도구 호출, 중간 출력, 비용, 지연 시간, 최종 결과까지 평가할 수 있습니다.

더 고도화된 구현에서는 하니스가 에이전트 지침, 도구, 시맨틱 모델, 프롬프트 또는 워크플로우 구성의 변경을 제안하고, 이를 배포하기 전에 회귀 및 평가 세트로 검증할 수도 있습니다. 이렇게 하면 에이전트 개선은 거버넌스가 적용된 루프가 됩니다. 평가하고, 진단하고, 수정하고, 테스트한 뒤, 기존에 정상 작동하던 동작을 깨뜨리지 않으면서 성능을 높이는 변경만 유지하는 방식입니다.

멀티 에이전트 시스템은 하나의 작업을 완료하기 위해 둘 이상의 에이전트를 사용합니다. 핵심 가치는 전문화에 있습니다. 한 에이전트는 컨텍스트를 검색하고, 다른 에이전트는 정책을 해석하며, 또 다른 에이전트는 코드를 작성하고, 다른 에이전트는 결과를 검증합니다. 오케스트레이터는 전체 워크플로우를 조율합니다.

이러한 전문화야말로 멀티 에이전트 시스템을 도입하는 주된 이유인 경우가 많습니다. 하나의 범용 에이전트에 모든 기능을 처리하게 하는 대신, 팀은 작업을 책임이 더 명확한 좁은 범위의 에이전트로 나눌 수 있습니다.

그 대가는 조정 오버헤드입니다. 모든 핸드오프에는 상태, 권한, 오류 처리, 그리고 각 에이전트가 수행한 작업에 대한 명확한 기록이 필요합니다. 실무에서 멀티 에이전트 설계의 본질은 에이전트를 더 많이 추가하는 데 있지 않습니다. 전문화가 추가 복잡성을 감수할 만큼 결과를 개선하는 지점을 판단하는 데 있습니다.

순차 오케스트레이션

순차 오케스트레이션은 파이프라인처럼 작동합니다. 한 에이전트가 단계를 완료하면 그 출력을 다음 에이전트에 전달합니다. 이는 멀티 에이전트 환경에서의 프롬프트 체이닝에 해당하며, 작업 순서를 예측할 수 있을 때 효과적입니다.

예를 들어 문서 처리 워크플로우는 고정된 시퀀스에 따라 엔터티를 추출하고, 문서를 분류하고, 규정 준수 규칙을 확인한 뒤, 요약 초안을 작성할 수 있습니다. 각 단계는 이전 단계의 출력에 의존하므로, 워크플로우를 중간 의사결정의 체인으로 점검할 수 있습니다.

계층형 오케스트레이션

계층형 오케스트레이션은 감독 에이전트를 사용합니다. 감독 에이전트는 목표를 받아 전문 에이전트에 하위 작업을 위임하고 최종 결과를 조합합니다.

LangGraph와 같은 프레임워크는 그래프 기반 상태 모델이 체크포인트, 재시도, 복구 지점과 잘 맞기 때문에 이러한 유형의 프로덕션 워크플로우를 지원합니다. CrewAI와 같은 역할 기반 프레임워크는 팀이 워크플로우를 견고하게 다듬기 전에 이름이 지정된 에이전트에 작업을 빠르게 할당하려는 프로토타입에서 자주 사용됩니다.

병렬 오케스트레이션

병렬 오케스트레이션은 동일한 문제를 여러 에이전트에 동시에 보내고, 이후 출력을 병합하거나 비교합니다. 이 패턴은 비용, 지연 시간, 조정 복잡성을 높이기 때문에 현재 프로덕션에서는 상대적으로 덜 사용됩니다.

다만 독립적인 답변이 신뢰도를 높이는 평가 중심 워크플로우에서는 여전히 유용할 수 있습니다. 예를 들어 최종 응답을 구성하기 전에 여러 에이전트가 동일한 제안 답변을 검토하고, 서로 다른 가정을 테스트하거나, 별도의 소스와 대조해 결과를 확인할 수 있습니다.

도구 및 에이전트 커뮤니케이션 표준

MCP와 새롭게 등장하는 에이전트 간 커뮤니케이션 프로토콜은 이 오케스트레이션 계층의 일부입니다. MCP는 에이전트와 AI 애플리케이션이 도구 및 데이터 소스에 연결되는 방식을 표준화합니다. 에이전트 간 커뮤니케이션 프로토콜은 에이전트들이 메시지, 상태, 작업 출력을 서로 교환하는 방식에 초점을 맞춥니다.

이러한 표준은 어떤 에이전트가 어떤 도구를, 누구의 권한으로, 어떤 작업을 위해 호출했으며 어떤 결과를 냈는지 조직이 거버넌스할 수 있는지, 가능하다면 어떻게 할 수 있는지에 대한 답을 찾도록 돕습니다.

자율성은 스펙트럼입니다. AI 에이전트는 워크플로우의 한 부분에서는 자율적으로 작동하고, 다른 부분에서는 엄격한 제약을 받을 수 있습니다. 예를 들어 문서를 검색하고, 메타데이터를 검사하고, 권장 사항 초안을 스스로 작성할 수 있지만, 시스템을 업데이트하거나 메시지를 보내거나 파이프라인을 변경하기 전에는 사람의 승인을 요구하도록 설계할 수 있습니다. 이 균형은 사용 사례에 따라 달라집니다.

워크플로우에 필요한 가드레일 수준은 실패의 결과, 즉 에이전트가 실수했을 때 어떤 일이 발생하고 이를 되돌리기 얼마나 어려운지와 실패가 발생할 가능성이 높은 지점에 따라 달라집니다. 포괄적인 승인 규칙은 위험을 줄일 수 있지만, 에이전트가 이미 잘 처리하는 저위험 단계까지 늦출 수 있습니다. 반대로 더 좁은 범위의 가드레일을 에이전트가 부실한 컨텍스트를 검색하거나 잘못된 도구를 선택하거나 신뢰도를 과장하기 쉬운 지점에 적용하면, 전체 워크플로우를 수동 검토로 전환하지 않고도 안정성을 높일 수 있습니다.

에이전트 거버넌스는 출력뿐 아니라 그 결과로 발생할 수 있는 영향까지 고려해야 합니다. AI 시스템이 데이터를 검색하고, 도구를 호출하고, 여러 워크플로우에서 작업을 수행할 수 있게 되면 실패는 더 이상 부정확한 응답에만 국한되지 않습니다. 에이전트가 승인되지 않은 컨텍스트를 사용하거나 민감 정보를 노출하거나, 비용이 크거나 되돌릴 수 없는 다운스트림 영향을 초래하는 조치를 취할 수 있습니다.

정확도

정확성은 가장 중요한 고려 사항입니다. 금융, 엔지니어링, 헬스케어, 보안 등 고위험 영역에서는 에이전트가 적절한 컨텍스트를 검색하고, 올바른 정의를 사용하며, 적절한 정책을 적용하고, 진행하기에는 신뢰도가 너무 낮은 시점을 판단할 수 있어야 합니다. 평가는 수행할 작업을 반영해야 합니다. 예를 들어, 일반적인 LLM 벤치마크만으로는 에이전트가 조직의 매출 인식 규칙을 정확히 적용하는지, 또는 적절한 보안 경고를 에스컬레이션하는지 확인할 수 없습니다.

거버넌스

거버넌스가 적용된 데이터 액세스도 높은 우선순위입니다. 에이전트는 정형 데이터, 문서, 오디오, 로그, 이미지, 티켓, 코드 전반에서 작업해야 하는 경우가 많습니다. 이러한 소스는 서로 다른 액세스 모델 뒤에 있으며, 에이전트의 실행 권한은 사용자의 권한을 넘어서는 안 됩니다. 거버넌스가 적용된 에이전트에는 어떤 데이터가 사용되었는지 보여주는 ID 전파, 정책 적용, 쿼리 제어, 감사 추적이 필요합니다.

다만 Allen은 조직이 시작하기 전에 모든 거버넌스 문제가 완전히 정리될 때까지 기다릴 필요는 없다고 말합니다. “정책을 수립하고, 방향을 잡고, 거버넌스를 적용해야 합니다. 하지만 더 빠르게 움직이는 것을 두려워하지 마세요. 거버넌스 측면을 이해하는 신뢰할 수 있는 파트너와 함께 추진하면 됩니다.”

신뢰와 보안

에이전트가 도구를 사용하기 시작하면 신뢰와 보안은 더 복잡해집니다. 프롬프트 인젝션, 과도한 권한, 안전하지 않은 도구 호출, 데이터 유출, 승인되지 않은 쓰기 작업은 모두 현실적인 리스크가 됩니다. 보안 프레임워크는 모델의 동작뿐 아니라 모델이 접근할 수 있는 시스템까지 고려해야 합니다.

비용과 지연 시간

비용과 지연 시간은 운영 단계에서 가장 먼저 마주하는 장애물이 되는 경우가 많습니다. 단일 프롬프트-응답 상호작용에는 모델 호출 한 번이면 충분할 수 있습니다. 반면 다단계 에이전틱 워크플로우에는 계획, 검색, 도구 호출, 리플렉션, 추가 검색 단계, 최종 응답이 포함될 수 있습니다. 각 단계는 비용과 시간을 추가합니다. 리플렉션, ReAct 루프, 멀티 에이전트 오케스트레이션은 작업이 이를 정당화할 만큼 복잡할 때 유용하지만, 비용과 정확성 사이에는 의도적인 트레이드오프가 존재합니다.

에이전트가 프로덕션에서 작동하기 전에 팀은 에이전트가 액세스할 수 있는 데이터, 사용할 수 있는 도구, 수행할 수 있는 작업, 필요한 승인, 그리고 실제로 어떤 일이 발생했는지 감사하는 데 필요한 증거를 정의해야 합니다. 목표는 단순히 모델을 더 많은 시스템에 연결하는 것이 아니라, 사용자 요청에서 에이전트 작업으로 이어지는 거버넌스 기반 실행 경로를 만드는 것입니다.

데이터 액세스부터 시작

에이전트가 프로덕션 데이터에 접근하기 전에 무엇을 읽고 쓸 수 있는지, 어떤 인터페이스를 사용해야 하는지 정의해야 합니다. 거버넌스가 적용된 아키텍처에서는 에이전트에 직접적이고 제한 없는 테이블 액세스를 허용해서는 안 됩니다. 에이전트는 ID를 전달하고 정책과 컨텍스트를 적용하는 승인된 쿼리 레이어, API, 시맨틱 모델 또는 검색 시스템을 통해 작동해야 합니다.

제어 영역 수준의 거버넌스 정의

제어 영역은 권한을 적용하고, 도구 호출을 라우팅하며, 작업을 로그로 남기고, 승인을 관리하며, 정의된 한도를 초과하는 워크플로우를 중단해야 합니다. 에이전트가 티켓을 업데이트하거나, 메시지를 보내거나, 파이프라인을 수정하거나, 민감 데이터에 대한 쿼리를 실행할 수 있다면 프로덕션 사용을 시작하기 전에 승인 및 감사 경로가 명확해야 합니다.

배포 전 평가

에이전트는 실제 수행할 작업을 반영하는 작업별 벤치마크를 기준으로 테스트해야 합니다. 데이터 에이전트라면 모호한 지표 정의, 오래된 테이블, 상충하는 문서, 액세스가 제한된 필드, 알려진 엣지 케이스가 포함된 질문을 평가에 포함할 수 있습니다. 정확성 임계값은 워크플로우의 리스크 수준에 맞춰야 합니다. 내부 지식 어시스턴트는 인프라를 변경하는 엔지니어링 에이전트나 보고에 영향을 주는 재무 에이전트보다 더 큰 불확실성을 허용할 수 있습니다.

배포 후에도 계속되는 모니터링

팀은 검색된 컨텍스트, 도구 호출, 중간 산출물, 승인, 지연 시간, 비용, 최종 작업 등 에이전트 워크플로우의 각 단계를 보여주는 추적 정보를 확보해야 합니다. 드리프트 감지, 작업 감사 추적, 휴먼 인 더 루프 에스컬레이션 경로는 에이전트의 동작이 달라지는 시점, 입력 품질이 저하되는 시점, 신뢰도가 낮은 결정에 검토가 필요한 시점을 팀이 파악하는 데 도움이 됩니다.

프로덕션 에이전트 시스템에서는 어떤 질문, 도구, 검색 경로 또는 워크플로우 단계가 실패를 유발하는지 보여주고, 제안된 수정 사항을 대상 사례와 회귀 세트 모두에 대해 테스트할 수 있는 하네스도 필요합니다. Snowflake의 CoCoEvolve가 대표적인 예입니다. 이 시스템은 AI 아티팩트를 감싸는 방식으로 작동하며, 변경 사항을 제안하고, 효과 여부를 평가한 뒤, 성공적인 변경 사항은 유지하고 실패한 변경 사항은 폐기합니다.

AI 에이전트의 미래는 개별 모델의 성능 향상보다는 컨텍스트를 제공하고, 작업을 통제하며, 도구 전반에서 업무를 조율하는 시스템에 의해 더 크게 좌우될 가능성이 큽니다. 에이전트가 채팅 창을 넘어 운영 워크플로우로 이동하면서, 기업은 적시에 적절한 데이터를 노출하고 사용자 권한을 유지하며 각 단계에서 발생한 일을 기록하는 아키텍처가 필요해질 것입니다.

엔터프라이즈 팀이 필요로 하는 아키텍처는 대개 데이터를 별도의 AI 환경으로 복사하는 방식이 아니라, 거버넌스가 적용된 데이터에 AI를 더 가까이 배치하는 방식에 달려 있습니다. Allen은 “거버넌스 요건 때문에 데이터를 밖으로 이동시키는 것이 아니라, AI를 데이터가 있는 곳으로 가져갈 수 있어야 합니다”라고 말합니다. “데이터는 현재 위치에 그대로 두고, 그 컨텍스트를 갖춘 에이전트를 구축하는 데 AI를 활용해야 합니다.”

이러한 요구사항 때문에 MCP와 같은 프로토콜의 중요성도 커지고 있습니다. 에이전트는 모든 연결을 사용자 지정 통합에 의존하지 않고도 도구, 데이터 소스, 애플리케이션을 일관된 방식으로 탐색하고 사용할 수 있어야 합니다. Anthropic은 MCP를 소개했습니다. 2024년 11월 공개된 MCP는 AI 애플리케이션을 외부 시스템에 연결하기 위한 개방형 표준이었으며, 이후 2025년 12월 Linux Foundation 산하 Agentic AI Foundation에 기부되었습니다. 이후 MCP는 로컬 도구를 넘어 확장되었으며 점점 더 다양한 조직의 프로덕션 환경에서 사용되고 있습니다.

MCP의 성장은 더욱 연결된 에이전틱 생태계로의 진전을 보여주지만, 연결만으로 엔터프라이즈 과제가 해결되는 것은 아닙니다. 다음 스테이지는 거버넌스가 적용된 상호운용성에 달려 있습니다. 즉, 에이전트가 도구를 탐색하고, 올바른 ID로 사용하며, 정책을 준수하고, 컨텍스트를 유지하면서 감사 추적을 잃지 않고 시스템 전반에 작업을 넘길 수 있어야 합니다.