AI 에이전트 2026, 무엇을 배우고 만들고 건너뛸 것인가

이 칼럼은 Rohit (@rohit4verse)의 글 "What to Learn, Build, and Skip in AI Agents (2026)"을 한국어 분석 칼럼으로 옮긴 글이다. 원문의 모든 주장과 사례, 도구 픽을 보존하면서 PM의 자리에서 다시 조립했다. 원문 링크는 본문 끝에서도 다시 밝힌다.

매주 새 프레임워크가 나온다. 새 벤치마크가 발표되고, 새 "10x" 런치가 떠오른다. 질문은 더 이상 "어떻게 따라갈 것인가"가 아니다. 무엇이 신호이고 무엇이 절박함의 가면을 쓴 노이즈인지를 가르는 일이다. 모든 로드맵은 출시 한 달 뒤 폐기된다. 지난 분기에 마스터한 프레임워크는 지금 레거시다. 최적화한 벤치마크는 게임됐고 다른 것으로 대체됐다.

그런데도 우리는 옛 모델로 일한다. 스택을 잡고, 단계를 밟고, 사다리를 천천히 오른다. AI가 그 캔버스를 다시 그렸다. 적절한 프롬프트와 적절한 안목만 있으면, 2년차 엔지니어가 한 스프린트에 했던 일을 누구나 출고할 수 있다. 전문성은 여전히 중요하다. 새벽 2시에 메모리 누수를 디버깅한 경험, 영리한 선택 대신 보링한 선택을 주장해서 옳았던 경험. 그 안목은 누적된다. 누적이 멈춘 건 이번 주에 출시된 프레임워크의 API 표면을 외우는 일이다. 6개월 후엔 다른 프레임워크가 그 자리에 와 있다. 2년 후 이기는 사람들은 일찍 견고한 프리미티브를 골랐고 나머지는 자기 옆을 지나가게 뒀다.

Rohit은 이 분야에 2년을 썼고 $250k 이상의 오퍼를 여러 번 깼고 지금은 스텔스 회사에서 기술을 책임지고 있다. 본인 표현으로는 "지금 무엇에 주의를 기울여야 하느냐고 묻는 사람에게 보내고 싶은 글"이다. 이건 로드맵이 아니다. 에이전트 분야는 아직 도착지가 없다. 큰 랩들도 공개적으로 반복하면서 수백만 사용자에게 회귀를 출시하고, 포스트모템을 쓰고, 라이브로 패치한다. Claude Code 팀이 47% 성능 회귀를 출시했고 사용자 커뮤니티가 잡기 전에 자기 모니터링이 잡지 못한 분야다. 안정된 지도가 깔려 있다는 생각은 환상이다. 모두가 알아내는 중이다.

신호와 노이즈를 가르는 5가지 질문

주간 런치를 따라갈 수는 없다. 시도하지 않는다. 필요한 건 피드가 아니라 필터다. 지난 18개월 동안 견딘 다섯 개의 테스트가 있다. 자기 스택에 들이기 전에 런치를 이 다섯에 통과시킨다.

첫째, 2년 후에도 의미가 있는가. 프론티어 모델 위의 래퍼이거나 CLI 플래그 하나, "Devin인데 X용"이라면 답은 거의 NO다. 프로토콜·메모리 패턴·샌드박스 같은 프리미티브라면 더 자주 YES다. 래퍼의 반감기는 짧고 프리미티브의 반감기는 연 단위다.

둘째, 형운님이 존경하는 누군가가 그 위에 무언가를 만들고 정직하게 썼는가. 마케팅 포스트는 안 친다. 포스트모템이 신호다. "프로덕션에서 X를 시도했고 무엇이 깨졌다"는 글이 출시 발표 열 개보다 가치 있다. 이 분야의 좋은 신호는 항상 그것에 주말을 잃은 사람이 쓴다.

셋째, 도입하려면 트레이싱·재시도·설정·인증을 다 버려야 하는가. 그렇다면 그것은 플랫폼이 되려는 프레임워크다. 플랫폼이 되려는 프레임워크의 사망률은 90%다. 좋은 프리미티브는 마이그레이션을 강제하지 않고 기존 시스템에 끼워 넣어진다.

넷째, 6개월 건너뛰면 무엇을 잃는가. 대부분의 런치에 답은 "아무것도"다. 6개월 후에는 더 많이 알게 되고, 승자 버전이 더 명확해진다. 출시 90%를 무시할 수 있게 해주는 테스트이고, 사람들이 가장 거부하는 테스트다. 무시하는 게 뒤처지는 것처럼 느껴지기 때문이다. 그렇지 않다.

