요약

  • draft-ietf-regext-balance-02는 이미 로그인한 EPP 클라이언트가 가용 잔액, 현금 잔액, 신용 한도, 그리고 선택적인 실행 하한과 알림 임계값을 조회할 수 있도록 합니다.
  • 반환 값은 자동화를 구동하기에 충분하지만, 건별 계정 기록, 잔액 시점, 환율 출처와 샘플링 시각, 정책 버전, 또는 이미 예약된 의무는 포함하지 않으므로 잔액이 어떻게 형성되었는지 단독으로 증명할 수 없습니다.
  • 잔액이 어떤 유료 명령의 실행 가능 여부를 결정하는 데 관여하게 되는 순간, 레지스트리와 등록기관(registrar)은 당시의 계산, 규칙, 세션, 명령 결과를 동일한 증거 사슬에 고정하는 '자금 상태 증명서'를 별도로 보관해야 합니다. 이것은 EPP에 완전한 회계 기능을 요구하는 것이 아닙니다.

흔한 시나리오를 상상해 보십시오. 등록기관이 연휴 전에 대량 갱신을 시작하고, 먼저 EPP로 잔액을 조회합니다. 서버는 양수를 내놓고, 첫 배치 명령은 성공하지만 그 뒤의 한 건은 자금 조건 때문에 받아들여지지 않습니다. 운영팀 손에는clTRID와svTRID가 있고, 재무팀 손에는 내부 장부가 있으며, 고객 지원팀에는 어쩌면 잔액 스크린샷 한 장이 있을 수 있습니다. 그러나 이 세 가지 기록을 함께 놓아도 핵심 질문에 답하지 못할 수 있습니다. 거부가 발생한 시점에, 정확히 어느 차감·예약·환율·임계값 조합이 작용하고 있었는가?

이것은 단순한 산술 오류가 아니라, 운영 프로토콜과 백엔드 회계 시스템 사이의 제도적 경계입니다.

REGEXT 워킹 그룹의 잔액 매핑은 이 경계의 한쪽 면을 표준화하려 합니다. 2026년 8월 14일에 발표된 제2판 초안은 현재 로그인한 클라이언트가 EPP를 통해 자신의 자금 상태를 얻을 수 있도록 합니다. 이는 표준 트랙으로 들어가려는 워킹 그룹 Internet-Draft이며 아직 RFC가 아닙니다. 문서의 존재 자체가 어떤 특정 레지스트리가 이미 배포했다는 증거도 될 수 없습니다.

표준화된 조회는 매우 가치 있습니다. 등록기관이 선불 자금이나 신용 여력을 판단하기 위해 서로 다른 포털에 일일이 로그인하거나, 이메일 알림을 해석하거나, 사설 인터페이스를 유지해야만 하는 상황은 바람직하지 않습니다. 그러나 숫자를 표준 프로토콜 안으로 옮긴다고 해서, 그 숫자 뒤에 있는 해석까지 자동으로 표준화되는 것은 아닙니다.

'가용'은 대차대조표가 아니라 조작 가능성입니다

초안은balanceAvailable을creditLine + cashBalance로 정의합니다. 현금 잔액은 서버 운영자가 고객을 위해 보관하는 자금이고, 신용 한도는 운영자가 고객이 사용하도록 허용한 여신입니다. 유료 청구는 음수로 기록되고, 환불과 입금은 양수로, 출금은 다시 음수로 기록됩니다.

이 정의는 애매한 '계좌 잔액'보다 엄밀합니다. 또한 가용 잔액과 미결제 잔액을 명확히 구분합니다. 후자는 고객이 얼마를 지불해야 하는지를 다루는 별도의 회계 개념이며, 현재 매핑에는 들어가지 않습니다.

하지만 XML 구조는 현금 잔액을 구성하는 등록·갱신·환불·입금·출금·조정의 각 건을 나열하지 않습니다. '기준 시점'이 명확하지 않고, 정산 기간 식별자도 없으며, 분쟁 중인 금액이 여전히 계산에 포함되어 있는지, 아직 기록되지 않은 활동이 이미 한도를 점유하고 있는지도 설명하지 않습니다. 클라이언트는 서버가 지금 무엇을 주장하는지 검증할 수 있지만, 이 응답만으로 동일한 결과를 다시 계산해 낼 수는 없습니다.

잔액이 단지 대시보드의 알림에 그친다면 이 한계는 쉽게 받아들여질 수 있습니다. 그러나 그것이 생성, 이전, 갱신 같은 유료 활동의 관문이 되는 순간, 등록기관 업무의 제어면에 들어서게 됩니다. 제어면의 결과는 간결하게 유지할 수 있지만, 추적 가능성을 잃어서는 안 됩니다.

진짜 경계는 실행 하한이 움직입니다

선택 필드executionLimit는 서버가 유료 클라이언트 트랜잭션을 거부할 수 있는 하한을 규정합니다. 기본값은 0.00이지만, 초안은 의도적으로 양수와 음수 모두를 허용합니다.

