프롬프트 엔지니어링

예시 프롬프트:

Make the app better

Fix the bugs

예시 프롬프트:

Add authentication

예시 프롬프트:

Build the entire user management system with authentication, authorization, profiles, settings, and admin dashboard

예시 프롬프트:

Update the validation logic

예시 프롬프트:

Expecting Verdent to know your specific business rules or constraints

예시 프롬프트:

Referencing files without including them in context

예시 프롬프트:

Repeatedly asking for the same thing when Verdent encounters errors

예시 프롬프트:

Requesting large refactorings or multi-file changes without using Plan Mode first

예시 프롬프트:

Using Auto-Run or Skip Permission Mode without Git initialized

예시 프롬프트:

Providing incomplete requirements and expecting Verdent to guess correctly

명확한 요구사항과 제약을 바탕으로 새 기능 만들기:

Create a POST /api/tasks endpoint that:
- Accepts task title (required), description (optional), and category_id (required)
- Validates that the category exists in the database
- Returns 400 if validation fails with descriptive error messages
- Saves the task to the database and returns the created task with 201 status
- Add this to the existing tasks router in routes/tasks.js
- Create the controller method in controllers/taskController.js
- Use the existing error handling pattern from other controllers

효과적인 이유:

• 입력값과 검증에 대한 요구사항이 명확함
• 구현할 파일 위치가 구체적임
• 일관성을 유지하기 위해 기존 패턴을 참조함
• 예상 HTTP 상태 코드와 오류 처리가 포함됨

컨텍스트와 제안된 해결책을 함께 문제 설명하기:

Fix the race condition in payment processing at checkout. When multiple users submit payments simultaneously, some transactions fail with "duplicate order ID" errors. The issue appears to be in PaymentController.js around line 45 where we generate order IDs. Implement proper locking or use UUID generation to ensure unique IDs even under concurrent load.

효과적인 이유:

• 증상이 포함된 명확한 문제 설명
• 문제가 있는 위치가 구체적임(파일과 줄 번호)
• 발생 조건에 대한 컨텍스트가 있음(동시 사용자)
• 해결 접근 방식이 제안됨

동작은 유지하면서 구현 변경하기:

Refactor the authentication middleware in middleware/auth.js to use JWT tokens instead of session cookies. Keep the same authorization logic, but:
- Replace session validation with JWT verification
- Store tokens in httpOnly cookies
- Maintain the existing user object structure that routes expect
- Update only the authentication mechanism, don't change authorization rules
- Ensure all existing routes continue to work without modification

효과적인 이유:

• 목표가 명확함(세션 대신 JWT)
• 리팩터링할 파일이 구체적임
• 제약이 명시적임(변경하면 안 되는 것)
• 하위 호환성 요구사항이 있음

포괄적인 커버리지로 테스트 작성하기:

Write comprehensive unit tests for the UserService class in services/UserService.js. Cover:
- User creation with valid and invalid data
- Email validation edge cases (empty, malformed, duplicate)
- Password hashing verification
- User lookup by ID and email
- Error handling for database failures
Use Jest and follow the testing patterns in existing service tests

효과적인 이유:

• 테스트할 클래스/파일이 구체적임
• 커버해야 할 시나리오 목록이 완전함
• 테스트 프레임워크가 지정됨
• 기존 테스트 패턴을 참조함

자세한 사양으로 UI 컴포넌트 만들기:

Create a reusable SearchBar component for the product catalog with:
- Text input with real-time debounced search (300ms delay)
- Category dropdown filter (fetch options from /api/categories)
- Price range slider (min $0, max $1000)
- Clear filters button
- Use Material-UI components to match existing design
- Emit search parameters via onChange callback to parent
- Include PropTypes for all props

효과적인 이유:

• 구체적인 세부 정보가 포함된 완전한 기능 목록
• 기술 사양이 있음(300ms 디바운스, 가격 범위)
• UI 라이브러리가 지정됨(Material-UI)
• 연동 방식이 명확함(부모로 콜백 전달)

특정 파일, 컴포넌트, 서브에이전트를 참조합니다:

@auth.js @UserController.js Refactor authentication to use the same validation pattern

장점:

