SERIESWarpInfra Data Grid

[WarpInfra] 남은 일 — mTLS·20GB 실측·Control MVP·그리고 컴퓨트 그리드

Aug 7, 2026·5 min read·178 views

WarpInfraPonsWarpDataGrid개발회고백로그

시리즈의 마지막 편은 백로그다. 지금 남은 일의 순서는 우연이 아니라 원칙으로 고정되어 있다. 이 편은 RC1 게이트 뒤의 작업을 Now/Next/Later로 나눠 읽고, 시리즈를 닫는다. 백로그를 마지막 편에 두는 이유도 있다 — 남은 일이 무엇인지가 그동안의 결정이 무엇을 지켰는지의 최종 성적표이기 때문이다.

백로그라는 형식 자체에 담긴 태도도 먼저 밝혀두자. 마지막 편은 보통 "비전"이나 "다음은 더 큰 그림"으로 끝난다. 이 시리즈는 대신 남은 일의 목록으로 끝난다. 완성되지 않은 것을 마지막 페이지에 놓는 것은, 이 시리즈가 "성공 서사"가 아니라 "중간 지점의 정확한 좌표"임을 선언하는 형식적 선택이다. 좌표가 정확하면 다음 이동도 정확하다. 감상으로 끝나는 회고보다 백로그로 끝나는 회고가 다음 주에 더 쓸모있다.

백로그 (우선순위 고정)

우선도	항목	왜 이 순서인가
P0	multi-host 20GB 실측 캡처	RC1 원칙 4 — 증거 없으면 미완
P0	mTLS / 인증서 검증 우회 제거	RC1 원칙 3 — 운영 안전
P0	사내 파일럿 시나리오 1 (1 seed → 5 receivers)	첫 실사용 검증
P1	온프레 Control MVP (카탈로그·토큰·정책)	플레인 분리 원칙의 완성
P1	관측성 · 서비스 패키징	운영 가능성
P2	multi Release Agent · GUI 운영 UX 심화	제품 확장
Later	컴퓨트 그리드 설계	데이터 그리드 안정화 후만

표를 위에서 아래로 읽으면 우선순위가, 오른쪽 열을 세로로 읽으면 이유가 보인다. P0 세 항목의 공통점은 전부 "증거"라는 것이다. 20GB 실측은 성능 증거, mTLS는 신원 증거, 사내 파일럿은 가치 증거. 제품이 세상에 나가기 전에 갖춰야 할 세 종류의 증명이다. P1 두 항목은 "완성"이다 — 플레인 분리 원칙이 정책 기능(Control MVP)을 갖추는 순간 완성되고, 운영 가능성은 관측성이 있어야 완성된다. P2 이하는 확장이고, Later의 컴퓨트 그리드는 로드맵 편에서 본 "구현하지 않는다" 원칙의 상태 그대로다.

우선순위가 "고정"이라는 단어와 함께 표 제목에 붙은 것도 읽을 거리다. 백로그의 우선순위는 살아있는 문서에서 가장 자주 바뀌는 부분이다 — 급한 일이 오면 P1이 P0가 되고, 목소리 큰 요구가 순위를 뛰어넘는다. 이 백로그가 고정될 수 있는 이유는 우선순위의 근거가 상황이 아니라 원칙(RC1 게이트)이기 때문이다. P0는 "지금 급한 것"이 아니라 "게이트가 요구하는 것"이다. 근거가 원칙이면 우선순위 논쟁은 원칙 논쟁으로 승격되고, 원칙을 바꾸려면 문서를 고쳐야 한다. 백로그 재배열의 진입 비용을 높이는 것 — 그게 원칙 기반 백로그의 실용적 기능이다.

P0의 세 번째 항목 — 사내 파일럿 시나리오(1 seed → 5 receivers) — 은 눈에 덜 띄지만 의미가 크다. 20GB 실측이 시스템을 검증한다면 파일럿은 제품을 검증한다. 실제 사용자가 실제 배포 상황에서 이 제품을 썼을 때 문제가 없는가. 이 두 검증은 서로를 대체하지 못한다. 시스템이 완벽해도 제품이 맞지 않으면 없는 것과 같고, 제품이 맞아도 시스템이 못 버티면 약속을 못 지키는 것이다. 1 seed → 5 receivers라는 구체적 형태도 의미가 있다. 분산 수신이라는 니치의 최소 실증 단위를 시나리오 언어로 박아둔 것이다 — 이 형태가 되지 않으면 그리드가 아니라 복제 다운로드다.

P1의 Control MVP는 백로그에서 가장 "설계다운" 항목이다. 카탈로그(release의 목록과 위치), 토큰(누가 무엇을 받을 수 있는가), 정책(대역폭·동시성 제한) — 이 셋은 S1-02에서 정의한 제어면의 책임 목록 그 자체다. 즉 Control MVP는 새 기능이 아니라 오래된 원칙의 구현 완결이다. 플레인 분리를 선택할 때 "정책 기능은 Control에 둔다"고 했는데, 정책이 존재하지 않는 동안 그 약속은 비어 있었다. Control MVP가 이 빈자리를 채운다.

관측성·서비스 패키징이 P1에 있는 것도 같은 논리다. 운영 가능성은 기능이 아니라 제품의 성숙도다. 데스크톱 편의 agentd가 "사람 없이 돌리는" 부품이었다면, 관측성은 "무슨 일이 일어나는지 아는" 부품이다. 둘 다 갖춰져야 사내 운영팀에 넘길 수 있다.

