4주 PoC 설계법 - 무엇을 증명하고 무엇을 버릴 것인가

PoC가 흐지부지 끝나는 이유는 대개 기술이 안 돼서가 아닙니다. 무엇을 증명하려 했는지 아무도 명확히 몰랐기 때문입니다.

"일단 한번 해 보죠"로 시작한 PoC는 4주 뒤 "괜찮은 것 같긴 한데"로 끝납니다. 그리고 다음 단계로 못 갑니다.

먼저 버려야 할 것들

4주는 짧습니다. 그래서 시작 전에 하지 않을 일을 먼저 정해야 합니다.

• 전 라인 적용 → 한 개 라인만
• 전 SKU 대상 → 오류가 잦은 SKU 군만
• API 자동 연동 → CSV·엑셀로 시작
• 기존 시스템 연계 → 검수 단계만 독립 운영
• 완벽한 UI → 현장이 쓸 수 있는 수준

이걸 다 넣으면 4주가 아니라 4개월짜리 프로젝트가 되고, 그 사이에 우선순위가 바뀝니다.

PoC의 목적은 완성된 시스템을 만드는 것이 아니라, 계속 갈지 말지를 결정할 근거를 만드는 것입니다.

1단계: 현장 진단 (1주차)

무엇을 검증할지 정하려면 현재 상태를 알아야 합니다. 이 주에 할 일은 관찰과 측정입니다.

확인할 것

• 현재 검수 절차가 실제로 어떻게 이루어지는지 (문서 말고 실제)
• 오류가 어느 공정에서 나는지
• 어떤 SKU 조합에서 자주 나는지
• 현재 오류를 어떻게 발견하고 있는지
• 클레임 한 건 처리에 걸리는 시간

2단계: 범위와 기준 설계 (1주차 말)

여기가 PoC의 성패를 가릅니다. 다음 다섯 가지를 문서로 확정합니다.

성공 기준을 숫자로 만드는 법

"정확도가 올라간다"는 기준이 될 수 없습니다. 측정 가능한 형태로 바꿔야 합니다.

• 대상 라인의 오류 검출 건수 (기존에는 0건으로 기록되던 것)
• 검수 1건당 소요 시간 (기존 대비 증감)
• 클레임 발생 시 확인 소요 시간
• 작업자가 절차를 따르지 않은 비율

3단계: 현장 검증 (2~4주차)

실제 주문으로 돌립니다. 이 기간에 중요한 것은 두 가지입니다.

매일 기록한다

주간 단위로 몰아서 보면 원인을 놓칩니다. 최소한 다음은 매일 남깁니다.

• 처리 건수와 검출된 오류 건수
• 오류 유형 (초과 / 오품 / 누락)
• 작업자가 겪은 불편
• 인식 실패 사례와 그때의 조건

현장 목소리를 기록으로 남긴다

"이거 좀 불편한데요"라는 말은 그 자리에서 사라집니다. 하지만 이것이 확대 도입의 성패를 가릅니다. 조도, 거치 각도, 화면 위치, 소리 크기 같은 것들입니다.

4단계: 판단 (4주차 말)

PoC가 끝나면 세 가지 중 하나를 결정합니다.

1. 확대 — 기준을 충족했고 현장 수용도도 확인됨
2. 조건부 재검증 — 특정 문제가 확인됐고 해결 후 재시도
3. 중단 — 이 방식이 이 현장에 맞지 않음

3번도 정상적인 결과입니다. 4주 만에 안 맞는다는 것을 알게 된 것이, 6개월 프로젝트 후에 아는 것보다 훨씬 낫습니다.

PoC 계약에서 확인할 것

• 시스템 교체나 장기 약정이 전제되지 않는지
• PoC 종료 시 원상 복구가 가능한지
• 검증 기간 중 수집된 데이터의 소유·삭제 조건
• 확대 도입 시 조건이 별도 협의인지

자주 묻는 질문

4주가 너무 짧지 않나요?

범위를 좁히면 충분합니다. 오히려 기간을 늘리면 우선순위가 밀려 흐지부지될 위험이 커집니다. 한 라인·제한된 SKU라면 3주 실운영으로도 판단 근거가 나옵니다.

PoC에 현장 인력을 얼마나 투입해야 하나요?

해당 라인 작업자 외에 별도 인력은 필요하지 않은 수준이어야 합니다. 별도 인력이 필요하다면 그 자체가 확대 도입이 어렵다는 신호입니다.

PoC 결과가 애매하면 어떻게 하나요?

애매하다는 것은 대개 성공 기준을 숫자로 정하지 않았다는 뜻입니다. 시작 전에 기준을 문서로 확정하면 애매한 결과는 잘 나오지 않습니다.