PoC
Publisher

작은 실험을 하나 만들 때도 실제 URL로 보여주려면 repository, web server, reverse proxy, SSL, 데이터 저장과 배포 방법을 준비해야 합니다. 아이디어 자체는 몇 시간 안에 만들 수 있는데 공개 환경을 세팅하는 시간이 비슷하게 들면, 결국 실험을 말로만 설명하거나 로컬 프로토타입에서 멈추게 됩니다.

사용자가 실제로 작동하는 프로토타입을 만져본 뒤 피드백할 수 있도록 공용 배포 환경을 만들었습니다. 서버·데이터·파일 저장을 한 번 구성해두고 다음 실험에서 재사용하도록 했습니다.

처음 목적은 웹 결과물을 빠르게 공개하는 것이었지만 실제 실험을 만들수록 상태 저장, 파일 업로드, 외부 API 호출과 간단한 서버 로직이 필요해졌습니다. 그래서 Publish 기능 위에 프로젝트별 SQLite Data API와 파일, API Key, 제한된 Server Function을 추가했습니다.

중앙 플랫폼과 프로젝트 데이터 분리

플랫폼 자체의 프로젝트 metadata는 중앙 SQLite에 두고, 각 프로젝트의 실제 데이터는 별도 SQLite DB로 분리했습니다. 거대한 멀티테넌트 데이터 플랫폼을 만드는 대신 단일 노드에서 프로젝트 단위로 이해하고 백업하기 쉬운 경계를 우선했습니다.

프로토타입을 AI Agent와 함께 만드는 빈도가 늘면서 배포도 사람이 브라우저에서만 수행하는 작업일 필요가 없었습니다. OAuth MCP를 별도 인터페이스로 두어 Codex나 Claude가 프로젝트를 만들고 결과물을 갱신하는 작업을 직접 수행할 수 있게 했습니다.

Admin UI와 Agent API가 같은 프로젝트 모델을 사용하도록 했습니다. 사람과 Agent가 동일한 프로젝트를 각자의 인터페이스에서 관리할 수 있습니다.

파일, DB, 외부 HTTP와 실행 가능한 함수가 한 플랫폼에 모이면 작은 개인 도구라도 위험한 입력이 많아집니다. Secret은 최초 한 번만 보여주고 저장 시에는 hash를 사용하며, filesystem에서는 path traversal과 symlink를 거부합니다. DB 접근은 prepared query와 manifest allowlist를 기반으로 제한했습니다.

외부 HTTP Relay는 허용 목적지를 명시하고 SSRF를 막으며 redirect 이후 목적지도 다시 검증합니다. Server Function도 범용 서버 런타임을 그대로 노출하지 않고 허용된 범위 안에서 실행합니다.

동시에 이 시스템의 한계도 명시합니다. 현재는 single-node와 신뢰 가능한 개인 사용을 전제로 합니다. 서로 신뢰하지 않는 사용자가 임의 코드를 업로드하는 진짜 multi-tenant PaaS라면 process/container isolation과 resource quota 등 훨씬 강한 격리가 필요합니다.

PoC Publisher는 개인 웹 실험의 공개·데이터·파일·배포 준비를 공통으로 처리하는 내부 플랫폼입니다. 다음 실험에서 같은 기반을 재사용하도록 구성했습니다.

프로토타입을 실제 URL로 전달해 사용자가 직접 조작한 결과를 기준으로 피드백할 수 있게 하는 것이 목적입니다. Storybook·Figma·Agent Workflow처럼 실제 결과를 확인하며 다음 작업을 판단하도록 구성했습니다.