무료 온라인 기술 작문 (맥머리, 저자): 릴리스 노트

이 페이지는 완전히 공사 중입니다!

여기를 클릭하여 도와주세요 데이비드 맥머리 웹 호스팅 요금을 지불하다:
작은 금액이라도 기부해 주세요!
온라인 기술 작문은 무료로 유지됩니다.

온라인 기술 문서 작성 교과서: 릴리스 노트

다음 정보는 아래 인용된 appcues.com의 기사에서 허가를 받아 수정되었습니다.

대부분의 릴리스 노트가 읽히지 않는 이유 (그리고 이를 해결하는 방법)

대부분의 릴리스 노트는 읽히지 않는다. 사용자가 제품의 변화에 대해 신경 쓰지 않기 때문이 아니라, 노트가 기능을 배포한 팀을 위해 작성되었지, 이를 이해해야 하는 사람을 위해 작성되지 않았기 때문이다.

아마도 당신은 이전에 이런 것을 보았을 것입니다: "향상된 데이터 지속성 계층을 구현하여 처리량 개선"으로 시작하는 릴리스 노트, 그러나 사용자가 실제로 듣고 싶었던 것은 "당신의 보고서가 이제 두 배 더 빨리 로드됩니다."라는 것이었습니다. 첫 번째 버전은 체크박스를 확인합니다. 두 번째 버전은 채택을 촉진합니다.

그 간극은 대부분의 팀이 깨닫는 것보다 더 중요하다. 릴리스 노트는 제품의 커뮤니케이션 순간이다. 그것은 배송과 채택 사이의 창이다. 제대로 작성하면 사용자가 당신이 만든 것을 탐색하게 된다. 놓치면 기능은 배송되지 않은 것과 다름없다.

이 기사는 그 간극을 메우는 데 필요한 정보를 제공합니다: 잘하는 회사의 13가지 릴리스 노트 예시(각 예시를 연구할 가치가 있는 이유로 정리됨), 오늘 바로 활용할 수 있는 템플릿, 그리고 기본 개념을 다룬 단계별 작성 가이드. 당신이 첫 번째 릴리스 노트를 작성하는 제품 관리자이든, 프로세스를 다듬고 있는 제품 마케팅 담당자이든, 즉시 활용할 수 있는 무언가를 얻고 가게 될 것입니다.

릴리스 노트란 무엇인가요?

릴리스 노트는 새로 출시되거나 업데이트된 소프트웨어와 함께 발행되는 간단한 사용자 보고서입니다. 이 노트는 무엇이 변경되었는지, 그 이유가 무엇인지, 그리고 누구에게 영향을 미치는지를 설명합니다. 새로운 릴리스의 경우, 릴리스 노트는 제품이 무엇을 하는지에 대한 요약을 사용자에게 제공합니다. 기존 제품의 업데이트 경우, 노트는 무엇이 새로 추가되었는지, 무엇이 개선되었는지, 그리고 지난 버전 이후 무엇이 수정되었는지를 설명합니다.

‍

릴리스 노트 예시 - 이전 릴리스 보여주기

‍

릴리스 노트 vs. 변경 로그

용어는 혼용되지만, 서로 다른 의미를 가집니다. 릴리스 노트는 특정 버전이나 업데이트를 자세히 설명합니다: 무엇이 변경되었는지, 왜 중요한지, 누구에게 영향을 미치는지. 변경 로그와 릴리스 노트의 차이는 이해할 가치가 있습니다: 변경 로그는 시간에 따라 모든 릴리스 노트의 연속 로그입니다. 아카이브라고 생각하세요. 많은 제품이 둘 다 유지합니다: 각 업데이트에 대한 개별 릴리스 노트와 모두 함께 역순 정렬된 변경 로그 페이지.

