에이전트에게 Planning을 통째로 맡기면 프로덕션에서 루프를 돌다 멈추는 일이 생깁니다. OpenAI가 공개한 가이드는 그 문제를 정확히 짚습니다. 에이전트는 지능체가 아니라 도구를 쓰는 자동화 프로그램이라는 관점에서 설계를 시작하라고 합니다.

자율성보다 예측 가능성이 먼저입니다

흐름 전체를 모델에 맡기지 말라. 상태 머신처럼 구조를 짜고 각 단계에서 시스템이 판단을 내리도록 명시적으로 유도해야 합니다. 제어가 없는 시스템은 운영 환경에서 사고를 냅니다.

도구 호출도 마찬가지입니다. API 명세만 넘기면 부족합니다. 입력 데이터 형식을 엄격히 제한하고 오류가 나면 원인을 모델에 피드백으로 돌려줍니다. 에러를 그냥 띄우지 않고 재시도 루프로 연결하면 성공률이 올라갑니다. 환각 문제는 지시문에 예시 몇 개를 추가하는 것만으로도 꽤 잡힙니다.

RAG 붙이기 전에 메모리 구조부터 설계하라

RAG를 붙인다고 성능이 바로 좋아지지 않습니다. 대화가 길어질수록 자원 소모는 커지고 유효한 데이터만 걸러내는 필터링 없이는 응답 속도만 늦춰집니다. 고정 정보(사용자 프로필 등)와 가변 정보(현재 대화)를 분리해 관리하면 토큰 비용이 줄어듭니다.

평가 체계를 나중으로 미루면 안 됩니다. 프롬프트 수정 전에 성공과 실패를 가르는 정량 지표부터 세웁니다. 수백 개의 테스트 케이스를 반복 통과하면서 수치가 쌓여야 병목 지점이 보입니다.

모델은 부품입니다

정밀한 계산이나 엄격한 규격이 필요한 작업은 외부 코드나 전문 라이브러리에 맡깁니다. 모든 규칙을 하나의 긴 지시문에 몰아넣으면 유지보수가 불가능해집니다. 기능을 쪼개고 각 모듈이 명확한 역할만 수행하도록 설계하는 것이 전부입니다.

요약

  • 자율적인 Planning보다는 개발자가 정의한 명시적 워크플로우 제어가 프로덕션 환경에서 더 안정적입니다
  • Tool 호출 시 발생하는 에러 피드백을 모델에게 재전달하는 루프 구조가 에이전트의 성공률을 높입니다
  • 정량적 Evaluation 지표 구축은 프롬프트 엔지니어링보다 선행되어야 할 핵심 작업입니다

관련 글