Rewrite a text for a different reader
Adjusts vocabulary, sentence length, and what needs explaining — not just the tone of the endings.
| Category | Writing › Editing |
|---|---|
| Tags | RewritingReformattingProofreading |
Rewrite this text in a different register. Do: 1. ***Do not just change the phrasing — check what the new reader will not know.*** Add explanation where needed, cut what they do not need, **and mark both.** 2. Match vocabulary to the reader. Where a technical term stays, gloss it. 3. **Adjust sentence and paragraph length too.** *Register is not only a matter of endings.* 4. Keep the claims and their order. Then: - What the new reader still will not follow. - Where the shift in register weakened a point, if anywhere.
What this prompt does
Changing register is usually done at the sentence ending and nowhere else. This also checks what the new reader does not know.
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.
Direction: 비개발자 임원진도 편하게 읽을 수 있는 쉽고 친근한 설명체 New reader: 기술 배경이 없는 40대 스타트업 대표님 Source text: 현재 프로덕션 클러스터는 HPA(Horizontal Pod Autoscaler)를 CPU 사용률 70% 기준으로 트리거하도록 설정되어 있습니다. 그런데 트래픽 스파이크가 순간적으로 발생하는 경우, 메트릭 서버의 스크레이핑 주기(15초)와 파드 부팅 시간(약 40초) 때문에 실제 오토스케일링이 반영되기까지 1분 이상의 지연이 생깁니다. 이 지연 구간 동안 기존 파드들이 요청을 처리하지 못해 5xx 에러율이 순간적으로 3%까지 치솟는 현상이 지난주 목요일 저녁 프로모션 이벤트 때 관측됐습니다. 이를 해결하기 위해 예측 기반 스케일링(KEDA + 커스텀 메트릭)을 도입하거나, 최소 replica 수를 상향 조정하는 방안을 검토 중입니다.
수정문
표시: [추가] 새 독자에게 필요한 설명, [삭제] 이해에 꼭 필요하지 않아 덜어낸 내용
현재 실제 서비스 운영 환경에서는 HPA(사용량이 늘면 애플리케이션 실행 단위를 자동으로 늘리는 기능)가 CPU 사용률 70%를 기준으로 작동하도록 설정되어 있습니다.
하지만 갑자기 트래픽이 몰리면 자동 확장이 즉시 반영되지 않습니다. 서버 상태를 확인하는 주기가 15초이고, 새 실행 단위(파드)가 실제로 준비되는 데 약 40초가 걸리기 때문입니다. [추가: 즉, 트래픽 증가를 감지하고 새 서버가 요청을 처리하기까지 최소 1분 이상이 필요합니다.]
그 결과 지난주 목요일 저녁 프로모션 이벤트에서는 기존 실행 단위만으로 요청을 감당하지 못했고, 잠시 동안 서버 오류(5xx) 비율이 최대 3%까지 올랐습니다. [삭제: 메트릭 서버의 스크레이핑 주기] [삭제: 파드 부팅 시간이라는 기술적 표현]
이 문제를 줄이기 위해 현재 두 가지 방안을 검토하고 있습니다. 첫째, CPU 사용률이 높아진 뒤 대응하는 대신 다른 지표를 활용해 더 빠르게 확장하는 방식(KEDA와 맞춤형 지표)을 도입하는 것입니다. 둘째, 평소에도 준비해 두는 최소 실행 단위 수(replica 수)를 늘려 갑작스러운 트래픽 증가에 대비하는 것입니다.
새 독자가 여전히 따라가기 어려울 수 있는 부분
- HPA, KEDA, 파드, replica 같은 기술 용어는 설명을 덧붙였지만, 실제 운영 방식까지 이해하려면 추가 설명이 필요합니다.
- “맞춤형 지표”가 무엇을 의미하는지, 그리고 어떤 지표를 사용할지는 원문에 정보가 없어 알 수 없습니다.
- 최소 실행 단위 수를 늘리면 비용이 증가할 수 있다는 점은 원문에 없어 추가하지 않았습니다.
레지스터 전환으로 약해진 점
- “메트릭 서버의 스크레이핑 주기”와 “파드 부팅 시간”을 구체적으로 설명하지 않아, 지연이 발생하는 기술적 원인은 다소 덜 정밀해졌습니다.
- “예측 기반 스케일링”이라는 표현을 풀어 쓰면서, 검토 중인 기술 방향이 조금 더 일반적인 설명처럼 들립니다.
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 |