• 특정 파일을 명시적으로 포함해 Verdent이 정확한 컨텍스트를 갖도록 보장합니다
• 비슷한 파일명이 많은 대규모 코드베이스에서 모호함을 방지합니다
• 정확한 리팩터링과 패턴 매칭을 위해 모든 관련 코드를 동시에 볼 수 있게 합니다
• 한 파일의 구현 패턴을 다른 파일에 적용할 때 필수적입니다

큰 변경을 실행하기 전에 Plan Mode로 전환합니다:

Switch to Plan Mode
Refactor the entire API layer to use TypeScript with strict type checking

장점:

• 파일이 수정되기 전에 Verdent의 전체 접근 방식을 검토할 수 있습니다
• 대규모 리팩터링이나 아키텍처 변경에서 비용이 큰 실수를 방지합니다
• 실행이 시작되기 전에 플랜을 반복 개선하거나, 제약을 추가하거나, 방향을 완전히 바꿀 수 있습니다
• 모든 요구사항을 미리 수집하기 위해 Verdent이 명확히 할 질문으로 인터뷰하도록 요청할 수 있습니다

특화된 작업을 기본 제공 또는 사용자 지정 서브에이전트에 위임합니다:

@Code-reviewer Review the security vulnerabilities in authentication flow
@Explorer Find all files that import the deprecated API client
@Verifier Validate the authentication logic in the middleware

장점:

• 특정 작업(탐색, 검증, 코드 리뷰)에 최적화된 특화 에이전트를 활용합니다
• 범용 처리보다 집중된 전문성과 더 빠른 결과를 얻습니다
• 여러 분석을 병렬로 실행해 전체 실행 시간을 크게 줄입니다
• 프로젝트 고유 요구사항에 맞는 도메인 지식을 가진 사용자 지정 서브에이전트를 만들 수 있습니다

기본 제공 서브에이전트:

• @Verifier - 빠른 코드 점검과 검증
• @Explorer - 빠른 코드베이스 탐색과 파일 찾기
• @Code-reviewer - 코드 품질 평가

정교한 문제에 확장 추론을 활성화합니다:

Think: Design the optimal database schema for a multi-tenant SaaS application

장점:

• 복잡한 문제를 여러 관점에서 더 깊이 분석하도록 확장 추론을 활성화합니다
• 대안 접근 방식과 엣지 케이스를 더 철저히 평가합니다
• 정확성이 가장 중요한 상황에서 견고한 해결책을 만듭니다
• 응답은 느리고 크레딧 사용량은 더 높지만, 성급하고 최적이 아닌 해결책으로 인한 비용 큰 재작업을 방지합니다

이전 응답을 바탕으로 점진적으로 개선합니다:

Initial: "Create a dashboard component"
Follow-up: "Add real-time data updates using WebSockets"
Follow-up: "Now add filtering and sorting capabilities"

장점:

• 복잡성을 더하기 전에 각 단계에서 테스트하며 점진적으로 개발할 수 있습니다
• 각 레이어가 올바르게 동작하는지 검증한 뒤 그 위에 구축해 위험을 줄입니다
• 반복 과정에서 예상치 못한 결과가 나오면 즉시 방향을 수정할 수 있습니다
• 각 반복이 작고 제한적이므로 어떤 변경이 버그를 만들었는지 식별하기 쉽습니다

변경할 내용과 함께 변경하지 말아야 할 내용을 지정합니다:

Add caching to the API endpoints, but:
- Don't modify the authentication middleware
- Keep the existing error handling unchanged
- Maintain backward compatibility with mobile clients

장점:

• 중요한 시스템(인증, 결제)을 수정하지 않도록 경계를 명시적으로 정의합니다
• 컴플라이언스나 위험 요구사항 때문에 변경되면 안 되는 안정적인 시스템을 보호합니다
• 변경 구현, 기능 손상 발견, 해결책 재작업으로 이어지는 비용 큰 반복을 피합니다
• 하위 호환성을 유지하고 충분히 검증된 코드를 불필요한 리팩터링에서 보호합니다

기존 코드를 구현 예시로 지정합니다:

Implement the new ProductService following the same pattern as UserService.js, including error handling, validation, and database transaction management

장점:

• 새 구현이 확립된 규칙과 일관성을 유지하도록 합니다
• 코드베이스를 더 유지보수하기 쉽고 예측 가능하게 만듭니다
• 필요한 설명을 크게 줄입니다. 접근 방식을 자세히 설명하는 대신 예시를 가리킵니다
• 해결책을 새로 만들기보다 검증된 패턴을 활용합니다
• 버그를 줄이고 기존 시스템과 자연스럽게 연동되도록 합니다