다섯째, 에이전트에 실제로 도움이 되는지 측정 가능한가. 측정할 수 없으면 추측이다. eval 없는 팀은 vibes로 굴러가다 회귀를 출시한다. eval 있는 팀은 GPT-5.5와 Opus 4.7 중 자기 워크로드에 무엇이 이번 주에 더 잘 맞는지 데이터로 결정한다.

이 글에서 단 하나의 습관만 가져간다면 이것이다. 새로운 것이 출시될 때, 6개월 후에 그것이 의미 있다고 믿으려면 무엇을 보아야 하는지 적어둔다. 그리고 6개월 후 돌아와 확인한다. 대부분의 경우 질문은 스스로 답한다. 그 동안 형운님의 주의력은 누적되는 것에 쓰였다. 이 다섯 테스트 밑에 깔린 더 어려운 능력은, 자기가 들이지 않은 것에 대해 쿨하지 않을 수 있는 의지다. 이번 주 Hacker News에서 화제가 된 프레임워크는 14일 동안 똑똑한 응원단을 가진다. 6개월 후 그 프레임워크의 절반은 유지보수가 끊긴다. 끼어들지 않은 사람은 hype가 지나간 뒤에도 살아남은 보링한 것들에 주의력을 남겨뒀다.

무엇을 배울 것인가, 컴파운드되는 프리미티브들

개념이다. 패턴이다. 사물의 모양이다. 컴파운드 수익을 내는 아이디어들이고, 모델·프레임워크·패러다임이 바뀌어도 살아남는다. 이걸 깊이 이해하면 어떤 새 도구도 주말 한 번에 익힐 수 있다. 건너뛰면 끝없이 표면 메커닉을 다시 배운다.

컨텍스트 엔지니어링. 지난 2년의 가장 중요한 이름 변경이 "프롬프트 엔지니어링"에서 "컨텍스트 엔지니어링"으로 옮긴 것이다. 모델은 더 이상 영리한 명령을 짜는 대상이 아니라, 매 스텝마다 작동하는 컨텍스트를 조립해주는 대상이다. 시스템 명령, 툴 스키마, 검색된 문서, 이전 툴 출력, 스크래치패드 상태, 압축된 히스토리가 한꺼번에 들어간다. 에이전트의 행동은 윈도우에 무엇을 넣었는지의 emergent property다. 컨텍스트는 상태다. 모든 무관한 토큰이 추론 품질을 갉아먹는다. context rot은 실제 프로덕션 실패다. 10단계 작업의 8단계쯤에서는 원래 목표가 툴 출력 아래에 묻혀 있다.

안정적인 에이전트를 출시하는 팀은 적극적으로 요약하고 압축하고 가지치기한다. 툴 설명을 버전 관리한다. 정적 부분을 캐싱하고 변하는 부분은 캐싱을 거부한다. 경험 많은 엔지니어가 RAM을 다루는 방식으로 컨텍스트 윈도우를 다룬다. 이 감각을 느끼는 구체적 방법이 있다. 프로덕션 에이전트를 골라 풀 트레이스 로깅을 켠다. 1단계 컨텍스트를 본다. 7단계 컨텍스트를 본다. 그 토큰 중 몇 개가 여전히 일하고 있는지 센다. 처음 해보면 부끄러워진다. 가서 고치면, 같은 에이전트가 모델 변경이나 프롬프트 변경 없이 눈에 띄게 더 안정적이 된다. 이 주제로 한 편만 읽는다면 Anthropic의 "Effective Context Engineering for AI Agents"다. 그 다음에 멀티 에이전트 리서치 포스트모템을 읽는다.

툴 디자인. 툴은 에이전트가 형운님 비즈니스를 만나는 자리다. 모델은 이름과 설명으로 툴을 고른다. 에러 메시지를 보고 재시도한다. 툴의 계약이 LLM이 표현하기 좋은 형태와 맞아야 성공한다. 잘 명명된 툴 5~10개가 평범한 툴 20개를 이긴다. 이름은 영어 동사구처럼 읽혀야 하고, 설명에는 언제 쓰고 언제 쓰지 말아야 하는지가 들어가야 한다. 에러 메시지는 모델이 행동할 수 있는 피드백이어야 한다. "Max tokens 500 exceeded, try summarizing first"가 "Error: 400 Bad Request"를 압도적으로 이긴다. 공개 리서치에 보고된 한 팀은 에러 메시지만 다시 써서 재시도 루프를 40% 줄였다. 에이전트 안정성에서 가장 큰 승리는 거의 항상 툴 쪽에 있다. 사람들은 프롬프트만 튜닝하면서 실제 레버리지가 있는 자리를 무시한다.

