프롬프트 엔지니어링 2026: ChatGPT·Claude·Gemini 공식 가이드로 본 프롬프트 작성법의 변화

2026년의 프롬프트 엔지니어링은 문장을 다듬는 요령보다 목표·맥락·완료 기준을 정확히 전달하는 일에 가깝습니다. 이 글은 ChatGPT, Claude, Gemini를 만드는 OpenAI, Anthropic, Google 세 회사의 공식 개발자 문서가 2026년 10월 현재 권장하는 프롬프트 작성 방식을 비교·정리한 실무 가이드입니다. 더 이상 권장하지 않는 기법, 회사별 모델과 추론 설정, 같은 과제를 세 모델에 맡길 때의 프롬프트 차이를 순서대로 다룹니다.

한눈에 보기

• 세 회사 모두 대문자 강조, "단계별로 생각해", 장문의 절차 지시 같은 기존 기법을 최신 모델에서는 줄이거나 빼라고 안내합니다. 모델이 내부적으로 추론하고 지시를 문자 그대로 따르기 때문입니다.
• 이제 추론의 양은 프롬프트 문구 대신 각 회사의 추론 수준 설정으로 조절하고, 출력 형식은 구조화 출력 기능으로 지정합니다.
• 구조화 방식, 예시 개수, 긴 자료의 배치처럼 세 회사의 권장 사항이 실제로 갈리는 지점이 있어, 같은 프롬프트라도 모델에 맞게 조정하면 결과가 나아집니다.

모델 이름과 권장 사항은 2026년 10월 2일에 각 회사 공식 문서에서 확인한 내용입니다. 모델은 수시로 바뀌므로 실제로 적용하기 전에 글 끝 출처의 원문을 확인해 보세요. 제로샷, 퓨샷, 사고 사슬(CoT) 같은 기본 기법과 그 원리는 프롬프트 엔지니어링이란?에 정리해 두었습니다.

이런 상황을 떠올려 보세요. 한 회사의 고객지원팀이 2024년에 만든 답변 작성용 프롬프트를 지금도 쓰고 있습니다. "반드시 정중하게 답할 것", "답하기 전에 단계별로 생각할 것", "절대로 추측하지 말 것" 같은 문장이 열 줄 넘게 이어지고, 중요한 단어는 대문자로 강조돼 있습니다. 그런데 최신 모델로 바꾼 뒤부터 답변이 지나치게 길어지고, 간단한 문의에도 되묻는 일이 잦아졌습니다. 모델 성능이 떨어져서 생긴 문제는 아닙니다. 예전 모델이 지시를 놓치지 않게 하려고 넣은 문장을 새 모델이 지나치게 충실히 따른 결과입니다.

기존 프롬프트 기법을 다시 검토해야 하는 이유

2~3년 전의 언어 모델은 지시를 자주 놓쳤습니다. 그래서 중요한 규칙은 대문자로 강조하고, 같은 지시를 여러 번 반복하고, 추론 과정을 출력하게 해서 품질을 끌어올리는 기법이 널리 쓰였습니다. 최신 모델에서는 두 가지가 달라졌습니다.

첫째, 모델이 답하기 전에 내부적으로 추론합니다. OpenAI는 추론 모델에 "단계별로 생각해"나 "추론 과정을 설명해"라고 요청할 필요가 없고, 오히려 성능이 떨어질 수 있다고 안내합니다⁴. Google도 Gemini 3에서는 응답에 추론 단계를 쓰게 할 필요가 없다고 설명합니다¹¹.

둘째, 모델이 지시를 문자 그대로 따릅니다. OpenAI는 GPT-5 계열 모델이 프롬프트의 규칙을 충실히 따르기 때문에, 설명이 빠진 프롬프트보다 규칙끼리 충돌하는 프롬프트에서 동작이 더 불안정해진다고 밝혔습니다¹. Anthropic은 "변경 사항을 제안해 줄 수 있나요?"라고 물으면 Claude가 실제로 고치지 않고 제안만 할 수 있다고 안내합니다⁷. 예전처럼 강하게 써 둔 지시에 새 모델은 과하게 반응합니다.

OpenAI는 그 효과를 수치로도 공개했습니다. 시스템 프롬프트를 간소화한 구성에서 평가 점수가 약 10~15% 올랐고, 전체 토큰은 41~66%, 비용은 33~67% 줄었습니다¹. 프롬프트를 늘리는 것보다 정리하는 것이 품질과 비용 모두에 유리할 수 있다는 뜻입니다.

더 이상 권장되지 않는 기법 8가지