복잡한 다단계 작업을 추적하기 위해 todos.md 파일을 만듭니다:

Create a todos.md file with these tasks:
1. Refactor authentication to use JWT tokens
2. Update all controllers to use new auth middleware
3. Add tests for authentication flow
4. Update API documentation

장점:

• 팀원과 검토하고 개선하며 공유할 수 있는 명확한 문서화된 로드맵을 만듭니다
• 프로젝트 중 요구사항이 바뀌어도 쉽게 조정할 수 있습니다
• 세션을 넘어 유지되므로 작업을 멈췄다가 나중에 재개해도 어디까지 했는지 즉시 이해할 수 있습니다
• 계획된 것, 완료된 것, 향후 유지보수와 온보딩을 위해 남은 것을 기록하는 프로젝트 산출물 역할을 합니다

서로 다른 todo 사이에는 새 세션을 시작해 컨텍스트를 새롭게 유지합니다:

After completing todo #1: "Start a new session"
Then: "Let's work on todo #2 from todos.md"

장점:

• 이전 작업의 세부 내용이 현재 작업에 부적절하게 영향을 주는 컨텍스트 오염을 방지합니다
• 이전 작업의 부담 없이 현재 todo에만 집중하도록 합니다
• 불필요한 대화 기록을 로드하지 않아 토큰 사용량을 줄입니다
• 응답을 더 빠르고 크레딧 효율적으로 만듭니다
• 테스트와 변경 커밋을 위한 자연스러운 체크포인트를 만들며, 깔끔한 git 기록과 쉬운 문제 격리를 유지합니다

MCP(Model Context Protocol) 서버를 사용해 특화된 컨텍스트를 주입합니다:

• 프로젝트별 문서
• API 사양(OpenAPI, GraphQL 스키마)
• 프레임워크별 지식

장점:

• 학습 데이터에 없는 사용자 지정 프레임워크, 내부 도구, 특화 도메인에 대한 Verdent의 이해를 높입니다
• 조직별 API 사양과 문서를 직접 주입해 사용자 지정 시스템을 반복해서 설명할 필요를 없앱니다
• 프롬프트만으로는 전달하기 어려운 내부 API와 독점 시스템을 올바르게 사용할 수 있게 합니다

관련 파일을 컨텍스트에 명시적으로 포함합니다:

@models/User.js @controllers/UserController.js Add password reset functionality

사용 시점:

• 서로 강하게 연결된 파일(모델과 컨트롤러, 서비스와 테스트)을 다룰 때
• 한 파일의 구현 패턴을 참조해 다른 파일에 적용할 때
• 여러 관련 파일에 걸친 변경을 조율할 때
• 비슷한 파일명이 많은 대규모 코드베이스에서 자동 감지가 컨텍스트를 놓칠 수 있을 때
• Verdent에게 "같은 패턴을 따라..."라고 요청할 때는 정확한 코드를 갖도록 항상 사용합니다

스택에 대한 상위 수준 컨텍스트를 포함합니다:

This is a MERN stack application (MongoDB, Express, React, Node.js) with JWT authentication. Add role-based access control following our existing middleware pattern.

사용 시점:

• 기존 기술 스택과 연동해야 하는 기능을 구현할 때
• 코드베이스에서 처음 작업하거나 프론트엔드부터 데이터베이스까지 여러 레이어에 걸친 기능을 다룰 때
• 스택에 구현 선택에 영향을 주는 강한 방향성이 있을 때(GraphQL vs REST, Redux vs Context API)
• 일반적인 해결책이 아니라 시스템에 맞는 접근 방식을 Verdent이 선택해야 할 때

규칙을 보여주는 코드를 가리킵니다:

Follow the same error handling pattern used in ProductController.js - return consistent error objects with status codes and descriptive messages

사용 시점:

• 새 코드가 확립된 규칙(오류 처리, 검증, 로깅, 테스트)과 일관성을 유지하길 원할 때
• 코드베이스의 새 영역에 비슷한 기능을 구현할 때
• 익숙하지 않은 코드베이스 영역에 온보딩하면서 기존 패턴을 배우고 재현하고 싶을 때
• 패턴을 자세히 설명하지 않고, 말로 표현하기 어려운 뉘앙스를 Verdent이 포착하길 원할 때