그 기록을 유지하는 것은 중요합니다. 이는 고객에게 제품이 지속적으로 개선되고 있음을 보여주고, 최근 변화가 이전 것들에 기반을 두고 있음을 나타냅니다. 또한 회사가 피드백에 귀 기울이고 있으며 사용자 경험에 전념하고 있음을 신호합니다.

릴리스 노트의 종류

모든 업데이트가 동일한 대우를 받을 필요는 없습니다. 릴리스 노트의 형식과 깊이는 변경의 범위에 맞춰야 합니다.

주요 릴리스 노트: 새로운 기능, 중요한 UI 변경, 새로운 기능들. 이들은 시각 자료, 변경 이유에 대한 맥락, 사용 방법에 대한 명확한 안내와 함께 보다 상세하게 다뤄져야 합니다.

소규모 업데이트 노트: 점진적인 개선, 작은 UX 변화. 짧은 형식이 여기에 적합하며, 일반적으로 항목당 한두세 줄입니다.

버그 수정 노트: 해결된 문제들. 사용자 경험 중심의 목록 형식, 간결한 언어로, 이전과 현재의 차이점에 초점을 맞춤.

보안 패치 노트: 간결하고 사실 기반. 무엇이 취약했는지, 무엇이 수정되었는지를 우선적으로 설명하되, 혼란을 초래할 수 있는 기술적 세부사항은 생략합니다.

릴리스 노트가 중요한 이유

그들은 배송과 사용 사이의 다리입니다. 변화된 사항을 이해하는 사용자는 새로운 기능을 탐색하고 수용할 가능성이 더 높습니다. 릴리스 노트는 엔지니어링 팀이 구축한 것을 사용자가 실제로 시도해보고 싶어하는 것으로 번역하는 제품 커뮤니케이션 순간입니다. 이러한 번역이 없다면 기능은 주목받지 못하고, 기능 수용이 저하되어 팀이 투자한 노력이 제 기능을 발휘하지 못하게 됩니다.

그들은 당신의 지원 팀의 업무량을 줄입니다. 사전 안내가 포함된 릴리스 노트는 무언가가 왜 다르게 보이거나 다르게 작동하는지에 대한 문의를 줄입니다. 사용자가 예상치 못한 변화를 접하면 지원 티켓을 엽니다. 그러나 이미 명확한 설명을 읽었다면 그렇게 하지 않습니다. 공식은 간단합니다: 사용자가 변화에 부딪히기 전에 그 변화를 문서화하세요.

그들은 고객의 신뢰와 유지를 구축합니다. 눈에 보이고 정기적인 릴리스 노트는 제품이 적극적으로 개선되고 있음을 나타냅니다. 갱신하거나 확장 여부를 평가하는 고객에게 건강한 변경 로그는 제품이 발전하고 있다는 증거입니다. 기능 요청을 제출한 고객은 릴리스 노트에서 자신의 피드백이 반영되는 것을 보면서 충성도가 깊어집니다.

그들은 내부 조정을 강화합니다. "무엇이 변경되었고, 누가 이를 위해 변경되었으며, 왜 중요한가"라는 질문에 구체적으로 답하는 좋은 릴리스 노트를 작성하는 규율은 제품 팀이 조직 전체에 걸쳐 명확하게 소통하도록 강제합니다. 제품 마케팅, 고객 성공, 그리고 영업 모두 릴리스 커뮤니케이션이 명확하고 일관될 때 혜택을 봅니다. 릴리스 노트는 다른 팀이 고객과 새로운 사항에 대해 이야기할 때 참고하는 진실의 원천이 되는 경우가 많습니다.

릴리스 노트에 포함할 내용

릴리스 노트의 구성을 생각해 보세요. 모든 우수한 릴리스 노트는 이러한 요소를 포함하지만, 주요 기능을 발표하는지 일상적인 버그 수정을 하는지에 따라 깊이는 달라집니다:

헤더 줄: 제품 이름, 버전 번호 또는 날짜, 그리고 관련이 있을 경우 환경 (웹, iOS, API 등).