오케스트레이터-서브에이전트 패턴. 2024~2025년의 멀티 에이전트 논쟁은 모두가 출시하는 합으로 끝났다. naïve 멀티 에이전트(여러 에이전트가 공유 상태에 병렬로 쓰는 형태)는 에러가 복합되어 파국적으로 실패한다. 단일 에이전트 루프는 생각보다 멀리 간다. 프로덕션에서 작동하는 멀티 에이전트 형태는 하나뿐이다. 오케스트레이터 에이전트가 좁고 read-only한 작업을 격리된 서브에이전트에 위임하고 결과를 종합한다. 이게 Anthropic 리서치 시스템의 작동 방식이고, Claude Code 서브에이전트의 작동 방식이고, Spring AI와 대부분의 프로덕션 프레임워크가 표준화한 패턴이다.

서브에이전트는 작고 집중된 컨텍스트를 받는다. 공유 상태를 변경할 수 없다. 쓰기는 오케스트레이터가 소유한다. Cognition의 "Don't Build Multi-Agents"와 Anthropic의 "How we built our multi-agent research system"은 반대처럼 보이지만 다른 어휘로 같은 말을 한다. 둘 다 읽는다. 기본값은 단일 에이전트다. 오케스트레이터-서브에이전트는 단일 에이전트가 진짜 벽에 부딪힐 때만 손을 댄다. 컨텍스트 윈도우 압박, 순차 툴 호출의 지연, 진짜로 격리된 컨텍스트가 필요한 작업의 이질성. 이 고통을 느끼기 전에 짓는 것은 필요 없는 복잡도를 출시하는 일이다.

Eval과 골든 데이터셋. 안정적인 에이전트를 출시하는 모든 팀은 eval이 있다. 그렇지 않은 모든 팀은 eval이 없다. 이 분야에서 가장 레버리지 큰 단일 습관이고, 거의 모든 회사가 가장 적게 투자하는 일이다. 작동 방식은 단순하다. 프로덕션 트레이스를 수집하고, 실패에 라벨링하고, 그것을 회귀 셋으로 다룬다. 새 실패가 출시될 때마다 추가한다. 주관적 부분은 LLM-as-judge, 나머지는 exact-match나 프로그래밍 검사를 쓴다. 프롬프트·모델·툴 변경 전에 스위트를 돌린다. Spotify 엔지니어링 블로그가 보고한 바, 그들의 judge 레이어는 약 25%의 에이전트 출력을 사용자에게 도달하기 전에 거부한다. 그게 없으면 4건 중 1건의 나쁜 결과가 사용자에게 도달했을 것이다.

이걸 잡아주는 멘탈 모델: eval은 다른 모든 것이 아래에서 변할 때 에이전트를 정직하게 유지하는 unit test다. 모델이 새 버전을 받는다. 프레임워크가 breaking change를 발표한다. 벤더가 엔드포인트를 deprecate한다. 형운님의 eval은 에이전트가 여전히 자기 일을 하고 있는지를 알려주는 유일한 것이다. 그게 없으면 형운님은 정확성이 움직이는 표적의 호의에 의존하는 시스템을 쓰고 있다. eval 프레임워크(Braintrust, Langfuse, LangSmith)는 어느 것도 병목이 아니다. 병목은 라벨링된 셋을 처음에 만드는 일이다. 첫째 날에 만든다. 처음 50개 예시는 오후 한 번에 손으로 라벨링할 수 있다. 변명은 없다.

파일 시스템을 상태로, think-act-observe 루프. 진짜 멀티 스텝 작업을 하는 모든 에이전트의 견고한 아키텍처는 think, act, observe, repeat다. 진실의 출처는 파일 시스템이거나 구조화된 저장소다. 모든 액션이 로깅되고 재생 가능하다. Claude Code, Cursor, Devin, Aider, OpenHands, goose. 다 이걸로 수렴했다. 모델은 stateless다. 하네스가 stateful이어야 한다. 파일 시스템은 모든 개발자가 이미 이해하는 stateful 프리미티브다. 이 프레임을 받아들이면 모든 하네스 규율(체크포인팅, 재개 가능성, 서브에이전트 검증, 샌드박스 실행)이 패턴을 진지하게 받아들인 결과로 떨어진다.

