탈중앙화 로드맵의 진척은 발표된 일정이 아니라 줄어든 권한과 새로 확보된 사용자 경로로 확인합니다. 코드 공개, 테스트넷 검증, 운영망 배포, 관리자 권한 변경은 각각 다른 단계입니다. 시퀀서, 증명 시스템, 업그레이드 키, 비상조치와 출금 경로를 나누어 이전 상태와 현재 설정을 대조해야 합니다.
달성률 대신 무엇을 바꿨는지 묻습니다
‘탈중앙화 80% 완료’라는 표현은 분모가 불명확하면 독자에게 실질 정보를 주지 못합니다. 시퀀서 교체와 관리자 키 제거, 증명 코드 공개를 같은 크기의 작업으로 계산했는지 알 수 없기 때문입니다. 먼저 로드맵을 개별 기능과 권한으로 풀어 쓴 뒤 각각의 이전 상태와 현재 상태를 비교합니다.
검증자가 늘었다는 발표와 관리자 권한이 줄었다는 발표도 다른 사건입니다. 거래 순서를 정하는 역할은 분산됐어도 계약을 즉시 바꾸는 키는 남아 있을 수 있습니다. 검증자 집중도 보고서의 집계 단위를 함께 확인하면 참여자 수 증가를 모든 통제권의 분산으로 확대하는 오류를 줄일 수 있습니다.
완료 표시 옆에는 달성한 기능뿐 아니라 남아 있는 예외 권한도 적어야 합니다.
JOBCOIN 분석 기준
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 달성률 대신 무엇을 바꿨는지 묻습니다
‘탈중앙화 80% 완료’라는 표현은 분모가 불명확하면 독자에게 실질 정보를 주지 못합니다.
- 발표부터 운영망 적용까지 증거가 다릅니다
깃 저장소에 코드가 공개됐다는 것은 독자가 구현을 읽을 수 있다는 뜻입니다.
- 시퀀서와 증명 시스템의 진척을 분리합니다
시퀀서는 거래의 순서를 구성하는 역할이고 증명 시스템은 상태 변화의 타당성을 확인하는 경로와 관련됩니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
발표부터 운영망 적용까지 증거가 다릅니다
깃 저장소에 코드가 공개됐다는 것은 독자가 구현을 읽을 수 있다는 뜻입니다. 특정 도구와 설정으로 같은 결과를 만들 수 있다는 재현성, 운영망에서 그 코드가 사용된다는 배포 확인까지 자동으로 따라오지는 않습니다. 브랜치 이름이 같아도 커밋과 빌드 설정이 바뀌면 다른 결과물일 수 있습니다.
아래 표는 독자가 발표를 단계별로 기록하는 방법입니다. 프로젝트를 평가하는 공식 등급표가 아니라 확인한 사실의 범위를 좁히는 편집용 도구입니다. 특정 항목이 테스트넷에서만 동작했다면 ‘운영망 완료’ 칸을 비워 두고 어떤 후속 자료가 필요한지 적습니다.
| 발표 단계 | 찾아볼 자료 | 그 자료만으로 확정하지 못하는 것 |
|---|---|---|
| 계획 발표 | 목표·담당 범위·예상 일정 | 기능 구현이나 적용 완료 |
| 구현 공개 | 저장소·커밋·변경 설명 | 운영망 사용 여부 |
| 재현·시험 | 빌드 안내·시험 조건·결과 | 모든 환경에서의 무결함 |
| 운영망 적용 | 체인·주소·실행 거래·설정 | 예외 권한까지 제거됐는지 |
| 권한 축소 | 관리자·임계값·지연 변경 기록 | 외부 의존성 전체의 해소 |
시퀀서와 증명 시스템의 진척을 분리합니다
시퀀서는 거래의 순서를 구성하는 역할이고 증명 시스템은 상태 변화의 타당성을 확인하는 경로와 관련됩니다. 시퀀서 운영자가 늘었다는 사실만으로 누구나 증명을 제출할 수 있게 됐다고 말할 수 없습니다. 반대로 증명 코드가 공개돼도 거래 접수와 순서 결정의 운영 주체는 그대로일 수 있습니다.
2026년 2월 16일 L2BEAT가 올린 Stage 1 증명 시스템 요건 설명은 소스 공개와 검증기·프로그램의 재현 가능성을 구분합니다. 이 글은 그 게시물을 요건을 읽는 사례로 사용합니다. 해당 게시물에 나온 개별 프로젝트의 당시 충족 여부를 2026년 9월의 현재 등급으로 옮기지는 않습니다.
재현성을 주장하는 공지에서는 입력 파일, 도구 버전, 검증 키 또는 프로그램 커밋먼트를 어떤 절차로 얻는지 찾아봅니다. 안내가 있다고 실제 재현에 성공했다는 뜻은 아니므로 기사 작성자가 직접 시험하지 않았다면 ‘재현 절차를 공개했다’고 표현합니다. 독립 검증 성공과 안내문 존재의 차이를 남기는 것입니다.
관리 키와 비상 권한은 예외 조항까지 읽습니다
일상적인 업그레이드에 대기 시간이 생겼더라도 보안 위원회가 비상 상황에 즉시 바꾸는 경로가 남을 수 있습니다. 이때 ‘모든 변경이 지연된다’고 쓰면 예외를 빠뜨립니다. 일반 경로와 비상 경로의 서명 임계값, 실행 권한, 정지·재개 조건을 각각 확인합니다.
거버넌스 제안이 통과한 시각과 실제 권한이 바뀐 시각도 다릅니다. 제안이 실행 대기열에 머물거나 일부 계약만 갱신됐을 수 있습니다. 멀티시그 서명자 변경 공시처럼 제안·승인·실행의 기록을 나누면 투표 결과를 운영 설정으로 오인하지 않을 수 있습니다.
권한 변경 뒤에는 사용자가 통제 기관에 의존하지 않고 어떤 행동을 할 수 있는지가 중요합니다. 장애 시 거래를 직접 포함할 수 있는지, 출금에 어떤 증명과 대기 시간이 필요한지, 정상 경로와 비상 경로가 어떻게 다른지 묻습니다. 단순히 관리자 주소가 바뀌었다는 사실보다 실제 사용자의 선택지가 더 구체적인 정보입니다.
단계 이름에는 평가 시점과 기준 버전을 붙입니다
L2BEAT의 Stages Framework는 롤업의 탈중앙화 성숙도를 설명하는 체계입니다. 설명 원문은 높은 단계가 코드 버그까지 없는 보안 보증은 아니라고 구분하며, 기준이 계속 바뀔 수 있음을 밝힙니다. 따라서 단계 이름을 투자 위험이 제거됐다는 인증처럼 사용해서는 안 됩니다.
같은 프로젝트가 다른 시점에 다른 단계로 표시됐다면 실제 기술 변화뿐 아니라 평가 기준 개정도 확인해야 합니다. 프로젝트의 자체 ‘탈중앙화 단계’와 제3자의 분류가 같은 정의를 쓰는지도 살펴야 합니다. 둘의 이름이 비슷하다는 이유로 서로의 판단을 대체할 수 없습니다.
- 평가 기관과 기준 문서의 버전을 기록합니다.
- 프로젝트의 자체 발표와 외부 분류를 따로 적습니다.
- 시퀀서·증명·관리 키·출금 경로별 완료 증거를 연결합니다.
- 예외 권한과 보류된 항목을 누락하지 않습니다.
- 현재 등급이 필요하면 해당 프로젝트의 최신 평가 페이지를 다시 확인합니다.
진척 보고서는 변경 전후 두 문장으로 만듭니다
예를 들어 ‘이전에는 운영 팀만 수행하던 작업을 이제 공개 코드로 외부 참여자도 재현할 수 있도록 절차를 제공했다’는 설명은 확인 범위가 드러납니다. 반면 ‘완전 탈중앙화 달성’은 누구의 어떤 권한이 없어졌는지를 가립니다. 넓은 수식어 대신 이전 상태와 바뀐 동작을 연결해 적는 방식이 독자에게 유용합니다.
한 로드맵 항목이 취소되거나 대체될 수도 있습니다. 예정일을 넘겼다는 사실만으로 실패를 단정하기보다 변경 공지의 이유와 대체 계획을 확인합니다. 다만 새 계획을 과거 목표의 완료로 소급해서 표시하지 않습니다. 원래 일정, 수정 일정, 실제 적용일을 남겨야 후속 발표와 일관되게 비교할 수 있습니다.
자주 묻는 질문
테스트넷에서 작동하면 탈중앙화 단계가 올라간 건가요?
운영망의 평가와는 구분해야 합니다. 시험 환경의 코드와 권한 구성이 실제 서비스에 적용됐는지, 평가 기준에서 어떤 조건을 요구하는지 확인해야 합니다.
Stage 2이면 계약 버그가 없다는 뜻인가요?
아닙니다. L2BEAT는 단계 체계와 버그에 대한 안전성을 구분합니다. 코드 검토 범위와 증명 시스템의 위험은 별도로 읽어야 합니다.
관리 키가 멀티시그로 바뀌면 권한이 사라진 건가요?
권한을 행사하는 승인 구조가 바뀐 것입니다. 계약 변경이나 정지 권한 자체가 남는지, 서명자들이 얼마나 독립적인지까지 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
