시리즈: warpinfra-data-grid에 해당하는 글입니다.
![[WarpInfra] 남은 일 — mTLS·20GB 실측·Control MVP·그리고 컴퓨트 그리드](/tistory/body-images/2026-08-07-warpinfra-10-remaining-work/cover.webp)
시리즈의 마지막 편은 백로그다. 지금 남은 일의 순서는 우연이 아니라 원칙으로 고정되어 있다. 이 편은 RC1 게이트 뒤의 작업을 Now/Next/Later로 나눠 읽고, 시리즈를 닫는다.
![[WarpInfra] RC1 — 20GB·다중 머신·SHA-256 없으면 출시가 아니다](/tistory/body-images/2026-08-07-warpinfra-09-rc1-gate/cover.webp)
제품이 "완료됐다"고 말하는 순간은 기능이 끝났을 때가 아니라 증거가 갖춰졌을 때다. WarpInfra의 RC1 문서는 이 원칙을 게이트로 박아두었다. 이 편은 그 게이트와 현재 통과 상태를 대조한다.
![[WarpInfra] Phase A를 95%까지 올린 구현 묶음](/tistory/body-images/2026-08-07-warpinfra-08-phase-a-95/cover.webp)
Phase ALAN Grid MVP의 목표는 단순하다. 코디네이터 없이, 같은 LAN에서 앱들이 release를 공유하고 메시 수신한다. 2026-07-18 기준 이 단계는 약 95%다. 이 편은 그 95%를 만든 부품 묶음을 정리한다.
![[WarpInfra] 희소한 조각부터, 여러 피어에게 동시에](/tistory/body-images/2026-08-07-warpinfra-07-rarest-first-piece-race/cover.webp)
여러 Node가 한 파일을 나눠 받을 때, 스케줄러가 "어느 조각을 먼저 요청할지" 고르는 기준이 결과를 가른다. WarpInfra는 rarest-first를 택하고, Have fanout으로 조각 보유 정보를 퍼뜨리고, multi-peer piece race로 지연을 줄였다.
![[WarpInfra] 폴더가 단일 스트림으로 줄줄이 나가던 버그](/tistory/body-images/2026-08-07-warpinfra-06-zip-streaming-folder/cover.webp)
폴더 전송은 겉보기엔 단순하다. "파일을 묶어서 보내면 된다." 그런데 zip으로 묶는 순간 메모리와 디스크와 타이밍이 한꺼번에 어긋난다. 이 편은 zip 패키징 실패가 단일 스트림 연속 송신으로 바뀌기까지의 커밋을 읽는다.
![[WarpInfra] WASM을 버리고 네이티브 QUIC로 갈아탄 날](/tistory/body-images/2026-08-07-warpinfra-05-native-quic/cover.webp)
한때 전송 코어는 WASM에 얹혀 있었다. 웹과 데스크톱이 같은 코어를 쓰려는 의도였다. 그런데 데스크톱에선 그 선택이 오히려 발목을 잡았다. 이 편은 WASM 의존을 제거하고 네이티브 QUIC로 전환한 커밋들을 추적한다.
![[WarpInfra] CLI를 1등 시민으로 둔 이유 — CI와 AI 에이전트](/tistory/body-images/2026-08-07-warpinfra-04-cli-first-ai-agents/cover.webp)
GUI를 먼저 만들고 CLI를 "개발자용 부가기능"으로 두는 제품이 많다. WarpInfra는 정반대다. CLIwarp가 1등 시민이고, GUI와 agentd가 같은 코어를 공유한다. 이 선택의 근거는 단순하다. "운영자는 사람이 아니라 파이프라인이다."
![[WarpInfra] 컴퓨트 그리드를 일부러 뒤로 미룬 로드맵](/tistory/body-images/2026-08-07-warpinfra-03-roadmap-data-grid-first/cover.webp)
"그리드"라는 단어를 들으면 대부분 분산 연산을 떠올린다. WarpInfra는 반대로 갔다. 분산 전송데이터 그리드을 먼저 끝내고, 분산 연산컴퓨트 그리드은 데이터 그리드가 안정화된 뒤에만 설계하기로 했다. 이 순서 고정이 이 시리즈의 로드맵 편이다.
![[WarpInfra] 파일 바이트는 Control을 지나지 않는다](/tistory/body-images/2026-08-07-warpinfra-02-control-vs-data-plane/cover.webp)
그리드 아키텍처에서 가장 먼저 고정한 원칙이 하나 있다. "파일 payload는 Control이 아니라 Node 간 P2P로 이동한다." 이 한 줄이 coordinator 설계, 라우트 노출, 보안 경계를 모두 결정했다.
![[WarpInfra] 레지스트리 옆 CLI release get — 복제하지 않는 니치](/tistory/body-images/2026-08-07-warpinfra-01-niche-cli-release-get/cover.webp)
분산 파일 전송 제품은 이미 많다. Resilio, Aspera, Signiant. 그런데도 WarpInfra를 처음부터 만들기로 한 이유는 무엇일까. 한 줄로: 전체 미러링 제품을 복제하는 대신, "레지스트리 옆에서 release를 받는 CLI"라는 좁은 일감을 골랐기 때문이다.
![[WarpInfra] 데이터 그리드 시리즈를 시작하며 — desktop과 grid, 그리고 이름](/tistory/body-images/2026-08-07-warpinfra-00-series-map/cover.webp)
레포는 두 개다. 이름은 하나다. 이 시리즈는 DeclanJeon/ponswarp-desktop146커밋과 DeclanJeon/ponswarp-grid29커밋의 커밋 이력을 시간순이 아니라 설계 → 구현 → 남은 일 순서로 다시 읽는 기록이다. 이 글이 그 지도다.
![[PonsWarp Grid] 방을 먼저 열고, direct와 grid를 가르다](/tistory/body-images/2026-08-07-ponswarp-grid-03-room-first-direct-grid/cover.webp)
파일을 고르는 순간 방이 열린다. 전송은 direct직접와 grid그리드로 갈린다. 사용자는 경로를 고르지 않는다. 제품이 고른다. 이 편은 room-first 메시 전송과 direct/grid 분기, 그리고 브라우저 대용량 export가 Blob에서 터진 사건을 함께 읽는다.
![[PonsWarp Grid] coordinator를 "안전하게" 노출한다는 것](/tistory/body-images/2026-08-07-ponswarp-grid-02-coordinator-routes/cover.webp)
제어면이 바이트를 안 다루기로 했으니, coordinator가 노출하는 라우트는 메타만 다뤄야 한다. 이 편은 ponswarp-grid에서 coordinator 라우트를 공개하면서 무엇을 넣고 무엇을 금지했는지, 그리고 mesh 연산을 CLI로 묶은 커밋을 본다.
![[PonsWarp Grid] 브라우저 그리드 엔진을 처음부터 다시 짜다](/tistory/body-images/2026-08-07-ponswarp-grid-01-engine-from-zero/cover.webp)
desktop이 네이티브 그리드로 가는 동안, 브라우저 쪽에는 별도의 엔진이 필요했다. ponswarp-grid 레포다. 이 편은 그 엔진을 처음부터제로베이스 짠 29개 커밋의 시작점을 읽는다.