이커머스 자료, 규정은 지키고 찾기는 쉽게: 프라이빗 RAG와 압축

몇 해 전만 해도 온라인 쇼핑몰 팀들은 문서 문제를 단순한 정리 업무쯤으로 여겼다. 스캔해서 공유 폴더에 넣고 다음 일로 넘어가면 그만. 그 태도는 데이터가 어디에 머무는지를 감시하는 규제의 시선이 날카로워지면서 금세 통하지 않게 됐다. 이제 많은 시장에서 규칙은 명확하다. 고객 정보나 거래 기록 같은 민감 문서는 건물 밖을 나가지 않아야 하고, "나중에 정리하겠다"는 말은 더 이상 통하지 않는다. 데이터 주권을 지키라는 요구, 즉 데이터를 자사 환경에 두고 통제하라는 흐름은 거스를 수 없는 방향이 됐다.

UglyPear Data가 만나는 이커머스 팀들의 패턴은 늘 비슷하다. 부족한 건 도구가 아니다. 파일이 너무 많고, 너무 흩어져 있고, 너무 다루기 조심스럽다는 점이다. 지우면 혹시 모를 데, 못 찾으면 골치 아프고, 감사 때 원본 증거를 못 내밀면 사고다.

McKinsey가 헛쓴 시간에 숫자를 붙였다. 지식 근로자는 근무 시간의 약 19%를 정보를 찾고 모으는 데 쓴다. 이커머스 팀이라면 그 비중은 더 올라간다. 상품 카탈로그, 스펙 시트, 공급사 계약서, 고객 응대 대본, 반품 정책, 라이브 커머스 대본이 매일 쌓이니까. Komprise가 기업 스토리지를 들여다본 결과는 뼈아프다. 60%에서 70%에 이르는 데이터가 90일 넘게 접근 없이 가장 비싼 주 스토리지를 점유하고 있었다. 정작 써야 할 파일은 잊어버린 파일 밑에 묻힌다.

거기다 아무도 예산 잡지 않는 비용이 있다. 주 스토리지는 최상위 티어 가격으로 매겨진다. 전체의 6~7할을 차지하는 거의 쓰지 않는 데이터를 그 티어에 그냥 둔다는 건, 잠든 파일에게 월세를 내주는 꼴이다. 대규모 프로모션이 끝나면 지난 시즌 랜딩 페이지, 만료된 라이브 영상, 폐기된 프로모션 약관이 그대로 눌러앉는다. 아무도 지우지 않는다. "나중에 쓸지도 몰라"라고 틀린 청을 들고 싶은 사람은 없으니까.

이커머스만의 골칫거리도 있다. 채널이 많고 버전이 엉켰다. 같은 상품이 상세 페이지, 호스트 대본, AS 조항, 해외몰 설명 다섯 벌로 날아다닌다. 어떤 게 최신인지 명확히 아는 사람이 드물다. 비싼 건 저장 공간이 아니라 "찾기"와 "구분하기"라는 걸.

Asana와 집중력 연구가 들려주는 숫자도 곁들일 만하다. 작업을 중단한 뒤 다시 집중 궤도에 오르기까지 평균 23분이 걸리고, 하루에 약 35개 앱 사이를 왔다 갔다 한다. 자료가 여기저기 흩어지면 그 헤엄은 더 길어진다.

이 많은 자료를 퍼블릭 클라우드 모델에 밀어 넣어 지식베이스를 만들면 편해 보인다. 실제로 돌리면 세 가지가 걸린다.

가장 먼저 데이터가 내부망을 빠져나가야 한다. 고객 주문이나 거래 기록이 걸린 문서라면 쿼리 한 줄 쓰기도 전에 컴플라이언스 벽에 부딪힌다. 다음은 원본 파일이 그대로 색인에 들어가서, 페이지마다 사진이 붙은 수백 쪽 카탈로그 하나로 저장·검색 할당량을 다 태워버린다. 마지막은 검색이 느리고, 모델이 "기억"한 게 정확한지 끝내 믿기 어렵다는 점이다.

그렇다면 이커머스는 규정도 지키고 찾기도 쉬운 자료집을 어떻게 꾸릴까. 짧게 말하면 데이터는 자사 환경에 두고, 프라이빗 RAG 데이터 엔지니어링 기반으로 올린 뒤, 그 앞에 압축이라는 전처리 공정을 하나 더 얹는다.

중요한 선택 기준 몇 가지를 정리했다.

프라이빗 RAG에서 진짜 공든 데는 모델을 연결하는 게 아니다. 자료를 깔끔히 다듬어 제대로 자료집에 담는 일이다. UglyPear Data의 접근은 검색 증강 생성(RAG) 데이터 엔지니어링 기반이다. 정의된 파이프라인과 내장 역량을 갖추고 프라이빗하게 배포돼 데이터가 내부망을 벗어나지 않으며, 13개 범주의 민감 정보에 대해 자동 비식별 처리를 한다. 데이터 주권을 지키는 로컬퍼스트(local-first) 배포가 바탕이고, 필요하면 내부망과 외부를 끊는 에어갭(air-gapped) 구성도 가능하다. 이커머스라면 공급사 계약서, 고객 주문, 상품 자료를 모두 로컬에서 검색하고 인용할 수 있고, 원본 데이터는 이동하지 않고 노출되지도 않는다. 프라이빗 배포 옵션은 RAG 데이터 기반에서 확인할 수 있다.

