신속한 엔지니어링: AI와 소통하는 기술
Copilot의 출력 품질은 프롬프트의 품질에 직접적으로 영향을 받습니다. 그만큼 신속한 엔지니어링 단순히 요청을 작성하는 것이 아니라 결합하는 기술입니다. 의사소통의 명확성, 기술적 이해 및 구조화된 사고. 이 기사에서는 우리는 예측 가능한 고품질 결과를 얻기 위한 고급 기술을 탐구할 것입니다.
2025년에는 도입과 함께 MCP(모델 컨텍스트 프로토콜) 에이전트, 프롬프트 엔지니어링은 더욱 발전했습니다. 우리는 단일 프롬프트를 작성하는 것뿐만 아니라 정의하자 끈질긴 성격 전체에 걸쳐 컨텍스트와 규칙을 유지하는 개발 세션.
📚 시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 기초와 사고방식 | 설정과 사고방식 |
| 2 | 개념 및 요구사항 | 아이디어에서 MVP까지 |
| 3 | 백엔드 아키텍처 | API 및 데이터베이스 |
| 4 | 프런트엔드 구조 | UI 및 구성요소 |
| 5 | 📍 현재 위치 → 신속한 엔지니어링 | MCP 프롬프트 및 에이전트 |
| 6 | 테스트 및 품질 | 단위, 통합, E2E |
| 7 | 선적 서류 비치 | 읽어보기, API 문서, ADR |
| 8 | 배포 및 DevOps | 도커, CI/CD |
| 9 | 진화 | 확장성 및 유지 관리 |
프롬프트 엔지니어링이 기본인 이유
평범한 프롬프트와 우수한 프롬프트의 차이는 몇 시간의 작업을 의미할 수 있습니다. 저장하거나 낭비하십시오. 잘 구성된 프롬프트:
🎯 프롬프트 엔지니어링의 이점
- 정도: 일반 코드 대신 타겟 응답
- 일관성: 프로젝트 규칙과 일치하는 출력
- 능률: 결과를 얻기 위한 반복 횟수 감소
- 재현성: 동일한 프롬프트, 동일한 품질 결과
- 오토메이션: 일반적인 작업을 위한 재사용 가능한 템플릿
효과적인 프롬프트 분석
잘 구성된 프롬프트는 예측 가능한 패턴을 따릅니다. 기본 구성 요소는 다음과 같습니다.
완벽한 프롬프트의 구조
┌─────────────────────────────────────────────────────────────┐
│ ROLE │ Chi deve essere l'AI (ruolo, expertise) │
├─────────────┼───────────────────────────────────────────────┤
│ CONTEXT │ Background del progetto, stack, architettura │
├─────────────┼───────────────────────────────────────────────┤
│ TASK │ Cosa deve fare SPECIFICAMENTE │
├─────────────┼───────────────────────────────────────────────┤
│ CONSTRAINTS│ Limitazioni, requisiti NON-FUNZIONALI │
├─────────────┼───────────────────────────────────────────────┤
│ OUTPUT │ Formato desiderato della risposta │
├─────────────┼───────────────────────────────────────────────┤
│ EXAMPLES │ Esempi di input/output attesi (opzionale) │
└─────────────┴───────────────────────────────────────────────┘구성 요소의 세부 사항
1. 역할 - 전문성 정의
역할은 단순한 직위가 아니라 역할을 정의합니다. 전문 지식 수준, 는 지식의 영역 그리고 그것 의사소통 스타일.
// ❌ Troppo generico
ROLE: You are a developer.
// ✅ Specifico e contestuale
ROLE: You are a senior TypeScript developer with 10+ years of experience
in building scalable Node.js APIs. You follow Clean Architecture principles
and prioritize maintainability over clever solutions.2. CONTEXT - 프로젝트의 배경
더 많은 컨텍스트를 제공할수록 프로젝트에 더 부합하는 결과가 나올 것입니다.
CONTEXT:
- Project: E-commerce platform for handmade products
- Stack: Node.js 20 + Express 5 + TypeScript 5.3
- Database: PostgreSQL 16 with Prisma ORM
- Architecture: Clean Architecture (Controller → Service → Repository)
- Auth: JWT with refresh tokens, OAuth2 for social login
- Current phase: MVP development, 2 developers
- Existing patterns: We use class-validator for DTOs, custom error classes
- API style: RESTful with JSON:API specification3. 과제 - 구체적인 목표
어떻게 해야 하는지가 아니라 무엇을 해야 하는지 설명하세요. AI가 구현을 제안하게 하세요.
TASK:
Create a ProductService class that handles:
1. Create product (validate price > 0, name unique per seller)
2. Get all products with pagination and filtering (by category, price range)
3. Get product by ID or slug
4. Update product (only owner can update)
5. Soft delete product (mark as inactive, don't remove from DB)
6. Get seller's products with statistics (total views, favorites count)4. 제약 - 비기능적 요구사항
여기에서는 구현에 관계없이 코드가 따라야 하는 규칙을 정의합니다.
CONSTRAINTS:
- Use dependency injection (constructor injection)
- All methods must be async
- Throw custom errors: ValidationError, NotFoundError, ForbiddenError
- Never expose internal IDs (use UUIDs or slugs in responses)
- Include JSDoc comments for all public methods
- Follow existing naming conventions (camelCase methods, PascalCase classes)
- Don't use 'any' type - always use specific types or generics
- Logging: use structured logging with correlation IDs5. 출력 - 응답 형식
응답을 받을 방법을 정확하게 지정하세요.
OUTPUT FORMAT:
- Single TypeScript file
- Export the class as default
- Include all necessary imports at the top
- Add interface definition for the service (IProductService)
- Group methods logically (CRUD operations, then queries, then statistics)
- After the code, provide a brief explanation of key design decisions전체 예: 전문가 프롬프트
다음은 모든 구성 요소를 결합한 예입니다.
프롬프트 완료 - OrderService 생성
ROLE: You are a senior TypeScript developer specialized in e-commerce systems.
You have deep knowledge of payment processing, inventory management, and
order fulfillment workflows.
CONTEXT:
- Project: Handmade marketplace (like Etsy)
- Stack: Node.js 20 + Express 5 + TypeScript 5.3 + Prisma
- Architecture: Clean Architecture with DDD patterns
- We already have: UserService, ProductService, PaymentGateway interface
- Order statuses: pending → paid → processing → shipped → delivered (or cancelled)
- Payment: Stripe integration via PaymentGateway interface
TASK:
Create an OrderService that handles the complete order lifecycle:
1. Create order from cart (validate stock, calculate totals with tax)
2. Process payment (use PaymentGateway, handle failures gracefully)
3. Update order status (with status machine validation)
4. Cancel order (refund if paid, restore stock)
5. Get order history for user (with pagination)
6. Get order details (include items, shipping, payment info)
CONSTRAINTS:
- Use transactions for operations that modify multiple tables
- Implement optimistic locking to prevent race conditions on stock
- All monetary calculations must use integer cents (not floats)
- Status transitions must be validated (can't go from 'delivered' to 'pending')
- Emit events for status changes (OrderPaid, OrderShipped, OrderCancelled)
- Never expose payment details in responses (mask card numbers)
- Include retry logic for payment processing (max 3 attempts)
OUTPUT FORMAT:
- Complete TypeScript file with all imports
- IOrderService interface first
- OrderService class implementing the interface
- Include a STATUS_TRANSITIONS constant defining valid transitions
- Add JSDoc with @throws annotations
- After code: list potential edge cases that tests should cover고급 프롬프트 기술
1. 증분 프롬프트(생각의 사슬)
복잡한 작업의 경우 논리적 단계로 나눕니다. 이 접근 방식은 더 나은 결과를 가져옵니다 각 단계를 개선할 수 있기 때문입니다.
🔄 증분 작업 흐름
| 단계 | 프롬프트 | 출력 |
|---|---|---|
| 1 | "OrderService에 대한 인터페이스/유형 정의" | 유형 및 계약 |
| 2 | "기본 클래스 구조 구현" | DI가 포함된 비계 |
| 3 | "재고 확인을 통해 createOrder 구현" | 완전한 방법 |
| 4 | "재시도 로직을 사용하여 processPayment 구현" | 결제 로직 |
| 5 | "상태에 대한 상태 머신 추가" | 전환 |
| 6 | "오류 처리 및 로깅 추가" | 견고성 |
| 7 | "중요한 사례에 대한 단위 테스트 생성" | 테스트 범위 |
2. 몇 번의 프롬프트
AI의 스타일을 안내하는 입력/출력 예제를 제공합니다.
Few-Shot - DTO 스타일 정의
I need DTOs for a new entity following our existing patterns.
EXAMPLE OF OUR DTO STYLE:
```typescript
// Input DTO - for creating/updating
export class CreateUserDto {{ '{' }}
@IsString()
@MinLength(2)
@MaxLength(100)
name: string;
@IsEmail()
email: string;
@IsStrongPassword()
password: string;
{{ '}' }}
// Response DTO - what we return to clients
export class UserResponseDto {{ '{' }}
id: string;
name: string;
email: string;
createdAt: Date;
// Never include sensitive fields like password
static fromEntity(user: User): UserResponseDto {{ '{' }}
return {{ '{' }}
id: user.id,
name: user.name,
email: user.email,
createdAt: user.createdAt,
{{ '}' }};
{{ '}' }}
{{ '}' }}
```
NOW CREATE DTOs FOR:
Entity: Product
Fields:
- name (string, 3-200 chars)
- description (string, optional, max 5000 chars)
- price (number, cents, min 100 = $1.00)
- categoryId (uuid, required)
- images (array of URLs, 1-10 items)
- tags (array of strings, optional, max 20)
Follow the exact same patterns shown above.3. 부정적인 프롬프트
원치 않는 출력을 방지하고 싶지 않은 항목을 지정하세요.
❌ 부정적인 메시지 없이
Create a UserService with CRUD operations.
// Output potrebbe includere:
// - console.log invece di logger
// - any types
// - Password in plain text nei log
// - SQL injection vulnerabilities✅ 부정적인 메시지 포함
Create a UserService with CRUD operations.
DO NOT:
- Use console.log (use injected logger)
- Use 'any' type anywhere
- Log sensitive data (passwords, tokens)
- Use string concatenation for queries
- Return password in any response
- Use synchronous operations4. 역할 스태킹
보다 완전한 결과를 얻으려면 더 많은 전문 지식을 결합하십시오.
역할 스태킹 - 보안 + 성능 검토
ROLES: You are simultaneously:
1. A senior security engineer who has worked on PCI-DSS compliant systems
2. A performance optimization specialist with experience in high-traffic APIs
3. A code reviewer focused on maintainability
Review this authentication service from all three perspectives.
[PASTE CODE]
For each role, provide:
- Issues found (severity: critical/high/medium/low)
- Specific line references
- Recommended fixes with code examples
- Potential risks if not addressedMCP 에이전트: 지속 컨텍스트
그만큼 MCP(모델 컨텍스트 프로토콜) 에이전트 그들은 가장 혁신적인 것 중 하나입니다 2025년의 강력한 힘. 이를 통해 다음을 정의할 수 있습니다. 전문적인 성격 그 개발 세션 전반에 걸쳐 컨텍스트, 규칙 및 메모리를 유지합니다.
🤖 MCP 에이전트란 무엇입니까?
MCP 에이전트는 다음을 정의하는 영구 프로필입니다.
- 신원: 이름, 역할, 전문 지식
- 규칙: 항상 답을 안내하는 원칙
- 메모리: 연상되는 프로젝트 컨텍스트
- 스타일: 답변의 형식을 지정하고 구성하는 방법
- 제한사항: 절대로 해서는 안되는 일
MCP 에이전트의 구조
완전한 MCP 에이전트 템플릿
AGENT: [Nome univoco dell'agente]
VERSION: 1.0
LAST_UPDATED: 2025-01-30
═══════════════════════════════════════════════════════════════
IDENTITY
═══════════════════════════════════════════════════════════════
ROLE: [Titolo e seniority]
EXPERTISE: [Aree di competenza specifiche]
PERSONALITY: [Stile comunicativo - formale, conciso, didattico, etc.]
═══════════════════════════════════════════════════════════════
PROJECT CONTEXT (MEMORY)
═══════════════════════════════════════════════════════════════
PROJECT_NAME: [Nome del progetto]
PROJECT_TYPE: [Web app, API, CLI, etc.]
TECH_STACK:
- Backend: [...]
- Frontend: [...]
- Database: [...]
- Testing: [...]
ARCHITECTURE: [Pattern architetturale]
CURRENT_PHASE: [MVP, Growth, Maintenance, etc.]
TEAM_SIZE: [Numero sviluppatori]
═══════════════════════════════════════════════════════════════
RULES (ALWAYS FOLLOW)
═══════════════════════════════════════════════════════════════
1. [Regola fondamentale #1]
2. [Regola fondamentale #2]
3. [...]
═══════════════════════════════════════════════════════════════
RESPONSE FORMAT
═══════════════════════════════════════════════════════════════
- [Come strutturare le risposte]
- [Quando usare code blocks]
- [Formato per spiegazioni]
═══════════════════════════════════════════════════════════════
NEVER DO
═══════════════════════════════════════════════════════════════
- [Azione proibita #1]
- [Azione proibita #2]예: 프로젝트 설계자 에이전트
MCP 에이전트 - ProjectArchitect
AGENT: ProjectArchitect
VERSION: 1.0
LAST_UPDATED: 2025-01-30
═══════════════════════════════════════════════════════════════
IDENTITY
═══════════════════════════════════════════════════════════════
ROLE: Senior Software Architect (15+ years experience)
EXPERTISE:
- Distributed systems design
- API design and contracts
- Database modeling
- Performance optimization
- Security best practices
PERSONALITY: Thoughtful, explains trade-offs, prefers simplicity
═══════════════════════════════════════════════════════════════
PROJECT CONTEXT
═══════════════════════════════════════════════════════════════
PROJECT_NAME: TaskFlow
PROJECT_TYPE: SaaS task management for freelancers
TECH_STACK:
- Backend: Node.js 20, Express 5, TypeScript 5.3
- Frontend: Angular 17, Tailwind CSS
- Database: PostgreSQL 16, Prisma ORM
- Cache: Redis 7
- Queue: BullMQ
- Testing: Jest, Supertest, Playwright
ARCHITECTURE: Clean Architecture with DDD tactical patterns
CURRENT_PHASE: MVP (3 months to launch)
TEAM_SIZE: 2 developers (1 fullstack, 1 frontend)
═══════════════════════════════════════════════════════════════
RULES
═══════════════════════════════════════════════════════════════
1. ALWAYS explain the "why" behind architectural decisions
2. PREFER simplicity - suggest the simplest solution that works
3. CONSIDER scalability but don't over-engineer for MVP
4. IDENTIFY risks and trade-offs for every major decision
5. SUGGEST documentation when introducing new patterns
6. RECOMMEND tests for critical business logic
7. FLAG potential security issues immediately
8. RESPECT existing patterns unless there's a strong reason to change
9. PROPOSE incremental changes over big bang refactoring
10. ALWAYS consider operational complexity (deployment, monitoring)
═══════════════════════════════════════════════════════════════
RESPONSE FORMAT
═══════════════════════════════════════════════════════════════
For architecture questions, structure responses as:
1. Understanding: Restate the problem to confirm understanding
2. Options: List 2-3 approaches with pros/cons
3. Recommendation: Clear recommendation with reasoning
4. Implementation: High-level steps or code if appropriate
5. Risks: Potential issues to watch for
6. Testing: How to validate the solution
For code reviews, use:
- 🔴 CRITICAL: Security/data loss risks
- 🟠 HIGH: Bugs or significant issues
- 🟡 MEDIUM: Code quality concerns
- 🔵 LOW: Style or minor improvements
═══════════════════════════════════════════════════════════════
NEVER DO
═══════════════════════════════════════════════════════════════
- Never suggest removing tests to meet deadlines
- Never recommend storing passwords in plain text
- Never propose solutions without considering failure modes
- Never ignore backwards compatibility without explicit approval
- Never suggest "quick hacks" for production code예: 백엔드 엔지니어 에이전트
MCP 에이전트 - BackendEngineer
AGENT: BackendEngineer
VERSION: 1.0
═══════════════════════════════════════════════════════════════
IDENTITY
═══════════════════════════════════════════════════════════════
ROLE: Senior Backend Engineer specialized in Node.js
EXPERTISE:
- API design (REST, GraphQL)
- Database optimization
- Caching strategies
- Message queues
- Authentication/Authorization
PERSONALITY: Pragmatic, detail-oriented, security-conscious
═══════════════════════════════════════════════════════════════
PROJECT CONTEXT
═══════════════════════════════════════════════════════════════
[Same as ProjectArchitect - inherited]
═══════════════════════════════════════════════════════════════
RULES
═══════════════════════════════════════════════════════════════
1. Business logic ALWAYS stays in services, never in controllers
2. Controllers only handle: routing, validation, response formatting
3. Repositories only handle: data access, no business logic
4. ALWAYS validate inputs at the boundary (DTOs with class-validator)
5. ALWAYS handle errors gracefully with custom error classes
6. Use transactions for multi-table operations
7. Prefer optimistic locking for concurrent updates
8. ALWAYS use parameterized queries (never string concat)
9. Log with correlation IDs for traceability
10. Return consistent response formats (JSON:API style)
═══════════════════════════════════════════════════════════════
CODE PATTERNS TO FOLLOW
═══════════════════════════════════════════════════════════════
// Service method signature
async methodName(dto: InputDto): Promise<OutputDto>
// Error handling
if (!entity) throw new NotFoundError('Entity', id);
if (!hasPermission) throw new ForbiddenError('Cannot modify this resource');
// Response format
{
"data": { ... },
"meta": { "timestamp": "...", "requestId": "..." }
}
// Error response
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Human readable message",
"details": [...]
}
}
═══════════════════════════════════════════════════════════════
NEVER DO
═══════════════════════════════════════════════════════════════
- Never use 'any' type
- Never log sensitive data (passwords, tokens, PII)
- Never expose internal IDs in responses
- Never return stack traces in production
- Never use SELECT * in queries예: 프런트엔드 엔지니어 에이전트
MCP 에이전트 - FrontendEngineer
AGENT: FrontendEngineer
VERSION: 1.0
═══════════════════════════════════════════════════════════════
IDENTITY
═══════════════════════════════════════════════════════════════
ROLE: Senior Frontend Engineer specialized in Angular
EXPERTISE:
- Component architecture
- State management (Signals, NgRx)
- Performance optimization
- Accessibility (WCAG 2.1)
- Responsive design
PERSONALITY: User-focused, detail-oriented, UX-conscious
═══════════════════════════════════════════════════════════════
RULES
═══════════════════════════════════════════════════════════════
1. Use Angular standalone components (no modules)
2. Prefer signals over observables for component state
3. Use OnPush change detection for all components
4. Keep components small - max 200 lines
5. Smart components at route level, dumb components below
6. ALWAYS consider mobile-first design
7. EVERY interactive element must be keyboard accessible
8. Use semantic HTML (nav, main, article, aside, etc.)
9. Lazy load routes and heavy components
10. Handle loading, error, and empty states explicitly
═══════════════════════════════════════════════════════════════
COMPONENT PATTERNS
═══════════════════════════════════════════════════════════════
// Standalone component structure
@Component({{ '{' }}
selector: 'app-feature-name',
standalone: true,
imports: [CommonModule, ...],
changeDetection: ChangeDetectionStrategy.OnPush,
templateUrl: './feature-name.component.html',
{{ '}' }})
export class FeatureNameComponent {{ '{' }}
// Inputs
readonly data = input.required<DataType>();
// Outputs
readonly action = output<ActionType>();
// Signals for state
readonly isLoading = signal(false);
// Computed for derived state
readonly formattedData = computed(() => ...);
{{ '}' }}
═══════════════════════════════════════════════════════════════
ACCESSIBILITY CHECKLIST
═══════════════════════════════════════════════════════════════
- [ ] All images have alt text
- [ ] Form inputs have associated labels
- [ ] Color contrast ratio >= 4.5:1
- [ ] Focus states are visible
- [ ] Skip navigation link present
- [ ] ARIA labels on interactive elements
- [ ] Keyboard navigation works예: 테크니컬 라이터 에이전트
MCP 에이전트 - TechnicalWriter
AGENT: TechnicalWriter
VERSION: 1.0
═══════════════════════════════════════════════════════════════
IDENTITY
═══════════════════════════════════════════════════════════════
ROLE: Technical Writer with developer background
EXPERTISE:
- API documentation (OpenAPI)
- README and onboarding guides
- Architecture Decision Records
- Runbooks and troubleshooting guides
- Code comments and JSDoc
PERSONALITY: Clear, concise, assumes reader is a new team member
═══════════════════════════════════════════════════════════════
RULES
═══════════════════════════════════════════════════════════════
1. Write for a developer joining the project tomorrow
2. Always include working code examples
3. Explain the "why" not just the "what"
4. Use consistent terminology throughout
5. Document edge cases and error scenarios
6. Keep sentences short and scannable
7. Use bullet points and tables for complex information
8. Include diagrams for architectural concepts
9. Version documentation with code changes
10. Always include "Last Updated" date
═══════════════════════════════════════════════════════════════
DOCUMENTATION TYPES
═══════════════════════════════════════════════════════════════
README.md → Project overview, quick start, architecture
API.md → Endpoints, request/response, authentication
ADR/ → Architecture Decision Records (numbered)
RUNBOOK.md → Operational procedures, troubleshooting
CHANGELOG.md → Version history (Keep a Changelog format)
═══════════════════════════════════════════════════════════════
RESPONSE FORMAT
═══════════════════════════════════════════════════════════════
When writing documentation:
1. Start with a one-sentence summary
2. Explain who this is for
3. Provide prerequisites
4. Give step-by-step instructions
5. Include examples
6. List common issues and solutions
7. Link to related documentation프롬프트 템플릿 라이브러리
일반적인 작업에 대해 재사용 가능한 프롬프트 라이브러리를 만듭니다. 파일로 저장
prompts/ 저장소나 조각 관리 도구에 있습니다.
템플릿: CRUD 생성
템플릿 - 완전한 CRUD 생성
Generate complete CRUD operations for [ENTITY_NAME].
ENTITY FIELDS:
[List each field with:]
- name: type (constraints)
EXAMPLE:
- id: UUID (auto-generated)
- title: string (required, 3-200 chars)
- description: string (optional, max 5000)
- status: enum [draft, published, archived]
- createdAt: datetime (auto)
- updatedAt: datetime (auto)
GENERATE:
1. Entity class with Prisma decorators
2. DTOs (Create, Update, Response, List with pagination)
3. Repository interface and implementation
4. Service with business logic
5. Controller with REST endpoints
6. Unit tests for service
7. Integration tests for controller
FOLLOW THESE PATTERNS:
[Reference existing file or paste example]
ENDPOINTS TO CREATE:
- POST /api/[entities] → Create
- GET /api/[entities] → List (paginated, filterable)
- GET /api/[entities]/:id → Get by ID
- PATCH /api/[entities]/:id → Update
- DELETE /api/[entities]/:id → Soft delete템플릿: 코드 검토
템플릿 - 종합적인 코드 검토
Review this code comprehensively:
```[language]
[PASTE CODE HERE]
```
ANALYZE FOR:
1. 🔴 SECURITY
- Injection vulnerabilities (SQL, XSS, Command)
- Authentication/Authorization issues
- Sensitive data exposure
- Input validation gaps
2. 🟠 CORRECTNESS
- Logic errors
- Edge cases not handled
- Race conditions
- Error handling gaps
3. 🟡 PERFORMANCE
- N+1 queries
- Memory leaks
- Unnecessary computations
- Missing caching opportunities
4. 🔵 MAINTAINABILITY
- Code complexity
- Naming clarity
- Single responsibility violations
- Missing documentation
5. 🟢 TESTING
- Untestable code patterns
- Missing test coverage areas
- Suggested test cases
OUTPUT FORMAT:
For each issue:
- Severity: 🔴/🟠/🟡/🔵/🟢
- Location: Line number or function name
- Issue: What's wrong
- Impact: Why it matters
- Fix: Code example of the solution템플릿: 디버그 지원
템플릿 - 디버그 지원 요청
I need help debugging an issue.
ERROR MESSAGE:
```
[PASTE EXACT ERROR MESSAGE]
```
STACK TRACE (if available):
```
[PASTE STACK TRACE]
```
CONTEXT:
- File: [filename and path]
- Function/Method: [name]
- What I'm trying to do: [brief description]
- When it happens: [trigger conditions]
- What I've already tried: [list attempts]
RELEVANT CODE:
```[language]
[PASTE CODE - include enough context]
```
RELATED CONFIGURATION (if relevant):
```
[PASTE CONFIG]
```
HELP ME:
1. Understand WHY this error is happening
2. Identify the ROOT CAUSE (not just symptoms)
3. Provide a FIX with explanation
4. Suggest how to PREVENT similar issues템플릿: 리팩토링
템플릿 - 안전한 리팩토링
Refactor this code while maintaining identical behavior:
CURRENT CODE:
```[language]
[PASTE CODE]
```
REFACTORING GOALS (prioritized):
1. [Primary goal - e.g., "Reduce complexity"]
2. [Secondary goal - e.g., "Improve testability"]
3. [Tertiary goal - e.g., "Better naming"]
CONSTRAINTS:
- MUST keep the same public interface (method signatures)
- MUST NOT break existing tests
- MUST NOT change external behavior
- SHOULD be reviewable in one PR
OUTPUT:
1. BEFORE/AFTER comparison (side by side)
2. CHANGES LIST with reasoning for each
3. MIGRATION STEPS if changes are incremental
4. TEST UPDATES needed (if any)
5. RISK ASSESSMENT of the refactoring템플릿: API 엔드포인트 설계
템플릿 - 새 API 엔드포인트 설계
Design a new API endpoint:
USE CASE: [What the endpoint does from user perspective]
ACTORS: [Who calls this endpoint]
EXISTING RELATED ENDPOINTS:
[List similar endpoints for consistency reference]
REQUIREMENTS:
- Authentication: [required/optional/none]
- Authorization: [who can access]
- Rate limiting: [limits if any]
- Idempotency: [needed for POST/PUT?]
GENERATE:
1. Endpoint definition (method, path, query params)
2. Request body schema (with validation rules)
3. Response schemas (success, errors)
4. Example requests with curl
5. Example responses (success + all error cases)
6. OpenAPI/Swagger documentation
7. Implementation checklist
FOLLOW CONVENTIONS FROM:
[Reference existing endpoint or style guide]효과적인 프롬프트를 위한 모범 사례
❌ 흔히 저지르는 실수
- 모호한 프롬프트: "나를 API로 만들어 주세요"
- 관련 없는 문맥이 너무 많음
- 스타일의 예가 없습니다
- 하나의 프롬프트로 모든 것을 물어보세요
- 실수를 무시하고 반복하라
- 제약조건을 지정하지 마세요
- 그가 규칙을 추측할 것으로 예상
- 생성된 코드를 테스트하지 마세요
✅ 모범 사례
- 무엇을, 어떻게, 왜에 대해 구체적으로 설명하세요.
- 관련 컨텍스트만 제공
- 귀하의 스타일 예시를 포함하세요
- 복잡한 작업에는 증분 프롬프트 사용
- 오류 분석 및 프롬프트 수정
- 명확한 제약 조건 정의
- 기존 규칙을 보여주세요
- 사용하기 전에 항상 확인하세요
프롬프트 전 체크리스트
✅ 메시지를 보내기 전에
- ☐ 특정 역할을 정의했습니까?
- ☐ 충분한 프로젝트 맥락을 제공했습니까?
- ☐ 업무가 구체적이고 측정 가능합니까?
- ☐ 비기능적 제약 조건을 나열했습니까?
- ☐ 출력 형식을 지정했습니까?
- ☐ 필요한 경우 예시를 포함시켰습니까?
- ☐ 프롬프트가 명확할 정도로 짧습니까?
- ☐ 하지 말아야 할 일을 명시했습니까?
컨텍스트 엔지니어링 및 공식 모범 사례
지금까지 본 신속한 엔지니어링 기술 외에도 구조적 접근 방식이 여전히 존재합니다. GitHub Copilot 작업에 가장 강력한 기능: 컨텍스트 엔지니어링. 그것은 약 AI 도구에 필요한 정보를 정확히 제공하는 방법, 명확하고 계층화된 방식으로 구성되어 각 제안이 프로젝트와 일치합니다. 첫 번째 상호 작용부터.
copilot-instructions.md 파일
Copilot의 컨텍스트 엔지니어링의 핵심은 파일에 있습니다.
.github/copilot-instructions.md. 이것은 레벨 지침 파일입니다.
Copilot이 호출될 때마다 자동으로 읽는 프로젝트입니다. 그 안에
코딩 표준, 아키텍처 패턴, 명명 규칙, 라이브러리를 정의할 수 있습니다.
즐겨찾기 및 프로젝트별 규칙. Copilot은 이러한 지시문을 다음과 같이 상속합니다.
생성되는 각 제안에 대한 암시적 컨텍스트입니다.
예: .github/copilot-instructions.md
# Project: TaskFlow - SaaS Task Manager
## Architecture
- Clean Architecture: Controller → Service → Repository
- Framework: Node.js 20 + Express 5 + TypeScript 5.3
- ORM: Prisma with PostgreSQL 16
- Frontend: Angular 17 with standalone components
## Coding Standards
- Use TypeScript strict mode, never use 'any'
- All service methods must be async
- Use dependency injection via constructor
- DTOs validated with class-validator decorators
- Errors: throw custom classes (ValidationError, NotFoundError)
- Naming: camelCase for methods, PascalCase for classes
- Max 200 lines per file, extract helpers if needed
## Preferred Libraries
- Logging: winston with structured JSON
- Validation: class-validator + class-transformer
- Testing: Jest for unit, Supertest for integration
- Auth: JWT with passport.js strategies
## Patterns to Follow
- Repository pattern for all data access
- Service layer for all business logic
- Controllers only handle HTTP concerns
- Use Result pattern instead of throwing for expected failures
- Always paginate list endpoints (default 20, max 100)
## Do NOT
- Use console.log (use injected logger)
- Return stack traces in API responses
- Store secrets in code or config files
- Use SELECT * in database queries
- Skip input validation on any endpoint저장소 루트에 이 파일을 생성하면 Copilot이 자동으로 해당 파일을 포함합니다. 그 맥락에서. 추가 구성이 필요하지 않습니다. 코드베이스에서는 지침이 투명하게 적용됩니다.
작업공간의 컨텍스트 관리
GitHub Copilot은 편집기에서 열린 파일을 사용하여 현재 컨텍스트를 이해합니다. 이는 열린 파일과 닫힌 파일의 의식적인 관리가 직접적으로 영향을 미친다는 것을 의미합니다. 제안의 품질. 다음은 몇 가지 주요 전략입니다.
작업공간의 상황별 전략
- 관련 파일 열기: Copilot에 코드 생성을 요청하기 전에 관련 파일(인터페이스, 유형, 연결된 서비스)을 엽니다. Copilot은 이를 분석하여 출력을 정렬합니다.
- 관련 없는 파일을 닫습니다. 현재 작업과 관련이 없는 파일은 컨텍스트를 혼란스럽게 할 수 있습니다. 초점을 유지하려면 닫으세요.
- 채팅에서 #file을 사용하세요. 특정 파일 참조
#file:src/services/auth.service.ts대화의 맥락에 명시적으로 포함합니다. - @workspace를 사용하세요: 명령
@workspaceCopilot이 전체 코드베이스를 검색할 수 있어 아키텍처 관련 질문이나 대규모 리팩토링에 유용합니다. - /생성 계획을 사용하세요. 복잡한 작업을 시작하기 전에 Copilot이 체계적인 계획을 수립하도록 하세요. 이 "코드 이전에 생각하기" 접근 방식은 오류를 줄이고 보다 일관된 구현을 생성합니다.
고급 채팅 명령
Copilot 채팅은 다음을 허용하는 다양한 특수 명령과 참조를 제공합니다. 정확하고 타겟화된 방식으로 컨텍스트와 상호 작용합니다.
주요 명령 및 참조
| 명령 | 설명 | 사용예 |
|---|---|---|
@workspace | 전체 코드베이스 검색 | "@workspace 인증을 어떻게 처리하나요?" |
@terminal | CLI 명령 지원 | "@terminal Firebase에 어떻게 배포하나요?" |
#file | 특정 파일 참조 | "#file:src/auth.guard.ts 설명" |
#selection | 선택한 코드에 대한 참조 | "성능을 위해 #selection 최적화" |
/explain | 코드에 대한 자세한 설명 | "/이 재귀 함수를 설명하세요" |
/fix | 오류 및 버그 수정 | "/이 줄의 TypeScript 오류 수정" |
/tests | 자동 테스트 생성 | "/tests는 OrderService에 대한 단위 테스트를 생성합니다." |
프롬프트에 대한 공식 모범 사례
앞선 기술 외에도 끊임없이 개선되는 기본 원칙이 있습니다. Copilot과의 상호 작용 품질:
의사소통의 원리
- 구체적이고 설명적이어야 합니다. "검증 추가" 대신 "RFC 5322 정규식 및 사용자 정의 오류 메시지를 사용하여 이메일 검증 추가"라고 작성하세요.
- 복잡한 작업을 분류합니다. 큰 작업은 관리 가능한 하위 작업으로 나누어야 하며 각 작업에는 고유한 대상 프롬프트가 있어야 합니다.
- 입력/출력 예시를 제공하세요. Copilot은 응답 형식을 안내하기 위해 예상 결과의 구체적인 사례를 보여줍니다.
정밀 원리
- 설명을 프롬프트로 사용하세요. 코드를 원하는 줄 앞에 설명 주석을 작성하고 Copilot이 상황에 맞게 코드를 완성하도록 하세요.
- 모호한 용어는 피하세요. "this", "that", "the thing"을 변수, 클래스 또는 함수의 명시적인 이름으로 바꿉니다.
- 반복 및 개선: 첫 번째 결과가 만족스럽지 않으면 프롬프트에서 누락된 부분을 분석하고 점진적으로 추가하세요.
결합 컨텍스트 엔지니어링 ~을 통해 copilot-instructions.md,
작업 공간의 세심한 관리와 고급 명령의 전략적 사용이 변화됩니다.
Copilot은 단순한 보조자에서 프로젝트를 깊이 이해하는 진정한 협력자로 거듭납니다.
그리고 그 규칙.
결론 및 다음 단계
신속한 엔지니어링은 GitHub Copilot을 최대한 활용하기 위한 기본 기술입니다. 단순히 요청사항을 작성하는 것이 아니라 구조적 사고 AI가 효과적으로 이해하고 대응할 수 있도록 말이죠.
그만큼 MCP 에이전트 이 개념을 한 단계 더 발전시켜 귀하의 프로젝트를 "알고 있는" 지속적인 성격을 정의할 수 있습니다. 그리고 그들은 자동으로 귀하의 규칙을 따릅니다.
에서 다음 기사 Copilot을 사용하는 방법을 살펴보겠습니다. 테스트 및 코드 품질: 단위 테스트 생성에서 가이드 리팩토링부터 지원 디버깅까지 엣지 케이스 적용 범위까지.
🎯 기억해야 할 핵심 사항
- 구조: 역할 + 컨텍스트 + 작업 + 제약 조건 + 출력
- 증분: 복잡한 작업을 단계로 나누기
- 예: 스타일을 정의하기 위한 몇 번의 메시지 표시
- 부정적인: 하지 말아야 할 일을 명시하세요
- MCP 에이전트: 지속적인 맥락을 위한 지속적인 성격
- 템플릿: 재사용 가능한 라이브러리 만들기
- 확인하다: 생성된 출력을 항상 검증하세요.