양수 하한은 0보다 위에서도 버퍼를 남겨야 함을 뜻합니다. 초안이 든 이유에는 자동 갱신 같은 서버가 주도하는 트랜잭션이 포함됩니다. 등록기관은 가용 잔액이 양수로 보여도, 레지스트리가 새로운 요청 없이도 발생할 수 있는 미래 의무를 보호하기 때문에 그 전액을 새 클라이언트 명령에 쓸 수 없을 수 있습니다.

음수 하한은 반대로 조작 가능 공간을 넓힙니다. 가용 잔액이 0 밑으로 떨어진 후에도 클라이언트는 일정 범위의 유료 트랜잭션을 계속 제출할 수 있습니다. 그 결과, 한 건의 명령이 갖는 경제적 의미는balanceAvailable만으로 읽을 수 없고, 실행 하한과 실행하려는 트랜잭션의 가격을 함께 고려해야 합니다.

응답은 현재 하한을 공개하지만, 그 하한을 만들어 낸 정책은 공개하지 않습니다. 버퍼를 승인한 것은 누구인가? 언제 변경되었는가? 자동 갱신 노출은 어떻게 추정되는가? 제품마다 다른 규칙이 적용되는가? 사고 기간의 임시 예외는 언제 만료되는가? 이러한 것들은 매핑에 없습니다.

조회 성공은 이후 명령에 대한 자금 예약도 아니고, 권한 부여 토큰도 아닙니다. 다른 세션이 먼저 자금을 소진할 수 있고, 백엔드 상태가 갱신될 수 있으며, 제품 규칙이나 비재무 정책도 거부의 원인이 될 수 있습니다. 잔액 응답은 결정의 입력일 뿐이며, 미래 결과에 대한 약속이 아닙니다.

저잔액 메시지는 큐 진입을 증명할 뿐, 대차 완료를 증명하지 않습니다

선택 필드인notificationThreshold는 관련 금액이 임계값을 넘을 때 저잔액 메시지를 생성합니다. 그basedOn속성은 실행 하한과 동일한 계산 기준을 사용해야 하며, 알림은 현금 잔액을 기준으로 하되 실제 차단은 가용 잔액을 기준으로 하는 암묵적 불일치를 방지합니다.

알림은 EPP의 폴링 큐를 그대로 사용합니다. 기본 프로토콜은 메시지에 큐 진입일과 메시지 식별자를 제공하고, 명령과 응답에는 클라이언트 및 서버 트랜잭션 식별자가 붙습니다. 클라이언트는 이어서 일반적인poll절차로 수신을 확인합니다. 초안은 매번 조회할 때 반복 경보를 울리는 대신, 임계값을 넘을 때 한 번 메시지를 만들기로 했습니다.

이는 잡음을 억제하는 데 유리하지만, 재무 대사는 아닙니다. 메시지 확인은 EPP 클라이언트가 큐 항목을 처리했다는 것만 증명하며, 재무 담당자가 경보를 이해했는지, 자금이 보충되었는지, 등록기관이 계정을 인정했는지, 동일한 임계값이 이후의 거부에서도 유효했는지를 증명하지 않습니다.

'전달', '인지', '동의', '시정'은 네 가지 별개의 일입니다. 시스템이 이들을 하나의 '알림됨' 상태로 압축하면, 분쟁이 발생했을 때 폴링 기록의 증명력을 과대평가하게 됩니다.

다중 통화는 공식을 보여주지만 환율의 출처를 숨깁니다

초안은 현금 잔액을 여러 통화 구성 항목으로 나눌 수 있게 합니다. 각 항목은 통화, 금액, 환율, 그리고 기준 통화로 환산한 값을 포함할 수 있으며, 이 환산 값들의 합은cashBalance와 같아야 합니다. 직접 호가 방식을 사용합니다. 구성 통화의 한 단위 금액에 환율을 곱하면 기준 통화 금액이 됩니다.

따라서 등록기관은 응답 내부의 합산이 성립하는지 확인할 수 있습니다. ISO 4217 코드 덕분에 계가 단위가 혼동되지도 않습니다. 그러나 응답은 환율 제공자, 시세 샘플링 시각, 반올림 정책 버전, 또는 데이터 소스가 중단되었을 때 사용된 대체 값이 무엇인지 설명하지 않으며, 잔액 전체에도 명확한 '기준 시점'이 없습니다.

자금이 실행 하한보다 훨씬 높을 때는 이러한 공백이 운영에 영향을 주지 않을 수 있습니다. 그러나 문턱에 가까워지면 사소한 환산 차이가 대량 갱신의 통과 여부를 결정할 수 있습니다. 이때 환율 인프라는 도메인 운영의 암묵적 의존성이 되면서도, 프로토콜 응답에는 그것을 검증하고 재계산하기에 충분한 출처 사슬을 남기지 않습니다.

