Claude Code Concise 출력 스타일: 서론을 지우면 무엇이 남나

Claude Code 응답에서 제일 자주 걸러내고 싶은 게 뭘까요. 저는 “먼저 파일을 확인해 보겠습니다” 같은 예고 문장이었어요. v2.1.237에 그걸 기본으로 지워 주는 출력 스타일이 들어왔습니다.

이름은 Concise입니다. 변경 로그 한 줄은 이렇습니다.

Added built-in “Concise” output style: Claude leads with results, skips preamble/narration, works thoroughly

내장 스타일이 다섯 개가 됐다

출력 스타일은 원래 Default에 Explanatory와 Learning 둘이 붙은 구성이었습니다. 지금은 Proactive와 Concise가 더해져 Default 외에 네 개입니다.

Concise를 두고 오해하기 쉬운 부분이 하나 있습니다. 짧게 답하라는 게 작업을 덜 하라는 뜻은 아닙니다. 공식 문서는 “doing the engineering work as thoroughly as in the Default style"이라고 적어 뒀습니다. 설명을 요청하면 그때는 길게 답합니다. 그리고 짧게 만들지 않는 예외가 정해져 있습니다. 오류 보고, 보안 경고, 파괴적 작업의 확인 문구는 내용을 온전히 유지합니다. 이 예외 목록이 있다는 게 스타일 설계에서 제일 중요한 부분이라고 봅니다. 짧게 쓰다가 위험 신호를 줄여 버리면 절약이 아니라 사고니까요.

Proactive는 성격이 좀 다릅니다. 톤이 아니라 행동 방침을 바꿉니다. auto mode보다 강한 자율 실행 지침인데, 권한 모드는 그대로 둡니다. 무엇을 물어보지 않고 실행할지는 여전히 권한 모드가 결정하고, Proactive는 “판단을 사용자에게 넘기지 말고 스스로 하라"는 쪽만 건드립니다.

스타일을 바꾸는 방법이 달라졌다

여기서 한 번 헤맬 수 있습니다. /output-style 명령이 없어졌습니다. v2.1.73에서 deprecated 되고 v2.1.91에서 제거됐습니다. 지금은 두 가지 방법뿐입니다.

터미널에서는 /config를 실행해 Output style 항목에서 고릅니다. 선택 결과는 프로젝트 로컬 설정 파일에 저장됩니다.

.claude/settings.local.json

설정 파일을 직접 고쳐도 됩니다.

{
  "outputStyle": "Concise"
}

데스크톱 앱에서는 /config가 메뉴 대신 Settings 화면을 엽니다. 그래서 데스크톱에서는 위 필드를 직접 넣는 쪽이 확실합니다.

바꾼 뒤 바로 안 바뀐다고 당황하지 않아도 됩니다. 출력 스타일은 시스템 프롬프트의 일부이고, 시스템 프롬프트는 세션이 시작할 때 한 번 읽습니다. /clear를 실행하거나 새 세션을 열어야 적용됩니다.

CLAUDE.md와 어디서 갈라지나

이게 문서에서 가장 값이 나가는 대목입니다. 둘 다 “Claude가 이렇게 행동하게 만드는 장치"인데 붙는 위치가 다릅니다.

flowchart TD
    A[세션 시작] --> B[시스템 프롬프트]
    B --> C[출력 스타일 지침 추가]
    C --> D[첫 user message]
    D --> E[CLAUDE.md 내용]
    E --> F[사용자 프롬프트]

출력 스타일은 시스템 프롬프트 끝에 붙습니다. CLAUDE.md는 시스템 프롬프트 뒤에 오는 user message로 들어갑니다. 이 차이가 실무에서 세 갈래 결과를 만듭니다.

첫째, 커스텀 출력 스타일은 기본 소프트웨어 엔지니어링 지침을 빼 버립니다. 변경 범위를 어떻게 잡고, 주석을 어떻게 쓰고, 작업을 어떻게 검증하라는 내장 지침 전체가 사라집니다. 그걸 유지하려면 frontmatter에 keep-coding-instructions: true를 넣어야 합니다. 기본값이 false라는 걸 모르고 커스텀 스타일을 만들면, 톤만 바꾸려던 게 코딩 행동까지 바꿔 버립니다.

둘째, 서브에이전트에는 적용되지 않습니다. 서브에이전트는 자기 시스템 프롬프트로 돕니다. 예외가 fork인데, fork는 부모의 시스템 프롬프트를 통째로 물려받기 때문입니다. Concise로 세션을 돌리면서 서브에이전트에게 요약을 맡겼는데 서브에이전트 응답이 장황한 이유가 여기 있습니다.

셋째, 프롬프트 캐시입니다. 시스템 프롬프트가 바뀌면 캐시 접두사가 깨집니다. 토큰 절약 가이드 글에서 모델과 effort를 세션 시작 시점에 고정하라는 권고를 다뤘는데, 출력 스타일도 같은 부류의 설정입니다. 세션 도중에 바꿀 값이 아닙니다.

