부록: 바이브 코딩 프롬프트 패턴 카탈로그

이 부록은 책 전체에서 다룬 효과적인 프롬프트 패턴을 체계적으로 정리한 빠른 참조 가이드입니다. 각 패턴은 컴퓨팅 사고의 4대 원리(분해, 패턴 인식, 추상화, 알고리즘적 사고)에 기반하며, GitHub Copilot과의 협업에서 즉시 활용할 수 있습니다.

📖 사용 가이드

패턴 구조

각 패턴은 다음과 같이 구성되어 있습니다:

패턴 이름: 패턴의 목적을 명확히 표현
사용 시기: 어떤 상황에서 이 패턴을 사용하는가
템플릿: 즉시 사용 가능한 프롬프트 템플릿
예시: 실제 적용 사례
팁: 효과를 극대화하는 노하우

패턴 선택 가이드

문제를 처음 만났을 때: 분해 패턴 사용
반복되는 구조를 발견했을 때: 패턴 인식 패턴 사용
복잡한 세부사항을 숨기고 싶을 때: 추상화 패턴 사용
효율적인 솔루션이 필요할 때: 알고리즘적 사고 패턴 사용

1. 분해 (Decomposition) 패턴

1.1 계층적 분해 패턴

사용 시기: 대규모 시스템을 설계하거나 복잡한 기능을 구조화할 때

템플릿:

[문제 또는 시스템 이름]을 다음 계층으로 분해해주세요:
1. 최상위 레벨: [핵심 도메인 또는 서브시스템]
2. 중간 레벨: [주요 컴포넌트 또는 모듈]
3. 하위 레벨: [구체적인 기능 또는 클래스]

각 계층에서 단일 책임 원칙을 준수하고, 계층 간 의존성을 명확히 해주세요.

예시:

온라인 쇼핑몰 시스템을 다음 계층으로 분해해주세요:
1. 최상위 레벨: 사용자 관리, 상품 카탈로그, 주문 처리, 결제
2. 중간 레벨: 각 도메인별 서비스, 리포지토리, 도메인 모델
3. 하위 레벨: 엔티티, 값 객체, 도메인 이벤트

각 계층에서 단일 책임 원칙을 준수하고, 계층 간 의존성을 명확히 해주세요.

팁:

3단계 이상 깊어지면 복잡도가 증가하므로 적절히 조정
각 레벨에서 "왜 이렇게 나눴는가?"를 명확히 요청
DDD나 Clean Architecture 같은 아키텍처 패턴 언급 시 더 정확한 결과

1.2 기능 분해 패턴

사용 시기: 특정 기능을 단계별로 나누거나 워크플로우를 설계할 때

템플릿:

[기능 이름]을 단계별로 분해하고, 각 단계를 독립적인 함수/메서드로 구현해주세요.

요구사항:
- 각 단계는 하나의 명확한 책임만 가짐
- 단계 간 데이터 전달을 명시적으로 정의
- 에러 처리는 각 단계에서 독립적으로
- TypeScript로 타입 안전하게 구현

[추가 제약 조건이나 비즈니스 규칙]

예시:

"사용자 회원가입" 기능을 단계별로 분해하고, 각 단계를 독립적인 함수/메서드로 구현해주세요.

요구사항:
- 각 단계는 하나의 명확한 책임만 가짐
- 단계 간 데이터 전달을 명시적으로 정의
- 에러 처리는 각 단계에서 독립적으로
- TypeScript로 타입 안전하게 구현

비즈니스 규칙:
- 이메일 중복 검사
- 비밀번호 강도 검증 (8자 이상, 특수문자 포함)
- 환영 이메일 발송

팁:

각 단계의 입력과 출력을 명확히 요청하면 인터페이스가 깔끔해짐
에러 처리 전략(예외 vs Result 타입)을 명시하면 일관성 있는 코드 생성
테스트 가능한 구조를 명시적으로 요청

1.3 도메인 분해 패턴 (DDD)

사용 시기: 비즈니스 도메인 중심의 시스템 설계를 할 때

템플릿:

[도메인 이름] 도메인을 Domain-Driven Design 원칙에 따라 다음으로 분해해주세요:

1. Bounded Context: [도메인 경계 정의]
2. Aggregate Root: [핵심 엔티티]
3. Entity: [식별자를 가진 객체]
4. Value Object: [불변 값 객체]
5. Domain Event: [도메인 이벤트]
6. Repository: [영속성 인터페이스]

