생활가전 B2C · 사례
정산 규정 문서 23종을 업무 CSV 18종에 적용해, 규정을 어긴 거래와 환수액을 뽑는다
이걸로 되는 일업무 CSV 18종과 정산 규정 문서 23종을 한 워크스페이스에 넣고, 주문과 출고를 가로질러 대사해 미출고 거래를 찾고 규정을 데이터에 적용해 위반 거래와 환수액을 산출한다.
월말 정산일. 정산 담당자의 모니터에는 ERP 화면 하나, 방금 내려받은 엑셀 시트 두 개, 그리고 PDF로 열어둔 정산 규정 문서가 나란히 떠 있다. 주문 테이블에서 거래를 보고, 출고 테이블을 따로 열어 대조하고, 규정의 몇 페이지 몇 항이 이 거래에 걸리는지는 결국 머릿속에서 끄집어낸다.
이 글은 생활가전을 만들어 소비자에게 직접 파는 어느 B2C 기업의 영업·CS·구매·물류·재무 업무를 가정한 이야기다. 다만 먼저 밝혀둔다. 여기 나오는 회사와 숫자는 실제 고객 사례가 아니라, 우리가 내부 검증을 위해 설계한 가상 데이터 기반의 예시이자 가설 시나리오다. '이런 일이라면 Consilience가 이렇게 풀 수 있지 않을까'를 가짜 데이터로 실험해 본 기록이라고 보면 된다.
그래도 현장의 고충만큼은 가상이 아니다. 데이터는 여러 테이블에 흩어져 있고, 규정은 데이터와 동떨어진 별도 문서로 존재하며, 둘을 잇는 건 늘 사람의 기억이다. 그 틈에서 무언가는 누락되고, 어떤 규정은 잘못 적용된다.
CSV 18종은 ERP에, 규정 23종은 PDF에
가정해 본 이 회사의 하루는 세 가지 도구로 쪼개져 있다. 데이터는 ERP에서 보고, 가공은 엑셀에서 하고, 규정은 머릿속에서 적용한다. 참고로 ERP는 기업의 주문·재고·회계를 한곳에서 관리하는 기간 시스템이다.
- 업무 데이터 CSV 18종. 주문·재고·출고·정산 같은 표 형태의 데이터 파일이다
- 정산 규정과 관련 법령 같은 문서 23종. 사람이 PDF로 열어 읽는 문서다
- ERP 화면. 영업은 주문 현황을, CS는 반품과 클레임을, 구매는 입고를, 물류는 출고를, 재무는 정산을 들여다본다. 저마다 자기 화면을 보지만 그 화면들은 서로 알아서 연결되지 않는다
- 엑셀 시트. ERP에서 내려받아 출고·반품 데이터와 손으로 맞춰 보는 중간 산물이다
- 규정의 어느 조항이 어느 거래에 걸리는지에 대한 담당자의 기억. 이 연결은 사람의 머릿속에만 있다
두 데이터를 눈으로 대조하고, 규정은 한 줄씩 떠올린다
정산 한 건을 정리하는 절차는 이렇다. ERP에서 주문 데이터를 조회하고, 그걸 엑셀로 내려받아 출고·반품 데이터와 손으로 맞춰 보고, 마지막으로 정산 규정 문서를 열어 '이 거래에 이 조항이 맞나'를 직접 판단한다. 데이터와 데이터를 잇는 일도, 데이터와 문서를 잇는 일도 전부 사람 몫이다.
구멍은 두 군데다. 첫째, 정합성을 자동으로 맞춰 보는 장치가 없다. 주문과 출고가 서로 들어맞는지, 어떤 거래가 정산 규정이 정한 단계를 제대로 거쳤는지 알아서 점검해 주는 도구가 없으니 사람이 두 데이터를 나란히 띄워 눈으로 대조하고 규정을 한 줄씩 떠올려야 한다. 둘째, 질문 하나에 답하려면 주문·재고·출고·정산 테이블을 차례로 열고 키를 맞춰 가며 이어 붙여야 한다. 이 과정에서 시간이 녹고, 집중력이 닳고, 실수가 끼어든다.
흔히 쓰는 일반 RAG를 붙이면 되지 않을까. RAG는 문서를 검색해 답을 만들어 주는 방식인데, 그것만으로는 부족하다. RAG는 '규정에 뭐라고 쓰여 있나'를 찾아 읽어 주는 데는 강하지만, 그 규정을 실제 거래 데이터에 적용해 '이 거래가 규정을 위반했고 환수액은 얼마인가'를 계산해 주지는 못한다. 문서를 읽는 일과 문서를 데이터에 실행하는 일은 차원이 다른 일이다.
CSV 18종과 문서 23종을 같은 워크스페이스에 넣는다
이 가설을 확인하려고 준비한 것은 한 가지다. 업무 데이터 CSV 18종과 정산 규정·관련 법령 같은 문서 23종을 같은 워크스페이스에 넣는 것이 전부다.
데이터와 문서를 한자리에 놓는 순서
"소스 추출하기"(⌘⇧I)에 CSV 18종과 문서 23종을 함께 넣는다
업무 데이터 CSV와 정산 규정·관련 법령 문서를 나눠 넣지 않고 한 워크스페이스에 함께 끌어다 놓는다. 이 단계에서 데이터와 문서가 처음으로 같은 공간에 놓인다.
활동 센터의 "이 워크스페이스를 지식그래프로 만들까요?" 카드에서 "만들기"
에이전트가 CSV의 스키마, 즉 어떤 테이블에 어떤 컬럼이 있고 키가 어떻게 연결되는지를 읽어 온톨로지를 자동으로 구성한다. 온톨로지란 개념과 관계를 이어 그린 지도다. 주문·재고·정산 같은 것들이 단순한 표가 아니라 서로 연결된 엔티티와 관계로 이뤄진 그래프가 된다.
"엔티티 테이블"(⌘⇧L)로 무엇이 뽑혔는지 훑는다
소스 전환 버튼을 열면 "전체"와 함께 "종류" 그룹이 실시간 개수를 달고 나열된다. 18종의 표에서 무엇이 엔티티가 됐는지를 여기서 눈으로 확인한다. 행을 클릭하면 그 엔티티의 360° 페이지가 열린다.
"새 채팅"(⌘⇧C)에서 묻는다
추출이 아직 도는 중이면 "지식 그래프 구축 중" 대화상자가 뜬다. "추출 완료 후 자동 전송"을 고르면 질문을 미리 적어 두고 다른 일을 해도 된다.
테이블을 가로지르는 질문, 규정을 실행하는 질문
"주문과 출고를 맞춰 봐서, 아직 안 나간 거래를 찾아 줘"
→ 주문과 출고를 가로지르는 멀티테이블 대사가 돈다.
미출고로 보이는 거래 120건이 나온다.
(가상 데이터 기준의 참고 수치다)
"정산 규정이 정한 단계를 안 거친 거래가 있나? 있으면 환수액까지."
→ 문서로 들어온 정산 규정을 실제 데이터에 적용해,
각 거래가 규정이 정한 정당한 단계를 거쳤는지 검증한다.
정책을 위반한 거래가 가려지고, 그에 따른 환수액이 산출된다.
"이 신상품 라인, 데이터로 정리해서 리포트로 만들어 줘"
→ 데이터를 집계하고, 규정을 적용하고,
그 결과를 다시 데이터와 맞춰 본 답이 돌아온다.
문서를 찾아 읽는 것만으로는 나오지 않는 종류의 답이다.이 답이 나오는 이유는 에이전트가 데이터를 집계하는 쿼리와 문서를 교차검증하는 일을 한 흐름 안에서 함께 해내기 때문이다. 사람이 PDF를 읽고 머릿속으로 데이터에 대입하던 일을, 에이전트가 데이터 위에서 직접 실행한다.
정산 검증 하나로 끝내지 않았다. 일반 RAG의 한계를 정말로 넘는지 보려고 신상품 분석·디마케팅·리포트 작성·세금 계산처럼 손이 많이 가는 과제형 시나리오 21건을 함께 돌렸다. 디마케팅은 특정 수요를 의도적으로 줄이는 마케팅을 말한다. 이 과제들의 공통점은 문서를 찾아 읽는 것만으로는 답이 나오지 않는다는 것이다. 데이터를 집계하고, 규정을 적용하고, 그 결과를 다시 데이터와 맞춰 봐야 결론이 선다.
무엇이 달라지나
| 예전 | 지금 |
|---|---|
| 주문 테이블을 조회해 엑셀로 내려받고 출고·반품 데이터와 손으로 맞춰 본다 | 주문과 출고를 가로지르는 멀티테이블 대사가 돌고, 미출고로 보이는 거래 120건이 나온다(가상 데이터 기준) |
| 정산 규정 PDF를 열어 어느 조항이 이 거래에 걸리는지 기억으로 판단한다 | 규정을 데이터에 적용해 각 거래가 정당한 단계를 거쳤는지 검증하고, 위반 거래와 환수액을 산출한다 |
| 질문 하나에 주문·재고·출고·정산 테이블을 차례로 열고 키를 맞춰 이어 붙인다 | CSV 스키마에서 구성된 온톨로지를 따라, 테이블을 가로질러 한 번에 묻는다 |
| ERP 화면 조회, 엑셀 가공, 기억에 의존한 규정 적용으로 세 갈래로 쪼개진다 | 데이터와 문서를 함께 다루는 하나의 흐름으로 합쳐진다 |
이 실험에서 주문·출고 대사와 규정 적용은 사람의 기억이 아니라 워크스페이스 안의 데이터 위에서 실행됐다. 데이터끼리, 그리고 데이터와 문서 사이의 정합성을 자동으로 맞춰 보는 장치가 있을 때 누락과 오적용의 틈은 줄어든다.