SERIESWarpInfra Data Grid

[WarpInfra] Phase A를 95%까지 올린 구현 묶음

Aug 7, 2026·4 min read·178 views

WarpInfraPonsWarpDataGrid개발회고PhaseA

Phase A(LAN Grid MVP)의 목표는 단순하다. 코디네이터 없이, 같은 LAN에서 앱들이 release를 공유하고 메시 수신한다. 2026-07-18 기준 이 단계는 약 95%다. 95%라는 숫자를 처음 보면 "거의 다 됐네"라는 느낌이 들지만, 이 편의 요지는 정반대다. 이 95%의 정체를 부품 목록으로 까보면, 남은 5%가 왜 가장 무거운지, 그리고 왜 그 5%가 "기능"이 아니라 "증거"인지가 보인다.

"코디네이터 없이"라는 조건을 다시 읽어달라. Control 최소 상태에서 그리드가 성립하는가를 보겠다는 것이다. 이 조건이 있기 때문에 Phase A는 통신 시스템의 시험이다 — 피어들이 서로를 발견하고, 조각 지도를 나누고, 스스로 스케줄링하는 능력 전체가 검증 대상이다. coordinator가 다 퍼줬다면 그건 그리드의 시험이 아니라 coordinator의 시험이다. 플레인 분리 원칙(S1-02)을 선택한 설계가 반드시 통과해야 하는 시험장이 Phase A다.

들어간 부품

부품	커밋/문서	상태
로컬 release manifest	`3568b2f` (local release manifest + warp CLI)	done
`warp` CLI	`3568b2f`, `8ac4ec9`	done
QUIC multi-peer piece path	`accb3ca`, `258740e`	done
resume	Phase A 목록 A-4	done
agentd	status doc	done
GUI RELEASE 동작	`3f2d9a4` (UI 패널)	done
loopback 증거	phase-a work report	done

이 표를 읽는 방법은 두 가지다. 위에서 아래로 "다 됐네"라고 읽거나, 오른쪽 열을 세로로 훑으며 "증거가 한 줄뿐이네"라고 읽거나. 나는 후자를 권한다. 부품은 여섯 개가 done이지만 증거는 loopback 하나뿐이다. loopback이란 같은 머신 안에서 자기 자신과 통신하는 테스트다. 네트워크 스택의 대부분을 우회하는 테스트로, 전송 로직의 올바름은 증명하지만 "그리드"의 실질 — 서로 다른 머신들이 조각을 나눠 받는 것 — 은 전혀 증명하지 못한다.

부품 목록을 다시 자세히 보면 Phase A의 성격이 더 잘 드러난다. manifest, CLI, QUIC piece 경로, resume, agentd, GUI — 전부 "받는다"라는 하나의 동사를 다른 방식으로 수행하는 부품들이다. manifest는 무엇을 받을지 정의하고, CLI는 명령으로 받고, QUIC 경로는 조각으로 받고, resume은 끊겨도 이어 받고, agentd는 사람 없이 받고, GUI는 눈에 보이게 받는다. Phase A의 스코프가 "기능 여러 개"가 아니라 "하나의 동사의 완성"이었다는 것이 이 표에서 읽힌다. 스코프가 좁아서 가능했던 집중이고, 그 집중이 95%를 만들었다.

즉 95%의 정체는 이렇다. 코어 로직은 완성됐고, 그 코어가 실제 세계에서 동작한다는 증거가 없다. 구현과 증명의 이 간극이 이 시리즈 전체에서 가장 반복되는 주제고, RC1 게이트가 존재하는 이유다.

loopback 증거의 가치와 한계

loopback 테스트를 깎아내리는 게 아니다. loopback이 있어서 가능한 것들이 있다. 조각 분할-재조립의 올바름, 해시 검증의 판정 정확성, resume의 상태 복원 — 이런 논리적 속성들은 네트워크 노이즈가 없는 환경에서 가장 깨끗하게 검증된다. 버그가 생겼을 때 네트워크 변수를 배제하고 로직만 볼 수 있는 환경은 디버깅 기반 시설이다.

한계도 명확하다. loopback은 시간이라는 변수가 없다. 실제 그리드에서 문제가 되는 것들 — 대역폭 경쟁, 지연 변동, 노드 이탈, 장시간 실행 — 은 전부 시간이 필요한 현상이다. 몇 초짜리 테스트가 통과하는 것과 몇 시간짜리 전송이 끝나는 것 사이에는 다른 세계가 있다. 그래서 증거 요건이 "테스트 통과"가 아니라 "20GB 실측"인 것이다. 20GB라는 숫자는 근거 없는 라운드 숫자가 아니라, "이 정도 크기면 스트리밍·스케줄링·검증의 모든 약점이 노출될 만큼 길다"는 기준으로 잡힌 선이다.

완료 선언 기준

Phase A가 "완료"가 되려면 두 가지가 더 필요하다. 이 둘은 기능이 아니라 증거다.

multi-host 20GB 실측 캡처
mTLS / 인증서 검증

"증거"라는 단어를 쓰는 이유는, 이 두 항목이 완료되면 무엇이 달라지는가를 보면 명확하다. 20GB 실측이 끝나면 Phase A의 품질 주장이 "우리가 잘 만들었다고 믿는다"에서 "측정 결과가 이렇다"로 바뀐다. mTLS가 끝나면 보안 주장이 "암호화를 쓴다"에서 "검증되지 않은 노드가 조각을 받을 수 없다"로 바뀐다. 믿음에서 증거로 — 완료 판정의 주체가 개발자에서 세계(측정·검증 장치)로 이동하는 것이 완료의 실질이다.

