내가 쓴 릴리즈 노트는 왜 안 읽힐까?
변경된 내용은 다음과 같습니다!
최근 신규로 배포한 기능 건에 대해 직접 릴리즈 노트를 작성할 기회를 얻었다. 인수조건이나 기획서야 당연히 써보았지만, 릴리즈 노트는 여태껏 한 번도 내 손으로 써본 적이 없었다. 그도 그럴 것이 지금까지는 CX파트에서 이를 작성해주셨기 때문에 배포 건에 대한 세부 내용은 업무용 메신저인 슬랙으로 공유하거나, 전사 타운홀 시간에 발표하는 정도가 전부였다. 릴리즈 노트라니. 수십 만에 달하는(..물론 모두가 읽진 않겠지만) 유저가 읽을 글이라고 생각하니 눈앞이 핑핑 도는 기분이었다.
*릴리즈 노트(Release Note) - 소프트웨어의 개선 사항과 추가 기능들을 요약한 문서
유저들이 릴리즈 노트를 읽지 않는 이유
무엇이든 잘하고 싶을 때는, Do보다는 Don't에 집중하라는 말이 있다. 유저들은 어떤 경우에 릴리즈 노트를 잘 읽지 않을까?
1. 읽기엔 너무 긴 릴리즈 노트
릴리즈 노트란 위에서 언급했듯이 앱 또는 웹과 같은 소프트웨어의 개선사항, 즉 주요 업데이트 사항을 요약한 문서이다. 서비스의 버그 수정 건이나 신규 기능의 추가 건, 기존 기능의 삭제 건 등 서비스상 일어나는 다양한 변경점들이 내용으로 담길 수 있다. 서비스를 만드는 입장에서는 고객들에게 전달하고 싶은 말이 많을 수도 있다. "우리는 이런 일도 하고 있고, 저런 일도 하고 있어요. 심지어 이런 신규 기능도 나왔어요, 멋지죠!" 그럼에도 불구하고 릴리즈 노트는 최대한 핵심적인 내용만 담아 간결하게 작성되어야 한다.
릴리즈 노트를 읽는 유저의 수는 얼마나 될까? 기대보다는 많을 수야 있지만, 전체 사용자 규모로 보면 그리 많지는 않을 것이다. 그 와중에 시간을 내어 업데이트 사항을 읽으러 온 고마운 유저들을 지루하게 만들어서 돌려보내지 말자.
2. 지나치게 기술적인 내용
어떤 글이든 읽는 이, 즉 독자를 고려하여 작성되는 것이 바람직하다. 서비스 입장에서 릴리즈 노트를 읽는 대상은 누구일까? 때로는 내부의 사용자 들일 수도 있지만, 더 많은 경우에는 외부에 있는 일반적인 유저들이다. 기술적인 용어로 작성된 릴리즈 노트는 유저 입장에서 어떤 가치를 얻을 수 있는지 이해하기 어렵다. 그렇기 때문에 내부의 히스토리 관리는 별도로 하되 릴리즈 노트는 항시 유저 관점에서, 사용자 친화적인 언어로 작성되는 것이 좋다.
임팩트가 미미한, 자잘한 버그 수정 건과 같이 굳이 고객이 알 필요 없는 사소한 변경점들 역시 과감하게 덜어내자. 이는 오히려 서비스를 이용하는 고객을 혼란스럽게 할 뿐이다.
3. 참고할 만한 정보나 링크를 전혀 포함하지 않는 경우
참고할 만한 정보가 없는 릴리즈 노트만큼 유용한 것이 없다. '소소한 버그 수정'과 같은 릴리즈 노트가 대표적인 예시라 할 수 있다. 유저가 그 글을 읽음으로써 얻을 수 있는 정보 효용 가치가 0에 수렴한다.
또한 참고 링크가 전혀 없다고 해서 릴리즈 노트를 읽지 않는 것은 아니겠지만, 효과가 떨어지는 것은 사실이다. 단순히 줄글만 있는 릴리즈 노트로 유저의 액션이나 반응을 유도하는 데에는 한계가 있다. 전달하고자 했던 내용을 유저들이 잘 소화시킬 수 있는 형태로 전달하되 이후 행동으로까지 파생될 수 있도록 디테일을 챙길 필요가 있다.
릴리즈 노트를 잘 쓰려면
릴리즈 노트를 잘 쓰는 방법은 단순하다. 위에서 언급된 내용을 반대로 하면 된다.
1. 간결하고 명확하게, 일관된 언어로 작성한다
최대한 핵심적인 내용만 간추려서 명확하고 일관된 언어로 전달하자. 예를 들어, 서비스에서 장바구니를 '수강바구니'라고 칭하고 있다면 수강바구니라는 단어를 일관적으로 사용한다. 상황에 따라 장바구니로 쓰거나 carts로 쓰는 등, 읽는 이로 하여금 혼동을 주는 표현은 지양한다.
2. Call to Action을 포함한다
빽빽한 줄글 형태보다는 최대한 간결하게 작성하되, 서비스를 이용하는 유저에게 충분한 정보를 제공할 수 있도록 미디어나 참고 링크가 포함된 형태로 작성한다. 신규로 배포되었거나 개선된 기능에서 의외의 효과(반응)를 거둘 수 있을지도 모른다. 단, 이 경우 유저의 CS 역시 함께 인입될 수 있으므로 문의할 수 있는 공식 창구나 서포트봇을 함께 안내하는 것이 중요하다. (이 부분은 CX 팀과의 협업이 필요하다.)
3. 한 가지 채널로만 전달하지 않는다
릴리즈 노트의 내용이 동일해도 좋으니 한 가지 채널로만 배포하지 말자. 서비스에서 활용하고 있는 뉴스레터나 대화형 서포트봇이 있다면 해당 채널을 활용해서 최대한 많은 유저들이 원문에 도달할 수 있도록 만든다. 여러 채널로 릴리즈 노트를 전달할 경우에는 분명한 이점이 있다.
예를 들어, 서비스의 SNS를 통해 전달하는 경우 유저들의 반응을 조금 더 적나라하고 손쉽게 '눈으로' 확인할 수 있다. 또 뉴스레터(이메일)를 통해 발송하는 경우, 서비스에 로그인하지 않은 유저들에게 접근할 수 있다. 채널별 장점을 최대한 취할 것.
릴리즈 노트의 좋은 사례
업무용 메신저 툴인 슬랙(Slack) 팀은 릴리즈 노트를 잘 쓰기로 업계에 정평이 나있어 예시로 들고 왔다.
1. 먼저 출시 버전과 날짜를 잘 기입하고,
2. 주요하게 변경된 내용이 무엇인지 잘 소개하고,
3. 버그 수정 건을 유저가 잘 이해할 수 있는 형태로 설명하고,
4. 참고할 수 있는 문서는 링크로 제공하며,
5. 서비스의 유쾌한 보이스톤을 잃지 않는다.
몇 문장 읽지 않았음에도 어쩐지 이 릴리즈 노트를 쓴 사람은 일도 되게 잘할 것 같은 합리적 의심이 든다.
릴리즈 노트의 이점
솔직히 처음 릴리즈 노트를 작성할 때까지만 해도 유저가 이 글을 과연 읽을지, 읽고 나서 어떻게 느낄지 자신이 없었다. 보이스톤부터 첨부하는 이미지, 링크, 문의 창구까지 과도하게 신경을 쓰다 보니 이게 정말 제대로 쓴 게 맞는지 멘붕이 오기도 했었다.
그럼에도 작성한 노트에 유저들의 반응이 나타나는 걸 보며, 릴리즈 노트를 작성하는 일이 꽤나 번거로운 일처럼 느껴질 수 있지만, 서비스가 나아가고 있는 방향을 유저에게 투명하게 공유하고 피드백을 받을 수 있는 커뮤니케이션 수단이 되기도 한다는 걸 깨달을 수 있었다. 뿐만 아니라, 릴리즈 노트는 같은 공간에 오랜 기간에 걸쳐 차곡차곡 쌓이기 때문에 유저로 하여금 서비스가 지속적으로 성장하고 있음을 알릴 수 있는 방법이 되기도 한다는 것 역시 알게 되었다.
오늘부터는 앱스토어에 올라온 여러 서비스들의 릴리즈 노트 역시 눈여겨보게 될 것 같다. 좋은 서비스를 만들기 위해 피땀 흘리고 있는 전국의 많은 메이커 여러분들에게 응원의 목소리를 전하고 싶다 :)
