📕 이 사이트를 굴린 428커밋의 기록이 상품이 됐습니다 — 전자책·스타터 키트 보기 →
agenwiki

입문

프롬프트 엔지니어링 하는 법: 실전 기법 정리

역할 지정, 예시 제공, 단계 분해, 출력 형식 고정 등 프롬프트 엔지니어링 실전 기법을 나쁜 예·좋은 예와 함께 정리합니다.

프롬프트 엔지니어링은 언어 모델의 가중치를 바꾸지 않고, 입력하는 지시문을 다듬어 원하는 결과를 얻는 작업입니다. 역할·맥락 지정, 예시 제공(퓨샷), 복잡한 작업의 단계 분해, 출력 형식 고정이라는 네 가지 기법만 익혀도 대부분의 반복 작업에서 결과가 눈에 띄게 좋아집니다.

프롬프트 엔지니어링, 어렵게 생각할 필요 없나?

프롬프트 엔지니어링은 언어 모델의 가중치를 바꾸지 않고, 입력하는 지시문을 다듬어 원하는 결과를 얻는 작업입니다. 자세한 정의는 프롬프트 엔지니어링 용어 페이지에서 확인할 수 있습니다. 이 글에서는 정의보다 실무에서 바로 쓸 수 있는 구체적인 기법과 예시에 집중합니다.

같은 모델이라도 프롬프트를 어떻게 쓰느냐에 따라 답변의 정확도와 형식이 크게 달라집니다. 아래 네 가지 기법만 익혀도 대부분의 반복 작업에서 결과가 눈에 띄게 좋아집니다.

기법 1: 역할과 맥락을 어떻게 지정하나?

모델에게 "누구로서 답할지"와 "어떤 상황인지"를 먼저 알려주면 답변의 톤과 깊이가 목적에 맞게 좁혀집니다. 역할이 없으면 모델은 가장 무난하고 일반적인 답을 고르는 경향이 있습니다.

  • 나쁜 예: "이 코드 리뷰해줘."
  • 좋은 예: "너는 5년 차 백엔드 개발자다. 아래 Python 함수를 코드 리뷰 관점에서 검토하고, 버그·성능·가독성 순으로 문제를 지적해줘."

역할 지정은 특히 코드 리뷰, 카피라이팅, 법률·의료처럼 전문성이 필요한 작업에서 효과가 큽니다.

기법 2: 예시로 원하는 형태를 어떻게 보여주나? (few-shot)

설명으로 원하는 결과를 전달하기 어려울 때는 예시 한두 개를 직접 보여주는 편이 훨씬 정확합니다. 이를 퓨샷(few-shot) 프롬프팅이라 부릅니다.

  • 나쁜 예: "고객 후기를 요약해줘."
  • 좋은 예: "고객 후기를 아래 형식으로 요약해줘.\n예시 입력: '배송이 빠르고 포장도 좋았어요. 다만 색상이 사진과 달랐어요.'\n예시 출력: 장점: 빠른 배송, 좋은 포장 / 단점: 실제 색상과 사진의 차이"

예시는 많을수록 좋은 것이 아니라, 원하는 패턴을 명확히 드러내는 1~3개면 충분한 경우가 많습니다.

기법 3: 복잡한 작업은 어떻게 쪼개나?

한 번에 모든 것을 요구하면 모델이 중간 단계를 건너뛰고 결론만 내놓는 경우가 많습니다. 작업을 순서대로 지시하면 각 단계의 결과를 확인하고 수정할 수 있어 오류를 줄일 수 있습니다.

  • 나쁜 예: "이 데이터로 보고서 써줘."
  • 좋은 예: "1) 아래 데이터에서 핵심 수치 3개를 뽑아줘. 2) 그 수치를 바탕으로 한 문단짜리 요약을 써줘. 3) 요약을 바탕으로 다음 액션 아이템 2개를 제안해줘."

복잡한 리서치나 코딩 작업에서는 단계별 지시와 함께, 이전 단계 결과를 다음 프롬프트에 그대로 붙여 넣는 것도 도움이 됩니다.

