[AI] px0: 리눅스 커널도 370ms에 훑는 AI 코드 리뷰 전용 IDE

VS Code를 켜는 데 몇 초가 걸리는 건 이제 아무 문제가 아니었다. 정작 문제는 그 다음이다 — AI 에이전트가 파일 열 몇 개를 고쳐놓고 나면, 사람은 그 변경이 맞는지 확인하느라 편집기보다 더 많은 시간을 검토 화면 앞에서 보낸다. 시스템 설계 교육자 Arpit Bhayani가 만든 오픈소스 프로젝트 px0-ai/px0는 이 관찰 하나에서 출발해, “타이핑 속도"가 아니라 “검토 속도"에 맞춰 처음부터 다시 설계한 IDE다. 이 글은 px0의 설계 철학과 실측 벤치마크, 에이전트 연동 구조를 살펴보고 언제 이 도구가 실제로 유용한지 판단 기준을 정리한다.

개요 — 누가, 왜 만들었나

px0는 Go로 작성된 MIT 라이선스 오픈소스 프로젝트로, 저장소는 px0-ai/px0다. 2026년 9월 30일 기준 GitHub 스타 1,700개대·포크 200개대를 넘겼고, 전날인 9월 29일에도 커밋이 올라올 만큼 활발히 관리되고 있다. 제작자 Arpit Bhayani는 Amazon Fast Data Team·Unacademy 엔지니어링 리더십을 거쳐 Google Staff Engineer(GCP Memorystore·Dataproc 담당)로 일했고 현재 Razorpay Principal Engineer II다(출처: arpitbhayani.me). 구독자 21만 명대의 유튜브 채널 Asli Engineering에서 시스템 설계·데이터베이스 내부 구조를 다뤄온 인물이 코드 편집기가 아니라 데이터베이스·분산 시스템 쪽 배경으로 IDE를 만든 이유는, px0 블로그의 선언문 “IDEs are dead, long live the IDE"에 명확히 적혀 있다.

“The primary bottleneck in software engineering is no longer typing speed. It is inspection latency.” (소프트웨어 엔지니어링의 주된 병목은 더 이상 타이핑 속도가 아니다. 검토 지연이다.)

— Arpit Bhayani, “IDEs are dead, long live the IDE” (px0 Blog, 2026-09-15)

추천 대상은 명확하다. Claude Code·Cursor·Codex 같은 CLI 에이전트를 이미 일상적으로 돌리고 있고, 그 결과물을 확인하는 데 매번 무거운 IDE를 새로 띄우는 게 번거롭다고 느끼는 개발자다. 반대로 에이전트 없이 직접 타이핑으로 코드를 짜는 워크플로가 중심이라면, px0가 해결하는 문제 자체가 아직 체감되지 않을 가능성이 크다.

왜 “읽기 중심” 설계를 택했는가

px0 블로그는 에이전트 시대의 개발 루프를 다음과 같은 순환으로 요약한다.

flowchart LR
    Agent["에이전트가 변경 생성"] --> Review["개발자가 검토·탐색"]
    Review --> Feedback["피드백 또는 다음 프롬프트"]
    Feedback --> Agent

이 루프에서 사람이 실제로 반복하는 작업은 코드를 새로 “쓰는” 것이 아니라, 크로스 파일 심볼 참조를 추적하고, HEAD 대비 실시간 git diff를 확인하고, 아키텍처·보안 불변식이 깨지지 않았는지 검증하는 일이다. 문제는 기존 IDE가 이 루프를 위해 설계되지 않았다는 데 있다.

“When you are running local LLMs, Docker containers, compilers, and multiple agent loops, sacrificing 2 GB of RAM and 15 background processes just to view code is unsustainable.” (로컬 LLM·Docker 컨테이너·컴파일러·여러 에이전트 루프를 동시에 돌리는 상황에서, 코드를 보기만 하는 데 2GB RAM과 15개 백그라운드 프로세스를 희생하는 건 지속 가능하지 않다.)

