고급 프롬프트 기법 - 실무 활용 가이드

핵심 원칙

명확하고 애매하지 않은 언어 사용

❌ 나쁜 예: "이것에 대해 요약해보세요"
✅ 좋은 예: "다음 텍스트를 3개의 글머리 기호로 요약해주세요"

지시사항을 간결하고 직접적으로 유지

❌ 나쁜 예: "가능하시다면, 제가 제공하는 이 텍스트를 번역해주실 수 있을까요"
✅ 좋은 예: "이 텍스트를 프랑스어로 번역해주세요:"

강력한 동작 동사 사용

（분석, 생성, 추출, 요약, 비교, 생성, 평가）

❌ 나쁜 예: "이 데이터를 좀 봐주실 수 있나요?"
✅ 좋은 예: "이 데이터를 분석하여 트렌드를 파악해주세요"

제약이 아닌 긍정적인 지시로 표현

❌ 나쁜 예: "전문 용어를 사용하지 마세요"
✅ 좋은 예: "일반 독자를 위해 쉬운 용어로 설명해주세요"

프롬프트 시도를 반복하고 문서화

❌ 나쁜 예: 테스트 없이 첫 번째 초안 사용
✅ 좋은 예: 테스트 → 출력 분석 → 개선 → 결과 문서화

기본 기법

간단한 작업에는 제로샷부터 시작

❌ 나쁜 예: 기본적인 작업에 예시를 과도하게 제공
✅ 좋은 예: "프랑스의 수도는 무엇인가요?"

특정 형식/스타일이 필요할 때 하나의 예시 추가

❌ 나쁜 예: 하나로 충분할 때 여러 예시 제공
✅ 좋은 예: 하나의 번역 예시를 보여주고 유사한 번역 요청

퓨샷 프롬프팅에는 3-5개의 다양한 예시 사용

❌ 나쁜 예: 유사하거나 편향된 예시 사용
✅ 좋은 예: 분류를 위해 긍정적, 부정적, 중립적 감정 예시 혼합

분류 예시에서 클래스 순서 무작위화

❌ 나쁜 예: 모든 긍정적 예시 먼저, 그 다음 모든 부정적 예시
✅ 좋은 예: 서로 다른 클래스 간에 무작위로 교대 배치

프롬프트 구조

처음에 시스템 맥락 설정

❌ 나쁜 예: 시스템 지시와 사용자 쿼리 혼합
✅ 좋은 예: "당신은 도움이 되는 AI 어시스턴트입니다. 항상 정중하게 응답하세요."

필요시 특정 역할 할당

❌ 나쁜 예: "로마에 대해 써주세요"
✅ 좋은 예: "여행 블로거 역할을 하여 로마의 숨겨진 명소에 대해 써주세요"

명확한 구분자 사용

（삼중 백틱, XML 태그, 대시）

❌ 나쁜 예: 지시사항과 내용 혼합
✅ 좋은 예: <instruction>이것을 요약하세요</instruction> <article>[내용]</article>

구조화된 출력을 명시적으로 요청

❌ 나쁜 예: "정보를 주세요"
✅ 좋은 예: "name, date, location 키를 가진 JSON으로 반환해주세요"

추론 강화

복잡한 문제에 "단계별로 생각해봅시다" 추가

❌ 나쁜 예: "847293 × 652847은 얼마인가요?"
✅ 좋은 예: "847293 × 652847은 얼마인가요? 단계별로 생각해봅시다."

결정론적 추론을 위해 temperature를 0으로 설정

❌ 나쁜 예: 수학 문제에 높은 temperature
✅ 좋은 예: 계산 및 논리 작업에 Temperature=0

특정 작업 전에 일반 원칙 질문 (Step-Back)

❌ 나쁜 예: "탐정 소설을 써주세요"
✅ 좋은 예: "좋은 탐정 소설의 요소는 무엇인가요? 이제 그 원칙을 사용해서 하나 써주세요"

중요한 작업에 여러 추론 경로 생성 (Self-Consistency)

❌ 나쁜 예: 중요한 결정에 단일 출력에 의존
✅ 좋은 예: 높은 temperature로 3-5회 실행하고 다수결 채택

