고도화된 RAG를 위한 코퍼스 설계 전략

궁금하면 500원·2026년 1월 9일

LLM RAG전략 검색엔진 데이터엔지니어링 데이터품질 벡터DB 이커머스AI 이커머스혁신

AI 미생지능

목록 보기

78/90

AI 데이터 전략의 본질과 엔지니어링적 난제가 이슈이기때문에 이번에는 이부분을 학습하게되었습니다.
이 내용을 바탕으로, 개념의 정의부터 실제 구축 전략, 그리고 평가 방법론까지 논리적 흐름(Logical Flow)을 갖춘 상세 포스팅하게되었느데요

각 항목마다 이해를 돕기 위한 구체적인 예시를 추가하여 실무 지침서로 활용할 수 있도록 작성했습니다.

코퍼스의 본질부터 RAG 전략까지

1. 코퍼스의 데이터의 철학 재정의

우리는 흔히 데이터를 '사실'이라고 생각하지만, AI 모델에게 데이터는 '학습해야 할 세계' 그 자체입니다.

개념적 구분

Fact: 세상에 존재하는 객관적 진실 그 자체입니다.
(예: "지구는 둥글다", "2024년 2월 1일 A기업 주가는 5만원이다")
Corpus: 모델이 학습하거나 참조하기 위해 선택된 데이터의 집합입니다.
모델 입장에서는 '있어야 하는 사실'이자 '유일한 세계'입니다.
LLM의 관점: 코퍼스는 모델이 학습할 세계의 축소판입니다. 코퍼스에 없는 지식은 모델의 세계에 존재하지 않는 것입니다.
RAG의 관점: 질문에 답하기 위해 동적으로 조회할 지식의 도서관입니다.

핵심 통찰: 코퍼스의 품질은 언어적 밀도가 아니라, 목적 부합성에 달려 있습니다.

예시: 법률 상담 AI를 만드는데 셰익스피어 전집을 학습시키는 것보다, 투박한 판결문이 훨씬 가치 있는 코퍼스입니다.

2. 코퍼스의 실체와 "Garbage In, Garbage Out"

목적에 따른 분류

분야	데이터 형태	예시
NLP	텍스트, 대화, 문서	뉴스 기사, 상담 로그, 위키백과
CV	이미지, 레이블, 임베딩	MRI 사진, CCTV 영상, 이미지 캡션
STT	음성 파형, 전사 텍스트	콜센터 녹취록, 회의록
추천	사용자 행동 로그	클릭 이력, 장바구니 담기, 체류 시간
RAG	청크, 메타데이터, 인덱스	사내 규정 PDF, DB 테이블, 제품 매뉴얼

실패의 원인 분석

"모델이 멍청하다"는 불만의 80%는 사실 "코퍼스가 잘못되었다"는 뜻입니다.

A. LLM이 이상하게 작동하는 경우

특정 도메인 지식 부재: 모델이 답변을 지어냄.

원인: 코퍼스에 해당 지식이 아예 포함되지 않음.

한국어 능력/뉘앙스 부족: 번역투나 어색한 문장 구사.

원인: 양질의 한국어 네이티브 코퍼스 비중이 낮음.

코드 스타일 엉망: 비효율적이거나 보안에 취약한 코드 생성.

원인: GitHub 등에서 필터링 없이 긁어온 'Bad Code'를 그대로 학습.

날짜/숫자 연산 오류:

원인: 텍스트 위주 학습으로 수리적 논리나 시계열 데이터가 중요하게 다뤄지지 않음.

B. RAG가 이상하게 작동하는 경우

검색 실패: 질문에 맞는 답이 있는데 못 찾음.

원인: 문서 청킹(Chunking)이 문맥을 잘라먹었거나 키워드가 잘림.

관련성 낮음: 엉뚱한 문서를 가져옴.

원인: 노이즈가 섞여 있거나 임베딩 모델 성능 저하.

최신성 결여: 옛날 정보를 사실인 양 답변.

원인: 2020년 규정과 2024년 규정이 섞여 있는데, 메타데이터 필터링을 안 함.

가비지 판정의 딜레마

쓰레기 데이터를 거르는 것은 매우 어렵습니다.

과도한 가공: 데이터의 다양성을 해쳐 편향된 결과를 낳습니다.
(예: 욕설을 다 지웠더니 모델이 욕설을 인지조차 못해 방어를 못함)
가공 부족: 중복, 노이즈, 정보 불일치로 모델이 혼란스러워합니다.

3. 데이터셋의 3단계 계층 구조

코퍼스는 목적에 따라 가공 수준이 달라집니다.

1단계: 원천 코퍼스

목적: 언어의 구조 이해, 배경 지식 습득
유형: 가공되지 않은 대규모 텍스트 뭉치
핵심: 다양성과 압도적인 규모
결과: 문장을 이어 쓸 수 있는 상태

