실전 릴리스 노트

실제로 읽히는 제품 업데이트 이메일 템플릿

4분 분량 업데이트

실제로 읽히는 제품 업데이트 이메일은 그것이 알리는 바로 그것을 정확히 요청했던 사람에게 보내진 것이다. 나머지 모든 것은 받은 편지함의 나머지와 흥미로움을 두고 경쟁하며, 릴리스 발표는 대부분의 주에 이 경쟁에서 진다. 이 하나의 사실이 어떤 문구보다 먼저 이메일의 형태를 결정해야 한다. 누가 그것을 받는지, 그리고 그 사람이 목록에 오르기 위해 무엇을 했는지.

제품 업데이트 이메일이란 무엇인가

기존 사용자에게 이미 사용 중인 제품에서 무엇이 바뀌었는지 알려주는 메시지다. 네 가지 서로 다른 유형이 있으며, 이들을 하나의 목록으로 취급하는 것이 오픈율이 떨어지는 이유다. 각각 다른 트리거, 다른 독자층, 다른 허용 가능한 빈도를 가진다.

유형트리거독자층빈도
타겟 알림누군가의 구체적인 요청이 출시됨한 사람발생할 때마다
파괴적 변경 알림독자에게 작업을 강요하는 변경영향받는 계정만발생할 때마다
다이제스트시간의 경과옵트인한 사용자최대 월 1회
출시 발표방해할 가치가 있는 출시세그먼트 또는 전체드물게, 드물게 느껴져야 함

대부분의 팀은 세 번째 유형만 만들고, 모두에게 보내고, 제품 업데이트 이메일이 효과가 없다고 결론짓는다. 처음 두 유형이 거의 모든 가치를 담고 있다. 독자에게는 이미 관심을 가질 이전의 이유가 있고, 메시지는 그 이유가 아직 살아 있는 동안 도착하기 때문이다.

여기 나온 네 줄은 모두 고객을 위해 쓰여 있다. 영업팀, 지원팀, 고객 성공팀도 무엇이 출시됐는지 알아야 하며, 보통 이 넷과는 다른 형태로 알아야 한다; 내부용 릴리스 노트가 그 문서가 무엇을 말해야 하는지와, 왜 고객용 노트보다 먼저 나가야 하는지를 다룬다.

이메일은 출시 발표가 사용할 수 있는 여러 채널 중 하나일 뿐, 유일한 것이 아니다. 새 기능을 어떻게 발표해야 하는가가 나머지 채널과, 기능이 실제로 얼마나 큰지에 따라 그 사이에서 어떻게 선택하는지를 다룬다.

템플릿에는 무엇이 들어가야 하는가

이 순서로 여섯 개의 블록이 있다. 첫 번째가 보통 빠져 있는 것이며, 실제로 일을 해내는 것이다.

제목:  <무엇이 바뀌었는지, 독자의 언어로>

1. 왜 이것을 받는가
   "귀하는 3월에 CSV 내보내기를 요청하셨습니다." 또는
   "귀하의 통합은 1월 15일에 변경되는 /v1/invoices를 호출하고
   있습니다."

2. 무엇이 바뀌었는가
   한 문장으로. 이제 무엇이 가능한지, 또는 이제 무엇이 깨지는지.

3. 무엇을 해야 하는가
   흔히 "아무것도 없음". 암시로 남기지 말고 명시적으로 말하라.

4. 어디서 볼 수 있는가
   홈페이지가 아니라 체인지로그 항목으로의 링크.

5. 언제
   출시된 날짜, 또는 언제부터 적용되는지.

6. 어떻게 구독을 취소하는가
   클릭 한 번, 즉시 존중됨.

블록 1은 메시지와 일괄 발송의 차이다. 첫 문장에서 이것이 자신이 개인적으로 요청했던 것의 해결이라는 말을 듣는 독자는 나머지를 읽는다. 그것이 없으면 블록 2에서 5까지는 아무리 잘 쓰였어도 뉴스레터일 뿐이다.

