체인지로그, 왜 써야 하고 어떻게 쓸까?
업데이트 했는데, 아무도 모릅니다
지난 한 달간 팀이 열심히 만든 기능, 고객 몇 퍼센트가 알고 있을까요? 대부분의 경우 10%도 안 됩니다. 앱 스토어 업데이트 문구에 "버그 수정 및 성능 개선"이라고만 적어두면, 고객은 무엇이 바뀌었는지 알 수 없습니다.
체인지로그는 단순한 변경 기록이 아닙니다. 고객과의 신뢰를 쌓는 커뮤니케이션 채널입니다.
체인지로그가 필요한 3가지 이유
1. 고객 신뢰 구축
정기적으로 변경사항을 공개하면 고객은 "이 제품은 계속 발전하고 있구나"라고 느낍니다. 특히 고객이 요청한 기능이 반영되었을 때 이를 명시하면, "내 의견이 반영된다"는 강력한 신호가 됩니다.
2. 기능 채택률 향상
아무리 좋은 기능도 고객이 모르면 소용없습니다. 체인지로그를 통해 새 기능을 소개하면, 별도의 마케팅 없이도 기능 발견과 채택이 자연스럽게 일어납니다.
3. 팀 내부 정렬
체인지로그를 작성하는 과정 자체가 "우리가 이번에 무엇을 했고, 왜 했는지"를 정리하는 기회입니다. 팀 전체의 맥락 공유에도 도움이 됩니다.
좋은 체인지로그의 구성 요소
- 날짜: 언제 배포되었는지
- 제목: 변경의 핵심을 한 문장으로
- 라벨: 새 기능, 개선, 버그 수정 등 유형 구분
- 설명: 무엇이 바뀌었고, 왜 바뀌었는지
- 스크린샷이나 GIF: 시각적으로 변화를 보여주기
작성 팁 5가지
- 고객 관점에서 쓰세요: "API 엔드포인트 리팩토링"이 아니라 "데이터를 더 빠르게 불러올 수 있습니다"
- 간결하게 쓰세요: 길어야 2-3문장이면 충분합니다. 더 상세한 내용은 별도 링크로 연결하세요
- 정기적으로 발행하세요: 매주 또는 격주가 이상적입니다. 일관성이 핵심입니다
- 라벨을 활용하세요: 새 기능, 개선, 버그 수정을 시각적으로 구분하면 읽기 편합니다
- 피드백과 연결하세요: "여러분이 요청하신 기능입니다"라는 한 마디가 큰 차이를 만듭니다
체인지로그를 발행한 후, 효과적으로 고객에게 알리는 방법은 제품 업데이트 알림 전략에서 다루고 있습니다.
나쁜 체인지로그 vs 좋은 체인지로그
나쁜 예:
버그 수정 및 성능 개선
무엇이 바뀌었는지 전혀 알 수 없습니다. 고객은 이런 체인지로그를 읽지 않습니다.
좋은 예:
대시보드 로딩 속도가 50% 빨라졌습니다. 많은 분이 요청하신 CSV 내보내기 기능도 추가했습니다. 이제 피드백 목록을 한 번에 다운로드할 수 있어요.
구체적인 변화와 고객의 기여를 언급하니, 읽는 즐거움이 생깁니다. 다음 체인지로그도 기대하게 되죠.
TownHall의 체인지로그 기능
TownHall에서는 리치 텍스트 에디터로 체인지로그를 작성하고, 라벨을 붙이고, 초안/발행 상태를 관리할 수 있습니다. 발행하면 공개 체인지로그 페이지에 자동으로 노출됩니다. 무료로 시작해 보세요.
마무리
체인지로그는 제품과 고객 사이의 가장 효율적인 소통 채널 중 하나입니다. 오늘 발행한 업데이트를 체인지로그로 기록하는 것부터 시작해 보세요. 피드백 루프를 완성하는 전체 그림은 피드백 루프 만들기에서 확인하실 수 있습니다.
관련 글: