정확히 지시하고, 구조로 받아내기

4.1 지시의 명시성이 정밀도를 결정한다

에이전트에게 '부적절한 요청을 걸러내라'처럼 모호하게 지시하면, 판정 기준을 모델이 매번 임의로 세우게 됩니다. 대신 판정 범주를 명시적으로 열거하고 각 범주의 조건을 문장으로 규정하면 정밀도가 올라가고 거짓 양성(false positive, 실제로는 문제없는 입력을 문제라고 판정하는 오류)이 줄어듭니다. 거짓 양성은 그 에이전트를 운영하는 개발자와 담당자의 신뢰를 빠르게 갉아먹습니다 — 한 번 오탐을 겪으면 판정 결과 전체를 의심하게 되기 때문입니다. 설계자에게 프롬프트의 판정 기준은 시스템 계약의 일부이며, 문서로 관리해야 하는 사양입니다.

4.2 퓨샷 예시로 판단의 일관성을 확보한다

퓨샷(few-shot, 프롬프트에 정답 예시 몇 개를 함께 제시하는 방식)은 판단의 일관성을 확보하는 핵심 장치입니다. 예시는 많을수록 좋은 것이 아니라, 경계가 흐릿한 사례를 겨냥한 두세 개면 충분합니다. 잘 고른 예시는 원하는 출력 형식을 눈으로 보여 주고, 예시에 없던 새로운 패턴으로도 일반화하도록 유도하며, 특히 추출 작업에서 없는 값을 지어내는 환각(hallucination, 근거 없는 내용을 만들어 내는 현상)을 줄여 줍니다. 애매한 표기 두셋을 골라 정답과 함께 보여 주는 편이, 규칙을 장황하게 나열하는 것보다 효과가 큽니다.

4.3 구조화 출력은 문법 오류를 없애되 의미 오류는 남긴다

도구 정의(tool_use, 모델이 미리 정한 JSON 스키마에 맞춰 응답하도록 하는 방식)로 구조화 출력을 받으면 괄호 누락이나 깨진 JSON 같은 문법 오류는 사라집니다. 그러나 형식은 맞는데 값이 틀린 의미 오류(semantic error)는 그대로 남는다는 점을 설계자는 반드시 구분해야 합니다. tool_choice로 도구 호출을 제어합니다 — auto는 모델이 필요할 때만, any는 반드시 하나의 도구를, forced는 지정한 도구를 강제합니다. 필드는 required와 optional·nullable을 구분하고, 열거형(enum)에는 '기타'와 자유서술 필드를 함께 두어 스키마 밖 사례를 흡수하도록 설계합니다.

4.4 검증과 재시도, 그리고 재시도가 소용없는 지점

검증에 실패하면 오류 메시지를 모델에 다시 전달해 재시도하는 방식(retry-with-error-feedback)이 기본입니다. 다만 재시도가 만능은 아닙니다. 원문에 애초에 정보가 없으면 몇 번을 다시 요청해도 없는 값을 만들어 낼 수 없으므로, 이때는 재시도 한도를 두고 '미검출'로 표기하는 편이 정직합니다. 문법 오류와 의미 오류는 원인이 다릅니다 — 문법 오류는 재시도로 잘 교정되지만, 의미 오류는 프롬프트나 예시 자체를 손봐야 합니다. 반복해서 나타나는 실패 유형을 기록해 두면(detected_pattern) 어느 지점을 고쳐야 하는지 드러납니다.

4.5 지연을 허용하는 작업은 배치로 묶는다

모든 요청이 실시간 응답을 요구하지는 않습니다. 사용자가 화면 앞에서 기다리는 작업(blocking)과, 결과를 나중에 받아도 되는 지연 허용(latency-tolerant) 작업을 먼저 구분하는 것이 설계의 출발점입니다. 지연을 허용할 수 있는 대량 작업은 메시지 배치 API(Message Batches API, 다수의 요청을 한 번에 제출하는 방식)로 묶으면 비용을 절반으로 줄일 수 있습니다. 대신 최대 24시간까지 걸릴 수 있고 응답 시각을 보장하지 않습니다. 각 요청에 custom_id를 붙여 응답과 짝지으며, 여러 차례 오가는 도구 호출은 배치에서 지원하지 않는다는 제약을 감안해 설계합니다.

4.6 독립된 검토가 자기검토보다 더 잡는다

한 인스턴스가 자기 결과를 스스로 검토하게 하는 것보다, 서로 독립적으로 실행한 여러 검토 인스턴스(review instance)를 두는 편이 더 많은 문제를 잡아냅니다. 자기검토는 자기 판단의 사각지대를 그대로 물려받기 때문입니다. 검토는 두 층으로 나눕니다. 파일 하나씩 보는 파일 단위 검토와, 파일 사이의 어긋남을 보는 통합 검토를 각각 수행합니다. 여기에 모델이 스스로 확신도를 함께 보고하도록 설계하면, 확신도가 낮은 항목만 상위 모델이나 담당 엔지니어의 검토로 넘겨 자원을 아낄 수 있습니다.

! 흔한 함정

• 구조화 출력(tool_use)을 쓰면 오류가 사라진다고 오해합니다 — 문법 오류는 없어져도, 형식만 맞고 값이 틀린 의미 오류는 그대로 남습니다.
• 예시는 많이 넣을수록 좋다고 생각합니다 — 경계 사례를 겨냥한 두세 개가 무작정 많은 예시보다 일관성에 유리합니다.
• 검증 실패를 무조건 재시도로 해결하려 합니다 — 원문에 정보가 없는 경우는 재시도해도 답이 나오지 않으므로 한도와 '미검출' 처리가 필요합니다.
• 실시간이 필요 없는 대량 작업까지 개별 요청으로 처리해 비용과 시간을 낭비합니다 — 지연 허용 작업은 배치로 묶는 편이 맞습니다.