Phase 3 — POC 설계와 실행

이 장에서 배우는 것 POC의 진짜 목적, 범위를 정하는 법, 그리고 "성공했다"를 판정하는 기준.

이 단계의 목적

소규모 파일럿을 통해 효과를 검증하고 피드백을 수집합니다.

여기서 오해가 하나 있습니다.

POC의 목적은 성공시키는 것이 아닙니다. 확대해도 되는지 판정하는 것입니다.

이 차이가 결과를 바꿉니다. "성공시키는 것"이 목적이 되면 잘 되는 케이스만 골라 보여주게 되고, 확대한 뒤에 실패합니다. 판정이 목적이면 안 되는 케이스를 일부러 찾습니다.

네 가지 활동

1. MVP 스코프 정의 (Quick Win 우선)

전체를 만들지 않습니다. 가장 자주 발생하고 가장 단순한 것부터 자릅니다.

청구서 예시로 보겠습니다.

text

전체 범위: 거래처 80곳, 양식 12종, 월 400건POC 범위: 거래처 상위 5곳, 양식 2종, 월 180건 (전체의 45%)          → 나머지는 사람이 계속 처리

전체의 45%만 다뤄도 판정에는 충분합니다. 여기서 효과가 없으면 나머지 55%에서 생길 리 없습니다.

범위를 좁힐 때 기준 발생 빈도가 높은 것부터. 어려운 예외부터 하면 시간이 다 갑니다. 예외 처리는 확대 단계에서 붙입니다.

2. AI 에이전트/워크플로 구축

여기가 실제로 만드는 부분입니다. Phase 2에서 그린 흐름도가 설계도가 됩니다.

이 단계에서 정할 것 두 가지입니다.

정할 것	예
어디에 사람 승인을 둘 것인가	100만원 초과 건은 승인
틀렸을 때 어떻게 아나	입력 후 담당자 확인 목록에 표시

두 번째가 특히 중요합니다. 틀린 걸 모르면 효과도 못 잽니다.

3. 사용자 테스트 & 피드백 수집

담당자가 실제로 써봅니다. 여기서 나오는 말이 POC 결과보다 중요할 때가 있습니다.

나오는 말	무슨 뜻인가
"이건 제가 하는 게 빠른데요"	구조 문제. 단계가 늘었을 가능성
"이 경우는 어떻게 되나요?"	예외 발견. 범위에 넣을지 판단
"확인하는 게 일이네요"	신뢰 부족. 정확도나 승인 지점 재설계
"이거 언제 정식으로 쓸 수 있어요?"	좋은 신호

4. 성과 지표 측정 (시간/비용/품질)

Phase 1에서 기록한 숫자와 같은 방법으로 잽니다. 방법이 다르면 비교가 안 됩니다.

text

                Phase 1 (이전)    POC 결과건당 처리 시간   6분              1.5분 (승인 대기 제외)월 총 시간       40시간           11시간 (POC 범위 환산)오류 건수        월 12건          월 2건사람 개입        전건             18% (100만원 초과분)

산출물

POC 결과 보고서 & 스케일업 권고안

보고서에 반드시 들어가야 하는 것은 잘된 것보다 안 된 것입니다.

text

1. 결과 요약 (위 표)2. 잘 된 것3. 안 된 것 ← 이게 가장 중요   - 손글씨 수기 청구서는 인식률이 낮음 (전체의 6%)   - 신규 거래처 첫 건은 계정 코드를 자주 틀림4. 확대 시 필요한 것   - 손글씨 건은 사람 처리로 분기   - 신규 거래처는 첫 3건 승인 필수5. 권고: 확대 / 조건부 확대 / 중단

게이트 — 다음으로 넘어가려면

Phase 1의 숫자가 실제로 움직였는가? 사용자가 계속 쓰고 있는가?

두 질문 다 "예"여야 합니다. 하나만 만족하면 아직 아닙니다.

숫자	사용	판정
움직임	계속 씀	확대
움직임	안 씀	구조 문제. 왜 안 쓰는지부터
안 움직임	계속 씀	편의는 있으나 효과 없음. 재설계
안 움직임	안 씀	중단하고 Phase 1로

"안 움직임 + 계속 씀"이 함정입니다. 사람들이 좋아하니 성공처럼 보이는데 지표는 그대로입니다. 확대하면 비용만 늘어납니다.

POC를 짧게 유지하는 법

POC가 길어지는 건 거의 항상 범위가 넓어져서입니다.

text

POC 2주차: "이 케이스도 되면 좋겠는데요"POC 4주차: "이왕이면 저 시스템도 연동하죠"POC 8주차: 아직 진행 중

시작할 때 범위를 문서에 적고, 추가 요청은 전부 "확대 단계 목록"으로 보내세요. 거절이 아니라 순서 문제라고 설명하면 대체로 받아들여집니다.

자주 하는 오해

"POC인데 대충 만들어도 되나?"

품질은 대충 하면 안 되고 범위를 좁혀야 합니다. 둘은 다릅니다. 좁은 범위를 제대로 만들어야 판정이 유효합니다. 넓은 범위를 대충 만들면 효과가 없어도 그게 설계 탓인지 대충 만든 탓인지 모릅니다.

"실패하면 시간 낭비 아닌가?"

POC 3~6주로 확대 실패를 막은 것입니다. 검증 없이 전사 확대했다가 6개월 뒤 실패하는 비용과 비교해보세요. POC의 실패는 성공입니다 — 비싼 실수를 싸게 막았습니다.

확인

1. POC의 목적을 한 문장으로 말하면?

답

확대해도 되는지 판정하는 것입니다. 성공시키는 게 목적이 되면 잘 되는 케이스만 골라 보여주게 되고 확대 후에 실패합니다. 판정이 목적이면 안 되는 케이스를 일부러 찾게 됩니다.

2. "지표는 안 움직였는데 사용자는 계속 쓴다"면 어떻게 판정합니까?

답

재설계입니다. 편의성은 있지만 효과가 없는 상태입니다. 사람들이 좋아하니 성공처럼 보이는 게 함정이고, 이대로 확대하면 비용만 늘어납니다.

3. POC 결과 보고서에서 가장 중요한 항목은 무엇입니까?

답

안 된 것입니다. 확대할 때 무엇을 보완해야 하는지가 거기서 나옵니다. 잘된 것만 적힌 보고서는 확대 단계에서 그대로 사고가 됩니다.

그 POC를 직접 한 장으로 설계해봅니다. 40분입니다 → POC를 한 장으로 설계해보기