예시

프롬프트 엔지니어링 예시 20가지, 개선 전후

2026년 9월 업데이트 · 읽는 데 약 12분

실망스러운 프롬프트와 잘 통하는 프롬프트의 차이는 보통 맥락 두 문장과 제약 하나예요. 사람들이 실제로 쓰는 버전과 유용한 답을 얻는 버전 20쌍을, 바꾼 점과 함께 소개해요.

예시 읽는 법

아래 각 쌍은 같은 요청을 두 번 보여 줘요. 실제로 입력하는 버전과 유용한 답을 얻는 버전이에요. 그 아래에는 바꾼 점을 한 줄로 적었어요. 목적은 프롬프트 20개를 모으는 것이 아니라, 같은 네다섯 가지 방법이 20번 적용되는 것을 보며 자연스럽게 익히는 거예요.

이 방법들은 프롬프트 엔지니어링 완벽 가이드에서 다뤄요. 역할, 추측할 수 없는 맥락, 구체적인 작업 하나, 실제 제약, 원하는 출력 형식을 주는 것이에요. 아래에서 찾아보세요.

이메일과 메시지

1. 회의 거절하기

개선 전

회의를 거절하는 이메일 써 줘

개선 후

관계를 유지하고 싶은 고객의 90분 워크숍 초대를 거절하는 짧은 답장을 써 줘. 바빠서가 아니라, 안건이 우리 팀이 영향을 줄 수 있는 내용이 아니기 때문이야. 대안은 하나만, 결정 담당자와 20분 통화를 제안해 줘. 따뜻하되 미안해하는 말투는 피하고, 80단어 미만, 느낌표 없이.

바꾼 점: 진짜 이유를 줬어요. ‘회의 거절’에는 정직한 이유가 여러 가지인데 모델이 다른 것을 골랐을 수 있어요. 이유를 말하면 대신 골라 주는 셈이에요.

2. 미납 청구서 독촉하기

개선 전

청구서 결제를 정중하게 다시 요청해 줘

개선 후

기한이 18일 지난 4,200유로 청구서에 대한 두 번째 독촉을 써 줘. 2년간 함께 일했고 관계를 유지하고 싶은 고객이야. 첫 알림에는 답이 없었어. 단호하되 비꼬지 말고, 아직 법적 조치나 상부 보고를 들먹이며 압박하지는 마. 답해야 하는 직접적인 질문 하나를 넣어 줘. 90단어 미만.

바꾼 점: 중요도와 경위예요. 첫 알림과 두 번째 알림은 다른 이메일이고, 부드럽기만 해도 되는 것은 첫 번째예요.

3. 동료에게 다시 해 달라고 요청하기

개선 전

작업을 다시 해야 한다고 말하는 걸 도와줘

개선 후

팀 디자이너에게 보낼 Slack 메시지를 써 줘. 받은 화면은 잘 만들었지만 기획서와 다른 문제를 해결하고 있어. 기획서를 모호하게 쓴 내 책임도 있어. 이번 주 안에 다시 만들어야 해. 기획서에 대한 책임을 인정하고, 무엇이 잘못됐는지 구체적으로 말하고, 부드럽게 하려다 모호해지지 않게 해 줘. 최대 네 문장.

바꾼 점: 메시지의 감정 구성이에요. ‘직접적으로’와 ‘친절하게’는 충돌할 수 있어서, 각각 어느 부분에 적용할지 정했어요.

4. 고객에게 지연 알리기

개선 전

지연 사과문 써 줘

개선 후

3월 출시를 예고한 기능이 5월로 늦어진다는 앱 내 메시지를 써 줘. 이유: 테스트에서 데이터 손실 버그를 찾았고, 해결하지 않은 채 출시하지 않기로 했어. 독자: 기다리고 있으며 공개적으로도 기대를 표현한 사용자들. 새 날짜를 먼저 말하고, 진짜 이유를 한 문장으로 설명해 줘. 기업식 모호한 표현이나 ‘기다려 주셔서 감사합니다’는 쓰지 마. 70단어 미만.

바꾼 점: 금지할 표현을 정했어요. 원치 않는 상투어를 명시하면 긍정적인 지시를 더하는 것보다 군더더기가 많이 줄어요.

글쓰기와 편집

5. 문단 줄이기

개선 전

이거 더 짧게 해 줘

개선 후

