통신3사 PASS 미사용 Aleo ZKP 단독 구조 정직한 한계 고지 포함

PASS 없이, Aleo 영지식증명만으로
만드는 프라이버시 인증 SaaS

"이거 가능한가?" — 결론: 조건부로 가능합니다. "멤버십·자격·구독 등급을 개인정보 노출 없이 증명"하는 SaaS는 PASS 없이도 Aleo ZKP만으로 완전히 구현 가능합니다. 다만 "실명·생년월일 같은 실제 신원 사실 자체를 검증"하려면 어떤 방식으로든 1곳의 신뢰 발급 주체(Root of Trust)가 필요합니다 — 이 페이지에서 그 경계선을 명확히 긋고, 지금 구조로 바로 시작할 수 있는 구독형 SaaS 모델과 안드로이드/iOS 앱 로드맵까지 제시합니다.

 실제 동작 데모 체험  가능성 판단 보기  구독 요금제 보기
0원
PASS/SMS 인증 비용
100%
클라이언트 ZKP 생성
3단계
신뢰수준(Tier) 모델
1곳
실신원 검증 시 필요한 발급주체
 가능성 검토

"가능한가?"에 대한 정직한 답변

Aleo ZKP는 "계산이 올바르게 수행되었다"는 것을 증명하는 기술입니다. 즉 입력값 자체가 진실인지는 증명하지 못합니다 (Garbage-in, Garbage-out). 이 원칙 위에서 두 가지 질문을 분리해야 합니다.

가능함 — PASS 완전 대체

"자격·등급·멤버십"을 개인정보 없이 증명하는 SaaS

서비스 자체가 발급 주체가 되어(자체 회원가입·구독결제·1회 자체 인증) Aleo 프로그램으로 "구독중/등급 충족/자격 보유" 같은 우리 서비스 안에서 정의한 사실을 증명한다면, 통신3사 PASS 없이도 100% Aleo ZKP만으로 구현 가능합니다. DAO·커뮤니티·구독 서비스·NFT/토큰 게이팅·Web3 로그인 등이 여기에 해당합니다.

한계 있음 — 100% PASS-free 불가

"실제 생년월일·실명 같은 현실 신원 사실"을 증명하는 SaaS

사용자가 스스로 입력한 생년월일은 ZKP가 아무리 정교해도 진짜인지 검증할 방법이 없습니다. 현실 신원과 연결하려면 PASS든, 신분증 스캔+대면대체(라이브니스) KYC든, 정부 발급 전자신분증(모바일 신분증)이든 최소 1곳의 외부 신뢰 발급 주체가 필요합니다. "PASS만 안 쓴다"는 가능해도 "발급 주체 자체가 없다"는 불가능합니다.

따라서 이 SaaS의 포지셔닝이 핵심입니다. "정부 신원증명/성인인증 대체"로 팔면 위 한계에 바로 부딫힙니다. 반대로 "Web3·구독형 서비스를 위한 프라이버시 우선 자격증명(Privacy-preserving Credential) 플랫폼"으로 포지셔닝하면 PASS 없이 지금 구조로 완전히 구현 가능하고, 필요 시 아래 Tier 2/3로 확장해 실신원 영역까지 단계적으로 넓힐 수 있습니다.

신뢰수준(Assurance Tier) 3단계 모델

서비스가 필요로 하는 신뢰 수준에 따라 아래 3개 티어 중 선택하거나 조합해서 구축합니다.

Tier 1 · Self-Sovereign

 지갑 기반 자기증명

완전 정적 웹사이트 + Aleo 지갑만으로 구현. 서버 불필요.
  • Aleo 지갑 연결 → 클라이언트에서 직접 ZK 증명 생성
  • 온체인 활동(스테이킹, NFT 보유, 구독 결제기록)을 증명
  • 구축 비용 최소, PASS·서버·KYC 전부 불필요
  • 실제 신원(실명·생년월일)과는 무관 — Sybil 저항만 제공
적합: 커뮤니티 멤버십, 익명 투표, 토큰/NFT 게이팅, 얼리엑세스 등급
Tier 2 · Issuer-Backed

 자체 발급 서버 + ZKP

경량 백엔드 1곳이 "최초 1회" 자격을 발급 → 이후 전부 ZKP로 재사용.
  • 자체 회원가입/이메일·카드 인증/결제 내역으로 자격 발급
  • 발급 이후 검증은 전부 클라이언트 ZKP — 서버 재조회 없음
  • 통신3사 PASS 대신 자체 KYC 벤더(선택) 연동 가능
  • "최초 1회" 발급 시점엔 최소한의 서버·데이터 저장 필요
