안녕하세요, 닥스훈트입니다.

최근 "최신 모델에서는 프롬프트 엔지니어링 (Prompt Engineering)이 필요 없다"라는 말을 듣기 시작했습니다.

그러던 중, OpenAI가 GPT-5.5를 위해 공개한 프롬프트 가이던스를 읽어보았는데, 그 내용에 조금 충격을 받았습니다.

"Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model’s search space, or lead to overly mechanical answers."

((GPT-5.5 이전의 모델에 사용했던) 오래된 프롬프트 스택의 지시를 모두 이어받지 않도록 하십시오. 기존의 프롬프트는 이전 모델이 궤도를 벗어나지 않도록 절차를 과도하게 상세하게 지정하는 경우가 많습니다. GPT-5.5에서는 그것이 노이즈가 되거나, 모델의 탐색 공간을 좁히거나, 답변이 지나치게 기계적으로 변하게 할 수 있습니다.)

즉, "이전 모델을 위해 공들여 만든 프롬프트는 최신 모델에서는 오히려 노이즈가 된다"는 이야기입니다. 이 내용을 보았을 때, LLM이 유행하기 시작한 시기에 캐치업했던 프롬프트 엔지니어링 기술에 대해 제 자신의 지식을 업데이트할 필요가 있다고 느꼈습니다.

그래서 OpenAI, Anthropic, Google 각각의 공식 문서와 제삼자의 연구 결과를 바탕으로, "무엇이 어떤 요인으로 변했는가", "변하지 않은 것은 무엇인가"를 조사해 보았습니다. 이 기사에서는 그러한 조사 결과를 소개하고자 합니다. 2026년 5월 시점의 조사 내용이며, 향후 LLM이 더욱 진화하면 여기서 소개한 경향이나 베스트 프랙티스 (Best Practice)가 크게 바뀔 가능성이 있습니다.

• Chain-of-Thought ("단계별로 생각해 봐")는 최근의 모델 (≒추론 모델)에서는 불필요하거나 오히려 역효과가 나는 경우가 있다

• "CRITICAL: ~를 반드시 할 것"과 같은 강조 지시는 Anthropic이 공식적으로 폐지를 권장

• GPT-5.5에서도 "과도한 프로세스 지정은 역효과"라는 새로운 가이던스가 나옴

• 단, "무엇을 전달할 것인가 (목표·제약·컨텍스트)"는 변함없이 중요

• 각 사(OpenAI, Anthтиc, Google)의 모델마다 가이던스가 다르므로, 프롬프트를 설계/재검토할 때는 공식 가이던스를 한 번 참조하는 것이 좋다

• Gemini 앱을 사용하는 분은 프롬프트를 짧고 간결하게. Gemini 3는 Gemini 2.x보다 간결한 프롬프트가 권장됨.

• AI 에이전트 개발이나 GitHub Copilot에서 GPT-5.5를 사용하는 분은 절차에 대한 세세한 지정을 줄여본다.

• 1. LLM에 대한 지시 방식이 변해왔다
• 2. 기법별로 보기: 무엇이 변했는가?
• 3. 왜 변했는가: 배경에 있는 두 가지 변화
• 4. 대형 LLM 벤더의 공식 발표를 살펴보기
• 5. 연구로도 뒷받침되고 있다
• 6. 변하지 않는 것은 무엇인가: 컨텍스트 엔지니어링 (Context Engineering)이라는 관점

• 요약

• 참고 문헌

조금 전까지만 해도 LLM에 무언가를 부탁할 때는 "의욕은 있지만 경험이 적은 신입 사원에게 지시하는 이미지"가 통했습니다. 실수하지 않도록 세세하게 절차를 적고, 중요 사항은 재차 강조하며, 출력 포맷도 상세하게 지정한다. 그것이 "좋은 프롬프트"의 조건이었습니다.

하지만 지금은 이러한 방식이 오히려 방해가 되는 장면이 늘고 있습니다.

OpenAI의 프롬프트 엔지니어링 공식 가이드에는 이렇게 적혀 있습니다.

"A reasoning model is like a senior co-worker. You can give them a goal to achieve and trust them to work out the details."

(추론 모델은 시니어 동료와 같다. 달성해야 할 목표를 전달하면 세부 사항은 스스로 해결할 것이다.)

"의욕 있는 신입 사원"에서 "유능한 부하"로——모델에 대해 가져야 할 이미지가 변했다는 것이 지금 일어나고 있는 일의 본질이라고 생각합니다.

