AI Agent 서비스 설계 패턴 - 도구 호출, 상태관리, 안전장치까지

데모용 Agent와 서비스용 Agent는 다르다

Agent 데모는 한 번 잘 동작하면 끝나지만, 서비스는 안정성, 비용, 추적 가능성까지 함께 설계해야 합니다.

서비스화 단계에서 꼭 부딪히는 문제:

너무 많은 도구 호출
동일 질문에도 결과 편차 발생
세션 상태가 꼬여 잘못된 문맥 사용
외부 API 장애 시 전체 응답 실패
비용 예측 불가

그래서 Agent는 프롬프트보다 시스템 구조가 더 중요합니다.

기본 구조는 이렇게 본다

실무에서는 아래처럼 역할을 분리하면 안정성이 좋아집니다.

User Request
 -> Router
 -> Planner
 -> Tool Executor
 -> Memory / State Store
 -> LLM Response Composer
 -> Output Guardrail

모든 작업을 한 번의 모델 호출로 해결하려 하면 디버깅이 매우 어려워집니다.

Tool Calling은 명확할수록 좋다

Agent에 연결하는 도구는 많을수록 좋은 게 아닙니다.

좋은 도구 정의 기준:

이름이 명확함
입력 스키마가 구체적임
반환 형식이 일정함
실패 케이스가 정의되어 있음

예:

{
  "name": "search_knowledge_base",
  "description": "내부 문서에서 관련 정보를 검색한다",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "top_k": { "type": "integer", "minimum": 1, "maximum": 10 }
    },
    "required": ["query"]
  }
}

도구 설명이 모호하면 모델이 도구 선택을 불안정하게 합니다.

Planner와 Executor를 분리할까

복잡한 Agent일수록 분리하는 편이 좋습니다.

Planner: 무엇을 할지 결정
Executor: 실제 도구 호출 수행

이 구조의 장점:

실행 로그 분석이 쉬움
불필요한 반복 호출 방지
권한 검사가 명확함
재시도 정책을 분리 가능

단순 FAQ Agent라면 과할 수 있지만, 멀티스텝 업무 자동화에는 큰 차이를 만듭니다.

상태관리는 어디까지 저장할까

Agent 서비스는 세션 상태 설계가 매우 중요합니다.

보통 아래 세 층으로 나눕니다.

1. Request State

현재 요청 안에서만 필요한 데이터입니다.

사용자 질문
현재 툴 호출 결과
이번 응답에 필요한 중간 계산값

2. Session State

같은 사용자 세션 동안 유지되는 상태입니다.

대화 히스토리
선호 설정
최근 작업 컨텍스트

3. Long-term Memory

장기적으로 재활용할 정보입니다.

사용자 프로필
과거 해결 이력
자주 쓰는 워크플로우

모든 대화를 영구 저장하는 방식은 비용과 프라이버시 측면에서 부담이 큽니다. 저장 가치가 있는 정보만 구조화하는 편이 낫습니다.

Human-in-the-loop가 필요한 구간

AI Agent가 모든 결정을 자동으로 내려서는 안 됩니다.

사람 승인 단계를 두기 좋은 작업:

운영 배포
결제/환불
사용자 권한 변경
데이터 삭제
고객 공지 발송

예시:

1. Agent가 변경 계획 생성
2. 사용자에게 요약과 영향 범위 표시
3. 승인 후 실행
4. 결과 로그 저장

이 승인 단계 하나가 사고 비용을 크게 줄입니다.

장애 대응은 어떻게 설계할까

Agent 서비스는 도구 하나만 실패해도 전체 흐름이 깨질 수 있습니다.

그래서 아래 정책이 필요합니다.

도구별 timeout
재시도 횟수 제한
fallback 응답 정의
부분 실패 허용 여부
circuit breaker

예:

문서 검색 실패 시: 일반 답변 대신 “관련 자료를 찾지 못했다”고 응답
외부 API 실패 시: 최근 캐시 사용 또는 사용자 재시도 유도

비용 통제는 기능이다

Agent는 잘 만들수록 호출 수가 늘어 비용이 빠르게 증가합니다.

비용을 제어하는 방법:

라우팅으로 간단한 질문은 소형 모델 사용
불필요한 히스토리 압축
툴 호출 횟수 상한 설정
동일 질문 캐시
답변 길이 제한

비용 통제가 안 되면 품질 개선보다 운영 지속성이 먼저 무너집니다.

로그와 관측성은 반드시 필요하다

운영 중에는 “왜 이런 답을 했는가”를 추적할 수 있어야 합니다.

남겨야 하는 로그:

사용자 입력
선택된 라우트
모델명과 토큰 사용량
툴 호출 목록
중간 상태 전이
최종 응답
오류와 fallback 발생 여부

가능하면 trace 단위로 묶어서 보는 것이 좋습니다.

안전장치는 어디에 둘까

보통 세 군데에 둡니다.

입력 단계

프롬프트 인젝션 패턴 탐지
금칙어 필터
민감정보 마스킹

실행 단계

허용된 도구만 호출
민감 작업은 승인 필요
외부 요청 도메인 제한

출력 단계

금지된 응답 유형 차단
출처 없는 단정 표현 완화
구조화된 응답 검증

마무리

AI Agent 서비스 설계의 핵심은 “스스로 판단하게 만드는 것”보다 “어디까지 자율성을 줄지 통제하는 것”입니다.

좋은 Agent 시스템은 다음 특징을 가집니다.

도구 경계가 분명함
상태가 추적 가능함
실패 시 안전하게 멈춤
사람 승인 지점이 있음
비용과 품질을 함께 관리함

이 기준으로 설계하면 데모를 넘어 실제 서비스 운영까지 훨씬 수월해집니다.