RAG만 있어도 자료집은 여전히 배가 부르기만 하다. SmartSlim은 수집 전 단계를 맡는다. 문서·이미지·영상·오디오를 압축하는 일인데, 공개된 기준으로 부피를 60%에서 80%까지 줄인다. 최근에 손에 익은 지점 하나를 짚고 싶다. 상품 카탈로그 같은 "복합 문서"는 이미지를 듬뿍 박아 넣는데, 압축 엔진이 문서가 자료집에 들어가기 전 내장 이미지를 가벼운 형식으로 바꾼다. 이미지를 손으로 내보낼 필요도 없고, 압축하고 나서 흐릿해질 걱정도 덜었다. 인장과 도표 같은 핵심 시각 정보는 그대로 살아 있다.

겉보기엔 저장 공간을 좀 아끼는 정도다. 곰곰이 뜯어보면 시스템에서 가장 돈 잡아먹는 다리를 잘라낸 셈이다. 검색 전에 작아지니 검색은 빨라지고 정확해지며, 기기 간 동기화도 막히지 않는다.

압축만 하고 자료집을 안 만들면 파일은 작아져도 아무도 못 찾는다. 자료집만 만들고 안 압축하면, 세운 자료집은 배가 불러 제대로 안 굴러간다. 둘이 이어져야 자료집이 가볍고, 빠르고, 규정도 지키는 상태가 된다.

구체적인 장면을 그려보자. 고객 센터에 오래된 상품의 보증 조항을 묻는 문의가 왔다. 예전이라면 채팅 기록 뒤적이고 PDF 뒤지고 제품팀에 메시지를 더했을 일이다. 지금은 로컬 지식베이스에 직접 물으면 답이 출처와 함께 돌아온다. 어느 문서의 몇 번째 항목인지 분명하다. 주문과 계약은 내부망에 있고, 한 문장 답하려고 고객 데이터를 밖으로 보낼 일이 없다. 이 흐름을 정리한 제품 총람도 참고하면 좋다.

감사 대화도 한결 가벼워진다. 감사관이 듣고 싶은 건 "우리 AI 도입했다"가 아니다. 원본 기록을 즉시 불러오고, 그 기록이 내부망을 나간 적 없음을 확인하는 거다. 프라이빗 배포에 로컬 보관을 더하면 바로 그 요구에 맞춘다.

FAQ

Q: 이커머스 지식베이스는 꼭 프라이빗이어야 하나?
A: 꼭 그런 건 아니다. 자료가 가볍고 민감하지 않다면 퍼블릭 클라우드 SaaS도 충분하다. 다만 거래 기록, 고객 주문, 공급사 계약처럼 걸린 것이 있다면 데이터가 내부망에 머무는 온프레미 배포가 컴플라이언스 부담을 크게 덜어준다.

Q: 상품 카탈로그나 스펙 시트는 이미지가 많은데 압축하면 흐릿해지지 않나?
A: 압축 엔진은 복합 문서를 따로 처리한다. 내장 이미지를 가벼운 형식으로 바꾸면서 핵심 시각 정보는 지킨다. 공개 테스트에서 443쪽 문서를 124초 만에 처리했고, 선명함은 유지된다.

Q: RAG 지식베이스 구축에 얼마나 걸리나?
A: UglyPear Data 방식은 엔드투엔드 실측을 중시해, 검색 응답이 1초 미만 수준에 도달한다. 실제 일정은 자료량과 연동 방식에 따라 다른데, 대개 기존 업무 데이터베이스에 직접 연결해 이동 없이 평가한다.

Q: 압축과 RAG를 왜 같이 쓰나?
A: 둘 다 따로 쓸 수는 있다. 같이 쓰면 흐름이 맞는다. 압축이 수집 전 파일을 줄이고, RAG가 로컬에서 검색과 생성을 맡는다. 이어지면서 자료집이 가볍고 빠르며 규정도 지키게 된다.

Q: 이미지가 많은 문서를 모델에 넣을 때 토큰 비용을 낮출 수 있나?
A: 가능하다. 공개 테스트에서 이미지 관련 토큰이 약 85.9% 줄었다. 검색에 들어가는 자료일수록 이득이 크다.

Try it now

실제 모습이 궁금하다면 데스크톱·서버 버전을 정리한 SmartSlim을 살펴보거나, 프라이빗 배포 옵션인 RAG 데이터 기반을 확인해 보세요. 더 많은 시나리오 분석은 기술 블로그에 있고, 한곳에서 전부 볼 수 있는 제품 총람도 있습니다.