모델 경쟁은 끝나지 않았다. 하지만 오늘의 진짜 경쟁장은 “일을 오래 붙잡고 끝내는 운영체계”로 이동했다.

Prologue. 오늘 뉴스들이 가리키는 하나의 장면

AI 산업은 한동안 “더 큰 모델, 더 높은 benchmark, 더 긴 context window”라는 방향으로 설명되었다. 그 흐름은 여전히 중요하다. OpenAI의 GPT-5.6 발표도 더 나은 reasoning, coding, browsing, computer use, performance per dollar를 전면에 둔다. Meta의 Muse Spark 1.1도 100만 토큰 context window, multi-agent orchestration, computer use, coding workload를 강조한다. 표면의 언어는 성능 경쟁이다.

그러나 같은 날 주변에서 나온 소식들을 함께 읽으면, 성능 경쟁의 의미가 달라진다. Google의 Managed Agents는 “오래 걸리는 일을 HTTP 연결 하나에 매달아 두지 말고 서버에서 background로 실행하고 나중에 다시 연결하라”고 말한다. Hugging Face/NVIDIA의 Data for Agents는 “agent behavior는 모델 가중치만으로 설명되지 않으며, tool-use failures, workflow execution, synthetic data, evaluation methods를 공개적으로 다뤄야 한다”고 말한다. OpenAI의 SWE-Bench Pro 감사 글은 “벤치마크가 깨져 있으면 모델 성능에 대한 의사결정도 깨진다”고 경고한다.

즉 오늘의 장면은 하나다. AI는 이제 단일 답변을 생성하는 엔진이 아니라, 일의 lifecycle을 통제하는 runtime이 되고 있다. 질문을 받아 답하는 단계는 시작일 뿐이고, 그 뒤에는 파일을 읽고, 도구를 부르고, 외부 시스템에 연결하고, 실패한 API 호출을 복구하고, 중간 산출물을 버리거나 압축하고, 결과를 평가 기준에 통과시키는 과정이 붙는다. Karpathy식으로 말하면, 소프트웨어가 사람이 직접 짠 규칙에서 neural network로 이동했던 것처럼, 사무와 지식노동의 운영 단위도 문서와 앱에서 agent runtime으로 이동하고 있다.

그래서 오늘의 digest는 “GPT-5.6이 나왔다”가 아니라 “모델 출시, agent API, eval 감사, open data, inference backend가 한꺼번에 같은 방향을 가리켰다”로 읽어야 한다. 그 방향은 모델을 고르는 시대에서, 모델이 일할 환경을 설계하는 시대로의 이동이다.

Chapter 1. prompt box에서 workflow runtime으로: ChatGPT Work와 Managed Agents가 말하는 것

문제 제시 채팅형 AI의 한계는 명확했다. 사용자가 질문하면 답을 주지만, 긴 작업을 몇 시간 동안 기억하고, 중간에 앱을 오가며, 실패한 도구 호출을 복구하고, 사용자가 자리를 비운 동안 계속 진행하는 능력은 별도의 운영 구조가 필요했다. 사람에게 “이 보고서 완성해줘”라고 맡길 때는 한 문장만 던지는 것이 아니라 자료 위치, 승인 규칙, 중간 점검, 제출 형식이 함께 필요하다. AI에게도 같은 것이 필요해졌다.

뉴스 근거 OpenAI는 ChatGPT Work를 “앱과 workflow 전반에서 정보를 모아 sheets, slides, docs, web apps 같은 finished materials를 만들고, 복잡한 project를 hours 동안 붙잡아 작은 단계로 나누어 독립적으로 수행하는 agent”라고 설명했다. Scheduled Tasks로 사용자가 away 상태여도 Teams와 Slack의 새 메시지를 문서나 슬라이드 업데이트로 바꿀 수 있다고도 했다. 같은 흐름에서 Google은 Gemini API의 Managed Agents에 배경 실행(background execution)을 넣었다. 오래 걸리는 agent interaction을 서버에서 비동기로 실행하고, client는 ID로 상태를 poll하거나 나중에 reconnect할 수 있게 하는 방식이다. 또한 원격 MCP 서버(remote Model Context Protocol server)를 통해 private database나 internal API와 연결할 수 있다고 설명한다.

