재작성 지시 설계, 어디서 비용이 새는가

재작성 지시 설계는 원문의 암묵적 선호까지 규칙으로 못박는 순간부터 어긋난다. OpenAI 공개 가이드는 원문이 명시적으로 강제하는 규칙만 남기고 암시적·권장 내용은 제약으로 추가하지 말라고 못박는데, 실무에서는 이 경계가 자주 무너진다. 이 글은 그 경계가 무너지는 지점과, 재작성 이후 검증에 실제로 드는 비용 구조를 2026년 기준으로 기록한다.

재작성 지시를 설계할 때 가장 먼저 무너지는 지점은 어디인가?

가장 먼저 무너지는 지점은 "원문에 없던 제약을 선의로 추가하는 순간"이다. 재작성자는 보통 원문을 더 안전하게, 더 명확하게 만들려는 의도로 새 규칙을 끼워 넣는데, 이게 쌓이면 원래 지시보다 더 많은 것을 요구하는 지시가 된다.

• 목표·제약·출력 형식·평가 기준이 한 문단에 뒤섞여 있으면 재작성 중 어느 하나가 누락되기 쉽다.
• instructions와 input을 분리하지 않으면 우선순위가 불명확해져 모델이 어느 쪽을 따를지 뒤섞인다.
• 평가 기준 없이 "좋아 보이게 고쳐라"로 지시하면 재작성 전후 비교가 불가능하다.
• 모델 스냅샷을 고정하지 않고 재작성하면, 같은 프롬프트도 스냅샷이 바뀌는 순간 동작이 달라진다.

흔한 함정은 이렇다. 원문에 "친절하게 답하라"는 문장이 있으면, 재작성자는 이를 "존댓말을 쓰고, 이모지를 넣고, 문단마다 요약을 달아라"로 확장한다. 원문은 어조만 지정했을 뿐인데 형식 제약 세 개가 추가된 셈이다. Prompt Migration Guide는 이런 확장을 "암시적 내용의 제약화"로 분류하고, 모호성·정의되지 않은 용어·충돌하는 지시·누락된 맥락을 별도 오류 유형으로 점검하라고 권한다. 재작성 단계에서 이 네 가지를 체크리스트로 쓰지 않으면, 재작성본이 원문보다 더 많은 것을 요구하면서도 "더 명확해졌다"고 착각하기 쉽다.

목표·제약·형식·평가를 어떻게 나눠야 지시가 안 새는가?

지시가 새지 않으려면 네 블록을 물리적으로 분리해야 한다. 목표는 "무엇을 달성할지", 제약은 "무엇을 반드시 지키거나 금지할지", 출력 형식은 "어떤 필드·자료형·마크업으로 출력할지", 평가 기준은 "성공 여부를 어떻게 검사할지"로 각각 한 블록씩 쓴다. OpenAI Cookbook의 최적화 가이드는 형식 요구가 JSON·CSV·Markdown 표라면 필드명, 자료형, 필수 여부까지 구체화하라고 명시한다.

예를 들어 "리뷰 글로 재작성하라"는 목표만 있고 출력 형식이 비어 있으면, 모델은 매 실행마다 다른 구조로 답을 만든다. 반대로 목표 없이 형식만 촘촘하면 내용은 비어 있는데 형식만 맞는 결과가 나온다. 네 블록을 분리하면 재작성 중 어느 블록이 비었는지 눈으로 바로 확인할 수 있고, 이것이 재작성 검토 시간을 줄이는 가장 직접적인 방법이다.

구조화 출력은 왜 필수 필드 누락을 막아주는가?

구조화 출력이 필드 누락을 막는 이유는 JSON Schema에서 모든 필드를 required로 지정하도록 강제하기 때문이다. Structured Outputs 가이드에 따르면 이 기능은 필수 키 누락과 허용되지 않은 enum 값 생성을 방지하도록 설계됐다.

다만 이는 "스키마를 지키게 강제"하는 것이지 "내용의 품질을 보장"하는 것은 아니다. 필드는 채워지지만 값이 부실할 수 있다는 뜻이다. 재작성 지시에 구조화 출력을 붙일 때 흔한 착각이 여기서 생긴다. 스키마 검증을 통과했다고 해서 평가 기준까지 통과한 것은 아니다. 스키마는 "형식" 블록을 대신하고, 평가 기준은 여전히 별도로 정의해야 한다. 2025년 10월 14일 수행된 한 공개 연구는 20개 진단 프롬프트로 형식 준수, 내용 제약, 논리적 순서, 다단계 실행을 각각 따로 평가했는데, 이는 형식 준수와 내용 품질이 서로 독립적으로 측정돼야 한다는 점을 뒷받침한다. 출처

