Rewrite titles and subheadings
Generates title candidates and a subheading set that summarizes the piece when read alone.
| Category | Writing › Editing |
|---|---|
| Tags | IdeationRewritingCreator |
Rewrite the title and subheadings for this piece. Produce: 1. Six title candidates across different approaches — the claim, the question, the specific detail, the outcome, the contrarian angle, the plain description. Note what each promises. 2. A rewritten subheading for every section. *Write them as claims, not labels.* "Why the migration stalled", not "Background". 3. The subheading skeleton — all of them in order, read as a list. If that list does not summarize the piece, the structure has a problem, not the wording. Say which. 4. Sections whose subheading cannot be written as a claim, because the section has no point. Those need cutting or merging. Rules: - The title must be honest about what the piece delivers. - No colons used to bolt a vague phrase onto a specific one. - Match the venue's register, but do not sacrifice specificity to it. - *Do not invent a claim the section does not make* just to produce a stronger subheading.
What this prompt does
Good subheadings reveal the skeleton on their own. This converts labels into claims and then checks whether the subheadings alone still make sense in sequence.
Real outputs by model
Read full answers
We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.
Text: 제목: 우리 팀의 DB 마이그레이션 회고 배경 작년 11월, 우리는 레거시 MySQL 5.7에서 PostgreSQL 15로 핵심 결제 DB를 옮기기로 결정했다. 서비스 규모가 커지면서 정합성 이슈와 스케일링 한계가 반복적으로 발생했기 때문이다. 진행 과정 초기 계획은 2주였다. 스키마 변환 스크립트를 작성하고, 더블라이트 방식으로 두 DB에 동시 쓰기를 하면서 데이터를 검증했다. 하지만 실제로는 3주가 더 걸려 총 5주가 소요됐다. 문제 원인 가장 큰 문제는 타임존 처리였다. MySQL의 DATETIME은 타임존 정보를 갖지 않았는데, PostgreSQL의 TIMESTAMPTZ로 옮기면서 과거 데이터 중 약 12만 건의 시각이 9시간씩 어긋나 있다는 걸 뒤늦게 발견했다. 이걸 역산해서 보정하는 데만 일주일이 걸렸다. 결론 결국 마이그레이션은 예정보다 3주 늦은 12월 셋째 주에 완료됐다. 롤백 없이 끝냈다는 점은 다행이지만, 사전에 타임존 문제를 테스트 환경에서 잡아내지 못한 건 아쉬운 지점이다. Venue: 브런치스토리 (기술/스타트업 에세이 채널)
1. 제목 후보
주장 중심
핵심 결제 DB 마이그레이션이 2주 계획에서 5주 일정으로 늘어난 이유
→ 마이그레이션 지연의 핵심 원인을 설명하겠다고 약속한다.질문 중심
왜 DB 마이그레이션은 2주가 아니라 5주가 걸렸을까
→ 독자가 가장 궁금해할 일정 지연의 원인을 따라가게 한다.구체적 디테일 중심
타임존 하나 때문에 과거 데이터 12만 건이 9시간씩 어긋났다
→ 문제의 규모와 기술적 원인을 구체적으로 보여준다.결과 중심
롤백 없이 끝냈지만 DB 마이그레이션은 3주 늦어졌다
→ 성공과 실패가 공존한 결과를 균형 있게 전달한다.반전·반론 중심
DB 마이그레이션의 가장 어려운 문제는 스키마가 아니었다
→ 독자가 예상하기 쉬운 스키마 변환보다 타임존 처리가 핵심이었다는 점을 약속한다.평이한 설명 중심
MySQL 5.7에서 PostgreSQL 15로 결제 DB를 옮긴 기록
→ 마이그레이션의 배경, 과정, 문제, 결과를 담은 기술 에세이임을 정확히 알린다.
가장 적합한 제목은 왜 DB 마이그레이션은 2주가 아니라 5주가 걸렸을까입니다. 브런치스토리의 에세이형 기술 글에 맞으면서도, 글이 실제로 다루는 질문을 정확히 제시합니다.
2. 섹션별 rewritten subheading
- 서비스가 커지면서 레거시 MySQL의 정합성과 확장성 문제가 반복됐다
- 2주로 예상한 마이그레이션은 더블라이트 검증 과정에서 5주로 늘어났다
- 타임존 정보가 없던 과거 데이터 12만 건이 PostgreSQL 전환 과정에서 9시간씩 어긋났다
- 롤백 없이 이전을 완료했지만 테스트 환경에서 타임존 문제를 잡지 못했다
3. subheading skeleton
- 서비스가 커지면서 레거시 MySQL의 정합성과 확장성 문제가 반복됐다
- 2주로 예상한 마이그레이션은 더블라이트 검증 과정에서 5주로 늘어났다
- 타임존 정보가 없던 과거 데이터 12만 건이 PostgreSQL 전환 과정에서 9시간씩 어긋났다
- 롤백 없이 이전을 완료했지만 테스트 환경에서 타임존 문제를 잡지 못했다
이 목록만 읽어도 글의 핵심인 마이그레이션 결정의 배경, 일정 지연, 타임존 문제, 최종 평가가 요약됩니다. 현재 구조에는 큰 문제가 없습니다.
4. 주장으로 쓸 수 없는 섹션
없습니다. 네 섹션 모두 분명한 요점을 갖고 있어 삭제하거나 병합할 필요가 없습니다. 다만 마지막 섹션은 완료 결과와 회고를 함께 담고 있으므로, 글을 더 길게 확장한다면 결과와 교훈을 나누는 방식을 고려할 수 있습니다.
More in this category
| Academic Text Refinement Assistant | |
| AI Writing Tutor | |
| Alternative Text Generator | |
| Birthday Message Generator – 3 Styles | |
| Brotherhood Pressure — CN→EN & EN→EN Street Rewrite |