적합: 구독형 SaaS 등급, B2B 파트너 API 접근권, 유료 멤버십 재사용 토큰
Tier 3 · Institution-Issued

 기관 발급 신원 크리덴셜

정부·통신사·금융기관 등 실신원 발급 주체와 연계 (PASS/모바일신분증 포함 가능).
  • 실명·생년월일 등 "현실 신원 사실"에 대한 강한 신뢰 확보
  • 모바일 신분증(NFC), 통신3사 PASS 등과 병행 가능
  • 발급 이후엔 동일하게 Aleo ZKP 토큰으로 재사용
  • "PASS 완전 미사용"과는 별개 트랙 — 고위험 서비스는 이 티어 권장
적합: 성인인증, 금융/도박 등 고위험 서비스, 법적 실명 요구 서비스

⚠️ 자주 하는 오해 — "PASS도 1회만 하면 되는 것 아닌가?"
아닙니다. 통신3사 PASS(나이스·다날·KG모빌리언스 등)는 원래 세션·토큰 재사용 기능이 없는 1회성 인증 이벤트입니다 — 검증이 필요한 순간마다 사용자가 그때그때 지문/PIN으로 재인증해야 하는 것이 PASS의 기본 스펙이며, 이게 정상입니다. Tier 2/3에서 "최초 1회만 PASS 하면 된다"고 설명한 부분은 PASS 호출 자체를 정말로 1번만 발생시키고, 그 결과를 우리 백엔드가 별도로 만든 Aleo ZKP 토큰으로 감싸서 재사용 가능하게 만든 것입니다. 이 토큰의 발급·만료·폐기 로직은 대행사가 제공하는 게 아니라 전적으로 우리 서버가 구현해야 하는 몫이며, 그 설계 품질에 따라 보안 수준이 결정됩니다. 상세: server/TELECOM-AUTH-INTEGRATION.md 6-2절 "오해 방지".

 아키텍처

Tier 1~2 기준 Pure-Aleo 구조

지금 이 SaaS를 시작할 수 있는 최소 구조입니다. 통신3사 PASS 호출이 어디에도 없습니다.

STEP 1
자체 회원가입
→
Aleo 지갑 연결/생성
→
구독 결제 (Tier 선택)
 PASS 호출 없음 · 전화번호/실명 수집 없음
STEP 2
자격 속성 로컬 생성
→
Leo 회로 실행 (클라이언트)
→
Groth16 ZK Proof 생성
 구독등급/자격 값은 증명 안에 숨김, 결과(TRUE/FALSE)만 공개
STEP 3
단발성 QR / 세션 토큰
→
Aleo 네트워크 기록(선택)
→
만료시간 자동 소멸
 재사용 가능, 매번 재인증 불필요 (SSO 패턴과 동일)
STEP 4
파트너 앱/사이트
→
ZKP 검증 (SDK)
→
접근 허용/차단
 파트너사는 사용자의 실제 데이터를 절대 보지 못함

Tier 3(실신원)로 확장 시에는 STEP 1의 "자체 회원가입" 자리에 server/TELECOM-AUTH-INTEGRATION.md에서 설계한 통신3사 PASS 또는 모바일 신분증 발급 절차를 "최초 1회"만 끼워 넣으면 됩니다 — 이후 STEP 2~4는 완전히 동일한 구조를 그대로 재사용합니다. 즉 이 SaaS는 Tier 1→2→3로 점진 확장 가능한 하나의 아키텍처입니다.

 실제 동작 데모

지금 이 페이지에서 직접 실행해보세요

아래 5단계는 시뮬레이션이지만, 통신3사 PASS 호출이 단 한 번도 없는 실제 Tier 1~2 아키텍처를 그대로 따릅니다. 브라우저 안에서 지갑 연결 → 자격 속성 선택 → Leo 회로 실행 → ZK Proof 생성 → 파트너사 검증까지 전 과정을 체험할 수 있습니다.

5단계 플로우
1

지갑 연결

Aleo 지갑 생성/연결 (PASS 없음)

2

자격 속성 선택

구독등급 · 서비스 요구조건 선택

3

Leo 회로 실행

클라이언트에서 ZK Proof 생성

4

재사용 토큰 발급

만료시간 포함 세션 토큰 생성

5

파트너사 검증

실제 데이터 노출 없이 접근 허용

STEP 1 · Aleo 지갑 연결

통신3사 PASS 대신, 이 SaaS는 사용자의 Aleo 지갑을 신원 앵커로 사용합니다. 전화번호·실명 수집이 전혀 없습니다.

 방식 비교

PASS 기반 인증 VS Pure-Aleo 인증

두 방식은 대체 관계가 아니라, 신뢰수준과 비용구조가 다른 보완 관계입니다.

비교 항목통신3사 PASS 방식Pure-Aleo (Tier 1~2)
실신원 신뢰수준매우 높음 (통신사 KYC 기반)낮음~중간 (자체 발급 수준)
건당 비용SMS 30~80원 / PASS앱 100~250원0원 (클라이언트 연산, 가스비만 발생 시 소액)
사업 계약NICE/Danal/KG모빌리언스 등 대리점 계약 필요불필요 — 자체 구축으로 즉시 시작
네트워크 요구항상 온라인 (외부 API 콜)증명 생성은 오프라인 가능
개인정보 노출이름/생년월일/통신사가 서버로 전송속성값 자체는 절대 노출 안 됨
적합 서비스성인인증, 금융, 도박 등 법적 실명 요구구독 멤버십, 커뮤니티, Web3, 토큰 게이팅
구축 착수 시점계약·심사 완료 후 (수주~수개월)지금 바로 시작 가능
 적합도 매트릭스

이 SaaS가 잘 맞는 곳 / 아직 어려운 곳

Tier 1~2로 지금 바로 가능
구독형 SaaS 등급 인증 — Free/Pro/Enterprise 등급을 서버에 매번 조회하지 않고 증명
DAO·온라인 커뮤니티 멤버십 — 회원 자격을 개인정보 없이 증명
Web3 로그인 / 지갑 기반 SSO — 여러 파트너 dApp에 동일 자격 재사용
NFT/토큰 게이팅 접근권 — 보유 여부만 증명, 잔액/주소 비공개
익명 투표·설문 자격 증명 — "투표권 있음"만 증명, 신원 비공개
B2B API 접근권한 증명 — 파트너사에 계약 등급만 증명
Tier 3(발급주체) 없이는 아직 어려움
법적 성인인증(주류·담배·게임 셔틀다운) — 자기입력 생년월일만으로는 법적 효력 부족
금융/대출/증권 실명 확인 — 금융실명법상 외부 신뢰기관 확인 의무
온라인 도박·경마 등 고위험 서비스 — 강한 신원 신뢰 + 실시간 재확인 필요
정부·공공기관 대체 신원증명 — 법적으로 통신사/정부 발급 신원과 연계 필수
가족 간 기기·생체정보 공유 악용 방지 — ZKP로 원천 차단 불가 (별도 위협모델 대응 필요)
 구독 요금제 (안)

B2B SaaS 구독 모델 — 파트너사(검증 측) 과금

사용자는 무료, 사용자의 자격을 "검증"하려는 파트너 기업/서비스가 월 구독료를 지불하는 구조입니다. (아래 금액은 사업성 검토용 예시안이며, 확정 가격 정책은 시장조사 후 별도 수립이 필요합니다.)

Community
개인 개발자 · 소규모 커뮤니티
무료 / 월
검증 API 월 1,000건까지
  • Tier 1 지갑 기반 증명만 지원
  • JS SDK / QR 검증 위젯
  • 커뮤니티 지원(포럼)
무료로 시작
추천
Starter
스타트업 · 구독형 서비스
₩99,000 / 월
검증 API 월 50,000건 포함
  • Tier 1~2 (자체 발급 서버 포함)
  • Aleo 토큰 재사용/SSO 연동
  • 대시보드 · 사용량 리포트
  • 이메일 지원 (영업일 1일 이내)
Starter 시작하기
Growth
중견 서비스 · 다기관 SSO
₩390,000 / 월
검증 API 월 300,000건 포함
  • Tier 1~2 + 커스텀 Leo 회로
  • 다기관 SSO 라우팅(스포츠·문화·행정)
  • 이상거래 탐지 알림(웹훅)
  • 전담 매니저
문의하기
Enterprise
Tier 3 실신원 · 고위험 서비스
맞춤 견적
PASS/모바일신분증 연계 포함
  • Tier 3 통신3사 PASS/모바일신분증 연동
  • 온프레미스/전용 인프라
  • 법무·컴플라이언스 자문 연계
  • SLA 계약 · 24/7 지원
영업팀 문의