이게 가르치는 더 깊은 것: 하네스는 모든 프로덕션 에이전트에서 모델보다 더 많은 일을 한다. 모델은 다음 액션을 고른다. 하네스는 그것을 검증하고, 샌드박스에서 돌리고, 출력을 캡처하고, 무엇을 다시 먹일지·언제 멈출지·언제 체크포인트할지·언제 서브에이전트를 띄울지를 결정한다. 비슷한 품질의 다른 모델로 바꿔도 좋은 하네스는 출시된다. 더 나쁜 하네스로 바꾸면 세상 최고의 모델도 자기가 뭐 하던 중인지 잊어버리는 에이전트가 된다. 단일 툴 호출보다 더 정교한 무언가를 만든다면 하네스가 시간을 써야 하는 자리다. 모델은 그 안의 컴포넌트다.

MCP, 개념적으로. MCP 서버를 어떻게 호출하는지만 배우지 않는다. 모델을 배운다. 에이전트 능력·툴·리소스의 깨끗한 분리에 확장 가능한 인증·전송 스토리가 깔린 구조다. 이걸 이해하면 다른 모든 "에이전트 통합 프레임워크"는 MCP의 더 나쁜 버전처럼 보이고, 각각을 평가하는 시간을 절약한다. Linux Foundation이 관리권을 가졌다. 모든 주요 모델 제공자가 지지한다. "AI의 USB-C" 비유는 이제 아이러니가 아니라 정확하다.

프리미티브로서의 샌드박싱. 모든 프로덕션 코딩 에이전트는 샌드박스에서 돈다. 모든 브라우저 에이전트는 indirect prompt injection에 한 번씩 맞았다. 모든 멀티 테넌트 에이전트는 어느 시점에 권한 스코핑 버그를 출시했다. 샌드박싱은 고객이 요청할 때 추가하는 기능이 아니라 프리미티브 인프라로 다룬다. 프로세스 격리, 네트워크 egress 통제, 시크릿 스코핑, 에이전트와 툴 사이 인증 경계를 배운다. 고객 보안 리뷰 후에 이걸 덧붙이는 팀은 거래를 잃는다. 첫 주부터 짓는 팀은 enterprise procurement를 땀 없이 통과한다.

무엇을 만들 것인가, 2026년 4월 기준 권장 스택

구체적 픽이다. 바뀌긴 하지만 천천히 바뀐다. 여기서는 보링하게 고른다. 오케스트레이션은 LangGraph가 프로덕션 기본값이다. 에이전트를 돌리는 대형사의 약 1/3이 쓴다. 추상화가 에이전트 시스템의 실제 모양과 맞는다. 타입드 상태, 조건부 엣지, 견고한 워크플로우, human-in-the-loop 체크포인트. 단점은 verbosity. 장점은 그 verbosity가 프로덕션에서 통제해야 할 것과 맞다는 점이다. TypeScript에 산다면 Mastra가 사실상의 픽이다. Pydantic을 사랑하고 타입 안전성을 일급으로 원하는 팀이라면 Pydantic AI. 2025년 말 v1.0을 찍었고 모멘텀이 진짜다. 프로바이더 네이티브 작업(컴퓨터 사용, 음성, 실시간)이라면 Claude Agent SDK나 OpenAI Agents SDK를 LangGraph 노드 안에서 쓴다. 이질적 시스템의 최상위 오케스트레이터로 만들지 않는다.

프로토콜 레이어는 MCP. 끝. 툴 통합을 MCP 서버로 짓는다. 외부 통합도 같은 방식으로 소비한다. 레지스트리는 필요한 서버를 거의 항상 짓기 전에 찾을 수 있는 지점을 넘었다. 2026년에 커스텀 툴 배관을 짜는 건 아무것도 아닌 일에 세금을 내는 것이다.

메모리는 hype가 아니라 자율성 수준으로 고른다. Mem0는 채팅 스타일 개인화. 사용자 선호, 가벼운 히스토리. Zep은 상태가 진화하고 엔티티 추적이 필요한 프로덕션 대화 시스템. Letta는 에이전트가 며칠 또는 몇 주에 걸친 작업의 일관성을 유지할 때. 대부분의 팀은 이게 필요 없다. 필요한 팀은 정확히 이게 필요하다. 실수는 메모리 문제가 생기기 전에 메모리 프레임워크에 손대는 것이다. 컨텍스트 윈도우가 담을 수 있는 것 + 벡터 스토어로 시작한다. 메모리 시스템은 그것이 해결하는 실패 모드를 말로 표현할 수 있을 때 추가한다.

