대모델 애플리케이션에 왜 「출력 길이 예산」이 반드시 필요한가
길이는 부작용이 아니라 설계 파라미터다.
5가지 심층 영향 차원
| 차원 | 주석 |
|---|
| 비용 통제 | API 과금에 직접 영향 |
| 응답 지연 | 첫 글자와 전체 소요 |
| 포맷 안정 | 출력 절단이나 주제 이탈 방지 |
| 중점 밀도 | 군말이 핵심 정보를 희석하는 것을 방지 |
| 사용자 경험 | 장황한 글은 아무도 끝까지 읽지 않음 |
장면마다 필요한 길이가 완전히 다르다
| 장면 | 기대 출력 |
|---|
| 고객센터 장면 | 세 문장이면 충분 |
| 리서치 장면 | 완전한 도출 과정 |
| 리포트 장면 | 고정 필드 |
「한 문장 쓰기」에서 「파라미터 세트 구성하기」로 업그레이드
- 반례: 프롬프트에 「답변을 좀 짧게」라고만 쓰는 것 — 통제 불가, 측정 불가
- 정례: 작업 유형별로 네 항목을 설정
| 설정 항목 | 역할 |
|---|
max_tokens | 하드 상한, 비용과 지연을 방어 |
| 문단 수 | 구조 전개의 입도를 통제 |
| 필드 수 | 구조화 출력 장면의 형태 제약 |
| 우선순위 | 길이가 부족할 때 무엇부터 버릴지 결정 |
콘텐츠 우선순위 전략: 길이가 부족할 때 무엇을 지킬 것인가
| 우선순위 | 내용 | 처리 |
|---|
| 높음 | 결론, 리스크 경고 | 반드시 보장 |
| 낮음 | 원인, 예시 | 공간이 허용하면 보충 |
정리
대모델 출력에는 길이 예산이 있어야 한다. 길이가 비용, 지연, 중점, 표시 경험에 영향을 주기 때문이다. 상용 시스템은 작업 유형과 표시 장면에 따라 출력을 통제해야지 모델이 자유롭게 발휘하게 두면 안 된다.
핵심 통찰
- 길이는 설계 파라미터이지 모델의 자유도가 아니다 — 「얼마나 길게 쓸지」를 모델이 스스로 결정하게 두는 것은 제품 경험을 샘플링 무작위성에 맡기는 것과 같다. 성숙한 시스템에서 길이는 temperature나 top_p와 마찬가지로 명시적으로 선언해야 할 설정 항목이다.
- 「Token 절약」은 다섯 영향면 중 가장 얕은 하나일 뿐이다 — 비용 / 지연 / 포맷 안정 / 중점 밀도 / 사용자 경험, 이 다섯 링크가 모두 길이에 끌려 움직인다. 이 다섯을 나란히 말하면 자연스럽게 「돈 절약」이라는 저득점 구간에서 벗어난다.
- 너무 긴 것과 너무 짧은 것은 같은 병의 두 증상이다 — 장황한 전개와 예기치 않은 절단은 둘 다 「예산이 없음」에서 온다. 이것이 프롬프트에 「짧게」라고만 쓰면 양방향으로 실패하는 이유를 설명한다. 그것은 전개해야 할 부분을 압축하면서 주제 이탈은 제약하지 못한다.
- 우선순위 설계가 길이 상한보다 중요하다 — 길이 상한은 「얼마나 쓸 수 있는가」를 정하고, 우선순위는 「다 못 쓸 때 무엇을 버리는가」를 정한다. 결론과 리스크 경고를 먼저 지키고 원인과 예시를 나중에 보충하는 이 순서가 절단을 「사고」에서 「우아한 강등」으로 바꾼다.
- 출력 규격은 표시 컨테이너로부터 역산해야 한다 — 프런트엔드 컨테이너의 물리적 크기(카드 / 말풍선 / 셀 / 본문)가 진짜 길이 제약의 원천이다. 표시 위치를 떠나서 정의된 출력은 내용이 완전히 맞아도 사용 불가능하다.
- 같은 시스템에도 여러 세트의 길이 등급이 필요하다 — 고객센터, 리서치, 리포트 세 종류 작업의 합리적 길이는 한 자릿수 이상 차이 난다. 전역 max_tokens 하나로 때우는 것은 전형적인 게으른 설계다. 길이 예산은 애플리케이션이 아니라 작업 유형에 매달아야 한다.
- 설정 가능하다는 것은 곧 평가 가능하다는 뜻이다 — 「자연어 요구 한 줄 쓰기」에서 「max_tokens / 문단 수 / 필드 수 / 우선순위 설정하기」로 바꾸는 것은, 본질적으로 모호한 지시를 버전 관리 가능하고 A/B 가능하며 회귀 가능한 공학 파라미터로 바꾸는 것이다.
엔지니어링 실전 Tips
- 「답변을 좀 짧게」 같은 자연어 제약을 주 통제 수단으로 삼지 말 것. 불안정하고 정량화도 불가능하다. 자연어는 보조만 하고 하드 제약은
max_tokens에 맡길 것.
- 지연 최적화는 첫 글자 소요와 전체 소요 두 값을 함께 볼 것. 긴 출력이 전체 소요에 미치는 영향이 첫 글자에 미치는 영향보다 훨씬 크므로, 스트리밍 장면에서는 나누어 측정해야 한다.
- 포맷 안정성은 길이와 직접 관련이 있다: 출력이 상한에 가까울 때 구조 절단(JSON 괄호 누락, 마크다운 표 줄바꿈 깨짐)이 가장 잘 발생한다. 길이 여유를 남기는 편이 사후 수리보다 싸다.
- 구조화 출력 장면에서는 「글자 수」보다 「필드 수」를 우선 제약할 것. 필드 수는 검증 가능하지만 글자 수는 그렇지 않다.
- 「우선순위」를 프롬프트 템플릿의 출력 순서에 써넣을 것: 모델이 결론을 먼저 쓰고 논증을 나중에 쓰게 하면, 절단이 자연히 저가치 콘텐츠에 떨어진다.
- UI 측에도 폴백이 있어야 한다: 길이 예산이 있더라도 프런트엔드는 오버플로 처리(접기 / 더 보기)를 해서 한 번의 예산 초과로 레이아웃이 깨지지 않게 해야 한다.