Cloudflare Void 분석: 사내 앱 배포를 열면 누가 운영을 맡을까

재고표를 앱으로 바꾼 다음에 생기는 일

운영팀이 스프레드시트로 관리하던 비품 재고를 작은 웹 앱으로 옮긴다고 하자. 코딩 에이전트가 품목 목록, 입출고 입력, 부족 재고 알림까지 만들었다. 개발 PC에서는 동작한다. 이제 동료에게 주소를 보내려면 서버 실행, 데이터베이스, 로그인, 배포와 오류 확인이 필요하다. 앱 제작이 쉬워질수록 이 뒷부분을 누가 맡을지가 더 자주 문제가 된다.

Cloudflare가 10월 15일 공개한 Void는 이 배포 경로를 Vite 개발 흐름과 연결하는 도구 묶음이다. SDK는 앱의 서버·클라이언트와 자원 API를, CLI는 빌드·자원 준비·배포를, Platform은 팀의 공유 배포 환경을 담당한다. 직원 모두에게 클라우드 관리 권한을 주지 않고 앱을 배포하게 하려는 것이 발표의 주요 목적이다. 공식 발표

이 글은 사내 재고 앱을 가정해 도입 구조를 분석한다. 예시는 설명을 위해 만든 것이며, Void를 설치하거나 실제 앱·DB를 배포한 결과가 아니다. 구현 기준은 10월 20일 확인한 공식 저장소 커밋 f53f2b7fc6138c49872c037df41c5194cc991977이다. 해당 커밋의 패키지 버전은 1.1.12, Node 요구 조건은 24.21.0 이상이다. 설치할 때는 자신의 버전과 문서를 다시 대조해야 한다. 고정 package.json

SDK·CLI·Platform을 도입하는 이유는 서로 다르다

SDK의 역할은 앱이 사용하는 자원을 개발 코드와 연결하는 것이다. 발표의 void/db 예에서는 로컬 개발용 DB를 제공하고 배포 시 D1을 준비한다. CLI의 void deploy는 빌드, 자원 준비, SQL 마이그레이션, 배포를 묶는다. Platform은 그 앱을 팀의 Cloudflare 계정에서 운영하도록 사용자와 프로젝트를 관리한다. SDK 설명 · 배포 문서

따라서 Void를 사용한다는 이유만으로 공유 플랫폼부터 설치할 필요는 없다. 담당 개발자 한 사람이 자신의 Cloudflare 계정으로 앱을 운영한다면 직접 배포 경로가 있다. 팀 공통 로그인, 프로젝트 역할, 남겨 둔 배포 기록과 로그가 필요해질 때 Platform을 검토할 이유가 생긴다.

선택	줄이려는 반복 작업	팀이 맡을 운영
자기 Cloudflare 계정에 직접 배포	앱별 빌드·자원 준비·배포	해당 계정과 앱의 운영
공용 Void Platform 설치	여러 제작자의 가입·프로젝트 접근·배포 경로	플랫폼 로그인·한도·업데이트·장애 대응과 각 앱의 소유권
기존 사내 배포 체계 유지	이미 해결한 인증·CI·운영을 재사용	Void가 줄일 추가 비용이 있는지 작은 앱으로 비교

이 표는 도입 판단을 위한 편집 분석이다. 이미 서비스 템플릿과 팀 권한을 잘 관리하는 조직에서는 새 플랫폼이 운영 대상을 늘릴 수도 있다. 반대로 앱 제작자가 늘고 담당 개발자가 매번 배포를 대행한다면 반복을 옮겨 맡길 가치가 크다.

공유 플랫폼의 설치 비용도 알아야 한다. 고정 문서는 Workers for Platforms, R2, Analytics Engine과 별도 PostgreSQL을 요구한다. PostgreSQL에는 플랫폼의 사용자·프로젝트·배포 정보가 저장되고, 개별 앱은 D1을 쓸 수 있다. Void는 PostgreSQL 서버 자체를 만들어 주지 않는다. 플랫폼 DB와 재고 앱 DB는 다른 역할이다. Workers for Platforms는 유료이며 DB와 Cloudflare 사용료는 따로 발생한다. 여기서는 가격 견적이나 절감액을 계산하지 않았다. 설치 전제

기능 목록도 설치 범위별로 읽어야 한다. core 설치는 CLI 배포와 자원 API를 제공하지만 사용자 대시보드, 관리형 GitHub 빌드, 앱별 사용자 지정 도메인은 기본 구성에 포함되지 않는다. 관리자 UI와 일반 사용자의 대시보드는 같은 것이 아니다. “GitHub에 push하면 자동 배포되는 사내 포털”이 목표라면 선택한 설치에 그 기능이 포함되는지 따로 확인해야 한다. 설치 형태별 비교

