안녕하세요! iOS 엔지니어를 하고 있는 다카하시입니다!

생성형 AI를 개발 업무에 활용하는 사례가 늘어남에 따라, AI 에이전트에게 사내 정보나 기존 코드베이스를 어떻게 참조하게 할 것인가는 중요한 테마가 되고 있습니다.

그래서 활용되는 메커니즘 중 하나가 RAG입니다.

본 기사에서는 RAG의 기본적인 메커니즘부터, AI 에이전트와 조합했을 경우의 사고방식, 그리고 코드베이스 이해·코드 생성·장애 대응·코드 리뷰와 같은 개발 현장에서의 활용 사례까지 해설합니다.

RAG (Retrieval-Augmented Generation)란 「검색 증강 생성」을 의미하며, 질문과 관련된 문서를 미리 검색하고 그 내용을 근거로 LLM이 답변하게 하는 메커니즘입니다.

쉽게 말하자면, LLM이 답변을 생성하기 전에 관련 자료를 취득하여 참조하게 하는 접근 방식입니다.

2023년부터 2024년에 걸쳐, 사내 문서나 PDF를 검색하여 답변할 수 있는 RAG 시스템이 급속도로 확산되었습니다.

한편, 실운용이 진행됨에 따라 단순한 벡터 검색(Vector Search)만으로는 다음과 같은 과제가 드러나기 시작했습니다.

• 질문에 대해 적절한 문서를 취득하지 못함
• 오래된 문서나 권한상 참조해서는 안 되는 문서를 취득해 버림
• 여러 문서·시스템을 가로지르는 복잡한 질문에 대응하기 어려움
• 검색 결과가 올바르더라도, LLM이 근거를 잘못 해석하는 경우가 있음

그렇기 때문에 최근에는 「RAG를 사용할 것인가·사용하지 않을 것인가」가 아니라, 보다 정확하게 필요한 정보를 취득하고 검증하여 답변으로 연결하기 위한 설계가 중요해지고 있습니다.

2026년이 되어, 차세대 대표적인 접근 방식으로,

• Hybrid Retrieval: 키워드 검색과 벡터 검색을 조합함
• Reranking: 취득 후보를 재평가하여, 관련도가 더 높은 문서를 상위에 배치함
• GraphRAG: 엔티티(Entity)나 관계성을 지식 그래프(Knowledge Graph)로 다룸
• Agentic RAG: AI 에이전트가 필요에 따라 검색을 반복하며, 추가 조사나 검증을 수행함
• Context Engineering: 모델에 전달할 정보의 양·순서·형식을 설계함

등이 주목받고 있습니다.

LLM을 업무에서 사용할 때 자주 발생하는 과제는 다음 3가지입니다.

• 사내 정보나 독자적인 전문 지식을 알지 못함
• 학습 시점 이후의 최신 정보를 반영하지 못함
• 그럴듯한 오정보를 생성할 때가 있음 (할루시네이션 (Hallucination))

예를 들어, 직원이 "출장 정산 상한액은?"이라고 AI에게 물었다고 가정해 봅시다. LLM 단독으로는 일반적인 정보로부터 그럴듯한 답변을 만들지도 모릅니다. 하지만 실제 상한액은 회사마다의 규정이나 개정일에 따라 다릅니다.

RAG라면, AI는 먼저 최신 경비 규정을 검색하고 해당 부분을 참조한 뒤에 답변할 수 있습니다. 이를 통해 답변의 정확성·설명 가능성을 높일 수 있습니다.

RAG는 대체로 다음과 같이 동작합니다.

• 문서를 준비한다
  매뉴얼, FAQ, 의사록, 규정, 제품 자료, 웹 페이지 등을 수집합니다.

• 문서를 분할한다
  긴 문서를 의미의 덩어리별로 작은 단위로 분할합니다. 이를 「청크 (Chunk)」라고 부릅니다.

예를 들어, 100페이지의 설계서를 그대로 1건의 데이터로 다루는 것이 아니라, 장·절·소제목·단락 등의 단위로 분할합니다.

코드의 경우도 파일 전체뿐만 아니라 클래스·함수·메서드·모듈 단위 등으로 다루기도 합니다.

• 검색할 수 있는 형태로 저장한다
  각 청크에 대해 의미를 수치로 표현한 임베딩 벡터 (Embedding Vector)를 생성하여 벡터 데이터베이스 (Vector Database) 등에 저장합니다.

벡터 검색을 사용함으로써 질문 문구와 완전히 동일한 단어가 적혀 있지 않더라도, 의미적으로 가까운 문서를 찾기 쉬워집니다.

• 질문에 가까운 문서를 검색한다
  사용자의 질문도 벡터화하여 의미적으로 가까운 청크를 찾습니다.