도구 사용 및 액션

매개변수가 포함된 명확한 도구 설명 제공

❌ 나쁜 예: "웹 검색이 가능합니다"
✅ 좋은 예: "도구: web_search(query: string) - 최신 정보 검색"

다단계 작업에 ReAct 패턴 사용

❌ 나쁜 예: 복잡한 쿼리를 한 번에 처리
✅ 좋은 예: 생각 → 행동 → 관찰 → 완료까지 반복

다음 단계의 맥락으로 도구 출력 포함

❌ 나쁜 예: 도구 결과 무시
✅ 좋은 예: "검색 결과를 바탕으로: [데이터], 이제 분석하세요..."

고급 최적화

복잡한 작업을 하위 작업으로 분할

❌ 나쁜 예: "AI에 대한 완전한 연구 논문을 써주세요"
✅ 좋은 예: 개요 → 섹션 → 결론을 위한 별도 프롬프트

대상 독자를 명시적으로 지정 (페르소나 패턴)

❌ 나쁜 예: "양자 물리학을 설명하세요"
✅ 좋은 예: "고등학생에게 양자 물리학을 설명하세요"

LLM을 사용하여 프롬프트 개선

❌ 나쁜 예: 수동 시행착오만 사용
✅ 좋은 예: "이 프롬프트를 분석하고 개선 사항을 제안하세요: [프롬프트]"

코드 및 기술 작업

언어와 버전 지정

❌ 나쁜 예: "리스트를 정렬하는 코드를 써주세요"
✅ 좋은 예: "Python 3.9에서 리스트를 정렬하는 코드를 써주세요"

디버깅을 위한 맥락과 오류 메시지 제공

❌ 나쁜 예: "이 코드를 고쳐주세요"
✅ 좋은 예: "NameError가 발생하는 이 Python 코드를 고쳐주세요: [코드 + 추적]"

품질 관리

엣지 케이스로 프롬프트 테스트

❌ 나쁜 예: 이상적인 입력으로만 테스트
✅ 좋은 예: 불완전하거나 애매하거나 이상한 입력으로 테스트

구조화된 출력을 프로그래밍 방식으로 검증

（JSON 검증을 위한 Pydantic 같은 스키마 사용）

❌ 나쁜 예: JSON이 항상 유효하다고 가정
✅ 좋은 예: 스키마 강제로 파싱 및 검증

성공한 프롬프트를 버전 관리에 저장

❌ 나쁜 예: 채팅 기록에만 프롬프트 보관
✅ 좋은 예: 코드베이스의 .txt/.md 파일에 저장

자동화된 테스트로 프롬프트 성능 모니터링

❌ 나쁜 예: 수동 확인만 사용
✅ 좋은 예: 예상 출력으로 테스트 스위트 생성

모델 변경 시 프롬프트 업데이트

❌ 나쁜 예: 프롬프트가 모든 버전에서 작동한다고 가정
✅ 좋은 예: 새 모델 릴리스에 대해 재테스트 및 조정

빠른 참조 - 프롬프트용 동작 동사

분석: 분석, 평가, 사정, 비교, 대조, 검토 생성: 생성, 창조, 제작, 설계, 개발, 구성 추출: 추출, 식별, 찾기, 위치 찾기, 검색, 분리 변환: 변환, 전환, 번역, 재포맷, 적응 요약: 요약, 압축, 추상화, 개요, 강조 정리: 분류, 분류, 정렬, 그룹화, 정리, 구조화

템플릿 예시

기본 작업 템플릿

역할: [선택사항: 특정 역할]
작업: [명확한 동작 동사 + 구체적 요구사항]
입력: [명확히 구분된 내용]
출력: [예상 형식/구조]

복잡한 추론 템플릿

맥락: [배경 정보]
작업: [주요 목표]
단계:
1. [첫 번째 하위 작업]
2. [두 번째 하위 작업]
3. [최종 종합]
형식: [출력 요구사항]

도구 사용 템플릿

사용 가능한 도구:
- tool_name(매개변수): 설명

작업: [도구가 필요한 복잡한 쿼리]
프로세스: ReAct 패턴 사용
예상: [최종 결과물]