JetBrains가 코드 의미 검색 RAG 파이프라인을 구축한 방법

Building a RAG Pipeline for Semantic Code Search

JetBrains가 코드 의미 검색 RAG 파이프라인을 구축한 방법

JetBrains가 LLM 에이전트를 위한 시맨틱 코드 검색 플랫폼 Air Context를 개발하며 얻은 교훈을 공유한다. 키워드 검색의 한계를 넘어 코드의 의미를 인덱싱하는 RAG 파이프라인 구축 과정에서 파싱, 청킹, 벡터화 단계의 기술적 도전과 해결책을 다룬다. 고정 크기 청킹의 실패, 구조 인식 청킹, 임베딩 비용 최적화 전략 등 프로토타입에서 프로덕션까지의 여정을 담았다.

에이전트가 세션 토큰이 갱신되는 위치를 찾고 있을 때, 코드에 친절하게 'refresh'라는 단어가 포함되어 있다고 기대할 수는 없다.
  1. keeda

    이런 게 코딩 에이전트의 품질을 높이는 데 핵심이 될 것 같아요. 많은 사람들이 관찰한 아주 흔한 문제(어쩌면 가장 큰 문제)는 에이전트가 중복되고 불필요한 코드를 많이 생성한다는 점입니다. 같은 목적의 사소한 변형을 위한 여러 추상화, 메서드, 클래스, 데이터 구조 등이요... 때로는 같은 파일 안에서도요!

    제 이론은 이것이 주어진 작업을 수행할 때 이 모델들이 가지는 일종의 "터널 시야" 때문이라는 겁니다. 회사에 새로 온 엔지니어들도 비슷한 문제가 다른 곳에서 이미 해결되었다는 걸 알게 될 때까지 똑같이 하니까요.

    예전 직장에서 제 팀은 내부 멀티 레포 코드서치 도구를 담당했는데, 이는 단연 가장 인기 있는 내부 도구였고 나중에 다른 팀이 유사한 시맨틱 검색 기능을 추가했습니다. 매우 흥미로웠지만 실제로 얼마나 잘 작동하는지 보기 전에 퇴사했어요.

    예를 들어, 상당한 작업이 필요한 주요 기능이 필요할 때 키워드 검색을 하고 탐색하거나, 코드가 저장소에 없는 추상화를 만나서 더 알고 싶을 때 그렇게 합니다. 하지만 흐름을 타고 클래스나 유틸리티 메서드 같은 작은 추상화를 만들 때는 굳이 검색할 생각을 하지 않습니다. 더 나쁜 건, 설령 검색한다 해도 비슷한 게 약간 다른 이름이나 용어, 또는 키워드 검색이 놓칠 오타로 존재할 수 있어 효과적으로 검색할 수 없습니다. 예상대로, sc […]

  2. duhhhhh1212

    https://www.pangram.com/history/c901e80e-9cb7-46e4-bf10-7348...

    전반부는 인간이 쓴 거니까 시간 낭비하지 말라고는 하고 싶지 않네요. 저자들에게 질문: 그냥 쓰기 지겨워서 "젠장, 나머지는 LLM이 끝내게 하자"라고 한 건가요? 아니면 한 명이 LLM으로 후반부를 쓰고 다른 한 명은 자기 말로 썼나요?

  3. simianwords

    또 시작이네, 업계는 RAG를 대부분 포기했어. 사실 grep이 RAG만큼 잘 작동하지 않는 경우를 거의 못 봤어.

이 날의 다른 글

2026-10-04