• 검색 결과를 LLM에 전달하여 답변을 생성한다
  "다음 자료만을 근거로 답해 주세요"와 같은 지시와 함께 검색된 문서를 LLM에게 전달합니다.

이때 다음과 같은 규칙을 지시하는 것이 중요합니다.

다음 자료만을 근거로 답변해 주세요.
근거를 찾을 수 없는 경우에는 추측하지 말고 "불명"이라고 답변해 주세요.
답변에는 참조한 자료를 표시해 주세요.

이를 통해 LLM이 근거 없는 내용을 보완해 버리는 리스크를 낮출 수 있습니다.

통상적인 RAG에서는 사용자의 질문에 대해 관련 문서를 검색하고, 그 검색 결과에 기반하여 LLM이 답변을 생성합니다.

질문
↓
검색
...

한편, 실제 개발 업무에서는 「한 번의 검색만으로는 대답할 수 없는 질문」도 많이 있습니다.

• 결제 API의 타임아웃 증가에 대하여,
• 최근의 변경 사항·관련된 모니터링 항목·과거의 유사 장애를 확인하고,
• 우선순위 순으로 조사 절차를 제안해줘

이 질문에 답하기 위해서는 소스 코드, 최근의 PR (Pull Request), 모니터링 설정, 대시보드, 장애 보고서, 로그 사양 등 여러 정보원을 횡단하여 확인해야 합니다.

AI 에이전트와 RAG (Retrieval-Augmented Generation)를 결합하면, AI는 단순히 검색 결과를 요약하는 것에 그치지 않고 목적에 따라 다음과 같은 행동을 취할 수 있게 됩니다.

• 질문을 여러 조사 항목으로 분해
• 코드, 문서, Issue, PR, 모니터링 설정 등을 검색
• 정보가 부족할 경우, 추가 검색 쿼리를 구성
• 필요에 따라 로그 검색이나 메트릭 (Metrics) 취득 등의 도구를 호출
• 취득한 정보의 모순이나 부족함을 확인
• 근거와 함께 조사 결과 및 다음 액션을 제시

새로 합류한 멤버가 다음과 같은 질문을 합니다.

사용자 등록부터 메일 전송까지의 처리 흐름을 알려줘

이 경우, AI는 다음과 같은 정보를 검색합니다.

• 라우팅 (Routing)
• 컨트롤러 (Controller)
• 유스케이스 (Use Case) 및 서비스 (Service)
• 데이터베이스 액세스 (Database Access)
• 작업 큐 (Job Queue)
• 메일 전송 처리
• 관련 테스트 코드

이를 바탕으로 처리 흐름이나 주요 책임을 설명할 수 있습니다.

GitHub의 공식 문서에서도 리포지토리의 목적·구조·주요 컴포넌트·실행 방법이나, 특정 파일·심볼 (Symbol)의 역할을 묻는 용도가 예시되어 있습니다. (docs.github.com)

다만, 코드베이스 이해에 있어서는 문서와 마찬가지로 코드를 단순히 분할하여 검색하는 것만으로는 불충분할 수 있습니다.

특히 다음과 같은 질문에는 구조적인 정보가 필요합니다.

이 함수는 어디에서 호출되고 있는가?
이 변경 사항의 영향 범위는 어디인가?
이 API의 인가 (Authorization) 체크는 어디에서 이루어지는가?

이러한 질문에 높은 정밀도로 답하기 위해서는 벡터 검색 (Vector Search)뿐만 아니라 파일 경로, 심볼 이름, 참조 관계, 호출 그래프 (Call Graph), 타입 정보, Git 이력 등을 함께 다루는 것이 중요합니다.

예를 들어, 다음과 같은 요청입니다.

기존 주문 API와 동일한 구성·예외 처리·테스트 방침으로
반품 API를 추가해줘

이 경우, AI는 기존 주문 API와 관련된 다음 정보를 취득합니다.

• 엔드포인트 (Endpoint) 정의
• 컨트롤러 및 유스케이스 구현
• 예외 클래스 (Exception Class)
• 에러 응답 형식
• 테스트 코드
• OpenAPI 정의
• 코딩 규약 (Coding Convention)
• 로그 출력 방침

그 정보를 바탕으로 프로젝트의 스타일(流儀)에 가까운 코드를 생성하게 합니다.

GitHub Copilot에서는 리포지토리 고유의 구조, 코딩 표준, 빌드·테스트 방법 등을 영구적인 컨텍스트 (Context)로 제공하는 메커니즘도 지원합니다. (docs.github.com)

하지만 기존 코드를 참조하여 생성된 코드라 할지라도 정확성이 보장되지는 않습니다.