관측과 eval. Langfuse가 OSS 기본값이다. 자체 호스팅 가능, MIT, 트레이싱·프롬프트 버저닝·기본 LLM-as-judge eval을 커버한다. 이미 LangChain 샵이라면 LangSmith가 더 타이트하게 통합된다. Braintrust는 엄격한 비교가 있는 리서치 스타일 eval 워크플로우의 정답. OpenLLMetry / Traceloop는 polyglot 스택에서 벤더 중립 OpenTelemetry 계측이 필요할 때. 트레이싱과 eval 둘 다 필요하다. 트레이싱은 "에이전트가 실제로 뭘 했지?"에 답한다. eval은 "에이전트가 어제보다 좋아졌나 나빠졌나?"에 답한다. 둘 다 없이 출시하지 않는다. 눈 감고 돌리는 비용은 첫째 날 제대로 배선하는 비용의 10배다.

런타임과 샌드박스. 일반 샌드박스 코드 실행은 E2B. 브라우저 자동화는 Browserbase + Stagehand. 진짜 OS 레벨 데스크톱 컨트롤이 필요하면 Anthropic Computer Use. 짧은 버스트는 Modal. 샌드박스 없이 코드 실행은 절대 하지 않는다. 절대. 프롬프트 인젝션된 에이전트 한 마리의 폭발 반경은 형운님이 들려주고 싶지 않은 이야기다.

모델은 벤치마크를 추격하지 않는다. 2026년 4월 기준 실용적으로는, Claude Opus 4.7과 Sonnet 4.6이 안정적인 툴 사용·멀티 스텝 일관성·우아한 실패 복구. Sonnet이 대부분의 워크로드에서 비용-성능 sweet spot. GPT-5.4와 5.5는 가장 강한 CLI/터미널 추론이 필요하거나 OpenAI 인프라에 살 때. Gemini 2.5와 3은 long-context-heavy 또는 multimodal-heavy 작업. DeepSeek-V3.2 또는 Qwen 3.6은 비용이 top-end 성능보다 중요한 좁고 잘 정의된 작업. 모델은 swappable로 다룬다. 에이전트가 한 모델에서만 작동한다면 그건 해자가 아니라 냄새다. eval로 배포 결정. 매주가 아니라 매분기 재평가.

무엇을 건너뛸 것인가

다 배우라고 다 만들라고 권유받는다. 그럴 필요 없다. 건너뛰는 비용은 낮고 절약되는 시간은 크다.

프로덕션용 AutoGen과 AG2. Microsoft 프레임워크가 커뮤니티 유지로 옮겨갔고, 릴리스가 정체됐고, 추상화가 프로덕션 팀의 실제 필요와 안 맞는다. 학술 탐색에는 괜찮다. 제품을 거기 앵커하지 않는다. 새 프로덕션 빌드의 CrewAI. 데모가 쉬워서 어디에나 있다. 진짜 시스템을 짓는 엔지니어들은 옮겨 갔다. 프로토타입에 쓰는 건 좋다. 커밋하지 않는다. Microsoft Semantic Kernel은 MS 엔터프라이즈 스택에 락인되어 있고 구매자가 그 사실에 신경 쓰지 않는 한 건너뛴다. DSPy는 스케일에서 프롬프트 프로그램 최적화를 구체적으로 한다는 게 아니라면 일반 에이전트 프레임워크가 아니다.

"자율 에이전트" 피칭. AutoGPT와 BabyAGI 계열은 제품 형태로 죽었다. 산업이 정착한 정직한 프레이밍은 "agentic engineering"이다. 감독되고 경계 지어지고 평가된다. 2026년에 deploy-and-forget 자율 에이전트를 파는 사람은 형운님에게 2023년을 팔고 있다. 에이전트 앱스토어와 마켓플레이스는 2023년부터 약속됐고 한 번도 엔터프라이즈 추진력을 내지 않았다. 엔터프라이즈는 generic 사전 빌드 에이전트를 사지 않는다. outcome에 묶인 vertical을 사거나 직접 짓는다. 앱스토어 꿈에 사업을 구조화하지 않는다.

수평적 "어떤 에이전트든 짓는" 엔터프라이즈 플랫폼(Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio 티어)을 고객으로. 결국 유용해질 것이다. 지금은 혼란스럽고 출시가 느리고, buy-vs-build 산수가 여전히 좁은 에이전트를 직접 짓거나 vertical을 사는 쪽으로 기운다. Salesforce Agentforce와 ServiceNow Now Assist는 예외다. 이미 쓰는 워크플로우 시스템에 임베디드되어 이긴다.

