AI 에이전트: 2026 년에 배워야 할 것, 만들어야 할 것, 그리고 피해야 할 것

매일 새로운 프레임워크, 새로운 벤치마크, 새로운 "10배" 출시가 쏟아집니다. 질문은 더 이상 "어떻게 따라잡지?"가 아닙니다. 진짜 신호는 무엇이고, 긴급함이라는 옷을 입은 잡음은 무엇인지가 중요해집니다.

모든 로드맵은 출시 한 달 만에 구식이 됩니다. 지난 분기에 마스터한 프레임워크는 이제 레거시입니다. 최적화했던 벤치마크는 이미 조작되고 대체되었습니다. 우리는 전통적인 경로를 따르도록 길들여졌습니다: 주제와 수준이 있는 스택, 일련의 직업과 재직 기간, 느린 성장. AI는 그 캔버스를 다시 그렸습니다. 올바른 프롬프트와 적절한 안목만 있다면, 이제 누구나 2년 차 엔지니어가 한 스프린트에 해내던 작업을 출시할 수 있습니다.

전문성은 여전히 중요합니다. 시스템이 고장 나는 것을 지켜본 경험, 새벽 2시에 메모리 누수를 디버깅한 경험, 영리한 선택보다 지루한 선택을 주장하고 옳았다는 것이 증명된 경험을 대체할 수 있는 것은 없습니다. 그런 안목은 복리로 쌓입니다. 더 이상 예전처럼 복리로 쌓이지 않는 것은: 이번 주 프레임워크의 API 표면을 아는 것입니다. 6개월 후면 달라질 것입니다. 2년 후에 승리하는 사람들은 내구성 있는 프리미티브를 일찍 선택하고 나머지는 흘려보낸 사람들입니다.

저는 이 분야에서 2년 동안 구축해 왔으며, 25만 달러가 넘는 여러 제안을 성사시켰고, 현재 스텔스 모드 회사에서 기술을 총괄하고 있습니다. 이것은 "지금 실제로 무엇에 주목해야 합니까?"라고 묻는 사람에게 보낼 내용입니다.

로드맵이 아닙니다. 에이전트 분야에는 아직 목적지가 없습니다. 대규모 연구소들은 공개적으로 반복하고, 수백만 사용자에게 회귀를 출시하고, 사후 분석을 작성하고, 실시간으로 패치를 적용하고 있습니다. Claude Code 팀이 47%의 성능 회귀를 출시하고 사용자 커뮤니티가 발견한 후에야 알아차릴 수 있다면, 그 밑에 안정적인 지도가 있다는 생각은 허구입니다. 모두가 알아내고 있는 중입니다. 스타트업이 번성하는 이유는 거인들도 모르기 때문입니다. 비개발자들은 에이전트와 협력하여 금요일에 ML 박사들이 화요일에 불가능하다고 말했던 것들을 출시하고 있습니다.

이 순간의 흥미로운 점은 자격 증명에 대한 질문에 어떤 영향을 미치는지입니다. 전통적인 경로는 자격 증명을 위해 최적화되었습니다: 학위, 주니어 역할, 시니어 역할, 스태프 역할, 느린 계급 축적. 이것은 당신 아래의 분야가 움직이지 않을 때 합리적이었습니다. 이제 분야는 모든 사람 아래에서 동등하게 움직입니다. 공개적으로 에이전트 데모를 출시하는 22세와 35세 시니어 엔지니어의 차이는 더 이상 10년의 축적된 스택 숙달이 아닙니다. 22세는 시니어와 동일한 빈 캔버스를 가지고 있으며, 둘 중 누구에게나 복리로 작용하는 것은 출시하려는 의지와 분기에 구식화되지 않는 작은 프리미티브 목록입니다.

이것이 이 글 전체가 기반으로 하는 재구성입니다. 다음은 어떤 프리미티브가 주목할 가치가 있고 어떤 출시를 흘려보낼지 생각하는 방법입니다. 맞는 것을 선택하세요. 맞지 않는 것은 놔두세요.