각 요소의 역할과 관계를 명확히 설명하고, [언어]로 구현해주세요.

예시:

"주문 관리" 도메인을 Domain-Driven Design 원칙에 따라 다음으로 분해해주세요:

1. Bounded Context: Order Management
2. Aggregate Root: Order
3. Entity: OrderItem
4. Value Object: Address, Money, OrderStatus
5. Domain Event: OrderPlaced, OrderCancelled, OrderShipped
6. Repository: IOrderRepository

각 요소의 역할과 관계를 명확히 설명하고, TypeScript로 구현해주세요.

팁:

Ubiquitous Language(공통 언어)를 먼저 정의하면 더 정확한 모델링
Aggregate 경계를 명확히 하면 트랜잭션 관리가 쉬워짐
도메인 이벤트는 시스템 간 결합도를 낮추는 핵심

2. 패턴 인식 (Pattern Recognition) 패턴

2.1 코드 패턴 발견 패턴

사용 시기: 기존 코드베이스에서 반복되는 구조를 찾고 리팩토링할 때

템플릿:

다음 코드에서 반복되는 패턴을 식별하고, 재사용 가능한 추상화로 리팩토링해주세요:

[코드 블록]

요구사항:
- 중복 제거
- 확장 가능한 구조
- 명확한 네이밍
- [언어]의 관용적 패턴 사용

예시:

다음 코드에서 반복되는 패턴을 식별하고, 재사용 가능한 추상화로 리팩토링해주세요:

function createUser(data) { /* validation, save, notify */ }
function createProduct(data) { /* validation, save, notify */ }
function createOrder(data) { /* validation, save, notify */ }

요구사항:
- 중복 제거
- 확장 가능한 구조
- 명확한 네이밍
- TypeScript의 제네릭 사용

팁:

3회 이상 반복되는 코드는 패턴으로 추출 고려
Template Method 또는 Strategy 패턴 언급 시 더 정교한 리팩토링
테스트 코드도 함께 요청하면 안전성 확보

2.2 아키텍처 패턴 적용 패턴

사용 시기: 검증된 아키텍처 패턴을 시스템에 적용할 때

템플릿:

[시스템 또는 기능 이름]에 [패턴 이름] 패턴을 적용해주세요.

컨텍스트:
[현재 시스템 상황, 제약 조건, 요구사항]

패턴 적용 시 다음을 포함:
- 패턴의 핵심 요소 구현
- 각 요소 간 상호작용 방식
- [언어]의 관용적 구현
- 예제 사용 코드

예시:

사용자 인증 시스템에 Strategy 패턴을 적용해주세요.

컨텍스트:
- 다양한 인증 방식 지원 필요 (로컬, OAuth, SAML)
- 런타임에 인증 방식 전환 가능해야 함
- 새로운 인증 방식 추가가 용이해야 함

패턴 적용 시 다음을 포함:
- Strategy 인터페이스와 구체 전략들
- Context 클래스
- TypeScript로 타입 안전하게 구현
- 각 전략 사용 예제 코드

팁:

GoF 디자인 패턴 이름을 명시하면 정확한 구조 생성
패턴의 "의도(Intent)"를 함께 설명하면 더 적절한 적용
과도한 패턴 적용(Over-engineering) 주의

2.3 데이터 패턴 분석 패턴

사용 시기: 데이터에서 반복되는 구조나 관계를 찾을 때

템플릿:

다음 데이터 구조에서 패턴을 분석하고, 정규화/비정규화 전략을 제안해주세요:

[데이터 스키마 또는 샘플 데이터]

분석 항목:
- 반복되는 데이터 구조
- 데이터 간 관계 (1:1, 1:N, N:M)
- 중복 데이터 및 이상 현상
- 쿼리 패턴에 따른 최적화 제안

[데이터베이스 종류: SQL/NoSQL]

예시:

다음 전자상거래 데이터 구조에서 패턴을 분석하고, 정규화/비정규화 전략을 제안해주세요:

Order { userId, products: [{id, name, price, quantity}], totalAmount, address }
User { id, name, email, orders: [...] }
Product { id, name, price, stock }

분석 항목:
- 반복되는 데이터 구조
- 데이터 간 관계 (1:1, 1:N, N:M)
- 중복 데이터 및 이상 현상
- 쿼리 패턴에 따른 최적화 제안

PostgreSQL 사용

팁:

