RAGPlay — RAG 파이프라인을 손으로 만져볼 수 있는 인터랙티브 도구

RAG 시리즈를 진행하면서 청킹, 임베딩, 검색까지 직접 코드를 짜서 해봤지만, 사실 각 단계가 눈에 보이지 않는다는 게 늘 답답했습니다 😮‍💨

저도 지금까지 스크립트 단위로 CLI 환경에서만 테스트 해봤는데, 물론 기능적으로는 충분하지만 — 청크가 어떻게 잘리는지, 임베딩 벡터가 어떤 분포를 갖는지, 검색 결과가 왜 이렇게 나오는지 시각적으로 확인하는 것의 가치는 무시하기 어렵죠

그러다 우연히 발견한 게 RAGPlay입니다. 조금만 더 빨리 발견했다면.. 아니다..

RAGPlay — Interactive RAG Pipeline Visualizer문서 업로드부터 청킹, 임베딩, 검색까지 RAG 파이프라인 전체를 시각적으로 체험할 수 있는 오픈소스 도구

ragplay.vercel.app

RAGPlay 는 RAG 파이프라인의 각 단계를 인터랙티브하게 시각화해주는 웹 도구입니다. Next.js 기반 오픈소스 프로젝트이고, 문서를 직접 넣으면 청킹 → 임베딩 → 검색 → 컨텍스트 생성 과정을 단계별로 눈으로 확인할 수 있습니다.

이전 RAG 시리즈처럼 여러 포스트에 걸쳐 직접 구현하며 테스트하는 방식과 달리, 이번엔 도구가 이미 완성되어 있으니까 — RAG용 문서를 하나 만들어서 실제로 돌려보겠슴니다 👍

---

테스트 문서

테스트에 사용할 문서는 가상의 “2026 사내 AI 도구 사용 가이드”입니다. 목적, 기본 원칙, 허용/금지 사용 예시, 예외 규정, 모델 선택 기준, FAQ, 시행일까지 포함된 8개 섹션 구성의 문서입니다.

원문은 아래와 같습니다.

문서 제목: 2026 사내 AI 도구 사용 가이드

1. 목적
이 문서는 사내 임직원이 생성형 AI 도구를 안전하고 효율적으로 사용하기 위한 기준을 설명한다.
적용 대상은 개발자, 데이터 분석가, 기획자, 디자이너를 포함한 전 임직원이다.

2. 기본 원칙
- 회사의 비공개 소스코드, 고객 개인정보, 계약서 원문을 외부 AI 서비스에 직접 입력해서는 안 된다.
- 공개 가능한 예시 데이터 또는 마스킹된 데이터만 테스트 용도로 사용할 수 있다.
- 결과물은 반드시 사람이 검토한 뒤 업무에 반영해야 한다.

3. 허용되는 사용 예시
- 코드 초안 작성
- SQL 쿼리 개선
- 회의록 요약
- 문서 초안 작성
- 테스트 케이스 아이디어 생성

4. 금지되는 사용 예시
- 주민등록번호, 계좌번호, 전화번호가 포함된 원문 업로드
- 고객사와 체결한 비공개 계약서 전문 입력
- 검토 없이 AI 응답을 대외 문서로 제출
- 라이선스 확인 없이 생성 코드를 제품에 바로 반영

5. 예외 규정
보안팀 사전 승인과 법무 검토가 완료된 경우에는 제한된 범위에서 민감 문서를 내부 전용 모델에
입력할 수 있다. 다만 이 경우에도 로그 보관 기간, 접근 권한, 출력물 저장 위치를 별도로 기록해야 한다.

6. 모델 선택 기준
- 빠른 아이디어 정리가 필요하면 경량 모델을 사용한다.
- 정확한 요약과 다단계 추론이 필요하면 고성능 모델을 사용한다.
- 비용이 중요한 대량 처리 작업은 배치 방식으로 실행한다.

7. 자주 묻는 질문
Q. 고객 이메일이 포함된 CSV를 업로드해도 되는가?
A. 안 된다. 개인정보가 포함되어 있으므로 마스킹 후 사용해야 한다.

Q. 사내 위키 내용을 요약하는 것은 가능한가?
A. 가능하다. 단, 위키의 접근 권한 정책을 따라야 하며 외부 공유는 금지된다.

Q. AI가 작성한 코드를 바로 운영 서버에 배포해도 되는가?
A. 안 된다. 코드 리뷰와 테스트를 거친 뒤 반영해야 한다.