다만, 여기서 주의해야 할 점은 "아무것도 지시할 필요가 없어진 것"이 아니라는 점입니다. 변한 것은 "어떻게 할 것인지에 대한 절차를 세세하게 지정하는 것"이 불필요해졌다는 부분입니다. "무엇을 달성하고 싶은지", "어떤 제약이 있는지", "어떤 컨텍스트 (Context)에서 사용하는지"——이러한 요소들은 이전보다 오히려 더 중요해지고 있습니다.

먼저 전체를 조망하기 위해, 변화가 있었던 대표적인 기법들을 표로 정리합니다.

이 표는 "이제 사용해서는 안 된다"는 리스트가 아닙니다. 모델의 종류나 용도에 따라 변화의 정도가 크게 다릅니다. 자세한 내용은 다음 절에서 설명합니다.

툴별 체크포인트

Gemini 앱을 사용하는 분 → 표의 "상세하고 긴 프롬프트 전반" 행에 해당합니다. Gemini 3에서는 Gemini 2.x를 위해 공들여 만든 긴 프롬프트가 역효과를 내는 경우가 있으므로, 짧고 구조화된 지시로의 재검토를 고려해 보세요.

GitHub Copilot이나 AI 에이전트 구축에 GPT-5.5를 사용하는 분 → 표의 "Chain-of-Thought", "세세한 단계 지시" 행이 특히 해당됩니다. 절차를 세세하게 적기보다, 목표와 컨텍스트를 명시적으로 전달하는 것이 정확도를 높이는 경우가 있습니다.

기법이 변한 배경에는 크게 두 가지 구조적인 변화가 있습니다.

2025년 이전, OpenAI의 라인업에는 "생성 모델 (GPT-4o, GPT-4.1)"과 "추론 모델 (o1, o3, o4-mini)"이라는 두 종류가 나란히 있었습니다. 프롬프트 엔지니어링 (Prompt Engineering) 기법도 각각 달랐습니다.

그런데 2026년에 들어서며 우선 이용자 측의 니즈가 변했습니다. 폐지 직전의 생성 모델 (GPT-4o) 선택률은 일일 사용자(Daily User)의 불과 0.1%로, 생성 모델의 수요가 축소되고 있었습니다. 이러한 수요 구조의 변화에 따라 추론 모델이 표준으로 제공되기 시작했습니다. 또한, 이러한 생성 모델 (GPT-4o, GPT-4.1)과 추론 모델 (o4-mini)은 2026년 2월에 폐지되었으며, 이후 5월에는 GPT-5.5 Instant (복잡한 프롬프트를 감지하면 자동으로 추론 모드로 전환되는 범용 모델)가 기본(Standard Model)이 되었습니다.

즉, "내부에서 추론할 수 없는 모델"이라는 선택지가 사용자들의 손에서 거의 사라진 것입니다.

o1, o3 등의 추론 모델은 강화학습 (RL)을 통해 "내부에서 Chain-of-Thought (단계별로 생각하기)를 실행하도록" 훈련되어 있습니다. 외부에서 다시 한번 "Chain-of-Thought (단계별로 생각하세요)"라고 지시하는 것은, 모델이 이미 내부에서 수행하고 있는 일을 이중으로 요구하게 되어, 충돌하거나 간섭할 가능성이 있습니다.

또한, GPT-5.5는 응답을 생성하기 전에 내부 추론 토큰을 사용하여, o1이나 o3보다 더욱 고도화된 에이전트로서의 사고 (계획 수립, 대안 검토, 모호함 해소, 도구의 효과적 활용 등)를 자율적으로 수행합니다. 이러한 메커니즘이 있기 때문에, "먼저 A를 하고, 그다음에 B를 확인하고..."와 같은 절차 기술형 프롬프트가 방해가 되는 것입니다.

여담: MoE가 역할 지정(Role Specification)을 불필요하게 만든 것 아닐까?

"최근 LLM에서 역할 지정이 불필요해지고 있다"는 소문을 들었을 때, 저는 그 이유가 "MoE (Mixture of Experts)가 보급되었기 때문이 아닐까?"라고 생각했습니다.

