살아 있는 소프트웨어는 엠파시가 만듭니다

Appearance

상황별 실전 프롬프트 모음집 (치트시트) ​

활용 안내: 본 프롬프트 모음집은 기획, 설계, 구현, 테스트, 오류 해결, 배포에 이르는 개발 전 단계에서 부분만 프로젝트 상황에 맞게 바꾸어 복사·붙여넣기로 활용할 수 있도록 정리한 실무 템플릿입니다.

목차 및 빠른 이동 ​

1. 기획 및 요구사항 분석 (기획자 / PO) ​

프롬프트 1.1: 예외 상황 및 누락 조건 발굴 ​

markdown
[역할] IT 서비스 수석 기획자이자 비즈니스 분석가
[기능명] {{기능명, 예: 장바구니 쿠폰 적용 기능}}
[기본 설명] {{기능에 대한 기본 설명 2~3줄}}

[요청 사항]
이 기능 개발에 착수하기 전, 기획 단계에서 사전에 결정해야 할 기술적·비즈니스적 예외 상황 5가지를 질문 형식으로 제시해 주세요.
1. 결제/취소/환불 시 정책
2. 최소 주문 금액 및 최대 할인 금액 경계 조건
3. 유효기간 만료 및 다중 기기 중복 적용 시도
4. 다른 할인(포인트, 제휴카드)과의 중복 적용 규칙

프롬프트 1.2: 상황별 완료 기준(인수 조건) 생성 ​

markdown
[역할] 요구사항 분석 및 테스트 설계 전문가
[맥락]
- 대상 기능: {{기능명}}
- 확정된 정책: {{결정된 정책 내용}}

[요청 사항]
QA 테스트가 가능한 완료 기준(Acceptance Criteria)을 작성해 주세요.
- 시나리오 1: 정상 흐름 (Happy Path)
- 시나리오 2: 입력값 유효성 검증 실패 (Validation Error)
- 시나리오 3: 잔액/재고 부족 또는 비즈니스 한도 초과
- 시나리오 4: 네트워크 타임아웃 또는 동시 요청 충돌

2. 아키텍처 및 데이터베이스 설계 (아키텍트 / DBA) ​

프롬프트 2.1: PostgreSQL 17 표준 DDL 생성 ​

markdown
[역할] 수석 데이터베이스 아키텍트
[데이터베이스] PostgreSQL 17
[도메인] {{도메인명, 예: shop_coupon}}
[요구사항] {{기능 명세서 내용}}

[작성 규칙]
1. 테이블명은 소문자 스네이크 케이스({{도메인_엔티티}})로 작성해 주세요.
2. 기본키 id는 BIGINT 표준을 적용해 주세요.
3. 감사 컬럼(created_at, updated_at, created_by, updated_by, del_flag)을 포함해 주세요.
4. 자주 조회되는 컬럼에 대해 명시적 인덱스(INDEX)를 부여해 주세요.
5. 임시 충돌 회피 구문(ON CONFLICT DO NOTHING 등) 대신 고유성이 검증된 순수 CREATE TABLE 및 INSERT 구문으로 작성해 주세요.

[출력 형식]
- Mermaid 테이블 관계도
- 02_schema_domain.sql DDL 스크립트 (테이블, 인덱스, 설명)

프롬프트 2.2: 표준 REST API 규격 및 OpenAPI 정의 ​

markdown
[역할] RESTful API 설계 전문가
[대상 엔드포인트] {{리소스 경로, 예: /api/v1/shop/cart/coupon}}
[데이터 모델] {{관련 테이블 컬럼 정보}}

[작성 규칙]
1. 단일 매핑 원칙: 오직 하나의 고유 URL만 부여해 주세요.
2. 경로는 반드시 `/api/v1/{도메인}/{리소스}` 형식을 준수해 주세요.
3. 공통 응답 구조(CommonResult: code, message, result, timestamp)를 적용해 주세요.

[출력 형식]
1. API 엔드포인트 목록 표 (메서드, URL, 설명, 권한)
2. 성공 및 실패 상황별 JSON 응답 예시
3. OpenAPI 3.0 YAML 스펙 조각

3. 백엔드 Java Spring Boot 구현 (백엔드 개발자) ​

프롬프트 3.1: Lombok 적용 및 표준 서비스 구현 ​

markdown
[역할] 시니어 Spring Boot 개발자
[기술 스택] Java 21, Spring Boot 3.x, PostgreSQL 17
[구현 대상] {{구현할 기능, 예: 쿠폰 적용 비즈니스 로직}}
[선행 명세] {{확정된 DDL 및 API 명세}}

[작성 규칙]
1. Project Lombok 적용:
   - @Autowired 필드 주입 대신 private final 필드와 @RequiredArgsConstructor 생성자 주입을 사용해 주세요.
   - 로깅은 @Slf4j를 사용해 주세요.
   - DTO에 @Getter, @Builder, @NoArgsConstructor, @AllArgsConstructor를 적용해 주세요.
2. 컨트롤러 매핑은 단일 표준 URL(`/api/v1/...`)만 사용해 주세요.
3. 단순 조회는 @Transactional(readOnly = true), 데이터 변경 메서드는 @Transactional을 적용해 주세요.
4. 임시 더미 리턴(return null 등) 대신 실제 데이터 접근 계층을 연동하는 완성된 코드로 작성해 주세요.

