공개하라고 했더니 오류가 드러났다

29일차에 추천 알고리즘 투명성을 다루면서 "알고리즘을 공개해도 투명해지지 않는다"고 썼습니다. 블랙박스라 공개 자체가 의미를 갖기 어렵다는 얘기였죠.

그런데 비슷한 시기에 시행된 다른 투명성 규제는 꽤 분명하게 작동했습니다. 확률형 아이템 정보공개 의무화입니다. 둘을 비교해보면 투명성 규제가 언제 작동하는지가 보입니다.

2024년 3월부터

게임산업진흥법 개정으로 2024년 3월 22일부터 확률 공개가 의무화됐습니다. 유예 기간 없이 바로 시행됐고요.

대상 범위가 넓습니다. 직접적이든 간접적이든 유상으로 구매 가능한 아이템은 전부 포함되고, 온전히 무상으로 얻는 것만 제외됩니다. 해외 게임사도 대상입니다.

유형별로 표시 방법이 정해져 있습니다. 캡슐형(뽑기), 강화형(성공 확률), 합성형(조합), 그리고 수량·기간 제한형, 확률변동형, 천장형 같은 기타 유형까지요.

눈여겨볼 조항은 단계별 개별 확률 공개입니다. 합성 결과에 따라 등급이 나뉘고 등급에 따라 나오는 아이템이 달라지는 구조라면, 각 단계의 확률을 모두 공개해야 합니다. 전체 확률 하나만 보여주고 넘어갈 수 없게 막은 거죠.

제재는 시정 요청에서 시작해 시정 권고·명령으로 이어지고, 명령을 이행하지 않으면 2년 이하 징역 또는 2천만원 이하 벌금입니다. 고의성이 인정되면 손해액의 2배 이내로 배상하는 징벌적 손해배상 조항도 들어갔습니다.

공개가 드러낸 것

시행 직후 흥미로운 일이 벌어졌습니다. 자율규제 시절에 공개했던 확률을 법 시행에 맞춰 재검토하는 과정에서 잘못 표기돼 있던 사례들이 발견된 겁니다.

한 사례에서는 특정 아이템이 0.25% 확률이 아니라 최소 149회를 뽑지 않으면 획득할 수 없는 구조였다는 게 드러났습니다. 이후 확인 결과 데이터 추출 과정의 설정 오류로 획득 불가능한 아이템 31종이 목록에 포함돼 있었던 것으로 파악됐고, 수정 후 실제 획득 확률이 올라갔습니다. 해당 회사는 이용자에게 재지급과 추가 보상을 했고, 확률 자동 공개 시스템을 도입하겠다고 밝혔습니다.

이 사건이 시사적인 이유는 의도적 조작이 아니라 내부에서도 모르던 오류였다는 점입니다. 외부에 공개할 의무가 생기자 내부 검증이 강제됐고, 그 과정에서 문제가 드러난 거죠.

규제의 효과를 "나쁜 짓을 막는 것"으로만 보면 이 부분을 놓칩니다. 공개 의무는 감시 기능과 별개로 자체 점검을 강제하는 기능을 합니다. 40일차에서 "복원해본 적 없는 백업은 백업이 아니다"라고 썼는데, 확률도 외부에 내보일 일이 없으면 검증할 계기가 없었던 셈입니다.

왜 이 규제는 작동했나

알고리즘 투명성 규제와 비교하면 차이가 선명합니다.

공개 대상이 숫자였습니다. 확률은 그 자체로 해석 가능한 값입니다. 반면 추천 알고리즘은 가중치를 공개해도 사람이 읽어낼 수 없습니다.

검증이 가능합니다. 이용자가 데이터를 모으면 공개 확률과 실제 결과를 비교할 수 있습니다. 실제로 커뮤니티에서 표본을 모아 검증하는 문화가 이미 있었고요. 감시 주체가 규제기관만이 아니라는 게 중요합니다.

기준이 명확합니다. 문체부가 해설서를 배포해 유형별 표시 방법을 구체적 예시로 제시했습니다. "투명하게 공개하라"가 아니라 "이 유형은 이렇게 표시하라"였습니다.

즉 투명성 규제는 공개 대상이 검증 가능한 형태일 때 작동합니다. 무엇을 공개하라고 할지가 규제 설계의 핵심이라는 뜻이죠. 35일차 앱스토어 규제에서 "요율이 아니라 무엇에 부과하는가가 핵심"이라고 썼는데, 같은 얘기입니다.

이용자 쪽에서도 읽는 법이 필요하다

공개가 됐다고 해서 해석까지 쉬워진 건 아닙니다. 확률 표기를 잘못 읽는 경우가 여전히 많습니다.

0.25%를 "400번이면 나온다"로 받아들이는 게 대표적입니다. 각 시도는 독립이라 그 숫자는 기댓값일 뿐이고, 분포상 훨씬 많이 시도하는 경우가 상당수 나옵니다. 단계가 중첩된 강화·합성에서 최종 확률이 체감보다 훨씬 낮아지는 것도 같은 맥락이고요.

그래서 공개 의무와 별개로 천장 유무를 명시하는 게 실질적인 정보가 됩니다. 상한이 있는지 없는지가 지출 예측 가능성을 가르니까요.

개발 관점에서

게임을 만드는 입장이라면 실무적으로 몇 가지가 요구사항이 됩니다.

확률 산출의 단일 출처. 기획 문서의 값과 서버 설정값, 공개 페이지의 숫자가 따로 관리되면 어긋납니다. 위 사례도 수동 추출 과정에서 오류가 났습니다. 서버 설정에서 직접 생성해 게시하는 자동화가 안전합니다.

단계 구조의 표현. 합성이나 강화처럼 중첩된 확률은 각 단계를 분리해 노출해야 합니다. 데이터 모델 단계에서 단계가 구분돼 있지 않으면 나중에 추출이 어렵습니다.

노출 채널 일관성. 게임 내 화면, 홈페이지, 광고물까지 같은 값이 나가야 합니다. 어느 하나만 업데이트가 누락돼도 위반이 됩니다.

변경 이력. 확률을 조정했다면 언제 무엇이 바뀌었는지 기록이 필요합니다. 분쟁 시 입증 자료가 됩니다.

남은 논점

업계 쪽에서는 공개 범위가 넓어지면서 검수 부담이 늘었다는 얘기가 나옵니다. 장비 서브 옵션 확률처럼 세부적인 부분까지 공개 대상이 되면서 추가 작업이 생겼다는 거죠.

반대로 이용자 쪽에서는 공개만으로 충분하냐는 지적이 있습니다. 확률을 알려줘도 사행성 구조 자체는 그대로니까요. 해외에서는 확률형 아이템을 도박 규제로 다루는 논의도 있습니다.

관련 소송도 진행 중입니다. 선고가 여러 차례 연기되면서 결론이 나지 않은 상태고요.

정리

확률 공개 의무화는 투명성 규제가 작동한 드문 사례입니다. 그리고 그 이유가 "공개 대상이 숫자였고 검증이 가능했기 때문"이라는 점이 다른 영역에도 적용될 만한 교훈이라고 봅니다.

무엇을 공개하라고 할 것인가. 이 질문에 답하지 못하면 투명성 규제는 선언으로 끝납니다.