제한사항이나 요구사항을 명시합니다:

We're using TypeScript with strict mode enabled, React 18 with hooks only (no class components), and Material-UI v5 for styling

사용 시점:

• 프로젝트에 특정 기술 요구사항이 있을 때(TypeScript strict mode, React hooks only, 외부 의존성 금지)
• 레거시 제약을 다룰 때(IE11 지원, Node.js 14 호환성)
• 컴플라이언스 요구사항이 선택을 좌우할 때(WCAG 접근성, GDPR 데이터 처리)
• 버전 간 깨지는 변경이 있는 특정 라이브러리 버전을 사용할 때
• Verdent이 프로젝트의 기술적 경계를 위반하는 해결책을 제안하지 못하게 해야 할 때

도메인별 규칙을 설명합니다:

Users can only view tasks assigned to them or their team. Managers can view all tasks in their department. Admins can view everything.

사용 시점:

• 코드만으로 Verdent이 추론할 수 없는 도메인별 규칙이 있는 기능을 구현할 때
• 권한 로직(누가 무엇에 접근할 수 있는지), 비즈니스 워크플로(승인 프로세스, 상태 머신)
• 검증 규칙(비밀번호 정책, 데이터 제약), 도메인 제약(재고 한도, 가격 규칙)
• 엔티티 관계와 카디널리티 설명이 필요한 데이터 모델을 만들 때
• 계산을 구현할 때(할인 규칙, 세금 계산, 커미션 구조)
• 단순히 동작하는 코드가 아니라 조직의 비즈니스 규칙을 Verdent이 올바르게 강제해야 할 때

디버깅할 때 오류 메시지나 로그를 공유합니다:

Getting "TypeError: Cannot read property 'id' of undefined" at UserController.js:42 when trying to update user profiles. The req.user object exists but doesn't have an id property after the recent auth middleware changes.

사용 시점:

• 버그를 수정할 때는 항상 전체 오류 메시지, 스택 트레이스, 로그를 포함합니다
• 런타임 오류(예외, 크래시), 빌드 실패(컴파일 오류, 린팅 위반)
• 테스트 실패(assertion 오류, timeout 문제), 예상치 못한 동작(잘못된 출력, 누락된 데이터)
• 줄 번호와 호출 체인을 보여주는 전체 스택 트레이스가 포함된 정확한 오류 메시지가 있을 때
• 발생 시점에 대한 컨텍스트를 제공할 수 있을 때(항상, 간헐적으로, 특정 조건)
• Verdent이 추측이 아니라 근본 원인을 식별하는 능력을 크게 높이고 싶을 때

Verdent은 요청을 바탕으로 관련 파일을 자동으로 로드합니다:

• 프롬프트에서 이름으로 언급된 파일
• 같은 디렉터리의 관련 파일
• 자주 접근하는 프로젝트 파일

이 기능에 의존할 때:

• 관계가 분명한 표준 파일 참조의 경우
• 컴포넌트 이름을 언급했고 Verdent이 해당 특정 파일을 로드해야 할 때
• 같은 디렉터리에서 함께 작업되는 경우가 많은 파일을 다룰 때
• 자주 사용하는 프로젝트 파일에 접근할 때(package.json, config 파일)
• 잘 정리된 코드베이스의 단순한 시나리오에서 잘 동작합니다
• 복잡한 다중 파일 리팩터링, 떨어져 있는 코드베이스 영역, 모호한 파일명에는 명시적 @-멘션을 대신 사용합니다

규칙 파일(Settings → Rules)을 통해 지속적인 컨텍스트를 설정합니다:

사용자 규칙(VERDENT.md): 모든 프로젝트에 적용되는 전역 선호사항

프로젝트 규칙(AGENTS.md): 프로젝트별 표준 - 아키텍처 패턴, 코딩 표준

플랜 규칙(plan_rules.md): Plan Mode에서 플랜 형식과 내용을 사용자 지정합니다

사용 시점:

• 여러 세션에서 같은 컨텍스트를 반복해서 제공할 때
• 개인 선호사항을 위한 사용자 규칙(코딩 스타일, 선호 라이브러리, 선호하는 패턴)
• 팀 표준을 위한 프로젝트 규칙(아키텍처 결정, 네이밍 규칙, 테스트 요구사항)
• 새 팀원 온보딩에 유용함(암묵지를 문서화)
• 대규모 팀에서 일관성을 유지하고 프롬프트 장황함을 줄일 때
• 프로젝트가 문서화할 만한 확립된 패턴을 갖출 만큼 성숙했다면 규칙 파일에 투자합니다