재고 앱에는 세 종류의 권한이 필요하다

아래 그림은 제품 화면이 아닌 설명용 설계다. 위에서 아래로 통과한다고 모든 업무 권한을 얻는 구조가 아니다. 각 단계의 판단 주체가 다르다는 점을 보여 준다.

첫째는 플랫폼에 가입할 권한이다. 사내 로그인이나 명시적 초대 등으로 들어올 사람을 정한다. Void 문서는 가입 허용 목록에서 항목을 지워도 이미 존재하는 계정이 정지되는 것은 아니라고 구분한다. “다음 가입을 막았다”와 “현재 사용자의 접근을 회수했다”를 같은 완료 상태로 기록하면 인계에서 빠지는 일이 생긴다. 가입과 접근

둘째는 프로젝트를 변경할 권한이다. 현재 문서의 역할은 다음과 같다.

역할	주요 권한	재고 앱에서 배정할 때의 질문
Reader	프로젝트·사용량·자원·배포·로그·구성원 조회	운영 로그에 노출되는 자료까지 읽어도 되는가?
Collaborator	Reader 권한에 배포·롤백·마이그레이션·비밀 설정 등을 추가	UI 수정 담당자가 운영 DB 구조와 연결 설정도 바꿔도 되는가?
Project administrator	구성원·역할·도메인 등 프로젝트 관리 추가	다른 제작자를 초대하고 변경 권한을 줄 책임이 있는가?
Owner	프로젝트 관리와 삭제, CI 배포 자격증명 관리	한도와 인계 책임을 계속 맡을 사람인가?

프로젝트 초대는 같은 플랫폼에 등록된 계정을 대상으로 한다. 초대 자체가 플랫폼 계정을 만들거나 가입 허용 목록에 추가하지는 않는다. 또 프로젝트 관리자가 설치 전체의 관리자가 되는 것도 아니다. 역할·초대 계약

셋째는 앱 안에서 재고를 읽고 바꿀 권한이다. 물류 담당자에게 입출고 화면을 열어 주려는 목적이라면, 제작자용 Collaborator 역할을 줄 이유는 없다. 앱의 사용자 로그인과 창고별 접근 규칙을 별도로 설계해야 한다. 예를 들어 서울 창고 담당자가 부산 창고의 수량을 수정하지 못하도록 실제 변경 요청에서 검사한다. 이것은 재고 업무를 위한 설계 제안이지 Void가 자동 생성해 준다고 확인한 기능이 아니다.

독자는 이 구분을 다른 사내 앱에도 적용할 수 있다. “누가 사용하나”와 “누가 코드를 바꾸나”를 한 사용자 목록으로 합치기 전에, 각 사람에게 필요한 행동부터 적어 보자. API 호출의 형식과 업무 권한을 나누는 원리는 MCP와 업무 API의 책임과도 연결된다.

자원 한도는 프로젝트 개수보다 소유자를 먼저 본다

재고 앱과 사내 설문 앱을 같은 담당자가 소유한다고 가정하자. 편집 예시로 월 요청 한도를 10만 건으로 정하고 재고 앱에서 7만 건, 설문 앱에서 4만 건을 사용했다면 합계는 11만 건이다. 앱별로 10만 건보다 작다는 사실만으로 소유자 계정의 한도 안이라고 판단할 수 없다. 이 숫자는 실제 기본값이나 측정값이 아닌 합산 단위를 설명하는 가정이다.

Void 문서상 프로젝트에는 소유자의 플랜·한도·정지 상태가 적용된다. Collaborator의 플랜이 더 커도 프로젝트 한도를 늘리거나 소유자 정지를 우회하지 않는다. 플랜의 requestsPerMonth는 계정의 청구 월 단위이며, 플랜을 바꿔도 사용 기록과 기간이 초기화되지는 않는다. 소유자와 프로젝트 · 한도 정의

플랜 이름은 Cloudflare 상품 구매나 사용자 청구를 뜻하지 않는다. 관리자가 정하는 사용 정책이다. 0은 플랜에서 제한하지 않는다는 의미이며, 빌드 시간에는 별도의 최대 60분이 있다. 특히 D1·R2·KV 저장량은 정보로 표시되지만 강제 저장 할당량으로 편집할 수 없다. 저장량을 보고 있다는 사실과 저장 증가를 차단한다는 사실을 구분해야 한다.

