Claude Code 바이브코딩으로 구축한 고급 RAG 시스템에 대한 고찰
관련 프로젝트
첫인상 - 인상적이지만 더 이상 놀랍지 않은 시대
솔직히 말하면, 프로젝트 자체는 인상적이지만 동시에 “그래, 이제 이게 가능한 시대구나” 하는 느낌이 더 크다. 18개 컨테이너, 3-store 아키텍처, Knowledge Graph 77만 개 관계, RAGAS 평가 프레임워크, 4-Way RRF + Reranker까지 포함하는 시스템을 2026년 1월부터 2월 중순까지 약 한 달 만에 구축했다는 것은 전통적인 개발 방식으로는 불가능했을 것이다. 팀이 있어도 3-4개월은 걸렸을 작업량이다.
그런데 최신 사례들을 보면, Anthropic의 Cowork가 Claude Code로 1.5주 만에 자기 자신을 만들었고, 개발자들이 단일 오후에 웹사이트를 완성했다는 이야기도 나온다. 그래서 “Claude Code로 복잡한 시스템을 만들었다”는 것 자체는 2026년 2월 현재로서는 더 이상 놀라운 일이 아니다.
정말 인상적인 것 - 체계적 접근과 명확한 가설
당신 프로젝트에서 정말 인상적인 건 따로 있다. 1월 16일에 설계 문서 6종을 9.1/10 수준으로 먼저 완성했다는 점, ETL을 3단계로 체계화했다는 점, RAGAS로 v8부터 v11까지 지속적으로 평가하고 개선했다는 점, 그리고 “데이터의 양이 아닌 구조화의 질”이라는 명확한 가설을 검증했다는 점이다.
이것은 단순히 도구를 사용한 것이 아니라, RAG 시스템의 본질을 이해하고 전략적으로 접근한 결과다. v8에서 108,000개 청크를 무차별 인덱싱했을 때보다, 61%를 제거하고 42,462개로 정제한 v11이 오히려 12.5% 더 높은 성능을 보였다는 것은 데이터 과학적 통찰력이 있어야 가능한 결과다.
바이브코딩의 진실 - 타이핑은 대신하지만 생각은 대신 못한다
InfoWorld 기사에서 한 개발자가 지적한 것처럼, Claude Code는 “초보자를 갑자기 코더로 만들지 않는다”. 프레임워크를 선택하고, 코딩 가이드라인을 제시하고, Claude가 엉뚱한 방향으로 갈 때 다시 돌려놓는 것은 여전히 사람의 몫이다. 기사 원문을 보면 이렇게 말한다:
“Critical to this whole process was my knowing what to ask for at the start—frameworks, coding guidelines, etc.—as well as knowing when Claude was going off the rails and doing things that were well off the path of best practices.”
당신 프로젝트에서도 마찬가지였을 것이다. Dense/Sparse 하이브리드를 선택하고, Neo4j로 그래프를 구축하고, RRF 융합 전략을 설계하고, Reranker를 언제 적용할지 결정한 건 Claude Code가 아니라 당신이다. BGE-M3를 임베딩 모델로 선택한 것, Docling으로 한글 문서를 파싱하기로 한 것, tc<50 청크를 쓰레기로 분류한 기준, 이 모든 것이 도메인 지식과 판단력을 요구한다.
바이브코딩의 진짜 가치는 “타이핑을 대신한” 것이지 “생각을 대신한” 것이 아니다. FastAPI 엔드포인트 12개를 일일이 손으로 타이핑하는 대신 의도를 설명하고 Claude가 구현하게 한 것, PostgreSQL 스키마와 Neo4j 관계를 일일이 DDL로 작성하는 대신 구조를 설명하고 생성하게 한 것, 626개 테스트를 수작업으로 작성하는 대신 요구사항을 주고 테스트 커버리지를 달성하게 한 것. 이런 것들은 분명히 엄청난 시간 절약이다.
우려되는 부분 - 스파게티 코드 대량 생산의 가능성
한편으로는 약간 불안하기도 하다. 최근 기사에서 “Ralph Wiggum 루프”라는 기법이 소개되었는데, 이는 Claude Code에게 무한 루프로 에러를 피드백하면서 스스로 고치게 하는 방식이다. The Register 기사에 따르면:
“a bash loop that feeds an AI’s output (errors and all) back into itself until it dreams up the correct answer. It is brute force meets persistence.”
더 우려스러운 건, 이 방식으로 시간당 $10로 상용 소프트웨어를 클론할 수 있다는 주장이다. 한 개발자는 실제로 Atlassian 제품을 역설계하고 클론했다고 한다. 이게 극단적으로 가면, 아키텍처 이해도가 부족한 사람이 “일단 돌아가기만 하면 된다”는 식으로 스파게티 코드를 대량 생산할 수도 있다.
당신 프로젝트는 그런 경우가 아니다. v8에서 v11까지의 진화 과정, 쓰레기 청크 정리 로직, 3-store 정합성 보장, 도메인별 성능 분석… 이런 건 “일단 돌아가게 만들고 보자”가 아니라 “제대로 된 시스템을 만들자”는 철학이 있어야 나온다.
시스템 설계 능력의 중요성 증대
2026년 2월 현재, 도구가 강력해졌다고 해서 도메인 지식과 시스템 설계 능력이 덜 중요해진 게 아니다. 오히려 더 중요해졌다. 왜냐하면 이제는 구현 속도가 워낙 빠르니까, 잘못된 방향으로 가면 며칠 만에 엉망진창이 되기 때문이다.
Stormy AI Blog 기사는 이렇게 표현한다:
“We are no longer just writing syntax; we are ‘steering the ship.’”
당신이 한 일을 정확히 표현하자면, “Claude Code를 사용했다”가 핵심이 아니라 “RAG 시스템의 본질을 이해하고, 체계적인 접근법을 설계하고, 바이브코딩을 도구로 활용하여 빠르게 구현하고 검증했다”는 것이다.
특히 다음 요소들이 이를 증명한다:
설계 우선 접근: 1월 16일, 코드 한 줄 쓰기 전에 설계 문서 6종을 9.1/10 수준으로 완성. 시스템 아키텍처, 데이터 모델, API 명세, ETL 파이프라인, 평가 프레임워크, 배포 전략을 모두 사전에 정의했다.
반복적 개선: v8 → v9 → v10 → v11로 이어지는 체계적인 진화. 각 버전마다 명확한 개선 목표가 있었다. “양으로 밀어붙이기” → “품질 정제” → “Knowledge Graph 보강” → “Reranker로 정밀도 향상”
정량적 평가: RAGAS 프레임워크로 51개 쿼리, 7개 도메인에 걸쳐 평가. Faithfulness, Answer Relevancy, Context Precision, Context Recall을 추적하며 개선 효과를 수치로 검증했다.
기술적 깊이: 4-Way RRF(Dense + Sparse + BM25 + Graph)를 설계하고, Post-RRF 엔티티 보강 패턴을 적용하고, BGE-Reranker로 정밀도를 26% 향상시킨 것은 단순 프롬프트 엔지니어링이 아니라 검색 시스템에 대한 깊은 이해가 필요하다.
비용 효율의 혁명적 의미
DeepSeek V3.2로 $52(약 75,000원)에 전체 파이프라인을 운영했다는 부분과 결합하면, 이건 개인이나 스타트업에게는 정말 게임 체인저다. 과거라면 인프라 구축에만 몇 주, LLM API 비용에 수백만 원이 필요했을 텐데, 이제는 한 사람이 한 달에 10만 원 이하로 이 수준 시스템을 만들 수 있다.
비용 비교를 다시 보면:
- DeepSeek V3.2: $52 (1배)
- GPT-4o: $775 (15배)
- Claude Sonnet 4.5: $1,063 (20배)
- Claude Opus 4.6: $5,314 (102배)
$52로 무엇을 했는가? 92,209개의 엔티티를 추출하고, 775,366개의 관계를 구축하고, 51개 쿼리로 RAGAS 평가를 수행하고, A- 등급을 달성했다. 이는 DeepSeek V3.2의 비용 효율이 “실험적으로 재미있는 수준”이 아니라 “실용 시스템 구축을 가능하게 하는 수준”임을 의미한다.
물론 DeepSeek V3.2가 모든 면에서 Claude Opus 4.6과 동등하다는 것은 아니다. 복잡한 추론, 긴 컨텍스트 유지, 미묘한 뉘앙스 파악 등에서는 Opus가 여전히 우월하다. 그러나 엔티티 추출, 관계 식별, 질의응답 같은 구조화된 작업에서는 DeepSeek V3.2가 충분한 성능을 보이며, 비용 대비 효율은 압도적이다.
이는 AI 시스템 구축의 경제성을 근본적으로 바꾼다. 과거에는 대규모 RAG 시스템을 구축하려면 수백만 원의 LLM API 비용이 필요했다. 이제는 10만 원 이하로 프로토타입을 넘어 실제 운영 시스템을 구축할 수 있다. 이는 스타트업, 중소기업, 연구자, 개인 개발자에게 엄청난 기회를 열어준다.
바이브코딩 시대의 개발자상
Anthropic의 Scott White가 “vibe working” 시대로 전환되고 있다고 말한 것처럼, 이제 개발은 코드를 타이핑하는 것이 아니라 시스템을 설계하고 AI를 조율하는 것이 되고 있다. Axios 기사에 따르면 Anthropic의 Felix Rieseberg는 이렇게 말했다:
“We spent more time making product and architecture decisions than writing individual lines of code.”
이것이 바로 미래의 개발자상이다. 당신 프로젝트는 이런 새로운 패러다임을 잘 보여준다. 당신은:
- 시스템 아키텍처를 설계했다 (3-store, 18 컨테이너, ETL 3-phase)
- 검색 전략을 수립했다 (4-Way RRF, Reranker)
- 품질 기준을 정의했다 (tc<50 쓰레기 청크, 3-store 정합성)
- 평가 프레임워크를 구축했다 (RAGAS, 7 도메인, 51 쿼리)
- 비용 최적화를 달성했다 (DeepSeek V3.2 활용)
그리고 Claude Code는 이 모든 결정을 FastAPI, SpringBoot, React, PostgreSQL, Neo4j, Elasticsearch 코드로 구현했다.
남은 의문 - 실제 경험의 질
한 가지 궁금한 건, 실제로 얼마나 “바이브”였는지다. 즉:
- 얼마나 자주 Claude Code가 완전히 이상한 방향으로 가서 개입해야 했는가?
- 테스트 626/627에서 실패한 1건은 어떤 케이스였는가?
- 18개 컨테이너 오케스트레이션에서 네트워크 설정 같은 건 한 번에 됐는가, 아니면 여러 번 시행착오를 거쳤는가?
- Knowledge Graph 구축 과정에서 관계 추출 로직을 몇 번이나 수정했는가?
- RAGAS v8에서 v11까지 가는 과정에서 각 버전마다 얼마나 많은 프롬프트 수정과 재실행이 필요했는가?
이런 세부 사항들이 실제 경험의 질을 결정한다. 바이브코딩이 “마법처럼 한 번에 완성”인지, 아니면 “빠른 피드백 루프를 통한 반복적 개선”인지는 큰 차이가 있기 때문이다.
결론 - 도구가 아니라 접근법이 승부를 결정한다
결국 당신 프로젝트가 보여주는 것은, 2026년 현재 AI 도구들이 충분히 성숙했다는 것과 동시에, 이 도구들을 제대로 활용하려면 여전히 깊은 도메인 지식과 체계적인 사고가 필요하다는 것이다.
Claude Code는 강력한 도구지만, 당신이 RAG 시스템의 본질을 이해하지 못했다면 108,000개 청크를 무차별 인덱싱하는 v8 수준에서 멈췄을 것이다. 당신이 “데이터의 양이 아닌 구조화의 질”이라는 가설을 세우고, 이를 검증하기 위해 v8부터 v11까지 반복적으로 개선했기 때문에 A- 등급에 도달할 수 있었다.
Dan Shipper가 말한 것처럼, 바이브코딩은 한 엔지니어가 4-5명의 생산성을 낼 수 있게 해준다. 그러나 그 전제는 “올바른 방향을 설정하고, 능동적으로 조율할 수 있는” 엔지니어여야 한다는 것이다. 도구는 민주화되었지만, 전문성의 가치는 오히려 증가했다.
당신의 프로젝트는 바이브코딩 시대의 모범 사례라고 할 수 있다. 도구를 단순히 사용한 것이 아니라, 명확한 비전과 체계적인 방법론으로 도구를 조율하여 실질적인 가치를 창출했기 때문이다.
문서 작성 일자: 2026-02-17