brain

문제 정의와 PRD: problem statement · goal · non-goal · scope

상황

• AI에게 “가계부 앱 만들어줘“라고 했더니, 원하지 않던 기능까지 잔뜩 들어간 거대한 앱이 나왔다. 정작 원한 핵심은 빠져 있었다.
• 만들고 보니 “근데 이거 왜 만들었더라?” 싶다. 기능은 있는데 해결하는 문제가 흐릿하다.
• 작업 도중 “이것도 넣자, 저것도 넣자”가 계속 붙어서 끝나지 않는다.

용어

• problem statement(문제 정의) — 누가, 어떤 상황에서, 무엇 때문에 곤란한가를 한두 문장으로. 해결책(기능)이 아니라 문제를 먼저 쓴다. 마케팅 브랜딩 용어 2번 pain point·JTBD(Jobs To Be Done)와 같은 출발점.
  • ❌ “카테고리별 그래프 기능이 필요하다” (해결책부터 씀)
  • ⭕ “가계부를 쓰는 직장인이 월말에 어디서 돈이 샜는지 파악하는 데 30분 넘게 걸려서, 결국 확인을 포기한다.”
  • 문제가 선명하면 해결책은 여러 개가 나오고, 그중 고를 수 있다(상황 2 해결).
• PRD(Product Requirements Document, 제품 요구사항 문서) — 만들 기능의 왜·누구·무엇·어디까지·성공 기준을 정리한 문서. 진단 Q3에서 이름은 맞힘. 흔한 목차:
  1. 배경·문제 정의 — 왜 지금 이걸 하나
  2. 대상 사용자 — 누구를 위한 건가(브랜딩 용어 2번 페르소나)
  3. goal(목표) — 이걸로 무엇을 이루나. 가능하면 성공 지표와 함께(그로스 용어 3번 리텐션, 8번 NSM(North Star Metric) 등). “월말 지출 확인 시간을 30분 → 1분으로”, “D7 리텐션 +5%p”.
  4. non-goal(비목표) — 이번에 하지 않을 것을 명시. “예산 설정 기능은 이번 범위가 아니다”, “웹 버전은 만들지 않는다”.
  5. scope(범위) — 포함(in-scope)과 제외(out-of-scope) 목록.
  6. 요구사항 — 사용자 시나리오·기능 목록(다음 레슨들의 유저 스토리, acceptance criteria).
  7. open question(미결 사항) — 아직 결정 안 된 것. 숨기지 않고 적어둬야 나중에 안 꼬인다.
• non-goal이 중요한 이유 — 사람도 AI도 “하지 말라고 안 했으니” 하는 경향이 있다. 하지 않을 것을 적어두면 범위가 고정된다(상황 1·3 해결). 웹 용어에서 “z-index 숫자 올리는 걸로 때우지 마”처럼 하지 말 것을 지시에 넣었던 것과 같은 원리.
• scope creep(범위 팽창) — 진행 중에 요구사항이 조금씩 계속 추가되어 끝이 안 나는 현상(상황 3). 새 아이디어는 바로 넣지 말고 다음 버전 목록으로 보낸다.
  • 비유: 여행 계획. “제주도 2박 3일, 휴식 목적(goal), 우도는 이번에 안 감(non-goal)”이라고 정해두지 않으면 일정이 계속 늘어 결국 아무 데서도 못 쉰다.
• AI 지시에서의 PRD — 큰 기능을 AI에게 맡길 때 “만들어줘” 한 줄 대신 짧은 PRD를 먼저 같이 쓰고, 그걸 기준으로 구현을 시키면 결과가 훨씬 정확해진다. 미결 사항은 AI가 추측하지 말고 묻게 한다.

지시 예문

• “가계부 ‘월말 리포트’ 기능의 PRD를 같이 쓰자. 문제 정의, 대상 사용자, goal(성공 지표 포함), non-goal, in/out scope, open question 순서로 초안을 써줘. 모르는 건 추측하지 말고 open question에 적어.”
• “이 기능 요청을 해결책 말고 문제 중심으로 problem statement 한 문장으로 다시 써줘.”
• “작업 중에 추가된 요청들이 scope creep인지 판단해서, 이번 범위와 다음 버전으로 보낼 것을 나눠줘.”
• “이 PRD의 non-goal에 적힌 건 절대 구현하지 마. 필요해 보이면 구현 대신 제안으로만 남겨줘.”

---

MVP 심화: viable의 의미 · MoSCoW · 가짜 MVP 기법

상황

