Claude CLI와 마크다운, 지식 그래프를 활용해 벡터 검색 RAG를 대체해 보았습니다. 결과가 놀랍네요.
I replaced vector-search RAG with Markdown + Knowledge Graphs using Claude CLI. The results surprised me.
핵심 요약
벡터 검색 대신 구조화된 마크다운 문서와 지식 그래프를 Claude에 제공하여 ERP 시스템의 답변 정확도를 크게 높인 실험 사례입니다.
- RAG 한계 극복 — 벡터 검색의 문맥 손실 문제를 구조화된 마크다운과 지식 그래프로 해결함
- 문서 중심 접근 — 코드와 별개로 비즈니스 로직과 관계를 명시한 문서를 통해 Claude의 이해도를 높임
- 성능 향상 — 복잡한 모듈 간 관계 질문에서 기존 RAG 대비 환각 현상을 95%가량 감소시킴
- 운영 과제 — 문서와 코드 간의 동기화 유지 및 다중 사용자 환경에서의 데이터 격리 방안을 고민 중임
최근에 이것저것 실험해 본 게 있어서 공유 좀 하려고. 이게 무슨 혁신적인 아키텍처라거나 RAG 문제를 완벽하게 해결했다는 건 절대 아님. 그냥 혹시 비슷한 거 시도해 본 사람 있나 궁금해서.
꽤 복잡한 ERP 애플리케이션용 AI 시스템을 만들고 있었거든. 처음에는 다들 쓰는 RAG 방식대로 임베딩하고, 벡터 검색 돌려서 관련 청크 가져온 다음에 LLM에 던져주는 식으로 했음.
근데 솔직히 결과물이 영 마음에 안 들더라.
문제는 LLM이 아니었음. 가끔은 검색해서 가져온 정보 자체가 부실한 게 문제였지. 모델이 개별 데이터베이스 테이블은 이해해도, 그 테이블들이랑 모듈, 비즈니스 규칙들이 어떻게 얽혀 있는지를 파악하는 건 차원이 다른 문제더라고.
그래서 생각했지. 애플리케이션 이해하려고 벡터 검색에만 매달리지 말고, 차라리 Claude한테 제대로 구조화된 지식 베이스를 통째로 먹여보면 어떨까?
내가 한 짓은 이거임.
애플리케이션에 있는 거의 모든 걸 마크다운 파일로 만들기 시작했어. 각 모듈이 어떻게 돌아가는지, 비즈니스 로직, 워크플로우, 모듈 간 관계, 조건, 예외 사항 같은 것들 말이야.
데이터베이스 문서도 따로 만들었음. 그냥 테이블 이름이랑 컬럼 정의만 적은 게 아님. 각 테이블이 실제로 뭘 의미하는지, 왜 존재하는지, 컬럼은 어떻게 쓰이는지, 비즈니스 관점에서 다른 테이블이랑 어떻게 연결되는지까지 다 적었지.
파일 작성하고 정리하는 방식에 엄청 신경 썼어. 수백 개의 잡다한 MD 파일이 굴러다니는 건 딱 질색이었거든. 모든 파일이 명확한 목적을 가져야 하고, 관련 문서랑 제대로 참조되고 연결되게끔 만들었음.
문서화가 끝나고 나서는 Claude한테 그 파일들을 읽게 한 다음, 전체 구조가 어떻게 연결되는지 그래프로 그려보라고 시켰어.
텍스트 청크 간의 의미론적 유사성에만 의존하는 대신, Claude가 애플리케이션 지식을 직접 이해하고 탐색할 수 있게 만든 거지.
그다음에는 읽기 전용 모드로 데이터베이스 쿼리를 실행하는 커스텀 MCP 서버를 만들었어. 덕분에 Claude가 동적인 정보가 필요할 때마다 실제 데이터베이스 레코드에 접근할 수 있게 됐지.
마지막으로 이 모든 걸 Claude CLI로 연결했음.
Claude가 사용자 질문을 어떻게 처리할지, 비즈니스 로직을 어떻게 이해할지, DB 쿼리는 어떻게 날릴지, 답변 포맷은 어떻게 잡을지, 차트나 시각화는 어떻게 만들지 같은 규칙이랑 지침을 짜는 데 시간을 꽤 썼어.
근데 여기서부터 진짜 재밌어지더라.
결과가 괜찮게 나오겠거니 싶었는데, 솔직히 예전에 쓰던 RAG 구현체보다 훨씬 잘 나옴. 여러 모듈이랑 비즈니스 규칙이 얽힌 복잡한 질문들도 놀라울 정도로 잘 처리해.
환각 현상은 한 95% 정도 줄어든 것 같은데, 제대로 된 벤치마크를 돌려본 건 아니라서 그냥 참고만 해.
특히 마음에 드는 건, 사용자가 할 법한 모든 질문에 대해 핸들러를 일일이 만들 필요가 없다는 거야. Claude가 알아서 요청을 이해하고 어떤 정보나 도구가 필요한지 판단하니까.
지금은 다중 사용자 지원을 실험 중인데, 이게 또 골치 아픈 문제임. 한 사용자의 대화나 세션, DB 접근 권한이 다른 사용자 정보로 절대 새어나가지 않게 확실히 막아야 하거든. 프롬프트 수준에서만 막는 게 아니라 애플리케이션이랑 MCP 서버 레벨에서 강제로 제어하려고 작업 중이야.
아직은 실험 단계임. 프로덕션에 올린 것도 아니고, 내가 미처 생각 못한 문제들이 분명히 있겠지.
벡터 데이터베이스나 기존 RAG가 쓸모없다는 건 아님. 분명히 제 자리가 있겠지. 근데 이번 엔터프라이즈 케이스에서는 내 '문서 우선(documentation-first)' 접근 방식이 훨씬 더 나은 결과를 보여주고 있어.
혹시 여기 비슷한 거 실험해 본 사람 있음? 내가 방향을 제대로 잡고 있는 건지, 아니면 뻔히 보이는 아키텍처 문제를 놓치고 있는 건지 궁금함.
실제로 프로덕션 AI 에이전트를 만들어봤거나 복잡한 엔터프라이즈 RAG 시스템 다뤄본 형들의 피드백을 간절히 기다림.
