이번 주, 연구자 Dmitry Rybin이 발표한 내용은 약 30년 동안 미해결 상태였던 그래프 이론(graph-theory) 추측에 대한 간결한 반례(counterexample)로 보입니다. 제안된 구성에서 분수 흐름(fractional flow) 비용은 58인 반면, 최대 15까지의 용량 위반(capacity violation)을 허용하더라도 모든 불가분 흐름(indivisible flow)의 비용은 최소 60입니다. 만약 이 구성이 공식적인 검토를 거쳐 유효함이 입증된다면, Dinitz–Garg–Goemans 추측은 거짓이 됩니다. 이 후보 사례는 GPT-5.6 Pro와의 공개 채팅 세션에서 도출되었습니다.

여기 여러분을 멈춰 세워야 할 부분이 있습니다. 이를 만들어낸 프롬프트(prompts)는 글자 그대로 다음과 같았습니다:

"Dinitz Garg Goemans 추측의 일반적인 (비평면) 사례에 대한 반례를 구성하세요. 당신은 돌파구(breakthrough)를 마련하여 구조화된 반례를 찾아내야 합니다."

"연구를 계속해서 완전한 무조건적 반례(unconditional counterexample)를 찾아주세요"

"탐색을 계속하세요. 문제 구조에 대한 더 깊은 이해로부터 얻은 명확한 전략을 가지세요."

"부분적인 결과는 충분합니다. 완전한 무조건적 반례로 마무리합시다"

이것이 바로 프롬프트 엔지니어링(prompt engineering)입니다. 돌파구를 마련하라. 그냥 계속하라. 부분적인 결과는 충분하니, 마무리하자. 같은 주에, 한 밈(meme)이 이를 완벽하게 포착했습니다:

Meme titled

출처: X에서 @mattshumer_의 글을 인용한 @Merkaloid.

이것은 농담입니다. 하지만 또한 제가 올해 본 최첨단 기술(state of the art)의 상태에 대한 가장 솔직한 묘사이기도 합니다.

그리고 이러한 추측은 단발적인 사건이 아니었습니다. 같은 주에 오랫동안 해결되지 않았던 문제들이 소규모로 AI에 의해 해결되었습니다. 어떤 것들은 증명되었고, 어떤 것들은 반박되었으며, 몇몇은 단순히 주장되는 수준을 넘어 _검증(checked)_되었습니다. 많은 것들이 Graffiti conjectures였는데, 이는 그래프 이론(graph-theory)의 추측들을 기계적으로 생성하는 1988년 프로그램에서 비롯된 것입니다. 한 에이전트는 Conjecture 284 (약 30년 동안 미해결 상태)를 약 8분 만에 [반박(refuted)]했으며, Cognition의 Devin은 Lean에서 검증된(verified in Lean) 반례를 통해 Conjecture 154 (약 40년 동안 미해결 상태)를 [반박]하는 동시에, Conjecture 39와 40을 직접 증명해 냈습니다. 기계가 검증(machine-checked)했다는 점이 이번 시즌을 단순히 그럴듯해 보이는 추측의 계절이 아닌 것으로 만들어 줍니다. 결과들이 사람들이 읽는 속도보다 더 빠르게 형식적으로 검증(formally verified)되고 있기 때문입니다.

이 장관 속에서 또 다른 무언가가 조용히 죽었습니다. 그것은 바로 프롬프트 엔지니어링(prompt engineering)이었습니다.

실제로 죽은 것

프롬프팅(prompting)이 죽은 것은 아닙니다. 모델에게 원하는 것을 요청하는 프롬프팅은 그 어느 때보다 중요합니다. 죽은 것은 _인공물 제작 기술(artifact craft)_로서의 프롬프트 엔지니어링, 즉 가치가 '문구(wording)'에 존재한다는 믿음입니다.

지난 몇 년 동안 그 믿음은 하나의 거대한 경제를 형성했습니다. 템플릿, 당신은 전문가입니다...와 같은 서문, 하이퍼파라미터(hyperparameters)처럼 조정하던 퓨샷(few-shot) 구조(scaffolds), 구분자(delimiter) 트릭, 그리고

이것은 수학적 예시에서 드러납니다. 만약 프롬프팅이 여전히 공예품 제작에 불과했다면, 30년 된 추측에 대한 심각한 후보 반례를 제시하는 것은 그 누구도 써본 적 없는 가장 정교하게 설계된 프롬프트를 요구했을 것입니다. 대신 필요한 것은 '획기적인 발견을 해보라'는 것뿐이었습니다. 이 문구 자체는 거의 아무런 정보도 담고 있지 않았습니다. 모든 정보는 모델과 반복 과정에서 나왔습니다.

