글 톤을 바꿔 다시 쓰는 프롬프트
같은 내용을 다른 말투로 옮깁니다. 격식을 올리거나 내리고, 읽는 사람이 바뀌었을 때 빼야 할 내용까지 짚어줍니다.
| 분류 | 창작 › 교정·첨삭 |
|---|---|
| 태그 | 재작성형식변환교정첨삭 |
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.
어떤 프롬프트인가
톤을 바꾼다면서 문장 끝만 손대는 경우가 대부분이다. 이 프롬프트는 새 독자가 모르는 것이 무엇인지까지 확인해서 설명을 넣고 빼고, 문장·문단 길이도 같이 조정한다.
모델별 실제 결과
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
목표톤: 비개발자 임원진도 편하게 읽을 수 있는 쉽고 친근한 설명체 새독자: 기술 배경이 없는 40대 스타트업 대표님 원문: 현재 프로덕션 클러스터는 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 같은 기술 용어는 설명을 덧붙였지만, 실제 운영 방식까지 이해하려면 추가 설명이 필요합니다.
- “맞춤형 지표”가 무엇을 의미하는지, 그리고 어떤 지표를 사용할지는 원문에 정보가 없어 알 수 없습니다.
- 최소 실행 단위 수를 늘리면 비용이 증가할 수 있다는 점은 원문에 없어 추가하지 않았습니다.
레지스터 전환으로 약해진 점
- “메트릭 서버의 스크레이핑 주기”와 “파드 부팅 시간”을 구체적으로 설명하지 않아, 지연이 발생하는 기술적 원인은 다소 덜 정밀해졌습니다.
- “예측 기반 스케일링”이라는 표현을 풀어 쓰면서, 검토 중인 기술 방향이 조금 더 일반적인 설명처럼 들립니다.
같은 분류의 프롬프트
| 학술 문장 다듬기 프롬프트 | |
| AI 글쓰기 튜터 프롬프트 | |
| 이미지 대체텍스트 생성 프롬프트 | |
| 3종 생일 메시지 프롬프트 | |
| 거리식 문체 재작성 프롬프트 |