4. 프론트엔드 Vue 3 및 모달 분리 (프론트엔드 개발자) ​

프롬프트 4.1: BasicModal 독립 팝업 컴포넌트 생성 ​

markdown
[역할] Vue 3 및 TypeScript 프론트엔드 개발자
[구현 대상] {{모달 기능 설명, 예: 보유 쿠폰 선택 및 적용 모달}}
[연동 API] {{백엔드 API URL 및 요청/응답 JSON}}

[작성 규칙]
1. 프레임워크 표준 모달인 BasicModal을 사용해 주세요.
2. 부모 화면에 인라인으로 작성하지 않고, components/CouponApplyModal.vue로 독립 분리해 주세요.
3. 모달 내부에 적절한 패딩(p-4)을 부여해 주세요.
4. 단순 빈 화면이 아닌 테이블, 라디오 선택, 할인 금액 미리보기 등 실질적인 화면 요소를 포함해 주세요.
5. interface Props 및 Emits(open, success, confirm)를 명확히 선언해 주세요.

5. 테스트 및 품질 검증 (QA 엔지니어) ​

프롬프트 5.1: JUnit 5 예외 케이스 단위 테스트 생성 ​

markdown
[역할] 시니어 QA 엔지니어
[테스트 대상 코드]
{{테스트할 Service 또는 Controller 소스코드}}
[완료 기준]
{{상황-행동-결과 시나리오}}

[작성 규칙]
1. 정상 작동 외에 최소 3개 이상의 비정상 예외 상황을 개별 @Test로 작성해 주세요:
   - 만료 시도, 잔액 부족 시도, 중복 동시 호출 시도
2. AssertJ(assertThat, assertThatThrownBy)를 사용하여 단언문을 작성해 주세요.
3. 단언문 없는 빈 테스트는 지양하고 각 테스트마다 2개 이상의 결과 검증을 수행해 주세요.
4. @DisplayName에 한글로 테스트 목적을 명확히 기재해 주세요.

6. 오류 해결 및 자동 수정 (디버깅 / 트러블슈팅) ​

프롬프트 6.1: 빌드 에러 및 테스트 오류 자동 수정 ​

markdown
[역할] 소프트웨어 디버깅 및 오류 수정 에이전트
[맥락] 빌드 중 컴파일 또는 테스트 오류가 발생했습니다.
[오류 로그]
{{에러 로그 스택 트레이스 내용}}

[오류 발생 소스코드]
{{해당 파일 소스코드 전문}}

[작성 규칙]
1. 원인 분석: 에러 원인을 2줄 이내로 요약해 주세요.
2. 부작용 점검: 수정 시 발생 가능한 영향도를 점검해 주세요.
3. 교체 코드: 해당 소스코드 전체를 바로 교체할 수 있는 형태로 작성해 주세요.
   - [주의] 에러 해결을 위해 비즈니스 유효성 검증문(if문)을 임의로 삭제하지 마세요.
   - [주의] 메서드 내부를 빈칸(// TODO)으로 남겨두지 마세요.

프롬프트 6.2: 쿼리 성능 병목 개선 (N+1 문제 등) ​

markdown
[역할] 데이터베이스 쿼리 튜닝 전문가
[맥락] 서비스 실행 중 특정 API에서 슬로우 쿼리 또는 N+1 문제가 발생했습니다.
[대상 코드 또는 쿼리 로그]
{{매퍼 XML 또는 JPA 엔티티/리포지토리 코드}}

[요청 사항]
1. 쿼리 병목이 발생하는 원인을 설명해 주세요.
2. 조인 쿼리나 배치 조회 등 가장 적합한 튜닝 방안을 제시해 주세요.
3. 튜닝 전/후의 예상 쿼리 실행 횟수와 성능 차이를 비교해 주세요.

7. 코드 검토 및 배포 요약 (리뷰어 / 운영자) ​

프롬프트 7.1: Git Diff 기반 PR 본문 정리 ​

markdown
[역할] 릴리즈 엔지니어링 테크니컬 라이터
[Git Diff 내용]
{{git diff 내용 붙여넣기}}

[작성 항목]
1. 작업 개요 (배경 및 목적)
2. 주요 변경 사항 (백엔드, 프론트엔드, DB 스키마)
3. 유의 사항 및 위험도 점검 (기존 기능 영향 여부)
4. 테스트 검증 결과 요약

프롬프트 7.2: 아키텍처 관점의 코드 검토 의견 작성 ​

markdown
[역할] 수석 시스템 아키텍트 겸 보안 점검자
[검토 대상 코드]
{{검토할 변경 소스코드}}

[점검 기준]
1. 동시성 결함 및 트랜잭션 경계 설정 여부
2. 보안 취약점(SQL 인젝션, 민감정보 노출, 권한 검증 누락)
3. 사내 표준 준수(Lombok 적용, 단일 표준 URL, 모달 컴포넌트 분리)
4. 가독성 및 단일 책임 원칙

[출력 형식]
라인별 구체적인 개선 제안(개선 전/후 코드 예시 포함) 및 종합 판정 의견.