아래 표는 세 회사의 공식 문서가 최신 모델에서 줄이거나 빼라고 안내하는 기법입니다. 근거 열에는 그 내용을 문서에 명시한 회사를 적었습니다. 한 회사만 적힌 항목도 다른 회사의 가이드와 충돌하지 않습니다.

몇 가지는 원문을 함께 보면 의도가 더 분명합니다. Anthropic은 예전에 "CRITICAL: 반드시 이 도구를 사용하라"라고 썼던 자리에 "이런 경우 이 도구를 사용한다" 정도의 평범한 문장이면 충분하다고 설명합니다⁷. OpenAI는 "간결하게"나 "짧게" 같은 포괄적 지시가 일부 작업에서는 답을 지나치게 짧게 만들 수 있으니, 포함할 내용을 직접 지정하라고 권합니다¹. Google은 temperature를 1.0보다 낮추면 같은 내용을 반복하거나 복잡한 추론에서 성능이 떨어질 수 있다고 경고합니다¹¹.

3사의 주요 모델과 추론 설정

프롬프트를 고치기 전에 모델 등급과 추론 수준부터 확인합니다. 세 회사 모두 품질을 높이려고 추론 수준부터 올리라고 권하지는 않습니다.

추론 수준에 관해서는 세 회사의 안내가 비슷합니다. OpenAI는 추론 강도를 "품질을 되살리는 주된 수단이 아니라 미세 조정 옵션"으로 설명하고, 강도를 높이기 전에 프롬프트에 성공 기준이나 검증 절차가 빠지지 않았는지 먼저 보라고 권합니다¹⁵. Anthropic은 모델을 바꾸는 것보다 effort를 조정하는 편이 더 나은 경우가 많다고 안내합니다²⁵. Google은 비용과 지연을 줄일 때 출력 길이를 자르지 말고 추론 수준을 낮추라고 권합니다¹⁴.

함께 알아 둘 변화가 두 가지 있습니다. 먼저 토큰 수로 추론 예산을 지정하던 방식은 점차 쓰이지 않습니다. Claude는 최신 모델에서 이 설정을 쓰면 오류를 반환하고⁷, Gemini 3.x에서는 이 설정을 더 이상 권장하지 않습니다¹³. 또 같은 이름의 단계라도 모델마다 실제 추론량이 다릅니다. Anthropic은 모델을 바꾸면 effort 단계별로 다시 평가하라고 안내합니다²⁶.

ChatGPT(OpenAI): 목표를 명시하고 수행 방식은 모델에 맡깁니다

OpenAI의 GPT-5.6 프롬프트 가이드는 핵심을 "모든 단계를 지정하지 말고 최종 목표를 기술하라"는 한 문장으로 정리합니다¹. 프롬프트에는 기대하는 결과물, 중요한 제약 조건, 활용할 근거, 완료 기준을 적고, 효율적인 수행 경로는 모델이 고르게 둡니다. 에이전트 작업이나 조사 작업이라면 무엇이 완료인지, 결과를 어떻게 검증할지를 함께 정합니다⁵.

일반 사용자용 ChatGPT 안내도 같은 방향입니다. 목표(Goal), 맥락(Context), 출력(Output), 제약 조건(Boundaries)의 네 요소를 제시하며, 정해진 공식이나 문법은 필요하지 않다고 설명합니다. 제약 조건은 가장 중요한 한두 가지에 집중하라고 권합니다⁶.

GPT-6 Astra에는 프롬프트를 작성할 때 고려할 성향이 몇 가지 있습니다²²⁷.

"친절하게", "공감하며" 같은 포괄적 표현도 다시 볼 대상입니다. OpenAI는 이런 표현이 모호하므로 원하는 문체를 구체적으로 기술하라고 권합니다¹.

Claude(Anthropic): 배경을 설명하고 XML 태그로 구조화합니다

Anthropic의 가이드는 Claude를 "역량은 뛰어나지만 조직의 업무 방식은 모르는 신입 직원"으로 보라는 말로 시작합니다⁷. 이어서 간단한 점검 방법을 제시합니다. 작업 배경을 거의 모르는 동료에게 프롬프트를 보여 주고 그대로 해 보게 합니다. 그 동료가 혼란스러워한다면 Claude도 마찬가지입니다⁷.

Claude에 맞춘 작성 원칙은 다음과 같습니다⁷.

