AI에게 마케팅 카피를 맡길 때 가장 먼저 무너지는 것이 브랜드 톤입니다. 문법은 맞는데 그 병원, 그 브랜드가 쓰던 말투가 아닙니다. 이 글은 자체 콘텐츠로 톤을 학습시키는 마케팅 RAG 지식창고를 어떻게 만들었는지, 소스별 청킹과 검색 설계를 정리한 것입니다.
마케팅 RAG 지식창고란 무엇인가
마케팅 RAG 지식창고란, 브랜드가 이미 만든 위키·블로그·영상 대본을 검색 가능한 형태로 쌓아 두고, 카피를 쓸 때마다 관련 문서를 찾아 프롬프트에 함께 넣어 톤과 지식을 유지하는 구조입니다. RAG(Retrieval-Augmented Generation)는 "검색해서 생성에 보태는" 접근으로, 모델을 새로 학습시키지 않고도 브랜드의 언어와 임상 철학을 반영하게 해 줍니다.
이 시스템은 세 종류의 소스를 지식창고로 씁니다. 홈페이지·위키 같은 정형 문서, 네이버 블로그, 유튜브 대본입니다. 세 소스는 성격이 완전히 달라서, 같은 방식으로 쪼개면 검색 품질이 떨어집니다.
소스마다 청킹 전략을 다르게 둔다
RAG의 성패는 **문서를 어떻게 쪼개느냐(청킹)**에서 갈립니다. 이 시스템은 소스별로 전략을 나눴습니다.
- 헤딩 기반 청킹: 위키·홈페이지·헤딩 있는 블로그는 제목(H1·H2·H3) 단위로 자르고, 너무 긴 절은 문단 단위로 다시 나눕니다. 어느 항목에서 온 내용인지 경로를 메타데이터로 남깁니다.
- 발화 구간 청킹: 유튜브 대본은 시간 창(기본 90초) 단위로 발화를 묶습니다. 구간의 시작·끝 시각을 함께 저장해, 어느 대목에서 나온 말인지 추적할 수 있습니다.
- 문단 폴백 청킹: 헤딩이 없는 블로그는 빈 줄 기준으로 나누고 최대 길이에 맞춰 묶습니다. 헤딩이 없다는 표시를 남겨, 이후 단계에서 보완할 수 있게 합니다.
여기에 안정성 장치가 하나 있습니다. 청크의 ID를 소스와 위치의 해시로 만들어, 같은 문서를 다시 올려도 같은 ID가 나오게 했습니다. 그러면 중복 업로드가 자연스럽게 걸러집니다.
하이브리드 검색으로 톤을 잡는다
검색도 한 방식만 쓰지 않습니다. 키워드 검색(BM25)과 의미 검색(임베딩)을 함께 쓰는 하이브리드 검색입니다. 키워드 검색은 정확한 용어를 잘 잡고, 의미 검색은 표현이 달라도 뜻이 비슷한 문서를 찾습니다. 둘의 가중치를 조절해 섞으면, 한쪽만 쓸 때보다 관련 문서를 안정적으로 가져옵니다.
한 가지 실무 교훈이 있습니다. 한국어 임베딩은 유사도 점수가 낮게 나오는 경향이 있어, 점수 문턱값을 높게 잡으면 검색 결과가 0건이 되는 일이 잦습니다. 그래서 문턱값으로 걸러 내기보다 상위 K개를 항상 반환하게 해, RAG 소스가 프롬프트에 반드시 포함되도록 했습니다.
검색 품질을 수치로 검증한다
지식창고는 만들고 끝이 아니라 품질을 측정해야 합니다. 이 시스템은 질의와 기대 결과 쌍을 모아 평가 세트를 만들고, 검색 결과가 기대 키워드를 포함하는지, 기대한 소스에서 왔는지, 톤 규칙을 지키는지를 점수화합니다. 특히 금지 표현이 검출되면 톤 점수를 0으로 떨어뜨려, 의료광고법 위반으로 이어질 표현이 톤 학습에 섞이지 않게 합니다.
업로드는 천천히, 순서대로 쌓는다
지식창고를 채우는 과정에도 함정이 있습니다. 청크를 한꺼번에 몰아서 올리면 지식 저장소가 요청을 거부하기 쉽습니다. 그래서 이 시스템은 청크를 한 번에 하나씩, 짧은 간격을 두고 순차적으로 올립니다. 속도는 느려 보여도, 중간에 막혀 반쯤 올라간 상태로 지식창고가 오염되는 것보다 낫습니다. 여기에 앞서 말한 결정론적 ID가 더해지면, 업로드가 중간에 끊겨 다시 실행해도 이미 올라간 청크는 같은 ID로 걸러져 중복이 쌓이지 않습니다.
정리하면, 마케팅 RAG 지식창고의 품질은 화려한 검색 알고리즘이 아니라 소스에 맞는 청킹, 하이브리드 검색의 균형, 중복을 막는 결정론적 설계, 그리고 품질을 수치로 검증하는 습관에서 나옵니다. 이 RAG 지식창고는 카피 에이전트의 입력 품질을 떠받치는 한 축입니다. 카피·검수·기획이 어떻게 하나의 파이프라인으로 엮이는지는 멀티에이전트 마케팅 자동화 아키텍처에서, 전체 사례는 의료 마케팅 자동화 OS 사례에서 볼 수 있습니다.
자주 묻는 질문
브랜드 톤을 AI에 어떻게 학습시키나요?
모델을 새로 학습시키지 않고, 브랜드가 이미 만든 위키·블로그·영상 대본을 지식창고에 쌓아 두고 카피를 쓸 때마다 관련 문서를 검색해 프롬프트에 함께 넣습니다. 이렇게 하면 브랜드의 말투와 임상 철학이 생성 결과에 반영됩니다.
소스별로 청킹을 다르게 하는 이유는요?
위키는 제목 구조가 뚜렷하고, 유튜브 대본은 시간 흐름이 있고, 헤딩 없는 블로그는 문단으로만 나뉩니다. 성격이 다른 소스를 같은 방식으로 쪼개면 검색 품질이 떨어져, 헤딩 기반·발화 구간·문단 폴백으로 나눠 처리합니다.
하이브리드 검색은 왜 쓰나요?
키워드 검색은 정확한 용어를 잘 잡고 의미 검색은 표현이 달라도 뜻이 비슷한 문서를 찾습니다. 둘을 가중치로 섞으면 한쪽만 쓸 때보다 관련 문서를 안정적으로 가져와 톤 유지에 유리합니다.
같은 문서를 여러 번 올리면 중복이 쌓이지 않나요?
청크의 ID를 소스와 위치의 해시로 만들어, 같은 문서를 다시 올려도 같은 ID가 생성됩니다. 그래서 중복 업로드가 자동으로 걸러지고 지식창고가 지저분해지지 않습니다. 업로드가 중간에 끊겨 다시 실행해도 이미 올라간 청크는 걸러지므로 안전하게 이어서 채울 수 있습니다.
검색이 아무것도 못 찾아오는 경우는 어떻게 막나요?
한국어 임베딩은 유사도 점수가 낮게 나오는 편이라, 점수 문턱값을 높게 잡으면 결과가 0건이 되기 쉽습니다. 그래서 문턱값으로 걸러 내기보다 상위 몇 개를 항상 반환하게 해, 카피를 쓸 때 참고할 브랜드 문서가 프롬프트에 반드시 들어가도록 했습니다.