App Store 릴리스 노트 작성 예시: 무엇이 바뀌었는지 알려 주는 새로운 기능 문구 쓰는 법 (2026)

좋은 App Store 릴리스 노트는 한 가지 질문에 답합니다. 업데이트하면 나에게 무엇이 달라지나요? 아래의 App Store 릴리스 노트 예시는 모두 하나의 패턴을 따릅니다. 사용자가 알아차릴 변경 사항을 먼저 쓰고, 각 수정 사항을 구체적으로 밝히고, 사용자가 볼 수 없는 내용은 빼는 것입니다. 이번 버전의 새로운 기능(What's New in This Version) 필드에 대한 Apple의 공식 안내도 같은 말을 합니다. 신규 기능, UI 개선, 버그 수정을 적으라고 하며 사용자에게 "해당 버전의 변경 사항, 개선 사항 또는 수정 사항을 구체적으로" 알리라고 권장합니다.

App Store Connect와 Google Play의 릴리스 노트 규칙은 무엇인가요?

Apple의 '새로운 기능' 필드는 4,000자까지 허용되며 첫 버전 이후 모든 버전에서 필수입니다. Google Play는 언어별로 유니코드 500자까지 허용하며 홍보성 콘텐츠를 금지합니다.

2026년 10월 기준 Play Console 고객센터는 "출시 노트를 홍보 목적이나 사용자 행동 유도에 사용하지 마세요"라고 안내합니다. Apple에서는 마케팅 문구를 프로모션 텍스트에 넣으세요. 이 필드는 170자까지 허용되고 설명 위에 표시되며, Apple은 새 버전을 제출하지 않고도 수정할 수 있게 해 줍니다.

좋은 App Store 릴리스 노트는 어떤 모습인가요?

좋은 릴리스 노트는 사용자가 처했던 상황과 이제 얻게 되는 결과를 밝힙니다. 아래 예시는 가상의 습관 추적 앱에서 가져왔습니다. 모호한 버전은 출시 직전에 급하게 쓰는 종류의 노트입니다.

한 문장으로 설명하기에 너무 기술적인 수정이라면 사용자는 아마 알아차리지 못할 것이므로, 끝부분의 "안정성 개선" 한 줄에 묶어도 됩니다. 가이드라인 2.3.12는 사소한 수정에 대해서는 이를 허용하지만 실제 기능 변경에 대해서는 허용하지 않습니다.

재사용할 수 있는 릴리스 노트 템플릿이 있나요?

네. 재사용 가능한 템플릿은 헤드라인 다음에 New(신규), Improved(개선), Fixed(수정) 섹션으로 구성됩니다. 저장소의 변경 로그 옆에 두고, 빌드를 업로드한 뒤가 아니라 릴리스 브랜치를 만들 때 채우세요.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Google Play용으로는 같은 노트를 헤드라인과 상위 글머리 기호 두세 개로 줄여 500자 안에 들어가게 하세요. 각 언어의 태그는 <en-US>와 </en-US>처럼 별도의 줄에 둡니다. 마지막 문장은 사용자에게 행동을 요청하므로 Play에서는 빼세요.

병합된 풀 리퀘스트를 어떻게 릴리스 노트로 바꾸나요?

병합된 풀 리퀘스트를 릴리스 노트로 바꾸려면 사용자가 볼 수 없는 변경 사항을 걸러 낸 다음, 남은 각 변경 사항을 증상이나 결과로 다시 쓰세요. 출시할 때마다 다음 단계를 따르세요.

1. 마지막 태그 이후 병합된 풀 리퀘스트 제목을 내보낸 다음, 리팩터링, 의존성 업데이트, CI 변경처럼 사용자가 볼 수 없는 항목을 삭제하세요.
2. 남은 각 항목을 증상이나 결과로 다시 쓰세요. "Fix nil coordinator"는 "Apple로 로그인한 뒤 빈 화면이 나타나던 문제를 수정했습니다"가 됩니다.
3. 엔지니어링 작업량이 아니라 영향을 받는 사용자 수에 따라 항목을 정렬하세요.
4. App Store Connect에서 새 버전을 만든 다음, 이전 버전의 메타데이터가 이월되므로 새 노트를 붙여 넣기 전에 복사된 '새로운 기능' 문구를 지우세요.
5. 지원하는 모든 현지화 언어에 노트를 붙여 넣고 번역하거나 최소한 언어별로 확인해서, 다른 지역의 사용자가 지난 버전의 노트를 보지 않게 하세요.
6. Play에는 줄인 버전을 언어 태그 안에 붙여 넣고 각 언어가 500자 미만인지 확인하세요.
7. 노트를 한 번 소리 내어 읽어 보세요. 개발자의 설명이 필요한 문장이 있다면 다시 쓰세요.

핫픽스 릴리스 노트에는 무엇을 써야 하나요?

핫픽스 릴리스 노트에는 문제가 있던 버전을 밝히고, 이제 수정된 증상을 설명하고, 영향을 받은 사용자가 업데이트 후 어떻게 되는지 알려야 합니다. Apple은 App Store에서 이전 버전으로 되돌리는 것을 허용하지 않으므로 수정은 항상 새 버전으로 배포됩니다.

예시: "3.4.0에서 일부 사용자에게 알림이 울리지 않던 문제를 수정했습니다. 업데이트 전에 설정한 알림은 자동으로 다시 작동합니다." 영향을 받은 사용자는 업데이트해야 한다는 것을 알고, 영향을 받지 않은 사용자는 자신과 무관한 수정임을 알 수 있습니다. 운영체제 탓을 하지 말고, 향후 수정 날짜를 약속하지 마세요. 단계적 출시로 업데이트를 배포한다면, 수정 버전이 심사 중인 동안 출시를 일시 중지해 문제 있는 빌드를 받는 사용자 수를 줄일 수 있습니다. 핫픽스로 기능의 동작이 바뀐다면 App Store 제출 체크리스트를 다시 확인해 노트, 스크린샷, 심사 메모가 일치하게 하세요.

App Review가 릴리스 노트 때문에 업데이트를 거부할 수 있나요?

네. 릴리스 노트는 메타데이터이며 App Review 가이드라인이 이를 직접 다룹니다. 가이드라인 2.3.12는 "앱은 '새로운 기능' 문구에 신규 기능과 제품 변경 사항을 명확하게 설명해야 한다"고 명시합니다.

"단순한 버그 수정, 보안 업데이트, 성능 개선"에는 일반적인 문구가 허용되지만 "더 중요한 변경 사항은 노트에 나열해야" 합니다. 가이드라인 2.3.10은 메타데이터에 다른 모바일 플랫폼의 이름이나 이미지를 사용하는 것을 금지하며, 여기에는 '새로운 기능'도 포함됩니다. 플래그 뒤에 숨겨진 기능이나 제출한 빌드에 없는 내용은 설명하지 마세요. 가이드라인 2.3.1(a)는 별도로 신규 기능을 "심사 메모(Notes for Review) 섹션에 구체적으로 설명"하도록 요구하므로, 심사자용 단계와 데모 계정은 공개 노트가 아니라 그곳에 넣으세요. 메타데이터 관련 문의를 받았다면 App Store 거부 해결 방법 가이드에서 답변 방법을 확인하세요.

다른 개발자들은 어떤 릴리스 노트 문제를 겪었나요?

공개적으로 보고된 사례에서는 두 가지 실패 유형이 나타납니다. 스토어의 길이 제한을 넘어 업로드가 거부되는 경우와, 정리 지침에 '새로운 기능' 문구가 포함된 심사 거부입니다.

• CI에서의 Play 길이 제한. Flutter 배포 템플릿의 GitHub 이슈는 AI가 생성한 변경 로그 때문에 fastlane을 통한 Google Play 내부 테스트 업로드가 다음 오류로 실패했다고 보고합니다. "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." 관리자들은 업로드 전에 노트를 자르는 스크립트를 추가했습니다. Play는 480자, 제한을 바이트로 측정하는 TestFlight는 3,800바이트입니다.
• '새로운 기능'을 포함하는 2.3.10 정리 요구. Apple Developer Forums의 한 개발자는 스크린샷의 iOS가 아닌 상태 표시줄 때문에 발생한 가이드라인 2.3.10 거부 사례를 올렸습니다. Apple의 후속 조치 안내에는 "앱 설명, 프로모션 텍스트, '새로운 기능' 정보, 미리보기, 스크린샷을 포함해 앱과 메타데이터에서 이 정보를 모두 제거하라"고 적혀 있었습니다. 답글에서는 스크린샷을 다시 찍고 릴리스 노트를 포함한 모든 메타데이터 필드를 확인하라고 조언했습니다.

핵심은 이렇습니다. 길이 제한은 기계적이어서 업로드 시점에 분명하게 실패하는 반면, 심사 규칙은 내용에 관한 것이며 모든 메타데이터 필드에 적용됩니다. 글자 수 검사는 자동화하고, '새로운 기능'은 스크린샷만큼 꼼꼼하게 읽으세요.

릴리스 노트를 제출하기 전에 무엇을 확인해야 하나요?

제출하기 전에 노트가 빌드에 있는 내용만 설명하는지, 각 스토어의 제한에 맞는지, 모든 언어에서 지난 버전의 문구를 대체했는지 확인하세요.

• 헤드라인이 대부분의 사용자가 알아차릴 변경 사항을 밝히고 있습니다.
• 가이드라인 2.3.12에 따라 모든 중요한 기능이나 제품 변경 사항이 나열되어 있습니다.
• 모든 수정 사항이 내부 코드가 아니라 사용자가 겪은 증상을 설명합니다.
• 플래그 뒤의 기능, 향후 약속, 내부 티켓 번호, 다른 플랫폼 이름이 없습니다.
• 모든 현지화 언어에서 이전 버전의 '새로운 기능' 문구를 지우고 교체했습니다.
• Play 노트가 언어별로 500자 미만이고, 올바른 언어 태그로 감싸져 있으며, 홍보나 행동 유도 문구가 없습니다.
• Apple에서는 마케팅 메시지를 프로모션 텍스트로 옮겼습니다.
• Android 테스터도 운영 중이라면 같은 노트를 비공개 테스트 계획과 대조해 확인했습니다.

제출 전에 업데이트 메타데이터를 한 번 더 검토받고 싶다면 노트 초안과 빌드의 변경 사항 목록을 yagyeshsrbobde@gmail.com으로 보내 주시거나 서비스를 확인하세요.