프롬프트 라이브러리

정말로 구체적인 ChatGPT 바꿔 쓰기 프롬프트.

쓸 만한 바꿔 쓰기 프롬프트는 ChatGPT에게 무엇을 유지할지, 무엇을 바꿀지, 무엇이 잘못된 결과인지 알려 줍니다. 아래의 모든 프롬프트가 그 구조를 따릅니다 — 복사해서 대괄호를 채우고 붙여 넣으십시오.

어조별

어조 프롬프트.

  1. 자연스럽되 충실하게: “이 글을 자연스러운 문장으로 고쳐 써 주세요. 모든 사실 관계, 숫자, 단서 조항은 유지하세요. AI 특유의 상투적인 표현은 없애고, 새로운 예시는 추가하지 마세요. 텍스트: [붙여넣기]”
  2. 전문적이되 딱딱하지 않게: “이 글이 유능한 사람이 [독자]를 위해 쓴 것처럼 들리게 해 주세요. 과장, 상투어, 근거 없는 확신은 피하세요. 자연스럽게 들리는 구어체 표현은 그대로 두세요. 텍스트: [붙여넣기]”
  3. 더 따뜻하게, 늘리지는 말고: “이 글을 더 따뜻한 어조로 고쳐 쓰되, 길이는 늘리지 마세요. 요청 사항과 모든 사실은 그대로 유지하세요. 텍스트: [붙여넣기]”

길이별

길이 프롬프트.

  1. 더 짧게: “간결하게 고쳐 써 주세요. 핵심 의미는 유지하고, 서두의 군더더기는 없애고, 구체적인 세부 정보는 남기고, 결과는 [x]단어 이내로 해 주세요.”
  2. 과감하게 자르기: “이 글을 절반으로 줄여 주세요. 삭제한 내용을 목록으로 알려 주세요. 중요한 것이 있으면 되살릴 수 있게요. 텍스트: [붙여넣기]”
  3. 정직하게 늘리기: “군더더기가 아니라 구조로 이 글을 확장해 주세요. 빠져 있는 ‘누가, 언제, 다음에 무슨 일이 일어나는지’를 채우되, 제가 주는 사실만 사용하세요. 사실: [목록] 텍스트: [붙여넣기]”

독자별

독자 프롬프트.

  1. 비전문가 독자: “[분야]에 배경지식이 없는 똑똑한 독자를 위해 고쳐 써 주세요. 전문 용어는 쉬운 말로 바꾸고, 모든 주장은 정확하게 유지하고, 단순화 때문에 의미가 달라지는 부분이 있으면 표시해 주세요.”
  2. 경영진 요약: “30초밖에 없는 의사 결정권자를 위해 고쳐 써 주세요. 결론부터, 그다음 결론을 뒷받침하는 사실 두 가지, 마지막에 요청 사항. 그 외에는 아무것도 넣지 마세요.”
  3. 기존 고객: “이미 우리 제품을 쓰는 사람을 위해 고쳐 써 주세요. 서두의 홍보성 문구는 없애고, 변경 사항, 영향, 해야 할 행동만 남기세요.”

형식별

형식 프롬프트.

  1. 이메일: “이 글을 120단어 이내의 이메일로 바꿔 주세요. 요청 사항은 첫 두 문장 안에, 명확한 다음 단계 하나는 마지막에, ‘안녕하세요, 별일 없으시죠’ 같은 인사말은 빼 주세요.”
  2. 불릿을 문단으로: “이 불릿들을 연결된 두 문단으로 바꿔 주세요. 모든 항목을 유지하고, 논리적 연결을 더하되, 새로운 주장은 넣지 마세요. 불릿: [붙여넣기]”
  3. 문단을 불릿으로: “이 글을 독자가 15초 안에 훑어볼 수 있는 불릿으로 바꿔 주세요. 불릿 하나에 아이디어 하나, 숫자는 모두 유지, 장식적인 표현은 전부 삭제. 텍스트: [붙여넣기]”

여기 있는 모든 프롬프트는 보이지 않는 같은 문장으로 끝납니다. 모델이 주장을 바꿨다면 알아야 하기 때문입니다. 중요한 글이라면 어느 프롬프트에든 “고쳐 쓴 뒤, 의미에 영향을 줄 수 있는 변경 사항을 목록으로 알려 주세요.”를 덧붙이십시오.

해부

이 프롬프트들이 통하는 이유: 네 부분으로 이루어진 구조.

이 페이지의 효과적인 바꿔 쓰기 프롬프트는 모두 같은 네 부분으로 만들어졌고, 이 구조를 한번 파악하면 라이브러리를 뒤지는 것보다 직접 쓰는 편이 더 빠릅니다. 첫째는 작업 정의입니다. 무엇을 무엇으로 고치는가 — “개선해 주세요”가 아니라 “이 이메일을 더 짧은 이메일로”입니다. 둘째는 유지 목록입니다. 글자 그대로 살아남아야 하는 주장, 숫자, 이름, 단서 조항입니다. 셋째는 변경 목록입니다. 어조, 길이, 구조, 독자 — 모델이 움직여도 되는 축입니다. 넷째는 실패 정의입니다. 무엇이 잘못된 결과인지 명시적으로 적는 것입니다 — 지어낸 예시, 약해진 경고, 덧붙여진 호들갑 같은 것들입니다.

