로드맵
무엇을 어떤 순서로 만들지, 그리고 왜 그 순서인지를 적었습니다. 기준일은 2026년 7월이고, 지금 동작하는 범위는 기능 전체 페이지에서 확인할 수 있습니다.
우선순위 원칙
기능을 넓히기 전에 이미 한 주장을 실체로 만듭니다. 지금 호패는 “살아있는 인증마크”라고 말하면서 재대사를 자동으로 돌리지 않고, “감사 가능한 증적”이라고 말하면서 증적 원본을 영구 보존하지 않습니다. 그 간극을 메우는 것이 다음 단계의 전부입니다.
- ·1순위 — 이미 한 주장과 구현의 간극 (재대사 데몬, 증적 저장소)
- ·2순위 — 신뢰의 근거 (벤더 검증, 주소 스크리닝, 운영 통제)
- ·3순위 — 표면 확장 (KYB·KYA, 속성 어테스테이션, 다른 체인)
한눈에 보기
| 시기 | 주제 | 핵심 산출물 |
|---|---|---|
| ~2026.07 | MVP — 발급·검증·폐기의 전 구간 온체인화 | 컨트랙트 4종 배포·Verified, SDK 알파, 데모 웹, ZK 커밋먼트와 첫 술어 회로 |
| 2026.08~09 | 실체화 — 자동화와 검증의 근거 | 일일 재대사 데몬, 증적 저장소, 주소 스크리닝, L2 실발급, 케이스 통제 |
| 2026.10 | 공개 검증 — 현장에서 돌려보는 데모 | 참여형 발급·폐기 시연, 라이브 KPI, 브라우저 ZK 증명 |
| 2026.11~2027.Q1 | 상용화 — 기관이 쓸 수 있는 운영 | L3·금융등급, KYB, 화이트리스트 운영, 컨트랙트 v2, 외부 감사 |
| 2027~ | 확장 — 법인·에이전트·다른 체인 | KYA 캐스케이드, 트래블룰 연동, 비연결형 증명, 다른 체인 이식 |
시점은 목표이지 약속이 아닙니다. 벤더 계약과 규제 일정에 의존하는 항목이 많아, 순서는 지키되 시기는 움직일 수 있습니다.
트랙 1 — 심사와 등급
가장 자주 받는 질문이 “그래서 실제 검증은 언제 붙나”입니다. 등급은 검증 강도의 약속이라, 벤더가 붙기 전에는 상위 등급을 발급하지 않습니다. 그래서 지금 발급되는 등급은 L1 하나입니다.
| 단계 | 내용 | 열리는 것 |
|---|---|---|
| 지금 | 지갑 소유권 서명 + 본인 선언 정보 커밋 + OFAC·UN 실명단 대사 + 위험평가 + 일일 재대사 | L1 본인 선언 라이브 |
| P1 · 1개월 | 휴대폰 본인확인 중계사 계약 + 벤더 어댑터 인터페이스 + 동일인(CI) 인덱스 | L2 명의확인 실발급 — 국내 실명 명의 기반 첫 어테스테이션 |
| P2 · 3개월 | eKYC 풀스택 연동(신분증 OCR·진위확인·사본판별·안면 라이브니스) + 수동심사 큐 | L3 신원증명 실발급 — 비대면 실명확인 2요소 구성 |
| P3 · 6개월 | 1원 계좌인증 + EDD 설문 운영(거래목적·자금출처) + 위험기반 평가 | 금융등급 + 기관 파트너 화이트리스트 시범 |
| P4 | 모바일 신분증 검증 연동, KYB(법인·실소유자), PEP·부정적 언론 스크리닝 | 법인 자격과 최고 보증수준 신원 |
P1~P4의 기간은 벤더 계약 착수 시점 기준입니다. 계약 심사와 연동 리드타임이 그대로 일정이 되기 때문입니다.
벤더는 등급마다 복수로 붙입니다. 한 곳이 장애를 겪어도 발급이 멈추지 않도록 어댑터 인터페이스를 먼저 만드는 이유입니다. 검증 불가일 때는 발급하지 않습니다 — fail-closed는 여기서도 같습니다.
트랙 2 — 수명주기 자동화
| 항목 | 내용 | 왜 이 순서인가 |
|---|---|---|
| 일일 재대사 데몬 | 제재 리스트 델타 수신 → 활성 어테스테이션 전체 대사 → 히트 시 케이스 생성 | 제품의 핵심 주장이 여기 걸려 있습니다. 1순위입니다. |
| 지갑 주소 스크리닝 | OFAC 디지털자산 주소 목록과 믹서·해킹 자금 근접도 | 사람이 깨끗해도 지갑이 더러울 수 있습니다. 다른 축이라 둘 다 필요합니다. |
| 벤더 웹훅 소비 | 벤더의 지속 모니터링 결과 변경을 이벤트로 수신 | 벤더 연동(트랙 1 P1)이 선행돼야 합니다. |
| 데몬 헬스 지표 | 마지막 동기화 시각을 콘솔과 SDK에 노출, 지연 시 알림 | 모니터링이 멈추면 마크의 “살아있음”도 멈춥니다. 그 사실을 숨기지 않기 위해서입니다. |
| 만료 알림과 갱신 | D-45 / D-7 알림 → 재검증 유도 → 갱신 발급 | 조용히 lapsed 되면 사용자는 이유를 모른 채 차단됩니다. |
| 위험기반 재이행 주기 | 고위험 1년 / 중·저위험 3년 스케줄러 | 위험 평가(트랙 1 P3)의 출력이 입력입니다. |
| 배치 폐기 | 대량 명단 갱신 시 N건을 한 트랜잭션으로 | 재대사 데몬이 돌기 시작해야 필요해집니다. |
트랙 3 — 증적과 감사
| 항목 | 내용 |
|---|---|
| 변조 방지 증적 저장소 | 발급·폐기·케이스·운영자 행위를 이전 해시로 물린 체인에 적재하고 WORM 성격 스토리지에 영구 보존합니다. 온체인 evidenceHash의 원본이 이것입니다. |
| 공개 증적 검증기 | 해시를 입력하면 대응 레코드(비밀정보 제외)와 재계산 결과를 보여줍니다. 감사 가능성을 주장이 아니라 화면으로 보여주는 항목입니다. |
| 서버측 SLA 측정 | 기점을 리스트 발행·웹훅 수신 시각으로, 종점을 폐기 블록 타임스탬프로 기록합니다. 현재 데모 측정은 감사 대응용이 아닙니다. |
| 감독·감사 리포트 | 기간별 발급·폐기·SLA·케이스 통계와 증적 패키지 익스포트. |
| 보존·파기 정책 | 증적 5년 보존, 개인정보 미보유 원칙의 데이터 맵 문서화. |
트랙 4 — 온체인 (컨트랙트 v2)
배포된 컨트랙트는 고칠 수 없으므로, 변경이 필요한 항목을 모아 한 번에 올립니다. 메인넷 이전이 그 시점입니다.
| 항목 | 내용 | 지금 |
|---|---|---|
| SUSPENDED 상태 | 조사 중 일시정지와 복원. 오탐 대응의 전제입니다. | active / revoked / lapsed 3상태 |
| 폐기 키 분리 | 발급 키가 유출돼도 폐기는 살아 있어야 합니다. 폐기는 fail-safe 방향이라 더 넓게 열어둡니다. | 발급자 = 폐기자 (의도적 보류, 기록됨) |
| 발급 한도·서킷브레이커 | 키 탈취 시 피해 반경을 온체인에서 제한합니다. | 미탑재 (테스트넷 기간 의도적 보류) |
| 배치 발급·폐기 | 대량 처리 시 가스와 SLA를 동시에 개선합니다. | 단건만 |
| KYA 캐스케이드 | 에이전트 어테스테이션이 refUID로 주인의 KYC를 참조해 연쇄 폐기됩니다. | refUID 미사용 |
| 속성 어테스테이션 | 거주 관할·연령대·투자자격 같은 판정형 속성 확장. | KYC·KYB·KYA 3종 |
| 멀티시그 owner | 레지스트리 소유권을 단일 키에서 분리합니다. | 단일 키 + 2단계 이전 |
트랙 5 — SDK와 통합
| 항목 | 내용 |
|---|---|
| 폐기 푸시 | 웹훅과 이벤트 구독. 판정을 캐시하는 dApp에도 폐기가 즉시 도달해야 “생태계 동시 차단”이 참이 됩니다. |
| 오프체인 검증 REST | 발급사 서명과 유효시각이 붙은 응답. 체인을 직접 다루지 않는 은행·발행사 백오피스용입니다. |
| 배치 조회 | multicall 기반 다건 판정 — 수취인 목록과 에어드랍 필터링. |
| EIP-1271 · AA 지갑 | 스마트 계정 서명 검증과, 소유자가 바뀐 계정의 신원 바인딩 재확인 정책. |
| SIWE 표준화 | 현재 EIP-191 서명을 EIP-4361 형식으로 정렬해 지갑·도구 호환성을 넓힙니다. |
| 게이트 헬퍼와 예제 | 선언형 <HopaeGate>, DEX 풀·대출·NFT 민팅 통합 레퍼런스. |
| npm 배포 | 현재 알파는 저장소 직접 참조입니다. 공개 배포와 버전 정책이 남았습니다. |
트랙 6 — 프라이버시와 ZK
| 단계 | 내용 | 상태 |
|---|---|---|
| A. ZK-ready | 스키마 v2(claimsRoot·auditRef), 커밋먼트 모듈, 선택공개, 제3자 검증 경로 3종 | 라이브 |
| B. 첫 술어 | age_over 회로 → 온체인 검증자 → 게이트. 온체인 경로는 동작하고 브라우저 증명 UI와 회로 외부 리뷰가 남았습니다. 완성형은 결제·회원가입의 성인확인입니다 — 이용자는 생년월일 대신 증명을 내고, 서비스는 가스 없는 verifyAdult 조회 한 번으로 확인합니다. | 개발 중 |
| C. 비연결형 | 멤버십 트리와 nullifier 게이트. 지갑 주소를 드러내지 않고 자격만 증명하고, 서비스별 1인 1계정을 강제합니다. | 로드맵 |
| D. 상용화 | t-of-n 감사 에스크로, 회로 외부 감사, 결과 어테스테이션, 여권류 증거 소스 검토 | 로드맵 |
폐기 즉시성을 ZK 경로에서도 유지하는 것이 설계의 축입니다. 증명이 아무리 유효해도 게이트가 레지스트리 상태를 다시 확인하므로, 폐기된 지갑의 증명은 통과하지 못합니다.
트랙 7 — 생태계
- ·지갑 탑재 — 지갑 홈의 인증마크와 송금 전 수취인 확인. 화면 목업까지 나와 있고, 다음은 실제 통합 협의입니다.
- ·cohort 통합 — 같은 프로그램의 팀에 SDK와 통합을 무료로 지원합니다. 첫 사용자이자 지표를 함께 만드는 관계입니다.
- ·트래블룰 연동 — 수취인 사전 확인 신호를 기존 솔루션에 제공합니다. 기준금액이 낮아질수록 개인 지갑 확인 수요가 커집니다.
- ·발행사·기관 — 화이트리스트 수명주기 운영과 증적 리포트 위탁. 원화 스테이블 발행 개시가 이 트랙의 트리거입니다.
- ·다른 체인 — EAS가 배포된 OP Stack 체인이면 같은 구조로 옮길 수 있습니다. 우선순위는 GIWA 다음입니다.
진척을 무엇으로 재나
발급·갱신·폐기가 전부 온체인 트랜잭션이라, 제품 지표가 곧 체인 지표입니다. 콘솔에서 실시간으로 볼 수 있습니다.
| 지표 | 의미 |
|---|---|
| 발급 수 | 누적 어테스테이션 |
| 활성 호패 수 | 폐기·만료를 제외한 실제 검증 사용자 |
| 게이트 통과 트랜잭션 | 호패를 읽고 실행된 트랜잭션 — 재사용의 실측치 |
| 통합 dApp 수 | 판정을 읽는 서비스의 수 |
| 폐기 SLA | 자격 상실 인지부터 온체인 반영까지 걸린 시간 |
| 데몬 헬스 | 마지막 제재 리스트 동기화 시각 (자동화 이후) |
하지 않기로 한 것
- ·본인확인기관이 되는 것 — 검증 실행은 계속 공인 벤더에 위임합니다.
- ·자산 동결 기능 — 폐기는 자격의 철회입니다. 잔고에 손대는 기능은 만들지 않습니다.
- ·개인정보의 온체인 기록 — 어떤 형태로도, 암호화해서도 올리지 않습니다.
- ·한도 정책의 대행 — 등급별로 무엇을 열어줄지는 각 dApp이 정합니다.
- ·기록 서비스와의 경쟁 — 같은 EAS 표준 위에 있어 연동이 가능합니다. 우리 몫은 검증 앞단의 파이프라인과 뒷단의 수명주기입니다.
열려 있는 결정
| 결정 | 선택지 | 기본값 |
|---|---|---|
| 첫 eKYC 벤더 | 국내 원벤더(계좌인증까지 묶음) vs 글로벌(확장 우선) | 국내 원벤더 — 계약·연동 비용이 절반 |
| 동일인 지갑 상한 | L1 3개 / 상위 2개 vs 무제한 | 등급별 상한을 두는 쪽 |
| 재이행 주기 | 전 등급 12개월 vs 위험등급별 1년·3년 | 초기 12개월 후 완화 |
| 멤버십 회로 | 기존 프로토콜 재사용 vs 자체 구현 | 자체 구현 — 스택 단일화 |
| 폐기 키 분리 시점 | 컨트랙트 v2 vs 그 이전 | 컨트랙트 v2 |
지금까지 한 것
온체인
- ·HopaeRegistry·GatedKRW·AgeVerifier·HopaeZkGate GIWA Sepolia 배포, 네 개 모두 Verified
- ·테스트 37종 — 유닛, fuzz, invariant 2종, 실제 증명 in-EVM 검증
- ·재발급 supersede, 2단계 소유권, UID 직접 폐기 경로
서비스와 SDK
- ·가스리스 발급·폐기 API + EIP-191 소유권 서명 검증(10분 TTL)
- ·
@hopae/sdk알파 — 코어, React 훅과 배지, 클레임 커밋먼트 모듈 - ·데모 웹 5탭 — 발급·검색·송금·크리덴셜 검증·콘솔
프라이버시
- ·스키마 v2 라이브 — 발급마다 claimsRoot와 auditRef 기록
- ·
age_over회로의 온체인 검증 성공, 폐기 지갑의 증명 revert 실증 - ·SDK 없이 재현 가능한 독립 검증 스크립트와 절차 공개