해결책은 EPP를 외환 플랫폼으로 바꾸는 것이 아니라, 프로토콜 밖에 그때의 계산이 실제로 사용한 환율 출처와 시각을 보존하는 것입니다. 단위 표준화는 상호운용성을 해결하고, 출처 기록은 책임성을 해결합니다. 두 가지는 서로를 대체할 수 없습니다.

기밀 요구가 증거를 여러 주체의 손에 흩어 놓습니다

초안은 잔액을 기밀 정보로 다루고, 접근 제어가 현재 로그인한 클라이언트만 조회하도록 요구합니다. 이 제약은 매우 필요합니다. 한 등록기관의 현금, 여신, 경보 수준을 경쟁자가 읽어서는 안 됩니다.

문제는 이 때문에 사고 복구에 필요한 증거가 흩어지는 경우가 많다는 것입니다. 대행 운영 서비스 제공자는 EPP 세션을 쥐고 있지만 자금을 소유하지 않고, 등록기관 재무는 계정 항목을 볼 수 있지만 명령 순서를 쥐고 있지 않으며, 레지스트리는 임계값 규칙을 이해하지만 전체 백엔드 장부를 마음대로 공개할 수 없습니다. 각 주체는 진실의 일부만 가집니다.

공개 범위를 넓히는 것은 해답이 아닙니다. 더 합리적인 것은 권한이 있는 계약 당사자만 읽을 수 있도록, 좁지만 완전한 증명서를 설계하는 것입니다. 장부를 유출하는 것보다 적게 노출되면서도, 잔액 스크린샷보다 더 많은 것을 증명합니다.

명령에 실질 영향을 주는 자금 상태에는 증명서를 남기십시오

제안은 다음과 같습니다. 잔액 규칙이 유료 EPP 명령에 대해 실질적으로 경고하거나 허용하거나 거부할 때, 자금 상태 증명서를 생성해야 합니다. 이는 거버넌스 차원의 편집 제안이며, Internet-Draft가 정한 의무가 아닙니다.

첫 번째 필드 그룹은 신원과 응답을 묶습니다. 인증된 클라이언트, 세션 또는 보안 컨텍스트, 잔액 조회의clTRID와svTRID, 읽기 시각, 기준 통화, 가용 잔액, 현금 잔액, 신용 한도, 실행 하한과 알림 임계값. 여러 통화가 있다면 각 항목의 금액, 실제 환율, 환율 출처, 샘플링 시각, 반올림 규칙도 함께 저장해야 합니다.

두 번째 필드 그룹은 프로토콜이 실어 나르지 않은 계산 근거를 가리킵니다. 불변의 장부 스냅샷 또는 대차대조표 참조, 실질적 영향을 주는 미처리 차변·대변 항목, 자동 갱신 예약, 정책 버전과 임시 예외. 모든 상업적 상세를 복제할 필요는 없습니다. 통제된 참조 또는 해시만으로도 백엔드 기록이 나중에 몰래 교체되지 않았음을 증명할 수 있습니다.

세 번째 필드 그룹은 실제 명령에 묶입니다. 객체 범주, 가격 또는 요금 참조, 요청 시각, 결정 시각, 결과, EPP 결과 코드, 그리고 명령의 클라이언트 및 서버 트랜잭션 식별자. 거부가 비재무 규칙에서 비롯되었다면 명시적으로 적습니다. 조회 후 잔액이 바뀌었다면 이전 상태와 이후 상태를 모두 보존하고, 새 값이 이전 값을 덮어쓰게 해서는 안 됩니다.

이렇게 하면 '자금 부족'은 반박할 수 없는 시스템 결론에서 검증 가능한 사건 사슬로 바뀝니다. 양측은 차이가 동시성, 환산, 예약, 기록 지연, 정책 변경 때문인지, 아니면 애초에 잔액과 무관한지 판단할 수 있습니다.

프로토콜은 절제하고, 기관은 기억을 보존합니다

이 매핑은 의도적으로 조회만 제공하며, EPP의check,create,delete,renew,transfer,update에 대한 잔액 전용 동작을 정의하지 않습니다. 이 절제는 장점입니다. 레지스트리마다 과금 모델의 차이가 크고, 완전한 인보이스와 범용 예약 엔진을 공급 프로토콜에 억지로 넣어서는 안 됩니다.

진짜 위험은 XML에 필드 하나가 부족한 것이 아니라, 표준 필드가 널리 사용된 뒤 고객 지원·자동화·고객 모두가 그것을 유일한 사실로 받아들이는 동시에, 백엔드가 그것을 성립시킨 조건을 버리는 것입니다. 인터페이스가 통일될수록 규칙의 차이는 오히려 보기 어려워집니다.

제2판은 이미 중심 개념을 balance에서 balance available로 바꾸고,basedOn을 추가했으며, 네임스페이스를 0.3으로 갱신했습니다. 이름의 변화는 중요합니다. '가용'은 이것이 조건에 구애받는 조작 가능성임을 인정합니다. 다음 거버넌스 과제는 숫자를 더 아름답게 다듬는 것이 아니라, 그 시점에 실제로 제어권을 행사했던 조건들을 보존하는 것입니다.

출처