퓨샷 · 사고의 연쇄 · 출력 형식
원하는 출력을 얻기 위해 지시·맥락·예시·형식을 설계하는 기술 — 검증된 패턴과 안티패턴을 실전 예제로 안내합니다.
프롬프트 엔지니어링 실전
프롬프트 엔지니어링은 원하는 출력을 얻기 위해 지시·맥락·예시·출력 형식을 설계하는 기술이다. 좋은 프롬프트는 세 요소를 갖춘다 — 명확한 과업, 정확히 수행할 만큼의 맥락, 정의된 출력 구조. 모델이 똑똑해질수록 장황한 주술보다 명료한 지시와 잘 고른 예시가 더 효과적이다.
좋은 프롬프트의 3요소
- 명확한 과업 정의 — 무엇을 해야 하는지 모호함 없이.
- 충분한(과하지 않은) 맥락 — 관련 자료만 추려 넣는다. 큰 컨텍스트를 무조건 채우면 노이즈·비용이 증가한다.
- 정의된 출력 구조 — JSON·표·불릿 등 형식을 못박는다.
퓨샷과 사고의 연쇄
퓨샷은 3~5개 예시를 주어 형식·톤을 모방하게 하는 기법으로, 분류·번역·요약에서 비용 대비 품질이 좋다. 사고의 연쇄(CoT)는 최종 답 전에 단계적으로 추론하게 유도해 수학·논리·다단계 정확도를 높인다. 가장 쉬운 형태는 '단계별로 생각해 보자' 한 줄을 붙이는 제로샷 CoT다. 여기에 자기 일관성(여러 추론 경로를 샘플링해 다수결)을 얹으면 오답률이 더 낮아진다 — 다만 토큰을 더 쓰므로 정답이 갈리는 문제에 아껴 쓴다.
예시 프롬프트 — 역할·맥락·예시·출력
[맥락] 아래 로그에서 의심스러운 접근을 찾습니다.
[지시] 단계별로 근거를 밝힌 뒤, 위험도(상/중/하)로 분류하세요.
[예시]
입력: "203.0.113.9 실패 로그인 40회/1분"
출력: { "risk": "상", "reason": "브루트포스 의심" }
[출력 형식] JSON 배열만. 설명 산문 금지.
# --- 분석할 로그 ---
[여기에 로그 붙여넣기]
출력 형식 강제와 시스템 프롬프트
자동화로 이어 받을 출력은 형식이 안정적이어야 한다. JSON 스키마·표를 명시하고 예시 출력을 보여 주면 파싱 실패가 크게 준다. 역할·규칙·금지사항처럼 항상 적용되는 지시는 사용자 입력과 분리해 시스템 프롬프트에 두면, 사용자 메시지가 바뀌어도 일관된 페르소나·제약이 유지되고 프롬프트를 파일처럼 버전 관리·A/B 테스트할 수 있다.
실전 팁
- '하지 말 것'보다 '할 것'을 긍정형으로 명시한다.
- 역할·페르소나를 부여해 톤·전문성 수준을 좁힌다.
- 잘 작동한 프롬프트는 템플릿으로 저장(MCP Prompts·사내 저장소)해 재사용한다.
- 모델 세대가 바뀌면 회귀 테스트로 품질을 재검증한다.
정교한 '주술'은 덜 필요해지지만, 명확한 과업 정의·적절한 맥락·출력 형식 설계의 가치는 오히려 커진다. 자동화·에이전트에서는 프롬프트가 곧 프로그램의 사양서 역할을 한다.
출력 예시를 한두 개 보여 주고, 구조화 출력/JSON 모드를 켜고, 파이프라인에 스키마 검증과 재시도를 추가하면 대부분 해결된다. 형식을 예시로 못박는 것이 부정 지시보다 효과적이다.
피해야 할 안티패턴
이것부터 고치면 결과가 달라집니다
모호한 과업
'잘 정리해줘' 같은 막연한 지시는 막연한 답을 부릅니다. 무엇을·어떤 관점으로·어떤 형식으로 원하는지 구체적으로 명시해야 합니다.
맥락 과다 투입
컨텍스트가 크다고 무조건 채우면 관련 없는 내용이 노이즈가 되고 비용도 증가합니다. 핵심 자료만 추려 넣고 반복 문서는 캐싱으로 재사용하세요.
부정형 지시 남발
'~하지 마'보다 원하는 동작을 긍정형으로 명시하는 편이 효과적입니다. 형식은 설명하지 말고 예시 출력으로 못박는 것이 파싱 실패를 줄입니다.
좋은 프롬프트의 뼈대
좋은 프롬프트는 역할, 문맥, 지시, 예시, 출력 형식이라는 뼈대를 갖춥니다. 역할·규칙처럼 항상 적용되는 지시는 시스템 프롬프트로 분리해 일관성을 유지하고, 예시(퓨샷)로 형식과 톤을 모방하게 하며, 복잡한 추론엔 '단계별로 생각해 보자'를 붙여 사고의 연쇄를 유도합니다. 모델이 강력해질수록 장황한 주술보다 이 명료한 구조가 결과 품질을 좌우합니다.