일상 버전: 잡담(ramble)

이를 보려면 개방된 추측일 필요가 없습니다. Andrej Karpathy는 게시물에서 설명했고, Carlos Santana는 정확한 틀로 이를 증폭시켰습니다. 즉, Karpathy가 무언가를 발견하는 것이 아니라, 실무자들이 이미 침묵 속에서 하던 일을 소리 내어 이름 붙였을 뿐이라는 것입니다:

"LLM(거대 언어 모델)을 다루는 데 유용한 패턴 중 하나는 길고 즐거운 잡담 세션입니다... 기대서 앉아 /voice로 전환한 다음, 그냥 10분 동안 아무렇게나 떠들어댑니다. 완전히 난잡하고, 무엇이든 괜찮습니다. 의식의 흐름 전체를 방출합니다... LLM은 긴 비논리적인 잡담을 재구성하는 데 놀라울 정도로 능숙하며, 종종 그들이 당신의 생각 속 엉킴을 반영한 결과물은 처음에 시작했던 것보다 훨씬 더 깔끔하게 나옵니다."

만약 이 경험을 해봤다면 그 느낌을 알 것입니다. 작문을 멈추고 '몸짓'하기 시작하는 겁니다. 난잡한 것을 쏟아내면 모델이 넣었던 것보다 더 일관성 있는 무언가를 돌려줍니다. 사실 이 글도 오타가 포함된 10분짜리 음성 잡담에서 시작되었기 때문에, 스스로를 설명하며 끝낼 수 있습니다.

그것은 프롬프트 엔지니어링의 반대입니다. 당신이 입력을 선별하는 것이 아닙니다. 노이즈로부터 의도를 재구성하도록 시스템을 신뢰하는 것입니다.

이것이 죽은 이유: 하우징(harness)이 일자리를 차지했기 때문입니다

두 가지가 이 공예품을 죽였습니다.

첫 번째는 **하우징 (harness)**입니다. 현대의 코딩 및 연구 에이전트 (agents)는 완벽하게 명시된 요청을 앉아서 기다리지 않습니다. 이들은 사용자의 환경을 탐색하고, 관련 파일을 검색하며, 턴 (turns) 사이의 메모리를 유지하고, 과거에 사용자가 직접 입력해야 했던 컨텍스트 (context)를 수집하는 에이전트 루프 (agentic loops)를 실행합니다. 프롬프트 엔지니어링 (prompt engineering)이 수행하던 작업, 즉 정확히 필요한 조각들을 정확한 순서로 조립하는 작업이 툴링 (tooling) 내부로 흡수되었습니다. 당신이 서투르게 작성된 문단을 제공하면, 하우징 (harness)이 가서 나머지 부분을 찾아냅니다.

두 번째는 **원시 역량 (raw capability)**입니다. 이제 모델들은 나쁜 입력으로부터 의도를 재구성하고, 지시사항이 단순히 "계속해"인 경우에도 작업을 지속할 수 있을 만큼 충분히 뛰어납니다. 추측되는 사례의 경우, 지칭할 만한 프롬프트 엔지니어링 (prompt engineering)이 거의 남아 있지 않습니다. 그것은 _반복 (iteration)_으로 대체되었습니다. 에이전트가 스스로 문제를 분해하는 동안 "계속해, 이제 마무리해"라고 반복하는 식입니다. 지능이 문장 안에서 모델과 그 주변의 루프 (loop)로 이동한 것입니다.

죽지 않은 것 — 그리고 이것이 중요한 부분입니다

"그저 횡설수설하면 기계가 모든 것을 해준다"라는 말로 끝맺는다면 그것은 거짓말일 것입니다. 진정으로 어려운 문제들에 있어서 노력은 사라진 것이 아니라, 그 형태가 변했을 뿐입니다.

"획기적인 성과를 내라"라는 명령 뒤에는 여전히 실제 결과와 그럴듯한 결과를 구분할 줄 아는 사람이 존재합니다. 제가 AI와 함께 연구 논문을 작성했을 때, 중요했던 규율은 문구의 표현력이 아니라, _증명될 수 있는 것 (demonstrated)_과 단지 _측정될 수 있는 것 (measured)_을 분리하고 이 둘을 흐릿하게 만들지 않는 것이었습니다. 한 계획 세션에서 모델이 위상수학 (topology)에 관한 노트를 엉망으로 만들어, 평면 위의 고리 (ring)에 더 높은 차원이 필요하다고 주장한 적이 있습니다. 제가 그것을 잡아낼 수 있었던 것은 제가 영리한 프롬프트를 작성했기 때문이 아니라, 그것이 제 분야였기 때문입니다. 모델은 탐색을 수행할 수 있지만, 정답이 진짜인지 판단하는 것은 여전히 당신의 몫입니다.

