의미 있는 AI POC 결과물 얻기

POC / Prototype / Pilot 비교

이 글은 원래 작성 계획에 없었습니다.

AX 전환 사업의 제안 전략을 이야기하던 중에, 현재 공공부문 AX 사업의 RFP가 기존 ISP/ISMP 형식과 내용을 그대로 따르고 있다는 점과 기존 정보화전략계획의 요구사항에 "AX"라는 단어만 얹어서 발주하고 있는 현황과 함께 그에 따라 제안서를 어떻게 작성해야 할까를 고민하던 중 POC를 급하게 주제로 잡았습니다.

논의하고 싶은 이야기는 AX 사업의 결과물로 POC를 요구하는 경우가 대부분인데, 이것이 과연 AX 전환 사업에 맞는 방향이고 결과물인가에 대한 것입니다.

컨설팅은 컨설턴트가 수행하고, POC는 AI 전문회사 엔지니어가 별도로 수행하는 사례를 목격 했었습니다. 하나의 사업 안에 사실상 두 개의 조직이 각각 독립적으로 프로젝트를 수행하고, 그 두 작업 사이의 유기적 연결이 약한 채로 사업이 종료되는 것이 현재 공공 AX사업의 사실상의 현주소 입니다.

이 문제를 제대로 짚으려면, POC가 무엇인지부터 정리해야겠다는 생각을 했습니다. 저도 개념적으로만 알고 있지, POC가 단계적 AX 전환 이행에 어떤 의미와 목적을 갖고 있는지 깊이 생각해 보지 못했습니다.

POC, Prototype, Pilot — 세가지 중 당신이 요구하고 있는 것은 무엇인가

실무에서 이 세 가지 용어는 자주 혼용되어 사용되고 일반적으로는 POC로 통칭되고 있습니다. 그러나 각각이 검증하려는 것은 본질적으로 다르고 결과물도 다를 수 밖에 없습니다.

첫번째, POC(Proof of Concept)는 "이것이 기술적으로 가능한가"를 확인하는 것입니다. 특정 AI 기술이 해당 업무에 적용될 수 있는지, 기술적 실현 가능성을 판단하는 것이 목적입니다. 결과물은 "된다" 또는 "안 된다"에 대한 판단 근거가 됩니다.

두번째, Prototype은 "이것이 어떻게 작동하는가"를 보여주는 것입니다 사용자 경험과 기능 흐름을 시각화한 동작 모형이 결과물입니다. 기술이 가능한지는 이미 전제된 상태에서, 실제 서비스가 어떤 형태가 될지를 미리 보여주는 데 초점을 둡니다.

마지막으로 Pilot은 "이것이 현장에서 통하는가"를 확인하는 것입니다. 실제 업무 환경에서 제한된 범위로 운영하면서, 기술의 작동뿐 아니라 업무 프로세스의 변화, 사용자의 수용도, 운영상의 문제점까지 함께 검증하게 됩니다. 결과물은 운영 데이터와 개선 과제입니다.

현재 공공부문 AX 사업의 RFP가 "POC"라고 부르고 있는 것은, 실제로는 이 중 어디에 해당할까요? 필자가 경험한 사례들은 대부분 Prototype에 가까웠습니다. 샘플 데이터를 기반으로 AI가 작동하는 모습을 시연하는 형태. 기술적 실현 가능성을 검증하는 POC도 아니고, 현장에서의 실효성을 확인하는 Pilot도 아닌, 그 사이 어딘가에 위치한 결과물이었습니다.

AX 사업에서 POC가 꼭 필요할까

앞서 필자가 목도한 현장의 상황을 고려한다면 이 질문을 먼저 던져야 한다 생각합니다. POC의 본래 목적은 기술적 실현 가능성의 검증입니다. 그렇다면 현재 공공부문 AX 사업에서 다루는 AI 적용 영역 — 문서 분류, 요약, 민원 응대, 데이터 분석 — 에서 기술적 실현 가능성은 여전히 불확실할까요?

제 생각으론 그렇지 않은 것 같습니다. 이미 시중에 작동하는 서비스가 충분히 존재하고, 기술적으로 "가능한가"라는 질문에 대한 답은 이미 나와 있는 영역이 대부분입니다.

진짜 POC가 필요한 경우는 제한적이라 생각합니다. 기관 고유의 특수한 문서 체계를 AI가 처리할 수 있는지, 기관만이 보유한 비정형 데이터를 학습에 활용할 수 있는지와 같이, 해당 기관의 특수한 맥락에서 기술적 불확실성이 존재할 때에 한해서 POC가 필요한 경우라 생각됩니다. 그리고 이런 불확실성은 AX 전환의 본질적 문제가 아니라 이후 구현 단계의 문제입니다.

그리고 더 중요한 고려사항이 있습니다. 점진적·단계적 AX 이행을 전제한다면, POC의 필요성은 한층 더 줄어든다는 것입니다. 점진적 이행은 "작은 단위로 시도하고, 결과를 확인하면서 확장한다"는 접근인데, 이것 자체가 Pilot의 논리입니다. 컨설팅 사업의 결과물로 기술 시연을 요구하는 것보다, 전환 로드맵에 따라 첫 번째 대상 업무를 선정하고 실제로 운영해보는 것이 점진적 이행의 취지에 훨씬 부합합니다.