실제로 작동하는 필터

매주 출시되는 것을 따라잡을 수 없습니다. 시도해서도 안 됩니다. 필요한 것은 피드가 아니라 필터입니다.

지난 18개월 동안 다섯 가지 테스트가 유효했습니다. 출시를 스택에 적용하기 전에 이 테스트를 실행하세요.

2년 후에도 중요할까요? 프론티어 모델, CLI 플래그, 또는 "X를 위한 Devin"의 래퍼라면 대답은 거의 항상 '아니오'입니다. 프리미티브(프로토콜, 메모리 패턴, 샌드박싱 접근 방식)라면 대답은 더 자주 '예'입니다. 래퍼의 반감기는 짧습니다. 프리미티브의 반감기는 수년입니다.

존경하는 누군가가 그 위에 실제 무언가를 구축하고 정직하게 글을 썼나요? 마케팅 게시물은 포함되지 않습니다. 사후 분석은 포함됩니다. "우리는 X를 프로덕션에서 시도했고 여기서 고장 났습니다"라는 블로그는 10개의 출시 발표만큼 가치가 있습니다. 이 분야의 좋은 신호는 항상 주말을 희생한 사람이 씁니다.

채택하려면 추적, 재시도, 구성, 인증을 모두 버려야 하나요? 그렇다면 플랫폼이 되려는 프레임워크입니다. 플랫폼이 되려는 프레임워크는 90%의 사망률을 보입니다. 좋은 프리미티브는 마이그레이션을 강요하지 않고 기존 시스템에 슬롯 인됩니다.

6개월 동안 건너뛰는 데 드는 비용은 얼마인가요? 대부분의 출시에서 대답은 '없음'입니다. 6개월 후에는 더 많이 알게 될 것입니다. 승리하는 버전이 더 명확해질 것입니다. 이것은 불안 없이 90%의 출시를 건너뛸 수 있게 해주는 테스트이며, 대부분의 사람들이 뒤처지는 것처럼 느껴지기 때문에 실행을 거부하는 테스트입니다. 그렇지 않습니다.

에이전트에 실제로 도움이 되는지 측정할 수 있나요? 측정할 수 없다면 추측하는 것입니다. 평가가 없는 팀은 분위기에 의존하고 회귀를 출시합니다. 평가가 있는 팀은 데이터를 통해 GPT-5.5 또는 Opus 4.7이 이번 주 특정 워크로드에서 승리하는지 알 수 있습니다.

이 글 전체에서 한 가지 습관을 들인다면 이것을 선택하세요: 새로운 것이 출시될 때, 6개월 후에 그것이 중요하다고 믿기 위해 무엇을 봐야 하는지 적어보세요. 그런 다음 돌아와서 확인하세요. 대부분의 경우 질문은 스스로 답할 것이며, 당신은 복리로 쌓이는 것들에 주의를 기울이게 될 것입니다.

이러한 테스트의 기반이 되는 기술은 그 어느 것보다 이름을 붙이기 어렵습니다. 선택하지 않은 것에 대해 쿨하지 않을 의지입니다. 이번 주 Hacker News에서 입소문을 타는 프레임워크는 14일 동안 응원군을 보유할 것이며, 그들은 모두 똑똑해 보일 것입니다. 6개월 후, 그 프레임워크의 절반은 유지 관리되지 않고 응원군은 다른 곳으로 이동했습니다. 참여하지 않은 사람들은 출시 과대 광고가 지나간 후에도 지루함의 테스트를 견딘 것들에 주의를 아꼈습니다. 그 자세, 즉 물러서서 지켜보고 "6개월 후에 알겠다"고 말하는 것이 이 분야의 실제 전문 기술입니다. 모든 사람이 출시를 읽을 수 있습니다. 거의 아무도 반응하지 않는 데 능숙하지 않습니다.

배울 것