읽기/쓰기 비율을 명시하면 더 정확한 최적화 전략
CQRS 패턴 고려 시 읽기 모델과 쓰기 모델 분리 요청
샤딩이나 파티셔닝 전략도 함께 요청 가능

3. 추상화 (Abstraction) 패턴

3.1 인터페이스 추상화 패턴

사용 시기: 구현 세부사항을 숨기고 명확한 계약을 정의할 때

템플릿:

[기능 또는 컴포넌트 이름]에 대한 인터페이스를 설계해주세요.

요구사항:
- 구현 세부사항이 아닌 "무엇을 하는가"에 집중
- 최소한의 메서드로 완전한 기능 제공
- 명확한 입력/출력 타입
- [언어]의 인터페이스/추상 클래스 사용

설계 원칙:
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
- 변경에 닫혀있고 확장에 열려있음 (OCP)

예시:

"이메일 발송" 기능에 대한 인터페이스를 설계해주세요.

요구사항:
- 구현 세부사항(SMTP, SendGrid, AWS SES 등)을 숨김
- 최소한의 메서드로 이메일 발송 가능
- 타입 안전한 이메일 데이터 구조
- TypeScript 인터페이스 사용

설계 원칙:
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
- 다양한 이메일 제공자 교체 가능

팁:

"역할(Role)" 기반으로 인터페이스 분리하면 ISP 준수
반환 타입으로 Result<T, E> 같은 명시적 에러 처리 권장
인터페이스 이름은 "I" 접두사보다 역할 중심 네이밍 (예: EmailSender)

3.2 계층 추상화 패턴

사용 시기: 시스템을 논리적 계층으로 분리할 때 (예: Clean Architecture, Hexagonal Architecture)

템플릿:

[시스템 이름]을 다음 계층으로 추상화해주세요:

1. Domain Layer: 비즈니스 로직과 규칙
2. Application Layer: 유스케이스 및 워크플로우
3. Infrastructure Layer: 외부 시스템 통합
4. Presentation Layer: 사용자 인터페이스

각 계층의 책임과 의존성 방향을 명확히 하고, [언어]로 구현해주세요.

의존성 규칙: 외부 → 내부 (Presentation → Application → Domain)

예시:

블로그 시스템을 다음 계층으로 추상화해주세요:

1. Domain Layer: Post, Author, Comment 엔티티 및 비즈니스 규칙
2. Application Layer: CreatePost, PublishPost, DeletePost 유스케이스
3. Infrastructure Layer: PostgreSQL 리포지토리, S3 파일 저장소
4. Presentation Layer: REST API 컨트롤러

각 계층의 책임과 의존성 방향을 명확히 하고, TypeScript로 구현해주세요.

의존성 규칙: Presentation → Application → Domain ← Infrastructure

팁:

Domain Layer는 외부 의존성 제로 (순수 비즈니스 로직)
Application Layer는 의존성 주입(DI)으로 Infrastructure 주입
각 계층별로 별도 폴더/모듈 구조 요청하면 코드 조직화 용이

3.3 데이터 추상화 패턴 (DTO, VO)

사용 시기: 계층 간 데이터 전달이나 불변 값 객체를 정의할 때

템플릿:

[도메인 개념]을 다음 데이터 추상화로 구현해주세요:

1. Entity: 식별자를 가진 변경 가능한 객체
2. Value Object: 불변이며 값으로만 비교되는 객체
3. DTO: 계층 간 데이터 전달 객체

각 타입의 특성:
- Entity: 생명주기 관리, 동등성은 ID 기반
- Value Object: 불변성, 동등성은 값 기반
- DTO: 데이터 전송 최적화, 검증 로직 포함

[언어]로 구현하고, 각 타입의 사용 예시 포함

예시:

"주문(Order)" 개념을 다음 데이터 추상화로 구현해주세요:

1. Entity: Order (id, items, status, createdAt)
2. Value Object: Money (amount, currency), Address (street, city, zipCode)
3. DTO: CreateOrderDTO, OrderResponseDTO

각 타입의 특성:
- Order: 주문 생명주기 관리, ID로 식별
- Money/Address: 불변 객체, 값으로 비교
- DTO: API 요청/응답 최적화

TypeScript로 구현하고, Zod로 검증 스키마 포함

팁:

Value Object는 생성자에서 유효성 검증하여 항상 유효한 상태 보장
DTO는 직렬화/역직렬화 명확히 정의 (JSON, Protobuf 등)
Entity는 불변성보다 일관성(Consistency)이 중요

