AI 에이전트 아키텍처
Source: Dev.to

“실제 현업 AI 에이전트 아키텍처는 어떻게 생겼을까?”
과대광고는 접어두세요. 이해하기 쉬우면서도 확장성 있게 견고한 최소·모듈형 아키텍처에 대해 이야기합니다.
4계층 청사진
효과적인 AI 에이전트는 네 개의 구분된 레이어 위에 구축됩니다:
1. 인터페이스 레이어: “세상이 에이전트와 대화하는 방식”
이 레이어의 역할은 순수 번역입니다: 모든 입력을 정규화하고 모든 출력을 렌더링합니다.
입력 핸들러
- 채팅 → 원시 텍스트
- 음성 → 음성‑텍스트 변환 (예: Whisper)
- 미래 대비: UI 액션, 파일 업로드, 센서 데이터
출력 렌더러
- 텍스트 응답
- 텍스트‑음성 변환 (음성 봇용)
- 구조화된 데이터 (API용)
원칙: 이 레이어는 무상태로 유지하세요. 컨텍스트와 세션 관리는 오케스트레이션 레이어가 담당합니다.
2. 오케스트레이션 레이어: “에이전트의 중앙 신경계”
명령 센터 역할을 합니다. 대화 흐름을 관리하고, 행동을 결정하며, 상태를 유지합니다.
- 상태 관리: 대화 히스토리, 사용자 의도, 현재 목표를 추적합니다.
- 툴 라우팅: 언제·어떻게 행동할지 결정합니다—직접 답변, 지식 검색, API 호출 등.
- 워크플로우 제어: 조건 로직, 다단계 프로세스, 오류 복구를 처리합니다.
3. 추론·메모리 레이어: “파일링 시스템을 갖춘 두뇌”
LLM을 기반으로 하지만 절대 독립적으로 두지 않습니다. 이 레이어는 근거 기반 지능을 다룹니다.
핵심 모델
선택한 LLM (GPT‑4와 같이 호스팅하거나 Llama 3와 같이 자체 호스팅).
검색‑증강 생성 (RAG)
- 지식 베이스: 임베딩으로 저장된 문서들을 벡터 DB에 보관 (클라우드용 Pinecone, 로컬용 Chroma).
- 프로세스: 쿼리(사용자 입력 + 컨텍스트)로 관련 청크를 가져와 LLM 프롬프트에 삽입, 근거 있는 응답을 생성합니다.
메모리
- 단기: 대화 히스토리 (Redis 혹은 메모리 캐시).
- 장기: 사용자 프로필, 과거 상호작용, 선호도 (전통적인 SQL/NoSQL DB 혹은 지식 그래프에 저장).
핵심 원칙: LLM이 “추측”하도록 두지 마세요. 항상 검색된 데이터나 검증된 툴 출력에 근거하도록 합니다.
4. 액션·통합 레이어: “실제 작업을 수행하게 하기”
에이전트를 단순 대화 파트너에서 자동화 엔진으로 전환합니다.
툴 라이브러리
타입이 명확하고 멱등성을 보장하며 오류 처리와 인증을 내장한 함수들의 선별된 집합.
예시
- 주문 상태를 확인하기 위해 REST API 호출.
- Salesforce 또는 HubSpot에 레코드 업데이트.
- 제품 데이터베이스에 쿼리 실행.
- CI/CD 파이프라인 트리거 혹은 Slack 알림 전송.
결론
가장 좋은 AI 에이전트는 가장 화려한 모델이 아니라 가장 견고한 아키텍처를 가진 것입니다—실제 문제를 해결하면서 프로덕션에서 깨지지 않는 것이 핵심입니다.
하나의 레이어부터 시작하세요. 그 레이어를 완벽히 다듬은 뒤에 확장해 나가면 됩니다.