스프린트 플래닝이나 백로그 정제 미팅에서 개발자가 “이 기능의 정확한 기대 동작이 뭔가요?”, QA 엔지니어가 “예외 처리는 어디까지 검수해야 하나요?”라고 물었을 때 즉답을 주지 못하면 커뮤니케이션 공수가 폭증합니다. 모호하게 작성된 기획서는 수많은 재확인 메시지와 버그 티켓을 양산합니다.
티몬, 여기어때, KT, 롯데닷컴, 패스트캠퍼스, 티켓베이 등 50여 개 대형 IT 프로젝트 현장에서 수백 명의 개발자·QA들과 합을 맞추며 검증한 ChatGPT 기반 유저 스토리(User Story) 및 인수 기준(AC, Acceptance Criteria) 10분 도출 프롬프트 체계를 정리합니다.
유저 스토리 & AC 작성 방식 비교
| 구분 | 수동 작성 (Traditional) | ChatGPT 프롬프트 활용 (AI-Assisted) |
| 작성 소요 시간 | 기능당 평균 30분 ~ 1시간 | 기능당 3분 ~ 5분 이내 (10분 만에 다수 도출) |
| 표현의 명확성 | PM 개인의 성향에 따라 주관적·모호함 | As a / I want / So that & Gherkin 포맷 표준화 |
| QA 인수 기준(AC) | 정상 케이스(Happy Path) 위주 작성 | 예외 상황(Edge Case) 및 에러 핸들링 자동 식별 |
| 지라(Jira) 연동성 | 티켓 본문 양식이 제각각으로 작성됨 | Jira 템플릿 양식에 맞춰 즉시 복사-붙여넣기 가능 |
1. 개발자·QA가 바로 알아듣는 유저 스토리 & AC 만능 메가 프롬프트
ChatGPT에게 단순히 “유저 스토리 써줘”라고 하면 실무에 적용하기 어려운 추상적인 답변만 나옵니다. 유저 스토리 표준 규격과 Gherkin 표기법(Given-When-Then)을 적용한 아래 메가 프롬프트를 사본으로 만들어 활용하세요
[역할 정의]
너는 10년 차 IT PM이자 프론트엔드/백엔드 개발자, QA 엔지니어와 명확하게 소통하는 애자일 기획 전문가야.
선언적이고 명확한 유저 스토리(User Story)와 Gherkin 포맷(Given-When-Then)의 인수 기준(Acceptance Criteria)을 도출하는 것이 너의 목적이야.
[기능 및 맥락]
1. 기능명: [예: 숙소 예약 결제 시 쿠폰 자동 적용 및 변경 기능]
2. 대상 유저: [예: 결제 단계 진입 후 보유 쿠폰 중 가장 할인율이 높은 쿠폰을 적용받고자 하는 구매자]
3. 서비스 환경: [예: 모바일 앱(iOS/Android) 환경, PG 연동 결제 레이어]
4. 핵심 로직: [예: 최소 주문 금액 충족 여부 확인, 타 쿠폰과 중복 적용 불가, 유효기간 만료 임박 쿠폰 우선 정렬]
[출력 요구사항]
다음 양식에 맞춰 유저 스토리와 인수 기준(AC)을 작성해줘:
### 1. 유저 스토리 (User Story)
- 형식: "As a [사용자 유형], I want to [수행하고자 하는 행동], So that [얻고자 하는 가치/이득]"
### 2. 인수 기준 (Acceptance Criteria - Gherkin Format)
- Normal Case (Happy Path) 2개 이상
- Edge Case / Exception Case (네트워크 에러, 자격 미달, 중복 사용 등) 3개 이상
- 각 AC는 아래 포맷을 엄격히 준수할 것:
* Scenario: [시나리오 제목]
* Given: [기초 사전 조건 및 상태]
* When: [유저가 수행하는 동작]
* Then: [시스템의 즉각적인 응답 및 상태 변화]
### 3. 백엔드 / 프론트엔드 체크포인트
- 개발자가 확인해야 할 API 및 데이터 상태 전달 항목 2~3가지 요약
2. 인수 기준(AC)의 핵심: Gherkin 표기법 (Given-When-Then)
QA팀과 개발팀이 가장 선호하는 문법 구조는 BDD(Behavior-Driven Development)의 표준인 Gherkin 표기법입니다. ChatGPT 프롬프트를 통해 이 표준을 자동화할 수 있습니다.
💡 Gherkin 표기법 구성 요소
- Scenario: 검증하려는 특정 유저 행동 시나리오 명시
- Given: 유저가 특정 동작을 하기 직전의 시스템 상태 (예: 로그인 완료 상태, 장바구니에 30,000원 이상 담긴 상태)
- When: 유저가 실제로 누르거나 입력하는 이벤트 (예: ‘최대 할인 쿠폰 적용’ 버튼 클릭)
- Then: 시스템이 보여줘야 할 결과값 및 데이터 변경 (예: 총 결제 금액이 할인된 금액으로 재계산되어 표시됨)
3. QA 검수 공수를 줄이는 예외 케이스(Edge Case) 확장 프롬프트
Happy Path(정상 유저 플로우)만 담긴 AC는 QA 단계에서 수많은 버그 티켓을 발생시킵니다. 초안 작성 후 아래 예외 상황 확장 프롬프트를 추가로 던져서 완성도를 높이세요.
[추가 프롬프트]
위에서 작성한 기능의 인수 기준(AC)에 대해 QA 엔지니어가 검수할 아래 4가지 예외 상황(Edge Case) 시나리오를 Gherkin 포맷으로 추가 도출해줘.
1. 네트워크 타임아웃 또는 서버 응답 지연 발생 시 (Timeout)
2. 동시성 이슈 (동일 쿠폰을 두 개 기기에서 동시에 결제 시도 시)
3. 세션 만료 또는 로그인 토큰이 만료된 상태에서 클릭 시
4. 쿠폰 적용 후 뒤로가기 버튼을 누르거나 앱을 강제 종료했을 때의 상태 유지 여부
4. 10년 차 PM의 지라(Jira) & 노션(Notion) 연동 팁
ChatGPT로 도출한 유저 스토리와 AC를 지라(Jira) 백로그 티켓으로 이관할 때는 지라의 Markdown 서식을 활용해 붙여넣으면 가독성이 극대화됩니다.
- Jira 에픽/스토리 연동: ChatGPT 출력 결과를 그대로 복사하여 Jira 이슈의
Description(설명)란에 전송합니다. - Acceptance Criteria 전용 필드 활용: Jira Custom Field에
Acceptance Criteria를 지정하고, Gherkin 코드를 블록 형태({code})로 감싸 넣으면 QA 담당자가 즉시 Test Case(TC)로 전환할 수 있습니다.
[7tipbox 요약]
개발자와 QA가 바로 알아듣는 유저 스토리 및 AC 작성의 핵심은 PM의 개인적 표현을 지우고 표준 프레임워크(User Story + Gherkin AC)를 적용하는 것입니다.
ChatGPT 메가 프롬프트를 활용해 10분 만에 정상 플로우와 예외 케이스(Edge Case)까지 도출하고, 이를 Jira 티켓에 표준화된 포맷으로 연결하는 것이 50개 이상의 대형 프로젝트를 성공으로 이끈 10년 차 IT PM의 핵심 커뮤니케이션 방정식입니다.