[WarpInfra] RC1 — 20GB·다중 머신·SHA-256 없으면 출시가 아니다
제품이 "완료됐다"고 말하는 순간은 기능이 끝났을 때가 아니라 증거가 갖춰졌을 때다. 이 문장이 말로는 아무도 반대하지 않는다. 그런데 실제 개발 현장에서 완료 선언은 거의 늘 기능 완료 시점에 나온다. 이유는 간단하다 — "증거가 갖춰졌다"의 기준을 아무도 미리 적어두지 않았기 때문이다. 완료가 감각의 영역에 있으면, 감각이 "됐다"고 하는 순간 완료다. 그리고 감각은 데모가 잘 도는 날에 가장 낙관적이다. WarpInfra의 RC1 문서는 이 기준을 게이트로 미리 박아두었다. 이 편은 그 게이트 다섯 개와 현재 통과 상태를 대조하고, 게이트가 프로젝트에 실제로 무엇을 해줬는지 본다.
이 편이 시리즈에서 하는 역할도 미리 밝혀둔다. S1~S3이 각각의 결정과 구현을 세로로 읽었다면, 이 편은 전체를 가로로 내려다보며 "지금 어디쯤인가"를 측정한다. 세로 읽기의 각 편이 남긴 원칙들 — 플레인 분리, 해시 판정, 컴퓨트 보류 — 이 이 편에서는 게이트 번호로 재등장한다. 같은 문장이 설계 편에서는 원칙이고 검증 편에서는 게이트다. 그리고 게이트는 원칙과 달리 통과/미달이 재판받는다.
RC1 게이트 (문서 원문 원칙)
| # | 원칙 |
|---|---|
| 1 | 파일 payload는 Control이 아닌 Node 간 P2P로 이동한다 |
| 2 | 최종 성공은 UI 표시가 아니라 SHA-256 무결성으로 판정한다 |
| 3 | 운영 환경에서 인증서 검증 우회를 허용하지 않는다 |
| 4 | 20GB 실제 다중 머신 전송 증거가 없으면 RC1로 판정하지 않는다 |
| 5 | 데이터 그리드 안정화 전 컴퓨트 그리드를 구현하지 않는다 |
게이트 표를 처음 본 사람이 가장 먼저 묻는 질문은 "왜 이 다섯 개인가"다. 답은 이 게이트들이 각각 다른 실패 양상을 막는다는 데 있다. 원칙 1은 "편해서 중앙 경유로 바꾸는" 실패를, 원칙 2는 "화면이 그러니 됐다"는 실패를, 원칙 3은 "LAN이니까 괜찮다"는 실패를, 원칙 4는 "로컬 테스트니까 충분하다"는 실패를, 원칙 5는 "전송 됐으니 연산도 되겠지"라는 실패를 막는다. 다섯 문장은 다섯 종류의 합리적 변명 각각에 대한 사전 기각이다.
다섯 게이트의 성격이 각각 다르다는 걸 먼저 보자. 원칙 1과 5는 설계 경계다 — 아키텍처와 로드맵의 선을 긋는다. 원칙 2는 판정 기준이다 — 성공의 정의를 UI가 아니라 수학에 둔다. 원칙 3은 보안 하한선이다 — 협상 불가능한 최소선이다. 원칙 4는 증거 요건이다 — 유일하게 "숫자"가 들어간 게이트다. 다섯 개가 서로 다른 종류의 문장이라서, 하나만 무너져도 다른 넷이 남아 프로젝트의 방향을 지킬 수 있다.
원칙 2를 조금 더 볼 만하다. "UI 표시가 아니라 SHA-256 무결성으로 판정한다"는 문장은 성공의 권위를 사용자 인터페이스에서 데이터로 옮긴 것이다. 전송 완료 화면이 나왔는데 조각 하나가 깨졌다면 — 그 전송은 실패다. UI는 성공을 "보여주는" 존재일 뿐 성공을 "판정하는" 존재가 아니다. 이 원칙이 없으면 UI와 실제 상태의 불일치가 철학적 문제가 아니라 제품 결함이 된다. S2에서 봤던 이벤트 주도 상태 전이(9253ddb)와 같은 계열의 규율인데, 여기서는 프로토콜 전체의 완료 판정으로 확대됐다.
현재 통과 상태 (2026-07-18 스냅샷)
| 항목 | 상태 |
|---|---|
| Phase A 구현 | ~95% (CLI·QUIC multi-peer·resume·agentd·GUI RELEASE) |
| 전체 비전 (A+B+C) | ~40% |
| 원칙 4 (20GB 실측) | 미달 — multi-host 캡처 필요 |
| 원칙 3 (mTLS) | 미달 — 인증서/PKI 미확정 |
표를 읽는 순서도 정해두면 좋다. 먼저 미달 행부터 읽고, 다음으로 미달이 왜 미달인지 물어보고, 마지막으로 통과 행을 읽는다. 반대로 읽으면(통과부터) 마음이 편해지지만 판단이 둔해진다 — "다 통과했네"라는 인상이 미달 두 개의 무게를 흡수하기 때문이다. 게이트 표의 목적이 안심이 아니라 경계라면, 읽는 순서도 경계부터가 맞다.
이 표가 이 시리즈의 "솔직함"을 대표한다. 구현이 95%여도 게이트 2개가 닫히지 않았으므로 RC1은 아니다. 원칙 1, 2, 5는 통과 상태다 — payload는 피어 경로로만 흐르고, 성공 판정은 해시로 하며, 컴퓨트 그리드는 아직 손대지 않았다. 즉 "설계는 다 지켰고, 증명 두 개가 남았다"가 현재 위치의 정확한 표현이다.
미달 항목 두 개의 성격이 다르다는 점도 기록할 가치가 있다. 원칙 4는 시간과 환경 문제다 — 머신을 준비하면 할 수 있다. 원칙 3은 설계 문제다 — PKI 체계를 정해야 한다. 후자가 더 어렵다. 환경은 준비하면 되지만 설계는 결정이고, 결정은 한번 내리면 바꾸기 어렵다. 인증서를 누가 발급하고, 어떻게 배포하고, 만료 교체는 어떻게 하는가 — 이 질문들에 답하는 동안 전송 개발은 계속 진행된다. 그래서 mTLS가 "남은 5%"의 핵심 난이도인 것이다.
원칙 4의 "20GB"라는 숫자가 어떻게 게이트가 되었는지도 살펴볼 만하다. 숫자가 없는 게이트는 약하다. "충분히 큰 파일을 여러 머신에서 전송해본다"는 원칙은 "해봤다"고 말하기 나름이다. 20GB라는 구체적 숫자는 판정을 기계적으로 만든다 — 20GB를 옮겼고 로그가 있으면 통과, 없으면 미달. 숫자가 들어가는 순간 완료 판정에서 주관이 퇴출된다. 어떤 숫자든 없는 것보다 나은데, 숫자의 존재 자체가 판정의 주체를 사람에서 증거로 이전하기 때문이다. 20이 정확히 옳은 숫자인지보다, 숫자가 있느냐 없느냐가 더 중요하다.
게이트가 남긴 효과
게이트 덕분에 로드맵의 우선순위가 흔들리지 않았다. "20GB 실측 없이 다음 단계"라는 유혹이 생길 때마다 원칙 4가 기준을 다시 세운다. 이 유혹의 실제 형태를 구체화하면 이렇다. 데모는 잘 돈다. 로컬 테스트는 통과한다. "일단 써보라"고 할 사람이 주변에 생긴다. 게이트가 없으면 이 시점에서 "사실상 출시"가 일어난다 — 공식 출시가 아니라 조용한 확산으로. 게이트가 있으면 같은 순간에 답이 정해져 있다. 증거가 없으니 RC1이 아니다.
게이트의 두 번째 효과는 정신력 절약이다. 완료 판정 기준이 문서에 있으면 "이 정도면 됐나"라는 질문을 매번 다시 하지 않는다. 판단의 반복은 의지력을 소모하고, 소모된 의지력은 품질 훼손으로 회수된다. 기준을 한 번 문장으로 박아두면 판단이 자동화된다.
세 번째 효과는 외부와의 대화다. "언제 끝나요"라는 질문에 게이트 있는 프로젝트는 "게이트 두 개가 남았다"로 답한다. 게이트 없는 프로젝트는 "거의 다 됐다"로 답한다 — 그리고 그 답은 몇 달이 지나도 반복된다. 게이트는 외부에 주는 약속을 만기일이 아니라 조건으로 표현하게 해준다. 조건은 달성되거나 안 되거나 둘 중 하나지만, "거의"는 계속 "거의"일 수 있다.
네 번째 효과는 미래의 자신에 대한 기록이다. 게이트와 점수가 함께 기록돼 있으면, 시간이 지난 뒤 "당시 판단이 맞았는가"를 검증할 수 있다. 95%로 멈춘 시점의 게이트 상태와, 실측이 끝난 뒤의 게이트 상태를 나란히 놓으면 프로젝트의 예측 능력 자체가 평가된다. 게이트 없는 프로젝트의 회고는 "어려웠다/잘됐다"의 감상으로 끝나지만, 게이트 있는 프로젝트의 회고는 "어떤 게이트가 예상대로 닫혔고 어떤 게이트가 예상보다 오래 열려 있었나"의 분석으로 끝난다.
게이트가 안 해주는 것
공정하게 대가도 적는다. 게이트는 속도를 늦춘다. 20GB 실측이 끝날 때까지 RC1이라는 이름을 쓸 수 없으니, 외부에 "우리 제품 완성됐다"는 발표도 미뤄진다. 게이트가 없는 프로젝트라면 그 사이에 얻었을 사용자 피드백이 늦어진다. 또한 게이트는 유연성과 트레이드오프다 — 원칙 4의 20GB라는 숫자가 실측 후 "너무 컸다/작았다"가 판명될 수도 있다. 게이트는 이런 조정 가능성을 자발적으로 포기하는 대신, 판정의 일관성을 산다.
대가의 또 다른 얼굴은 게이트가 팀원 개개인의 동기와 마주하는 지점이다. 코드가 다 돌아가는 상태에서 "아직 증거가 없다"는 선언은 구현자에게 상냥하지 않은 말이다. 몇 주간의 노력이 "증명 대기 상태"로 분류되는 셈이니까. 게이트가 이 간극을 메우는 방법은 완료의 정의를 두 단계로 나누는 것이다 — "구현 완료"는 인정하되 "RC1"은 보류한다. Phase A 부품 표(앞 편)의 done 표기가 그 역할이다. 부품은 done이고 제품은 미완. 두 문장이 공존하지 않으면 게이트는 팀의 사기를 잡아먹는 장치가 된다.
그리고 게이트는 프로젝트 내부의 창조적 압력도 조금 잠식한다. "컴퓨트 그리드 아이디어"처럼 게이트 5에 막힌 영역의 아이디어는 기록만 쌓이고 검증 기회가 없다. 게이트가 아이디어를 보호하냐 억압하냐는 관점에 따라 갈리는데, 이 시리즈의 입장은 명확하다 — 데이터 그리드의 증거가 그 아이디어들의 성배(검증 기반)를 제공할 때까지 기다리는 것이 서로에게 낫다.
이 편은 시리즈에서 유일하게 점수와 게이트를 숫자로 보여준다. 숫자가 공개되면 그 숫자는 나중에 재판받는다 — 95%가 정확했는지, 40%가 보수적이었는지. 그 재판을 감수하고 숫자를 남기는 것이 이 시리즈의 태도다. 다음 마지막 편에서 이 게이트 뒤의 백로그를 Now/Next/Later로 정리하며 시리즈를 닫는다.