※ 위 가격은 시뮬레이션 예시입니다. 실제 서비스 오픈 전 Aleo 온체인 수수료(가스비), 클라우드 인프라비, 결제 PG 수수료를 반영한 원가 분석이 필요합니다.

 로드맵

Web MVP → 네이티브 앱까지

"나중에 안드로이드/iOS 앱을 만들 것"이라는 목표를 반영한 4단계 로드맵입니다.

Phase 1 · 0~2개월
Web MVP (Tier 1)
Aleo 지갑 연동 (Leo Wallet / Puzzle Wallet)
클라이언트 ZK 증명 생성 데모 (본 사이트 구조 재사용)
구독 결제 연동(PG) + 등급별 접근 제어
파트너 검증용 JS SDK v0.1
정적 사이트로 100% 구현 가능
Phase 2 · 2~4개월
발급 서버 (Tier 2)
경량 백엔드: 최초 1회 자격 발급 API
Aleo 토큰 발급/만료/폐기(Revocation) 정책
다기관 SSO 라우팅 (sport_sso.html 구조 확장)
사용량 기반 구독 청구 시스템
server/ 스캐폴딩 재사용
Phase 3 · 4~7개월
네이티브 앱 (Android/iOS)
React Native / Flutter 앱 셸 + WebView 하이브리드 우선 출시
Aleo 모바일 SDK 바인딩(WASM/Rust FFI) 검토
기기 생체인증: BiometricPrompt(Android) / LocalAuthentication(iOS)
앱스토어/플레이스토어 심사 대응 (개인정보 처리방침 정비)
WebAuthn 데모가 사전 검증 역할
Phase 4 · 7개월+
Tier 3 확장 & 고도화
통신3사 PASS / 모바일 신분증(NFC) 선택적 연동
실시간 AI 나이추정 등 고위험 서비스용 보강 인증
엔터프라이즈 SLA, 온프레미스 배포 옵션
해외 확장(EU eIDAS, 미국 mDL 등 표준 대응 검토)
TELECOM-AUTH-INTEGRATION.md 로드맵과 합류
 기술 스택

지금 구조로 바로 쓸 수 있는 스택

ZKP / 블록체인
Aleo 블록체인 · Leo 언어
Groth16 / Marlin zk-SNARK
membership_proof.aleo / age_proof.aleo 회로
프런트엔드
정적 HTML/CSS/JS (본 사이트와 동일 구조)
WebAuthn/FIDO2 (기기 로컬 생체인증)
Aleo 지갑 연동 SDK (Leo/Puzzle Wallet)
백엔드 (Tier 2~3)
Node.js/Express (server/ 기존 스캐폴딩)
PostgreSQL 16 (자격 발급 로그)
JWT 세션 + Aleo 토큰 재사용 정책
향후 네이티브 앱
React Native / Flutter
BiometricPrompt(Android) / LocalAuthentication(iOS)
Aleo Mobile SDK (WASM/Rust FFI, 검토 필요)

이 프로젝트(정적 사이트 환경)에서는 Tier 1(지갑 기반 자기증명) 수준의 프런트엔드/데모까지 바로 구현할 수 있습니다. Tier 2의 "최초 1회 발급 서버"와 Tier 3의 "PASS/모바일신분증 연동", 그리고 Phase 3의 "네이티브 앱 스토어 배포"는 서버 인프라·앱 빌드/배포 파이프라인이 필요해 이 정적 사이트 툴로는 직접 만들 수 없고, 별도 백엔드/앱 개발 단계가 필요합니다. (server/ 폴더의 스캐폴딩과 TELECOM-AUTH-INTEGRATION.md 문서가 그 다음 단계의 시작점입니다.)

 실전 배포 전 체크

"지금 바로 실전에 써도 되는가?" — 아직 아닙니다

위 실제 동작 데모는 100% 브라우저 안에서만 동작하는 시뮬레이션입니다. 지갑 주소·ZK Proof·토큰이 모두 화면 안에서만 생성되고 새로고침하면 사라지며, 실제 블록체인·서버·결제망과는 연결되어 있지 않습니다. "무료 운영 → 유료 구독 전환"이라는 사업모델 자체는 타당하지만, 그 전에 아래 항목들이 실제로 구현되어야 진짜 서비스로 돈을 받을 수 있습니다.