아래 문단을 절반 정도로 줄여 줘. 모든 사실과 숫자는 남겨. 부사, 모호한 표현, 앞 문장을 되풀이하는 문장은 빼 줘. 내 어휘를 더 격식 있는 말로 바꾸지 말고 축약 표현도 유지해 줘. 줄인 버전만 보여 줘.

바꾼 점: ‘짧게’에 목표, 지워도 되는 것, 남겨야 하는 것을 더했어요. 제약이 없으면 모델은 내 말투를 평평하게 만들어 분량을 줄여요.

6. 사람다운 자기소개 쓰기

개선 전

linkedin 소개 써 줘 백엔드 개발자야

개선 후

내 LinkedIn 소개를 써 줘. 백엔드 개발 경력 6년, 주로 Go와 Postgres를 쓰고 현재 중견 핀테크 회사의 결제 인프라를 맡고 있어. 내가 정말 잘하는 것은 느린 시스템을 빠르고 별 탈 없이 돌아가게 만드는 거야. 독자는 리크루터가 아니라 채용할 팀의 관리자야. 1인칭, 짧은 세 문단, ‘열정적인’과 ‘성과 지향적인’은 쓰지 말고 형용사 목록 대신 구체적인 예 하나를 넣어 줘.

바꾼 점: 구체적이고 조금 독특한 정보 하나예요. ‘느린 시스템을 빠르고 별 탈 없이’는 평범한 소개에서 나오기 어렵고, 좋은 소개의 중심이 되는 표현이에요.

7. 메모를 읽기 좋은 글로 바꾸기

개선 전

이 회의 메모 정리해 줘

개선 후

아래는 고객 통화 중 적은 원본 메모야. 참석하지 않은 동료를 위한 요약으로 바꿔 줘. 구성: 고객이 원하는 것, 현재 대신 하는 일, 전환하려면 충족돼야 할 조건, 미해결 질문. 메모에 없는 내용은 더하지 마. 불분명하면 추측하지 말고 미해결 질문에 넣어 줘.

바꾼 점: 지어내지 말라는 조건이에요. 요약은 빈틈을 그럴듯하게 채우면서 실패하기 쉬워요. 불확실한 내용을 둘 자리를 주면 막을 수 있어요.

조사와 학습

8. 적절한 수준으로 설명하기

개선 전

kubernetes 설명해 줘

개선 후

Docker Compose로 서비스를 출시한 경험은 있지만 오케스트레이터는 써 본 적 없는 백엔드 개발자에게 Kubernetes가 실제로 하는 일을 설명해 줘. 구조보다 해결하는 문제부터 시작해. 전체에 걸쳐 같은 예 하나를 써 줘. 서비스가 50개 이상일 때만 필요한 내용은 빼 줘. 400단어 미만.

바꾼 점: 독자를 이미 아는 지식으로 정의했어요. ‘X를 설명해 줘’에는 누가 묻는지 알기 전까지 정답이 없어요.

9. 두 선택지 비교하기

개선 전

postgres랑 mongodb 뭐가 더 좋아

개선 후

예약 제품을 만들고 있어. 관계형 읽기가 많고 강한 일관성이 필요해. 팀은 두 명이고 SQL 경험은 있지만 NoSQL 경험은 없어. 이 상황에 맞춰 Postgres와 MongoDB를 데이터 모델 적합성, 일관성, 두 명의 운영 부담, 채용 관점에서 표로 비교해 줘. 이어서 두 문장으로 하나를 추천하고, 그 선택에 반대하는 가장 강한 이유를 말해 줘.

바꾼 점: ‘뭐가 더 좋아’가 ‘이 상황에는 뭐가 더 좋아’로 바뀌었어요. 반론을 요청하면 비교가 결론을 정당화하는 글로 흐르는 것을 막아요.

10. 실천할 수 있는 학습 계획 받기

개선 전

스페인어 공부 도와줘

개선 후

12주 스페인어 계획을 만들어 줘. 현재 메뉴는 읽고 느린 말은 이해하지만, 말하려면 얼어 버려. 평일 30분, 일요일 1시간을 쓸 수 있어. 목표는 크리스마스에 파트너 가족과 영어로 바꾸지 않고 10분 대화하는 거야. 말하기에 비중을 많이 둬 줘. 1주차는 자세히, 나머지 11주는 각각 한 줄로 알려 줘.

바꾼 점: 날짜가 있는 목표와 약점을 명시했어요. 마지막 지시는 2주차 이후로 아무도 읽지 않는 12주짜리 장문도 막아요.

계획과 결정

11. 실제 결정 따져 보기

개선 전

이직 제안 받아야 할까

개선 후

