0. 들어가며
본 글은 당시 진행된 내부 MVP 기반 프로젝트 경험을 바탕으로 작성되었으며, 기술 검토 및 시행착오 중심의 사례 공유 목적입니다.
안녕하세요! KT AX플랫폼본부에서 에이전트 기획을 담당하고 있는 유주원입니다.
여러분은 "당사의 실제 비즈니스 문제를 해결하는 에이전트를 만들어보자"는 제안을 들으면 무엇이 가장 먼저 떠오르시나요? 단순히 편리한 툴을 만드는 것이라 생각할 수 있지만, 이번 프로젝트는 훨씬 더 거대한 전략적 목표에서 출발했습니다.
당시 프로젝트는 실제 운영 현장의 문제를 AI 기반으로 어떻게 지원할 수 있을지 검증해보기 위한 시도에서 출발했습니다.
단순한 예측 모델을 넘어, 현업의 의사결정을 도울 수 있는 형태를 만드는 것이 목표였습니다.
우리는 그 첫 번째 타겟으로 ‘셋톱박스(STB) 재고 관리'를 낙점했습니다. 전국에 흩어진 재고를 관리하며 겪는 End-to-End의 복잡한 문제들이야말로, 우리 에이전트 기술의 완성도를 증명할 가장 완벽한 시험대였기 때문입니다.
[Agent Architecture]
1. 전략적 출발: 왜 'STB 재고 관리'인가?
이번 프로젝트는 당사의 비즈니스 기여와 기술 검증이라는 두 마리 토끼를 잡기 위해 기획되었습니다.
비즈니스 실익 확보: 담당자의 '경험과 감'에 의존하던 수급 계획을 지능화하여, 재고 운영 효율을 높이고 운영 오류를 줄이는 것을 목표로 했습니다.
- 기술 검증: 사내의 복잡한 기반 시스템(ERP, Data Lake 등)을 에이전트와 연결하며 신규 컴포넌트를 도출하고, 기술적 완성도를 한 단계 끌어올리고자 했습니다.
- 실질적 문제 해결의 경험: 고객사들이 동일하게 겪을 수 있는 재고 관리와 수요 예측 문제를 직접 해결함으로써, 대내외에 어필할 수 있는 우리만의 에이전트 확산 사례를 확보하는 것이 핵심이었죠.
하지만 야심 찬 목표와 달리, 실제 마주한 현업의 반응은 생각보다 냉담했습니다. "이미 엑셀도 있고, ERP도 있는데, 예측 수치를 믿고 발주 버튼을 누르지는 않아요. 결국 제 '감'을 믿죠." 기술적 정확도가 문제가 아니라, 사람의 의사결정을 어떻게 도울 것인가에 대한 본질적인 고민이 필요한 시점이었습니다.
[셋탑박스 Agent 실행화면]
2. 가시밭길이었던 여정: "모델링보다 어려운 사람의 언어 찾기"
프로젝트를 진행하면서 가장 힘들었던 건 성능 좋은 알고리즘을 짜는 게 아니었습니다. "왜 이 수치가 나왔는지 모르겠어요"라는 현업의 한마디를 넘어서는 것이었죠.
첫 번째 난관: 데이터에 담기지 않는 '맥락'
모델은 과거 데이터를 기반으로 아주 합리적인 값을 내놓습니다. 하지만 갑작스러운 마케팅 프로모션, 명절, 내부 정책 변경 같은 '이벤트'들은 숫자로는 남아있어도 그 의미까지 모델이 이해하긴 어려웠죠.
두 번째 난관: 보안과 연결의 벽
이론적으로는 사내 시스템과의 연동 과정에서는 메일 발송까지 척척 해낼 줄 알았습니다. 하지만 실제로는 사내 보안 정책과 권한 관리(Access Control) 때문에 우리가 직접 통로를 만들어야 했습니다. "에이전트는 쉽게 연결되지 않는다"는 뼈아픈 교훈을 얻은 순간이었습니다.
3. 나만의 노하우: 결론 대신 '생각의 과정'을 공유하기
우리는 전략을 바꿨습니다. AI가 대신 결정해주는 '자동화'가 아니라, 사람의 판단을 검증해주는 '대화 상대'를 만들기로 한 것이죠.
"What-If" 시뮬레이션 도입
"만약 다음 달 프로모션으로 수요를 20% 높인다면, 재고는 언제 바닥날까?" 담당자가 궁금해하는 시나리오를 즉시 시뮬레이션해 주는 기능을 넣었습니다.
설명 가능한 AI (XAI)
에이전트가 결과를 내놓을 때 반드시 이유를 함께 말하도록 기획했습니다. 아쉽게도 이 부분은 이번 Phase 1에는 반영되지 못했고, 당시에는 적용되지 못했지만, 설명 가능한 형태의 응답 구조에 대한 고민은 이후에도 계속 이어졌습니다.
"이번 주 예측치가 높게 잡힌 이유는 최근 3주간 판매량이 급증했고, 물류센터의 리드타임이 평소보다 2일 길어졌기 때문입니다."
이렇게 '생각의 근거'를 보여주면, 답변자가 아니라 함께 고민하는 '파트너'로 인식하여 에이전트가 의사결정의 한 부분으로 자리 할 수 있을거라고 생각합니다.
4. 트러블 슈팅: "엉뚱한 예측치에 대처하는 법"
개발 중 특정 지역의 수요가 비상식적으로 튀는 문제가 발생했을 때, 예전 같으면 코드를 다시 뜯어봤을 겁니다. 하지만 이번엔 Feature 중요도(Feature Importance)를 시각화해서 사용자에게 보여주었습니다.
"이 값은 데이터 이상치 때문일 수 있으니, 사용자가 직접 수동으로 조정할 수 있습니다"라는 옵션을 제공했죠. 완벽한 모델을 추구하기보다, 사용자가 개입할 수 있는 여지를 주는 것이 진정한 트러블 슈팅임을 배웠습니다.
5. 프로젝트가 남긴 것: 기술보다 질문이 먼저다
프로젝트 이후 팀 내부에서도 모델 성능 자체보다, 사용자의 의사결정을 얼마나 잘 지원하는지가 더 중요하다는 공감대가 커졌습니다. 대신 "우리가 사용자의 고민을 어떻게 해결하고 있는가?"를 더 많이 묻게 되었죠. LLM을 도입한 진정한 이유는 복잡한 ERP 데이터를 '사람의 언어'로 설명하고, 불확실한 미래 앞에서 우리가 어떤 근거로 결정할지 함께 이야기하는 방법을 만들기 위해서였습니다.
혹시 지금 복잡한 데이터를 다루고 계신가요? 그렇다면 성능 좋은 모델을 고르기 전에 한번 물어보세요.
"이 시스템은 사람의 결정을 정말로 돕고 있는가?"