분석개발자 도구
emilkowalski/skills는 모션 감각을 어떻게 에이전트 시스템으로 바꾸는가
다섯 가지 모션 디자인 스킬이 어휘, 원칙, 리뷰, 계획, 실행을 어떻게 분리하는지, 그리고 두 가지 중요한 워크플로 예외가 아키텍처의 실제 모습을 어떻게 드러내는지 소스 수준에서 해부한다.
최신
최신 분석
분석개발자 도구
CodexBar는 사실 메뉴 막대 앱이 아니다. 프로바이더 사용량 측정 런타임이다.
CodexBar는 AI 코딩 한도를 보여주는 작은 macOS 유틸리티처럼 보인다. v0.41.0의 소스를 읽어보니, 실제 아키텍처는 컴파일 시점의 프로바이더 ID, 디스크립터, 전략 파이프라인, 별도의 앱 훅으로 제각각인 벤더 할당량 신호를 하나의 사용량 화면으로 바꾸는 선별된 프로바이더 카탈로그였다.
분석개발자 도구
LazyCodex는 에이전트 집 전체가 아니라 그 입구다
LazyCodex는 복잡한 코드베이스를 위한 에이전트 하네스로 소개된다. v4.15.1의 소스를 읽어보니 범위는 더 좁았고, 오히려 그래서 더 유용했다. 루트 패키지는 작은 Codex 설치 별칭이고, 실제 제품은 번들로 제공되는 omo 플러그인이며, 더 깊은 하네스의 소유권은 OmO로 이어진다.
비교데이터 인프라
벡터 검색은 하나가 아니다: 서버, 확장, 임베디드 파일
벡터 검색은 먼저 어디에 존재하느냐에 따라 갈린다. Qdrant는 전용 벡터 엔진이고, pgvector는 PostgreSQL 인덱스 접근 방식이며, LanceDB/Lance는 파일 기반 임베디드 스택이다. 이 운영상의 기반이 벤치마크 튜닝을 시작하기도 전에 필터링, 내구성, 일관성, 장애 양상을 결정한다.
비교개발자 도구
AI 코딩 에이전트가 코드베이스를 모델에 전달하는 방법: 세 가지 진영
AI 코딩 에이전트는 한 가지 설계 선택, 즉 코드를 모델의 컨텍스트에 넣는 방식에 따라 갈린다. 나는 세 제품의 소스를 읽었다. Aider는 정적 그래프의 순위를 매기고, Continue는 임베딩하고 검색하며, Cline은 모델에 도구를 주고 필요할 때 읽게 한다. 이 한 가지 선택이 결정성, 토큰 비용, 프라이버시, 대규모 저장소에서의 동작 방식을 결정한다.
분석개발자 도구
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 인프라
LLM 게이트웨이의 세 진영 — 구독 풀링, 키 라우팅, 또는 프로덕션 게이트웨이 운영
LLM 게이트웨이라고 불리는 도구는 무엇을 라우팅하고 누구를 위한 것인지에 따라 나뉜다. CLIProxyAPI는 구독 로그인을 풀링한다. LiteLLM은 사용량 계측과 장애 조치를 갖춰 API 키를 라우팅한다. Portkey는 요청마다 전달하는 선언적 설정으로 구동되는 무상태 엣지 게이트웨이다. 세 프로젝트의 소스를 모두 읽어보니, 무엇을 가르는 결정적인 축은 각각 어떤 상태를 유지하는가였다.
분석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 인프라
로컬에서 LLM 실행하기: llama.cpp vs Ollama vs vLLM — 세 진영
오픈 모델을 자체 호스팅하는 도구는 어느 계층을 직접 운영하느냐에 따라 세 진영으로 나뉜다. llama.cpp는 원시 엔진이다. GGUF를 불러오고 가지고 있는 어떤 하드웨어로든 레이어를 오프로딩하는 독립 실행형 바이너리다. Ollama는 이를 감싸는 친근한 관리자다. vLLM은 이를 대체하는 처리량 서버다. 이 세 프로젝트의 소스를 모두 읽고 이식성, 편의성, 처리량을 비교했다.
분석AI 인프라
CLIProxyAPI는 AI 구독을 어떻게 로드 밸런싱하는가 — 그리고 스케줄러가 드러내는 할당량 제한의 실체
CLIProxyAPI는 Claude, ChatGPT/Codex, Gemini 구독을 라운드 로빈으로 순회하는 OpenAI 호환 프록시로 소개된다. 소스를 읽어보면 실제로는 반응형 쿨다운 스케줄러다. 할당량을 추적하지 않고 429를 기다리며, 제한이 언제 초기화되는지 실제로 아는 경우는 Codex뿐이다.
질문별
도구 뒤에 있는 질문
질문 하나는 서로 경쟁하는 답으로 갈립니다. 선택지마다 소스를 직접 읽어, 결정하기 전에 트레이드오프가 보이게 정리했습니다.
코드는 어떻게 모델까지 가는가?
결정 축은 컨텍스트 소유권이다. 코드를 미리 압축하느냐, 로컬 인덱스에서 검색하느냐, 모델이 직접 파일을 읽게 하느냐가 토큰 비용과 예측 가능성을 바꾼다.
어느 계층을 직접 운영할 것인가?
결정 축은 운영 계층이다. 바이너리 엔진을 직접 통제하느냐, 모델 매니저를 쓰느냐, 서버 처리량을 위해 엔진을 갈아 끼우느냐로 갈린다.
- raw 엔진llama.cpp
GGUF 모델을 직접 로드하는 이식성 우선 로컬 추론 엔진
로컬에서 LLM 실행하기: llama.cpp vs Ollama vs vLLM — 세 진영 - 모델 매니저Ollama
llama.cpp 서버를 감싸고 모델 수명 주기를 관리하는 로컬 LLM 매니저
Ollama가 모델을 로드하는 방식 — 그리고 실제로 GPU 레이어 수를 결정하지 않는 이유 - 처리량 서버vLLM
동시 요청 처리량을 위해 KV 캐시와 배칭을 다시 설계한 추론 서버
vLLM은 어떻게 그렇게 많은 요청을 한꺼번에 처리하는가: PagedAttention과 연속 배칭
게이트웨이는 어떤 상태를 쥐고 라우팅하는가?
결정 축은 상태 소유권이다. 제품이 로그인 세션을 모으는지, 키 사용량을 계측하는지, 엣지에서 설정만 나르는지가 그 한계를 정한다.
- 구독 풀CLIProxyAPI
여러 구독 계정을 OpenAI 호환 프록시 뒤에 두는 계정 풀러
CLIProxyAPI는 AI 구독을 어떻게 로드 밸런싱하는가 — 그리고 스케줄러가 드러내는 할당량 제한의 실체 - 키 라우터LiteLLM
여러 모델 배포와 API 키에 걸쳐 계측하고 라우팅하는 LLM 프록시
LiteLLM의 라우터는 어떻게 배포를 고르는가 — 기본값은 가중 무작위, 직접 설정해야만 스마트해진다 - 선언형 엣지 게이트웨이Portkey
선언형 설정으로 제공자 라우팅을 통제하는 프로덕션 지향 게이트웨이
LLM 게이트웨이의 세 진영 — 구독 풀링, 키 라우팅, 또는 프로덕션 게이트웨이 운영
벡터 검색은 무엇으로 존재하는가?
결정 축은 존재 방식이다. 별도 엔진을 돌리느냐, Postgres 안에 사느냐, 애플리케이션 프로세스에서 파일을 여느냐가 일관성, 배포, 필터링 전략을 바꾼다.
- 전용 서버Qdrant
필터링된 HNSW 검색을 자체 엔진 안에서 푸는 전용 벡터 서버
Qdrant의 필터 적용 벡터 검색 방식: 페이로드 필터를 견디는 HNSW - Postgres 확장pgvector
HNSW를 인덱스 접근 방식으로 구현한 Postgres 확장
pgvector는 HNSW를 어떻게 Postgres 안에 넣는가 — 인덱스 접근 방식으로서의 벡터 검색 - 임베디드 파일과 포맷LanceDB
서버가 아니라 애플리케이션이 직접 여는 파일 포맷 기반 벡터 데이터베이스
LanceDB가 벡터 데이터베이스를 파일에 담는 방식: Lance 컬럼형 포맷 위의 IVF-PQ, 서버는 없다