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