# Phase 3 — POC 설계와 실행
> **이 장에서 배우는 것**
> POC의 진짜 목적, 범위를 정하는 법, 그리고 "성공했다"를 판정하는 기준.
## 이 단계의 목적
> **소규모 파일럿을 통해 효과를 검증하고 피드백을 수집합니다.**
여기서 오해가 하나 있습니다.
> **POC의 목적은 성공시키는 것이 아닙니다. 확대해도 되는지 판정하는 것입니다.**
이 차이가 결과를 바꿉니다. "성공시키는 것"이 목적이 되면 잘 되는 케이스만 골라
보여주게 되고, 확대한 뒤에 실패합니다. **판정이 목적이면 안 되는 케이스를 일부러
찾습니다.**
## 네 가지 활동
### 1. MVP 스코프 정의 (Quick Win 우선)
전체를 만들지 않습니다. **가장 자주 발생하고 가장 단순한 것부터** 자릅니다.
청구서 예시로 보겠습니다.
```
전체 범위: 거래처 80곳, 양식 12종, 월 400건
POC 범위: 거래처 상위 5곳, 양식 2종, 월 180건 (전체의 45%)
→ 나머지는 사람이 계속 처리
```
**전체의 45%만 다뤄도 판정에는 충분합니다.** 여기서 효과가 없으면 나머지 55%에서
생길 리 없습니다.
> **범위를 좁힐 때 기준**
> 발생 빈도가 높은 것부터. 어려운 예외부터 하면 시간이 다 갑니다.
> 예외 처리는 확대 단계에서 붙입니다.
### 2. AI 에이전트/워크플로 구축
여기가 실제로 만드는 부분입니다. Phase 2에서 그린 흐름도가 설계도가 됩니다.
이 단계에서 정할 것 두 가지입니다.
| 정할 것 | 예 |
|---|---|
| **어디에 사람 승인을 둘 것인가** | 100만원 초과 건은 승인 |
| **틀렸을 때 어떻게 아나** | 입력 후 담당자 확인 목록에 표시 |
두 번째가 특히 중요합니다. **틀린 걸 모르면 효과도 못 잽니다.**
### 3. 사용자 테스트 & 피드백 수집
담당자가 실제로 써봅니다. 여기서 나오는 말이 POC 결과보다 중요할 때가 있습니다.
| 나오는 말 | 무슨 뜻인가 |
|---|---|
| "이건 제가 하는 게 빠른데요" | **구조 문제.** 단계가 늘었을 가능성 |
| "이 경우는 어떻게 되나요?" | 예외 발견. 범위에 넣을지 판단 |
| "확인하는 게 일이네요" | 신뢰 부족. 정확도나 승인 지점 재설계 |
| "이거 언제 정식으로 쓸 수 있어요?" | **좋은 신호** |
### 4. 성과 지표 측정 (시간/비용/품질)
Phase 1에서 기록한 숫자와 **같은 방법으로** 잽니다. 방법이 다르면 비교가
안 됩니다.
```
Phase 1 (이전) POC 결과
건당 처리 시간 6분 1.5분 (승인 대기 제외)
월 총 시간 40시간 11시간 (POC 범위 환산)
오류 건수 월 12건 월 2건
사람 개입 전건 18% (100만원 초과분)
```
## 산출물
> **POC 결과 보고서 & 스케일업 권고안**
보고서에 반드시 들어가야 하는 것은 **잘된 것보다 안 된 것**입니다.
```
1. 결과 요약 (위 표)
2. 잘 된 것
3. 안 된 것 ← 이게 가장 중요
- 손글씨 수기 청구서는 인식률이 낮음 (전체의 6%)
- 신규 거래처 첫 건은 계정 코드를 자주 틀림
4. 확대 시 필요한 것
- 손글씨 건은 사람 처리로 분기
- 신규 거래처는 첫 3건 승인 필수
5. 권고: 확대 / 조건부 확대 / 중단
```
## 게이트 — 다음으로 넘어가려면
> **Phase 1의 숫자가 실제로 움직였는가? 사용자가 계속 쓰고 있는가?**
두 질문 다 "예"여야 합니다. 하나만 만족하면 아직 아닙니다.
| 숫자 | 사용 | 판정 |
|---|---|---|
| 움직임 | 계속 씀 | **확대** |
| 움직임 | 안 씀 | 구조 문제. 왜 안 쓰는지부터 |
| 안 움직임 | 계속 씀 | 편의는 있으나 효과 없음. 재설계 |
| 안 움직임 | 안 씀 | **중단**하고 Phase 1로 |
**"안 움직임 + 계속 씀"이 함정입니다.** 사람들이 좋아하니 성공처럼 보이는데
지표는 그대로입니다. 확대하면 비용만 늘어납니다.
## POC를 짧게 유지하는 법
POC가 길어지는 건 거의 항상 **범위가 넓어져서**입니다.
```
POC 2주차: "이 케이스도 되면 좋겠는데요"
POC 4주차: "이왕이면 저 시스템도 연동하죠"
POC 8주차: 아직 진행 중
```
**시작할 때 범위를 문서에 적고, 추가 요청은 전부 "확대 단계 목록"으로 보내세요.**
거절이 아니라 순서 문제라고 설명하면 대체로 받아들여집니다.
## 자주 하는 오해
### "POC인데 대충 만들어도 되나?"
**품질은 대충 하면 안 되고 범위를 좁혀야 합니다.** 둘은 다릅니다. 좁은 범위를
제대로 만들어야 판정이 유효합니다. 넓은 범위를 대충 만들면 효과가 없어도 그게
설계 탓인지 대충 만든 탓인지 모릅니다.
### "실패하면 시간 낭비 아닌가?"
POC 3~6주로 **확대 실패를 막은 것**입니다. 검증 없이 전사 확대했다가 6개월 뒤
실패하는 비용과 비교해보세요. **POC의 실패는 성공입니다** — 비싼 실수를 싸게
막았습니다.
---
## 확인
**1. POC의 목적을 한 문장으로 말하면?**
답
**확대해도 되는지 판정하는 것**입니다. 성공시키는 게 목적이 되면 잘 되는 케이스만
골라 보여주게 되고 확대 후에 실패합니다. 판정이 목적이면 안 되는 케이스를 일부러
찾게 됩니다.
**2. "지표는 안 움직였는데 사용자는 계속 쓴다"면 어떻게 판정합니까?**
답
**재설계**입니다. 편의성은 있지만 효과가 없는 상태입니다. 사람들이 좋아하니
성공처럼 보이는 게 함정이고, 이대로 확대하면 비용만 늘어납니다.
**3. POC 결과 보고서에서 가장 중요한 항목은 무엇입니까?**
답
**안 된 것**입니다. 확대할 때 무엇을 보완해야 하는지가 거기서 나옵니다. 잘된
것만 적힌 보고서는 확대 단계에서 그대로 사고가 됩니다.
---
그 POC를 직접 한 장으로 설계해봅니다. 40분입니다 →
[POC를 한 장으로 설계해보기](/guide/ax-try-poc-design)