개념. 패턴. 사물의 형태. 복리 수익을 가져다주는 아이디어들입니다. 모델 교체, 프레임워크 교체, 패러다임 전환을 견뎌냅니다. 깊이 이해하면 주말 안에 새로운 도구를 익힐 수 있습니다. 건너뛰면 표면 메커니즘을 영원히 다시 배우게 됩니다.

컨텍스트 엔지니어링

지난 2년간 가장 중요한 이름 변경은 "프롬프트 엔지니어링"이 "컨텍스트 엔지니어링"이 된 것입니다. 변화는 실제이며, 미용적인 것이 아닙니다.

모델은 더 이상 영리한 지시를 작성하는 대상이 아닙니다. 모든 단계에서 작업 컨텍스트를 조립하는 대상입니다. 그 컨텍스트는 시스템 지침, 도구 스키마, 검색된 문서, 이전 도구 출력, 스크래치패드 상태, 압축된 기록이 모두 동시에 포함됩니다. 에이전트의 행동은 창에 넣은 것의 창발적 속성입니다.

이것을 내면화하세요: 컨텍스트는 상태입니다. 관련 없는 노이즈의 모든 토큰은 추론 품질을 떨어뜨립니다. 컨텍스트 부패는 실제 프로덕션 실패입니다. 10단계 작업의 8단계에서 원래 목표는 도구 출력 아래에 묻힐 수 있습니다. 안정적인 에이전트를 출시하는 팀은 적극적으로 요약, 압축, 정리합니다. 도구 설명을 버전 관리합니다. 정적 부분을 캐시하고 변경되는 부분은 캐시하지 않습니다. 숙련된 엔지니어가 RAM에 대해 생각하는 방식으로 컨텍스트 창에 대해 생각합니다.

이것을 구체적으로 느끼는 방법: 프로덕션에서 에이전트를 선택하고 전체 추적 로깅을 켜세요. 1단계의 컨텍스트를 살펴보세요. 7단계의 컨텍스트를 살펴보세요. 그 토큰 중 얼마나 많은 토큰이 여전히 제 역할을 하고 있는지 세어보세요. 처음 이 작업을 하면 당황할 것입니다. 그런 다음 수정하고, 동일한 에이전트가 모델이나 프롬프트 변경 없이 눈에 띄게 더 안정적으로 변하는 것을 볼 수 있습니다.

이에 대해 한 가지를 읽는다면 Anthropic의 "AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링"을 읽으세요. 그런 다음 규모를 확장할 때 컨텍스트 격리가 얼마나 중요한지 수치로 보여주는 다중 에이전트 연구 사후 분석을 읽으세요.

도구 설계

도구는 에이전트가 비즈니스를 만나는 곳입니다. 모델은 이름과 설명을 기반으로 도구를 선택합니다. 모델은 오류 메시지를 기반으로 재시도합니다. 모델은 도구의 계약이 LLM이 표현하는 데 능숙한 것과 일치하는지 여부에 따라 성공하거나 실패합니다.

잘 명명된 5~10개의 도구가 20개의 평범한 도구를 능가합니다. 도구 이름은 영어 동사구처럼 읽혀야 합니다. 설명에는 도구를 사용해야 하는 경우와 사용하지 말아야 하는 경우가 포함되어야 합니다. 오류 메시지는 모델이 조치를 취할 수 있는 피드백이어야 합니다. "최대 토큰 500 초과, 먼저 요약해 보세요"는 "오류: 400 잘못된 요청"보다 훨씬 낫습니다. 한 공개 연구 팀은 오류 메시지만 다시 작성한 후 재시도 루프가 40% 감소했다고 보고했습니다.

Anthropic의 "에이전트를 위한 도구 작성"이 올바른 시작점입니다. 그 후, 자신의 도구를 계측하고 실제 호출 패턴을 살펴보세요. 에이전트 안정성의 가장 큰 개선은 거의 항상 도구 측에서 발생합니다. 사람들은 계속해서 프롬프트를 조정하고 실제 레버리지가 있는 곳을 무시합니다.

오케스트레이터-서브에이전트 패턴