전체를 약 150단어 이하로 유지하라. 이메일은 체인지로그 항목을 가리키는 포인터이며, 세부 사항이 속한 곳은 그쪽이다. 항목 전체를 재현하는 이메일은 독자에게 클릭할 이유를 주지 않고, 여러분에게는 누군가가 신경 썼는지에 대한 신호도 주지 않는다.

어떤 제목이 효과가 있는가

릴리스가 아니라 변경 사항을 명명하라. “CSV 내보내기가 라이브됨”은 “9월 업데이트”를 이긴다. 전자는 독자가 평가할 수 있는 사실이고 후자는 그릇에 불과하기 때문이다. 제목의 버전 번호는 API 호출자에게는 유용하고 나머지 모두에게는 잡음이며, 독자층을 나누어야 할 또 다른 이유다.

독자가 동의하지 않은 이점을 주장하는 것을 피하라. “귀하의 리포트가 이제 더 빨라졌습니다”는 그의 경험에 대해 무언가를 주장한다. “10,000행이 넘는 리포트가 이제 1초 이내에 로드됩니다”는 변경 사항을 보고하고 그것이 중요한지는 그가 결정하게 한다.

언제, 누구에게 보내야 하는가

그것이 출시되는 순간, 그것을 요청했던 사람들에게 개별적으로 타겟 알림을 보내라. 날짜가 확정되는 즉시, 그리고 그에 가까워질 때 다시 한번, 전체 목록이 아니라 실제로 영향받는 계정에 파괴적 변경 알림을 보내라. 그렇지 않으면 독자가 무언가를 놓칠 만큼 충분한 변경 사항이 있을 때만 다이제스트를 보내고, 사람들이 별도로 등록하게 하라.

거의 절대 사용하지 말아야 할 목록은 “모든 사용자”다. 구체적인 메시지를 일반적인 메시지로 바꾸고, 구독 취소를 훈련시킨다. 이미 저장하고 있는 행동으로 세그먼트하라. 누가 요청했는지, 누가 이 엔드포인트를 사용하는지, 누가 이 플랜에 있는지.

이것을 보내는 데 동의가 필요한가

기존 고객에게는 이미 사용 중인 서비스에 대한 업데이트가 보통 잠재 고객에 대한 마케팅과는 다른 법적 문제이며, 답은 그들이 어디에 있는지와 가입 시 무엇을 알려주었는지에 달려 있다. EU에서는 GDPR 제6조의 어떤 법적 근거가 적용되는지가 관련 질문이며, 미국에서는 상업적 메시지가 FTC의 CAN-SPAM 준수 가이드에 명시된 구체적인 요건을 가진다. 둘 다 실질적으로 같은 것을 요구한다. 여러분이 누구인지 밝히고, 목적을 명확히 하고, 사람들이 멈출 수 있게 하라.

근거가 무엇이든, 거래성 흐름과 마케팅 흐름을 발송 수준에서 분리하라. 프로모션 다이제스트와 목록을 공유했다는 이유로 고객이 구독을 취소한 파괴적 변경 알림은 그 날짜를 기다리는 지원 사고다.

실제로 채워 넣으면 어떤 모습인가

타겟 알림, 가장 가치 있는 제품 업데이트 이메일이자 대부분의 팀이 절대 만들지 않는 것이다.

제목: CSV 내보내기가 라이브됨

안녕하세요 Dana님,

3월에 CSV 내보내기를 요청하셨죠.

오늘 아침 라이브되었습니다. 리포트에는 이제 필터를 포함한
현재 뷰의 CSV를 생성하는 내보내기 버튼이 있습니다.

귀하 쪽에서 할 일은 없습니다. 이미 귀하의 계정에서 활성화되어
있습니다.

  세부 정보: example.com/changelog#csv-export
  출시일: 2026년 9월 2일

이것을 요청하셨기 때문에 받으셨습니다. 요청 업데이트에서
구독 취소: <링크>

