프롬프트 최적화 (Prompt Optimizer)
초안 프롬프트를 분석하고 비판한 후, ECC 에코시스템 구성 요소와 매칭하여 사용자가 복사하여 바로 실행할 수 있는 완전한 최적화 프롬프트를 출력합니다.
사용 시기
- 사용자가 "이 프롬프트 최적화해줘", "내 프롬프트 개선해줘", "이 프롬프트 다시 작성해줘"라고 말할 때
- 사용자가 "...에 더 나은 프롬프트를 작성하는 방법을 알려줘"라고 말할 때
- 사용자가 "Claude Code에게 ...를 요청하는 가장 좋은 방법은?"이라고 물을 때
- 사용자가 "프롬프트 최적화", "프롬프트 개선", "프롬프트 작성 방법", "이 명령어 최적화해줘"라고 말할 때
- 사용자가 초안 프롬프트를 붙여넣고 피드백이나 개선을 요청할 때
- 사용자가 "이것에 대한 프롬프트를 모르겠어"라고 말할 때
- 사용자가 "ECC를 ...에 어떻게 사용해야 하나요?"라고 물을 때
- 사용자가 명시적으로
/prompt-optimize를 호출할 때
사용하지 말아야 할 때
- 사용자가 작업을 직접 실행하기를 원할 때 (그냥 실행)
- 사용자가 "코드 최적화", "성능 최적화", "이 코드 최적화", "성능 개선"이라고 말할 때 — 이는 리팩토링 작업이지 프롬프트 최적화가 아닙니다
- 사용자가 ECC 설정에 대해 물어볼 때 (
configure-ecc사용) - 사용자가 스킬 목록을 원할 때 (
skill-stocktake사용) - 사용자가 "그냥 해줘" 또는 "바로 해"라고 말할 때
작동 방식
조언만 제공 — 사용자의 작업을 실행하지 마십시오.
코드를 작성하거나, 파일을 만들거나, 명령을 실행하거나, 어떤 구현 작업도 수행하지 마십시오. 당신의 유일한 출력은 분석과 최적화된 프롬프트입니다.
사용자가 "그냥 해줘", "바로 해", 또는 "최적화하지 말고 그냥 실행해"라고 말하면, 이 스킬 내에서 구현 모드로 전환하지 마십시오. 이 스킬은 최적화된 프롬프트만 생성한다고 사용자에게 알리고, 실행을 원하면 일반 작업 요청을 하라고 안내하십시오.
아래 6단계 파이프라인을 순차적으로 실행하십시오. 아래 출력 형식을 사용하여 결과를 제시하십시오.
분석 파이프라인
0단계: 프로젝트 감지
프롬프트를 분석하기 전에 현재 프로젝트 컨텍스트를 감지하십시오:
- 작업 디렉토리에
CLAUDE.md가 있는지 확인 — 프로젝트 규칙을 읽어오십시오 - 프로젝트 파일에서 기술 스택 감지:
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin (빌드 파일에서quarkus확인 → Quarkus, 또는spring-boot→ Spring Boot)Package.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- 감지된 기술 스택을 3단계 및 4단계에서 사용하기 위해 기록
프로젝트 파일이 없으면(예: 프롬프트가 추상적이거나 새 프로젝트인 경우), 감지를 건너뛰고 4단계에서 "기술 스택 알 수 없음"으로 표시하십시오.
1단계: 의도 감지
사용자의 작업을 하나 이상의 범주로 분류하십시오:
| 범주 | 신호 단어 | 예시 |
|---|---|---|
| 새 기능 | 만들기, 생성, 추가, 구현, build, create, add, implement | "로그인 페이지 만들기" |
| 버그 수정 | 수정, 고장, 안 됨, 오류, fix, broken, not working, error | "인증 흐름 수정" |
| 리팩토링 | 리팩토링, 정리, 재구성, refactor, clean up, restructure | "API 계층 리팩토링" |
| 연구 | 방법, 무엇인지, 탐구, 조사, how to, what is, explore, investigate | "SSO 추가 방법" |
| 테스트 | 테스트, 커버리지, 검증, test, coverage, verify | "장바구니 테스트 추가" |
| 검토 | 검토, 감사, 확인, review, audit, check | "내 PR 검토" |
| 문서 | 문서화, 문서 업데이트, document, update docs | "API 문서 업데이트" |
| 인프라 | 배포, CI, 도커, 데이터베이스, deploy, CI, docker, database | "CI/CD 파이프라인 설정" |
| 설계 | 설계, 아키텍처, 계획, design, architecture, plan | "데이터 모델 설계" |
2단계: 범위 평가
0단계에서 프로젝트가 감지되면 코드베이스 크기를 신호로 사용하십시오. 그렇지 않으면 프롬프트 설명만으로 추정하고 추정치가 불확실하다고 표시하십시오.
| 범위 | 휴리스틱 | 오케스트레이션 |
|---|---|---|
| 사소함 | 단일 파일, 50줄 미만 | 직접 실행 |
| 낮음 | 단일 컴포넌트 또는 모듈 | 단일 명령 또는 스킬 |
| 중간 | 여러 컴포넌트, 동일 도메인 | 명령 체인 + /verify |
| 높음 | 크로스 도메인, 5개 이상 파일 | 먼저 /plan, 그런 다음 단계별 실행 |
| 에픽 | 다중 세션, 다중 PR, 아키텍처 변경 | 다중 세션 계획을 위해 blueprint 스킬 사용 |
3단계: ECC 구성 요소 매칭
의도 + 범위 + 기술 스택(0단계에서)을 특정 ECC 구성 요소에 매핑하십시오.
의도 유형별
| 의도 | 명령 | 스킬 | 에이전트 |
|---|---|---|---|
| 새 기능 | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| 버그 수정 | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
| 리팩토링 | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
| 연구 | /plan | search-first, iterative-retrieval | — |
| 테스트 | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
| 검토 | /code-review | security-review | code-reviewer, security-reviewer |
| 문서 | /update-docs, /update-codemaps | — | doc-updater |
| 인프라 | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
| 설계 (중간-높음) | /plan | — | planner, architect |
| 설계 (에픽) | — | blueprint (스킬로 호출) | planner, architect |
기술 스택별
| 기술 스택 | 추가할 스킬 | 에이전트 |
|---|---|---|
| Python / Django | django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing | python-reviewer |
| Go | golang-patterns, golang-testing | go-reviewer, go-build-resolver |
| Spring Boot / Java | springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns | java-reviewer |
| Quarkus / Java | quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns | java-reviewer |
| Kotlin / Android | kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture | kotlin-reviewer |
| TypeScript / React | frontend-patterns, backend-patterns, coding-standards | code-reviewer |
| Swift / iOS | swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing | code-reviewer |
| PostgreSQL | postgres-patterns, database-migrations | database-reviewer |
| Perl | perl-patterns, perl-testing, perl-security | code-reviewer |
| C++ | cpp-coding-standards, cpp-testing | code-reviewer |
| 기타 / 목록 외 | coding-standards (범용) | code-reviewer |
4단계: 누락된 컨텍스트 감지
프롬프트에서 누락된 중요한 정보를 스캔하십시오. 각 항목을 확인하고 0단계에서 자동 감지되었는지 또는 사용자가 제공해야 하는지 표시하십시오:
- 기술 스택 — 0단계에서 감지되었습니까, 아니면 사용자가 지정해야 합니까?
- 대상 범위 — 파일, 디렉토리 또는 모듈이 언급되었습니까?
- 수용 기준 — 작업 완료 여부를 어떻게 알 수 있습니까?
- 오류 처리 — 엣지 케이스 및 실패 모드가 다루어졌습니까?
- 보안 요구 사항 — 인증, 입력 검증, 비밀?
- 테스트 기대치 — 단위, 통합, E2E?
- 성능 제약 조건 — 부하, 지연 시간, 리소스 제한?
- UI/UX 요구 사항 — 디자인 명세, 반응형, 접근성? (프론트엔드인 경우)
- 데이터베이스 변경 — 스키마, 마이그레이션, 인덱스? (데이터 계층인 경우)
- 기존 패턴 — 참조 파일 또는 따라야 할 규칙?
- 범위 경계 — 하지 말아야 할 것은?
중요 항목 3개 이상 누락된 경우, 최적화된 프롬프트를 생성하기 전에 사용자에게 최대 3개의 명확화 질문을 하십시오. 그런 다음 답변을 최적화된 프롬프트에 통합하십시오.
5단계: 워크플로 및 모델 추천
이 프롬프트가 개발 수명 주기 중 어디에 해당하는지 결정하십시오:
연구 → 계획 → 구현 (TDD) → 검토 → 검증 → 커밋
중간+ 작업의 경우 항상 /plan으로 시작하십시오. 에픽 작업의 경우 blueprint 스킬을 사용하십시오.
모델 추천 (출력에 포함):
| 범위 | 추천 모델 | 근거 |
|---|---|---|
| 사소함-낮음 | Sonnet 5 | 간단한 작업에 빠르고 비용 효율적 |
| 중간 | Sonnet 5 | 표준 작업에 최적의 코딩 모델 |
| 높음 | Sonnet 5 (주) + Opus 5 (계획) | Opus는 아키텍처, Sonnet은 구현 |
| 에픽 | Opus 5 (청사진) + Sonnet 5 (실행) | 다중 세션 계획을 위한 심층 추론 |
다중 프롬프트 분할 (높음/에픽 범위):
단일 세션을 초과하는 작업의 경우 순차적 프롬프트로 분할하십시오:
- 프롬프트 1: 연구 + 계획 (search-first 스킬 사용, 그 다음 /plan)
- 프롬프트 2-N: 프롬프트당 한 단계씩 구현 (각각 /verify로 종료)
- 최종 프롬프트: 모든 단계에 대한 통합 테스트 + /code-review
- 세션 간 컨텍스트를 유지하려면 /save-session 및 /resume-session 사용
출력 형식
분석 결과를 이 정확한 구조로 제시하십시오. 사용자 입력과 동일한 언어로 응답하십시오.
섹션 1: 프롬프트 진단
강점: 원본 프롬프트가 잘한 점을 나열하십시오.
문제점:
| 문제점 | 영향 | 제안된 수정 |
|---|---|---|
| (문제) | (결과) | (수정 방법) |
명확화 필요: 사용자가 답변해야 할 질문의 번호 목록입니다. 0단계에서 답변을 자동 감지한 경우 질문 대신 해당 내용을 명시하십시오.
섹션 2: 추천 ECC 구성 요소
| 유형 | 구성 요소 | 목적 |
|---|---|---|
| 명령 | /plan | 코딩 전 아키텍처 계획 |
| 스킬 | tdd-workflow | TDD 방법론 안내 |
| 에이전트 | code-reviewer | 구현 후 검토 |
| 모델 | Sonnet 5 | 이 범위에 추천 |
섹션 3: 최적화된 프롬프트 — 전체 버전
완전한 최적화된 프롬프트를 단일 펜스 코드 블록 안에 제시하십시오. 프롬프트는 독립적이며 복사하여 붙여넣을 준비가 되어 있어야 합니다. 다음을 포함하십시오:
- 컨텍스트가 포함된 명확한 작업 설명
- 기술 스택 (감지 또는 지정)
- 적절한 워크플로 단계에서의 /command 호출
- 수용 기준
- 검증 단계
- 범위 경계 (하지 말아야 할 것)
blueprint를 참조하는 항목의 경우: "blueprint 스킬을 사용하여..."라고 작성하십시오 (/blueprint가 아님, blueprint는 명령이 아닌 스킬이므로).
섹션 4: 최적화된 프롬프트 — 빠른 버전
경험이 풍부한 ECC 사용자를 위한 간결한 버전입니다. 의도 유형에 따라 다릅니다:
| 의도 | 빠른 패턴 |
|---|---|
| 새 기능 | /plan [기능]. /tdd로 구현. /code-review. /verify. |
| 버그 수정 | /tdd — [버그]에 대한 실패 테스트 작성. 통과하도록 수정. /verify. |
| 리팩토링 | /refactor-clean [범위]. /code-review. /verify. |
| 연구 | search-first 스킬을 [주제]에 사용. 발견 사항을 바탕으로 /plan. |
| 테스트 | /tdd [모듈]. 중요 흐름에 /e2e. /test-coverage. |
| 검토 | /code-review. 그런 다음 security-reviewer 에이전트 사용. |
| 문서 | /update-docs. /update-codemaps. |
| 에픽 | blueprint 스킬을 "[목표]"에 사용. /verify 게이트로 단계 실행. |
섹션 5: 개선 근거
| 개선 사항 | 이유 |
|---|---|
| (추가된 것) | (중요한 이유) |
바닥글
원하는 결과가 아닌가요? 조정할 사항을 알려주거나, 프롬프트 최적화 대신 실행을 원한다면 일반 작업 요청을 하십시오.
예제
트리거 예제
- "ECC용 이 프롬프트 최적화해줘"
- "Claude Code가 올바른 명령을 사용하도록 이 프롬프트 다시 작성해줘"
- "이 명령어 최적화해줘"
- "이 작업을 위해 ECC에 어떻게 프롬프트해야 하나요?"
예제 1: 모호한 중국어 프롬프트 (프로젝트 감지됨)
사용자 입력:
사용자 로그인 페이지를 작성해주세요
0단계 감지: package.json — Next.js 15, TypeScript, Tailwind CSS
최적화된 프롬프트 (전체):
프로젝트의 기존 기술 스택(Next.js 15 + TypeScript + Tailwind CSS)을 사용하여 사용자 로그인 페이지를 구현하십시오.
기술 요구 사항:
- 프로젝트의 기존 컴포넌트 구조 및 라우팅 규칙을 따르십시오
- 양식 검증은 프로젝트에 이미 사용된 검증 방식을 사용하십시오 (Zod/Yup/기타 사용 여부 확인)
- 인증 방식: 프로젝트의 기존 인증 방식을 따르십시오 (없는 경우 기본 JWT)
- 포함: 이메일/비밀번호 로그인 양식, 양식 검증, 오류 메시지, 로딩 상태, 반응형 레이아웃
워크플로:
1. /plan으로 먼저 컴포넌트 구조 및 인증 흐름 계획, 기존 페이지 패턴 참조
2. /tdd로 테스트 우선: 로그인 양식 단위 테스트 및 인증 흐름 통합 테스트 작성
3. 로그인 페이지 및 인증 로직 구현
4. /code-review로 구현 검토
5. /verify로 모든 테스트 통과 및 페이지 정상 렌더링 확인
보안 요구 사항:
- 비밀번호 평문 전송 금지
- 무차별 대입 공격 방어 (rate limiting)
- XSS 방어
- CSRF 토큰
수용 기준:
- 모든 테스트 통과, 커버리지 80%+
- 페이지가 모바일 및 데스크탑에서 정상 렌더링
- 로그인 성공 시 dashboard로 이동, 실패 시 오류 메시지 표시
하지 말 것:
- 회원가입 페이지 구현하지 말 것
- 비밀번호 찾기 기능 구현하지 말 것
- 기존 라우팅 구조 수정하지 말 것
예제 2: 중간 수준 영어 프롬프트
사용자 입력:
사용자 프로필 업데이트를 위한 REST API 엔드포인트를 검증과 함께 추가해줘
0단계 감지: go.mod — Go 1.22, Chi 라우터
최적화된 프롬프트 (전체):
사용자 프로필 업데이트를 위한 REST API 엔드포인트(PATCH /api/users/:id)를 추가하십시오.
기술 스택: Go 1.22 + Chi 라우터 (프로젝트에서 감지됨)
요구 사항:
- PATCH /api/users/:id — 사용자 프로필 부분 업데이트
- 필드 입력 검증: name, email, avatar_url, bio
- 인증: 유효한 토큰 필요, 사용자는 자신의 프로필만 업데이트 가능
- 성공 시 업데이트된 사용자와 함께 200 반환
- 잘못된 입력 시 검증 오류와 함께 400 반환
- 인증 실패 시 401/403 반환
- 코드베이스의 기존 API 패턴을 따를 것
워크플로:
1. /plan으로 엔드포인트 구조, 미들웨어 체인 및 검증 로직 계획
2. /tdd — 성공, 검증 실패, 인증 실패, 찾을 수 없음에 대한 테이블 기반 테스트 작성
3. 기존 핸들러 패턴을 따라 구현
4. /go-review
5. /verify — 전체 테스트 스위트 실행, 회귀 없음 확인
하지 말 것:
- 기존 엔드포인트 수정 금지
- 데이터베이스 스키마 변경 금지 (기존 사용자 테이블 사용)
- 먼저 기존 종속성을 확인하지 않고 새 종속성 추가 금지 (search-first 스킬 사용)
예제 3: 에픽 프로젝트
사용자 입력:
모놀리스를 마이크로서비스로 마이그레이션
최적화된 프롬프트 (전체):
blueprint 스킬을 사용하여 계획: "모놀리스를 마이크로서비스 아키텍처로 마이그레이션"
실행 전 blueprint에서 다음 질문에 답변하십시오:
1. 현재 모놀리스에 존재하는 도메인 경계는 무엇입니까?
2. 어떤 서비스를 먼저 분리해야 합니까 (결합도가 가장 낮은)?
3. 통신 패턴: REST API, gRPC 또는 이벤트 기반 (Kafka/RabbitMQ)?
4. 데이터베이스 전략: 처음에는 공유 DB, 아니면 처음부터 서비스별 DB?
5. 배포 대상: Kubernetes, Docker Compose 또는 서버리스?
blueprint는 다음과 같은 단계를 생성해야 합니다:
- 1단계: 서비스 경계 식별 및 도메인 맵 생성
- 2단계: 인프라 설정 (API 게이트웨이, 서비스 메시, 서비스별 CI/CD)
- 3단계: 첫 번째 서비스 분리 (strangler fig 패턴)
- 4단계: 통합 테스트로 검증, 그런 다음 다음 서비스 분리
- N단계: 모놀리스 폐기
각 단계 = 1 PR, 단계 사이에 /verify 게이트.
단계 사이에 /save-session 사용.
...
[번역을 위해 잘림]