RAG 정확도는 이제 덜 중요해졌다 — Claude Code가 바꿔버린 구조(feat.GPT, CLAUDE)

1. 1년 동안 RAG 정확도를 90%까지 올렸다

나는 1년 넘게 RAG Agent의 정확도를 끌어올리는 작업을 했다.
Query 튜닝, chunk 전략, embedding, re-ranking까지 다 건드렸다.

그 결과, 약 90% 수준의 정답률이 나왔다.

여기까지는 기존 RAG 프로젝트의 정석적인 목표였다.
“한 번의 질문으로 정답을 맞춘다”

---

2. 그런데 Claude Code를 붙이니까 게임이 바뀌었다

최근 흥미로운 케이스를 봤다.

Claude Code의 skills에
내가 만든 RAG agent를 tool처럼 연결해두고,

agent가 알아서:

• 질의어를 바꾸고
• 여러 번 검색하고
• 결과를 비교하면서

정답을 찾게 만든 구조였다.

이걸 보고 깨달은 게 있다.

---

3. 문제의 정의가 바뀌었다

기존:

• 1번 질문 → 1번 검색 → 정답 판단

지금:

• 여러 번 질문 → 여러 번 검색 → 가장 좋은 결과 선택

즉,

👉 “정확도 문제” → “탐색 문제”로 바뀌었다

---

4. 그래서 생긴 생각: RAG 정확도 덜 중요해진 것 아닌가?

이전에는:

• RAG 정확도 = 시스템 성능

지금은:

• RAG 정확도 = 전체 시스템의 일부

왜냐하면:

• Query mismatch → agent가 다시 시도
• Recall 부족 → 다른 query로 보완
• 일부 오답 → 비교해서 제거

즉, Agent가 RAG의 약점을 흡수한다

---

5. 그럼 온톨로지는 필요 없는가?

이 질문이 자연스럽게 나온다.

결론부터 말하면:

👉 없어지는 게 아니라 역할이 바뀐다

과거:

• 온톨로지 = 정확도를 높이기 위한 구조

현재:

• 온톨로지 = 탐색을 빠르게 하기 위한 구조

---

6. 왜 여전히 필요한가

Agent가 모든 걸 해결해줄 것 같지만 현실은 다르다.

• 탐색 공간이 크면 비용이 폭발한다
• 재시도 횟수가 늘어나면 지연 증가
• 토큰 비용 증가
• 잘못된 경로로 계속 탐색할 수도 있음

즉,

👉 온톨로지는 “정답률”이 아니라
👉 **“탐색 비용을 줄이는 장치”**다

---

7. 현재 구조의 본질

지금의 구조를 정리하면 이렇다.

• RAG → 데이터 접근 인터페이스
• Agent → 탐색 및 판단 엔진
• 온톨로지 → 탐색 가이드

이 셋이 역할이 분리됐다.

---

8. 실무에서 느낀 가장 큰 변화

예전에는:

• embedding 튜닝
• chunk 전략
• retriever 성능

이게 핵심이었다.

지금은:

• query rewriting 전략
• retry loop 설계
• tool orchestration
• 결과 평가 로직

이게 더 중요해졌다.

---

9. 중요한 오해 하나

“그럼 RAG는 대충 만들어도 되나?”

→ 아니다.

👉 기본 정확도가 낮으면 agent도 못 살린다

하지만:

• 70~85% 수준이면 충분한 경우가 많고
• 나머지는 agent가 끌어올린다

---

10. 결론

Claude Code 이후, 구조가 바뀌었다.

• RAG는 더 이상 핵심 엔진이 아니다
• Agent가 중심이 된다

그리고 앞으로의 경쟁력은 여기서 갈린다:

👉 “얼마나 정확하게 찾느냐”가 아니라
👉 “얼마나 잘 탐색하게 만드느냐”

---

한 줄 요약

RAG는 답을 찾는 기술이 아니라,
Agent가 탐색할 수 있는 인터페이스가 되었다