에이전트의 신뢰성은 모델이 지시를 얼마나 잘 기억하느냐에만 달려 있지 않다. 규칙이 늘어날수록 자연어로 전달하는 방식의 한계와 실행 단계에서 통제하는 방식의 차이가 커진다.
긴 프롬프트가 문제를 해결하지 못하는 이유
기업용 에이전트의 시스템 프롬프트에는 브랜드 문체부터 보안 정책, 예외 처리까지 규칙이 계속 붙는다. 하지만 지시가 길어질수록 일부를 빠뜨리거나 형식만 맞춘 답을 내놓기 쉽다. 웹사이트 제작 플랫폼 Wix의 엔지니어링팀은 이를 컨텍스트 피로라고 부른다.
실제로 컨텍스트 창(모델이 한 번에 입력받아 처리하는 정보 범위)이 넓다고 모든 정보를 고르게 처리하는 것도 아니다. 벡터 데이터베이스 기업 Chroma가 18개 모델을 평가한 결과, 입력이 길어질수록 성능이 떨어졌고 정보의 위치에 따라서도 차이가 났다. 프롬프트 중간에 묻힌 브랜드 규칙이나 예외 조항은 모델이 읽어도 놓치는 경우가 있다는 뜻이다.
도구를 연결하면 상황은 더 나빠지지 않는가. 한 측정에서는 MCP 서버 7개의 도구 정의만 6만7,300토큰을 차지했다. 실제 실행 기록을 분석한 연구에서도 주요 실패 원인은 불완전한 명세와 조율 실패, 검증 부족이었다. 이처럼 문제는 프롬프트의 문장보다 운영 구조에 가깝다.
모델 대신 검증기가 판단한다
더 긴 지시를 주는 대신 결과물을 검사하는 편이 낫다. 에이전트가 초안을 만들면 검증기가 스키마(데이터의 구조, 필드, 형식을 정한 규칙), 디자인 토큰(색상, 간격, 글꼴 같은 디자인 값을 표준화한 변수), 접근성 기준, API 계약(API가 주고받을 데이터 형식과 동작 조건을 정한 규칙)을 확인하고, 문제가 있으면 원인과 수정법을 돌려주고 다시 시도하게 한다. 별도의 심판 모델은 필요하지 않다.
그렇다고 모델에게 자기 답을 다시 읽게 한다고 정확도가 높아질까. 외부 정보 없이 답을 고치게 한 연구에서는 재검토 뒤 성능이 떨어진 사례도 나왔다. 같은 한계를 지닌 모델은 오류를 잡기보다 되풀이하기 쉽다.
여기에 평가 모델의 자기선호 편향(같은 모델 계열이 내놓은 답을 스스로 더 후하게 평가하는 경향)도 섞인다. 한 연구에서는 이 영향으로 HealthBench(의료 대화 답변의 정확성을 평가하는 벤치마크) 점수가 최대 10점 달라졌다. 따라서 필드 누락이나 규격 위반은 코드가 검사하고, 설득력이나 브랜드 적합성처럼 정답이 하나가 아닌 항목만 사람이나 평가 모델에 맡겨야 한다.
오류 메시지를 수정 매뉴얼로 만든다
검증을 쉽게 하려면 결과물의 형식부터 제한해야 한다. Jay Framework는 복잡한 자바스크립트 대신 HTML과 CSS에 Jay 태그를 섞은 선언형(원하는 결과 구조만 기술하는 방식) Jay HTML을 쓴다. 검증기는 이를 컴포넌트 계약(컴포넌트가 허용하는 속성, 상태, 데이터 형식의 규칙)과 design.md의 디자인 규칙에 맞춰 검사한다. 자유도를 조금 줄이는 대신 대부분의 규칙을 자동으로 확인한다.
이런 장치는 실무에서 특히 중요하다. 웹 접근성 전문 기관 WebAIM이 상위 100만 개 홈페이지를 검사했더니 95.9%에서 WCAG(웹 콘텐츠 접근성 지침) 위반이 발견됐고 페이지당 오류는 평균 56.1건이었다. 사람이 자주 놓치는 기준을 긴 프롬프트만으로 어떻게 지키겠는가.
같은 맥락에서 도구 설명도 필요할 때만 주면 된다. Jay WebMCP Plugin은 호출이 실패했을 때 해당 스키마와 허용값, 관련 문서만 오류 응답에 담는다. 이런 지연 로딩은 컨텍스트와 비용을 함께 아낀다. Anthropic의 Tool Search Tool도 필요한 도구만 불러와 도구 정의의 토큰 사용량을 85% 줄인다.
API 오류 역시 단순한 HTTP 400에 그쳐서는 안 된다. 잘못된 필드와 허용값, 예상 스키마, 수정 절차를 기계가 바로 읽도록 제공해야 한다. 오류 메시지가 곧 에이전트의 수정 매뉴얼이다.
무엇을 코드로 옮길 것인가
정리하면 목표와 역할, 어조처럼 하나의 답으로 판정하기 어려운 내용은 시스템 프롬프트에 남긴다. 필수 필드, 색상 토큰, 스키마, 대비율처럼 참과 거짓이 갈리는 규칙은 코드로 옮긴다.
| 구분 | 남기는 곳 |
|---|---|
| 목표·역할·어조 | 시스템 프롬프트 |
| 필수 필드·색상 토큰·스키마·대비율 | 코드 |
기계가 자동으로 검사하는 규칙은 검증기에 둔다. OpenAI의 구조화 출력(미리 정한 스키마에 맞춰 생성하는 출력) 실험에서도 모델 학습만으로는 스키마 준수율이 93%였지만, 제약 디코딩을 적용하자 100%에 도달했다. 제약 디코딩은 생성 단계마다 스키마상 유효한 토큰만 고르도록 제한하는 방식이다. 지시를 늘리는 대신 잘못된 형식이 나오지 않게 한 결과다.
코드로 관리한 규칙은 버전 기록과 회귀 테스트(변경 뒤 기존 기능이나 규칙이 깨지지 않았는지 다시 확인하는 테스트)가 가능하다. 모델을 바꿔도 같은 검증기를 그대로 쓰기 때문에 유지도 쉽다.
다만 검증기가 결과물의 가치까지 보장할까. 접근성 기준을 통과한 페이지도 전환율은 낮을 수 있다. 코드는 반드시 지켜야 할 최저선을 맡고, 실제 효용은 사람의 평가와 사용 지표로 확인해야 한다.
결국 안정적인 에이전트는 긴 프롬프트보다 검사 가능한 규칙과 고치기 쉬운 오류에 기대어 작동한다.
그 결과 이 구조에서는 모델의 성능 변화와 운영 규칙의 결함을 분리해서 본다. 같은 실패가 반복될 때도 모델 교체부터 검토할 필요 없이 어느 검사와 피드백이 부족했는지 확인할 여지가 생긴다.