8. 시행일
이 가이드는 2026년 4월 1일부터 시행한다.
기존 문서와 충돌할 경우 본 가이드를 우선 적용한다.

---

청킹 전략 비교

RAGPlay에서 지원하는 세 가지 청킹 전략을 같은 문서에 적용해서 결과를 비교해보겠습니다. 임베딩은 모든 전략에서 Snowflake/snowflake-arctic-embed-xs 모델로 동일하게 고정됩니다.

1. Fixed Size Chunking

가장 단순한 방식입니다! 정해진 글자 수(또는 토큰 수)로 기계적으로 자릅니다.

설정: chunk_size=100, overlap=10

문서 자체 분량이 많지 않아서 chunk_size를 크게 잡으면 범위가 너무 넓어집니다. 100자가 이 문서 대비 적절하다고 판단했습니다. overlap은 일반적으로 chunk_size의 10~20% 수준을 권장하니 10으로 설정했습니다.

overlap을 10~20%로 권장하는 이유

청크 경계에서 문장이 잘릴 때, 앞뒤 청크에 일부 내용이 중복되면 검색 시 맥락 단절을 줄일 수 있습니다. overlap이 너무 작으면 경계 손실이 생기고, 너무 크면 중복 데이터가 늘어 토큰 비용과 노이즈가 증가하기 때문에 10~20%가 실용적인 균형점으로 통용됩니다.

관찰 포인트:

• chunk_size=100으로 설정했지만 실제 청크는 크기 제한을 자주 초과 — “기본 원칙” 섹션은 148자, “예외 규정”은 122자로 생성됐습니다. 평균 크기는 91자이지만 편차가 큽니다.
• overlap=10으로 설정했지만 실제 Overlap은 0 — RAGPlay의 Fixed Character 방식에서는 overlap이 적용되지 않았습니다 🤔
• 제목(27자)이 단독 청크로 분리됐습니다. 내용 없이 제목만 담긴 청크는 검색에서 노이즈가 됩니다.
• 총 11개 청크 생성, FAQ 3개 질문이 각각 별도 청크로 분리되어 “고객 데이터 관련 질문”처럼 모든 FAQ를 한 번에 참조하는 검색에는 불리할 것으로 보입니다.

---

2. Recursive Chunking

Recursive 방식은 구분자(\n\n, \n, . 등)를 우선순위대로 적용해서, 의미 단위에 가깝게 분할합니다.

설정: chunk_size=100, overlap=10, separators=["\n\n", "\n", ". "]

관찰 포인트:

• \n\n이 섹션 사이 구분자 역할을 해줘서, “기본 원칙”이 하나의 청크에 온전히 담겼습니다
• “허용”과 “금지”가 Chunk 3에 함께 들어갔는데, 이건 두 섹션 사이에 줄바꿈이 \n 하나뿐이고 합쳐도 chunk_size 이하이기 때문으로 보입니다.
• FAQ 섹션(Chunk 5)도 Q&A 쌍이 깨지지 않고 한 덩어리로 유지되고 있습니다.
• Fixed 대비 섹션 경계 보존율이 훨씬 높습니다

---

3. Parent-Child Chunking

Parent-Child는 계층 구조를 활용합니다. 큰 단위(Parent)로 먼저 나누고, 각 Parent 안에서 다시 작은 단위(Child)로 분할합니다. 검색은 Child로 하되, 컨텍스트는 Parent를 반환합니다.

설정: parent_chunk_size=300, child_chunk_size=100

관찰 포인트:

• 총 4개의 Parent, 16개의 Child로 분할 — 평균 4개의 Child per Parent 시각적으로 봤을 땐 제일 정돈되고 이쁘다..
• Child는 100자 단위로 세밀하게 분리되어 있어 검색 정밀도가 높음
• 검색 시 Child가 매칭되지만, 컨텍스트는 해당 Parent 전체가 반환되어 LLM이 더 넓은 맥락을 참조 가능
• Fixed처럼 제목 청크가 노이즈로 끼어드는 문제 없이, 의미 단위로 깔끔하게 분리됨

---

전략별 비교 정리

기준	Fixed	Recursive	Parent-Child
구현 난이도	매우 쉬움	쉬움	보통
섹션 경계 보존	낮음	높음	높음
검색 정밀도	보통	좋음	매우 좋음
컨텍스트 풍부함	낮음	보통	높음
토큰 효율	좋음	좋음	보통 (Parent 크기에 따라)
한국어 적합도	낮음	높음	높음