기법 4: 출력 형식은 어떻게 고정하나?

답변을 다른 시스템에 연결하거나 반복적으로 같은 형태가 필요하다면, 원하는 출력 형식을 프롬프트에 명시해야 합니다. JSON, 표, 글머리 기호처럼 구조가 정해진 형식을 요청하면 파싱과 재사용이 쉬워집니다.

  • 나쁜 예: "이 문장에서 이름과 날짜 찾아줘."
  • 좋은 예: "이 문장에서 이름과 날짜를 찾아 다음 JSON 형식으로만 답해줘. 다른 설명은 붙이지 마. {\"name\": string, \"date\": string}"

형식을 고정할 때는 "다른 설명 없이", "코드 블록 없이" 같은 제약 조건도 함께 적어야 모델이 불필요한 문장을 덧붙이지 않습니다.

자주 하는 실수는 무엇인가?

  • 모호한 지시: "잘 써줘", "적당히 정리해줘"처럼 기준이 없는 표현은 결과를 예측하기 어렵게 만듭니다. 분량, 톤, 대상 독자를 구체적으로 적어야 합니다.
  • 맥락 누락: 배경 설명 없이 질문만 던지면 모델이 잘못된 전제를 채워 넣을 수 있습니다. 필요한 배경 정보는 먼저 제공하세요.
  • 한 프롬프트에 너무 많은 요구: 요약과 번역과 감정 분석을 한 번에 요청하면 일부만 반영되기 쉽습니다. 요청을 나누거나 순서를 명시하세요.

이런 기법은 검색 증강 생성(RAG)이나 에이전트 워크플로우를 설계할 때도 그대로 적용됩니다. RAG의 동작 원리가 궁금하다면 RAG란 무엇인가 글을, 에이전트 워크플로우 설계 기초는 AI 에이전트 시작하기 글을 참고하세요.

자주 묻는 질문

  • Q. 역할을 지정하면 무엇이 달라지나?
    • A. "누구로서, 어떤 상황에서" 답할지 알려주면 답변의 톤과 깊이가 목적에 맞게 좁혀집니다. 역할이 없으면 모델은 가장 무난하고 일반적인 답을 고르는 경향이 있습니다.
  • Q. 예시(퓨샷)는 많이 넣을수록 좋은가?
    • A. 아닙니다. 예시는 많을수록 좋은 것이 아니라, 원하는 패턴을 명확히 드러내는 1~3개면 충분한 경우가 많습니다.
  • Q. 한 프롬프트에 여러 작업을 한꺼번에 넣어도 되나?
    • A. 요약·번역·감정 분석을 한 번에 요청하면 일부만 반영되기 쉽습니다. 요청을 나누거나 순서를 명시하세요.

다음 단계

프롬프트 엔지니어링은 한 번에 완성되지 않습니다. 결과를 보고 프롬프트를 고치는 반복 과정 자체가 이 작업의 핵심입니다. 위 네 가지 기법을 실제 업무 프롬프트에 하나씩 적용해 보면서, 어떤 조합이 자신의 작업에 가장 잘 맞는지 실험해 보길 권합니다.

과제 유형별로 바로 복사해 고쳐 쓸 수 있는 예시가 필요하다면 프롬프트 엔지니어링 실전 예제 10가지에서 요약·번역·분류·이메일 답장 등 10가지 예시 프롬프트를 확인할 수 있습니다.

관련 글

용어

제로샷 러닝

모델이 특정 작업에 대한 예시 없이, 지시문만으로 바로 그 작업을 수행하는 방식이다. 모델이 학습 과정에서 습득한 일반화 능력에 의존해 새로운 작업에도 곧바로 대응한다.

용어

사고의 연쇄

모델이 최종 답을 바로 내놓지 않고, 중간 풀이 과정을 단계별로 거치도록 유도하는 프롬프트 기법이다. 복잡한 추론이 필요한 문제에서 정확도를 높이는 데 쓰인다.