커스텀 스타일은 파일 하나다

내장 다섯 개로 부족하면 마크다운 파일을 만듭니다. 위치는 세 곳이고, 파일명이 스타일 이름이 됩니다. frontmatter에 name을 적으면 그쪽이 이깁니다.

~/.claude/output-styles/          # 사용자 전역
.claude/output-styles/            # 프로젝트

공식 문서 예시가 성격을 잘 보여 줍니다.

---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---

When explaining code, architecture, or data flow, start with a Mermaid diagram
showing the structure, then explain in prose.

프로젝트 스타일은 작업 디렉터리부터 저장소 루트까지의 모든 .claude/output-styles/에서 읽습니다. 같은 이름이 여러 층에 있으면 작업 디렉터리에 가까운 쪽이 이깁니다. 플러그인도 output-styles/ 디렉터리로 스타일을 배포할 수 있는데, 플러그인 전용 필드인 force-for-plugin: true를 켜면 사용자의 outputStyle 설정을 덮어쓰고 강제 적용됩니다. 플러그인을 깔았는데 응답 톤이 갑자기 변했다면 이 필드를 의심해 볼 만합니다.

frontmatter 필드는 네 개입니다.

토큰은 어느 쪽으로 움직이나

방향이 둘로 갈립니다. 입력 토큰은 스타일 지침이 시스템 프롬프트에 붙는 만큼 늘어납니다. 다만 첫 요청 이후에는 프롬프트 캐시가 이 비용을 상당히 덮습니다. 출력 토큰은 스타일이 결정합니다. Explanatory와 Learning은 설계상 응답이 길어지고, Concise는 반대로 갑니다.

그러니 Concise의 절약 효과는 출력 쪽입니다. 응답 길이가 짧아지는 만큼 출력 토큰이 줄고, 그 짧은 응답이 다음 턴의 입력으로 다시 들어가니 대화가 길어질수록 차이가 누적됩니다. 반대로 Learning 스타일로 긴 세션을 돌리면 그 반대 방향으로 누적됩니다. 제가 지금 이 글을 쓰는 세션이 Learning 스타일인데, 확실히 응답 길이가 기본보다 깁니다.

같은 주에 들어온 나머지

Concise만 있던 주가 아닙니다. v2.1.234에 실무에서 체감될 항목이 둘 붙었습니다.

사용량 한도 자동 재개입니다. claude.ai 사용량 한도가 초기화되면 세션을 자동으로 이어서 진행합니다. /config에서 켜고 끕니다. 장시간 작업을 돌려 두고 자리를 비우는 사용 방식이라면 이 항목 하나로 흐름이 달라집니다. Routines처럼 사람이 안 보는 동안 도는 작업과 결이 같습니다.

GitLab merge request 배지도 들어왔습니다. GitLab remote가 걸린 저장소에서 glab으로 인증돼 있으면 MR !N 형태로 draft, pending, green 상태를 상태줄에 표시합니다. GitHub PR 배지만 있던 자리에 GitLab이 붙은 셈입니다.

이후 버전도 흐름이 이어집니다. v2.1.238에는 커스텀, 프로젝트, 플러그인 출력 스타일이 세션 도중에 기본 목소리로 되돌아가던 버그 수정이 들어갔습니다. 출력 스타일 자체를 손보는 작업이 한 주 내내 계속됐다는 뜻입니다. v2.1.239에서는 사용량 한도 안내가 세션, 주간, 월간 중 무엇이 초기화되는지 구분해 알려 주게 바뀌었습니다.

어떤 스타일로 쓸까

정답은 작업 성격에 달렸습니다. 제 기준으로는 이렇게 갈립니다.

익숙한 코드베이스에서 반복 작업을 돌릴 때는 Concise가 맞습니다. 무엇을 할지 이미 알고 있으니 예고가 필요 없습니다. 처음 보는 코드베이스를 파악하는 중이라면 Explanatory가 낫습니다. “왜 이 파일을 골랐나"가 정보이기 때문입니다. 새 기술을 배우려고 붙었다면 Learning이 값을 합니다. TODO(human) 표시가 남으면 직접 손을 대야 하고, 그 지점이 대개 판단이 필요한 자리입니다.

Proactive는 조심스럽습니다. 권한 모드를 안 건드린다지만 “묻지 말고 판단하라"는 지침 자체가 리스크입니다. 되돌리기 쉬운 작업에만 쓰는 쪽이 안전합니다.

그리고 이 다섯 개는 서로 배타적입니다. 한 세션에 하나만 걸립니다. 작업 성격이 바뀌면 /clear하고 다시 고르는 게 정석입니다.

참고

• Claude Code CHANGELOG
• Output styles 공식 문서
• Permission modes 공식 문서