---

검색 테스트

세 가지 전략으로 청킹한 결과에 대해, 같은 질문을 던져보고 어떤 청크가 매칭되는지 비교합니다.

차트 로딩 중...

Recursive와 Parent-Child 폴리곤이 많이 겹치는 것을 확인할 수 있고, Fixed는 Q2~Q5에서 안쪽에 위치합니다. 전반적으로 두 전략이 Fixed보다 근소하게 앞서며, Q3와 Q5에서 차이가 가장 두드러지는 것을 확인할 수 있습니다.

질문	Fixed	Recursive	Parent-Child	비고
Q1. AI 코드 배포	0.977	0.983	0.983	Fixed 제목 청크 노이즈
Q2. 고객 데이터 입력	0.959	0.961	0.961	세 전략 동일 패턴
Q3. 예외 규정	0.980	0.990	0.990	Recursive/PC 1위는 노이즈 청크
Q4. 빠른 요약 모델	0.968	0.969	0.969	세 전략 모두 직접 답변 Top 10 밖
Q5. 적용 대상	0.971	0.982	0.982	Fixed 노이즈, Recursive/PC 직접 매칭

수치 읽는 법

각 수치는 질문과 1위 매칭 청크 사이의 코사인 유사도입니다. 질문 텍스트와 각 청크를 동일한 임베딩 모델(Snowflake Arctic Embed XS, 384차원)로 벡터화한 뒤, 두 벡터 사이의 유사도 거리를 0~1로 나타낸 값입니다. 1에 가까울수록 의미적으로 유사하다는 뜻이며, 0.96 이상이면 실용적으로 높은 유사도로 볼 수 있습니다.

---

느낀 점

1. Fixed는 프로토타이핑용으로만. 실제 검색 테스트에서 Q1, Q5 모두 제목 청크나 관련 없는 FAQ가 상위에 끼어드는 노이즈가 반복됐습니다. 의미 단위가 아닌 글자 수로 잘리는 구조적 한계가 한국어 문서에서는 더 두드러지는 것을 알 수 있었습니다 🤣

2. Recursive가 실무 기본값. 5개 질문 중 3개에서 직접 답변이 1~2위로 안정적으로 매칭됐습니다. 구현도 간단하고 결과도 안정적이라 가성비가 가장 좋았습니다.

3. Parent-Child는 Recursive와 결과가 매우 유사했습니다. 이번 테스트 문서 기준으로는 두 전략의 유사도 점수와 순위가 거의 동일했습니다. 문서가 짧고 구조가 단순할수록 전략 차이가 줄어드는 것 같습니다. Parent-Child의 진가는 더 크고 복잡한 문서, 혹은 “왜?”까지 함께 반환해야 하는 맥락 검색에서 드러날 것으로 기대가 됩니다:)

4. 어떤 전략을 써도 Q4는 취약했습니다. “빠른 요약에 적합한 AI 모델은?” — 모델 선택 기준 청크가 세 전략 모두에서 Top 10 밖으로 밀렸습니다. 청킹 전략의 문제가 아니라 임베딩 유사도 자체의 한계입니다. 질문과 답변 텍스트 사이의 어휘 겹침이 낮을 때는 어떤 전략도 도움이 되지 않습니다ㅎㅎ…

---

마무리

RAG를 공부하면서 RAGPlay 도 그렇고 보통 디폴트로 Recursive를 많이 사용하기도 한다고 해서 청킹은 항상 “일단 Recursive로 하면 되지”라고 넘겼었는데, 이렇게 시각적으로 비교해보니 각 전략의 트레이드오프가 훨씬 명확하게 와닿았습니다 😃

특히 한국어 문서는 영어와 토크나이징 특성이 다르기 때문에, chunk_size 숫자만 복붙하면 안 되고 반드시 실제 결과를 눈으로 확인해야 한다는 걸 알 수 있었고, 생각보다 청킹보다 질문 설계가 더 중요할 수 있다는 것도 새로 깨달았습니다.

Q4 처럼 질문과 답변의 어휘가 크게 다를 때는 어떤 전략도 효과가 없는 거 같더라고요. RAG 품질을 올리고 싶다면 청킹 전략과 함께 쿼리 리라이팅이나 하이브리드 검색도 같이 고민해야 할 것 같습니다:)