하부 원리 여기서 중요한 용어는 런타임(runtime)이다. 런타임은 프로그램이 실제로 실행되는 무대다. 배우가 아무리 뛰어나도 무대 조명, 대본, 출입문, 음향, 안전요원이 없으면 공연은 망가진다. AI 모델도 마찬가지다. 모델은 생각하고 문장을 만들지만, 긴 작업을 안전하게 끝내려면 실행 상태를 저장하는 장치, 도구 접근권(access), 실패 복구, 사용자 승인 흐름, 로그와 평가가 필요하다. Managed Agents와 ChatGPT Work는 이 무대를 제품 안으로 끌어들이는 움직임이다.

비개발자용 직관적 모델링 예전의 prompt box는 카운터 창구와 비슷했다. 종이에 질문을 써서 내면 답변지를 받는다. 오늘의 workflow runtime은 출장 비서팀에 가깝다. 팀이 회사 시스템에 접속하고, 파일을 찾아보고, 시간이 걸리는 조사를 백그라운드에서 계속하고, 중간 결과를 보고하고, 필요하면 결재를 요청한다. 중요한 변화는 “똑똑한 답”이 아니라 “일을 놓지 않는 구조”다.

사용자 질문/실행 사용자님의 Hermes Agent + Telegram workflow는 이미 이 방향의 개인용 축소판이다. 질문은 Telegram에서 오지만, 실제 결과는 파일 생성, browser verification, skills, wiki separation, HTML artifact로 이어진다. 오늘의 질문은 “새 ChatGPT Work를 써볼까?”보다 먼저 “내 Hermes 작업도 background task, source extraction, output verification, wiki promotion gate가 충분히 분리되어 있는가?”이다. 즉 신제품 체험보다 중요한 것은 내 agent workflow가 오래 걸리는 일을 어디까지 안전하게 맡을 수 있는가를 점검하는 일이다.

Chapter 2. benchmark는 점수표가 아니라 안전장치다: SWE-Bench Pro 감사의 의미

문제 제시 AI 모델 뉴스에서 benchmark는 시험 점수처럼 쓰인다. 80점 모델이 65점 모델보다 좋아 보인다. 그러나 학교 시험도 문제가 잘못 출제되면 점수가 학생의 실력을 보여주지 않는다. AI에서는 이 문제가 더 크다. 모델 배포, 안전성 판단, 비용 예산, provider 선택이 모두 benchmark 숫자에 기대기 때문이다.

뉴스 근거 OpenAI는 SWE-Bench Pro를 감사한 결과, datapoint analysis pipeline이 731개 public split 중 200개(27.4%)의 broken tasks를 flag했고, human annotation campaign은 249개(34.1%)를 문제로 식별했다고 밝혔다. 문제 유형은 overly strict tests, underspecified prompts, low-coverage tests, misleading prompt였다. 이 글은 외부 benchmark가 hard하지만 fair해야 하며, 결함 있는 평가가 capability와 safety case를 왜곡할 수 있다고 말한다.

하부 원리 평가 기준(eval)은 AI에게 시험지를 주는 일에 가깝다. 하지만 단순히 정답 하나를 맞히는 시험이 아니다. agent에게는 출처를 구분했는지, 도구를 올바르게 불렀는지, 실패했을 때 복구했는지, 숨은 조건을 과장하지 않았는지, 결과물이 실제로 실행되는지까지 봐야 한다. 그래서 eval은 점수표라기보다 “이 AI에게 일을 맡겨도 되는가”를 확인하는 안전장치다. 평가 출처성(eval provenance)은 그 시험지가 어디서 왔고, 어떤 결함 가능성이 있으며, 어떤 작업에는 맞고 어떤 작업에는 안 맞는지를 추적하는 태도다.