2024년과 2025년의 다중 에이전트 논쟁은 이제 모든 사람이 출시하는 종합으로 끝났습니다. 여러 에이전트가 공유 상태에 병렬로 쓰는 순진한 다중 에이전트 시스템은 오류가 누적되기 때문에 치명적으로 실패합니다. 단일 에이전트 루프는 예상보다 더 확장됩니다. 프로덕션에서 작동하는 하나의 다중 에이전트 형태가 있습니다: 격리된 서브에이전트에게 범위가 좁은 읽기 전용 작업을 위임한 다음 결과를 종합하는 오케스트레이터 에이전트입니다.

이것이 Anthropic의 연구 시스템이 작동하는 방식입니다. Claude Code의 서브에이전트가 작동하는 방식입니다. Spring AI와 대부분의 프로덕션 프레임워크가 현재 표준화하는 패턴입니다. 서브에이전트는 작고 집중된 컨텍스트를 얻습니다. 공유 상태를 변경할 수 없습니다. 오케스트레이터가 쓰기를 소유합니다.

Cognition의 "다중 에이전트를 구축하지 마세요" 에세이와 Anthropic의 "다중 에이전트 연구 시스템을 구축한 방법"은 반대처럼 보이지만 다른 어휘로 같은 것을 말하고 있습니다. 둘 다 읽으세요.

기본값은 단일 에이전트입니다. 단일 에이전트가 실제 벽에 부딪힐 때만 오케스트레이터-서브에이전트를 사용하세요: 컨텍스트 창 압박, 순차적 도구 호출로 인한 지연 시간, 또는 집중된 컨텍스트의 이점을 실제로 얻는 작업 이질성. 고통을 느끼기 전에 이것을 구축하면 필요하지 않은 복잡성을 출시하게 됩니다.

평가 및 골든 데이터셋

안정적인 에이전트를 출시하는 모든 팀에는 평가가 있습니다. 그렇지 않은 팀은 없습니다. 이것은 이 분야에서 가장 레버리지가 높은 습관이며, 제가 살펴본 모든 회사에서 가장 과소 투자된 부분입니다.

작동하는 것: 프로덕션 추적을 수집하고, 실패에 레이블을 지정하고, 회귀 세트로 취급합니다. 새로운 실패가 출시될 때마다 추가합니다. 주관적인 부분에는 LLM-as-judge를 사용하고, 나머지에는 정확한 일치 또는 프로그래매틱 검사를 사용합니다. 프롬프트, 모델 또는 도구 변경 전에 스위트를 실행합니다. Spotify의 엔지니어링 블로그는 판사 계층이 출시 전에 에이전트 출력의 약 25%를 거부한다고 보고했습니다. 그것 없이는 네 개의 잘못된 결과 중 하나가 사용자에게 도달했을 것입니다.

이것을 지속하게 만드는 정신 모델: 평가는 그 아래의 모든 것이 변경되는 동안 에이전트를 정직하게 유지하는 단위 테스트입니다. 모델은 새 버전을 얻습니다. 프레임워크는 획기적인 변경을 출시합니다. 공급업체는 엔드포인트를 더 이상 사용하지 않습니다. 평가는 에이전트가 여전히 제 역할을 하고 있는지 알려주는 유일한 것입니다. 평가 없이는 정확성이 움직이는 표적의 호의에 의존하는 시스템을 작성하는 것입니다.

평가 프레임워크(Braintrust, Langfuse 평가, LangSmith)는 괜찮습니다. 그들 중 어느 것도 병목 현상이 아닙니다. 병목 현상은 먼저 레이블이 지정된 세트를 보유하는 것입니다. 아무것도 확장하기 전에 첫날에 구축하세요. 처음 50개의 예제는 오후에 수동으로 레이블을 지정할 수 있습니다. 변명의 여지가 없습니다.

파일 시스템을 상태로 사용하는 사고-행동-관찰 루프