• MVP라며 기능을 줄였는데, 남은 기능도 절반씩만 만들어서 아무것도 제대로 안 된다. 사용자가 써 보고 실망만 했다.
• “최소한”이라고 정했는데 회의할 때마다 꼭 필요한 기능이 하나씩 늘어 결국 MVP가 3개월짜리가 됐다.
• 이 기능을 사람들이 정말 원할지 확인하고 싶은데, 만드는 데만 한 달이 걸린다.

용어

• MVP(Minimum Viable Product, 최소 기능 제품) — 진단 Q1에서 맞힌 개념. 핵심은 “Minimum(최소)”보다 “Viable(쓸 만한)”이다. 범위는 작아도 그 범위 안에선 실제로 문제를 해결해야 한다(1번 레슨 problem statement).
  • 흔히 인용되는 그림: 이동 수단을 만든다면 바퀴 하나 → 바퀴 두 개 → 차체 → 자동차 순서(각 단계엔 탈 수 없음)가 아니라 킥보드 → 자전거 → 오토바이 → 자동차(매 단계 타고 이동할 수 있음) 순서로 만들라는 비유. 상황 1은 “바퀴 하나”를 낸 것.
  • 목적은 배우기다. “사람들이 정말 이걸 쓰는가?”(그로스 용어 8번 PMF(Product-Market Fit) 신호)를 빨리 확인하는 실험 도구.
• prototype(프로토타입) — 생각을 확인하려고 만든 시제품. 실제로 작동하지 않아도 된다(UI 용어 14번: 눌러볼 수 있는 시안). MVP는 실제 사용자가 실제로 쓰는 제품이라는 점이 다르다.
• MLP(Minimum Lovable Product, 최소 사랑받는 제품) — “쓸 만한” 수준을 넘어 좋아할 만한 경험까지 담은 첫 버전. 경쟁이 치열한 시장에선 “작동만 하는” MVP로는 아무도 다시 안 오기 때문에 나온 말. 기능 수는 적게, 그 기능의 완성도는 높게.
• MoSCoW(모스크바) 우선순위 — 요구사항을 네 바구니로 나눠 범위를 자르는 틀(상황 2 해결). 가운데 o는 읽기 쉽게 넣은 글자.
  • M — Must have(반드시): 없으면 출시 의미가 없는 것
  • S — Should have(가능하면): 중요하지만 없어도 출시는 가능
  • C — Could have(있으면 좋음): 여유 있을 때
  • W — Won’t have (this time)(이번엔 안 함): 1번 레슨 non-goal과 같은 역할
  • MVP는 Must만으로 구성하는 게 원칙. “Must가 너무 많다”면 1번 레슨 문제 정의로 돌아가 문제를 더 좁힌다.
  • 그로스 용어 10번 ICE·RICE가 “무엇을 먼저“라면, MoSCoW는 “이번 버전에 넣나 빼나“를 정하는 도구.
• 만들기 전에 검증하는 MVP 기법들(상황 3 해결)
  • fake door test(가짜 문 테스트) — 아직 없는 기능의 버튼만 만들어 두고, 누르면 “곧 출시 예정, 알림 받기”를 보여준다. 누른 비율로 수요를 잰다. 만들기 전 하루 만에 가능.
  • landing page MVP — 제품 없이 소개 페이지와 사전 신청만으로 반응을 본다(마케팅 디지털 9번 랜딩 페이지).
  • concierge MVP(컨시어지 MVP) — 자동화 대신 사람이 직접 손으로 서비스해 준다. “AI 지출 분석” 대신 처음 10명에게 직접 엑셀로 분석해 보내기.
  • Wizard of Oz MVP(오즈의 마법사 MVP) — 사용자 눈엔 자동처럼 보이지만 뒤에서 사람이 처리. 동화에서 커튼 뒤 평범한 사람이 마법사 행세를 한 데서 온 이름.
  • 비유: 식당 창업 전 푸드트럭·팝업 스토어로 먼저 팔아 보기.

지시 예문

• “이 PRD의 요구사항을 MoSCoW로 분류해줘. MVP는 Must만으로 구성하고, Must가 5개를 넘으면 문제를 더 좁히는 방법을 제안해줘.”
• “MVP 범위의 기능은 절반씩 만들지 말고, 적은 기능을 끝까지 쓸 수 있게 완성해줘. 각 기능의 ‘이것까지 되면 쓸 만하다’ 기준을 먼저 적어줘.”
• "’예산 알림’ 기능 수요를 확인하려고 fake door test를 넣고 싶어. 버튼, ‘곧 출시’ 모달, 알림 신청, 클릭 이벤트 트래킹까지 만들어줘.”

---

유저 스토리와 acceptance criteria: user story · Given-When-Then · DoD

상황

• 기능 요청을 “카테고리 그래프 추가“라고만 적었더니, 누구를 위한 건지·왜 필요한지 몰라 엉뚱한 그래프가 나왔다.
• 개발자가 “로그인 다 만들었어요”라고 했는데, 비밀번호 오류 안내도, 5회 실패 잠금도 없었다. “완료”의 기준이 서로 달랐다(진단 Q4).
• AI가 “구현 완료”라고 했는데 테스트도 없고, 모바일 확인도 안 했다. 매번 같은 걸 다시 시켜야 한다.

용어

• user story(유저 스토리) — 기능을 사용자 관점의 한 문장으로 쓰는 형식. 진단 Q2의 답.
  • 형식: “[누구]로서, [무엇]을 하고 싶다. [왜냐하면/그래서] [목적].” (영어 원형: As a [user], I want [action], so that [benefit].)
  • 예: “바쁜 직장인 회원으로서, 월말에 카테고리별 지출 그래프를 보고 싶다. 그래야 어디서 돈이 샜는지 1분 안에 알 수 있다.”
  • 셋 다 중요하지만 특히 “그래야(목적)”가 핵심 — 목적을 알면 구현 방법을 더 나은 쪽으로 바꿀 수 있다(1번 레슨 problem statement를 기능 단위로 쪼갠 것). 상황 1은 “누구”와 “왜”가 빠진 것.
  • 비유: 식당 주문서. “김치찌개 1”보다 “매운 걸 못 먹는 아이가 먹을 거라 덜 맵게“라고 적혀 있으면 주방이 알아서 맞춘다.
  • 좋은 스토리 점검(INVEST) — Independent(독립적), Negotiable(협의 가능), Valuable(가치 있음), Estimable(규모 추정 가능), Small(작음), Testable(검증 가능). 특히 작고(Small) 검증 가능(Testable)해야 한다.
• acceptance criteria(AC, 인수 조건·완료 조건) — 그 스토리가 “됐다”고 인정할 구체적인 조건 목록. 진단 Q4의 답. 스토리마다 따로 적는다(상황 2 해결).
  • 로그인 스토리의 AC 예:
    • 올바른 이메일·비밀번호면 홈으로 이동한다
    • 비밀번호가 틀리면 “이메일 또는 비밀번호가 맞지 않아요” 안내가 입력칸 아래 뜬다(UI 용어 17번 에러 메시지)
    • 5회 연속 실패하면 15분간 로그인이 잠긴다(인프라 용어 14번 brute force 방어)
    • 로그인 상태는 새로고침 후에도 유지된다(웹 용어 23번)
• Given-When-Then(주어진 상황-행동-결과) — AC를 시나리오 형식으로 쓰는 틀. 그대로 테스트 코드로 옮기기 쉽다.
  • Given(이런 상황에서) 비밀번호를 4번 틀린 사용자가
  • When(이걸 하면) 한 번 더 틀린 비밀번호로 로그인하면
  • Then(이렇게 된다) 15분 잠금 안내가 뜨고 로그인 버튼이 비활성화된다
• DoD(Definition of Done, 완료의 정의) — 스토리마다 다른 AC와 달리, 모든 작업에 공통으로 적용하는 완료 체크리스트. “AC 모두 통과, 테스트 작성, 모바일·다크 모드 확인, 콘솔 에러 없음, 리뷰 완료, 스테이징 배포”. 상황 3처럼 AI에게 매번 같은 걸 반복해 시킨다면 DoD를 한 번 정해 두고 항상 적용하게 한다(예: 프로젝트 지침 파일에 기록).
  • 차이: AC = 이 기능이 해야 할 일, DoD = 어떤 기능이든 끝났다고 말하기 전에 해야 할 일.

지시 예문

• “이 기능 요청들을 ‘[누구]로서 [무엇]을 하고 싶다. 그래야 [목적]’ 형식의 user story로 바꿔줘. 목적이 불분명한 건 질문으로 남겨줘.”
• “로그인 스토리의 acceptance criteria를 Given-When-Then 형식으로 써줘. 성공·실패·잠금·세션 유지 시나리오를 빠짐없이.”
• “이 AC를 그대로 테스트 코드로 만들어서, 구현 전에 먼저 실패하는 걸 확인하고 구현해줘.”
• “우리 프로젝트 DoD를 정해서 CLAUDE.md에 적어줘: AC 통과, 테스트, 모바일·다크 모드 확인, 콘솔 에러 없음. 앞으로 ‘완료’라고 하기 전에 항상 이걸 확인해.”

---

예외 상황 설계: happy path · edge case · 경계값 · 상태 매트릭스

