변경 로그 페이지 만드는 방법: 항목, 태그, RSS, '새로운 기능'

변경 로그 페이지는 제품에서 무엇이 바뀌었는지를 날짜순으로, 최신 항목이 위에 오도록 나열한 목록으로, 제품을 쓰는 사람들을 위해 작성합니다. 이것을 만들려면 날짜, 명확한 제목, 짧은 설명, 태그(New, Improved, Fixed)가 있는 항목, 항목을 나열하는 페이지, 항목마다 별도의 URL, 그리고 가능하면 RSS 피드와 사용자에게 새 소식을 알리는 방법이 필요합니다. 가장 단순하게 만들 수 있는 것 중 하나이며, 핵심 결정은 항목을 어디에 두느냐입니다. 사이트 안의 파일로 둘지, 관리자 페이지가 있는 데이터베이스에 둘지 정하세요.

변경 로그가 가치 있는 이유

변경 로그는 고객과 잠재 고객에게 제품이 꾸준히 관리되고 있다는 것을 보여 줍니다. 누군가 "이거 아직 되나요?"라고 물을 때 지원팀과 영업팀이 보낼 링크가 됩니다. 피드백을 마무리하는 자리이기도 합니다. 요청된 기능이 출시되면, 사람들에게 안내할 곳이 바로 변경 로그 항목입니다. 고객 피드백 포털을 운영한다면, 출시된 요청을 해당 항목으로 바로 연결하세요.

변경 로그는 내부 커밋 기록이 아닙니다. "청구 서비스 리팩터링"은 사용자에게 아무 의미가 없습니다. "이제 송장에 회사의 부가세 번호가 표시됩니다"는 의미가 있습니다.

페이지에 필요한 것

항목마다 들어갈 내용

페이지

• 변경 로그 목록: 최신순, 태그 필터, 간단한 페이지네이션 또는 "더 보기".
• 항목 페이지: URL마다 항목 하나, 링크하고 공유할 수 있도록.
• RSS 또는 Atom 피드: 이메일 없이도 사람들과 도구가 업데이트를 구독할 수 있게 합니다.
• 관리자 페이지(데이터베이스 버전에만): 항목 작성, 미리보기, 예약, 게시.

앱 내 추가 기능

• "새로운 기능" 배지: 사용자가 아직 보지 않은 항목이 있으면 메뉴 항목에 점을 표시합니다. 사용자별로 또는 브라우저에 마지막으로 연 항목의 날짜를 저장하세요.
• 이메일 요약: 수신에 동의한 사용자에게 보내는 요약. 발송 제공업체가 필요하며, 앱에서 이메일 보내는 방법을 참고하세요.

핵심 결정: 파일 또는 데이터베이스

사이트 안의 파일로 된 항목

각 항목은 프로젝트 안의 Markdown 파일입니다. 항목을 게시한다는 것은 파일을 추가하고 다시 배포하는 것입니다. 가장 단순하고 탄탄한 방법입니다. 데이터베이스도, 관리자 로그인도, 보호할 것도 없고, 페이지를 사전 렌더링할 수 있어 빨리 로드되고 검색엔진이 읽기도 쉽습니다.

항목을 쓰는 사람이 AI 빌더에게 요청하거나 파일을 편집하는 것에 익숙한 팀에 어울립니다.

관리자 페이지가 있는 데이터베이스의 항목

항목은 테이블에 저장되고, 비공개 관리자 페이지를 통해 팀의 누구나 작성, 미리보기, 예약, 게시할 수 있습니다. 마케팅이나 지원팀이 업데이트를 쓰거나, 예약 게시나 대상별 항목(예: 엔터프라이즈 고객에게만 엔터프라이즈 기능 표시)이 필요한 팀에 어울립니다.

대신 만들고 관리하는 데 더 많은 노력이 듭니다. 관리자 로그인, 이미지 업로드, 그리고 공개 페이지를 검색엔진이 계속 읽을 수 있도록 보장해야 합니다. 브라우저에서만 항목을 불러오는 페이지는 그렇지 않을 수 있습니다.

사람들이 읽는 항목 쓰기

• 혜택으로 시작하세요. "보고서를 Excel로 내보내기"가 "새 내보내기 모듈"보다 낫습니다.
• 누구에게 해당되는지 말하세요. 모든 요금제, Pro 전용, 이번 주부터 순차 적용 등.
• 보여 주세요. 스크린샷 하나나 짧은 클립.
• 작은 수정은 묶으세요. 글머리 기호가 있는 주간 "수정 및 개선" 항목 하나면 페이지가 넘쳐 나지 않습니다.
• 제거 사항은 솔직하게. 무언가가 사라질 예정이라면 언제인지, 무엇을 대신 쓰면 되는지 말하세요.

작동하는 첫 프롬프트