2단계: 인스트럭션 데이터

목적: 지시 이행 능력 향상 및 말투 형성
유형: {Instruction(지시), Input(입력), Output(정답)} 쌍
핵심: 데이터의 정확성, 가이드라인 준수 여부. 동일한 Input에 대해 다양한 지시를 수행하는 능력.
결과: 질문에 대해 동문서답하지 않고 의도에 맞게 대답함.

3단계: 선호 데이터

목적: 가치관 정렬 및 선호도 반영
유형: {Prompt, Chosen(채택), Rejected(기각)} 쌍
핵심: 두 답변 간의 명확한 우열 관계.
(A가 B보다 더 안전하다/친절하다)
결과: 사용자가 원하는 방향으로 답변을 생성.

4. 벡터 DB와 질의 처리 전략

RAG 시스템에서 벡터 DB에 질의가 들어오는 순간은 매우 복잡합니다.
단순 검색과는 차원이 다릅니다.

복잡한 컨텍스트 상황

사용자의 질문은 진공 상태에서 오지 않습니다.

사용자 프로필/기억: "나 저번에 샀던 거랑 비슷한 거 추천해줘"
대화 컨텍스트: "그거 말고 좀 더 싼 거는?"
('그거'가 무엇인지 직전 대화에서 파악 필요)
도메인 컨텍스트: 답변은 항상 법적 근거를 포함해야 한다는 전제.

라우팅과 전략적 역할 분리

질문이 복합적일수록 임베딩 검색만으로는 한계가 있습니다. "검색 대상이 여러 개로 쪼개져야 하는 상황"이 발생합니다.

예시 상황: "지난달 우리 회사 실적과 비교해서 이번 달 인건비가 늘어난 이유는 뭐야?"
문제: '실적'과 '인건비'를 동시에 봐야 하며, '비교'까지 해야 함.
단순 벡터 검색으로는 불가능.

해결책: 리트리버와 라우터의 분리

LLM 라우터: 질문을 분석해 검색 계획을 수립합니다.

-> "재무 테이블에서 지난달 실적 조회"
-> "인사 테이블에서 이번 달 인건비 내역 조회"

벡터 DB: 명확하고 단순화된 질의만 받아서 검색합니다.

5. 코퍼스 생성 및 관리 전략

주제 분류의 모호성과 유동성

코퍼스를 폴더처럼 예쁘게 나누는 것은 불가능에 가깝습니다. "관점"에 따라 분류가 계속 바뀌기 때문입니다.

예시: 나이키 운동화 데이터
물류팀 관점: 신발 > 스포츠 > 재고 있음
마케팅팀 관점: 20대 타겟 > 러닝 > 인기 상품

전략: 사용자는 채팅 중 수시로 관점을 바꿉니다. 따라서 고정된 분류보다는 유동적인 메타데이터와 임베딩 모델의 특성을 활용해야 합니다.
코드: CodeBERT 등 코드 전용 임베딩
이미지: CLIP 등 Vision-Language 모델

테이블 병합 vs 분할 전략

벡터 DB를 어떻게 구성할 것인가에 대한 딜레마입니다. 임베딩 유사도 값은 절대적인 수치가 아니라, 현재 비교군 내에서의 상대적 위치에 가깝습니다.

전략	장점	단점	추천 시나리오
단일 거대 테이블	관리가 단순함. 메타데이터 필터링으로 유연한 검색 가능.	메타데이터 구조가 매우 복잡해짐. 검색 속도 저하 가능성.	데이터 간 경계가 모호하고 상호 연관성이 높은 경우
다수 테이블 분할	명확한 도메인 분리. 검색 속도 빠름.	어떤 테이블을 검색할지 정하는 '라우팅' 로직이 복잡해짐.	인사/재무/법무처럼 도메인이 명확히 분리된 경우

복합 전략 (Hybrid):
하나의 표준 메타데이터를 가진 거대 원본 테이블을 두고,
특정 목적을 위해 주제별 뷰 나 사본을 생성하여 라우팅 효율을 높입니다.

6. 평가: 무엇이 좋은 검색인가?

A. 정확성 - 판정의 어려움

"정확하다"는 것은 주관적입니다. 인간은 내 마음에 드는 답변을 정확하다고 착각합니다.

평가 방법: 질문-정답 세트를 사람이 만들고, 검색 결과가 정답과 얼마나 유사한지 LLM에게 채점을 맡깁니다.
한계: 결국 거대 모델이 작은 모델을 갈구는 구조가 되며, '정답 세트' 자체가 편향될 수 있습니다. 또한, 결과가 틀렸을 때 원인이 임베딩 탓인지, 메타데이터 탓인지, 본문 내용 탓인지 분리하기 어렵습니다.