상황

• AI가 만든 지출 입력 화면이 정상적으로 쓸 땐 완벽한데, 금액에 0이나 음수를 넣거나 메모를 3,000자 넣으면 화면이 깨진다.
• 처음 가입한 사용자가 들어오니 데이터가 하나도 없어서 그래프 자리에 에러가 뜬다.
• 지하철에서 저장 버튼을 눌렀는데 인터넷이 끊겨 입력한 내용이 그냥 사라졌다.

용어

• happy path(해피 패스, 정상 경로) — 사용자가 모든 걸 예상대로 하고 아무 문제도 없는 흐름. 올바른 값 입력 → 저장 성공 → 목록 표시. 기획서·AI 결과물이 보통 이것만 다룬다.
• unhappy path / exception flow(예외 흐름) — 무언가 잘못되거나 예상과 다른 흐름. 잘못된 입력, 실패, 취소, 권한 없음. 실제 사용자의 하루는 생각보다 예외가 많다.
  • 비유: 여행 계획. 해피 패스는 “비행기 타고 호텔 체크인”. 예외 흐름은 “비행기 지연되면? 호텔 예약이 누락되면? 여권을 잃어버리면?” 이걸 생각해 둔 여행이 망하지 않는다.
• edge case(엣지 케이스) — 정상 범위의 가장자리·극단에서 일어나는 드문 경우(상황 1). corner case(코너 케이스)는 엣지 케이스 여러 개가 동시에 겹친 더 드문 경우.
• boundary value(경계값) — 허용 범위의 양 끝과 그 바로 바깥. 금액이 1~10,000,000원이라면 0, 1, 10,000,000, 10,000,001을 꼭 시험한다. 버그는 경계에 몰려 있다.
• 흔한 엣지 케이스 체크리스트 — AI에게 기능을 맡길 때 이 목록을 함께 주면 결과가 단단해진다. 거의 다 앞에서 배운 레슨과 연결된다.
  • 값: 비어 있음, 아주 김(웹 용어 10번 텍스트 넘침), 0·음수·최대값(DB 용어 6번 CHECK), 이모지·특수문자·다국어(웹 용어 40번), 공백만 입력
  • 데이터 양: 0개(첫 사용자·빈 상태, 웹 용어 22번 empty state, 상황 2), 1개, 아주 많음(웹 용어 7번 virtualization, 29번 pagination)
  • 네트워크·시간: 느림·끊김(상황 3), 응답 순서 뒤바뀜(웹 용어 5번 race condition), 시간대·날짜 경계(웹 용어 26번)
  • 사용자 행동: 버튼 연타(웹 용어 27번 중복 제출), 뒤로가기·새로고침(웹 용어 18번), 중간에 앱 닫기, 두 기기 동시 수정(DB 용어 8번 동시성)
  • 권한·상태: 로그인 안 함, 권한 없음(웹 용어 23번 401·403), 탈퇴한 사용자 데이터(DB 용어 1번·10번), 결제 실패·환불
• state matrix(상태 매트릭스) — 화면이 가질 수 있는 상태를 표로 전부 나열하는 것. 웹 용어 22번의 loading·empty·error·success를 기본으로, 화면별 고유 상태(편집 중, 저장 중, 오프라인, 권한 없음)를 추가한다. 디자인·구현·테스트가 같은 표를 본다.
• graceful degradation(우아한 실패) — 무언가 실패해도 전체가 무너지지 않고, 가능한 만큼은 동작하며 사용자에게 상황을 알려주는 것. 오프라인이면 입력을 기기에 임시 저장했다가 연결되면 보내기(상황 3 해결), 그래프 API가 실패해도 목록은 보여주기(웹 용어 22번 error boundary).

지시 예문

• “지출 입력 기능의 happy path와 unhappy path를 시나리오로 나눠 써줘. 각 예외마다 사용자에게 보여줄 메시지와 동작까지.”
• “이 기능에 대해 값·데이터 양·네트워크·사용자 행동·권한 관점의 엣지 케이스 목록을 만들고, 각각 테스트를 써줘. 금액은 경계값 0, 1, 최대값, 최대값+1 포함.”
• “대시보드 화면의 state matrix를 표로 만들어줘. loading, empty(첫 사용자), error, success, 오프라인, 권한 없음 상태별 화면 구성까지.”
• “저장 중 네트워크가 끊기면 입력이 사라져. 기기에 임시 저장했다가 재연결 시 자동 전송하는 graceful degradation을 넣어줘.”

---

흐름과 구조: user flow · user journey · IA · sitemap · 화면 설계서

상황