실제 다단계 작업을 수행하는 모든 에이전트에게 내구성 있는 아키텍처는 다음과 같습니다: 생각하고, 행동하고, 관찰하고, 반복합니다. 파일 시스템 또는 구조화된 저장소를 진실의 원천으로 사용합니다. 모든 작업이 기록되고 재생 가능합니다. Claude Code, Cursor, Devin, Aider, OpenHands, goose. 모두 이유가 있어서 이것에 수렴했습니다.

모델은 상태 비저장입니다. 하네스는 상태 저장이어야 합니다. 파일 시스템은 모든 개발자가 이미 이해하는 상태 저장 프리미티브입니다. 이 프레이밍을 수용하면 전체 하네스 규율(체크포인팅, 재개 가능성, 서브에이전트 검증, 샌드박스 실행)이 패턴을 진지하게 받아들이는 것에서 비롯됩니다.

이것이 가르쳐주는 더 깊은 것: 계산 비용을 정당화하는 프로덕션 에이전트에서 하네스는 모델보다 더 많은 작업을 수행하고 있습니다. 모델은 다음 작업을 선택합니다. 하네스는 이를 검증하고, 샌드박스에서 실행하고, 출력을 캡처하고, 무엇을 다시 공급할지 결정하고, 언제 중단할지 결정하고, 언제 체크포인트할지 결정하고, 언제 서브에이전트를 생성할지 결정합니다. 모델을 유사한 품질의 다른 모델로 교체해도 좋은 하네스는 여전히 출시됩니다. 하네스를 더 나쁜 것으로 교체하면 최고의 모델도 무작위로 무엇을 하고 있었는지 잊어버리는 에이전트를 생성합니다.

단일 샷 도구 호출보다 더 정교한 것을 구축하는 경우 하네스에 시간을 투자해야 합니다. 모델은 그 안의 구성 요소입니다.

개념적으로 MCP

MCP 서버를 호출하는 방법만 배우지 마세요. 모델을 배우세요. 확장 가능한 인증 및 전송 스토리가 아래에 있는 에이전트 기능, 도구 및 리소스 간의 깔끔한 분리. 일단 이해하면, 보게 될 다른 모든 "에이전트 통합 프레임워크"는 MCP의 더 나쁜 버전처럼 보일 것이며, 각각을 평가하는 시간을 절약할 수 있습니다.

Linux Foundation이 이제 관리합니다. 모든 주요 모델 제공업체가 지원합니다. "AI의 USB-C" 비교는 이제 아이러니보다 더 정확합니다.

프리미티브로서의 샌드박싱

모든 프로덕션 코딩 에이전트는 샌드박스에서 실행됩니다. 모든 브라우저 에이전트는 간접 프롬프트 주입의 영향을 받았습니다. 모든 다중 테넌트 에이전트는 어느 시점에서 권한 범위 지정 버그가 출시되었습니다. 샌드박싱을 고객이 요청할 때 추가하는 기능이 아닌 프리미티브 인프라로 취급하세요.

기본 사항을 배우세요. 프로세스 격리. 네트워크 이그레스 제어. 비밀 범위 지정. 에이전트와 도구 간의 인증 경계. 고객 보안 검토 후에 이것을 추가하는 팀은 거래를 잃는 팀입니다. 1주차부터 구축하는 팀은 땀 흘리지 않고 엔터프라이즈 조달을 통과합니다.

함께 구축할 것

2026년 4월의 특정 선택. 이것들은 천천히 바뀔 것입니다. 여기서는 지루하게 선택하세요.

오케스트레이션

LangGraph가 프로덕션 기본값입니다. 에이전트를 실행하는 대기업의 약 1/3이 사용합니다. 추상화는 에이전트 시스템의 실제 형태와 일치합니다: 타입이 지정된 상태, 조건부 에지, 내구성 있는 워크플로, 인간-인-더-루프 체크포인트. 단점은 장황함입니다. 장점은 장황함이 에이전트가 프로덕션에 들어간 후 실제로 제어해야 하는 것과 일치한다는 것입니다.

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 리더보드 추적. Berkeley 연구원들은 2025년을 통해 거의 모든 공개 벤치마크가 기본 작업을 해결하지 않고도 조작될 수 있음을 문서화했습니다. 팀은 이제 Terminal-Bench 2.0 및 자체 내부 평가를 실제 신호로 사용합니다. 단일 숫자 벤치마크 도약을 기본적으로 회의적으로 취급하세요.