거의 모든 사람이 빼먹는 부분이 실패 정의인데, 사실 프롬프트에서 지렛대 효과가 가장 큰 문장입니다. 모델은 상냥하도록 훈련되어 있습니다. 실패 조건을 지정하지 않으면 모델은 “더 좋게 들리는 것”에 최적화하고, “더 좋게 들리는 것”은 단서 조항, 유보적 표현, 불리한 숫자에 조용히 반대표를 던집니다. “내가 제공하지 않은 사실을 추가하면 실패로 간주합니다”라는 한 문장이 돌아오는 결과를 눈에 띄게 바꿉니다.

내면화할 가치가 있는 따름정리 하나. 글이 짧을수록 프롬프트는 상대적으로 길어져도 됩니다. 40단어짜리 문장에 60단어짜리 프롬프트를 쓰는 것은 우스꽝스러워 보이지만, 그 문장이 캠페인의 제목이거나 자기소개서의 첫 줄이라면 전적으로 합리적입니다. 프롬프트에 들이는 공은 글의 길이가 아니라 글의 무게를 따라가야 합니다.

문제 해결

결과가 잘못됐다면 결과가 아니라 프롬프트를 고치십시오.

증상 → 원인 → 추가할 문장. 모델의 결과물을 손으로 고치는 것은 한 번이면 괜찮지만, 세 번이라면 프롬프트에 빠진 부분이 있다는 뜻입니다.

증상흔한 원인추가할 문장
결과가 여전히 밋밋함프롬프트에 독자가 없음.“독자는 [구체적인 상황에 있는 구체적인 사람/역할]입니다.”
사실이 뭉개져 사라짐유지 목록이 없음.“다음 항목은 바꾸지 말고 그대로 넣으세요: [목록].”
지어낸 예시가 등장함실패 정의가 없음.“제가 주지 않은 예시, 인용, 숫자는 추가하지 마세요.”
어조가 과함(너무 가볍거나 너무 딱딱함)어조를 형용사로 묘사함.“이 샘플의 어조에 맞춰 주세요: [직접 쓴 문장 2–3개 붙여넣기].”
길이 제한이 무시됨느슨한 제한(“짧게 해 주세요”).“최대 [n]단어. 단어 수를 세어 주세요.”
매번 같은 구조로 나옴모델이 자기 템플릿으로 회귀함.“요약 문장으로 시작하지 마세요. [요청 사항 / 숫자 / 장면]으로 시작하세요.”

고급

기본 프롬프트가 한계에 부딪혔을 때 쓰는 세 가지.

  1. 내 글에서 스타일 옮겨 오기: “제가 쓴 문단 세 개입니다: [붙여넣기]. 아래 텍스트를 같은 사람이 쓴 것처럼 고쳐 써 주세요. 제 문장 길이, 직설성, 어휘를 따라 하되 주제는 따라 하지 마세요. 모든 사실은 그대로 유지하세요. 텍스트: [붙여넣기]”. 이 방법은 형용사로 어조를 지시하는 어떤 방법보다 낫습니다. 어떤 묘사도 할 수 없는 방식으로 샘플이 문체의 격을 정의하기 때문입니다.
  2. 회의적인 독자 통과시키기: “회의적이고 바쁜 독자를 위해 고쳐 써 주세요. 이 독자는 근거 없는 주장에는 이의를 제기하고, 아무 내용 없는 문장이 나오는 순간 읽기를 멈춥니다. 그 기준에 맞춰 자르거나 근거를 보강하세요. 텍스트: [붙여넣기]”. 제안서와 경영진에게 올라가는 모든 글에 유용합니다.
  3. 의미 대조표 요청하기: “위 지시대로 고쳐 쓴 다음, 두 열짜리 표를 출력해 주세요. 의미가 달라진 모든 문장을 원문 대 수정본으로 놓고, 차이를 한 줄씩 설명해 주세요.” 모델 자신의 변경 추적을 나의 품질 검증 자료로 바꾸는 방법입니다 — 물론 직접 확인해야 하지만, 대부분의 의미 변형을 먼저 잡아 줍니다.

세 가지를 조합해 보십시오. 스타일 옮겨 오기로 문체의 격을 잡고, 회의적인 독자로 내용의 기준을 세우고, 의미 대조표로 안전망을 칩니다. 이 세 줄짜리 스택 자체가 하나의 완결된 고쳐 쓰기 시스템입니다.

FAQ

바꿔 쓰기 프롬프트에 관한 질문들.

좋은 바꿔 쓰기 프롬프트의 조건은 무엇입니까?

세 가지를 명시합니다. 바뀌면 안 되는 것(사실, 주장, 숫자), 바뀌어야 하는 것(어조, 길이, 구조), 그리고 실패의 기준(지어낸 예시, 약해진 단서 조항)입니다.

바꿔 쓰기 프롬프트를 써도 왜 계속 밋밋한 글이 나옵니까?

프롬프트가 독자가 아니라 스타일을 묘사하고 있기 때문입니다. “더 자연스럽게”는 모델에게 아무 의미가 없지만, “일정이 밀린 클라이언트에게 보내는 글”이라고 하면 문체의 격이 자동으로 달라집니다.

프롬프트를 나눠서 연결해야 합니까, 하나로 크게 써야 합니까?

짧은 글이라면 구체적인 프롬프트 하나로 충분합니다. 한 페이지가 넘는 글은 의미 확인과 어조 조정을 별도의 단계로 나누는 편이 낫습니다 — 3단계 워크플로를 참고하십시오.

이 프롬프트들은 Claude와 Gemini에서도 작동합니까?

네. 유지할 것 · 바꿀 것 · 실패 조건이라는 구조는 모델과 무관합니다. 결과물의 스타일은 다를 것이고, 바로 그렇기 때문에 모델 비교가 유용합니다.