이직 제안을 검토하도록 도와줘. 현재: 시니어 개발자, 안정적, 지루함, 좋은 팀. 제안: 30명 스타트업의 스태프 역할, 급여 15% 인상, 18개월 운영 자금, 면접에서 마음에 들었던 상사. 주택담보대출이 있고 다른 부양가족은 없어. 결정 전에 알아야 하지만 아직 묻지 않았을 법한 것을 나열한 뒤, 각 선택을 지지하는 가장 강한 이유 두 개씩을 줘. 추천하지 마. 답이 아니라 질문을 원해.

바꾼 점: 모델이 할 일을 정했어요. 추천을 거절하는 것이 조언을 유용한 판단 재료로 바꿔요.

12. 어려운 대화 준비하기

개선 전

연봉 인상을 어떻게 요청해

개선 후

연봉 인상 대화를 준비해 줘. 두 개의 급여 조사에 따르면 내 급여는 같은 직무의 시장 수준보다 20% 낮아. 입사 3년 차이고, 인프라 비용을 3분의 1 줄인 이전 작업을 이끌었어. 상사는 지지하지만 예산 권한은 없어. 첫마디, 가장 예상되는 반론 두 개와 각각의 답변, 그리고 하지 말아야 할 한 문장을 줘.

바꾼 점: 구체적인 협상 근거와 장애물이에요. 마지막 요청이 혼자서는 쓰기 어려운 내용을 만들어 줘요.

13. 목표를 일주일 행동으로 바꾸기

개선 전

더 생산적이게 도와줘

개선 후

아직 사용자가 없는 개인 프로젝트를 출시하고 싶어. 평일 저녁을 합쳐 주 8시간쯤 쓸 수 있어. 내 실패 패턴은 사람들과 이야기하는 대신 랜딩 페이지를 다시 만드는 거야. 피하고 있는 일에 비중을 두어, 일주일 동안 할 구체적인 작업과 시간을 정해 줘. 회피를 막을 규칙 하나도 줘.

바꾼 점: 실패 패턴을 명시했어요. 일반적인 생산성 조언은 쓸모없지만, 내가 어떻게 실패하는지 알면 구체적이 돼요.

코드

14. 디버깅

개선 전

내 코드가 왜 느려

개선 후

이 엔드포인트는 약 2,000행 목록에서 4초, 50행에서는 100ms 미만이 걸려. Postgres와 Go를 쓰고 캐시 계층은 없어. user_id 인덱스가 쓰이는 것은 이미 확인했어. 이 규모별 성능 차이를 바탕으로 가능한 원인 세 개를 가능성 순으로 주고, 각각 확인하거나 배제하려면 정확히 무엇을 측정할지 알려 줘. 아직 코드를 다시 쓰지는 마.

바꾼 점: 문제가 나타나는 형태와 이미 배제한 내용을 줬어요. ‘아직 다시 쓰지 마’가 추측으로 수정하는 대신 진단하게 해요.

15. 실제로 도움이 되는 코드 리뷰 받기

개선 전

내 코드 리뷰해 줘

개선 후

아래 함수를 신뢰하는 동료의 풀 리퀘스트처럼 리뷰해 줘. 우선순위는 동시 호출 시 정확성, 오류 처리, 가독성 순이야. 스타일과 이름은 무시해. 문제마다 줄, 무엇이 깨지는지, 그 문제를 일으키는 구체적인 입력을 줘. 실제 문제가 없다면 억지로 찾지 말고 없다고 말해 줘.

바꾼 점: 우선순위와 문제가 없어도 된다는 허용이에요. 마지막 조건이 없으면 리뷰 프롬프트는 진짜든 아니든 늘 지적을 내놓아요.

16. 가치 있는 테스트 쓰기

개선 전

이 함수 단위 테스트 써 줘

개선 후

아래 함수의 테이블 기반 테스트를 써 줘. 빈 입력, 요소 하나, 중복 키, 길이 제한 경계값을 다뤄. 평범한 항목 세 개의 정상 경로는 빼 줘. 그 테스트는 거의 문제를 잡지 못해. 표준 라이브러리만 쓰고, 각 사례는 입력이 아니라 보장하는 동작을 기준으로 이름 지어 줘.

바꾼 점: 코드를 아는 사람이 사례를 골랐어요. 테스트 작성 프롬프트는 기본적으로 실패하지 않는 사례를 고르는 경향이 있어요.

이미지와 음악

17. 의도가 보이는 인물 사진

개선 전

여성 인물 사진

