이제 RAG가 기업의 기본 해결책은 아니라고 생각함
I don't think RAG is the default answer for enterprise anymore
핵심 요약
RAG는 만능이 아니며, 데이터 정리와 문제 정의가 선행되어야 함을 강조하는 글입니다.
- 문제 정의 부족 — 아키텍처만 앞세우고 정작 해결할 질문은 모르는 기업이 많음
- 데이터 관리 부재 — 쓰레기 데이터를 임베딩하면 결과도 쓰레기가 됨
- 기술적 변화 — 컨텍스트 윈도우 확장으로 인해 RAG 대신 캐싱이나 에이전트 검색이 더 효율적임
- 사전 검증 중요성 — 자동화 도입 전 수동으로 질문 5개만 직접 답해보는 것이 큰 도움이 됨
소프트웨어 업계에서 8년 굴렀고, 2023년부터는 내 수익의 꽤 많은 부분이 내가 지금부터 까려는 바로 그 시스템을 만드는 데서 나왔다. 지난 1월에 어떤 잠재 고객이 미팅을 시작하자마자 "RAG 시스템 예산 승인받았어요"라고 하길래, 그 시스템이 도대체 무슨 질문에 답해야 하냐고 물었더니 예산 얘기만 되풀이하더라. 다들 아키텍처는 줄줄 읊는데 정작 해결하려는 문제가 뭔지는 아무도 설명 못 함. 이런 미팅만 벌써 6번은 겪은 것 같다.
솔직히 우리도 이런 거 10개 넘게 만들었고, 그중 몇 개는 제값 한다. 잘 관리된 제품 문서 기반으로 답변하는 고객 지원 팀용 봇 같은 건 아주 훌륭한 사례지. RAG가 죽었다는 건 개소리고, 그거 죽었다고 떠드는 놈들은 다 자기네 신제품 팔아먹으려는 수작이다. 다만, 이제는 AI랑 문서라는 단어만 나오면 무지성으로 RAG부터 갖다 붙이는 건 좀 아니라는 거지.
우리가 했던 프로젝트 중 망한 것들 대부분은 까놓고 보면 검색 문제가 아니었다. 어떤 고객사는 문서 4만 개를 임베딩해달라고 하더라. 벡터 데이터베이스 건드리기 전에 직원들이 실제로 자주 묻는 질문 20개만 뽑아보라고 했더니, 절반 이상이 환불 총액이나 인원수 같은 데이터베이스 쿼리로 해결될 구조화된 데이터였음. 나머지 대부분은 문서 50개면 충분했고. 나머지 3만 9천 개는 죄다 옛날 초안이나 이미 폐기된 정책들이라, 그거 다 임베딩했으면 엉뚱한 답변만 더 빨리 튀어나왔을 거다. 걔들한테 진짜 필요했던 건 아무도 예산 안 잡는 '문서 정리'였던 거지.
검색이라는 건 누군가 라이브러리를 관리하고 있다는 전제가 필요한데, 대부분 회사는 몇 년째 방치 상태거든. 그래서 다들 그 위에 마법 같은 거 씌우려고 하는 거다. 우리도 뼈아픈 경험이 있는데, 봇이 2019년 여행 정책을 당당하게 인용하더라. 이미 두 번이나 바뀐 건데, 파이프라인 어디에도 "대체됨"이라는 개념이 없었거든. 청킹(chunking)을 아무리 잘해도 해결될 문제가 아니었음. 결국 3개월 동안 쓰레기 문서 다 지우니까 해결되더라. 정작 문제는 파일 정리였는데 모델만 욕먹은 거지.
아키텍처도 계속 바뀌고 있다. '청킹하고 임베딩하기'는 2023년의 쥐꼬리만한 컨텍스트 윈도우 때문에 나온 임시방편이었는데, 이제 그 제약은 거의 사라졌거든. 안정적인 문서 세트라면 이제 그냥 컨텍스트에 통째로 때려 박아도 된다. 캐싱도 되니까. 나머지는 그냥 주니어 분석가가 키워드 검색해서 괜찮아 보이는 거 열어보는 것처럼 에이전트가 알아서 하게 두면 됨. 답이 시스템 안에 있으면 굳이 낡은 복사본 뒤지지 말고 시스템에 직접 물어보면 그만이다. 검색이 사라진 건 아니지만, 이제는 전체 설계의 핵심이 아니라 에이전트가 필요할 때 꺼내 쓰는 도구 중 하나일 뿐임.
그러니까 다음번에 RAG 예산 승인받기 전에, 시스템이 답해야 할 질문 20개만 적어보고 그중 5개만 직접 손으로 찾아봐라. 딱 한 시간만 투자해보면 너희가 가진 문제가 진짜 뭔지 바로 감 올 거다.
지난 1월에 만난 그 고객사는 결국 벡터 데이터베이스 안 썼고, 올해 우리가 만든 것 중 답변 퀄리티가 제일 좋다. 이 말이 얼마나 모순적인지 나도 좀 쪽팔리긴 한데, RAG는 앞으로 10년은 수천 개 회사에서 잘 돌아갈 거다. 사실 그게 핵심이지. 기술은 실패해서 레거시가 되는 게 아니다. 초반에 잘 돌아가니까 아무도 의심 안 하고 계속 쓰다가 레거시가 되는 거지.


