AI PoC에서 확인해야 할 6가지 기준

기능보다 먼저 의사결정을 적습니다

우리가 PoC 착수 문서에서 가장 먼저 고정하는 문장은 하나입니다. 이 검증이 끝났을 때 누가 어떤 결정을 내려야 하는가. 전사 도입, 특정 부서 확대, 데이터 정비 선행, 보류 가운데 가능한 결정을 미리 적으면 검증 범위가 현실적으로 좁아집니다.

호반건설 협업은 현업 부서가 실제 업무 문제를 정의하고 AI 적용 시나리오와 검증 기준을 설계하며, 스텝하우가 이를 바탕으로 문서 검색과 분석 환경을 구축하는 방식으로 공개돼 있습니다. 계약 조건 검토, 공정 현황 확인, 기술 자료 탐색, 보고서 작성처럼 실제 반복 업무를 검증 대상으로 제시했다는 점이 중요합니다.

이 방식은 기술 공급자가 성공 장면을 혼자 정하는 일을 막습니다. 현업은 업무상 쓸모를 정의하고, 보안과 운영 담당자는 허용 범위를 정의하며, 의사결정자는 다음 투자에 필요한 근거를 정의합니다. PoC 팀은 이 세 기준이 겹치는 범위만 구현해야 합니다.

깨끗한 샘플이 아니라 실제 난도를 넣습니다

실제 업무 문서는 제목 규칙이 다르고, 같은 용어가 부서마다 다르게 쓰이며, 스캔본과 표가 섞이고, 개정 전 문서가 남아 있습니다. PoC 데이터에서 이런 문제를 지우면 모델이 아니라 정리된 샘플의 품질을 검증하게 됩니다. 성공률을 높이기 위해 난도를 제거하는 대신, 실패가 어디서 생기는지 분류할 수 있도록 대표 표본을 구성해야 합니다.

테크로스 실증은 설계 문서, 품질 시험 보고서, 공정 기록, 유지보수 이력 등 5만 건 이상의 제조 데이터를 적용했습니다. 설계 문서, FAT 보고서, 선급 인증서, BOM처럼 형식과 업무 맥락이 다른 자료를 통합 인덱싱하고 유사 프로젝트 검색, 품질 이슈 분석, 규제 대응 자료 탐색을 검증했습니다.

대표 데이터는 전체 데이터를 무작정 많이 넣는 것과 다릅니다. 자주 쓰는 문서, 판단이 어려운 문서, 최신성과 권한이 중요한 문서, 실패하면 영향이 큰 문서를 나눠 포함해야 합니다. 그래야 오류가 검색 누락인지, 문서 파싱인지, 권한인지, 질문 설계인지 구분됩니다.

정답률 하나로 평가하지 않습니다

기업 업무에서 좋은 답은 문장만 맞는 답이 아닙니다. 근거를 찾을 수 있어야 하고, 사용자가 다음 행동을 할 수 있어야 하며, 틀렸을 때 문제를 추적할 수 있어야 합니다. 따라서 평가는 답변 품질, 업무 완결성, 운영 가능성의 세 층으로 나누는 편이 안전합니다.

탈린시 실증은 법령 정보, 공공 집회 정보, 문서 관리의 세 행정 시스템을 연동하고 에스토니아어와 영어 질문에서 출처를 확인하는 제한된 환경으로 설계됐습니다. 검증용 자료와 지정된 내부 사용자를 대상으로 범위를 제한한 점도 중요한 조건입니다.

이 사례처럼 검증 항목은 답이 자연스러운가에서 끝나지 않아야 합니다. 올바른 시스템과 문서를 찾았는가, 인용한 부분이 답을 실제로 뒷받침하는가, 권한 밖 정보가 섞이지 않는가, 사용자가 원문을 보고 판단을 이어갈 수 있는가를 따로 기록해야 합니다.

성공 사례만큼 실패 질문을 보존합니다

데모에서는 가장 잘 되는 질문을 골라 보여주기 쉽습니다. 운영에서는 사용자가 표현을 바꾸고, 한 질문에 여러 조건을 섞고, 존재하지 않는 정보를 요구합니다. 이때 실패 질문을 지우지 않고 유형별로 보존해야 개선 우선순위를 정할 수 있습니다.

실패 기록에는 질문과 답변만 남기지 않습니다. 기대한 근거, 실제로 검색된 근거, 실패가 발견된 업무 단계, 사용자가 취한 우회 행동을 함께 적습니다. 같은 현상이 반복되면 데이터 정비, 검색 전략, 안내 문구, 사람 확인 절차 가운데 어디를 고쳐야 하는지 판단할 수 있습니다.

모든 실패를 모델 변경으로 해결하려는 태도도 피해야 합니다. 최신 문서가 구분되지 않거나 접근 권한이 잘못 설정됐거나 업무 용어가 합의되지 않은 문제는 모델보다 지식 운영의 문제입니다. PoC는 이런 선행 조건을 드러내는 과정이기도 합니다.

종료할 때 운영 인수물을 남깁니다

PoC가 끝난 뒤 공급사만 시스템을 이해한다면 확대가 시작될수록 위험이 커집니다. 어떤 데이터가 연결돼 있는지, 변경 사항은 어떻게 반영되는지, 실패는 누가 검토하는지, 사용자 피드백은 어디에 모이는지 문서로 남겨야 합니다.

테크로스 프로젝트에서는 제조 데이터 검증과 함께 생산 및 연구 인력을 대상으로 AI와 Agentic RAG 교육을 운영했고, 실제 제조 데이터와 ISO 매뉴얼, 업무 프로세스 자료를 활용한 PBL 방식이 병행됐습니다. 기술 검증과 현업 학습을 분리하지 않은 구성입니다.

운영 인수물은 거대한 최종 보고서일 필요가 없습니다. 연결 데이터 목록, 대표 질문 세트, 실패 유형, 권한 원칙, 갱신 절차, 담당자와 검토 주기처럼 다음 팀이 바로 사용할 수 있는 짧은 문서가 더 중요합니다.

확대와 보완과 중단을 같은 무게로 둡니다

PoC의 목적을 도입 승인으로 미리 정하면 불리한 근거가 사라집니다. 결과는 확대, 조건부 보완, 중단 중 하나여야 하며 어느 결론도 검증의 실패로 취급하지 않아야 합니다. 중단이 필요한 과제를 일찍 발견하는 것도 비용을 줄이는 유효한 결과입니다.

확대는 대표 업무에서 가치와 운영 조건을 모두 확인했을 때 선택합니다. 보완은 가치가 보이지만 데이터 정비나 권한 설계가 선행돼야 할 때 선택합니다. 중단은 사용 빈도가 낮거나 오류 영향이 크고 사람이 확인하는 기존 흐름보다 나아질 근거가 부족할 때 선택합니다.