지금 완성된 것
UI/UX 전체 플로우 (지갑연결→등급선택→증명→토큰→검증)
Leo 회로 설계 예시 (membership_proof.aleo)
Tier 1~3 신뢰수준 아키텍처 및 사업 포지셔닝 문서
B2B 구독 요금제(안) — 사업모델 초안
통신3사 인증 연동 요구사항 명세 (server/TELECOM-AUTH-INTEGRATION.md)
실제 회원 DB — pv_members/pv_payments 테이블, 새로고침해도 유지됨 (account.html)
서버(DB) 기준 등급 재조회 접근제어 — 로컬 변수 대신 매번 DB GET으로 판정
결제 흐름 UI(샌드박스) — 결제레코드 생성→상태전환→등급 PATCH 전체 플로우
실제 Aleo 지갑 확장 연동 코드 — Leo/Puzzle Wallet 감지 시 실지갑 연결, 없으면 시뮬레이션으로 명확히 구분 표시
이용약관·개인정보처리방침 초안, 사업자등록/신고 체크리스트 (legal.html)
실전 서비스에 반드시 필요 (여전히 미구현)
진짜 Aleo SDK 연동 — 증명 생성(privacy.html 데모)은 여전히 랜덤 문자열 시뮬레이션. 지갑 연결만 실제 확장 감지 코드가 추가됨
진짜 PG 결제 연동 — account.html의 결제는 샌드박스이며 실제 카드 승인/청구가 발생하지 않음. 토스페이먼츠 등 실 API 키 발급 및 웹훅 서버 검증 필요
완전한 서버측 보안 — Table API가 인증 계층 없는 공개 REST라서, 판정 로직 자체는 여전히 브라우저 JS에서 실행됨. Cloudflare Worker 등 진짜 서버가 앞단에서 응답을 통제해야 완전히 안전
사업자등록·신고 실제 처리 — 체크리스트는 준비됐으나, 국세청/정부24 행정 절차는 사용자님이 직접 진행해야 함
법무 검토 — 이용약관/개인정보처리방침은 템플릿 초안이며 변호사 검토 필요
추가 보안 점검 — Rate Limiting, 토큰 위변조 방지, HTTPS/키 관리 등 운영 인프라 보안
 결론

"무료로 시작 → 나중에 유료 구독 전환"이라는 사업 전략 자체는 완전히 타당합니다(Freemium은 SaaS 업계 표준 전략). account.html에서 실제 회원가입·DB 기준 등급 관리·서버측 재조회 접근제어·샌드박스 결제 흐름까지 동작하는 프로토타입을 확인할 수 있습니다. 다만 실제 돈을 받으려면 여전히 ① 진짜 PG사 가맹점 가입 + 웹훅 검증 서버, ② 진짜 Aleo SDK, ③ 사업자등록·신고, ④ Table API 앞단의 진짜 인증 서버(Cloudflare Worker 등)가 추가로 필요합니다. 이 사이트(정적 웹빌더)는 이 단계의 프론트엔드/DB/기획 문서까지는 만들 수 있지만, 결제 웹훅 서버·블록체인 프로그램 배포·행정 신고는 별도 단계로 진행해야 합니다.

네이티브 앱(Android/iOS)으로 "동일하게" 만들 경우 추가 고려사항

웹과 동일한 기능·UI를 앱으로 그대로 옮기더라도, 앱스토어 생태계 특유의 제약이 추가로 발생합니다.

항목내용
구독 결제 강제 정책Apple App Store / Google Play는 앱 내 디지털 구독을 자체 In-App Purchase(IAP)로 처리하도록 강제하며 15~30% 수수료를 부과합니다. PG사(카드결제) 직접 연동만 넣으면 심사 거부될 수 있습니다.
암호화폐/지갑 기능 심사Aleo 지갑 키 관리 기능이 포함되면 앱스토어 가이드라인상 암호화폐 지갑 앱으로 분류되어 심사가 더 엄격해질 수 있습니다(특히 iOS).
모바일 ZK 증명 성능Groth16 증명 생성은 연산량이 큽니다. 모바일 기기(특히 저가형)에서 배터리 소모·발열·처리시간을 실기기 테스트로 검증해야 합니다.
생체인증 APIWebAuthn 대신 네이티브 BiometricPrompt(Android) / LocalAuthentication(iOS)를 사용하면 더 안정적이고 UX가 좋습니다 (유리한 점).
앱 심사·정책 변경 리스크Apple/Google 정책은 수시로 바뀌며, 블록체인·구독 관련 앱은 심사 반려 사례가 상대적으로 많아 심사 기간·반려 대응 일정을 별도로 확보해야 합니다.