프롬프트만으로 글자 수를 정확히 맞출 수 있을까?

결론부터 쓰면, "짧게 써줘" 같은 지시만으로는 분량이 매번 들쭉날쭉하지만, 목표·제약·형식·평가를 네 블록으로 분리하고 측정 단위를 명시한 뒤 후검사를 더하면 결과를 검수 가능한 범위로 좁힐 수 있다. 다만 어떤 조합도 글자 수를 완벽히 보장하지는 않는다. 최종 판정은 결국 애플리케이션 쪽에서 실제 문자열 길이를 다시 계산하는 방식으로만 가능하다.

  • GPT-5의 verbosity 파라미터는 간결함 수준만 조절할 뿐 정확한 단어 수를 보장하지 않는다.[출처: https://openai.com/index/introducing-gpt-5-for-developers/]
  • "한국어 700~900자, 본문 4문단, 문단당 3~4문장" 처럼 측정 단위를 명시하면 검수 기준을 만들기 쉽다.
  • Structured Outputs로 character_count 필드를 받아도 모델이 보고한 숫자를 그대로 믿지 말고 재계산해야 한다.[출처: https://developers.openai.com/api/docs/models/gpt-5]
  • max_output_tokens는 상한일 뿐 목표 분량이 아니며, 종료 조건은 프롬프트에 별도로 써야 한다.
  • 이 글은 2026년 기준 공개 API 문서와 가격표를 근거로 설계 패턴을 정리하고, 직접 반복 측정이 필요한 지점을 분리해 표시한다.

이번 실험에서 검증하려는 것은 하나다. 프롬프트를 목표·제약·형식·평가 네 블록으로 나누면, 단순히 "짧게 써줘"라고 요청할 때보다 실제로 분량 통제가 쉬워지는가. 이 질문에 정답을 주는 독립 벤치마크는 확인되지 않았다. 그래서 공개 문서에 나온 메커니즘을 근거로 설계 패턴을 정리하고, 어디서부터는 직접 돌려봐야 알 수 있는지를 구분해 남겨둔다.

목표·제약·형식·평가를 나누면 왜 더 잘 맞을까?

네 블록을 분리하면 모델이 "무엇을 얼마나 어떻게" 써야 하는지를 각각 다른 규칙으로 받기 때문에, 하나의 뭉뚱그린 지시보다 검증 지점이 명확해진다. 예를 들어 다음 구조를 쓸 수 있다.

[목표] 자료를 일반 독자용 사용 후기로 요약한다.
[제약] 한국어 800~1,000자, 확인된 수치만 사용, 추측 표현 금지
[형식] 핵심 결론 1문장 + 불릿 6개, 각 수치 뒤 출처 표기
[평가] 실제 글자 수 계산, 수치별 출처 확인, 위반 시 재작성

이렇게 쓰면 "짧게"라는 모호한 지시 대신 "800~1,000자"라는 숫자, "불릿 6개"라는 형식, "출처 표기"라는 체크 항목이 각각 독립적으로 검증 가능해진다. 평가 블록을 모델 자신에게 다시 넘기는 방식(자기 검증)과, 애플리케이션 코드에서 글자 수를 세는 방식을 병행하면 더 안전하다. 다만 이 구조가 글자 수 준수율을 몇 퍼센트까지 끌어올리는지에 대한 2025~2026년 공개 벤치마크 수치는 확인되지 않았으므로, 이 부분은 판단 기준으로만 제시한다.

verbosity와 max_output_tokens로 분량을 통제할 수 있을까?

부분적으로만 가능하다. GPT-5 API는 verbosity를 low, medium, high로 설정해 답변의 간결함·상세도를 조절하지만, 이는 "정확한 단어 수 보장" 기능이 아니다.[출처: https://openai.com/index/introducing-gpt-5-for-developers/] 최종 길이를 고정하려면 verbosity와 별도로 출력 제약을 프롬프트에 명시하는 편이 안전하다. 토큰 상한 쪽도 마찬가지다. GPT-5는 최대 272,000 입력 토큰, 최대 128,000 추론·출력 토큰, 전체 컨텍스트 400,000토큰을 지원하지만, max_output_tokens를 1,000으로 설정해도 1,000토큰을 반드시 채워서 생성하지는 않는다. 즉 토큰 제한은 "넘지 말아야 할 최대치"이지 "도달해야 할 목표"가 아니다. 가격 구조도 길이 설계에 영향을 준다. GPT-5는 입력 100만 토큰당 1.25달러, 출력 100만 토큰당 10달러로 출력 쪽 단가가 더 높다.[출처: https://openai.com/index/introducing-gpt-5-for-developers/] 불필요한 예시·규칙·대화 이력을 줄이면 비용과 지연을 동시에 낮출 여지가 있지만, 특정 프롬프트의 축약률이나 품질 유지율은 과제별로 직접 측정해야 확인할 수 있다.

구조화된 출력과 후검사로 글자 수를 검증하는 법은?

정확한 길이가 필요할 때는 Structured Outputs와 애플리케이션 재검사를 함께 쓰는 쪽이 현실적이다. GPT-5 계열은 Structured Outputs를 지원하므로, summary, body, character_count, constraint_check 같은 필드를 JSON으로 받는 설계가 가능하다.[출처: https://developers.openai.com/api/docs/models/gpt-5] 여기서 주의할 점은 모델이 스스로 보고한 character_count 값을 그대로 신뢰하지 않는 것이다. 모델은 자기 출력을 다시 세는 작업에서도 오차를 낼 수 있으므로, 실제 문자열 길이는 애플리케이션 코드에서 len() 같은 함수로 재계산해야 한다. 이렇게 얻은 숫자를 바탕으로 "분량 범위 충족 여부", "수치별 출처 존재 여부", "모델명·버전 표기 여부", "불릿 개수", "추측 표현 포함 여부"를 각각 통과·실패로 판정하는 이진 체크리스트를 만들면 "대체로 짧다" 같은 주관적 평가를 줄일 수 있다. 조건을 벗어난 경우 모델에게 같은 평가 블록을 넘겨 재작성을 요청하는 루프를 한두 번 추가하는 방식도 실무에서 쓰인다.

긴 프롬프트와 긴 컨텍스트는 길이 제어에 어떤 변수를 더할까?

입력이 길어질수록 출력 길이 관리가 더 까다로워지므로 둘을 분리해서 설계해야 한다. Claude Sonnet 4 API는 2025년 공개 기준 최대 100만 토큰 컨텍스트를 지원하지만, 20만 토큰을 초과하는 프롬프트에는 더 높은 가격이 붙는다. 20만 토큰 이하 구간은 입력 100만 토큰당 3달러·출력 15달러이고, 초과 구간은 입력 6달러·출력 22.50달러다.[출처: https://www.anthropic.com/news/1m-context] 고정된 시스템 지침이나 긴 문서를 매번 통째로 보내면 비용이 커지므로, Anthropic 문서에 따르면 프롬프트 캐싱을 쓰는 편이 유리하다. 5분 캐시 쓰기는 기본 입력 가격의 1.25배, 1시간 캐시 쓰기는 2배, 캐시 적중 읽기는 0.1배다.[출처: https://docs.anthropic.com/en/docs/about-claude/pricing] 즉 변하지 않는 목표·제약·형식 블록은 캐시 대상으로 고정하고, 매번 달라지는 질문이나 자료만 새로 보내는 구조가 길이 제어 실험을 반복할 때 비용 부담을 줄여준다.

공개 자료가 실제로 확인해 주는 것과 확인해 주지 않는 것은?

GPT-5의 SWE-bench Verified 점수는 74.9%로 공개됐지만, 이는 소프트웨어 공학 과제 성능 지표이지 목표 글자 수 준수율이나 길이 제어 정확도를 뜻하지 않는다.[출처: https://openai.com/index/introducing-gpt-5-for-developers/] 이 글에서 이 수치는 "전반적 작업 성능 참고용"으로만 쓰고, 길이 제어 주장의 근거로 쓰지 않는다. 마찬가지로 verbosity 파라미터, Structured Outputs 지원 여부, 토큰 상한, 가격, 캐싱 할인율은 모두 공개 문서에서 확인된 사실이지만, "목표·제약·형식·평가 분리 프롬프트가 글자 수 범위를 몇 퍼센트 지켰는가"를 직접 측정한 독립 벤치마크는 찾지 못했다. 이 구분을 분명히 해 두지 않으면 "모델 성능이 좋으니 길이도 잘 맞을 것"이라는 식의 비약으로 이어지기 쉽다.

이 방법은 어디서 막힐까?

가장 큰 한계는 실측 부재다. 이 글에 정리한 네 블록 구조, verbosity 조절, Structured Outputs 조합이 실제로 몇 퍼센트의 생성 결과를 목표 글자 수 범위 안에 넣는지는 같은 모델·프롬프트·온도·입력 자료를 고정한 뒤 10~30회 반복 생성해서 직접 측정해야 알 수 있다. 공개 문서 어디에도 이 수치는 없다. 또 다른 한계는 컨텍스트와 가격이 모델 버전에 따라 바뀐다는 점이다. GPT-5와 Claude Sonnet 4의 토큰 상한·가격·지원 기능은 문서 업데이트로 달라질 수 있으므로, 리뷰나 운영 문서에는 확인일, API 모델명, 문서 버전 또는 기준일, 사용한 max_output_tokens·verbosity 값을 함께 적어 두는 편이 안전하다.[출처: https://developers.openai.com/api/docs/models/gpt-5] 마지막으로, 모델이 보고하는 글자 수나 평가 결과를 그대로 신뢰할 수 없다는 점도 구조적 한계다. 애플리케이션 쪽 재계산 없이는 "평가 통과"라는 모델의 자기 보고만으로 길이 제어가 됐다고 결론 내리기 어렵다.

다음 실험에서 확인할 것은?

이번 정리는 설계 패턴을 모으는 데 그쳤고, 실측은 다음 단계로 남겨둔다. 계획은 같은 프롬프트를 동일 조건으로 10~30회 호출해 실제 글자 수의 평균·최솟값·최댓값·목표 범위 준수율을 기록하는 것이다. 네 블록 구조를 쓴 경우와 단순 지시만 쓴 경우를 나란히 돌려서 차이를 비교할 필요도 있다. 이 글 자체는 그 비교 실험의 사전 설계도에 가깝다. 공개 문서에 있는 사실과, 아직 확인하지 못한 가설을 섞지 않고 구분해 두는 것이 이번 작업에서 가장 신경 쓴 부분이다.

핵심 정리

  • "짧게 써라"보다 "한국어 800~1,000자, 불릿 6개" 같은 측정 단위 지시가 검수 가능한 결과를 만든다.
  • verbosity, max_output_tokens는 분량 조절에 참고가 되지만 정확한 길이를 보장하는 기능이 아니다.
  • Structured Outputs로 character_count를 받아도 애플리케이션에서 실제 문자열 길이를 재계산해야 한다.
  • 긴 시스템 지침은 프롬프트 캐싱으로 비용을 줄이고, 매번 바뀌는 질문과 분리해 관리하는 편이 유리하다.
  • 이 설계 패턴의 글자 수 준수율은 공개 벤치마크로 확인되지 않으므로, 적용하려면 같은 조건으로 10~30회 반복 측정하는 과정이 필요하다.