AI DELIVERY · 2026.08.25

AI PoC는 됐는데, 왜 현업에서 멈출까?

회의실 데모에서는 잘 돌아갔습니다. 파일 하나를 넣으면 AI가 요약하고, 버튼을 누르면 답도 잘 나옵니다. 그런데 막상 실제 업무에 붙이려 하면 ERP 권한, 엑셀 버전, API 제한, 개인정보, 응답 지연, 실패 처리 같은 문제가 한꺼번에 등장합니다. PoC의 성공과 운영의 성공은 다른 문제이기 때문입니다.

PoC가 잘 됐다는 말의 함정

PoC에서는 보통 범위를 작게 잡습니다. 테스트용 데이터 몇 개를 고르고, 담당자가 직접 파일을 넣고, 문제가 생기면 개발자가 옆에서 바로 고칩니다. 이 환경에서는 AI 모델의 성능이 좋아 보이기 쉽습니다.

하지만 실제 운영에서는 하루 수백·수천 건의 데이터가 들어오고, 사용자가 여러 명이며, 데이터 형식도 자주 바뀝니다. 누군가는 권한이 없고, 외부 API가 느려지고, 모델 응답이 예상과 다를 때도 있습니다. 이때부터 프로젝트의 중심은 AI 모델보다 시스템 엔지니어링과 업무 설계로 이동합니다.

현업에서 멈추는 7가지 이유

1. 데이터가 자동으로 들어오지 않으면 자동화가 아닙니다

PoC에서 가장 자주 빠지는 부분입니다. 예를 들어 매출 분석 AI를 만들었는데 매일 직원이 ERP에서 CSV를 내려받아 업로드해야 한다면, AI는 붙었지만 업무는 완전히 자동화되지 않았습니다.

운영 단계에서는 데이터의 출처와 갱신 주기를 먼저 정의해야 합니다. ERP API, DB 조회, SFTP, Google Sheets, 쇼핑몰 API처럼 데이터를 가져오는 방법을 결정하고, 실패했을 때 재시도와 알림까지 설계해야 합니다.

2. 권한 설계가 없으면 실제 사내 데이터에 연결하기 어렵습니다

AI가 고객·매출·계약서·인사 문서를 볼 수 있다면 누구에게 무엇까지 보여줄지 기준이 필요합니다. 영업팀 직원이 다른 팀의 계약 정보를 보거나, 외부 모델에 민감정보가 그대로 전달되면 문제가 됩니다.

따라서 운영화에서는 사용자 인증, 역할별 권한, 데이터 마스킹, 저장 여부, 외부 API 전송 범위를 함께 결정해야 합니다. 이 작업은 AI 프롬프트보다 시스템 아키텍처에 가깝습니다.

3. ‘실패하면 어떻게 할지’를 먼저 정해야 합니다

업무 시스템은 항상 정상적으로만 동작하지 않습니다. API가 끊기고, 컬럼 이름이 바뀌고, 파일이 비어 있고, AI가 엉뚱한 형식으로 답할 수 있습니다.

예를 들어 주문 분류 AI라면 신뢰도가 낮은 결과는 자동 처리하지 않고 담당자 검토함으로 보내는 식의 사람 개입 구간을 두는 것이 현실적입니다. AI에게 모든 판단을 맡기는 것보다 실패 경로를 설계하는 것이 중요합니다.

4. 로그가 없으면 문제가 생겼을 때 원인을 찾을 수 없습니다

“어제는 맞았는데 오늘 왜 틀렸지?”라는 질문에 답하려면 입력 데이터, 사용 모델, 프롬프트 버전, 응답, 처리 시간, 오류 기록이 남아 있어야 합니다. 운영 시스템에서는 모델 응답 자체보다 이 추적성이 중요할 때가 많습니다.

5. AI 품질은 평균 정확도 하나로 판단하면 안 됩니다

실제 업무에서는 특정 종류의 실수가 훨씬 비쌀 수 있습니다. 고객 문의 초안의 문장 하나가 어색한 것과, 환불 대상 고객을 잘못 분류하는 것은 같은 오류가 아닙니다.

따라서 업무별로 허용 가능한 오류를 정해야 합니다. 자동 실행 가능한 영역, 사람이 검토해야 하는 영역, AI를 사용하면 안 되는 영역을 나누면 운영 안정성이 훨씬 높아집니다.

6. 모델 비용보다 전체 처리 비용을 봐야 합니다

LLM 가격만 비교하면 실제 비용 구조를 놓치기 쉽습니다. 데이터 수집, 벡터 검색, DB, 로그 저장, 모니터링, 재시도, 외부 API, 개발·유지보수 비용이 함께 들어갑니다.

