XRP 레저(XRPL) 문서에 어떤 기능이 설명돼 있어도, 그 기능을 바꾸는 amendment가 메인넷에서 활성화되기 전에는 쓸 수 없습니다. XRPL은 거래 처리 규칙을 바꿀 때 amendment를 만들고 검증인이 투표합니다. 신뢰받는 검증인의 80%를 넘는 지지가 2주 동안 유지되면 활성화되고, 그 뒤로는 영구히 적용됩니다. 그래서 기능 하나를 볼 때는 ‘문서에 있음 / 개발 중 / 투표 중 / 활성’을 나눠 확인해야 합니다. 이 글은 XRPL.org의 Amendments 문서와 Known Amendments 페이지에 적힌 절차만 정리했습니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2027-01-27
amendment가 활성화되는 과정
| 상태 | 뜻 | 메인넷에서 쓸 수 있나 |
|---|---|---|
| In Development(개발 중) | 적극 개발 중인 amendment, 다른 네트워크에서는 이미 켜졌을 수 있음 | 아니오 |
| Open for Voting(투표 중) | 안정판 서버 릴리스에 포함돼 검증인이 투표할 수 있음 | 아니오(활성 전) |
| Enabled(활성) | 80% 초과 지지를 2주 유지해 통과, 이후 모든 원장에 영구 적용 | 예 |
| Vetoed(거부) | 활성화되지 않은 채 소스 코드가 제거됨 | 아니오 |
| Obsolete(폐기) | 이전 서버 버전에서 제거됐거나 제거 예정 | 아니오 |
XRPL.org는 거래 처리 방식을 바꾸는 버그 수정도 amendment가 필요하다고 적습니다. 한번 통과된 amendment를 끄려면 그것을 끄는 새 amendment가 필요합니다. 투표 중인 amendment는 다수를 얻었다가 잃는 일을 여러 번 겪을 수 있고, 2주가 지나 활성화되면 해당 원장 이후의 거래부터 적용됩니다.
문서만 보고 판단하면 안 되는 이유
Known Amendments 페이지는 개발 중 목록의 amendment가 “안정판 서버 릴리스에 포함되면 메인넷에서 투표를 시작할 수 있고, 다른 네트워크에서는 이미 활성화됐을 수 있다”고 설명합니다. 테스트넷이나 개발 네트워크에서 동작하는 기능 설명을 메인넷 기능으로 읽으면 틀릴 수 있다는 뜻입니다. 기능 소개 글이나 SDK 예제를 볼 때는 그 기능의 amendment 이름을 찾아 메인넷 상태를 따로 확인해야 합니다.
amendment blocked: 서버가 멈추는 경우
amendment가 활성화된 뒤에는 그 코드를 모르는 예전 버전 서버가 네트워크 규칙을 이해하지 못합니다. XRPL.org에 따르면 이런 서버는 원장 데이터를 잘못 해석하는 대신 ‘amendment blocked’ 상태가 되어 원장 유효성 판단, 거래 제출·처리, 합의 참여, 이후 amendment 투표를 하지 못합니다. 서버의 투표 설정과 관계없이 활성화된 amendment를 따르므로, 노드를 운영한다면 서버 버전을 맞춰야 합니다.
상태를 확인하는 곳
- XRPL.org Known Amendments: 메인넷에서 활성화됐거나 투표 중인 amendment, 개발 중 목록, 폐기 목록
- XRPL.org 상단 메뉴의 Amendment Voting Status: 투표 현황 탐색 화면
- 각 amendment 항목의 기본 투표값(Default Vote)과 이전 기능 폐지 여부
XRP의 발행·합의·준비금 구조는 XRP 레저 기초 글에서 다뤘고, 프로토콜 규칙 변경을 읽는 일반적인 방법은 프로토콜 파라미터 변경 글에 정리했습니다.
자주 묻는 질문
XRPL 문서에 나온 기능은 바로 쓸 수 있나요?
그 기능을 바꾸는 amendment가 메인넷에서 활성화됐을 때만 쓸 수 있습니다. 개발 중이거나 투표 중인 amendment의 기능은 메인넷에서 아직 동작하지 않습니다.
XRPL amendment는 어떻게 활성화되나요?
XRPL.org에 따르면 신뢰받는 검증인 80%를 넘는 지지를 2주 동안 유지하면 통과되고, 그 뒤 모든 원장에 영구 적용됩니다.
활성화된 amendment를 되돌릴 수 있나요?
통과된 amendment를 끄려면 그것을 끄는 새 amendment가 필요하다고 XRPL.org는 설명합니다.
