AI 에이전트 시스템 설계 입문: 모델 라우팅·툴·메모리·오케스트레이션·평가

핵심 메시지

• 에이전트형 AI 시스템은 챗 인터페이스에 LLM을 감싼 것이 아니라, 목표를 추론하고 툴을 호출하며 상태를 유지해 여러 단계에 걸쳐 실제 행동을 실행하는 프로덕션 소프트웨어다.
• 모든 단계에 강력한 모델을 쓰지 말고, 단순 작업엔 값싼 모델, 모호하고 깊은 추론이 필요한 단계에만 강한 모델을 쓰는 '모델 라우팅'이 핵심이다.
• 툴은 이름·설명·입출력 스키마·권한·타임아웃·에러 형식을 갖춘 API처럼 설계하고, 읽기 툴과 쓰기 툴을 분리하며 위험한 쓰기에는 검증과 사람 승인을 둔다.
• 상태(현재 실행 맥락)와 메모리(대화·선호·지식 등)를 구분하고, 모든 것을 벡터DB나 컨텍스트에 밀어넣지 말고 접근 패턴에 맞는 저장소를 골라 최소 컨텍스트만 전달한다.
• 프로덕션 등급은 궤적(trace) 단위 평가, 고위험 행동의 승인 게이트, 그리고 신뢰성·비용/지연·컨텍스트·관측성·보안·프라이버시 설계가 함께 받쳐야 완성된다.

쉽게 이해하기

많은 사람이 AI 에이전트를 '챗 인터페이스에 LLM을 씌운 것' 정도로 이해하지만, 실제로 에이전트를 만들 때 가장 중요한 것은 그 뒤의 시스템 설계다. 에이전트형 AI 시스템은 모델이 목표를 추론하고, 툴을 사용하고, 컨텍스트를 검색하고, 상태를 유지하며, 여러 단계에 걸쳐 결정을 내리고 API를 통해 실제 행동을 촉발하는 프로덕션 소프트웨어 시스템이다. 이 영상은 데모를 넘어 실사용자가 신뢰할 수 있는 시스템으로 가기 위해 무엇을 고민해야 하는지를 '빌더의 관점'에서 정리한다.

시스템에는 크게 단일 에이전트와 멀티 에이전트 패턴이 있다. 단일 에이전트는 하나의 주 에이전트가 워크플로를 소유하며 제어 루프가 중앙집중적이다(예: 고객지원 에이전트가 요청 분류→계정 컨텍스트 조회→결제 API 호출→확인 요청→최종 응답). 멀티 에이전트는 계획·지식 검색·코드 작성·검토·실행처럼 역할을 나눠 각 에이전트에 입력·출력 계약과 라우팅 로직을 정의한다. 전문화·병렬 작업·검토 루프에 유용하지만, 조율 부담과 실패 지점, 추적할 상태, 비용·지연이 늘어난다. 어려운 부분은 모델이 답을 내는 것이 아니라, 신뢰할 수 있고 비용을 의식하며 빠르고 관측 가능하고 안전하게 실제 툴에 연결되는 시스템을 설계하는 일이다.

핵심 구성요소는 먼저 모델 계층이다. 모든 단계에 강한 모델을 쓰면 비싸고 느려지므로, 의도 분류·라우팅·추출·스키마 채우기·간단 요약 같은 저복잡도 단계엔 값싸고 빠른 모델을, 모호한 제약이 얽힌 단계엔 강한 추론 모델을 쓰는 모델 라우팅을 설계한다. 또한 다른 시스템으로 넘어가는 출력은 자유형 문장이 아니라 JSON 스키마·pydantic·함수 호출 같은 예측 가능한 구조로 만든다. 모델 계층은 '이 단계에 어떤 모델을 쓰는가, 어떤 출력 계약을 반환하는가, 실패하면 어떻게 되는가'라는 세 질문에 답해야 한다.

다음은 툴과 메모리·상태다. 툴은 모델과 외부 세계의 인터페이스로, 자연어 문자열을 그대로 백엔드에 흘리지 않도록 엄격한 계약(이름·설명·입출력 스키마·권한 경계·타임아웃·재시도·에러 형식)을 갖춰야 하고, 읽기 툴→저위험 쓰기→고위험 쓰기 순으로 위험도를 나눠 확장한다. 표준화된 방식으로 툴·리소스를 노출하는 MCP(Model Context Protocol)도 이 맥락에서 유용하다. 메모리 설계는 사실상 데이터 아키텍처다. '현재 어떤 단계인지, 어떤 정보를 모았는지, 어떤 툴을 불렀는지' 같은 실행 상태와, 대화 이력·사용자 선호·검색된 지식 같은 넓은 의미의 메모리를 구분하고, 모든 것을 벡터DB에 넣는 대신 접근 패턴에 맞는 저장소(Redis·Postgres·RAG용 벡터 저장소·S3 등)를 고른다. 목표는 컨텍스트 창을 채우는 것이 아니라 현재 단계에 필요한 최소 컨텍스트만 꺼내 쓰는 것이다.