• 지시의 이유를 함께 씁니다. Claude는 설명을 바탕으로 원칙을 일반화해 적용합니다.
• XML 태그로 구성 요소를 나눕니다. 지시, 맥락, 예시, 입력을 각각의 태그로 감싸면 해석 오류가 줄어듭니다. 태그 이름은 일관되게 씁니다.
• 예시는 3~5개를 제공합니다. 출력 형식과 어조를 맞추는 가장 확실한 방법이라고 설명합니다.
• 긴 자료는 위에, 질문은 아래에 둡니다. Anthropic의 테스트에서는 질문을 끝에 두었을 때 응답 품질이 최대 30% 향상됐습니다. 긴 문서라면 작업 전에 관련 부분을 먼저 인용하게 하는 방법도 권합니다.
• 금지 대신 수행할 내용을 씁니다. "마크다운을 쓰지 말 것"보다 "서술형 문단으로 작성할 것"이 효과적입니다.

최신 Claude에서 바뀐 점도 있습니다. 응답 앞부분을 미리 채워 형식을 유도하던 프리필은 Claude 4.6부터 지원하지 않으며, 요청하면 오류가 반환됩니다. 형식은 구조화 출력으로 지정합니다⁷. Claude Opus 5.5에서는 "답하기 전에 신중하게 생각하라"는 지시를 빼라고 안내하며, 추론량은 effort로 조절합니다¹⁰. 또 프롬프트에 쓴 서식이 출력에도 옮겨 가므로, 출력의 마크다운을 줄이려면 프롬프트의 마크다운부터 줄이라고 권합니다⁷.

Gemini(Google): 간결하게 지시하고 예시를 항상 넣습니다

Google의 「프롬프트 설계 전략」 문서는 목표를 명확하고 간결하게 적고, 불필요한 표현이나 과하게 설득조인 표현은 피하라고 권합니다¹¹. 세 회사 가운데 예시를 가장 강하게 권하는 곳도 Google입니다. 프롬프트에 예시를 항상 넣으라고 안내하며, 예시가 충분히 명확하면 지시문을 줄여도 된다고 설명합니다. 다만 예시가 지나치게 많으면 응답이 예시에 과적합될 수 있다고 덧붙입니다¹¹.

Gemini에 맞춘 작성 원칙은 다음과 같습니다¹¹.

• 구조화 방식은 한 가지만 씁니다. XML 스타일 태그와 마크다운 헤더 모두 효과적이지만, 한 프롬프트 안에서는 하나를 골라 일관되게 씁니다.
• 핵심 지시는 맨 앞에 둡니다. 동작 제약, 역할, 출력 형식은 시스템 프롬프트나 프롬프트 맨 앞에 배치합니다.
• 자료를 먼저, 질문은 맨 끝에 둡니다. "위 정보를 바탕으로"처럼 자료와 질문을 잇는 문구를 쓰라고 권합니다.
• 도구를 활성화합니다. 잘 알려지지 않았거나 최근의 사실이 필요하면 Google 검색 그라운딩을, 계산이 들어가면 코드 실행을 켭니다.

Gemini 3.x에서 바뀐 점은 설정 쪽에 많습니다. temperature, top_p, top_k는 더 이상 권장하지 않으며¹³, 추론을 끌어내던 사고 사슬 프롬프트 대신 thinking_level을 medium이나 high로 설정하라고 안내합니다¹³. Gemini 3.8 Flash로 옮길 때는 응답 프리필을 제거하라고 명시합니다²². 기존 모델에 맞춰 길게 쓴 프롬프트를 그대로 쓰면 모델이 과도하게 분석할 수 있다고도 안내합니다¹³.

3사 가이드 비교: 공통점과 차이점

세 회사의 권장 사항이 실제로 갈리는 지점은 아래와 같습니다. 같은 프롬프트를 세 모델에 그대로 쓰면 결과 품질이 달라지는 부분이기도 합니다.

공통점은 더 많습니다. 세 회사 모두 목표, 성공 기준, 제약 조건, 출력 형식을 명확히 적으라고 권합니다. 출력 형식은 프리필 대신 구조화 출력으로 지정하고, 고정된 내용은 프롬프트 앞쪽에 두어 캐시를 활용하라고 안내합니다¹⁷¹⁸¹⁹. 모델을 바꾸면 프롬프트를 다시 평가하라는 권고도 같습니다. OpenAI는 정상 동작하던 프롬프트를 한 번에 전면 수정하지 말고, 대표 사례로 평가를 먼저 돌린 뒤 바꾸라고 안내합니다¹.

같은 과제를 세 모델에 맡길 때

과제는 쇼핑몰 리뷰 200건에서 반복되는 불만 사항 세 가지를 찾아 기획팀 회의용 보고서로 정리하는 일입니다. 아래는 각 회사의 권장 사항에 맞춰 젠아이랩스가 작성한 예시이며, 공식 문서에 실린 프롬프트가 아닙니다.

