추첨은 사람들이 믿을 때만 쓸모가 있습니다. 당첨자가 발표되는 순간 처음 나오는 질문은 늘 같습니다. 그거 조작한 거 아니에요? 이 가이드는 그 질문을 견디는 추첨을 진행하는 방법과, 나중에 그것을 증명하는 방법을 다룹니다.
다섯 단계
1단계: 아무도 응모하기 전에 자격 규칙을 정의하세요
응모가 열리기 전에 규칙을 적어 공개하세요. 누가 자격이 있나요? 한 사람당 한 번의 응모가 적용되나요? 직원이나 가족은 제외되나요?
분쟁이 무작위성에 관한 것인지 규칙에 관한 것인지를 결정하는 단계입니다. 대부분의 “불공정한 추첨” 불만은 사실 규칙에 대한 의견 차이이며, 어떤 무작위 선택기도 그것을 해결하지 못합니다.
2단계: 추첨 전에 풀을 확정하세요
응모를 마감한 뒤 최종 목록의 스냅샷을 찍으세요. 아직 늘어날 수 있는 목록에서 추첨하지 마세요. 마감을 놓친 사람이 자신도 응모했을 것이라고 주장할 수 있습니다.
사진 가져오기를 쓴다면 이때 추출된 이름을 꼼꼼히 확인하세요. 잘못 읽은 이름은 정당한 이의 제기 대상이며, 추첨 전에 고치는 것이 훨씬 저렴합니다.
3단계: 중복 방지를 켜세요
같은 계정의 응모가 두 개면 풀의 의미가 없어집니다. 중복 이름 방지를 켜서 도구가 반복을 걸러 내게 하세요. 규칙이 가중 응모나 여러 장의 티켓을 허용한다면 대신 가중 추첨을 사용하세요. 가중치를 우연이 아니라 명시적으로 만들어 줍니다.
4단계: 당첨자 수와 제거 동작을 설정하세요
여러 상품을 뽑는 경우 추첨 전에 당첨자 수를 정하고 당첨자를 목록에서 제거를 켜서 같은 사람이 두 번 당첨되지 않게 하세요.
단일 상품을 연속으로 뽑는 경우 — 뽑고, 발표하고, 다시 뽑기 — 발표 중에는 제거 동작을 꺼 두고 규칙에 따라 조정하세요. 누군가 지켜보는 도중이 아니라 시작 전에 정하세요.
5단계: 추첨하고 기록하고 공개하세요
풀이 보이는 상태에서 추첨을 진행하세요. 참가자 목록을 포함한 결과 패널 스크린샷을 저장하세요. 둘을 함께 공개하세요.
그 스크린샷이 증거입니다. 추첨 순간에 누가 자격이 있었는지를 보여 줍니다.
결과가 실제로 무작위인 이유
대부분의 도구는 Math.random()을 사용합니다. 유사 난수 생성기입니다. 빠르지만 결정적입니다. 내부 상태를 원칙적으로 재구성해 앞으로의 모든 결과를 예측할 수 있습니다. 커피 타임 추첨에서는 아무도 신경 쓰지 않습니다. 상품, 유료 프로모션, 법적 효력이 있는 일에는 잘못된 토대입니다.
RandomSelect는 브라우저의 crypto.getRandomValues()를 사용하며, 운영체제의 암호학적 원본에서 엔트로피를 가져옵니다. 중요한 속성은 다음과 같습니다:
- 독립성 — 각 추첨은 이전 및 이후 추첨과 무관합니다
- 조작할 시드 없음 — 사용자 입력이나 타이밍으로 결과를 조종할 수 없습니다
- 균등 분포 — 모든 이름의 확률이 정확히 같습니다
전체 설명은 플랫폼의 감사 페이지에서 볼 수 있습니다: 공정성 검증 방법.
대부분의 논쟁을 끝내는 세부 사항
애니메이션은 장식입니다.
당첨자는 룰렛이 움직이기 전에 계산됩니다. 그런 다음 애니메이션이 그 미리 정해진 결과를 향해 재생됩니다.
이것이 중요한 이유는 아무도 클릭 타이밍을 맞추거나, 룰렛이 도는 속도를 보고, 버튼을 언제 “누를지” 판단해서 결과에 영향을 줄 수 없다는 뜻이기 때문입니다. 이용할 타이밍 입력이 없습니다. 타이밍은 아예 입력이 아니기 때문입니다.
빠른 클릭이 느린 클릭과 다른 당첨자를 냈다고 누군가 주장한다면 직접 시험할 수 있습니다. 같은 추첨을 서로 다른 클릭 타이밍으로 백 번 실행해 보세요. 분포는 달라지지 않습니다.
공개적으로 검증 가능하게 만들기
상품이 걸린 브랜드 캠페인처럼 중요한 추첨에서는 다음 네 가지를 공개하세요:
- 자격 규칙 — 응모가 열리기 전에 작성한 것
- 확정된 최종 참가자 목록
- 무작위 선택 방식 — 도구 이름을 밝히고 암호학적 난수를 사용한다는 점을 명시
- 기록 — 목록이 보이는 상태의 추첨을 담은 영상이나 스크린샷
이것이 완전한 감사 기록입니다. 누구든 규칙이 먼저 공개되었는지, 기록된 목록이 확정했다고 주장하는 풀과 일치하는지 확인할 수 있습니다.
이의 제기 대응
“애니메이션이 너무 빨라서 확인할 수 없었어요.” 당첨자가 애니메이션 전에 정해진다는 점을 짚고, 목록이 보이는 스크린샷을 제시하세요.
“당신 도구가 다른 순서를 골랐을 수도 있잖아요.” 그러면 같은 목록으로 추첨을 다시 실행하세요. 도구가 적용한 무작위화는 순서 변경으로 드러나며, 누구든 코드를 들여다보지 않고도 관찰할 수 있습니다.
“나는 응모한 적이 없어요.” 이것은 무작위성 문제가 아니라 규칙 문제입니다. 공개된 자격 규칙과 응모 시각을 가리키세요.
“사진에서 이름을 잘못 읽었어요.” 추첨 전에 수정된 목록을 익명 처리해 다시 공개하세요. 사진 가져오기를 확정 이후가 아니라 확정 전에 검증해야 하는 이유가 바로 이것입니다.
흔한 실수
- 살아 있는 목록에서 추첨하기 — 응모가 먼저 마감되어야 합니다
- 중복 방지 없음 — 여러 번 응모한 사람의 당첨이 가장 흔한 분쟁입니다
- 추첨 도중 상품 수 발표하기 — 전에 정하고 진행 중에 기록하세요
- 목록 없이 결과 공개하기 — 스크린샷이 증거입니다
- 불편한 결과를 다시 뽑기 — 다시 뽑은 추첨은 새로운 추첨이며, 이전 것이 무효라고 주장하는 것은 피하려는 의심을 정확히 불러옵니다
직접 진행할 준비가 되셨나요? 랜덤 추첨이나 이름 룰렛을 여세요. 둘 다 같은 암호학적 난수를 사용하므로 공정성 논리가 똑같이 적용됩니다.
RandomSelect.net — 사람들이 검증할 수 있는 추첨.