GS리테일 DX블로그 최신 글
gsretail.tistory.com에서 발행한 기술 글을 테크곳간이 수집해 최신순으로 보여드립니다.
원문 블로그 방문하기 →최신 글
AI 개발 도구와 세션 기반 아이템 그래프를 활용한 i2i 추천 모델 개선
GS SHOP 앱에는 백 여개에 달하는 추천 영역이 고객 탐색 경험을 돕고 있습니다. 고객의 쇼핑을 더 빠르고 편리하게 도와줄, 추천 알고리즘 개선 프로젝트에서 AI 개발 도구의 생산성을 활용해 돌파구를 찾고 성과를 만들어 낸 경험을 공유드립니다. 안녕하세요, GS 리테일 검색추천파트의 최원일입니다. 2025년 GS 리테일에 합류해 추천 시스템 전면 재구축 프로젝트를 진행하면서, 다수의 아이템 간(item-to-item, 이하 i2i) 추천 구좌가 공통으로 의존하는 핵심 모델이 있다는 사실을 알게 됐습니다. 이 모델의 성능을 개선하면 현재 운영 중인 여러 추천 영역의 비즈니스 지표도 함께 개선될 가능성이 높다고 판단해 프로젝트를 시작했습니다. 기존 i2i 모델은 ItemCF 계열의 통계 기반 머신러닝 모델입니다. 수년간 온라인 테스트에서 검증되며 좀처럼 이기기 어려운 강력한 베이스라인으로 자리 잡았습니다. 구현·운영 비용이 낮고 성능과 커버리지도 준수해, 시대별 SOTA 모델과의 경
2026년 10월 6일
[ AI-DLC 사례 2: 추천 ] AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까?
목차 [ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정 [ AI-DLC 사례 2: 추천 ] AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까? AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까? AI-DLC에서 시작한 3일간의 추천 실험 앞선 글에서 검색 과제팀은 3일 만에 자연어 검색을 구현해봤습니다. 그 과정에서 크게 남은 것은, AI와 일할 때 사람이 무엇을 얼마나 또렷하게 정의해야 하는가에 대한 경험이었습니다. 같은 3일, 저희는 5명이 한 팀이 되어 AI-DLC를 통해 추천 문제를 풀기로 했습니다. 사실 AI와 함께 개발하는 일은 이미 꽤 익숙했습니다. 저희 검색추천파트도 평소 Claude, Cursor 같은 Coding Agent를 자주 사용하고 있었고, 아이디어를 구상하고나면 코드를 만들고, 오류를 고치고, 테스트를 붙이는 속도는 예전보다 확실히 빨라졌습니다. 이번에
2026년 8월 20일
[ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정
목차 [ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정 [ AI-DLC 사례 2: 추천 ] AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까? 개요 9월 GS SHOP에 고객과 대화하며 상품을 찾아주는 쇼핑Agent 서비스가 오픈할 예정입니다. 기존 검색 서비스에서는 고객이 "샴푸", "손상모 샴푸"처럼 짧은 검색어를 입력했다면, 쇼핑Agent에서는 원하는 조건을 자연어 문장으로 표현할 수 있습니다. "건조한 두피와 손상모발 동시에 관리하는 샴푸" 그런데 문장을 받아줄 검색이 아직 없었습니다. GS SHOP 검색의 주축은 단어 검색과 임베딩 검색이고, 문장에 담긴 여러 조건을 나눠서 다루는 단계가 없었기 때문입니다. 2026년 7월 7일부터 9일까지, 저희 검색추천파트 4명은 AI-DLC(AI-Driven Development Life Cycle) 라는 개발 방법론으로 이 문제를 풀어봤습니다. 요구사항 정의부터 운영 엔드포
2026년 8월 14일
[사내 지식 AI 만들기 ⑤·수집] 좋은 답변의 90%는 검색 전에 결정된다 — Notion 회사와는 차원이 다른 20년치 수집
GIGO, 그런데 우리 건 차원이 다르다 RAG에는 오래된 격언이 있다. "쓰레기를 넣으면 쓰레기가 나온다(Garbage In, Garbage Out)." 그런데 사내 지식은 — 쓰레기인지 아닌지조차 애매했다. 작년에 폐기된 규정인데 멀쩡해 보이는 문서, 부서마다 다르게 부르는 용어, 같은 내용이 세 군데에 흩어진 중복, 그리고 절대 새어 나가면 안 되는 개인정보. 1탄~4탄에서 검색·권한·대화·채널을 아무리 잘 만들어도, 들어온 지식이 엉망이면 답도 엉망이다. 좋은 검색의 대부분은 검색 알고리즘이 아니라 _수집 단계_에서 결정된다. 그리고 개인정보 한 건이 새어나가면 그건 "틀린 답변"이 아니라 보안 사고다. 사내 지식은 "얼마나 정확한가"와 "얼마나 위험한가"를 동시에 조심해야 하는, 일반 GIGO보다 한 단계 무거운 문제였다. Notion 하나 쓰는 회사 vs 20년 Excel·PPT 쓴 회사 다른 회사 이야기를 들으면 부러울 때가 있다. 처음부터 지식을 Notion 하나 같은
2026년 7월 12일
사내 지식 AI 만들기 ④·채널] 모바일 앱을 또 만들 뻔했다 — 채널은 글로벌 업체를 못 이긴다, 그래서 Thin 플랫폼
우리가 만든 앱, 그리고 폐기한 앱 솔직히 고백하면 — 우리는 모바일 앱을 만들었다. 포털도 만들었다. 그리고 폐기했다. 이유는 단순하고 아팠다. 사용자는 우리 앱에 안 들어왔다. 이미 Teams에 살고 있었다. 좋은 지식 AI를 만드는 것과, 사용자가 그걸 쓰게 만드는 것은 완전히 다른 일이었다. 멋진 새 집(앱)을 지었는데, 사용자는 이사 올 생각이 없었다. 하루 종일 일하는 곳은 워크스페이스(Teams, Google Chat)였으니까. 채널은 글로벌 업체를 못 이긴다 — 그래서 Thin 플랫폼 방향을 틀면서 우리가 인정한 게 하나 있다. 채널 그 자체(메신저 UX, 알림, 첨부, 카드 렌더링…)는 글로벌 업체가 수십 년 투자한 영역이고, 우리가 그 수준으로 만들 수 없다. Teams를, Google Chat을 우리가 다시 만들 수는 없다. 그리고 하나에 락인(lock-in) 되는 것도 위험했다. 한 플랫폼에 올인하면 그 플랫폼 정책 하나에 서비스가 흔들린다. 그래서 택한 게
2026년 7월 12일
[사내 지식 AI 만들기 ③-2부·대화] RAG Score와 Answer Readiness는 다른 질문이다
정확도 1.0, 그런데 남은 질문 1부에서 정확도 1.0을 냈다. 에이전트가 KB를 정확히 고르고, 권한 안에서, 근거를 재정렬해서 답했다. 그런데도 사용자는 여전히 나쁜 경험을 겪었다. 이유는 하나였다 — "검색이 맞았는가"와 "이 사람에게 답이 됐는가"는 다른 질문이기 때문이다. 이 구분을 실감 나게 보여주는 비교 대상이 하나 있다. 좋은 비교 대상, 그러나 다른 질문 — NotebookLM 여기서 자주 듣는 말이 있다. "이건 NotebookLM에서는 잘 나오는데요?" 틀린 말은 아니다. NotebookLM은 문서 몇 개를 넣고 요약·질문·근거 정리를 시키는 데 실제로 뛰어나다. 범위가 좁고, 문맥이 유지되고, 목적이 분명해서 잘 나온다. 문제는 비교 대상이 다르다는 데 있다. NotebookLM은 문서를 잘 읽는 도구다. 기업의 지식 AI는 그 위에 몇 가지를 더 얹어야 하는 운영체계다. 같은 질문도 누가 물었는지에 따라 답이 달라진다 — 그 사람이 그 문서를 볼 권한이 있는
2026년 7월 10일
[사내 지식 AI 만들기 ③-1부·대화] 사용자는 한 줄로 묻지 않았다 — 그런데 정확도 1.0으로도 부족했다 (RAG → AgenticRAG)
사서가 필요했다 2탄까지 — 지식은 통합 컬렉션에 잘 저장되고, 권한대로 안전하게 조회된다. 그런데 한 가지가 끈질기게 남았다. "이 질문은 어느 KB를 봐야 하지?" per-KB 시절엔 사람이 골라줬다. "그건 인사 KB에 물어보세요." 새 KB가 끝없이 추가되는 환경에서, 이 수동 선택은 곧 한계에 부딪혔다. 게다가 사용자는 한 줄로 묻지 않는다. "지난번 그 정산 건, 점포 기준이랑 본사 기준 다르지? 그리고 그거 휴가에도 영향 있어?" 한 마디에 정산·점포운영·인사 세 지식이 얽힌다. 멀티턴, 멀티인텐트. 사람이 KB를 골라주는 고전 RAG로는 이 대화를 감당할 수 없다. 잘못 고르면 — 문서는 있는데 답을 못 한다. 이건 가정이 아니라 반복해서 겪은 패턴이었다. 같은 사용자가 부서 경계를 넘나드는 질문을 매번 다른 봇에 따로 물어야 했고, "이걸 왜 매번 나눠서 물어야 하나"라는 불만이 쌓였다. 지식은 잘 저장돼 있는데(1탄), 그걸 하나의 대화로 잇지 못하면 사용자
2026년 7월 10일
[사내 지식 AI 만들기 ②·권한] 지식을 한곳에 모았더니, 아무나 다 볼 수 있게 됐다 — payload 필터로 RBAC를 다시 세운 이유
통합의 청구서 1탄에서 우리는 KB마다 따로 있던 컬렉션을 하나로 합쳤다. 컬렉션 폭증은 사라졌고, 끝없이 늘어나는 지식에 드디어 대응이 됐다. 그런데 합쳐진 건 컬렉션만이 아니었다 — 격리도 같이 합쳐졌다. per-KB 컬렉션 시절엔 격리가 _공짜_였다. 인사 KB는 인사 컬렉션에만 있으니, 다른 컬렉션을 안 보면 그만이었다. 물리적인 벽. 그런데 모든 KB가 한 컬렉션에 들어오자 — 그 벽이 사라졌다. 아무 필터 없이 검색하면 모두가 모든 지식을 본다. 인사 평가도, 다른 부문 기밀도. 통합의 청구서가 날아온 것이다: "이제 누가, 무엇을, 볼 수 있게 할 것인가?" 사실 이 질문은 우리가 먼저 던진 게 아니었다. 엔터프라이즈 AI를 도입하려는 조직이 가장 먼저 묻는 질문이 항상 이거였다. "우리 회사 전체 지식을 하나의 AI에 모으면, 신입사원이 임원 보고서를 검색해서 읽을 수 있는 거 아닌가?" — 보안·권한 관리는 옵션이 아니라 엔터프라이즈 AI가 팔리기 위한 전제조건이었다
2026년 7월 2일
[사내 지식 AI 만들기 ①·저장] 컬렉션이 KB만큼 늘어나기 시작했다
종합 공구 상자와, 내가 필요했던 전동 드릴 처음 사내에 RAG를 붙였을 때, 우리의 벡터 DB는 AWS OpenSearch였다 — 처음 도입한 1세대 지식 솔루션이 고른 선택이었다. 좋았다. 진심으로. 색인 만들고, 임베딩 넣고, k-NN 한 번 던지면 — 끝이었다. "이거면 되네?" 싶었다. OpenSearch도, 그 뿌리인 Elasticsearch도 이미 검증된 솔루션이다. 누구도 쉽게 "나쁘다"고 말 못 한다. 로그도 보고, 전문 검색도 하고, 분석도 하고, 벡터도 한다. 뭐든 한다. 그게 정확히 문제였다. 그건 종합 공구 상자였다. 그런데 나는 벽에 구멍 하나 — RAG — 를 뚫어야 했다. 망치도 줄자도 필요 없었다. 나는 RAG 하나를 제대로 파는 전동 드릴이 필요했다. 이 글은 그 드릴을 찾아 Qdrant로 가고, 거기서 첫 번째 설계를 보기 좋게 말아먹고, 다시 설계한 이야기다. 1. 공구 상자의 한계 — 비용, 그리고 "RAG 특화"의 부재 작은 RAG에선
2026년 6월 30일
쇼핑에 영상을 더하다: Part 3. 이해한 영상을 추천으로 연결하기
시리즈 목차 Part 1. 쇼핑에 영상을 더하다: GSSHOP 숏픽 추천 알고리즘 진화기 Part 2. 쇼핑에 영상을 더하다: 영상을 '이해'하기 시작하다 Part 3. 쇼핑에 영상을 더하다: 이해한 영상을 추천으로 연결하기 고객이 워킹화 숏폼을 클릭했을 때, 추천 시스템은 무엇을 기록했을까요? 아마 이렇게 남겼을 겁니다. "운동화 선호". 맞는 말이긴 한데, 뭔가 많이 잘려나간 느낌이 듭니다. 고객이 실제로 반응한 건 운동화라는 카테고리가 아니라, 영상이 전달한 "편안하고 활동적인 일상"이라는 맥락이었을지도 모릅니다. 그 차이를 시스템이 읽지 못하면, 추천은 늘 비슷한 운동화만 반복하게 됩니다. Part 1에서는 숏픽 추천이 어떻게 진화해 왔는지, Part 2에서는 왜 영상을 중요한 신호로 봐야 하는지를 다뤘습니다. 이번 글은 그 다음 이야기입니다. 영상에서 읽어낸 의미를 실제 추천 시스템에 어떻게 연결했는지, 그 과정을 정리해 보려고 합니다. GS SHOP은 상
2026년 4월 9일
쇼핑에 영상을 더하다: Part 2. 영상을 '이해'하기 시작하다
시리즈 목차 - Part 1. 쇼핑에 영상을 더하다: GSSHOP 숏픽 추천 알고리즘 진화기 - Part 2. 쇼핑에 영상을 더하다: 영상을 '이해'하기 시작하다 - Part 3. 쇼핑에 영상을 더하다: 이해한 영상을 추천으로 연결하기 지난 포스팅 (Part 1) 에서 저희는 MAB 기반의 숏픽 추천 시스템을 소개했습니다. 카테고리, 브랜드, 상품명 같은 정형 메타데이터를 feature로 삼아 고객 취향을 학습하는 방식이었습니다. 그 글의 마지막 '앞으로의 방향' 에서 이런 문장을 남겼습니다. 숏픽 추천은 아직 갈길이 멉니다. 기술적으로도, 콘텐츠 전략 측면에서도 진화의 여지가 많습니다. 숏픽 추천의 Next는 영상 자체의 메타 정보를 활용한 콘텐츠 이해에 기반한 추천이라고 생각합니다. 지금까지는 숏픽에 매핑된 상품 정보를 중심으로 추천을 구성해왔다면, 앞으로는 영상 내 포함된 텍스트, 음성, 이미지 등 콘텐츠 자체의 속성까지 분석해 추천에 반영하여 더 좋은 성
2026년 3월 30일