90단어이며, 독자는 첫 문장에서 왜 이것이 도착했는지 안다. 이것을 월간 다이제스트에서 아홉 개 항목 중 하나로 나타나는 같은 변경 사항과 비교해 보라. Dana에게는 자신의 요청이 나갔다는 것을 알아챌 이유가 없다.

무엇을 측정해야 하는가

오픈율만이 아니다. 타겟 알림의 경우 질문은 요청했던 사람이 돌아와서 그것을 사용했는지이며, 따라서 추적해야 할 숫자는 항목으로의 클릭과 그 계정이 일주일 안에 기능을 사용하는지 여부다. 파괴적 변경 알림의 경우 커버리지다. 영향받는 계정 중 몇 퍼센트가 날짜 전에 열었는지, 그리고 누구와 개별적으로 후속 조치를 했는지.

다이제스트는 넷 중에서 오픈율이 많은 것을 의미하는 유일한 것이며, 그곳에서도 업계 벤치마크보다는 자체 기록에 대한 추세로서 더 유용하다. 서로 다른 유형의 제품 업데이트 이메일은 서로 다른 임무를 가지므로, 모두에 걸쳐 평균화된 숫자는 행동할 수 있는 무엇도 설명하지 못한다.

릴리스 노트와는 어떻게 다른가

릴리스 노트는 계속 사용 가능한 상태로 남는 문서다. 이메일은 한 번 일어나는 전달 메커니즘이다. 같은 변경 사항이 둘 다를 만들어내며, 이메일은 그것이 가리키는 항목보다 짧아야 한다. 릴리스 노트 모범 사례는 문서를 다루고, 체인지로그 대 릴리스 노트는 여러분이 지금 쓰고 있는 것이 무엇인지를 다룬다.

제대로 정립할 가치가 있는 관계는 이렇다. 체인지로그 항목이 정본 텍스트이고 이메일은 그것을 인용한다. 이 둘이 어긋나면 클릭한 독자는 변경 사항에 대한 다른 설명을 발견하고 둘 다에 대한 신뢰를 잃는다. 항목을 먼저 발행하고 거기서 이메일을 생성하면 구조적으로 그 어긋남이 제거된다. changeloop도 자기 쪽에서 같은 방식으로 동작한다. 항목은 한 번 검토되어 페이지, 피드, 위젯에 발행되며, 위젯을 통해 그것을 요청한 사람은 자신의 피드백으로 만들어진 GitHub 이슈와 위젯 자체에서 통보받는다. changeloop는 이메일을 보내지 않는다. 여러분의 이메일 도구가 발행된 항목을 인용한다.

FAQ

제품 업데이트 이메일은 얼마나 자주 나가야 하는가? 수신자가 알고 싶어 하는 구체적인 무언가가 있을 때마다이며, 타겟 알림의 경우 그의 요청이 출시될 때마다를, 다이제스트의 경우 최대 월 1회를 의미한다.

이메일에 체인지로그 항목 전체가 들어가야 하는가? 아니다. 한 문장과 링크면 된다. 항목이 정본 버전이며, 이메일 안의 전체 사본은 서로 맞춰야 할 두 개의 텍스트를 의미한다.

어떤 오픈율을 기대해야 하는가? 각 유형을 벤치마크가 아니라 그 자체와 비교하라. 타겟 알림과 월간 다이제스트는 서로 다른 제품이며, 그것들을 평균 내면 추적할 가치가 있는 유일한 숫자가 가려진다.

파괴적 변경을 위한 별도의 목록이 필요한가? 그렇다. 그리고 그것은 사람들이 결과를 이해하지 못한 채 무심코 구독을 취소할 수 없는 목록이어야 한다. 그것이야말로 그들에게 장애를 초래하는 목록이기 때문이다.


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

changeloop 관련 페이지: changelog 예시, 개발자 문서

changeloop
루프를 닫는 changelog를 만드는 팀입니다. 사용자가 무언가를 요청하면 팀이 전달하고, 요청한 사람은 알게 됩니다.