1. PoC에서 동작했다고 바로 운영할 수 있는 것은 아닙니다
첫 번째 검증은 명확했습니다.
사람이 반복적으로 처리하던 일련의 업무를 Agent가 대신 수행할 수 있는가?
PoC에서는 업무 절차를 시나리오화하고 필요한 데이터와 작업을 연결해 Agent가 실제 업무를 수행할 수 있는지를 확인했습니다.
하지만 실제 동작을 확인하고 나면 관심사는 달라집니다.
업무량이 늘어나도 안정적인지, 여러 사용자가 동시에 실행할 수 있는지, 처리 시간은 현업에서 사용할 수 있는 수준인지 등을 확인해야 합니다.
PoC와 운영 시스템의 목적을 구분해야 하는 이유입니다.
PoC에서는 '가능성'을 확인하고, 본 구축에서는 '안정성과 운영성'을 확보합니다.
따라서 PoC 단계에서 모든 운영 요건을 완성하려 하기보다 실제 업무 적용 가능성을 먼저 확인하고, 이후 예상 사용자와 업무량, 실행 빈도 등을 바탕으로 필요한 인프라와 아키텍처를 구체화하는 것이 현실적입니다.
2. 유통 업무에서는 Agent보다 '연결'이 더 어려울 수도 있습니다
식품·유통 기업의 업무는 하나의 시스템 안에서 끝나지 않는 경우가 많습니다.
상품, 주문, 거래처, 정산 등 서로 다른 업무 시스템이 연결되어 있고 외부 시스템을 함께 사용하는 경우도 있습니다.
AI Agent가 실제 업무를 수행하려면 이 환경 안에서 필요한 데이터를 가져오고 작업 결과를 다시 업무 시스템에 반영할 수 있어야 합니다.
연결 방식도 시스템마다 달라집니다.
API를 이용하는 것이 적합할 수도 있고, 기존 웹 화면을 이용하는 방식이 현실적일 수도 있습니다. 업무 특성에 따라 배치나 이벤트 방식이 필요할 수도 있습니다.
따라서 기업의 Agent 도입에서는 AI 모델의 성능뿐 아니라 기존 업무환경과 어떻게 연결할 것인지를 초기 단계부터 함께 검토해야 합니다.
기존 시스템을 모두 바꾸고 AI를 도입하는 것이 아니라 현재 사용하고 있는 시스템을 최대한 유지하면서 AI가 그 사이에서 일할 수 있도록 만드는 것이 현실적인 과제이기 때문입니다.
3. 모든 Agent를 개발자가 만들어야 할까요?
PoC 이후 실제 확산을 생각하면 자연스럽게 등장하는 질문입니다.
식품·유통 기업에는 상품, 마케팅, 영업, 구매, 물류, 경영지원 등 서로 다른 업무를 담당하는 조직이 존재합니다.
각 조직에서 필요한 Agent가 늘어날 때마다 개발조직이 하나씩 만들어주는 방식으로는 확산 속도에 한계가 생길 수 있습니다.
반면 실제 업무 규칙과 예외 상황을 가장 잘 알고 있는 사람은 현업 담당자입니다.
따라서 비교적 단순한 업무는 교육을 받은 현업 담당자가 직접 구성하고, 복잡한 로직이나 시스템 연계가 필요한 영역은 전문 인력이 지원하는 방식으로 역할을 나눌 수 있습니다.
현업 담당자 — 업무 정의 및 단순 Agent 구성
전문 조직 — 복잡한 로직 및 시스템 연계 지원
플랫폼 — 권한·검증·배포·운영 관리
이렇게 역할을 구분하면 현업의 업무 전문성을 활용하면서도 기업이 요구하는 관리 수준을 유지할 수 있습니다.
4. 모든 업무에 같은 AI 모델이 필요한 것도 아닙니다
유통기업 안에서도 AI가 수행하는 업무는 다양합니다.
문서를 이해하는 업무와 데이터를 분석하는 업무, 정보를 검색하는 업무, 판단과 추론이 필요한 업무의 난이도는 서로 다릅니다.
따라서 모든 Agent에 하나의 AI 모델을 적용하기보다 업무 특성에 따라 적절한 모델을 선택할 수 있는 구조가 필요합니다.
특히 기업 환경에서는 성능만으로 모델을 결정하기 어렵습니다.
성능 / 비용 / 보안 / 응답속도 / 운영환경
을 함께 고려해야 합니다.
이미 기업 내부에서 사용하거나 검토하고 있는 AI 모델이 있다면 이를 활용할 수 있는지도 중요한 조건이 됩니다.
결국 모델 선택의 기준은 **"가장 좋은 모델이 무엇인가"가 아니라 "이 업무에 적합한 모델이 무엇인가"**에 가깝습니다.
5. 첫 번째 Agent를 만들었다면 두 번째는 더 빨라야 합니다
PoC에서는 하나의 Agent가 잘 동작하는 것이 중요합니다.
하지만 기업 차원에서는 그다음이 더 중요합니다.
첫 번째 Agent에서 만든 업무 로직과 도구, 지식, 연계 방식을 다음 Agent에서도 활용할 수 있다면 새로운 업무를 자동화할 때마다 처음부터 다시 개발할 필요가 없습니다.
공통으로 사용하는 Agent를 여러 조직이 공유하고 필요한 부분만 각 조직의 업무에 맞게 구성하는 방식도 가능합니다.
이렇게 되면 PoC 결과가 일회성 데모가 아니라 기업의 AI 자산으로 남습니다.
PoC → Agent·도구 자산화 → 재사용 → 추가 업무 적용 → 조직 확산
플랫폼 기반으로 Agent를 관리해야 하는 이유도 여기에 있습니다.
Agent가 많아질수록 만드는 기능뿐 아니라 공유하고 재사용하고 배포하고 관리하는 기능의 중요성이 커집니다.
6. 첫 번째 과제는 '가장 멋진 업무'보다 '효과를 확인할 수 있는 업무'가 좋습니다
AI Agent를 처음 도입한다면 처음부터 복잡하고 큰 업무를 선택할 필요는 없습니다.
오히려 반복 빈도가 높고 업무 절차가 비교적 명확하며 결과를 측정하기 쉬운 업무가 첫 번째 과제로 적합할 수 있습니다.
작은 범위에서 시작하면 Agent의 기술적 가능성뿐 아니라 현업의 사용 방식, 기존 시스템과의 연결, 운영 절차, 필요한 교육까지 함께 확인할 수 있습니다.
그리고 그 경험을 바탕으로 더 복잡한 업무로 확대할 수 있습니다.
작은 업무에서 검증 → 현업 적용 → 효과 확인 → 운영 방식 정립 → 고난도 업무로 확대
처음부터 전사적인 Agent 체계를 완성하는 것보다 실제 업무 하나에서 작동하는 방식을 먼저 만드는 것이 시행착오를 줄일 수 있습니다.
Field Report
이번 PoC를 통해 확인한 것은 특정 업무 하나의 자동화 가능성만은 아니었습니다.
식품·유통처럼 많은 상품과 거래처, 여러 업무 시스템을 함께 운영하는 환경에서는 Agent가 실제 업무에 들어가기 위해 고려해야 할 조건이 많습니다.
기존 시스템과 어떻게 연결할 것인지, 어느 정도의 업무를 현업이 직접 구성할 것인지, 어떤 모델을 사용할 것인지, 만들어진 Agent를 어떻게 다른 업무에서 재사용할 것인지까지 함께 설계해야 합니다.
그래서 첫 번째 PoC에서 확인해야 할 질문도 조금 달라질 필요가 있습니다.
"이 Agent가 동작하는가?"뿐 아니라
"이 방식으로 두 번째, 세 번째 업무까지 확장할 수 있는가?"
첫 번째 Agent가 하나의 자동화로 끝나지 않고 다음 업무를 더 빠르게 바꿀 수 있는 기반이 될 때, PoC의 경험도 기업의 AI 역량으로 축적될 수 있습니다.
