LangTailor페이지 목차
이 페이지에서 검색
AI 드리븐
이 페이지에 묻기
AI 드리븐 · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
AI · DEVELOPMENT
AI 드리븐
생성 수정
요구사항과 역할 정의부터 구현·검증·배포·운영까지, AI와 함께 개발하며 사람이 판단할 기준을 정리합니다.
26개 문서 · 1일차 · 4 / 26
3차시 · 기획 ① 요구사항을 완료 기준으로
지도 위치 : 1일차 · 기획 · "무엇이 맞는 상태인가"를 정하는 자리 | 이전: 2차시 AI 개발팀을 세우는 핵심 기능 | 다음: 4차시 범위 결정과 서비스 설계 키워드 : 요구 추출, 모호한 표현 → 측정 가능한 기준, 기획 역할 정의
이 차시를 다 읽으면
- 사용자 스토리를 유와 종차로 정의하고, 기능 목록과 무엇이 다른지 말할 수 있다.
- "빠르게", "쉽게", "안전하게" 같은 모호한 표현을 "그걸 어떻게 확인하지?" 질문으로 측정 가능한 기준으로 바꿀 수 있다.
- 인수 기준 을 정의하고, Given / When / Then 형식으로 정상 시나리오와 실패 시나리오를 함께 쓸 수 있다.
- 같은 기준을 AI가 테스트로 옮길 형태 와 내가 화면에서 직접 해 볼 형태 두 가지로 쓸 수 있다.
- "확인 필요" 항목 중 사람이 정해야 하는 사업 결정 을 골라낼 수 있다.
0. 이 차시의 판별 축
| # | 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축으로 갈리는 것 | 큰 축 (README 5장) |
|---|---|---|---|---|---|
| 1 | ⭐ 모호함 ↔ 측정 가능 | "빠르게", "쉽게", "잘" | "95%의 요청이 500ms 안에", "화면 전환 3번 이하" | AI가 완료를 판정할 수 있는가 | ⑧의 파생 |
| 2 | 추상 ↔ 구상 | 인수 기준 (무엇이 맞는 상태인가) | 코드 (그 상태를 만드는 방법) | 기획이 정하는 것 ↔ 구현이 정하는 것 | ② |
| 3 | 정상 경로 ↔ 실패 경로 | 일이 잘 풀릴 때 | 자리가 없을 때, 로그인 안 했을 때 | AI가 빠뜨리기 쉬운 쪽 | 이 차시의 축 |
| 4 | 사람이 정함 ↔ AI가 채움 | 사업 결정 (취소 정책, 환불 규정) | 기술 세부 (변수 이름, 파일 위치) | 위임해도 되는 결정인가 | 이 차시의 축 (README 9.2) |
이 차시가 답하는 질문은 "완료가 무엇인지를 어떻게 참/거짓으로 쓰는가" 입니다. 앞에서 배운 에이전트 루프(1차시 2절)는 "확인" 단계가 품질을 정합니다. 그런데 확인하려면 무엇이 맞는 상태인지 가 먼저 정해져 있어야 합니다. 그 재료를 만드는 차시입니다.
1. 왜 완료 기준인가
완료 기준이 없으면 이렇게 됩니다.
| 증상 | 원인 |
|---|---|
| AI가 아무 데서나 "완료했습니다"라고 멈춘다 | 루프의 확인 단계에 넣을 기준이 없다 (1차시 2.2) |
| 사람마다, 에이전트마다 "완료"의 뜻이 다르다 | 기준이 각자의 머릿속에만 있다 |
| 나중에 테스트를 쓸 근거가 없다 | 테스트는 "무엇이 맞는가"를 코드로 옮긴 것인데, 그 "무엇"이 없다 |
⭐ 완료 기준은 기획 문서이자 미래의 테스트 목록입니다. 그리고 코드를 읽지 않는 사람에게는 그 이상입니다. 개발자는 코드를 보고 맞는지 판단하지만, 코드를 읽지 않으면 "기준대로 동작하는가"로만 판단할 수 있습니다. 그러니 이 차시는 내가 가장 강한 영역이고, 가장 공을 들일 영역 입니다. 기준이 허술하면 이후 모든 검수가 허술해집니다.
2. 요구 추출 — 사용자 스토리
2.1 정의
요구사항 — [기획 산출물]인데, [ 서비스가 무엇을 해야 하는지를 사용자 쪽에서 적는다 ]는 점에서 어떻게 만들지를 적는 설계 문서와 구별된다.
사용자 스토리 — [요구사항 표현]인데, [ 누가 · 무엇을 · 왜를 한 문장에 담아 사용자의 목적에서 출발한다 ]는 점에서 기능 이름만 나열한 기능 목록과 구별된다.
[누가]로서, 나는 [무엇을] 하고 싶다. 왜냐하면 [목적] 때문이다.
🔍 읽는 포인트 : 마지막 칸 [목적] 이 핵심입니다. 목적이 있어야 나중에 "이 기능이 정말 필요한가"를 판단할 수 있습니다.
예: "수강생으로서, 나는 주말에 남은 자리가 있는 클래스만 보고 싶다. 헛걸음하고 싶지 않기 때문이다."
| 기능 목록 | 사용자 스토리 |
|---|---|
| "검색 기능" | 수강생으로서, 주말에 남은 자리가 있는 클래스만 보고 싶다. 헛걸음하기 싫어서 |
| → 무엇을 검색하는지, 왜인지 없음 | → "남은 자리 0인 클래스는 숨긴다"는 기준이 목적에서 저절로 나옴 |
2.2 AI에게 인터뷰를 시킨다
아이디어를 던지고 바로 만들게 하지 말고, 질문을 받습니다.
클래스온의 예약 기능을 만들려고 해. 구현하기 전에 나에게 질문을 해서 요구사항을 정리해줘.
한 번에 3개씩 물어보고, 내가 답하면 다음 3개를 물어봐.
취소, 정원, 결제 실패처럼 일이 잘 안 풀리는 경우를 꼭 포함해줘.
🔍 읽는 포인트 : "구현하기 전에"와 "한 번에 3개씩" 두 곳만 보면 됩니다. 앞의 것이 AI가 코드부터 짜는 것을 막고, 뒤의 것이 질문 폭탄을 막습니다.
AI는 내가 놓친 경우(취소 정책은? 정원이 차면? 결제가 실패하면?)를 물어봐 줍니다. 질문은 AI가, 답은 내가 합니다.
3. ⭐ 모호한 표현을 측정 가능한 기준으로
3.1 변환표
| 모호한 표현 | 측정 가능한 기준 |
|---|---|
| 빠르게 로딩된다 | 클래스 목록이 95%의 요청에서 500ms(0.5초) 안에 응답한다 |
| 쉽게 예약한다 | 상세 화면에서 결제 완료까지 화면 전환 3번 이하 |
| 안전하게 결제한다 | 결제 금액은 서버가 DB 가격으로 계산 하고, 화면이 보낸 금액은 무시한다 |
| 정원 관리가 잘 된다 | 남은 자리가 0이면 예약 요청은 거절되고 예약이 생성되지 않는다 |
| 에러를 잘 보여준다 | 모든 에러 응답은 { "error": { "code", "message" } } 한 가지 모양 이다 |
변환 요령은 하나입니다. 모호한 형용사를 만나면 "그걸 어떻게 확인하지?" 라고 물어보세요. 확인 방법이 곧 기준입니다.
💡 "95%의 요청에서"라고 쓰는 이유: 요청 100개 중 대부분은 빠르고 몇 개만 아주 느린 경우가 흔합니다. 평균은 이 느린 몇 개를 가립니다. "100개 중 95개가 0.5초 안에"처럼 쓰면 느린 꼬리 까지 기준에 들어옵니다.
3.2 반례 — 측정 가능해 보이지만 아닌 것
| 표현 | 왜 측정 가능하지 않은가 | 고치면 |
|---|---|---|
| "사용자가 만족한다" | 누가, 언제, 무엇으로 재는지 없다 | "예약 완료 후 별점 4 이상이 80%" (재는 방법을 정해야 기준) |
| "버그가 없다" | 없음을 증명할 방법이 없다 | 인수 기준 시나리오가 전부 통과 한다 |
| "최대한 빠르게" | 숫자가 있어도 상한이 없다 | "500ms 안에" |
| "모바일에서도 잘 보인다" | "잘"이 남아 있다 | "폭 375px 화면에서 가로 스크롤이 생기지 않는다" |
⚠️ 숫자 기준(500ms 등)을 처음부터 정확히 정할 필요는 없습니다. 대략 정하고, 나중에 재서 조정 하면 됩니다. 숫자가 없는 것보다 대략의 숫자가 훨씬 낫습니다.
앞으로 다시 만납니다 — 이 축(모호함 ↔ 측정 가능)은 6차시에서 "따뜻한 느낌"을 디자인 토큰 으로, 17차시에서 인수 기준을 자동 테스트 로 바꿀 때 다시 씁니다.
4. ⭐ 인수 기준과 Given / When / Then
4.1 정의
인수 기준 (Acceptance Criteria) — [요구사항 문서]인데, [ 참/거짓으로 판정할 수 있는 문장으로 완료를 정의한다 ]는 점에서 무엇이 있어야 하는지만 적은 기능 목록과 구별된다.
Given / When / Then — [인수 기준을 쓰는 형식]인데, [ 전제(Given) · 행동(When) · 기대 결과(Then)를 나눠 써서 그대로 시험 절차가 된다 ]는 점에서 자유롭게 서술한 문장과 구별된다.
| 부분 | 묻는 것 | 시험 절차로 읽으면 |
|---|---|---|
| Given | 어떤 상황에서? | 시험 전에 이 상태를 준비 한다 |
| When | 무엇을 하면? | 이 행동 을 한다 |
| Then | 무엇이 되어야 하나? | 이 결과가 나오는지 확인 한다 (참/거짓) |
4.2 예시
기능: 클래스 예약
시나리오: 남은 자리가 있을 때 예약
Given 정원 6명, 예약 5명인 클래스가 있고
When 로그인한 수강생이 1명 예약을 요청하면
Then 예약이 "결제 대기" 상태로 생성되고
And 남은 자리는 0이 된다
시나리오: 자리가 없을 때 예약
Given 남은 자리가 0인 클래스가 있고
When 예약을 요청하면
Then 409 응답과 "SOLD_OUT" 에러 코드를 받고
And 예약은 생성되지 않는다
🔍 읽는 포인트 : 각 시나리오의 Then 줄만 보면 됩니다. 그 줄이 참인지 거짓인지 확인할 수 있으면 좋은 인수 기준입니다.
409는 서버가 "지금 상태와 충돌해서 처리할 수 없다"고 답할 때 쓰는 숫자입니다. 이런 숫자를 상태 코드 라고 하며, 4차시에서 정의합니다.
4.3 실패 시나리오를 반드시 쓴다
⭐ 정상 경우만 쓰지 말고 실패 경우도 반드시 씁니다. AI는 정상 경로는 잘 만들고 실패 경로는 잘 빠뜨립니다(0절 축 3).
| 기능 | 빠뜨리기 쉬운 실패 시나리오 |
|---|---|
| 예약 | 자리가 없을 때, 로그인 안 했을 때, 이미 지난 날짜일 때 |
| 결제 | 결제가 실패했을 때, 같은 결제를 두 번 눌렀을 때 |
| 취소 | 취소 기한이 지났을 때, 남의 예약을 취소하려 할 때 |
4.4 ⭐ 두 형태로 쓰기 — AI용과 나용
같은 기준을 두 형태로 써 두면 가장 좋습니다.
| AI가 테스트로 옮길 기준 | 내가 화면에서 직접 해 볼 기준 |
|---|---|
| 예약 생성 시 남은 자리 값이 1 감소한다 | 예약 후 상세 화면의 "남은 자리"가 1 줄어든다 |
| 409 응답과 SOLD_OUT 코드를 반환한다 | 자리가 없으면 "마감되었어요"가 보이고 결제 화면으로 넘어가지 않는다 |
왼쪽은 AI가 자동 테스트로 옮기고(17차시), 오른쪽은 내가 행동 시험 에 씁니다(README 9.1의 신뢰 근거 ②). 오른쪽은 코드를 몰라도 참/거짓을 직접 판정할 수 있습니다.
앞으로 다시 만납니다 — 13차시 동작 검증과 17차시 자동 테스트에서 이 Given / When / Then이 그대로 테스트 이름 이 됩니다. 22차시에서 배포된 서비스를 끝까지 눌러 볼 때는 오른쪽 열이 점검표가 됩니다.
4.5 반례 — 이건 인수 기준이 아닙니다
| 대상 | 왜 아닌가 |
|---|---|
| "로그인, 검색, 예약, 결제" | 기능 목록. 언제 완료인지 판정할 문장이 없다 |
| "예약이 잘 동작한다" | 참/거짓을 가를 수 없다 |
"예약은 서버의 createReservation 함수가 처리한다" | 구현 방법(축 2의 구상). 인수 기준은 무엇이 맞는 상태인가 만 쓴다 |
💡 비유는 마지막에 — 인수 기준은 집을 지을 때의 준공 검사표 입니다. "튼튼한 집"이 아니라 "문을 닫으면 틈이 1mm 이하"처럼 검사관이 재서 판정할 수 있는 문장입니다.
5. 기획 역할과 클래스온
5.1 기획 역할 정의
기획을 하위 에이전트(2차시 3.1)로 분리하면 역할이 명확해집니다.
# .claude/agents/planner.md
---
name: planner
description: 아이디어를 요구사항과 인수 기준으로 정리한다. 새 기능 착수 전에 사용.
tools: Read, Write, Glob
---
너는 기획자다.
- 하는 일: 사용자 스토리 작성, 모호한 표현을 측정 가능한 기준으로 변환, Given/When/Then 인수 기준 작성
- 하지 않는 일: 코드 작성, 기술 스택 결정
- 불명확한 점은 추측하지 말고 "확인 필요" 목록으로 남긴다
- 산출물: docs/requirements.md
🔍 읽는 포인트 : "하지 않는 일"과 "추측하지 말고" 두 줄입니다. 이 두 줄이 없으면 기획 에이전트가 신나서 코드까지 짜고, 모르는 것을 그럴듯하게 채웁니다.
앞으로 다시 만납니다 — 5차시에서 이 정의를 책임 · 맥락 · 권한 · 완료 조건 네 축으로 일반화합니다.
5.2 "확인 필요"는 내가 채운다
| 확인 필요 항목 | 누가 정하나 | 이유 |
|---|---|---|
| 취소 수수료가 있는가? | 나 | 돈과 고객 관계가 걸린 사업 결정 |
| 한 번에 여러 명 예약이 가능한가? | 나 | 서비스 성격을 바꾸는 결정 |
| 예약 번호를 어떤 형식으로 만드나? | AI에게 맡겨도 됨 | 기술 세부 |
⚠️ AI가 "확인 필요"를 임의로 채우게 두지 마세요. 취소 정책, 환불 규정, 최대 인원 같은 사업 결정은 코드 실력과 상관없이 내가 정해야 합니다(README 9.2의 "내가 직접").
5.3 클래스온에 적용하면
docs/requirements.md의 뼈대:
## 사용자
- 수강생 / 공방 운영자
## 사용자 스토리
- US-1 수강생은 날짜 · 지역으로 클래스를 찾는다
- US-2 수강생은 남은 자리가 있는 클래스를 예약하고 결제한다
- US-3 수강생은 수업 2일 전까지 예약을 취소하고 환불받는다
- US-4 운영자는 클래스와 정원을 등록한다
## 인수 기준
(각 스토리마다 Given/When/Then, 실패 시나리오 포함, AI용 · 나용 두 형태)
## 확인 필요
- 취소 수수료가 있는가?
- 한 번에 여러 명 예약이 가능한가?
🔍 읽는 포인트 : 맨 아래 ## 확인 필요 절입니다. 이 절이 비어 있지 않고, 항목마다 내 답이 적혀 갈 자리라는 것만 보면 됩니다.
6. 실습 — 맡기고 검수하기
지시
planner 역할로 클래스온의 US-2(예약하고 결제한다)의 인수 기준을 써줘.
- 형식: Given/When/Then
- 정상 시나리오 1개 + 실패 시나리오 최소 3개(자리 없음, 로그인 안 함, 지난 날짜)
- 각 시나리오마다 두 형태로: [AI용 기준(서버 응답 기준) | 나용 기준(화면에서 보이는 것)]
- 모호한 표현이 남아 있으면 표시하고, 측정 가능한 기준을 제안해줘
- 사업 결정이 필요한 부분은 채우지 말고 "확인 필요" 목록으로 따로 빼줘
- 결과는 docs/requirements.md에 쓰고, 쓴 내용 원문을 보고에 붙여줘
받을 증거
docs/requirements.md의 해당 부분 원문- "확인 필요" 목록
내가 직접 확인할 것
| 볼 것 | 이걸로 아는 것 / 왜 내가 보는가 |
|---|---|
모든 Then 줄을 소리 내어 읽고 "참/거짓으로 갈리는가?" 물어보기 | 측정 가능한 기준인지. "잘", "적절히", "빠르게"가 남아 있으면 되돌려 보냄 |
| 나용 기준을 내가 화면에서 직접 해 볼 수 있는가 상상해 보기 | 2일차 이후 행동 시험에 그대로 쓸 수 있는지 |
| 실패 시나리오가 정상보다 많은가 | AI가 실패 경로를 빠뜨리지 않았는지 |
| "확인 필요" 목록에 있는 항목에 내가 직접 답하기 | 사업 결정을 AI가 추측으로 채우지 않았는지. 답한 내용을 requirements.md에 반영시킴 |
| 인수 기준 안에 기술 이름 (DB, 함수 이름, 라이브러리 이름)이 섞였는지 | 인수 기준이 구현으로 미끄러졌는지 (4.5) |
부록 A. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | 완료 기준이 없으면 생기는 세 가지 증상은? | 1 |
| 2 | 사용자 스토리와 기능 목록의 종차는? | 2.1 |
| 3 | AI에게 인터뷰를 시킬 때 넣을 두 가지 제한은? | 2.2 |
| 4 | "검색이 편리해야 한다"를 측정 가능한 기준 두 개로 바꾸면? | 3.1 |
| 5 | "버그가 없다"가 측정 가능한 기준이 아닌 이유는? | 3.2 |
| 6 | 인수 기준을 유와 종차로 정의하면? | 4.1 |
| 7 | Given / When / Then을 시험 절차로 읽으면? | 4.1 |
| 8 | 실패 시나리오를 반드시 넣어야 하는 이유는? | 4.3 |
| 9 | 같은 기준을 AI용 · 나용 두 형태로 쓰는 이유는? | 4.4 |
| 10 | 기획 에이전트 정의에 "하지 않는 일"을 적는 이유는? | 5.1 |
부록 B. 자주 하는 실수
| 실수 | 바로잡기 |
|---|---|
| 기능 목록("로그인, 검색, 결제")만 쓰고 끝낸다 | ❌ 완료 기준이 없습니다. Given/When/Then으로 (4.5) |
| 정상 시나리오만 쓴다 | ❌ AI는 실패 경로를 빠뜨립니다 (4.3) |
| "확인 필요" 사항을 AI가 임의로 채우게 둔다 | ❌ 사업 결정은 사람이 (5.2) |
| 숫자 기준을 정확히 몰라서 아예 안 쓴다 | ⭕ 대략 정하고 나중에 재서 조정 (3.2) |
| 인수 기준에 구현 방법을 쓴다 | ⚠️ 무엇이 맞는 상태인지만 씁니다 (4.5) |
| 서버 응답 기준만 쓴다 | ⭕ 내가 화면에서 해 볼 수 있는 형태도 함께 (4.4) |
부록 C. NotebookLM 복습 프롬프트
이 3차시 노트만 근거로 6문제를 내줘. 코드를 모르는 사람 기준으로.
"모호한 표현을 측정 가능한 기준으로 바꾸기", "Given/When/Then", "실패 시나리오", "AI용 기준과 나용 기준"은 반드시 포함해줘.
모호한 문장 하나를 주고 내가 직접 바꿔 보게 하는 문제도 1개 넣어줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.