changelog 예시

1. 일상적인 SaaS 릴리스

흔한 경우: 사용자에게 보이는 몇 가지 변경 사항, 마이그레이션 없음, 드라마 없음. 릴리스가 작았기 때문에 짧으며, 그것을 부풀리고 싶은 충동에 저항하는 것이 그 기술의 대부분입니다.

## 2026년 8월 20일

### 새 기능
- 받은편지함에 저장된 뷰. 필터를 한 번 고정하면 사이드바에서
  재사용할 수 있습니다.

### 개선
- 내보내기 작업이 대규모 계정에서 멈춘 것처럼 보이는 대신
  진행 상황을 보고합니다.

### 수정
- 초대된 멤버가 첫 로그인 전에 빈 대시보드를 보는 일이
  없어졌습니다.

2. 폐기를 포함한 API 릴리스

API changelog의 독자는 한 가지를 찾습니다: 자신의 통합이 곧 깨질 것인지, 그리고 얼마나 시간이 남았는지. 그것을 맨 위에 두고 날짜를 붙이세요.

## Acme API 4.2 - 2026년 8월 20일

### 호환성이 깨지는 변경 사항
- `?page=`가 모든 목록 엔드포인트에서 제거되었습니다.
  이전 응답의 `nextCursor` 값을 사용하세요.
  `?page=`는 2026년 10월 1일 이후 400을 반환합니다.
  마이그레이션 단계: acme.example/docs/pagination

### 새 기능
- webhook을 단일 프로젝트로 제한할 수 있습니다.

### 개선
- 목록 엔드포인트가 10,000개 이상의 레코드가 있는
  계정에서 약 4배 더 빠르게 응답합니다.

3. 모바일 릴리스

앱 스토어는 잘린 새 소식 필드를 보여주며, 심사가 빌드를 며칠 동안 지연시킬 수 있습니다. 두 사실 모두 항목을 형성합니다.

## iOS 3.4.0 - 2026년 8월 20일

오프라인 모드. 연결 없이 열고, 읽고, 초안을 작성하세요.
다시 온라인 상태가 되면 모든 것이 동기화됩니다.

### 이번 릴리스에도 포함된 내용
- 구형 기기에서 더 빠른 실행.
- Mail에서 공유 링크를 열 때 발생하던 충돌 수정.

4. 보안 수정

적게 말하는 것이 옳은 유일한 항목입니다. 사용자는 업데이트해야 한다는 것을 알아야 하지만, 다른 누구도 아직 업데이트하지 않은 버전을 공격할 만큼 정확한 설명이 필요하지 않습니다.

## 2026년 8월 20일

### 보안
- 세션 토큰 검증 방식을 강화했습니다. 자체 호스팅 설치의
  계정은 4.2.1 이상으로 업데이트해야 합니다. 책임감 있게
  보고되었으며 악용된 증거는 없습니다.
  자세한 내용: acme.example/security/2026-08

5. 나쁜 예시는 이렇게 생겼다

여기 있는 모든 줄은 형태로는 진짜이며, 모든 줄이 실수입니다:

## v2.3.7

- feature/inbox-refactor에서 PR #482 병합
- lodash를 4.17.20에서 4.17.21로 업데이트
- MembershipCache.resolve()의 레이스 컨디션 수정
- 다양한 버그 수정 및 개선
- SavedView 모델 리팩터링 (Dave에게 감사!)

좋은 것들의 공통점

• 구현이 아니라 결과를 설명합니다. 코드를 한 번도 본 적 없는 독자도 항목이 자신에게 영향을 미치는지 알 수 있습니다.
• 것들을 생략합니다. 의존성 업데이트, 리팩터링, CI 변경, 내부 이름 변경이 없으며, 그 부재가 나머지를 읽기 쉽게 유지합니다.
• 비용이 큰 것을 먼저 둡니다. 무언가 깨진다면 그것이 날짜와 함께 첫 번째 제목입니다.
• 독자가 사용할 수 있는 방식으로 날짜가 지정됩니다: 사용자가 버전을 볼 수 있는 곳에서는 버전 번호, 볼 수 없는 곳에서는 날짜.
• 의도적으로 지루합니다. 느낌표도, 마케팅용 형용사도, '발표하게 되어 기쁩니다'도 없습니다. changelog를 읽는 사람들은 정보를 찾고 있으며, 그것을 방해하는 무엇에든 짜증을 낼 것입니다.

자주 묻는 질문

changelog는 어떤 형식을 사용해야 하나요?

keepachangelog.com이 표준에 가장 가까우며, 그 섹션 이름(Added, Changed, Deprecated, Removed, Fixed, Security)은 널리 인정받고 있습니다. 이는 섹션 내부의 표현 방식보다 훨씬 덜 중요합니다. 모호한 항목이 있는 일관된 형식은 구체적인 항목이 있는 느슨한 형식보다 나쁩니다.

얼마나 자주 게시해야 하나요?

여러분의 릴리스에 맞는 어떤 리듬이든, 그리고 일관되게. 릴리스별로 게시하는 것이 가장 간단한 규칙입니다. 한 달치 릴리스를 하나의 게시물로 묶으면 나중에 각 개별 변경 사항을 찾기 더 어려워지며, 그때가 바로 대부분의 사람들이 실제로 changelog를 읽는 순간입니다.

changelog는 자체 사이트에 있어야 하나요, 아니면 제3자 페이지에 있어야 하나요?

가능하다면 자체 사이트에 두세요. 트래픽과 검색 가치가 그곳에 쌓이기 때문이고, 다른 사람의 도메인에 있는 changelog는 여러분 제품의 일부가 아니라 그로부터 링크 하나 떨어진 곳에 있기 때문입니다. 이것이 링크를 거는 호스팅된 페이지가 아니라 직접 렌더링하는 피드로 제공하는 근거입니다.

사용자가 정말로 changelog를 읽나요?

소수의 사람들이 정기적으로 읽고, 훨씬 많은 사람들이 자신의 발밑에서 무언가가 바뀐 순간에 그것을 검색합니다. 그 두 번째 그룹이 원인이 아니라 증상을 써야 하는 이유입니다. 그들은 자신의 말로 자신에게 일어난 일을 검색하고 있기 때문입니다.

더 읽어보기: changelog와 릴리스 노트의 차이, 그리고 Keep a Changelog, 실제로 구현하기.