순진한 병렬 다중 에이전트 아키텍처. 공유 메모리를 통해 채팅하는 5개의 에이전트는 데모에서 인상적으로 보이지만 프로덕션에서 무너집니다. 냅킨에 읽기/쓰기 경계가 있는 깔끔한 오케스트레이터-서브에이전트 다이어그램을 그릴 수 없다면 출시하지 마세요.

새로운 에이전트 제품에 대한 좌석당 SaaS 가격 책정. 시장은 결과 및 사용량 기반으로 이동했습니다. 좌석당 가격 책정은 돈을 남기고 구매자에게 자체 제품이 결과를 제공할 것이라고 신뢰하지 않는다는 신호를 보냅니다.

이번 주 Hacker News에서 볼 다음 프레임워크. 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배 규모에서 폭발합니다. $0.50/실행 PoC는 적당한 볼륨에서 월 $50,000가 됩니다. 그것이 오는 것을 보지 못하는 팀은 즐겁지 않은 CFO 미팅을 갖게 됩니다.

모델을 매주가 아닌 분기별로 재평가하세요. 분기 동안 고정하세요. 분기 말에 현재 프론티어에 대해 평가 스위트를 실행하고 데이터가 전환을 지시하면 전환하세요. 모든 릴리스를 쫓는 혼란 없이 모델 개선의 이점을 얻을 수 있습니다.

흐름 읽기

무언가가 신호라는 구체적인 징후:

(Note: The original text ends with "Concrete tells that something is signal:" without further content. The translation reflects this.)

존경받는 엔지니어링 팀이 단순한 도입 주장이 아닌, 숫자로 뒷받침된 사후 분석(postmortem)을 작성합니다. 그것은 래퍼(wrapper)나 번들(bundle)이 아닌, 원시 요소(프로토콜, 패턴, 인프라)입니다. 기존 시스템을 대체하는 대신, 이미 운영 중인 시스템과 상호 운용됩니다. 그 제안은 활성화하는 기능이 아니라 해결하는 실패 모드를 설명합니다. 그리고 "무엇이 실패했는가"에 대한 블로그 게시물이 나올 정도로 오래된 기술입니다.

노이즈(noise)임을 알려주는 구체적인 신호들은 다음과 같습니다:

출시 후 30일이 지났는데도 프로덕션 사례 연구 없이 데모 비디오만 있는 경우. 너무 깔끔해서 현실적이지 않은 벤치마크 성능 향상. "자율적(autonomous)", "에이전트 OS(agent OS)", 또는 "모든 에이전트 구축"이라는 표현을 조건 없이 사용하는 제안. 기존의 추적, 인증, 설정을 모두 폐기할 것을 가정하는 문서를 제공하는 프레임워크. 커밋, 릴리스, 기여자 수는 정체된 채 스타(star) 수만 빠르게 증가하는 경우. GitHub 활동 없이 트위터(Twitter)에서만 활발한 경우.

유용한 주간 습관 하나: 금요일에 30분을 할애해 이 분야를 살펴보세요. 세 가지를 읽으십시오. Anthropic의 엔지니어링 블로그. Simon Willison의 노트. Latent Space. 만약 새로운 사후 분석이 나왔다면 한두 개를 훑어보세요. 그 주의 다른 모든 것은 건너뛰세요. 그러면 정말 중요한 것들을 알게 될 것입니다.

주목할 가치가 있는 것들

향후 두 분기 동안 주목할 가치가 있는 것들입니다. 반드시 성공할 것이라고 확신해서가 아니라, "이것이 신호(signal)인가?"라는 질문이 아직 완전히 해결되지 않았기 때문입니다.