P2와 Later 사이의 경계도 언급할 만하다. multi Release Agent와 GUI 심화는 제품이 자리 잡은 뒤의 확장이고, 컴퓨트 그리드는 로드맵 원칙이 잠금 해제 조건을 명시한 유일한 항목이다. "데이터 그리드 안정화 후만"이라는 문구가 Later에도 붙어 있는 것은, 미룬다고 잊는 것과 미룬다고 보호하는 것의 차이를 만든다. 조건이 적힌 보류는 자격이 생기면 열리는 문이고, 조건 없는 보류는 잊히는 서랍이다.

설계가 남긴 약속 vs 구현이 닿은 선

이 시리즈를 한 문장으로 닫는다면:

"파일 바이트는 제어면을 지나지 않는다"라는 설계 약속을, 구현은 QUIC 피어 경로까지 지켰고, 검증은 20GB 실측이라는 게이트 앞에서 정직하게 멈춰 섰다.

약속 (설계)	구현 도달	검증
payload P2P	✅ QUIC/WebRTC 피어 경로	부분 (로컬)
control 최소화	✅ coordinator 메타만	✅
CLI-first	✅ warp CLI · agentd	✅
20GB 증거	—	❌ P0

이 표가 시리즈 전체의 재무제표다. 자산은 지켜진 약속이고 부채는 검증 대기 항목이다. 부채 중 가장 큰 것이 20GB 증거고, 이 부채를 갚는 것이 시리즈 이후의 첫 작업이다.

표의 세 행이 공유하는 검증 패턴도 짚자. payload P2P는 "로컬에서 부분 검증됨", control 최소화는 "라우트 목록으로 검증됨", CLI-first는 "계약 문서와 커밋으로 검증됨". 같은 "검증"이라도 무엇으로 하는지가 각기 다르다 — 측정, 코드 구조, 문서. 이 표를 만들 때 든 생각은 "모든 약속이 같은 종류의 증거를 요구하지 않는다"는 것이었다. 그래서 각 행에 맞는 검증 양식을 붙였고, 양식이 없는 행(20GB)이 가장 큰 부채로 남았다.

표에서 눈여길 행은 "20GB 증거"의 구현 도달 칸이 비어 있다는 것이다. 다른 행은 구현이 체크돼 있거나 명시적으로 부분이다. 20GB 증거만은 구현 자체가 아니라 — 구현은 95% 끝났으니까 — 오직 검증 칸에만 존재한다. 이 비어 있는 칸이 시리즈 전체를 관통한 "구현과 증명의 간극"의 최종 형태다. 간극이 채워지는 순간 RC1 논의가 열리고, 채워지지 않으면 이 표가 그대로 다음 기록의 출발점이 된다.

시리즈를 돌아보며

14편을 통틀어 반복된 패턴이 세 가지 있다.

첫째, 기각의 기록. Resilio 복제 금지(니치), coordinator 중계 금지(플레인), WASM 기각(QUIC), 컴퓨트 보류(로드맵) — 이 시리즈의 결정 목록에서 기각이 채택보다 많았다. 무엇을 안 만들었는지가 무엇을 만들었는지보다 제품을 많이 설명했다.

둘째, 근거의 인용. 커밋 해시(8aabffc, 785ed4a, 258740e…), 문서 파일명, 날짜가 붙은 스냅샷. 모든 주장이 검증 가능한 형태로 적혔다. 이 기록을 읽는 누군가 — 미래의 나든 다른 개발자든 — 커밋을 checkout해서 주장을 확인할 수 있다.

셋째, 미해결의 보존. mTLS, 20GB, Control MVP, grid-experimental 포함 여부 — 해결 안 된 것들은 사라지지 않고 백로그의 자리를 지킨다. 이 시리즈가 "완성 스토리"가 아니라 "95% 지점의 스냅샷"이라고 스스로 규정한 것과 같은 맥락이다.

세 패턴의 공통점은 하나다 — 기록이 미래의 판단을 돕도록 썼다. 기각은 다음 제안이 왔을 때 다시 논쟁하지 않게, 근거는 주장을 재검증 가능하게, 미해결은 다시 발견되지 않게. 회고의 소비 기한이 읽는 순간이 아니라 다음 결정의 순간이라고 보는 관점이다. 14편의 분량 대부분이 이 세 가지를 반복하는 데 쓰였고, 반복이 지루했다면 그건 목적 달성의 증거다 — 방법은 반복될 때 익혀진다.

시리즈 에필로그

14편 동안 본 것은 "멋진 아키텍처"가 아니라 게이트를 지키는 개발이다. 아키텍처는 결국 게이트를 통과해야 신뢰되고, 게이트는 아키텍처가 있어야 의미가 있다. 다음 시리즈는 20GB 실측이 끝난 뒤, Control MVP의 설계로 이어진다. 그때까지 이 백로그가 기준이다.

백로그가 기준이라는 말의 실질은 이렇다. 다음에 이 프로젝트를 다룰 때 — 블로그든 코드든 — 우선순위를 다시 논할 필요가 없다. P0가 끝났으면 P1로 간다. P0가 중간에 바뀌어야 한다면 그건 원칙이 바뀐 것이고, 원칙이 바뀌면 그 이유를 문서로 남긴다. 이 마지막 편이 시리즈가 아니라 프로젝트의 기준선이 되기를 바란다.

읽어준 독자에게 남기는 실용적 조언 하나로 끝낸다. 이 시리즈에서 재사용 가능한 것은 PonsWarp의 설계가 아니라 방법이다 — 완료 판정 기준을 문장으로 박아두는 것, 기각의 이유를 기록해두는 것, 구현과 증명을 구분하는 것, 남은 일을 원칙에서 역산하는 것. 이 네 가지는 파일 전송 제품이 아니라도 어떤 인프라 프로젝트에나 그대로 옮겨 붙는다. 아키텍처는 프로젝트에 갇히지만 방법은 갇히지 않는다. 그리고 방법이야말로 이 기록이 여러 편에 걸쳐 남을 만한 이유다.