비즈니스 현실8 분 읽기

"51만 자가 비어 있다"고 적어 두고, 기준을 바꾸니 1만 9천 자였습니다

안드로이드 스토어 전체 설명 196개 슬롯이 한도의 34%만 쓰고 있었습니다. 미사용 51만 자를 '가장 큰 유입 면적'이라고 보고서에 적었는데, 그 숫자는 잘못 잰 것이었습니다. 상한 대신 원문 대비로 재니 결손은 1만 9천 자였고 대부분이 소수 슬롯에 몰려 있었습니다.

#metrics#aso#audit#gotchas#first-principles
같은 데이터를 두 그래프로. 왼쪽은 4,000자 상한 대비라 막대들이 전부 3분의 1쯤 차 있어 다 비어 보이고, 오른쪽은 원문 대비 언어 밀도로 정규화해 대부분이 기준선에 붙어 있고 두 개만 바닥에 붙어 빨간 테두리가 쳐져 있음.
총량으로 재면 '다 채워야 한다'는 결론밖에 안 나옵니다. 그건 틀린 결론입니다.

당신이 마지막으로 보고서에 적은 큰 숫자는, 무엇 대비 큰 숫자였습니까?

저는 그 질문을 안 하고 "미사용 51만 자"를 적어 넘겼습니다. 그 숫자로 계획을 세우면 하루가 통째로 잘못된 방향에 갑니다.

처음 잰 것

안드로이드 스토어 리스팅에서 가장 큰 필드는 전체 설명입니다. 한도가 4,000자입니다. 앱 14개, 196개 슬롯을 세어 보니 34%만 쓰고 있었습니다.

미사용 = 4000 - len(본문)
합계   = 516,000자

그래서 보고서에 이렇게 적었습니다. "가장 큰 유입 면적."

그 숫자는 잘못 잰 것이었습니다

4,000자는 상한이지 목표가 아닙니다.

좋은 설명이 2,000자면 나머지 2,000자는 "비어 있는" 게 아니라 "안 쓴" 것입니다. 게다가 검색엔진은 길이가 아니라 내용을 봅니다. 채우려고 낱말을 늘리면 오히려 감점됩니다.

이 오독의 진짜 비용은 숫자가 틀린 게 아닙니다. 그 숫자로는 "다 채워야 한다"는 결론밖에 안 나온다는 것입니다. 196개 슬롯을 다 늘리는 작업 계획이 나오고, 그건 틀린 계획입니다.

기준을 바꿔서 다시 쟀습니다

물어야 했던 건 이거였습니다. "이 로케일이 영어 원문 대비 내용을 잃었는가."

번역이 원문의 몇 할인지를 보되, 언어별 밀도를 감안했습니다.

언어 영어 대비 기대 밀도
중국어 0.45
일본어 0.55
한국어 0.60
태국어 0.80
기대치 = len(영어_본문) * 밀도계수[언어]
결손   = max(0, 기대치 - len(본문))

그렇게 재니 결손은 18,924자였습니다. 51만이 아니라 1만 9천. 27분의 1입니다.

그리고 더 중요한 건, 그 대부분이 소수의 슬롯에 몰려 있었다는 겁니다. 한 앱 하나가 6,793자를 차지했습니다.

진짜 결함은 셋이었습니다

정말 빈 슬롯을 찾는 건 별도 검사입니다. 링크와 법적 문구를 지운 뒤 300자 미만이면 본문이 없는 것으로 봅니다.

  1. 한 앱의 스페인어 설명은 본문이 통째로 없었습니다. 법적 링크 두 줄, 102자가 전부였습니다.
  2. 프랑스어는 455자짜리 토막인데, 그 안에 이 앱에 없는 다른 플랫폼 기능을 연동한다고 적혀 있었습니다. 이건 페이월이 없는 기능을 팔고 있던 것과 같은 계열입니다.
  3. 24개 슬롯의 제목이 영어 원문 그대로였습니다.

세 개입니다. 196개가 아니라. 총량으로 재면 어디를 고칠지 안 보입니다.

당신이라면 어느 숫자를 보고하시겠습니까

두 숫자 다 사실입니다. 상한 대비 51.6만도 맞고, 원문 대비 1만 9천도 맞습니다. 차이는 어떤 행동을 부르는가입니다.

  • 51.6만 → "196개 슬롯을 다 늘려라"
  • 1만 9천 → "이 두 슬롯에 본문이 없다"

지표를 고를 때 물어야 하는 건 "이 숫자가 정확한가"가 아니라 **"이 숫자가 부르는 행동이 옳은가"**입니다.

같은 주에 면적이 진짜로 비어 있던 경우도 있었습니다. 거기서는 검증기가 실한도의 3분의 1에서 자르고 있어서 비어 있는 게 진짜 결함이었습니다. 두 사례의 차이가 이 글의 요지입니다 — 똑같이 "3분의 1만 찼다"로 보여도, 상한이 인위적인지 자연스러운지에 따라 결론이 정반대입니다.

자가진단 3줄

  1. 당신의 지표는 상한 대비입니까, 기준선 대비입니까? 상한 대비는 거의 항상 "다 채워라"를 부릅니다.
  2. 그 숫자가 소수에 몰려 있습니까, 고르게 퍼져 있습니까? 분포를 안 보면 총량은 어디를 고칠지 못 알려줍니다.
  3. 보고서에 숫자를 쓸 때 단위와 기준을 같이 적었습니까? 안 적으면 읽는 사람이 그 숫자로 하루를 계획합니다.

솔직한 부분

이 오독을 보고서에 적어서 넘겼습니다. 사용자가 그걸 근거로 하루 작업을 계획할 수 있었습니다. 숫자를 인용할 때 단위와 기준을 같이 적지 않으면, 틀린 숫자는 그대로 틀린 계획이 됩니다. 이건 제가 만든 손해입니다.

밀도 계수(0.45~0.80)는 제가 정한 값이고 근거가 관찰뿐입니다. 실제 정보 밀도를 잰 것이 아니라 "이 정도면 내용이 같다고 보자"는 기준선입니다. 이 계수가 틀리면 결손 수치도 같이 틀립니다. 즉 1만 9천도 확정값이 아닙니다.

기준을 바꾼 뒤에도 남은 14,332자 중 상당수는 여전히 정상적인 압축 번역일 가능성이 큽니다. 절 단위로 대조해 봐야 확실해지는데, 거기까지는 안 갔습니다.

지금 대시보드에 "미사용 X"라는 지표가 있으시면, X를 무엇으로 나눴는지 한 번 열어 보세요. 분모가 상한이면 그 지표는 항상 빨간불입니다.

관련 글