SERIESWarpInfra Data Grid

[WarpInfra] 컴퓨트 그리드를 일부러 뒤로 미룬 로드맵

Aug 7, 2026·4 min read·168 views

WarpInfraPonsWarpDataGrid개발회고로드맵

"그리드"라는 단어를 들으면 대부분 분산 연산(compute grid)을 떠올린다. 노드 여러 대가 계산을 나눠 하는 그림이다. 세계적으로 유명한 그리드 프로젝트들 — SETI@home부터 과학 컴퓨팅 그리드까지 — 의 이미지가 워낙 강력해서, "그리드"하면 계산이 먼저 온다. WarpInfra의 로드맵 문서를 처음 열 때 가장 의아했던 결정이 바로 여기에 있다. 분산 전송(데이터 그리드)을 먼저 끝내고, 분산 연산(컴퓨트 그리드)은 데이터 그리드가 안정화된 뒤에만 설계하도록 순서를 고정한 것이다. 계산이 더 화려한 기능인데 전송이 먼저라니, 처음엔 순서가 거꾸로 된 것 같았다. 이 편은 그 순서를 왜 거꾸로 두지 않았는지에 대한 기록이다.

컴퓨트는 데이터의 후발 주자다

순서를 뒤집어 생각해 보면 답이 나온다. 컴퓨트 그리드의 모든 연산은 결국 데이터를 필요로 한다. 어떤 노드가 연산을 맡든, 그 노드는 연산 대상 데이터를 먼저 받아야 한다. 데이터 이동이 불안정하면 — 조각이 깨지거나, 재개가 안 되거나, 무결성 검증이 없으면 — 그 위에서 도는 어떤 연산도 결과를 신뢰할 수 없다. 연산 결과가 틀렸을 때 원인이 코드인지 데이터인지 알 수 없는 상태가 된다. 디버깅 불가능한 분산 시스템보다 나쁜 건 없다.

반대로 데이터 전송이 검증되면 이야기가 달라진다. 컴퓨트는 "조각을 나눠 받는" 이미 검증된 경로 위에 얹을 수 있다. 데이터 도착 보장, 무결성 판정, 재개 — 이 세 가지가 이미 동작한다면 연산 노드는 자기 로직에만 집중하면 된다. 즉 데이터 그리드는 컴퓨트 그리드의 의존성이지, 경쟁 기능이 아니다. 의존성을 나중에 만들고 싶은 기능보다 먼저 만드는 건 로드맵의 기본 문법이다. 이 순서가 특별한 게 아니라, "그리드"라는 단어의 이미지 때문에 이 순서를 지키기가 오히려 어려운 것뿐이다.

RC1 문서에는 이 원칙이 작업 지시서 수준으로 고정돼 있다.

"데이터 그리드가 안정화되기 전 컴퓨테이셔널 그리드를 구현하지 않는다."

"보류"가 아니라 "구현하지 않는다"로 쓴 점에 주목할 필요가 있다. 로드맵에서 미룬다는 표현은 언제든 깨질 수 있는 약속이다. 여유가 생기거나, 데모 기회가 오거나, "일찍 만들어 두면 좋지 않겠냐"는 제안이 들어오면 미뤄둔 것은 꺼내진다. 부정문으로 박아두면 그 제안이 들어왔을 때 판정 기준이 된다. 안정화의 정의도 명확해야 한다 — 그 정의가 RC1 게이트(20GB multi-host 실측)라는 점이 이 시스템이 정교한 부분이다. "안정화됐다"는 느낌이 아니라 증거가 안정화의 판정 기준이다.

로드맵 구조

이 순서 원칙이 실제 로드맵에 반영된 모습이다.

text
Phase A — LAN Grid MVP (앱만, Control 최소)     [~95%]
  CLI · QUIC multi-peer · resume · agentd · GUI RELEASE
Phase B — 온프레 Control MVP                    [미착수]
  카탈로그 · 토큰 · mTLS · 정책