• AI에게 화면을 하나씩 따로 만들라고 했더니, 각 화면은 멀쩡한데 화면끼리 어떻게 이어지는지가 엉망이다. 결제 후 어디로 가는지, 취소하면 어디로 돌아가는지 정해진 게 없다.
• 메뉴가 기능 추가될 때마다 아무 데나 붙어서, 설정 하나 찾으려면 다섯 번 눌러야 한다.
• 디자이너·개발자·AI에게 화면을 설명할 때마다 말로 길게 풀고, 그래도 서로 다르게 이해한다.

용어

• user flow(유저 플로우) — 사용자가 하나의 목표(가입, 결제, 지출 기록)를 이루기까지 거치는 화면·행동·분기의 순서도. 시작점 → 화면 → 행동 → 분기(성공/실패, 로그인 여부) → 끝점. 4번 레슨 happy·unhappy path를 그림으로 이어 놓은 것(상황 1 해결).
  • 예: 장바구니 → [로그인 여부?] → (아니오) 로그인 → 배송지 → 결제 → [성공?] → (예) 완료 화면 / (아니오) 실패 안내 → 결제 재시도.
  • 비유: 지하철 노선도. 역(화면)과 선(이동)과 환승역(분기)이 보여야 길을 잃지 않는다.
• user journey map(사용자 여정 지도) — flow보다 넓고 긴 그림. 사용자가 처음 알게 된 순간부터 오래 쓰기까지(마케팅 그로스 용어 1번 AARRR 전체) 단계별로 무엇을 하고, 어떤 생각·감정이고, 어떤 접점(브랜딩 용어 1번 touchpoint)에서 무엇이 불편한지를 지도로 그린다. 감정이 가장 떨어지는 지점이 개선 1순위.
  • 차이: flow = 한 가지 일을 하는 길, journey = 고객과의 전체 관계.
• IA(Information Architecture, 정보 구조) — 서비스 안의 정보·기능을 어떻게 묶고, 이름 붙이고, 어디에 배치할지의 설계. 메뉴 분류, 카테고리 이름, 계층(깊이)(상황 2 해결).
  • depth(깊이) — 원하는 기능까지 몇 단계를 눌러 들어가야 하나. 자주 쓰는 기능은 얕게(1~2단계). UI 용어 18번 Fitts’s·Hick’s law와 연결.
  • card sorting(카드 소팅) — 기능 이름을 카드에 적어 사용자에게 직접 묶어 보게 하는 방법. 팀이 아니라 사용자 머릿속 분류대로 IA를 짠다.
  • 비유: 마트 진열. 라면은 라면 코너에, 자주 사는 우유는 입구 가까이. 기획자 마음대로 늘어놓으면 손님이 못 찾는다.
• sitemap(사이트맵) — IA를 트리(가지) 그림으로 그린 것. 홈 → 지출 / 리포트 / 설정 → 설정 아래 계정·알림·카테고리… 전체 화면 목록이자 구조도. (웹 용어 35번 SEO의 sitemap.xml과 이름이 같지만, 이건 기획용 구조도다.)
• 화면 설계서 · 스토리보드(SB, StoryBoard) — 화면마다 와이어프레임(UI 용어 14번) 옆에 번호를 달고, 각 요소의 동작·조건·문구·예외 처리를 적은 문서. 한국 웹·앱 기획 실무에서 많이 쓰는 형식으로, 흔히 “SB”라 부른다(상황 3 해결).
  • 예: ① 저장 버튼 — 필수값 미입력 시 비활성 / ② 금액 입력 — 숫자만, 0 이하 불가(4번 레슨 경계값) / ③ 저장 성공 시 토스트 “저장했어요”(UI 용어 9번) 후 목록으로 이동.
  • AI에게도 “화면 하나 만들어줘” 대신 스토리보드 형식으로 요소별 동작을 적어 주면 훨씬 정확하다.

지시 예문

• “결제 기능의 user flow를 Mermaid 순서도로 그려줘. 로그인 여부, 결제 성공/실패, 취소 분기와 각 끝점(어느 화면으로 가는지)까지.”
• “현재 앱의 sitemap을 트리로 정리하고, depth가 3 이상인 자주 쓰는 기능을 찾아서 IA 개선안을 제안해줘.”
• “신규 사용자의 user journey map을 만들어줘. 알게 됨 → 가입 → 첫 기록 → 1주 사용 → 결제 단계별로 행동·감정·접점·불편, 감정이 가장 낮은 지점 표시.”
• “지출 입력 화면을 스토리보드 형식으로 정리해줘. 요소마다 번호, 동작, 조건, 문구, 예외 처리.”

---

