AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

AI 에이전트 튜토리얼 – 프로덕션 에이전트 파이프라인 7계층 설계하기

프로덕션 AI 에이전트는 “LLM을 while 루프에 넣고 도구를 호출하게 하는 코드”보다 더 넓은 구조가 필요하다. 실전에서는 입력 정규화, 기억, 계획, 도구 실행, 오케스트레이션, 가드레일, 관찰 가능성이 분리돼야 장애 원인을 찾고 권한을 통제할 수 있다.

기본 루프

에이전트의 중심 루프는 다음 흐름으로 볼 수 있다.

Goal -> Perception -> Reasoning -> Planning -> Action
     -> Observation -> Memory Update -> Reasoning ...

데모에서는 이 루프가 한 파일에 섞여 있어도 돌아간다. 하지만 동시 사용자, 실패하는 외부 API, 장기 작업, 고객 데이터 접근, 비용 한도가 들어오면 각 책임을 분리해야 한다.

7계층

계층책임흔한 실패
Perception웹훅, 텍스트, 파일, 음성, API payload를 공통 구조로 변환입력 형식마다 다른 의미로 해석
Memory현재 작업 컨텍스트와 장기 기억을 구분오래된 정보가 현재 지시를 덮어씀
Reasoning목표·입력·기억을 바탕으로 다음 판단 수행도구 없이 추측하거나 너무 큰 계획 생성
Planning실행 가능한 단계와 중단 조건 정의실패 복구 경로 없음
Tool Execution외부 API·파일·코드 실행 호출재시도·타임아웃·권한 경계 누락
Orchestration루프 상태, 분기, 멀티에이전트 조율언제 멈춰야 하는지 모름
Guardrails & Observability정책 적용과 trace 기록문제 발생 후 원인 재현 불가

설계 원칙

입력은 먼저 구조화한다

에이전트가 받는 입력은 자연어만이 아니다. 웹훅 JSON, 업로드 파일, 브라우저 상태, Slack 메시지, 음성 transcript가 한 시스템에 들어올 수 있다. perception 계층은 이를 intent, entities, source, risk, attachments처럼 downstream이 신뢰할 수 있는 구조로 바꿔야 한다.

작업 기억과 장기 기억을 나눈다

작업 기억(working memory)은 현재 세션에서 필요한 최근 turn과 임시 상태를 담는다. 장기 기억(episodic memory)은 과거 실행 결과, 사용자 선호, 실패 사례를 검색 가능한 형태로 보존한다. 둘을 섞으면 오래된 메모가 현재 지시보다 강해져 잘못된 결정을 만들 수 있다.

도구 실행은 정책으로 감싼다

도구 호출은 모델의 판단이 아니라 시스템의 권한 모델을 따라야 한다. 예를 들어 send_email, delete_customer, deploy_production은 일반 조회 도구와 같은 권한 수준으로 두면 안 된다. allow/deny list, 비용 한도, 도메인 제한, 사람 승인, 감사 로그를 실행 계층에 넣어야 한다.

관찰 가능성은 나중에 붙이지 않는다

에이전트 장애는 “최종 답변이 틀렸다”보다 “4번째 단계에서 어떤 도구를 왜 골랐는가”가 핵심이다. 목표, 계획, 도구 입력, 도구 출력, 정책 결정, 재시도, 중단 사유를 trace로 남겨야 eval과 디버깅이 가능하다.

언제 프레임워크를 쓸까

작은 내부 자동화는 raw API와 몇 개의 명시적 함수로 충분하다. 하지만 상태 그래프, 재시도, human-in-the-loop, 멀티에이전트, trace 저장이 필요해지면 LangGraph, CrewAI, AutoGen 같은 오케스트레이션 프레임워크를 검토할 만하다. 핵심은 프레임워크 도입 자체가 아니라 각 계층의 책임이 코드에서 드러나게 만드는 것이다.

관련 문서

참고 자료



AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)