변경 요약: 이번 릴리스는 무엇을 다루고 있으며, 누구에게 영향을 미치는지를 한두 문장으로 정리합니다. 이 부분은 사용자가 가장 먼저 읽는 부분이므로, 중요성을 담아 작성하세요.

새로운 기능: 이름을 붙여서, 간단한 사용자 영향과 함께. 사용자가 이제 무엇을 할 수 있는지로 시작하며, 기술적 구현은 제외하세요.

개선 사항: 사용자의 관점에서 무엇이 변경되었는지. "검색 결과가 이제 40% 더 빨리 로드됩니다."가 "검색 인덱싱 파이프라인을 최적화했습니다."보다 더 좋습니다.

버그 수정: 사용자가 이전에 경험한 내용과 현재 어떤 일이 발생하는지에 대한 간단한 설명. "대시보드가 날짜 범위로 필터링할 때 더 이상 멈추지 않습니다"는 사용자가 무엇이 잘못되었는지와 그것이 수정되었음을 정확하게 전달합니다.

알려진 문제 또는 한계: 문제가 완전히 해결되지 않았다면 그렇게 말하세요. 사용자들은 불완전함보다 투명성을 더 존중합니다.

릴리스 노트 작성 방법

포함할 내용을 아는 것은 기초입니다. 그것을 어떻게 작성하느냐가 누군가 실제로 읽을지 여부를 결정합니다. 이 일곱 단계는 흐름에 맞춰 정리되었습니다: 무엇을 말할지, 그런 다음 어떻게 말할지, 그다음 어떻게 제시할지입니다.

1. 기능이 아니라 사용자에 초점을 맞추세요.

이것은 릴리스 노트 작성에서 가장 중요한 원칙입니다. 모든 변경 사항은 문제를 해결하거나 사용자에게 기능을 제공하기 위해 만들어졌습니다. 그것을 우선적으로 강조하세요.

본능적으로 당신의 팀이 만든 것을 설명하고 싶겠지만, 이를 저항하세요. 대신 사용자가 이제 무엇을 할 수 있는지 (또는 더 이상 무엇을 처리하지 않아도 되는지) 설명하세요.

이전: "구성 가능한 청크 크기를 가진 데이터 내보내기 위한 배치 처리 구현."

이제 시간 초과 없이 대규모 데이터 세트를 내보낼 수 있습니다. 10,000행에서 실패하던 내보내기가 이제는 500,000행까지 처리할 수 있습니다.

첫 번째 버전은 엔지니어링 작업을 설명합니다. 두 번째는 사용자의 경험을 설명합니다. 두 번째 버전을 작성하세요.

2. 변경의 의도를 명확히 하다.

릴리스 노트를 스캔하는 사용자는 두 가지를 원합니다: 무엇이 변경되었는지와 그것이 그들에게 영향을 미치는지. 각 항목의 첫 문장에서 두 가지 답변을 명확히 하세요.

명확성은 중요합니다. 웹 사용자는 선형적으로 읽지 않습니다. 그들은 스캔합니다. 따라서 릴리스 노트를 스캔하기 쉽게 만드세요. 중요한 키워드를 강조하세요. 기능 이름과 변경 유형에 대해 굵은 글씨를 사용하세요. 각 줄의 가장 중요한 정보를 앞부분에 배치하세요.

수정된 버그와 업데이트가 적용되었습니다.

수정 완료: "앱 간 전환 시 예기치 않은 충돌을 일으키는 버그를 수정했습니다. 이제 모든 지원되는 기기에서 앱 전환이 안정적입니다."

첫 번째 버전은 짧지만 사용자에게 아무것도 알려주지 않습니다. 두 번째는 여전히 간결하지만 사용자가 실제로 가지고 있는 질문에 답변합니다.

3. 평범한 언어 사용하기