Replit Agent 4의 병렬 분기 모델. "여러 에이전트가 병렬로 작업하는" 방식에 대한 최초의 진지한 시도로, 공유 상태(shared state) 문제에 부딪히지 않습니다. 만약 이것이 대규모로 유지된다면, 오케스트레이터-서브에이전트(orchestrator-subagent) 기본값이 바뀔 수 있습니다.

결과 기반 가격 책정의 성숙도. Sierra와 Harvey의 수익 궤적은 좁은 수직적 영역 내에서 이를 검증했습니다. 문제는 이것이 수직적 영역 밖으로 일반화될 수 있는지, 아니면 수직적 영역 전용 모델로 남을지입니다.

패키징 레이어로서의 스킬(Skills). GitHub 전반에 걸친 AGENTS.md와 스킬 디렉토리의 확산은 에이전트 기능을 패키징하는 새로운 방식을 시사합니다. 이것이 MCP가 도구(tools)에 대해 그랬던 것처럼 표준화될지는 여전히 미해결 질문입니다.

Claude Code의 2026년 4월 품질 저하와 그 사후 분석. 업계를 선도하는 에이전트가 47%의 성능 저하를 겪었고, 내부 모니터링이 이를 감지하기 전에 사용자에게 먼저 발견되었습니다. 이는 프로덕션 에이전트 평가 관행이 선두 기업에서조차 얼마나 미성숙한지 보여주는 교훈입니다. 만약 이것이 업계 전반에 걸쳐 더 나은 온라인 평가에 대한 투자를 촉진한다면, 그 시정은 건강한 것입니다.

기본 지원 인터페이스로서의 음성(Voice). Sierra의 음성 채널은 2025년 후반에 텍스트를 넘어섰습니다. 만약 이 패턴이 다른 수직적 영역에서도 유지된다면, 설계 제약 조건(지연 시간, 중단, 실시간 도구 사용)이 최우선 과제가 되며, 많은 현재 아키텍처는 재설계가 필요할 것입니다.

격차를 좁히는 오픈 모델 에이전트 성능. 네이티브 사고-도구 사용(native thinking-into-tool-use)을 갖춘 DeepSeek-V3.2. Qwen 3.6. 더 넓은 오픈소스 환경. 좁은 에이전트 작업을 위한 비용 대비 성능이 변화하고 있습니다. 폐쇄형 소스가 기본값인 시대는 영원하지 않습니다.

이 각각에는 "6개월 안에 무엇을 보게 된다면 이것을 믿을 수 있을까"라는 명확한 답이 있습니다. 그것이 바로 시험입니다. 발표가 아닌 그 답을 추적하세요.

파격적인 선택

당신이 채택하지 않는 모든 프레임워크는 당신이 갚지 않아도 될 마이그레이션(migration)입니다. 당신이 쫓지 않는 모든 벤치마크는 당신이 유지하는 한 분기의 집중력입니다. 이번 사이클에서 승리하는 회사들(Sierra, Harvey, Cursor는 각자의 영역에서)은 좁은 목표를 선택하고, 지루할 정도로 기본에 충실했으며, 현장의 노이즈를 무시했습니다.

전통적인 길은 다음과 같았습니다: 스택을 선택하고, 수년간 마스터하며, 사다리를 오르는 것. 그것은 스택이 10년 동안 안정적이었을 때 통했습니다. 이제 스택은 분기마다 바뀝니다. 승리하는 사람들은 스택 마스터리에 최적화하는 것을 멈추고 취향(taste), 원시 요소(primitives), 그리고 출시 속도(ship velocity)에 최적화하기 시작했습니다. 그들은 공개적으로 작은 것들을 만듭니다. 그들은 출시를 통해 배웁니다. 그들은 이미 만든 것 덕분에 중요한 자리로 불려갑니다. 자격 증명은 바로 그 결과물(the artifact)입니다.

