진단: “공정성”은 UX 문구가 아니라 정산 리스크를 줄이는 설계 항목
Provably Fair를 붙이는 이유는 이미지 개선이 아니다. 운영자가 구체적으로 겪는 통증은 분쟁 비용이다. “결과가 조작됐다”는 클레임이 들어오는 순간, CS 티켓이 늘고 환불 압박이 생기며 커뮤니티에서 신뢰가 붕괴한다. 이 신뢰 붕괴는 트래픽 감소로 끝나지 않는다. 결제 차단, 파트너 정산 보류, 마케팅 채널 제한 같은 수익 파이프라인 손상으로 이어진다.
문제는 대부분의 플랫폼이 공정성을 “랜덤이니까 공정하다” 수준에서 설명한다는 점이다. RNG가 안전한지, 결과 생성 과정이 재현 가능한지, 운영자가 사후에 결과를 바꿀 수 없는지, 사용자가 사전에 결과를 예측할 수 없는지. 이 네 가지를 동시에 만족해야 분쟁이 줄어든다, 하나라도 빠지면 공정성은 주장에 머물고, 주장과 증명 사이의 간극이 운영 리스크로 남는다.
블록체인을 활용한 provably fair는 이 간극을 줄이기 위한 구조다. 핵심은 “결과 데이터”를 블록체인에 올리는 게 아니다. 결과를 만드는 입력값과 커밋 타임라인을 고정해, 운영자도 사용자도 결과를 임의로 바꾸거나 미리 알 수 없게 만드는 것. 운영 관점에서 이 구조는 분쟁 처리 시간을 줄이고, 감사 가능성을 높이며, 내부자 리스크까지 낮춘다.
분석: Provably Fair의 내부 메커니즘은 커밋-리빌과 결정적(deterministic) 난수 생성
Provably Fair의 표준 패턴은 commit-reveal이다. 서버는 “서버 시드(server seed)”를 비밀로 보관하되, 그 해시를 먼저 공개해 커밋한다. 사용자는 “클라이언트 시드(client seed)”를 제공하거나, 세션 기반으로 생성된 값을 사용한다. 마지막으로 nonce(회차 카운터)를 더해 매 라운드 입력이 달라지게 만든다. 결과는 HMAC-SHA256 같은 결정적 함수로 산출된다. 같은 입력이면 언제나 같은 출력이 나오므로 검증이 가능해진다.
여기서 운영자가 실수하는 지점이 두 가지다. 첫째, 서버 시드를 공개하는 순간까지 서버가 결과를 바꿀 수 없다는 보장이 없다. 둘째, 서버 시드를 너무 일찍 공개하면 사용자가 결과를 예측할 수 있다. commit-reveal은 “서버가 먼저 커밋하고, 나중에 리빌한다”는 시간 순서가 핵심이다. 시간 순서가 깨지면 공정성은 붕괴한다.
블록체인은 이 시간 순서를 외부에서 강제하는 도구로 쓰인다. 특정 블록 높이, 특정 트랜잭션 해시, 특정 스마트컨트랙트 이벤트를 기준으로 “언제 커밋했는지”가 공개적으로 고정된다. 운영자가 DB 로그를 보여주는 것과 다르다. DB는 운영자가 바꿀 수 있다. 체인 기록은 운영자가 단독으로 바꾸기 어렵다. 이 차이가 분쟁 비용을 줄인다.
이러한 암호학적 검증과 무결성 설계의 기본 원칙은 한국인터넷진흥원(KISA) 자료에서도 확인할 수 있다.
결정적 난수 생성 흐름(현장형 모델)
실무에서 가장 많이 쓰는 조합은 다음 4요소다. serverSeed, clientSeed, nonce, chainAnchor. chainAnchor는 블록 해시나 컨트랙트 이벤트 ID처럼 외부에서 고정되는 값이다. 결과는 HMAC(serverSeed, clientSeed + “:” + nonce + “:” + chainAnchor)로 만들고, 해시를 정수로 매핑해 확률 분포를 구성한다. 이때 “분포가 균등한가”까지 검증 포인트다. 단순히 해시 앞자리 몇 개로 모듈러 연산하면 편향이 생길 수 있다. rejection sampling 같은 보정이 필요하다.
nonce는 재사용되면 안 된다. 같은 serverSeed와 clientSeed에서 nonce가 반복되면 결과가 반복된다. 운영자 입장에서는 “패턴이 보인다”는 클레임으로 번진다. nonce는 세션 단위 증가 카운터로 관리하고, 원자적 증가(atomic increment)로 레이스 컨디션을 막아야 한다. 멀티리전 환경에서 nonce 충돌이 나면 검증 불가능한 결과가 생긴다. 그 순간 Provably Fair는 오히려 역효과다.
커밋의 의미: 해시 공개는 “사전 고정”이지 “난수 생성”이 아니다
해시를 공개했다고 공정해지는 게 아니다, 서버 시드를 고정했다는 증거만 생긴다. 진짜 공정성은 “서버 시드가 고정된 상태에서, 서버가 사용자 시드나 체인 앵커를 보고 유리한 방향으로 선택할 수 없게” 만드는 데서 나온다. 예를 들어 운영자가 라운드 시작 직전에 여러 serverSeed 후보를 만들어 놓고, 가장 유리한 해시 커밋만 선택해 올리면 사용자는 속는다. 커밋 자체는 진실인데, 선택 과정이 조작이다.
이걸 막으려면 커밋 빈도와 커밋 시점이 정책으로 고정돼야 한다. “매일 00:00 UTC에 다음 24시간 분량의 커밋을 일괄 등록” 같은 스케줄링이 필요하다. 커밋은 스마트컨트랙트에 시드 해시를 append-only로 기록하고, 커밋 시점 이후에는 수정이 불가능해야 한다. 운영팀이 임의로 커밋 타이밍을 바꾸는 순간, 공정성 설명은 무력화된다.
블록체인 적용 지점: 무엇을 온체인에 고정하고, 무엇을 오프체인에 남길 것인가
온체인에 모든 결과를 올리는 방식은 비용과 Throughput에서 깨진다. 초당 수백~수천 트랜잭션이 발생하는 플랫폼에서 결과를 매번 기록하면 가스비가 수익을 잠식한다. 블록 확정 시간(finality) 때문에 Latency도 늘어난다. 사용자 경험이 무너진다. 실무적으로는 “앵커링”만 온체인에 두고, 실제 결과 생성과 서빙은 오프체인에서 처리하는 하이브리드가 정답에 가깝다.
온체인에 올릴 후보는 세 가지다. (1) serverSeedHash 커밋, (2) 라운드 배치의 머클 루트(Merkle root), (3) 외부 랜덤 소스의 참조 값. 여기서 비용 대비 효과가 좋은 건 (1)과 (2)다. (1)은 “서버가 사전에 고정했다”를 보장한다. (2)는 “특정 시간 구간의 결과 목록이 사후에 바뀌지 않았다”를 보장한다. 둘을 같이 쓰면, 커밋과 결과 무결성의 양쪽을 잡는다.
머클 루트 방식은 운영에 특히 유리하다. 라운드별 결과를 전부 온체인에 올리지 않고, 일정 기간(예: 1분 또는 5분) 동안 생성된 결과 레코드를 머클 트리로 묶어 루트만 기록한다. 분쟁이 생기면 해당 라운드의 머클 프루프만 제공하면 된다. 데이터는 오프체인에 있어도 “이 데이터가 그때 존재했다”는 무결성 증명이 된다, 체인 비용은 낮고, 감사 가능성은 높다.
체인 앵커 선택: 블록 해시를 그대로 쓰면 생기는 오해
블록 해시는 외부 고정값처럼 보이지만, 특정 체인에서는 블록 생성자가 단기적으로 영향력을 행사할 수 있다. 완전한 조작이라기보다 “약한 편향”이 가능하다는 의미다. 특히 낮은 해시파워, 낮은 참여자 수, 또는 중앙화된 시퀀서가 있는 네트워크에서는 더 그렇다. 운영자가 “블록 해시를 썼으니 완벽히 공정”이라고 말하면, 공격 모델을 아는 사용자는 바로 반박한다.
실무에서는 블록 해시를 단독으로 쓰지 않는다. serverSeed와 clientSeed가 주된 엔트로피이고, 블록 해시는 “타임스탬프 고정 및 사후 변경 방지”의 앵커로 쓰는 편이 안전하다. 진짜 외부 랜덤이 필요하면 VRF(Verifiable Random Function)를 고려한다. 그러나 VRF는 비용과 Latency가 올라간다, 어떤 구간에서 vrf가 필요한지, 어느 구간은 커밋-리빌로 충분한지 구분하는 게 아키텍처의 역할이다.
운영 설계: 공정성은 보안, 관측성, 장애 대응까지 포함한 “시스템 계약”
Provably Fair를 도입하면 운영자가 얻는 이득은 명확하다. 분쟁의 증거를 “말”이 아니라 “재현 가능한 계산”으로 제시할 수 있다. 그 다음 단계는 운영 프로세스에 녹이는 일이다. 커밋 키 관리, 시드 로테이션, 장애 시 롤백 정책, 로그 보존, 감사 리포트 자동화. 여기서 허술하면 공정성 모듈이 오히려 서비스 중단 포인트가 된다.
키 관리부터 정리한다. serverSeed는 사실상 비밀키다. HSM 또는 KMS에 넣고, 애플리케이션 서버가 평문으로 들고 있지 않게 해야 한다. 내부자 한 명이 serverSeed를 빼가면 “미리 결과를 계산해서 유리한 행동”이 가능해진다. 외부 공격보다 내부자 리스크가 더 현실적이다. 접근 제어는 최소권한, 감사 로그는 불변 스토리지에 남겨야 한다.
시드 로테이션 정책도 수익성과 직결됩니다. 너무 자주 바꾸면 검증 UI가 복잡해지고 사용자가 따라오지 못하며, API 게이트웨이를 통한 외부 밴더사 콘텐츠 연동 기술 표준처럼 외부 연동 구간까지 함께 고려하지 않으면 리빌 타이밍 관리가 어려워집니다. 너무 늦게 바꾸면 장기 예측 공격이나 데이터 누적 분석에 노출됩니다. 현장에서는 세션 단위 또는 일 단위가 많이 쓰입니다. 중요한 건 고정된 정책과 예외 처리입니다. 장애로 인해 리빌이 지연되면 그 기간의 모든 결과가 의심받습니다. 리빌 SLA를 운영 KPI로 잡아야 합니다.
Failover와 데이터 일관성: 멀티리전에서 Provably Fair가 깨지는 방식
멀티리전 액티브-액티브 환경에서 가장 흔한 사고는 nonce 충돌과 커밋 순서 불일치다. 리전 A와 B가 각각 라운드를 처리하면서 동일한 nonce를 발급하거나, 커밋된 serverSeedHash가 서로 다른 상태로 진행되면 검증이 불가능해진다. 사용자는 “검증이 안 된다”를 “조작”으로 해석한다. 기술적 장애가 신뢰 사고로 번지는 구간이다.
해결책은 단순하다. 난수 생성에 필요한 상태를 단일한 소스 오브 트루스(예: 글로벌 트랜잭션 DB, 강한 일관성의 KV, 또는 리더-팔로워 구조)로 묶는다. latency를 줄이려고 지역별로 상태를 쪼개면, 공정성 검증이 깨진다. 처리량이 필요하면 라운드 샤딩을 하되, 샤드별로 독립된 시드 체인을 운용한다. “샤드 ID + nonce”로 유일성을 보장하는 식이다.
관측성: 공정성 모듈은 메트릭이 없으면 운영할 수 없다
Provably Fair는 암호학 기능이라서 “동작하면 끝”으로 취급되기 쉽다. 운영은 다르다. 커밋 트랜잭션 실패율, 컨트랙트 이벤트 지연, 리빌 누락, 검증 API 오류율, 라운드 생성 지연 같은 메트릭을 잡아야 한다. 특히 블록체인 앵커를 쓰면 외부 의존성이 생긴다. RPC 제공자 장애가 나면 커밋이 밀리고, 그 밀림이 바로 신뢰 리스크다.
RPC는 멀티 벤더로 구성하고, 체인별로 백업 엔드포인트를 둔다. 캐시를 잘못 두면 “옛 블록 해시”를 참조해 검증이 엇갈린다. 검증 API는 idempotent해야 하고, 같은 라운드를 여러 번 조회해도 동일한 응답을 줘야 한다. CS가 사용자를 안내할 때도 이 일관성이 중요하다.
제언: 구현 체크리스트와 흔한 함정, 그리고 “증명 가능한 운영”으로의 확장
Provably Fair는 암호학 문제로 시작다만, 최종적으로는 운영 계약으로 귀결된다. 사용자는 해시 함수가 뭔지 몰라도 “나중에 검증이 되느냐”로 판단한다. 검증이 안 되는 순간, 공정성 배지는 독이 된다. 구현 단계에서부터 “장애가 나도 검증 데이터는 남는다”를 목표로 잡아야 한다.
블록체인을 쓴다는 이유로 모든 것을 온체인에 밀어 넣을 필요는 없다. 비용과 지연이 수익을 깎는다. 반대로 온체인 기록을 최소화한다고 해서 신뢰가 자동으로 생기지도 않는다. 커밋 타이밍, 시드 선택 과정, 키 관리, nonce 일관성, 로그 무결성까지 한 묶음으로 설계해야 한다. 이 묶음이 갖춰지면 분쟁은 “감정 싸움”이 아니라 “재현 가능한 계산”으로 정리된다.
마지막으로, Provably Fair를 “마케팅 페이지”가 아니라 “감사 리포트 파이프라인”으로 취급하는 팀이 살아남는다. 월간 리포트에 커밋 트랜잭션 목록, 리빌 성공률, 검증 API 가용성(예: 99.9% 이상), 머클 루트 앵커링 성공률을 넣어라. 파트너나 결제사와의 협상에서 이 데이터는 방패가 된다. 운영자는 신뢰를 말로 사지 않는다. 로그와 증명으로 산다.
- 커밋은 스마트컨트랙트에 append-only로 기록. 커밋 스케줄을 정책으로 고정하고 예외를 금지하는 게 핵심
- serverSeed는 KMS/HSM에 보관, 애플리케이션 서버에 평문 저장 금지, 접근 감사 로그 필수
- 결과 생성은 hmac 기반 결정적 함수로 표준화. 모듈러 편향 방지 로직(rejection sampling 등) 포함
- nonce는 원자적으로 증가. 멀티리전에서는 샤딩과 유일성 규칙을 먼저 설계하지 않으면 검증 불능 사고가 난다
- 온체인은 앵커링 위주: serverSeedHash, 배치 머클 루트. 결과 전체 온체인은 비용과 Latency로 수익성 악화
- 외부 앵커(블록 해시)는 “무결성 고정”에 가깝다. 완전 랜덤이 필요하면 VRF를 선택하되 비용과 지연을 계산
- 관측성: 커밋 실패율, 리빌 누락률, RPC 지연, 검증 API 오류율을 SLO로 관리. 공정성은 운영 지표가 있어야 유지된다