읽는 데 9분
직접 Label 309 게이트웨이 운영하기
그렇습니다 — 기업이나 개발자는 직접 Label 309 게이트웨이를 운영하고, 그 Cardano 지갑과 스토리지 지갑에 자금을 채운 다음, CardanoWall을 호스팅 운영자로 쓰지 않고도 표준 존재 증명을 게시할 수 있습니다. 그러려면 무엇이 필요한지 살펴봅니다.

그렇습니다 — 직접 게이트웨이를 운영할 수 있습니다. Label 309 게이트웨이는 존재 증명 레코드의 견적을 내고, 업로드하고, 게시하고, 확인하고, 색인하는 오픈소스 서비스입니다. 직접 운영하면 조직이 운영자가 됩니다. Cardano 지갑과 스토리지 지갑에 자금을 채우고, 계정과 API 키를 관리하며, CardanoWall의 호스팅 서비스에 의존하지 않고 표준 레코드를 게시합니다. 이렇게 고정한 레코드는 다른 누구의 레코드와도 동일합니다. 형식을 정의하는 것은 운영자가 아니라 표준이기 때문입니다.
자체 호스팅은 쉬운 길이 아닙니다. 통제의 길입니다. 이 글에서는 그 맞바꿈이 언제 가치가 있는지, 게이트웨이가 실제로 무엇을 실행하는지, 그리고 직접 운영함으로써 무엇을 떠안는지 설명합니다.
직접 게이트웨이를 운영해야 하는 경우는 언제입니까?
편의보다 운영 통제가 더 중요할 때 직접 게이트웨이를 운영합니다.
대부분의 사용자에게는 호스팅 CardanoWall 게이트웨이가 정답입니다. 시작이 더 간단하고, 자금 채우기가 더 쉬우며, 인프라 작업을 전부 없애 줍니다. 가끔만 게시하고 직접 키를 보유해야 할 정책상의 이유가 없다면 여기서 멈추십시오. 호스팅 경로는 그런 분을 위해 만들어졌습니다.
하지만 일부 팀에는 다른 모델이 필요합니다.
- 엄격한 벤더 및 데이터 소재지 정책;
- 규제 대상이거나 감사를 받는 워크플로;
- 대용량 게시;
- 내부 컴플라이언스 아카이브와 법적 증거 시스템;
- AI 출처 증명 인프라와 CI/CD 증명 파이프라인;
- 자체 브랜드로 Label 309 위에 구축한 제품;
- 키, 계정, 자금, 가격에 대한 직접 통제.
이런 팀이라면 자체 호스팅을 통해 파이프라인을 제3자에게 거치지 않고 조직이 통째로 소유할 수 있습니다.
게이트웨이는 실제로 무엇을 실행합니까?
게이트웨이는 전체 게시 파이프라인과 그 이면의 자금·체인·스토리지 상태를 소유합니다. 단일 Rust 바이너리에 PostgreSQL을 더한 구성이며, 다음을 처리합니다.
- 견적 생성과 가격 책정;
- 콘텐츠 또는 암호문의 스토리지 업로드;
- 스토리지 자금 조달과 회계;
- Cardano 트랜잭션 빌드, 제출, 확인 추적;
- reorg 처리와 게시가 영구적으로 실패할 때의 자동 환불;
- 공개 온체인 레코드 색인;
- 계정 잔액과 잔액 원장;
- API 키, 계정 토큰, 운영자 컨트롤 플레인;
- 웹훅과 감사 추적.
이것이 신뢰할 수 있는 게시 서비스를 떠받치는 기계 장치입니다. 사용자 측 의도와 개인 키는 여전히 클라이언트가 소유하고, 체인·스토리지·가격·계정 인프라는 게이트웨이가 소유합니다. 이 분리는 의도적입니다. CardanoWall이 게이트웨이를 운영하든 여러분이 운영하든 동일한 경계입니다.
자체 호스팅에는 무엇이 필요합니까?
최소한 다섯 가지에 대한 운영상의 소유권이 필요합니다.
게이트웨이 배포. 바이너리, 그 구성, Postgres 데이터베이스, 네트워크 접근, 로그, 모니터링, 그리고 업그레이드 경로입니다. 바이너리는 부팅 시 자체 스키마 마이그레이션을 적용하고, 모든 백그라운드 루프를 하나의 슈퍼바이저 아래에서 실행합니다. 따라서 루프 하나가 실패하면 조용히 성능이 저하되는 대신 프로세스 자체가 멈춥니다.
Cardano 자금. 게이트웨이는 트랜잭션 수수료를 낼 자금이 채워진 지갑이 필요합니다. 개별 트랜잭션 출력을 직접 관리하지는 않습니다. 지갑은 즉시 사용할 수 있는 출력을 소규모 풀로 미리 다듬어 두며, 그래서 게시할 때마다 추정치가 아니라 정확한 수수료를 냅니다. 여러분은 그 지갑의 잔액을 채워 두기만 하면 됩니다. 나머지는 게이트웨이가 합니다.
스토리지 자금. 게이트웨이가 파일이나 암호문 업로드를 받는다면, 스토리지 백엔드와 바이트를 저장할 자금이 필요합니다. 프로덕션에서는 Turbo 번들러를 통한 Arweave이며, Arweave 지갑에서 충전하는 선불 스토리지 크레딧으로 비용을 냅니다. 스토리지가 전혀 없는 해시 전용 배포로 운영할 수도 있습니다. 그러면 레코드에는 콘텐츠 해시(그리고 외부에 호스팅된 모든 URI)만 담기고, 인스턴스는 아무것도 저장하지 않습니다.
운영자 자격 증명. 컨트롤 플레인은 운영자 루트 시크릿으로 보호되며, 이 시크릿은 인스턴스를 프로비저닝할 때 단 한 번만 출력됩니다. 일상적인 관리 작업은 그 시크릿에서 발급한 단기 운영자 토큰으로 수행합니다. 이런 시크릿은 브라우저, 클라이언트 번들, 모바일 앱, CI 로그에 절대로 닿아서는 안 됩니다.
계정 및 결제 정책. 사용자가 여러분 한 명뿐이라 해도, 게이트웨이는 여전히 누가 게시할 수 있고 잔액을 어떻게 적립할지 결정해야 합니다. 잔액은 게이트웨이 자체의 권한이며, 여러분은 어떤 결제 레일을 운영하든 컨트롤 플레인을 통해 잔액을 적립합니다.
자체 호스팅은 실제 인프라입니다. 그렇게 다루면 믿을 만하고, 가볍게 다루면 부담이 됩니다.
자체 호스팅이 표준을 바꿉니까?
아닙니다. 자체 호스팅 게이트웨이는 다른 운영자와 동일한 Label 309 레코드를 게시하며, 레코드는 표준 그대로 유지됩니다.
검증기는 Cardano 트랜잭션 메타데이터, 선택적으로 콘텐츠 바이트, 그리고 공개 Cardano 탐색기만 있으면 됩니다. 레코드가 호스팅 CardanoWall 게이트웨이에서 왔는지, 여러분 회사의 게이트웨이에서 왔는지, 개발자의 노트북에서 왔는지는 알 필요도 없고 알 수도 없습니다. 바로 그것이 오픈 표준을 호스팅 제품에서 분리하는 핵심입니다. 오래 남는 산출물은 Label 309이고, 모든 게이트웨이는 그 하위 구현입니다.
자체 호스팅이 모든 비용을 없앱니까?
아닙니다. 호스팅 운영자의 마진은 없애지만, 그 밑바탕의 비용은 여전히 여러분의 몫입니다.
여전히 다음 비용을 냅니다.
- Cardano 트랜잭션 수수료와 업로드된 바이트에 대한 스토리지 비용;
- 인프라, 데이터베이스, 백업 비용;
- 모니터링, 로깅, 보안 운영;
- 인력 시간, 자금 관리, 장애 복구;
- 업그레이드와 지속적인 유지보수.
물량이 적다면, 인프라 운영의 인적 비용까지 셈에 넣으면 실제로는 호스팅 게이트웨이가 더 저렴한 경우가 많습니다. (애초에 게시에 왜 돈이 드는지, 그 작동 방식은 게시에 가격이 붙는 이유를 참고하십시오.) 물량이 많거나 정책상 키를 직접 보유해야 한다면, 자체 호스팅이 본전을 뽑기 시작합니다.
자체 호스팅을 하지 말아야 할 사람은 누구입니까?
단지 가격을 고민하기 싫어서 자체 호스팅을 하지는 마십시오.
가끔만 게시하고, 운영 역량이 부족하며, 자금이 채워진 지갑을 관리하고 싶지 않고, 맞춤 정책 통제가 필요하지 않다면, 거의 틀림없이 호스팅 게이트웨이가 더 나은 선택입니다. 자체 호스팅은 가용성, 보안, 자금, 모니터링, 업그레이드를 여러분이 책임지게 합니다 — 이는 그 책임을 실제로 원할 때에만 이점이 됩니다.
대부분의 개인과 많은 소규모 팀에게는 호스팅 CardanoWall이 현실적인 길입니다.
자체 호스팅에 잘 맞는 사람은 누구입니까?
이미 본격적인 인프라를 운영하고 있고, 파이프라인을 직접 보유할 구체적인 이유가 있는 팀입니다. 좋은 후보는 다음과 같습니다.
- 대용량 증명을 게시하는 기업;
- 매일 또는 매시간 증거를 고정하는, 이상적으로는 단일 레코드로 배치 처리하는 컴플라이언스 팀;
- 데이터셋과 출력 매니페스트를 커밋하는 AI 팀;
- 증명을 릴리스 파이프라인에 녹여 넣는 DevSecOps 팀;
- 민감한 증거를 다루는 법률 플랫폼;
- 자체 브랜드로 Label 309를 쓰려는 제품;
- 민감한 워크플로를 제3자 호스팅 서비스로 거칠 수 없는 조직.
이런 경우, 게이트웨이 운영은 새로 돌봐야 할 무언가가 아니라 조직의 기존 보안·인프라 체계의 일부가 됩니다.
제품은 게이트웨이 위에 어떻게 구축합니까?
제품은 게이트웨이를 기반 계층으로 다룰 수 있습니다. 게이트웨이는 체인, 스토리지, 가격, 잔액, 레코드, 게시 상태를 처리합니다. 여러분의 제품은 사용자, 세션, 결제 표현, 알림, 워크플로, UI, 그리고 도메인별 의미를 처리합니다.
예를 들면 다음과 같습니다.
- 컴플라이언스 제품은 매일 통제 스냅샷을 게시합니다;
- 미디어 제품은 Content Credentials(C2PA) 매니페스트 해시를 고정합니다;
- 법률 제품은 특정 수신자를 위해 증거를 봉인합니다;
- 개발자 도구는 릴리스 증명을 게시합니다;
- AI 제품은 생성 출력 배치에 타임스탬프를 찍습니다.
제품은 Cardano 제출이나 스토리지 회계를 다시 만들지 않습니다 — 게이트웨이를 호출합니다. CardanoWall이 바로 이렇게 만들어졌습니다. 웹 앱과 워커는 제3자가 사용하는 것과 동일한 공개 게이트웨이 플레인을 감싼 래퍼이며, 별도의 비공개 출입구는 없습니다. 통합 패턴을 깊이 있게 보고 싶다면 Label 309 게이트웨이 위에 구축하기를 참고하십시오.
클라이언트는 게이트웨이에 어떻게 연결합니까?
게이트웨이의 HTTP API를 통하며, 이 API는 두 개의 플레인으로 나뉩니다.
웹 앱, 데스크톱 앱, CLI, SDK 통합, 또는 백엔드 서비스는 계정 토큰 또는 API 키로 데이터 플레인을 호출합니다. 견적, 업로드, 게시, 잔액 읽기, 레코드 읽기가 여기에 속합니다. 운영자 동작 — 계정 생성, 잔액 적립, 마진 설정, 자격 증명 발급 — 은 컨트롤 플레인을 거치며, 오직 신뢰할 수 있는 백엔드에서만 수행합니다.
일반적인 분리는 다음과 같습니다.
- 클라이언트는 범위가 한정된 단기 계정 자격 증명으로 동작합니다;
- 여러분의 백엔드는 운영자 자격 증명을 보유하고 절대 노출하지 않습니다;
- 개인 신원 키는 사용자 기기 또는 여러분 자체의 키 정책 아래에 머뭅니다;
- 게이트웨이는 봉인된 콘텐츠를 절대 복호화하지 않습니다.
실용적인 패턴은 토큰 발급 프록시입니다. 클라이언트가 여러분 자체의 세션 시스템에 인증하면, 백엔드가 그 세션을 페이지에 필요한 만큼만 범위가 한정된 단기 계정 토큰으로 교환하고, 클라이언트는 오직 그 토큰만 봅니다. 그러면 토큰이 유출되어도 사고가 아니라 한 시간짜리 문제로 끝납니다. 레코드 읽기 표면은 더 단순합니다 — 익명 호출자에게도 제공되므로, 공개 검증 페이지와 탐색기에는 자격 증명이 전혀 필요하지 않습니다.
운영자는 무엇을 보호해야 합니까?
여러 가지를, 대략 다음의 심각도 순으로 보호해야 합니다.
키와 자격 증명. 게이트웨이는 단일 암호화 키링으로 서명합니다 — Cardano, 스토리지, 웹훅 키를 하나의 패스프레이즈 아래 한 파일에 담습니다. 오프라인에서 생성하고, 파일과 패스프레이즈를 모두 오프라인으로 백업하며, 운영자 루트 시크릿을 프로덕션 데이터베이스 비밀번호처럼 지키십시오. 키 내보내기나 자금 회수 경로는 없습니다. 키링을 잃으면 그 주소에 들어 있는 자금이 그대로 묶입니다.
자금과 권한. 누가 계정을 생성하고, API 키를 발급하고, 잔액을 조정하고, 마진을 변경할 수 있는지 통제하십시오. 모든 컨트롤 플레인 동작은 감사 로그에 남으며, 잔액 조정은 피해 범위 제한 차원에서 호출당 상한이 걸려 있습니다. 그래서 손가락이 헛나간 입력이나 탈취된 토큰도 한 번에 옮길 수 있는 금액에는 한계가 있습니다.
운영. 로그와 감사 추적, 백업·복원 계획, 그리고 지갑 잔액 부족, 스토리지 고갈, 멈춘 업로드, 실패한 게시, 정체된 체인 팁에 대한 모니터링을 유지하십시오. 바이너리는 로그 수집기를 위해 구조화된 JSON 로그를 남기고, 헬스 프로브를 노출합니다.
최소 권한. 브라우저는 운영자 자격 증명을 절대 받아서는 안 됩니다. CI 작업은 필요 이상의 권한을 절대 받아서는 안 됩니다. 계정 토큰의 범위를 좁게 한정하고 단기로 유지하십시오.
자체 호스팅 게이트웨이에 대한 검증은 어떻게 작동합니까?
어떤 게이트웨이에 대해서든 똑같습니다 — 검증은 게이트웨이를 전혀 신뢰하지 않습니다.
검증기는 표준 규칙을 사용해 Cardano 트랜잭션, Label 309 메타데이터, 해시, 선택적 서명, 모든 Merkle 증명, 그리고 봉인된 페이로드를 확인합니다. 그 과정에 발행자 서버는 끼어들지 않습니다. 게이트웨이는 게시와 색인을 돕습니다. 유효하지 않은 증명을 유효하게 만들 수는 없습니다.
이는 내부 시스템에서 가장 중요합니다. 자체 게이트웨이를 운영하는 기업도 자신의 레코드를 독립적으로 검증해야 합니다. "우리 게이트웨이가 게시했다고 말했다"는 증명이 아닙니다. 온체인 레코드와 독립적인 확인이 증명입니다. 그 확인은 오픈소스 cardanowall 명령줄 도구로 실행하거나 수동으로 레코드를 검증할 수 있으며, 어느 쪽도 여러분의 게이트웨이가 실행 중일 필요가 없습니다.
이것은 CardanoWall과 어떤 관계입니까?
CardanoWall은 호스팅되고 다듬어진 제품이자 표준의 레퍼런스 운영자입니다. 자체 호스팅은 독립의 길입니다. 둘은 서로 대립하지 않습니다.
사용자는 CardanoWall에서 시작했다가 나중에 자체 호스팅 게이트웨이로 옮길 수도 있고, 서로 다른 워크플로에 둘 다 쓸 수도 있습니다. 개발자는 게이트웨이 모델 위에 제품을 구축할 수 있습니다. 기업은 단순한 팀에는 호스팅 CardanoWall을 유지하면서 규제 대상 자동화에는 자체 게이트웨이를 운영할 수 있습니다. 그 모든 것의 밑바탕에 깔린 공유 계층이 Label 309입니다 — 개방적이고, 벤더 중립적이며, 누가 게시하든 온체인에서 동일합니다.
짧게 요약하면
게시 서비스를 직접 운영하고 싶을 때 직접 게이트웨이를 운영하십시오. 자금, 계정, 마진, API 키, 인프라, 정책에 대한 통제를 얻고 — 가용성, 보안, 지갑, 스토리지, 모니터링, 업그레이드에 대한 책임을 떠안습니다.
호스팅 CardanoWall은 편의입니다. 자체 호스팅은 통제입니다. 어느 쪽이든 증명 레코드는 표준 그대로 유지됩니다.
더 읽어보기
- 오픈 표준: label309.org.
- 게이트웨이, SDK, CLI — 모두 오픈소스(Apache-2.0): github.com/cardanowall.
- 메타데이터 표준은 Cardano CIP 절차에 제출되어 검토 중입니다: 제안 풀 리퀘스트.
- Label 309 게이트웨이란 무엇입니까?
- Label 309는 오픈소스입니다