이들을 조율하는 것이 오케스트레이션이다. 애플리케이션 코드나 LangGraph 같은 그래프 프레임워크, Temporal·LlamaIndex 워크플로 등으로 제어 흐름을 명시적으로 정의한다. 단계가 대체로 정해진 단순 사례는 완전 자율 루프보다 결정론적 파이프라인이 낫고, 분기·재시도·승인 게이트·폴백이 필요한 복잡한 시스템엔 그래프 기반 오케스트레이션이 유용하다. 자율성을 '구조 없음'과 혼동하지 말아야 한다는 것이 핵심이다.

주요 인사이트

• 평가는 최종 답만 보지 말고 궤적(trace) 단위로 해야 한다. 에이전트는 의미상 틀린 유효 JSON을 내거나, 맞는 툴을 틀린 인자로 부르거나, 엉뚱한 컨텍스트를 검색하거나, 확인 절차를 건너뛸 수 있다. 의도 분류·검색 품질·툴 선택·툴 인자·정책 준수·확인 행동·최종 답 품질을 단계별로 평가하고, 정상·모호·범위 외·툴 실패·악의적 입력 등 현실 시나리오 테스트셋을 회귀 테스트로 유지한다. LLM-as-judge는 유용하나 완벽하지 않으므로 결정론적 검사와 사람 검토를 함께 쓰고, 결국 지표(의도 정확도·툴 성공률·검색 적중률·과제 완료율·성공당 비용 등)로 이어져야 한다.
• 고위험 행동에는 승인 게이트가 필요하다. 이메일 전송, 데이터 삭제, 환불, 예약 취소, 결제 변경, 코드 실행 같은 행동은 모델이 의도를 추론했다는 이유만으로 실행돼선 안 된다. '모델이 제안→코드가 검증→사용자가 승인→툴이 실행'이 안전한 패턴이며, 소유권·권한·정책 허용 여부·필수 필드·명시적 확인은 가능한 한 결정론적으로 검사한다. 멀티 에이전트에서도 실행 계층이 계획 계층을 맹신하지 말아야 하고, 비즈니스 규칙의 진실 원천은 에이전트가 아니라 애플리케이션 코드다.
• 신뢰성은 모델을 완벽하게 만드는 게 아니라, 모델의 불완전함이 곧바로 제품 실패가 되지 않도록 시스템을 설계하는 일이다. 큰 프롬프트를 작은 단계로 분해하고, 구조화 출력과 스키마 검증·재시도·폴백을 두며, 모든 모델 호출을 타임아웃·잘못된 출력·요청 제한·제공자 오류를 처리해야 하는 '불안정한 상위 의존성'처럼 감싼다. 날짜 검증, 사용자 ID 권한 확인, 툴 인자 검증처럼 결정론적 검증을 모델 추론에서 분리한다.
• 비용과 지연은 함께 설계해야 한다. 한 번의 상호작용에도 의도 분류·질의 재작성·검색·계획·툴 선택·인자 생성·결과 해석·최종 응답·평가처럼 여러 모델 호출이 들어가기 때문이다. 모델 라우팅으로 단순 단계는 작은 모델에 맡기고, 출력 토큰을 공격적으로 제한하며, 검색 결과·정책 조회·툴 메타데이터·안정적 컨텍스트를 캐싱하고, 평가·요약 같은 비차단 작업은 배치·비동기로 돌린다. 사용자 대면 작업엔 스트리밍으로 진행 상태를 보여 주고, 범위 밖 요청은 값싼 필터·규칙·의도 게이트로 값비싼 추론 전에 걸러낸다.
• 컨텍스트·RAG 설계와 보안이 장난감 에이전트와 실전 에이전트를 가른다. 모든 것을 프롬프트에 넣는 대신 현재 단계에 맞는 컨텍스트만 전달하고, RAG는 청킹·메타데이터 필터·하이브리드 검색·리랭킹·신선도·출처 표기로 품질을 확보한다. 특히 신뢰된 지시와 신뢰되지 않은 콘텐츠를 분리해야 한다. 검색 문서가 시스템 지시를 덮어쓰게 두지 말고, 툴 출력은 지시가 아닌 데이터로 다루며, 모델이 만든 텍스트에서 SQL·셸을 직접 실행하지 않는다. 사용자 메시지·검색 문서·툴 출력은 프롬프트 인젝션의 통로가 될 수 있으므로 공격자 입력으로 간주하고, 툴엔 최소 권한을 주며, 모델에는 과업에 필요한 최소 데이터만 보내고 PII는 마스킹·보존정책으로 관리한다.

자주 묻는 질문

관련 AI 소식