에이전트가 같은 실수를 반복할 때 가장 먼저 손이 가는 곳은 프롬프트다. 지시를 더 명확하게 다듬으면 해결될 것 같다. 하지만 대부분의 반복 실수는 지시 문제가 아니라 흐름 설계 문제다.
프롬프트를 수정해도 같은 실수가 반복되는 이유는 무엇인가
프롬프트는 에이전트에게 무엇을 어떻게 할 것인지를 알려준다. 그런데 실수가 발생하는 조건, 즉 특정 상황에서 에이전트가 어떤 선택지를 갖게 되는지는 흐름 설계가 결정한다.
예를 들어 "외부 발송 전에 항상 확인하라"는 지시를 프롬프트에 넣어도, 에이전트는 발송 직전에 스스로 판단을 내린다. 반면 "발송 단계에 사람 승인이 반드시 필요하도록 흐름을 나눈다"는 설계는 에이전트의 판단 자체를 막는다.
프롬프트는 에이전트의 행동을 유도하지만, 구조는 에이전트가 실수할 수 있는 선택지 자체를 제거한다. 같은 실수가 프롬프트 수정 후에도 2회 이상 반복된다면, 그것은 구조 문제로 봐야 한다.
반복 실수를 막는 구조에는 어떤 종류가 있는가
승인 게이트: 에이전트가 외부에 영향을 미치는 행동(발송, 게시, 결제, 삭제)을 실행하기 전에 사람이 확인하는 단계를 삽입한다. 프롬프트 개선보다 즉각적이고 안정적이다. 실수를 예방하는 것이 아니라 실수가 외부에 도달하기 전에 차단하는 방식이다.
범위 격리: 에이전트가 실수를 해도 다른 프로세스나 데이터에 영향을 주지 않도록 동작 범위를 한정한다. 예를 들어 특정 폴더 안의 파일만 처리하거나, 특정 레이블이 붙은 메일만 분류하도록 설계하면 실수의 파급 범위가 제한된다.
실행 전 체크리스트: 에이전트가 특정 행동을 실행하기 전에 반드시 충족해야 하는 조건 목록을 명시적으로 정의한다. 조건을 충족하지 못하면 실행이 차단된다. 프롬프트에 "확인하라"고 쓰는 것보다 확인 항목을 구조화하면 통과 여부가 명확해진다.
반복 실수가 생겼을 때 어떤 순서로 접근해야 하는가
- 최근 2주간 같은 유형으로 발생한 실수를 3개 이상 수집한다
- 각 실수가 "에이전트가 지시를 잘못 이해한 것"인지 "흐름상 그렇게 선택할 수밖에 없는 구조인지"를 구분한다
- 전자라면 프롬프트를 수정하고, 후자라면 단계 분리나 승인 삽입으로 흐름 자체를 바꾼다
이 구분이 중요한 이유가 있다. 구조 문제를 프롬프트로 계속 고치려 하면 프롬프트가 길어지고 복잡해지지만, 정작 실수는 줄어들지 않는다. 진단을 먼저 하는 것이 수정 시간을 줄이는 방법이다.