모바일 앱 릴리스 노트: 글자 수 제한이 무엇을 잘라내는가

이 허브에서 릴리스 노트 작성에 대해 다룬 모든 내용은 완전히 통제할 수 있는 페이지를 전제로 한다. 원하는 길이, 작동하는 링크, 렌더링되는 서식 말이다. 모바일 앱의 릴리스 노트는 다른 누군가의 상자 안에서 산다. 애플은 대략 4,000자를 주지만 “더 보기”를 누르기 전까지는 처음 몇 줄만 보여준다. 구글도 비슷한 여유를 주지만 똑같이 실질적인 미리보기 문제가 있고, 두 플랫폼 모두 텍스트 안에 클릭 가능한 링크를 렌더링하지 않는다. 사람들이 실제로 읽는 릴리스 노트 작성법에 나온 규칙, 무엇이 바뀌었고 독자가 무엇을 해야 하는지 말하라는 규칙은 여전히 적용되지만, 그것을 할 공간은 체인지로그 페이지가 허용하는 것의 일부에 불과하며, 잘라내는 일은 우연이 아니라 의도적이어야 한다.

눈에 보이는 미리보기에 실제로 들어가는 것은 무엇인가

기기와 글꼴 크기에 따라 대략 80에서 170자 정도인 처음 한두 줄이다, 독자가 펼치려고 탭하기 전까지. 이것이 릴리스 노트에서 누군가 나머지를 읽을지를 결정하는 부분의 전체 예산이며, 가장 중요한 문장이 가장 먼저 와야 한다는 뜻이다. 버전 번호도, 인사말도, 카테고리 제목도 아니다. “이번 버전의 새로운 점:“으로 시작하는 릴리스 노트는 독자에게 아무것도 알려주지 않는 네 단어에 이미 보이는 공간의 3분의 1을 써버린 것이다.

“지금 무엇을 할 수 있고 무엇이 보장되는가”라는 규칙이 이 길이에서도 통하는가

통한다, 그리고 다르게가 아니라 더 엄격하게 통한다. 항목당 한 문장, 동사가 먼저, 서두 없이: “설정에서 데이터를 CSV로 내보내세요.”는 “사용자가 이제 데이터를 CSV 형식으로 내보낼 수 있는 기능을 추가했습니다”를 3분의 1의 단어로 같은 말을 함으로써 이긴다. 체인지로그 페이지 길이에서는 다소 장황한 문장이 독자에게 0.5초를 잃게 한다. 모바일 릴리스 노트 길이에서는 같은 장황함이 문장 전체를 눈에 보이는 미리보기 밖으로 밀어낼 수 있어서, 독자는 무엇이 바뀌었는지 알려줬을 동사를 아예 보지 못하게 된다.

나쁨, 미리보기를 서두에 낭비함:
"개선 사항으로 가득한 새 업데이트를 가져오게
되어 기쁩니다! 자세한 내용은 계속 읽어보세요."

좋음, 첫 줄에 모든 가치가 담김:
"데이터를 CSV로 내보내세요. 다크 모드가 이제
시스템 설정을 따릅니다. 공유 링크를 열 때
발생하던 충돌을 수정했습니다."

웹 체인지로그 항목이라면 보통 남겨둘 것 중 무엇을 잘라내야 하는가

링크가 먼저다, 두 스토어 모두 그것을 클릭 가능하게 렌더링하지 않으므로 텍스트 속 URL은 독자가 다시 입력해야 할 죽은 무게이기 때문이다. 항목에 목적지가 필요하다면 대신 앱에서 무엇을 탭해야 하는지 말하라: “설정 > 검색 아래 새 필터를 확인하세요”는 통하지만 “example.com/blog/filters에서 더 읽어보세요”는 이 표면에서는 통하지 않는다. 둘째, 조건부이거나 특정 독자에게만 해당하는 것 전부다. 웹 체인지로그는 “API를 사용한다면 이것이 당신에게 해당됩니다”라고 말할 수 있지만, 스토어 목록은 설치한 모든 사용자에게 동시에 도달하므로 조건부 줄은 해당되지 않는 95%에게는 잡음으로 읽힌다. 조건부 세부 사항은 대신 실제로 관련된 계정에만 트리거되는 앱 내 메시지에 넣어라.

