Sourcegraph의 무료 오픈 소스 대안을 직접 만든 이유

화요일 새벽 2시, 나는 한 번도 본 적 없는 함수를 뚫어지게 쳐다보고 있었다.

코드베이스는 6개의 마이크로서비스 (microservices)에 걸쳐 47,000개의 파일로 구성되어 있었고, 이 코드들은 이미 몇 년 전에 회사를 떠난 사람들이 작성한 것이었다. 나는 모바일 앱에서 백엔드로, 세 개의 서로 다른 서비스를 거쳐 다시 돌아오는 인증 (authentication) 흐름이 어떻게 되는지 이해해야 했다. 한 탭에는 grep을, 다른 탭에는 코드베이스를, 세 번째 탭에는 ChatGPT를 띄워놓고 파일을 하나씩 복사해서 붙여넣고 있었다.

이것은 워크플로우 (workflow)가 아니다. 그것은 그저 버티기 위한 방편일 뿐이다.

내가 아는 모든 개발자는 이와 유사한 방식을 사용한다. 우리는 하나의 함수를 이해하기 위해 다섯 개의 파일을 읽는다. 우리는 수동으로 임포트 (imports)를 추적한다. 우리는 Slack 알림이 울리는 순간 증발해 버리는 정신적 모델 (mental models)을 구축한다. 우리는 새로운 코드베이스를 이해하는 데 몇 주, 때로는 몇 달이 걸리는 것을 마치 소프트웨어가 만들어지는 당연한 과정인 것처럼 받아들인다.

나는 반드시 이럴 필요는 없다고 생각한다.

아무도 해결하지 못한 문제

Sourcegraph가 존재한다. 그것은 엔터프라이즈 규모의 코드 검색 (code search)이라는 본연의 기능에 매우 탁월하다. 하지만 그것은 전용 인프라 예산을 갖춘 조직을 위해 만들어졌다. 직접 호스팅 (self-host)해야 하고, 설정해야 하며, 유지 관리해야 한다. 개인 개발자, 소규모 팀, 또는 오픈 소스 (open-source) 프로젝트에게 이러한 오버헤드 (overhead)는 합리적이지 않다.

다른 도구들도 있다. 하지만 그들은 모두 동일한 간극을 가지고 있다. 그들은 '텍스트'를 검색할 뿐, '의미'를 검색하지 못한다.

Lexithm은 모든 파일, 모든 함수, 모든 임포트(import)를 포함한 저장소 전체를 읽고, 이에 대해 자연어(natural language)로 질문할 수 있게 해줍니다. Lexithm은 심볼(symbols)을 추출하고, 의존성 그래프(dependency graphs)를 구축하며, API 경로를 탐지하고, 의미론적 검색(semantic search)을 위한 임베딩(embeddings)을 생성합니다.

진행 과정은 다음과 같습니다:

GitHub로 로그인 — CLI도, 설정(config)도, 설치(setup)도 필요 없습니다.
저장소 선택 — 공개(public) 또는 비공개(private) 저장소 모두 동일한 방식으로 작동합니다.
인덱싱(indexing) 대기 — Python, JavaScript, TypeScript, Go, Java, Rust에 대해 AST(Abstract Syntax Tree) 수준의 파싱(parsing)을 수행합니다. 대부분의 저장소는 2~5분 내에 완료됩니다.
질문하기 — "이 프로젝트는 무엇을 하나요", "인증(authentication)은 어떻게 작동하나요", "결제 흐름에서 버그를 찾아주세요"와 같이 질문할 수 있습니다. 모든 답변은 참조하는 파일 경로와 줄 번호를 인용합니다.

핵심적인 설계 결정은 **설치 없음(no installation)**이었습니다. 모든 것이 브라우저에서 실행됩니다. 플러그인을 설치하거나, 서버를 설정하거나, 무엇인가를 구성할 필요가 없습니다. GitHub에 연결하여 바로 작동하는 웹 앱입니다.

아키텍처 (The Architecture)

백엔드(backend)는 FastAPI를 사용하는 Python입니다. 인덱싱 파이프라인(indexing pipeline)은 16단계로 구성됩니다:

파일 발견 (File discovery) — 모든 파일을 유형별로 분류
AST 파싱 (AST parsing) — 각 소스 파일의 구조화된 표현 구축
그래프 구축 (Graph construction) — 심볼들을 의존성 및 호출 그래프(call graphs)로 연결
임베딩 생성 (Embedding generation) — 모든 코드 청크(chunk)를 벡터 임베딩(vector embeddings)으로 변환
저장 (Storage) — 즉각적인 검색을 위해 인덱싱된 데이터를 영구 저장

질문을 하면 시스템은 사용자의 의도(intent)를 분류하고, 인덱스에서 가장 관련 있는 코드 청크를 검색하여, 맞춤형 프롬프트(prompt)와 함께 LLM에 전달합니다. 오직 관련 컨텍스트(context)만 전송되며, 코드베이스 전체가 전송되는 일은 절대 없습니다.

프론트엔드(frontend)는 터미널에서 영감을 받은 채팅 인터페이스를 갖춘 Next.js입니다. 응답을 토큰(token) 단위로 스트리밍하여 답변이 실시간으로 생성되는 것을 볼 수 있습니다.

무료인 이유 (Why It's Free)

Lexithm은 무료 티어(free tiers)에서 실행됩니다. NVIDIA NIM이 비용 부담 없이 LLM 추론(inference)을 제공합니다. OpenRouter가 폴백(fallback) 역할을 수행합니다. 임베딩 모델은 NVIDIA의 API에서 실행됩니다. Supabase가 데이터베이스와 인증을 처리합니다. 모든 것이 무료 사용 한도 내에서 유지됩니다.

제가 이것을 만든 이유는 이런 도구가 존재하기를 원했기 때문입니다. 모든 것이 스타트업일 필요는 없습니다. 모든 것이 엔터프라이즈 라이선스(Enterprise license)를 필요로 할 필요도 없습니다. 어떤 것들은 그저 유용하기만 하면 됩니다.

사람들이 실제로 묻는 FAQ

Sourcegraph와 무엇이 다른가요?
Sourcegraph는 수천 개의 리포지토리(Repository)에 걸친 정규 표현식(Regex) 검색과 같이 대규모 엔터프라이즈 코드 검색을 위해 구축되었습니다. Lexithm은 대화형 코드 이해(Conversational code understanding)를 위해 구축되었습니다. 영어로 질문하면 인용(Citation)과 함께 답변을 얻을 수 있습니다. 또한 무료이며, 인프라가 필요하지 않고, 설정 과정도 전혀 필요 없습니다.

제 코드는 안전한가요?
사용자의 리포지토리는 백엔드에서 인덱싱(Indexing)될 뿐, 어떤 LLM 제공업체에도 저장되지 않습니다. 각 질문에 대해 관련 컨텍스트(Context)만 전송됩니다. 인덱스는 언제든지 삭제할 수 있습니다.

인덱싱은 얼마나 걸리나요?
대부분의 리포지토리는 2~5분 내에 완료됩니다. 100,000개 이상의 파일을 가진 대규모 프로젝트는 최대 20분까지 소요될 수 있습니다.

무엇인가를 설치해야 하나요?
아니요. 모든 것은 브라우저를 통해 실행됩니다.

사용해 보기

사이트는 lexithm.vercel.app에서 라이브로 운영 중입니다. GitHub로 로그인하고, 리포지토리를 선택한 뒤, 질문을 던져보세요.

코드는 GitHub에 있습니다 — 음, 제가 푸시(Push)하는 대로 바로 올라갈 것입니다. (이 포스트를 먼저 쓰고 싶었거든요.)

낯선 리포지토리에서 코드를 추적하느라 몇 시간을 보낸 적이 있다면, 제가 왜 이것을 만들었는지 정확히 알 것입니다. 이것이 여러분의 소중한 시간을 아껴줄 수 있기를 바랍니다.

Next.js, FastAPI, NVIDIA NIM, Supabase, 그리고 수많은 밤샘 작업으로 만들어졌습니다.