비개발자용 직관적 모델링 식당을 고를 때 별점만 보면 실패할 수 있다. 어떤 별점은 배달 속도만 반영하고, 어떤 별점은 음식 맛보다 포장 상태에 민감하며, 어떤 리뷰는 광고일 수 있다. 그래서 좋은 소비자는 별점과 함께 리뷰의 맥락을 본다. AI benchmark도 같다. 숫자는 시작점일 뿐이고, 그 숫자가 어떤 업무를 얼마나 공정하게 대표하는지 확인해야 한다.

사용자 질문/실행 사용자님의 Link-to-Book HTML, YouTube-to-Book HTML, ai-news insight cron도 작은 eval이 필요하다. “HTML이 생성되었는가”만 보면 부족하다. 출처가 실제로 열렸는가, 본문과 해석이 분리되었는가, reader controls가 작동하는가, 위키를 자동 수정하지 않았는가, 사용자 맥락 실행 설계가 들어갔는가를 봐야 한다. 오늘 뉴스는 개인 LLM Wiki 운영에서도 eval provenance를 문서화하는 습관이 중요하다는 신호다.

Chapter 3. open-weight 다음은 open-data와 open-harness다: 에이전트는 가중치만으로 설명되지 않는다

문제 제시 오픈소스 AI 논의는 오래도록 open-weight, 즉 모델 가중치가 공개되었는가에 집중했다. 가중치는 모델의 배운 패턴이 저장된 거대한 숫자 묶음이다. 그러나 agent가 실제 도구를 쓰고 workflow를 실행하는 시대에는 “가중치만 공개되었는가”로 충분하지 않다. 왜 어떤 도구 호출은 성공하고, 어떤 실패는 복구하며, 어떤 상황에서는 위험한 행동을 피하는지 설명하려면 데이터와 실행 환경까지 봐야 한다.

뉴스 근거 Hugging Face에 올라온 NVIDIA의 “Data for Agents” 글은 agentic AI가 open data를 필요로 하며, synthetic data가 그 확장 방법이라고 설명한다. 글은 tool-use failures, multi-step reasoning, retrieval, safety, user simulation, workflow execution 같은 데이터가 중요하다고 말하고, agent behavior는 datasets, curation choices, training recipes, evaluation methods에 의존한다고 강조한다. NVIDIA의 Nemotron/LangChain 글도 비슷한 방향이다. LangChain Deep Agents harness를 Nemotron 3 Ultra에 맞게 조정했더니 모델 재훈련 없이 prompt, tool descriptions, middleware 같은 harness engineering만으로 성능과 비용이 개선되었다고 설명한다.

하부 원리 하네스(harness)는 말을 다루는 마구처럼, 모델의 힘을 실제 작업에 연결하는 장치다. system prompt, tool schema, memory, middleware, evaluation loop, secure runtime이 모두 harness에 속한다. 자동차 엔진만 좋다고 차가 안전한 것이 아니다. 브레이크, 변속기, 계기판, 도로 규칙이 함께 있어야 한다. AI agent도 모델만으로는 제품이 되지 않는다. 모델을 어떤 데이터로 훈련했는지, 어떤 도구 설명을 줬는지, 실패를 어떻게 기록했는지, 어떤 sandbox에서 실행했는지가 실전 품질을 만든다.

비개발자용 직관적 모델링 요리사를 평가한다고 해보자. 요리사의 재능만 보는 것은 open-weight에 가깝다. 하지만 실제 식당 품질은 재료 공급망, 레시피 노트, 주방 동선, 위생 점검표, 주문 처리 시스템에 달려 있다. open-data와 open-harness는 “이 요리가 어떻게 안정적으로 반복되는가”를 보여주는 레시피와 주방 공개에 가깝다.