인가 누락, 트랜잭션 경계 (Transaction Boundary), 예외 처리, 병행 실행 (Concurrency), 퍼포먼스 (Performance), 보안 요구 사항 등은 반드시 사람이 리뷰해야 합니다.

예를 들어, 다음과 같은 케이스입니다.

결제 API에서 타임아웃이 증가하고 있어.
관련된 처리, 과거의 유사 장애, 확인해야 할 로그 항목을 정리해줘

검색 대상에는 소스 코드뿐만 아니라 다음과 같은 정보도 포함될 수 있습니다.

• 장애 보고서
• 운영 절차서
• 모니터링 설정
• 로그 사양
• 대시보드 정의
• Issue
• 과거의 Pull Request
• 외부 서비스 설정 정보

AI 에이전트라면 정보가 부족할 경우 추가 검색을 수행하거나, 허용된 범위 내에서 로그나 메트릭을 취득할 수도 있습니다.

다만, RAG나 AI 에이전트의 답변만으로 장애 원인을 단정해서는 안 됩니다.

특히 장애 대응 시에는 로그, 메트릭, 트레이스 (Trace), 실제 설정값, 배포 이력 등을 통해 반드시 검증하는 운영이 필요합니다.

AI는 조사 보조자로서 유용하지만, 사실 확인을 대신할 수는 없습니다.

RAG에 설계 원칙이나 팀 규약, 유사 구현을 참조하게 함으로써, Pull Request에 대해 다음과 같은 관점을 제시할 수 있습니다.

이 변경 사항은 기존의 인가 체크 방침과 일치하는가?
유사한 구현과 비교했을 때 테스트가 부족하지 않은가?
예외 처리나 로그 출력은 팀의 규칙을 따르고 있는가?

하지만 "AI가 문제없다고 말했다"는 사실이 품질 보증이 되지는 않습니다. 최종적인 설계 판단, 보안 판단, 머지 (Merge) 판단은 인간이 담당해야 합니다.

사내에 독자적인 인증 기반, 공통 라이브러리, API, 배포 절차가 있는 경우, 개발자는 다음과 같은 정보를 조사하는 데 시간을 허비하곤 합니다.

• 어떤 SDK를 사용해야 하는가
• 인증은 어떻게 구현하는가
• 필요한 환경 변수는 무엇인가
• 로컬 개발 환경을 어떻게 구축하는가
• 어떤 환경에 어떻게 배포하는가
• 자주 발생하는 에러를 어떻게 해결하는가

RAG의 검색 대상으로 다음을 등록해 두면, AI를 사내 개발 포털처럼 사용할 수 있습니다.

• API 사양서
• SDK 레퍼런스 (Reference)
• 샘플 구현
• 인증·인가 (Authentication/Authorization) 설계서
• 배포 절차
• FAQ
• 자주 발생하는 장애와 대처법

단, 사내 정보를 다룰 때는 권한 관리가 필수적입니다.

'검색할 수 있는 정보'와 '그 사용자에게 보여줘도 되는 정보'는 별개입니다. RAG를 도입할 때는 기존 시스템의 액세스 권한을 고려하여, 검색 결과에도 적절한 액세스 제어 (Access Control)를 적용해야 합니다.

프로그래밍에서 RAG의 본질적인 가치는 코드를 작성하는 시간 그 자체보다, 올바른 전제나 기존의 설계 의도를 찾아 이해하는 시간을 줄일 수 있다는 점에 있습니다.

특히 기존 시스템의 개발에서는 구현 그 자체보다 다음과 같은 작업에 시간이 많이 소요됩니다.

• 어떤 파일을 변경해야 하는지 찾기
• 유사한 구현 찾기
• 설계 의도 확인하기
• API나 데이터베이스의 사양 확인하기
• 팀의 규칙 조사하기
• 과거의 장애·논의·판단 사항 찾기
• 변경에 따른 영향 범위 확인하기

RAG는 이러한 '탐색'과 '문맥 수집'을 지원합니다.

거대한 리포지토리(Repository)나 방대한 문서를 매번 LLM에 전부 전달하는 것이 아니라, 질문과 관련된 코드나 문서만을 추출할 수 있기 때문에 AI에게 제공할 컨텍스트 (Context)를 좁히기 쉽다는 점도 이점입니다.

GitHub Copilot의 시맨틱 검색 (Semantic Search) 또한, 정확한 이름이나 검색 패턴을 모를 때 의미에 기반하여 관련 코드를 찾는 용도로 설명되어 있습니다. (docs.github.com)

적절하게 설계한다면, RAG는 LLM에 전달하는 토큰 (Token) 양과 추론 비용을 억제하는 수단도 됩니다.