MoE (Mixture of Experts)란 하나의 모델 내부에 라우터(Router)와 여러 개의 '전문가(Expert) 네트워크'를 갖추는 설계입니다. 라우터가 질문을 받으면 내용에 따라 적절한 전문가에게 처리를 맡김으로써 효율적으로 동작하는 구조입니다. 이를 알게 되었을 때, 저는 "의사로서 답변해 주세요"라고 말하면 의료 계열의 전문가가 선택되어 의료계의 입장에서 답변 생성이 이루어지는—과 같은 이미지를 떠올렸습니다. 그렇다면 "모델이 스스로 전문가를 선택해 주는 것이 영향을 미쳐, 역할 지정(Role specification)이 불필요해진 것이 아닐까"라고 추측했습니다.

하지만 MoE에 대해 조사해 보니, 이 가설은 틀렸습니다.

2026년 4월에 발표된 논문 「The Myth of Expert Specialization in MoEs」에 따르면, MoE의 라우터는 "의사"나 "코딩 전문가"와 같은 역할로 전문가를 배분하는 것이 아닙니다. 실제로는 입력된 정보의 수학적 특징의 유사성에 따라 기계적으로 선택할 뿐, "의료 계열의 전문가로서 답변하는 기능이 있는" 것은 아니었습니다. 같은 단어라도 문맥이 바뀌면 선택되는 전문가가 달라지는 듯했습니다.

또한, 역할 지정이 불필요해지고 있다는 소문에 대해서도 조사해 보았으나, 이를 뒷받침할 만한 증거는 발견되지 않았습니다.

각 사(OpenAI, Anthropic, Google)의 공식 발표나 가이드를 비교해 보면, 권장되는 프롬프트(Prompt)에 대한 사고방식은 회사나 모델마다 상당히 다르다는 것을 알 수 있습니다.

OpenAI는 추론 모델을 위해 Chain-of-Thought (CoT) 프롬프트에 대해 명확하게 언급하고 있습니다.

"Avoid chain-of-thought prompts: Since these models perform reasoning internally, prompting them to 'think step by step' or 'explain your reasoning' is unnecessary."

(Chain-of-Thought를 유도하는 프롬프트는 피하십시오. 이 모델들은 내부적으로 추론을 수행하므로, '단계별로 생각하라'거나 '추론 과정을 설명하라'고 유도할 필요가 없습니다.)

나아가 GPT-5.5를 위한 새로운 가이드에서는 이를 GPT 계열 모델로 확장하는 형태로 작성되어 있습니다.

"When you over-specify the route with step-by-step instructions like 'first do A, then check B, then compare C, then output D,' you're constraining the model and forcing a less intelligent path through a problem space the model could navigate better on its own."