재고 앱에서는 요청 횟수 외에 사진 첨부와 보관 기간을 따로 적는 편이 낫다. “요청 한도 통과”만으로 오래 쌓이는 첨부파일 비용까지 관리된다고 볼 수 없기 때문이다. 다음과 같은 운영 메모를 제안한다.

소유자: 재고 앱의 배포와 인계를 책임지는 담당자
공유 사용량: 같은 소유자의 다른 앱까지 포함
강제 한도: 실제 플랜에서 설정한 요청·CPU·배포 항목
별도 관측: 첨부 저장량, 외부 DB, 보관 기간
초과 시 행동: 확인할 담당자와 앱별 중단·재개 기준

이 양식은 예산 운영을 돕는 기록이며 자동 비용 차단 도구가 아니다. 앱이 요청·CPU 한도를 넘을 때 API와 Pages action 요청에 구조화된 HTTP 429를 반환하고, 브라우저 요청에는 오류 페이지를 제공한다는 동작은 배포 문서에서 확인했다. 이미 시작된 스트림은 오류 페이지로 바꿀 수 없다는 조건도 있다. 따라서 앱에는 저장 완료 여부를 다시 확인할 경로가 필요하다. 한도 초과 응답

제작자가 떠나도 앱과 데이터는 남는다

사내 앱의 어려운 순간은 첫 배포보다 담당자가 바뀔 때다. 기존 소유자가 떠나면 다른 사람을 팀에 초대하는 것만으로 소유권 인계가 끝나지 않는다. 고정 문서에서는 설치 관리자만 소유자를 바꿀 수 있고, 새 소유자는 같은 플랫폼에 계정이 있어야 한다. 이전 소유자는 프로젝트 관리자가 되며, 기존 프로젝트 CI 배포 자격증명은 폐기되어 새 소유자가 대체해야 한다. 이전 사용량과 이후 사용량의 귀속도 나뉜다. 소유권 이전

따라서 퇴사 인계의 완료 조건에는 소유권 이전, 이전 담당자의 남은 역할, CI 재설정, 실제 배포 결과를 따로 적어야 한다. 소유권 이전만 한 상태에서는 이전 담당자가 아직 프로젝트 관리자로 남을 수 있다.

구성원 회수에도 시간이 걸리는 부분이 있다. Collaborator나 관리자를 제거하거나 Reader로 바꾸면 프로젝트 Worker가 플랫폼 서비스를 호출할 때 쓰는 자격증명을 교체한다. 문서는 교체가 끝나기 전까지 기존 자격증명이 동작할 수 있고, 실패 시 상태 경고를 확인하라고 설명한다. 이미 배포한 코드는 구성원 삭제만으로 사라지지 않는다. 신뢰할 수 없는 코드가 남았다면 신뢰하는 버전의 재배포를 별도로 판단해야 한다. 회수 과정과 남는 코드

여기에 코딩 서비스 같은 외부 앱을 연결하는 경우도 구분할 필요가 있다. Void의 Connected apps 문서는 로그인 동의만으로 프로젝트 관리 권한을 주지 않고, 게시할 산출물의 정보와 digest를 보여 준 뒤 개별 승인을 받는 흐름을 정의한다. 연결을 해제해도 이미 게시된 앱이 제거되지는 않는다. 이는 해당 OAuth 연결 경로의 계약이며, 일반 CLI 배포가 매번 같은 게시 승인 화면을 거친다는 뜻은 아니다. Connected apps

롤백 버튼 하나로 재고를 과거로 돌리면 안 되는 이유

가상 변경을 하나 보자. 오전에는 재고 수량을 정수로 저장했는데 오후 버전부터 창고별 테이블을 분리했다. 마이그레이션은 성공했지만 새 코드 업로드가 실패했다. 이때 사용자는 옛 코드를 보고 있어도 DB는 새 구조일 수 있다. 코드 업로드 성공 여부만으로 전체 배포 상태를 판단하면 안 된다.

Void는 배포 중 마이그레이션을 적용하며 앱 롤백이 DB 마이그레이션을 되돌리지는 않는다고 명시한다. 아래는 이 계약을 업무 복구에 적용한 판단표다. 실제 장애 재현 결과는 아니다.

