GS리테일 DX블로그

[사내 지식 AI 만들기 ⑤·수집] 좋은 답변의 90%는 검색 전에 결정된다 — Notion 회사와는 차원이 다른 20년치 수집

DarionKim — Sun, 12 Jul 2026 09:59:58 +0900

GIGO, 그런데 우리 건 차원이 다르다

RAG에는 오래된 격언이 있다. "쓰레기를 넣으면 쓰레기가 나온다(Garbage In, Garbage Out)."

그런데 사내 지식은 — 쓰레기인지 아닌지조차 애매했다. 작년에 폐기된 규정인데 멀쩡해 보이는 문서, 부서마다 다르게 부르는 용어, 같은 내용이 세 군데에 흩어진 중복, 그리고 절대 새어 나가면 안 되는 개인정보.

1탄~4탄에서 검색·권한·대화·채널을 아무리 잘 만들어도, 들어온 지식이 엉망이면 답도 엉망이다. 좋은 검색의 대부분은 검색 알고리즘이 아니라 _수집 단계_에서 결정된다. 그리고 개인정보 한 건이 새어나가면 그건 "틀린 답변"이 아니라 보안 사고다. 사내 지식은 "얼마나 정확한가"와 "얼마나 위험한가"를 동시에 조심해야 하는, 일반 GIGO보다 한 단계 무거운 문제였다.

Notion 하나 쓰는 회사 vs 20년 Excel·PPT 쓴 회사

다른 회사 이야기를 들으면 부러울 때가 있다. 처음부터 지식을 Notion 하나 같은 단일 도구에 모아 쓰는 회사는, 도서관을 신축 설계도 한 장으로 짓는 것과 같다. 소스가 하나고, 게다가 Notion은 태생이 마크다운 — 텍스트 구조가 이미 깔끔해서 파싱이 거의 공짜다. 서가 규칙이 처음부터 하나다.

우리는 달랐다. 20년 넘게 Excel·PowerPoint·사내 게시판·메일로 지식을 쌓아온 회사였다. 여기서 진짜 난이도는 "소스가 많다"가 아니라 "20년치 이질적 포맷" 자체다.

Excel: 표, 병합 셀, 여러 시트, 수식 결과값, 셀 안에 줄바꿈으로 욱여넣은 문단.
PowerPoint: 텍스트가 도형·표·이미지 안에 흩어져 있고, 발표 흐름은 사람 머릿속에만 있다.
게다가 표를 이미지로 캡처해 붙인 문서도 흔하다 — 그 안의 글자는 텍스트가 아니라 그림이다.

Notion 회사가 "책을 그대로 서가에 꽂는" 일이라면, 우리는 책을 펼쳐 표·도형·이미지에서 글자를 발라내는 일부터 해야 했다. 통째로 다시 지을 순 없었다 — 이미 그 안에 20년치 지식이 살고 있었으니까. 그래서 만든 건 "하나의 표준 서가"가 아니라, 소스마다 맞춘 전용 손수레(connector) 였다. Confluence, Jira, SharePoint, 게시판, Teams… 소스마다 다른 문·다른 포맷에 맞춰 각각의 connector를 만들고, 그 손수레들이 정해진 시간에 각 소스를 도는 순회 일정(scheduler) 을 짰다.

검수대(Ingestion Gate)

포맷을 발라 텍스트를 얻었다고 끝이 아니다. 도서관에 책을 들이기 전, 검수대를 뒀다. 모든 문서는 색인되기 전에 이 게이트를 통과한다.

[소스] → 파싱 → 한국어 전처리 → 청킹 → (검수대: ingestion gate)
                                          ├─ 품질: 너무 짧거나 깨진 문서?
                                          ├─ 보안: PII/기밀? → 격리(quarantine)
                                          └─ 메타: 권한 태깅(tenant/kb/tier/acl)
        → 중복 제거 → 임베딩 → 저장(Qdrant)

100G를 통째로 나를 수는 없다 — 분할과 델타

소스 하나가 워낙 커서(대용량), 손수레로 한 번에 다 나르려면 트럭 몇 대로도 부족했다. 두 가지를 했다.

분할(partition): 큰 자료 뭉치를 통째로 나르지 않고, 감당할 수 있는 단위로 쪼개서 나른다.
델타(delta): 매번 소스 전체를 다시 뒤지지 않는다. fingerprint로 지난번과 달라진 부분만 골라 옮긴다 — 안 그러면 순회할 때마다 도서관 하나를 통째로 다시 옮기는 셈이 된다.

여러 소스를 돌다 보면 같은 문서가 이름만 바꾼 채 여러 곳에 꽂혀 있는 것도 발견한다 — 그대로 다 꽂으면 사용자는 같은 답을 세 번 받거나, 서로 다른 버전의 답을 받는다. 그래서 서가에 꽂기 전, 마지막으로 한 번 더 골라내는 절차(중복 제거)를 거친다.

수집 스택:

소스 connector : Confluence / Jira / SharePoint / 사내 게시판 / Teams — 소스별 어댑터
포맷 파싱      : Excel / PPT / PDF / 문서 — 표·도형·이미지에서 텍스트 추출
증분 크롤      : fingerprint 기반 변경분만 재수집
워크플로       : Temporal(스케줄·재시도·크롤 상태 추적)
PII 스크럽     : 정규 포맷 + 우회 케이스(하이픈 없는 번호 등) 규칙 엔진
중복 제거      : 해시 → 근사중복 → 의미중복 다단계 파이프라인
임베딩/저장    : 청킹 → 임베딩(OpenAI) → Qdrant(1탄의 통합 컬렉션, 권한 태그 포함)

심화 — 검수대는 무엇을 막고, 우리는 어디서 데였나

이 절은 깊다. 검수대가 실제로 어떻게 판정하고, 대용량 수집이 어디서 터졌는지 궁금한 분을 위한 detail이다. 바쁘면 체크리스트로 건너뛰어도 좋다.

① 검수대 판정 — 무엇을 막고, 무엇을 통과시키나

게이트는 결과를 네 갈래로 나눈다.

if verdict in {보안 위반: PII·기밀}:     action = QUARANTINE   # 색인 안 함, 격리
elif core_fail >= 2:                     action = REJECT       # 핵심 품질 다중 실패
elif core_fail == 1:                     action = HOLD         # 재작업 여지
elif core_warn:                          action = PROCEED      # 로그만, 색인은 진행 (아래 ②)

핵심은 보안 위반(PII·기밀)만 색인을 막는 하드 블록(격리) 이고, 나머지 품질 문제는 정도에 따라 REJECT/HOLD로 나뉜다는 것. "정확도"와 "위험도"를 같은 잣대로 다루지 않는다.

② 영리한 선택 — 경미한 경고(WARN)는 색인을 막지 않기로

처음엔 품질 경고(WARN)도 색인을 막았다. 그랬더니 문제가 생겼다 — 사소한 경고 하나 때문에 멀쩡한 문서가 0청크로 저장돼 검색에 안 잡히는 일이 벌어졌다. 그래서 정책을 뒤집었다: Core WARN은 PROCEED(로그만 남기고 색인은 진행). 막아서 얻는 안전보다, 막아서 잃는 "있는데 안 나오는 지식"이 더 컸기 때문이다. 게이트의 목적은 "완벽한 것만 통과"가 아니라 "위험한 것만 차단"이었다.

③ 숫자, 정직하게

여기도 자랑할 실측 %는 없다. 아래 ④의 사고를 고친 뒤 "0청크 → 정상 청크 + 한글 근거 복원"을 확인한 정성적 결과가 전부다. 없는 숫자는 안 만든다.

④ 우리가 처음엔 틀렸다 — chunks=0의 진범은 파일명 길이였다

대용량 재적재 중, 어떤 소스의 문서들이 인제스트했는데 청크가 0개로 나왔다. 원인을 다섯 번 오진했다: PostgreSQL 갭 → S3 키 불일치 → 버킷 IAM 권한 → boto3 버전 → 인코딩(ASCII rekey). 다 아니었다.

진범은 어이없게도 파일명 길이였다. 리눅스 파일시스템의 파일명 한계는 255바이트인데, 그 소스의 한글 파일명은 인코딩하면 283바이트로 그 한계를 넘었다. 그래서 다운로드가 로컬에 저장되는 순간 ENAMETOOLONG으로 실패했는데 — 이걸 넓은 except: continue가 삼키면서 겉으로는 "S3 object not found" 로 위장됐다. 있는 파일을, 없다고 보고하고 있었던 것이다.

고친 방식: 다운로드 로컬 파일명을 원본 키 대신 짧은 해시(sha256 앞 16자) 로 쓰고, 사용자에게 보일 제목(한글 citation)은 원본 키에서 따로 유도했다. 그리고 그 broad except의 마스킹을 걷어내 진짜 에러가 드러나게 했다.

# S3 키 basename이 로컬 255바이트 한계를 넘으면 ENAMETOOLONG →
# 이전엔 "S3 object not found"로 위장됐다. 짧은 해시명으로 우회.
safe_name = hashlib.sha256(key.encode("utf-8")).hexdigest()[:16] + Path(key).suffix

교훈 두 개. 하나의 증상(chunks=0)이 다섯 개의 서로 다른 원인을 가릴 수 있다. 그리고 넓은 except는 사고를 고치는 게 아니라 숨긴다 — 3탄에서 본 "같은 증상, 다른 원인"이 수집 파이프라인에서 다시 나타난 셈이다.

들이기 전에 고민한 것들 (체크리스트)

PII redaction — 주민번호·카드·전화·이메일을 들어오기 전에 스크럽한다. 표준 포맷뿐 아니라 우회 케이스(하이픈 없는 번호, 공백 구분, 국제 포맷)까지. 한 번 새면 영속 저장소에 남는다.
중복(dedup) — 같은 문서가 여러 소스에 → 다단계 파이프라인으로 거른다(해시 → 근사 중복 → 의미 중복 → 충돌 탐지).
신선도(freshness) — 오래된 규정이 최신처럼 답하면 그게 사고다. 소스별 신선도 SLA를 두고, 늦으면 경보·재수집.
권한 메타 — 수집 시점에 출입증(2탄의 tenant/kb/tier)을 박아야 한다. 검색 시점에 뒤늦게 권한을 붙일 수 없다.

한 줄로

좋은 답변은 좋은 검색에서, 좋은 검색은 좋은 저장에서, 좋은 저장은 — 좋은 수집에서 시작한다.

시리즈를 마치며

저장(1) → 권한(2) → 대화(3) → 채널(4) → 그리고 그 모든 것의 출발점, 수집(번외). 한 바퀴를 돌았다.

우리가 내내 붙잡은 원칙 하나로 닫는다: 구조를 만드는 것은 시작이지 끝이 아니다. "저장이 잘 됐나?"가 아니라 "각 사용자의 질문에 근거 있게 답했나?" 를 — 실제 사용자가, 측정된 품질로, 운영 경로에서 증거와 함께 — 확인할 때, 비로소 완료다.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 · 번외 수집 (이 글)

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

사내 지식 AI 만들기 ④·채널] 모바일 앱을 또 만들 뻔했다 — 채널은 글로벌 업체를 못 이긴다, 그래서 Thin 플랫폼

DarionKim — Sun, 12 Jul 2026 09:58:51 +0900

우리가 만든 앱, 그리고 폐기한 앱

솔직히 고백하면 — 우리는 모바일 앱을 만들었다. 포털도 만들었다. 그리고 폐기했다.

이유는 단순하고 아팠다.

사용자는 우리 앱에 안 들어왔다. 이미 Teams에 살고 있었다.

좋은 지식 AI를 만드는 것과, 사용자가 그걸 쓰게 만드는 것은 완전히 다른 일이었다. 멋진 새 집(앱)을 지었는데, 사용자는 이사 올 생각이 없었다. 하루 종일 일하는 곳은 워크스페이스(Teams, Google Chat)였으니까.

채널은 글로벌 업체를 못 이긴다 — 그래서 Thin 플랫폼

방향을 틀면서 우리가 인정한 게 하나 있다. 채널 그 자체(메신저 UX, 알림, 첨부, 카드 렌더링…)는 글로벌 업체가 수십 년 투자한 영역이고, 우리가 그 수준으로 만들 수 없다. Teams를, Google Chat을 우리가 다시 만들 수는 없다.

그리고 하나에 락인(lock-in) 되는 것도 위험했다. 한 플랫폼에 올인하면 그 플랫폼 정책 하나에 서비스가 흔들린다.

그래서 택한 게 Thin 플랫폼이다 — 채널을 _소유_하지 않는다. 대신 각 채널에 얇게 연결만 하고, 무거운 지능(검색·권한·근거·rerank)은 우리 쪽 공통 substrate에 둔다. 채널은 갈아 끼울 수 있는 얇은 어댑터가 되고, 우리는 벤더와 경쟁하는 대신 그 위에 올라탄다.

        [디지털 동료]  (1~3탄: 저장 · 권한 · 대화)
             │  공통 substrate (검색/권한/rerank/근거)   ← 무겁게, 우리가 소유
   ┌─────────┼──────────┬───────────┐
 Teams봇   Google Chat   Outlook    A2A(에이전트 연동)    ← 얇게, 갈아끼움

디지털 동료 하나 → 채널 N개

Thin 플랫폼의 보상은 여기서 나온다. 신원 확인과 UX 포장을 채널별로 한 번씩만 풀어두면, 그 다음부터는 —

디지털 동료 하나를 추가하면 이미 연결된 모든 채널에 동시에 나타난다.
채널 하나를 연결하면 이미 있는 모든 동료가 그 채널에서 한 번에 쓸 수 있게 된다.

동료 M명 × 채널 N개를 M×N번 따로 만드는 게 아니라, M + N번만 만들면 되는 구조다. 이게 "직접 UI를 안 만든다"가 단순 비용 절감을 넘어 _구조적 레버리지_가 되는 지점이다.

같은 답, 다른 얼굴

인증만 채널마다 다른 게 아니었다. 같은 질문에 같은 근거로 답해도, 그걸 _보여주는 방식_은 채널마다 달라야 했다. Teams에선 풍부한 카드(Adaptive Card)로, Google Chat에선 그 채널의 카드 포맷으로, 사람이 보지 않는 에이전트 연동 채널에선 애초에 "보여줄" 필요 없이 구조화된 데이터로 — 같은 답을 그 채널이 이해하는 언어로 다시 포장한다.

여기서 데인 교훈 하나: pod에서 함수로 찍어 본 게 사용자 화면이 아니다. 이건 그냥 넘어갈 얘기가 아니라 심화에서 따로 다룬다.

직접 UI를 안 만든다는 원칙

모바일·포털은 폐기. 워크스페이스 플랫폼 + 채널 + 디지털 동료 연결로 통합.
새 기능 = 새 화면을 또 만드는 게 아니라, 기존 채널에 동료의 능력을 더하는 것.
운영 작업(관리자)은 별도 UI 대신 CLI·슬래시 명령으로.

우리는 _프론트엔드를 다시 만드는 일_을 줄이고, _동료의 능력_에 집중할 수 있게 됐다.

심화 — 채널마다 다른 인증, 그리고 렌더링은 화면에서 검증한다

이 절은 깊다. 채널을 얇게 연결한다는 게 코드에서 뭘 뜻하는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 같은 "누구인지" 확인인데, grant 타입이 다르다

채널을 하나 늘릴 때마다 가장 먼저 부딪힌 건 신원 확인 방식이 제각각이라는 점이었다. 두 개만 나란히 놓아 보자.

Google Chat — 서비스 신원(OIDC) 검증. Google이 발급한 OIDC id_token을 우리 쪽 verifier가 검증한다(정해진 발신자 allowlist인 service_account 모드, 또는 도메인 정책상 허용된 사용자 이메일 토큰). 핵심은 "이 요청이 신뢰된 발신자(서비스)에서 왔는가" 를 토큰으로 확인하는, machine-to-machine에 가까운 모델이다.
에이전트 연동(A2A) — 위임 토큰 교환(OBO). 여기선 사람이 채널에 로그인하는 게 아니라, 에이전트가 사용자를 대신해(on-behalf-of) 통신한다. 사용자 동의로 얻은 토큰을 downstream 토큰으로 교환(On-Behalf-Of) 해서, 그 위임 신원으로 다음 시스템에 접근한다. authorization-code에서 파생된 위임(delegated) 모델이다.

같은 "이 사용자가 누구인지 확인한다"인데, 한쪽은 _서비스 신원을 검증_하고 다른 쪽은 _사용자 위임을 교환_한다 — grant 타입 자체가 다르다. 그래서 채널 하나 = 인증 어댑터 하나였다. (이 위임 교환은 실제로 한 번 크게 데였다 — invalid_grant가 무더기로 나 별도 원인분석을 했다.) 각 채널의 인증을 2탄의 출입증(payload 권한)에 다시 맞물리는 게 Thin 플랫폼의 진짜 일이었다.

② 영리한 선택 — 채널을 소유하지 않는다

기각한 대안은 명확했다: 자체 채널·앱을 만들어 그 안에서 모든 걸 통제하기(모바일·포털이 그거였고, 폐기했다). Thin 플랫폼은 그 반대다 — 채널 UX는 벤더에게 맡기고, 우리는 그 위에 얇은 어댑터로만 붙는다. 잃는 것: 채널 화면을 100% 우리 맘대로 못 함. 얻는 것: 벤더와 경쟁 안 함 + 락인 회피 + M+N 레버리지.

③ 숫자, 정직하게

여기엔 자랑할 하드 넘버가 없다. M+N의 이득은 "채널·동료를 늘려도 연결 작업이 곱이 아니라 합으로 는다"는 구조적 사실이지 측정된 %가 아니다. 없는 숫자는 안 만든다.

④ 우리가 처음엔 틀렸다 — pod에서 찍은 건 사용자 화면이 아니다

가장 아팠던 채널 사고는 렌더링이었다. Teams 카드가 단일 줄바꿈을 공백으로 뭉개 잘 정리한 답이 한 덩어리 벽처럼 나온 적이 있다. 또 한 번은 카드를 감싸던 내부 호환 마커(__ADAPTIVE_CARD__)가 안 벗겨져 raw JSON이 그대로 사용자에게 노출된 적도 있다. 둘 다 pod 안에서 함수를 호출해 찍어 보면 멀쩡했다 — "함수 출력이 맞다"와 "그 채널에서 실제로 그렇게 보인다"는 다른 일이었으니까.

그래서 렌더링을 화면 기준으로 강제하는 4겹을 깔았다: commit 훅(원시 마커 누출 차단) · CI(카드 골든 렌더 테스트) · 런타임(발신 직전 outbound guard) · Datadog 모니터(마커 누출·렌더 실패율). 채널을 얇게 연결한다는 건, 역설적으로 각 채널의 화면을 더 깐깐하게 검증한다는 뜻이었다. (사실 문서를 한 도구에서 다른 도구로 옮길 때마다 겪는 일이다 — 원본에선 멀쩡한데 옮긴 화면에선 깨지는. 규모만 다를 뿐 같은 교훈이다.)

맺음 — 그런데 좋은 지식이 없으면 다 소용없다

저장(1) → 권한(2) → 대화(3) → 채널(4). 이제 사용자는 자기 자리에서, 권한 안에서, 근거 있는 답을 받는다.

그런데 이 모든 건 _좋은 지식이 들어와 있을 때_만 의미가 있다. 쓰레기가 들어가면 쓰레기가 나온다. 그 지식을 _어떻게 모으고, 들이기 전에 무엇을 검수했는지_는 — 번외편 — 좋은 답변의 90%는 검색 전에 결정된다에서.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 (이 글) · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ③-2부·대화] RAG Score와 Answer Readiness는 다른 질문이다

DarionKim — Fri, 10 Jul 2026 14:12:11 +0900

정확도 1.0, 그런데 남은 질문

1부에서 정확도 1.0을 냈다. 에이전트가 KB를 정확히 고르고, 권한 안에서, 근거를 재정렬해서 답했다. 그런데도 사용자는 여전히 나쁜 경험을 겪었다. 이유는 하나였다 — "검색이 맞았는가"와 "이 사람에게 답이 됐는가"는 다른 질문이기 때문이다.

이 구분을 실감 나게 보여주는 비교 대상이 하나 있다.

좋은 비교 대상, 그러나 다른 질문 — NotebookLM

여기서 자주 듣는 말이 있다. "이건 NotebookLM에서는 잘 나오는데요?" 틀린 말은 아니다. NotebookLM은 문서 몇 개를 넣고 요약·질문·근거 정리를 시키는 데 실제로 뛰어나다. 범위가 좁고, 문맥이 유지되고, 목적이 분명해서 잘 나온다.

문제는 비교 대상이 다르다는 데 있다. NotebookLM은 문서를 잘 읽는 도구다. 기업의 지식 AI는 그 위에 몇 가지를 더 얹어야 하는 운영체계다.

같은 질문도 누가 물었는지에 따라 답이 달라진다 — 그 사람이 그 문서를 볼 권한이 있는지부터 확인해야 한다(2탄).
최신 공지와 오래된 규정이 충돌하면, 어느 쪽을 우선할지도 판단해야 한다.
답이 틀렸을 때, 누가·어떤 근거로·어떤 경로로 답했는지 나중에 재현할 수 있어야 한다.

이건 문서 QA가 아니라 운영이다. 그래서 NotebookLM은 경쟁 대상이 아니라 기준점으로 쓰는 게 맞았다. 같은 문서를 넣었을 때 NotebookLM은 답하는데 우리 검색은 못한다면 — 그건 검색·청킹·리랭킹(1부)·근거검증·프롬프트 중 어딘가가 부족하다는 신호다. 반대로 NotebookLM이 잘한다고 그 경험을 그대로 기업 시스템에 옮길 수 있는 것도 아니다. 권한이 있어야 하고, 감사가 있어야 하고, 실패가 드러나야 하고, 업무로 이어져야 한다 — 문서를 잘 읽는 것과 회사 안에서 그 답을 운영 가능하게 만드는 것은 다른 일이다.

RAG Score vs Answer Readiness

이제 이름을 붙여보자.

RAG Score        : 문서를 잘 읽었는가?         (검색·태깅·재정렬의 정확도)
Answer Readiness : 이 사람에게 답이 됐는가?     (맥락·권한·시점까지 반영한 실사용 준비도)

RAG Score는 도구의 품질이고, Answer Readiness는 운영체계의 자격이다. 1부는 전자의 이야기였다. 여기서부터는 후자다.

Query Expansion — 사람은 완전한 문장으로 안 묻는다

"그거 다시 설명해줘." "방금 그건 휴가에도 적용돼?" — 이런 말은 그 자체로는 검색할 수 없다. 이전에 뭘 물었는지, 뭘 가리키는지가 없으면 "그거"는 그냥 대명사다.

그래서 검색으로 넘기기 전에 질문을 한 번 다듬는다. 세 갈래로:

문맥 보존 명확화 — "그거"가 뭘 가리키는지 앞선 대화에서 찾아 완전한 문장으로 바꾼다.
핵심 키워드 추출 — 검색엔진이 더 잘 무는 형태로 다시 뽑는다.
의미 보존 변형 — 같은 뜻을 다르게 표현한 질문 몇 개를 더 만들어서, 하나로 안 걸리는 것도 다른 표현으론 걸리게 한다.

여기서도 익숙한 구조가 나온다. 사전에 등록된 동의어·줄임말은 규칙 기반으로 항상 확장하고, 그걸로 부족하면 LLM 기반으로 의미를 더 풀어서 확장한다. 값싼 걸 먼저, 비싼 건 필요할 때만 — 1부 rerank에서 봤던 것과 같은 이중 구조다.

세 번 넘어졌던 이야기

이거 켜는 데 세 번 넘어졌다.

첫 번째는 이름이었다. 코드는 한 이름의 환경변수만 봤는데, 운영자는 다른(그러나 더 흔히 쓰이던) 이름으로 설정을 넣었다. 둘 다 "쿼리 확장을 켜라"는 같은 뜻이었는데, 코드가 한쪽만 알아들어서 — dev에는 켜졌고 prod에는 조용히 안 켜져 있었다. 에러 한 번 없이, 그냥 확장이 안 됐을 뿐이었다.

두 번째는 기본값이었다. 이름을 통일한 다음에도 기본값이 꺼짐으로 남아 있었다. 로그를 뒤져서 잡았다 — 같은 기간 dev 로그엔 "쿼리 확장됨" 흔적이 여러 건 있었는데, prod 로그엔 한 건도 없었다. 품질 지표(주제 적합도)도 유독 낮게 나오던 원인 중 하나가 이거였다. 기본값을 켬으로 뒤집었다.

세 번째는 인터페이스였다. LLM 기반 확장을 붙이자 "지원하지 않는 클라이언트 타입"이라는 에러가 매 요청마다 조용히 찍히기 시작했다 — 확장을 시도했다가 실패하고 원래 쿼리로 되돌아가는 걸 반복하고 있었다. 새로 붙인 LLM 클라이언트가 기대하던 메서드 이름과 실제 메서드 이름이 달랐던 것 — 어댑터로 감싸서 맞췄다.

세 번 다 겉으로는 "왜 확장이 안 켜지지"라는 같은 증상이었다. 원인은 매번 달랐다 — 이름 불일치, 기본값 반전, 인터페이스 불일치. 셋이 서로 아무 관계가 없다는 게 오히려 배운 점이었다. 같은 증상이 여러 다른 원인을 가릴 수 있다는 것.

개인화 스레드 회수 — 출입증이 이제 기억한다

2탄 끝에서 열어둔 질문이 있었다. "출입증은 못 들어가는 문만 막아줄 뿐, 이 사람이 평소 자주 드나드는 문이 어딘지는 알려주지 않는다."

이제 그 답을 할 수 있다. 매 턴마다, 이 사람이 누구이고(조직·부서·직급) 무엇을 기억하고 있는지(장기 기억)를 한 번에 모아 하나의 맥락으로 만든다. 이 맥락이 두 곳에 쓰인다.

하나는 대화 이어가기다. "그거 다시 설명해줘" 같은 말은 그 자체로는 아무것도 아니다. 기억이 있어야 "그거"가 뭔지 안다. 장기 기억에서 방금 무슨 대화가 있었는지를 찾아, 그 말을 완전한 질문으로 다시 써서 검색에 넘긴다. (앞서 본 Query Expansion의 문맥 보존 명확화와 같은 문제를, 대화가 남긴 흔적 쪽에서 한 번 더 푸는 셈이다.)

다른 하나는 조직에 맞춘 우선순위다. 같은 질문도 이 사람이 어느 조직·부서에 있는지에 따라 무엇을 먼저 보여줄지가 달라진다. 접근 가능한 범위(2탄)는 그대로지만, 그 안에서 _이 사람에게 더 맞는 것_을 앞에 놓는다.

두 가지 다 최근에 실제로 켜졌다. "이 사람이 평소 자주 드나드는 문"에 대한 답은 결국, 문을 열어주는 것과는 별개로 — 그 사람을 기억하고, 그 기억을 대화와 라우팅 양쪽에 실제로 쓰는 것이었다.

Before/After — 뭐가 달라졌나

숫자로 자랑할 단계는 아직 아니다. 그런데 체감은 있다.

같은 질문을 두 번 다른 말로 다시 물어야 했던 게, 한 번으로 줄었다 — 문맥 재작성과 쿼리 확장이 같이 자리를 잡은 덕분이다.
"그거 다시" 같은 되묻기가 끊기지 않고 이어진다 — 장기 기억이 무엇을 가리키는지 찾아준다.
같은 권한 범위 안에서도, 이 사람 조직에 더 맞는 답이 앞으로 온다.

여전히 남은 것도 있다. 그리고 그건 다음 이야기 몫이다.

심화 — "그거"를 자립형 질문으로 바꾸는 프롬프트, 그리고 "Pod" 사고

이 절은 깊다. 대화 재작성과 쿼리 확장이 실제 코드에서 어떻게 도는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 코드 — "그거"를 푸는 실제 프롬프트 + 방어막

본문의 "문맥 보존 명확화"는 실제로 이런 프롬프트로 돈다.

def _build_prompt(query, history):
    return (
        "사용자의 모호한 후속 질문을, 대화 기록에서 대명사·지시어(그거, 저분, 위, 아까)를 "
        "풀어 자립형 한국어 검색 질의로 다시 써라. 하나의 간결한 질의로. 답하지 말 것. "
        "이미 자립형이면 그대로 반환.\n\n"
        f"[대화 기록]\n{history}\n\n[현재 질문] {query}\n\n[자립형 질문]"
    )

중요한 건 프롬프트 자체가 아니라 그 주위의 방어막이다. 재작성 결과는 (a) 비어있지 않고 (b) 원본 대비 터무니없이 길지 않고 (c) 프롬프트의 섹션 마커를 되돌려 뱉지 않을 때만 믿는다(_is_plausible_rewrite). 하나라도 실패하면(타임아웃·예외·이상한 출력) 조용히 옛 방식(직전 대화를 그냥 뒤에 이어 붙이기)으로 폴백하고, Datadog에 applied|timeout|error|rejected 태그를 남긴다. "LLM 한 스텝 + 하드 폴백 + 관측 트립와이어" — 이 기능 하나를 넘어 재사용되는 패턴이다.

② 우리가 처음엔 틀렸다 — "Pod"가 "Print On Demand"가 되다

쿼리 확장이 켜지자 새로운 실패가 나왔다. 쿠버네티스 "Pod"를 물은 사용자의 질의가, 같은 용어 사전에 있던 전혀 다른 도메인의 약어로 조용히 확장됐다(리테일 쪽 "Pod = Print On Demand"). 사전에 IT 약어와 리테일 약어가 같이 살았고, 확장 로직은 사용자가 어느 도메인을 뜻했는지 몰랐던 것.

여기서 배운 게 이 시리즈에서 드문 결이다 — 확장은 "못 찾던 걸 찾게" 할 뿐 아니라, "맞던 걸 틀리게" 만들 수도 있다. 본문의 세 번 넘어진 이야기(안 켜지는 문제)와는 정반대 방향의 실패다. 고친 방식: 질의에 이미 다른 IT·인프라 용어가 섞여 있으면, 알려진 교차-도메인 동음이의(pod, node, service, image, port, token, storage, disk)에 대해선 사전 확장을 건너뛴다 — 사전을 무조건 믿지 않고 문맥으로 가드.

그리고 하나 더 — 이 확장이 답변 품질을 실제로 올리는지 A/B로 재려 했는데, 정작 골든 질문 세트에 "짧은 도메인 약어 질의"가 너무 적어 통계적으로 판정할 수 없었다. 그때 결과를 우겨서 내는 대신 INSUFFICIENT_DATA로 정직하게 기록하고, 검정력이 낮다는 단서를 붙여 A/B 결론을 냈다. 기능의 버그가 아니라, 기능을 재는 방식의 결함을 먼저 공개한 사례다.

맺음 — 그리고 다음 질문

1부에서 라우팅을 풀었고, 2부에서 대화의 결을 채웠다. 태깅 정확도와 대화 능력, 둘 다 갖췄으니 이제 완성일까?

아직 하나가 남는다. 이 좋은 답을 어디서 보여줄 것인가. 우리는 하마터면 앱을 또 만들 뻔했다. 그 이야기는 4탄 — 모바일 앱을 또 만들 뻔했다에서.

(그리고 — 이 모든 걸 사람이 아니라 에이전트가 굴린다는 이야기, Claude나 Codex 같은 코딩 에이전트도 결국 같은 틀 안의 "에이전트"라는 이야기는 언젠가 따로.)

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 (이 글) · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ③-1부·대화] 사용자는 한 줄로 묻지 않았다 — 그런데 정확도 1.0으로도 부족했다 (RAG → AgenticRAG)

DarionKim — Fri, 10 Jul 2026 13:56:17 +0900

사서가 필요했다

2탄까지 — 지식은 통합 컬렉션에 잘 저장되고, 권한대로 안전하게 조회된다. 그런데 한 가지가 끈질기게 남았다.

"이 질문은 어느 KB를 봐야 하지?"

per-KB 시절엔 사람이 골라줬다. "그건 인사 KB에 물어보세요." 새 KB가 끝없이 추가되는 환경에서, 이 수동 선택은 곧 한계에 부딪혔다. 게다가 사용자는 한 줄로 묻지 않는다.

"지난번 그 정산 건, 점포 기준이랑 본사 기준 다르지? 그리고 그거 휴가에도 영향 있어?"

한 마디에 정산·점포운영·인사 세 지식이 얽힌다. 멀티턴, 멀티인텐트. 사람이 KB를 골라주는 고전 RAG로는 이 대화를 감당할 수 없다. 잘못 고르면 — 문서는 있는데 답을 못 한다.

이건 가정이 아니라 반복해서 겪은 패턴이었다. 같은 사용자가 부서 경계를 넘나드는 질문을 매번 다른 봇에 따로 물어야 했고, "이걸 왜 매번 나눠서 물어야 하나"라는 불만이 쌓였다. 지식은 잘 저장돼 있는데(1탄), 그걸 하나의 대화로 잇지 못하면 사용자에게는 여전히 흩어진 지식일 뿐이었다.

RAG → AgenticRAG

전환점은 이거였다. "어느 지식을 볼지"를 사람이 하드코딩하는 대신, 에이전트가 대화 맥락 + 사용자 권한 + 의도로 동적으로 고르게 했다.

여기서 "Agentic"의 범위: 에이전트가 무엇을 검색할지 스스로 정한다는 뜻이다 — 의도를 분해하고, 접근 가능한 KB scope를 고르고, 멀티인텐트를 라우팅한다. (검색 결과를 스스로 평가·재시도하는 더 무거운 _적응형 루프_는 지연·비용 트레이드오프가 있어 별개의 프론티어로, 신중히 단계적으로 켠다. 과장하지 않는다.)

멀티턴/멀티인텐트 질문
   → 의도 분해 (멀티 인텐트 감지)
   → 사용자 권한(2탄) 해석 → 접근 가능한 KB scope 자동 선택   ← 사람이 KB 안 고름
   → scope 내 통합 검색(1탄)
   → 필요하면 clarify ("어느 점포 기준이요?")
   → rerank → 근거 기반 답변

대화 스택:

LLM 라우팅   : LiteLLM Proxy (작업별 모델 분리 — 분류는 가볍게, 답변은 무겁게)
의도 분해    : LLM 기반 intent classifier (멀티인텐트 감지)
에이전트 조율: Supervisor 패턴 (역할별 에이전트에게 위임)
비동기 실행  : Temporal 워크플로 (에이전트 작업 상태 추적)
권한 신호    : 사용자 조직 기준 KB 접근범위 결정

한 명의 사서가 아니라 역할이 나뉜 여러 에이전트가 이 대화를 나눠 맡는다. 지식을 아는 에이전트, 그걸 조율하는 층, 실제로 화면을 조작하거나 알림을 보내는 에이전트 — 저마다 자기 몫을 하고, 서로에게 넘긴다. 그리고 누가 물었는지(조직)가 그 라우팅에 함께 반영된다 — 다만 "이 사람이 평소 자주 찾는 지식까지" 반영하는 개인화는 아직 다른 이야기다. (2부에서 왜 그런지 다룬다.)

사서 비유 — 사서 한 명에서, 사서 팀으로

예전 도서관에선 사서가 "303호 서가로 가세요"라고 위치를 알려줬다 — 사용자가 서가 번호를 알아야 했다(수동 KB 선택). 처음엔 사서 한 명(에이전트 하나)이 질문을 듣고 알아서 서가를 도는 정도로 충분해 보였다.

그런데 질문이 여러 전문 분야에 걸치자, 사서 한 명으로는 부족했다. 그래서 도서관을 사서 팀으로 다시 그렸다 — 각 분야를 잘 아는 사서들이 있고(아는 역할), 그 사서들 사이에서 "이 질문은 누구한테 먼저 물어야 하나"를 정리해주는 총괄 사서가 있고(조율하는 역할), 그리고 자료를 찾아주는 데서 그치지 않고 실제로 뭔가를 갖다주거나 대신 처리해야 할 때 움직이는 사람도 있다(실행하는 역할). 사용자는 여전히 한 명의 사서에게 물을 뿐이지만, 그 뒤에서는 팀이 협업한다.

핵심은 "검색을 똑똑하게"이기 이전에, "무엇을 검색할지를 에이전트가 정한다"였다. 끝없이 자라는 KB를 사람이 일일이 관리하던 구조에서, 에이전트가 권한과 의도로 길을 찾는 구조로.

rerank — 후보를 찾은 다음, 순서를 다시 세운다

"무엇을 검색할지"는 에이전트가 정했다. 그런데 검색(1탄, dense+sparse hybrid)은 후보를 넓게 찾는 데 강할 뿐, 그 후보를 질문에 가장 잘 맞는 순서로 세우는 데는 약하다. 임베딩 검색(bi-encoder)은 질문과 문서를 각각 따로 벡터로 만들어 거리로 비교하기 때문에 빠르지만, 질문과 문서를 나란히 놓고 세밀하게 견주지는 못한다.

그래서 상위 후보에만 한 번 더 손을 댄다. 질문과 문서를 함께 입력해 정밀하게 관련도를 매기는 cross-encoder 기반 reranker를 상위 후보에만 돌린다 — 전체 후보에 돌리면 느리니까, 값싼 1차 검색으로 후보를 좁힌 다음 비싼 2차 정렬을 그 위에만 얹는 구조다. 상용 rerank API를 1순위로 쓰고, 막히면 자체 호스팅 cross-encoder로 넘어가는 이중화도 해뒀다.

순서를 정할 때도 모델 점수 하나만 보지 않는다. 모델 관련도 + 원래 검색 순위 + 출처 종류(공식 문서·웹·그래프·FAQ 별 가중치) + 필요하면 결과 다양성을 가중합해서 최종 순서를 만든다. FAQ로 등록된 답이 있으면 살짝 밀어주고, 비슷한 문서만 줄줄이 나오지 않도록 다양성 점수도 얹는다. "무엇을 볼지"는 에이전트가 고르고, "어떤 순서로 보여줄지"는 이 재정렬이 고른다 — 둘이 같이 맞아야 사용자가 실제로 원하는 답에 먼저 닿는다.

(이 "값싸고 넓게 + 비싸고 정밀하게" 이중 구조, 기억해 두면 2부에서 한 번 더 보게 된다 — 검색 말고 다른 layer에서.)

정확도 1.0인데, 왜 여전히 나쁜 경험이었나

여기서 또 한 번 배웠다. 어느 질문이 어느 지식 범위(KB)에 속하는지, API로 태그를 정확히 매기는 것 자체는 정확도 1.0까지도 낼 수 있었다. 그런데 그것만으론 부족했다.

사람은 한 번에 묻지 않는다. 되묻고, 앞서 한 말을 다시 끌어오고, 한 문장에 여러 의도를 섞는다. 지식 범위를 완벽하게 골라내는 것과, 그 반복·다의도 대화를 자연스럽게 받아내는 것은 다른 능력이었다. 태깅 정확도가 아무리 높아도, 대화 기능이 그 대화의 흐름을 못 따라가면 — 사용자에게 돌아오는 건 잘 만든 지식이 아니라, 뚝뚝 끊기는 나쁜 경험뿐이었다.

즉 1탄의 저장, 2탄의 권한이 아무리 정교해도, 이 위에서 사람과 자연스럽게 대화를 이어가는 능력이 없으면 그 지식은 사용자에게 닿지 않는다. 지식 범위를 고르는 일(라우팅)과 대화를 이어가는 일(대화 관리)은 같이 완성돼야 하는 한 쌍이었다.

심화 — reranker는 fallback 안에 fallback, 그리고 점수가 1.0에 붙어버린 사고

이 절은 깊다. 라우팅과 재정렬이 실제 코드에서 어떻게 방어되는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 코드 — 리랭커는 fallback 안에 fallback

본문에서 "상용 rerank API 1순위, 막히면 자체 호스팅 cross-encoder"라 했다. 실제 코드는 한 겹 더 깊다.

def _create_reranker():
    """우선순위: cohere(상용, LiteLLM 경유) > cross_encoder(자체) > 없음."""
    if reranker_type == "cohere" and os.getenv("LITELLM_API_BASE"):
        return CohereReranker()                    # 1순위: 상용 API
    if os.getenv("DISABLE_CROSS_ENCODER_RERANKER") != "true":
        adapter = CrossEncoderIRerankerAdapter()   # 2순위: 자체 호스팅
        loop.create_task(adapter.warmup())         # 모델 로드는 논블로킹
        return adapter
    logger.warning("리랭커 없음 — 벡터 유사도 순서만. 관련도 ~20%% 저하 예상.")
    return None                                    # 3순위: 없음(조용히 넘기지 않고 숫자 로깅)

눈여겨볼 두 가지: (1) 자체 모델 warmup을 loop.create_task로 논블로킹 발사 — 콜드 모델 로딩이 그 요청을 붙잡지 않는다. (2) "리랭커가 아예 없는" 최후 분기가 조용히 넘어가지 않고 "~20% 관련도 저하"라는 숫자를 로그에 남긴다. 그리고 자체 어댑터(CrossEncoderIRerankerAdapter) 안에는 또 3단 fallback이 있다 — 원격 자체호스팅 HTTP → 인프로세스 로컬 모델 → 원순위 기반 선형감쇠. fallback 안의 fallback.

② 영리한 선택 — 점수 정규화: 절대 clamp vs 배치 상대 stretch

싼 1차 점수(벡터 유사도)와 비싼 2차 점수(cross-encoder 관련도)를 가중합할 때, 두 점수의 스케일이 다르다(코사인은 대략 0~~1, rerank logit은 -10~~10 같은 무한대역). 우리가 고른 방식은 각 점수를 절대 기준 0~1로 clamp하는 것. 기각한 대안:

정규화 없이 그냥 합산 — 스케일이 달라 무의미.
배치 안에서 min-max로 늘리기(stretch) — 이게 함정이었다(④ 참조).
순위-위치 가중(1등=1.0, 2등=0.95…) — 점수 크기를 버려서, 톱1이 "진짜 좋아서"인지 "그 배치에서 제일 덜 나빠서"인지 구분 못 함.

③ 숫자, 정직하게 — 둘은 실측, 하나는 아직

점수 포화 fix: golden-question 평가에서 리랭커 톱1 점수가 천장에 붙어 있었다 — 실제 관련도와 무관하게 톱1이 ≥0.94인 비율이 89.6%. 배치 min-max 정규화가 그 배치의 최고점을 항상 1.0으로 만든 탓. 목표를 "톱1 ≥0.94 비율 <50%"로 잡고 고쳤다.
KB scope 확장 A/B(프로덕션 데이터, 골든 26문항): 좁은 기본 scope vs 권한 내 넓힌 scope → 도메인 질문 근거율(grounded@0.5)이 3/22(13%)에서 10/22(45%)로, 대조군 회귀 0.
intent classifier 정확도: 하드 넘버 아직 없음(목표 ≥80% top-1, 8문항 PoC만) — 정직하게 "측정 인프라는 설계했으나 아직 대규모 미가동".

④ 우리가 처음엔 틀렸다 — flag 켜니 "이 시스템 뭐야?"가 깨졌다

KB scope를 넓히는 건 명백히 좋아 보였다(③의 A/B가 증명). 그런데 프로덕션에서 flag를 켜자, 그동안 항상 맞히던 기본 질문 — "이 시스템 뭐야?" — 이 즉시 회귀했다. 격리된 A/B 경로에선 멀쩡했는데, 라이브 end-to-end 경로에서만 깨졌다.

원인은 ②의 점수 포화와 같은 버그 계열이었다: 명시적 KB 리스트가 없을 때만 도는 내부 "KB 선택" 스텝이, min/max 기반 정규화로 아무 상관없는 대형 KB에 인공적 천장 점수를 줘서 톱으로 올려버린 것. 좁혀진 후보 집합에서 "제일 top인 하나"가 실제 관련도와 무관하게 1.0을 받는, 바로 그 실패.

고친 순서가 교훈이다: (1) 같은 날 flag를 한 줄로 되돌려 롤백 → (2) 다음날 격리로 원인 규명(명시적 KB 리스트로 넘기면 정상, "필터 없이 파이프라인이 알아서 고르게" 하면 회귀) → (3) 넓힌 scope를 항상 명시적 KB 리스트로 넘겨 그 버그 경로를 고치는 대신 우회해 재출시. 이 사고는 지금 라이브 코드의 docstring(_resolve_accessible_default_kb_filter)에 그대로 적혀 있다 — 코드가 자기 과거 회귀를 기억한다.

교훈: 격리된 실험에서 좋았다고 라이브에서도 좋은 게 아니다. "이 경로에서만 도는 스텝"이 실험 경로엔 없고 라이브 경로엔 있으면, 그 차이가 정확히 회귀가 숨는 자리다.

맺음 — 그리고 이 반전이 남긴 질문

이제 에이전트가 알아서 지식을 찾는다. 멀티턴으로 얽힌 질문도, 권한 안에서, 근거를 모아 답한다. 그런데 정확도 1.0짜리 라우팅으로도 사용자는 여전히 나쁜 경험을 겪었다 — 그 이유를 따라가면 질문이 하나 남는다.

"검색이 맞았는가"와 "이 사람에게 답이 됐는가"는 다른 질문이었다. 그리고 2탄이 심어놓은 또 다른 숙제 — 이 사람이 _평소 자주 찾는 지식_은 여전히 못 알아본다는 것 — 도 그대로 남아있었다.

이 두 질문에 어떻게 답을 하려 했는지는 3탄-2부 — RAG Score와 Answer Readiness는 다른 질문이다에서.

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 (이 글) · 3탄-2부 대화 · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ②·권한] 지식을 한곳에 모았더니, 아무나 다 볼 수 있게 됐다 — payload 필터로 RBAC를 다시 세운 이유

DarionKim — Thu, 2 Jul 2026 11:07:46 +0900

통합의 청구서

1탄에서 우리는 KB마다 따로 있던 컬렉션을 하나로 합쳤다. 컬렉션 폭증은 사라졌고, 끝없이 늘어나는 지식에 드디어 대응이 됐다. 그런데 합쳐진 건 컬렉션만이 아니었다 — 격리도 같이 합쳐졌다.

per-KB 컬렉션 시절엔 격리가 _공짜_였다. 인사 KB는 인사 컬렉션에만 있으니, 다른 컬렉션을 안 보면 그만이었다. 물리적인 벽. 그런데 모든 KB가 한 컬렉션에 들어오자 — 그 벽이 사라졌다. 아무 필터 없이 검색하면 모두가 모든 지식을 본다. 인사 평가도, 다른 부문 기밀도.

통합의 청구서가 날아온 것이다: "이제 누가, 무엇을, 볼 수 있게 할 것인가?"

사실 이 질문은 우리가 먼저 던진 게 아니었다. 엔터프라이즈 AI를 도입하려는 조직이 가장 먼저 묻는 질문이 항상 이거였다. "우리 회사 전체 지식을 하나의 AI에 모으면, 신입사원이 임원 보고서를 검색해서 읽을 수 있는 거 아닌가?" — 보안·권한 관리는 옵션이 아니라 엔터프라이즈 AI가 팔리기 위한 전제조건이었다.

물리 벽 대신, 출입증

선진사례(Qdrant multitenancy, Azure의 security trimming)의 답은 같았다. 물리 분리 대신 payload 필터. 모든 청크에 "출입증" 메타데이터를 박고, 질의 시 그 사용자가 통과할 수 있는 것만 본다.

청크 payload
{ tenant_id, kb_id, kb_tier, acl, ... }   + tenant_index (is_tenant=true)

4-tier 권한 모델:

Tier	접근
GLOBAL	전사 공통 (인프라·전사 지식)
BU	조직(부문) 일치
TEAM	부서 일치 또는 명시적 공유
PERSONAL	개인 소유 — 본인만 접근, 본인이 직접 지식을 만들고 관리

기존 조직 위계(GLOBAL→BU→TEAM)만으로는 부족했다. 개인도 자기 지식을 직접 관리할 수 있어야 했다 — 회사 조직도에 없는, 그 사람만의 메모·노트·업무 자료. 그래서 tier 하나를 더 열었다.

질문 → 사용자 신원(tenant/부서/role/tier) 해석
     → payload 필터 자동 주입
     → 통합 컬렉션 검색 (접근 가능한 KB만 매칭)
     → 결과

Qdrant는 이 4-tier 자체를 코드로 하드코딩하지 않는다. payload 스키마가 YAML 설정이라, tier 종류를 늘리거나 조직의 RBAC 정책이 바뀌어도 컬렉션 구조를 새로 짜지 않고 설정만 반영하면 됐다 — 이게 개인 tier를 추가로 여는 결정이 부담 없었던 이유다.

권한 스택:

신원 확인   : Azure AD(Teams 싱글사인온) / OIDC(로그인 표준 프로토콜)
조직 동기화 : HR 시스템 ↔ 조직 디렉토리 sync
정책 엔진   : Casbin (RBAC/ABAC 정책 평가)
격리 실행   : Qdrant payload 필터 + tenant index
위반 감지   : 무필터 검색 차단 + 관측 알림(Datadog)

풀어 쓰면: 사용자가 Teams에 로그인한 세션(싱글사인온, SSO)을 그대로 넘겨받아 "이 사람이 누구인지"를 확인하고, 그 신원에 조직 위계에 따른 권한(역할 기반 접근제어, RBAC)과 민감도 등급에 따른 권한(속성 기반 접근제어, ABAC)을 함께 적용한다.

"kb_id는 장식이 아니다"

가장 중요한 깨달음 한 줄:

공유 컬렉션에서 kb_id는 cosmetic 메타필드가 아니라 _접근 경계_다.

per-KB 시절 kb_id는 그냥 라벨이었다. 통합 컬렉션에선 그게 벽이다. 그래서 우리는 이 계약을 검색 엔진이 소유하게 했다 — 호출자가 매번 필터를 깜빡하지 않도록, 엔진이 항상 강제한다.

그리고 fail-closed: 혹시라도 필터 없이 공유 컬렉션을 검색하려는 코드가 있으면? 거부하고 경보한다. "권한을 깜빡한 검색"은 버그가 아니라 보안 사고다. 그래서 무필터 공유-컬렉션 검색은 차단이 기본값이다.

출입증은 한 번 발급으로 끝나지 않는다

출입증에는 또 다른 함정이 있다. 발급하고 끝이 아니라는 것. 사람은 입사하고, 부서를 옮기고, 퇴사한다. 출입증이 그때그때 갱신되지 않으면 — 옮긴 부서의 문은 못 열고, 떠난 부서의 문은 여전히 열리는 유령 출입증이 남는다.

그래서 접근제어는 권한 로직 하나로 끝나는 일이 아니었다. 인사 시스템의 조직 정보와 지속적으로 동기화돼야 했다 — 누가 어느 조직에 속했는지가 바뀔 때마다, 그 사람의 출입증(payload 필터가 참조하는 신원)도 같이 갱신된다. 권한은 한 번 세우는 구조가 아니라, 계속 맞춰 나가야 하는 흐름이었다.

한 단계 더 — tier ABAC

같은 KB 안에서도 민감도(tier)가 다른 청크가 있다. 그래서 사용자 tier에 맞는 것만 통과시키는 속성 기반 접근제어(ABAC)를 공유 검색 경로에 얹었다. kb_id로 _어느 KB_를, tier로 _그 안의 어느 등급_까지를 거른다.

실전에서 — 4단계 권한이 3단계까지만 살아있었던 이야기

우리 시스템은 GLOBAL → BU → TEAM → PERSONAL, 4단계로 권한을 나눴다. 그런데 실제로 붙여보니 GLOBAL과 BU까지만 제대로 동작했다. TEAM과 PERSONAL은 설계는 있었지만, 코드는 "항상 빈 목록"을 돌려주는 껍데기였다 — 자기 팀 KB조차 누구도 볼 수 없는 상태로 방치돼 있었던 것.

원인을 파고들자 진짜 문제가 나왔다. 부서 매칭을 이름으로 하고 있었다. "인사팀"이라는 문자열이 인사 시스템 쪽과 우리 쪽에서 한 글자라도 다르면 — 매칭 실패, 그 사람은 자기 부서 KB를 못 본다. 조직개편 한 번이면 전체가 깨질 수 있는 구조였다.

고친 방법은 이름 대신 안정적인 코드를 쓰는 것이었다. 인사 시스템이 주는 고유 조직 코드를 사람의 신원 토큰에 실어 나르고, 그 코드로만 매칭한다. 이름은 바뀌어도 코드는 안 바뀐다. 그리고 그 코드를 매 HR 동기화마다 다시 써준다 — "출입증은 한 번 발급으로 끝나지 않는다"는 원칙을 코드로 만든 것.

심화 — 권한을 "검색 엔진이 소유"하게 만든 코드

이 절은 깊다. payload 필터가 실제로 어떻게 강제되는지 코드까지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① fail-closed는 문장이 아니라 코드다

앞에서 "무필터 검색은 차단이 기본값"이라 했다. 그 문장의 실체는 이렇다 — 공유 컬렉션을 kb_id 필터 없이 검색하려 하면, 검색 엔진이 거부하고 빈 결과를 돌려주며 경보를 쏜다. 에러로 죽이지도, 조용히 전체를 훑지도 않는다.

# 공유 프로파일 컬렉션은 여러 KB의 청크를 kb_id로 나눠 담는다.
# kb_id 필터 없이 조회 = KB 경계를 넘는 스캔(교차-KB 유출) → 거부.
if self._is_shared_profile_collection(collection_name, cfg) \
        and not self._filter_has_kb_id(filter_conditions):
    logger.error("공유 컬렉션 무필터 검색 거부 — kb_id 필터 없음: %s", collection_name)
    emit_silent_fail(area="kb_search", signal="profile_collection_unfiltered",
                     reason="no_kb_id_filter", collection=collection_name)
    return []   # ← raise가 아니라 "빈 결과 + 카운터"

이 계약을 검색 엔진이 소유한다. 동반 함수의 docstring이 이 글 본문 문장을 거의 그대로 적고 있다 — "kb_id는 cosmetic payload 필드가 아니라 접근 경계다. 검색 엔진이 이 계약을 소유하므로, 호출자가 매 진입점마다 같은 필터를 기억할 필요가 없다." 본문의 "검색 엔진이 소유"는 마케팅 문구가 아니라 실제 코드 주석의 의역이다.

② 영리한 선택 — 엔진을 새로 들이지 않고, 있는 걸 확장

조직 위계(org-tree) + 상속 + 민감도(tier) 속성을 한 번에 평가하는 이 문제엔 업계 정석이 여럿 있다. 우리가 비교한 4가지 — SharePoint식 site→library 상속, Confluence식 space 격리, Google Drive OU+공유드라이브, 그리고 Casbin/OpenFGA식 ReBAC 튜플. 개념적으로 가장 잘 맞은 건 ReBAC 튜플 shape(상속 있는 org-tree)였다.

그런데 우리는 그걸 위해 새 엔진(OpenFGA)을 들이지 않고, 이미 쓰던 Casbin 하나 안에서 표현했다 — Casbin의 role 계층(g)과 org-tree 그룹핑(g2)이 같은 shape를 추가 인프라 0으로 커버했기 때문. "새 문제 = 새 엔진"이 아니라 "있는 엔진의 표현력부터 확인"이 먼저였다. (model.conf엔 정밀도 선택도 박혀 있다 — keyMatch2 대신 keyMatch: keyMatch2는 :를 경로 파라미터로 취급해 mcp:adapter:tool 같은 식별자를 너무 넓게 매칭시키기 때문.)

③ 숫자, 정직하게 — 아직 없다

이 권한 엔진의 실측 성능 숫자(enforce() p99 latency 등)는 아직 없다. 설계 목표로 "org-tree 깊이 ≤5 → 정책 평가 <5ms p99"를 잡아뒀지만 그건 target이지 measured가 아니다. 여기서도 시리즈 규율을 지킨다 — 없는 숫자를 지어내지 않는다.

④ 우리가 처음엔 틀렸다 — 같은 기능, 두 경로가 조용히 갈라지다

본문의 "이름 매칭 → 조직 코드 매칭"은 신원 데이터가 시간이 지나며 낡는 이야기였다. 결이 다른 두 번째 사고가 하나 더 있다.

tier-ABAC(민감도 필터)가 같은 공유 컬렉션을 치는 두 경로 사이에서 비대칭이었다. 주(主) 검색 경로는 tier 필터를 제대로 걸었는데, 나중에 붙은 "보조" 경로는 안 걸었다. 요청이 어쩌다 보조 경로로 흐르면, 자기 tier보다 높은 청크가 조용히 보일 수 있었다 — 에러도 알림도 없이.

이걸 잡은 건 사용자 신고가 아니라 일부러 "두 경로가 대칭인가"를 감사한 것이었다("당연히 같겠지" 하고 안 보던 경로였으니까). 고친 방식이 흥미롭다 — 한 방에 안 고치고 3단계로: (1) 우선 무필터 스캔을 막는 fail-closed 가드(①)를 안전망으로 즉시 투입 → (2) 빠진 tier 필터를 보조 경로에 추가하되 기본 off인 feature flag 뒤에 둬서 격리 검증 → (3) 그다음에야 검색 실행기 전체를 tier-aware로 확장.

재발을 눈에 보이게 하려고 카운터 3개를 심었다: "무필터로 공유 컬렉션 도달"(항상 0이어야) · "tier 필터 빌더가 실패해 no-tier로 fallback"(항상 0이어야) · "tier 필터가 실제 적용됨"(이게 0인데 flag는 켜져 있으면 = 코드가 새 경로를 안 타는 silent no-op cutover 감지).

교훈: 신원 데이터가 낡는 것(본문)과, 같은 기능을 구현한 두 코드 경로가 조용히 갈라지는 것은 다른 종류의 사고다. 후자는 실패 신호를 기다리면 안 보이고, "대칭인지 일부러 확인"해야만 드러난다.

맺음 — 그리고 새로운 문제

출입증 구조(payload 필터 + fail-closed + tier ABAC)는 섰다. 통합 컬렉션의 효율을 가지면서도, 권한을 다시 세웠다.

그런데 1탄에서 배운 게 하나 있다. 구조가 섰다고 문제가 끝난 게 아니다. "코드에 출입증 검사가 있다"와 "모든 경로가 실제로 그 검사를 통과하는가"는 다른 질문이다. 새 경로가 하나 늘 때마다, 그 경로도 출입증을 확인하는지 계속 확인해야 한다 — 이것도 결국 저장 구조와 똑같이, _운영하면서 증명해야 하는 일_이다.

그리고 — 사용자는 여전히 한 줄로 묻지 않았다. "이 질문은 _어느 KB_를 봐야 하지?"가 남았다. 출입증은 "못 들어가는 문"만 막아줄 뿐, "이 사람이 평소 자주 드나드는 문이 어딘지"는 알려주지 않는다. 그걸 사람이 골라주던 시절의 한계, 그리고 그걸 에이전트에게 넘긴 이야기는 3탄-1부 — 사용자는 한 줄로 묻지 않았다에서.

시리즈: 1탄 저장 · 2탄 권한 (이 글) · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

[사내 지식 AI 만들기 ①·저장] 컬렉션이 KB만큼 늘어나기 시작했다

DarionKim — Tue, 30 Jun 2026 09:25:26 +0900

종합 공구 상자와, 내가 필요했던 전동 드릴

처음 사내에 RAG를 붙였을 때, 우리의 벡터 DB는 AWS OpenSearch였다 — 처음 도입한 1세대 지식 솔루션이 고른 선택이었다.

좋았다. 진심으로. 색인 만들고, 임베딩 넣고, k-NN 한 번 던지면 — 끝이었다. "이거면 되네?" 싶었다.

OpenSearch도, 그 뿌리인 Elasticsearch도 이미 검증된 솔루션이다. 누구도 쉽게 "나쁘다"고 말 못 한다. 로그도 보고, 전문 검색도 하고, 분석도 하고, 벡터도 한다. 뭐든 한다.

그게 정확히 문제였다.

그건 종합 공구 상자였다. 그런데 나는 벽에 구멍 하나 — RAG — 를 뚫어야 했다. 망치도 줄자도 필요 없었다. 나는 RAG 하나를 제대로 파는 전동 드릴이 필요했다.

이 글은 그 드릴을 찾아 Qdrant로 가고, 거기서 첫 번째 설계를 보기 좋게 말아먹고, 다시 설계한 이야기다.

1. 공구 상자의 한계 — 비용, 그리고 "RAG 특화"의 부재

작은 RAG에선 OpenSearch가 잘 돌았다. 그런데 사내 지식 전체로 미션이 커지자 두 가지가 보였다.

① 비용. 규모가 커질수록 운영 비용이 먼저 말을 걸어왔다.

② RAG 특화 기능의 부재. 이게 더 컸다. 좋은 한국어 enterprise RAG에 필요한 것들 —

dense(의미) + sparse(정확어) 하이브리드 검색
한 청크에 여러 임베딩 표현을 얹는 named vector
수십 KB·권한을 컬렉션 폭증 없이 다루는 payload 기반 멀티테넌시
토큰 단위 late-interaction rerank

— 공구 상자엔 "없거나, 직접 조립"이었다. 할 수는 있다. 다만 드릴 한 자루로 끝날 일을, 공구 상자 전체를 뒤지며 해야 했다.

[문서] → [임베딩] → OpenSearch k-NN → top-k → LLM → 답변
   ↑ 작을 땐 충분했다.  ↑ 사내 지식 "전체"엔 부족했다.

2. 미션, 그리고 전동 드릴(Qdrant)을 고르다

미션이 떨어졌다. "사내 지식 전체를 검색하게 만들어라."

지식 플랫폼을 만들려면 검색 엔진 요구사항이 달라진다. 우리가 본 기준:

요구	왜 필요했나
named vectors (dense+sparse+late-interaction)	의미 검색 + 정확어 검색을 한 포인트에
payload 기반 멀티테넌시	끝없이 늘어날 KB·권한을 컬렉션 폭증 없이
hybrid + rerank 네이티브	한국어 enterprise 검색 품질
self-host / 비용 통제	사내 데이터 + 규모

→ Qdrant. 종합 공구 상자가 아니라, RAG 하나를 제대로 파는 드릴.

현재 기술 스택:

임베딩(dense)  : OpenAI text-embedding-3-large
rerank         : Cohere rerank (LiteLLM 경유)
벡터 DB        : Qdrant (named vectors + payload multitenancy)
그래프 컨텍스트: Neo4j

3. 첫 번째 실수 — KB 하나에 컬렉션 하나

드릴을 손에 쥐고, 우리는 가장 자연스러운 첫 설계를 했다. KB 하나 = Qdrant 컬렉션 하나.

CVS-KB     → collection: kb_cvs
HR-KB      → collection: kb_hr
물류-KB    → collection: kb_logistics
...

단일 KB 검색은 단순하고, 격리도 물리적으로 깔끔하다. 데모는 예뻤다.

그리고 — 우리는 이 구조의 실패를 이미 한 번 맛본 적이 있었다. 알면서도, 처음엔 또 직관을 따랐다.

문제는 KB가 늘 때 터진다:

교차 KB 질문 1건
   └─▶ N개 컬렉션에 각각 질의  →  클라이언트에서 결과 합치기
       (N = KB 수.  KB가 늘수록 비용·복잡도·운영지옥이 선형으로 증가)

컬렉션 수 = KB 수 → 지식이 늘면 컬렉션 폭증
교차/멀티 KB 검색은 매번 fan-out
임베딩 버전·인덱스 설정 같은 공통 정책을 N곳에 반복

사내 지식은 고정돼 있지 않다. 새 부서, 새 제품, 새 규정 — KB가 끝없이 추가된다. 컬렉션이 KB만큼 늘어나기 시작한 순간, 이 구조의 수명은 정해져 있었다.

4. 다시 설계 — 운영 경계로 나눈 통합 컬렉션

그래서 1:1을 버렸다. 업계 선진사례(Qdrant·Azure AI Search·Elastic)의 공통 원칙은 같았다:

컬렉션은 운영 경계(콘텐츠 종류·테넌트·라이프사이클·ACL)로 나눈다. KB로 나누지 않는다. 같은 청크의 다른 임베딩 표현은 named vector로, 테넌트/KB 격리는 payload 필터 + 테넌트 인덱스로.

        통합 텍스트 컬렉션 (모든 KB 공유)
        ├─ named vector: dense(의미)  [+ sparse(정확어) — 품질 반전은 아래 §5]
        └─ payload: { tenant, kb_id, tier, acl, ... }
                            ▲
        질의 시: payload 필터로 "이 사용자가 접근 가능한 KB"만 조회
        (시각 자산은 별도 통합 컬렉션 — 텍스트와 다른 point population이므로)

효과는 즉각적이었다. KB가 100개 추가돼도 컬렉션은 그대로다. 교차 KB 검색은 단일 질의 + 필터. 새 KB 온보딩은 "컬렉션 생성"이 아니라 "payload 태깅". 끝없이 자라는 지식 범위에 드디어 대응이 된다.

심화 — 1:1 구조 vs 통합 구조, 코드 레벨로 뜯어보기

이 절은 깊다. 왜 1:1을 버렸는지 메커니즘까지 궁금한 분을 위한 detail이다. 바쁘면 §5로 건너뛰어도 좋다.

한눈에:

차원	1:1 (KB = 컬렉션)	통합 (운영 경계)
매핑	KB N개 = 컬렉션 N개 (`kb_<id>`)	content type별 소수 (텍스트 / 시각자산)
분리 기준	KB	point population (콘텐츠 종류)
격리	물리 (컬렉션 경계)	논리 (payload 필터 + 인덱싱된 필드)
벡터	컬렉션마다 dense + sparse	한 포인트에 named vector 다중
교차 KB 검색	N개 fan-out + 클라이언트 병합	단일 질의 + 필터 (서버사이드)
융합(fusion)	클라이언트가 점수 섞기	서버사이드 RRF
재색인	컬렉션별	alias blue/green 무중단
비용	컬렉션·HNSW 그래프 N배	소수 고정

표만으론 왜 그런지 안 보인다. 핵심 메커니즘 5개를 뜯어보자.

① named vector — "컬렉션을 늘리지 말고, 포인트에 표현을 얹어라"

흔한 오해: "dense랑 sparse는 다른 검색이니 컬렉션을 따로 만들자." 틀렸다. Qdrant에선 한 포인트에 여러 벡터를 이름 붙여 얹는다.

point {
  vectors: {
    dense   : [1536차원]      # 의미(dense)
    sparse  : {index: value}  # 정확어(sparse, 희소)
    colbert : 토큰별 multivector  # (설계) 재정렬 전용
  },
  payload: { tenant_id, kb_id, tier, acl, ... }
}

같은 청크의 다른 표현이 같은 포인트에 사니, 질의 때 dense·sparse를 함께 쓸 수 있다. 컬렉션을 새로 만드는 건 "벡터 종류"가 달라서가 아니라, "포인트 집단(콘텐츠 종류)"이 다를 때만이다. 텍스트 청크와 이미지/표 자산은 다른 집단이라 컬렉션을 나눴고, dense·sparse·ColBERT는 같은 청크라 named vector로 얹었다.

② payload 멀티테넌시 — 공유 컬렉션에서 "내 KB만" 좁히기

"다 합치면 느리지 않나?" 통합 컬렉션은 tenant_id / kb_id를 인덱싱된 payload 필드로 두고, 질의 시 그 필드로 먼저 좁힌 다음 벡터를 본다. 물리 분리 없이도 "내가 접근 가능한 KB만" 검색 범위에서 걸러낸다. 1:1이 "물리 벽으로 격리"했다면, 통합은 "인덱스로 격리"한다.

여기에 Qdrant는 한 단계 더 — 테넌트 수가 많을 때를 위한 tenant 전용 최적화 인덱스(is_tenant: true)를 제공한다. 정확히 이 용도다. 그런데 정직하게: 우리 라이브 컬렉션 생성 코드는 아직 plain keyword index만 부른다. tenant 최적화 인덱스는 "쓸 수 있는데 아직 안 켠" 상태다 — 이 얘기는 §심화 애프터노트에서 다시 한다(이 글이 자기 반전을 한 번 더 겪는 자리다).

③ 서버사이드 hybrid — prefetch + RRF (클라이언트 fan-out과 다른 점)

1:1에서 교차 KB 검색은 — N개 컬렉션에 각각 질의하고, 클라이언트가 서로 다른 점수 체계를 제멋대로 섞어 병합했다. 통합에선 Qdrant Query API가 서버 안에서 처리한다:

prefetch(sparse, limit=100)  ─┐
prefetch(dense,  limit=100)  ─┤→  RRF(서버사이드 순위 융합)  →  [선택] ColBERT 재정렬  →  top_n
                              ┘

여기서 RRF(Reciprocal Rank Fusion)는 저장 구조가 아니라 질의 융합 방법이다. 흔한 오해: "RRF 컬렉션이나 RRF 벡터를 만들자" — 그런 건 없다. RRF는 여러 prefetch 순위 리스트를 질의 시점에 합칠 뿐이다.

정직하게: 현재 prod 서빙은 dense 1선 + 외부 rerank다. sparse·RRF·ColBERT는 구조가 지원하지만 아직 품질 로드맵(§5)이다. "구조가 지원한다"와 "서빙 경로가 그걸 쓴다"는 다른 일 — 이게 바로 이 글의 반전이다.

④ 멱등 point_id — 재색인해도 중복이 안 생기는 이유

1:1에서 흔한 사고: 재색인하면 같은 청크가 또 들어가 중복이 쌓인다. 통합에선 결정적(deterministic) ID를 쓴다.

point_id = {tenant}:{kb}:{document}:{page}:{chunk}:{embedding_version}

같은 청크는 항상 같은 ID → upsert가 덮어쓴다. 재색인이 안전해지고, 임베딩 버전을 ID에 넣으니 버전 교체도 깔끔하다.

⑤ HNSW 비용 + blue/green alias

컬렉션마다 HNSW 그래프가 따로 선다. 컬렉션 N개 = 그래프 N개 = 메모리·관리 비용 N배. 통합은 2개로 끝. 그리고 ColBERT 같은 재정렬 전용 벡터는 hnsw_config.m = 0으로 둔다 — 그래프를 아예 안 만들고 선형 스캔한다. 재정렬은 이미 추려진 후보만 보니 인덱스가 낭비이기 때문이다. 재색인이 필요하면 새 물리 컬렉션을 만들어 backfill한 뒤 alias만 바꿔(blue/green) 무중단으로 전환하도록 설계했다 — 코드도 있고 테스트도 됐다. 다만 이건 feature flag로 켜고 끄는데, 지금 라이브에선 꺼져 있다(그래서 실제 alias는 아직 0개). "만들어 두고 아직 안 켠" 메커니즘이다. 이것도 §애프터노트에서 다시.

⑥ 결정을 문서가 아니라 코드로 못 박기 (architecture-as-code)

"1:1을 버리고 통합으로 간다"는 건 설계 문서 한 줄로 끝날 수도 있었다. 문제는 — 문서는 읽지 않으면 그만이고, 6개월 뒤 누군가 "이 KB는 특별하니까 전용 컬렉션 하나 파자"라고 하면 조용히 원점이다. 그래서 우리는 이 결정을 런타임에서 강제했다.

ADR012_PROFILE_COLLECTIONS = frozenset({ "<통합 텍스트 컬렉션>", "<통합 시각자산 컬렉션>" })

def _assert_legacy_collection_creation_allowed(self, *, kb_id, collection_name):
    """ADR-012 컷오버 후, 실수로 per-KB 컬렉션을 만드는 걸 차단."""
    if self._provider.config.allow_nonstandard_collection_creation:
        return  # 명시적·시한부 레거시 마이그레이션 창구에서만
    raise NonStandardQdrantCollectionError(
        f"비-ADR-012 컬렉션 생성 거부: kb_id={kb_id!r}, collection={collection_name!r}. "
        "통합 프로파일 컬렉션을 쓰거나, 환경변수로 명시적 마이그레이션 창을 열어라."
    )

레거시 per-KB 컬렉션 생성 경로로 들어오는 모든 호출은 sanctioned된 통합 컬렉션 이름 집합과 대조되고, 새 비표준 컬렉션은 명시적으로 이름 붙은 환경변수 escape hatch를 켜지 않는 한 기본적으로 거부된다. 결정이 문서로만 남지 않고 구조적으로 회귀 불가능해지는 것 — 앞 표의 "매핑: content type별 소수"가 지켜지는 진짜 이유다.

이 여섯이 "1:1을 버린 이유"의 실체다. 앞 표의 각 줄 뒤엔 이 메커니즘이 있다.

심화 애프터노트 — 이 글을 쓰고, 코드를 다시 봤더니

솔직한 고백으로 이 심화를 닫자. 위 ②(tenant 최적화 인덱스)와 ⑤(alias 무중단 전환)를 처음 쓸 때 우리는 "이렇게 한다"고 적었다. 발행하고 나서 코드를 다시 열었더니 — 서술이 코드보다 앞서 있었다. tenant 전용 인덱스는 라이브가 아직 안 부르고 있었고, alias 전환은 flag가 꺼져 실제 alias가 0개였다. 둘 다 "구조는 지원, 서빙은 아직" — 이 글 §5가 말하려는 바로 그 gap을, 이 글 자신이 저지르고 있었다. 그래서 위 두 문단을 고쳐 썼고, 이 애프터노트를 남긴다. 완료를 다시 정의한 글이 자기 서술까지 receipt로 검증받지 않으면 그건 위선이니까.

그리고 이왕 고백하는 김에 — ④(멱등 point_id)에도 뒷이야기가 있다. 결정적 ID는 재색인 시 중복을 막아준다. 그런데 그게 point-id의 타입 일관성까지 보장하진 않았다.

Qdrant의 point ID는 부호 없는 정수 아니면 UUID 문자열이어야 한다 — 절대 "정수를 문자열로 담은 값"이면 안 된다. Qdrant가 문자열 ID는 UUID로 파싱하려 들기 때문이다. 그런데 서로 다른 시기에 서로 다른 ingest 소스로 들어온 탓에, 두 개의 KB만 정수 ID로 색인돼 있었고 나머지는 전부 UUID 문자열이었다. 후보를 추린 뒤 본문·late-interaction 벡터를 다시 당겨오는 hydration 경로가 모든 ID를 일괄 stringify해서 Qdrant retrieve를 불렀고 — 정수-ID KB는 hydration이 100% "UUID 파싱 실패"로 떨어졌다. 그러면 재시도 루프가 돌면서 그 두 KB에서 나온 답변마다 약 24초가 얹혔다. 조용히 느려지기만 하다가, 하필 채팅 채널 sync timeout이 터지면서 사용자 눈에 보였다.

고친 건 작은 타입 강제 헬퍼 하나였다(전부 숫자면 int, 아니면 str 유지) + 다시 뒤집히지 않게 UUID 경로를 지키는 회귀 테스트. 교훈: 결정성(④)은 idempotent upsert를 보장하지만, 여러 ingest 소스로 유기적으로 자란 corpus에서 point-id "타입"의 일관성은 그와 별개의 두 번째 invariant였다 — 우리가 한 번 데어보고 배운.

이 세 자리(② ⑤ 정정 + point-id 사고)가 서로 다른 얼굴로 같은 말을 한다. 저장 구조가 "완성"돼도, 그게 라이브에서 그대로 도는지는 계속 다시 확인해야 한다. 그래서 ⑥처럼 결정을 코드에 못 박고, 이런 애프터노트를 남긴다.

벡터 옆에, 그래프 — "비슷한 것"과 "연결된 것"

지식을 잘 저장한다는 건 벡터만 잘 넣는 게 아니었다. 실제 업무 질문은 자주 관계로 온다.

"이 시스템과 연결된 담당 부서는?"
"이 장애가 어느 프로세스의 다음 단계랑 이어져?"
"A 문서엔 없는데, B와 연결하면 답이 나오는 질문"

벡터 검색은 "비슷한 문장"엔 강하지만 이런 연결 질문엔 약하다. 그래서 우리는 지식을 두 가지로 저장한다 — *Qdrant(벡터, 비슷함) + Neo4j(그래프, 연결).** 그래프의 엣지는 *수집 시점에 같이 쌓인다.

그런데 여기서 또 한 번 멈췄다. 검증 안 된 그래프 검색을 일반 봇 답변 경로에 바로 섞으면, 잘 답하던 대화 품질이 흔들릴 수 있다. 켜보고 측정했더니:

항목	상태
그래프 데이터(Neo4j)	있음 — 연결 재료는 쌓여 있다
그래프 확장기	동작 (chunk 1개 → 관련 후보 10개)
교차-KB 탐색	timeout — 답변 경로에 바로 넣기엔 불안정
검색 개선	0건 케이스 존재 — 항상 개선하진 않음
답변 경로	원복 — 기존 봇 답변 품질 보호 우선

→ "그래프가 나쁘다"가 아니라 "지금 전체 답변 경로에 켜는 방식이 맞지 않는다." 그래서 그래프는 답변 경로가 아니라 검증 레이어에 먼저 둔다:

① 답변 경로 유지 (그래프 마스터 기본 off)
② 전용 eval 경로 (실사용 질문 X, 검증용 질문 세트로 그래프 vs 벡터 비교)
③ 성공 조건 (timeout 없음 · 벡터-only 대비 recall↑ · 근거↑ · latency OK · 회귀 0)
④ 그 다음 좁은 canary (특정 KB · 질문 유형 · 봇만)

핵심은 GraphRAG의 가치는 대체*가 아니라 관계형 질문 *보강이라는 것, 그리고 증명되기 전엔 답변 품질을 지킨다는 것이다.

5. 반전 — "구조 완성"이 "검색 품질 완성"은 아니었다

저장 구조를 닫고 나서, 우리는 값진 걸 배웠다. 저장을 잘 설계한 것과 검색이 좋아진 것은 다른 일이었다.

특히 짧은 한국어 현장어 — "침수", "미송", "담배권", "재고감모" — 같은 질문. 의미(dense) 검색은 긴 문장엔 강하지만 이런 정확어엔 약하다. 설계엔 dense+sparse 하이브리드가 분명히 있었다. 그런데 "구현돼 있다"와 "서빙 경로가 그걸 쓴다"는 다른 일이었다. 실제로는 색인 파이프라인이 sparse named vector를 채워 넣긴 하는데, 질의 서빙 프로세스가 sparse 인코더를 일부러 로드하지 않는다(자원 트레이드오프 설정). 그래서 hybrid fusion 질의는 dense·sparse 두 다리에 똑같이 가중치를 주고 돌지만, sparse 다리는 매번 빈손으로 돌아온다.

이걸 어떻게 살릴지도 하나의 선택이었다. 우리가 지금 검토 중인 안(내부 ADR, 아직 PROPOSAL)은 dense 모델은 그대로 두고, sparse 전용 로컬 인코더만 질의 pod에 얹는 것 — 이미 만들어 둔 RRF 융합의 sparse 다리에 드디어 질의 시점 벡터를 주는, 가장 가벼운 변경이다. 기각한 대안은 임베딩 모델 전면 교체(dense+sparse+late-interaction을 한 모델이 함께 뽑도록): 이미 결론 난 임베딩 전략 ADR을 다시 열고, 전체 corpus를 blue/green으로 재색인해야 해서 무겁다. 근거로 인용한 숫자는 공개 논문 하나 — BGE-M3 논문(Table 2)이 한국어 검색에서 hybrid가 dense-only로 퇴화하면 약 -1.4 nDCG@10을 추정한다. 다만 같은 조건의 내부 paired 벤치는 아직 "미측정"이다. 외부 인용 + 구조적 gap 추적은 있고, 내부 하드 넘버는 없다 — 그것까지 정직하게 적는다. 벡터 하이브리드든, 위의 그래프든 — 결국 똑같이 "저장은 됐지만, 답변 품질로 증명돼야 완료"다.

그래서 우리는 "완료(Done)"를 다시 정의했다.

PR 머지 / dev에서 켜짐 / "코드에 있음" → 완료 아님
실제 사용자가, 측정된 품질로, 운영 경로에서, 영속된 증거(receipt)와 함께 더 나은 답을 받을 때 완료

이걸 팀의 엔지니어링 표준(4-layer Receipt)으로 못 박았다 — 저장 구조의 완성이, 검색 품질의 완료를 다시 정의하게 만든 자리에서.

(품질 coda): 첫 파일럿은 OFC봇이었다. 실제 사용자 로그에서 나온 짧은 질문 20건을 dev 운영 경로로 다시 흘려보냈다. 개선 전에는 답변은 생성됐지만 근거 문서를 찾지 못한 케이스가 많았다. 개선 후 근거 문서 연결률은 35%에서 100%로 올랐다(+65%p). 평균 근거 문서 수는 0.9개에서 4.15개로 늘었고, 약한 케이스는 13건에서 0건으로 줄었다.

6. 맺음 — 그리고 새로운 문제

드릴은 손에 익었다. 전동 드릴(Qdrant)로 구멍 뚫는 법 — 통합 컬렉션 + named vector + payload — 도 배웠다. 끝없이 자라는 사내 지식을 컬렉션 폭증 없이 저장하는 구조는 완성됐다.

그런데 지식을 한곳에 모으자 곧바로 새로운 질문이 생겼다.

"이제 누가, 무엇을, 볼 수 있지?"

물리적으로 분리돼 있던 격리가 사라졌으니, 권한을 다시 세워야 했다. 그 이야기는 2탄 — 지식을 한곳에 모았더니, 아무나 다 볼 수 있게 됐다에서.

시리즈: 1탄 저장 (이 글) · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

쇼핑에 영상을 더하다: Part 3. 이해한 영상을 추천으로 연결하기

세우초밥 — Thu, 9 Apr 2026 18:01:49 +0900

시리즈 목차

고객이 워킹화 숏폼을 클릭했을 때, 추천 시스템은 무엇을 기록했을까요?

아마 이렇게 남겼을 겁니다. "운동화 선호". 맞는 말이긴 한데, 뭔가 많이 잘려나간 느낌이 듭니다.

고객이 실제로 반응한 건 운동화라는 카테고리가 아니라, 영상이 전달한 "편안하고 활동적인 일상"이라는 맥락이었을지도 모릅니다. 그 차이를 시스템이 읽지 못하면, 추천은 늘 비슷한 운동화만 반복하게 됩니다.

Part 1에서는 숏픽 추천이 어떻게 진화해 왔는지, Part 2에서는 왜 영상을 중요한 신호로 봐야 하는지를 다뤘습니다.

이번 글은 그 다음 이야기입니다. 영상에서 읽어낸 의미를 실제 추천 시스템에 어떻게 연결했는지, 그 과정을 정리해 보려고 합니다.

GS SHOP은 상품 데이터만 많은 커머스가 아니라, 방송 영상, 숏폼 콘텐츠, 고객 행동 데이터가 함께 축적되는 환경을 가지고 있습니다. 그렇기 때문에 이 문제는 단순히 "영상을 분석해 보자"는 실험이 아니라, 기존 커머스 추천 시스템이 활용하지 못했던 신호를 실제 서비스에 어떻게 편입할 것인가에 중점을 두었습니다.

GS SHOP에서는 왜 이 문제가 중요했을까

홈쇼핑과 커머스 서비스에서 영상은 오래전부터 중요한 자산이었습니다. 상품명, 가격, 카테고리, 리뷰, 대표 이미지 같은 정형 정보만으로도 기본적인 추천은 충분히 가능합니다. 실제로 많은 추천 시스템이 이런 신호들 위에서 잘 동작해 왔습니다.

하지만 GS SHOP이 다루는 콘텐츠는 그보다 훨씬 풍부합니다. 라이브 방송에는 쇼핑호스트의 설명, 시연 장면, 사용 맥락, 비교 포인트가 담겨 있고, 숏픽 같은 숏폼에는 짧은 시간 안에 상품의 핵심 메시지와 사용 장면이 압축되어 있습니다.

문제는 기존 추천 시스템이 이런 차이를 대부분 상품 중심의 정형 신호로만 읽고 있었다는 점입니다. 예를 들어 같은 패션 상품이라도 영상에서는 "체형 커버", "출근룩", "편안한 착용감"처럼 전혀 다른 메시지가 강조될 수 있고, 같은 리빙 상품이라도 "캠핑", "전자레인지 사용 가능", "정리 수납"처럼 고객이 반응하는 포인트가 달라질 수 있습니다.

즉, GS SHOP 입장에서는 이미 충분한 영상 자산을 가지고 있었지만, 추천 시스템이 그 안의 의미를 충분히 활용하지 못하고 있었습니다.
이 간극을 메우는 것이 이번 작업의 출발점이었습니다.

기존 추천의 한계

숏픽 추천은 꾸준히 발전해 왔지만, 한 가지 전제는 꽤 오랫동안 유지되고 있었습니다. 숏픽이 노출되더라도, 어떤 영상을 보여줄지는 결국 상품 추천 결과에 따라 결정되는 구조였습니다. 즉, 추천의 중심은 여전히 상품이었고, 입력 신호 역시 상품 ID, 카테고리, 브랜드 같은 정형 데이터가 대부분이었습니다.

이 구조는 상품 추천 관점에서는 충분히 합리적이었습니다. 하지만 영상 추천 관점에서는 분명한 한계가 있었습니다.

고객이 무엇을 클릭했는지는 볼 수 있었지만, 왜 반응했는지는 알기 어려웠습니다.

예를 들어 고객이 어떤 숏픽을 클릭했을 때, 시스템은 이를 "이 상품을 좋아했다" 정도로만 해석할 수 있었습니다. 하지만 실제 고객은 상품 자체보다 영상이 전달한 분위기, 사용 상황, 스타일링, 기능성 같은 요소에 더 크게 반응했을 수도 있습니다. 즉, 영상은 노출되고 있었지만, 영상 안에 담긴 맥락은 추천에 거의 쓰이지 못하고 있었습니다.

이 구조는 서비스 운영 관점에서는 이해할 수 있는 선택이기도 했습니다. 기존 추천 시스템은 상품 추천을 중심으로 발전해 왔고, 영상은 그 결과를 보조적으로 보여주는 방식이 더 단순하고 안정적이었기 때문입니다. 다만 숏폼과 영상 소비가 커질수록, 추천 시스템 입장에서는 조금 난감해졌습니다. 고객은 분명히 영상에 반응하고 있는데, 시스템이 읽을 수 있는 것은 여전히 상품 코드 중심이었기 때문입니다.

클릭을 다시 해석하기

그래서 저희는 숏픽 클릭을 조금 다르게 보기 시작했습니다.

영상 클릭은 단순한 상품 선호가 아니라, 고객 취향의 단서를 남긴다.

예를 들어 워킹화 숏폼을 클릭한 고객을 생각해보겠습니다. 기존 방식이라면 이를 "운동화 선호"로 해석하기 쉽습니다. 하지만 실제로는 편안함, 기능성, 활동적인 라이프스타일, 실용적인 코디에 반응했을 가능성이 더 클 수 있습니다.

이 차이는 생각보다 중요합니다. "운동화"라는 카테고리 하나로 해석하면 비슷한 상품만 반복 추천하게 되지만, "편안하고 활동적인 스타일"이라는 맥락으로 해석하면 다른 상품군까지도 더 자연스럽게 연결할 수 있기 때문입니다.

그래서 저희는 숏픽 클릭을 상품 선호가 아니라 맥락 선호, 혹은 취향 신호로 해석해 보기로 했습니다.
조금 과장해서 말하면, 고객은 꽤 풍부하게 반응하고 있었는데 시스템이 너무 단순하게 받아쓰고 있었던 셈입니다.

영상만이 줄 수 있는 신호, 소구 포인트

문제는 여기서 끝나지 않았습니다. 영상에서 의미를 읽었다고 해도, 추천 시스템이 그대로 이해해 주는 것은 아니기 때문입니다. 추천 시스템은 결국 숫자와 점수로 움직입니다. 그래서 영상이 전달하는 설명을 추천에 활용할 수 있도록 구조화한 개념이 바로 소구 포인트입니다.

소구 포인트는 고객이 영상에서 실제로 반응했을 만한 핵심 메시지입니다. 예를 들면 "전자레인지 OK", "캠핑용", "실용성", "기능성", "활용도 높은 스타일링" 같은 표현들입니다.

여기서 중요한 점은, 카테고리나 브랜드는 이미 기존 추천 신호가 어느 정도 잘 설명하고 있었다는 점입니다. 그래서 영상에는 영상만이 드러낼 수 있는 신호를 맡기기로 했습니다. 즉, 영상에서 소구 포인트를 추출하고, 이를 임베딩해 비슷한 맥락의 영상을 찾을 수 있도록 설계했습니다. 이렇게 하면 고객이 최근 반응한 영상과 비슷한 결을 가진 다른 영상이나 상품을 추천 후보로 활용할 수 있습니다.

영상 임베딩, 무엇을 담아야 할까

처음에는 영상 전체를 설명하는 긴 텍스트를 임베딩해 유사 영상을 찾는 방식도 시도했습니다. 결과는 꽤 그럴듯해 보였습니다. 그런데 자세히 들여다보니, 비슷하다고 묶이는 영상들이 대부분 같은 카테고리나 같은 브랜드 숏폼이었습니다. 영상을 열심히 읽었는데, 결국 상품 코드 근처를 맴도는 결과였습니다. 원점에 가까웠습니다.

그래서 방향을 조금 바꿨습니다. 카테고리와 브랜드 선호는 기존 상품 추천이 맡고, 영상 쪽은 소구 포인트 키워드 자체를 더 잘 표현하도록 역할을 분리했습니다. 결과적으로 Pegasus와 Claude를 통해 추출한 소구 포인트를 임베딩하고, 그 벡터를 기반으로 비슷한 맥락의 영상을 찾는 구조로 정리할 수 있었습니다.

소구 포인트 임베딩은 처음에는 더 높은 차원으로 다뤘지만, 검색 속도와 저장 비용을 함께 고려해야 했습니다. 실서비스에서는 추천 품질뿐 아니라 인덱싱 비용, 조회 속도, 운영 복잡도도 함께 봐야 하기 때문입니다. 그래서 정보 보존율, 복원 오차, 유사도 유지율, 검색 속도 등을 비교하며 차원 축소를 진행했고, 운영 가능한 수준으로 최적화했습니다. 상품 임베딩과 같은 차원으로 맞춰 둔 덕분에 운영 측면에서도 훨씬 단순한 구조를 만들 수 있었습니다.

기존 추천을 버리지 않고, 얹었습니다

영상 신호를 도입한다고 해서 기존 추천 엔진을 처음부터 다시 만들지는 않았습니다. 오히려 저희가 택한 방식은 반대에 가까웠습니다.

기존 추천을 버린 것이 아니라, 영상 맥락 신호를 그 위에 얹었습니다.

기존에는 상품 점수, 카테고리 선호, 인기나 평점 같은 신호들이 추천의 중심을 이루고 있었습니다. 여기에 "이 고객이 최근 반응한 영상과 얼마나 비슷한 맥락인가"라는 영상 신호를 추가해, 최종 추천 점수를 함께 계산하도록 설계했습니다.

이 선택은 기술적으로도 중요했습니다. 새로운 추천 시스템을 별도로 만들면 품질 검증, 운영, fallback, 기존 지표와의 비교가 모두 어려워집니다. 반면 기존 추천 로직 위에 영상 신호를 레이어처럼 얹는 방식은, 기존 시스템의 안정성을 유지하면서도 새로운 신호의 효과를 상대적으로 명확하게 검증할 수 있다는 장점이 있었습니다. 말 그대로 "다 뜯어고치기"보다 "잘 쓰던 엔진에 새 감각을 붙이는" 쪽에 가까웠습니다.

이 구조를 저희는 Hybrid라고 부릅니다. 기존 추천의 강점은 유지하되, 영상이 전달하는 의미를 새로운 레이어로 더한 방식입니다.

영상은 의미를 담고 있고, 행동은 의도를 담고 있습니다

영상 기반 추천을 설계하면서 가장 중요하게 본 것은, 영상과 행동이 서로 다른 역할을 한다는 점이었습니다.

영상은 의미를 담고 있고, 행동은 의도를 담고 있습니다.

영상 쪽에서는 소구 포인트를 임베딩한 뒤 OpenSearch에서 유사한 맥락을 찾도록 했습니다. 반면 행동 쪽에서는 고객이 최근 어떤 영상을 클릭하고 시청했는지, 어떤 맥락에 반응했는지를 Redis에 빠르게 조회할 수 있는 형태로 쌓았습니다. 그리고 추천 시점에는 API가 이 두 정보를 함께 조회해 최종 추천을 만듭니다.

즉, "이 영상이 어떤 메시지를 갖고 있는가"와 "이 고객이 최근 어떤 메시지에 반응했는가"를 한 번에 보는 구조입니다. 조금 더 기술적으로 설명하면, 전체 구조는 크게 세 단계로 나눌 수 있습니다.

오프라인 처리 단계
영상에서 소구 포인트를 추출하고 임베딩을 생성해 검색 가능한 형태로 적재합니다.
행동 집계 단계
고객의 클릭·시청 로그를 바탕으로 최근 선호 맥락을 사용자 단위로 누적합니다.
온라인 추천 단계
추천 요청 시 OpenSearch에서 의미 기반 후보를 찾고, Redis에서 사용자 행동 기반 선호를 조회한 뒤, 여러 점수를 합산해 최종 결과를 반환합니다.

이렇게 역할을 나눈 이유는 명확합니다. 영상 의미를 계산하는 작업은 상대적으로 무겁고, 사용자 반응은 빠르게 갱신되어야 하며, 최종 추천 응답은 짧은 시간 안에 끝나야 하기 때문입니다. 한 시스템이 모든 걸 한 번에 다 잘해주기를 기대하기보다는, 각 단계가 잘하는 일을 나눠 맡기는 편이 훨씬 현실적이었습니다.

행동을 어떻게 선호도로 바꿨을까

행동 신호를 설계할 때는 단순 노출을 그대로 선호도로 보지 않았습니다. 대신 실제 시청과 클릭 행동을 중심으로, 의도 수준이 다른 행동을 구분해서 반영했습니다.

예를 들어 상품 클릭, 상품 상세 진입, 이벤트 클릭처럼 구매나 전환에 더 가까운 행동에는 더 높은 가중치를 두고, 재생, 끝까지 시청, 썸네일 클릭처럼 관심을 보여주는 행동은 그보다 낮은 단계의 선호 신호로 반영했습니다.

정리하면 행동 신호는 크게 두 층으로 나눌 수 있습니다.

구매·전환에 가까운 행동: 상품 클릭, 상품 상세 진입, 이벤트 클릭
관심에 가까운 행동: 재생, 끝까지 시청, 썸네일 클릭, 추천 영역 진입

중요한 점은, 보였다는 사실 자체보다 실제로 반응했는가를 더 강한 신호로 봤다는 것입니다. 숏폼 영역은 노출 위치나 UI 구조의 영향도 크기 때문에, 단순 impression까지 그대로 선호 신호로 쓰면 오히려 의도가 흐려질 수 있다고 판단했습니다. 또한 최근 행동일수록 더 큰 의미를 갖도록 반감기 개념을 적용해 시간에 따라 점수가 자연스럽게 감쇠되도록 설계했습니다. 이렇게 하면 오래전 행동보다 지금 고객이 실제로 관심을 보이는 맥락을 더 잘 반영할 수 있습니다.