사용자 질문/실행 사용자님의 LLM Wiki는 개인용 open-harness의 형태를 띠고 있다. raw/source/wiki/output separation은 데이터 출처를 보존하고, skills는 반복 workflow를 고정하며, evals와 playbooks는 결과 품질을 점검한다. 오늘의 실행 질문은 “새 모델을 하나 더 붙일까?”가 아니라 “내 wiki와 skills가 agent behavior를 설명할 만큼 traceable한가?”이다. 특히 자동 digest는 매일 반복되므로, source reliability와 extraction limit를 HTML 안에 남기는 것이 단순 예의가 아니라 harness 품질이다.

Chapter 4. 가격 경쟁의 진짜 뜻: 모델 라우팅과 대체 경로가 기본 설계가 된다

문제 제시 모델 가격표는 숫자 놀음처럼 보이지만, 실제로는 workflow 설계의 자유도를 결정한다. agent가 길게 일할수록 token, tool call, intermediate trace, retry가 늘어난다. 한 번 답변하는 챗봇에서는 비싼 모델도 감당할 수 있지만, 매일 뉴스 digest를 만들고, 긴 링크를 책처럼 바꾸고, 위키를 검사하고, 브라우저까지 검증하는 agent 운영에서는 비용과 속도가 곧 구조가 된다.

뉴스 근거 OpenAI는 GPT-5.6에서 더 적은 token과 낮은 estimated cost로 long-running agentic performance를 개선했다고 주장했다. Simon Willison은 GPT-5.6의 Luna/Terra/Sol 가격과 100만 token context, 128k output, programmatic tool calling, multi-agent beta를 해설하며, price-per-million token만으로는 reasoning token 차이를 설명하기 어렵다고 지적했다. Meta의 Muse Spark 1.1은 Meta Model API public preview와 함께 agentic tasks, computer use, coding, multi-agent orchestration을 강조했다. The Decoder와 TechCrunch의 RSS는 Meta, OpenAI, Anthropic, xAI 사이의 가격 압박과 enterprise coding battle을 시장 신호로 다뤘다.

하부 원리 모델 라우팅(model routing)은 모든 일을 한 모델에게 맡기지 않고, 작업 성격에 따라 적절한 모델과 provider를 고르는 일이다. 쉬운 분류는 저렴한 모델, 긴 reasoning과 final synthesis는 강한 모델, 브라우저 조작은 computer-use가 좋은 모델, local privacy가 필요한 작업은 로컬/오픈 스택을 쓰는 식이다. 대체 경로(fallback)는 한 provider가 막히거나 품질이 떨어질 때 workflow가 멈추지 않도록 준비한 예비 경로다.

비개발자용 직관적 모델링 배송을 생각하면 쉽다. 모든 물건을 특급 항공 배송으로 보내면 빠르지만 비용이 폭발한다. 모든 물건을 일반 우편으로 보내면 싸지만 중요한 물건이 늦는다. 좋은 물류 시스템은 물건의 중요도, 부피, 마감, 위험도에 따라 배송 수단을 고른다. AI agent 운영도 같은 물류 문제다. 모델은 트럭이고, workflow는 물류망이며, eval은 배송 확인서다.

사용자 질문/실행 사용자님의 Hermes 환경에서는 “최신 모델로 전부 바꾸기”보다 “작업 유형별 routing 기준과 fallback 기준을 wiki에 명확히 두기”가 더 중요하다. 이미 `Model Routing and Fallback Criteria` 문서가 있으므로, 오늘 뉴스는 그 문서의 장기 후보를 보강할 수 있다. 단, 자동으로 위키를 수정하지는 않는다. 며칠 더 가격/품질 패턴이 반복되는지 본 뒤, provider fallback과 eval criteria를 함께 업데이트하는 것이 안전하다.