ENKO

분석

잘 알려진 프로젝트 하나를 실제 소스 경로로 읽는 분석입니다.

글
12
저장소
13
최신
2026년 7월 12일
분석개발자 도구

CodexBar는 사실 메뉴 막대 앱이 아니다. 프로바이더 사용량 측정 런타임이다.

CodexBar는 AI 코딩 한도를 보여주는 작은 macOS 유틸리티처럼 보인다. v0.41.0의 소스를 읽어보니, 실제 아키텍처는 컴파일 시점의 프로바이더 ID, 디스크립터, 전략 파이프라인, 별도의 앱 훅으로 제각각인 벤더 할당량 신호를 하나의 사용량 화면으로 바꾸는 선별된 프로바이더 카탈로그였다.

분석개발자 도구

LazyCodex는 에이전트 집 전체가 아니라 그 입구다

LazyCodex는 복잡한 코드베이스를 위한 에이전트 하네스로 소개된다. v4.15.1의 소스를 읽어보니 범위는 더 좁았고, 오히려 그래서 더 유용했다. 루트 패키지는 작은 Codex 설치 별칭이고, 실제 제품은 번들로 제공되는 omo 플러그인이며, 더 깊은 하네스의 소유권은 OmO로 이어진다.

분석개발자 도구

Aider의 레포 맵이 코드베이스를 실제로 읽는 방식 — 임베딩이 아닌 PageRank

Aider는 전체 코드베이스를 읽는 AI로 소개된다. v0.86.3.dev에서 읽은 레포 맵은 AI 문제가 아니라 순위 산정 문제다. tree-sitter가 심볼을 추출하고, 참조 그래프의 PageRank가 순위를 매기며, 이진 탐색이 상위 심볼을 토큰 예산에 맞춰 담는다. 임베딩도, 벡터 저장소도, 네트워크 호출도 없다.

분석개발자 도구

Continue가 코드베이스를 인덱싱하는 방식 — 그리고 코드가 내 컴퓨터를 떠나는가

Continue는 Aider와 대조되는 임베딩 우선 방식이다. v2.1.0에서 읽고 모두가 실제로 묻는 질문, 즉 내 독점 코드가 임베딩 API로 전송되는가에 답하면 기본값으로는 아니다. 번들된 all-MiniLM-L6-v2로 로컬에서 임베딩하고, 벡터를 로컬 LanceDB에 저장하며, 원격 임베딩 제공자를 설정할 때만 코드를 외부로 보낸다.

분석데이터 인프라

LanceDB가 벡터 데이터베이스를 파일에 담는 방식: Lance 컬럼형 포맷 위의 IVF-PQ, 서버는 없다

LanceDB는 서버가 아니라 라이브러리이자 파일 포맷이다. connect()는 로컬 경로나 객체 스토리지 URI를 프로세스 안에서 열고, 리터럴 접두사 `db`로 시작하는 URI만 Cloud HTTP 클라이언트로 보낸다. 저장소는 추가 전용 매니페스트 버저닝을 사용하는 Lance 컬럼형 포맷이며, 인덱스 계열은 HNSW 그래프가 아니라 PQ 압축을 결합한 IVF 우선 구조다. lance v8.0.0 / lancedb v0.30.0에서 읽었다.

분석AI 인프라

LiteLLM의 라우터는 어떻게 배포를 고르는가 — 기본값은 가중 무작위, 직접 설정해야만 스마트해진다

LiteLLM은 여러 모델 배포를 아우르는 스마트 로드 밸런서로 소개된다. v1.92.0-dev.1 기준으로 읽어보면 기본값은 가중 동전 던지기다. simple-shuffle은 무작위로 정상 배포를 고르며, rpm/tpm을 설정했다면 그에 따라 가중치를 적용한다. 지능적인 기능인 최소 부하, 지연 시간, 사용량 기반 라우팅은 선택 사항이며, LiteLLM이 모든 키를 계측하기 때문에 가능하다. 실패 시에는 재시도-쿨다운-폴백 사다리를 실행한다.

분석AI 인프라

Ollama가 모델을 로드하는 방식 — 그리고 실제로 GPU 레이어 수를 결정하지 않는 이유

대부분은 Ollama가 모델의 메모리를 추산하고 GPU에 올릴 레이어 수를 계산한다고 생각한다. v0.31.1을 읽어보니 실제로는 그렇지 않았다. Ollama는 상위 프로젝트인 llama.cpp의 llama-server를 실행하고, 기본적으로 GPU 분할 자동 감지를 맡긴 다음, 오프로딩된 레이어 수를 로그에서 다시 읽는 스케줄러다. Ollama 자체의 메모리 계산은 무엇이 들어가고 무엇을 퇴출할지 결정하는 데만 쓰이는, 의도적으로 거친 근삿값이다.

분석데이터 인프라

pgvector는 HNSW를 어떻게 Postgres 안에 넣는가 — 인덱스 접근 방식으로서의 벡터 검색

pgvector는 벡터 검색에 대한 '그냥 Postgres를 쓰자'는 답이며, Qdrant 같은 전용 엔진과의 차이는 알고리즘이 아니라 자리다. 둘 다 HNSW지만, pgvector는 이를 Postgres 인덱스 접근 방식으로 구현한다. v0.8.4 기준으로 읽었다. 그래프는 WAL에 기록되는 Postgres 페이지에 살고, 검색은 평범한 SQL이며, 필터링은 새 반복 스캔으로 보완된 Postgres의 몫이다.

분석데이터 인프라

Qdrant의 필터 적용 벡터 검색 방식: 페이로드 필터를 견디는 HNSW

메타데이터 필터를 추가하는 순간 단순한 벡터 검색은 무너진다. 사후 필터링은 재현율을 망가뜨리고, 사전 필터링은 그래프를 활용할 수 없다. v1.18.2에서 읽은 Qdrant의 답은 두 가지다. 필터의 카디널리티를 추정해 정확 스캔과 그래프 검색 중 하나를 고르고, 빌드 시점에 페이로드를 인식하는 링크를 추가해 필터링된 하위 그래프의 연결을 유지한다. 이 해법의 근거는 침투 이론이다.

분석AI 인프라

vLLM은 어떻게 그렇게 많은 요청을 한꺼번에 처리하는가: PagedAttention과 연속 배칭

vLLM의 처리량은 여기서 v0.24.0rc2(v1 엔진)를 기준으로 읽은, 서로 맞물린 두 아이디어에서 나온다. PagedAttention은 각 요청의 KV 캐시를 공유 풀의 고정 16토큰 블록으로 페이징해 메모리를 비연속적이고 빽빽하게 채우며 동일한 접두사끼리 공유할 수 있게 한다. 연속 배칭은 매 순전파 단계마다 토큰 예산을 기준으로 배치를 다시 구성하고, 프리필과 디코드를 섞으며, 블록이 떨어지면 선점한다.

분석AI 인프라

CLIProxyAPI는 AI 구독을 어떻게 로드 밸런싱하는가 — 그리고 스케줄러가 드러내는 할당량 제한의 실체

CLIProxyAPI는 Claude, ChatGPT/Codex, Gemini 구독을 라운드 로빈으로 순회하는 OpenAI 호환 프록시로 소개된다. 소스를 읽어보면 실제로는 반응형 쿨다운 스케줄러다. 할당량을 추적하지 않고 429를 기다리며, 제한이 언제 초기화되는지 실제로 아는 경우는 Codex뿐이다.