ChatGPT용: 목표, 완료 기준, 출력 형식을 헤더로 나누고 자료는 태그로 감쌉니다.

# 목표
아래 리뷰에서 반복되는 불만 사항 3가지를 찾아, 상품 기획팀 회의용 1페이지 보고서로 정리한다.
# 완료 기준
- 불만 사항별 건수를 집계하고, 근거 리뷰를 2건 이상 원문 그대로 인용했다
- 리뷰에 없는 원인을 추정해 넣지 않았다
# 출력 형식
서술형 3개 문단. 표와 목록은 쓰지 않는다.
<reviews> …리뷰 200건… </reviews>

Claude용: 자료를 맨 위에 두고, 보고서를 누가 왜 읽는지 설명한 뒤 인용부터 하게 합니다.

<reviews> …리뷰 200건… </reviews>
<context>
상품 기획팀이 회의에서 개선 우선순위를 정한다. 팀원들은 리뷰 원문을 읽지 않으므로 보고서만으로 판단할 수 있어야 한다.
</context>
<instructions>
먼저 불만이 담긴 문장을 <quotes> 안에 원문 그대로 옮겨 적어 줘. 그 인용을 근거로 반복되는 불만 사항 3가지를 건수와 함께 정리해 줘. 회의 자료에 그대로 쓰므로 서술형 3개 문단으로 작성해 줘.
</instructions>

Gemini용: 자료를 먼저 주고 예시를 넣은 뒤, 질문을 맨 끝에 둡니다.

<context> …리뷰 200건… </context>
<examples>
입력: "배송은 빠른데 상자가 찌그러져 왔어요" → 출력: 포장 | 불만 | "상자가 찌그러져"
입력: "가격 대비 만족합니다" → 출력: 가격 | 만족 | "가격 대비 만족"
</examples>
<task>
위 리뷰를 바탕으로 예시처럼 분류한 뒤, 가장 많이 나온 불만 사항 3가지를 건수와 근거 인용 2건씩 붙여 보고해 줘. 서술형 3개 문단으로 자세히 작성해 줘.
</task>

세 프롬프트 모두 "단계별로 생각해"나 대문자 강조를 쓰지 않았습니다. 추론의 양은 각 모델의 추론 수준 설정으로 정합니다.

에이전트에게 일을 맡길 때의 프롬프트 원칙

도구를 쓰며 오래 동작하는 에이전트에서는 프롬프트의 역할이 달라집니다. 문장 표현보다 작업 범위와 판단 기준을 정하는 일이 중요해집니다.

• 완료 기준과 검증 방법을 먼저 정합니다. 테스트 통과, 빌드 성공, 원본 자료와의 대조처럼 어떤 조건을 만족하면 완료인지 적습니다¹⁵.
• 자율 범위와 확인 대상을 나눕니다. OpenAI는 외부 쓰기, 삭제, 결제, 작업 범위를 크게 넓히는 경우에만 확인을 받게 하라고 권합니다¹. Anthropic도 되돌리기 어렵거나 공유 시스템에 영향을 주는 작업만 사용자에게 묻게 하라고 안내합니다⁷.
• 같은 금지 지시를 반복하지 않습니다. "먼저 물어볼 것"을 여러 번 적으면 안전한 작업까지 승인을 요청하게 됩니다¹.
• 독립적인 조회는 병렬로, 선후 관계가 있는 작업은 순차로 수행하게 합니다¹.
• 진행 보고는 줄입니다. 첫 도구 호출 전에 짧게 알리고, 이후에는 큰 단계가 바뀔 때만 결과 위주로 보고하게 합니다¹.
• 장시간 작업의 상태는 파일과 git에 남기게 합니다. 컨텍스트가 초기화돼도 작업을 이어 갈 수 있습니다⁷.
• 외부에서 가져온 텍스트는 태그로 감쌉니다. 붙여 넣은 문서 안의 지시를 모델이 따르지 않도록 자료와 지시를 구분합니다¹⁰.

이 영역에서는 회사 간 차이도 있습니다. OpenAI와 Anthropic은 최신 모델에 절차 지시를 줄이라고 권하지만, Google은 의존성, 리스크, 가설, 지속성 등 9개 항목으로 구성된 계획 템플릿을 시스템 프롬프트 예시로 제공합니다. Google은 사용자와 상호작용하며 복잡한 규칙을 따라야 하는 에이전트 벤치마크에서 이 템플릿으로 성능이 올랐다고 설명합니다¹¹. Gemini로 에이전트를 만든다면 이 템플릿에서 시작해 볼 만합니다.