("'먼저 A를 하고, 그다음 B를 확인하고, C를 비교한 뒤, 마지막으로 D를 출력하라'와 같이 단계별 지시로 경로를 지나치게 상세히 지정하면, 모델을 제약하게 되어 모델 스스로 더 잘 탐색할 수 있는 문제 공간(Problem space)에서 오히려 덜 지능적인 경로를 강요하게 됩니다.)

요컨대 "절차를 너무 상세히 지정하면, 모델이 본래 잘 탐색할 수 있는 문제 공간에서 굳이 비효율적인 경로를 걷게 만든다"는 이야기입니다.

단, 이것이 모든 세대의 GPT 계열 모델에 적용되는 것은 아닙니다. GPT-4.1과 같은 구형 GPT 계열은 "태스크를 어떻게 실행할지에 대해 더 명시적인 지시가 있으면 성능이 향상된다"라고 여전히 기술되어 있습니다. 따라서 사용 중인 모델을 확인하는 것이 중요합니다.

Anthropic의 견해에서 특징적인 점은, "프롬프트 엔지니어링이 불필요하다"는 이야기가 아니라, "이전 모델을 위해 추가했던 불필요한 지시나 회피책(Workarounds)을 삭제하라"는 메시지가 전면에 나와 있다는 점입니다.

Claude Opus 4.7의 이행 가이드에는 다음과 같은 기술이 있습니다.

"Claude Opus 4.5와 Claude Opus 4.6 또한 이전 모델들보다 시스템 프롬프트 (System Prompt)에 더 민감하게 반응합니다. 만약 당신의 프롬프트가 도구(Tool)나 기술(Skill)의 호출 부족(Undertriggering)을 줄이기 위해 설계되었다면, 이 모델들은 이제 과도하게 호출(Overtriggering)할 수 있습니다. 해결 방법은 공격적인 언어 사용을 줄이는 것입니다. 이전에는 'CRITICAL: 반드시 이 도구를 사용해야 함...'이라고 말했을 부분에, '이 도구를 사용하세요...'와 같이 더 일반적인 프롬프팅을 사용할 수 있습니다."

(Claude Opus 4.5와 Claude Opus 4.6은 이전 모델보다 시스템 프롬프트에 대한 반응성이 높습니다. 만약 당신의 프롬프트가 도구(Tool)나 기술(Skill)의 호출 부족을 줄이기 위해 설계되었다면, 이 모델들은 이제 과도하게 호출할 수 있습니다. 해결 방법은 강한 표현을 완화하는 것입니다. 예를 들어 이전에는 "CRITICAL: 이 도구는 반드시 사용해야 합니다"라고 작성했던 상황에서도, 지금은 "이 경우에는 이 도구를 사용해 주세요" 정도의 일반적인 작성 방식만으로도 충분합니다.)

「CRITICAL」이나 「MUST」와 같은 강조 표현은 이전 모델이 지시를 따르지 않는 상황에 대한 대처책이었습니다. 현재 모델은 시스템 프롬프트에 대한 감응성이 높아졌기 때문에, 동일한 방식을 사용하면 도구가 과도하게 호출되는 등 예기치 않은 동작으로 이어질 수 있습니다.

삭제해야 할 오래된 프롬프트 요소로서, 이행 가이드는 다음과 같은 예시를 들고 있습니다.

• "3번의 도구 호출마다 진행 상황을 요약하라"와 같은 중간 상태의 강제
• "망설여지면 도구를 사용하라"는 모호한 지시 (과도한 트리거의 원인)
• CoT (Chain of Thought) 방식의 강제 지시 (모델이 자발적으로 수행하므로 불필요)

나아가, Claude 4.6 이후부터는 어시스턴트 턴(Assistant turn)의 프리필(Prefill, 어시스턴트 답변의 시작 부분을 미리 지정하는 기능)이 폐지되었습니다. 이유는 "모델의 지시 이행 능력이 향상되어 대부분의 유스케이스에서 더 이상 프리필이 필요하지 않기 때문"입니다. Claude Opus 4.7 이후부터는 temperature 파라미터도 폐지되어, 창의성(Creativity)의 동작 제어는 프롬프트로 수행하도록 설계되어 있습니다.

Google은 3사 중에서도 가장 "프롬프트 엔지니어링은 여전히 중요하다"는 입장을 취하고 있습니다. 공식 문서에는 "2026년에도 프롬프트 엔지니어링은 AI 활용을 최적화하기 위한 필수 기술로 남아 있을 것"이라고 명시되어 있으며, 퓨샷 프롬프팅 (Few-shot Prompting, 예시를 몇 개 포함하는 방식)에 대해서는 "항상 프롬프트에 포함할 것을 권장한다"고 밝히고 있습니다.

다만, Gemini 3에서는 변화가 나타나고 있습니다. Gemini 2.x를 위해 정교하게 만들어진 긴 프롬프트가 역효과를 내는 경우입니다.

"Gemini 3는 Gemini 2.x보다 짧고 직접적인 지시를 훨씬 더 잘 따르며, 만약 Gemini 2.x를 궤도에 유지시키기 위해 긴 프롬프트를 구축했다면, 동일한 프롬프트가 이제는 내용이 불필요하게 비대해진(Bloated) 답변을 생성할 수 있습니다."

(Gemini 3는 Gemini 2.x보다 짧고 직접적인 지시에 훨씬 더 잘 따릅니다. 따라서 Gemini 2.x를 궤도에 유지시키기 위해 긴 프롬프트를 만들었다면, 동일한 프롬프트가 이번에는 장황한 답변을 낳을 수 있습니다.)

「Structure beats length (길이보다 구조가 중요하다)」라는 원칙이 강조되고 있으며, 양보다 질과 구조화라는 방향성은 타사와 동일합니다.

또한, 싱킹 모드 (Thinking mode, Gemini 2.5/3 시리즈의 내부 추론 기능)에 대해서도 CoT 지시와의 충돌에 주의가 필요합니다. 싱킹 모드가 활성화되어 있을 때 외부에서 CoT를 지시하더라도, 모델은 이미 내부적으로 이를 수행하고 있기 때문에 효과가 미미합니다.

3사의 발표를 나열하면 다음과 같이 정리할 수 있습니다.

각사의 공식 견해와 더불어, 제3자의 연구에서도 동일한 방향의 변화가 확인되고 있습니다.

Wharton GAIL이 2025년 6월에 발표한 기술 보고서는 PhD 수준의 난제 198문항 (GPQA Diamond)을 사용하여, CoT 프롬프트의 효과를 모델별로 측정했습니다.

비추론 모델에서는 일정 수준의 효과 (10% 이상의 정확도 향상)가 확인되었습니다 (Gemini Flash 2.0: +13.5%, Claude Sonnet 3.5: +11.7%). 반면, 추론 모델에서는 이야기가 달라집니다.

추론 모델에서는 정확도 향상이 미미하거나, 반대로 정확도가 약간 떨어지는 현상이 나타남을 알 수 있었습니다. 또한, Gemini Flash 2.5를 더 자세히 살펴보면, 100% 정답률을 기록했던 문제에서는 -13.1%라는 큰 하락도 확인되었습니다.

또한 비용 관점에서도, CoT 지시로 인해 추론 시간이 35~600% 증가한다고 보고되었습니다. 이를 통해 추론 모델에서 CoT로 지시하는 것은 추론 시간이 늘어날 뿐만 아니라 정확도도 크게 향상되지 않는, 가성비가 낮은 지시라는 점을 알 수 있습니다.

2025년 10월에 공개된 논문 「You Don't Need Prompt Engineering Anymore: The Prompting Inversion」(Imran Khan, arXiv:2510.22251)은 GPT-4o와 GPT-5를 대상으로 상세 프롬프트와 표준 프롬프트를 비교하는 실험을 진행했습니다.

GPT-4o에서는 상세 프롬프트가 유리했던 반면, GPT-5에서는 역전되었습니다. 논문은 이 현상을 「guardrail handcuff transfer (가드레일에서 수갑으로)」라고 명명했습니다.

"constraints preventing common-sense errors in mid-tier models induce hyper-literalism in advanced models"

(중위 클래스 모델에서 상식적인 실수를 방지하기 위해 설정한 제약이, 고도화된 모델에서는 과도하게 문자 그대로 해석하는 행동을 유발한다.)

중급 모델 (성능이 아주 높지 않은 모델)에서의 이탈을 방지하기 위해 설정한 가드레일 (지시의 제약)이, 고도화된 모델에서는 오히려 수갑 (족쇄)이 되어버린다는 지적입니다.

지금까지의 내용을 바탕으로 하면 "그럼 이제 프롬프트는 아무런 고민 없이 써도 되는 걸까?"라는 의문이 생길 수 있지만, 그렇지 않은 것 같습니다.

불필요해지고 있는 것은 "모델에게 어떤 프로세스로 생각할지를 지정하는 것"이며, 반대로 필요해지고 있는 것은 "목표·제약·컨텍스트를 명확하게 전달하는 것"입니다.

이 맥락에서 최근 주목받고 있는 것이 「컨텍스트 엔지니어링 (Context Engineering)」이라는 개념입니다. 2025년 6월에 Andrej Karpathy (전 OpenAI)가 X에 게시한 정의가 널리 퍼졌으며, 이후 Anthropic과 Google도 이를 채택하고 있습니다.

"the delicate art and science of filling the context window with just the right information for the next step"

(컨텍스트 윈도우에 다음 단계를 위한 적절한 정보를 채워 넣는 섬세한 기술과 과학)

컨텍스트 엔지니어링과 프롬프트 엔지니어링의 차이를 정리하면 다음과 같습니다.

변화된 부분:

• Chain-of-Thought (CoT) 지시("단계별로 생각하세요")는 추론 모델(Reasoning Model)에서는 불필요하거나 오히려 역효과를 내는 경우가 있음
• "CRITICAL", "MUST"와 같은 강조 표현은 최신 Claude 모델에서 과도한 트리거(Trigger)의 원인이 됨
• GPT-5.5에서도 "과도한 프로세스 지정은 탐색 공간(Search Space)을 좁힌다"라는 새로운 가이드라인이 나옴
• 이전 Claude 모델에 대한 대응책으로 추가했던 scaffolding (CoT 강제, 진행 상황 보고 강제, prefill 등)은 현재 모델에서는 삭제가 권장됨
• 출력 포맷 지정은 API 레벨의 Structured Outputs 기능으로 대체할 수 있는 경우가 늘어남

변하지 않는 부분:

• 목표, 성공 기준, 제약 조건, 사용 가능한 컨텍스트(Context)를 명확하게 전달하는 것은 오히려 더욱 중요해짐
• 모델에 따라 최적의 프롬프트 작성 방식은 여전히 다름 (GPT-5.5 vs Gemini vs Claude)
• few-shot 프롬프트는 대상 모델에 따라 계속해서 유효함 (Anthropic은 권장 사항을 유지 중)

지금 바로 시도해 볼 수 있는 것:

Gemini 앱을 사용하는 경우 → Gemini 3에서는 Gemini 2.x용으로 정교하게 만든 긴 프롬프트가 역효과를 내는 경우가 있으므로, 짧고 구조화된 지시로의 재검토를 고려해 보세요. -
GitHub Copilot이나 AI 에이전트 구축에서 GPT-5.5를 사용하는 경우 → 절차를 세세하게 적는 것보다, 목표와 컨텍스트를 명시적으로 전달하는 것이 정확도를 높일 수 있습니다.

"프롬프트 엔지니어링은 이제 필요 없다"라는 말은 절반은 맞고 절반은 오해입니다. 불필요해진 것은 "모델의 사고 프로세스를 절차를 적듯 제어하는 것"이며, 무엇을 달성하고 싶은지, 어떤 제약이 있는지를 명확하게 전달하는 것은 변함없이 중요합니다.

또한, 같은 "추론 모델"이라 하더라도 각 회사의 입장에는 온도 차가 있습니다. 현재 사용 중인 모델의 공식 문서를 한 번 확인해 보는 것이 가장 확실한 지름길입니다.

GPT-5.5를 사용한다면 → OpenAI Prompt guidance -
Claude를 사용한다면 → Anthropic Prompting Best Practices ／ Migration Guide -
Gemini를 사용한다면 → Gemini Prompt design strategies

각 회사 모두 최신 모델에 맞춰 가이드를 업데이트하고 있습니다. 이전에 만든 프롬프트를 그대로 유용하고 있다면, 공식 가이드와 대조해 보았을 때 "이 부분은 이제 삭제해도 된다"라는 것을 의외로 쉽게 발견할 수 있습니다.

똑똑한 부하 직원에게 지시하는 것과 마찬가지로, 모든 절차를 다 적지 않아도 목표와 배경을 전달하면 움직여 주는—그런 모델이 표준이 되어 왔습니다. 프롬프트가 불필요해진 것이 아니라, 프롬프트로 무엇을 지시해야 하는지가 변해온 것이 지금의 상황이라고 생각합니다.

• GPT-5.5 소개 | OpenAI
• 프롬프트 가이드 (Prompt guidance) | OpenAI API — GPT-5.5를 위한 새로운 프롬프트 가이드
• 추론 모범 사례 (Reasoning best practices) | OpenAI API — 추론 모델을 위한 CoT(Chain of Thought) 불필요에 관한 공식 견해
• ChatGPT에서 GPT-4o, GPT-4.1, GPT-4.1 mini 및 OpenAI o4-mini 서비스 종료 | OpenAI
• Anthropic 프롬프팅 모범 사례 (Anthropic Prompting Best Practices) — Claude Opus 4.8을 위한 가이드
• Anthropic 마이그레이션 가이드 (Anthropic Migration Guide) — Claude Opus 4.7/4.8 이전 가이드
• 프롬프트 설계 전략 (Prompt design strategies) | Gemini API | Google AI for Developers
• Gemini 3 프롬프팅 가이드 (Gemini 3 prompting guide) | Gemini Enterprise Agent Platform
• Wharton GAIL — CoT 보고서 — GPQA Diamond 198문항에서의 CoT 효과 측정 (2025년 6월)
• 당신은 더 이상 프롬프트 엔지니어링이 필요하지 않다: 프롬프트 역전 현상 (You Don't Need Prompt Engineering Anymore: The Prompting Inversion) (arXiv:2510.22251) — GPT-4o와 GPT-5에서의 상세 프롬프트 역전 실험
• MoE의 전문가 특화 신화 (The Myth of Expert Specialization in MoEs) (arXiv:2604.09780) — MoE의 라우팅(Routing)은 도메인이 아닌 기하학적 유사성에 의한 것임을 보여준 논문 (2026년 4월)
• Karpathy의 X (구 Twitter) — 컨텍스트 엔지니어링 (Context Engineering)의 정의
• Google Cloud | AI 컨텍스트 엔지니어링 (AI Context Engineering)
• IntuitionLabs — 컨텍스트 엔지니어링 vs 프롬프트 엔지니어링 (Context Engineering vs Prompt Engineering)