선호도 저장 역시 무한정 누적하지 않았습니다. 실시간 조회가 필요한 데이터인 만큼 사용자별 상위 선호 항목만 유지하는 방식으로 관리했고, 이를 통해 추천 시점의 조회 비용과 응답 시간을 함께 제어했습니다. 선호도 점수는 개념적으로 보면, 낮은 구간은 "얼마나 오래 봤는가"에 더 가깝고, 높은 구간은 실제 클릭이나 상세 진입 같은 행동이 붙으면서 올라가는 구조입니다. 즉, 단순 시청과 적극적인 반응을 같은 무게로 보지 않도록 설계했습니다.

최종 추천 점수는 어떻게 만들었을까

최종 추천은 크게 다섯 단계를 거쳐 계산했습니다.

상품 점수
최근 클릭한 상품을 기준으로 유사 상품을 찾고, 최근에 클릭한 상품일수록 더 높은 가중치를 둡니다.
숏폼 점수
최근 선호한 숏폼을 기준으로 유사 숏폼을 찾고, 해당 숏폼에 대한 사용자 선호 점수를 함께 반영합니다.
카테고리 점수
사용자의 대/중 카테고리 선호를 반영해, 평소 관심을 보이던 축에 맞는 상품에 점수를 더합니다.
최종 점수 계산
상품, 숏폼, 카테고리, 평점 등 여러 신호를 가중 합산해 1차 점수를 만듭니다. 이때 상품과 숏폼 신호를 중심에 두고, 카테고리와 평점은 보조 신호로 활용했습니다.
후처리
마지막으로 MMR(Maximal Marginal Relevance)을 적용해 유사도뿐 아니라 다양성까지 함께 고려합니다.

이 과정의 핵심은 단순히 비슷한 것을 찾는 데서 멈추지 않는다는 점입니다. 고객이 좋아할 가능성이 높은 후보를 모으고, 그 안에서 너무 비슷한 결과만 반복되지 않도록 다시 한 번 정리해 주는 구조입니다.

특히 GS SHOP 같은 커머스 환경에서는 정확도만큼이나 구성의 다양성도 중요합니다. 비슷한 맥락을 잘 맞추더라도 결과가 지나치게 한쪽 카테고리나 유사 상품군에 쏠리면 서비스 품질은 오히려 떨어질 수 있습니다. 그래서 MMR은 단순한 후처리가 아니라, 실제 사용자 경험을 보정하는 중요한 단계로 작동했습니다.

구현하면서 함께 고민한 것들

실서비스에 연결하는 과정에서는 추천 품질만큼이나 서빙 안정성도 중요했습니다. 그래서 Redis 조회와 상품/숏폼/카테고리 추천 계산은 가능한 한 병렬로 처리해 지연 시간을 줄였고, 여러 소스에서 같은 상품이 동시에 추천되면 하나로 묶어 점수를 통합했습니다. 이때 같은 상품이 여러 추천 소스에서 반복해서 등장하면 단순 중복 제거로 끝내지 않고, "여러 관점에서 동시에 추천된 후보"라는 의미로 보고 소량의 추가 점수를 주는 방식도 함께 사용했습니다. 완전히 새로운 규칙을 더한 것은 아니지만, 여러 신호에서 공통으로 살아남은 후보를 조금 더 위로 올려주는 데 도움이 되었습니다.

또한 추천 결과가 충분하지 않거나 예외 상황이 생길 때는 인기도 기반 결과로 자연스럽게 보완할 수 있도록 fallback도 마련했습니다. 기술적으로는 작은 디테일일 수 있지만, 실제 서비스에서는 이런 장치들이 사용자 경험을 안정적으로 유지하는 데 꽤 중요했습니다.

온라인 서빙에서는 응답 시간이 매우 중요하기 때문에, Redis 조회와 추천 파이프라인 전반에 적절한 타임아웃을 두었습니다. 추천 품질이 좋아도 응답이 늦어지면 서비스 품질은 바로 흔들리기 때문에, 이 부분은 모델 성능과는 다른 의미의 중요한 운영 조건이었습니다.

또 하나 중요했던 점은, 새 신호를 도입하더라도 기존 서비스 운영 체계를 크게 흔들지 않는 것이었습니다. 추천 품질 실험, 단계적 적용, 장애 대응, 비교 지표 검증까지 모두 고려해야 했기 때문에, 아키텍처와 로직 모두 "좋은 아이디어"보다 "서비스에 안전하게 얹을 수 있는 구조"를 우선해 설계했습니다.

그래서 무엇이 달라졌을까요?

추천 품질을 이야기할 때 결과 화면만 보면 쉽게 와닿을 수 있지만, 그 전에 먼저 봐야 할 변화는 추천에 들어가는 입력 자체가 달라졌다는 점입니다. 결과보다 먼저, 추천 시스템이 세상을 보는 방식이 달라졌다고 볼 수 있습니다.

기존에는 클릭한 상품, 카테고리, 브랜드 같은 정형 신호가 중심이었습니다. 하지만 영상 기반 추천에서는 여기에 영상이 전달한 맥락과 고객 행동의 의도가 함께 들어가기 시작했습니다. 즉, 추천의 기준이 "어떤 상품을 봤는가"에서 "어떤 맥락에 반응했는가"로 확장된 것입니다.

이 변화는 추천 결과에서도 드러났습니다. 기존에는 같은 카테고리 상품 위주로 영상이 붙어 나오는 경향이 강했다면, 이제는 카테고리가 다르더라도 실용성, 스타일링, 사용 상황처럼 맥락이 비슷한 영상과 상품이 함께 추천될 수 있게 되었습니다.

예를 들어 워킹화에 반응한 고객에게 단순히 운동화만 더 보여주는 것이 아니라, "편안하고 활동적인 일상"이라는 맥락에 맞는 다른 숏픽을 연결해줄 수 있고, 와이드 청바지에 반응한 고객에게 단순히 청바지만 더 보여주는 것이 아니라, "편안한 핏"이라는 맥락에 맞는 슬랙스, 티셔츠 관련 숏픽까지 연결해 줄 수 있게 된 것입니다.

실제로 어떤 변화가 있었을까

동일 영역, 동일 기간 기준으로 A/B 테스트를 진행한 결과 입니다.

	클릭 UV	총주문고객수	CR
기존 로직 대비 증감율	+21.7%	+57.5%	+29.4%

클릭 UV, 총주문고객수, 전환율(CR) 모두에서 개선이 관찰됐고, 일별 지표를 보더라도 전환율이 유의미하게 상승한 구간들을 확인할 수 있었습니다. 즉, 영상 이해 신호를 추천에 연결한 효과는 실제 서비스 지표에서도 확인할 수 있었고, 비즈니스 성과에 실질적으로 기여함을 입증할 수 있었습니다.

앞으로의 방향

이번 작업을 통해 확인한 것은, GS SHOP이 이미 가지고 있는 영상 자산과 고객 반응 데이터를 더 잘 해석하면 추천 시스템이 훨씬 풍부해질 수 있다는 점이었습니다.

그리고 저희는 여기서 한 단계 더 나아가고자 합니다.

지금까지는 사람이 직접 숏폼 영상을 만들고, 저희가 그 영상에서 소구 포인트를 추출해 추천에 활용해 왔습니다. 그런데 추천 시스템은 무엇을 보여줄지 결정하는 역할에 그치지 않고, 고객이 실제로 어떤 소구 포인트에 반응했는지를 계속 학습하는 구조이기도 합니다. 만약 실용성, 스타일링, 활용 상황 같은 요소가 클릭과 전환으로 이어졌다면, 이 정보는 추천 신호인 동시에 다음 콘텐츠를 만들 때 참고할 수 있는 제작 신호가 됩니다.

그래서 앞으로는 다음과 같은 선순환을 만들고 싶습니다.

사람이 영상을 만들고
AI가 그 핵심 메시지를 구조화하고
추천이 어떤 포인트가 실제로 효과 있었는지 검증하고
그 결과를 다시 다음 콘텐츠 제작에 반영하는 것

즉, 콘텐츠 제작 → 추천 → 반응 학습 → 다시 콘텐츠가 이어지는 구조입니다.
추천을 넘어 검색과 탐색, 그리고 나아가 콘텐츠 제작까지 연결되는 방향으로 발전시켜 나가고자 합니다.

마무리하며

이번 글을 통해 말씀드리고 싶었던 것은 세 가지입니다.

영상은 상품 메타데이터만으로 담기지 않는 더 풍부한 신호를 제공합니다.
추천에 필요한 신호만을 구조화해서 남기는 것이 중요했습니다.
그리고 그 연결은 새로운 시스템을 처음부터 만드는 방식이 아니라, 기존 추천과 결합하며 인프라 위에 자연스럽게 확장하는 방식으로도 충분히 구현할 수 있습니다.

Part 1이 숏픽 추천의 진화 과정이었다면, Part 2는 왜 영상을 중요한 신호로 봐야 하는지에 대한 이야기였고, 이번 Part 3는 그 신호를 실제 추천 시스템 언어로 바꿔 넣은 이야기였습니다.

이 글에서는 그 가능성을 GS SHOP 서비스 안에서 어떻게 시스템으로 만들었는가를 조금 더 구체적으로 남기고 싶었습니다.
결국 저희가 풀고자 했던 문제는 영상 모델을 쓰는 것 자체가 아니라, GS SHOP이 이미 가지고 있는 영상과 고객 반응을 추천 가능한 데이터 구조로 다시 해석하는 일이었습니다.

이제 GS SHOP은 영상을 노출하는 것을 넘어, 영상을 이해하며 추천하기 시작했습니다.

감사합니다 :)

이세윤 Erica | AX본부 홈쇼핑AX부문 검색추천파트(H)

추천 알고리즘 개발을 담당하고 있습니다.

사용자에게 도움이 되는 서비스를 개발하고,

합리적인 추론을 통해 변화를 만들어내는 일을 하고 싶습니다.

쇼핑에 영상을 더하다: Part 2. 영상을 '이해'하기 시작하다

otch80 — Mon, 30 Mar 2026 17:51:57 +0900

시리즈 목차

- Part 1. 쇼핑에 영상을 더하다: GSSHOP 숏픽 추천 알고리즘 진화기

- Part 2. 쇼핑에 영상을 더하다: 영상을 '이해'하기 시작하다

- Part 3. 쇼핑에 영상을 더하다: 이해한 영상을 추천으로 연결하기

지난 포스팅 (Part 1) 에서 저희는 MAB 기반의 숏픽 추천 시스템을 소개했습니다. 카테고리, 브랜드, 상품명 같은 정형 메타데이터를 feature로 삼아 고객 취향을 학습하는 방식이었습니다.

그 글의 마지막 '앞으로의 방향' 에서 이런 문장을 남겼습니다.

숏픽 추천은 아직 갈길이 멉니다. 기술적으로도, 콘텐츠 전략 측면에서도 진화의 여지가 많습니다.
숏픽 추천의 Next는 영상 자체의 메타 정보를 활용한 콘텐츠 이해에 기반한 추천이라고 생각합니다.

지금까지는 숏픽에 매핑된 상품 정보를 중심으로 추천을 구성해왔다면,
앞으로는 영상 내 포함된 텍스트, 음성, 이미지 등 콘텐츠 자체의 속성까지 분석해 추천에 반영하여 더 좋은 성능을 낼 수 있을 것입니다.

그렇다면 영상 안에 담긴 그 풍부한 정보를, 과연 어떻게 꺼낼 수 있을까.

그 고민이 Part 2의 출발이었습니다.

GS SHOP은 수많은 홈쇼핑 영상 데이터를 보유하고 있습니다.

그런데 정작 그 영상들을 우리는 제대로 활용하고 있었을까요?

들어가며

추천을 만든다는건, 일상 속 소통방식을 모방하는 일이라고 생각합니다

친한 친구에게 좋은 식당을 알려줄때 우리는 어떻게 하나요?

지도 링크를 직접 보내기도 하지만 가게 후기 영상 링크를 보냅니다.

식당에 가서 꼭 먹어봐야할 음식과 그 장소만의 분위기를 전부 생생하게 전할 수 있기때문입니다.

하고 싶은 말이 많을수록, 영상이 더 효과적임을 우리는 경험을 통해 알고있습니다.

이번 포스팅에는 영상을 데이터로 이해하기까지의 여정을 담았습니다.

왜 지금이었을까 - 이 과제를 시작한 이유

영상 기반 추천은 오래된 숙제였습니다.

Part 1을 마무리하면서 To-Be로 적어놓긴 했지만 그게 당장 실현 가능한 일이라고는 생각하지 않았습니다.

영상을 이해한다는 건 영상에서 의미 있는 정보를 기계가 꺼낼 수 있어야 하는데, 그게 가능한지 자체가 불분명했기 때문입니다

그런데 2024년을 지나면서 분위기가 달라졌습니다

LLM이 텍스트를 넘어 이미지를, 이미지를 넘어 영상을 이해하기 시작했습니다.

멀티모달 모델들이 빠르게 등장했고, 몇 가지 시도를 해보면서 "이 수준이면 실제 서비스에 붙일 수 있겠다"는 감이 왔습니다.

타이밍이 맞아 떨어졌습니다.

GS SHOP에는 영상이 있습니다. 매일 생방송이 쌓이고, 숏폼 콘텐츠가 쌓이고, S3에 저장되는 영상들이 있었습니다.

어디서부터 시작해야 할까 고민이 들었습니다.

영상 추천이라는 최종 목표는 있었지만, 처음부터 추천 시스템을 뜯어고칠 수는 없었습니다.

먼저 "기계가 영상을 이해할 수 있는가"를 확인해야 했습니다

그 검증을 위해 가장 먼저 한 일은, 사내에서 영상을 가장 많이 다루는 현업 담당자들과 이야기를 나누는 것이었습니다

1. 과제의 출발점: PD의 고충

이 여정의 시작은 추천 시스템이 아닌, 영상 검색이었습니다

GS SHOP에서는 매일 생방송 이후에 PD가 수십 개의 영상을 하나씩 재생하며 필요한 장면을 수동으로 찾아야 했습니다.

"이 영상에서 쇼핑호스트가 시식하는 장면이 어디였더라..." 그 장면 하나를 찾는 데 몇 시간이 걸리기도 했습니다.

이 고충에서 자연스럽게 질문이 떠올랐습니다.

"영상도 텍스트처럼 검색할 수 있지 않을까?"

2. TwelveLabs와의 첫 만남: 영상을 검색하다

영상 이해 모델을 찾던 중 TwelveLabs를 알게 됐습니다.

그 중 Marengo는 자연어로 영상 속 특정 장면을 찾아주는 모델이었습니다.

바로 접목해 영상 검색 대시보드를 만들었습니다.

대시보드를 통해 몇 시간 걸리던 장면 검색을 몇 초 만에 해결할 수 있는 가능성을 보게 되었습니다

그런데 조사하는 과정에서 흥미로운 사실을 알게 되었는데, 바로 TwelveLabs 는 두개의 모델을 지원한다는 것입니다.

모델	역할	질문 방식
Marengo	영상 장면 검색	"이 장면이 몇 초에 있나?"
Pegasus	영상 전체 질의·응답	"이 영상이 무엇에관한 건가?"

PD 업무엔 Marengo가 맞았지만, Pegasus는 영상 속 검색 그 이상의 가능성을 갖고 있었습니다.

이미 영상을 이해하고 있었고,

여기서부터 다른 아이디어가 떠오르기 시작했습니다.

3. 발견: 숏픽 추천은 "영상" 추천이 아니다

이 시점에 숏픽 추천이 어떻게 작동하는지 다시 한번 되짚어봤습니다.

이미 알다시피 숏픽 추천은 영상 추천이 아니었습니다.

현재의 추천 방식은 상품과 상품 사이의 추천이었고, 추천된 상품에 숏폼 영상이 있으면 그 영상이 노출되는 방식이었습니다.

영상의 내용은 전혀 반영되지 않았습니다.

영상 추천이 왜 이런 방식으로 운영이 되고 있었을까요?

저희는 이미 이유를 알고 있습니다.

그리고 동시에, 오래된 질문이 하나 떠올랐습니다.