평가 루프는 몇 개 사례부터 시작해야 신뢰할 수 있는가?

평가 루프는 "분석 → 측정 → 개선"의 3단계로 돌리며, 초기 분석은 약 50개 실패 사례부터 시작하는 편이 실무적으로 권장된다. 평가 플라이휠 가이드는 각 오류에 개방형 라벨을 붙이고, 유사 라벨을 상위 실패 유형으로 묶으라고 안내한다. 이는 보편 법칙이 아니라 OpenAI Cookbook의 실무 권고 수치이며, 프롬프트 복잡도나 도메인에 따라 더 많이 필요할 수 있다.

평가표는 "좋아 보이는가"보다 검증 가능한 항목으로 쪼개야 한다. 앞서 인용한 연구는 256개 검증 모델을 시험하면서 단계 순서 준수, 금칙어·문자 위반 수, 필수 필드 누락 수, 형식 파싱 성공 여부 같은 항목을 사용했다. 별도의 18개 LLM 비교 사례는 2,100~2,400단어, 정확히 3개 H2 장면 같은 하드 제약을 걸고 10점 루브릭과 수정 작업량으로 평가했는데, 이 자료는 독립 학술 논문이 아니라 개인 연구 성격의 공개 벤치마크이므로 제품 성능의 일반화 근거보다는 사례 연구로 보는 편이 안전하다.

재작성하면 원문 의도가 더 정확해진다는 말은 사실인가?

이 말은 부분적으로만 맞다. 재작성은 "표현을 명확하게" 만들 수는 있어도, 원문 작성자가 말하지 않은 의도까지 복원해주지는 않는다. 재작성 과정에서 GPT-4.1 같은 모델로 비평을 받는 절차가 있다 해도, 그 비평은 원문에 없던 해석을 추가할 위험을 동시에 안고 있다.

공개된 Prompt Migration Guide의 6단계 절차—원래 프롬프트 입력, 지시사항 식별, GPT-4.1로 비평, 개정 시스템 프롬프트 생성, 평가·반복, 선택적 권장사항 적용—은 비평과 적용을 분리해 이 위험을 줄이려는 구조다. "GPT-4.1 권장사항 적용"이 선택적 단계로 명시된 이유도, 모델이 제안한 개선이 원문의 명시적 규칙인지 모델의 선호인지 사람이 다시 확인해야 하기 때문이다. 재작성본이 원문보다 "읽기 좋다"는 느낌은 종종 실제로는 제약이 늘어난 결과일 수 있으므로, 재작성 직후 원문과 항목별로 대조하는 과정을 생략해서는 안 된다.

재작성 지시 설계, 운영 비용은 어디서 새는가?

운영 비용은 재작성 자체가 아니라 그 이후의 반복 평가에서 주로 샌다. 프롬프트를 바꿀 때마다 평가 실행을 다시 돌려야 하고, 모델 스냅샷이 바뀌면 동일한 프롬프트라도 재검증이 필요하다. OpenAI Prompt Engineering Guide는 운영 환경에서 모델 스냅샷을 gpt-4.1-2025-04-14처럼 고정하고, 프롬프트 변경 전 대표 테스트 사례와 평가 검사를 추가하라고 권고한다.

비용을 기록할 때는 "저렴하다"는 식의 단정 대신 모델명, 입력·출력 토큰 단가, 사용량, 캐시 적용 여부, 평가 실행 횟수, 기준일을 함께 적어야 재현 가능한 비교가 된다. 이번 리서치에는 2025~2026년의 검증 가능한 구체 단가가 포함되지 않아, 이 글에서도 특정 비용 수치를 추가로 제시하지 않는다. 운영 체크리스트로는 모델명, 스냅샷 또는 문서 기준일, 프롬프트 핵심 조건, 테스트 입력 수, 평가 기준, 실패율·수정 횟수를 함께 기록하는 방식이 재현성 측면에서 안전하다.

핵심 정리

• 재작성의 가장 흔한 함정은 원문에 없던 암시적 선호를 제약으로 승격시키는 것이다.
• 목표·제약·형식·평가를 물리적으로 분리하면 어느 블록이 비었는지 바로 확인할 수 있다.
• 구조화 출력은 필드 누락을 막아주지만 내용 품질까지 보장하지는 않는다.
• 초기 실패 분석은 약 50개 사례부터, 평가 항목은 "좋아 보이는가"가 아니라 검증 가능한 지표로 쪼갠다.
• 운영 비용은 재작성 자체보다 모델 스냅샷 변경 시의 재검증 반복에서 주로 발생한다.