확인한 상태	먼저 판단할 것	다음 행동의 조건
새 코드가 실패했고 DB는 변경 전	빌드·배포 실패 지점	데이터 변경이 없음을 확인한 뒤 원인을 수정
DB 변경 성공, 코드 업로드 실패	옛 코드가 새 스키마에서 동작하는가	호환되면 배포 수정, 호환되지 않으면 데이터 복구 계획과 함께 처리
새 앱이 운영 중이고 이후 입출고가 쌓임	과거 복원 시 잃는 쓰기는 무엇인가	코드 롤백·추가 마이그레이션·데이터 복원 중 업무 손실이 적은 경로 선택

직접 Cloudflare에 배포하는 경로에는 D1 마이그레이션 전 Time Travel 복원 지점을 저장하고 실패 시 복원 명령을 안내하는 절차가 문서화돼 있다. 하지만 복원은 그 지점 이후의 쓰기를 버린다. 재고 앱이라면 “배포 전 DB로 복원 성공”이 “그동안의 입출고까지 보존”을 뜻하지 않는다. 이 자동 복원 지점 설명은 직접 배포 경로의 문서 범위이며, 공유 Platform 전체에 동일하게 보장된다고 확대하지 않는다. 배포·마이그레이션·복원

검토 기록에는 코드 버전, 적용한 마이그레이션, 현재 데이터의 마지막 변경, 복원 때 잃을 쓰기를 한 줄씩 남기는 편이 유용하다. 입출고와 외부 알림을 함께 다룬다면 트랜잭셔널 아웃박스의 이중 쓰기 문제도 이어서 검토할 수 있다.

도입 평가는 작은 앱의 세 번의 인계로 한다

Void를 평가하는 실무 과제로 제작자에서 사용자로, 제작자에서 운영자로, 옛 버전에서 새 버전으로 넘기는 세 번의 인계를 제안한다. 단순한 첫 배포 성공보다 사내 앱의 수명을 더 잘 드러낸다. 운영 자료 대신 가상 재고로 시험하고 결과를 관측값으로 채운다.

1. 사용자 인계: 제작 권한이 없는 동료가 앱을 쓰고, 허용한 창고의 재고만 바꿀 수 있는지 확인한다. 플랫폼 가입과 업무 앱 사용의 조건을 각각 기록한다.
2. 담당자 인계: 소유권·팀 역할·CI를 넘긴 뒤 새 담당자가 상태와 로그를 찾고 다음 배포를 할 수 있는지 확인한다. 역할 표시 변경과 자격증명 교체 완료도 구분한다.
3. 버전 인계: 데이터가 있는 상태에서 호환되는 변경과 호환되지 않는 변경의 복구 계획을 검토한다. 코드·DB·입출고 기록 각각 무엇을 되돌릴지 정한다.

운영자가 정보를 찾는 자리도 역할에 맞춰 고른다. 문서상 관리자 화면의 People → Access는 가입 정책을, Plans는 계정에 적용할 한도를, 프로젝트 상세는 자원·도메인·최근 배포를 확인하는 곳이다. System Status는 플랫폼 구성 서비스의 상태를 확인한다. 앱에서 수량 수정이 실패한 문제를 가입 화면에서 찾는 대신, 앱 요청과 해당 배포의 로그를 연결해야 한다. 이 설명은 공식 문서의 화면 위치를 분석한 것이며 실제 관리자 화면의 모바일·키보드 동작은 검증하지 않았다. 접근 설정 · 운영 관측

평가 기록은 다음처럼 짧게 남길 수 있다. 처음에는 모두 미확인이어도 된다.

앱 / 코드 버전 / 소유자:
선택 경로: 직접 배포 또는 공유 Platform
사용자 인계: 업무 접근 규칙 / 실제 결과
담당자 인계: 소유권 / 남은 역할 / CI / 교체 완료 상태
버전 인계: 코드 / DB / 이후 쓰기 / 복구 가능 범위
운영 비용: 강제 한도 / 별도 관측 / 대응 담당자
다음 결정: 도입 · 범위 축소 · 기존 체계 유지, 그 근거

한 사람의 단일 앱이라면 직접 배포부터, 여러 제작자의 앱을 오래 유지할 조직이라면 공유 플랫폼과 이 인계 과제를 함께 검토할 수 있다. Void가 줄여 주는 것은 자원 준비와 배포의 반복이다. 그 덕분에 앱이 늘어난다면 팀은 그 앱의 소유자와 수명도 함께 관리해야 한다. 다음 앱을 검토할 때 위 양식을 다시 쓸 수 있도록 이 글을 저장하고, 자동 생성한 업무 입력의 의미 검사는 JSON 출력과 업무 검증에서 이어서 볼 수 있다.