AI를 써먹기 위한 최소 지식 5편: RAG와 검색 인덱스

RAG와 검색 인덱스의 기본 개념, embedding, chunk, retrieval, context injection을 개발 작업 관점에서 정리합니다.

목차

지난 글에서는 AI에게 좋은 입력 묶음을 주는 방법을 정리했습니다.

그런데 입력 묶음을 사람이 매번 직접 만들어야 한다면 한계가 있습니다.

문서가 많아지고, 코드베이스가 커지고, 운영 기록이 쌓이면 매번 필요한 내용을 사람이 골라서 붙여넣는 건 번거롭습니다. 심지어 뭘 붙여야 할지 모를 때도 많습니다.

이때 나오는 개념이 RAG입니다.

RAG는 Retrieval-Augmented Generation의 줄임말입니다. 이름은 길지만, 개발자 입장에서 보면 흐름은 비교적 단순합니다.

RAG는 "찾고 나서 답하기"다

기본 LLM 호출은 대략 이렇게 볼 수 있습니다.

사용자 질문
-> 모델
-> 답변

RAG가 붙으면 중간에 검색 단계가 들어갑니다.

사용자 질문
-> 관련 문서 검색
-> 검색 결과를 컨텍스트로 추가
-> 모델
-> 답변

핵심은 모델이 답하기 전에 참고할 자료를 찾아온다는 점입니다.

예를 들어 이런 질문이 있다고 해보겠습니다.

프로젝트에서 공개되지 않은 초안이 외부 색인에 노출되지 않게 한 기준이 뭐였지?

모델이 이 내용을 이미 알고 있지 않다면 추측할 수밖에 없습니다.

하지만 설계 문서, 코드, 이전 글을 검색해서 아래 정보를 가져올 수 있다면 답은 훨씬 정확해집니다.

- 공개 상태인 문서만 공개 목록에 포함
- 초안은 비공개 검토 화면에서만 확인
- RSS, sitemap, 공개 데이터에는 초안 식별자가 없어야 함
- 생성 후 공개 산출물에서 초안 식별자 노출 여부 확인

이게 RAG의 실용적인 가치입니다.

검색 인덱스는 왜 필요한가

문서가 몇 개 없으면 그냥 파일을 열어보면 됩니다.

하지만 글, 코드, 로그, 설계 문서가 많아지면 매번 전체를 훑을 수 없습니다.

검색 인덱스는 문서를 나중에 빠르게 찾기 위한 구조입니다.

단순 키워드 검색도 인덱스고, embedding 기반 semantic search도 인덱스입니다.

개발 작업에서는 둘 다 필요할 때가 많습니다.

에러 메시지나 함수명은 키워드 검색이 강하고, "이 설계와 비슷한 문서"를 찾을 때는 semantic search가 유리합니다.

embedding은 문서를 숫자로 바꾸는 과정이다

RAG 이야기를 하면 embedding이 같이 나옵니다.

embedding은 텍스트를 벡터로 바꾸는 과정입니다.

아주 단순하게 말하면:

"비공개 초안은 공개 색인에 노출되면 안 된다"
-> [0.12, -0.03, 0.44, ...]

이 숫자 배열은 문장의 의미를 어느 정도 담고 있습니다.

그래서 질문도 embedding으로 바꾸고, 문서도 embedding으로 바꿔서, 서로 가까운 것을 찾습니다.

질문 embedding
-> 가까운 문서 chunk 검색
-> 상위 결과를 컨텍스트에 넣기

여기서 chunk는 긴 문서를 검색하기 좋은 단위로 나눈 조각입니다.

문서 전체를 하나로 embedding하면 너무 넓고, 문장 하나씩 나누면 맥락이 부족할 수 있습니다. 그래서 적당한 크기로 나누는 게 중요합니다.

RAG에서 자주 생기는 문제

RAG를 붙인다고 자동으로 답이 정확해지는 건 아닙니다.

자주 생기는 문제는 이런 것들입니다.

1. 잘못된 문서를 검색한다.
2. 너무 많은 문서를 넣어서 핵심이 묻힌다.
3. 오래된 문서와 최신 문서가 충돌한다.
4. 검색 결과를 답변에서 제대로 인용하지 않는다.
5. 문서에 없는 내용을 모델이 채워 넣는다.

그래서 RAG도 검증 흐름이 필요합니다.

최소한 이런 기준은 있어야 합니다.

RAG는 "AI가 알아서 찾아서 답해줌"이 아니라, 검색과 답변 사이에 품질 관리가 필요한 구조입니다.