B. 벡터 유사도 - 수치적 접근

수치적 판정이 가능하여 엔지니어링 지표로 적합합니다.

분포 확인: 특정 질문에 대해 검색된 상위 k개 문서들의 유사도 점수 분포를 봅니다.
좋은 신호: 1등(0.92), 2등(0.85), 3등(0.60) -> 확실한 정답을 찾음.
나쁜 신호: 1등~10등이 모두 0.75~0.76 사이 -> 변별력이 없음.

개선 전략:
분포가 너무 평탄하면 임베딩 모델을 교체하거나, Softmax Temperature를 조절해 차이를 강제로 벌립니다.
유사도가 전반적으로 너무 낮다면 코퍼스에 해당 내용이 없거나, 청킹 전략이 잘못된 것입니다.

C. 코퍼스 분포도

우리가 가진 데이터가 사용자 질문을 커버할 수 있는지 확인합니다.

히트맵 분석: 실제 사용자 질의들을 임베딩하여 공간에 뿌려보고, 우리 코퍼스 문서들이 그 주변에 있는지 확인합니다.
불균형 발견: 특정 질문 군집에는 문서가 하나도 없다면? -> 데이터 공백입니다.
해당 주제의 코퍼스를 추가 수집해야 합니다.
중복 발견: 특정 지점에 문서가 수천 개 몰려 있다면? -> 중복 데이터일 확률이 높음. 정리 대상입니다.

D. 필터 적합성

검색은 Semantic Search + Filter의 결합입니다.

필터링된 집합 vs 제외된 집합:
만약 제외된 집합에 정답과 매우 유사한 임베딩을 가진 문서가 많다면? -> 메타데이터가 잘못 태깅되었거나 필터 조건이 너무 엄격한 것입니다.

키워드 선정:
LLM을 통해 사용자 질문에서 키워드를 추출할 때, 너무 일반적인 단어를 키워드로 잡으면 검색 결과가 폭증하여 노이즈가 됩니다.
반대로 너무 희귀한 키워드는 검색 결과가 0건이 됩니다. 이 키워드 선정 프롬프트 튜닝이 RAG 성능의 핵심입니다.

이커머스 코퍼스의 재정의

이커머스에서 코퍼스는 단순히 상품 목록이 아닙니다. '고객의 구매 여정을 결정짓는 지식의 집합'입니다.

Fact : 상품의 원천 데이터
Corpus: 검색과 추천에 최적화된 정보
(예: "여름에 입기 좋은 린넨 소재의 시원한 반팔 셔츠", 사용자 리뷰 키워드, 스타일 가이드)
목적 부합성: 언어적 유려함보다 "이 정보가 고객의 구매 결정을 돕는가?"가 코퍼스의 품질을 결정합니다.

이커머스 AI가 '가비지'를 내뱉는 이유

"최신 트렌드 아이템 추천해줘"라고 했을 때 AI가 엉뚱한 대답을 한다면 80%는 코퍼스 문제입니다.

도메인 지식 부재: 2026년 신상 키워드가 코퍼스에 반영되지 않음.
데이터 노이즈: 중복 등록된 상품, 품절된 지 오래된 과거 데이터가 필터링 없이 검색 대상에 포함됨.
코드/형식 이상: 상품 상세페이지의 HTML 태그나 깨진 이미지가 임베딩되어 검색 정확도를 떨어뜨림.
GIGO 현상: 잘못된 상품 카테고리 매칭은 결국 고객에게 엉뚱한 검색 결과를 제공합니다.

이커머스형 전략적 역할 분리 RAG

이커머스 고객의 질문은 매우 복합적입니다. 단순 벡터 검색만으로는 한계가 명확합니다.

질문 예시: "지난달 내 구매 이력이랑 비교해서, 이번 달에 새로 들어온 아웃도어 의류 중에 나한테 어울릴만한 거 추천해줘."

이 질문의 난관:

구매 이력: 사용자 개인 DB 조회 필요
신규 입고: 상품 DB의 '등록일' 필터링 필요
개인화 추천: 스타일 임베딩 유사도 측정 필요

전략적 해결:
LLM 라우터: 질문을 분해합니다.
(①사용자 ID 추출 -> ②신상 카테고리 필터링 -> ③스타일 유사도 검색)
벡터 DB: 라우팅된 독립적 질의에 대해서만 정밀하게 검색합니다.

이커머스 데이터 품질 평가

1. 벡터 유사도 분포

특정 카테고리에서 검색 결과가 평탄하게 나온다면 변별력이 없는 것입니다.

예시: '운동화' 검색 시 모든 신발의 유사도가 0.8로 비슷하다면? -> 임베딩 모델이 브랜드나 용도의 미세한 차이를 구분하지 못하고 있음.
해결: 이커머스 전용 임베딩 모델로 변경하거나, 소프트맥스로 변별력을 강화해야 합니다.

2. 코퍼스 커버리지

고객이 자주 찾는 키워드에 대응하는 상품 데이터가 충분한지 확인합니다.
특정 브랜드에만 데이터가 몰려있다면, 검색 결과가 특정 브랜드로 편향될 위험이 있습니다.

3. 필터 적합성

상황: "5만원 이하 나이키 운동화" 검색
판정: 필터링된 결과와 전체 검색 결과의 유사도를 비교합니다.
만약 A의 유사도가 현저히 낮다면, 가격 필터가 시맨틱 검색의 핵심 문맥을 방해하고 있을 가능성이 큽니다.

전략적 코퍼스 구축 제언

이커머스 AI의 승패는 테이블 분할과 라우팅 전략에 있습니다.

거대 마스터 테이블: 모든 상품의 원천 정보를 표준화하여 저장합니다.
주제별 사본 생성: '베스트셀러', '신상품', '특가 상품' 등 목적별 테이블을 별도로 구성하여 라우팅 효율을 극대화합니다.
LLM 도구 활용: 라우터가 단순히 테이블을 고르는 것을 넘어, 검색 쿼리를 스스로 생성하게 하는 것이 가장 고성능의 결과를 냅니다.

오랜 시간 개발 현장에서 수많은 아키텍처와 데이터를 다뤄왔지만, 오늘 나눈 이 ‘코퍼스와 데이터 전략’에 관한 이야기는 마치 잘 짜인 한 편의 테크니컬 스릴러 영화를 감상한 듯한 기분을 줍니다.
화려한 CG 뒤에 숨겨진 탄탄한 시나리오가 얼마나 중요한지를 다시금 깨닫게 해주는 시간이었거든요.

모델이라는 배우보다 데이터라는 시나리오에 주목해야 하는 이유

최근 인공지능 열풍 속에서 우리는 흔히 ‘어떤 모델이 더 똑똑한가’에만 매몰되곤 합니다. 하지만 오늘 우리가 나눈 대화의 궤적은 그 화려한 무대 뒤, ‘코퍼스’라는 원석을 깎아내는 장인의 작업실을 비추고 있었습니다.

가장 먼저 제 가슴을 울렸던 지점은 ‘코퍼스는 단순한 사실이 아니라, 모델이 존재해야 할 세계 그 자체’라는 정의였습니다.
개발자로서 우리가 흔히 저지르는 실수는 널린 데이터를 긁어모아 던져주면 AI가 알아서 이해할 것이라는 막연한 기대입니다.
하지만 영화의 개연성이 시나리오에서 나오듯, AI의 지능은 그가 발을 딛고 있는 코퍼스의 '목적 부합성'에서 시작된다는 점이 매우 인상 깊었습니다.

특히 이커머스라는 현실적인 전장을 배경으로 논의했을 때, 그 긴장감은 극에 달했습니다. 사용자의 복잡 미묘한 질의를 해결하기 위해 단순히 벡터 유사도에 의존하는 것이 아니라, ‘라우터’와 ‘리트리버’의 역할을 전략적으로 분리해야 한다는 대목에서는 무릎을 탁 쳤습니다. 이것은 단순한 코딩의 문제가 아니라, 시스템의 흐름을 읽는 설계자의 통찰이 필요한 영역이기 때문입니다.

또한, ‘가비지 인, 가비지 아웃’이라는 고전적인 격언을 RAG 시스템의 관점에서 재해석한 부분은 실무자들에게 경종을 울립니다.
임베딩 유사도 값이 평탄해지는 순간 변별력이 사라진다는 지표적 접근은, 막연했던 성능 평가를 공학적인 데이터 분포의 문제로 끌어올린 아주 훌륭한 복선 회수였다고 생각합니다.

결국 이 영화의 결말은 우리에게 하나의 메시지를 던집니다.

"훌륭한 AI 엔지니어링은 결국, 데이터의 결을 이해하고 목적에 맞게 세상을 재구성하는 '데이터 큐레이션'에서 완성된다."

단순히 기술을 배우는 것을 넘어, 우리가 만드는 서비스가 어떤 지식을 먹고 자라야 하는지 그 철학을 고민해 볼 수 있는 귀한 시간이었습니다.

오늘의 학습을 마친 나의 생각:
"모델의 화려함에 속지 마세요.
진짜 승부는 보이지 않는 코퍼스의 밀도와 전략적인 라우팅 설계에서 결정됩니다."

궁금하면 500원

그냥 코딩할래요 재미있어요

이전 포스트

트랜스포머를 넘어서는 AI 아키텍처의 진화 Mamba와 HyperConnection

다음 포스트