— Arpit Bhayani, “IDEs are dead, long live the IDE” (px0 Blog, 2026-09-15)

VS Code 같은 Electron 기반 IDE는 에이전트 한두 개가 아니라 편집기 자신도 GB 단위 메모리를 점유한다. px0는 그 반대편 극단을 택했다 — 구문 강조·자동완성 UI·리팩터링 도구 같은 “쓰기” 기능을 아예 들어내고, 심볼 탐색·diff·검색만 남긴 순수 조회 도구로 좁힌 것이다. 코드를 실제로 고치는 일은 Claude Code·Gemini CLI 같은 외부 CLI 에이전트에 전부 위임한다.

벤치마크로 보는 성능

px0는 공식 벤치마크 페이지에서 px0·Vim·Neovim·Sublime Text·Zed·VS Code 6종을 Flask(235개 파일)부터 리눅스 커널(95,710개 파일)까지 7개 실제 오픈소스 저장소로 비교한 결과를 공개하고, benchmark.sh 스크립트로 직접 재현할 수 있게 했다(테스트 환경: Linux 6.x, Ryzen 7/Core i7급, 32GB DDR5, NVMe SSD, 언어 서버 끈 상태에서 5회 측정 중 최고 기록).

리눅스 커널이 TypeScript 저장소보다 파일 수가 더 많은데도 인덱싱이 더 빠른 이유는 파일 구성의 성격 차이다. 커널 소스는 대부분 평평한 구조의 C 소스·헤더 파일이라 px0의 병렬 디렉터리 워커가 비-코드 파일을 걸러내며 동시에 훑기 유리한 반면, TypeScript 저장소는 node_modules류 중첩 디렉터리와 다양한 파일 타입이 섞여 순회 비용이 더 든다. “5회 중 최고 기록"이라는 측정 조건은 평균값보다 낙관적인 수치일 수 있다는 점도 함께 감안해야 한다.

메모리 쪽 차이는 더 크다. px0의 Go 서버 데몬은 상주 메모리(RSS) 20–30MB만 쓰고, 브라우저 탭의 DOM·V8 런타임·GPU 컴포지팅까지 합쳐도 전체 100–180MB 선이다. 반면 VS Code는 1,100–1,440MB를 쓴다 — px0 기준 약 85–90% 가볍다는 계산이 여기서 나온다. 다만 이 수치는 px0 자체 벤치마크 스크립트로 측정한 결과이므로, 다른 하드웨어·워크로드에서는 편차가 있을 수 있다는 점을 감안해야 한다.

주요 기능 상세

에이전트 디스패치 — 코드는 CLI에, 검토는 브라우저에

px0는 Claude Code(claude --permission-mode acceptEdits --model haiku 같은 형태로 등록), Gemini CLI, Cursor Agent, Antigravity, OpenCode, Codex, Aider, Goose까지 8종의 CLI 코딩 에이전트를 실행 명령으로 등록해둔다. 코드 영역을 마우스로 선택해 우클릭하거나 단축키로 원하는 에이전트를 고르면, 선택한 텍스트를 컨텍스트로 실어 변경 요청을 보낸다. 에이전트가 돌아가는 동안 실행 로그는 터미널 패널에 그대로 스트리밍되고, 작업이 끝나면 변경된 파일을 자동으로 다시 읽어 diff에 반영한다. 겹치는 줄 범위를 동시에 건드리려는 요청은 거부하도록 만들어, 여러 에이전트를 한 파일에 동시에 붙여도 서로 덮어쓰는 충돌을 막는다.

Git·GitHub 통합

브라우저를 벗어나지 않고 GitHub PR을 직접 열어 스코프된 merge-base diff를 확인하고, 인라인 리뷰 코멘트를 작성하고, 로컬 변경을 스테이징·커밋·푸시까지 할 수 있다. 아직 푸시하지 않은 로컬 커밋도 같은 Git 패널에서 검토 대상이 된다.

