시작 전
오늘은 제품이 아니라 판단표를 만듭니다
PoC는 작게 만든 제품이 아니라 “이 가정이 맞는가?”를 빨리 확인하고 버릴 수 있는 실험입니다. 화면보다 다음 결정을 내릴 근거가 중요합니다.
- 가정: 아직 사실로 확인하지 않았지만 계획에 들어 있는 전제
- 위험도: 그 가정이 틀렸을 때 다시 해야 하는 비용
- PoC: 질문 하나에 답하도록 입력과 관찰 지점을 줄인 실험
- 판정표: 통과·실패·경계를 결과 전에 약속한 세 줄
01 · 가정 찾기
AI의 말과 내 계획에서 “당연하다”를 꺼냅니다
가정은 거창한 가설이 아닙니다. 입력이 항상 같은 형식일 것, 사람이 결과를 믿을 것처럼 말하지 않고 넘어간 문장입니다.
- 01
목표를 한 문장으로 다시 쓰기
왜 하나요? 무엇을 성공으로 볼지 고정합니다.
할 일 누가 어떤 입력을 넣고 어떤 결과를 얻으면 도움이 되는지 씁니다.
복사해서 써도 되는 요청이 과제의 사용자·입력·기대 결과를 한 문장으로 정리해줘. 문서에 없는 내용은 추측하지 마.
정상이라면 “자동화한다” 대신 “담당자가 파일을 넣으면 피드백 요약을 검토한다”처럼 관찰 가능한 문장이 됩니다.
- 02
숨은 전제를 전부 나열하기
왜 하나요? 나중에 실패했을 때 무엇이 깨졌는지 찾을 재료를 만듭니다.
할 일 입력 형식·품질·처리 정확도·외부 연결·사람의 신뢰에 관한 전제를 적습니다.
복사해서 써도 되는 요청현재 Spec과 계획에서 말하지 않았지만 전제로 사용한 문장을 찾아줘. 근거 위치도 함께 적어줘.
정상이라면 각 가정에 근거가 붙고, 모르는 내용은 미결정으로 구분됩니다.
- 03
틀렸을 때 비용으로 순위 매기기
왜 하나요? 흥미로운 질문이 아니라 비싼 오답을 먼저 확인합니다.
할 일 전체 계획이 무효가 되는지, 늦게 알수록 비싼지, 다음 결정을 막는지 비교합니다.
복사해서 써도 되는 요청가정을 재작업 범위·지연·사용자 영향으로 높음/중간/낮음 순위화해줘. 근거가 없으면 질문으로 남겨줘.
정상이라면 “중요해 보인다”가 아니라 “틀리면 연결 설계 전체를 버린다”처럼 비용이 설명됩니다.
TIP · 가정 여러 개를 한 실험에 넣지 말고 가장 높은 하나만 고릅니다.
02 · PoC 설계
질문 하나를 가장 싼 실험으로 줄이기
실험의 크기는 코드 양이 아니라 질문을 판정하는 데 필요한 최소 입력으로 정합니다. 기준은 결과 전에 씁니다.
- 01
가정 하나를 질문으로 바꾸기
왜 하나요? 실험이 답해야 할 문장을 고정합니다.
할 일 “잘 될까?” 대신 입력과 조건이 들어간 예·아니오 질문으로 씁니다.
복사해서 써도 되는 요청선택한 가정을 “어떤 입력에서 어떤 결과가 나오면 성립하는가?”라는 한 문장으로 바꿔줘.
정상이라면 실험 전에 결과의 모양을 상상할 수 있습니다.
- 02
최소 입력과 관찰 지점 정하기
왜 하나요? 불필요한 기능이 판정을 흐리지 않게 합니다.
할 일 대표 입력 하나, 실패를 드러낼 입력 하나, 결과를 확인할 위치 하나를 정합니다.
정상이라면 “전체 데이터를 넣는다”가 아니라 “두 파일을 넣고 누락률을 본다”가 됩니다.
- 03
통과·실패·경계 세 줄 쓰기
왜 하나요? 사람마다 다른 감상 대신 같은 판정을 남깁니다.
할 일 통과 조건, 실패 조건, 애매할 때 다시 확인할 방법을 결과 전에 적습니다.
복사해서 써도 되는 요청이 질문의 PASS/FAIL/BOUNDARY 조건을 관찰 가능한 문장으로 제안해줘. 정할 수 없으면 이유를 써줘.
정상이라면 “대체로 괜찮다” 대신 숫자나 사례로 판정할 수 있습니다.
- 04
판정 뒤의 다음 행동 예약하기
왜 하나요? 결과를 보고 다시 회의하지 않게 합니다.
할 일 통과·실패·경계마다 다음에 할 일을 한 줄씩 씁니다.
정상이라면 실험 문서만 읽어도 결과가 다음 주 행동으로 이어집니다.
03 · 다음 단계
W04에서 설계한 실험을 실행합니다
이번 주의 완료는 실행 화면이 아니라 질문·입력·관찰·판정이 연결된 설계입니다.
- 한 번 실행하고 실제로 어긋난 지점을 기록합니다.
- 실패를 “고쳐줘”로 넘기지 않고 재현 명령과 원인 후보부터 만듭니다.
- 경계 판정이면 입력이나 관찰 지점을 더 작게 줄입니다.
마지막 확인
poc-experiment.md
아래 한 장을 채우면 PoC가 기능 목록이 아니라 판정 가능한 실험이 됩니다.
# PoC 실험 카드
## 검증할 가정
- 가정: [아직 확인하지 않은 전제]
- 틀리면 생기는 비용: [다시 해야 하는 범위]
## 질문
[어떤 입력에서 어떤 결과가 나오면 성립하는가?]
## 최소 입력과 관찰
- 대표 사례: [입력]
- 실패를 드러낼 사례: [입력]
- 관찰 지점: [판정 근거]
## 판정표
- PASS: [통과 조건]
- FAIL: [실패 조건]
- BOUNDARY: [애매하면 줄일 것]
## 다음 행동
- PASS: [다음 범위]
- FAIL: [버리거나 다시 정의할 것]
- BOUNDARY: [추가 질문]완료 체크
이 7가지가 보이면 오늘의 목표를 달성한 것입니다
- 목표가 사용자·입력·결과 한 문장이다.
- 숨은 가정을 근거와 함께 뽑았다.
- 틀렸을 때 비용으로 순위를 매겼다.
- 가장 위험한 하나를 질문으로 골랐다.
- 최소 입력과 관찰 지점을 정했다.
- PASS·FAIL·BOUNDARY 기준이 있다.
- 판정 뒤 다음 행동이 적혀 있다.
다음 단계
다음 주에는 설계한 실험을 실제로 실행합니다
W04에서 재현 가능한 실패를 만들고, 추측 대신 증거로 원인을 좁힙니다.
막힐 때
자주 나오는 질문
가정을 찾으려는데 아무것도 떠오르지 않아요.
“이 계획이 성립하려면 무엇이 항상 참이어야 하나?”라고 물어보세요. 입력 형식·빈도·권한·사람의 신뢰처럼 말하지 않고 넘어간 부분이 대부분 가정입니다.
가장 위험한 것이 여러 개면 모두 실험하면 안 되나요?
한 실험에 여러 가정을 넣으면 실패했을 때 원인을 알 수 없습니다. 비용이 가장 큰 하나부터 확인하고 나머지는 다음 질문으로 남깁니다.
PoC를 버리면 만든 시간이 아깝지 않나요?
PoC의 산출은 코드가 아니라 판정입니다. 틀린 방향을 몇 주 뒤에 발견하는 비용을 줄였다면 버리는 것이 실험의 성공입니다.
경계 판정은 통과로 봐도 되나요?
아니요. 기준이나 입력이 선명하지 않다는 뜻입니다. 관찰 지점을 더 좁혀 다시 보거나 다음 범위에 넣지 않습니다.