프롬프트 다음 단계: 컨텍스트, 스킬, 평가

세 회사의 문서는 공통으로 문장 표현보다 모델에 어떤 정보를 주고 결과를 어떻게 검증할지에 무게를 둡니다.

컨텍스트 엔지니어링. Anthropic은 컨텍스트 엔지니어링을 "프롬프트 엔지니어링의 자연스러운 다음 단계"로 정의합니다. 원하는 결과가 나올 가능성을 가장 높이는, 꼭 필요한 정보만 담은 최소한의 토큰을 찾는 일입니다¹⁵. 토큰이 늘수록 모델의 주의는 분산되므로, 많이 넣는 것보다 필요한 정보를 골라 넣는 것이 중요합니다. 개념은 컨텍스트 엔지니어링이란?에서 자세히 다룹니다.

스킬. 반복해서 쓰는 지시와 스크립트를 폴더 단위로 묶어 두고 필요할 때만 불러오는 방식입니다. Anthropic은 스킬을 쓰면 대화마다 같은 안내를 반복하지 않아도 된다고 설명합니다²¹. OpenAI도 같은 공개 표준을 따르는 스킬을 지원합니다²³.

평가. 프롬프트를 고쳤다면 같은 사례로 다시 확인해야 합니다. Anthropic은 실제 실패 사례에서 뽑은 과제 20~50개면 시작하기에 충분하다고 안내합니다¹⁶. OpenAI는 실패 유형을 분류하고, 원인이 된 지시나 충돌 지점을 찾아 그 부분만 고친 뒤, 같은 사례로 다시 실행하라고 권합니다¹.

관리 방식도 바뀌고 있습니다. OpenAI는 저장형 프롬프트 API(v1/prompts)를 2026년 11월 30일에 종료한다고 공지하며, 프롬프트를 애플리케이션 코드처럼 관리하라고 권합니다²⁰. 같은 날 자체 평가 플랫폼도 종료할 예정입니다²⁴. 프롬프트를 저장소에서 버전 관리하고, 바꿀 때마다 평가를 돌리는 방식이 표준이 되고 있습니다.

자주 묻는 질문

예전에 만든 프롬프트는 모두 다시 써야 하나요?

모두 다시 쓸 필요는 없습니다. 먼저 대표적인 사례 몇 개로 지금 프롬프트의 결과를 확인하고, 문제가 보이는 부분부터 고칩니다. 대문자 강조, 반복된 지시, "단계별로 생각해" 같은 문구는 우선적으로 정리할 대상입니다. OpenAI는 정상 동작하던 프롬프트를 한 번에 전면 수정하지 말라고 권합니다¹.

세 모델에 같은 프롬프트를 써도 되나요?

목표, 맥락, 출력 형식, 제약 조건을 갖춘 프롬프트라면 어느 모델에서나 기본적인 결과는 나옵니다. 다만 구조화 방식, 예시 개수, 긴 자료의 배치는 회사마다 권장 사항이 달라, 자주 쓰는 프롬프트는 모델에 맞게 조정하는 편이 좋습니다.

추론 수준은 항상 가장 높게 두는 것이 좋은가요?

그렇지 않습니다. 추론 수준을 높이면 비용과 응답 시간이 늘어납니다. OpenAI는 높은 단계는 평가에서 의미 있는 개선이 확인될 때만 쓰라고 권합니다¹. 먼저 프롬프트에 빠진 정보가 없는지 확인하고, 난도가 높은 작업에만 단계를 올립니다.

개발자를 위한 심화

API로 모델을 호출할 때 쓰는 설정값을 모았습니다. 지원 값은 모델마다 다르므로 모델별 문서를 함께 확인합니다.

캐싱은 세 회사 모두 프롬프트의 앞부분이 같아야 적용됩니다. 도구 정의, 시스템 프롬프트, 예시처럼 바뀌지 않는 내용을 앞에 두고, 요청마다 달라지는 자료는 뒤에 둡니다¹⁷¹⁸¹⁹. 세 회사 모두 출력 형식을 강제하는 수단으로 JSON 스키마를 지정하는 구조화 출력 기능을 제공합니다. OpenAI는 이 기능을 쓰면 형식을 맞추려고 강한 표현을 쓸 필요가 없다고 설명합니다²⁹.

글쓴이 박수현(젠아이랩스 대표) with AI (Claude Opus 5.5). 모델 이름과 권장 사항은 2026년 10월 2일 각 회사 공식 문서 기준입니다. AI 실무서로는 『바이브 코딩의 시대, 프롬프트를 넘어 컨텍스트 엔지니어링으로』 등 네 권을 썼습니다.