대용량 코드베이스 처리

가상 렌더링으로 40만 줄짜리 단일 파일도 스크롤이 끊기지 않게 열 수 있고, Chroma 기반 토크나이저로 약 280개 언어를 네이티브로 인식한다. LSP(Language Server Protocol)를 지원해 심볼 정의·참조 추적이 별도 플러그인 없이 동작하며, 마크다운 미리보기·CSV/TSV 표 뷰·14개 내장 테마도 함께 제공한다.

원격 우선 아키텍처

SSH 포트포워딩이나 원격 데스크톱 데몬 없이 Tailscale·WireGuard·리버스 프록시만으로 원격 서버·VM·CI 러너의 코드베이스를 로컬 브라우저에서 바로 열어볼 수 있다. 상태는 저장소 안이 아니라 ~/.px0/settings.json에만 저장해, 검토 도구가 저장소 자체를 오염시키지 않는다.

적용 시나리오와 판단 기준

에이전틱 코딩 도구 생태계에서 지금까지 주목받은 축은 대부분 “에이전트를 어떻게 오케스트레이션하고 비용을 최적화할까"였다. px0는 정반대 지점 — 에이전트가 이미 만들어낸 변경을 사람이 얼마나 빨리 확인하느냐 — 를 별도의 병목으로 취급한다는 점에서 다르다. 그래서 px0가 적합한지 여부는 도구 자체의 성능보다 “지금 내 하루 중 검토가 실제 병목인가"라는 질문에 달려 있고, 이 질문의 답에 따라 적합한 상황과 과한 선택이 명확히 갈린다.

적합한 경우

• CLI 기반 코딩 에이전트(Claude Code, Codex 등)를 이미 상시 사용 중이고, 결과물 검토가 워크플로의 실제 병목인 경우 — 무거운 IDE를 매번 새로 띄우는 대신 브라우저 탭 하나로 diff·심볼·PR을 즉시 확인할 수 있어 “에이전트 실행 → 결과 확인” 사이의 대기 시간이 줄어든다.
• 원격 서버·VM·CI 환경의 코드를 자주 들여다봐야 하는 경우 — SSH 포트포워딩 없이 원격 코드베이스를 로컬 설치 없이 바로 검토할 수 있다는 이점이 그대로 워크플로 이점이 된다.
• 리소스가 제한된 머신(저사양 노트북, 다중 VM 동시 운용)에서 여러 도구를 함께 돌려야 하는 경우 — 로컬 LLM·컴파일러·여러 에이전트 인스턴스와 동시에 돌려도 검토 도구 자체가 차지하는 메모리가 20–30MB 선이라 여유가 남는다.

과한 선택일 수 있는 경우

• 코드를 여전히 직접 타이핑으로 작성하는 비중이 높아, 자동완성·리팩터링 같은 편집 기능이 핵심 워크플로인 경우 — px0에는 애초에 이런 기능이 없어 별도 편집기와 병행해야 한다.
• 이미 VS Code나 JetBrains 계열 IDE의 확장 생태계(디버거, 언어별 플러그인)에 깊이 의존하고 있어, 그 생태계를 포기하면서 얻는 이득보다 전환 비용이 더 클 경우.
• 프로젝트 규모가 작아 애초에 인덱싱·검색 속도 차이를 체감하기 어려운 경우 — 벤치마크 격차는 파일 수가 만 단위를 넘어갈 때부터 뚜렷해진다.

장단점과 종합 평가

장점