SWE-bench와 OSWorld 리더보드 추격. Berkeley 연구자들이 2025년 내내 거의 모든 공개 벤치마크가 underlying task를 풀지 않고도 게임될 수 있다고 문서화했다. 팀들은 이제 Terminal-Bench 2.0과 자체 내부 eval을 진짜 신호로 쓴다. 단일 숫자 벤치마크 점프는 기본적으로 회의로 다룬다. Naïve 병렬 멀티 에이전트 아키텍처는 데모에서 인상적이고 프로덕션에서 무너진다. 오케스트레이터-서브에이전트 다이어그램을 read/write 경계와 함께 냅킨에 깨끗하게 그릴 수 없다면 출시하지 않는다. 새 에이전트 제품의 per-seat SaaS 가격은 시장이 outcome과 usage 기반으로 옮겨간 자리에서 돈을 테이블에 두고, 구매자에게 형운님이 자기 제품의 outcome을 신뢰하지 않는다는 신호를 보낸다. 이번 주 Hacker News에서 본 다음 프레임워크는 6개월 기다린다. 여전히 중요하면 명확해질 것이다. 아니면 마이그레이션을 절약했다.

실제로 움직이는 법, 8단계

따라가는 게 아니라 도입하려 한다면 이 시퀀스가 작동한다. 보링하다. 작동한다.

이미 중요한 outcome 하나를 고른다. 문샷이 아니다. 수평적 "에이전트 플랫폼" 프로젝트가 아니다. 비즈니스가 이미 신경 쓰는 측정 가능한 무언가다. 지원 티켓 디플렉션. 1차 법무 검토 초안. 인바운드 리드 자격 검증. 월간 보고서 생성. outcome이 움직이면 에이전트가 성공한 것이다. 이게 첫째 날의 eval 타깃이 된다. 이 단계가 후속 결정을 모두 제약하기 때문에 어떤 것보다 중요하다. 구체적 outcome이 있으면 "어떤 프레임워크"가 더는 철학적이지 않다. outcome을 가장 빨리 출시하는 것을 고른다. "어떤 모델"이 더는 벤치마크 논쟁이 아니다. 자기 eval이 통한다고 말하는 것을 고른다. 이 단계를 건너뛰는 팀은 아무도 부탁하지 않은 수평 플랫폼을 짓고 끝난다. 진지하게 받아들이는 팀은 한 분기에 비용을 회수하는 좁은 에이전트 하나를 출시하고, 그 에이전트가 2년 동안 글을 읽는 것보다 이 분야에 대해 더 많이 가르쳐 준다.

뭔가 출시하기 전에 트레이싱과 eval을 세팅한다. Langfuse나 LangSmith를 고르고 배선한다. 작은 골든 데이터셋을 손으로 만든다. 50개 라벨링된 예시가 시작에 충분하다. 측정할 수 없는 걸 개선할 수 없다. 나중에 짓는 비용은 지금 짓는 비용의 약 10배다.

단일 에이전트 루프로 시작한다. LangGraph나 Pydantic AI. 모델로는 Claude Sonnet 4.6이나 GPT-5. 잘 디자인된 툴 3~7개를 준다. 파일 시스템이나 데이터베이스를 상태로 준다. 작은 청중에 출시한다. 트레이스를 본다.

에이전트를 프로젝트가 아니라 제품으로 다룬다. 예측하지 못한 방식으로 실패할 것이다. 그 실패가 형운님의 로드맵이다. 회귀 셋을 실제 프로덕션 트레이스에서 짓는다. 모든 프롬프트 변경, 모델 스왑, 툴 변경은 배포 전에 eval을 통과해야 한다. 대부분의 팀이 가장 적게 투자하는 자리고, 대부분의 안정성이 여기서 나온다.

스코프는 벌었을 때만 추가한다. 서브에이전트는 컨텍스트가 병목일 때 들어온다. 메모리 프레임워크는 단일 윈도우 컨텍스트가 담을 수 없는 것이 필요할 때. 컴퓨터 사용이나 브라우저 사용은 underlying API가 정말로 없을 때. 미리 아키텍팅하지 않는다. 실패 모드가 끌어오게 둔다.

보링한 인프라를 고른다. 툴은 MCP. 샌드박스는 E2B나 Browserbase. 상태는 이미 돌리는 Postgres나 데이터 스토어. 기존 인증과 관측 스택. 이국적 인프라가 승리인 경우는 드물다. 규율이다.

