프롬프트 엔지니어링
프롬프트 엔지니어링 (Prompt Engineering)
모델에 어떤 지시를 쓰느냐에 따라 결과 품질이 크게 달라져요. 프롬프트 엔지니어링은 모델이 원하는 내용을 꾸준히 만들어내도록 효과적인 지시를 작성하는 과정이에요. 모델 결과는 결정적이지 않아 예술과 과학이 섞이지만, 몇 가지 기법과 모범 사례를 적용하면 좋은 결과를 반복해서 얻을 수 있어요.
모델 선택
API로 콘텐츠를 만들 때 핵심 선택은 어떤 모델을 쓸지예요. 고려할 요소는 다음과 같아요.
- Reasoning 모델 은 내부 chain of thought로 입력을 분석하고 복잡한 작업·다단계 계획을 잘 이해해요. 다만 GPT 모델보다 일반적으로 느리고 비싸요.
- GPT 모델 은 빠르고 비용 효율적이며 지능도 높지만, 작업 수행 방법에 대한 더 명시적인 지시가 유리해요.
- 크고 작은 모델(mini/nano) 온 속도·비용·지능의 트레이드오프가 있어요. 큰 모델이 도메인 전반의 이해·문제 해결에 강하고, 작은 모델은 보통 더 빠르고 싸요.
무엇을 쓸지 애매하면 gpt-6-astra가 범용 텍스트 생성·프롬프트 반복의 강력한 기본값이 돼요.
메시지 역할과 지시 따르기
instructions API 파라미터나 메시지 역할로 모델에 서로 다른 권한 수준의 지시를 줄 수 있어요. instructions는 모델이 응답할 때의 톤, 목표, 올바른 응답 예시 같은 상위 지시를 주고, input의 프롬프트보다 우선해요.
| developer | user | assistant |
|---|---|---|
| 애플리케이션 개발자가 제공하는 지시. user보다 우선. | 최종 사용자가 제공하는 지시. developer보다 뒤에 처리. | 모델이 생성한 메시지. |
developer와 user를 프로그램의 함수와 인자로 떠올려 보세요. developer는 함수 정의처럼 시스템 규칙·비즈니스 로직을, user는 그 함수에 넘겨지는 인자처럼 입력·설정을 담당해요. instructions는 현재 요청에만 적용되고, previous_response_id로 대화를 관리하면 이전 턴의 instructions는 컨텍스트에 남지 않아요.
프롬프트를 코드로 버전 관리하기
재사용 가능한 프롬프트 객체 대신 프로덕션 프롬프트를 애플리케이션 코드에 저장하는 걸 권장해요. 코드로 관리하면 타입 있는 입력, 코드 리뷰, 테스트, 평소 배포 프로세스로 모델 동작을 바꿀 수 있어요. OpenAI는 재사용 가능한 프롬프트 객체를 폐기하고 있어요. 프롬프트 생성은 2026년 6월 3일부터 비중이 줄고, v1/prompts는 2026년 11월 30일에 종료될 예정이에요(폐기 일정).
새 프롬프트 작업에서는 다음을 지켜요.
- 프롬프트 빌더를 지원하는 기능 옆의 작은 모듈에 유지
- 고객 데이터·파일·작업 옵션 같은 동적 값은 타입 있는 함수 인자나 스키마로 처리
- 생성된
instructions와input을 Responses API에 직접 전달 - 프로덕션 프롬프트를 바꾸기 전에 대표 픽스처·테스트·평가 추가
- 프롬프트 변경은 배포 시스템(기능 플래그나 설정)으로 단계적 배포
이미 저장된 프롬프트를 ID·버전으로 호출 중이라면 프롬프트 객체 마이그레이션 가이드를 참고하세요.
마크다운과 XML로 메시지 꾸미기
developer·user 메시지를 쓸 때 Markdown과 XML 태그를 섞으면 프롬프트와 컨텍스트 데이터의 논리적 경계를 모델이 이해하기 쉬워져요. Markdown 헤더·리스트는 섹션 구분·계층 전달에, XML 태그는 한 콘텐츠가 어디서 시작·끝나는지 알려주는 데 좋아요. XML 속성으로 프롬프트 내 콘텐츠 메타데이터를 정의할 수도 있어요.
developer 메시지는 보통 다음 순서로 구성돼요(모델에 따라 최적 구성은 다를 수 있어요).
- Identity: 어시스턴트의 목적, 커뮤니케이션 스타일, 상위 목표
- Instructions: 원하는 응답을 만들 지침. 규칙, 해야 할 일과 하지 말아야 할 일
- Examples: 가능한 입력과 기대 출력 예시
- Context: 학습 데이터 밖의 사유 데이터처럼 응답에 필요한 추가 정보. 요청마다 다를 수 있어 보통 프롬프트 끝에 둬요
Few-shot learning
파인튜닝 없이 프롬프트에 몇 쌍의 입력·출력 예시를 넣어 모델을 새 작업으로 이끄는 기법이에요. 모델은 예시의 패턴을 암묵적으로 파악해 적용해요. 예시를 줄 땐 가능한 입력과 원하는 출력의 다양한 범위를 보여주는 게 좋아요. 보통 developer 메시지 안에 예시로 넣어요.
관련 컨텍스트 포함하기
모델 응답에 활용할 추가 정보를 프롬프트에 넣는 건 흔히 유용해요. 사유 데이터나 학습 데이터 밖의 정보를 주거나, 응답을 특정 리소스 집합으로 제한하려는 경우죠. 이렇게 추가 컨텍스트를 주는 기법을 retrieval-augmented generation (RAG) 이라고 불러요. 벡터 데이터베이스를 조회해 텍스트를 프롬프트에 넣거나, OpenAI 내장 file search 도구로 업로드 문서 기반 콘텐츠를 만들면 돼요.
단, 모델이 한 번에 처리할 수 있는 데이터는 컨텍스트 윈도우(토큰 단위의 메모리 한계) 안으로 제한돼요. 모델마다 컨텍스트 윈도우 크기가 달라요 — 저수준 10만 범위부터 최신 GPT-4.1 모델은 백만 토큰까지. 구체적인 크기는 모델 문서에서 확인하세요.
현재 모델 프롬프팅
gpt-6-astra 같은 GPT 모델은 작업을 완료하는 데 필요한 로직·데이터를 명시적으로 제공하는 정밀한 지시가 유리해요. 최신 모델에서 가장 좋은 결과를 얻으려면 현재 prompting 가이드로 시작하는 걸 권해요.
최신 모델 프롬프팅 실천 요령을 영역별로 보면 이래요.
- 코딩: 에이전트 역할을 명확히 하고, 도구 사용 예시를 제시하며, 정확성을 위한 테스트를 요구하고, 깨끗한 출력을 위한 Markdown 기준을 세워요.
- 프론트엔드 작업: Tailwind CSS·shadcn/ui·Radix Themes 같은 추천 라이브러리를 쓰고, 대형 코드베이스에서는 원칙·UI/UX·구조·컴포넌트·페이지·에이전트 지시 범주를 지시에 포함해요.
- 에이전트 작업: 계획을 철저히 세워 완전히 해결하게 하고, 주요 도구 사용 결정에는 명확한 전조(preable)를, 진행 추적에는 TODO 도구를 쓰게 해요.
Reasoning 모델 프롬프팅
reasoning 모델과 GPT 모델은 프롬프팅 방식이 달라요. 일반적으로 reasoning 모델은 수준 높은 지침만으로 더 나은 결과를 내요. GPT 모델은 아주 정밀한 지시가 유리하고요. 비유하자면, reasoning 모델은 목표를 주면 세부를 스스로 해결하는 선임 동료이고, GPT 모델은 구체적인 출력을 만들어내는 명시적 지시가 필요한 주니어 동료예요. reasoning 모델 사용의 모범 사례는 이 가이드를 참고하세요.