그리고 모든 작업에 최고 성능 모델을 쓸 필요도 없습니다. 단순 분류·요약은 작은 모델로 처리하고, 복잡한 판단만 고성능 모델로 보내는 구조가 비용과 속도 면에서 유리할 수 있습니다.

7. ROI는 PoC가 끝난 뒤가 아니라 시작 전에 정해야 합니다

“AI를 도입했다” 자체는 성과가 아닙니다. 프로젝트 시작 전에 성공 기준을 정해두어야 합니다.

예를 들어 월 80시간 걸리던 보고 업무를 20시간으로 줄이는 것이 목표라면, AI 정확도뿐 아니라 실제로 60시간이 줄었는지를 봐야 합니다.

PoC에서 운영으로 넘어가는 현실적인 4단계

1단계: 업무 하나만 고릅니다

회사의 모든 데이터를 연결하려 하지 말고 반복 빈도가 높고 비용이 명확한 업무 하나를 선택합니다.

2단계: 운영 조건을 PoC에 포함합니다

실제 데이터 소스, 실제 사용자 권한, 실제 호출량의 일부를 테스트합니다. “데모 환경에서 된다”보다 “우리 환경에서 된다”를 확인합니다.

3단계: 사람 검토 구간을 둡니다

초기에는 AI 결과를 바로 실행하지 말고 담당자 승인 후 처리하도록 설계합니다. 오류 패턴이 쌓이면 자동화 범위를 점차 넓힐 수 있습니다.

4단계: 2~4주 운영 후 ROI를 비교합니다

도입 전과 후의 처리 시간, 오류, 비용, 처리량을 비교합니다. 효과가 확인된 업무부터 다음 프로세스로 확장하면 됩니다.

이 지점에서 FDE가 필요한 이유

PoC까지는 AI 개발자가 혼자 만들 수 있습니다. 하지만 운영 단계에서는 현업 요구, 데이터 엔지니어링, API, 보안, 백엔드, 모델 품질, 업무 프로세스를 동시에 봐야 합니다.

FDE(Forward Deployed Engineer)는 이런 경계에서 일합니다. 대표나 운영팀이 말하는 “매일 경쟁사 변화를 자동으로 알고 싶다”를 데이터 수집 구조, DB, AI 분석, 알림, 대시보드까지 실제 시스템으로 바꾸는 역할입니다.

특히 내부 개발팀이 AI·데이터 통합 경험이 부족하거나, 외주 개발과 현업 사이에서 요구사항이 계속 어긋나는 회사라면 FDE 성격의 역할이 프로젝트 성공률을 높이는 데 도움이 됩니다.

운영 전 체크리스트

• 데이터가 사람 손을 거치지 않고 자동으로 들어오는가?
• 누가 어떤 데이터에 접근할 수 있는지 정의했는가?
• API·AI·데이터 처리 실패 시 재시도와 알림이 있는가?
• 입력·출력·오류 로그를 추적할 수 있는가?
• AI가 틀렸을 때 사람이 검토하는 경로가 있는가?
• 월간 호출량과 전체 운영 비용을 계산했는가?
• 도입 전후를 비교할 ROI 지표가 정의되어 있는가?

이 질문에 대부분 답할 수 있다면 PoC는 데모를 넘어 실제 업무 시스템에 가까워진 상태입니다.

FAQ

PoC 기간은 얼마나 잡아야 하나요?

업무 복잡도에 따라 다르지만 기간 자체보다 검증 범위가 중요합니다. 단순 데모가 아니라 실제 데이터 연결과 실제 사용자 테스트까지 포함해야 운영 전환 가능성을 판단할 수 있습니다.

AI 정확도가 몇 %면 운영할 수 있나요?

업무마다 다릅니다. 틀려도 쉽게 사람이 수정할 수 있는 초안 업무와, 자동 환불·가격 변경처럼 실수 비용이 큰 업무는 기준이 달라야 합니다. 정확도 숫자보다 오류가 발생했을 때의 위험을 함께 평가해야 합니다.

기존 ERP를 바꿔야 AI를 붙일 수 있나요?

대부분은 기존 시스템을 전면 교체하기보다 API, DB, 파일 연동 계층을 만들어 필요한 데이터만 연결하는 방식으로 시작할 수 있습니다. 기존 시스템의 연동 가능 여부를 먼저 확인하는 것이 좋습니다.

Voxen은 PoC 이후의 ‘운영화’를 만듭니다

Voxen은 AI 데모를 만드는 데서 끝내지 않고 실제 데이터와 업무 시스템에 연결하는 과정을 함께 설계합니다. 데이터 수집·데이터 엔지니어링·AI 자동화·API·대시보드·맞춤 시스템 구축을 연결해, 현업에서 매일 사용할 수 있는 구조로 만드는 일을 합니다.