RAG 6년이 남긴 설계 원칙 - 방식이 아니라 구멍을 보는 법
RAG 방식들은 서로 경쟁한 게 아니라 앞의 방식이 남긴 구멍을 메우며 나왔습니다. 6년의 순서를 설계 원칙으로 바꿔 정리하고, 제가 수치를 잘못 읽었던 기록도 함께 남깁니다.
방구석컴퍼니
혼자 일하는 사람 · 작업 기록
제 작업 메모에 이렇게 적혀 있었습니다.
꼬리표 붙이기 → 실패율 67% 감소. 이거 쓰면 됨.
이 줄은 틀렸습니다. 원문을 열어보니 67%는 꼬리표에 낱말 검색과 재선별까지 세 단계를 합쳤을 때 값이었고, 꼬리표 단독은 35%였습니다. 숫자 하나가 아니라 무엇을 하면 되는가가 바뀌는 오독이었어요. 67을 믿고 꼬리표만 붙인 사람은 "왜 안 되지"에서 멈춥니다.
이 글은 그 오독을 고치면서 정리한 것입니다. 방식 목록이 아니라 각 방식이 메우려던 구멍을 순서대로 놓고, 거기서 나오는 설계 원칙 세 가지를 적습니다.
남의 설계를 평가해야 하는데 근거가 없어 막히신 분들을 염두에 두고 썼습니다. 2026년 8월 기준으로 정리했습니다.
왜 RAG는 방식 목록이 아니라 구멍의 계보인가?
RAG는 방식 목록이 아니라 구멍의 계보입니다. 2020년 이후 나온 방식들은 서로 경쟁한 게 아니라, 앞 방식이 만든 문제를 뒤 방식이 메우는 순서로 등장했어요. 다만 이 순서는 논문 제목만 봐서는 안 보이고, 각 논문이 무엇을 반증했는지를 봐야 드러납니다.
시작은 단순했습니다. 2020년 패트릭 루이스 팀은 모델이 외운 것만 말하는 한계를 지적하며, 답하기 전에 자료를 찾아다 주는 구조를 정리했습니다. 논문은 이를 두 종류의 기억을 합치는 일로 설명합니다.
여기서 첫 구멍이 생깁니다.
자르기 - 맥락을 버리고 얻은 것
모델에 문서를 통째로 넣을 수 없으니 잘라서 저장합니다. 질문이 오면 비슷한 조각을 꺼내옵니다.
이 구조는 검색을 가능하게 만드는 대신 조각의 자기완결성을 포기합니다. "작년보다 15% 늘었습니다"만 잘려 나오면 주어도 기준연도도 없습니다. 원문에는 있었고, 자르는 과정에서 버려진 것입니다.
여기서 첫 번째 설계 원칙이 나옵니다. 검색 단위는 저장 단위가 아니라 이해 단위여야 한다. 저장하기 편한 크기로 자르면 검색은 되는데 이해가 안 됩니다.
길게 주기 - 그러면 가운데가 사라진다
자르지 않고 길게 주면 되지 않느냐는 반론은 자연스럽습니다. 2023년 스탠퍼드 연구진이 이걸 실제 측정으로 확인했습니다.
설계가 깔끔합니다. 문서 여러 개를 주고 정답이 든 문서의 위치만 바꿉니다. 다른 조건은 고정입니다. 결과는 U자 곡선이었습니다. 맨 앞과 맨 뒤는 잘 맞히고 가운데는 확 떨어집니다.
| 정답 위치 | 정확도 경향 |
|---|---|
| 앞부분 | 높음 |
| 가운데 | 뚜렷하게 낮음 |
| 뒷부분 | 높음 |
논문 제목이 「Lost in the Middle」입니다. 여기서 두 번째 원칙이 나옵니다. 입력을 늘리는 건 용량 문제를 푸는 것이지 주목 문제를 푸는 게 아니다. 넣을 수 있는 양과 실제로 읽히는 양은 다릅니다.
의심시키기 - 찾아온 걸 그냥 쓰지 않기
2023년 Self-RAG는 전혀 다른 곳을 건드립니다. 자르기도 길이도 아니라, 찾아온 자료를 검증 없이 쓰는 것이 문제라고 봤습니다.
네 가지를 스스로 묻게 만듭니다. 굳이 찾아야 하는가. 찾아온 게 질문과 관련이 있는가. 내 답이 그 자료에 실제로 적혀 있는가. 이 답이 묻는 사람에게 쓸모가 있는가.
세 번째 질문이 핵심입니다. 근거 없이 만들어낸 문장을 생성 시점에 걸러내려는 시도거든요. 사후 검증이 아니라요.
지도 그리기 - 조각으로는 못 덮는 질문
2024년 GraphRAG는 질문의 종류가 다르다는 데서 출발합니다. "이 자료 전체에서 가장 중요한 흐름은 무엇인가" 같은 질문은 조각 몇 개로 답할 수 없습니다. 아무리 잘 꺼내와도 전체를 대표하지 못하니까요.
그래서 미리 자료에서 인물·조직·사건을 뽑아 관계를 잇고, 비슷한 것끼리 묶어 요약을 만들어둡니다. 검색 대상을 조각에서 구조로 바꾸는 설계입니다.
대가는 분명합니다. 만드는 비용이 크고, 원본이 바뀌면 다시 그려야 합니다.
꼬리표 붙이기 - 가장 싼 회복
2024년 Anthropic이 공개한 접근은 훨씬 단순합니다. 잘린 조각 앞에 그 조각이 어느 문서 어느 맥락인지 한 줄을 덧붙여 저장합니다. 자르면서 버린 맥락을 조각 자체에 되돌려놓는 것입니다.
실측이 단계별로 공개돼 있습니다. 자료를 못 찾는 비율 기준입니다.
| 방법 | 실패율 | 기준 대비 감소 |
|---|---|---|
| 그냥 자르기 | 5.7% | - |
| + 꼬리표 | 3.7% | 35% |
| + 낱말 검색 | 2.9% | 49% |
| + 재선별 | 1.9% | 67% |
제가 처음에 잘못 읽은 표가 이것입니다. 마지막 줄만 보고 첫 단계의 효과로 옮겨 적었어요. 표를 인용할 때는 어느 행을 인용하는지까지가 인용입니다.
세 번째 원칙이 여기서 나옵니다. 회복 비용이 가장 싼 곳부터 손댄다. 꼬리표 한 줄이 손 대비 회수가 가장 좋고, 나머지는 필요해질 때 얹는 순서입니다.
먼저 생각하기 - 한 번에 끝내지 않기
2025년 이후 정리되는 Agentic RAG는 순서를 바꿉니다. 질문이 오면 바로 찾으러 가는 대신, 무엇을 알아봐야 하는지 먼저 계획하고, 찾아온 게 부족하면 다시 찾습니다.
사람이 자료 조사할 때 하는 순서와 같습니다. 검색창부터 열지 않고, 뭘 알아봐야 하는지 정리한 다음 부족하면 또 찾잖아요.
한국어에서는 이 계보가 그대로 적용될까?
한국어에서는 적용되지만 숫자는 다시 재야 합니다. 위 실험들이 대부분 영어 문서 기준이기 때문입니다.
국내 연구진이 올해 학회 논문지에 한국어 직접 측정 결과를 발표했습니다. 위키 문서 612건과 질문답변 1,500쌍을 표본으로, 분할 방식만 달리해 비교한 실험입니다.
- 200자 고정 크기가 정답률 68.8% 로 가장 높았습니다
- 문장 단위 분할이 가장 낮았습니다 — 직관과 반대입니다
- 300자를 넘기면 관련 조각을 찾아오는 성능은 계속 개선되는데 정답률은 떨어집니다
세 번째가 설계자에게 중요합니다. 검색 지표와 응답 지표가 갈라지는 구간이 존재한다는 뜻이거든요. 검색 성능만 보고 튜닝하면 답이 나빠지는 방향으로 최적화할 수 있습니다.
이 정리에서 제가 틀릴 수 있는 곳
세 군데를 적어둡니다.
첫째, 계보를 선형으로 그렸지만 실제로는 같은 시기에 병렬로 나온 것들입니다. "앞의 구멍을 뒤가 메웠다"는 서술은 사후 정리라 인과를 과장할 위험이 있습니다.
둘째, 한국어 실측은 위키백과 기준 한 편입니다. 문서 종류가 다르면 200자라는 값은 흔들립니다. 값보다 "직접 재봐야 한다"는 절차가 이 논문에서 가져갈 것에 가깝습니다.
셋째, 저는 이 방식들을 대규모로 운영해본 당사자가 아닙니다. 논문과 공개 실측을 대조해 정리한 것이고, 운영 비용에 대한 판단은 실제로 굴려본 쪽의 기록을 더 믿으셔야 합니다.
세 원칙으로 다시 정리하면
- 검색 단위는 저장 단위가 아니라 이해 단위여야 한다
- 입력을 늘리는 건 용량 문제를 푸는 것이지 주목 문제를 푸는 게 아니다
- 회복 비용이 가장 싼 곳부터 손댄다
그리고 이 셋에 대응하는 확인 항목이 있습니다.
- 내 조각 하나를 떼어 읽었을 때 무슨 말인지 알 수 있는가
- 긴 입력의 가운데 정보를 실제로 물어봤는가
- 꼬리표 한 줄을 붙여보기 전에 관계 지도부터 계획하고 있지 않은가
새 방식이 나오면 물어볼 것도 하나입니다. 이건 어느 구멍을 메우려는 건가. 그 구멍이 지금 내 구조에 비어 있지 않다면, 좋은 방식이어도 나에게는 필요 없는 방식입니다.
여러분 문서에서는 세 확인 항목 중 어디가 먼저 걸리던가요.