일 쪼개기: backlog · epic · story · task · vertical slice · story point

상황

• AI에게 “가계부 앱 전체“를 한 번에 만들라고 했더니, 반쯤 만들다 맥락이 꼬이고 앞에서 만든 걸 망가뜨렸다.
• 해야 할 일이 메모장·슬랙·머릿속에 흩어져 있어 무엇이 남았는지 모르겠다.
• 화면을 다 만든 뒤 API를 다 만들고 마지막에 붙였더니, 마지막 날에야 하나도 연결이 안 된다는 걸 알았다.

용어

• backlog(백로그) — 앞으로 할 일의 대기 목록. 우선순위 순으로 정렬해 둔다(2번 레슨 MoSCoW, 그로스 용어 10번 ICE·RICE). 흩어진 요청을 한 곳에 모으는 것부터가 시작(상황 2 해결).
  • product backlog — 제품 전체의 할 일 목록. 계속 바뀌고 다듬어진다(backlog grooming / refinement, 백로그 정리).
• 일의 크기 단위(큰 것 → 작은 것)
  • epic(에픽) — 여러 스토리를 묶은 큰 덩어리. “월말 리포트 기능”. 한 번에 끝나지 않는다.
  • story(스토리) — 3번 레슨 user story. 사용자가 느낄 수 있는 가치 한 조각. “카테고리별 지출 그래프를 보고 싶다”.
  • task(태스크) — 스토리를 구현하기 위한 작업 조각. “집계 API 만들기”, “그래프 컴포넌트 만들기”. 사용자에겐 따로 보이지 않을 수 있다.
  • subtask(하위 작업) — 태스크를 더 쪼갠 것.
  • 비유: 이사. epic = 이사 전체, story = 거실 정리 끝내기(가족이 쓸 수 있게 됨), task = 소파 옮기기·TV 설치·커튼 달기.
• ticket / issue(티켓·이슈) — 백로그의 일 하나를 기록한 카드(GitHub Issues, Jira, Linear 등). 제목, 유저 스토리, acceptance criteria(3번 레슨), 우선순위, 담당자를 담는다. AI에게도 티켓 하나 = 한 번의 작업 단위로 주면 맥락이 덜 꼬인다(상황 1 해결).
• horizontal vs vertical slice(가로 자르기 vs 세로 자르기)
  • horizontal(가로) — 층별로 나눠 만든다: 화면 전부 → API 전부 → DB 전부. 마지막에 합칠 때까지 아무것도 작동하지 않고, 문제가 끝에 터진다(상황 3).
  • vertical slice(세로 자르기) — 기능 하나를 화면·API·DB까지 얇게 끝까지 관통해서 만든다. “식비 카테고리 그래프 하나만, 하지만 실제 데이터로 작동하게”. 매 조각이 작동하는 결과물이라 일찍 문제를 찾는다. 2번 레슨 킥보드→자전거 비유와 같은 원리.
  • 비유: 케이크. 가로로 자르면 맨 위 크림층만 먹게 되지만, 세로로 자르면 한 조각에 빵·크림·과일이 다 들어 있다.
• story point(스토리 포인트) — 일의 상대적 크기를 시간 대신 점수로 추정하는 것. 보통 1, 2, 3, 5, 8, 13처럼 간격이 벌어지는 숫자(피보나치 수열)를 쓴다 — 큰 일일수록 정확히 알기 어렵다는 걸 반영. 8 이상이면 쪼개라는 신호로 쓰는 팀이 많다.
• work breakdown(작업 분해) — 큰 일을 작고 검증 가능한 조각으로 계속 나누는 습관 자체. AI 작업에서 특히 중요하다: 한 번에 큰 걸 시키기보다 계획(조각 목록)을 먼저 받고, 조각마다 구현 → 확인 → 커밋.

지시 예문

• "’월말 리포트’ epic을 user story 5~8개로 쪼개고, 각 스토리를 task로 나눠 GitHub Issue 형식(제목, 스토리, AC, 우선순위)으로 써줘.”
• “화면·API를 따로 다 만들지 말고, ‘식비 카테고리 그래프’를 화면부터 DB까지 vertical slice로 먼저 하나 끝까지 작동하게 만들어줘.”
• “이 스토리들에 story point를 매기고, 8점 이상인 건 더 작게 쪼개줘.”
• “바로 구현하지 말고 먼저 작업 분해 계획을 보여줘. 내가 확인하면 조각 하나씩 구현하고 조각마다 커밋해줘.”

---

요구사항의 종류: functional · non-functional · constraint · assumption · dependency

상황

