프롬프트 엔지니어링 실전 - 원하는 답을 얻는 법
같은 모델에게 같은 일을 시켜도, 어떻게 묻느냐에 따라 결과 품질이 극단적으로 갈립니다. "요약해줘"와 "3문장으로, 핵심 지표 중심으로, 존댓말로 요약해줘"는 전혀 다른 답을 냅니다. 프롬프트 엔지니어링은 마법 주문이 아니라, 모델에게 원하는 것을 오해 없이 전달하는 커뮤니케이션 기술입니다.
이 글에서는 실무에서 바로 쓰는 프롬프트 구성 원칙, 대표 기법, 자주 실패하는 패턴, 그리고 개발자용 템플릿을 정리합니다.
1. 좋은 프롬프트의 4가지 축
잘 짜인 프롬프트는 대개 네 요소를 갖춥니다. 역할 · 지시 · 예시 · 출력 형식 입니다.
1-1. 역할(Role) — 누구로서 답할지 지정
너는 10년차 백엔드 엔지니어야. 주니어에게 코드 리뷰를 해준다.
역할을 주면 모델이 어휘·깊이·관점을 그에 맞춰 조정합니다. "전문가처럼"보다 구체적인 역할이 효과가 큽니다.
1-2. 지시(Instruction) — 무엇을, 어떻게
- 애매한 지시: "이 코드 좀 봐줘"
- 명확한 지시: "이 함수에서 동시성 버그를 찾고, 각 문제의 원인과 수정 방법을 알려줘"
모델은 눈치가 없습니다. 원하는 것을 구체적으로, 긍정문으로 적으세요. "~하지 마"보다 "~하라"가 잘 먹힙니다.
1-3. 예시(Few-shot) — 보여주면 확실하다
말로 설명하기 애매한 형식·톤은 예시 몇 개로 보여주는 게 가장 빠릅니다. 이걸 few-shot 프롬프팅이라 합니다.
다음 형식으로 커밋 메시지를 작성해.
입력: 로그인 시 토큰 만료 처리 안 됨
출력: fix(auth): 만료된 토큰 갱신 로직 추가
입력: 상품 목록 API 응답 느림
출력: perf(product): 목록 조회 쿼리 인덱스 추가
입력: 회원가입 이메일 중복 검사 누락
출력:
예시 없이(zero-shot) 되면 좋지만, 형식이 중요할수록 few-shot이 안정적입니다.
1-4. 출력 형식(Output Format) — 받을 그릇을 정하라
프로그램이 파싱할 답이라면 형식을 못 박아야 합니다.
반드시 아래 JSON 형식으로만 답해. 다른 설명은 붙이지 마.
{ "severity": "high|medium|low", "summary": "한 줄 요약", "line": 숫자 }
"다른 설명 붙이지 마"를 명시하지 않으면 모델이 "물론이죠! 여기 있습니다:" 같은 군더더기를 붙여 파싱을 깨뜨립니다.
2. Chain-of-Thought — 생각할 시간을 줘라
어렵거나 여러 단계를 거치는 문제는, 곧장 답을 요구하면 틀리기 쉽습니다. 단계적으로 생각하게 하면 정확도가 올라갑니다. 이것이 Chain-of-Thought(CoT) 입니다.
다음 문제를 풀 때, 먼저 단계별로 근거를 정리한 뒤 마지막에 결론을 내려줘.
직관은 이렇습니다. 모델은 토큰을 하나씩 생성하므로, 중간 추론을 글로 뱉으면 그 추론 위에서 다음을 계산할 수 있습니다. 곧바로 정답을 내라고 하면 "계산할 공간" 없이 찍는 셈이죠.
주의점:
- 간단한 작업엔 오히려 과하다. 분류·추출 같은 단순 작업은 CoT가 토큰·비용만 늘립니다.
- 사용자에게 추론 과정을 보일 필요는 없다. 내부적으로 생각하게 하되, 최종 응답만 노출하는 구조로 설계할 수 있습니다.
- 최근 추론 모델(reasoning model) 들은 이 과정을 내부에서 알아서 하므로, 굳이 "단계별로 생각해"를 붙이지 않아도 됩니다.
3. 구조화 — 프롬프트에도 문서 구조를
긴 프롬프트일수록 구획을 나눠 주면 모델이 지시와 데이터를 헷갈리지 않습니다. 구분자(마크다운 헤딩, XML 태그 등)를 쓰는 게 정석입니다.
# 역할
너는 기술 문서 번역가야.
# 지시
아래 <text>를 한국어로 번역해. 코드와 고유명사는 그대로 둬.
# 제약
- 존댓말 사용
- 의역보다 정확성 우선
<text>
{번역할 원문}
</text>