첫째 날부터 unit economics를 본다. 액션당 비용. 캐시 히트율. 재시도 루프 비용. 모델 호출 분포. 에이전트는 PoC에서 싸 보이고 100x 스케일에서 폭발한다. 첫째 날부터 outcome당 비용을 계측하지 않으면. $0.50/run PoC가 적당한 볼륨에서 월 $50K가 된다. 다가오는 걸 못 본 팀은 즐겁지 않은 CFO 미팅을 연다.

모델은 매주가 아니라 매분기 재평가한다. 한 분기 락인. 분기 끝에 현재 frontier에 대해 eval 스위트를 돌리고, 데이터가 바꾸라고 하면 바꾼다. 모든 릴리스를 추격하는 카오스 없이 모델 개선의 upside를 얻는다.

조류를 읽는 법, 그리고 아직 답이 안 나온 것들

신호인 구체적 신호가 있다. 존경받는 엔지니어링 팀이 채택 주장이 아니라 숫자를 담은 포스트모템을 쓴다. 래퍼나 번들이 아니라 프리미티브(프로토콜·패턴·인프라)다. 이미 돌리는 것을 대체하지 않고 상호 운용한다. 피칭이 가능하게 만드는 능력이 아니라 해결하는 실패 모드를 묘사한다. "무엇이 통하지 않았는지" 블로그 포스트가 쓰일 만큼 오래 됐다.

노이즈인 구체적 신호도 있다. 30일 후 프로덕션 사례 연구 없는 데모 비디오. 너무 깨끗해서 진짜 같지 않은 벤치마크 점프. "자율적", "에이전트 OS", "어떤 에이전트든 짓는"을 자격 없이 쓰는 피칭. 형운님의 기존 트레이싱·인증·설정을 버리라고 가정하는 프레임워크 문서. 커밋·릴리스·기여자가 함께 오르지 않는데 빠르게 오르는 별 카운트. GitHub velocity 없는 Twitter velocity. 유용한 주간 습관: 금요일 30분을 분야에 예약한다. 세 가지를 읽는다. Anthropic 엔지니어링 블로그, Simon Willison의 노트, Latent Space. 포스트모템이 떨어진 게 있으면 한두 개 훑는다. 이번 주 그 외 모든 것을 건너뛴다. 중요한 것을 알게 될 것이다.

다음 두 분기 동안 주의할 만한 것들도 있다. 보장된 승리가 아니라, "이게 신호인가" 질문이 아직 풀리지 않았기 때문이다. Replit Agent 4의 parallel forking 모델은 공유 상태에 걸려 넘어지지 않는 "병렬로 작업하는 여러 에이전트"의 첫 진지한 시도다. 스케일에서 버티면 오케스트레이터-서브에이전트 기본값이 옮겨갈 수 있다. Outcome 기반 가격 책정의 성숙은 Sierra와 Harvey의 매출 궤적이 좁은 vertical 안에서 검증한다. 질문은 그게 밖에서도 일반화되느냐다. 패키징 레이어로서의 Skills. GitHub 전반의 AGENTS.md와 skills 디렉토리 확산은 에이전트 능력을 패키징하는 떠오르는 방식을 시사한다. MCP가 툴에 대해 표준화한 방식으로 표준화될지가 열린 질문.

Claude Code의 2026년 4월 품질 회귀와 그 포스트모템. 산업 선도 에이전트가 47% 성능 회귀를 출시했고 내부 모니터링이 잡기 전에 사용자가 잡았다. 리더에서조차 프로덕션 에이전트 eval 관행이 얼마나 미성숙한지에 대한 교훈이다. 이게 더 나은 온라인 eval에 산업 전반의 투자를 끌어내면 교정은 건강하다. 기본 지원 표면으로서의 음성. Sierra의 음성 채널이 2025년 말 텍스트를 넘어섰다. 그 패턴이 다른 vertical에 걸쳐 유지되면 디자인 제약(지연·인터럽션·실시간 툴 사용)이 1차로 들어오고 현재 아키텍처의 많은 부분이 재작업이 필요하다. 오픈 모델 에이전트 능력의 격차 좁히기. 네이티브 thinking-into-tool-use가 있는 DeepSeek-V3.2, Qwen 3.6, 더 넓은 오픈 풍경. 좁은 에이전트 작업의 비용-성능이 옮겨가는 중이다. 클로즈드 소스 기본값은 영구적이지 않다.

각각 "6개월 후 무엇을 보아야 중요하다고 믿게 될까"의 명확한 답이 있다. 그게 테스트다. 발표가 아니라 답을 추적한다.

비전통적 베팅, 사다리 없는 시대의 일하는 법

