Claude Code 말투 설정 — output style로 압축 문체가 새는 걸 막았습니다

Claude Code 에서 받는 답변에는 늘 줄표와 이모지와 마크다운 헤딩이 붙어 있었습니다. 읽지 못할 정도는 아니었는데, 되물어야 하는 일이 잦았습니다. 한 문장 안에 사실과 원인과 단서와 판단이 경계 없이 들어 있어서, 어디를 믿고 어디를 의심해야 할지 제가 고를 수가 없었습니다. 그 문체가 어디서 왔는지 따져 보니 뜻밖에도 제가 직접 쓴 CLAUDE.md 였습니다.

Claude Code 에는 이 말투를 설정 파일로 갈아끼우는 기능이 있습니다. output style 입니다. 이 글은 그 기능이 시스템 프롬프트의 어느 층을 건드리는지 설치된 바이너리에서 실측으로 확인하고, 제가 실제로 만들어 적용한 사례를 함께 적은 기록입니다. 환경은 macOS, Claude Code 2.1.266 입니다.

증상: 되물음 38건 중 24건이 같은 원인이었습니다

막연한 불편으로 두지 않으려고 한번 세어 보기로 했습니다. 최근 답변 60편과, 대조군으로 다른 CLI 코딩 에이전트(Codex)의 답변 107편을 나란히 놓고 몇 가지 표지를 기계적으로 셌습니다. 표본은 제 답변 539문장, 대조군 407문장이었습니다.

먼저 기호 밀도입니다. 1,000자당 등장 횟수인데, 제 글로벌 CLAUDE.md 를 함께 놓고 보면 어디서 왔는지가 그대로 드러납니다.

표지 (1,000자당)	글로벌 CLAUDE.md	내 답변	대조군 답변
줄표(—)	4.54	2.67	0.11
이모지	1.59	0.91	0.00
백틱	16.2	19.4	2.7

세 표지 모두 대조군이 아니라 제 상주 문서 쪽에 붙어 있습니다. 문장 단위로 봐도 결과는 같았습니다.

지표	내 답변	대조군
문장 중간에 줄표가 들어간 문장	22.4%	0.25%
한 문장에 강조 장치가 두 겹 이상	25.8%	2.2%
코드 식별자를 주어로 세운 문장 (100문장당)	8.91	0.74
마크다운 헤딩 사용	60편에 54회	107편에 0회
자기정정을 별도 절로 세운 글	8편	0편

줄표만 91배 차이인데, 답변 길이가 더 길다는 점을 보정해도 20배가 남았습니다. 같은 기간 제가 되물은 38건을 분류해 보니 24건이 갈래 둘을 한 단어로 덮은 문장에서 나왔습니다. 7일간 자기정정은 713건이었습니다. 취향의 문제라고 생각했던 것이 실제로는 되물음을 만들어 내는 비용이었다는 생각이 들었습니다.

원인: 규칙을 CLAUDE.md 에 적으면 옆에 있는 본문이 이깁니다

CLAUDE.md 는 매 요청마다 시스템 프롬프트에 통째로 들어갑니다. 상주하는 파일이라 토큰 예산이 걸려 있고, 그래서 저는 그 파일을 일부러 압축해 왔습니다. 줄표로 절을 매달고, 심각도를 이모지로 찍고, 표로 병렬 항목을 눌러 담았습니다. 그 압축은 그 파일에서는 옳은 선택입니다. 컨텍스트가 무엇이고 왜 예산이 되는지는 컨텍스트 윈도우를 다룬 글에 적어 두었습니다.

문제는 그다음입니다. 매 요청마다 들어가는 압축된 문서는 규칙으로만 읽히지 않고 문체의 본보기로도 읽힙니다. 그래서 같은 파일에 "답변은 또박또박 쓸 것" 이라고 한 줄 적어 봐야, 바로 아래 이어지는 수만 자의 압축 본문이 훨씬 강한 예시로 작동합니다. 규칙 한 줄과 본보기 수만 자가 붙어 있으면 이기는 쪽은 정해져 있습니다.

결국 고쳐야 할 것은 규칙의 내용이 아니라 규칙을 놓는 층이었습니다. 압축 본문과 같은 파일에 있는 한, 문장을 아무리 다듬어도 같은 자리에서 집니다. 이 지점에서 output style 이 필요해졌습니다.

output style 은 시스템 프롬프트의 말투 절을 갈아끼웁니다

output style 은 Claude Code 시스템 프롬프트에서 말투를 담당하는 절을 통째로 다른 내용으로 바꾸는 기능입니다. 사용자 규칙 파일에 문장을 더하는 것과는 층이 다릅니다.

기본값의 말투 지침은 네 문장이 전부입니다