Phase C — 상용/멀티호스트                        [미착수]
  20GB 실측 · multi Release Agent · 관측성

2026-07-18 기준 상태 스냅샷은 **Phase A 약 95%, 전체 비전(A+B+C) 약 40%**이다. 이 숫자들은 시리즈 후반 RC1 편에서 게이트와 함께 다시 대조한다. 지금 눈여겨볼 것은 Phase 배치의 논리다. Phase A는 "앱만" — Control 없이 애플리케이션 계층만으로 그리드가 성립하는지를 본다. Phase B는 제어면을 채운다. Phase C는 검증과 운영이다. 컴퓨트 그리드는 이 세 단계 어디에도 없다. Later로도 쓰이지 않고, 별도 영역으로 완전히 밖으로 뺐다.

Phase 순서에도 이유가 있다. Control(Phase B)을 앱보다 먼저 만들지 않은 이유는, 제어면의 정책 기능은 "그리드가 실제로 동작하는 모습"이 있어야 무엇을 통제할지 알 수 있기 때문이다. 정책 없는 Phase A는 사실 정책이 전부 "모두 허용"인 세계다. 그 세계에서 전송이 성립하는 것을 먼저 확인하고, 나중에 정책을 씌우는 방향이 설계 리스크가 낮다. 반대로 정책 프레임을 먼저 만들면 실제 전송 패턴과 안 맞는 정책이 되기 쉽다.

완료 판정 기준이 설계에 박혀 있다

로드맵에서 내가 가장 가치 있다고 본 부분은 Phase 배치가 아니라 완료 판정 기준이 문서에 박혀 있다는 점이다. Phase A에서 "남은 5%"는 명확하다. multi-host 20GB 실측, mTLS. 이 둘이 없으면 Phase A를 완료로 부르지 않는다.

이 기준이 없으면 어떻게 되는지 상상해 볼 수 있다. 구현은 다 됐고, 로컬 테스트는 돌고, 데모는 잘 나온다. 누군가는 "이 정도면 출시하고 운영하면서 고치자"고 말한다. 로드맵에 완료 기준이 없으면 그 제안을 기각할 근거가 없다 — 기각이 아니라 시간 싸움이 되고, 바쁜 스프린트는 보통 시간 싸움에서 진다. 기준이 있으면 대답은 한 줄이다. "20GB multi-host 실측 증거가 아직 없다." 완료 선언의 주체가 개발자의 자신감이 아니라 증거가 된다. 이 원칙은 RC1 문서의 "20GB 실제 다중 머신 전송 증거가 없으면 RC1로 판정하지 않는다"와 같은 계열의, 문장 하나로 프로젝트의 부패 속도를 늦추는 장치다.

퍼센트 숫자를 읽는 주의점

"Phase A ~95%, 전체 비전 ~40%"라는 숫자가 로드맵 편에 등장하는데, 이 숫자들을 어떻게 읽어야 하는지 따로 정리해 둘 가치가 있다.

첫째, 이 퍼센트는 시간이 아니라 작업 항목 기준의 근사치다. Phase A의 작업 목록(CLI, QUIC multi-peer, resume, agentd, GUI RELEASE, loopback 증거) 중 완료된 항목의 비중에 가깝고, "95%의 시간이 지났다"는 뜻이 아니다. 작업 항목 기준 근사치의 맹점은 항목별 무게가 다르다는 것이다. 남은 5%가 사실 가장 무거운 5%일 수 있다 — 실제로 그렇다. multi-host 20GB 실측은 여러 물리 머신과 환경 구성이 필요하고, mTLS는 PKI 설계라는 별도의 전문 영역이다. 남은 항목 수가 적다고 남은 일이 가벼운 건 아니다.

