- 에이전트 AI
AI 시스템이 프롬프트에 응답하는 수준을 넘어 실제 환경에서 조치를 취하기 시작하면서, 아키텍처는 예측 가능하게 작동하는지 여부를 결정하는 중요한 요소가 돼요.
에이전트 아키텍처는 에이전트 AI 시스템이 프로덕션 환경에서 효율적이고 안전하게 계획, 실행, 관찰 및 협업할 수 있도록 돕는 시스템 설계 방식이에요.
GenAI에서 에이전트 AI로의 변화는 응답 생성에서 워크플로 실행으로의 전환을 의미하죠. 에이전트가 데이터베이스를 `Query`하고, API를 호출하고, 레코드를 업데이트하고, 인프라 변경을 트리거할 수 있게 되면, 프롬프트 자체보다 주변 시스템 설계가 훨씬 더 중요해진답니다.
아키텍처는 단순해 보일 수 있지만, 단일 에이전트 시스템이 아닌 에이전트들이 서로 의존하는 다중 에이전트 시스템에서는 복잡해져요. 비용이 많이 드는 실수를 피하면서 목표를 향해 효율적으로 작동하는 프로덕션급 에이전트 AI 시스템을 구축하려면 올바른 아키텍처를 선택하는 것이 정말 중요하답니다.
이 가이드에서 다룰 내용은 다음과 같아요:
- Agentic AI 아키텍처 구성 요소
-
- 단일 에이전트 시스템
-
- 다중 에이전트 시스템
-
- 내 사용 사례에 어떤 아키텍처를 선택해야 하나요?
- Knowledge Graph가 Agentic 아키텍처를 강화하는 방법
- 생산 준비가 완료된 Agentic 시스템 구축
- Agentic 아키텍처: FAQ
Agentic AI 아키텍처 구성 요소
Agentic AI 시스템의 아키텍처에는 다음과 같은 기본 구성 요소가 있어요. 작업을 완료하기 위해 모델, 도구 및 메모리에 액세스할 수 있는 에이전트; 여러 에이전트를 조정하기 위한 오케스트레이션, 에이전트의 행동을 제한하고 안전하게 유지하는 가드레일.
- 은 추론 엔진이에요. 언어 모델은 사용 가능한 컨텍스트를 사용하여 목표와 이유를 해석하고 이를 달성하기 위한 계획을 만들죠. 다양한 에이전트나 작업에 대해 다양한 모델을 사용할 수 있어요.
- 는 에이전트를 외부 시스템에 연결하여 데이터를 검색하고 조치(데이터베이스, 내부 서비스, SaaS 앱, 자동화, 코드 실행 및 검색)를 수행할 수 있게 해줘요. 모델 컨텍스트 프로토콜(MCP)은 에이전트를 외부 도구 및 데이터 소스에 연결하는 표준화된 방법이에요.
- 는 단계와 세션 전반에 걸쳐 상담원의 일관성을 유지해줘요. 단기 기억은 현재 세션의 중간 결과를 저장하고, 장기 기억은 지속적인 사실, 선호도, 사전 결정을 저장하죠. 메모리에는 다음과 같은 안정적인 검색 파이프라인이 필요해요. 그래프RAG를 통해 에이전트는 추측하는 대신 올바른 단계에서 올바른 컨텍스트를 가져올 수 있어요.
- 는 모델을 사용하는 프로그램이에요. 추론, 도구 행동하고 기억하는 것 반영하다. 목표나 작업이 완료될 때까지 루프에서 실행되죠. 에이전트 시스템에는 최소한 하나의 에이전트가 필요하지만, 공유 목표를 위해 함께 일하는 서로 다른 전문 분야를 가진 여러 에이전트가 있는 경우가 더 많아요.
- 은 여러 에이전트의 작업을 조정하여 작업 라우팅, 공유 상태 및 메모리를 통한 핸드오프 관리, 도구 호출 시 처리를 통해 공유 목표를 향해 효율적으로 작업할 수 있게 해줘요.
- 은 도구 액세스, 검증, 데이터 액세스, 사람의 감독 및 추적성과 같은 메커니즘을 통해 시스템을 안전하고 감사 가능하게 유지해줘요.
Agentic AI 시스템의 아키텍처 패턴
루프에서 실행되는 단일 에이전트를 사용하여 간단한 에이전트 시스템을 구축할 수 있어요. 요구 사항이 증가하고 전문화, 동시성 또는 더 강력한 검증이 필요해짐에 따라 다중 에이전트 패턴이 중요해지죠. 아키텍처의 복잡성은 사용 사례에 따라 달라요. 프로덕션의 Agentic AI 시스템은 이러한 아키텍처 패턴의 조합을 사용하여 원하는 결과를 효율적으로 얻는 경우가 많아요.
단일 에이전트 시스템
단일 에이전트 아키텍처는 메모리와 도구가 포함된 모델인 단일 에이전트로 구성된 간단한 에이전트 시스템이에요. 계획을 세우고, 조치를 취하고, 결과를 반영하고, 작업이 완료될 때까지 반복되죠. 이는 다음과 같은 이유로 간단한 사용 사례의 올바른 시작점이 되는 경우가 많아요.
- 도구 입력 및 출력 검증(Schema 및 오류 처리)
- 각 단계에서 품질 측정
- 복잡성을 확장하기 전에 가드레일 추가
예를 들어 간단한 고객 지원 에이전트는 승인된 지식 소스와 실시간 주문 상태를 사용하여 제품 및 주문에 대한 질문에 답변해요.
다중 에이전트 시스템
다중 에이전트 시스템은 공유 목표를 위해 여러 에이전트를 조정해요. 속도와 전문화를 향상시킬 수 있지만 조정 오버헤드를 추가하고 평가 및 관찰 가능성을 더욱 어렵게 만들죠.
복잡한 다중 에이전트 시스템에는 일반적으로 다음이 포함돼요.
- 특정 작업을 완료하는 전문 에이전트
- 작업을 계획하고 위임하는 감독 에이전트
- 에이전트와 상태 및 메모리를 공유하는 오케스트레이터
다음은 에이전트 시스템에 사용되는 가장 일반적인 아키텍처 패턴 중 일부예요.
병렬 (Parallel)
병렬 에이전트는 독립적인 하위 작업을 동시에 수행해요. 작업이 다르고 서로의 출력에 의존하지 않는 경우 이 아키텍처를 사용하면 좋아요. 예를 들어 잠재적인 신제품에 대한 시장을 조사하는 경우, 한 에이전트는 시장 수요를 분석하고 다른 에이전트는 경쟁 환경을 조사하고 또 다른 에이전트는 규정을 조사할 수 있겠죠.
경쟁 (Competitive)
여러 에이전트가 동시에 작업하지만 동일한 문제에 대해 각자 고유한 솔루션을 제안해요. 마지막에 평가자가 출력의 점수를 매기고 가장 적합한 출력을 선택하거나 이를 최종 출력으로 결합하죠. 견고함과 사고의 다양성이 필요할 때 사용하면 좋아요. 이는 에이전트가 다양한 버전으로 작업하고 평가자가 기준에 가장 적합한 버전을 선택하는 마케팅 카피 생성과 같은 사용 사례에 적합하답니다.
순차 (Sequential)
에이전트는 파이프라인에서 작동해요. 각 단계가 이전 단계에 따라 달라질 때 사용하면 좋죠. 실제 세계에서는 다음과 같이 보일 수 있어요. 검색 에이전트는 API 호출을 통해 실시간 데이터를 검색하고, 분석 에이전트는 데이터를 정리 및 분석하며, 인터프리터 에이전트는 이 데이터를 해석하고 분석에 대한 설명을 자연어로 생성하는 거죠.
라우터
라우터 에이전트는 작업을 적절한 전문가에게 전달하는 역할을 해요. 다양한 전문 분야에 대한 에이전트가 있다면 이 기능을 활용해 보세요. 예를 들어, 고객 지원 담당자는 요청의 성격에 따라 고객 요청을 기술 지원, 청구 또는 환불 담당자에게 전달할 수 있겠죠.
회로망
수평적 아키텍처라고도 불리는 네트워크 아키텍처는 전문 에이전트들을 연결해서 서로 정보를 공유하거나 작업을 전달할 수 있도록 해줘요. 다양한 전문 에이전트가 함께 협업해야 하는 복잡한 사용 사례에 유용하죠. 마치 여러 전문가들이 서로 직접 대화를 나누는 전쟁 상황실과 같다고 할까요? 그들은 최선의 대응책을 찾을 때까지 끊임없이 서로의 의견에 도전하고 발전시켜 나간답니다.
- 예: 여러 서비스에서 사고를 분류하는 에이전트들이 조정된 해결을 위해 작업하면서 소유권, 종속성, 최근 배포 및 실시간 결과를 공유하는 경우
계층적
계층적 아키텍처는 직원이 감독자 아래에서 일하는 조직 구조를 반영한다고 볼 수 있어요. 에이전트에는 감독 에이전트가 목표를 세분화하고 전문 에이전트에게 작업을 위임하는 수준이 존재하죠. 전문 에이전트는 출력을 생성해서 감독자에게 반환하고, 감독자는 이를 집계해서 상위 감독자(있는 경우)에게 전달합니다. 다양한 부서나 도메인이 포함된 복잡한 사용 사례에서 강력한 제어, 명확한 위임 및 감사 가능성이 필요한 경우에 사용하면 좋답니다.
이런 방식은 여러 부서와 전문가들이 협업해야 하는 복잡한 엔터프라이즈 시스템에서 자주 사용돼요. 예를 들어, ESG 보고서 작성이 목표라면, 중앙 리더는 HR, 재무, 법무 등 각 부서에 특정 업무를 전문가에게 위임해서 작업을 조율하죠. 이때 전문가들은 서로 직접적으로 상호 작용하지 않고, 감독관이 모든 정보를 모아서 최종 보고서를 작성하는 방식이에요.
내 사용 사례에 어떤 아키텍처를 선택해야 합니까?
처음에는 간단하게 시작하고, 해결해야 할 명확한 실패 모드가 있을 때만 구조를 추가하는 게 좋아요. 지연 시간, 전문성, 검증 등을 고려해보고, 통제(Governance) 또는 조정 복잡성도 생각해봐야겠죠.
| 사용 사례의 성격 | 힘 | |
| 하나의 명확한 작업 또는 제한된 작업 흐름 | 단일 에이전트 | 복잡성 및 운영 오버헤드 최소화 |
| 하위 작업은 독립적입니다. | 평행한 | 낮은 대기 시간 및 출력 시간 |
| 다양한 관점이나 검증이 필요함 | 경쟁적 | 출력 비교 및 평가 |
| 단계는 순서대로 이루어져야 합니다. | 잇달아 일어나는 | 종속성은 순서를 따르므로 에이전트가 다른 에이전트의 출력으로 작업할 수 있습니다. |
| 다양한 도구/정책을 사용하는 다양한 요청 유형 | 라우터 | 실패 가능성 및 완료 시간 감소 |
| 에이전트 간의 복잡한 협업 | 회로망 | 동일한 수준의 에이전트 간 동적 협업 |
| 도메인/팀 간의 복잡한 조정 | 계층적 | 부서 간 조정을 통해 실제 조직과 같은 구조 |
실용적인 팁:
- 오케스트레이션을 관찰 가능하게 만드세요. 복잡한 에이전트 아키텍처의 가장 큰 위험은 관찰 가능성을 잃는 거예요. 각 결정, 도구 호출, 중간 결과를 기록해서 실패를 디버깅하고 품질을 평가하며 각 단계의 동작을 감사할 수 있도록 해야 해요.
- 에이전트를 확장하기 전에 도구를 제한하세요. 대부분의 생산 사고는 도구 오용, 불분명한 계약 또는 지나치게 광범위한 권한 때문에 발생해요. 오용을 방지하려면 에이전트가 올바른 도구와 데이터 액세스 권한만 갖추고 있는지 확인하는 게 중요해요.
Knowledge Graph가 에이전트 아키텍처를 강화하는 방법
Knowledge Graph는 정보를 엔터티와 관계로 구성해요. 데이터를 분산된 텍스트로 저장하는 대신, 데이터를 연결해서 누가 무엇을 소유하고 있는지, 무엇이 무엇에 의존하는지, 모든 것이 어떻게 조화를 이루는지 보여주는 거죠. 이렇게 하면 에이전트가 단순히 벡터 공간에서 유사한 단어를 검색하는 대신 연결을 따라 관련 엔터티를 찾을 수 있으므로 답변을 더 쉽게 찾을 수 있어요.
에이전트 AI 시스템의 경우, Knowledge Graph는 장기 기억에 대한 구조화된 컨텍스트를 제공해요. AI 에이전트는 GraphRAG 서비스를 통해 Knowledge Graph에서 데이터를 검색하고, 사용자 및 작업이 어떻게 연결되어 있는지 확인하고, 의사 결정이 어떻게 이루어졌는지 추적해서 컨텍스트를 빠르게 이해할 수 있어요. 이는 더 나은 추론, 더 적은 사각지대, 더 신뢰할 수 있는 결과를 의미하죠.
사고 대응 시스템을 예로 들어볼게요. Agentic Workflow 로그와 배포 데이터를 가져올 수도 있지만, 여전히 실질적인 질문에 답해야 하죠. 뭐가 고장 났을까요? 누가 책임을 지고 있나요? 이제 뭘 안전하게 할 수 있을까요? Knowledge Graph를 사용하면 시스템 전반의 관계를 추적해서 빠르고 정확하게 답변을 얻을 수 있어요.
다중 에이전트 시스템처럼 고급 설정에서는 에이전트들이 서로 밟거나 접근해서는 안 되는 정보에 접근하지 않고도, 연결된 사실과 현재 상태에 대한 공유된 논리적 뷰를 통해 조율할 수 있어요.
생산 준비가 완료된 에이전트 시스템 구축
아키텍처는 에이전트 AI 시스템을 신뢰할 수 있게 만들어줘요. 프로덕션에 바로 사용할 수 있는 에이전트 시스템을 구축하려면, 작업을 수행하고 성능을 평가하는 단일 전문 에이전트로 시작하세요. 그런 다음 사용 사례에 따라 전문가를 다중 에이전트 패턴에 통합하는 거죠. 에이전트에 구조화된 메모리, 에이전트 간 공유 상태, 프로덕션에서 지속될 수 있는 추적 가능한 검색이 필요한 경우 Knowledge Graph를 사용하세요. 모든 것을 기록하고, 각 에이전트에 제한된 도구와 권한을 제공하고, 적절한 가드레일을 구축하는 것도 중요해요.
Knowledge Graph는 프로덕션에 바로 사용할 수 있는 에이전트 AI 시스템을 위해 연결된 데이터, 역할 기반 액세스 제어 및 GraphRAG 등 안정적인 컨텍스트와 메모리 계층을 제공해요.
GraphRAG를 사용해서 에이전트 AI 시스템에서 검색 품질, 추적성 및 접지를 개선하는 방법을 알아보세요.
에이전트 아키텍처: FAQ
에이전트 아키텍처는 AI 에이전트가 생산 환경에서 안전하게 계획하고, 행동하고, 도구에 액세스하고, 협업하고, 운영할 수 있도록 지원하는 시스템 설계에요.
실제로 이는 LLM 주변의 실행 루프처럼 보이죠. 시스템은 다음 단계를 결정하고, 올바른 도구를 호출하고, 결과를 확인하고, 메모리와 상태를 업데이트하고, 필요할 때 중지하거나 에스컬레이션해요. 또한 범위가 지정된 도구 액세스, 검증 및 감사 가능성과 같이 프로덕션에서 이를 안전하게 만드는 경계도 포함된답니다.
이는 프롬프트에 응답할 수 있는 모델과 다단계 작업을 완료할 수 있는 시스템 간의 격차를 해소해줘요. 이는 여러 에이전트가 작업을 조정하고, 컨텍스트를 공유하고, 서로의 결과에 의존해야 하는 다중 에이전트 시스템에서 특히 중요하죠.
오케스트레이션을 통해서요. 다중 에이전트 시스템에서 오케스트레이션은 작업 라우팅, 공유 상태 및 메모리를 통한 핸드오프 관리, 도구 호출 시기 제어를 통해 공유 목표를 향해 에이전트를 조정해요. 에이전트는 공유 상태를 반복적으로 계획하고, 실행하고, 반영하고, 업데이트하고, 목표가 달성될 때까지 계속한답니다.
간단하게 시작한 다음, 명확한 실패 모드가 있으면 구조를 추가하세요.
• 사용좁은 작업을 위해
• 사용하위 작업이 독립적이고 대기 시간이 중요한 경우
• 사용평가와 엄격한 결과가 필요한 경우
• 사용단계에 강한 종속성이 있는 경우
• 추가요청에 다른 도구/정책이 필요한 경우
• 사용상담원이 동일한 수준에서 협업해야 하는 경우
• 사용상담원이 다기능 팀과 함께 조직 환경에서 작업하는 경우