- 공유 링크 만들기
- X
- 이메일
- 기타 앱
요즘 개발하는 방식이 참 많이 바뀌었죠. 저도 20년 가까이 개발자로 밥벌이를 하다 보니 웬만한 변화에는 덤덤한 편인데, 솔직히 AI 바이브 코딩은 좀 다르게 느껴졌어요. 예전에는 IDE 열고 로그 찍고 문서 뒤지고 Stack Overflow 검색하면서 하루를 보냈다면, 요즘은 AI에게 “이 코드 좀 봐줘”, “여기 리팩토링 방향 잡아줘” 하고 먼저 물어보게 되더라고요. 그런데 어느 순간부터 묘하게 답답했습니다. AI가 똑똑하긴 한데, 내 프로젝트를 모르는 거예요. 마치 회의에 처음 들어온 외부 컨설턴트가 우리 회사 사정을 하나도 모르면서 정답을 말하는 느낌이랄까요. 그래서 한동안 붙잡고 삽질했던 게 바로 RAG를 이용한 코드베이스 검색입니다.
처음엔 저도 가볍게 생각했어요. “그냥 프로젝트 파일 몇 개 던져주면 알아서 잘하겠지.” 뭐, 이런 마음이었죠. 그런데 레거시 프로젝트 하나만 열어봐도 파일 수가 몇백 개고, 클래스 이름도 비슷비슷하고, 예전에 급하게 만든 유틸 함수들은 어디 숨어 있는지도 모릅니다. 그걸 LLM에게 통째로 먹이겠다는 건, 제주도 여행 가면서 캐리어에 겨울 패딩부터 전기밥솥까지 다 넣고 가겠다는 얘기랑 비슷하더라고요. 필요한 것만 잘 챙겨야 편합니다. 코드도 마찬가지였어요.
AI가 내 코드를 모르면 생기는 은근히 피곤한 일들
제가 이걸 진지하게 고민하게 된 계기가 하나 있었어요. 예전에 운영 중이던 Spring Boot 프로젝트에서 사용자 조회 로직을 리팩토링하려고 GPT에게 물어본 적이 있습니다. 질문은 나름 친절하게 했어요. “UserService의 사용자 조회 흐름을 개선하고 싶은데, 어떤 구조가 좋을까?” 이런 식이었죠.
그런데 답변이 꽤 그럴듯했습니다. repository 패턴을 기준으로 계층을 나누고, 예외 처리를 공통화하고, DTO 변환을 분리하라고 하더라고요. 말만 들으면 맞는 얘기예요. 문제는 우리 프로젝트가 그 구조가 아니었다는 겁니다. repository 패턴을 거의 안 쓰고 있었고, queryDSL을 서비스 레이어에서 상당히 직접적으로 다루고 있었어요. 심지어 일부 조회 로직은 성능 때문에 Native Query까지 섞여 있었습니다.
그때 살짝 허탈했어요. 답변이 틀렸다기보다, 우리 사정을 모르는 사람이 너무 자신 있게 말하는 느낌이었거든요. 이게 바로 RAG 없이 LLM에게 코드 질문을 했을 때 자주 생기는 문제입니다. LLM은 일반적인 개발 지식은 잘 말해주지만, 내 코드베이스 안에 있는 진짜 맥락은 모릅니다.
그 뒤로는 질문 방식도 바꿔봤어요. 관련 클래스를 복사해서 붙여넣고, 에러 로그도 넣고, “이 프로젝트는 repository 패턴을 안 써”라고 조건도 달아봤죠. 그런데 이 방식도 금방 한계가 오더라고요. 토큰은 토큰대로 많이 쓰고, 매번 필요한 파일을 사람이 골라서 넣어야 하니까 피곤합니다. 개발 생산성을 올리려고 AI를 쓰는 건데, AI에게 먹일 자료를 준비하느라 제가 더 바빠지는 이상한 상황이 된 거죠.
그래서 방향을 바꿨습니다. “내가 매번 설명하지 말고, 질문할 때마다 관련 코드만 자동으로 찾아서 LLM에게 넘겨주자.” 이게 제가 코드베이스 RAG를 붙이게 된 출발점이었어요.
코드베이스 RAG는 생각보다 단순하지만, 대충 만들면 바로 티가 납니다
개념만 놓고 보면 RAG는 그렇게 복잡하지 않습니다. 코드베이스를 적당한 단위로 쪼갭니다. 그 조각들을 임베딩해서 벡터 DB에 넣습니다. 사용자가 질문하면 관련 있는 코드 조각을 검색합니다. 그리고 그 검색 결과를 LLM 프롬프트에 같이 넣어줍니다.
말은 참 쉽죠. 저도 처음엔 “이 정도면 주말에 대충 붙이면 되겠네” 싶었습니다. 그런데 실제로 해보니 포인트는 따로 있더라고요. 코드를 어떻게 쪼갤지, 검색 결과를 몇 개나 가져올지, LLM에게 그대로 넣을지 한 번 정리해서 넣을지, 이런 작은 결정들이 결과 품질을 확 갈랐습니다.
제가 처음 만들었던 구조는 대충 이런 식이었어요.
/project-rag
/src
indexer.py
retriever.py
prompt_builder.py
/data
source_chunks.json
embeddings.index
/config
rag-config.yml처음에는 파일 단위로 코드를 읽어서 그대로 임베딩했습니다. 예를 들어 UserService.java 파일 하나를 통째로 하나의 문서처럼 넣은 거죠. 얼핏 보면 괜찮아 보입니다. 그런데 검색 결과가 너무 둔탁해졌어요. “이메일 중복 체크 로직 어디 있어?”라고 물었는데 UserService 전체가 검색되고, 그 안에 로그인 처리, 권한 체크, 프로필 조회, 이벤트 발행 코드까지 줄줄이 딸려 나오는 식이었습니다.
LLM 입장에서는 갑자기 관련 없는 코드까지 잔뜩 받은 셈이에요. 그러면 답변이 산으로 갑니다. 인간도 마찬가지잖아요. 친구가 “서울역 근처 맛집 하나만 추천해줘”라고 물었는데, 제가 서울시 전체 음식점 리스트를 보내면 고마운 게 아니라 짜증 나겠죠.
청크는 파일 단위보다 함수 단위가 훨씬 편했습니다
제가 가장 크게 체감한 부분은 청크 사이즈였습니다. RAG에서 청크를 어떻게 나누느냐가 정말 중요하더라고요. 처음에는 1000토큰 정도로 무식하게 잘랐습니다. 그랬더니 함수 중간이 잘리거나, 반대로 여러 함수가 한 청크에 섞이는 일이 많았어요. 검색 품질이 들쭉날쭉했습니다.
몇 번 갈아엎고 나서 정착한 방식은 함수나 메소드 단위로 청크를 나누는 방식이었습니다. 개발자가 실제로 질문하는 단위가 대부분 함수 단위거든요. “findByEmail이 어디서 호출돼?”, “validateToken에서 만료 체크 어떻게 해?”, “createOrder 안에서 재고 차감 순서 맞아?” 이런 식이잖아요.
그래서 저는 간단한 파서를 만들어서 아래 정보를 같이 저장했습니다.
- 파일 경로
- 클래스명 또는 모듈명
- 함수명 또는 메소드명
- 함수 시그니처
- 주요 로직 본문
- 근처 주석 또는 docstring
- 호출 관계가 있으면 호출 대상 함수명
이렇게 바꾸고 나니 체감이 확 왔습니다. 예전에는 질문 한 번에 관련 없는 코드가 잔뜩 붙어서 3000토큰 넘게 쓰던 경우가 많았는데, 함수 단위로 쪼개고 나서는 1000토큰 안쪽으로 해결되는 일이 꽤 늘었습니다. 대략적으로는 토큰 사용량이 50~60% 정도 줄어든 느낌이었어요. 물론 프로젝트마다 다르겠지만, 제 경우에는 확실히 효과가 있었습니다.
| 청크 방식 | 제가 느낀 장점 | 실제로 불편했던 점 | 추천 정도 |
|---|---|---|---|
| 파일 단위 | 구현이 제일 쉽습니다 | 불필요한 코드가 너무 많이 딸려옵니다 | 작은 프로젝트에서만 괜찮음 |
| 고정 토큰 단위 | 언어 상관없이 처리하기 편합니다 | 함수 중간이 잘리는 일이 잦습니다 | 초기 테스트용 |
| 함수 또는 메소드 단위 | 질문 의도와 가장 잘 맞습니다 | 파서 구현이 조금 귀찮습니다 | 실무에서 가장 추천 |
여기서 재미있는 게 하나 있었어요. 처음엔 주석을 다 빼려고 했습니다. 토큰 아끼려고요. 그런데 오래된 프로젝트일수록 주석에 중요한 사연이 들어 있는 경우가 많더라고요. “이 로직은 PG사 응답 지연 때문에 재시도하지 않음” 같은 주석 말입니다. 코드만 보면 이상한데, 주석을 보면 이유가 있는 경우가 있어요. 그래서 저는 주석을 무조건 제거하지 않고, 함수 바로 위에 붙은 주석이나 docstring 정도는 같이 저장하는 쪽으로 바꿨습니다.
벡터 검색만 믿었다가 함수명을 못 찾는 걸 보고 정신이 번쩍 들었습니다
RAG라고 하면 보통 벡터 검색을 먼저 떠올리잖아요. 의미 기반으로 비슷한 문서를 찾아주는 방식이니까, 코드 검색에도 잘 맞을 거라고 생각했습니다. 그런데 막상 해보니 코드베이스 검색에서는 벡터 검색만으로는 부족한 순간이 꽤 많았습니다.
예를 들어 사용자가 “getUserProfile 호출하는 곳 찾아줘”라고 물었다고 해볼게요. 이건 의미 검색보다 정확한 문자열 매칭이 중요합니다. 함수명이 getUserProfile이면 getUserProfile을 찾아야지, “사용자 프로필 조회”와 의미적으로 비슷한 다른 함수가 나와버리면 곤란하거든요.
실제로 저는 이런 일을 겪었습니다. “sendPaymentCancelEvent” 관련 로직을 찾고 있었는데, 벡터 검색 결과 상위에 “cancelPayment” 함수가 올라왔습니다. 의미상 비슷하긴 하죠. 그런데 제가 찾던 건 이벤트 발행 함수였고, 결제 취소 실행 함수가 아니었습니다. 그날 괜히 로그만 한참 봤습니다. 뭐랄까, 길 찾을 때 네비가 목적지 근처까지는 데려다줬는데 골목 하나를 잘못 알려준 느낌이었어요.
그래서 지금은 벡터 검색과 키워드 검색을 같이 쓰는 하이브리드 검색을 선호합니다. 저는 Elasticsearch 쪽에 코드 인덱스를 걸어두고, 함수명이나 변수명은 BM25 기반으로 찾고, 의미 기반 후보는 벡터 검색으로 가져온 뒤 점수를 합치는 식으로 구성했습니다.
| 검색 방식 | 좋았던 점 | 아쉬웠던 점 | 어울리는 상황 |
|---|---|---|---|
| 벡터 검색 | 질문이 애매해도 의미를 잘 잡습니다 | 정확한 함수명, 변수명 검색에는 약합니다 | 로직 설명, 유사 코드 탐색 |
| 키워드 검색 | 함수명과 에러 메시지를 정확히 잡습니다 | 표현이 다르면 놓치기 쉽습니다 | 함수 호출 위치, 상수명, 로그 문구 검색 |
| 하이브리드 검색 | 정확도와 유연함을 같이 챙길 수 있습니다 | 점수 조정과 구현이 조금 번거롭습니다 | 실무 코드베이스 검색 |
제 기준으로는 하이브리드 검색을 붙인 뒤부터 답변이 훨씬 안정적이었습니다. 정확도를 숫자로 딱 잘라 말하긴 어렵지만, 제가 테스트했던 50개 정도의 질문 세트에서는 원하는 파일이나 함수가 상위 3개 안에 들어오는 비율이 확실히 올라갔어요. 체감상 80%대에서 90%대 중반까지 올라간 느낌이었습니다.
검색 결과를 그대로 넣지 말고, 한 번 정리해서 넣는 게 토큰 절약에 좋았습니다
RAG를 처음 붙이면 괜히 마음이 넉넉해집니다. 검색 결과 5개, 10개씩 가져와서 LLM에게 넘기고 싶어져요. 저도 그랬습니다. “관련 있을 수도 있으니까 일단 다 넣자.” 이 마음이죠. 그런데 이러면 RAG를 쓰는 의미가 반쯤 사라집니다. 토큰이 다시 줄줄 새거든요.
제가 써보니 중요한 건 검색 결과를 그대로 프롬프트에 넣지 않는 것이었습니다. 코드 조각 안에는 import문, 오래된 주석, 지금 질문과 상관없는 분기문이 섞여 있는 경우가 많습니다. 그래서 저는 중간에 아주 얇은 전처리 단계를 하나 뒀습니다.
예를 들면 이런 식입니다.
질문:
UserService의 이메일 중복 체크 로직이 어떤 흐름으로 동작하는지 설명해줘.
검색 결과:
1. UserService.checkDuplicatedEmail(...)
2. UserQueryService.findByEmail(...)
3. SignupValidator.validateEmail(...)
전처리 요청:
각 코드 조각에서 질문과 직접 관련된 핵심 로직만 5줄 이내로 추려줘.
파일 경로와 함수명은 유지해줘.
추측하지 말고 코드에 있는 내용만 정리해줘.이렇게 한 번 줄여서 넣으면 LLM 답변이 훨씬 담백해졌습니다. 불필요한 설명도 줄고, 엉뚱한 추측도 줄었습니다. 특히 토큰 절약에는 꽤 효과가 있었어요. 500토큰짜리 청크 5개를 그대로 넣으면 2500토큰이 훌쩍 넘어가는데, 핵심만 추리면 600~800토큰 안쪽으로 들어오는 경우가 많았습니다.
다만 여기서 조심할 점도 있습니다. 전처리 요약을 너무 과하게 하면 중요한 조건문이 빠질 수 있어요. 예를 들어 결제 로직이나 권한 체크 로직은 한 줄 빠지는 순간 의미가 바뀝니다. 그래서 저는 요약 프롬프트에 꼭 이 문장을 넣습니다.
예외 처리, 권한 체크, 트랜잭션 처리, 외부 API 호출, 데이터 변경 로직은 생략하지 마세요.별거 아닌 문장처럼 보이는데, 이거 하나 넣고 안 넣고 차이가 꽤 있었습니다. 특히 리팩토링이나 버그 분석할 때는 저런 부분이 진짜 중요하거든요. 겉으로 보기엔 부수적인 코드 같은데, 운영 장애는 보통 그런 데서 납니다.
실제 설정에서 제일 많이 삽질한 건 chunk overlap이었습니다
제가 LangChain 기반으로 RAG 파이프라인을 만들 때 가장 귀찮게 느꼈던 설정이 chunk overlap이었습니다. 처음에는 overlap을 0으로 뒀어요. 깔끔해 보이잖아요. 중복도 없고, 저장 공간도 덜 쓰고, 토큰도 아낄 것 같고요.
그런데 바로 문제가 생겼습니다. 함수 시작부와 본문이 애매하게 갈라지는 경우가 있었어요. 특히 Java처럼 annotation이 여러 줄 붙거나, TypeScript처럼 타입 정의가 긴 함수는 시그니처와 본문이 다른 청크로 갈라지더라고요.
그때 제가 봤던 로그가 대충 이런 느낌이었습니다.
[RAG_SEARCH]
query: "findUser 파라미터 검증 로직 알려줘"
top_k: 5
result_1:
file: UserService.java
score: 0.72
content: "if (user == null) { throw new UserNotFoundException(); } ..."
missing:
method signature not found
parameter context not found검색은 됐는데 함수 시그니처가 빠져 있으니 LLM이 파라미터를 제대로 설명하지 못했습니다. 이게 참 애매합니다. 사람은 파일 열어서 위아래를 보면 되는데, LLM은 프롬프트에 들어온 조각만 보고 판단하니까요.
그래서 지금은 대략 이런 기준으로 잡습니다.
- 짧은 함수가 많은 프로젝트는 250~400토큰 정도
- 비즈니스 로직이 긴 Java 서비스 클래스는 400~700토큰 정도
- chunk overlap은 보통 50~100토큰 사이
- 함수 단위 파싱이 가능하면 overlap 의존도를 낮춤
- annotation, decorator, docstring은 함수 본문과 같이 묶음
물론 정답은 없습니다. 프로젝트마다 코드 스타일이 다르니까요. 그래도 제가 느낀 건, overlap을 너무 아끼면 검색 품질에서 손해를 보고, 너무 크게 잡으면 토큰과 저장 공간이 새어나간다는 겁니다. 적당히가 어렵죠. 개발 인생 대부분이 그런 것 같습니다.
임베딩 모델은 아무거나 쓰면 안 되더라고요
처음에는 OpenAI의 범용 임베딩 모델을 사용했습니다. 세팅도 쉽고, 문서도 많고, 일단 빨리 붙이기 좋으니까요. 일반적인 문서 검색에는 꽤 괜찮았습니다. 그런데 코드 검색에서는 가끔 아쉬운 순간이 있었습니다.
특히 변수명, 함수명, 코드 구조를 잘 이해해야 하는 질문에서는 결과가 미묘하게 빗나갔습니다. “tokenExpiredAt” 같은 필드를 찾고 싶은데, 의미상 비슷한 “refreshToken” 쪽 로직이 올라오는 경우가 있었어요. 문장 의미로 보면 비슷하지만, 개발자가 원하는 건 그게 아니잖아요.
그래서 코드 특화 모델도 테스트했습니다. CodeBERT, GraphCodeBERT 같은 모델을 붙여봤는데, 확실히 코드 구조나 식별자 처리에서 나은 부분이 있었습니다. 물론 로컬에서 제대로 돌리려면 환경 세팅이 조금 번거롭고, GPU가 있으면 편합니다. 회사 보안 정책 때문에 외부 API로 코드를 보내기 어려운 환경이라면, 이런 로컬 임베딩 모델을 검토할 만합니다.
| 임베딩 선택지 | 장점 | 주의할 점 | 제가 추천하는 상황 |
|---|---|---|---|
| 범용 임베딩 API | 빠르게 붙일 수 있고 운영이 편합니다 | 코드 식별자 이해가 아쉬울 수 있습니다 | PoC, 개인 프로젝트, 문서 검색 병행 |
| CodeBERT 계열 | 코드 구조와 식별자 처리에 강합니다 | 환경 세팅과 성능 튜닝이 필요합니다 | 사내 코드 검색, 보안 민감 프로젝트 |
| 하이브리드 구성 | 문서와 코드를 함께 다루기 좋습니다 | 파이프라인이 복잡해집니다 | 큰 조직의 레거시 분석 도구 |
여기서 제 생각은 좀 분명합니다. 처음부터 너무 완벽한 구성을 만들려고 하면 지칩니다. 일단 범용 임베딩 API로 빠르게 PoC를 만들고, 실제 질문 로그를 모아본 뒤에 코드 특화 모델로 갈아타도 늦지 않습니다. 도구는 멋있게 만드는 것보다, 팀원이 실제로 쓰게 만드는 게 먼저더라고요.
프롬프트는 친절하게, 대신 추측할 틈은 줄여야 합니다
RAG를 붙였다고 해서 프롬프트가 대충이어도 되는 건 아닙니다. 오히려 저는 RAG 이후에 프롬프트를 더 신경 쓰게 됐어요. 검색된 코드 조각이 들어가면 LLM은 그걸 근거로 답변해야 하는데, 지시가 흐릿하면 또 일반론을 섞습니다.
제가 자주 쓰는 기본 프롬프트는 이런 느낌입니다.
당신은 이 코드베이스를 분석하는 시니어 개발자입니다.
아래 제공된 검색 결과만 근거로 답변하세요.
검색 결과에 없는 내용은 추측하지 말고 "제공된 코드만으로는 확인하기 어렵다"고 말하세요.
답변할 때는 다음 순서로 정리하세요.
- 관련 파일과 함수
- 실제 동작 흐름
- 주의해야 할 예외 처리나 부작용
- 리팩토링이 필요하다면 최소 변경 방향
이 프롬프트에서 제가 제일 중요하게 보는 문장은 “검색 결과에 없는 내용은 추측하지 말라”는 부분입니다. LLM은 빈칸을 채우고 싶어 합니다. 그게 장점이기도 한데, 코드 분석에서는 위험할 때가 많아요. 없는 함수를 있다고 말하거나, 실제로는 호출되지 않는 흐름을 그럴듯하게 설명하면 개발자는 시간을 날립니다.
또 하나 좋았던 방식은 답변 형식을 고정하는 겁니다. 특히 팀에서 같이 쓸 때는 “관련 파일”, “동작 흐름”, “주의점”, “수정 제안” 정도로 틀을 잡아두면 리뷰하기 편합니다. 매번 답변 모양이 달라지면 사람이 다시 정리해야 하거든요.
제가 실제로 남겨둔 RAG 설정 체크리스트
여러 번 망치고 나니, 나름의 체크리스트가 생겼습니다. 지금도 새 프로젝트에 RAG를 붙일 때는 이걸 먼저 봅니다. 대단한 건 아닌데, 안 챙기면 꼭 나중에 귀찮아지는 것들이에요.
- 코드 청크는 가능하면 함수 또는 메소드 단위로 나눈다.
- 파일 경로, 클래스명, 함수명은 메타데이터로 반드시 저장한다.
- 함수명과 변수명 검색을 위해 키워드 검색을 같이 둔다.
- 검색 결과 top_k는 처음부터 크게 잡지 말고 3~5개부터 시작한다.
- 검색 결과를 LLM에 넣기 전, 질문과 관련된 부분만 줄인다.
- 보안상 민감한 키, 토큰, 개인정보는 인덱싱 전에 제거한다.
- 프롬프트에는 “제공된 코드만 근거로 답변”이라는 제한을 넣는다.
- 답변 품질은 실제 개발자가 던지는 질문 로그로 평가한다.
특히 보안 쪽은 꼭 조심하셔야 합니다. 코드베이스를 인덱싱하다 보면 application.yml, .env, 운영 URL, API Key 같은 게 섞일 수 있습니다. 개인 프로젝트야 실수하고 지우면 되지만, 회사 코드에서는 얘기가 다르죠. 저는 인덱싱 전에 아래 패턴은 무조건 필터링하도록 했습니다.
SECRET
PASSWORD
API_KEY
ACCESS_TOKEN
PRIVATE_KEY
client-secret
jdbc:password
Authorization이건 귀찮아도 해야 합니다. AI 도구 잘 쓰려다가 보안 사고 나면 생산성이고 뭐고 다 의미 없어지니까요. 나이 먹고 개발 오래 하다 보니, 빠른 것보다 안 터지는 게 더 중요하다는 걸 자주 느낍니다.
RAG를 붙였다고 AI가 갑자기 만능 팀원이 되는 건 아닙니다
솔직히 말하면, 코드베이스 RAG를 붙인다고 해서 AI가 갑자기 우리 팀의 10년 차 개발자처럼 변하진 않습니다. 그래도 차이는 큽니다. 예전에는 AI가 일반적인 얘기를 했다면, RAG를 붙인 뒤에는 적어도 우리 프로젝트 안에 있는 코드 조각을 근거로 얘기합니다. 이게 생각보다 큰 차이예요.
특히 저는 이런 작업에서 도움을 많이 받았습니다.
- 오래된 레거시 코드의 호출 흐름 파악
- 에러 로그에 찍힌 함수와 관련 코드 찾기
- 리팩토링 전에 영향 범위 대략 확인
- 비슷한 기능이 이미 있는지 검색
- 신규 입사자나 외주 개발자에게 코드 설명 자료 만들기
예전에는 “이 기능 어디 있지?” 하면서 IDE 검색창에 키워드를 여러 개 넣고, Git blame 보고, 예전 Jira 티켓 뒤지고 그랬거든요. 이제는 질문을 조금 더 자연어에 가깝게 던질 수 있습니다. “회원 탈퇴할 때 쿠폰 데이터는 어떻게 처리돼?” 이런 식으로요. 그러면 관련 서비스, 이벤트 핸들러, 배치 코드 후보가 올라옵니다. 완벽하진 않아도 출발점으로는 꽤 훌륭합니다.
저는 이 정도만 돼도 충분히 가치 있다고 봅니다. AI가 정답을 다 주는 도구라기보다, 내가 헤매는 시간을 줄여주는 동료 같은 느낌이에요. 여행 갈 때도 좋은 지도 하나 있으면 골목길에서 덜 헤매잖아요. 맛집은 결국 내가 고르더라도요.
이 글이 도움이 될 만한 분들
이 글은 “AI 코딩 도구를 쓰긴 쓰는데, 자꾸 내 프로젝트랑 안 맞는 답변이 나와서 답답하다” 싶은 분들에게 특히 잘 맞을 것 같습니다. 레거시 코드가 많거나, 팀 프로젝트 규모가 커서 전체 구조를 한눈에 보기 어려운 분들에게도요. 특히 LLM 토큰 비용을 줄이면서 코드 분석 정확도를 올리고 싶은 개발자라면 RAG를 한 번쯤은 진지하게 만져볼 만합니다.
제가 해보니 핵심은 거창하지 않았습니다. 코드를 함수 단위로 잘 쪼개고, 벡터 검색만 믿지 말고 키워드 검색을 섞고, 검색 결과를 그대로 던지지 말고 한 번 정리해서 넣는 것. 이 세 가지만 챙겨도 체감이 꽤 큽니다.
물론 처음 세팅은 조금 번거롭습니다. 임베딩도 봐야 하고, 벡터 DB도 붙여야 하고, 프롬프트도 다듬어야 합니다. 그런데 한 번 자리를 잡으면 AI가 적어도 “우리 코드 좀 아는 척”은 하게 됩니다. 그 정도만 돼도 개발자는 훨씬 덜 외롭습니다. 밤에 장애 로그 보면서 혼자 중얼거릴 일이 조금 줄어들거든요.
그래서 제 총평은 이렇습니다. 작은 토이 프로젝트에는 굳이 과할 수 있지만, 회사 코드나 오래된 서비스, 여러 사람이 손댄 프로젝트라면 RAG 기반 코드베이스 검색은 충분히 투자할 가치가 있습니다. AI 바이브 코딩을 진짜 실무에 붙이고 싶다면, 이제는 프롬프트만 잘 쓰는 단계를 넘어 “AI가 볼 수 있는 내 코드 지도”를 만들어줘야 할 때가 온 것 같아요.
댓글
댓글 쓰기