• 실측 벤치마크가 재현 스크립트와 함께 공개돼 있어, 1,700개대 스타에 기대는 게 아니라 수치 자체를 직접 검증할 수 있다.
• Go 정적 바이너리 하나로 배포되어 설치·실행이 단순하고, MIT 라이선스라 상업적 사용에도 제약이 적다.
• 8종의 CLI 에이전트를 동일한 인터페이스로 다루므로 특정 벤더에 종속되지 않고, 조직마다 다른 에이전트 조합을 그대로 유지한 채 검토 레이어만 공통화할 수 있다.

한계·리스크

• 코드 편집 기능이 아예 없으므로, 에이전트 없이 직접 코드를 짜는 작업에는 별도 편집기가 여전히 필요하다. 즉 px0는 IDE 대체재가 아니라 검토 전용 보조 도구다.
• 비교적 신생 프로젝트(2026년 하반기 기준)라 장기 유지보수·보안 패치 이력이 아직 짧다. 원격 접속 구조를 쓰는 만큼 프로덕션 코드베이스에 연결할 때는 접근 통제를 직접 점검해야 한다.
• GitHub에는 동일한 README·구조를 그대로 복제한 개인 fork 저장소가 다수 관측되는데, 이는 오픈소스에서 흔한 fork/star 확산 패턴일 수 있으므로 원본(px0-ai/px0) 기준 지표만 신뢰하는 것이 안전하다.

종합하면 px0는 “모든 개발자를 위한 차세대 IDE"라기보다, 에이전트 결과물 검토가 이미 일과의 큰 비중을 차지하는 사람들을 위한 틈새 도구에 가깝다. 그 틈새를 벤치마크로 증명해가며 파고든다는 점에서, 에이전틱 코딩 도구 생태계가 “생성"에서 “검증"으로 무게 중심을 옮기고 있다는 신호로 읽을 만하다.

이 글을 읽고 나면 판단할 수 있어야 하는 것

px0를 실제로 도입할지 결정하기 전에, 아래 질문에 스스로 답할 수 있는지 확인해보면 이 글의 핵심을 제대로 짚었는지 가늠할 수 있다.

• px0가 왜 편집 기능을 아예 들어냈는지 — “타이핑 속도"가 아니라 “검토 지연"이 병목이라는 설계 논리를 다른 사람에게 설명할 수 있는가?
• 리눅스 커널이 TypeScript 저장소보다 파일 수가 많은데도 더 빨리 인덱싱되는 이유를 파일 구성 차이로 설명할 수 있는가?
• 8종 CLI 에이전트 디스패치 구조에서, 여러 에이전트가 같은 파일을 동시에 건드릴 때 충돌을 막는 장치가 무엇인지 아는가?
• 지금 자신의 워크플로에서 px0가 “적합한 경우"와 “과한 선택” 중 어디에 해당하는지, 그 근거를 하나 이상 들어 판단할 수 있는가?

시작하기

macOS·Linux·BSD에서는 설치 스크립트 한 줄로 바로 시작할 수 있다.

1

curl -fsSL https://px0.ai/install.sh | sh

Go 1.24 이상과 Node.js 또는 Bun이 있다면 소스에서 직접 빌드할 수도 있다.

1
2
3

git clone https://github.com/px0-ai/px0.git
cd px0 && make build
install -d ~/.local/bin && install px0 ~/.local/bin/

이후 현재 디렉터리를 바로 열거나, 특정 파일·GitHub PR·원격 서버를 지정해 실행한다.

1
2
3
4

px0                                           # 현재 디렉터리 검사
px0 main.go:42                                # 특정 파일·라인
px0 https://github.com/owner/repo/pull/123    # GitHub PR 검토
px0 -host 0.0.0.0 -port 7777 ~/workspace      # 원격 서버에서 실행

업데이트는 px0 --update 한 줄로 처리된다.

참고 문헌

• px0-ai/px0 GitHub 저장소
• px0 공식 벤치마크 페이지
• Arpit Bhayani, “IDEs are dead, long live the IDE” (px0 Blog, 2026-09-15)
• px0 공식 사이트
• Arpit Bhayani 소개