둘째, 40%라는 전체 비전 숫자는 Phase B와 C가 미착수라는 사실의 다른 표현이다. 이 숫자의 용도는 진행 상황 보고가 아니라 "아직 초반"임을 스스로에게 상기시키는 장치다. Phase A가 95%에 가까워지면 심리적으로 제품이 거의 끝났다고 느껴지는데, 전체로 보면 절반도 안 왔다. 두 숫자를 나란히 놓는 이유가 바로 이 심리 보정이다.

셋째, 이 숫자들에는 유효기간이 있다. 2026-07-18 기준 스냅샷이지, 이 글을 읽는 시점의 상태가 아니다. 스냅샷의 기준일을 글에 명시하는 관습은 이런 이유다 — 낡은 숫자가 최신 상태로 둔갑하는 것을 막는다.

로드맵 문서와 커밋의 관계

로드맵 문서가 있으면 문서대로 되는 것 같지만 실제로는 문서와 코드는 다른 속도로 흘러간다. 코드는 매일 바뀌고 문서는 잊혀진다. 그래서 이 시리즈에서는 로드맵 문서의 각 항목이 커밋으로 이행됐는지를 대조하는 방식으로 진행한다. Phase A의 부품 목록(CLI, manifest, QUIC multi-peer, resume, agentd, GUI)이 S2~S3 편에서 커밋 해시와 하나씩 대응되는 걸 확인할 수 있다.

문서가 커밋을 이끄는 방향으로 작동한 대표 사례가 "구현하지 않는다" 문장이다. 이 문장이 없었다면 컴퓨트 그리드의 시제품이 어느 시점에는 만들어졌을 가능성이 높다. 시제품이 만들어졌다면 데이터 경로가 불안정한 상태에서 연산 실패가 섞인 디버깅 지옥이 시작됐을 것이다. 문장 하나가 프로젝트의 미래 사고 하나를 막은 셈인데, 이런 문장이 문서에 남아 있는지 없는지가 프로젝트 문서의 가치를 결정한다. 읽기 좋은 문서가 아니라, 미래의 나를 대신해 거절을 해주는 문서가 필요한 것이다.

이 순서 고정의 부작용

물론 이 원칙에도 비용이 있다. 첫째, 컴퓨트 그리드에 대한 기대가 있는 환경에서는 "전송만 되는 그리드"가 지루하게 느껴질 수 있다. 둘째, 데이터 그리드가 안정화될 때까지 컴퓨트 관련 아이디어를 전부 기록만 해두고 손대지 않는 규율이 필요하다. 셋째 — 이게 실무에서 가장 자주 충돌하는 지점인데 — 컴퓨트 기능을 미리 만들어두면 "데이터 그리드가 그 위에서 검증된다"는 식의 논리가 나온다. 겉보기엔 그럴듯하지만, 미완성 데이터 경로 위에서 연산을 돌리면 실패의 원인 분리가 안 된다는 게 이 편의 첫 섹션에서 본 이유다.

비용에는 현금성 비용도 있다. 컴퓨트 기능이 "나중"에 묶여 있으면, 컴퓨트를 원하는 잠재 사용자와의 대화에서 제품의 어필 포인트가 절반으로 줄어든다. 전송만으로 어필해야 하니, 전송이 실제로 잘 되는 증거가 곧 마케팅 그 자체가 된다. 이 압박이 나쁘지만은 않다 — 증거 없는 기능 나열 대신 증거를 만들게 강제하니까. RC1 게이트와 컴퓨트 보류는 결국 같은 철학의 두 얼굴이다. "말 대신 증거"로 프로젝트를 운영하겠다는 것.

지금까지의 판단은 이렇다 — 아이디어는 백로그에 쌓아두고, 데이터 전송의 증거(20GB multi-host)가 그것을 꺼낼 자격을 주면 그때 설계를 연다. 자격 증명이 아이디어의 품질이 아니라 하위 계층의 증거라는 점이 이 로드맵의 특징이다. 다음 편에서는 이 로드맵을 실제로 수행할 "운영자"가 누구인지 — 사람이 아니라 CLI와 AI 에이전트라는 전제 — 를 다룬다.