도입하지 않은 모든 프레임워크는 빚지지 않은 마이그레이션이다. 추격하지 않은 모든 벤치마크는 형운님이 지킨 한 분기의 집중이다. 이번 사이클을 이기는 회사들(Sierra, Harvey, 각자 도메인의 Cursor)은 좁은 타깃을 골랐고, 보링한 규율을 지었고, 분야의 노이즈가 자기를 지나가게 뒀다.

전통적 경로는 스택을 고르고 몇 년에 걸쳐 마스터하고 사다리를 오르는 것이었다. 스택이 10년 안정적일 때 그게 통했다. 스택은 이제 매 분기 바뀐다. 이기는 사람들은 스택 마스터리 최적화를 멈추고 안목·프리미티브·출시 속도 최적화를 시작했다. 작은 것을 공개적으로 짓는다. 출시하면서 배운다. 이미 만든 것이 그들을 방으로 끌어들인다. 자격은 산출물이다.

이걸 잠시 곱씹어볼 가치가 있다. 이 글 전체의 진짜 포인트이기 때문이다. 우리 대부분은 일의 모델을 자격이 누적될 만큼 세상이 정지해 있다고 가정하는 위에서 자랐다. 학교에 갔다. 학위를 받았다. 사다리를 올랐다. 여기서 2년, 저기서 3년, 그리고 천천히 이력서가 문을 여는 무언가가 됐다. 그 기계 전체가 그것의 반대편에 안정적인 산업이 있다고 가정했다. 에이전트 공간은 지금 안정된 반대편이 없다. 형운님이 일하고 싶을 만한 회사들은 6개월 됐다. 그들이 짓는 프레임워크는 18개월 됐다. 그 아래 프로토콜은 2년 됐다. 분야에서 가장 많이 인용되는 글의 절반은 3년 전에 분야에 없던 사람이 썼다. 사다리는 없다. 건물이 자꾸 층을 바꾸기 때문이다. 사다리가 통하지 않을 때 남는 것은 훨씬 오래된 방법이다. 무언가를 만든다. 인터넷에 올린다. 일이 자기를 소개하게 둔다.

이게 안에서 본 시대의 모습이다. 거인들조차 공개적으로 반복하고, 회귀를 출시하고, 포스트모템을 쓰고, 라이브로 패치한다. 올해 가장 흥미로운 것을 출시하는 팀에는 18개월 전 분야에 없던 사람이 포함된다. non-coder들이 에이전트와 짝지어 진짜 소프트웨어를 출시한다. PhD들이 올바른 프리미티브를 골라 휘두르기 시작한 빌더에게 추월당한다. 문은 열려 있다. 대부분의 사람들은 여전히 신청서를 찾고 있다.

지금 정말로 개발해야 할 능력은 "에이전트"가 아니다. 표면이 자꾸 바뀌는 분야에서 어떤 일이 누적되는지를 알아내는 규율이다. 컨텍스트 엔지니어링은 누적된다. 툴 디자인은 누적된다. 오케스트레이터-서브에이전트 패턴은 누적된다. eval 규율은 누적된다. 하네스 마인드셋은 누적된다. 화요일에 출시된 프레임워크의 API를 아는 것은 누적되지 않는다. 이 둘을 구분할 수 있게 되면 주간 출시 조류가 더 이상 압박처럼 느껴지지 않고 무시할 수 있는 노이즈로 느껴진다.

모든 걸 배울 필요는 없다. 누적되는 것을 배우고 누적되지 않는 것을 건너뛰는 능력이 필요하다. outcome 하나를 고른다. 출시하기 전에 트레이싱과 eval을 배선한다. LangGraph나 팀의 등가물을 쓴다. MCP를 쓴다. 런타임을 샌드박싱한다. 단일 에이전트를 기본값으로 한다. 실패 모드가 끌어올 때 스코프를 추가한다. 모델은 매분기 재평가한다. 금요일에 세 가지를 읽는다. 그게 플레이북이다. 나머지는 안목, 출시 속도, 그리고 중요하지 않은 것을 추격하지 않을 인내심이다. 무언가를 만든다. 인터넷에 올린다. 시대는 이것을 묘사할 수 있는 사람보다 만드는 사람에게 보상한다. 만드는 자리에 있을 더 좋은 창은 없었다.

원문 출처: Rohit (@rohit4verse), "What to Learn, Build, and Skip in AI Agents (2026)". 이 글은 원문의 모든 주장과 사례, 도구 픽을 보존하면서 한국어 분석 칼럼으로 옮긴 것이다.