원문은 55가지를 소개하고 있는데 그 중에서 "소프트웨어 개발 및 협업 도구"에 해당하는 12가지만 소개해봅니다.
화면 캡처 시점이 2022년 11월인 것을 보면 이 글이 작성된 시점은 2023년 즈음이 아닌가 싶은데 Wayback Machine으로 확인해보면 2024년 하반기입니다(정확한 게시 일자를 확인할 수 없네요).
Amoeboids는 아틀라시안 마켓플레이스 앱을 개발하는 IT 서비스 화시라고 합니다. 제품군 중에 자동으로 릴리스 노트를 생성하는 것이 있어 이런 콘텐츠를 만든 것이 아닌가 싶네요.
https://amoeboids.com/atlassian-apps/automated-release-notes-for-jira/
원문은 아래 링크를 참고하세요.
https://amoeboids.com/blog/55-release-notes-examples-to-inspire-you/
릴리스 노트는 많은 팀에서 충분히 활용하지 못하는 마케팅 도구입니다. 새로운 버전에서 제품이 어떻게 달라졌는지 보여줄 뿐만 아니라, 고객에게 개발팀이 얼마나 헌신적인지 전달할 수 있는 수단입니다.
자세한 내용을 담은 버전부터 깔끔하고 유머러스한 버전까지, 릴리스 노트는 다양한 형태와 크기로 제공되며, 그중 55개를 소개합니다. 역대 최고의 릴리스 노트를 작성할 수 있도록 (물론 다음 번에도 또 최고의 릴리스 노트를 작성할 수 있도록) 자세히 분석했습니다.
- 소프트웨어 개발 및 협업 도구
- 고객 지원 도구
- 영업 및 마케팅 도구
- 프로젝트 관리 도구
- 유명한 일상 사용 도구
1. 깃헙(GitHub)
https://github.blog/changelog/
깃헙은 릴리스 노트를 세분화하고 다양한 접근 방식을 채택하는 데 탁월합니다. 최근 업데이트된 릴리스 노트는 내용이 짧고 스크린샷을 포함하지만, 이전 릴리스 노트는 문제와 영향을 받은 부분에 대한 명확한 설명이 많이 포함되어 있습니다. 릴리스 노트의 빈도는 매우 짧아서 하루에 여러 업데이트가 발표되는 경우도 있습니다.
* 깃헙의 릴리스 노트 작성 방침이 바뀐 건 아니고 아이템에 따라 다른 것 같습니다. 최근 올라온 릴리스 노트도 상세한 내용이 포함된 항목이 있습니다.
변경 사항 되돌리기(change revert)에 대한 업데이트는 주목할 만한데, 릴리스 노트에는 팀이 문제를 어떻게 확인하고 해결했는지 설명되어 있습니다. 또한 발생한 문제의 범위(있는 경우)를 자세히 설명하고, 영향을 받을 것으로 의심되는 경우 고객에게 어떻게 해야 하는지 알려줍니다.
* 변경 사항을 적용해 사용자가 이미 다른 개발을 진행한 경우 이를 되돌렸을때 이에 대한 지원을 어떻게 할지의 문제입니다. 단순히 설명으로 끝나면 좋겠지만, 비용적인 문제가 발생할 수도 있고, 법적인 문제가 생길 수도 있습니다.
참고할 점: 홈페이지에 정보가 적절하게 구조화되어 있습니다. 릴리스 노트도 보기 좋게 정리되어 있습니다. 태그는 노트를 특정 버킷으로 그룹화하는 데 도움이 되며, 깃헙은 이 기능을 잘 활용하고 있습니다.
* 원문에서는 "The segmentation is right on the homepage"라고 설명하고 있는데 어떤 의미인지 살짝 애매합니다. 일단 깃헙의 릴리스 노트는 깃헙 블로그 메뉴에 잘 보이게 노출이 되어 있고 릴리스 노트는 3개의 항목(New Releases, Improvements, Retired)으로 구분해서 필터링하고 세부 기능 단위로도 필터링을 제공합니다.
피해야 할 점: 매우 긴 스크린샷, 페이지에 걸쳐 나오는 한 줄짜리 버그 수정 - 접을 수 있는 아코디언 구조를 사용하면 해당 업데이트로의 탐색 속도를 높일 수 있습니다.
* 이 글을 참고해서인지 최근 업데이트된 UI에서는 아코디언 구조를 사용해 월별로 접근이 가능합니다.
2. 줌(Zoom)
https://support.zoom.us/hc/en-us/articles/201361953-Release-notes-for-Windows
* 링크가 바뀐 것 같습니다. 줌은 제품별로 릴리스 노트를 제공하는데 제품이 너무 많아서 ^^ 일단 윈도우 앱의 릴리스 노트는 아래 링크를 참고하세요.
https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0061222
줌의 릴리스 노트는 최신 상태로 유지되며, 새로운 기능과 향상된 기능, 기존 기능 업데이트, 버그 수정 사항이 포함되어 있습니다. 또한, 예정된 변경 사항에 대한 정보는 가능한 한 자주 제공되며, 지난 2년간의 소프트웨어 업데이트 내역은 릴리스 날짜와 버전 번호로 표시됩니다. 페이지는 깔끔하게 구성되어 있지만 개별 릴리스 노트 링크는 제공하지 않습니다. (팁: 이러한 페이지가 나타나면 Ctrl/Cmd + F 키를 눌러 버전 번호를 검색하세요. 단, 페이지가 제대로 로드되었는지 확인하기 위해 몇 번 아래로 스크롤해야 할 수도 있습니다.)
참고할 점: '관련 문서' 사이드바를 통해 사용자는 해당 릴리스 및 새로 도입된 기능과 관련된 일반적인 문제에 대한 도움말 항목을 확인할 수 있습니다. 사용자는 여기에서 블로그로 바로 이동할 수 있습니다.
* 현재 릴리스 노트에는 관련 문서(Related articles) 항목이 없습니다.
피해야 할 점: 모든 릴리스 노트가 한 페이지에 나열되어 있으며, 특정 릴리스 노트에 접근할 방법이 없습니다(스크롤/검색 제외).
* 앵커(anchor)를 제공하기는 합니다만 전체 스크롤이 길어져서 로딩이 오래 걸리는 문제는 여전히 남아 있습니다.
https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0061222#mcetoc_1iuf0lu2r31t
* 아마도 오래된 릴리스 노트를 일부러 찾아보는 경우가 많이 없다고 판단한 것이 아닌가 싶습니다. 깃헙처럼 아코디언 구조를 사용했다면 좀 더 사용성은 좋아질 것 같네요.
3. 구글 클라우드(Google Cloud)
https://cloud.google.com/release-notes
구글 클라우드 릴리스 노트는 최신 정보로 잘 업데이트되어 있고, 내용도 상세합니다. 팀에서는 한 걸음 더 나아가, 그날 발생한 중요한 업데이트까지 직접 입력해 둡니다. 때로는 며칠(혹은 몇 주)간 조용할 때도 있지만, 갑자기 많은 활동이 이루어지기도 하는데, 이는 팀이 제품을 항상 최신 상태로 유지하기 위해 얼마나 노력하는지를 보여줍니다.
* 2025년 6월 기준으로 하루도 빠지지 않고 릴리스 노트가 올라와있는데 해당 페이지는 전체 제품군 릴리스 노트라서 그렇고 개별 제품 릴리스 노트로 가면 업데이트 주기가 다릅니다. 아래 링크에서 개별 제품 릴리스 노트로 이동할 수 있습니다.
https://cloud.google.com/release-notes/all
참고할 점: 매일 꾸준히 업데이트하는 것은 일부 팀에게는 쉬운 일이겠지만, 브랜드 가치에 큰 기여를 할 수 있습니다. 업데이트는 모두 기술적인 내용이며 관리자를 위해 작성되었으며, 특히 색상으로 구분된 이슈 분류 방식은 훌륭한 아이디어입니다.
* 매일 업데이트는 작성자가 오해한 것이 아닌가 싶네요. 아마도 각 제품별로 작성된 릴리스 노트가 취합되어 한 페이지로 표시되는 것이 아닌가 싶습니다.
피해야 할 점: 이러한 변화로 인해 고객이 무엇을 기대할 수 있는지에 대한 간략한 맥락이나 요약 문단을 제공하면 대상 고객의 보다 포괄적인 계층이 메모를 이해할 수 있습니다.
4. 마이크로소프트 팀즈(Microsoft Teams)
https://support.microsoft.com/en-us/office/what-s-new-in-microsoft-teams-d7092a6d-c896-424c-b362-a472d5f105de
마이크로소프트 팀즈는 릴리스 노트에서 최종 사용자 관점을 반영하여 핵심만 간략하게 정리했습니다. 하지만 더 자세한 정보가 필요할 경우 관련 문서와 링크를 제공합니다. 릴리스 노트에는 릴리스 번호는 없지만 날짜만 표기되어 있습니다. 교육 기관을 비롯한 여러 기관에서 큰 호응을 얻은 것을 고려하면 이러한 단순한 형식의 릴리스 노트는 효과가 있었던 것으로 보입니다.
* 릴리스 노트와 제품 수용과 어떤 관계가 있는지 명확하지 않지만, 아마 작성자의 생각은 간결한 내용이 인상적이었다 정도가 아닌가 싶습니다.
참고할 점: TL; DR(너무 길어서 읽지 않음) 아이디어에서 사용자 이점을 몇 마디로 요약하면 기술 분야에 종사하지 않은 사람들도 릴리스 노트 페이지를 더 많이 볼 수 있습니다.
피해야 할 점: 릴리스 노트에 출시 번호가 없으면, 특정 출시 정보를 검색하는 것이 쉽지 않습니다.
5. 슬랙(Slack)
https://slack.com/intl/en-in/release-notes/windows
다소 느긋하게 들리는 이름에도 불구하고, 슬랙은 지난 업데이트 이후 개선된 사항, 사용자 업무 개선에 도움이 되는 방법, 패치에 추가 권한이 필요한 경우 관리자에게 제공하는 참고 사항 등을 설명하는 제품 노트를 적극적으로 공개하고 있습니다. 이 모든 내용은 대화형 언어로 제공됩니다.
* 대화형 언어보다는 위트가 담긴 릴리스 노트를 작성하고 있습니다. 예를 들면 "All bugs that were fixed in this release were too small for the eye to see or too fiddly for human words to describe"같은 표현이죠. 제품 자체가 힙한 제품이라 그런 것 같기도 하구요.
참고할 점: 어조가 편안하면서도 친근해야 합니다. 이는 조직의 소통 방식에 따라 달라지지만, 이러한 언어를 사용하면 모든 이해관계자에게 유익할 수 있습니다.
피해야 할 점: 보안 알림(security notification, 위의 캡쳐 이미지에서 표시한 부분)의 강조 표시 방식을 개선할 수 있습니다. 업데이트 권장 이유를 간략하게 설명하면 열람률을 높이고 낮은 참여율을 해소할 수 있습니다.
6. 아사나(Asana)
https://help.asana.com/s/article/release-notes?language=en_US
아사나는 주요 릴리스에 대한 소개 영상을 제공하여 사용자가 변경 사항을 이해하고 이를 통해 무엇을 할 수 있는지 자세히 설명합니다. 버그 수정 및 업데이트에 대한 자세한 내용 뒤에는 관련 항목으로 연결되는 유용한 링크가 제공되어 사용자가 변경 사항과 관련된 여러 단계를 안내합니다.
* 구글 크롬도 비슷하게 주요 릴리스를 개발자 또는 데브렐 팀에서 나와 소개하는 형식을 채택하고 있습니다. 시각적으로 보여주어야 할 변경이 많다면 이미지보다 비디오가 좀 더 효율적일 수 있죠.
참고할 점: 왼쪽 사이드바의 도움말 탐색 기능이 가장 관련성 높은 섹션으로 깔끔하게 정리되어 있어 문제 해결이 더욱 수월합니다.
피해야 할 점: 월별 그룹화는 훌륭하지만, 개별 업데이트 링크가 없어 나중에 참고할 수 있는 유일한 방법은 스크린샷을 찍는 것입니다.
* 현재는 구조가 좀 바뀐 것 같네요. 왼쪽 사이드바의 기능이 사라지고 각 월별 링크를 따로 제공합니다.
7. 베이스캠프(Basecamp)
https://updates.37signals.com/post/category/Basecamp
베이스캠프는 최종 고객 관점에서 최고의 릴리스 노트 중 하나를 제공하는데, 여기에는 사용자에게 관련된 주요 내용과 변경 사항만 언급되어 있습니다. 팀은 사람들이 흥미롭게 읽을 수 있도록 최선을 다합니다. 제목에는 예상되는 내용이 자세히 설명되어 있으며, 경우에 따라 전체 내용을 드러냅니다.
참고할 점: 스크린샷에서 관련 정보를 처리하는 방식. 업데이트에서 새로운 기능이 추가될 때 릴리스 노트에 티저를 사용하기도 합니다.
피해야 할 점: 기술적인 세부 정보의 부재. 패치를 업데이트해야 하는 관리자가 공개 저장소에 접근하여 빠르게 참조할 수 없습니다.
* 제품 특성 상 기술적인 세부 정보가 필요할까 싶긴 합니다. 피해야 할 점에서 언급한 세부 정보나 저장소에 대한 이야기는 어떤 부분인지 잘 모르겠습니다.
8. 도커(Docker)
https://docs.docker.com/engine/release-notes/
도커는 기본적으로 시스템 다크 테마를 반영하는 몇 안 되는 웹사이트 중 하나인데, 이는 좋은 놀라움이었습니다. 참고 사항은 자세하고 추가 정보와 연결되어 있어 사용자가 필요에 따라 데이터를 사용할 수 있습니다. 2021년 말부터는 처음에 추가된 요약을 통해 어떤 변경 사항이 적용되었고 사용자에게 어떤 영향이 미치는지 쉽게 이해할 수 있도록 자세히 설명합니다.
* 관련된 추가 정보를 제공한다기 보다는 기본 문서 카테고리 내 릴리스 노트가 포함되어 있어서 그렇게 보이는 것 같습니다.
참고할 점: 구성이 최고 수준이며, 도움말 섹션을 통해 사용자는 어려운 용어를 쉽게 이해할 수 있습니다. 사용자에게 부담을 주지 않으면서도 다양한 수준의 세부 정보를 제공합니다. 알림 기능 사용 또한 현명하게 활용되었습니다.
피해야 할 점: 메모에 명확한 라벨이 붙어 있고 체계적으로 정리되어 있어 부족한 부분이 거의 없습니다. 메모의 구조가 다소 단조로워 보일 수 있습니다. 마치 팀이 체크리스트의 모든 항목을 체크하려는 것처럼 보입니다 .
* 도커 릴리스 노트의 경우 깃헙의 PR 링크를 제공하고 있습니다. 이슈 관리가 잘되고 있다면 릴리스 노트에 요약만 제공하고 상세 정보는 이슈관리목록에서 확인하도록 하는 것도 나쁘지 않습니다. 다만, 사용자 입장에서 딱 필요한 정보를 찾기가 어려운 단점도 있긴 합니다.
9. 트윌리오(twilio)
https://www.twilio.com/changelog
Twilio 릴리스 노트는 최종 사용자를 염두에 두고 작성되었습니다. 최근 출시되는 다양한 기능을 고려하여 프로세스를 설명하기 위해 스크린샷이 많이 사용되었습니다. 주요 업데이트에 대한 릴리스 노트는 상세하며, 별도의 문제 해결 페이지로도 활용될 수 있습니다.
참고할 점: 음성 기능 향상에 대한 간략한 업데이트에서 볼 수 있듯이, 사용자가 무엇을 알고 있고 새로운 기능을 어떻게 사용해야 하는지 이해하는 친근한 설명.
피해야 할 점: 공개 버전의 종속성과 같은 기술적 세부 정보가 부족하면, 일부 사용자에게 저장소를 사용할 수 없게 만들 수 있으며, 이메일을 하나하나 찾아야 하는 번거로운 작업에 직면하게 될 수 있습니다.
10. 컨플루언스(Confluence)
https://developer.atlassian.com/cloud/confluence/changelog/
컨플루언스 릴리스 노트는 전형적인 불릿 중심의 방법론을 따르며, 주요 내용을 강조하고 가능한 한 관련 정보로의 링크를 제공합니다. '자세히 보기(More details)' 섹션은 언제 등장하든 읽기에 매우 즐겁습니다. 대개 개발 과정과 흥미로운 뒷이야기를 담고 있기 때문입니다.
* 자세히 보기 항목이 작성자의 말처럼 항상 흥미로운 것은 아닙니다. 단순히 관련 코드만 담고 있는 경우도 있습니다.
참고할 점: 정보를 전달하는 간결한 방법은 릴리스 관리자가 무엇을 하고 있는지 잘 알고 있음을 보여줍니다. 관련 링크는 기사 섹션을 이해하는 데 도움이 되며, 변경 사항을 더 빨리 이해할 수 있도록 도와줍니다.
피해야 할 점: '자세히 보기' 아래에 중요한 업데이트 내용을 숨기는 것. 특히 업데이트의 기술적 측면과 자연스럽게 연결되는 경우, 핵심 내용을 먼저 언급하는 것이 좋습니다.
11. 세그먼트(Segment)
https://segment.com/release-notes/
세그먼트는 릴리스 노트를 블로그처럼 운영하는데, 이는 페이지 구조에도 반영되어 있습니다. 주제는 페이지에 정렬되어 있으며, 특정 릴리스와 관련된 개별 노트에는 사용자 이점이나 사용자가 할 수 있거나 해야 하는 일과 같은 세부 정보가 제공됩니다. 각 주제는 거의 모든 사용자 친화적이지 않은 용어에 대한 관련 도움말 페이지로 연결됩니다.
* 최근 릴리스 노트 페이지는 구조가 좀 달라졌습니다. 주제 항목이 없어졌네요.
참고할 점: 도움말 페이지를 크로스 링크하는 데 들어간 세심한 배려는 릴리스 노트를 훌륭하게 뒷받침합니다. 색상으로 구분된 섹션 덕분에 유사한 카테고리의 다른 게시물을 쉽게 찾을 수 있습니다.
* 작성자가 이야기한 세심한 배려는 모두 사라졌습니다. 담당자가 바뀐 걸까요?
피해야 할 점: 게시물은 유익하지만, 변경 사항이나 예상되는 내용에 대한 자세한 내용은 거의 제공하지 않습니다. 도움말 페이지도 중요한 작업을 담당하지만, 개선의 여지가 있습니다.
* 세부적인 정보는 정보에 따라 다르지만, 없는 것은 아닙니다.
12. readme
https://docs.readme.com/main/changelog
팀이 API 문서를 인터랙티브 허브로 전환할 수 있도록 지원하는 개발자 중심 도구입니다. Readme 파일 자체에도 API 변경 내역을 관리하는 제품이 포함되어 있으며, 당연히 동일한 제품을 사용합니다.
참고할 점 : 시각적 일관성을 유지하기 위해 각 릴리스 노트는 스크린샷으로 시작합니다. 한 걸음 더 나아가, 이러한 스크린샷은 유사한 스타일을 갖습니다. 스크린샷과 같은 시각적 보조 자료를 사용하면 릴리스 노트 참여도를 높이는 확실한 방법입니다 .
피해야 할 점: 필터링 옵션이 없고 릴리스 노트 페이지가 너무 길어서 특정 업데이트를 검색하거나 다시 보기가 어렵습니다.
