2026년에 인공지능 에이전트에서 무엇을 배우고, 무엇을 구현해야 하며, 무엇은 건너뛰어야 할까?
매일 새로운 프레임워크, 새로운 벤치마크, 새로운 “10배” 출시가 쏟아진다. 이제 질문은 “어떻게 따라잡을까”가 아니다. 진짜 질문은 이것이다: 무엇이 실제 시그널이고, 무엇이 긴박함이라는 가면을 쓴 노이즈인가.
모든 로드맵은 출시 한 달 후면 구식이 된다. 지난 분기에 마스터한 프레임워크는 이제 레거시다. 최적화했던 벤치마크는 게임화되어 교체되었다. 우리는 전통적인 경로를 따르도록 훈련받았다: 주제와 레벨이 있는 스택, 일련의 직무와 근속 연수, 느린 상승. AI가 그 캔버스를 다시 썼다. 올바른 프롬프트와 올바른 안목을 가진 사람이라면 누구나, 예전에는 2년 경력의 엔지니어가 한 스프린트 동안 걸리던 작업을 지금 바로 출시할 수 있다.
전문성은 여전히 중요하다. 시스템이 망가지는 것을 지켜보고, 새벽 2시에 메모리 누수를 디버깅하고, 영리한 선택보다 지루한 선택을 주장해서 옳았던 경험을 대체할 수 있는 것은 없다. 그런 종류의 안목은 복리로 쌓인다. 더 이상 예전처럼 복리로 쌓이지 않는 것: 이번 주 프레임워크의 API 표면을 아는 것. 6개월 후면 달라져 있을 것이다. 2년 후에 승리하는 사람들은 내구성 있는 기본 요소를 일찍 선택하고 나머지는 흘려보낸 사람들이다.
나는 이 분야에서 2년 동안 구축해왔고, 25만 달러 이상의 여러 오퍼를 따냈으며, 지금은 스텔스 모드의 회사에서 기술 책임자로 일하고 있다. 이것은 “지금 당장 무엇에 주목해야 할까”라고 묻는 사람에게 보내줄 내용이다.
이것은 로드맵이 아니다. 에이전트 분야에는 아직 목적지가 없다. 주요 연구소들은 공개적으로 반복하고, 수백만 사용자에게 회귀를 배포하고, 포스트모템을 작성하고, 실시간으로 패치한다. Claude Code 팀이 47%의 성능 회귀를 배포하고 사용자 커뮤니티가 발견한 후에야 알아챌 수 있다면, 이 모든 것 아래에 안정적인 지도가 있다는 생각은 허구다. 모두가 알아가고 있는 중이다. 거대 기업들도 모르기 때문에 스타트업이 번성하고 있다. 비개발자들이 에이전트와 페어링하여 화요일에 ML 박사들이 불가능하다고 말했던 것을 금요일에 출시하고 있다.
이 순간이 흥미로운 이유는 자격 증명이라는 질문에 미치는 영향 때문이다. 전통적인 경로는 자격 증명을 위해 최적화되었다: 학위, 주니어 역할, 시니어 역할, 스태프 역할, 느린 직급 축적. 그 아래의 분야가 움직이지 않을 때는 그것이 합리적이었다. 이제 그 분야는 모두에게 동등하게 움직인다. 공개적으로 에이전트 데모를 출시하는 22세와 35세 시니어 엔지니어의 차이는 더 이상 10년간 축적된 스택 숙련도가 아니다. 22세는 시니어가 가진 것과 동일한 백지 캔버스를 가지고 있으며, 둘 모두에게 복리로 쌓이는 것은 출시하려는 의지와 한 분기 만에 구식이 되지 않는 소수의 기본 요소들뿐이다.
이것이 이 글 전체를 관통하는 재구성이다. 다음은 어떤 기본 요소가 당신의 관심을 받을 가치가 있고 어떤 출시는 흘려보내야 하는지 생각하는 방법이다. 맞는 것을 골라라. 맞지 않는 것은 남겨둬라.
실제로 작동하는 필터
매주 쏟아지는 출시를 따라잡을 수 없다. 따라잡으려고 해서도 안 된다. 필요한 것은 피드가 아니라 필터다.
지난 18개월 동안 견뎌낸 다섯 가지 테스트가 있다. 무언가가 당신의 스택에 닿기 전에 이 테스트를 통과시켜라.
이것이 2년 후에도 중요할까? 프론티어 모델을 감싼 래퍼, CLI 플래그, 또는 “Devin but for X”라면 대답은 거의 항상 ‘아니오’다. 기본 요소(프로토콜, 메모리 패턴, 샌드박싱 접근법)라면 대답은 더 자주 ‘예’다. 래퍼의 반감기는 짧다. 기본 요소의 반감기는 수년이다.
당신이 존경하는 누군가가 이것 위에 실제 무언가를 구축하고 그것에 대해 솔직하게 글을 썼는가? 마케팅 게시물은 해당되지 않는다. 포스트모템은 해당된다. “우리는 X를 프로덕션에서 시도했고 여기서 망가진 것들입니다”라는 블로그는 열 개의 출시 발표보다 가치가 있다. 이 분야에서 좋은 시그널은 항상 그것에 주말을 바친 사람이 쓴 것이다.
이것을 도입하려면 트레이싱, 재시도, 설정, 인증을 모두 버려야 하는가? 그렇다면 플랫폼이 되려는 프레임워크다. 플랫폼이 되려는 프레임워크의 사망률은 90%다. 좋은 기본 요소는 마이그레이션을 강요하지 않고 기존 시스템에 슬롯 인 된다.
이것을 6개월 동안 건너뛰는 데 드는 비용은 무엇인가? 대부분의 출시에서 답은 ‘아무것도 아니다’다. 6개월 후면 더 많이 알게 될 것이다. 승리하는 버전이 더 명확해질 것이다. 이것은 불안 없이 출시의 90%를 건너뛸 수 있게 해주는 테스트이며, 건너뛰는 것이 뒤처지는 것처럼 느껴져서 대부분의 사람이 실행하기를 거부하는 테스트이기도 하다. 뒤처지는 게 아니다.
이것이 실제로 당신의 에이전트에 도움이 되는지 측정할 수 있는가? 측정할 수 없다면 추측하고 있는 것이다. 평가 체계가 없는 팀은 분위기로 운영하고 회귀를 배포한다. 평가 체계가 있는 팀은 데이터가 GPT-5.5가 이번 주 그들의 특정 워크로드에서 이기는지 Opus 4.7이 이기는지 말해주도록 할 수 있다.
이 글 전체에서 단 하나의 습관만 채택한다면 이것으로 해라: 새로운 무언가가 출시되면, 그것이 중요하다고 믿기 위해 6개월 후에 무엇을 봐야 하는지 적어둬라. 그리고 돌아와서 확인해라. 대부분의 경우 질문은 스스로 답을 내릴 것이고, 당신은 복리로 쌓이는 것들에 주의력을 사용했을 것이다.
이 테스트들의 기저에 있는 기술은 그 어느 것보다 이름 붙이기 어렵다. 그것은 집지 않은 것에 대해 쿨하지 않아도 되는 의지다. 이번 주 해커뉴스에서 바이럴되는 프레임워크는 14일 동안 열성 지지자 군단을 거느릴 것이고, 그들은 모두 똑똑해 보일 것이다. 6개월 후, 그 프레임워크의 절반은 유지보수되지 않고 열성 지지자들은 다른 곳으로 옮겨갔다. 관여하지 않은 사람들은 출시 과대광고가 지나간 후 지루해지는 테스트에서 살아남은 것들을 위해 주의력을 아꼈다. 그 자세, 물러서서 지켜보며 “6개월 후에 알게 될 거야”라고 말하는 것, 이것이 이 분야의 실제 직업적 기술이다. 누구나 출시를 읽을 수 있다. 그것에 반응하지 않는 데 능숙한 사람은 거의 없다.
배워야 할 것
개념. 패턴. 사물의 형태. 이것들은 복리 수익을 지불하는 아이디어들이다. 모델 교체, 프레임워크 교체, 패러다임 전환에서도 살아남는다. 이것들을 깊이 이해하면 어떤 새로운 도구든 주말이면 익힐 수 있다. 이것들을 건너뛰면 표면적인 메커니즘을 영원히 다시 배우게 될 것이다.
컨텍스트 엔지니어링
지난 2년간 가장 중요한 이름 변경은 “프롬프트 엔지니어링”이 “컨텍스트 엔지니어링”이 된 것이다. 이 전환은 표면적이지 않고 실제적이다.
모델은 더 이상 교묘한 명령을 작성하는 대상이 아니다. 매 단계마다 작동하는 컨텍스트를 조립하는 대상이다. 그 컨텍스트는 시스템 명령어, 도구 스키마, 검색된 문서, 이전 도구 출력, 스크래치패드 상태, 압축된 히스토리가 모두 한꺼번에 존재하는 것이다. 에이전트의 행동은 윈도우에 넣은 것들의 창발적 속성이다.
이것을 내재화해라: 컨텍스트는 상태다. 관련 없는 노이즈의 모든 토큰은 추론 품질을 깎아먹는다. 컨텍스트 부패는 실제 프로덕션 장애다. 10단계 작업의 8단계쯤 되면 원래 목표가 도구 출력 아래에 묻혀버릴 수 있다. 신뢰할 수 있는 에이전트를 출시하는 팀은 능동적으로 요약하고, 압축하고, 가지치기한다. 그들은 도구 설명을 버전 관리한다. 정적인 부분은 캐시하고 변경되는 부분은 캐시하지 않는다. 그들은 경험 많은 엔지니어가 RAM을 생각하는 방식으로 컨텍스트 윈도우를 생각한다.
이것을 체감하는 구체적인 방법: 프로덕션의 아무 에이전트나 골라 전체 트레이스 로깅을 켜라. 1단계의 컨텍스트를 보라. 7단계의 컨텍스트를 보라. 그 토큰 중 몇 개나 아직 제값을 하고 있는지 세어보라. 처음 이것을 하면 부끄러워질 것이다. 그러면 가서 고칠 것이고, 모델이나 프롬프트를 전혀 바꾸지 않았는데도 같은 에이전트가 눈에 띄게 더 신뢰할 수 있게 될 것이다.
이 주제에 대해 한 가지만 읽는다면, Anthropic의 “Effective Context Engineering for AI Agents”를 읽어라. 그다음 그들의 멀티 에이전트 연구 포스트모템을 읽어라. 규모를 확장할 때 컨텍스트 격리가 얼마나 중요한지 수치로 보여준다.
도구 설계
도구는 에이전트가 당신의 비즈니스와 만나는 지점이다. 모델은 이름과 설명을 기반으로 도구를 선택한다. 모델은 오류 메시지를 기반으로 재시도한다. 모델은 도구의 계약이 LLM이 표현하기 좋은 것과 일치하는지에 따라 실패하거나 성공한다.
잘 이름 지어진 5~10개의 도구가 평범한 20개를 이긴다. 도구 이름은 영어 동사구처럼 읽혀야 한다. 설명에는 도구를 사용해야 할 때와 사용하지 말아야 할 때가 포함되어야 한다. 오류 메시지는 모델이 행동할 수 있는 피드백이어야 한다. “최대 토큰 500 초과, 먼저 요약해보세요”가 “오류: 400 Bad Request”보다 엄청난 차이로 낫다. 공개 연구의 한 팀은 오류 메시지만 다시 작성한 후 재시도 루프가 40% 감소했다고 보고했다.
Anthropic의 “Writing tools for agents”가 올바른 출발점이다. 그 후에는 자신의 도구를 계측하고 실제 호출 패턴을 보라. 에이전트 신뢰성에서 가장 큰 승리는 거의 항상 도구 쪽에 있다. 사람들은 계속 프롬프트를 튜닝하면서 실제 레버리지가 존재하는 곳을 무시한다.
오케스트레이터-서브에이전트 패턴
2024년과 2025년의 멀티 에이전트 논쟁은 이제 모두가 배포하는 종합으로 끝났다. 여러 에이전트가 공유 상태에 병렬로 쓰는 순진한 멀티 에이전트 시스템은 오류가 복합되기 때문에 치명적으로 실패한다. 단일 에이전트 루프는 예상보다 훨씬 더 확장된다. 프로덕션에서 작동하는 멀티 에이전트 형태는 단 하나다: 오케스트레이터 에이전트가 좁은 범위의 읽기 전용 작업을 격리된 서브에이전트에 위임한 다음, 그 결과를 종합하는 것이다.
이것이 Anthropic의 연구 시스템이 작동하는 방식이다. Claude Code의 서브에이전트가 작동하는 방식이다. Spring AI와 현재 대부분의 프로덕션 프레임워크가 표준화하는 패턴이다. 서브에이전트는 작고 집중된 컨텍스트를 얻는다. 그들은 공유 상태를 변경할 수 없다. 오케스트레이터가 쓰기를 소유한다.
Cognition의 “Don’t Build Multi-Agents” 에세이와 Anthropic의 “How we built our multi-agent research system”은 상반된 것처럼 보이지만 서로 다른 어휘로 같은 말을 하고 있다. 둘 다 읽어라.
기본값은 단일 에이전트다. 오케스트레이터-서브에이전트는 단일 에이전트가 실제 벽에 부딪혔을 때만 도달해라: 컨텍스트 윈도우 압박, 순차적 도구 호출로 인한 지연, 또는 집중된 컨텍스트가 진정으로 이점을 주는 작업 이질성. 이 고통을 느끼기 전에 이것을 구축하는 것은 필요하지 않은 복잡성을 배포하는 것이다.
평가 체계와 골든 데이터셋
신뢰할 수 있는 에이전트를 출시하는 모든 팀은 평가 체계를 갖추고 있다. 그렇지 않은 모든 팀은 갖추고 있지 않다. 이것은 이 분야에서 가장 높은 레버리지를 가진 습관이며, 내가 본 모든 회사에서 가장 과소 투자된 부분이다.
효과적인 방법: 프로덕션 트레이스를 수확하고, 실패에 레이블을 지정하고, 그것을 회귀 세트로 취급해라. 새로운 실패가 배포될 때마다 추가해라. 주관적인 부분에는 LLM-as-judge를 사용하고, 나머지는 정확 일치나 프로그래밍 방식 검사를 사용해라. 프롬프트, 모델, 또는 도구를 변경하기 전에 이 스위트를 실행해라. Spotify의 엔지니어링 블로그는 그들의 judge 레이어가 배포 전에 에이전트 출력의 약 25%를 거부한다고 보고했다. 이것이 없었다면 네 개 중 하나의 나쁜 결과가 사용자에게 도달했을 것이다.
이것을 지속하게 만드는 멘탈 모델: 평가는 그 아래의 모든 것이 변하는 동안 에이전트를 정직하게 유지하는 단위 테스트다. 모델은 새 버전이 나온다. 프레임워크는 브레이킹 체인지를 릴리스한다. 벤더는 엔드포인트를 폐기한다. 당신의 평가는 에이전트가 여전히 제 역할을 하고 있는지 알려주는 유일한 것이다. 이것들이 없으면, 당신은 움직이는 표적의 호의에 정확성이 의존하는 시스템을 작성하고 있는 것이다.
평가 프레임워크(Braintrust, Langfuse evals, LangSmith)는 괜찮다. 그 중 어느 것도 병목이 아니다. 병목은 애초에 레이블된 세트를 가지고 있는 것이다. 무엇이든 확장하기 전에 첫날부터 이것을 구축해라. 처음 50개의 예제는 오후 하나면 수동으로 레이블할 수 있다. 변명의 여지가 없다.
파일 시스템을 상태로, 생각-행동-관찰 루프
실제 멀티 스텝 작업을 수행하는 모든 에이전트에게 내구성 있는 아키텍처는: 생각하고, 행동하고, 관찰하고, 반복하라. 파일 시스템이나 구조화된 저장소를 진실의 원천으로 삼아라. 모든 행동은 로깅되고 재생 가능해야 한다. Claude Code, Cursor, Devin, Aider, OpenHands, goose. 이들은 모두 이유가 있어서 이 패턴으로 수렴했다.
모델은 상태가 없다. 하네스는 상태를 가져야 한다. 파일 시스템은 모든 개발자가 이미 이해하는 상태 기반 기본 요소다. 이 프레이밍을 받아들이면, 전체 하네스 규율(체크포인팅, 재개 가능성, 서브 에이전트 검증, 샌드박스 실행)이 이 패턴을 진지하게 받아들이는 데서 자연스럽게 따라온다.
이것이 가르치는 더 깊은 것은: 컴퓨팅 비용을 지불할 가치가 있는 모든 프로덕션 에이전트에서 하네스는 모델보다 더 많은 작업을 수행한다는 것이다. 모델은 다음 행동을 선택한다. 하네스는 그것을 검증하고, 샌드박스에서 실행하고, 출력을 캡처하고, 무엇을 피드백할지 결정하고, 언제 멈출지 결정하고, 언제 체크포인트할지 결정하고, 언제 서브에이전트를 생성할지 결정한다. 비슷한 품질의 다른 모델로 교체해도 좋은 하네스는 여전히 배포된다. 더 나쁜 하네스로 교체하면 세상에서 가장 좋은 모델도 자신이 무엇을 하고 있었는지 무작위로 잊어버리는 에이전트를 만들어낸다.
단발성 도구 호출보다 더 정교한 것을 구축하고 있다면, 하네스가 당신이 시간을 써야 할 곳이다. 모델은 그 안의 컴포넌트일 뿐이다.
MCP, 개념적으로
단순히 MCP 서버를 호출하는 방법만 배우지 마라. 모델을 배워라. 에이전트 기능, 도구, 리소스 간의 깔끔한 분리와 확장 가능한 인증 및 전송 계층. 일단 이것을 이해하면, 보게 되는 다른 모든 “에이전트 통합 프레임워크”는 MCP의 더 나쁜 버전처럼 보일 것이고, 각각을 평가하는 시간을 절약할 것이다.
이제 Linux Foundation이 이를 관리한다. 모든 주요 모델 제공업체가 이를 지원한다. “AI의 USB-C”라는 비유는 이제 아이러니보다 더 정확하다.
기본 요소로서의 샌드박싱
모든 프로덕션 코딩 에이전트는 샌드박스에서 실행된다. 모든 브라우저 에이전트는 간접 프롬프트 인젝션에 당한 적이 있다. 모든 멀티 테넌트 에이전트는 어느 시점에 권한 스코핑 버그를 배포한 적이 있다. 샌드박싱을 고객이 요청할 때 추가하는 기능이 아니라 기본 인프라로 취급해라.
기본을 배워라. 프로세스 격리. 네트워크 송신 제어. 시크릿 스코핑. 에이전트와 도구 사이의 인증 경계. 고객 보안 검토 후에 이것을 덧붙이는 팀은 거래를 잃는 팀이다. 첫 주부터 구축하는 팀은 땀 흘리지 않고 엔터프라이즈 조달을 통과한다.
무엇으로 구축할 것인가
구체적인 선택, 2026년 4월. 이것들은 변하겠지만 천천히 변할 것이다. 여기서 지루하게 골라라.
오케스트레이션
LangGraph가 프로덕션 기본값이다. 에이전트를 실행하는 대기업의 약 3분의 1이 사용한다. 추상화는 에이전트 시스템의 실제 형태와 일치한다: 타입된 상태, 조건부 엣지, 내구성 있는 워크플로우, 인간 개입 체크포인트. 단점은 장황함이다. 장점은 그 장황함이 에이전트가 프로덕션에 들어간 후 실제로 제어해야 하는 것과 일치한다는 것이다.
TypeScript 환경이라면 Mastra가 사실상의 선택이다. 그 생태계에서 가장 깔끔한 멘탈 모델.
팀이 Pydantic을 좋아하고 타입 안전성을 일급 시민으로 원한다면, Pydantic AI가 합리적인 그린필드 선택이다. 2025년 말에 v1.0에 도달했고 모멘텀이 진짜다.
제공업체 네이티브 작업(컴퓨터 사용, 음성, 실시간)에는 LangGraph 노드 안에서 Claude Agent SDK나 OpenAI Agents SDK를 사용해라. 둘 중 어느 것도 이질적인 시스템의 최상위 오케스트레이터로 만들려고 하지 마라. 그들은 자신의 영역에 최적화되어 있다.
프로토콜 레이어
MCP, 더 이상 말할 필요 없다. 도구 통합을 MCP 서버로 구축해라. 외부 통합도 같은 방식으로 소비해라. 레지스트리는 이제 구축하기 전에 거의 항상 서버를 찾을 수 있는 지점을 넘었다. 2026년에 커스텀 도구 배관을 배선하는 것은 아무것도 없는 세금을 내는 것이다.
메모리
과대광고가 아니라 자율성 수준으로 골라라.
채팅 스타일 개인화에는 Mem0. 사용자 선호도, 가벼운 히스토리. 상태가 진화하고 엔티티 추적이 필요한 프로덕션 대화 시스템에는 Zep. 며칠 또는 몇 주간의 작업에 걸쳐 에이전트가 일관성을 유지해야 할 때는 Letta. 대부분의 팀은 이것이 필요하지 않을 것이다. 필요한 팀은 정확히 이것이 필요하다.
실수는 메모리 문제가 생기기 전에 메모리 프레임워크에 손을 뻗는 것이다. 컨텍스트 윈도우가 담을 수 있는 것 + 벡터 저장소로 시작해라. 해결하는 실패 모드를 명확히 설명할 수 있을 때만 메모리 시스템을 추가해라.
관측 가능성과 평가
Langfuse가 OSS 기본값이다. 자체 호스팅 가능, MIT 라이선스, 트레이싱, 프롬프트 버전 관리, 기본 LLM-as-judge 평가를 다룬다. 이미 LangChain 샵이라면 LangSmith가 더 긴밀하게 통합된다. 엄격한 비교가 필요한 연구 스타일 평가 워크플로우에는 Braintrust가 올바른 선택이다. 폴리글랏 스택에서 벤더 중립적인 OpenTelemetry 계측이 필요하다면 OpenLLMetry / Traceloop가 답이다.
트레이싱과 평가 모두 필요하다. 트레이싱은 “에이전트가 실제로 무엇을 했는가?”에 답한다. 평가는 “에이전트가 어제보다 나은가 나쁜가?”에 답한다. 둘 다 없이 배포하지 마라. 맹목적으로 운영하는 비용은 첫날에 이것을 제대로 연결하는 비용의 10배다.
런타임과 샌드박스
일반 샌드박스 코드 실행에는 E2B. 브라우저 자동화에는 Browserbase(Stagehand와 페어링). 실제 OS 수준 데스크톱 제어가 필요할 때는 Anthropic Computer Use. 단기 버스트에는 Modal. 샌드박스 없는 코드 실행은 절대 하지 마라. 프로덕션 환경에서 단일 프롬프트 인젝션된 에이전트의 폭발 반경은 말하고 싶지 않은 이야기다.
모델
벤치마크 추적은 지치고 대체로 도움이 되지 않는다. 실용적으로, 2026년 4월 기준:
신뢰할 수 있는 도구 사용, 멀티 스텝 일관성, 우아한 실패 복구에는 Claude Opus 4.7과 Sonnet 4.6. Sonnet은 대부분의 워크로드에서 비용 대비 성능의 스위트 스팟이다. 가장 강력한 CLI/터미널 추론이 필요하거나 OpenAI 인프라에서 작업한다면 GPT-5.4와 5.5. 긴 컨텍스트가 많거나 멀티모달 작업이 많다면 Gemini 2.5와 3. 비용이 최상위 성능보다 중요하다면, 특히 좁고 잘 정의된 작업에서는 DeepSeek-V3.2나 Qwen 3.6.
모델을 교체 가능한 것으로 취급해라. 에이전트가 하나의 모델로만 작동한다면 그것은 해자가 아니라 악취다. 평가를 사용하여 무엇을 배포할지 결정해라. 매주가 아니라 매 분기마다 재평가해라.
건너뛸 것
이 모든 것을 배우고 구축하라는 말을 들을 것이다. 그럴 필요 없다. 건너뛰는 비용은 낮다. 절약되는 시간은 크다.
프로덕션을 위한 AutoGen과 AG2. Microsoft의 프레임워크는 커뮤니티 유지보수로 이동했고, 릴리스는 정체되었으며, 추상화는 프로덕션 팀이 실제로 필요로 하는 것과 일치하지 않는다. 학술적 탐구에는 괜찮다. 제품을 여기에 고정하지 마라.
새로운 프로덕션 구축을 위한 CrewAI. 데모가 쉽기 때문에 어디에나 있다. 실제 시스템을 구축하는 엔지니어들은 이미 떠났다. 프로토타입에 사용하고 싶다면 써라. 거기에 커밋하지 마라.
Microsoft Semantic Kernel - Microsoft 엔터프라이즈 스택에 잠겨 있고 구매자들이 그것을 신경 쓰는 경우가 아니라면. 생태계가 향하는 곳이 아니다.
DSPy - 규모에 맞춰 프롬프트 프로그램을 최적화하는 경우가 아니라면. 철학적 가치는 있지만, 틈새 청중. 일반 에이전트 프레임워크가 아니다. 그런 용도로 선택하지 마라.
아키텍처 선택으로서의 독립형 코드 작성 에이전트. 행동으로서의 코드는 흥미로운 연구다. 아직 프로덕션 기본 패턴이 아니며, 경쟁자들이 겪지 않는 도구 및 보안 전투를 치르게 될 것이다.
“자율 에이전트” 피치. AutoGPT와 BabyAGI 계보는 제품 형태로는 죽었다. 업계가 정착한 정직한 프레이밍은 “에이전틱 엔지니어링”이다: 감독되고, 경계 지어지고, 평가되는 것. 2026년에 여전히 배포 후 방치하는 자율 에이전트를 판매하는 사람은 2023년을 팔고 있는 것이다.
에이전트 앱 스토어와 마켓플레이스. 2023년부터 약속되어 왔지만, 엔터프라이즈 트랙션을 얻지 못했다. 기업은 일반적인 기성품 에이전트를 사지 않는다. 그들은 성과에 연결된 수직형 에이전트를 사거나, 직접 구축한다. 앱 스토어의 꿈을 중심으로 비즈니스를 구조화하지 마라.
고객으로서의 수평형 “모든 에이전트 구축” 엔터프라이즈 플랫폼 (Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio 티어). 결국에는 유용해질 것이다. 지금은 혼란스럽고, 배포가 느리며, 구매 대 구축 계산은 여전히 좁은 에이전트를 직접 구축하거나 수직형을 구매하는 쪽에 유리하다. Salesforce Agentforce와 ServiceNow Now Assist는 이미 사용 중인 워크플로우 시스템에 내장되어 승리하기 때문에 예외다.
SWE-bench와 OSWorld 리더보드 추적. 버클리 연구자들은 2025년을 통해 거의 모든 공개 벤치마크가 기반 작업을 해결하지 않고도 게임화될 수 있다고 문서화했다. 팀들은 이제 Terminal-Bench 2.0과 자체 내부 평가를 실제 시그널로 사용한다. 단일 숫자 벤치마크 도약은 기본적으로 회의적으로 대하라.
순진한 병렬 멀티 에이전트 아키텍처. 공유 메모리를 두고 대화하는 다섯 개의 에이전트는 데모에서는 인상적으로 보이지만 프로덕션에서는 무너진다. 냅킨에 읽기/쓰기 경계를 가진 깔끔한 오케스트레이터-서브에이전트 다이어그램을 그릴 수 없다면 배포하지 마라.
새로운 에이전트 제품을 위한 시트당 SaaS 가격 책정. 시장은 성과와 사용량 기반으로 이동했다. 시트당 가격 책정은 돈을 테이블 위에 남기고 구매자에게 당신이 자신의 제품이 성과를 낼 것이라고 믿지 않는다는 신호를 보낸다.
이번 주 해커뉴스에서 보는 다음 프레임워크. 6개월 기다려라. 여전히 중요하다면 명백할 것이다. 그렇지 않다면 마이그레이션을 절약한 것이다.
실제로 움직이는 방법
에이전트를 따라잡는 것이 아니라 도입하려고 한다면, 이 순서가 작동한다. 지루하다. 작동한다.
이미 중요한 하나의 성과를 골라라. 문샷이 아니다. 수평적인 “에이전트 플랫폼” 프로젝트가 아니다. 비즈니스가 이미 신경 쓰는 측정 가능한 무언가. 지원 티켓 전환. 1차 법률 검토 초안 작성. 인바운드 리드 자격 평가. 월간 보고서 생성. 그 성과가 움직일 때 에이전트가 성공한 것이다. 이것이 첫날부터 당신의 평가 대상이 된다.
이 단계가 그 무엇보다 중요한 이유는 이후의 모든 결정을 제약하기 때문이다. 구체적인 성과가 있으면 “어떤 프레임워크”라는 질문이 철학적 논쟁이 아니게 된다. 당신의 성과를 가장 빨리 출시하는 것을 고른다. “어떤 모델”이라는 질문이 벤치마크 논쟁이 아니게 된다. 평가가 이 특정 작업에서 작동한다고 말하는 것을 고른다. “메모리/서브에이전트/커스텀 하네스가 필요한가”라는 질문이 사고 실험이 아니게 된다. 특정 실패 모드가 요구하는 것만 추가한다. 이 단계를 건너뛰는 팀은 아무도 요청하지 않은 수평적 플랫폼을 구축하게 된다. 진지하게 받아들이는 팀은 한 분기 만에 비용을 회수하는 단일 좁은 에이전트를 출시하게 되고, 그 출시된 단일 에이전트가 2년간의 독서보다 이 분야에 대해 더 많은 것을 가르쳐준다.
아무것도 배포하기 전에 트레이싱과 평가를 설정해라. Langfuse나 LangSmith를 골라라. 연결해라. 필요하다면 손으로 작은 골든 데이터셋을 구축해라. 레이블된 50개의 예제로 시작하기에 충분하다. 측정할 수 없는 것은 개선할 수 없다. 이것을 나중에 구축하는 비용은 지금 구축하는 비용의 약 10배다.
단일 에이전트 루프로 시작해라. LangGraph나 Pydantic AI를 골라라. 모델로 Claude Sonnet 4.6이나 GPT-5를 골라라. 에이전트에게 잘 설계된 3~7개의 도구를 줘라. 파일 시스템이나 데이터베이스를 상태로 줘라. 작은 청중에게 배포해라. 트레이스를 관찰해라.
에이전트를 프로젝트가 아닌 제품으로 취급해라. 예측하지 못한 방식으로 실패할 것이다. 그 실패들이 당신의 로드맵이다. 실제 프로덕션 트레이스로부터 회귀 세트를 구축해라. 모든 프롬프트 변경, 모든 모델 교체, 모든 도구 변경은 배포 전에 평가를 통과한다. 이것이 대부분의 팀이 과소 투자하는 지점이다. 이것이 대부분의 신뢰성이 나오는 곳이다.
자격을 얻었을 때만 범위를 추가해라. 서브에이전트는 컨텍스트가 병목일 때 들어온다. 메모리 프레임워크는 단일 윈도우 컨텍스트가 필요한 것을 담을 수 없을 때 들어온다. 컴퓨터 사용이나 브라우저 사용은 기반 API가 정말로 없을 때 들어온다. 이것들을 미리 아키텍처링하지 마라. 실패 모드가 이것들을 끌어들이게 해라.
지루한 인프라를 골라라. 도구에는 MCP. 샌드박스에는 E2B나 Browserbase. 상태에는 Postgres나 이미 실행 중인 어떤 데이터 저장소든. 기존의 인증 및 관측 가능성 스택. 이국적인 인프라는 거의 승리가 아니다. 규율이 승리다.
첫날부터 단위 경제를 관찰해라. 액션당 비용. 캐시 히트율. 재시도 루프 비용. 모델 호출 분포. 에이전트는 PoC에서는 저렴해 보이지만, 처음부터 성과당 비용을 계측하지 않으면 100배 규모에서 폭발한다. 실행당 50K가 된다. 이를 예측하지 못한 팀은 즐겁지 않은 CFO 미팅을 갖게 된다.
모델을 매주가 아니라 매 분기마다 재평가해라. 한 분기 동안 고정해라. 분기 말에 현재 프론티어에 대해 평가 스위트를 실행하고 데이터가 전환하라고 말하면 전환해라. 모든 릴리스를 쫓는 혼란 없이 모델 개선의 이점을 얻는다.
조류 읽기
무언가가 시그널이라는 구체적인 신호:
존경받는 엔지니어링 팀이 도입 주장만이 아닌 숫자가 담긴 포스트모템을 작성한다. 래퍼나 번들이 아닌 기본 요소(프로토콜, 패턴, 인프라)다. 교체하는 대신 이미 실행 중인 것과 상호운용된다. 피치는 활성화하는 기능이 아니라 해결하는 실패 모드를 설명한다. 그것에 대해 “무엇이 작동하지 않았는가” 블로그 게시물이 작성될 만큼 오래되었다.
무언가가 노이즈라는 구체적인 신호:
30일 후에도 프로덕션 사례 연구가 없는 데모 비디오. 진짜라고 하기에는 너무 깔끔한 벤치마크 도약. 자격 없이 “자율”, “에이전트 OS”, “모든 에이전트 구축”을 사용하는 피치. 기존 트레이싱, 인증, 설정을 버릴 것이라고 가정하는 프레임워크 문서. 커밋, 릴리스, 기여자가 함께 상승하지 않고 별 개수만 빠르게 오르는 것. GitHub 속도 없는 Twitter 속도.
유용한 주간 습관: 금요일에 이 분야를 위해 30분을 확보해라. 세 가지를 읽어라. Anthropic의 엔지니어링 블로그. Simon Willison의 노트. Latent Space. 포스트모템이 있다면 하나나 둘 훑어봐라. 그 주의 다른 모든 것은 건너뛰어라. 중요한 것들은 알게 될 것이다.
주목할 만한 것들
다음 두 분기 동안 주목할 가치가 있는 것들. 보장된 승리여서가 아니라 “이것이 시그널인가?”라는 질문이 아직 완전히 해결되지 않았기 때문이다:
Replit Agent 4의 병렬 포킹 모델. 공유 상태에 걸려 넘어지지 않는 “병렬로 작업하는 여러 에이전트”에 대한 첫 진지한 시도. 규모에서 유지된다면 오케스트레이터-서브에이전트 기본값이 바뀔 수 있다.
성과 기반 가격 책정의 성숙. Sierra와 Harvey의 수익 궤적은 좁은 수직 영역 내에서 이를 검증한다. 질문은 이것이 외부로 일반화될지, 아니면 수직 전용 모델로 남을지다.
패키징 레이어로서의 스킬. GitHub 전역에 AGENTS.md와 skills 디렉토리가 확산되는 것은 에이전트 기능을 패키징하는 새로운 방식을 시사한다. MCP가 도구에 대해 그랬던 것처럼 표준화될지는 열린 질문이다.
Claude Code의 2026년 4월 품질 회귀와 그 포스트모템. 업계 선도 에이전트가 47% 성능 회귀를 배포했고 내부 모니터링이 잡기 전에 사용자가 발견했다. 이것은 리더들조차 프로덕션 에이전트 평가 관행이 얼마나 미성숙한지에 대한 교훈이다. 이것이 더 나은 온라인 평가에 대한 업계 전반의 투자를 이끈다면, 그 수정은 건강하다.
기본 지원 표면으로서의 음성. Sierra의 음성 채널이 2025년 말에 텍스트를 넘어섰다. 이 패턴이 다른 수직 영역에서도 유지된다면, 설계 제약(지연, 중단, 실시간 도구 사용)이 일급이 되고, 현재의 많은 아키텍처는 재작업이 필요하다.
오픈 모델 에이전트 능력의 격차 해소. 네이티브 사고-도구 사용을 갖춘 DeepSeek-V3.2. Qwen 3.6. 더 넓은 오픈소스 환경. 좁은 에이전트 작업에 대한 비용 대비 성능이 이동하고 있다. 클로즈드 소스 기본값은 영구적이지 않다.
이 각각은 “6개월 후에 그것이 중요하다고 믿으려면 무엇을 봐야 하는가”라는 명확한 답을 가지고 있다. 그것이 테스트다. 발표가 아니라 답을 추적해라.
비전통적인 베팅
당신이 도입하지 않은 모든 프레임워크는 당신이 지지 않아도 될 마이그레이션이다. 당신이 쫓지 않은 모든 벤치마크는 당신이 유지하는 한 분기의 집중이다. 이 사이클에서 승리하는 회사들(Sierra, Harvey, Cursor 각각의 도메인에서)은 좁은 목표를 선택하고, 지루한 규율을 구축하고, 이 분야의 노이즈를 흘려보냈다.
전통적인 경로는: 스택을 고르고, 수년간 마스터하고, 사다리를 오르는 것. 스택이 10년간 안정적일 때는 효과가 있었다. 이제 스택은 매 분기마다 변한다. 승리하는 사람들은 스택 숙련도를 최적화하는 것을 멈추고 안목, 기본 요소, 출시 속도를 최적화하기 시작했다. 그들은 공개적으로 작은 것들을 구축한다. 그들은 출시하면서 배운다. 그들은 이미 만든 것에 의해 방으로 끌려 들어간다. 자격 증명은 바로 그 결과물이다.
잠시 이것에 대해 생각해보라. 이것이 이 글 전체의 진짜 요점이기 때문이다. 우리 대부분은 자격 증명이 복리로 쌓일 만큼 세상이 충분히 오래 멈춰 있을 것이라고 가정하는 노동 모델 위에서 자랐다. 학교에 갔다. 학위를 땄다. 사다리를 올랐다. 여기서 2년, 저기서 3년, 그리고 천천히 이력서가 문을 여는 무언가로 변했다. 그 전체 기계는 그 반대편에 안정적인 산업이 있을 것이라고 가정했다.
에이전트 분야에는 지금 안정적인 반대편이 없다. 당신이 일하고 싶어할 회사들은 생긴 지 6개월 되었다. 그들이 구축된 프레임워크는 18개월 되었다. 그 아래의 프로토콜은 2년 되었다. 이 분야에서 가장 많이 인용된 게시물의 절반은 3년 전에는 이 분야에 없었던 사람들이 썼다. 건물이 계속 층을 바꾸기 때문에 오를 사다리가 없다. 사다리가 작동하지 않을 때 남는 것은 훨씬 더 오래된 방법이다: 무언가를 만들고, 인터넷에 올리고, 작업이 당신을 소개하게 하라. 이것이 비전통적인 경로인 이유는 자격 증명 시스템을 무시하기 때문이다. 또한 움직이는 분야에서 복리로 쌓이는 유일한 방법이기도 하다.
이것이 내부에서 본 이 시대의 모습이다. 거대 기업들조차 공개적으로 반복하고, 회귀를 배포하고, 포스트모템을 작성하고, 실시간으로 패치한다. 올해 가장 흥미로운 것들을 출시하는 팀에는 18개월 전에는 이 분야에 없었던 사람들이 포함되어 있다. 비개발자들이 에이전트와 페어링하여 실제 소프트웨어를 출시하고 있다. 박사들은 올바른 기본 요소를 선택하고 휘두르기 시작한 빌더들에게 앞서가고 있다. 문은 열려 있다. 대부분의 사람들은 여전히 지원서 양식을 찾고 있다.
지금 당장 실제로 개발해야 할 기술은 “에이전트”가 아니다. 표면이 계속 변하는 분야에서 어떤 작업이 복리로 쌓이는지 분별하는 규율이다. 컨텍스트 엔지니어링은 복리로 쌓인다. 도구 설계는 복리로 쌓인다. 오케스트레이터-서브에이전트 패턴은 복리로 쌓인다. 평가 규율은 복리로 쌓인다. 하네스 마인드셋은 복리로 쌓인다. 화요일에 출시된 프레임워크의 API를 아는 것은 그렇지 않다. 이 둘을 구별할 수 있게 되면, 주간 출시의 물결은 압박감이 아니라 무시할 수 있는 노이즈처럼 느껴지기 시작한다.
모든 것을 배울 필요는 없다. 복리로 쌓이는 것을 배우고 그렇지 않은 것은 건너뛰면 된다. 하나의 성과를 골라라. 배포하기 전에 트레이싱과 평가를 연결해라. LangGraph나 팀의 동등한 것을 사용해라. MCP를 사용해라. 런타임을 샌드박싱해라. 기본값은 단일 에이전트로 해라. 실패 모드가 끌어들일 때 범위를 추가해라. 모델은 매 분기마다 재평가해라. 금요일에 세 가지를 읽어라.
이것이 플레이북이다. 나머지는 안목, 출시 속도, 중요하지 않은 것을 쫓지 않는 인내심이다. 무언가를 만들어라. 인터넷에 올려라. 이 시대는 무언가를 설명할 수 있는 사람보다 무언가를 만드는 사람에게 보상한다. 만드는 사람이 되기에 이보다 더 좋은 창은 없었다.