업데이트를 출시할 때마다, Apple에 무엇이 바뀌었는지 알릴 수 있는 4,000자가 주어집니다. 대부분의 인디 개발자는 40자도 채 쓰지 않습니다.
‘버그 수정 및 성능 개선’은 릴리스 노트가 아닙니다. 낭비된 공간일 뿐이며, Apple의 2026년 가이드라인 아래에서는 오히려 당신 앱의 스토어 내 위치에 불리하게 작용할 수 있습니다.
릴리스 노트가 실제로 하는 일
App Store의 릴리스 노트는 동시에 세 개의 서로 다른 독자를 상대합니다.
- 업데이트 여부를 결정하는 기존 사용자
- 제품 페이지의 버전 기록 섹션을 읽는 잠재 사용자
- 이 업데이트가 의미 있고 능동적인 개발을 나타내는지 평가하는 Apple의 색인 시스템
대부분의 인디 개발자는 첫 번째 독자만을 위해 쓰거나, 빌드를 출시한 뒤 시간에 쫓겨 릴리스 노트를 아예 건너뜁니다. 이것은 실수입니다.
Apple의 App Store 검색 알고리즘은 당신 앱의 업데이트 이력을 신호로 취급합니다. 버전 번호가 아니라, 바이너리 크기도 아니라, 릴리스 노트의 내용입니다. 일관된 업데이트 이력에 걸쳐 구체적이고 설명적인 릴리스 노트를 가진 앱은 능동적인 유지보수를 신호합니다. 모든 업데이트 항목에 “버그 수정.”만 적힌 앱은 그 반대를 신호합니다.
WWDC26 가이드라인 개정에서 Apple은 “업데이트되거나 개선되지 않는” 앱을 삭제할 수 있는 권리를 명시적으로 확대했습니다. 릴리스 노트 필드는 당신의 앱이 실제로 의미 있게 업데이트되었는지를 들여다볼 수 있는 직접적인 창입니다. 최근 다섯 개 항목이 모두 “사소한 개선”이라고만 되어 있다면, 바이너리에서 실제로 무엇이 출시되었는지와 무관하게 당신의 업데이트 이력은 방치된 것처럼 읽힙니다.
Apple이 릴리스 노트를 색인하는 방식
Apple은 제품 페이지 전반의 텍스트를 색인해 당신의 앱이 어떤 검색어에 노출될 자격이 있는지를 결정합니다. 가장 높은 가중치를 가진 필드는 제목, 부제목, 키워드 필드입니다. 그 아래로 Apple은 설명, 프로모션 텍스트, 릴리스 노트를 처리합니다.
릴리스 노트는 업데이트할 때마다 다시 색인됩니다. 즉, 출시할 때마다 지금 당신의 앱이 무엇을 하는지 반영하는 새로운 용어를 도입할 새로운 창이 열린다는 뜻입니다. 새 기능을 출시했다면, 다음 전체 메타데이터 제출 전에 그 기능을 색인시키는 가장 빠른 경로가 바로 릴리스 노트 항목입니다.
이는 출시 당시에는 존재하지 않았던 기능에 특히 중요합니다. 최초 메타데이터를 작성한 이후 다크 모드 지원, 위젯, 공유 확장, 또는 새로운 워크플로를 추가했다면, 당신의 키워드 필드는 아마 이러한 기능을 전혀 언급하지 않고 있을 것입니다. 새 기능을 설명하는 릴리스 노트 항목은 그 용어를 즉시 Apple의 색인에 반영시킵니다.
이것은 편법이 아닙니다. Apple이 설계한 방식대로 도구를 사용하는 것입니다. 이 필드는 개발자가 변경 사항을 전달할 수 있도록 존재합니다. Apple이 변경 사항을 색인하는 이유는, 특정 기능을 가진 앱을 찾는 사용자들에게 그것이 중요하기 때문입니다.
대부분의 앱이 저지르는 구체적인 실수
App Store Connect를 열어 최근 10개의 릴리스 노트 항목을 살펴보세요.
다음과 같이 보인다면:
- “버그 수정”
- “성능 개선”
- “사소한 안정성 업데이트”
- “여러분의 경험을 개선하기 위해 열심히 노력하고 있습니다”
당신은 단지 사용자를 소홀히 대하고 있는 것이 아닙니다. Apple의 색인 시스템에게는 보이지 않는 콘텐츠를 쓰고 있는 것입니다.
“버그 수정”에는 키워드 신호가 전혀 없습니다. “성능 개선”은 아무도 검색창에 입력하지 않는 용어입니다. “경험을 개선하기 위해 노력하고 있습니다”는 자연어를 처리하는 모든 순위 시스템에서 걸러지는 상투어입니다.
다음과 비교해 보세요.
Focus 필터 연동을 추가해 현재 Focus 모드에 따라 앱 목록이 자동으로 조정되도록 했습니다. 키워드 제안 기능을 개선해 각 용어의 월간 검색량을 표시하도록 했습니다. 추적 중인 앱이 50개를 넘는 상태에서 경쟁사 분석 화면을 열 때 iPad에서 발생하던 충돌을 수정했습니다.
이 버전은 구체적인 기능(Focus 필터 연동)을 명시하고, Apple이 색인할 수 있는 카테고리 용어(키워드 제안, 검색량)를 명시하며, 플랫폼 맥락이 있는 실제 수정 사항(iPad 충돌)을 설명하고, 개발자가 기능을 검색하는 방식과 일치하는 자연어를 담고 있습니다.
둘 중 하나는 당신을 위해 일합니다. 다른 하나는 그렇지 않습니다.
효과가 있는 공식
릴리스 노트를 세 부분으로 나누어 작성하세요.
기능을 구체적으로 명시하며 시작하세요. “예약 키워드 리포트 추가”는 색인이 가능합니다. “리포트 섹션 개선”은 그렇지 않습니다. 새 화면을 출시했다면 그 화면의 이름을 밝히세요. 연동 기능을 추가했다면 연동 대상의 이름을 밝히세요. 구체성이 색인되는 것이며, 동시에 사용자가 업데이트 여부를 판단할 때 훑어보는 것도 바로 구체성입니다.
작동 방식이 아니라 사용 사례를 명시하세요. “50개 스토어프런트에서 경쟁사 키워드 변화를 매일 이메일 다이제스트로 추적”은 검색어에 근접합니다. “경쟁사 추적을 위한 백엔드 최적화”는 그렇지 않습니다. 엔지니어의 시점이 아니라 사용자의 시점에서 쓰세요.
수정 사항은 맥락과 함께 설명하세요. 버그 수정도 릴리스 노트에 들어가야 하지만, 무엇이 고장 났는지, 어떤 기기나 구성에서였는지, 그리고 지금은 어떤 동작을 기대할 수 있는지를 포함해야 합니다. “일본어 문자가 포함된 메타데이터를 제출할 때 iPhone SE에서 발생하던 충돌 수정”은 유용합니다. “충돌 수정”은 그렇지 않습니다.
이 공식에 따르면, 실질적인 업데이트에 대한 릴리스 노트 항목은 다음과 같은 모습일 수 있습니다.
키워드 순위 이력에 대한 CSV 내보내기를 추가했습니다. 이제 추적 화면에서 바로 키워드별, 스토어프런트별로 90일치 순위 데이터를 내보낼 수 있습니다. 내보내기는 키워드 탭 우측 상단 아이콘에서 실행됩니다.
ASO 점수 계산을 개선해 프로모션 텍스트의 최신성과 리뷰 응답률을 별개의 신호로 반영하도록 했습니다.
일본어, 한국어, 중국어 등 다중 문자 체계를 사용하는 로케일에서 키워드 필드 편집기에 표시되던 잘못된 글자 수를 수정했습니다.
이 항목은 약 400자로, 4,000자 제한에 여유 있게 들어가며, 메타데이터와 현지화 카테고리에 걸쳐 색인 가능한 용어를 담고 있습니다. 사용자가 직접 확인할 수 있는 실제 변경 사항을 설명하며, Apple에게는 이 업데이트가 실질적이었다는 신호를 보냅니다.
릴리스 노트가 2026년 대숙청 위험과 연결되는 방식
“업데이트되거나 개선되지 않거나 고객을 끌어모으지 못하는”이라는 Apple의 가이드라인 문구는 이미 출시된 앱에도 적용됩니다. 당신의 릴리스 노트는 Apple이 업데이트 최신성을 평가할 때 살펴보는 증거의 일부입니다.
최근 여러 업데이트에 걸쳐 구체적이고 기능 중심적인 릴리스 노트를 가진 앱은, 이력 전체가 “버그 수정 및 성능 개선”인 앱과 Apple의 시스템에서 다르게 읽힙니다. 전자는 일관되고 능동적인 개발을 보여줍니다. 후자는 어느 쪽으로도 신호를 제공하지 못하며, 이는 업데이트가 아예 없는 것과 거의 다를 바 없습니다.
이 시리즈의 이전 글에서 다룬 메타데이터 점검을 실행해 봤다면, 업데이트 최신성이 여섯 가지 점검 항목 중 하나였다는 것을 알 것입니다. 탄탄한 릴리스 노트는 바로 그 점검 항목을 뒷받침하는 실질적인 장치입니다. 릴리스 노트가 무엇이 바뀌었는지 아무것도 말하지 않는다면, 바이너리 업데이트만으로 “능동적인 개발”을 주장할 수는 없습니다.
릴리스 노트 전략을 얼마나 자주 재검토해야 하는가
릴리스 노트는 다음 업데이트가 나올 때까지 계속 게시되어 있습니다. 표준 제출 전 체크리스트의 일부로 검토하세요.
- 중요한 기능을 출시하기 전: 기능이 완성된 뒤가 아니라, 기능과 함께 릴리스 노트 초안을 작성하세요
- 유지보수성 릴리스에서도: 변경 사항이 작더라도 실제로 무엇이 바뀌었는지 설명하세요
- 주요 플랫폼 업데이트(새 iOS 버전, 신규 기기 지원) 이후: 릴리스 노트에 호환성을 명시적으로 언급하세요
빈도에 대해 말하자면, Apple은 업데이트를 얼마나 자주 출시해야 하는지에 대한 공식적인 기준을 공개하지 않았습니다. 하지만 개발자 계정 경고에서 나타나는 패턴을 보면, 실질적인 업데이트 없이 6개월이 지나면 위험 구간에 들어간다는 것을 시사합니다. 90일 주기로 구체적인 노트를 담은 일관된 릴리스는, 8개월마다 한 번씩 나오는 대규모 업데이트보다 유지보수의 더 강력한 증거가 됩니다.
다음 제출 전에 할 수 있는 일
과거의 릴리스 노트를 소급해서 다시 쓸 수는 없습니다. 하지만 지금부터의 모든 업데이트는 백지 상태입니다.
다음 App Store 제출 전에:
- 초안을 열고 빌드에서 사용자가 확인할 수 있는 모든 변경 사항을 나열하세요
- 각 변경 사항마다, 그 기능의 이름과 해결하는 사용 사례를 담은 한 문장을 쓰세요
- 각 버그 수정마다, 영향을 받은 플랫폼이나 상황을 덧붙이세요
- 이를 합쳐 릴리스 노트 필드를 완성하세요 (실질적인 항목이라면 보통 300자에서 500자면 충분합니다. 업데이트가 그럴 만한 가치가 있다면 4,000자 제한 안에서 더 깊이 들어갈 여유도 있습니다)
여기에는 15분이면 충분합니다. 당신이 만들 수 있는 가장 저렴한 색인 가능 메타데이터이며, 다른 모든 메타데이터 투자와 함께 누적됩니다. 제출 버튼을 누르기 전에 하세요.
Marteso의 AI 메타데이터 최적화 도구는 리스팅 전반에 걸쳐 키워드를 고려한 콘텐츠를 작성하는 데 도움을 줍니다. 아직 현재 메타데이터를 점검해 보지 않았다면, marteso.com/aso-score-checker에서 다음 업데이트 전에 당신의 리스팅이 정확히 어디서 저조한 성과를 내고 있는지 확인할 수 있습니다.