그럼에도 기술 검증이 필요하다면 — Pilot이 답이다

만약 발주기관이 사업 결과물에 기술 검증 요소를 반드시 포함하겠다면, 세 가지 중 Pilot이 AX 전환의 성격에 가장 부합합니다.

POC는 기술만 검증하고 업무 맥락은 검토대상이 아닙니다. "AI가 문서를 분류할 수 있는가"에 답하지만, "그래서 담당자의 업무가 실제로 어떻게 바뀌는가"에는 답하지 못합니다. Prototype은 사용자 경험을 보여주지만, 깔끔한 데모 환경에서의 시연이기 때문에 실제 현장의 예외 상황, 데이터 품질 문제, 업무 담당자의 수용도 같은 변수가 드러나지 않습니다.

Pilot만이 "기술이 작동하는가"와 "업무가 실제로 전환되는가"를 동시에 검증할 수 있습니다. AX 전환이 업무 재설계라면, 재설계된 업무가 현장에서 돌아가는지 확인하는 Pilot이 유일하게 의미 있는 검증 방식입니다.

다만 현실적 제약을 무시할 수 없기도 합니다. Pilot은 AI 엔진의 설치, 기관 데이터의 수집과 정제, 학습 또는 파인튜닝, 실제 업무 환경에서의 운영, 모니터링과 피드백이라는 전체 사이클을 필요로 합니다. 3개월에서 1년 남짓한 컨설팅 사업 기간 안에 전환 전략 수립과 Pilot을 병행하는 것은 사실상 컨설팅 사업과 시스템 구축 사업을 동시에 수행하라는 요구라 이해하는 것이 맞습니다. 여기에 공공부문의 보안 환경, 데이터 반출 제한, 망 분리 같은 제약까지 더해지면 사실상 제대로된 Pilot을 수행하기는 불가능에 가깝습니다.

그래서 현장에서는 Pilot 대신 Prototype으로 후퇴한 것이 현실입니다. 그리고 그것을 POC라고 부르고 있습니다. 이름, 목적, 실체가 모두 어긋나 있는 상태에서 사업이 반복되고 있는 것입니다.

사업관리자가 판단해야 할 것

문제의 근원은 "POC를 해야 한다"는 전제를 의심 없이 수용한 데 있습니다. 타 기관의 RFP를 참고하여 제안요청서를 작성하는 관행 속에서, 최초에 어떤 기관이 어떤 맥락에서 POC를 요구했는지는 전달되지 않고 형식만 복제되고 있습니다. "AX 사업이면 POC를 넣는 것"이 관행이 된 것으로 보입니다.

인공지능 기본법과 시행령에서 POC를 정의하거나 요구하는 조항은 없습니다. 공공부문 초거대 AI 도입·활용 가이드라인 2.0에서도 "PoC 등"이라는 병기가 있을 뿐, POC의 개념, 기준, 적절한 결과물 형태에 대한 체계적 안내는 존재하지 않습니다. 그러니깐 근거 없이 관행으로 POC 수행요구가 반복되고 있는 셈입니다.

사업관리자에게 필요한 것은 POC를 넣을 것인가 말 것인가의 이분법이 아니라, 다음과 같은 판단 기준을 하면 어떨까 싶습니다.

첫째, 우리 기관의 AX 사업에서 기술적 실현 가능성이 정말 불확실한 영역이 있는가? 이미 검증된 기술을 적용하는 것이라면 POC는 불필요 합니다.

둘째, 기술 검증이 필요하다면, 검증하려는 것이 정확히 무엇인가? 기술의 작동 가능성(POC)인가, 서비스의 형태(Prototype)인가, 현장에서의 실효성(Pilot)인가? 이 구분 없이 "POC"라고 뭉뚱그려 요구하면, 결과물도 모호해 집니다.

셋째, 컨설팅 사업의 기간과 범위 그리고 예산 안에서 어디까지가 현실적인가? Pilot이 이상적이지만 현실적으로 불가능하다면, 차라리 컨설팅 사업에서는 전환 설계에 집중하고 기술 검증은 별도의 후속 사업으로 분리하는 것이 더 정직한 설계일 수 있습니다.

마지막으로 컨설팅과 기술 검증을 하나의 사업에 넣어야 한다면, 두 작업 사이의 연결 구조를 RFP에 명시하고 있는가? "컨설팅 따로, POC 따로"가 되지 않으려면, 컨설팅의 어떤 산출물이 기술 검증의 입력이 되고, 기술 검증의 결과가 컨설팅의 어떤 결론을 수정하는지가 사전에 설계되어야 합니다.

RFP를 복제하는 것이 아니라, 자기 기관의 상황에 맞게 판단하는 것. 그것이 의미 있는 POC 결과물을 얻어내는 첫 번째 조건입니다.