첫 번째가 성능 증거라면 두 번째는 신원 증거다. 20GB 실측이 답하는 질문은 "길고 무거운 전송이 여러 물리 머신 사이에서 안정적으로 끝나는가"다. loopback이 답하지 못하는 질문들 — 네트워크 지연이 스케줄러 판단을 흔들지 않는가, 머신 하나가 중도 이탈해도 그리드가 완주하는가, 몇 시간짜리 스트림이 자원을 유출하지 않는가 — 전부 여기서 검증된다.

mTLS가 답하는 질문은 다르다. "받는 노드와 주는 노드가 서로를 믿을 수 있는가." LAN이라는 환경은 "다 같은 사내망"이라는 신뢰를 암시하지만, 사내망 안의 모든 머신이 자격 있는 노드는 아니다. 테스트 머신, 방문자 노트북, 반입된 장비 — 그리드가 이들과 조각을 나눠서는 안 된다. 현재 구현은 연결 자체의 암호화는 갖췄지만(QUIC) 상대의 신원을 검증하지 않는다. RC1 원칙 3 "운영 환경에서 인증서 검증 우회를 허용하지 않는다"가 이 빈틈의 기준이다.

두 증거 중 어느 하나라도 없으면 Phase A는 "완료"가 아니라 "구현 완료"다. 이 구분이 말장난처럼 들리는가? 완료는 출시를 허락하는 단어고, 구현 완료는 그렇지 않다. 두 단어의 경계가 흐려지는 순간 아직 증명 안 된 제품이 사용자에게 간다.

남은 5%

작업	왜 남았나
multi-host 20GB	여러 물리 머신이 필요
mTLS	인증서 PKI 설계와 운영 결정
`grid-experimental` 기능의 기본 빌드 포함 여부	컴파일 시간/안정성 트레이드오프 (A-1)

표의 세 항목이 남은 이유는 전부 기술 난이도가 아니다. 첫째는 환경 — 실측하려면 물리 머신 여러 대와 시간이 필요하다. 둘째는 설계 영역 확장 — PKI는 전송 개발과 다른 전문성이다. 셋째는 판단 보류 — 실험 기능을 기본 빌드에 넣을지는 컴파일 시간과 안정성의 트레이드오프로, 성급하게 결정할 문제가 아니다.

세 번째 항목(grid-experimental 기본 빌드 포함 여부, A-1)은 겉보기에 사소해 보이지만 제품 철학의 시금석이다. 실험 기능을 기본 빌드에 넣으면 접근성이 높아지는 대신 "기본 경험"이 불안정해진다. 빼면 안정적이지만 실험이 적어진다. 이 판단을 지금 미루는 것은 무결점이 아니라, "무엇이 기본값인가"는 증거(안정성 데이터)가 정해야 한다는 원칙의 적용이다. A-1 같은 판단 보류 항목이 목록에 명시돼 있는 것 자체가 — 잊혀진 게 아니라 대기 중임을 — 이 단계의 기록이 정직하다는 증거다.

즉 95%에서 100%로 가는 길에 남은 코드 작업이 없다. 남은 건 환경 구성, 별도 영역의 설계, 그리고 판단이다. 이런 완료 단계의 특징은 진행 속도가 코딩 속도가 아니라 준비 속도에 묶인다는 것이다. 물리 머신을 준비하고, 실측 절차를 설계하고, PKI 정책을 정하는 일은 코딩 세션으로 압축되지 않는다. 개발자가 아무리 빨리도 이 5%는 줄지 않는다 — 준비의 일정을 쥐고 있는 건 코드가 아니라 물리 세계다.

이 편의 95%가 시리즈에서 하는 역할

S2의 앞선 편들이 부품 이야기였다면 이 편은 재고 조사다. 재고 조사가 중요한 이유는 다음 단계로 넘어가기 전에 "무엇이 있는가"와 "무엇이 없는가"의 경계를 명확히 해야 하기 때문이다. 이 경계가 흐려지면 다음 단계(Control MVP, 컴퓨트 그리드)의 논의가 "아직 Phase A가 남았잖아"와 "Phase A는 거의 됐잖아" 사이의 감정 논쟁으로 흐른다. 부품 표와 증거 현황이 있으면 대화는 사실 기준으로 고정된다. 구현은 다 됐다. 증명이 남았다. 그러니 다음은 코딩이 아니라 실측이다.

재고 조사의 또 하나의 산출물은 리스크 지도다. 증거가 없는 부분이 곧 리스크가 있는 부분이다. 지금 시점의 최대 리스크는 "loopback에서 잘 되던 것이 multi-host에서 안 될 가능성"이다. 이 리스크가 실제로 터진다면 어디서 고쳐야 하나 — 스케줄러일 수도, Have 타이밍일 수도, resume 상태일 수도 있다. 실측을 앞두고 이 가설 목록을 미리 적어두는 것이, 실측이 실패했을 때의 디버깅 출발점이 된다.

마지막으로 이 95%가 앞의 편들과 어떻게 맞물리는지 짚고 넘어가자. CLI-first 편의 계약 문서, QUIC 편의 전환 커밋들, zip 편의 스트리밍 원칙, 스케줄러 편의 Have-race 조합 — 이 편의 부품 표는 그 모든 결정이 만든 결과물의 목록이다. 반대로 읽으면, 이 5%의 증거 작업이 실패한다면 어떤 편의 결정이 기각 대상이 될지도 이미 좁혀져 있다. 재고 조사란 과거 결정들의 성적표를 미래 결정의 입력으로 바꿔놓는 작업이다.

다음 편부터는 잠시 데스크톱을 떠나 브라우저 세계 — ponswarp-grid 레포의 그리드 엔진 — 로 넘어간다.