모든 릴리스가 자체 노트를 가져야 하는가, 아니면 “버그 수정 및 성능 개선”을 재사용해도 괜찮은가

정말로 그러한 릴리스에는 재사용해도 되지만, 그것이 실제로 얼마나 자주 사실인지 감사하라. 릴리스 노트 작성법은 그 문구가 독자를 위해서가 아니라 내부에서 쓰인 노트를 드러낸다는 점을 이미 다룬다. 모바일에서는 이것이 이중으로 해를 끼치는데, 스토어 릴리스 노트는 일부 사용자가 업데이트 사이에 무언가를 볼 수 있는 몇 안 되는 곳 중 하나이기 때문이고, “버그 수정 및 성능 개선”이 길게 이어지면 앱이 변하지 않는 것처럼 읽혀서, 그 기간 동안 노트가 아예 없는 것보다 더 나쁜 인상을 준다.

릴리스 노트는 사람들이 앱을 업데이트할지 여부에 아예 영향을 미치는가

설득보다는 가시성을 통해 간접적으로 영향을 미친다. 대부분의 사용자는 자동으로 업데이트하고 업데이트 전에 노트를 읽는 일이 없다. 노트는 업데이트를 수동으로 확인하는 소수, 그리고 스토어 목록의 이력을 훑어보는 리뷰어나 언론에게 가장 중요하다. 그 작은 독자층을 위해 쓰는 것도 여전히 값어치를 하는데, 구체적이고 날짜가 찍힌 항목들의 실제 이력이 있는 목록은 활발히 관리되는 앱처럼 읽히고, “버그 수정 및 성능 개선”만 1년 이어진 목록은 그 기간 실제로 얼마나 많은 것이 출시되었든 그렇게 읽히지 않기 때문이다.

사용자에게 선택권이 없는 이유를 노트가 설명해야 하는 강제 업데이트는 어떤가

이유와 기한을 다른 무엇보다 먼저 첫 줄에 밝혀라, 강제 업데이트는 독자가 읽기 시작하기도 전에 이미 짜증이 난 유일한 경우이기 때문이다. “데이터 동기화를 계속하려면 이 업데이트가 필요합니다. 중단을 피하려면 [날짜]까지 업데이트하세요.”는 무엇을 해야 하고 왜인지를 한 문장으로 말한다. 그 이유를 관련 없는 기능 노트 세 줄 아래에 묻어버리면 앱이 불편한 부분을 숨기는 것처럼 읽힌다.

FAQ

모바일 릴리스 노트는 같은 릴리스의 웹 체인지로그와 일치해야 하는가? 같은 근본적인 변경 사항을 다뤄야 하지만 토씨 하나까지 같을 필요는 없다. 웹 체인지로그는 완전한 설명을 감당할 수 있지만, 모바일 노트는 동사가 먼저 오는 한 문장으로 압축된 같은 사실이 필요하며, 이것은 보통 복사가 아니라 다시 쓰기를 의미한다.

지원하는 언어마다 모바일 릴리스 노트를 현지화할 가치가 있는가? 있다, 웹 체인지로그보다 더 그렇다, 스토어 목록이 종종 일부 사용자가 세션 사이에 보는 유일한 현지화된 표면이기 때문이며, 두 플랫폼 모두 번역 자체를 넘어서는 추가 엔지니어링 작업 없이 로케일별 릴리스 노트를 지원한다.

간결함을 강제하는 한도가 없다면 모바일 릴리스 노트는 얼마나 길어야 하는가? 그래도 짧아야 한다. iOS의 4,000자 상한이 실제 제약인 경우는 드물다. 실제 제약은 2-3줄 미리보기이며, 그 미리보기가 보여주는 것을 넘어서 쓰는 것은 그저 중요한 부분을 읽는 사람이 줄어든다는 뜻일 뿐이다.

릴리스 노트는 눈에 보이는 텍스트에 버전 번호가 필요한가? 아니다. 스토어는 이미 노트 옆에 버전 번호를 보여준다. 텍스트 안에서 그것을 반복하는 것은 독자가 이미 눈앞에 가지고 있는 정보에 눈에 보이는 글자를 쓰는 셈이다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 릴리스 노트 템플릿, changelog 예시