4. 알고리즘적 사고 (Algorithmic Thinking) 패턴

4.1 효율성 최적화 패턴

사용 시기: 성능이 중요한 알고리즘을 설계하거나 개선할 때

템플릿:

다음 문제를 효율적으로 해결하는 알고리즘을 설계해주세요:

문제: [문제 설명]
입력: [입력 형식 및 크기]
출력: [출력 형식]

요구사항:
- 시간 복잡도: O([목표 복잡도])
- 공간 복잡도: O([목표 복잡도])
- [언어]로 구현
- 엣지 케이스 처리

알고리즘 설명 포함:
1. 접근 방법 (예: 동적 계획법, 탐욕 알고리즘, 분할 정복)
2. 시간/공간 복잡도 분석
3. 최적화 기법

예시:

다음 문제를 효율적으로 해결하는 알고리즘을 설계해주세요:

문제: 배열에서 두 수의 합이 target인 모든 쌍 찾기
입력: 정수 배열 (최대 10^6개), target 정수
출력: [index1, index2] 쌍의 배열

요구사항:
- 시간 복잡도: O(n)
- 공간 복잡도: O(n)
- TypeScript로 구현
- 중복 처리, 음수 처리

알고리즘 설명 포함:
1. 해시맵 활용 (Two-Pass vs One-Pass)
2. 시간 O(n), 공간 O(n) 분석
3. 추가 최적화 가능 여부

팁:

입력 크기를 명시하면 적절한 알고리즘 선택 가능
"시간 우선" vs "메모리 우선" 트레이드오프 명시
벤치마크 코드도 함께 요청하면 성능 검증 가능

4.2 단계별 솔루션 패턴

사용 시기: 복잡한 문제를 명확한 단계로 나누어 해결할 때

템플릿:

다음 문제를 단계별로 해결하는 알고리즘을 작성해주세요:

문제: [문제 설명]

단계:
1. [1단계 설명]
2. [2단계 설명]
3. [3단계 설명]
...

각 단계별로:
- 입력과 출력 명시
- 시간 복잡도 분석
- [언어]로 구현
- 단위 테스트 포함

예시:

사용자 활동 로그에서 이상 패턴을 탐지하는 알고리즘을 작성해주세요:

문제: 시간 순서로 정렬된 로그 데이터에서 비정상적인 활동 탐지

단계:
1. 로그 데이터 파싱 및 정규화
2. 시간 윈도우별 통계 계산 (평균, 표준편차)
3. Z-score 기반 이상치 탐지 (threshold: 3σ)
4. 이상 패턴 보고서 생성

각 단계별로:
- 입력과 출력 명시
- 시간 복잡도 분석
- TypeScript로 구현
- 단위 테스트 포함

팁:

각 단계를 순수 함수로 구현하면 테스트와 디버깅 용이
파이프라인 패턴으로 단계 연결 가능
중간 결과 로깅 요청하면 디버깅 편리

4.3 재귀적 사고 패턴

사용 시기: 문제가 자기 자신의 작은 버전으로 표현될 때 (트리, 그래프, 분할 정복)

템플릿:

다음 문제를 재귀적으로 해결해주세요:

문제: [문제 설명]
기저 조건: [재귀 종료 조건]
재귀 관계: [큰 문제를 작은 문제로 분해하는 방법]

요구사항:
- 명확한 기저 조건
- 스택 오버플로우 방지 (꼬리 재귀 또는 반복 변환)
- [언어]로 구현
- 재귀 트리 시각화 주석 포함

예시:

디렉토리 구조를 깊이 우선 탐색하며 파일 크기 합계를 계산해주세요:

문제: 주어진 디렉토리의 모든 파일 크기 합계 (하위 디렉토리 포함)
기저 조건: 파일인 경우 파일 크기 반환, 빈 디렉토리인 경우 0 반환
재귀 관계: 디렉토리의 총 크기 = 모든 하위 항목 크기의 합

요구사항:
- 명확한 기저 조건
- 심볼릭 링크 순환 참조 방지
- TypeScript로 구현
- 재귀 깊이 제한 (예: 100)

팁:

재귀 깊이가 깊으면 반복문 버전도 함께 요청
메모이제이션(Memoization)으로 중복 계산 방지
재귀 호출 트리를 주석으로 요청하면 이해 용이

5. 복합 패턴 (Multi-Principle Patterns)

5.1 전체 시스템 설계 패턴

사용 시기: 처음부터 끝까지 전체 시스템을 설계할 때