우리 사이트의 /changelog에 공개 변경 로그를 추가해 줘. 각 항목은 제목, 날짜, 태그(New, Improved 또는 Fixed), 선택적 대표 이미지, 본문이 있는 Markdown 파일이야. 목록 페이지에는 최신순으로 항목의 날짜, 태그, 첫 문단을 보여 주고, 태그 필터 버튼을 두고, 페이지당 10개 항목을 보여 줘. 각 항목은 /changelog/<slug>에 자체 페이지를 갖고, 검색엔진을 위한 적절한 페이지 제목과 설명이 있어야 해. /changelog/rss.xml에 RSS 피드를 추가해 줘. 샘플 항목 세 개를 만들어 줘. 기존 사이트 디자인과 맞추고, 휴대폰에서 읽기 편하게 하고, 빨리 로드되도록 페이지를 사전 렌더링해 줘.

데이터베이스 버전을 원한다면, 첫 문장을 "항목은 초안/게시됨 상태와 게시일이 있는 데이터베이스에 저장하고, 작성, 미리보기, 게시를 할 수 있는 비밀번호 보호 관리자 페이지를 추가해 줘."로 바꾸세요.

빌드 단계

1. 위 표를 보고 파일 또는 데이터베이스를 결정하세요.
2. 샘플 항목 몇 개와 함께 목록 페이지와 항목 페이지를 만드세요.
3. 태그와 필터를 추가하세요.
4. RSS 피드를 추가하고 페이지에서 링크하세요.
5. 각 항목에 페이지 제목, 설명, 사이트맵 항목을 추가하세요. 기본은 AI로 만든 웹사이트를 위한 SEO 가이드에서 다룹니다.
6. 데이터베이스 경로를 골랐다면 관리자 페이지와 로그인을 만드세요.
7. 앱에 "새로운 기능" 배지를 넣으세요.
8. 페이지가 빈 상태로 출시되지 않도록 지난 몇 달의 실제 항목을 작성하세요.

흔한 실수

• 커밋 메시지를 그대로 복사하기. 개발자가 아니라 사용자를 위해 쓰세요.
• 항목별 URL 없이 페이지 하나에 모두 넣기. 누구도 특정 변경으로 링크할 수 없고, 검색엔진은 여러 페이지 대신 한 페이지만 봅니다.
• 한 달 뒤 업데이트 중단. 1년 전에 마지막으로 갱신된 변경 로그는 버려진 제품처럼 보입니다. 지킬 수 있는 리듬을 정하세요.
• 브라우저에서만 항목 불러오기. 검색엔진과 링크 미리보기는 빈 페이지를 볼 수 있습니다. 사전 렌더링하거나 서버에서 렌더링하세요.
• 장애 소식과 섞기. 서비스 중단은 변경 로그가 아니라 상태 페이지에 두어야 합니다.

호스팅된 변경 로그 도구가 더 나은 경우

호스팅된 변경 로그 및 제품 업데이트 도구가 있으며, 일부는 피드백 보드나 앱 내 위젯과 함께 제공됩니다. 직접 만들지 않고 앱 내 팝업, 대상 지정, 분석 기능을 원하거나, 팀이 이미 그런 기능이 포함된 도구에 비용을 내고 있다면 가치가 있습니다. 블로그나 도움말 센터 소프트웨어에도 적합한 형식이 이미 있을 수 있습니다.

변경 로그를 자신의 도메인에, 자신의 디자인으로, 완전히 색인 가능하게 두고 싶다면 직접 만드는 것이 맞습니다. 날짜가 있는 단순한 게시물 목록이라면 작업량도 많지 않습니다.

Mythex로 만들기

Mythex에서는 기존 프로젝트에 변경 로그를 추가하거나 독립된 작은 사이트로 만들어 달라고 에이전트에게 요청할 수 있으며, 만드는 과정을 라이브 미리보기에서 볼 수 있습니다. 파일 기반 버전에는 데이터베이스가 필요 없습니다. 관리자 버전을 고르면, 항목을 저장해야 할 때 에이전트가 전용 Postgres 데이터베이스를 추가하고(또는 /database를 입력), 스크린샷은 프로젝트 파일 스토리지에 저장됩니다. 관리자 로그인은 직접 고른 인증 방식으로 추가합니다(로그인 추가 레시피).

새로 만든 Mythex 앱은 종종 클라이언트에서 렌더링되는 싱글 페이지 앱인데, SEO 레시피에 따르면 이런 방식은 검색에 약합니다. 항목이 검색에 잡히길 원한다면 정적이거나 사전 렌더링된 변경 로그 페이지를 요청하세요. 같은 레시피가 제목, 설명, 사이트맵을 다룹니다. 변경 로그가 내장된 시작점이 필요하다면 제품 지식 허브 템플릿을 보세요.

자주 묻는 질문