릴리즈 노트는 다양한 목적을 수행할 수 있습니다: 새 기능을 홍보하고, 사용자와의 관계를 구축하며, 사람들에게 해결책을 찾도록 돕는 것입니다. 그러나 노트가 오직 엔지니어 팀만 이해하는 기술 용어로 가득 차면 그 어떤 것도 효과가 없습니다.

전문 용어를 쉽게 이해할 청중이 아닌 경우, 용어 사용을 줄이세요. 간단하고 이해하기 쉬운 표현을 사용하세요. 좋은 테스트 방법은, 기술적 배경을 모르는 사람에게 릴리즈 노트를 큰 소리로 읽어주는 것입니다. 그들이 이해하면, 여러분의 사용자도 이해할 것입니다.

이제는 우리가 메시징 서비스에 대해 파일 압축, 투명성, 인터레이싱 및 단일 파일 내 여러 이미지를 저장할 수 있는 기능을 포함한 그래픽 교환 형식 비트맵 이미지를 사용할 수 있도록 구현했습니다.

이제 우리의 메시징 서비스에서 GIF를 사용할 수 있습니다.

단순한 언어는 사물을 간단히 만드는 것이 아닙니다. 그것은 사용자의 시간을 존중하는 것입니다.

4. 복잡한 변경사항에 대한 시각자료 추가

릴리스 노트에 긴 설명이 필요하다면, 대신 시각적 요소를 추가할 신호입니다. 기능이 작동하는 모습을 보여주는 짧은 GIF나 주석이 달린 스크린샷은 UI 변경에 대한 두 개의 단락 설명보다 더 많은 것을 전달합니다.

이는 특히 다음과 같은 경우에 유용합니다:

새로운 UI 요소 또는 레이아웃 변경 (변경 전과 후를 보여줌)

새로운 워크플로우 또는 다단계 기능(15초 화면 녹화)

데이터 시각화 기능(실제 출력의 스크린샷)

비주얼은 독자의 부담을 줄이고 릴리즈 노트를 더 기억에 남게 만듭니다. 변화가 본질적으로 시각적일 때, 시각적으로 보여주세요.

5. 스캔을 위한 정리

사용자들은 긴 텍스트를 읽으라고 하면 무감각해집니다. 소제목, 카테고리, 글머리 기호, 문단 구분 등을 사용하여 내용을 정리하고 분리해 주세요. 큰 텍스트 블록을 나누면 사용자가 모든 내용을 읽지 않고도 어떤 변경 사항이 자신에게 적용되는지 찾는 데 도움이 됩니다.

좋은 조직적 형식에는 다음이 포함됩니다:

유형별 변경 사항 그룹화: 새 기능, 개선 사항, 버그 수정

"새로움", "개선됨", "수정됨"과 같은 레이블이나 태그를 사용하여 빠른 스캔을 위해

상위에 간단한 요약을 추가하여 하이라이트만 원하는 사용자들을 위한 것입니다.

일부 사용자만 필요한 자세한 기술 노트를 위해 접을 수 있는 섹션 사용하기

6. 템플릿을 사용하고 그것을 고수하세요.

일관성은 특징이지 제한이 아닙니다. 귀하의 릴리스 노트가 예측 가능한 구조를 따를 때, 사용자는 자신이 관심 있는 정보를 어디에서 찾아야 하는지 배우게 됩니다. 그들은 정보를 분석하는 데 덜 시간을 소비하고 이해하는 데 더 많은 시간을 할애할 것입니다.

템플릿을 선택하세요(다음 섹션에 복사할 수 있는 것이 있습니다), 제품에 맞게 사용자 정의하고 매번 사용하세요. 이렇게 하면 구조가 이미 결정되어 있으므로 팀의 글쓰기 과정도 빨라집니다.

7. 브랜드의 목소리에 맞추고, 엔지니어링의 목소리는 맞추지 마세요.

릴리스 노트는 커밋 메시지처럼 들려서는 안 되고, 당신의 브랜드처럼 들려야 합니다. 당신의 브랜드가 따뜻하고 친근하다면, 릴리스 노트도 그렇도록 해야 합니다. 당신의 브랜드가 정확하고 전문적이라면, 그에 맞춰야 합니다.

핵심은 지나치지 않으면서 진정성을 유지하는 것입니다. 명확성을 희생하지 않으면서 개성을 추가할 수 있습니다. 약간의 따뜻함은 큰 효과를 발휘하지만, 지나친 자기 홍보는 신뢰를 약화시킵니다. 유용한 가이드라인: 콘텐츠의 80%는 진정으로 유용한 정보여야 하고, 20%만이 브랜드 포지셔닝이나 목소리를 반영해야 합니다.

피해야 할 것: "우리는 당신의 작업 흐름을 혁신하기 위해 여기 있습니다. 매 업데이트마다 이를 성공적으로 이뤘습니다. 환영합니다. 우리의 새로운 핫픽스는 에너지 소비를 50% 줄였습니다."

버그 수정: 소프트웨어가 이제 최종 사용자 에너지 소비를 50% 줄입니다. 지속 가능한 미래를 위해 노력하는 많은 방법 중 하나입니다.

첫 번째 버전은 브랜드를 부풀리고 과도한 약속을 한 후에 변화를 언급합니다. 두 번째 버전은 해결책을 먼저 말한 다음, 자연스럽게 브랜드 요소를 추가합니다.

릴리스 노트 템플릿

여기 복사하여 수정할 수 있는 릴리스 노트 템플릿이 있습니다. 이는 대부분의 업데이트에 필요한 사항을 포함합니다. 릴리스의 범위에 따라 깊이를 조절하세요: 주요 릴리스는 기능당 더 많은 세부 정보를 제공하고, 소규모 릴리스는 섹션을 압축할 수 있으며, 버그 수정 전용 릴리스는 "새로운 기능" 블록을 완전히 생략할 수 있습니다.

[제품 이름] 릴리스 노트 - [버전 번호 또는 날짜]

요약: [이번 릴리스는 어떤 문제를 다루고 있으며, 누구에게 영향을 미치는지에 대한 1-2 문장 개요]

무엇이 새롭습니까

- [기능 이름]: [무엇을 하는지와 사용자에게 왜 중요한지]

- [기능 이름]: [그 기능이 하는 일과 사용자에게 중요한 이유]

개선 사항

- [무엇이 바뀌었는가] - [사용자 경험에 미치는 영향]

버그 수정

- [사용자가 경험한 것] - [지금 일어나는 일]

알려진 문제

- [문제 설명] - [사용 가능한 경우 우회 방법 또는 일정]

질문이 있습니까? [도움 문서 또는 지원 연락처 링크]

템플릿을 조정하는 방법: 세 가지 새로운 기능이 포함된 주요 릴리스의 경우, 각 기능에 대한 단락을 추가하여 "새로운 내용" 섹션을 확장합니다. 소규모 개선이 다섯 가지 있는 마이너 릴리스의 경우, "새로운 내용"과 "개선 사항"을 단일 목록으로 통합할 수 있습니다. 버그 수정 전용 릴리스의 경우, 수정 사항을 먼저 소개하고 기능 섹션은 완전히 생략합니다. 구조는 내용을 지원해야 하며, 그 반대가 되어서는 안 됩니다.

13 릴리스 노트 예시, 가장 잘하는 것에 따라 정리됨

아래의 예시는 각 회사의 릴리스 노트가 특히 잘하는 점을 기반으로 다섯 가지 카테고리로 정리되어 있습니다. 각 예시에는 회사가 하는 일, 릴리스 노트가 잘하는 점, 그리고 여러분이 본인에게 적용할 수 있는 구체적이고 전이 가능한 교훈이 포함되어 있습니다.

릴리스 노트

무슨 새로운 일이 있나요? 뭐가 변했나요?

목차

다른 언어들