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

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

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

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

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

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

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

모델은 부품이다

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

핵심만 뽑으면

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

관련 글

소스