스크린샷, 목업, 다이어그램을 포함합니다:

@screenshot.png Implement this UI design with React components

사용 시점:

• 시각 정보가 텍스트보다 요구사항을 더 효과적으로 전달할 때
• UI/UX 구현(디자인 목업, 와이어프레임, 사용자 흐름)
• 시각적 문제 디버깅(깨진 레이아웃 스크린샷, 렌더링 문제)
• 복잡한 아키텍처 이해(시스템 다이어그램, 데이터베이스 스키마, 플로차트)
• 반응형 디자인, 접근성 분석, 오류 재현에 필수적입니다
• Figma나 Sketch 같은 도구의 디자인을 코드로 옮길 때
• 잘 캡처된 스크린샷 하나가 여러 문단으로 설명해야 할 세부 정보를 전달하는 경우가 많습니다

외부 문서나 예시를 참조합니다:

Ultrathink: Read this API documentation at https://api-docs.example.com/v1/endpoints and implement the authentication flow

사용 시점:

• 공식 문서가 온라인에 있는 외부 API 또는 라이브러리와의 연동을 구현할 때
• 라이브러리에 복잡한 설정 옵션이나 인증 흐름이 있을 때 특히 유용합니다
• Verdent에게 코드를 생성하기 전에 웹 콘텐츠를 가져와 분석하도록 지시하려면 "Ultrathink:" 접두사를 사용합니다
• 문서가 학습 데이터보다 최신인 빠르게 변화하는 API에 필수적입니다
• 프레임워크별 패턴을 따를 때(Next.js App Router, Vue Composition API)
• 구현이 현재 API 버전에 맞고 공식 권장사항을 따르도록 합니다

초기 프롬프트:

Add authentication to the API

Verdent의 응답이 일반적일 수 있습니다. 개선합니다:

Use JWT tokens stored in httpOnly cookies, implement refresh token rotation, and follow the authentication pattern from our existing UserController

사용 시점: 일반적인 요청으로 시작한 뒤 초기 응답을 바탕으로 세부 정보를 추가할 때

Verdent의 구현이 기대와 다를 때:

The validation logic is good, but use Joi schema validation instead of manual checks. Match the validation pattern in ProductController.js

사용 시점: 결과물을 검토하고 구체적인 개선점을 찾은 뒤

점진적으로 구축합니다:

Initial: "Create a UserProfile component"
Follow-up: "Add an avatar upload feature with image preview"
Follow-up: "Add validation - max 5MB, only jpg/png formats"
Follow-up: "Show upload progress with a progress bar"

사용 시점: 같은 세션에서 기능을 점진적으로 만들 때

구현이 예상과 다르게 보일 때:

Why did you use Redux instead of Context API? Can you explain the trade-offs for this use case?

그런 다음 이해한 내용을 바탕으로 개선합니다:

Actually, use Context API for consistency with the rest of our application

사용 시점: 변경을 요청하기 전에 추론을 이해하고 싶을 때

복잡한 변경의 경우:

Switch to Plan Mode
Show me how you would refactor the authentication system to support OAuth providers

실행 전에 플랜을 검토하고, 질문하고, 접근 방식을 반복 개선합니다.

사용 시점: 검토가 필요한 주요 아키텍처 변경

Verdent의 스타일이 내 스타일과 맞지 않을 때:

The component structure is close, but use this pattern instead:
[paste example of your preferred structure]
Apply this same pattern to the remaining components

사용 시점: 코드 스타일 선호사항을 설정하거나 강화할 때

결과물이 명시하지 않은 제약을 위반할 때:

Good approach, but don't modify the database schema - work within the existing User table structure

사용 시점: 초기 구현을 본 뒤 발견한 제약을 추가할 때

핵심 기능부터 시작해 기능을 반복적으로 추가합니다:

Step 1: "Create basic CRUD endpoints for tasks"
Step 2: "Add pagination to the GET endpoint"
Step 3: "Add filtering by status and priority"
Step 4: "Add full-text search across title and description"

사용 시점: 각 단계에서 테스트하며 복잡한 기능을 점진적으로 만들 때