• 기능은 요청대로 다 만들어졌는데, 목록 화면이 5초씩 걸리고 모바일에서 버튼이 안 눌린다. 요구사항엔 “빠르게”, “모바일 지원” 같은 말이 없었다.
• “보안 신경 써줘”라고 했는데 무엇을 어디까지 해야 하는지 AI도 나도 기준이 없다.
• 외부 결제 서비스 승인이 늦어져서 출시 일정 전체가 밀렸다. 그게 필요하다는 걸 계획에 적지 않았다.

용어

• functional requirement(기능 요구사항) — 시스템이 무엇을 하는가. “사용자는 지출을 입력·수정·삭제할 수 있다”, “월말에 카테고리별 그래프를 보여준다”. 3번 레슨 user story와 acceptance criteria가 대부분 여기.
• non-functional requirement(NFR, 비기능 요구사항) — 시스템이 얼마나 잘 하는가. 기능이 아니라 품질 기준. 적지 않으면 “작동은 하는데 쓸 수 없는” 결과가 나온다(상황 1). 흔한 항목과 지금까지 배운 지표:
  • performance(성능) — “지출 목록 응답 p95 500ms 이하”(인프라 용어 8번 metric), “LCP(Largest Contentful Paint) 2.5초 이하”(웹 용어 2번)
  • security(보안) — “모든 테이블 RLS(Row Level Security) 적용”(DB 용어 12번), “로그인 5회 실패 시 잠금”(인프라 용어 14번)
  • accessibility(접근성) — “본문 대비 WCAG(Web Content Accessibility Guidelines) AA 4.5:1”(UI 용어 5번), “키보드만으로 모든 기능 사용 가능”(웹 용어 19번)
  • compatibility(호환성) — “iOS Safari·Android Chrome 최신 2개 버전, 360px 폭부터”(웹 용어 30번 반응형)
  • reliability · availability(신뢰성·가용성) — “월 가용성 99.9%”(인프라 용어 13번 SLO(Service Level Objective))
  • scalability(확장성) — “가입자 10만 명까지 구조 변경 없이”(인프라 용어 6번)
  • usability(사용성) — “신규 사용자가 도움말 없이 3분 안에 첫 지출 기록”(그로스 용어 2번 TTV(Time To Value))
  • 핵심은 측정 가능하게 쓰는 것. “빠르게”·”안전하게”는 기준이 아니다(상황 2). 숫자와 확인 방법을 붙이면 3번 레슨 acceptance criteria처럼 검증할 수 있다.
  • 비유: 집 짓기. functional은 “방 3개, 화장실 2개”, non-functional은 “겨울에 실내 20도 유지, 층간 소음 기준 충족”. 방이 다 있어도 춥고 시끄러우면 살 수 없다.
• constraint(제약 조건) — 선택의 여지가 없는 조건. “Next.js + Supabase로”, “예산 월 5만 원 이하”(인프라 용어 10번 비용), “개인정보는 국내 리전에”(인프라 용어 9번), “2주 안에 출시”.
• assumption(가정) — 확인은 안 됐지만 사실이라고 두고 진행하는 것. “사용자는 대부분 모바일로 접속할 것이다”. 가정은 적어 두고 나중에 검증한다 — 틀리면 설계가 바뀐다(1번 레슨 open question과 짝).
• dependency(의존성) — 이 일이 끝나려면 먼저 되어야 하는 다른 일·외부 요소. 결제 서비스 심사, 디자인 시안, 다른 팀의 API, 도메인 연결(인프라 용어 2번). 계획에 적고 가장 먼저 착수한다(상황 3 해결).
  • blocker(블로커) — 지금 진행을 막고 있는 의존성. 생기면 바로 공유한다.

지시 예문

• “이 PRD에 non-functional requirement 섹션을 추가해줘. 성능·보안·접근성·호환성을 각각 측정 가능한 숫자와 확인 방법으로.”
• "’보안 신경 써줘’를 구체적인 NFR 목록으로 바꿔줘. RLS, 비밀값 관리, rate limit, 입력 검증 각각 무엇을 어디까지 할지.”
• “이 기능의 constraint, assumption, dependency를 나눠 정리하고, 외부 의존성은 가장 먼저 착수할 순서로 표시해줘.”
• “구현 끝나면 NFR 기준(목록 응답 p95 500ms, LCP 2.5초, 대비 4.5:1)을 실제로 측정해서 통과 여부를 표로 보고해줘.”

---

QA와 버그 리포트: test case · regression · smoke test · UAT · severity vs priority

상황

