답변이 길어지면 사람은 보통 모델부터 바꾼다.
근데 실무에서는 반대가 더 많다.
모델이 멍청해서 긴 게 아니라 출력 정책이 없어서 긴 경우가 진짜 많다.
이걸 놓치면 돈만 새고, 회의록만 늘고, 팀은 계속 같은 말을 다시 읽는다.
코딩 에이전트에서 특히 그렇다.
질문 하나 던졌더니 설명 7줄, 주의사항 4줄, 배경 5줄, 예외 6줄, 그리고 맨 마지막에 “원하시면 더 자세히 설명드릴게요”가 붙는다.
이러면 좋은 답변이 아니다.
좋은 답변은 길이가 아니라 형식이 먼저 맞아야 한다.
이 글은 AI 코딩 답변이 너무 길어질 때 모델 교체보다 출력 정책을 먼저 손봐야 하는 이유를 Playground, Console, Studio 기준으로 정리한 글이다.
이 글이 필요한 사람
- AI 코딩 답변이 매번 길고 읽는 데 시간이 너무 오래 걸리는 사람
- 팀원마다 같은 질문을 해도 답변 길이가 달라서 피곤한 사람
- 비용보다 먼저 출력 피로도를 줄이고 싶은 사람
- 모델을 바꾸면 해결될 줄 알았는데 계속 길어서 답답한 사람
- Claude Code, OpenAI Playground, Google AI Studio에서 출력 규칙을 잡고 싶은 사람
Quick Answer
답변이 너무 길면 아래 순서로 고친다.
- 출력 길이 상한을 먼저 둔다
짧게가 아니라몇 줄인지를 정한다.- 출력 형식을 먼저 잠근다
- 결론, 표, 코드, 체크리스트 중 무엇이 나와야 하는지 정한다.
- 설명 모드를 분리한다
- 짧은 답 / 표준 답 / 깊은 답을 나눈다.
- 정지 조건을 준다
- 더 이상 설명하지 말아야 하는 시점을 명시한다.
- 그래도 안 되면 모델을 바꾼다
- 모델 교체는 맨 마지막이다.
즉, 길이가 문제일 때는 모델 교체가 아니라 출력 정책이 1차 수술이다.
지금 결론
- 출력 길이가 길다고 항상 더 똑똑한 건 아니다.
- 짧은 모델도 정책이 좋으면 실무 답변은 더 읽기 좋다.
- OpenAI는 verbosity와 structured output, prompt management를 같이 봐야 한다.
- Anthropic은 max_tokens와 system instructions로 출력 길이를 먼저 잡는 게 중요하다.
- Google AI Studio는 system instructions와 run settings가 정책 설정의 출발점이다.
이번에 공식 문서로 확인한 것
내가 이번 글에서 기준으로 둔 공식 신호는 세 가지다.
- OpenAI 최신 모델 문서에는
verbosity가 있고, 낮추면 더 간결한 답변을 유도할 수 있다. - Anthropic 문서에는
max_tokens가 있으며, 출력 토큰 상한을 직접 주는 구조다. - Google AI Studio quickstart에는
System Instructions와Run settings가 있고, structured output과 function calling도 켤 수 있다.
이 셋은 모두 모델을 바꾸기 전에 출력 행동을 먼저 고칠 수 있다 는 공통점을 보여준다.
아직 직접 검증 안 한 것
문서상 가능하다고 해서 우리 팀에서 그대로 먹히는 건 아니다.
- 우리 에이전트가 실제로 몇 줄에서 만족하는지
- 코드 리뷰와 설명 모드의 최적 분리가 어디인지
- 짧은 답변이 오히려 재질문을 늘리는지
- 모델별로 출력 길이 민감도가 얼마나 다른지
이건 결국 우리 워크플로 실험이 필요하다.
그렇지만 출발점은 분명하다.
모델 교체 전에 출력 정책부터.
답변이 길어지는 이유 5가지
1. 질문이 너무 넓다
질문이 넓으면 답변도 넓어진다.
이 코드 왜 이래? 보다 이 함수의 사이드 이펙트만 3줄로 설명해줘 가 훨씬 짧다.
2. 출력을 구조화하지 않았다
답변 형식을 안 정하면 모델은 안전하게 길게 말한다.
3. 길이 제한이 없다
max_tokens, verbosity, response length 상한이 없으면 모델은 친절하게 늘어난다.
4. 설명 모드가 하나뿐이다
짧은 답, 표준 답, 깊은 답을 나누지 않으면 항상 중간 이상 길이로 간다.
5. 팀 규칙이 없다
사람마다 “짧게”의 기준이 다르면 같은 에이전트도 서로 다른 길이로 말한다.
모델 교체보다 먼저 볼 출력 정책 5개
1) 길이 상한
짧게 써 달라는 말은 애매하다.
5줄 불릿 3개 표 1개 처럼 숫자로 말해야 한다.
OpenAI 최신 문서에서는 verbosity 개념으로 출력의 말투와 길이 범위를 조절할 수 있다.
Anthropic 쪽은 max_tokens로 아예 출력 상한을 걸 수 있다.
Google AI Studio에서는 System Instructions와 Run settings로 형식과 도구 사용을 같이 조절할 수 있다.
2) 형식 계약
형식이 없으면 길어지고, 형식이 있으면 압축된다.
예를 들면 이런 식이다.
- 결론 1줄
- 이유 2개
- 코드 1블록
- 예외 1개
이건 모델 친절함을 줄이는 게 아니라 읽는 사람의 피로를 줄이는 작업이다.
3) 정지 조건
좋은 답변은 언제 멈춰야 하는지도 알아야 한다.
예:
핵심 원인만 말하고 배경 설명은 하지 마예외는 1개만의심되면 질문 1개만 하고 멈춰
4) 역할 분리
설명하는 모델과 패치 제안하는 모델이 같으면 길어질 수 있다.
그래서 팀에서는 보통 이렇게 나눈다.
- 요약 모드
- 리뷰 모드
- 수정안 모드
- 디버깅 모드
5) 예시 기반 고정
추상 지시문보다 예시가 강하다.
짧게라고 적는 대신 좋은 답변 예시 1개를 넣는 게 훨씬 낫다.
표로 보면 더 빠르다
| 증상 | 흔한 원인 | 먼저 고칠 정책 | 모델 교체가 필요한 경우 |
|---|---|---|---|
| 답변이 2배 길다 | 형식이 없음 | 줄 수, bullet 수, 표 여부 지정 | 짧게 써도 핵심을 못 잡을 때 |
| 매번 설명이 덧붙는다 | 정지 조건 없음 | 예외 1개, 배경 생략 명시 |
지시를 계속 무시할 때 |
| 코드보다 설명이 많다 | 역할 분리 없음 | patch only, diff only 같은 모드 분리 |
코딩 능력 자체가 부족할 때 |
| 팀원마다 길이가 다르다 | 공통 정책 없음 | system prompt 템플릿화 | 각자 다른 모델을 쓰고 있을 때 |
| 비용도 같이 늘어난다 | output budget 없음 | max_tokens/verbosity 조절 | 여전히 품질이 부족할 때 |
실전 예시
나쁜 지시문
이 코드 짧게 설명해줘.
이건 거의 아무 것도 정하지 않은 셈이다.
좋은 지시문
아래 규칙으로만 답해줘.
– 결론 1줄
– 원인 2개
– 수정 제안 3개
– 코드 예시는 1개만
– 120단어를 넘기지 마
이렇게 해야 길이가 먼저 잡힌다.
더 좋은 지시문
역할: 팀 코드 리뷰어
목표: 문제 원인과 수정 우선순위를 짧게 알려주기
출력:
1. 핵심 결론 1줄
2. 수정 우선순위 3개
3. 한 가지 예외
4. 추가 설명 금지
이건 길이뿐 아니라 읽는 순서까지 잡아준다.
OpenAI, Anthropic, Google에서 보는 차이
OpenAI
OpenAI 문서에서는 verbosity와 structured output이 같이 보인다.
즉, 길이를 조절할 수 있고 출력 구조도 함께 잡을 수 있다.
Playground에서 prompt management까지 쓰면 버전, Eval, Publish까지 묶어서 관리할 수 있다.
Anthropic
Anthropic 쪽은 max_tokens가 아주 직설적이다.
그리고 system instructions로 출력 톤과 규칙을 미리 잡는 방식이 잘 맞는다.
Claude Code를 쓰는 경우에도 긴 답변은 종종 workflow의 문제지 모델 성능만의 문제는 아니다.
Google AI Studio
AI Studio는 실험 속도가 빠르다.
Run settings에서 structured output, function calling, code execution, grounding 같은 걸 켜고 끌 수 있다.
이 말은 곧 출력 정책 실험을 빨리 해볼 수 있다는 뜻이다.
운영 기준
기본 정책
- 짧은 답변은 5줄 이내
- 표준 답변은 bullet 3개 + 표 1개
- 긴 답변은 이유와 예외를 분리
- 코드 답변은 설명보다 patch를 우선
팀 정책
- 답변 길이는 개인 취향이 아니라 팀 표준으로 정한다
- 프롬프트 파일에
brief / normal / deep를 분리한다 - 테스트 세트에 길이 기준을 넣는다
- 모델이 아니라 정책을 먼저 수정한다
운영 체크
- 같은 질문에 답변 길이가 일정한가
- 불필요한 배경 설명이 줄었는가
- 재질문이 줄었는가
- 코드보다 말이 많지 않은가
실수 TOP
1. 짧게만 쓰는 것
짧게는 너무 애매하다. 숫자가 있어야 한다.
2. 모델부터 바꾸는 것
대부분은 모델 문제가 아니다. 정책이 없는 게 문제다.
3. 출력 형식 없이 대화만 하는 것
대화는 재미있지만 운영은 재현성이 중요하다.
4. 긴 답변을 허용한 뒤 불평하는 것
길어지는 건 모델의 친절일 수 있다. 근데 팀 입장에선 낭비다.
5. 팀 표준을 안 만드는 것
한 사람은 짧게, 다른 사람은 길게 쓰면 결국 에이전트는 모든 사람의 타협점이 된다.
FAQ
Q. 모델을 바꾸면 더 짧아지지 않나?
가끔 그렇다. 근데 길이 문제는 보통 모델보다 정책이 먼저다.
Q. max_tokens를 무조건 낮추면 되나?
아니다. 너무 낮추면 핵심이 잘릴 수 있다. 짧은 모드와 표준 모드를 분리하는 게 낫다.
Q. Anthropic / OpenAI / Google 중 어디가 제일 짧게 잘 나오나?
모델 차이도 있지만 같은 모델이어도 출력 정책이 더 큰 차이를 만든다.
Q. 팀 표준은 어떻게 시작하나?
짧은 답변용 system prompt 하나, 표준 답변용 하나, 깊은 분석용 하나를 먼저 만든다.
Q. 언제 모델을 바꿔야 하나?
출력 정책을 이미 잘 잡았는데도 사실관계, 추론, 코드 수정 품질이 계속 부족할 때다.
다음에 읽을 글
- 유료 AI 구독 전에 Playground와 Console에서 먼저 확인할 5가지 2026 — 팀 도입 전 감 잡는 법
- Claude Code 팀 예산 짜는 법 2026 — seat·token·실험비를 따로 잡아야 덜 터진다
- Claude Code에서 돈 새는 패턴 2026 — 비싼 건 모델보다 workflow일 때가 많다