기본값이 실제로 무엇을 지시하는지 궁금해서, 설치된 바이너리(2.1.266)에서 해당 문자열을 직접 뽑아 봤습니다. # Tone and style 절은 네 문장이었습니다.

# Tone and style

- Only use emojis if the user explicitly requests it.
  Avoid using emojis in all communication unless asked.
- Your responses should be short and concise.
- When referencing specific functions or pieces of code include the pattern
  file_path:line_number to allow the user to easily navigate to the source code location.
- Do not use a colon before tool calls. Your tool calls may not be shown directly
  in the output, so text like "Let me read the file:" followed by a read tool call
  should just be "Let me read the file." with a period.

이모지, 길이, 코드 좌표 표기, 콜론. 네 가지입니다. 한국어 문체에 대해서는 한마디도 하지 않습니다. 문장 하나에 사실 하나를 담으라거나, 정정을 본문에 녹이라거나, 확실하지 않은 것을 어떻게 표시하라는 지시는 애초에 없었습니다. 제 압축 문체가 그 빈자리를 메우고 있었던 셈입니다.

내장 스타일은 다섯 가지입니다

직접 만들기 전에 준비된 것부터 확인했습니다. 같은 바이너리에서 뽑은 내장 스타일 목록입니다.

스타일	설명
default	위 네 문장이 그대로 들어가는 기본값
Proactive	즉시 실행하고 중단을 최소화하며 계획보다 행동을 앞세움
Concise	결과부터 말하고 서론과 중계를 생략함
Explanatory	구현 선택과 코드베이스 패턴을 설명함
Learning	중간에 멈춰 사용자에게 작은 코드를 직접 써 보게 함

넷 다 영어권 기준의 행동 방식이고, 제가 겪은 한국어 문체 문제는 어느 쪽도 다루지 않았습니다. 그래서 직접 만들었습니다.

파일 하나로 만듭니다 — frontmatter 세 필드

스타일은 마크다운 파일 하나입니다. 사용자 레벨이라면 ~/.claude/output-styles/ 에 두면 됩니다.

mkdir -p ~/.claude/output-styles
cat > ~/.claude/output-styles/my-style.md <<'EOF'
---
name: 내 스타일
description: 결론 먼저, 한 문장에 사실 하나
keep-coding-instructions: true
---

한 문장에 사실 하나만 담고 끝냅니다.
판단을 묻는 질문에는 첫 문장에서 예 또는 아니요로 답합니다.
EOF

frontmatter 세 필드가 각각 무엇을 하는지도 바이너리에 정의가 그대로 들어 있었습니다.

필드	역할
name	/config 의 Output style 선택기와 설정에 표시되는 이름. 생략하면 파일명
description	/config 선택기에 함께 보이는 한 줄 설명
keep-coding-instructions	true 면 기본 코딩 지침이 이 스타일과 함께 시스템 프롬프트에 남음

세 번째가 중요합니다. 이 값을 켜지 않으면 기본 코딩 지침이 빠집니다. 말투만 바꾸려고 스타일을 만들었는데 코딩 관련 지시까지 함께 사라지면 원하지 않은 부작용이 생깁니다. 저는 true 로 두었습니다.

활성화는 두 가지입니다. /config 에서 Output style 을 고르거나, 설정 파일에 직접 적습니다. 저는 후자를 택했습니다.

{
  "outputStyle": "또박또박 한국어"
}

이 키가 없으면 내장 default 로 동작합니다. 참고로 ~/.claude/settings.json 은 제 하네스 레포에서 git 추적 제외 대상이라, 이 변경은 커밋 이력에 남지 않았습니다. 나중에 언제 무엇을 바꿨는지 확인하려면 변경 직전 백업을 따로 남겨 두는 편이 낫다는 생각이 들었습니다. 설정 소스 자체는 policy·user·project·local·flag 다섯 갈래로 나뉘어 있어 프로젝트 단위 지정도 가능해 보입니다. 다만 저는 사용자 레벨만 시험했고 프로젝트 레벨은 직접 확인하지 않았습니다.

제가 만든 스타일: 규칙 일곱 절

파일은 67줄이고 본문은 일곱 절입니다. 취향을 적은 것이 아니라, 앞에서 센 표지를 하나씩 막는 체크리스트로 썼습니다.

