좋은 결과는 '읽기 좋게 다듬은 답'이 아니라, 처음부터 그 형태로 생성된 답에서 시작합니다. 문서에 붙여 넣을 요약이 필요하면 요약을, 시스템에 넣을 데이터가 필요하면 JSON을, UI에 들어갈 한 줄이 필요하면 한 줄을 처음부터 받는 것이 편집 비용을 가장 크게 줄입니다.
이 장에서는 출력 제어를 네 가지 축으로 나눠 다룹니다.
형식: 표/불릿/체크리스트/섹션 템플릿/코드/CSV 등 '모양'
길이: 문장 수, 항목 수, 글자·단어·토큰 등 '분량'
톤: 독자, 말투, 난이도, 금지 표현 등 '목소리'
스키마: JSON 필드, 타입, 필수 키 등 '구조 규격'
출력 제어는 "정답"보다 먼저다
출력을 고정하지 않으면, 모델은 내용뿐 아니라 '형태'도 매번 새로 결정합니다. 같은 일을 반복하는 실무에서 이 변동성은 곧 비용입니다.
예를 들어 "회의록 요약해줘"는 요약을 해 주긴 하지만,
어떤 날은 5줄, 어떤 날은 20줄
어떤 날은 핵심만, 어떤 날은 배경을 길게
어떤 날은 번호 목록, 어떤 날은 문단
이렇게 흔들리기 쉽습니다. 반대로, 형식·길이·톤을 먼저 고정하면 내용은 그 안에 담깁니다. 출력 제어는 '미관'이 아니라 명세입니다.
1) 형식 고정: "무엇을 말할지"가 아니라 "어떤 모양인지"부터
형식을 고정하는 가장 강력한 방법은 출력 템플릿을 프롬프트에 박아 넣는 것입니다. "표로 해줘"는 약하고, "이 열 이름으로, 이 순서로, 이 빈칸을 채워"가 강합니다.
섹션 템플릿(문서형 출력)
보고서·기획안·가이드처럼 문서형 결과물이 필요할 때는, 섹션 이름을 고정하면 결과의 흔들림이 크게 줄어듭니다.
프롬프트 예시
아래 형식으로만 작성하라.
한 줄 결론
핵심 근거(3개)
리스크(2개)
다음 행동(오늘/이번 주)
각 섹션의 제목은 그대로 유지하고, 다른 섹션을 추가하지 마라.
섹션을 고정할 때는 제목을 "요약/핵심/다음 액션"처럼 짧게 잡는 편이 좋습니다. 제목이 길어지면 모델이 제목 자체를 변형하거나, 제목을 설명하는 문장을 끼워 넣는 경우가 늘어납니다.
표(Table) 고정
표는 사람이 읽기에도 좋지만, 이후에 복사해 스프레드시트로 옮기거나 비교할 때 특히 강합니다.
프롬프트 예시
마크다운 표로 출력하라. 열은 3개로 고정한다:
항목 | 정의 | 예시. 행은 정확히 6행만 작성하라.
"표로 정리해줘"보다 "열 이름 + 행 수"가 들어가면 훨씬 안정적입니다.
체크리스트(검토형 출력)
체크리스트는 '내용 생성'보다 '검토/점검'에 잘 맞습니다. 특히 정책·배포·문서 검토처럼 빠짐이 치명적인 작업에서 유용합니다.
프롬프트 예시
다음 산출물을 점검하는 체크리스트를 만들라. 출력은 체크박스 형식(예:
- [ ])만 사용한다. 카테고리는정확성/일관성/용어/누락4개로 고정하고, 각 카테고리마다 5개 항목을 생성하라.
이렇게 '카테고리 수'와 '항목 수'를 동시에 못 박으면, 체크리스트가 갑자기 에세이로 변하는 일을 막을 수 있습니다.
2) 길이 고정: 단어 수보다 "측정 가능한 단위"를 고르기
길이 제어에서 가장 흔한 실수는 "짧게/간단히/자세히" 같은 상대 표현에 의존하는 것입니다. 상대 표현은 사람에게도 애매하고, 모델에게도 애매합니다. 명시적인 제약이 더 잘 작동합니다.1
또 한 가지 현실을 알아야 합니다. 모델은 워드프로세서처럼 내장된 정확한 단어·글자 카운터를 기준으로 엄격히 맞추는 도구가 아닙니다. 대신, 프롬프트의 길이 제약은 맞출 확률을 올리는 장치로 생각하는 편이 안전합니다.1
길이 제약의 우선순위
실무에서 안정적으로 먹히는 순서가 있습니다.
항목 수 고정(예: 5개 아이디어)
문장 수·문단 수 고정(예: 2문장 요약)
각 항목의 최대 길이 고정(예: 각 항목 12단어 이하)
이 순서가 좋은 이유는 "검증이 쉽기" 때문입니다. 단어 수 120을 맞추는 것보다, 5개 항목인지 확인하는 게 빠릅니다.
길이를 고정하는 문장 패턴
프롬프트 예시(문장 수 고정)
아래 글을 2문장으로만 요약하라. 1문장은 문제, 1문장은 결론으로 구성하라.
프롬프트 예시(항목 수 + 항목 길이 고정)
실행 과제 6개를 번호 목록으로 쓰고, 각 항목은 10단어 이하로 작성하라.1
길이 제약이 깨질 때는 "더 짧게"를 반복하기보다, 단위를 바꾸는 것이 효과적입니다. "200자 이내"가 잘 안 맞으면 "3문장"으로 바꿔 보세요.
3) 톤 고정: '친절하게' 대신 '독자+문장 규칙'으로 지시하기
톤은 감정의 문제가 아니라 문장 선택 규칙입니다. 톤을 고정하려면 "따뜻하게/프로답게" 같은 추상어보다, 독자와 문장 규칙을 같이 주는 게 안정적입니다.
톤을 고정하는 3요소
독자: 누구에게 쓰는가(예: 신규 입사자, CEO, 고객)
거리감: 반말/존댓말, 단정/완곡, 1인칭 여부
금지 규칙: 피해야 할 표현(예: 과장, 공격적 표현, 확정 단정)
프롬프트 예시
독자는 처음 쓰는 사용자다. 존댓말로, 과장 표현("완벽", "무조건")을 쓰지 말고, 문장 끝은
~합니다로 통일하라.
톤이 흔들리는 이유는 대부분 '감정 지시'만 있고 '문장 규칙'이 없기 때문입니다. "친절하게"라는 지시는 사람마다 해석이 다르지만, "문장 끝 통일"은 해석이 갈리지 않습니다.
4) JSON/스키마 고정: 'JSON처럼'이 아니라 '이 키와 타입으로'
JSON 출력이 필요한 순간부터는 목표가 달라집니다. 사람에게 읽히는 글이 아니라, 파싱 가능한 데이터가 목적입니다.
여기서 자주 겪는 문제는 세 가지입니다.
JSON을 달라고 했더니 마크다운 코드 블록(```json)으로 감싸서 준다
JSON은 맞지만 필요한 필드가 빠진다
타입이 틀린다(정수여야 하는데 문자열)
이 문제는 프롬프트만 잘 써도 줄어들지만, 완전히 사라지지 않기도 합니다.2
프롬프트만으로 스키마를 고정하는 방법
가능하면 스키마를 예시(샘플)로 보여주는 방식이 잘 먹힙니다.1
프롬프트 예시
아래 JSON 스키마로만 답하라. 다른 텍스트를 절대 포함하지 마라.
스키마:
{ "title": "string", "audience": "string", "key_points": ["string"], "risks": ["string"] }입력 글: "..."
이때 "다른 텍스트를 절대 포함하지 마라"를 넣어도 종종 인사말이 붙을 수 있습니다. 그럴 때는 아예 아래처럼 출력 시작/끝을 고정합니다.
출력은 반드시
{로 시작해서}로 끝나야 한다.
스키마 설계 팁: 모델이 이해하기 쉽게
스키마를 고정하는 목적은 '엄격함'이 아니라 '실수 방지'입니다. 필드 이름이 모호하면 모델도 값을 헷갈립니다. field1보다 customer_email처럼 의미가 드러나는 키가 낫습니다.3
또 값의 후보가 제한되어 있다면 문자열로 풀어 쓰게 두지 말고 enum 같은 제한을 고려해야 합니다. 가능한 값의 범위를 좁히면, 선택지가 줄어 정확도가 올라갑니다.3
5) 프롬프트만으로 부족할 때: "강제" 기능을 쓰는 구간
실무에서 JSON이 깨져서 파이프라인이 멈추는 순간부터는, "프롬프트를 더 잘 쓰자"가 아니라 출력 강제 기능을 쓰자로 전략이 바뀝니다.
(1) 응답 MIME 타입/스키마로 형식을 강제
일부 플랫폼은 응답을 application/json 같은 MIME 타입으로 강제하거나, 아예 response_schema처럼 스키마를 전달해 모델 출력 형식을 제한할 수 있습니다.2
이 방식의 핵심 장점은, 프롬프트에서 형식을 길게 설명하지 않아도 모델이 스키마에 맞춰 답하려 한다는 점입니다.2
(2) 제약 디코딩(constrained decoding) 기반 '구조화 출력'
더 강한 방식은 생성 과정에서부터 스키마를 어기는 토큰을 막는 제약 디코딩입니다. Amazon Bedrock의 structured outputs는 JSON Schema에 맞는 출력을 제약 디코딩으로 보장하는 방향을 명확히 설명합니다.3
이 구간에서 중요한 관점이 하나 있습니다.
구조가 맞는 것(유효한 JSON, 필드 존재, 타입 일치)
내용이 맞는 것(사실, 의미, 업무 규칙)
둘은 다릅니다. 구조화 출력은 구조의 신뢰도를 올리지만, 값의 진실성까지 보장하지는 않습니다. 그래서 "형식 강제 + 값 검증"을 분리해 설계하는 편이 안전합니다.
6) 실패 모드와 수습: '재시도'보다 '자기검사'를 붙이기
출력 제어가 어긋나는 패턴은 대체로 반복됩니다. 그래서 재시도를 무작정 돌리기보다, 모델이 스스로 체크하게 만드는 편이 비용이 적습니다.
가장 흔한 실패 3가지
형식이 섞임: 표를 달랬더니 중간에 문단이 끼어듦
길이 초과: 3개를 달랬더니 4~6개가 나옴
JSON 오염: 앞뒤에 설명 문장이 붙어 파싱이 깨짐2
수습 프롬프트(자기검사 포함)
프롬프트 예시
아래 규칙을 먼저 점검한 뒤, 규칙을 모두 만족하면 최종 답을 출력하라. 규칙을 하나라도 만족하지 못하면, 최종 답 대신
RETRY:로 시작하는 한 줄을 출력하고 어떤 규칙이 깨졌는지 말하라.규칙:
항목은 정확히 5개
각 항목은 12단어 이하
출력은 번호 목록만
이 방식은 "한 번에 완벽하게"보다, 깨질 때의 형태를 일정하게 만들어 후처리를 쉽게 합니다.
7) 바로 가져다 쓰는 출력 제어 템플릿
이 장의 내용을 한 번에 적용하는 '복사-붙여넣기용' 템플릿입니다.
템플릿 A: 문서 섹션 + 톤 + 길이
너는 {역할}이다. 독자: {독자}. 톤: {예: 전문적/친근/단호}. 문장 끝:
{~합니다}로 통일.아래 형식을 그대로 사용하라. 섹션을 추가/삭제하지 마라.
한 줄 결론(1문장)
핵심 포인트(정확히 3개, 각 15단어 이하)
다음 액션(정확히 2개)
입력: """{본문}"""
템플릿 B: JSON(프롬프트 기반)
아래 JSON만 출력하라. 다른 텍스트를 포함하지 마라. 출력은 반드시
{로 시작해}로 끝나야 한다.스키마:
{ "summary": "string", "items": [ {"name": "string", "priority": "P0|P1|P2", "owner": "string"} ] }items는 정확히 5개.
입력: """{본문}"""
마무리
출력 제어는 "모델이 알아서 잘 해주겠지"를 포기하는 기술입니다. 대신, 형식·길이·톤·스키마라는 네 개의 나사를 조여서 결과를 재현 가능하게 만듭니다. 프롬프트만으로도 상당히 좋아지지만, JSON이 업무의 입력으로 들어가는 순간부터는 응답 스키마/구조화 출력 같은 '강제 장치'까지 고려해야 안정적인 시스템이 됩니다.23
다음 장에서는 출력이 아니라 컨텍스트(재료)를 어떻게 제공해야 결과가 흔들리지 않는지, '배경·자료·예시·용어정의'의 기술로 넘어가겠습니다.
참고
1Control LLM Output Length and Format
2Control LLM output with response type and schema
3Structured outputs on Amazon Bedrock: Schema-compliant AI responses
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.