잠시 이것에 대해 생각해보세요. 이것이 이 글의 진짜 요점이기 때문입니다. 우리 대부분은 세상이 자격 증명이 쌓일 수 있을 만큼 충분히 오래 멈춰 있을 것이라는 가정 위에 세워진 업무 모델에서 자랐습니다. 학교에 갔습니다. 학위를 받았습니다. 사다리를 올랐습니다. 여기서 2년, 저기서 3년, 그리고 천천히 이력서는 문을 여는 열쇠가 되었습니다. 그 전체 시스템은 그 반대편에 안정적인 산업이 있다고 가정했습니다.

에이전트 공간에는 지금 안정적인 반대편이 없습니다. 당신이 일하고 싶어할 만한 회사들은 생긴 지 6개월 되었습니다. 그들이 기반으로 하는 프레임워크는 18개월 되었습니다. 그 아래에 있는 프로토콜은 2년 되었습니다. 이 분야에서 가장 많이 인용된 게시물의 절반은 3년 전만 해도 이 분야에 없었던 사람들이 썼습니다. 오를 사다리가 없습니다. 건물의 층이 계속 바뀌기 때문입니다. 사다리가 통하지 않을 때 남는 것은 훨씬 더 오래된 방법입니다: 무언가를 만들고, 인터넷에 올리고, 그 작업이 당신을 소개하게 하는 것. 이것이 파격적인 길인 이유는 자격 증명 시스템을 무시하기 때문입니다. 또한 변화하는 분야에서 유일하게 축적(compounds)되는 길이기도 합니다.

이것이 내부에서 본 이 시대의 모습입니다. 거인들조차 공개적으로 반복하고, 성능 저하를 출시하고, 사후 분석을 작성하고, 실시간으로 패치를 적용하고 있습니다. 올해 가장 흥미로운 것들을 출시하는 팀에는 18개월 전만 해도 이 분야에 없었던 사람들이 포함되어 있습니다. 비개발자들은 에이전트와 협력하여 실제 소프트웨어를 출시하고 있습니다. 박사 학위 소지자들은 올바른 원시 요소를 선택하고 실행에 옮긴 빌더(builder)들에게 뒤쳐지고 있습니다. 문은 열려 있습니다. 대부분의 사람들은 여전히 지원서를 찾고 있습니다.

당신이 지금 실제로 개발해야 할 기술은 "에이전트"가 아닙니다. 표면이 계속 변하는 분야에서 어떤 작업이 축적(compounds)되는지 파악하는 훈련입니다. 컨텍스트 엔지니어링(context engineering)은 축적됩니다. 도구 설계는 축적됩니다. 오케스트레이터-서브에이전트 패턴은 축적됩니다. 평가 훈련은 축적됩니다. 활용 마인드셋(harness mindset)은 축적됩니다. 화요일에 출시된 프레임워크의 API를 아는 것은 그렇지 않습니다. 이것들을 구분할 수 있게 되면, 매주 쏟아지는 출시 소식은 더 이상 압박감으로 느껴지지 않고 무시할 수 있는 노이즈로 느껴지기 시작합니다.

모든 것을 배울 필요는 없습니다. 축적되는 것들을 배우고 그렇지 않은 것들은 건너뛰어야 합니다. 하나의 결과를 선택하세요. 출시하기 전에 추적과 평가를 연결하세요. LangGraph 또는 팀에 맞는 도구를 사용하세요. MCP를 사용하세요. 런타임을 샌드박스 처리하세요. 기본값은 단일 에이전트로 하세요. 실패 모드가 필요할 때만 범위를 추가하세요. 분기별로 모델을 재평가하세요. 금요일에는 세 가지를 읽으세요.

그것이 바로 플레이북입니다. 나머지는 취향, 출시 속도, 그리고 중요하지 않은 것을 쫓지 않는 인내심입니다. 무언가를 만드세요. 인터넷에 올리세요. 이 시대는 무언가를 설명할 수 있는 사람보다 무언가를 만드는 사람에게 더 큰 보상을 줍니다. 만드는 사람이 되기에 이보다 더 좋은 시기는 없었습니다.