RAG를 붙이기 전에 정리할 것

RAG를 시작한다고 해서 바로 벡터 데이터베이스부터 만들 필요는 없습니다.

오히려 처음에는 문서 정리가 먼저입니다.

문서 자체가 정리되어 있지 않으면 embedding을 붙여도 품질이 좋아지지 않습니다.

검색 시스템은 지저분한 문서를 마법처럼 정리해주는 도구가 아닙니다. (마법이면 제가 먼저 씁니다..ㅎㅎ)

좋은 RAG는 좋은 문서 정리에서 시작합니다.

개인 프로젝트에서는 작게 시작해도 된다

처음부터 벡터 데이터베이스, 재랭킹, 평가셋까지 모두 붙일 필요는 없습니다.

개인 블로그나 작은 코드베이스라면 이렇게 시작해도 됩니다.

1. Markdown/문서 파일을 모은다.
2. 제목, slug, tags, 본문 요약을 추출한다.
3. 키워드 검색으로 먼저 찾는다.
4. 필요하면 embedding 검색을 추가한다.
5. 검색 결과를 AI에게 근거로 넘긴다.

가장 먼저 필요한 건 거창한 시스템보다 찾을 수 있는 형태로 문서를 정리하는 것입니다.

문서 제목이 명확하고, 태그가 잘 붙어 있고, 내용이 너무 뒤섞이지 않으면 검색 품질이 좋아집니다.

처음 구현한다면 이렇게 시작한다

개인 프로젝트에서 RAG 비슷한 구조를 붙인다면 저는 이 순서를 추천합니다.

1. 문서 목록을 만든다.
2. title, date, tags, status, summary를 추출한다.
3. 먼저 키워드 검색으로 찾는다.
4. 검색 결과 상위 3~5개만 AI에게 넘긴다.
5. 답변에 사용한 문서 제목을 같이 남긴다.
6. 틀린 검색 결과를 기록해서 문서 제목/태그를 고친다.

이 단계만으로도 꽤 쓸만합니다.

처음부터 embedding, vector DB, reranker, evaluation pipeline을 다 붙이면 멋있어 보이지만, 작은 프로젝트에서는 운영 부담이 먼저 커질 수 있습니다.

RAG는 기능이 아니라 운영 흐름입니다. 검색 결과가 틀렸을 때 어디를 고칠지 보여야 합니다.

RAG를 개발 작업에 붙이면

개발 작업에서 RAG는 이런 식으로 쓸 수 있습니다.

질문:
"댓글 삭제 기능은 어떤 정책으로 동작해야 하지?"

검색 대상:
- 설계 문서
- 관련 migration
- 서버/API 코드
- 기존 블로그 글

검색 결과:
- 댓글은 비밀번호 기반 수정/삭제
- 삭제 시 내용은 '삭제된 댓글입니다'로 표시
- 비밀댓글은 관리자만 본문 확인
- 관리자 로그인 상태에서는 숨김/삭제 가능

답변:
- 관련 정책 요약
- 수정해야 할 파일
- 검증 체크리스트

이렇게 되면 AI는 기억에 의존하지 않고 프로젝트 자료를 근거로 답할 수 있습니다.

물론 최종 판단은 여전히 사람이 해야 합니다.

RAG 답변을 볼 때 확인할 것

RAG가 붙은 답변은 일반 답변보다 더 믿고 싶어집니다.

하지만 답변에 문서가 붙었다고 해서 자동으로 정답은 아닙니다.

저는 아래를 봅니다.

특히 개발 작업에서는 마지막이 중요합니다.

좋은 RAG 답변은 "이렇습니다"에서 끝나지 않고, 다음에 확인할 파일, 수정 후보, 검증 기준으로 이어져야 합니다.

정리하면

RAG는 AI를 똑똑하게 만드는 마법 버튼이 아닙니다.

필요한 자료를 찾아서 컨텍스트에 넣어주는 구조입니다.

1. RAG는 검색 후 답변하는 흐름이다.
2. 검색 인덱스는 문서를 빠르게 찾기 위한 구조다.
3. embedding은 의미 기반 검색을 가능하게 한다.
4. chunk 크기와 문서 최신성이 답변 품질에 영향을 준다.
5. RAG에도 검색 품질과 출처 검증이 필요하다.

다음 글에서는 AI가 문서를 참고하는 단계를 넘어, 실제로 파일을 읽고 명령을 실행하고 배포까지 도와주는 Tool Calling과 Agent 개념을 정리해보겠습니다.