템플릿:

[시스템 이름]을 다음 원칙에 따라 설계해주세요:

1. 분해: 시스템을 도메인, 레이어, 모듈로 나누기
2. 패턴 인식: 재사용 가능한 패턴 식별 및 적용
3. 추상화: 명확한 인터페이스와 계약 정의
4. 알고리즘: 핵심 비즈니스 로직의 효율적 구현

요구사항:
- Clean Architecture 또는 Hexagonal Architecture
- DDD 전술적 패턴 적용
- SOLID 원칙 준수
- [언어]로 구현
- 테스트 전략 포함

예시:

"온라인 예약 시스템"을 다음 원칙에 따라 설계해주세요:

1. 분해: Reservation, User, Resource 도메인 / Clean Architecture 4계층
2. 패턴 인식: Repository, Unit of Work, CQRS
3. 추상화: 도메인 인터페이스, 애플리케이션 서비스 인터페이스
4. 알고리즘: 예약 가능 시간 탐색 (효율적 시간 슬롯 매칭)

요구사항:
- Clean Architecture 적용
- DDD 전술적 패턴 (Aggregate, Entity, Value Object)
- SOLID 원칙 준수
- TypeScript + NestJS
- 단위/통합 테스트 전략

팁:

전체 설계를 한 번에 요청하기보다 단계별로 진행
먼저 도메인 모델링 → 유스케이스 → 인프라 순서 추천
각 단계마다 검증하고 피드백 반영

5.2 레거시 리팩토링 패턴

사용 시기: 기존 코드를 현대적 아키텍처로 점진적으로 개선할 때

템플릿:

다음 레거시 코드를 리팩토링해주세요:

[기존 코드 또는 구조 설명]

리팩토링 목표:
1. 분해: God Class/Function을 작은 단위로 분리
2. 패턴 인식: 중복 제거 및 디자인 패턴 적용
3. 추상화: 의존성 역전, 인터페이스 도입
4. 알고리즘: 비효율적인 로직 최적화

제약 조건:
- 기존 API 인터페이스 유지 (Breaking Change 최소화)
- 점진적 마이그레이션 가능 (Strangler Fig 패턴)
- 테스트 커버리지 확보
- [언어]로 구현

예시:

다음 1000줄짜리 UserService 클래스를 리팩토링해주세요:

class UserService {
  // 사용자 CRUD, 인증, 권한, 알림, 로깅 등 모두 포함
}

리팩토링 목표:
1. 분해: UserRepository, AuthService, NotificationService 등으로 분리
2. 패턴 인식: Strategy (인증), Observer (알림), Repository
3. 추상화: 각 서비스 인터페이스 정의, DI 적용
4. 알고리즘: N+1 쿼리 문제 해결

제약 조건:
- 기존 REST API 엔드포인트 유지
- Strangler Fig 패턴으로 점진적 교체
- 단위 테스트 작성
- TypeScript로 현대화

팁:

리팩토링 전 테스트 작성 필수 (Characterization Test)
한 번에 큰 변경보다 작은 단위로 나눠서 진행
Branch by Abstraction 패턴으로 안전한 마이그레이션

5.3 API 설계 패턴

사용 시기: 사용자 친화적이고 확장 가능한 API를 설계할 때

템플릿:

[API 이름]을 다음 원칙에 따라 설계해주세요:

1. 분해: 리소스 기반 URL 구조, 엔드포인트 분리
2. 패턴 인식: REST 또는 GraphQL 표준 패턴
3. 추상화: 명확한 요청/응답 스키마, 에러 처리
4. 알고리즘: 페이지네이션, 필터링, 정렬 최적화

설계 원칙:
- RESTful 또는 GraphQL Best Practices
- 일관된 네이밍 컨벤션
- 버전 관리 전략
- 보안 (인증, 인가, Rate Limiting)
- [프레임워크]로 구현

예시:

"블로그 플랫폼 API"를 다음 원칙에 따라 설계해주세요:

1. 분해: /posts, /authors, /comments, /tags 리소스
2. 패턴 인식: RESTful, HATEOAS (Hypermedia)
3. 추상화: OpenAPI 3.0 스펙, 에러 응답 표준화
4. 알고리즘: Cursor-based 페이지네이션, Full-text 검색

설계 원칙:
- RESTful Level 3 (HATEOAS)
- 일관된 snake_case 네이밍
- URL 버전 관리 (/v1/posts)
- JWT 인증, RBAC 인가, Rate Limiting (100 req/min)
- NestJS + OpenAPI (Swagger)

