[Google Play] 릴리스 노트 500자 제한과 다국어 트리밍 전략

개요

Google Play 콘솔에서 릴리스 노트(What’s new)는 언어별 500자가 상한입니다. 영어로 한 줄씩 모든 변경 사항을 적다 보면 이 한도를 어렵지 않게 넘기게 됩니다. 한도를 넘긴 채로 fastlane supply 같은 자동 업로드 도구로 릴리스를 시도하면 업로드 자체가 실패하므로, 노트 작성 단계에서 한도를 의식하는 규율이 필요합니다.

이 글에서는 한국어 노트는 512자에서 482자로, 영어 노트는 890자에서 406자로 압축했던 실제 사례를 바탕으로, 다국어 릴리스 노트를 한도 안에 맞추는 트리밍 전략을 정리합니다.

Google Play의 릴리스 노트 500자 제한

Google Play 콘솔의 “What’s new in this release” 필드는 언어별로 최대 500자(공백·줄바꿈 포함)까지 허용합니다. 한도를 초과하면 콘솔 UI 에서 즉시 빨간 경고가 표시되고, fastlane / Play Developer API 로 업로드할 경우 다음과 비슷한 오류로 실패합니다.

The release notes for language 'en-US' are too long. Limit is 500 characters.

각 언어의 노트는 독립적으로 한도가 적용됩니다. 한국어 노트가 한도를 만족해도 영어 노트가 초과하면 release 자체가 거부되므로, 모든 언어를 동시에 검증해야 합니다.

다국어 노트의 글자 수 비대칭

한국어와 영어를 동시에 운영하다 보면, 같은 의미를 표현해도 영어 쪽이 훨씬 길다는 사실을 자주 마주칩니다. 다음은 동일한 변경 사항을 한 줄로 적었을 때의 비교입니다.

# 한국어 (한 줄)
복습 결과 화면에서 정답 단어의 한자 상세 정보를 바로 확인할 수 있도록 개선했습니다.
# → 약 42자

# 영어 (한 줄)
Improved the review result screen to let you view kanji details of the correct word directly.
# → 약 95자

영어가 한국어의 약 2~2.5 배 길이가 됩니다. 결과적으로 항목 수가 늘어날수록 영어 쪽이 먼저 한도를 돌파합니다. 실제 사례에서도 한국어 노트는 12 항목에 512자(한도 약간 초과)였지만, 영어 노트는 동일한 12 항목에 890자(한도의 1.78배)였습니다.

이 비대칭은 노트 작성 패턴에 그대로 영향을 줍니다.

한국어: 항목 1~2개만 빼면 한도를 만족할 수 있다 → “한 줄 = 한 항목” 원칙을 유지
영어: 항목을 빼는 것만으로는 부족하다 → 관련 항목을 묶어서 그룹핑할 필요가 있다

글자 수 카운트 방법

먼저 현재 노트가 몇 자인지 정확히 알아야 합니다. macOS / Linux 의 wc -m 은 줄바꿈을 포함한 문자 수를 출력하므로 한도 검증에 그대로 쓸 수 있습니다.

