기능을 만든 뒤 다시 글로 설명해야 했던 이유
코딩은 AI에게 맡겼습니다 · 시즌 1 / 17
v1.3.0 기능을 만든 뒤 같은 날 한국어·영어 업데이트 글과 기능 스크린샷을 추가했습니다. 네 개 파일에서 223줄이 늘었습니다. 코드 커밋이 제품을 바꿨다면 콘텐츠 커밋은 사용자가 그 변화를 발견하게 했습니다.
먼저 보는 핵심
하나의 개발 기록은 릴리스 노트, 사용법, 개발 회고와 짧은 홍보 문구로 나눌 수 있습니다. 같은 내용을 복사하지 말고 독자마다 궁금한 질문을 바꾸는 것이 AI 콘텐츠 재가공의 핵심입니다.
같은 기능을 네 방식으로 설명하기
자동 정리와 휴지통이라는 한 가지 변경도 대상에 따라 강조점이 달라집니다.
| 콘텐츠 | 독자의 질문 | 중심 내용 |
|---|---|---|
| 릴리스 노트 | 무엇이 바뀌었나 | 새 기능과 호환성 |
| 사용자 가이드 | 어떻게 쓰나 | 설정, 복원, 주의점 |
| 개발 블로그 | 왜 이렇게 만들었나 | 판단과 실패 사례 |
| 스토어 설명 | 왜 설치해야 하나 | 결과와 신뢰 |
AI에게 “이 글을 네 번 바꿔 써줘”라고 하면 표현만 달라진 중복 글이 나오기 쉽습니다. 각 결과물의 독자 질문과 행동을 먼저 지정해야 합니다.
코드에서 콘텐츠 근거 뽑기
재가공할 자료는 기억보다 변경 기록에서 가져오는 편이 정확합니다.
- 커밋 메시지와 변경 파일
- 설정 화면의 실제 옵션
- 기본값과 보관 기간 상수
- 실패 처리와 제외 조건
- 전후 스크린샷
- 출시 후 발견한 수정 사항
AI에게 이 근거만 사용하고 확인되지 않은 성과 수치는 만들지 말라고 명시했습니다. “생산성이 몇 배 증가했다” 같은 문장은 실제 측정값이 없으면 쓰지 않는 편이 낫습니다.
한국어와 영어는 번역만 하지 않았다
언어가 달라지면 익숙한 용어와 설명의 길이도 달라집니다. 한국어 글은 개발 판단을 조금 더 풀어 쓰고, 영어 업데이트 글은 제품 사용 장면과 핵심 변경을 빠르게 보여주는 식으로 목적을 나눌 수 있습니다.
언어별 글을 만들 때도 다음 사실은 동일해야 합니다.
- 버전 번호
- 실제 제공 기능
- 기본 설정값
- 데이터 처리와 권한
- 지원 링크
표현은 달라도 제품 사실은 하나의 원본에서 가져와야 합니다.
다음 편
마지막 편에서는 스토어 설명 일곱 줄을 갱신한 커밋까지 포함해 7주와 18개 커밋을 결산합니다. AI가 정말 줄여 준 일과 끝까지 남은 일을 나눠 보겠습니다.
댓글
댓글 쓰기