팁:

API 문서 자동 생성 도구(Swagger, Redoc) 활용 명시
에러 코드 체계를 RFC 7807 (Problem Details) 표준 권장
GraphQL인 경우 스키마 설계와 N+1 문제 해결 포함 요청

6. GitHub Copilot Agent 특화 패턴

6.1 컨텍스트 제공 패턴

사용 시기: Agent에게 충분한 맥락을 제공하여 정확한 코드 생성을 유도할 때

템플릿:

# 프로젝트 컨텍스트
- 프로젝트 종류: [웹앱/API/CLI/라이브러리 등]
- 기술 스택: [언어, 프레임워크, 데이터베이스]
- 아키텍처: [Clean Architecture/MVC/Microservices 등]
- 코딩 컨벤션: [스타일 가이드 링크 또는 주요 규칙]

# 작업 내용
[구체적인 작업 설명]

# 파일 위치 및 관련 코드
- [관련 파일 경로 또는 코드 스니펫]

# 제약 조건
- [기술적 제약, 성능 요구사항, 보안 고려사항]

예시:

# 프로젝트 컨텍스트
- 프로젝트 종류: 전자상거래 REST API
- 기술 스택: TypeScript, NestJS, PostgreSQL, TypeORM
- 아키텍처: Clean Architecture (Domain, Application, Infrastructure, Presentation)
- 코딩 컨벤션: Airbnb TypeScript Style Guide

# 작업 내용
Order Aggregate에 "주문 취소" 도메인 로직 추가

# 파일 위치 및 관련 코드
- src/domain/order/Order.entity.ts (기존 엔티티)
- src/domain/order/OrderStatus.enum.ts (상태 정의)

# 제약 조건
- 취소 가능한 상태: PENDING, CONFIRMED (배송 시작 전만)
- 도메인 이벤트 발행: OrderCancelled
- 불변성 보장 (새 인스턴스 반환)

팁:

Copilot이 프로젝트 구조를 이해할 수 있도록 파일 트리 공유
기존 코드 스타일을 참고할 수 있도록 예시 파일 명시
"워크스페이스 컨텍스트"를 Agent에게 명시적으로 요청

6.2 반복 개선 패턴

사용 시기: 생성된 코드를 점진적으로 개선하고 최적화할 때

템플릿:

[1단계: 초기 구현 요청]
[기본 기능 설명] - 일단 작동하는 버전

[2단계: 개선 요청]
위 코드를 다음 관점에서 개선해주세요:
- 성능: [구체적 성능 목표]
- 가독성: [코드 품질 개선]
- 확장성: [미래 변경 고려]
- 테스트: [테스트 추가]

[3단계: 최종 최적화]
다음 추가 요구사항 반영:
- [구체적 요구사항]

예시:

[1단계: 초기 구현]
배열에서 중복을 제거하는 함수 작성 - TypeScript

[2단계: 개선]
위 함수를 다음 관점에서 개선해주세요:
- 성능: O(n) 시간 복잡도 (Set 활용)
- 가독성: 명확한 변수 이름, JSDoc 주석
- 확장성: 제네릭으로 모든 타입 지원
- 테스트: Vitest 단위 테스트 추가

[3단계: 최종 최적화]
다음 추가 요구사항 반영:
- 커스텀 비교 함수 지원 (객체 배열 중복 제거)
- 대규모 배열(100만 항목) 처리 최적화
- 엣지 케이스 (빈 배열, null, undefined) 처리

팁:

처음부터 완벽한 코드를 요구하지 말고 단계적 개선
각 단계에서 명확한 피드백 제공
"왜" 개선이 필요한지 이유 설명하면 더 나은 결과

6.3 멀티 파일 편집 패턴

사용 시기: 여러 파일에 걸친 변경 작업을 수행할 때

템플릿:

다음 파일들을 일관되게 수정해주세요:

# 변경 범위
- [파일1 경로]: [변경 내용]
- [파일2 경로]: [변경 내용]
- [파일3 경로]: [변경 내용]

# 변경 이유
[전체적인 변경 목적과 맥락]

# 일관성 유지
- [네이밍 규칙]
- [타입 정의 공유 방법]
- [의존성 방향]

한 번에 모든 파일 수정 후, 변경 사항 요약 제공

예시:

사용자 인증 방식을 JWT에서 세션 기반으로 변경:

# 변경 범위
- src/auth/auth.service.ts: JWT 생성/검증 → 세션 생성/검증
- src/auth/auth.guard.ts: JWT 검증 미들웨어 → 세션 검증
- src/auth/auth.controller.ts: 로그인 응답에서 토큰 제거, 쿠키 설정
- src/main.ts: 세션 미들웨어 설정 추가

# 변경 이유
보안 강화 및 토큰 관리 복잡도 감소

# 일관성 유지
- 세션 타입: SessionData 인터페이스 정의
- 세션 저장소: Redis 사용
- 쿠키 설정: httpOnly, secure, sameSite 일관 적용

한 번에 모든 파일 수정 후, 변경 사항 요약 및 마이그레이션 가이드 제공

팁:

Agent 모드에서 "workspace" 컨텍스트 활용 명시
파일 간 의존성 순서 고려 (Domain → Application → Infrastructure)
변경 후 영향받는 테스트 파일도 함께 수정 요청

7. 프롬프트 품질 체크리스트

좋은 프롬프트는 다음 기준을 충족합니다:

✅ 명확성 (Clarity)

요청 내용이 구체적이고 모호하지 않음
입력과 출력 형식이 명확히 정의됨
제약 조건과 요구사항이 리스트로 나열됨

✅ 컨텍스트 (Context)

프로젝트 배경과 기술 스택 명시
관련 파일 경로나 기존 코드 참조 제공
아키텍처 패턴 또는 설계 원칙 언급

✅ 구조 (Structure)

컴퓨팅 사고 원리 중 하나 이상 명시
단계별 또는 계층적 요청 구조
우선순위와 중요도 표시

✅ 예시 (Examples)

가능하면 입력 예시 제공
기대하는 출력 형식 샘플
비슷한 기존 코드 참조

✅ 제약 (Constraints)

시간/공간 복잡도 제약
코딩 컨벤션 및 스타일 가이드
보안, 성능, 접근성 요구사항

✅ 검증 (Validation)

테스트 요청 포함
엣지 케이스 처리 명시
에러 처리 전략 정의

8. 자주 하는 실수와 해결책

❌ 실수 1: 너무 모호한 프롬프트

잘못된 예:

로그인 기능 만들어줘

개선된 예:

사용자 로그인 API를 다음과 같이 구현해주세요:

- POST /api/auth/login 엔드포인트
- 입력: { email: string, password: string }
- 출력: { accessToken: string, refreshToken: string, user: UserDTO }
- 비밀번호 bcrypt 검증
- JWT 토큰 생성 (access: 15분, refresh: 7일)
- 실패 시 HTTP 401, 명확한 에러 메시지
- TypeScript + NestJS
- 단위 테스트 포함

❌ 실수 2: 컨텍스트 부족

잘못된 예:

OrderService 리팩토링해줘

개선된 예:

src/services/OrderService.ts를 Clean Architecture 원칙에 따라 리팩토링해주세요:

현재 문제:
- 500줄 God Class, 비즈니스 로직과 인프라 코드 혼재
- 직접 DB 쿼리 실행, TypeORM 직접 의존

리팩토링 목표:
- Domain Layer: Order Aggregate, OrderItem Entity 분리
- Application Layer: CreateOrderUseCase, CancelOrderUseCase
- Infrastructure Layer: OrderRepository 구현
- 의존성 역전: 도메인이 인프라에 의존하지 않도록

기존 API 인터페이스 유지, 점진적 마이그레이션 가능하도록

❌ 실수 3: 한 번에 너무 많은 요청

잘못된 예:

전자상거래 전체 시스템 만들어줘 (사용자, 상품, 주문, 결제, 배송 포함)

개선된 예 (단계적 접근):

[1단계] 전자상거래 도메인 모델링:
- User, Product, Order Aggregate 정의
- 핵심 Value Object: Money, Address 등
- 도메인 이벤트: OrderPlaced, PaymentCompleted

[2단계] Order Aggregate 구현:
- Order 엔티티 및 OrderItem
- 주문 생성 비즈니스 규칙
- 도메인 이벤트 발행

[3단계] 주문 생성 유스케이스 구현...
(이후 단계별 진행)

❌ 실수 4: 제약 조건 누락

잘못된 예:

배열 정렬 함수 만들어줘

개선된 예:

배열 정렬 함수를 다음 요구사항에 맞춰 구현해주세요:

- 시간 복잡도: O(n log n) 이하
- 공간 복잡도: O(1) - in-place 정렬
- 제네릭으로 모든 타입 지원
- 커스텀 비교 함수 옵션
- 안정 정렬(Stable Sort)
- 빈 배열, null, undefined 처리
- TypeScript, 타입 안전성 보장
- Vitest 테스트 포함

9. 산업별 특화 패턴 예시

9.1 금융 시스템

결제 트랜잭션 처리 시스템을 다음 원칙으로 설계해주세요:

분해: Payment, Account, Transaction Aggregate
패턴: Saga 패턴 (분산 트랜잭션), Event Sourcing
추상화: IPaymentGateway 인터페이스 (다양한 결제 제공자)
알고리즘: 동시성 제어 (Optimistic Locking), 멱등성 보장

제약 조건:
- ACID 트랜잭션 보장
- 감사 추적 (모든 변경 로그)
- 금액 계산: Decimal 타입 사용 (부동소수점 X)
- PCI DSS 보안 표준 준수

9.2 헬스케어

환자 의료 기록 관리 시스템을 다음 원칙으로 설계해주세요:

분해: Patient, MedicalRecord, Prescription Aggregate
패턴: CQRS (읽기/쓰기 분리), RBAC (역할 기반 접근 제어)
추상화: HL7 FHIR 표준 인터페이스
알고리즘: 민감 정보 암호화 (AES-256), 감사 로그

제약 조건:
- HIPAA 규정 준수 (개인정보 보호)
- 데이터 불변성 (의료 기록 삭제 불가, 수정 이력 보존)
- 고가용성 (99.99% Uptime)
- 접근 권한 세밀한 제어

9.3 이커머스

실시간 재고 관리 시스템을 다음 원칙으로 설계해주세요:

분해: Product, Inventory, Reservation Aggregate
패턴: Pessimistic Locking (재고 동시성), Cache-Aside
추상화: IInventoryService (다양한 창고 시스템 통합)
알고리즘: 재고 할당 최적화 (창고별 우선순위, 배송 비용 최소화)

제약 조건:
- 동시 주문 처리 (초당 1만 건)
- 재고 일관성 보장 (초과 판매 방지)
- 실시간 재고 업데이트 (5초 이내)
- 분산 환경 (여러 창고, 여러 서버)

10. 패턴 조합 전략

복잡한 실무 문제는 여러 패턴을 조합하여 해결합니다.

조합 예시 1: 대규모 리팩토링

계층적 분해 패턴 → 시스템 구조 파악
코드 패턴 발견 패턴 → 중복 식별
인터페이스 추상화 패턴 → 결합도 낮추기
레거시 리팩토링 패턴 → 점진적 개선
멀티 파일 편집 패턴 → 일관된 적용

조합 예시 2: 신규 기능 개발

기능 분해 패턴 → 요구사항 분석 및 단계 정의
도메인 분해 패턴 (DDD) → 도메인 모델 설계
아키텍처 패턴 적용 → Clean Architecture 적용
효율성 최적화 패턴 → 핵심 알고리즘 최적화
컨텍스트 제공 패턴 → Copilot과 협업하여 구현

11. 지속적 개선을 위한 팁

프롬프트 라이브러리 구축: 효과적이었던 프롬프트를 저장하고 재사용
피드백 루프: Copilot 응답 품질을 평가하고 프롬프트 개선
팀 표준화: 팀 내에서 공통 프롬프트 패턴 정의 및 공유
도메인 지식 통합: 산업별 특화 패턴 추가
실험 정신: 다양한 프롬프트 변형 시도 및 비교

결론

이 프롬프트 패턴 카탈로그는 바이브 코딩의 핵심 도구입니다. 컴퓨팅 사고를 기반으로 한 체계적인 프롬프트 작성은 GitHub Copilot과의 협업 품질을 극적으로 향상시킵니다.

핵심 원칙 요약:

분해: 복잡한 문제를 관리 가능한 단위로 나누기
패턴 인식: 반복되는 구조를 식별하고 재사용
추상화: 세부사항을 숨기고 명확한 인터페이스 제공
알고리즘적 사고: 효율적이고 단계적인 솔루션 설계

이 패턴들을 내면화하면, 여러분은 AI와 함께 더 빠르고 정확하며 유지보수 가능한 소프트웨어를 만들 수 있습니다. 바이브 코딩의 여정에서 이 카탈로그가 항상 여러분의 곁에서 든든한 동반자가 되기를 바랍니다.

Happy Vibe Coding!

사고의 깊이