4. "우리는 지금까지 영상을 이해하지 못했습니다"

카테고리, 브랜드, 상품명, 이미지 — 시스템이 다룰 수 있는 건 이런 멈춰있는 데이터뿐이었습니다.

영상을 이해할 수단이 없었기 때문에 상품 정보에 기댈 수밖에 없었던 겁니다.

그렇다면 영상은 무엇일까요?

영상은 상품 이미지에 시간축이 더해진 형태입니다.

정보의 밀도가 근본적으로 다릅니다.

우리가 지금까지 놓치고 있던 정보들이 어쩌면 시간의 흐름이었던 걸지도 모른다는 생각이 들었습니다

그렇다면 "이해한다"는 건 무슨 뜻일까요?

이해한다는 것은 자신 있게 누군가에게 설명할 수 있다는 것. 그리고 이것이 추천의 본질이기도 합니다.

추천이란 결국 "이게 당신에게 맞을 것 같아"라고 말하는 행위입니다.

5. 멈춰있던 데이터에 시간이 더해지다

시스템이 다룰 수 있는 데이터는 항상 멈춰있는 것들이었습니다.

카테고리 코드, 브랜드 ID, 상품명 텍스트, 대표 이미지. 이런 정형 데이터는 숫자나 텍스트로 표현되고,

추천 엔진이 이해할 수 있는 언어로 변환이 가능했습니다.

그렇다면 영상은 어떤 정보를 담고 있을까요?

앞서 말한것 처럼 영상은 상품 이미지에 시간이 더해진 형태입니다.

사람이 영상을 보면서 직관적으로 받아들이는 맥락 — "아 이 제품 실제로 효과가 있나 보다", "저 MC가 이렇게 좋아하는 걸 보면 진짜인가 봐" — 이런 정보들은 기존 시스템이 전혀 건드리지 못하는 영역이었습니다.

LLM과 멀티모달 모델이 이미지를 이해하기 시작했고, 똑똑해진 모델의 입력 시퀀스가 늘어나면서

비로소 기계가 이 시간의 흐름을 이해할 수 있게 됐습니다.

시공간을 살아가는 저희에게 시간의 흐름을 이해하는 도구가 생겼습니다.

드디어 저희가 바라보는 세상과 기계가 바라보는 세상의 차원이 일치하게 된 것입니다

6. 처음부터 설계된 것처럼 — AWS Bedrock 파이프라인

Pegasus를 숏픽에 적용하려는 순간, 인프라 고민이 생각보다 크지 않았습니다

이미 모든 재료가 AWS 위에 있었습니다

GS SHOP의 영상 데이터는 S3에 저장되어 있었고, 상품·방송 정보는 Redshift에 있었습니다.

그리고 Pegasus는 AWS Bedrock에 올라가 있었습니다.

퍼즐 조각들이 이미 같은 판 위에 놓여 있었던 셈입니다.

각 단계가 하는 일은 명확합니다.

Pegasus는 영상을 보고 한국어로 장면을 설명합니다. "쇼핑호스트가 클렌징폼을 직접 얼굴에 올려 풍성한 거품을 만들며 피지 개선 효과를 강조하고 있다" 같은 문장을 만들어냅니다.

Claude는 그 설명에서 추천에 쓸 수 있는 핵심 키워드를 뽑아냅니다. "체험형 시연", "피지 개선", "거품 풍부", "셀럽 인증" 같은 소구 포인트입니다.

Cohere는 이 텍스트를 벡터(숫자 배열)로 변환합니다. 비슷한 맥락의 영상은 벡터 공간에서 가깝게 위치하게 되어, "이 영상과 비슷한 영상"을 수학적으로 계산할 수 있게 됩니다.

OpenSearch는 이 벡터들을 인덱싱해서 실시간 추천 서빙에 씁니다.

영상이 S3에 올라가는 시점부터 추천 후보에 등록되기까지 — 이 모든 과정이 AWS 안에서 닫힙니다. 별도 인프라를 구축할 필요가 없었고, 기존 서비스에 새로운 레이어를 자연스럽게 얹을 수 있었습니다.

처음부터 이렇게 설계된 것처럼 맞아 떨어졌습니다.

마치며

이번 포스팅에서 다룬 내용을 정리하면 이렇습니다.

출발점: PD의 영상 검색 고충에서 "영상도 텍스트처럼 검색할 수 있지 않을까"라는 질문이 시작됐습니다.
발견: Marengo로 영상 검색을 해결하면서, Pegasus라는 두 번째 모델이 가진 더 큰 가능성을 봤습니다.
문제 인식: 현재 숏픽 추천은 영상을 이해하지 않은 채 영상을 노출하고 있었습니다. 이유는 하나였습니다 — 영상을 이해할 수단이 없었기 때문입니다.
개념 전환: 영상은 2D 이미지에 시간 차원이 더해진 데이터입니다. LLM과 멀티모달 모델 덕분에 비로소 이 차원을 다룰 수 있게 됐습니다.
파이프라인: Pegasus → Claude → Cohere → OpenSearch. AWS 안에서 닫히는 구조였습니다.

이제 영상을 이해할 수 있게 됐습니다. 다음 질문은 하나입니다.

"이해한 영상을, 어떻게 추천으로 연결할까?"

그 이야기는 Part 3에서 이어집니다.

조민규 Josh | AX본부 홈쇼핑AX부문 검색추천파트(H)

추천 시스템 개발을 담당하고 있습니다

기술을 통해 사람을 이해하고

현상을 설명하려 노력하고 있습니다

비개발자 리서처가 AI로 인터뷰를 자동화하기까지: GS리테일 리서치봇 구축기

sunmibae — Mon, 8 Dec 2025 12:18:55 +0900

AI로 리서치 프로세스를 재설계한 GS리테일의 AX 사례

안녕하세요 AX본부에서 UX/고객 리서치를 담당하는 배선미 매니저입니다

오늘은 비개발자 리서처가 GEN AI를 활용해 ‘인터뷰 기반 정성 리서치’를 자동화한 과정을 소개해보려고 합니다.

Intro: 쉽게 접근할 수 없었던 ‘리서치’, AI로 풀 수 있을까?

저희 팀은 고객 경험을 분석하기 위해 다양한 리서치를 진행하는데요,
그 중에서도 ‘인터뷰 기반 리서치’는 사실 많은 실무자들이 가장 부담을 느끼는 영역입니다.

인터뷰 설계 → 일정 조율 → 진행 → 분석 → 보고서… 전부 다 챙기려면 정말 많은 시간과 전문성이 필요하죠.
그래서 “필요하긴 하지만 당장은 어렵다…” 하고 포기하는 경우를 많이 봐왔어요.

저 역시 리서처로서, 더 많은 실무자가 고객의 목소리를 ‘쉽고 빠르게’ 들을 수 있다면 좋겠다는 생각을 늘 하고 있었습니다.

“AI를 활용해 인터뷰 각 단계의 부담을 덜 수 있다면, 누구나 빠르고 쉽게 리서치를 할 수 있지 않을까?”

이 질문이, 바로 GS리테일 ‘AI 리서치봇’ 개발의 출발점이었습니다.

문제 정의: 인터뷰는 ‘특정 단계’가 아니라 ‘전 과정’이 어렵다

실무자들이 인터뷰를 어려워하는 이유는 아주 명확했습니다.

1. 어떤 질문이 좋은 질문인지 모르겠다

2. 인터뷰를 직접 진행하고 준비할 시간이 없다

3. 기록하고 분석하는 데 너무 오래 걸린다

즉, 인터뷰는 준비부터 분석까지 모든 단계가 부담이 큰 작업이었어요.
그런데 이 구조는 오히려 AI가 가장 잘할 수 있는 영역이기도 했습니다.

<인터뷰 진행 시 어려움>

개발 방식: 비개발 리서처가 GEN AI로 직접 만들다

리서치봇 개발 과정에는 특별한 포인트가 있습니다.
바로 개발자가 아닌, 저 같은 ‘비개발자 리서처’가 직접 만들었다는 점입니다.
“리서처가? 개발 지식 없이? 어떻게?”라고 놀라실 수도 있는데요

GS리테일에는 MISO라는 GEN AI기반의 워크플로우·AI 에이전트 생성 플랫폼이 있습니다.

올해 회사에서는 구성원들의 AI 실무 역량을 키우기 위해 MISO 교육을 운영했고,
저도 그 과정을 거치며 실제 업무에 적용할 기회를 얻었습니다.

리서치봇은 바로 이 MISO를 기반으로 만들어졌습니다.

<AI리서치봇 개발 과정>

리서치봇을 만들기 위해 다음과 같은 과정을 거쳤습니다:

리서치 프로세스를 단계별로 쪼개고
각 단계에서 AI가 할 수 있는 일을 정리하고
프롬프트와 흐름을 설계하고
테스트 개선을 반복했습니다

이 과정을 빠르게 반복하면서, 몇주만에 인터뷰 설계부터 분석까지 자동화하는 베타버전을 완성할 수 있었어요.

<인터뷰 프로세스에서 AI기회요소 도출>

이 과정에서 느낀점은 “업무 흐름을 가장 잘 아는 사람이 직접 도구를 만들 수 있는 환경”의 가치가 얼마나 큰지 다시 한 번 느꼈습니다.

<팀 내부 테스트 및 피드백 수집>

리서치봇 기술 구조: Agent × Workflow로 구현된 자동화

앞서 소개한 MISO의 두 가지 핵심 요소인 Agent(에이전트)와 Workflow(워크플로우)를 조합해 구현하였습니다.

Agent = 대화하고 판단하는 역할(AI 챗봇)
Workflow = 여러 작업을 순차적으로 자동 처리하는 역할(AI 자동화)

이 두 기능을 활용하여 ‘설계 → 진행 → 분석’까지의 인터뷰 전체 흐름을 하나로 묶을 수 있었는데요,

Agent가 “대화와 생성”을 담당하고 Workflow가 “정제와 자동화”를 담당하면서,
인터뷰 전 과정이 유기적으로 연결되도록 설계한 것이 핵심입니다.

또한, 각 단계의 프롬프트에는 역할(Role)과 수행 규칙을 명확히 정의해 일관된 품질을 유지할 수 있도록 했습니다.

①설계봇(Agent) 질문 생성 설계자	②진행봇(Agent) 실제 인터뷰 진행자	③분석봇(Workflow) 데이터 정제 및 인사이트 분석가
조사 목적·대상자·알고 싶은 내용을 입력하면, 설계봇이 질문 생성 지침과 구조 프롬프트를 기반으로 인터뷰 질문 리스트를 자동으로 만들어줍니다. 필요하면 재생성·수정도 바로 가능해요.	설계봇이 만든 질문 리스트가 전달되면, 진행봇은 인터뷰 가이드 프롬프트에 따라 사람처럼 자연스럽게 인터뷰를 진행합니다. 탐색 질문(probing)도 상황에 맞춰 이어가요.	인터뷰가 끝나면 분석봇이 로그 데이터를 자동으로 정제한 뒤, 분석 프롬프트를 통해 핵심 문장 추출·주요 인사이트·요약·긍·부정 키워드·개선 제안을 생성해요. 최종적으로 자동으로 보고서가 작성됩니다.

AI 리서치봇의 가치 — 인터뷰 설계, 진행, 분석의 과정을 자동화

리서치봇의 핵심 목표는 “리서치를 해보지 않은 사람도 쉽게 인터뷰를 할 수 있게 하는 것”인데요,
그래서 인터뷰의 세 가지 큰 허들(① 설계, ② 진행, ③ 분석)을 낮추는 데 집중했어요.

① 인터뷰 질문 설계 자동화

조사 목적만 입력하면 리서치 경험이 없어도 5분 안에 인터뷰 질문 설계가 완성할 수 있습니다.
후속 질문·응답 시간 같은 부가 정보도 자동 구성돼요.

② 인터뷰 진행 자동화

기존의 대면 1:1 인터뷰 대신, AI가 채팅 기반으로 자연스럽게 인터뷰를 진행합니다.
필요한 경우 probing 질문도 스스로 이어가고요.
여러 인터뷰를 동시에 진행할 수도 있어 예전엔 며칠 걸리던 일이 수십 분으로 줄어듭니다.

③ 결과 분석 자동화

AI가 분석 초안을 먼저 만들어주고 실무자는 그 결과를 빠르게 검토·보완하는 방식으로 기존 대비 분석 시간이 크게 줄었어요.
보고서 품질 편차도 줄고, 정성 분석의 부담이 크게 줄어드는 효과가 있었습니다.

그 결과, 파일럿 기준 리서치 전체 소요시간이 약 80% 감소하는 효과를 확인했습니다.

궁금한 내용이 생겼을 때 바로 질문하고 → 바로 데이터를 얻는 ‘즉시 리서치 환경’ 이 가능해진거죠

이는 아이디어 검증–수정–재확인까지의 사이클을 크게 단축시키며, 업무 속도와 협업 효율을 크게 높여줄 것으로 기대됩니다.

< AI리서치봇 설계–진행–분석 화면: 사내 프로그램 인터뷰 사례>

활용 범위의 확장 : UX(User Experience) + EX(Employee Experience)로

리서치봇은 원래 고객 인터뷰 자동화를 목표로 시작했습니다.
하지만 MISO 보안상, 대고객 서비스 적용은 당장은 어려워 우선 임직원 의견 수집에 활용하기로 방향을 바꿨습니다.

그런데 예상 밖의 기회가 열렸습니다. 임직원 인터뷰 중심으로 진행해 보니,

조직문화
교육·온보딩
사내 제도·프로세스·시스템 피드백

등 임직원 경험(EX) 개선에도 활용 가치가 크다는 점을 발견할 수 있었어요.
즉, UX뿐 아니라 EX 영역까지 기대하지 않았던 확장성이 자연스럽게 열리게 되었어요.

현재 단계: 내부 테스트 완료, 베타테스트 준비 중, 그리고 앞으로의 확장

파일럿 테스트 과정에서 받은 리서치봇 피드백은 긍정적이었습니다.

“채팅형 인터뷰는 대면 인터뷰에서 얻기 힘든 '솔직한 의견', 특히 '단점'이나 '개선점'을 파악하는 데 매우 효과적일 것 같아요."
“진짜 리서처와 인터뷰하는 느낌을 받았어요 집요하게 사례를 찾아내려고 하네요”
"AI 리서치봇이 다수로부터 정성적 데이터를 수집하고 이를 정량화할 수 있다는 점에 큰 기대가 돼요"

이제 더 많은 임직원이 실제로 사용해보고 피드백을 남길 수 있도록 베타테스트를 진행할 예정입니다.
베타 기간 동안 인터뷰 품질·UI/UX·보고서 형태를 고도화해 장기적으로는 고객 대상 서비스로 확장하는 것도 목표입니다.

마치며: 이 프로젝트가 가능했던 이유

마지막으로, 이번 프로젝트는 제 개인의 역량만으로는 완성할 수 없었습니다.
사내 MISO 교육 과정과 DX COE팀의 기술적 지원이 없었다면, 비개발자인 제가 혼자 구현하기 어려웠을 거에요.

또한 파일럿 테스트 단계에서 바쁜 와중에도 적극적으로 참여해 실제 사용 기반 피드백을 제공해주신
UX인사이트팀 팀장님과 팀원들 덕분에, 리서치봇은 훨씬 더 빠른 속도로 완성도를 높일 수 있었습니다.

업무 도메인을 가장 잘 아는 사람이 직접 도구를 만들 수 있도록 환경과 교육, 실험 기회를 제공해준 조직의 문화와 지원에 대해 이 자리를 빌려 감사의 마음을 전하고 싶습니다.

배선미 | AX본부 플랫폼AX부문 편의점AX팀

GS리테일에서 고객경험 개선을 위한 UX리서치를 담당하고 있습니다
새로운 것을 배우고 이것저것 시도해보는 것을 좋아합니다 :)

[GS리테일] DX본부 플랫폼데이터분석팀/홈쇼핑데이터분석팀 데이터 사이언티스트 경력사원 채용(~10/24)

jayjay5 — Tue, 14 Oct 2025 11:39:51 +0900