PoC(개념 검증)를 많이 했어요. 성공한 것도 있고 실패한 것도 있어요. 실패한 것들을 돌아보면 공통점이 있었는데, 기술이 안 돼서 실패한 경우는 거의 없었어요. "성공이 뭔지 정하지 않고 시작한" 경우가 대부분이었어요.
PoC가 실패하는 전형적인 흐름
- 데모를 봤어요. 멋있어요. "우리 문서로도 해 보자."
- 문서 몇십 장을 받아서 돌려요. 꽤 잘 돼요.
- 결과를 보여 드려요. "오, 되네요. 근데 이건 좀 틀렸네요."
- 틀린 걸 고쳐요. 또 보여 드려요. "이것도 틀렸네요."
- 몇 달 지나요. "그래서 이걸 도입하면 뭐가 좋아지는 거죠?"
- 끝.
5번 질문에 답이 없는 이유는 1번에서 답을 안 정했기 때문이에요.
시작 전에 정할 네 가지
1. 성공 기준을 숫자로. "잘 되면"이 아니라 "필드별 정확도 ○% 이상, 신뢰도 낮음 표시된 항목의 실제 오류율 ○% 이상, 검수 시간 건당 ○분 이하". 기준이 없으면 PoC는 끝나지 않아요.
2. 평가 문서를 미리 정하고 봉인. PoC 중에 본 문서로 평가하면 당연히 잘 나와요. 시작할 때 평가용 문서를 따로 떼어 두고, 저희도 안 보고, 끝날 때 그걸로 재요.
3. 범위를 좁게. 문서 종류 하나, 필드 10개 이내. 5월 19일 도면 글에서 쓴 것처럼 "읽기 → 대조 → 규칙" 중 어디까지인지도요. 넓게 시작한 PoC는 전부 늘어졌어요.
4. 도입 후 흐름을 미리 그려요. PoC가 성공하면 누가 매일 이걸 쓰고, 결과는 어느 시스템에 들어가고, 검수는 누가 하나요? 이게 안 그려지면 PoC가 성공해도 도입이 안 돼요. "써 줄 사람"이 없는 PoC를 여러 번 봤어요.
PoC 중에 확인할 것
- 틀린 것의 분포. 틀린 게 특정 양식·특정 필드에 몰려 있는지. 몰려 있으면 그 부분만 범위에서 빼거나 사람이 보면 돼요. 고르게 퍼져 있으면 모델 문제예요.
- "모른다"가 믿을 만한지. 신뢰도 낮음으로 표시된 것들이 실제로 틀린 비율과, 높음으로 표시된 것들이 틀린 비율. 차이가 안 나면 신뢰도가 의미 없고, 그러면 전부 검수해야 해서 효과가 없어요(3월 3일).
- 검수 시간. 담당자가 실제로 결과를 확인하는 데 걸리는 시간을 재세요. 이게 진짜 효과 지표예요. 근거 위치가 뜨는지 아닌지에 따라 몇 배 차이 나요.
- 새 문서에서. PoC 막바지에 처음 보는 문서 몇 장을 넣어 보세요. 그동안 고친 게 "그 문서들만 외운" 건지 "일반적으로 좋아진" 건지 알 수 있어요.
끝낼 때 확인할 것
- 성공 기준을 달성했나요? 숫자로요.
- 달성 못 했다면 원인이 뭔지 알게 됐나요? 그것도 PoC의 성과예요. "지금 기술로는 이 양식은 안 된다"는 결론은 실패가 아니에요.
- 도입하면 운영은 어떻게 되나요? 모델 업데이트, 새 양식 추가, 성능 저하 감지(ML Ops 얘기는 9월에 할게요).
- 비용은요? 폐쇄망이면 GPU, API면 토큰(4월 21일). PoC에서 쓴 양으로 월 비용을 추정할 수 있어야 해요.
저희가 PoC를 거절하는 경우
솔직히 쓸게요. 이런 경우엔 저희가 먼저 "PoC 말고 다른 걸 먼저 하자"고 해요.
- 평가 문서를 못 주시는 경우(보안 때문에 샘플도 안 된다면 저희가 가서 폐쇄망 안에서 하는 방법이 있어요. 그것도 안 되면 PoC 자체가 안 돼요).
- 성공 기준을 "일단 해 보고"로 두시는 경우.
- 도입 후 쓸 사람이 안 정해진 경우.
이런 PoC는 양쪽 다 시간만 써요.
체크리스트로 정리
시작 전
- 성공 기준이 숫자로 있다
- 평가 문서가 봉인돼 있다
- 문서 종류 1개, 필드 10개 이내
- 도입 후 사용자·검수자·연계 시스템이 정해져 있다
진행 중
- 틀린 것의 분포를 본다
- 신뢰도가 믿을 만한지 확인한다
- 검수 시간을 잰다
- 처음 보는 문서로 확인한다
종료 시
- 기준 달성 여부가 숫자로 있다
- 미달성이면 원인이 정리돼 있다
- 운영 계획과 비용 추정이 있다
다음 주는 다시 기술로 돌아가서, OCR이 글자 인식에서 문서 이해로 어떻게 바뀌어 왔는지 세대별로 정리할게요.