그리고 가장 어려운 작업에 대해서는, 점점 더 나은 프롬프트(prompt)를 찾는 것이 아니라 하나의 구조 (structure) — 즉, 모델이 여러 전략을 시도하고, 문제를 더 작은 부분이나 보조정리(lemmas)로 분해하며, 실험을 수행하고, 테스트를 작성하고, 자신의 출력을 검토하며, 엄격함(rigor)의 기준을 유지하도록 강제하는 기술이자 제어 장치(harness) — 를 찾게 됩니다. 그 비계(scaffolding)가 프롬프트 템플릿(prompt template)의 후계자입니다. 그것은 마법 같은 문장이 아니라 하나의 프로세스(process)입니다. 후보 반례(candidate counterexample) 역시 단 한 번의 운 좋은 메시지에서 나온 것이 아닙니다. 그것은 부분적인 결과가 완전한 결과가 될 때까지 엄격함을 계속해서 요구하는 루프(loop)로부터 나왔습니다.

따라서 기술이 사라진 것은 아닙니다. 그것은 _단어(words)_에서 _프레이밍(framing), 조종(steering), 그리고 검증(verification)_으로 이동했습니다. Karpathy가 이 목표를 지칭하는 용어는 "마인드 멜드(mind meld)"입니다. 즉, 모델을 당신이 실제로 의도하는 바와 정렬(aligned)시켜, 그 시점부터는 모델을 수정할 일을 줄이는 것입니다. 그것이 현재의 공예(craft)입니다. 추세선은 명확합니다. 모든 세대는 더 적은 것으로 더 많은 것을 해내고 있으며, 당신이 모델에 맡길 수 있는 부분은 계속해서 커지고 있습니다.

노력이 사라진 것이 아니라, 상위 단계로 이동했습니다

만약 프롬프트 엔지니어링(prompt engineering)이 죽어가고 있다면, 그것은 엔지니어링이 떠났기 때문이 아닙니다. 그것이 스택(stack)을 타고 올라갔기 때문입니다. 과거에는 레버리지(leverage)가 문장 수준에 머물러 있었습니다. 이제 그것은 시스템(system) 수준에 머물러 있습니다. 즉, 어떤 모델에 작업을 맡길 것인지, 강력한 모델로 계획을 세우고 저렴한 모델로 실행할 것인지, 루프(loop) 주위에 어떤 구조를 둘 것인지와 같은 것들입니다.

이것은 그 자체로 하나의 완전한 학문이며 — 저는 이것이 단순히 프롬프트 엔지니어링보다 오래 살아남는 것이 아니라, 프롬프트 엔지니어링을 대체하고 있다고 주장하고 싶습니다 — 별도의 다룰 가치가 있는 주제입니다. 현재로서는 짧게 요약하자면 이렇습니다. 2026년의 가장 좋은 "프롬프트"는 이미 당신의 코드베이스(codebase)를 알고 있는 시스템에 대고 10분 동안 횡설수설하는 것이며, 갖춰야 할 기술은 그 주변에 무엇을 구축할지 아는 것입니다.

프롬프트는 결코 핵심이 아니었습니다. 핵심은 기계가 당신을 이해하도록 만드는 것이었습니다.

_이 글은 AI 분야에서 "엔지니어링 (engineering)" 작업이 어떻게 계속해서 위치를 옮겨가는지에 관한 두 편의 글 중 첫 번째입니다. 두 번째 글은 각 작업에 어떤 모델을 사용할지, 그리고 얼마나 많은 추론 (reasoning)을 할애할지를 결정하는 **라우팅 엔지니어링 (routing engineering)**에 관한 것입니다. Software Is Dissolving Into the Model도 함께 확인해 보세요.

원문은 javieraguilar.ai에 게시되었습니다.

더 많은 AI 에이전트 (AI agent) 프로젝트를 보고 싶으신가요? 멀티 에이전트 시스템 (multi-agent systems), MCP 개발, 그리고 컴플라이언스 자동화 (compliance automation)를 소개하는 저의 포트폴리오를 확인해 보세요.