KCH W05 · 검증 결과로 MVP 범위 합의하기

KCH AGENT BUILDER LAB · W05 REVIEW

검증 결과를, 만들 수 있는 MVP 약속으로 바꾸기

W4의 실험 결과를 보고 큰 요구를 다시 줄입니다. 사용자 행동 한 문장, 테스트 경계, 사람 승인 지점, 이번에 하지 않을 일을 한 장 명세로 합의합니다.

복습 25분 · 실습 40분 결과물 2개 복습 후 퀴즈 →

시작 전

MVP는 작은 기능 목록이 아니라 작은 약속입니다

MVP는 대충 만든 제품이 아니라 현재 증거로 책임질 수 있는 첫 사용 흐름입니다. 검증되지 않은 욕심은 제외 범위로 보냅니다.

  • 판정: W04 실험의 통과·부분 통과·중단과 근거
  • 행동 문장: 사용자가 무엇을 해서 어떤 결과를 얻는지 쓴 문장
  • 테스트 경계: 어긋남을 빨리 잡을 입력·변환·결과 지점
  • 제외 범위: 이번에 하지 않는 일과 다시 볼 조건

01 · 증거 정리

실험의 세 칸을 범위 후보로 바꾸기

통과했거나 조건이 명확한 부분 통과만 다음 범위의 재료가 됩니다.

  1. 01

    결과를 PASS/PARTIAL/STOP으로 분류하기

    왜 하나요? 범위가 희망사항이 아니라 실행 결과 위에 서게 합니다.

    할 일 각 결과 옆에 입력 조건·관찰 신호·재현 기록을 붙입니다.

    복사해서 써도 되는 요청

    W04 기록을 읽고 결과를 PASS/PARTIAL/STOP으로 분류해줘. 근거가 없으면 미결정으로 남겨줘.

    정상이라면 판정과 조건이 함께 보입니다.

  2. 02

    부분 통과의 조건 고정하기

    왜 하나요? 애매한 결과가 전체 기능으로 부풀지 않게 합니다.

    할 일 성립한 입력·결과와 실패한 조건을 나눠 적습니다.

    정상이라면 “요약이 된다”가 아니라 어떤 입력에서 되는지 범위가 생깁니다.

  3. 03

    중단 판정을 기록하기

    왜 하나요? 실험 실패를 구현 실패로 오해하지 않습니다.

    할 일 깨진 가정과 다시 물어야 할 질문을 적고 MVP 후보에서 제외합니다.

    정상이라면 버린 결과도 다음 의사결정의 자료가 됩니다.

02 · 명세 작성

기능 이름 대신 사용자 행동으로 쓰기

“알림 기능”은 누가 무엇을 얻는지 말해주지 않습니다. 행동 문장을 읽으면 입력부터 결과와 판정이 상상되어야 합니다.

  1. 01

    문제를 한 문장으로 유지하기

    왜 하나요? 기능이 늘어도 해결 이유를 놓치지 않습니다.

    할 일 누가 어떤 상황에서 무엇 때문에 막히는지 적습니다.

    복사해서 써도 되는 요청

    현재 증거를 바탕으로 사용자·상황·문제를 한 문장으로 정리해줘. 검증되지 않은 효과는 넣지 마.

    정상이라면 문제와 해결책이 분리됩니다.

  2. 02

    사용자 행동과 결과 적기

    왜 하나요? MVP의 끝을 화면이 아니라 사용자 변화로 정합니다.

    할 일 “사용자는 [입력]을 해서 [검토 가능한 결과]를 얻는다”로 씁니다.

    정상이라면 첫 사용 흐름과 완료 상태를 알 수 있습니다.

  3. 03

    테스트와 승인 경계 정하기

    왜 하나요? 자동으로 흘릴 부분과 사람이 책임질 부분을 구분합니다.

    할 일 어긋남을 빨리 잡을 지점과 외부 영향 전에 확인할 사람을 적습니다.

    복사해서 써도 되는 요청

    행동 문장을 검증할 테스트 경계 3곳과 사람 승인 지점 1곳을 이유와 함께 제안해줘.

    정상이라면 언제 멈춰야 하는지가 보입니다.

03 · 제외와 승인

이번에 안 하는 일을 함께 합의하기

제외 목록은 포기가 아니라 약속의 울타리입니다. 이유와 재검토 조건을 붙입니다.

  1. 01

    제외 항목마다 근거 붙이기

    왜 하나요? 같은 범위 논쟁을 반복하지 않습니다.

    할 일 검증되지 않음·권한 비용·복구 불명확·가치 불명확 중 이유를 적습니다.

    정상이라면 “나중에”가 아니라 다시 볼 조건이 남습니다.

  2. 02

    사람이 명세를 고치고 승인하기

    왜 하나요? AI 초안이 팀의 결정처럼 굳는 것을 막습니다.

    할 일 증거가 있는지, 사용자가 확인할 결과가 있는지, 추측이 없는지 읽습니다.

    정상이라면 승인한 문장과 미결정 질문이 구분됩니다.

마지막 확인

mvp-spec.md

다섯 줄과 제외 범위를 채우면 Agent에게 위임할 수 있는 명세가 됩니다.

# MVP 명세

## 1. 문제
[누가 어떤 상황에서 무엇 때문에 막히는가]

## 2. 해결 방향
[검증 결과가 지지하는 해결 방법만]

## 3. 사용자 행동
사용자는 [입력]을 해서 [검토 가능한 결과]를 얻는다.

## 4. 구현·테스트·승인
- 구현 범위: [이번에 하는 처리]
- 테스트 경계: [입력 / 변환 / 결과]
- 사람 승인: [누가 무엇을 확인하는가]

## 5. 제외 범위
- 항목: [이유와 다시 볼 조건]

## 출처 판정
[W04 기록 링크]

완료 체크

이 7가지가 보이면 오늘의 목표를 달성한 것입니다

  • W04 판정과 근거가 연결되어 있다.
  • 부분 통과의 조건이 분리되어 있다.
  • 사용자 행동이 입력과 검토 가능한 결과로 끝난다.
  • 테스트 경계와 승인 위치가 있다.
  • 제외 항목마다 이유와 재검토 조건이 있다.
  • 추측한 효과를 넣지 않았다.
  • 사람이 초안을 읽고 승인했다.

다음 단계

다음 주에는 합의한 범위에 맞는 구조를 고릅니다

W06에서 유행 기술이 아니라 데이터·권한·오류 조건으로 가장 단순한 구조를 결정합니다.

모바일 퀴즈 풀기

막힐 때

자주 나오는 질문

MVP는 기능을 많이 넣을수록 좋은 것 아닌가요?

MVP의 크기는 현재 증거로 책임질 수 있는 사용자 흐름의 크기입니다. 기능이 늘어 판정과 복구가 흐려지면 미확인 약속이 됩니다.

부분 통과는 통과로 넣어도 되나요?

조건이 명확하면 조건부 후보로 넣을 수 있습니다. 성립·실패 조건을 쓸 수 없다면 다시 실험하거나 제외합니다.

제외 범위는 나중에 기억하면 안 되나요?

기억에 맡기면 다음 회의에서 다시 살아납니다. 제외 이유와 재검토 조건을 문서에 남기세요.

AI가 명세를 잘 써주면 승인 없이 써도 되나요?

안 됩니다. AI는 정리할 수 있지만 요구의 진실성을 보증하지 않습니다. 사람은 증거·범위·제외를 직접 확인해야 합니다.