프롬프트가 막막할 때는 기법의 원리를 익히기보다 비슷한 과제의 예시 프롬프트를 가져다 내 상황에 맞게 고쳐 쓰는 편이 빠릅니다. 이 글은 요약·번역·분류·이메일 답장 등 실무에서 자주 반복되는 과제 10가지의 예시 프롬프트를 모았습니다. 각 예제는 대괄호로 표시한 부분만 실제 내용으로 바꾸면 대부분의 대화형 AI에서 그대로 쓸 수 있습니다.
원리보다 예시가 빠를 때는 언제인가?
프롬프트를 어떻게 써야 할지 막막할 때는 기법의 원리를 하나씩 익히는 것보다, 비슷한 과제의 예시 프롬프트를 가져다 내 상황에 맞게 고쳐 쓰는 편이 더 빠릅니다. 이 글은 요약, 번역, 분류, 이메일 답장처럼 실무에서 자주 반복되는 과제 10가지를 골라, 그대로 복사해 변수만 바꿔 쓸 수 있는 예시 프롬프트를 모았습니다.
프롬프트 엔지니어링의 기법 자체(역할 지정, 퓨샷, 단계 분해, 출력 형식 고정 등)를 원리부터 이해하고 싶다면 프롬프트 엔지니어링 하는 법 가이드를, 용어 정의는 프롬프트 엔지니어링 페이지를 참고하세요. 이 글은 원리 설명 대신 "일단 써먹는" 것에 집중합니다.
각 예제는 대괄호([ ])로 표시한 부분만 실제 내용으로 바꿔 쓰면 됩니다. 특정 모델에서만 되는 예제는 없으며, 대부분의 대화형 AI 서비스에서 그대로 시도해 볼 수 있습니다.
예제 1: 긴 글 요약
언제 쓰나: 기사, 보고서, 리뷰처럼 긴 텍스트를 짧게 압축하고 싶을 때 씁니다.
아래 글을 3문장으로 요약해줘. 글에 없는 내용은 추가하지 말고, 원문에 실제로 있는 내용만 사용해줘.
[요약할 글 붙여넣기]
팁: "몇 문장으로"처럼 분량을 숫자로 못 박아야 결과가 들쭉날쭉하지 않습니다. 더 구조화된 요약이 필요하면 긴 문서 요약 프롬프트를 참고하세요.
예제 2: 번역 (톤과 대상 독자 지정)
언제 쓰나: 단순 직역이 아니라 대상 독자와 상황에 맞는 번역이 필요할 때 씁니다.
아래 문장을 한국어로 번역해줘. 대상 독자는 [예: 비전문가 고객]이고, 톤은 [예: 격식 있는 존댓말]로 맞춰줘. 직역보다는 자연스러운 표현을 우선해줘.
[번역할 문장 붙여넣기]
팁: 대상 독자와 톤을 지정하지 않으면 모델이 임의로 격식 수준을 정하므로, 이 두 가지는 항상 명시하는 편이 안전합니다.
예제 3: 분류·태깅
언제 쓰나: 고객 문의, 리뷰, 이슈 등 여러 건의 텍스트를 정해진 기준으로 분류할 때 씁니다.
아래 텍스트를 다음 카테고리 중 하나로 분류해줘: [카테고리1, 카테고리2, 카테고리3].
분류 결과와 함께 그렇게 판단한 이유를 한 문장으로 설명해줘. 카테고리 중 애매하면 가장 가까운 것을 고르고 "애매함"이라고 표시해줘.
[분류할 텍스트 붙여넣기]
팁: 카테고리 목록을 미리 확정해서 프롬프트에 넣어야 결과가 일관됩니다. 카테고리를 모델이 알아서 정하게 하면 매번 다른 기준이 나올 수 있습니다.
예제 4: 텍스트에서 표 추출
언제 쓰나: 줄글로 된 자료에서 이름, 날짜, 금액 같은 항목을 뽑아 표로 정리하고 싶을 때 씁니다.
아래 텍스트에서 [항목1, 항목2, 항목3]을 찾아 표(마크다운 표)로 정리해줘.
텍스트에 없는 항목은 빈 칸으로 두고 지어내지 마. 같은 항목이 여러 번 나오면 각각 한 행으로 정리해줘.
[텍스트 붙여넣기]
팁: "지어내지 마"라는 제약을 꼭 넣어야 없는 정보를 그럴듯하게 채워 넣는 것을 줄일 수 있습니다.
예제 5: 이메일 답장 초안
언제 쓰나: 받은 이메일에 빠르게 답장 초안을 만들고 싶을 때 씁니다.
아래는 내가 받은 이메일이야. 이 내용에 답장하는 이메일 초안을 써줘.
답장의 핵심 내용은 [전달하고 싶은 요점]이고, 톤은 [예: 정중하지만 간결하게]로 맞춰줘.
[받은 이메일 붙여넣기]
팁: 핵심 내용을 프롬프트에 직접 적어주지 않으면 모델이 임의로 답변 방향을 지어낼 수 있습니다. 반복적으로 이메일을 쓴다면 이메일·보고서 작성 프롬프트 템플릿처럼 변수만 바꾸는 템플릿을 만들어 두는 편이 낫습니다.
예제 6: 코드 설명
언제 쓰나: 남이 짠 코드나 오래전에 작성한 코드를 다시 파악해야 할 때 씁니다.
아래 코드가 무슨 일을 하는지 한 줄 요약을 먼저 알려주고, 이어서 주요 로직을 함수·블록 단위로 설명해줘.
코드에 버그로 의심되는 부분이 있으면 별도로 짚어줘.
[코드 붙여넣기]
팁: "한 줄 요약 먼저"를 요청하면 전체 코드를 다 읽지 않아도 핵심을 빠르게 파악할 수 있습니다.
예제 7: 아이디어 브레인스토밍
언제 쓰나: 기획 초기 단계에서 여러 방향의 아이디어를 넓게 뽑아보고 싶을 때 씁니다.
[주제]에 대한 아이디어를 [개수]개 제안해줘. 각 아이디어는 한 줄 설명과 함께, 장점과 우려되는 점을 하나씩 붙여줘.
비슷한 아이디어끼리 겹치지 않게 서로 다른 각도에서 제안해줘.
팁: 개수를 지정하지 않으면 모델이 아이디어를 너무 적게 내놓는 경우가 많으므로, 원하는 개수를 명시하는 편이 좋습니다.
예제 8: 문체·어조 교정
언제 쓰나: 초안은 다 썼지만 톤이 상황에 안 맞거나 문장이 어색할 때 다듬는 용도로 씁니다.
아래 글의 내용과 의미는 그대로 유지하면서, 톤을 [예: 더 격식 있게 / 더 친근하게]로 바꿔줘.
문장이 어색하거나 반복되는 부분은 자연스럽게 다듬되, 원문에 없는 내용을 추가하지는 마.
[원문 붙여넣기]
팁: "내용은 그대로 유지"를 명시하지 않으면 톤을 바꾸는 과정에서 원래 의미가 슬쩍 달라지는 경우가 있으니 꼭 넣어야 합니다.
예제 9: 단계별 계획 세우기
언제 쓰나: 목표는 있지만 실행 순서가 정리되지 않은 일을 계획으로 만들고 싶을 때 씁니다.
목표: [달성하려는 목표]
제약 조건: [기간, 예산, 인력 등 있으면 적기]
이 목표를 달성하기 위한 단계별 계획을 세워줘. 각 단계마다 할 일, 예상 소요 시간, 이 단계가 필요한 이유를 함께 적어줘.
팁: 제약 조건(기간, 인력 등)을 비워두면 비현실적인 계획이 나올 수 있으니, 아는 범위까지는 채워서 넣는 편이 좋습니다.
예제 10: 역할 지정 롤플레이
언제 쓰나: 특정 관점에서 피드백을 받거나, 인터뷰·면접처럼 대화형으로 연습하고 싶을 때 씁니다.
너는 [역할, 예: 까다로운 면접관 / 신입 개발자를 코칭하는 시니어 개발자]다.
이 역할에 맞는 말투와 관점을 유지하면서 나와 대화해줘. 내가 먼저 이야기를 시작할 테니, 역할에서 벗어나지 말고 응답해줘.
[대화 시작 문장]
팁: 역할만 지정하고 "어떤 상황인지"를 안 알려주면 대화가 겉돌 수 있습니다. 역할과 함께 상황(면접 종류, 코칭 주제 등)도 짧게 덧붙이세요.
예제를 내 상황에 맞게 어떻게 바꾸나?
위 예제들은 그대로 써도 되지만, 결과가 원하는 것과 다르다면 다음 순서로 손보길 권합니다. 먼저 대괄호 안 내용을 더 구체적으로 채우고, 그래도 부족하면 "이런 형식으로 답해줘" 같은 출력 형식 지정을 추가합니다. 그 다음에도 결과가 애매하면 사고의 연쇄처럼 단계별 추론을 유도하는 지시문을 덧붙여 보세요.
반대로 별도 예시 없이 지시문만으로 충분한 단순한 작업이라면 제로샷 러닝 방식 그대로도 괜찮습니다. 작업이 복잡해질수록 예시나 단계 분해를 추가하는 식으로 프롬프트를 점진적으로 키워가는 것이 한 번에 완벽한 프롬프트를 쓰려는 것보다 효율적입니다.
자주 묻는 질문
- Q. 예제를 그대로 복사해 써도 되나?
- A. 대괄호로 표시한 부분만 실제 내용으로 바꾸면 대부분의 대화형 AI 서비스에서 그대로 시도할 수 있습니다. 특정 모델에서만 되는 예제는 없습니다.
- Q. 예제를 써도 결과가 원하는 것과 다르면?
- A. 먼저 대괄호 안 내용을 더 구체적으로 채우고, 그래도 부족하면 "이런 형식으로 답해줘" 같은 출력 형식 지정을 추가합니다. 그다음에도 애매하면 사고의 연쇄처럼 단계별 추론을 유도하는 지시문을 덧붙입니다.
- Q. 예시 없이 지시문만으로도 충분한 경우가 있나?
- A. 있습니다. 단순한 작업은 제로샷 러닝 방식 그대로도 괜찮고, 작업이 복잡해질수록 예시나 단계 분해를 점진적으로 추가하는 편이 효율적입니다.