단, RAG의 제1 목적은 '올바르고 최신인 근거를 제공하는 것'이며, 도입한다고 해서 반드시 토큰 수나 비용이 낮아지는 것은 아닙니다.

방대한 매뉴얼이나 사내 문서를 그대로 모두 프롬프트 (Prompt)에 넣으면, 그 전체량이 입력 토큰이 됩니다.

RAG에서는 문서를 미리 분할하여, 질문과 관련된 몇 개의 청크 (Chunk)만을 LLM에 전달합니다.

예를 들어, 수백 페이지의 자료 중에서 필요한 몇 단락만을 참조하게 하는 것이 가능합니다.

이를 통해 LLM에 초점을 맞춘 컨텍스트를 전달하기 쉬워집니다.

Microsoft의 RAG 해설에서도 관련 청크만을 반환하는 설계는 모델에 초점을 맞춘 문맥을 전달하여 토큰 사용량을 줄이는 방법으로 설명되어 있습니다. (learn.microsoft.com)

반면, RAG에는 다음과 같은 비용이나 운영 부하도 존재합니다.

• 문서 수집 및 정제
• 청크 분할
• 임베딩 벡터 (Embedding Vector) 생성
• 인덱스 (Index) 업데이트
• 검색 처리
• 재순위화 (Re-ranking)
• 검색 정확도 및 답변 정확도 평가
• 액세스 권한 관리

따라서 단순히 입력 토큰 수만 볼 것이 아니라, 답변 정확도, 응답 속도, 검색 비용, 문서 업데이트 빈도, 운영 부하를 모두 포함하여 설계하는 것이 중요합니다.

결론부터 말하자면, RAG를 도입한다고 해서 할루시네이션 (Hallucination)이 완전히 사라지는 것은 아닙니다.

예를 들어, 다음과 같은 문제는 남습니다.

• 검색 결과 자체가 틀린 경우
• 필요한 정보를 검색에서 놓치는 경우
• 오래된 문서를 참조하는 경우
• LLM이 근거를 잘못 해석하는 경우
• 근거 없는 내용을 그럴듯하게 보완하는 경우
• 인용원은 맞지만, 답변 내용이 이를 충분히 뒷받침하지 못하는 경우

따라서 RAG를 도입할 때는 다음과 같은 대책이 중요합니다.

• 답변과 함께 참조원을 표시할 것
• 참조원이 실제로 답변 내용을 뒷받침하는지 확인할 것
• 근거 없는 내용을 답변하지 않도록 프롬프트로 제약할 것
• 충분한 근거가 없는 경우에는 '알 수 없음'이라고 답변하게 할 것
• 문서의 업데이트 날짜나 유효 기간을 관리할 것
• 검색 정확도와 답변 정확도를 나누어 평가할 것
• 고위험 답변에는 사람에 의한 확인 과정을 포함할 것
• 문서의 권한 관리와 감사 로그 (Audit Log)를 정비할 것

RAG는 'AI를 반드시 올바르게 만드는 기술'이 아닙니다.

AI가 답변하기 위한 근거를 제공하고, 그 근거를 인간이 확인할 수 있도록 만드는 메커니즘입니다.

RAG는 LLM이 외부 지식을 검색하고 참조하게 함으로써, 더욱 실무적이고 신뢰성 높은 답변을 실현하는 메커니즘입니다.

특히 빈번하게 업데이트되는 정보나 조직·업계 고유의 정보를 다루는 상황에서 큰 가치를 발휘합니다. 개발 현장에서는 코드베이스의 이해, 기존 설계에 따른 구현, 장애 조사, 코드 리뷰, 사내 SDK 및 API 이용 지원 등에 활용할 수 있습니다.

또한, AI 에이전트 (AI Agent)와 결합함으로써 RAG는 단순히 "자료를 검색하여 답변하는" 메커니즘에 머물지 않게 됩니다. AI가 질문을 분해하고, 필요한 정보를 추가로 조사하며, 여러 정보원을 횡단하고, 근거를 정리하여 다음 액션 (Action)을 제안하기 위한 지식 기반 (Knowledge Base)이 됩니다.

하지만 성공의 열쇠는 LLM (Large Language Model)의 성능만이 아닙니다. 올바른 문서를 정비하고, 업데이트 날짜·권한·신뢰성을 관리하며, 적절하게 검색하고, 근거를 확인할 수 있는 운영 체계를 구축하는 것이 중요합니다.

RAG는 단순한 AI 기능이 아니라, 조직의 지식을 "찾을 수 있고, 사용할 수 있으며, 설명할 수 있는" 형태로 변환하기 위한 기반이라고 할 수 있습니다.