Claude Code 프롬프트 엔지니어링 기법 (Prompt Engineering for Claude Code)

핵심 원리: Claude Code는 "간결하고 실행 중심"으로 설계되어 있으므로, 프롬프트도 그에 맞춰야 합니다. 내부적으로 Plan → Understand → Implement → Verify → Complete 워크플로를 따르며, 이 흐름에 맞물리는 프롬프트가 가장 효율적인 결과를 만듭니다.
1 명확한 작업 단위로 지시하라
"이 프로젝트 전체를 리팩토링해줘"보다는 구체적인 클래스, 함수, 동작 단위로 지시하라. 복잡한 작업은 한번에 던지되, TodoWrite가 분할할 수 있도록 전체 스코프를 명시하는 게 좋다.
✗ 모호한 지시
"플러그인 코드 전체를 정리해줘"
✓ 구체적 단위
"EgFilletPlugin.csInitialize 메서드에서 TriggerStateService 등록 로직을 StartAction으로 분리해줘"
2 컨텍스트를 코드로 가리켜라
"Understand the codebase" 단계가 있으므로, 파일 경로나 함수명을 직접 언급하면 탐색 시간이 줄어든다. Claude Code는 알아서 코드를 읽지만, 시작점을 알려주면 훨씬 빠르다.
✗ 시작점 없음
"WPF 뷰모델에서 바인딩이 안 되는 버그 있어"
✓ 파일/함수 명시
"src/ViewModels/RebuildWindowViewModel.csPointCount 프로퍼티에서 OnPropertyChanged 호출이 누락되어 UI에 값이 반영 안 돼"
3 불필요한 설명을 요구하지 마라
시스템 프롬프트 자체가 "4줄 미만 답변, 서론/결론 없이"로 설정되어 있다. "자세히 설명해줘"라고 하면 시스템 지침과 충돌하며 결과가 어중간해질 수 있다. 설명이 필요하면 코드 작업과 분리해서 별도로 요청하는 게 낫다.
✗ 혼합 요청
"MVVM 패턴이 뭔지 설명하고 ViewModel 만들어줘"
✓ 분리 요청
1차: "MVVM 패턴에서 ICommand 바인딩 방식 알려줘"
2차: "FilletOptionView.xaml에 대한 ViewModel을 CommunityToolkit.Mvvm 기반으로 만들어줘"
4 검증 조건을 함께 명시하라
Verify 단계에서 lint/typecheck를 필수로 돌리게 되어 있으므로, 추가 검증 기준이 있다면 미리 알려주라. Claude Code가 자체 검증 루프에 자연스럽게 포함시킨다.
✗ 검증 기준 없음
"Offset 로직 수정해줘"
✓ 검증 포함
"OffsetCalculator.cs의 음수 거리 처리 로직 수정해줘. 변경 후 dotnet test tests/EgOffsetCrvPlugin.Tests 통과 확인해줘"
5 부작용(Side Effect)은 명시적으로
시스템 프롬프트에 "사용자가 명시적으로 요청하지 않으면 절대 커밋하지 말 것"이라고 되어 있다. 반대로 말하면, 커밋까지 원하면 직접 말해야 한다.
✗ 암묵적 기대
"Fillet 플러그인 버그 고쳐줘"
(커밋을 해줄 거라 기대하지만 실제로는 안 함)
✓ 명시적 지시
"Fillet 플러그인 버그 고쳐줘. 변경사항을 fix: FilletCalculator 음수 반경 처리 메시지로 커밋해줘"
6 기존 패턴 따르기를 활용하라
"기존 스타일/패턴 모방"이 내장되어 있으므로, 프로젝트에 일관된 컨벤션이 있다면 Claude Code가 알아서 따른다. 새로운 패턴을 도입하고 싶을 때만 명시하면 된다.
✗ 불필요한 지정
"EgCirclePlugin 스타일대로 ObservableProperty 쓰고, RelayCommand 쓰고, XAML은 Grid 레이아웃 사용해서 새 플러그인 만들어줘"
(이미 프로젝트에 해당 패턴이 있으면 자동으로 따름)
✓ 변경 시에만 명시
"새 ExtendCrv 플러그인 만들어줘. 이번엔 기존 DrawingGridUI 대신 WPF Window + ViewModel 방식으로 옵션 UI를 구현해줘"
실전 프롬프트 예시 (Practical Examples)
🛠 예시 1 — 플러그인 버그 수정
src/EgFilletPlugin/EgFilletPlugin.csStartAction에서 SelectFilter가 Curve만 허용하는데, Surface 엣지도 선택 가능하도록 수정해줘. samples/EgLengthPlugin의 SelectFilter 패턴을 참고해. 변경 후 dotnet build 통과 확인하고, 커밋은 하지 마.
컨텍스트 파일 경로 + 함수명 직접 지정
작업 SelectFilter 변경이라는 구체적 단위
검증 dotnet build 통과 명시
부작용 커밋하지 말라고 명시
🛠 예시 2 — WPF ViewModel 생성
src/EgOffsetCrvPlugin/View/OffsetOptionWindow.xaml에 대한 ViewModel을 만들어줘. Distance(double), BothSide(bool), CornerType(enum) 프로퍼티가 필요해. 기존 RebuildWindowViewModel.cs 패턴을 따르되, CommunityToolkit.Mvvm의 [ObservableProperty] 사용해줘. 완료 후 dotnet test 돌려줘.
컨텍스트 XAML 파일 + 참조할 기존 ViewModel 명시
작업 프로퍼티 목록과 타입까지 구체적
검증 dotnet test 실행 지시
부작용 커밋 언급 없음 = 커밋 안 함
🛠 예시 3 — 상태 다이어그램 기반 플러그인 구현
docs/diagrams/plugin-state-flow-example.drawio 다이어그램을 보고 새 EgExtendCrvPlugin을 만들어줘. 상태 전이는 다이어그램의 Idle → SelectCurve → SetLength → Preview → Confirm 흐름을 따라. samples/EgLinePlugin 구조를 기반으로 하되, Preview 상태에서 동적 미리보기를 추가해줘. 빌드 통과 확인 후 feat: Add EgExtendCrv plugin으로 커밋해줘.
컨텍스트 다이어그램 + 참조 샘플 프로젝트 지정
작업 상태 흐름과 추가 기능(Preview) 명시
검증 빌드 통과 확인
부작용 커밋 메시지까지 명시적으로 지정