• AI에게 “결제가 안 돼요, 고쳐줘“라고만 했더니 엉뚱한 곳을 고치고 “해결했다”고 한다. 실제로는 그대로다.
• 검색 기능을 고쳤더니 멀쩡하던 로그인이 깨졌다. 배포하고 나서야 알았다.
• 사소한 오타와 결제 불가 버그가 같은 줄에 섞여 있어서 무엇부터 고쳐야 할지 모르겠다.

용어

• QA(Quality Assurance, 품질 보증) — 출시 전에 제품이 요구사항대로, 문제없이 동작하는지 확인하는 활동 전부. 3번 레슨 acceptance criteria·DoD(Definition of Done), 7번 NFR(Non-Functional Requirement)이 QA의 기준표가 된다.
• test case(테스트 케이스) — “이 조건에서 이렇게 하면 이렇게 돼야 한다“를 하나씩 적은 확인 항목. 3번 레슨 Given-When-Then, 4번 레슨 엣지 케이스가 그대로 테스트 케이스가 된다.
• bug report(버그 리포트) — 버그를 다른 사람(AI)이 재현할 수 있게 적은 기록(상황 1 해결). 웹 용어 36번 개발자 도구 “증거 전달”의 정식 형식.
  • 제목 — 무엇이 어디서 안 되나: “iOS Safari에서 카드 결제 버튼이 반응 없음”
  • steps to reproduce(재현 단계) — 1, 2, 3 순서대로. 재현이 안 되면 고칠 수 없다.
  • expected vs actual(기대 결과 vs 실제 결과) — “결제창이 떠야 함” vs “아무 반응 없음, 콘솔에 TypeError”
  • environment(환경) — 기기·OS·브라우저·계정 종류·앱 버전·배포 환경(웹 용어 33번)
  • 증거 — 스크린샷, 영상, 콘솔 에러, Network 상태 코드(웹 용어 28번), 발생 시각(인프라 용어 8번 로그 찾기용)
  • 비유: 병원 진료. “아파요”가 아니라 “어제부터, 오른쪽 아랫배가, 누르면 더”. 재현 단계는 “증상이 나타나는 동작”을 의사 앞에서 보여주는 것.
• regression(회귀) — 고치거나 기능을 추가하다가 원래 잘 되던 게 다시 망가지는 것(상황 2). AI가 코드를 넓게 고칠 때 특히 자주 생긴다.
  • regression test(회귀 테스트) — 변경 후 기존 기능이 여전히 되는지 다시 확인하는 테스트. 자동화해서 CI(Continuous Integration, 웹 용어 33번)에서 매번 돌리는 게 이상적.
• smoke test(스모크 테스트) — 배포 직후 핵심 기능 몇 개만 빠르게 확인하는 점검. 로그인되나, 메인 화면 뜨나, 결제 버튼 눌리나. 전자 기기에 처음 전원을 넣고 연기가 나는지 보던 데서 온 이름.
• UAT(User Acceptance Testing, 사용자 인수 테스트) — 실제 사용자(또는 기획자)가 실제 시나리오대로 써 보며 “이거면 받아들이겠다”를 확인하는 마지막 단계. 개발자의 테스트가 “제대로 만들었나“라면 UAT는 “맞는 걸 만들었나”.
• severity vs priority(심각도 vs 우선순위) — 둘은 다르다(상황 3 해결).
  • severity(심각도) — 버그가 얼마나 큰 피해를 주나. 결제 불가·데이터 손실은 치명(critical), 오타는 사소(trivial).
  • priority(우선순위) — 얼마나 빨리 고쳐야 하나. 대체로 심각도를 따르지만 예외가 있다: 메인 화면 회사 이름 오타는 심각도 낮아도 우선순위 높음.
• hotfix(핫픽스) — 실서비스의 급한 버그를 정규 일정 밖에서 바로 고쳐 배포하는 것. 그 전에 웹 용어 33번 rollback으로 피해부터 멈출 수 있는지 먼저 본다(인프라 용어 13번 mitigation).
• known issue(알려진 문제) — 알고 있지만 아직 안 고친 문제 목록. 숨기지 않고 공유한다.

지시 예문

• “이 버그를 고치기 전에, 재현 단계·기대 결과·실제 결과·환경·콘솔 에러를 정리한 bug report부터 써서 보여줘. 재현이 확인되면 원인을 찾아줘.”
• “결제 기능 고친 뒤 regression test를 돌려줘. 로그인·지출 입력·검색이 여전히 되는지 자동 테스트로 확인하고 결과 보고.”
• “배포 후 smoke test 체크리스트를 만들어줘. 5분 안에 끝나는 핵심 기능 5개.”
• “버그 목록 20개를 severity(치명·높음·보통·사소)와 priority로 따로 분류해서 표로 정리해줘.”