절	핵심 규칙
문장	한 문장에 사실 하나. 줄표로 절을 계속 매달지 않기. 합쇼체 통일
기호	이모지와 심각도 아이콘 대신 말로. 답변을 헤딩으로 조판하지 않기. 강조 장치는 한 문장에 하나
구조	기본값은 산문 서너 문장. 표는 병렬 항목 셋 이상일 때만, 앞뒤에 결론과 해석 문장 필수
확실하지 않은 것	관측 다음 문장에 "그것이 뜻하지 않는 것"을 붙이기. 근거 없으면 "추론입니다"를 먼저
되물음을 부르는 세 가지	갈래 둘을 상위어로 덮지 않기. 규약을 한 단어 라벨로 압축하지 않기. 내가 지은 압축어를 정의 없이 주어로 쓰지 않기
앞말을 정정할 때	별도 절을 세우지 말고 맞는 값을 먼저 문장으로 세운 뒤 앞말이 틀렸다는 사실을 붙이기
적용 범위	코드·명령어·diff·JSON, 그리고 CLAUDE.md·MEMORY.md·에이전트 정의는 예외

다섯 번째 절이 되물음 24건에 직접 대응하고, 마지막 절이 이 스타일의 안전장치입니다. 같은 규칙을 상주 문서에까지 적용하면 그 파일의 토큰 예산이 깨집니다. 압축이 목적인 파일과 풀어쓰기가 목적인 답변을 한 규칙으로 묶지 않으려고 예외를 명시했습니다.

켠 뒤 실제로 달라진 것과, 아직 확인하지 못한 것

적용 후 세션의 시스템 프롬프트를 직접 확인해 보니 # Tone and style 절이 사라지고 그 자리에 # Output Style: 또박또박 한국어 절이 들어와 있었습니다. 기본 말투 지침을 보태는 것이 아니라 대체한다는 뜻입니다. keep-coding-instructions 를 켜 둔 덕분에 나머지 작업 지침은 그대로 남아 있었습니다.

다만 적용 후 수치를 다시 재지는 않았습니다. 앞의 표는 전부 적용 전 값이고, 줄표 22.4%가 실제로 얼마나 내려갔는지는 아직 모릅니다. 같은 방식으로 대화 로그를 다시 세어 확인하는 절차는 자가 진단 후속 글에 적어 둔 방법 그대로 쓸 수 있어서, 며칠 뒤에 다시 재 볼 생각입니다. 처방을 적어 두고 재측정하지 않으면 그 처방이 들었는지는 영영 모른 채로 남습니다.

트레이드오프 — 예산을 옮긴 것이지 없앤 것이 아닙니다

솔직히 말하면 이 방법에도 값이 붙습니다. 스타일 본문 5.7KB 가 매 요청마다 시스템 프롬프트에 상주합니다. CLAUDE.md 를 압축했던 이유가 바로 그 예산이었으니, 저는 예산 문제를 없앤 것이 아니라 옆칸으로 옮긴 셈입니다. 규칙을 늘릴수록 이 비용도 같이 늘어납니다.

두 번째로, 스타일은 규칙 목록이지 강제 장치가 아닙니다. 매 답변에서 일곱 절이 다 지켜진다는 보장은 없고, 규칙이 많아질수록 지켜지지 않을 여지도 커집니다. 세 번째로 도구가 형식을 정해 둔 산출물에는 적용되지 않습니다. 그래서 저는 적용 범위 절을 아예 파일 안에 못박아 두었습니다.

같은 목적을 이루는 다른 방법들과 비교하면 이렇습니다.

방법	지속성	한계
매번 프롬프트로 지시	그 턴만	세션이 바뀌면 사라지고 매번 다시 써야 함
CLAUDE.md 에 규칙 추가	영구	같은 파일의 압축 본문이 더 강한 본보기로 작동
output style	영구	매 요청 컨텍스트 비용. 코딩 지침 유지 여부를 직접 챙겨야 함

즉 output style 의 값어치는 새 기능이 생긴다는 데 있지 않고, 규칙을 압축 본문과 다른 층에 놓을 수 있다는 데 있습니다.

남는 생각

돌이켜 생각해보면 이 일에서 제가 배운 것은 문체 규칙 자체가 아니었습니다. 규칙을 지키게 하려면 규칙의 문장을 다듬는 것보다 그 규칙이 어느 층에 놓이는지를 먼저 봐야 한다는 쪽에 가깝습니다. 압축된 본보기 옆에 규칙 한 줄을 적어 두고 왜 안 지켜지는지 묻는 것은, 애초에 이길 수 없는 자리에 규칙을 놓아둔 것이었습니다. 규칙이 이기는 게 아니라 옆에 있는 예시가 이깁니다.

한 레포에만 있던 개발 규율을 글로벌 층으로 끄집어냈던 지난 기록과도 결이 같습니다. 그때도 고친 것은 규칙의 내용이 아니라 규칙이 사는 자리였습니다. 도구를 오래 쓰다 보면 결국 무엇을 적을까보다 어디에 적을까를 더 자주 고민하게 된다는 생각이 들었습니다.