개선 후

새벽 첫빛의 항구 방파제에 선 풍파를 겪은 60대 여성 어부, 소금이 밴 방수 작업복, 깊은 웃음 주름, 카메라 너머를 보는 시선, 흐린 북대서양의 빛, 얕은 피사계 심도, 85mm 인물 사진, 차분한 파랑과 녹슨 붉은빛 --ar 4:5 --stylize 250

바꾼 점: 피사체, 배경, 빛, 구도, 매체를 그 순서로 정했어요. 이미지 모델은 앞쪽 단어를 더 중요하게 보므로 순서도 프롬프트의 일부예요.

18. 제품 사진

개선 전

우리 가게 커피 봉투 사진

개선 후

옅은 오크 목재 위에 세운 무광 크라프트 커피 봉투, 앞면 라벨은 카메라를 향함, 흩어진 원두, 왼쪽 창에서 들어오는 부드러운 빛, 부드러운 그림자 하나, 깔끔하고 미니멀한 연출, 얕은 피사계 심도, 상업용 제품 사진 --ar 1:1 --style raw

바꾼 점: 조명과 바닥면이에요. 제품 프롬프트에서는 이 둘이 거의 모든 것을 결정하지만, ‘커피 봉투 사진’에는 어느 것도 담겨 있지 않아요.

19. 글자가 들어가야 하는 이미지

개선 전

grand opening이라고 쓰인 포스터

개선 후

빈티지 활판 인쇄 포스터, 위쪽 3분의 1에 크고 폭이 좁은 세리프 대문자로 ‘GRAND OPENING’, 그 아래 작은 산세리프체로 ‘Saturday 14th’, 질감이 보이는 크림색 종이, 짙은 빨강과 검정의 2색 인쇄, 미세한 잉크 어긋남 --ar 2:3

바꾼 점: 정확한 문구를 인용하고 위치를 정했어요. 글자를 표현할 수 있는 모델에는 문구, 크기, 위치를 알려줘야 해요. 아니면 세 가지를 모두 임의로 정해요.

20. 머릿속 음악과 닮은 곡

개선 전

슬픈 피아노 곡

개선 후

스타일: 우울한 네오클래식 피아노, 가까이 마이킹한 펠트 피아노, 희미한 실내 소음, 드문드문 받쳐 주는 첼로, 드럼 없음, 루바토, 62 BPM, 친밀하고 해결되지 않는 여운. 구조 태그가 있는 가사: [Intro] [Verse] [Chorus] [Bridge] [Outro]

바꾼 점: 악기 편성, 녹음의 질감, 템포예요. ‘슬픈 피아노’는 기분이고, 나머지가 평범한 곡이 아닌 특정 녹음으로 만들어요.

20개 예시의 공통점

개선 후 버전만 읽으면 같은 몇 가지 방법이 반복해서 나타나요.

어느 것도 작성 틀을 외울 필요는 없어요. 보내기 전에 작업만 설명하고 상황을 빼놓지 않았는지 알아차리면 돼요.

20개 예시 대신 키 하나

Prompt AI Keyboard는 이미 쓴 글에, 사용할 도구에 맞는 역할, 맥락, 제약, 형식을 더해요. 입력 중인 앱을 떠날 필요가 없어요. 문법 수정, 어조 변경, 번역, 말한 내용의 음성 입력도 해요.

자주 묻는 질문

좋은 프롬프트 예시란 무엇인가요?

같은 요청을 두 번 보여 주고 무엇이 달라졌는지 알려주는 예시예요. 프롬프트만 있으면 응용하지 못하는 틀에 그치지만, 개선 전후를 보면 내 작업에도 적용할 방법을 배울 수 있어요.

좋은 프롬프트의 공통점은 무엇인가요?

나만 아는 구체적인 정보 하나, 명시된 독자, 적어도 하나의 금지사항, 지어내느니 답하지 않아도 된다는 허용, 정해진 출력 형태예요. 약한 프롬프트는 대개 작업만 설명하고 상황을 빼놓아요.

이 예시를 ChatGPT, Claude, Gemini에서 모두 쓸 수 있나요?

네. 다섯 요소가 모델을 가리지 않으므로 여기의 예시는 모두 공통으로 쓸 수 있어요. 그 위에 모델별 차이를 더하면 돼요. Claude는 더 자세한 구조, Gemini는 아주 긴 입력과 명확한 출력 형식에 잘 반응해요. 이미지와 음악 모델은 문장보다 밀도 높은 묘사 구절을 원해요.