Feature/korean docs (#417)

* added Korean Readme

* korean agents.md

* korean command.md

* korean flags.md

* korean mcp-servers.md

* korean modes.md

* korean session management.md

---------

Signed-off-by: David-Dohyun-Im <143546517+David-Dohyun-Im@users.noreply.github.com>
This commit is contained in:
David-Dohyun-Im 2025-10-08 01:27:21 +09:00 committed by GitHub
parent 0b4924b36e
commit abedc43346
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 2813 additions and 1 deletions

View File

@ -0,0 +1,865 @@
# SuperClaude 에이전트 가이드 🤖
SuperClaude는 Claude Code가 전문 지식을 위해 호출할 수 있는 15개의 도메인 전문 에이전트를 제공합니다.
## 🧪 에이전트 활성화 테스트
이 가이드를 사용하기 전에 에이전트 선택이 작동하는지 확인하세요:
```bash
# 수동 에이전트 호출 테스트
@agent-python-expert "데코레이터 설명해줘"
# 예상 동작: Python 전문가가 자세한 설명으로 응답
# 보안 에이전트 자동 활성화 테스트
/sc:implement "JWT 인증"
# 예상 동작: 보안 엔지니어가 자동으로 활성화되어야 함
# 프론트엔드 에이전트 자동 활성화 테스트
/sc:implement "반응형 네비게이션 컴포넌트"
# 예상 동작: 프론트엔드 아키텍트 + Magic MCP가 활성화되어야 함
# 체계적 분석 테스트
/sc:troubleshoot "느린 API 성능"
# 예상 동작: 근본 원인 분석가 + 성능 엔지니어 활성화
# 수동 및 자동 결합 테스트
/sc:analyze src/
@agent-refactoring-expert "개선 사항 제안해줘"
# 예상 동작: 분석 후 리팩토링 제안
```
**테스트가 실패하면**: `~/.claude/agents/`에 에이전트 파일이 있는지 확인하거나 Claude Code 세션을 재시작하세요
## 핵심 개념
### SuperClaude 에이전트란?
**에이전트**는 Claude Code의 동작을 수정하는 컨텍스트 지시문으로 구현된 전문 AI 도메인 전문가입니다. 각 에이전트는 `SuperClaude/Agents/` 디렉토리에 있는 신중하게 작성된 `.md` 파일로, 도메인별 전문 지식, 행동 패턴, 문제 해결 접근 방식을 포함합니다.
**중요**: 에이전트는 별도의 AI 모델이나 소프트웨어가 아닙니다 - Claude Code가 읽어 전문화된 행동을 채택하는 컨텍스트 구성입니다.
### 에이전트 사용 방법 2가지
#### 1. @agent- 접두사를 사용한 수동 호출
```bash
# 특정 에이전트를 직접 호출
@agent-security "인증 구현 검토해줘"
@agent-frontend "반응형 네비게이션 디자인해줘"
@agent-architect "마이크로서비스 마이그레이션 계획해줘"
```
#### 2. 자동 활성화 (행동 라우팅)
"자동 활성화"는 Claude Code가 요청의 키워드와 패턴에 따라 적절한 컨텍스트를 참여시키기 위해 행동 지침을 읽는 것을 의미합니다. SuperClaude는 Claude가 가장 적절한 전문가에게 라우팅하기 위해 따르는 행동 가이드라인을 제공합니다.
> **📝 에이전트 "자동 활성화" 작동 방식**:
> 에이전트 활성화는 자동 시스템 로직이 아닙니다 - 컨텍스트 파일의 행동 지침입니다.
> 문서에서 에이전트가 "자동 활성화"된다고 할 때, Claude Code가 요청의 키워드와 패턴을 기반으로
> 특정 도메인 전문 지식을 참여시키는 지침을 읽는다는 의미입니다. 이는 기본 메커니즘에 대해
> 투명하면서도 지능적인 라우팅 경험을 만듭니다.
```bash
# 이러한 명령은 관련 에이전트를 자동 활성화합니다
/sc:implement "JWT 인증" # → security-engineer 자동 활성화
/sc:design "React 대시보드" # → frontend-architect 자동 활성화
/sc:troubleshoot "메모리 누수" # → performance-engineer 자동 활성화
```
**MCP 서버**는 Context7(문서), Sequential(분석), Magic(UI), Playwright(테스팅), Morphllm(코드 변환)과 같은 전문 도구를 통해 향상된 기능을 제공합니다.
**도메인 전문가**는 일반적인 접근 방식보다 더 깊고 정확한 솔루션을 제공하기 위해 좁은 전문 영역에 집중합니다.
### 에이전트 선택 규칙
**우선순위 계층:**
1. **수동 재정의** - @agent-[name]이 자동 활성화보다 우선합니다
2. **키워드** - 직접적인 도메인 용어가 주요 에이전트를 트리거합니다
3. **파일 유형** - 확장자가 언어/프레임워크 전문가를 활성화합니다
4. **복잡성** - 다단계 작업이 조정 에이전트를 참여시킵니다
5. **컨텍스트** - 관련 개념이 보완 에이전트를 트리거합니다
**충돌 해결:**
- 수동 호출 → 지정된 에이전트가 우선합니다
- 여러 일치 → 다중 에이전트 조정
- 불명확한 컨텍스트 → 요구사항 분석가 활성화
- 높은 복잡성 → 시스템 아키텍트 감독
- 품질 우려 → 자동 QA 에이전트 포함
**선택 결정 트리:**
```
작업 분석 →
├─ 수동 @agent-? → 지정된 에이전트 사용
├─ 단일 도메인? → 주요 에이전트 활성화
├─ 다중 도메인? → 전문 에이전트 조정
├─ 복잡한 시스템? → system-architect 감독 추가
├─ 품질 중요? → security + performance + quality 에이전트 포함
└─ 학습 중심? → learning-guide + technical-writer 추가
```
## 빠른 시작 예제
### 수동 에이전트 호출
```bash
# @agent- 접두사로 특정 에이전트를 명시적으로 호출
@agent-python-expert "이 데이터 처리 파이프라인 최적화해줘"
@agent-quality-engineer "포괄적인 테스트 스위트 만들어줘"
@agent-technical-writer "이 API를 예제와 함께 문서화해줘"
@agent-socratic-mentor "이 디자인 패턴 설명해줘"
```
### 자동 에이전트 조정
```bash
# 자동 활성화를 트리거하는 명령
/sc:implement "속도 제한이 있는 JWT 인증"
# → 트리거: security-engineer + backend-architect + quality-engineer
/sc:design "접근 가능한 React 대시보드와 문서"
# → 트리거: frontend-architect + learning-guide + technical-writer
/sc:troubleshoot "간헐적 실패가 있는 느린 배포 파이프라인"
# → 트리거: devops-architect + performance-engineer + root-cause-analyst
/sc:audit "결제 처리 보안 취약점"
# → 트리거: security-engineer + quality-engineer + refactoring-expert
```
### 수동 및 자동 접근 방식 결합
```bash
# 명령으로 시작 (자동 활성화)
/sc:implement "사용자 프로필 시스템"
# 그런 다음 전문가 검토를 명시적으로 추가
@agent-security "프로필 시스템의 OWASP 규정 준수 검토해줘"
@agent-performance-engineer "데이터베이스 쿼리 최적화해줘"
```
---
## SuperClaude 에이전트 팀 👥
### 아키텍처 및 시스템 설계 에이전트 🏗️
### system-architect 🏢
**전문 분야**: 확장성과 서비스 아키텍처에 중점을 둔 대규모 분산 시스템 설계
**자동 활성화**:
- 키워드: "architecture", "microservices", "scalability", "system design", "distributed"
- 컨텍스트: 다중 서비스 시스템, 아키텍처 결정, 기술 선택
- 복잡성: >5개 컴포넌트 또는 교차 도메인 통합 요구사항
**역량**:
- 서비스 경계 정의 및 마이크로서비스 분해
- 기술 스택 선택 및 통합 전략
- 확장성 계획 및 성능 아키텍처
- 이벤트 기반 아키텍처 및 메시징 패턴
- 데이터 흐름 설계 및 시스템 통합
**예제**:
1. **전자상거래 플랫폼**: 이벤트 소싱을 사용한 사용자, 제품, 결제, 알림 서비스를 위한 마이크로서비스 설계
2. **실시간 분석**: 스트림 처리 및 시계열 저장소를 갖춘 고처리량 데이터 수집 아키텍처
3. **다중 테넌트 SaaS**: 테넌트 격리, 공유 인프라, 수평 확장 전략을 갖춘 시스템 설계
### 성공 기준
- [ ] 응답에서 시스템 수준 사고가 명확함
- [ ] 서비스 경계 및 통합 패턴 언급
- [ ] 확장성 및 신뢰성 고려사항 포함
- [ ] 기술 스택 권장사항 제공
**검증:** `/sc:design "마이크로서비스 플랫폼"`은 system-architect를 활성화해야 함
**테스트:** 출력에 서비스 분해 및 통합 패턴이 포함되어야 함
**확인:** 인프라 문제에 대해 devops-architect와 조정해야 함
**최적의 협업 대상**: devops-architect(인프라), performance-engineer(최적화), security-engineer(규정 준수)
---
### backend-architect ⚙️
**전문 분야**: API 신뢰성과 데이터 무결성을 강조하는 견고한 서버 측 시스템 설계
**자동 활성화**:
- 키워드: "API", "backend", "server", "database", "REST", "GraphQL", "endpoint"
- 파일 유형: API 스펙, 서버 설정, 데이터베이스 스키마
- 컨텍스트: 서버 측 로직, 데이터 지속성, API 개발
**역량**:
- RESTful 및 GraphQL API 아키텍처 및 디자인 패턴
- 데이터베이스 스키마 설계 및 쿼리 최적화 전략
- 인증, 권한 부여 및 보안 구현
- 오류 처리, 로깅 및 모니터링 통합
- 캐싱 전략 및 성능 최적화
**예제**:
1. **사용자 관리 API**: JWT 인증, 역할 기반 액세스 제어 및 속도 제한
2. **결제 처리**: PCI 규정 준수 트랜잭션 처리, 멱등성 및 감사 추적
3. **콘텐츠 관리**: 캐싱, 페이지네이션, 실시간 알림을 갖춘 RESTful API
**최적의 협업 대상**: security-engineer(인증/보안), performance-engineer(최적화), quality-engineer(테스팅)
---
### frontend-architect 🎨
**전문 분야**: 접근성과 사용자 경험에 중점을 둔 현대적인 웹 애플리케이션 아키텍처
**자동 활성화**:
- 키워드: "UI", "frontend", "React", "Vue", "Angular", "component", "accessibility", "responsive"
- 파일 유형: .jsx, .vue, .ts(프론트엔드), .css, .scss
- 컨텍스트: 사용자 인터페이스 개발, 컴포넌트 설계, 클라이언트 측 아키텍처
**역량**:
- 컴포넌트 아키텍처 및 디자인 시스템 구현
- 상태 관리 패턴(Redux, Zustand, Pinia)
- 접근성 규정 준수(WCAG 2.1) 및 포용적 디자인
- 성능 최적화 및 번들 분석
- 프로그레시브 웹 앱 및 모바일 우선 개발
**예제**:
1. **대시보드 인터페이스**: 실시간 업데이트 및 반응형 그리드 레이아웃을 갖춘 접근 가능한 데이터 시각화
2. **폼 시스템**: 검증, 오류 처리, 접근성 기능을 갖춘 복잡한 다단계 폼
3. **디자인 시스템**: 일관된 스타일링 및 상호작용 패턴을 갖춘 재사용 가능한 컴포넌트 라이브러리
**최적의 협업 대상**: learning-guide(사용자 안내), performance-engineer(최적화), quality-engineer(테스팅)
---
### devops-architect 🚀
**전문 분야**: 안정적인 소프트웨어 전달을 위한 인프라 자동화 및 배포 파이프라인 설계
**자동 활성화**:
- 키워드: "deploy", "CI/CD", "Docker", "Kubernetes", "infrastructure", "monitoring", "pipeline"
- 파일 유형: Dockerfile, docker-compose.yml, k8s 매니페스트, CI 설정
- 컨텍스트: 배포 프로세스, 인프라 관리, 자동화
**역량**:
- 자동화된 테스팅 및 배포를 갖춘 CI/CD 파이프라인 설계
- 컨테이너 오케스트레이션 및 Kubernetes 클러스터 관리
- Terraform 및 클라우드 플랫폼을 사용한 Infrastructure as Code
- 메트릭, 로그, 추적을 위한 모니터링, 로깅, 관찰성 스택 구현
- 보안 스캔 및 규정 준수 자동화
**예제**:
1. **마이크로서비스 배포**: 서비스 메시, 자동 확장, blue-green 릴리스를 갖춘 Kubernetes 배포
2. **다중 환경 파이프라인**: 자동화된 테스팅, 보안 스캔, 단계별 배포를 갖춘 GitOps 워크플로우
3. **모니터링 스택**: 메트릭, 로그, 추적, 알림 시스템을 갖춘 포괄적인 관찰성
**최적의 협업 대상**: system-architect(인프라 계획), security-engineer(규정 준수), performance-engineer(모니터링)
---
### deep-research-agent 🔬
**전문 분야**: 적응형 전략과 다중 홉 추론을 사용한 포괄적인 연구
**자동 활성화**:
- 키워드: "research", "investigate", "discover", "explore", "find out", "search for", "latest", "current"
- 명령어: `/sc:research`가 자동으로 이 에이전트를 활성화
- 컨텍스트: 철저한 조사가 필요한 복잡한 쿼리, 최신 정보 필요, 사실 확인
- 복잡성: 여러 도메인에 걸쳐 있거나 반복적 탐색이 필요한 질문
**역량**:
- **적응형 계획 전략**: Planning(직접), Intent(먼저 명확화), Unified(협업)
- **다중 홉 추론**: 최대 5단계 - 엔티티 확장, 시간적 진행, 개념적 심화, 인과 관계 체인
- **자기 성찰 메커니즘**: 각 주요 단계 후 진행 상황 평가 및 재계획 트리거
- **증거 관리**: 명확한 인용, 관련성 점수, 불확실성 인정
- **도구 오케스트레이션**: Tavily(검색), Playwright(JavaScript 콘텐츠), Sequential(추론)을 사용한 병렬 우선 실행
- **학습 통합**: Serena 메모리를 통한 패턴 인식 및 전략 재사용
**연구 깊이 수준**:
- **Quick**: 기본 검색, 1홉, 요약 출력
- **Standard**: 확장 검색, 2-3홉, 구조화된 보고서(기본값)
- **Deep**: 포괄적 검색, 3-4홉, 상세 분석
- **Exhaustive**: 최대 깊이, 5홉, 완전한 조사
**예제**:
1. **기술 연구**: `/sc:research "최신 React Server Components 패턴"` → 구현 예제를 포함한 포괄적인 기술 연구
2. **시장 분석**: `/sc:research "2024년 AI 코딩 어시스턴트 현황" --strategy unified` → 사용자 입력을 포함한 협업 분석
3. **학술 조사**: `/sc:research "양자 컴퓨팅 돌파구" --depth exhaustive` → 증거 체인을 포함한 포괄적인 문헌 검토
**워크플로우 패턴** (6단계):
1. **이해** (5-10%): 쿼리 복잡성 평가
2. **계획** (10-15%): 전략 선택 및 병렬 기회 식별
3. **TodoWrite** (5%): 적응형 작업 계층 구조 생성(3-15개 작업)
4. **실행** (50-60%): 병렬 검색 및 추출
5. **추적** (지속적): 진행 상황 및 신뢰도 모니터링
6. **검증** (10-15%): 증거 체인 확인
**출력**: 보고서는 `claudedocs/research_[topic]_[timestamp].md`에 저장됨
**최적의 협업 대상**: system-architect(기술 연구), learning-guide(교육 연구), requirements-analyst(시장 연구)
### 품질 및 분석 에이전트 🔍
### security-engineer 🔒
**전문 분야**: 위협 모델링 및 취약점 예방에 중점을 둔 애플리케이션 보안 아키텍처
**자동 활성화**:
- 키워드: "security", "auth", "authentication", "vulnerability", "encryption", "compliance", "OWASP"
- 컨텍스트: 보안 검토, 인증 흐름, 데이터 보호 요구사항
- 위험 지표: 결제 처리, 사용자 데이터, API 액세스, 규정 준수 필요
**역량**:
- 위협 모델링 및 공격 표면 분석
- 안전한 인증 및 권한 부여 설계(OAuth, JWT, SAML)
- 데이터 암호화 전략 및 키 관리
- 취약점 평가 및 침투 테스트 지침
- 보안 규정 준수(GDPR, HIPAA, PCI-DSS) 구현
**예제**:
1. **OAuth 구현**: 토큰 새로 고침 및 역할 기반 액세스를 갖춘 안전한 다중 테넌트 인증
2. **API 보안**: 속도 제한, 입력 검증, SQL 인젝션 방지, 보안 헤더
3. **데이터 보호**: 저장/전송 중 암호화, 키 순환, 프라이버시 바이 디자인 아키텍처
**최적의 협업 대상**: backend-architect(API 보안), quality-engineer(보안 테스팅), root-cause-analyst(사고 대응)
---
### performance-engineer ⚡
**전문 분야**: 확장성과 리소스 효율성에 중점을 둔 시스템 성능 최적화
**자동 활성화**:
- 키워드: "performance", "slow", "optimization", "bottleneck", "latency", "memory", "CPU"
- 컨텍스트: 성능 문제, 확장성 우려, 리소스 제약
- 메트릭: 응답 시간 >500ms, 높은 메모리 사용량, 낮은 처리량
**역량**:
- 성능 프로파일링 및 병목 현상 식별
- 데이터베이스 쿼리 최적화 및 인덱싱 전략
- 캐싱 구현(Redis, CDN, 애플리케이션 레벨)
- 부하 테스트 및 용량 계획
- 메모리 관리 및 리소스 최적화
**예제**:
1. **API 최적화**: 캐싱 및 쿼리 최적화를 통해 응답 시간을 2초에서 200ms로 단축
2. **데이터베이스 확장**: 읽기 복제본, 연결 풀링, 쿼리 결과 캐싱 구현
3. **프론트엔드 성능**: 번들 최적화, 지연 로딩, CDN 구현으로 <3초 로드 시간 달성
**최적의 협업 대상**: system-architect(확장성), devops-architect(인프라), root-cause-analyst(디버깅)
---
### root-cause-analyst 🔍
**전문 분야**: 증거 기반 분석 및 가설 테스트를 사용한 체계적인 문제 조사
**자동 활성화**:
- 키워드: "bug", "issue", "problem", "debugging", "investigation", "troubleshoot", "error"
- 컨텍스트: 시스템 장애, 예상치 못한 동작, 복잡한 다중 컴포넌트 문제
- 복잡성: 체계적인 조사가 필요한 교차 시스템 문제
**역량**:
- 체계적인 디버깅 방법론 및 근본 원인 분석
- 시스템 전반의 오류 상관 관계 및 종속성 매핑
- 실패 조사를 위한 로그 분석 및 패턴 인식
- 복잡한 문제에 대한 가설 형성 및 테스트
- 사고 대응 및 사후 분석 절차
**예제**:
1. **데이터베이스 연결 실패**: 연결 풀, 네트워크 타임아웃, 리소스 제한 전반의 간헐적 실패 추적
2. **결제 처리 오류**: API 로그, 데이터베이스 상태, 외부 서비스 응답을 통한 트랜잭션 실패 조사
3. **성능 저하**: 메트릭 상관 관계, 리소스 사용량, 코드 변경을 통한 점진적인 둔화 분석
**최적의 협업 대상**: performance-engineer(성능 문제), security-engineer(보안 사고), quality-engineer(테스트 실패)
---
### quality-engineer ✅
**전문 분야**: 자동화 및 커버리지에 중점을 둔 포괄적인 테스팅 전략 및 품질 보증
**자동 활성화**:
- 키워드: "test", "testing", "quality", "QA", "validation", "coverage", "automation"
- 컨텍스트: 테스트 계획, 품질 게이트, 검증 요구사항
- 품질 우려: 코드 커버리지 <80%, 테스트 자동화 부족, 품질 문제
**역량**:
- 테스트 전략 설계(단위, 통합, e2e, 성능 테스팅)
- 테스트 자동화 프레임워크 구현 및 CI/CD 통합
- 품질 메트릭 정의 및 모니터링(커버리지, 결함률)
- 엣지 케이스 식별 및 경계 테스팅 시나리오
- 접근성 테스팅 및 규정 준수 검증
**예제**:
1. **전자상거래 테스팅**: 사용자 흐름, 결제 처리, 재고 관리를 다루는 포괄적인 테스트 스위트
2. **API 테스팅**: REST/GraphQL API에 대한 자동화된 계약 테스팅, 부하 테스팅, 보안 테스팅
3. **접근성 검증**: 자동화 및 수동 접근성 감사를 통한 WCAG 2.1 규정 준수 테스팅
**최적의 협업 대상**: security-engineer(보안 테스팅), performance-engineer(부하 테스팅), frontend-architect(UI 테스팅)
---
### refactoring-expert 🔧
**전문 분야**: 체계적인 리팩토링 및 기술 부채 관리를 통한 코드 품질 개선
**자동 활성화**:
- 키워드: "refactor", "clean code", "technical debt", "SOLID", "maintainability", "code smell"
- 컨텍스트: 레거시 코드 개선, 아키텍처 업데이트, 코드 품질 문제
- 품질 지표: 높은 복잡성, 중복 코드, 낮은 테스트 커버리지
**역량**:
- SOLID 원칙 적용 및 디자인 패턴 구현
- 코드 냄새 식별 및 체계적인 제거
- 레거시 코드 현대화 전략 및 마이그레이션 계획
- 기술 부채 평가 및 우선순위 프레임워크
- 코드 구조 개선 및 아키텍처 리팩토링
**예제**:
1. **레거시 현대화**: 모놀리식 애플리케이션을 테스트 가능성이 향상된 모듈형 아키텍처로 변환
2. **디자인 패턴**: 결제 처리에 Strategy 패턴 구현으로 결합도 감소 및 확장성 향상
3. **코드 정리**: 중복 코드 제거, 명명 규칙 개선, 재사용 가능한 컴포넌트 추출
**최적의 협업 대상**: system-architect(아키텍처 개선), quality-engineer(테스팅 전략), python-expert(언어별 패턴)
### 전문 개발 에이전트 🎯
### python-expert 🐍
**전문 분야**: 현대적인 프레임워크와 성능을 강조하는 프로덕션급 Python 개발
**자동 활성화**:
- 키워드: "Python", "Django", "FastAPI", "Flask", "asyncio", "pandas", "pytest"
- 파일 유형: .py, requirements.txt, pyproject.toml, Pipfile
- 컨텍스트: Python 개발 작업, API 개발, 데이터 처리, 테스팅
**역량**:
- 현대적인 Python 아키텍처 패턴 및 프레임워크 선택
- asyncio 및 concurrent futures를 사용한 비동기 프로그래밍
- 프로파일링 및 알고리즘 개선을 통한 성능 최적화
- pytest, 픽스처, 테스트 자동화를 사용한 테스팅 전략
- pip, poetry, Docker를 사용한 패키지 관리 및 배포
**예제**:
1. **FastAPI 마이크로서비스**: Pydantic 검증, 의존성 주입, OpenAPI 문서를 갖춘 고성능 비동기 API
2. **데이터 파이프라인**: 대규모 데이터셋에 대한 오류 처리, 로깅, 병렬 처리를 갖춘 Pandas 기반 ETL
3. **Django 애플리케이션**: 사용자 정의 사용자 모델, API 엔드포인트, 포괄적인 테스트 커버리지를 갖춘 풀스택 웹 앱
**최적의 협업 대상**: backend-architect(API 설계), quality-engineer(테스팅), performance-engineer(최적화)
---
### requirements-analyst 📝
**전문 분야**: 체계적인 이해관계자 분석을 통한 요구사항 발견 및 사양 개발
**자동 활성화**:
- 키워드: "requirements", "specification", "PRD", "user story", "functional", "scope", "stakeholder"
- 컨텍스트: 프로젝트 시작, 불명확한 요구사항, 범위 정의 필요
- 복잡성: 다중 이해관계자 프로젝트, 불명확한 목표, 상충하는 요구사항
**역량**:
- 이해관계자 인터뷰 및 워크숍을 통한 요구사항 도출
- 승인 기준 및 완료 정의를 갖춘 사용자 스토리 작성
- 기능 및 비기능 사양 문서화
- 이해관계자 분석 및 요구사항 우선순위 프레임워크
- 범위 관리 및 변경 제어 프로세스
**예제**:
1. **제품 요구사항 문서**: 사용자 페르소나, 기능 사양, 성공 메트릭을 포함한 핀테크 모바일 앱 포괄적 PRD
2. **API 사양**: 오류 처리, 보안, 성능 기준을 갖춘 결제 처리 API에 대한 상세 요구사항
3. **마이그레이션 요구사항**: 데이터 마이그레이션, 사용자 교육, 롤백 절차를 갖춘 레거시 시스템 현대화 요구사항
**최적의 협업 대상**: system-architect(기술적 실현 가능성), technical-writer(문서화), learning-guide(사용자 안내)
### 커뮤니케이션 및 학습 에이전트 📚
### technical-writer 📚
**전문 분야**: 대상 분석 및 명확성에 중점을 둔 기술 문서화 및 커뮤니케이션
**자동 활성화**:
- 키워드: "documentation", "readme", "API docs", "user guide", "technical writing", "manual"
- 컨텍스트: 문서화 요청, API 문서화, 사용자 가이드, 기술 설명
- 파일 유형: .md, .rst, API 스펙, 문서 파일
**역량**:
- 기술 문서화 아키텍처 및 정보 설계
- 다양한 기술 수준에 대한 대상 분석 및 콘텐츠 타겟팅
- 작동 예제 및 통합 지침을 포함한 API 문서화
- 단계별 절차 및 문제 해결을 포함한 사용자 가이드 작성
- 접근성 표준 적용 및 포용적 언어 사용
**예제**:
1. **API 문서화**: 인증, 엔드포인트, 예제, SDK 통합 가이드를 포함한 포괄적인 REST API 문서
2. **사용자 매뉴얼**: 스크린샷, 문제 해결, FAQ 섹션을 포함한 단계별 설치 및 구성 가이드
3. **기술 사양**: 다이어그램, 데이터 흐름, 구현 세부사항을 포함한 시스템 아키텍처 문서
**최적의 협업 대상**: requirements-analyst(사양 명확성), learning-guide(교육 콘텐츠), frontend-architect(UI 문서화)
---
### learning-guide 🎓
**전문 분야**: 기술 개발 및 멘토십에 중점을 둔 교육 콘텐츠 설계 및 점진적 학습
**자동 활성화**:
- 키워드: "explain", "learn", "tutorial", "beginner", "teaching", "education", "training"
- 컨텍스트: 교육 요청, 개념 설명, 기술 개발, 학습 경로
- 복잡성: 단계별 분해 및 점진적 이해가 필요한 복잡한 주제
**역량**:
- 점진적 기술 개발을 갖춘 학습 경로 설계
- 유추 및 예제를 통한 복잡한 개념 설명
- 실습 연습을 포함한 대화형 튜토리얼 생성
- 기술 평가 및 역량 평가 프레임워크
- 멘토십 전략 및 개인화된 학습 접근법
**예제**:
1. **프로그래밍 튜토리얼**: 실습 연습, 코드 예제, 점진적 복잡성을 포함한 대화형 React 튜토리얼
2. **개념 설명**: 시각적 다이어그램 및 연습 문제를 포함한 실제 예제를 통한 데이터베이스 정규화 설명
3. **기술 평가**: 실제 프로젝트 및 피드백을 포함한 풀스택 개발을 위한 포괄적인 평가 프레임워크
**최적의 협업 대상**: technical-writer(교육 문서화), frontend-architect(대화형 학습), requirements-analyst(학습 목표)
---
## 에이전트 조정 및 통합 🤝
### 조정 패턴
**아키텍처 팀**:
- **풀스택 개발**: frontend-architect + backend-architect + security-engineer + quality-engineer
- **시스템 설계**: system-architect + devops-architect + performance-engineer + security-engineer
- **레거시 현대화**: refactoring-expert + system-architect + quality-engineer + technical-writer
**품질 팀**:
- **보안 감사**: security-engineer + quality-engineer + root-cause-analyst + requirements-analyst
- **성능 최적화**: performance-engineer + system-architect + devops-architect + root-cause-analyst
- **테스팅 전략**: quality-engineer + security-engineer + performance-engineer + frontend-architect
**커뮤니케이션 팀**:
- **문서화 프로젝트**: technical-writer + requirements-analyst + learning-guide + 도메인 전문가
- **학습 플랫폼**: learning-guide + frontend-architect + technical-writer + quality-engineer
- **API 문서화**: backend-architect + technical-writer + security-engineer + quality-engineer
### MCP 서버 통합
**MCP 서버를 통한 향상된 기능**:
- **Context7**: 모든 아키텍트 및 전문가를 위한 공식 문서화 패턴
- **Sequential**: root-cause-analyst, system-architect, performance-engineer를 위한 다단계 분석
- **Magic**: frontend-architect, learning-guide 대화형 콘텐츠를 위한 UI 생성
- **Playwright**: quality-engineer를 위한 브라우저 테스팅, frontend-architect를 위한 접근성 검증
- **Morphllm**: refactoring-expert를 위한 코드 변환, python-expert를 위한 대량 변경
- **Serena**: 모든 에이전트를 위한 프로젝트 메모리, 세션 전반의 컨텍스트 보존
### 에이전트 활성화 문제 해결
## 문제 해결
문제 해결 도움말은 다음을 참조하세요:
- [일반적인 문제](../Reference/common-issues.md) - 자주 발생하는 문제에 대한 빠른 수정
- [문제 해결 가이드](../Reference/troubleshooting.md) - 포괄적인 문제 해결
### 일반적인 문제
- **에이전트 활성화 없음**: 도메인 키워드 사용: "security", "performance", "frontend"
- **잘못된 에이전트 선택**: 에이전트 문서의 트리거 키워드 확인
- **너무 많은 에이전트**: 주요 도메인에 키워드 집중 또는 `/sc:focus [domain]` 사용
- **에이전트가 조정하지 않음**: 작업 복잡성 증가 또는 다중 도메인 키워드 사용
- **에이전트 전문 지식 불일치**: 더 구체적인 기술 용어 사용
### 즉각적인 수정
- **에이전트 활성화 강제**: 요청에 명시적 도메인 키워드 사용
- **에이전트 선택 재설정**: Claude Code 세션을 재시작하여 에이전트 상태 재설정
- **에이전트 패턴 확인**: 에이전트 문서의 트리거 키워드 검토
- **기본 활성화 테스트**: `/sc:implement "security auth"`로 security-engineer 테스트
### 에이전트별 문제 해결
**보안 에이전트 없음:**
```bash
# 문제: 보안 우려가 security-engineer를 트리거하지 않음
# 빠른 수정: 명시적 보안 키워드 사용
"implement authentication" # 일반적 - 트리거하지 않을 수 있음
"implement JWT authentication security" # 명시적 - security-engineer 트리거
"secure user login with encryption" # 보안 중심 - security-engineer 트리거
```
**성능 에이전트 없음:**
```bash
# 문제: 성능 문제가 performance-engineer를 트리거하지 않음
# 빠른 수정: 성능별 용어 사용
"make it faster" # 모호함 - 트리거하지 않을 수 있음
"optimize slow database queries" # 구체적 - performance-engineer 트리거
"reduce API latency and bottlenecks" # 성능 중심 - performance-engineer 트리거
```
**아키텍처 에이전트 없음:**
```bash
# 문제: 시스템 설계가 아키텍처 에이전트를 트리거하지 않음
# 빠른 수정: 아키텍처 키워드 사용
"build an app" # 일반적 - 기본 에이전트 트리거
"design microservices architecture" # 구체적 - system-architect 트리거
"scalable distributed system design" # 아키텍처 중심 - system-architect 트리거
```
**잘못된 에이전트 조합:**
```bash
# 문제: 백엔드 작업에 프론트엔드 에이전트 활성화
# 빠른 수정: 도메인별 용어 사용
"create user interface" # frontend-architect를 트리거할 수 있음
"create REST API endpoints" # 구체적 - backend-architect 트리거
"implement server-side authentication" # 백엔드 중심 - backend-architect 트리거
```
### 지원 수준
**빠른 수정:**
- 에이전트 트리거 테이블의 명시적 도메인 키워드 사용
- Claude Code 세션 재시작 시도
- 혼란을 피하기 위해 단일 도메인에 집중
**상세 도움말:**
- 에이전트 설치 문제는 [일반적인 문제 가이드](../Reference/common-issues.md) 참조
- 대상 에이전트의 트리거 키워드 검토
**전문가 지원:**
- `SuperClaude install --diagnose` 사용
- 조정 분석은 [진단 참조 가이드](../Reference/diagnostic-reference.md) 참조
**커뮤니티 지원:**
- [GitHub Issues](https://github.com/SuperClaude-Org/SuperClaude_Framework/issues)에서 문제 보고
- 예상 대비 실제 에이전트 활성화 예제 포함
### 성공 검증
에이전트 수정 적용 후 테스트:
- [ ] 도메인별 요청이 올바른 에이전트 활성화 (security → security-engineer)
- [ ] 복잡한 작업이 다중 에이전트 조정 트리거 (3개 이상 에이전트)
- [ ] 에이전트 전문 지식이 작업 요구사항과 일치 (API → backend-architect)
- [ ] 적절한 경우 품질 에이전트 자동 포함 (security, performance, testing)
- [ ] 응답에 도메인 전문 지식 및 전문 지식 표시
## 빠른 문제 해결 (레거시)
- **에이전트 활성화 없음** → 도메인 키워드 사용: "security", "performance", "frontend"
- **잘못된 에이전트** → 에이전트 문서의 트리거 키워드 확인
- **너무 많은 에이전트** → 주요 도메인에 키워드 집중
- **에이전트가 조정하지 않음** → 작업 복잡성 증가 또는 다중 도메인 키워드 사용
**에이전트가 활성화되지 않나요?**
1. **키워드 확인**: 도메인별 용어 사용 (예: security-engineer의 경우 "login"이 아닌 "authentication")
2. **컨텍스트 추가**: 파일 유형, 프레임워크 또는 특정 기술 포함
3. **복잡성 증가**: 다중 도메인 문제가 더 많은 에이전트 트리거
4. **예제 사용**: 에이전트 전문 지식과 일치하는 구체적인 시나리오 참조
**너무 많은 에이전트?**
- 주요 도메인 필요에 키워드 집중
- `/sc:focus [domain]`을 사용하여 범위 제한
- 특정 에이전트로 시작하고 필요에 따라 확장
**잘못된 에이전트?**
- 에이전트 문서의 트리거 키워드 검토
- 대상 도메인에 더 구체적인 용어 사용
- 명시적 요구사항 또는 제약조건 추가
## 빠른 참조 📋
### 에이전트 트리거 조회
| 트리거 유형 | 키워드/패턴 | 활성화된 에이전트 |
|-------------|-------------------|------------------|
| **보안** | "auth", "security", "vulnerability", "encryption" | security-engineer |
| **성능** | "slow", "optimization", "bottleneck", "latency" | performance-engineer |
| **프론트엔드** | "UI", "React", "Vue", "component", "responsive" | frontend-architect |
| **백엔드** | "API", "server", "database", "REST", "GraphQL" | backend-architect |
| **테스팅** | "test", "QA", "validation", "coverage" | quality-engineer |
| **DevOps** | "deploy", "CI/CD", "Docker", "Kubernetes" | devops-architect |
| **아키텍처** | "architecture", "microservices", "scalability" | system-architect |
| **Python** | ".py", "Django", "FastAPI", "asyncio" | python-expert |
| **문제** | "bug", "issue", "debugging", "troubleshoot" | root-cause-analyst |
| **코드 품질** | "refactor", "clean code", "technical debt" | refactoring-expert |
| **문서화** | "documentation", "readme", "API docs" | technical-writer |
| **학습** | "explain", "tutorial", "beginner", "teaching" | learning-guide |
| **요구사항** | "requirements", "PRD", "specification" | requirements-analyst |
| **연구** | "research", "investigate", "latest", "current" | deep-research-agent |
### 명령어-에이전트 매핑
| 명령어 | 주요 에이전트 | 지원 에이전트 |
|---------|----------------|-------------------|
| `/sc:implement` | 도메인 아키텍트 (frontend, backend) | security-engineer, quality-engineer |
| `/sc:analyze` | quality-engineer, security-engineer | performance-engineer, root-cause-analyst |
| `/sc:troubleshoot` | root-cause-analyst | 도메인 전문가, performance-engineer |
| `/sc:improve` | refactoring-expert | quality-engineer, performance-engineer |
| `/sc:document` | technical-writer | 도메인 전문가, learning-guide |
| `/sc:design` | system-architect | 도메인 아키텍트, requirements-analyst |
| `/sc:test` | quality-engineer | security-engineer, performance-engineer |
| `/sc:explain` | learning-guide | technical-writer, 도메인 전문가 |
| `/sc:research` | deep-research-agent | 기술 전문가, learning-guide |
### 효과적인 에이전트 조합
**개발 워크플로우**:
- 웹 애플리케이션: frontend-architect + backend-architect + security-engineer + quality-engineer + devops-architect
- API 개발: backend-architect + security-engineer + technical-writer + quality-engineer
- 데이터 플랫폼: python-expert + performance-engineer + security-engineer + system-architect
**분석 워크플로우**:
- 보안 감사: security-engineer + quality-engineer + root-cause-analyst + technical-writer
- 성능 조사: performance-engineer + root-cause-analyst + system-architect + devops-architect
- 레거시 평가: refactoring-expert + system-architect + quality-engineer + security-engineer + technical-writer
**커뮤니케이션 워크플로우**:
- 기술 문서화: technical-writer + requirements-analyst + 도메인 전문가 + learning-guide
- 교육 콘텐츠: learning-guide + technical-writer + frontend-architect + quality-engineer
## 모범 사례 💡
### 시작하기 (간단한 접근법)
**자연어 우선:**
1. **목표 설명**: 도메인별 키워드를 사용한 자연어 사용
2. **자동 활성화 신뢰**: 시스템이 자동으로 적절한 에이전트로 라우팅하도록 허용
3. **패턴에서 학습**: 다양한 요청 유형에 대해 어떤 에이전트가 활성화되는지 관찰
4. **반복 및 개선**: 추가 전문 에이전트를 참여시키기 위해 구체성 추가
### 에이전트 선택 최적화
**효과적인 키워드 사용:**
- **구체적 > 일반적**: security-engineer를 위해 "login" 대신 "authentication" 사용
- **기술 용어**: 프레임워크 이름, 기술, 특정 과제 포함
- **컨텍스트 단서**: 파일 유형, 프로젝트 범위, 복잡성 지표 언급
- **품질 키워드**: 포괄적인 커버리지를 위해 "security", "performance", "accessibility" 추가
**요청 최적화 예제:**
```bash
# 일반적 (제한된 에이전트 활성화)
"로그인 기능 수정"
# 최적화됨 (다중 에이전트 조정)
"속도 제한 및 접근성 규정 준수를 갖춘 안전한 JWT 인증 구현"
# → 트리거: security-engineer + backend-architect + frontend-architect + quality-engineer
```
### 일반적인 사용 패턴
**개발 워크플로우:**
```bash
# 풀스택 기능 개발
/sc:implement "실시간 알림이 있는 반응형 사용자 대시보드"
# → frontend-architect + backend-architect + performance-engineer
# 문서화를 포함한 API 개발
/sc:create "포괄적인 문서가 있는 결제 처리를 위한 REST API"
# → backend-architect + security-engineer + technical-writer + quality-engineer
# 성능 최적화 조사
/sc:troubleshoot "사용자 경험에 영향을 미치는 느린 데이터베이스 쿼리"
# → performance-engineer + root-cause-analyst + backend-architect
```
**분석 워크플로우:**
```bash
# 보안 평가
/sc:analyze "GDPR 규정 준수 취약점에 대한 인증 시스템"
# → security-engineer + quality-engineer + requirements-analyst
# 코드 품질 검토
/sc:review "현대화 기회를 위한 레거시 코드베이스"
# → refactoring-expert + system-architect + quality-engineer + technical-writer
# 학습 및 설명
/sc:explain "실습 예제가 있는 마이크로서비스 패턴"
# → system-architect + learning-guide + technical-writer
```
### 고급 에이전트 조정
**다중 도메인 프로젝트:**
- **광범위하게 시작**: 아키텍처 에이전트를 참여시키기 위해 시스템 수준 키워드로 시작
- **구체성 추가**: 전문 에이전트를 활성화하기 위해 도메인별 필요 포함
- **품질 통합**: 보안, 성능, 테스팅 관점 자동 포함
- **문서화 포함**: 포괄적인 커버리지를 위해 학습 또는 문서화 필요 추가
**에이전트 선택 문제 해결:**
**문제: 잘못된 에이전트 활성화**
- 해결책: 더 구체적인 도메인 용어 사용
- 예제: "database optimization" → performance-engineer + backend-architect
**문제: 에이전트가 충분하지 않음**
- 해결책: 복잡성 지표 및 교차 도메인 키워드 증가
- 예제: 요청에 "security", "performance", "documentation" 추가
**문제: 에이전트가 너무 많음**
- 해결책: 구체적인 기술 용어로 주요 도메인에 집중
- 예제: 범위를 제한하기 위해 "/sc:focus backend" 사용
### 품질 중심 개발
**보안 우선 접근법:**
도메인 전문가와 함께 security-engineer를 자동으로 참여시키기 위해 개발 요청에 항상 보안 고려사항을 포함하세요.
**성능 통합:**
처음부터 performance-engineer 조정을 보장하기 위해 성능 키워드("빠른", "효율적", "확장 가능")를 포함하세요.
**접근성 규정 준수:**
프론트엔드 개발에서 접근성 검증을 자동으로 포함하기 위해 "accessible", "WCAG" 또는 "inclusive"를 사용하세요.
**문서화 문화:**
자동 technical-writer 포함 및 지식 전달을 위해 요청에 "documented", "explained" 또는 "tutorial"을 추가하세요.
---
## 에이전트 지능 이해 🧠
### 에이전트를 효과적으로 만드는 것
**도메인 전문 지식**: 각 에이전트는 도메인별 전문 지식 패턴, 행동 접근법, 문제 해결 방법론을 가지고 있습니다.
**컨텍스트 활성화**: 에이전트는 키워드뿐만 아니라 요청 컨텍스트를 분석하여 관련성 및 참여 수준을 결정합니다.
**협업 지능**: 다중 에이전트 조정은 개별 에이전트 능력을 초과하는 시너지 효과를 생성합니다.
**적응형 학습**: 에이전트 선택은 요청 패턴 및 성공적인 조정 결과를 기반으로 향상됩니다.
### 에이전트 vs. 전통적인 AI
**전통적인 접근법**: 단일 AI가 다양한 수준의 전문 지식으로 모든 도메인을 처리
**에이전트 접근법**: 전문가들이 깊은 도메인 지식과 집중된 문제 해결로 협업
**이점**:
- 도메인별 작업에서 더 높은 정확도
- 더 정교한 문제 해결 방법론
- 전문가 검토를 통한 더 나은 품질 보증
- 조정된 다중 관점 분석
### 시스템을 신뢰하고 패턴을 이해하세요
**기대할 수 있는 것**:
- 적절한 도메인 전문가에게 자동 라우팅
- 복잡한 작업에 대한 다중 에이전트 조정
- 자동 QA 에이전트 포함을 통한 품질 통합
- 교육 에이전트 활성화를 통한 학습 기회
**걱정하지 않아도 되는 것**:
- 수동 에이전트 선택 또는 구성
- 복잡한 라우팅 규칙 또는 에이전트 관리
- 에이전트 구성 또는 조정
- 에이전트 상호작용 마이크로 관리
---
## 관련 리소스 📚
### 필수 문서
- **[명령어 가이드](commands.md)** - 최적의 에이전트 조정을 트리거하는 SuperClaude 명령어 마스터
- **[MCP 서버](mcp-servers.md)** - 전문 도구 통합을 통한 향상된 에이전트 기능
- **[세션 관리](session-management.md)** - 영구 에이전트 컨텍스트를 사용한 장기 워크플로우
### 고급 사용
- **[행동 모드](modes.md)** - 향상된 에이전트 조정을 위한 컨텍스트 최적화
- **[시작하기](../Getting-Started/quick-start.md)** - 에이전트 최적화를 위한 전문가 기법
- **[예제 모음](../Reference/examples-cookbook.md)** - 실제 에이전트 조정 패턴
### 개발 리소스
- **[기술 아키텍처](../Developer-Guide/technical-architecture.md)** - SuperClaude의 에이전트 시스템 설계 이해
- **[기여하기](../Developer-Guide/contributing-code.md)** - 에이전트 기능 및 조정 패턴 확장
---
## 에이전트 여정 🚀
**1주차: 자연스러운 사용**
자연어 설명으로 시작하세요. 어떤 에이전트가 활성화되는지, 그리고 그 이유를 주목하세요. 프로세스를 과도하게 생각하지 않고 키워드 패턴에 대한 직관을 구축하세요.
**2-3주차: 패턴 인식**
에이전트 조정 패턴을 관찰하세요. 복잡성과 도메인 키워드가 에이전트 선택에 어떻게 영향을 미치는지 이해하세요. 더 나은 조정을 위해 요청 문구를 최적화하기 시작하세요.
**2개월 이상: 전문가 조정**
최적의 에이전트 조합을 트리거하는 다중 도메인 요청을 마스터하세요. 효과적인 에이전트 선택을 위한 문제 해결 기법을 활용하세요. 복잡한 워크플로우를 위한 고급 패턴을 사용하세요.
**SuperClaude 이점:**
간단하고 자연스러운 언어 요청을 통해 조정된 응답으로 작동하는 14명의 전문 AI 전문가의 힘을 경험하세요. 구성도, 관리도 필요 없이, 필요에 따라 확장되는 지능적인 협업만 있습니다.
🎯 **지능적인 에이전트 조정을 경험할 준비가 되셨나요? `/sc:implement`로 시작하여 전문 AI 협업의 마법을 발견하세요.**

View File

@ -0,0 +1,367 @@
# SuperClaude 명령어 가이드
SuperClaude는 Claude Code를 위한 25개의 명령어를 제공합니다: 워크플로우를 위한 `/sc:*` 명령어와 전문가를 위한 `@agent-*`.
## 명령어 유형
| 유형 | 사용 위치 | 형식 | 예제 |
|------|------------|--------|---------|
| **슬래시 명령어** | Claude Code | `/sc:[명령어]` | `/sc:implement "기능"` |
| **에이전트** | Claude Code | `@agent-[이름]` | `@agent-security "검토"` |
| **설치** | 터미널 | `SuperClaude [명령어]` | `SuperClaude install` |
## 빠른 테스트
```bash
# 터미널: 설치 확인
python3 -m SuperClaude --version
# Claude Code CLI 확인: claude --version
# Claude Code: 명령어 테스트
/sc:brainstorm "테스트 프로젝트" # 발견 질문을 해야 함
/sc:analyze README.md # 분석을 제공해야 함
```
**워크플로우**: `/sc:brainstorm "아이디어"``/sc:implement "기능"``/sc:test`
## 🎯 SuperClaude 명령어 이해하기
## SuperClaude 작동 방식
SuperClaude는 Claude Code가 읽어 전문화된 동작을 채택하는 행동 컨텍스트 파일을 제공합니다. `/sc:implement`를 입력하면 Claude Code는 `implement.md` 컨텍스트 파일을 읽고 행동 지침을 따릅니다.
**SuperClaude 명령어는 소프트웨어로 실행되지 않습니다** - 프레임워크의 전문 지침 파일을 읽어 Claude Code의 동작을 수정하는 컨텍스트 트리거입니다.
### 명령어 유형:
- **슬래시 명령어** (`/sc:*`): 워크플로우 패턴 및 행동 모드 트리거
- **에이전트 호출** (`@agent-*`): 특정 도메인 전문가를 수동으로 활성화
- **플래그** (`--think`, `--safe-mode`): 명령어 동작 및 깊이 수정
### 컨텍스트 메커니즘:
1. **사용자 입력**: `/sc:implement "인증 시스템"` 입력
2. **컨텍스트 로딩**: Claude Code가 `~/.claude/SuperClaude/Commands/implement.md` 읽음
3. **동작 채택**: Claude가 도메인 전문 지식, 도구 선택, 검증 패턴 적용
4. **향상된 출력**: 보안 고려사항 및 모범 사례를 갖춘 구조화된 구현
**핵심 포인트**: 이는 전통적인 소프트웨어 실행이 아닌 컨텍스트 관리를 통해 정교한 개발 워크플로우를 만듭니다.
### 설치 vs 사용 명령어
**🖥️ 터미널 명령어** (실제 CLI 소프트웨어):
- `SuperClaude install` - 프레임워크 컴포넌트 설치
- `SuperClaude update` - 기존 설치 업데이트
- `SuperClaude uninstall` - 프레임워크 설치 제거
- `python3 -m SuperClaude --version` - 설치 상태 확인
**💬 Claude Code 명령어** (컨텍스트 트리거):
- `/sc:brainstorm` - 요구사항 발견 컨텍스트 활성화
- `/sc:implement` - 기능 개발 컨텍스트 활성화
- `@agent-security` - 보안 전문가 컨텍스트 활성화
- 모든 명령어는 Claude Code 채팅 인터페이스 내에서만 작동
> **빠른 시작**: 핵심 워크플로우를 경험하려면 `/sc:brainstorm "프로젝트 아이디어"``/sc:implement "기능 이름"``/sc:test`를 시도해보세요.
## 🧪 설정 테스트
### 🖥️ 터미널 확인 (터미널/CMD에서 실행)
```bash
# SuperClaude 작동 확인 (주요 방법)
python3 -m SuperClaude --version
# 예상 출력: SuperClaude 4.1.5
# Claude Code CLI 버전 확인
claude --version
# 설치된 컴포넌트 확인
python3 -m SuperClaude install --list-components | grep mcp
# 예상 출력: 설치된 MCP 컴포넌트 표시
```
### 💬 Claude Code 테스트 (Claude Code 채팅에 입력)
```
# 기본 /sc: 명령어 테스트
/sc:brainstorm "테스트 프로젝트"
# 예상 동작: 대화형 요구사항 발견 시작
# 명령어 도움말 테스트
/sc:help
# 예상 동작: 사용 가능한 명령어 목록
```
**테스트가 실패하면**: [설치 가이드](../Getting-Started/installation.md) 또는 [문제 해결](#troubleshooting) 확인
### 📝 명령어 빠른 참조
| 명령어 유형 | 실행 위치 | 형식 | 목적 | 예제 |
|-------------|--------------|--------|---------|----------|
| **🖥️ 설치** | 터미널/CMD | `SuperClaude [명령어]` | 설정 및 유지보수 | `SuperClaude install` |
| **🔧 구성** | 터미널/CMD | `python3 -m SuperClaude [명령어]` | 고급 구성 | `python3 -m SuperClaude --version` |
| **💬 슬래시 명령어** | Claude Code | `/sc:[명령어]` | 워크플로우 자동화 | `/sc:implement "기능"` |
| **🤖 에이전트 호출** | Claude Code | `@agent-[이름]` | 수동 전문가 활성화 | `@agent-security "검토"` |
| **⚡ 향상된 플래그** | Claude Code | `/sc:[명령어] --플래그` | 동작 수정 | `/sc:analyze --think-hard` |
> **기억하세요**: 모든 `/sc:` 명령어와 `@agent-` 호출은 터미널이 아닌 Claude Code 채팅 내에서 작동합니다. 이들은 Claude Code가 SuperClaude 프레임워크에서 특정 컨텍스트 파일을 읽도록 트리거합니다.
## 목차
- [필수 명령어](#필수-명령어) - 여기서 시작하세요 (8개 핵심 명령어)
- [일반적인 워크플로우](#일반적인-워크플로우) - 작동하는 명령어 조합
- [전체 명령어 참조](#전체-명령어-참조) - 카테고리별로 정리된 25개 명령어
- [문제 해결](#문제-해결) - 일반적인 문제 및 해결책
- [명령어 인덱스](#명령어-인덱스) - 카테고리별로 명령어 찾기
---
## 필수 명령어
**즉각적인 생산성을 위한 핵심 워크플로우 명령어:**
### `/sc:brainstorm` - 프로젝트 발견
**목적**: 대화형 요구사항 발견 및 프로젝트 계획
**구문**: `/sc:brainstorm "아이디어"` `[--strategy systematic|creative]`
**사용 사례**:
- 새 프로젝트 계획: `/sc:brainstorm "전자상거래 플랫폼"`
- 기능 탐색: `/sc:brainstorm "사용자 인증 시스템"`
- 문제 해결: `/sc:brainstorm "느린 데이터베이스 쿼리"`
### `/sc:help` - 명령어 참조
**목적**: 사용 가능한 모든 `/sc` 명령어와 설명 목록 표시
**구문**: `/sc:help`
**사용 사례**:
- 사용 가능한 명령어 발견: `/sc:help`
- 명령어 이름 빠른 확인: `/sc:help`
### `/sc:research` - 심층 연구 명령어
**목적**: 적응형 계획 및 지능형 검색을 통한 포괄적인 웹 연구
**구문**: `/sc:research "[쿼리]"` `[--depth quick|standard|deep|exhaustive] [--strategy planning|intent|unified]`
**사용 사례**:
- 기술 연구: `/sc:research "최신 React 19 기능" --depth deep`
- 시장 분석: `/sc:research "2024년 AI 코딩 어시스턴트 현황" --strategy unified`
- 학술 조사: `/sc:research "양자 컴퓨팅 돌파구" --depth exhaustive`
- 최신 정보: `/sc:research "2024년 최신 AI 개발"`
**핵심 기능**:
- **6단계 워크플로우**: 이해 → 계획 → TodoWrite → 실행 → 추적 → 검증
- **적응형 깊이**: Quick(기본 검색), Standard(확장), Deep(포괄적), Exhaustive(최대 깊이)
- **계획 전략**: Planning(직접), Intent(먼저 명확화), Unified(협업)
- **병렬 실행**: 기본 병렬 검색 및 추출
- **증거 관리**: 관련성 점수가 있는 명확한 인용
- **출력 표준**: 보고서가 `claudedocs/research_[주제]_[타임스탬프].md`에 저장됨
### `/sc:implement` - 기능 개발
**목적**: 지능형 전문가 라우팅을 통한 풀스택 기능 구현
**구문**: `/sc:implement "기능 설명"` `[--type frontend|backend|fullstack] [--focus security|performance]`
**사용 사례**:
- 인증: `/sc:implement "JWT 로그인 시스템"`
- UI 컴포넌트: `/sc:implement "반응형 대시보드"`
- API: `/sc:implement "REST 사용자 엔드포인트"`
- 데이터베이스: `/sc:implement "관계를 가진 사용자 스키마"`
### `/sc:analyze` - 코드 평가
**목적**: 품질, 보안, 성능에 걸친 포괄적인 코드 분석
**구문**: `/sc:analyze [경로]` `[--focus quality|security|performance|architecture]`
**사용 사례**:
- 프로젝트 상태: `/sc:analyze .`
- 보안 감사: `/sc:analyze --focus security`
- 성능 검토: `/sc:analyze --focus performance`
### `/sc:business-panel` - 전략적 비즈니스 분석
**목적**: 9명의 저명한 사상가와 함께하는 다중 전문가 비즈니스 전략 분석
**구문**: `/sc:business-panel "내용"` `[--mode discussion|debate|socratic] [--experts "name1,name2"]`
**사용 사례**:
- 전략 평가: `/sc:business-panel "우리의 시장 진출 전략"`
- 경쟁 분석: `/sc:business-panel @competitor_analysis.pdf --mode debate`
- 혁신 평가: `/sc:business-panel "AI 제품 아이디어" --experts "christensen,drucker"`
- 전략적 학습: `/sc:business-panel "경쟁 전략" --mode socratic`
**전문가 패널**: Christensen, Porter, Drucker, Godin, Kim/Mauborgne, Collins, Taleb, Meadows, Doumont
### `/sc:spec-panel` - 전문가 사양 검토
**목적**: 저명한 사양 및 소프트웨어 엔지니어링 전문가를 사용한 다중 전문가 사양 검토 및 개선
**구문**: `/sc:spec-panel [내용|@파일]` `[--mode discussion|critique|socratic] [--focus requirements|architecture|testing|compliance]`
**사용 사례**:
- 사양 검토: `/sc:spec-panel @api_spec.yml --mode critique --focus requirements,architecture`
- 요구사항 워크숍: `/sc:spec-panel "사용자 스토리 내용" --mode discussion`
- 아키텍처 검증: `/sc:spec-panel @microservice.spec.yml --mode socratic --focus architecture`
- 규정 준수 검토: `/sc:spec-panel @security_requirements.yml --focus compliance`
- 반복적 개선: `/sc:spec-panel @complex_system.spec.yml --iterations 3`
**전문가 패널**: Wiegers, Adzic, Cockburn, Fowler, Nygard, Newman, Hohpe, Crispin, Gregory, Hightower
### `/sc:troubleshoot` - 문제 진단
**목적**: 근본 원인 분석을 통한 체계적인 문제 진단
**구문**: `/sc:troubleshoot "문제 설명"` `[--type build|runtime|performance]`
**사용 사례**:
- 런타임 오류: `/sc:troubleshoot "로그인 시 500 오류"`
- 빌드 실패: `/sc:troubleshoot --type build`
- 성능 문제: `/sc:troubleshoot "느린 페이지 로드"`
### `/sc:test` - 품질 보증
**목적**: 커버리지 분석을 통한 포괄적인 테스팅
**구문**: `/sc:test` `[--type unit|integration|e2e] [--coverage] [--fix]`
**사용 사례**:
- 전체 테스트 스위트: `/sc:test --coverage`
- 단위 테스팅: `/sc:test --type unit --watch`
- E2E 검증: `/sc:test --type e2e`
### `/sc:improve` - 코드 향상
**목적**: 체계적인 코드 개선 및 최적화 적용
**구문**: `/sc:improve [경로]` `[--type performance|quality|security] [--preview]`
**사용 사례**:
- 일반적인 개선: `/sc:improve src/`
- 성능 최적화: `/sc:improve --type performance`
- 보안 강화: `/sc:improve --type security`
### `/sc:document` - 문서 생성
**목적**: 코드 및 API에 대한 포괄적인 문서 생성
**구문**: `/sc:document [경로]` `[--type api|user-guide|technical] [--format markdown|html]`
**사용 사례**:
- API 문서: `/sc:document --type api`
- 사용자 가이드: `/sc:document --type user-guide`
- 기술 문서: `/sc:document --type technical`
### `/sc:workflow` - 구현 계획
**목적**: 요구사항에서 구조화된 구현 계획 생성
**구문**: `/sc:workflow "기능 설명"` `[--strategy agile|waterfall] [--format markdown]`
**사용 사례**:
- 기능 계획: `/sc:workflow "사용자 인증"`
- 스프린트 계획: `/sc:workflow --strategy agile`
- 아키텍처 계획: `/sc:workflow "마이크로서비스 마이그레이션"`
---
## 일반적인 워크플로우
**검증된 명령어 조합:**
### 새 프로젝트 설정
```bash
/sc:brainstorm "프로젝트 개념" # 요구사항 정의
/sc:design "시스템 아키텍처" # 기술 설계 생성
/sc:workflow "구현 계획" # 개발 로드맵 생성
```
### 기능 개발
```bash
/sc:implement "기능 이름" # 기능 구축
/sc:test --coverage # 테스트로 검증
/sc:document --type api # 문서 생성
```
### 코드 품질 개선
```bash
/sc:analyze --focus quality # 현재 상태 평가
/sc:improve --preview # 개선 사항 미리보기
/sc:test --coverage # 변경 사항 검증
```
### 버그 조사
```bash
/sc:troubleshoot "문제 설명" # 문제 진단
/sc:analyze --focus problem-area # 심층 분석
/sc:improve --fix --safe-mode # 대상 수정 적용
```
### 사양 개발
```bash
/sc:spec-panel @existing_spec.yml --mode critique # 전문가 검토
/sc:spec-panel @improved_spec.yml --iterations 2 # 반복적 개선
/sc:document --type technical # 문서 생성
```
## 전체 명령어 참조
### 개발 명령어
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **workflow** | 구현 계획 | 프로젝트 로드맵, 스프린트 계획 |
| **implement** | 기능 개발 | 풀스택 기능, API 개발 |
| **build** | 프로젝트 컴파일 | CI/CD, 프로덕션 빌드 |
| **design** | 시스템 아키텍처 | API 스펙, 데이터베이스 스키마 |
### 분석 명령어
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **analyze** | 코드 평가 | 품질 감사, 보안 검토 |
| **research** | 지능형 검색을 통한 웹 연구 | 기술 연구, 최신 정보, 시장 분석 |
| **business-panel** | 전략적 분석 | 비즈니스 결정, 경쟁 평가 |
| **spec-panel** | 사양 검토 | 요구사항 검증, 아키텍처 분석 |
| **troubleshoot** | 문제 진단 | 버그 조사, 성능 문제 |
| **explain** | 코드 설명 | 학습, 코드 검토 |
### 품질 명령어
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **improve** | 코드 향상 | 성능 최적화, 리팩토링 |
| **cleanup** | 기술 부채 | 데드 코드 제거, 정리 |
| **test** | 품질 보증 | 테스트 자동화, 커버리지 분석 |
| **document** | 문서화 | API 문서, 사용자 가이드 |
### 프로젝트 관리
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **estimate** | 프로젝트 추정 | 타임라인 계획, 리소스 할당 |
| **task** | 작업 관리 | 복잡한 워크플로우, 작업 추적 |
| **spawn** | 메타 오케스트레이션 | 대규모 프로젝트, 병렬 실행 |
### 유틸리티 명령어
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **help** | 모든 명령어 나열 | 사용 가능한 명령어 발견 |
| **git** | 버전 제어 | 커밋 관리, 브랜치 전략 |
| **index** | 명령어 발견 | 기능 탐색, 명령어 찾기 |
### 세션 명령어
| 명령어 | 목적 | 최적 사용처 |
|---------|---------|----------|
| **load** | 컨텍스트 로딩 | 세션 초기화, 프로젝트 온보딩 |
| **save** | 세션 지속성 | 체크포인팅, 컨텍스트 보존 |
| **reflect** | 작업 검증 | 진행 상황 평가, 완료 검증 |
| **select-tool** | 도구 최적화 | 성능 최적화, 도구 선택 |
---
## 명령어 인덱스
**기능별:**
- **계획**: brainstorm, design, workflow, estimate
- **개발**: implement, build, git
- **분석**: analyze, business-panel, spec-panel, troubleshoot, explain
- **품질**: improve, cleanup, test, document
- **관리**: task, spawn, load, save, reflect
- **유틸리티**: help, index, select-tool
**복잡성별:**
- **초급**: brainstorm, implement, analyze, test, help
- **중급**: workflow, design, business-panel, spec-panel, improve, document
- **고급**: spawn, task, select-tool, reflect
## 문제 해결
**명령어 문제:**
- **명령어를 찾을 수 없음**: 설치 확인: `python3 -m SuperClaude --version`
- **응답 없음**: Claude Code 세션 재시작
- **처리 지연**: MCP 서버 없이 테스트하려면 `--no-mcp` 사용
**빠른 수정:**
- 세션 재설정: `/sc:load`로 다시 초기화
- 상태 확인: `SuperClaude install --list-components`
- 도움말 받기: [문제 해결 가이드](../Reference/troubleshooting.md)
## 다음 단계
- [플래그 가이드](flags.md) - 명령어 동작 제어
- [에이전트 가이드](agents.md) - 전문가 활성화
- [예제 모음](../Reference/examples-cookbook.md) - 실제 사용 패턴

271
Docs/User-Guide-kr/flags.md Normal file
View File

@ -0,0 +1,271 @@
# SuperClaude 플래그 가이드 🏁
**대부분의 플래그는 자동으로 활성화됩니다** - Claude Code가 요청의 키워드와 패턴을 기반으로 적절한 컨텍스트를 참여시키는 행동 지침을 읽습니다.
## 필수 자동 활성화 플래그 (사용 사례의 90%)
### 핵심 분석 플래그
| 플래그 | 활성화 시점 | 수행 작업 |
|------|---------------|--------------|
| `--think` | 5개 이상 파일 또는 복잡한 분석 | 표준 구조화된 분석 (~4K 토큰) |
| `--think-hard` | 아키텍처 분석, 시스템 종속성 | 향상된 도구를 사용한 심층 분석 (~10K 토큰) |
| `--ultrathink` | 중요한 시스템 재설계, 레거시 현대화 | 모든 도구를 사용한 최대 깊이 분석 (~32K 토큰) |
### MCP 서버 플래그
| 플래그 | 서버 | 목적 | 자동 트리거 |
|------|---------|---------|---------------|
| `--c7` / `--context7` | Context7 | 공식 문서, 프레임워크 패턴 | 라이브러리 임포트, 프레임워크 질문 |
| `--seq` / `--sequential` | Sequential | 다단계 추론, 디버깅 | 복잡한 디버깅, 시스템 설계 |
| `--magic` | Magic | UI 컴포넌트 생성 | `/ui` 명령어, 프론트엔드 키워드 |
| `--play` / `--playwright` | Playwright | 브라우저 테스팅, E2E 검증 | 테스팅 요청, 시각적 검증 |
| `--morph` / `--morphllm` | Morphllm | 대량 변환, 패턴 편집 | 대량 작업, 스타일 강제 |
| `--serena` | Serena | 프로젝트 메모리, 심볼 작업 | 심볼 작업, 대규모 코드베이스 |
### 행동 모드 플래그
| 플래그 | 활성화 시점 | 수행 작업 |
|------|---------------|--------------|
| `--brainstorm` | 모호한 요청, 탐색 키워드 | 협업 발견 마인드셋 |
| `--introspect` | 자기 분석, 오류 복구 | 투명성을 갖춘 추론 과정 노출 |
| `--task-manage` | >3단계, 복잡한 범위 | 위임을 통한 오케스트레이션 |
| `--orchestrate` | 다중 도구 작업, 성능 필요 | 도구 선택 및 병렬 실행 최적화 |
| `--token-efficient` / `--uc` | 컨텍스트 >75%, 효율성 필요 | 심볼 강화 커뮤니케이션, 30-50% 감소 |
### 실행 제어 플래그
| 플래그 | 활성화 시점 | 수행 작업 |
|------|---------------|--------------|
| `--loop` | "개선", "다듬기", "정제" 키워드 | 반복적 향상 사이클 |
| `--safe-mode` | 프로덕션, >85% 리소스 사용 | 최대 검증, 보수적 실행 |
| `--validate` | 위험 >0.7, 프로덕션 환경 | 실행 전 위험 평가 |
| `--delegate` | >7개 디렉토리 또는 >50개 파일 | 하위 에이전트 병렬 처리 |
## 명령어별 플래그
### 분석 명령어 플래그 (`/sc:analyze`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--focus` | 특정 도메인 대상 | `security`, `performance`, `quality`, `architecture` |
| `--depth` | 분석 철저함 | `quick`, `deep` |
| `--format` | 출력 형식 | `text`, `json`, `report` |
### 빌드 명령어 플래그 (`/sc:build`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 빌드 구성 | `dev`, `prod`, `test` |
| `--clean` | 빌드 전 정리 | 불린 |
| `--optimize` | 최적화 활성화 | 불린 |
| `--verbose` | 상세 출력 | 불린 |
### 디자인 명령어 플래그 (`/sc:design`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 디자인 대상 | `architecture`, `api`, `component`, `database` |
| `--format` | 출력 형식 | `diagram`, `spec`, `code` |
### 설명 명령어 플래그 (`/sc:explain`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--level` | 복잡성 수준 | `basic`, `intermediate`, `advanced` |
| `--format` | 설명 스타일 | `text`, `examples`, `interactive` |
| `--context` | 도메인 컨텍스트 | 모든 도메인 (예: `react`, `security`) |
### 개선 명령어 플래그 (`/sc:improve`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 개선 초점 | `quality`, `performance`, `maintainability`, `style`, `security` |
| `--safe` | 보수적 접근 | 불린 |
| `--interactive` | 사용자 안내 | 불린 |
| `--preview` | 실행 없이 표시 | 불린 |
### 작업 명령어 플래그 (`/sc:task`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--strategy` | 작업 접근법 | `systematic`, `agile`, `enterprise` |
| `--parallel` | 병렬 실행 | 불린 |
| `--delegate` | 하위 에이전트 조정 | 불린 |
### 워크플로우 명령어 플래그 (`/sc:workflow`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--strategy` | 워크플로우 접근법 | `systematic`, `agile`, `enterprise` |
| `--depth` | 분석 깊이 | `shallow`, `normal`, `deep` |
| `--parallel` | 병렬 조정 | 불린 |
### 문제 해결 명령어 플래그 (`/sc:troubleshoot`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 문제 카테고리 | `bug`, `build`, `performance`, `deployment` |
| `--trace` | 추적 분석 포함 | 불린 |
| `--fix` | 수정 적용 | 불린 |
### 정리 명령어 플래그 (`/sc:cleanup`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 정리 대상 | `code`, `imports`, `files`, `all` |
| `--safe` / `--aggressive` | 정리 강도 | 불린 |
| `--interactive` | 사용자 안내 | 불린 |
| `--preview` | 실행 없이 표시 | 불린 |
### 추정 명령어 플래그 (`/sc:estimate`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 추정 초점 | `time`, `effort`, `complexity` |
| `--unit` | 시간 단위 | `hours`, `days`, `weeks` |
| `--breakdown` | 상세 분해 | 불린 |
### 인덱스 명령어 플래그 (`/sc:index`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 인덱스 대상 | `docs`, `api`, `structure`, `readme` |
| `--format` | 출력 형식 | `md`, `json`, `yaml` |
### 성찰 명령어 플래그 (`/sc:reflect`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--type` | 성찰 범위 | `task`, `session`, `completion` |
| `--analyze` | 분석 포함 | 불린 |
| `--validate` | 완전성 검증 | 불린 |
### 스폰 명령어 플래그 (`/sc:spawn`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--strategy` | 조정 접근법 | `sequential`, `parallel`, `adaptive` |
| `--depth` | 분석 깊이 | `normal`, `deep` |
### Git 명령어 플래그 (`/sc:git`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--smart-commit` | 커밋 메시지 생성 | 불린 |
| `--interactive` | 안내 작업 | 불린 |
### 도구 선택 명령어 플래그 (`/sc:select-tool`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--analyze` | 도구 분석 | 불린 |
| `--explain` | 선택 설명 | 불린 |
### 테스트 명령어 플래그 (`/sc:test`)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--coverage` | 커버리지 포함 | 불린 |
| `--type` | 테스트 유형 | `unit`, `integration`, `e2e` |
| `--watch` | 감시 모드 | 불린 |
## 고급 제어 플래그
### 범위 및 초점
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--scope` | 분석 경계 | `file`, `module`, `project`, `system` |
| `--focus` | 도메인 타겟팅 | `performance`, `security`, `quality`, `architecture`, `accessibility`, `testing` |
### 실행 제어
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--concurrency [n]` | 병렬 작업 제어 | 1-15 |
| `--iterations [n]` | 개선 사이클 | 1-10 |
| `--all-mcp` | 모든 MCP 서버 활성화 | 불린 |
| `--no-mcp` | 네이티브 도구만 | 불린 |
### 시스템 플래그 (SuperClaude 설치)
| 플래그 | 목적 | 값 |
|------|---------|--------|
| `--verbose` / `-v` | 상세 로깅 | 불린 |
| `--quiet` / `-q` | 출력 억제 | 불린 |
| `--dry-run` | 작업 시뮬레이션 | 불린 |
| `--force` | 검사 건너뛰기 | 불린 |
| `--yes` / `-y` | 자동 확인 | 불린 |
| `--install-dir` | 대상 디렉토리 | 경로 |
| `--legacy` | 레거시 스크립트 사용 | 불린 |
| `--version` | 버전 표시 | 불린 |
| `--help` | 도움말 표시 | 불린 |
## 일반적인 사용 패턴
### 프론트엔드 개발
```bash
/sc:implement "반응형 대시보드" --magic --c7
/sc:design component-library --type component --format code
/sc:test ui-components/ --magic --play
/sc:improve legacy-ui/ --magic --morph --validate
```
### 백엔드 개발
```bash
/sc:analyze api/ --focus performance --seq --think
/sc:design payment-api --type api --format spec
/sc:troubleshoot "API 타임아웃" --type performance --trace
/sc:improve auth-service --type security --validate
```
### 대규모 프로젝트
```bash
/sc:analyze . --ultrathink --all-mcp --safe-mode
/sc:workflow enterprise-system --strategy enterprise --depth deep
/sc:cleanup . --type all --safe --interactive
/sc:estimate "마이크로서비스로 마이그레이션" --type complexity --breakdown
```
### 품질 및 유지보수
```bash
/sc:improve src/ --type quality --safe --interactive
/sc:cleanup imports --type imports --preview
/sc:reflect --type completion --validate
/sc:git commit --smart-commit
```
## 플래그 상호작용
### 호환 가능한 조합
- `--think` + `--c7`: 문서를 사용한 분석
- `--magic` + `--play`: 테스팅을 사용한 UI 생성
- `--serena` + `--morph`: 변환을 사용한 프로젝트 메모리
- `--safe-mode` + `--validate`: 최대 안전성
- `--loop` + `--validate`: 검증을 통한 반복적 개선
### 충돌하는 플래그
- `--all-mcp` vs 개별 MCP 플래그 (하나만 사용)
- `--no-mcp` vs 모든 MCP 플래그 (--no-mcp 우선)
- `--safe` vs `--aggressive` (정리 강도)
- `--quiet` vs `--verbose` (출력 수준)
### 자동 활성화 관계
- `--safe-mode``--uc``--validate` 자동 활성화
- `--ultrathink`는 모든 MCP 서버 자동 활성화
- `--think-hard``--seq` + `--c7` 자동 활성화
- `--magic`는 UI 중심 에이전트 트리거
## 플래그 문제 해결
### 일반적인 문제
- **너무 많은 도구**: 네이티브 도구만 테스트하려면 `--no-mcp` 사용
- **작업이 너무 느림**: 출력 압축을 위해 `--uc` 추가
- **검증 차단**: 개발 중에는 `--safe-mode` 대신 `--validate` 사용
- **컨텍스트 압박**: >75% 사용 시 `--token-efficient` 자동 활성화
### 디버그 플래그
```bash
/sc:analyze . --verbose # 결정 로직 및 플래그 활성화 표시
/sc:select-tool "작업" --explain # 도구 선택 과정 설명
/sc:reflect --type session --analyze # 현재 세션 결정 검토
```
### 빠른 수정
```bash
/sc:analyze . --help # 명령어에 사용 가능한 플래그 표시
/sc:analyze . --no-mcp # 네이티브 실행만
/sc:cleanup . --preview # 정리될 내용 표시
```
## 플래그 우선순위 규칙
1. **안전 우선**: `--safe-mode` > `--validate` > 최적화 플래그
2. **명시적 재정의**: 사용자 플래그 > 자동 감지
3. **깊이 계층**: `--ultrathink` > `--think-hard` > `--think`
4. **MCP 제어**: `--no-mcp`가 모든 개별 MCP 플래그 재정의
5. **범위 우선순위**: system > project > module > file
## 관련 리소스
- [명령어 가이드](commands.md) - 이러한 플래그를 사용하는 명령어
- [MCP 서버 가이드](mcp-servers.md) - MCP 플래그 활성화 이해
- [세션 관리](session-management.md) - 영구 세션에서 플래그 사용

View File

@ -0,0 +1,340 @@
# SuperClaude MCP 서버 가이드 🔌
## 개요
MCP (Model Context Protocol) 서버는 전문 도구를 통해 Claude Code의 기능을 확장합니다. SuperClaude는 8개의 MCP 서버를 통합하고 작업에 따라 언제 활성화할지에 대한 지침을 Claude에 제공합니다.
### 🔍 현실 확인
- **MCP 서버란**: 추가 도구를 제공하는 외부 Node.js 프로세스
- **MCP 서버가 아닌 것**: 내장된 SuperClaude 기능
- **활성화 방식**: Claude가 컨텍스트에 따라 적절한 서버를 사용하도록 지침을 읽음
- **제공하는 것**: Claude Code의 네이티브 기능을 확장하는 실제 도구
**핵심 서버:**
- **context7**: 공식 라이브러리 문서 및 패턴
- **sequential-thinking**: 다단계 추론 및 분석
- **magic**: 현대적인 UI 컴포넌트 생성
- **playwright**: 브라우저 자동화 및 E2E 테스팅
- **morphllm-fast-apply**: 패턴 기반 코드 변환
- **serena**: 의미론적 코드 이해 및 프로젝트 메모리
- **tavily**: 웹 검색 및 실시간 정보 검색
- **chrome-devtools**: 성능 분석 및 디버깅
## 빠른 시작
**설정 확인**: MCP 서버는 자동으로 활성화됩니다. 설치 및 문제 해결은 [설치 가이드](../Getting-Started/installation.md) 및 [문제 해결](../Reference/troubleshooting.md)을 참조하세요.
**자동 활성화 로직:**
| 요청 포함 | 활성화되는 서버 |
|-----------------|------------------|
| 라이브러리 임포트, API 이름 | **context7** |
| `--think`, 디버깅 | **sequential-thinking** |
| `component`, `UI`, frontend | **magic** |
| `test`, `e2e`, `browser` | **playwright** |
| 다중 파일 편집, 리팩토링 | **morphllm-fast-apply** |
| 대규모 프로젝트, 세션 | **serena** |
| `/sc:research`, `latest`, `current` | **tavily** |
| `performance`, `debug`, `LCP` | **chrome-devtools** |
## 서버 세부정보
### context7 📚
**목적**: 공식 라이브러리 문서 액세스
**트리거**: Import 문, 프레임워크 키워드, 문서 요청
**요구사항**: Node.js 16+, API 키 불필요
```bash
# 자동 활성화
/sc:implement "React 인증 시스템"
# → 공식 React 패턴 제공
# 수동 활성화
/sc:analyze auth-system/ --c7
```
### sequential-thinking 🧠
**목적**: 구조화된 다단계 추론 및 체계적 분석
**트리거**: 복잡한 디버깅, `--think` 플래그, 아키텍처 분석
**요구사항**: Node.js 16+, API 키 불필요
```bash
# 자동 활성화
/sc:troubleshoot "API 성능 문제"
# → 체계적인 근본 원인 분석 활성화
# 수동 활성화
/sc:analyze --think-hard architecture/
```
### magic ✨
**목적**: 21st.dev 패턴에서 현대적인 UI 컴포넌트 생성
**트리거**: UI 요청, `/ui` 명령어, 컴포넌트 개발
**요구사항**: Node.js 16+, TWENTYFIRST_API_KEY ()
```bash
# 자동 활성화
/sc:implement "반응형 대시보드 컴포넌트"
# → 현대적인 패턴으로 접근 가능한 UI 생성
# API 키 설정
export TWENTYFIRST_API_KEY="your_key_here"
```
### playwright 🎭
**목적**: 실제 브라우저 자동화 및 E2E 테스팅
**트리거**: 브라우저 테스팅, E2E 시나리오, 시각적 검증
**요구사항**: Node.js 16+, API 키 불필요
```bash
# 자동 활성화
/sc:test --type e2e "사용자 로그인 흐름"
# → 브라우저 자동화 테스팅 활성화
# 수동 활성화
/sc:validate "접근성 규정 준수" --play
```
### morphllm-fast-apply 🔄
**목적**: 효율적인 패턴 기반 코드 변환
**트리거**: 다중 파일 편집, 리팩토링, 프레임워크 마이그레이션
**요구사항**: Node.js 16+, MORPH_API_KEY
```bash
# 자동 활성화
/sc:improve legacy-codebase/ --focus maintainability
# → 파일 전반에 일관된 패턴 적용
# API 키 설정
export MORPH_API_KEY="your_key_here"
```
### serena 🧭
**목적**: 프로젝트 메모리를 갖춘 의미론적 코드 이해
**트리거**: 심볼 작업, 대규모 코드베이스, 세션 관리
**요구사항**: Python 3.9+, uv 패키지 매니저, API 키 불필요
```bash
# 자동 활성화
/sc:load existing-project/
# → 프로젝트 이해 및 메모리 구축
# 수동 활성화
/sc:refactor "UserService 추출" --serena
```
### tavily 🔍
**목적**: 연구를 위한 웹 검색 및 실시간 정보 검색
**트리거**: `/sc:research` 명령어, "최신" 정보 요청, 최신 이벤트, 사실 확인
**요구사항**: Node.js 16+, TAVILY_API_KEY (https://app.tavily.com에서 무료 티어 사용 가능)
```bash
# 자동 활성화
/sc:research "2024년 최신 AI 개발"
# → 지능형 웹 연구 수행
# 수동 활성화
/sc:analyze "시장 트렌드" --tavily
# API 키 설정 (https://app.tavily.com에서 무료 키 받기)
export TAVILY_API_KEY="tvly-your_api_key_here"
```
### chrome-devtools 📊
**목적**: 성능 분석, 디버깅, 실시간 브라우저 검사
**트리거**: 성능 감사, 레이아웃 문제 디버깅 (예: CLS), 느린 로딩 시간 (LCP), 콘솔 오류, 네트워크 요청
**요구사항**: Node.js 16+, API 키 불필요
```bash
# 자동 활성화
/sc:debug "페이지 로딩이 느림"
# → Chrome DevTools로 성능 분석 활성화
# 수동 활성화
/sc:analyze --performance "홈페이지"
```
**기능:**
- **웹 검색**: 랭킹 및 필터링을 통한 포괄적인 검색
- **뉴스 검색**: 시간 필터링된 최신 이벤트 및 업데이트
- **콘텐츠 추출**: 검색 결과에서 전체 텍스트 추출
- **도메인 필터링**: 특정 도메인 포함/제외
- **다중 홉 연구**: 발견에 기반한 반복적 검색 (최대 5홉)
**연구 깊이 제어:**
- `--depth quick`: 5-10개 소스, 기본 종합
- `--depth standard`: 10-20개 소스, 구조화된 보고서 (기본값)
- `--depth deep`: 20-40개 소스, 포괄적 분석
- `--depth exhaustive`: 40개 이상 소스, 학술 수준 연구
## 구성
**MCP 구성 파일 (`~/.claude.json`):**
```json
{
"mcpServers": {
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
},
"sequential-thinking": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
},
"magic": {
"command": "npx",
"args": ["@21st-dev/magic"],
"env": {"TWENTYFIRST_API_KEY": "${TWENTYFIRST_API_KEY}"}
},
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
},
"morphllm-fast-apply": {
"command": "npx",
"args": ["@morph-llm/morph-fast-apply"],
"env": {"MORPH_API_KEY": "${MORPH_API_KEY}"}
},
"serena": {
"command": "uvx",
"args": ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "ide-assistant"]
},
"tavily": {
"command": "npx",
"args": ["-y", "tavily-mcp@latest"],
"env": {"TAVILY_API_KEY": "${TAVILY_API_KEY}"}
},
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}
```
## 사용 패턴
**서버 제어:**
```bash
# 특정 서버 활성화
/sc:analyze codebase/ --c7 --seq
# 모든 MCP 서버 비활성화
/sc:implement "간단한 함수" --no-mcp
# 모든 서버 활성화
/sc:design "복잡한 아키텍처" --all-mcp
```
**다중 서버 조정:**
```bash
# 풀스택 개발
/sc:implement "전자상거래 체크아웃"
# → Sequential: 워크플로우 분석
# → Context7: 결제 패턴
# → Magic: UI 컴포넌트
# → Serena: 코드 조직
# → Playwright: E2E 테스팅
```
## 문제 해결
**일반적인 문제:**
- **서버 연결 없음**: Node.js 확인: `node --version` (v16+ 필요)
- **Context7 실패**: 캐시 정리: `npm cache clean --force`
- **Magic/Morphllm 오류**: API 키 없이 예상됨 (유료 서비스)
- **서버 타임아웃**: Claude Code 세션 재시작
**빠른 수정:**
```bash
# 연결 재설정
# Claude Code 세션 재시작
# 종속성 확인
node --version # v16+ 표시되어야 함
# MCP 없이 테스트
/sc:command --no-mcp
# 구성 확인
ls ~/.claude.json
```
**API 키 구성:**
```bash
# Magic 서버용 (UI 생성에 필요)
export TWENTYFIRST_API_KEY="your_key_here"
# Morphllm 서버용 (대량 변환에 필요)
export MORPH_API_KEY="your_key_here"
# Tavily 서버용 (웹 검색에 필요 - 무료 티어 사용 가능)
export TAVILY_API_KEY="tvly-your_key_here"
# 지속성을 위해 셸 프로필에 추가
echo 'export TWENTYFIRST_API_KEY="your_key"' >> ~/.bashrc
echo 'export MORPH_API_KEY="your_key"' >> ~/.bashrc
echo 'export TAVILY_API_KEY="your_key"' >> ~/.bashrc
```
**환경 변수 사용:**
- ✅ `TWENTYFIRST_API_KEY` - Magic MCP 서버 기능에 필요
- ✅ `MORPH_API_KEY` - Morphllm MCP 서버 기능에 필요
- ✅ `TAVILY_API_KEY` - Tavily MCP 서버 기능에 필요 (무료 티어 사용 가능)
- ❌ 문서의 다른 환경 변수 - 예제용, 프레임워크에서 사용하지 않음
- 📝 Magic과 Morphllm은 유료 서비스, Tavily는 무료 티어 있음, 프레임워크는 이들 없이도 작동
## 서버 조합
**API 키 없음 (무료)**:
- context7 + sequential-thinking + playwright + serena
**API 키 1개**:
- 전문 UI 개발을 위해 magic 추가
**API 키 2개**:
- 대규모 리팩토링을 위해 morphllm-fast-apply 추가
**일반적인 워크플로우:**
- **학습**: context7 + sequential-thinking
- **웹 개발**: magic + context7 + playwright
- **엔터프라이즈 리팩토링**: serena + morphllm + sequential-thinking
- **복잡한 분석**: sequential-thinking + context7 + serena
- **심층 연구**: tavily + sequential-thinking + serena + playwright
- **최신 이벤트**: tavily + context7 + sequential-thinking
- **성능 튜닝**: chrome-devtools + sequential-thinking + playwright
## 통합
**SuperClaude 명령어와 함께:**
- 분석 명령어는 자동으로 Sequential + Serena 사용
- 구현 명령어는 Magic + Context7 사용
- 테스팅 명령어는 Playwright + Sequential 사용
- 연구 명령어는 Tavily + Sequential + Playwright 사용
**행동 모드와 함께:**
- 브레인스토밍 모드: 발견을 위한 Sequential
- 작업 관리: 지속성을 위한 Serena
- 오케스트레이션 모드: 최적의 서버 선택
- 심층 연구 모드: Tavily + Sequential + Playwright 조정
**성능 제어:**
- 시스템 부하에 따른 자동 리소스 관리
- 동시성 제어: `--concurrency N` (1-15)
- 제약 조건 하에서 우선순위 기반 서버 선택
## 관련 리소스
**필수 읽기:**
- [명령어 가이드](commands.md) - MCP 서버를 활성화하는 명령어
- [빠른 시작 가이드](../Getting-Started/quick-start.md) - MCP 설정 가이드
**고급 사용:**
- [행동 모드](modes.md) - 모드-MCP 조정
- [에이전트 가이드](agents.md) - 에이전트-MCP 통합
- [세션 관리](session-management.md) - Serena 워크플로우
**기술 참조:**
- [예제 모음](../Reference/examples-cookbook.md) - MCP 워크플로우 패턴
- [기술 아키텍처](../Developer-Guide/technical-architecture.md) - 통합 세부사항

658
Docs/User-Guide-kr/modes.md Normal file
View File

@ -0,0 +1,658 @@
# SuperClaude 행동 모드 가이드 🧠
## ✅ 빠른 확인
`/sc:` 명령어를 사용하여 모드를 테스트하세요 - 작업 복잡성에 따라 자동으로 활성화됩니다. 전체 명령어 참조는 [명령어 가이드](commands.md)를 참조하세요.
## 빠른 참조 표
| 모드 | 목적 | 자동 트리거 | 주요 동작 | 최적 사용처 |
|------|---------|---------------|---------------|---------------|
| **🧠 브레인스토밍** | 대화형 발견 | "brainstorm", "maybe", 모호한 요청 | 소크라테스식 질문, 요구사항 도출 | 새 프로젝트 계획, 불명확한 요구사항 |
| **🔍 내성** | 메타인지 분석 | 오류 복구, "추론 분석" | 투명한 사고 마커 (🤔, 🎯, 💡) | 디버깅, 학습, 최적화 |
| **🔬 심층 연구** | 체계적 조사 마인드셋 | `/sc:research`, 조사 키워드 | 6단계 워크플로우, 증거 기반 추론 | 기술 연구, 최신 이벤트, 시장 분석 |
| **📋 작업 관리** | 복잡한 조정 | >3단계, >2개 디렉토리 | 단계 분해, 메모리 지속성 | 다단계 작업, 프로젝트 관리 |
| **🎯 오케스트레이션** | 지능형 도구 선택 | 다중 도구 작업, 높은 리소스 사용 | 최적의 도구 라우팅, 병렬 실행 | 복잡한 분석, 성능 최적화 |
| **⚡ 토큰 효율성** | 압축 커뮤니케이션 | 높은 컨텍스트 사용, `--uc` 플래그 | 심볼 시스템, 예상 30-50% 토큰 감소 | 리소스 제약, 대규모 작업 |
---
## 시작하기 (2분 개요)
**모드는 행동 지침을 통해 활성화됩니다** - Claude Code가 컨텍스트 파일을 읽어 작업 패턴과 복잡성에 따라 채택할 모드 동작을 결정합니다.
**빠른 예제:**
```bash
# 자동 활성화 예제
/sc:brainstorm "모바일 앱" # → 소크라테스식 발견 질문
/sc:implement "인증 시스템" # → 다단계 조정
"--uc analyze large-codebase/" # → 압축된 심볼 출력
```
**수동 플래그를 사용할 때:**
- 특정 동작 필요: `--brainstorm`, `--introspect`, `--uc`
- 학습/디버깅을 위한 자동 감지 재정의
- 특정 제약(메모리, 시간, 명확성)에 최적화
---
## 모드 세부정보
### 🧠 브레인스토밍 모드 - 대화형 발견
**목적**: 협업 발견을 통해 모호한 아이디어를 구조화된 요구사항으로 변환합니다.
**자동 활성화 트리거:**
- 모호한 프로젝트 요청: "만들고 싶어...", "생각하고 있는데..."
- 탐색 키워드: brainstorm, explore, discuss, figure out, not sure
- 불확실성 지표: "maybe", "possibly", "could we"
- 수동 플래그: `--brainstorm`, `--bs`
**행동 변화:**
- **소크라테스식 질문**: 숨겨진 요구사항을 찾기 위한 탐색 질문
- **비가정적 접근**: 가정을 피하고 발견 방향을 안내하도록 함
- **협업 파트너십**: 지시적 컨설팅이 아닌 탐색에서 함께 작업
- **요구사항 종합**: 통찰력을 구조화된 기술 브리프로 변환
- **교차 세션 메모리**: 후속 토론을 위한 발견 컨텍스트 유지
**예제 경험:**
```
표준 접근법: "JWT 토큰으로 사용자 인증 시스템을 구축하겠습니다..."
브레인스토밍 접근법:
"🤔 함께 탐색해봅시다:
- 인증이 앱에서 해결하는 특정 사용자 문제는 무엇인가요?
- 사용자는 누구이며 기술적 편안함 수준은 어떤가요?
- 통합할 기존 시스템이나 소셜 로그인이 있나요?
- 어떤 보안/규정 준수 요구사항이 있나요?
📝 결과: 구현 준비가 된 상세한 인증 요구사항 브리프"
```
#### 성공 기준
- [ ] 즉각적인 솔루션 대신 질문으로 응답
- [ ] 질문이 사용자 요구, 기술 제약, 비즈니스 목표 탐색
- [ ] 발견 과정 전반에 걸쳐 협업적 어조 유지
- [ ] 결과로 구조화된 요구사항 또는 기술 브리프 생성
**검증:** `/sc:brainstorm "웹 앱"`은 사용자, 기능, 기술에 대해 질문해야 함
**테스트:** 모호한 요청은 가정이 아닌 발견 질문을 트리거해야 함
**확인:** 동일한 대화에서 후속 질문 전반에 걸쳐 모드가 지속되어야 함
**최적의 협업 대상:**
- **→ 작업 관리**: 요구사항 발견 → 체계적인 구현 계획
- **→ 오케스트레이션**: 요구사항 명확성 → 구현을 위한 최적의 도구 선택
- **수동 재정의**: "명확한" 요구사항에도 발견을 강제하려면 `--brainstorm` 사용
---
### 🔍 내성 모드 - 메타인지 분석
**목적**: 학습 최적화 및 투명한 의사결정을 위한 추론 과정 노출
**자동 활성화 트리거:**
- 자기 분석 요청: "내 추론 분석", "결정 성찰"
- 조사가 필요한 오류 복구 시나리오 및 예상치 못한 결과
- 여러 가능한 접근법이 있는 복잡한 문제 해결
- 최적화 기회를 위한 패턴 인식 필요
- 수동 플래그: `--introspect`
**행동 변화:**
- **추론 투명성**: 명확한 마커로 사고 과정 노출 (🤔, 🎯, ⚡, 📊, 💡)
- **결정 분석**: 선택 논리 평가 및 대안 접근법 고려
- **패턴 인식**: 반복되는 행동 및 개선 기회 식별
- **메타 학습**: 지속적인 프레임워크 개선을 위한 통찰력 추출
- **프레임워크 규정 준수**: SuperClaude 원칙 및 품질 게이트에 대한 행동 검증
**예제 경험:**
```
표준 접근법: "이 코드 구조를 분석하고 개선 사항을 제안하겠습니다..."
내성적 접근법:
"🧠 메타 분석: 왜 기능 흐름보다 구조적 분석을 선택했을까?
🎯 결정 논리: 클래스 계층 구조 확인 → OOP 패턴 우세 가정
🔄 고려된 대안: 데이터 흐름 분석이 숨겨진 종속성 드러낼 수 있음
📊 증거 확인: 파일 임포트가 OOP가 아닌 함수형 구성 시사
💡 학습: 분석 전략 선택 전에 임포트 분석 필요
⚡ 수정: 함수형 흐름 분석 접근법으로 전환"
```
**최적의 협업 대상:**
- **→ 작업 관리**: 복잡한 단계 결정에 대한 투명한 추론 제공
- **모든 모드**: 다른 모드의 작업에 추론 투명성 레이어 추가
- **수동 재정의**: 학습 세션 및 디버깅 워크플로우에 `--introspect` 사용
---
### 🔬 심층 연구 모드 - 체계적 조사 마인드셋
**목적**: 체계적 조사 및 증거 기반 추론을 위한 연구 마인드셋
**자동 활성화 트리거:**
- `/sc:research` 명령어 호출
- 연구 관련 키워드: investigate, explore, discover, analyze
- 지식 컷오프를 넘어선 최신 정보가 필요한 질문
- 복잡한 연구 요구사항
- 수동 플래그: `--research`
**행동 수정:**
- **사고 스타일**: 캐주얼보다 체계적, 가정보다 증거, 점진적 깊이 탐색
- **커뮤니케이션**: 신뢰 수준으로 시작, 인라인 인용 제공, 불확실성 인정
- **우선순위 전환**: 속도보다 완전성, 추측보다 정확성, 가정보다 검증
- **프로세스 적응**: 항상 조사 계획 생성, 병렬 작업 기본값, 증거 체인 유지
**6단계 연구 워크플로우:**
- 📋 **이해** (5-10%): 쿼리 복잡성 및 요구사항 평가
- 📝 **계획** (10-15%): 전략 선택 (planning/intent/unified) 및 병렬화 식별
- ✅ **TodoWrite** (5%): 복잡성에 따라 적응형 작업 계층 구조 생성 (3-15개 작업)
- 🔄 **실행** (50-60%): 병렬 우선 검색 및 스마트 추출 라우팅
- 📊 **추적** (지속적): 진행 상황 모니터링 및 신뢰도 점수 업데이트
- ✓ **검증** (10-15%): 증거 체인 확인 및 완전성 보장
**예제 경험:**
```
표준 모드: "양자 컴퓨팅에 대한 검색 결과입니다..."
심층 연구 모드:
"📊 연구 계획: 양자 컴퓨팅 돌파구
✓ TodoWrite: 8개 연구 작업 생성
🔄 도메인 전반에 걸쳐 병렬 검색 실행
📈 신뢰도: 15개 검증된 소스에서 0.82
📝 보고서 저장됨: claudedocs/research_quantum_[timestamp].md"
```
#### 품질 표준
- [ ] 인라인 인용이 있는 주장당 최소 2개 소스
- [ ] 모든 발견에 대한 신뢰도 점수 (0.0-1.0)
- [ ] 독립적인 작업에 대한 병렬 실행 기본값
- [ ] 적절한 구조로 claudedocs/에 보고서 저장
- [ ] 명확한 방법론 및 증거 제시
**검증:** `/sc:research "테스트 주제"`는 TodoWrite를 생성하고 체계적으로 실행해야 함
**테스트:** 모든 연구에 신뢰도 점수 및 인용이 포함되어야 함
**확인:** 보고서가 자동으로 claudedocs/에 저장되어야 함
**최적의 협업 대상:**
- **→ 작업 관리**: TodoWrite 통합을 통한 연구 계획
- **→ 오케스트레이션**: 병렬 Tavily/Playwright 조정
- **수동 재정의**: 세밀한 제어를 위해 `--depth``--strategy` 사용
---
### 📋 작업 관리 모드 - 복잡한 조정
**목적**: 다단계 작업을 위한 세션 지속성을 갖춘 계층적 작업 조직
**자동 활성화 트리거:**
- >3개의 조정된 단계가 필요한 작업
- 다중 파일/디렉토리 범위 (>2개 디렉토리 또는 >3개 파일)
- 단계 및 체크포인트가 필요한 복잡한 종속성
- 품질 개선 요청: polish, refine, enhance
- 수동 플래그: `--task-manage`, `--delegate`
**행동 변화:**
- **계층적 계획**: 복잡한 작업을 Plan → Phase → Task → Todo 구조로 분해
- **세션 지속성**: 중단 전반에 걸쳐 프로젝트 컨텍스트 및 진행 상황 유지
- **메모리 통합**: 상태 보존을 위해 write_memory/read_memory 사용
- **진행 오케스트레이션**: 추적을 위해 TodoWrite와 메모리 업데이트 조정
- **품질 게이트**: 단계 간 체계적인 검증 체크포인트 구현
**예제 경험:**
```
표준 접근법: "사용자 인증을 구현하겠습니다..." → 직접 구현
작업 관리 접근법:
"📋 다단계 구현 계획:
🎯 1단계: 보안 요구사항 분석 (세션 1)
🎯 2단계: API 설계 및 문서화 (세션 2)
🎯 3단계: 구현 및 테스팅 (세션 3-4)
🎯 4단계: 통합 및 검증 (세션 5)
💾 세션 지속성: 자동으로 컨텍스트 재개
✓ 품질 게이트: 각 단계 전환 전 검증"
```
**최적의 협업 대상:**
- **브레인스토밍 →**: 요구사항 발견 후 체계적인 구현
- **+ 오케스트레이션**: 최적의 도구 선택을 통한 작업 조정
- **+ 내성**: 복잡한 단계 결정에 대한 투명한 추론
---
### 🎯 오케스트레이션 모드 - 지능형 도구 선택
**목적**: 지능형 도구 라우팅 및 병렬 조정을 통한 작업 실행 최적화
**자동 활성화 트리거:**
- 정교한 조정이 필요한 다중 도구 작업
- 성능 제약 (높은 리소스 사용)
- 병렬 실행 기회 (>3개 독립적 파일/작업)
- 여러 유효한 도구 접근법이 있는 복잡한 라우팅 결정
**행동 변화:**
- **지능형 도구 라우팅**: 각 작업 유형에 최적의 MCP 서버 및 네이티브 도구 선택
- **리소스 인식**: 시스템 제약 및 가용성에 따라 접근법 조정
- **병렬 최적화**: 동시 실행을 위한 독립적인 작업 식별
- **조정 초점**: 조정된 실행을 통한 도구 선택 및 사용 최적화
- **적응형 폴백**: 선호하는 옵션을 사용할 수 없을 때 도구를 우아하게 전환
**예제 경험:**
```
표준 접근법: 순차적 파일별 분석 및 편집
오케스트레이션 접근법:
"🎯 다중 도구 조정 전략:
🔍 1단계: Serena (의미론적 분석) + Sequential (아키텍처 검토)
⚡ 2단계: Morphllm (패턴 편집) + Magic (UI 컴포넌트)
🧪 3단계: Playwright (테스팅) + Context7 (문서 패턴)
🔄 병렬 실행: 3개 도구 동시 작업"
```
**최적의 협업 대상:**
- **작업 관리 →**: 복잡한 다단계 계획을 위한 도구 조정 제공
- **+ 토큰 효율성**: 압축 커뮤니케이션을 통한 최적의 도구 선택
- **모든 복잡한 작업**: 실행을 향상시키기 위한 지능형 도구 라우팅 추가
---
### ⚡ 토큰 효율성 모드 - 압축 커뮤니케이션
**목적**: 정보 품질을 유지하면서 심볼 시스템을 통해 예상 30-50% 토큰 감소 달성
**자동 활성화 트리거:**
- 제한에 근접한 높은 컨텍스트 사용
- 리소스 효율성이 필요한 대규모 작업
- 사용자 명시적 플래그: `--uc`, `--ultracompressed`
- 여러 출력이 있는 복잡한 분석 워크플로우
**행동 변화:**
- **심볼 커뮤니케이션**: 논리 흐름, 상태, 기술 도메인을 위한 시각적 심볼 사용
- **기술 약어**: 반복되는 기술 용어에 대한 컨텍스트 인식 압축
- **구조화된 밀도**: 장황한 단락보다 글머리 기호, 표, 간결한 형식
- **정보 보존**: 압축에도 불구하고 ≥95% 정보 품질 유지
- **구조화된 형식**: 명확성 및 작업 완료를 위해 조직화
**예제 경험:**
```
표준 접근법: "인증 시스템 구현은 즉각적인 주의가 필요한 사용자 검증 함수의 보안 취약점을 보여줍니다..."
토큰 효율적 접근법:
"🛡️ 보안 경고:
auth.js:45 → user val() → 중요한 취약점
📊 영향: ❌ 토큰 우회 가능
⚡ 조치: 검증 수정 + 감사 ∵ 높은 심각도
🔧 예상: 2시간 구현 + 1시간 테스트"
```
**최적의 협업 대상:**
- **모든 모드**: 모드별 동작을 유지하면서 압축 레이어 추가
- **오케스트레이션 →**: 압축된 도구 조정 및 상태 업데이트
- **수동 재정의**: 컨텍스트 압박 또는 효율성이 우선순위일 때 `--uc` 사용
---
### 🎨 표준 모드 - 균형 잡힌 기본값
**목적**: 간단한 개발 작업을 위한 명확하고 전문적인 커뮤니케이션 제공
**자동 활성화 트리거:**
- 복잡성 지표가 없는 간단하고 잘 정의된 작업
- 명확한 요구사항이 있는 단일 파일 작업
- 기본 설명 및 표준 개발 워크플로우
- 다른 모드 트리거가 감지되지 않음 (기본 폴백)
**행동 변화:**
- **전문적 커뮤니케이션**: 압축 없이 명확하고 간결한 기술 언어
- **적당한 세부사항**: 대부분의 개발 작업에 적합한 균형 잡힌 정보 깊이
- **표준 도구 선택**: 네이티브 Claude 기능 및 기본 도구 사용
- **품질 초점**: 복잡한 오케스트레이션 오버헤드 없이 코드 품질 유지
- **반응형 적응**: 복잡성이 증가할 때 전문 모드로 전환할 준비
**예제 경험:**
```
표준 접근법: 모든 작업에 대한 일관되고 전문적인 기준선
"적절한 오류 처리와 함께 로그인 함수를 구현하겠습니다:
1. 사용자 입력 검증 (이메일 형식, 비밀번호 요구사항)
2. 안전한 해싱으로 데이터베이스에 대해 인증
3. 적절한 만료를 갖춘 JWT 토큰 생성
4. 사용자 데이터와 함께 성공 응답 반환
구현은 보안 모범 사례를 따르고 포괄적인 오류 처리를 포함할 것입니다."
```
**최적의 협업 대상:**
- **→ 모든 모드**: 다른 모드가 향상시키는 기준선 역할
- **모드 전환**: 필요할 때 자동으로 전문 모드로 확장
- **명확성 우선순위**: 간단한 커뮤니케이션이 최적화보다 중요할 때
---
## 고급 사용
### 모드 조합
**다중 모드 워크플로우:**
```bash
# 발견 → 계획 → 구현
/sc:brainstorm "마이크로서비스 아키텍처" --task-manage
# → 브레인스토밍: 요구사항 발견
# → 작업 관리: 다단계 조정
# 투명성 및 효율성을 갖춘 분석
/sc:analyze legacy-system/ --introspect --uc
# → 내성: 투명한 추론
# → 토큰 효율성: 압축된 출력
```
### 수동 모드 제어
**특정 동작 강제:**
- `--brainstorm`: 모든 작업에 대한 협업 발견 강제
- `--introspect`: 모든 모드에 추론 투명성 추가
- `--task-manage`: 계층적 조정 활성화
- `--orchestrate`: 도구 선택 및 병렬 실행 최적화
- `--uc`: 효율성을 위해 커뮤니케이션 압축
**재정의 예제:**
```bash
# "명확한" 요구사항에 브레인스토밍 강제
/sc:implement "사용자 로그인" --brainstorm
# 디버깅에 추론 투명성 추가
# 투명한 추론으로 인증 문제 디버그
# 간단한 작업에 작업 관리 활성화
# 체계적인 작업 관리로 styles.css 업데이트
```
### 모드 경계 및 우선순위
**모드가 활성화되는 시점:**
1. **복잡성 임계값**: >3개 파일 → 작업 관리
2. **리소스 압박**: 높은 컨텍스트 사용 → 토큰 효율성
3. **다중 도구 필요**: 복잡한 분석 → 오케스트레이션
4. **불확실성**: 모호한 요구사항 → 브레인스토밍
5. **오류 복구**: 문제 → 내성
**우선순위 규칙:**
- **안전 우선**: 품질 및 검증이 항상 효율성 재정의
- **사용자 의도**: 수동 플래그가 자동 감지 재정의
- **컨텍스트 적응**: 모드가 복잡성에 따라 스택됨
- **리소스 관리**: 압박 하에서 효율성 모드 활성화
---
## 실제 예제
### 완전한 워크플로우 예제
**새 프로젝트 개발:**
```bash
# 1단계: 발견 (브레인스토밍 모드 자동 활성화)
"생산성 앱을 만들고 싶어요"
→ 🤔 사용자, 기능, 플랫폼 선택에 대한 소크라테스식 질문
→ 📝 구조화된 요구사항 브리프
# 2단계: 계획 (작업 관리 모드 자동 활성화)
/sc:implement "핵심 생산성 기능"
→ 📋 종속성이 있는 다단계 분해
→ 🎯 품질 게이트를 갖춘 단계 조정
# 3단계: 구현 (오케스트레이션 모드가 도구 조정)
/sc:implement "프론트엔드 및 백엔드 시스템"
→ 🎯 Magic (UI) + Context7 (패턴) + Sequential (아키텍처)
→ ⚡ 병렬 실행 최적화
```
**복잡한 문제 디버깅:**
```bash
# 문제 분석 (내성 모드 자동 활성화)
"사용자가 간헐적인 인증 실패를 겪고 있어요"
→ 🤔 잠재적 원인에 대한 투명한 추론
→ 🎯 가설 형성 및 증거 수집
→ 💡 유사한 문제 전반의 패턴 인식
# 체계적 해결 (작업 관리가 조정)
# 인증 시스템 포괄적으로 수정
→ 📋 1단계: 근본 원인 분석
→ 📋 2단계: 솔루션 구현
→ 📋 3단계: 테스팅 및 검증
```
### 모드 조합 패턴
**높은 복잡성 시나리오:**
```bash
# 여러 제약이 있는 대규모 리팩토링
/sc:improve legacy-system/ --introspect --uc --orchestrate
→ 🔍 투명한 추론 (내성)
→ ⚡ 압축 커뮤니케이션 (토큰 효율성)
→ 🎯 최적의 도구 조정 (오케스트레이션)
→ 📋 체계적 단계 (작업 관리 자동 활성화)
```
---
## 빠른 참조
### 모드 활성화 패턴
| 트리거 유형 | 예제 입력 | 활성화된 모드 | 주요 동작 |
|--------------|---------------|----------------|--------------|
| **모호한 요청** | "앱을 만들고 싶어요" | 🧠 브레인스토밍 | 소크라테스식 발견 질문 |
| **복잡한 범위** | >3개 파일 또는 >2개 디렉토리 | 📋 작업 관리 | 단계 조정 |
| **다중 도구 필요** | 분석 + 구현 | 🎯 오케스트레이션 | 도구 최적화 |
| **오류 복구** | "예상대로 작동하지 않아요" | 🔍 내성 | 투명한 추론 |
| **리소스 압박** | 높은 컨텍스트 사용 | ⚡ 토큰 효율성 | 심볼 압축 |
| **간단한 작업** | "이 함수 수정" | 🎨 표준 | 명확하고 직접적인 접근 |
### 수동 재정의 명령어
```bash
# 특정 모드 동작 강제
/sc:command --brainstorm # 협업 발견
/sc:command --introspect # 추론 투명성
/sc:command --task-manage # 계층적 조정
/sc:command --orchestrate # 도구 최적화
/sc:command --uc # 토큰 압축
# 여러 모드 결합
/sc:command --introspect --uc # 투명 + 효율적
/sc:command --task-manage --orchestrate # 조정 + 최적화
```
---
## 문제 해결
문제 해결 도움말은 다음을 참조하세요:
- [일반적인 문제](../Reference/common-issues.md) - 자주 발생하는 문제에 대한 빠른 수정
- [문제 해결 가이드](../Reference/troubleshooting.md) - 포괄적인 문제 해결
### 일반적인 문제
- **모드가 활성화되지 않음**: 수동 플래그 사용: `--brainstorm`, `--introspect`, `--uc`
- **잘못된 모드 활성화**: 요청의 복잡성 트리거 및 키워드 확인
- **모드가 예기치 않게 전환됨**: 작업 진화에 따른 정상적인 동작
- **실행 영향**: 모드는 도구 사용 최적화, 실행에 영향을 주지 않아야 함
- **모드 충돌**: [플래그 가이드](flags.md)의 플래그 우선순위 규칙 확인
### 즉각적인 수정
- **특정 모드 강제**: `--brainstorm` 또는 `--task-manage`와 같은 명시적 플래그 사용
- **모드 동작 재설정**: 모드 상태를 재설정하려면 Claude Code 세션 재시작
- **모드 지표 확인**: 응답에서 🤔, 🎯, 📋 심볼 찾기
- **복잡성 확인**: 간단한 작업은 표준 모드 사용, 복잡한 작업은 자동 전환
### 모드별 문제 해결
**브레인스토밍 모드 문제:**
```bash
# 문제: 모드가 질문 대신 솔루션 제공
# 빠른 수정: 요청 명확성 확인 및 명시적 플래그 사용
/sc:brainstorm "웹 앱" --brainstorm # 발견 모드 강제
"...에 대한 모호한 아이디어가 있어요" # 불확실성 언어 사용
"...를 구축할 수 있을까요" # 탐색 트리거
```
**작업 관리 모드 문제:**
```bash
# 문제: 간단한 작업이 복잡한 조정을 받음
# 빠른 수정: 범위 줄이기 또는 더 간단한 명령어 사용
/sc:implement "함수" --no-task-manage # 조정 비활성화
/sc:troubleshoot bug.js # 기본 명령어 사용
# 작업이 정말 복잡한지 확인 (>3개 파일, >2개 디렉토리)
```
**토큰 효율성 모드 문제:**
```bash
# 문제: 출력이 너무 압축되거나 불명확함
# 빠른 수정: 명확성을 위해 압축 비활성화
/sc:command --no-uc # 압축 비활성화
/sc:command --verbose # 상세 출력 강제
# 명확성이 효율성보다 중요할 때 사용
```
**내성 모드 문제:**
```bash
# 문제: 너무 많은 메타 주석, 충분한 행동 없음
# 빠른 수정: 직접 작업을 위해 내성 비활성화
/sc:command --no-introspect # 직접 실행
# 학습 및 디버깅에만 내성 사용
```
**오케스트레이션 모드 문제:**
```bash
# 문제: 도구 조정이 혼란 야기
# 빠른 수정: 도구 사용 단순화
/sc:command --no-mcp # 네이티브 도구만
/sc:command --simple # 기본 실행
# 작업 복잡성이 오케스트레이션을 정당화하는지 확인
```
### 오류 코드 참조
| 모드 오류 | 의미 | 빠른 수정 |
|------------|---------|-----------|
| **B001** | 브레인스토밍 활성화 실패 | 명시적 `--brainstorm` 플래그 사용 |
| **T001** | 작업 관리 오버헤드 | 간단한 작업에 `--no-task-manage` 사용 |
| **U001** | 토큰 효율성이 너무 공격적 | `--verbose` 또는 `--no-uc` 사용 |
| **I001** | 내성 모드 정체 | 직접 행동을 위해 `--no-introspect` 사용 |
| **O001** | 오케스트레이션 조정 실패 | `--no-mcp` 또는 `--simple` 사용 |
| **M001** | 모드 충돌 감지 | 플래그 우선순위 규칙 확인 |
| **M002** | 모드 전환 루프 | 상태를 재설정하려면 세션 재시작 |
| **M003** | 모드를 인식할 수 없음 | SuperClaude 업데이트 또는 철자 확인 |
### 점진적 지원 수준
**수준 1: 빠른 수정 (< 2분)**
- 자동 모드 선택을 재정의하려면 수동 플래그 사용
- 작업 복잡성이 예상 모드 동작과 일치하는지 확인
- Claude Code 세션 재시작 시도
**수준 2: 상세 도움말 (5-15분)**
```bash
# 모드별 진단
/sc:help modes # 사용 가능한 모든 모드 나열
/sc:reflect --type mode-status # 현재 모드 상태 확인
# 요청 복잡성 및 트리거 검토
```
- 모드 설치 문제는 [일반적인 문제 가이드](../Reference/common-issues.md) 참조
**수준 3: 전문가 지원 (30분 이상)**
```bash
# 심층 모드 분석
SuperClaude install --diagnose
# 모드 활성화 패턴 확인
# 행동 트리거 및 임계값 검토
```
- 행동 모드 분석은 [진단 참조 가이드](../Reference/diagnostic-reference.md) 참조
**수준 4: 커뮤니티 지원**
- [GitHub Issues](https://github.com/SuperClaude-Org/SuperClaude_Framework/issues)에서 모드 문제 보고
- 예상치 못한 모드 동작 예제 포함
- 원하는 모드 활성화 vs 실제 모드 활성화 설명
### 성공 검증
모드 수정 적용 후 다음으로 테스트:
- [ ] 간단한 요청은 표준 모드 사용 (명확하고 직접적인 응답)
- [ ] 복잡한 요청은 적절한 모드 자동 활성화 (조정, 추론)
- [ ] 수동 플래그가 자동 감지를 올바르게 재정의
- [ ] 예상될 때 모드 지표 (🤔, 🎯, 📋) 나타남
- [ ] 다양한 모드 전반에 걸쳐 성능이 양호하게 유지됨
## 빠른 문제 해결 (레거시)
- **모드가 활성화되지 않음** → 수동 플래그 사용: `--brainstorm`, `--introspect`, `--uc`
- **잘못된 모드 활성화** → 요청의 복잡성 트리거 및 키워드 확인
- **모드가 예기치 않게 전환됨** → 작업 진화에 따른 정상적인 동작
- **실행 영향** → 모드는 도구 사용 최적화, 실행에 영향을 주지 않아야 함
- **모드 충돌** → [플래그 가이드](flags.md)의 플래그 우선순위 규칙 확인
## 자주 묻는 질문
**Q: 어떤 모드가 활성화되어 있는지 어떻게 알 수 있나요?**
A: 커뮤니케이션 패턴에서 이러한 지표를 찾으세요:
- 🤔 발견 질문 → 브레인스토밍
- 🎯 추론 투명성 → 내성
- 단계 분해 → 작업 관리
- 도구 조정 → 오케스트레이션
- 심볼 압축 → 토큰 효율성
**Q: 특정 모드를 강제할 수 있나요?**
A: 예, 자동 감지를 재정의하려면 수동 플래그 사용:
```bash
/sc:command --brainstorm # 발견 강제
/sc:command --introspect # 투명성 추가
/sc:command --task-manage # 조정 활성화
/sc:command --uc # 출력 압축
```
**Q: 모드가 실행에 영향을 미치나요?**
A: 모드는 조정을 통해 도구 사용 최적화:
- **토큰 효율성**: 30-50% 컨텍스트 감소
- **오케스트레이션**: 병렬 처리
- **작업 관리**: 체계적인 계획을 통한 재작업 방지
**Q: 모드가 함께 작동할 수 있나요?**
A: 예, 모드는 서로를 보완하도록 설계됨:
- **작업 관리**가 다른 모드 조정
- **토큰 효율성**이 모든 모드의 출력 압축
- **내성**이 모든 워크플로우에 투명성 추가
---
## 요약
SuperClaude의 5가지 행동 모드는 필요에 따라 자동으로 일치하는 **지능형 적응 시스템**을 만듭니다:
- **🧠 브레인스토밍**: 모호한 아이디어를 명확한 요구사항으로 변환
- **🔍 내성**: 학습 및 디버깅을 위한 투명한 추론 제공
- **📋 작업 관리**: 복잡한 다단계 작업 조정
- **🎯 오케스트레이션**: 도구 선택 및 병렬 실행 최적화
- **⚡ 토큰 효율성**: 명확성을 유지하면서 커뮤니케이션 압축
- **🎨 표준**: 간단한 작업을 위한 전문적 기준선 유지
**핵심 인사이트**: 모드에 대해 생각할 필요가 없습니다 - 개발 경험을 향상시키기 위해 투명하게 작동합니다. 달성하고자 하는 것을 설명하면 SuperClaude가 자동으로 필요에 맞게 접근 방식을 조정합니다.
---
## 관련 가이드
**학습 진행:**
**🌱 필수 (1주차)**
- [빠른 시작 가이드](../Getting-Started/quick-start.md) - 모드 활성화 예제
- [명령어 참조](commands.md) - 명령어가 자동으로 모드 활성화
- [설치 가이드](../Getting-Started/installation.md) - 행동 모드 설정
**🌿 중급 (2-3주차)**
- [에이전트 가이드](agents.md) - 모드가 전문가와 조정하는 방법
- [플래그 가이드](flags.md) - 수동 모드 제어 및 최적화
- [예제 모음](../Reference/examples-cookbook.md) - 실제 모드 패턴
**🌲 고급 (2개월 이상)**
- [MCP 서버](mcp-servers.md) - 향상된 기능과의 모드 통합
- [세션 관리](session-management.md) - 작업 관리 모드 워크플로우
- [시작하기](../Getting-Started/quick-start.md) - 모드 사용 패턴
**🔧 전문가**
- [기술 아키텍처](../Developer-Guide/technical-architecture.md) - 모드 구현 세부사항
- [코드 기여](../Developer-Guide/contributing-code.md) - 모드 기능 확장
**모드별 가이드:**
- **브레인스토밍**: [요구사항 발견 패턴](../Reference/examples-cookbook.md#requirements)
- **작업 관리**: [세션 관리 가이드](session-management.md)
- **오케스트레이션**: [MCP 서버 가이드](mcp-servers.md)
- **토큰 효율성**: [명령어 기본사항](commands.md#token-efficiency)

View File

@ -0,0 +1,311 @@
# 세션 관리 가이드
SuperClaude는 Serena MCP 서버를 통해 영구 세션 관리를 제공하여 Claude Code 대화 전반에 걸쳐 진정한 컨텍스트 보존과 장기 프로젝트 연속성을 가능하게 합니다.
## 영구 메모리를 사용한 핵심 세션 명령어
### `/sc:load` - 영구 메모리를 사용한 컨텍스트 로딩
**목적**: 이전 세션의 프로젝트 컨텍스트 및 영구 메모리로 세션 초기화
**MCP 통합**: Serena MCP가 저장된 프로젝트 메모리를 읽도록 트리거
**구문**: `/sc:load [프로젝트_경로]`
**발생하는 일**:
- Serena MCP가 이전 세션의 영구 메모리 파일 읽기
- 저장된 메모리에서 프로젝트 컨텍스트 복원
- 이전 결정, 패턴, 진행 상황 로드
- 과거 컨텍스트로 세션 상태 초기화
**사용 사례**:
```bash
# 영구 메모리에서 기존 프로젝트 컨텍스트 로드
/sc:load src/
# 전체 기록과 함께 특정 프로젝트 작업 재개
/sc:load "authentication-system"
# 코드베이스 분석 및 이전 통찰력으로 초기화
/sc:load . --analyze
```
### `/sc:save` - 메모리에 세션 지속성
**목적**: 현재 세션 상태 및 결정을 영구 메모리에 저장
**MCP 통합**: Serena MCP가 메모리 파일을 작성하도록 트리거
**구문**: `/sc:save "세션_설명"`
**발생하는 일**:
- 현재 컨텍스트 및 결정이 Serena 메모리에 작성됨
- 프로젝트 상태 및 진행 상황이 대화 전반에 걸쳐 지속됨
- 주요 통찰력 및 패턴이 향후 세션을 위해 저장됨
- 검색을 위한 타임스탬프와 함께 세션 요약 생성
**사용 사례**:
```bash
# 향후 참조를 위해 완료된 기능 작업 저장
/sc:save "JWT로 사용자 인증 구현됨"
# 복잡한 작업 중 체크포인트
/sc:save "API 설계 단계 완료, 구현 준비"
# 아키텍처 결정을 영구적으로 저장
/sc:save "마이크로서비스 아키텍처 결정, 서비스 경계 정의됨"
```
### `/sc:reflect` - 메모리 컨텍스트를 사용한 진행 상황 평가
**목적**: 저장된 메모리에 대한 현재 진행 상황 분석 및 세션 완전성 검증
**MCP 통합**: Serena MCP를 사용하여 저장된 메모리에 대한 현재 상태 비교
**구문**: `/sc:reflect [--scope project|session]`
**발생하는 일**:
- Serena MCP가 이전 메모리 및 현재 컨텍스트 읽기
- 저장된 목표 및 마일스톤에 대한 진행 상황 평가
- 과거 컨텍스트를 사용하여 격차 및 다음 단계 식별
- 프로젝트 메모리에 대한 세션 완전성 검증
**사용 사례**:
```bash
# 저장된 마일스톤에 대한 프로젝트 진행 상황 평가
/sc:reflect --scope project
# 현재 세션 완전성 검증
/sc:reflect
# 메모리를 기반으로 다음 단계로 이동할 준비가 되었는지 확인
/sc:reflect --scope session
```
## 영구 메모리 아키텍처
### Serena MCP가 진정한 지속성을 가능하게 하는 방법
**메모리 저장**:
- 구조화된 메모리 파일로 저장된 세션 컨텍스트
- 영구적으로 보존된 프로젝트 결정 및 아키텍처 패턴
- 대화 전반에 걸쳐 유지되는 코드 분석 결과 및 통찰력
- 장기적으로 유지되는 진행 상황 추적 및 마일스톤 데이터
**교차 세션 연속성**:
- 새 대화에서 자동으로 사용 가능한 이전 세션 컨텍스트
- 대화 전반에 걸쳐 보존되고 액세스 가능한 결정 및 근거
- 과거 패턴 및 솔루션으로부터의 학습 유지
- 무기한 유지되는 일관된 프로젝트 이해
**메모리 유형**:
- **프로젝트 메모리**: 장기 프로젝트 컨텍스트 및 아키텍처
- **세션 메모리**: 특정 대화 결과 및 결정
- **패턴 메모리**: 재사용 가능한 솔루션 및 아키텍처 패턴
- **진행 메모리**: 마일스톤 추적 및 완료 상태
## 지속성을 갖춘 세션 라이프사이클 패턴
### 새 프로젝트 초기화
```bash
# 1. 새 프로젝트 시작
/sc:brainstorm "전자상거래 플랫폼 요구사항"
# 2. 초기 결정을 영구 메모리에 저장
/sc:save "프로젝트 범위 및 요구사항 정의됨"
# 3. 구현 계획 시작
/sc:workflow "사용자 인증 시스템"
# 4. 아키텍처 결정을 영구적으로 저장
/sc:save "인증 아키텍처: JWT + 리프레시 토큰 + 속도 제한"
```
### 기존 작업 재개 (교차 대화)
```bash
# 1. 영구 메모리에서 이전 컨텍스트 로드
/sc:load "e-commerce-project"
# 2. 저장된 진행 상황에 대한 현재 상태 평가
/sc:reflect --scope project
# 3. 저장된 컨텍스트를 사용하여 다음 단계 계속
/sc:implement "결제 처리 통합"
# 4. 진행 상황 체크포인트를 메모리에 저장
/sc:save "Stripe API와 결제 시스템 통합됨"
```
### 장기 프로젝트 관리
```bash
# 지속성을 갖춘 주간 체크포인트 패턴
/sc:load project-name
/sc:reflect --scope project
# ... 기능 작업 ...
/sc:save "N주차 진행: 기능 X, Y, Z 완료"
# 메모리를 사용한 단계 완료 패턴
/sc:reflect --scope project
/sc:save "1단계 완료: 핵심 인증 및 사용자 관리"
/sc:workflow "2단계: 결제 및 주문 처리"
```
## 교차 대화 연속성
### 지속성을 갖춘 새 대화 시작
새 Claude Code 대화를 시작할 때 영구 메모리 시스템이 다음을 허용합니다:
1. **자동 컨텍스트 복원**
```bash
/sc:load project-name
# 모든 이전 컨텍스트, 결정, 진행 상황을 자동으로 복원
```
2. **진행 계속**
- 이전 세션 결정을 즉시 사용 가능
- 아키텍처 패턴 및 코드 통찰력 보존
- 프로젝트 기록 및 근거 유지
3. **지능형 컨텍스트 구축**
- Serena MCP가 현재 작업에 기반하여 관련 메모리 제공
- 과거 솔루션 및 패턴이 새 구현 정보 제공
- 프로젝트 진화 추적 및 이해
### 메모리 최적화
**효과적인 메모리 사용**:
- 설명적이고 검색 가능한 메모리 이름 사용
- 프로젝트 단계 및 타임스탬프 컨텍스트 포함
- 특정 기능 또는 아키텍처 결정 참조
- 향후 검색을 직관적으로 만들기
**메모리 콘텐츠 전략**:
- 결과뿐만 아니라 결정 및 근거 저장
- 고려된 대안 접근법 포함
- 통합 패턴 및 종속성 문서화
- 향후 참조를 위한 학습 및 통찰력 보존
**메모리 라이프사이클 관리**:
- 오래된 메모리의 정기적인 정리
- 관련 세션 메모리 통합
- 완료된 프로젝트 단계 아카이빙
- 쓸모없는 아키텍처 결정 정리
## 영구 세션 모범 사례
### 세션 시작 프로토콜
1. 기존 프로젝트의 경우 항상 `/sc:load`로 시작
2. `/sc:reflect`를 사용하여 메모리에서 현재 상태 이해
3. 영구 컨텍스트 및 저장된 패턴을 기반으로 작업 계획
4. 이전 결정 및 아키텍처 선택 기반 구축
### 세션 종료 프로토콜
1. `/sc:reflect`를 사용하여 저장된 목표에 대한 완전성 평가
2. 향후 세션을 위해 `/sc:save`로 주요 결정 저장
3. 메모리에 다음 단계 및 미해결 질문 문서화
4. 원활한 향후 계속을 위한 컨텍스트 보존
### 메모리 품질 유지
- 쉬운 검색을 위해 명확하고 설명적인 메모리 이름 사용
- 결정 및 대안 접근법에 대한 컨텍스트 포함
- 특정 코드 위치 및 패턴 참조
- 세션 전반에 걸쳐 메모리 구조의 일관성 유지
## 다른 SuperClaude 기능과의 통합
### MCP 서버 조정
- **Serena MCP**: 영구 메모리 인프라 제공
- **Sequential MCP**: 향상된 복잡한 분석을 위해 저장된 메모리 사용
- **Context7 MCP**: 저장된 패턴 및 문서화 접근법 참조
- **Morphllm MCP**: 저장된 리팩토링 패턴을 일관되게 적용
### 메모리를 사용한 에이전트 협업
- 에이전트가 향상된 컨텍스트를 위해 영구 메모리 액세스
- 이전 전문가 결정이 보존되고 참조됨
- 공유 메모리를 통한 교차 세션 에이전트 조정
- 프로젝트 기록을 기반으로 한 일관된 전문가 권장사항
### 지속성을 갖춘 명령어 통합
- 모든 `/sc:` 명령어가 영구 컨텍스트를 참조하고 구축 가능
- 이전 명령어 출력 및 결정이 세션 전반에 걸쳐 사용 가능
- 워크플로우 패턴이 저장되고 재사용 가능
- 구현 기록이 향후 명령어 결정 안내
## 영구 세션 문제 해결
### 일반적인 문제
**메모리 로딩 안 됨**:
- Serena MCP가 올바르게 구성되고 실행 중인지 확인
- 메모리 파일 권한 및 접근성 확인
- 일관된 프로젝트 명명 규칙 보장
- 메모리 파일 무결성 및 형식 검증
**세션 간 컨텍스트 손실**:
- 세션을 종료하기 전에 항상 `/sc:save` 사용
- 쉬운 검색을 위해 설명적인 메모리 이름 사용
- 메모리 완전성을 검증하기 위한 정기적인 `/sc:reflect`
- 중요한 메모리 파일을 주기적으로 백업
**메모리 충돌**:
- 버전 제어를 위해 타임스탬프가 있는 메모리 이름 사용
- 오래된 메모리의 정기적인 정리
- 프로젝트 및 세션 메모리 간의 명확한 분리
- 세션 전반에 걸쳐 일관된 메모리 명명 규칙
### 빠른 수정
**세션 상태 재설정**:
```bash
/sc:load --fresh # 이전 컨텍스트 없이 시작
/sc:reflect # 현재 상태 평가
```
**메모리 정리**:
```bash
/sc:reflect --cleanup # 오래된 메모리 제거
/sc:save --consolidate # 관련 메모리 병합
```
**컨텍스트 복구**:
```bash
/sc:load --recent # 최근 메모리 로드
/sc:reflect --repair # 컨텍스트 격차 식별 및 수정
```
## 고급 영구 세션 패턴
### 다단계 프로젝트
- 조직을 위한 단계별 메모리 명명 사용
- 단계 전반에 걸쳐 아키텍처 결정 연속성 유지
- 영구 메모리를 통한 교차 단계 종속성 추적
- 과거 컨텍스트를 사용한 점진적 복잡성 관리
### 팀 협업
- 공유 메모리 규칙 및 명명 표준
- 팀 컨텍스트를 위한 결정 근거 보존
- 모든 팀원이 액세스 가능한 통합 패턴 문서
- 메모리를 통한 일관된 코드 스타일 및 아키텍처 강제
### 장기 유지보수
- 완료된 프로젝트를 위한 메모리 아카이빙 전략
- 누적된 메모리를 통한 패턴 라이브러리 개발
- 시간이 지남에 따라 구축된 재사용 가능한 솔루션 문서
- 영구 메모리 축적을 통한 지식 베이스 구축
## 영구 세션 관리의 주요 이점
### 프로젝트 연속성
- 여러 대화에 걸쳐 원활한 작업 계속
- Claude Code 세션 간 컨텍스트 손실 없음
- 보존된 아키텍처 결정 및 기술 근거
- 장기 프로젝트 진화 추적
### 향상된 생산성
- 프로젝트 컨텍스트를 다시 설명할 필요 감소
- 계속 작업을 위한 더 빠른 시작 시간
- 이전 통찰력 및 패턴 기반 구축
- 누적 프로젝트 지식 성장
### 품질 일관성
- 세션 전반에 걸쳐 일관된 아키텍처 패턴
- 보존된 코드 품질 결정 및 표준
- 재사용 가능한 솔루션 및 모범 사례
- 유지된 기술 부채 인식
---
**핵심 요점**: Serena MCP를 통한 세션 관리는 SuperClaude를 단일 대화 지원에서 영구 프로젝트 파트너십으로 변환하여 모든 개발 단계 및 Claude Code 대화 전반에 걸쳐 컨텍스트, 결정, 학습을 유지합니다.

View File

@ -33,7 +33,7 @@
<a href="README-ja.md"> <a href="README-ja.md">
<img src="https://img.shields.io/badge/🇯🇵_日本語-green" alt="日本語"> <img src="https://img.shields.io/badge/🇯🇵_日本語-green" alt="日本語">
</a> </a>
<a href="README-ko.md"> <a href="README-kr.md">
<img src="https://img.shields.io/badge/🇰🇷_한국어-orange" alt="한국어"> <img src="https://img.shields.io/badge/🇰🇷_한국어-orange" alt="한국어">
</a> </a>
</p> </p>