CLAUDE.md를 지워도 될까: Claude Code 5의 Context·Output Style·Skill을 다시 나누는 방법
CLAUDE.md를 지워도 될까: Claude Code 5의 Context·Output Style·Skill을 다시 나누는 방법
최근 Claude Code 커뮤니티에서 비슷한 시기에 세 가지 글이 주목받았다.
첫 번째는 웹페이지를 ChatGPT나 Perplexity 같은 AI 답변 서비스가 인용하기 좋은 형태로 점검하는 Claude Code Skill이다.
두 번째는 상당히 과감하다.
delete claude.md프로젝트의 CLAUDE.md를 줄이거나 아예 삭제했는데도 Claude Code의 작업 품질이 크게 떨어지지 않았다는 사용자 실험이다.
세 번째는 Claude Opus의 답변이 지나치게 길 때 CLAUDE.md에 “짧게 답하라”는 문장을 계속 추가하는 대신, /config에서 Output Style을 Concise로 바꾸는 편이 더 효과적이었다는 사용 팁이다.
각각 다른 이야기처럼 보이지만 공통점이 있다.
프로젝트 지식
응답 스타일
반복 업무 절차를 모두 CLAUDE.md에 넣는 방식이 한계에 도달하고 있다는 것이다.
앞으로 Claude Code를 잘 설정한다는 것은 거대한 CLAUDE.md를 만드는 일이 아니다.
다음처럼 책임을 분리하는 일에 가까워지고 있다.
CLAUDE.md
→ 프로젝트에서 항상 알아야 하는 사실
Output Style
→ Claude가 어떻게 말하고 보고할지
Skill
→ 특정 업무를 어떤 절차로 수행할지
현재 Prompt
→ 지금 해결해야 하는 구체적인 작업이번 글에서는 최근 커뮤니티의 세 사례를 바탕으로, CLAUDE.md를 실제로 어디까지 줄여도 되는지와 Output Style·Skill을 어떻게 분리해야 하는지 정리한다.
1. 먼저 세 이슈의 신뢰 수준부터 구분하자
이번에 언급된 세 글은 모두 Reddit 사용자 게시물이다.
즉 다음과 같은 성격이다.
공식 Benchmark
아님
Anthropic 공식 권장 설정
아님
특정 사용자의 경험과 도구
맞음따라서 다음과 같이 받아들이는 것이 적절하다.
Claude Code Skill로 AI 인용을 늘렸다는 글
웹페이지 구조를 정리한 뒤 ChatGPT나 Perplexity에서 더 잘 인용됐다는 사용자 주장이다.
하지만 인용 결과는 다음 요인에도 영향을 받는다.
검색 엔진과 크롤러의 접근 여부
사이트 신뢰도
콘텐츠의 고유성
페이지 최신성
답변 엔진의 색인 상태
질문의 종류
경쟁 페이지Skill 하나를 설치하면 AI 인용이 보장된다고 받아들이면 안 된다.
다만 “검색엔진 SEO뿐 아니라 AI 답변 엔진이 읽기 좋은 구조를 의식하는 흐름”을 보여주는 사례로는 흥미롭다.
CLAUDE.md 삭제 실험
특정 프로젝트와 작업 환경에서 CLAUDE.md를 없애도 체감 품질이 크게 떨어지지 않았다는 경험담이다.
이 결과를 다음처럼 일반화해서는 안 된다.
모든 프로젝트에서 CLAUDE.md는 필요 없다.프로젝트마다 상황이 다르다.
작은 개인 프로젝트
→ 코드 자체만 봐도 구조 파악 가능
대규모 Monorepo
→ Build 명령과 경계 설명 필요
Legacy 프로젝트
→ 코드만 보고는 알 수 없는 예외가 많음
보안 프로젝트
→ 절대 변경하면 안 되는 영역 존재정확한 질문은 “삭제할 것인가”가 아니다.
CLAUDE.md에 들어 있는 각 문장이
모든 작업에서 정말 필요한가?다.
Output Style Concise 팁
사용자는 CLAUDE.md에 간결한 응답을 요구하는 문장을 넣는 것보다 Output Style 설정을 바꾸는 편이 더 효과적이었다고 설명했다.
이것은 Claude Code의 공식 구조와도 방향이 맞는다.
Anthropic은 다음을 서로 다른 설정 수단으로 구분한다.
CLAUDE.md
→ 프로젝트 맥락과 규칙
Output Style
→ 역할, 어조, 기본 응답 형식
Skill
→ 재사용 가능한 절차
Hook
→ 반드시 실행해야 하는 자동화즉 “답변을 짧게 해달라”는 요구는 프로젝트 Architecture가 아니다.
Output Style 쪽에 두는 편이 책임상 자연스럽다.
2. CLAUDE.md가 커지는 과정
처음에는 CLAUDE.md가 짧다.
# Project
Swift 6 + SwiftUI 기반 iOS 앱이다.
## Commands
- Build: `make build`
- Unit test: `make test`
## Important
- `Generated/`는 직접 수정하지 않는다.사용하면서 문제가 하나씩 생긴다.
답변이 너무 길다.
→ 간결하게 답하라고 추가
테스트를 빼먹는다.
→ 테스트 절차 추가
PR 설명이 마음에 안 든다.
→ PR 양식 추가
웹페이지를 점검하고 싶다.
→ 콘텐츠 분석 절차 추가
코드 리뷰가 약하다.
→ 리뷰 체크리스트 추가몇 달 뒤에는 이런 파일이 된다.
CLAUDE.md
프로젝트 설명
Architecture
코딩 스타일
테스트 절차
코드 리뷰 절차
Git Workflow
릴리스 절차
보안 검토
응답 길이
말투
Markdown 형식
SEO 점검
AI 인용 점검
문서 작성법문제는 모든 내용이 세션 시작부터 Context에 들어간다는 점이다.
로그인 버그 하나를 고칠 때도 다음 규칙이 함께 따라온다.
릴리스 노트 작성법
AI 인용 최적화
블로그 문체
문서 메타데이터현재 작업에 필요하지 않은 정보다.
3. “CLAUDE.md를 삭제하라”보다 “항상 필요한 것만 남겨라”
Anthropic 공식 자료도 CLAUDE.md를 무조건 크게 만들라고 하지 않는다.
오히려 간결하게 시작하고 실제 마찰이 발생한 항목만 추가할 것을 권장한다.
좋은 CLAUDE.md는 보통 다음 질문에 답한다.
이 Repository는 무엇인가?
어떤 명령으로 Build와 Test를 실행하는가?
어떤 Architecture 경계를 지켜야 하는가?
코드만 봐서는 알기 힘든 함정이 무엇인가?
어떤 파일은 수정하면 안 되는가?반대로 다음 내용은 다른 위치가 더 적합할 수 있다.
답변을 짧게 작성해라.
→ Output Style
릴리스할 때 수행할 14단계
→ Skill
파일 저장 시 Formatter 실행
→ Hook
Security Review 전용 역할
→ Subagent
현재 Issue의 Acceptance Criteria
→ 현재 Prompt 또는 Task4. 삭제 실험을 바로 Production 프로젝트에서 하면 안 된다
CLAUDE.md가 정말 도움이 되는지 확인하고 싶다면 삭제보다 비교 실험이 낫다.
먼저 현재 파일을 보관한다.
cp CLAUDE.md CLAUDE.full.md그다음 최소 버전을 만든다.
# Project
Swift 6 + SwiftUI 기반 iOS 앱.
## Commands
- Build: `make build`
- Test: `make test`
## Architecture
- 기존 Module 경계를 유지한다.
- View에서 API Client를 직접 호출하지 않는다.
## Gotchas
- `Generated/`는 직접 수정하지 않는다.
- API 오류는 `AppErrorMapper`를 거쳐야 한다.그리고 같은 종류의 작업을 비교한다.
A
기존 긴 CLAUDE.md
B
축소한 CLAUDE.md
C
CLAUDE.md 없음측정할 항목은 다음과 같다.
Task 성공 여부
관련 없는 파일 수정 수
잘못된 Build 명령 수
테스트 누락
Architecture 위반
재질문 횟수
총 Turn 수“느낌상 비슷하다”보다 실제 작업 결과를 비교하는 편이 낫다.
5. CLAUDE.md가 없어도 잘 작동하는 프로젝트
다음 조건이라면 CLAUDE.md의 효과가 작을 수 있다.
Repository가 작다.
폴더와 타입 이름이 명확하다.
표준 Build Tool을 사용한다.
테스트 명령이 일반적이다.
기존 코드 패턴이 일관돼 있다.
특별한 금지 사항이 없다.예를 들어 작은 Swift Package라면 Claude가 다음을 직접 찾을 수 있다.
Package.swift
Sources/
Tests/
swift test이런 정보를 CLAUDE.md에서 길게 반복할 필요는 없다.
6. CLAUDE.md가 여전히 필요한 프로젝트
반대로 다음 프로젝트에서는 유용성이 크다.
대형 Monorepo
Legacy 시스템
사내 Build Tool 사용
생성 코드와 수동 코드 혼재
이름과 실제 역할이 다른 Module
잘못 수정하면 장애가 나는 공통 영역
특정 Simulator나 환경에서만 실행되는 테스트예를 들어 다음 정보는 코드만 보고 즉시 판단하기 어렵다.
## Gotchas
- `LegacyAuthService`는 이름과 달리 아직 Production에서 사용한다.
- `API.swift`는 직접 수정하지 말고 `make generate-api`를 실행한다.
- 전체 테스트보다 `make test-ios`를 먼저 실행한다.
- `SharedContainer` 변경은 두 앱 Target에 영향을 준다.이런 정보는 남겨야 한다.
7. 일반적인 개발 상식은 줄인다
다음과 같은 문장이 수십 줄 들어 있다면 줄일 수 있다.
- 변수 이름은 의미 있게 작성한다.
- 함수는 읽기 쉽게 만든다.
- 코드는 깨끗하게 유지한다.
- 복잡한 로직에는 필요한 설명을 작성한다.
- 중복을 줄인다.
- 기존 코드 스타일을 따른다.이 중 핵심은 한 줄로 줄일 수 있다.
- Match the surrounding code's naming, structure, abstractions, and comment density.또는 한국어로:
- 주변 코드의 명명, 구조, 추상화 수준과 주석 밀도를 따른다.최신 모델이 코드 자체에서 판단할 수 있는 항목까지 세세하게 지시할 필요는 줄어들고 있다.
8. 응답 스타일은 CLAUDE.md에서 빼자
다음 문장은 프로젝트 사실이 아니다.
- 항상 짧게 답한다.
- 서론 없이 바로 결론을 말한다.
- 불필요한 설명을 하지 않는다.
- 최대 5개의 Bullet만 사용한다.이런 지시는 프로젝트를 바꿔도 유지되는 사용자 선호에 가깝다.
그리고 코드 수정 품질보다 Claude의 표현 방식을 바꾼다.
따라서 Output Style로 분리하는 편이 낫다.
CLAUDE.md
→ 무엇을 알고 일해야 하는가
Output Style
→ 결과를 어떻게 표현해야 하는가9. /config에서 Concise를 먼저 확인한다
Claude Code 버전에 따라 표시되는 메뉴와 내장 Style은 달라질 수 있다.
Claude Code 안에서 다음을 실행한다.
/config설정 화면에서 output-style 또는 Output Style 항목을 확인한다.
현재 설치 버전에 Concise가 표시된다면 선택해 비교할 수 있다.
Output Style
Default
Proactive
Explanatory
Concise
...커뮤니티 사용자는 이 설정이 Opus의 장황한 설명을 줄이는 데 효과적이었다고 보고했다.
다만 이는 개인 경험이다.
다음 작업으로 직접 비교하는 것이 좋다.
이 Diff에서 실제 버그만 찾아줘.
근거 파일과 수정 필요 여부만 보고해.Default와 Concise에서 다음을 비교한다.
응답 길이
핵심 Finding 누락
중복 설명
불필요한 서론
실행 결과의 명확성10. Concise가 없으면 사용자 정의 Output Style을 만든다
Claude Code는 사용자 정의 Output Style을 지원한다.
프로젝트 또는 사용자 설정 아래에 다음과 같은 파일을 둘 수 있다.
.claude/
└── output-styles/
└── concise-engineering.md예시:
---
name: concise-engineering
description: Concise software engineering responses with evidence and verification.
keep-coding-instructions: true
---
Respond concisely.
Lead with the result or current status.
For code changes, report only:
- what changed
- affected files
- verification actually executed
- remaining risks or blockers
Do not repeat the user request.
Do not add generic explanations.
Do not claim tests passed unless they were executed.중요한 항목은 다음이다.
keep-coding-instructions: true사용자 정의 Output Style은 기본 Claude Code의 Software Engineering 지침을 대체할 수 있다.
이를 잘못 구성하면 다음과 같은 기본 행동이 약해질 수 있다.
작업 범위 제한
보안 고려
테스트와 검증
주석 작성 기준단순히 답변 길이만 줄이고 싶은 경우에는 Coding 지침을 유지하도록 구성하는 편이 안전하다.
11. Output Style은 강한 설정이다
Output Style은 단순한 마지막 Formatting 단계가 아니다.
Claude Code의 System Prompt 수준에 들어가 기본 행동에 강하게 영향을 줄 수 있다.
그래서 다음처럼 거대한 역할을 넣으면 주의해야 한다.
You are a marketing writer.
Never discuss implementation details.
Always produce persuasive copy.이 Style을 Coding 작업에도 사용하면 Claude Code의 기본 역할과 충돌할 수 있다.
작업별로 구분한다.
concise-engineering
→ 일반 개발
explanatory
→ 코드 학습과 설명
reviewer
→ 코드 리뷰
content-writer
→ 개발 문서나 블로그하나의 Output Style을 모든 업무에 사용하지 않는다.
12. “짧게 답하라”와 “작게 수정하라”는 다른 규칙이다
다음 두 문장은 비슷해 보이지만 책임이 다르다.
답변을 짧게 해라.이는 표현 방식이다.
현재 Task에 필요한 최소 파일만 수정해라.이는 작업 범위 정책이다.
따라서 위치도 다르다.
답변을 짧게
→ Output Style
수정 범위를 작게
→ CLAUDE.md 또는 RuleOutput Style을 적용했다고 작업 범위까지 자동으로 안전해지는 것은 아니다.
13. AI 인용 최적화는 Skill로 분리하기 좋은 예다
첫 번째 Reddit 글의 Claude Code Skill은 이번 구조를 설명하기 좋은 사례다.
웹페이지를 AI 답변 엔진이 읽기 좋은 형태로 점검하는 절차는 모든 Coding Task에서 필요하지 않다.
로그인 버그 수정
→ 필요 없음
Database Migration
→ 필요 없음
블로그 페이지 개선
→ 필요할 수 있음따라서 CLAUDE.md에 항상 넣는 것보다 Skill로 분리하는 것이 자연스럽다.
.claude/
└── skills/
└── ai-citation-audit/
├── SKILL.md
├── references/
│ └── evaluation-rubric.md
└── scripts/
└── inspect-page.mjs14. AI 인용 점검 Skill 예시
SKILL.md:
---
name: ai-citation-audit
description: Use when auditing a public web page for clarity and machine-readable answer extraction.
---
# AI Citation Readiness Audit
Evaluate the supplied page without promising ranking or citation.
## Check
1. The page has a clear title and primary topic.
2. Important claims are stated directly in text.
3. Headings reflect real user questions.
4. Definitions are concise and unambiguous.
5. Claims include primary sources where appropriate.
6. Tables and lists have surrounding explanatory text.
7. Author, publication date, and update date are visible.
8. Canonical URL and structured metadata are consistent.
9. Important information is not available only inside images.
10. The page does not contain unsupported promotional claims.
## Output
Return:
- confirmed strengths
- citation obstacles
- recommended changes
- evidence from the page
- claims requiring human verification
Never claim that a change guarantees citation by ChatGPT, Perplexity, or another answer engine.핵심은 마지막 문장이다.
인용 가능성을 높이는 구조 점검
≠
AI 인용 보장15. Skill은 검증 가능한 작업만 맡긴다
“AI가 좋아하는 글로 바꿔라”는 지시는 모호하다.
대신 확인 가능한 항목으로 나눈다.
제목과 본문 주제가 일치하는가?
핵심 정의가 텍스트로 존재하는가?
출처가 연결돼 있는가?
작성일과 수정일이 보이는가?
중요 내용이 이미지 안에만 있지 않은가?
FAQ가 실제 질문과 답변 구조인가?이런 항목은 Skill로 반복 실행하기 좋다.
16. 실제 검색 최적화와 혼동하지 않는다
AI 답변 엔진 인용 최적화라는 표현이 유행하고 있지만, 기존 검색 최적화의 기본을 무시해도 된다는 뜻은 아니다.
여전히 중요하다.
크롤링 가능성
robots 설정
Canonical URL
서버 응답 상태
페이지 속도
콘텐츠 품질
원본 출처
구조화된 데이터
내부 링크Claude Code Skill은 페이지를 점검하고 수정 제안을 만드는 도구다.
실제 색인 여부나 인용 결과를 통제하지는 못한다.
17. 세 이슈를 하나의 설정 구조로 정리하면
프로젝트 구조를 다음처럼 만들 수 있다.
MyProject/
├── CLAUDE.md
│
├── .claude/
│ ├── output-styles/
│ │ └── concise-engineering.md
│ │
│ ├── skills/
│ │ ├── verification/
│ │ │ └── SKILL.md
│ │ │
│ │ └── ai-citation-audit/
│ │ ├── SKILL.md
│ │ └── references/
│ │ └── evaluation-rubric.md
│ │
│ └── rules/
│ └── generated-files.md
│
└── Sources/각 파일의 책임은 다음과 같다.
CLAUDE.md
→ 프로젝트의 최소 공통 맥락
concise-engineering.md
→ 결과를 간결하게 보고
verification Skill
→ 변경 후 검증 절차
ai-citation-audit Skill
→ 웹 콘텐츠 점검 업무
generated-files Rule
→ 특정 파일 변경 금지18. 최소 CLAUDE.md 예시
# Project
Swift 6 + SwiftUI 기반 iOS 애플리케이션.
## Commands
- Build: `make build`
- Unit tests: `make test`
## Architecture
- 기존 Module 경계를 유지한다.
- UI에서 Network Client를 직접 호출하지 않는다.
## Scope
- 현재 Task에 필요한 최소 범위만 수정한다.
- 새 외부 Dependency는 추가 전에 확인한다.
## Gotchas
- `Generated/`는 직접 수정하지 않는다.
- API 오류는 `AppErrorMapper`를 거쳐야 한다.
## Verification
행동이 바뀌면 verification Skill을 사용한다.
실행하지 않은 테스트는 통과했다고 보고하지 않는다.응답 길이나 블로그 점검 절차는 들어 있지 않다.
19. 무엇을 어디에 둘지 판단하는 기준
CLAUDE.md
다음 질문에 “예”라면 후보가 된다.
거의 모든 작업에서 필요한가?
Repository의 지속적인 사실인가?
코드만 봐서는 쉽게 알 수 없는가?
잘못 판단하면 반복적으로 재작업이 생기는가?Output Style
Claude가 어떻게 말해야 하는가?
얼마나 길게 보고해야 하는가?
어떤 순서로 결과를 보여줘야 하는가?
어떤 역할이나 어조가 필요한가?Skill
특정 작업에서만 사용하는가?
순서가 있는 반복 절차인가?
Checklist나 Script가 필요한가?
팀에서 재사용할 Workflow인가?Hook
모델 판단과 관계없이 항상 실행해야 하는가?
Formatter, Linter, 보안 검사처럼 결정론적인가?
실패 시 작업을 막아야 하는가?현재 Prompt
이번 Task에만 적용되는 요구인가?
Acceptance Criteria인가?
수정 대상과 범위인가?
이번 Issue의 특수 조건인가?20. CLAUDE.md 삭제보다 좋은 정리 순서
기존 파일이 길다면 다음 순서로 정리한다.
1단계: 문장을 분류한다
Project Fact
Style
Workflow
Policy
Current Task
General Advice2단계: 일반론을 삭제한다
깨끗한 코드를 작성한다.
좋은 이름을 사용한다.
최선을 다한다.처럼 구체적인 행동을 만들지 못하는 문장은 제거 후보다.
3단계: Style을 이동한다
간결하게
친절하게
Markdown을 적게는 Output Style로 옮긴다.
4단계: 절차를 Skill로 이동한다
Release
Review
Verification
AI Citation Audit같은 작업이다.
5단계: 결정론적 작업을 Hook으로 이동한다
Formatter
Lint
금지 파일 검사6단계: 최소본으로 실제 작업을 평가한다
작업 품질이 떨어진 항목만 다시 추가한다.
21. 삭제 실험에서 놓치기 쉬운 점
CLAUDE.md를 없앤 직후에는 잘 작동하는 것처럼 보일 수 있다.
Claude가 이미 다음을 통해 프로젝트를 파악했을 수 있기 때문이다.
현재 Conversation
이전에 읽은 파일
Git Diff
Session Memory
사용자가 방금 설명한 내용정확한 비교를 하려면 새로운 Session에서 반복해야 한다.
동일 Task Fixture
새 Session
동일 Repository Revision
동일 모델과 Effort
동일 Tool Permission조건을 맞춘다.
22. Output Style 평가도 내용 누락을 함께 본다
Concise가 항상 좋은 것은 아니다.
응답이 짧아지면서 중요한 정보가 빠질 수 있다.
예를 들어 코드 수정 후 다음 보고가 필요하다.
수정 파일
실행한 Test
실패한 Test
남은 위험Concise Style이 다음처럼 끝나면 부족하다.
수정 완료했습니다.좋은 간결함은 정보가 적은 것이 아니다.
중복 설명이 없고
필수 정보의 밀도가 높은 것이다.
23. 추천하는 간결한 결과 형식
## 결과
로그인 오류 메시지 매핑을 수정했습니다.
## 변경
- `AuthErrorMapper.swift`
- `AuthErrorMapperTests.swift`
## 검증
- `make test-auth`: 통과
## 남은 사항
- UI Test는 실행하지 않음짧지만 작업 상태를 판단할 수 있다.
24. 제가 지금 Claude Code를 설정한다면
다음처럼 시작할 것 같다.
CLAUDE.md
→ 30~80줄 안팎의 프로젝트 핵심 정보
Output Style
→ concise-engineering
Skills
→ verification
→ code-review
→ release
→ ai-citation-audit
Hooks
→ formatter
→ generated-file guard
Prompt
→ 현재 Task와 Acceptance Criteria줄 수 자체가 절대 기준은 아니다.
중요한 것은 다음이다.
모든 세션에 들어갈 가치가 있는가?25. 최근 세 글이 보여주는 변화
예전 Claude Code 설정은 이런 모양이었다.
CLAUDE.md
모든 지식
모든 규칙
모든 스타일
모든 Workflow지금은 점점 다음처럼 바뀌고 있다.
CLAUDE.md
→ 최소 공통 Context
Output Style
→ 표현 방식
Skill
→ 필요할 때만 불러오는 전문 절차
Hook
→ 반드시 실행되는 자동화
Subagent
→ 독립 Context에서 수행할 전문 업무설정 파일이 늘어난 것처럼 보이지만 실제 목적은 Context를 줄이고 책임을 명확하게 만드는 것이다.
26. 마무리
CLAUDE.md를 삭제했는데 품질이 유지됐다는 커뮤니티 글의 핵심은 모든 프로젝트에서 파일을 지우라는 뜻이 아니다.
오히려 다음 질문을 던진다.
지금 CLAUDE.md에 있는 내용이
정말 프로젝트 Context인가?답변을 짧게 만드는 설정은 Output Style이 더 적합하다.
간결한 보고
→ Output Style웹페이지의 AI 인용 가능성을 점검하는 반복 절차는 Skill이 더 적합하다.
AI Citation Audit
→ Skill프로젝트의 변하지 않는 사실과 함정만 CLAUDE.md에 남긴다.
Build 명령
Architecture 경계
Generated 파일
특수한 Gotcha한 줄로 정리하면 이렇다.
CLAUDE.md를 잘 쓰는 방법은
많은 지시를 넣는 것이 아니라,
항상 필요한 정보만 남기고
나머지를 올바른 설정 계층으로 옮기는 것이다.Claude Code가 장황하다면 CLAUDE.md에 같은 문장을 반복해서 추가하기 전에 Output Style을 점검한다.
특정 업무 절차가 길다면 CLAUDE.md에 붙이지 말고 Skill로 분리한다.
그리고 CLAUDE.md를 삭제할지 고민하기 전에, 먼저 각 문장이 Context인지, Style인지, Workflow인지, Policy인지부터 구분하는 편이 낫다.
참고 자료
-
Reddit r/ClaudeAI — delete claude.md
CLAUDE.md를 줄이거나 삭제한 뒤 Claude Code의 체감 품질을 비교한 커뮤니티 사용자 실험. 공식 평가가 아니므로 프로젝트별 재현 검증이 필요하다. -
Reddit r/ClaudeAI —
/configOutput Style Concise
Opus의 장황한 응답을 줄이기 위해CLAUDE.md지시보다 Output Style 설정이 효과적이었다는 사용자 경험담. -
Reddit r/ClaudeAI — Claude Code Skill for AI citation readiness
웹페이지 구조를 AI 답변 엔진이 해석하고 인용하기 좋은 방향으로 점검하는 Community Skill 사례. 실제 인용이나 순위를 보장하는 공식 도구는 아니다. -
Anthropic — Steering Claude Code: CLAUDE.md, Skills, Hooks, Rules, Subagents and More
CLAUDE.md, Rules, Skills, Hooks, Output Styles, Subagents가 언제 Context에 들어가며 어떤 목적으로 사용해야 하는지 비교한 공식 가이드. -
Anthropic — Using CLAUDE.md Files
CLAUDE.md를 처음부터 크게 만들지 말고, 실제 프로젝트의 반복적인 마찰과 코드만으로 알기 어려운 정보를 중심으로 간결하게 유지하라는 공식 자료. -
Claude Code Docs — Output Styles
Output Style이 System Prompt에 영향을 주며, 프로젝트 규칙은CLAUDE.md, 반복 절차는 Skill, 표현 방식과 역할 변화는 Output Style에 두는 차이를 설명한 공식 문서.
핵심 참고 포인트
세 Reddit 글은 공식 검증이나 Anthropic의 공식 권고가 아니라 사용자 경험과 Community Tool이다. 따라서 “CLAUDE.md는 필요 없다”, “Skill을 설치하면 ChatGPT에 인용된다”, “Concise가 항상 더 좋다”는 결론으로 일반화하면 안 된다.
다만 Anthropic 공식 문서도 root CLAUDE.md의 모든 문장이 세션 전체 Context 비용을 사용한다고 설명하며, 항상 필요한 프로젝트 정보만 남기고 절차는 Skill, 표현 방식은 Output Style로 분리하는 방향을 안내한다.
Output Style은 Claude Code의 System Prompt에 강하게 영향을 줄 수 있다. 사용자 정의 Style을 만들 때 기본 Coding 지침을 유지하려면 keep-coding-instructions: true 같은 설정을 검토해야 하며, 변경 후에는 테스트 보고·보안·작업 범위 같은 기본 행동이 약해지지 않았는지 확인해야 한다.
AI 인용 최적화 Skill은 페이지의 명확성, 구조, 출처, 메타데이터와 기계 판독성을 점검하는 Workflow로는 활용할 수 있지만 특정 답변 엔진의 인용·노출·트래픽을 보장할 수는 없다.