# 언어별 글자 수
for f in release_notes/*.txt; do
  printf "%-25s %4d chars\n" "${f}" "$(wc -m < "${f}")"
done

출력 예시:

release_notes/en.txt       890 chars
release_notes/ja.txt       431 chars
release_notes/ko.txt       512 chars

wc -c (바이트 수) 가 아니라 wc -m (문자 수)를 써야 한국어 / 일본어처럼 멀티바이트 문자를 한 글자로 셉니다. UTF-8 환경에서는 로케일이 영문일 경우 wc -m 이 바이트 수를 반환할 수 있으므로, LANG=en_US.UTF-8 같은 UTF-8 로케일이 설정되어 있는지 확인합니다.

트리밍 전략

500자를 맞추는 작업은 단순히 항목을 자르는 것이 아니라, 사용자 가치를 최대한 유지하면서 길이를 줄이는 편집 작업입니다. 두 가지 전략을 조합해 사용합니다.

전략 1. 사용자 체감도가 낮은 항목 제거

한국어처럼 한도를 살짝 초과한 경우에는 항목 한두 개를 빼는 것이 가장 간단합니다. 어떤 항목을 뺄지는 다음 우선순위로 판단합니다.

다른 언어 사용자에게는 영향이 없는, locale 전용 변경부터 후보로 둡니다.
사용자가 직접 인지하기 어려운 내부 변경(라벨 표기 통일, 문구 미세 조정 등)을 우선 뺍니다.
버그 수정 항목은 가능하면 남깁니다. release 노트는 사용자가 “이번 버전에서 내 문제가 해결됐는지” 확인하는 채널이기도 하기 때문입니다.

실제 사례에서도 한국어 노트는 한국어 문제 유형 라벨 표기 형식을 통일했습니다. 항목을 제거했습니다. ko 전용 변경이고, 사용자가 라벨 형식 차이를 명시적으로 인지하기 어렵다는 두 조건을 모두 만족하기 때문입니다.

전략 2. 관련 항목 그룹핑

영어처럼 한도의 1.5배 이상을 초과한 경우에는 항목을 빼는 것만으로는 부족합니다. 의미적으로 관련 있는 여러 항목을 한 줄로 묶어 압축합니다. 그룹핑 기준은 다음과 같습니다.

기능 단위로 묶기: “복습 화면 관련 신규 옵션 3개” → 한 줄
플랫폼 단위로 묶기: “iOS 오디오 관련 수정 3개” → 한 줄
카테고리 단위로 묶기: “호환성 / 안정화 / 크래시 수정” → 한 줄

실제 사례에서 영어 노트는 12 항목 890자에서 6 항목 406자로 압축됐는데, 변환 패턴은 다음과 같았습니다.

# Before — 항목별 한 줄
- Added per-quiz-type descriptions and display options to the review screen.
- Improved the review result screen to let you view kanji details of the correct word directly.
- Added an option to hide the pronunciation under the speaker in listening quiz types.

# After — 기능 단위로 그룹핑
- New review options: per-quiz-type descriptions, kanji details on correct answer,
  listening pronunciation hide.

# Before — iOS 오디오 관련 3개를 따로 적음
- Improved the voice filter to make more voices available on iOS.
- Fixed an issue on iOS where audio could cut off during auto-repeat playback.
- Fixed an issue where ads containing speech blocked the app's voice.

# After — 플랫폼 단위로 그룹핑
- iOS audio: more voices, no auto-repeat cut-off, ad blocking fix.

그룹핑은 정보를 잃지 않으면서도 길이를 절반 이하로 줄일 수 있는 강력한 기법입니다. 다만 너무 많이 묶으면 한 줄이 추상적으로 변해 사용자가 무엇이 바뀌었는지 파악하기 어려워지므로, “한 줄에 3~4개 항목” 정도를 상한으로 두는 것이 좋습니다.

CI에 글자 수 검증 게이트 추가

500자 한도를 매번 사람이 체크하면 누락이 발생합니다. CI 단계에서 모든 언어의 릴리스 노트 길이를 자동 검증하도록 게이트를 추가하면, release 워크플로가 트리거되기 전에 한도 초과를 잡아낼 수 있습니다.

#!/usr/bin/env bash
# scripts/verify_release_notes_length.sh

LIMIT=500
FAIL=0

for f in release_notes/*.txt; do
  len=$(wc -m < "${f}")
  if [ "${len}" -gt "${LIMIT}" ]; then
    echo "FAIL: ${f} ${len} chars (> ${LIMIT})"
    FAIL=$((FAIL + 1))
  else
    echo "OK:   ${f} ${len} chars"
  fi
done

if [ "${FAIL}" -eq 0 ]; then
  echo "RESULT: PASS"
  exit 0
else
  echo "RESULT: FAIL (${FAIL} files over limit)"
  exit 1
fi

GitHub Actions 워크플로에서는 release 빌드 직전에 이 검증 단계를 배치합니다.

# .github/workflows/release_android.yml
- name: Verify release notes length
  run: bash scripts/verify_release_notes_length.sh

이렇게 두면 누군가 노트에 새 항목을 추가하다가 한도를 넘긴 채로 머지하더라도, release 가 진행되기 전에 CI 에서 실패합니다. 이미 태그를 푼 다음 fastlane 단계에서 한도 초과로 실패하는 것보다 훨씬 빨리 피드백을 받을 수 있습니다.

정리

Google Play 의 언어별 500자 제한은 릴리스 노트를 자동화하는 과정에서 자주 마주치는 제약입니다. 이 글에서 다룬 내용을 요약하면 다음과 같습니다.

한도는 언어별 독립이므로, 모든 언어를 동시에 검증해야 한다.
영어는 한국어 / 일본어보다 같은 의미를 표현하는 데 약 2배 길이가 필요하므로, 한국어가 통과해도 영어가 한도를 넘기는 패턴이 흔하다.
글자 수는 wc -m 으로 정확히 셀 수 있다. UTF-8 로케일을 확인한다.
한도 약간 초과: 사용자 체감도가 낮은 항목(locale 전용, 내부 변경)을 우선 제거한다.
한도 1.5배 이상 초과: 관련 항목을 기능 / 플랫폼 / 카테고리 단위로 그룹핑한다. 한 줄에 3~4 항목까지가 무리 없는 상한이다.
매번 수동으로 세지 말고, CI 에 글자 수 검증 게이트를 추가하여 release 가 진행되기 전에 한도 초과를 잡는다.