1. 문서 OCR의 목표는 '읽기'가 아니라 '업무 데이터화'다
첫 번째 PoC 후보는 입점업체가 제출하는 각종 문서를 처리하는 업무였습니다.
사업자등록증, 통장사본, 법인인감증명서와 같은 문서를 AI가 판독하고 필요한 정보를 추출해 DB에 적재하는 방식입니다.
흔히 이런 과제를 OCR 도입 프로젝트로 생각하기 쉽습니다.
하지만 현업 관점에서 보면 OCR은 전체 업무의 한 단계일 뿐입니다.
문서 입력 → 문서 판독 → 필요 정보 추출 → 데이터 구조화 → 검증 → DB 적재
까지 연결되어야 실제 업무가 줄어듭니다.
사업자등록증에서 글자를 정확하게 읽었다고 업무가 끝나는 것이 아닙니다. 어떤 값이 사업자등록번호인지, 상호인지, 대표자명인지 구분하고 기업이 사용하는 데이터 구조에 맞게 변환해야 합니다.
필요하다면 여러 문서에 존재하는 정보를 비교하고 검증하는 과정도 추가될 수 있습니다.
따라서 기업의 문서 AI를 평가할 때는 "OCR 정확도가 몇 %인가?"뿐 아니라 **"읽은 정보를 실제 업무 데이터로 얼마나 안정적으로 전환할 수 있는가?"**를 함께 봐야 합니다.
2. 상품코드 생성은 OCR보다 '추론'의 문제에 가깝다
두 번째 과제는 상품 및 행사 코드 생성이었습니다.
기업의 상품코드는 단순한 일련번호가 아니라 상품의 특성과 기업 내부의 분류 기준을 반영하는 경우가 많습니다.
따라서 AI가 상품 정보를 분석해 코드를 생성하려면 두 가지 능력이 필요합니다.
먼저 기존 기준에 따라 상품을 **분류(Classification)**해야 합니다.
그리고 명시적인 정보만으로 결정하기 어려운 부분은 상품의 속성과 맥락을 바탕으로 **추론(Reasoning)**해야 합니다.
즉,
상품정보 → 정보 해석 → 기준에 따른 분류 → 필요한 속성 추론 → 코드 생성
이라는 과정입니다.
이런 업무는 생성형 AI가 기업의 기존 업무 규칙과 결합될 때 의미가 있습니다.
AI가 임의로 코드를 만드는 것이 아니라 기업이 정의한 분류체계와 업무 기준 안에서 판단하도록 설계하는 것이 핵심입니다.
이 관점에서 상품코드 생성은 단순 생성형 AI 기능이라기보다 기업의 업무 규칙과 AI 추론을 결합하는 Agent 과제에 가깝습니다.
3. 기업 AI라고 해서 반드시 파인튜닝이 필요한 것은 아니다
이번 논의에서는 모델 파인튜닝과 도메인 특화 sLLM 구축 가능성도 다뤄졌습니다.
기업 내부 업무를 AI에 적용한다고 하면 흔히 "우리 회사 데이터를 학습한 전용 모델이 필요하지 않을까?"라는 질문부터 나옵니다.
하지만 실제 환경에서는 모델 학습을 위한 GPU와 메모리, 데이터셋 구축, 학습·평가 환경, 지속적인 모델 관리까지 고려해야 합니다.
특히 제한된 인프라 환경에서는 모델을 직접 학습하는 것보다 검증된 오픈소스 모델을 활용하고 기업의 데이터와 업무 규칙을 Agent 단계에서 결합하는 방식이 더 현실적일 수 있습니다.
이번 논의에서도 제한된 리소스를 고려해 별도의 모델 파인튜닝보다는 오픈소스 모델 활용을 우선 검토하는 방향이 제시됐습니다.
중요한 것은 '우리만의 모델을 가지고 있는가'가 아니라 **'우리 업무를 얼마나 정확하게 수행할 수 있는가'**입니다.
Enterprise AI에서는 모델 자체의 소유보다 모델과 데이터, 업무 규칙, 시스템을 어떻게 조합하는지가 더 중요한 경우가 많습니다.
4. Agent 하나만 만들면 되는가, 플랫폼이 필요한가
PoC 단계에서 자주 나오는 질문이 있습니다.
"필요한 Agent만 하나 만들어 사용하면 안 될까?"
하나의 업무만 보면 별도의 Agent를 개발하는 것이 더 간단해 보일 수 있습니다.
하지만 Agent가 실제 업무에 적용되고 개수가 증가하기 시작하면 상황이 달라집니다.
누가 Agent를 만들 수 있는지, 어떤 모델과 데이터에 접근할 수 있는지, 어떤 버전이 현재 운영되고 있는지, 누가 배포를 승인했는지, 실행 과정에서 문제가 발생하지 않았는지 등을 관리해야 하기 때문입니다.
또 하나의 Agent에서 구축한 지식과 도구를 다른 Agent에서도 활용해야 할 수도 있습니다.
따라서 플랫폼의 역할은 단순히 Agent를 만드는 화면을 제공하는 것이 아닙니다.
Agent 생성 → 지식·도구 공유 → 권한 관리 → 검증 → 배포 → 모니터링 → 거버넌스
를 하나의 체계로 연결하는 데 있습니다.
Agent가 한두 개일 때보다 기업 전체로 확산되는 시점에서 플랫폼의 필요성이 커지는 이유입니다.
5. 보안은 AI를 도입한 이후가 아니라 아키텍처 단계에서 결정된다
기업 내부 문서를 다루는 AI에서는 보안도 중요한 논의 대상입니다.
특히 사업자등록 관련 서류처럼 기업 업무 문서를 처리한다면 어떤 데이터가 어떤 모델로 전달되는지 명확해야 합니다.
퍼블릭 모델을 활용한다면 내부 시스템에서 외부 모델에 접근할 수 있는 네트워크 정책이 필요하고, 어떤 사용자와 Agent가 외부 모델을 사용할 수 있는지도 통제해야 합니다.
반대로 민감한 업무에서는 내부 프라이빗 모델을 사용하는 구조를 검토할 수 있습니다.
여기에 개인정보 탐지·보호, 가드레일, 사용자 권한과 리소스 제어 같은 플랫폼 차원의 통제가 결합됩니다.
결국 Enterprise AI의 보안은 단순히 퍼블릭 LLM인가, 프라이빗 LLM인가를 선택하는 문제가 아닙니다.
Data → Model → Agent → User → System
전체 흐름에서 어떤 정보가 이동하고 누가 무엇을 실행할 수 있는지를 통제하는 아키텍처의 문제입니다.
6. 현업이 직접 Agent를 만들 수 있을까
H사에서도 비개발자가 직접 Agent를 만들 수 있는지에 대한 질문이 나왔습니다.
Enterprise AI가 확산되면 모든 Agent를 개발조직이 만들어주는 방식은 한계가 생길 수밖에 없습니다.
실제 업무를 가장 잘 이해하는 사람은 현업 담당자이기 때문입니다.
플래티어가 진행하고 있는 금융권 프로젝트에서도 부서별 담당자를 지정하고 교육을 통해 현업이 필요한 Agent를 직접 구성하는 방식을 적용하고 있습니다.
다만 이것이 모든 직원에게 무제한으로 Agent 개발 권한을 제공한다는 의미는 아닙니다.
현실적인 접근은
플랫폼 제공 → 담당자 지정 → 교육 → 현업 Agent 제작 → 검증·승인 → 배포
와 같은 구조입니다.
즉, 현업의 업무 전문성과 IT·거버넌스 조직의 통제 체계를 함께 가져가는 것이 중요합니다.
7. 좋은 PoC는 본사업에서 버려지지 않아야 한다
이번 논의에서 중요하게 본 또 하나의 부분은 PoC 이후였습니다.
PoC를 위해 만든 Agent가 본사업에서 다시 개발되어야 한다면 검증 과정에서 만든 자산과 노하우 상당 부분이 사라집니다.
따라서 초기 PoC 단계부터 본사업 전환 가능성을 고려하는 것이 좋습니다.
이번 논의에서도 PoC에서 개발한 Agent를 향후 XGEN 도입 시 플랫폼에 탑재해 이어서 활용하는 방안을 검토했습니다.
이는 PoC의 목적을 단순한 기술 시연과 다르게 만듭니다.
PoC → 검증 → 보완 → 플랫폼 탑재 → 운영 → 확산
으로 연결할 수 있기 때문입니다.
PoC에서 중요한 것은 화려한 데모보다 **"이 결과를 실제 운영환경으로 가져갈 수 있는가?"**라는 질문입니다.
이번 현장에서 확인한 네 가지 인사이트
이번 논의를 통해 유통 기업의 AI Agent 도입에서 특히 중요하게 봐야 할 네 가지 지점을 확인했습니다.
① OCR보다 End-to-End 업무를 봐야 합니다.
문서를 읽는 것 자체보다 판독한 정보를 구조화하고 검증해 기존 시스템에 반영하는 과정까지 연결해야 실제 업무 자동화가 됩니다.
② 모든 기업에 전용 모델이 필요한 것은 아닙니다.
인프라와 운영 여건에 따라 검증된 모델을 활용하고 기업의 데이터·규칙·도구를 Agent와 결합하는 것이 더 현실적인 선택일 수 있습니다.
③ Agent의 수가 늘어나면 플랫폼이 필요해집니다.
Agent 생성뿐 아니라 권한, 공유, 배포, 모니터링과 거버넌스까지 고려해야 기업 전체로 확장할 수 있습니다.
④ PoC 단계부터 운영 전환을 고려해야 합니다.
PoC를 일회성 데모로 끝내기보다 검증된 Agent와 업무 설계를 본사업에서도 이어갈 수 있도록 처음부터 구조를 설계하는 것이 중요합니다.
Field Report
이번 현장에서 나온 질문들은 결국 하나의 방향을 가리키고 있었습니다.
기업은 이제 "AI가 무엇을 할 수 있는가"보다 **"우리 업무에 어떻게 넣을 것인가"**를 묻기 시작했습니다.
문서를 읽는 OCR, 상품을 분류하는 AI, 정보를 추론하는 LLM 각각의 기술도 중요합니다.
하지만 실제 현업에서는 이 기술들이 서로 떨어져 동작하지 않습니다.
문서를 읽고, 필요한 정보를 추출하고, 기업의 기준에 따라 판단하고, 결과를 기존 시스템에 반영하고, 그 모든 과정을 권한과 거버넌스 아래에서 관리해야 하나의 업무가 완성됩니다.
그래서 Enterprise AI의 다음 경쟁력은 더 좋은 모델 하나를 선택하는 것보다,
AI가 기업의 실제 업무 프로세스 안에서 안전하게 판단하고 실행할 수 있는 구조를 만드는 것에 있을 수 있습니다.
