원문 제목: AI 에이전트(2026)에서 배우고 구축하고 건너뛰어야 할 것
원문 저자: Rohit
번역: Peggy, BlockBeats

편집자 주: AI 에이전트 분야는 지금 도구의 폭발과 합의 부족 단계에 들어섰다.

매주 새로운 프레임워크, 새로운 모델, 새로운 벤치마크, 그리고 새로운 "10배 효율" 제품이 등장하지만, 실제로 중요한 문제는 "모든 변화에 뒤쳐질 방법"이 아니라 "어떤 변화에 진정으로 투자할 가치가 있는지"이다.

저자는 현재 기술 스택이 계속 재작성되는 상황에서, 최신 프레임워크를 쫓는 것이 아니라 보다 근본적인 역량에 집중하는 것이 장기적인 이득을 가져다줄 것이라고 생각한다: 컨텍스트 엔지니어링, 도구 설계, 평가 체계, orchestrator-subagent 모델, 그리고 샌드박스 및 하네스 사고방식. 이러한 역량은 모델 교체로 인해 빠르게 퇴화되지 않을 뿐 아니라 신뢰할 수 있는 AI 에이전트를 구축하는 데 기반을 제공할 것이다.

이 글은 또한 AI 에이전트가 "경력"의 의미를 변화시키고 있다고 덧붙였다. 과거에는 학력, 직급 및 경력 연수가 산업에 진출하는 데 필요한 자격증으로 인식되었지만, 거대 기업조차도 공개적인 시험과 오류를 해야 하는 분야에서는 이력서가 더 이상 유일한 자격증이 아니다. 당신이 무엇을 이루었는지, 무엇을 제공했는지가 더 중요해지고 있는 것이다.

따라서, 이 글은 2026년 AI 에이전트에게 배워야 할 것, 구축해야 할 것, 건너뛌 것뿐만 아니라, 현재 소음이 점점 더 커지는 시대에 가장 부족한 능력은 무엇을 배울 가치가 있는지 판단하고 실제로 유용한 일을 계속해서 하는 것임을 상기시키기 위한 것이다.

아래는 원문입니다:

매일 새로운 프레임워크, 새로운 벤치마크, 새로운 "10배 효율" 제품이 등장한다. 문제는 더 이상 "어떻게 따라잡아야 하는가"가 아니라, 여기에 어떤 것이 진정한 신호이고 무엇이 그저 시급성의 외피를 쓴 소음인가이다.

각각의 로드맵은 한 달 후에는 이미 구식일 수 있다. 지난 분기에 습득했던 프레임워크는 이미 오래된 기술이 되었다. 최적화해온 벤치마크는 빠르게 뚫려난 뒤 새로운 것으로 교체된다. 과거에는 특정 전통적인 경로를 따라 진행할 것을 훈련받았다. 하나의 기술 스택이 일련의 주제 및 레벨에 대응하며, 일련의 경험은 연차와 칭호에 대응했다. 천천히 올라가는 것이었다. 그러나 AI는 그림을 재작성하고 있다. 오늘날, 제대로된 단서와 충분한 미적 판단력만 있다면, 한 명의 개인이 이전에는 두 년 경력이 있는 엔지니어가 한 스프린트에 완료하는 데 필요한 작업을 완수할 수 있다.

전문 역량은 여전히 중요합니다. 시스템이 다운되는 것을 눈으로 직접 보거나 새벽 두 시에 메모리 누수를 디버깅한 경험을 바로 얻을 수 있는 것은 없습니다. 또한 지루하지만 옳은 해법을 선택하고 결국 옳다는 것이 증명되는 과정을 통해 만들어진 판단력도 없습니다. 이러한 판단력은 복리로 자라납니다. 그러나 과거와 같이, 같은 복리 성장을 겪고 있는 것은 '이번 주 핫한 프레임워크 API 표면'에 대한 이해 수준이 아닙니다. 여섯 달 후, 그것은 다시 변할지도 모릅니다. 두 년 뒤에 진정으로 성공한 사람은 초기에 견고한 기본 능력을 선택하고 다른 소음이 지나가도록 하는 사람입니다.

지난 두 년간 저는 이 분야에서 제품을 개발했고 연봉 25만 달러 이상의 여러 제안을 받았으며 지금은 기술 담당자로서 은신컴퍼니에서 일하고 있습니다. 누군가가 나에게 "지금 정확히 무엇에 주의를 기울여야 하나요?"라고 물으면, 이것이 바로 제가 그에게 보낼 내용입니다.

이것은 로드맵이 아닙니다. 에이전트 영역은 아직 명확한 목적지가 없습니다. 대기업 연구소도 일반에게 공개적으로 반복하고 있으며 백만 명의 사용자에게 문제를 직면시키고 나서 피드백을 받아 수정하고 있습니다. 만약 Claude Code 뒤의 팀이 사용자 커뮤니티가 문제를 발견한 후까지 문제에 대해 인식하지 못한 47% 성능 하락을 일으키는 버전을 배포할 수 있다면, 그러한 "안정적인 지도가 밑에 있다"라는 생각은 허구입니다. 모든 사람들이 아직 헤매고 있습니다. 스타트업이 기회를 갖는 이유가 바로 거인들도 답을 모르기 때문입니다. 코드를 작성하지 못하는 사람들이 에이전트와 협업하여 기계 학습 박사가 불가능하다고 생각했던 것을 금요일에 제출합니다.

이 시대에서 가장 흥미로운 점은 "경력"에 대한 우리의 이해를 변화시켰다는 것입니다. 전통적인 경로는 경력을 최적화했습니다: 학위, 주임 포지션, 고위 포지션, 시니어 포지션 및 천천히 쌓인 직급. 이는 하부 영역이 극심한 변화에 무관하다고 확실할 때 적합합니다. 그러나 지금, 발을 딛고 있는 땅도 모든 이의 발 뒤꿈치 속도로 움직이고 있습니다. 에이전트 데모를 공개 출시한 22세의 젊은이와 시니어 엔지니어 35세와의 차이는 더 이상 10년 기술 스택 숙련도 누적만이 아닙니다. 이 22세와 시니어 엔지니어가 직면한 것은 동일한 공백 캔버스입니다. 그들에게 있어 복리로 자라날 수 있는 것은 계속해서 서비스를 제공하려는 의지와 분기 내에 오래지 지 않을 기본 능력의 작은 부분입니다.

이것이 이 기사의 핵심 재구성입니다. 그 다음에, 저는 판단 방식을 제시할 것입니다: 어떤 기본 능력에 주의를 기울일 가치가 있고 어떤 출시가 그것을 단기 내에서 바로 넘어갈 수 있는지. 당신에게 맞는 것은 가져가고, 그렇지 않은 것은 버려두면 됩니다.

실질적인 유용한 필터

매주 새로운 출시를 따라잡을 수 없고 그렇게 하면 안 됩니다. 당신이 필요로 하는 것은 정보 스트림이 아니라 필터입니다.

지난 18개월 동안 다섯 가지 테스트가 계속 효과적이었습니다. 기술 스택에 새로운 것을 도입하기 전에 이 다섯 가지 질문을 거쳐보세요.

그 후 두 년 뒤에도 여전히 중요합니까?
이 프론트 엔드 방식의 쉘, CLI 매개변수 또는 "Devin 버전"과 같이 단순히 전선 모델의 케이스라면 대부분이 부정적일 것입니다. 그러나 프로토콜, 패턴, 샌드박스 방식과 같은 기본 원천이라면 대부분이 긍정적일 것입니다. 쉘 케이스 제품의 반감기는 매우 짧으며, 기본 원천의 반감기는 연 단위로 계산될 수 있습니다.

존경하는 사람들 중에서 이미 이를 기반으로 한 실제 제품을 출시하고 솔직하게 경험을 공유했습니까?
마케팅 글은 아닙니다. 리뷰 포스트여야 합니다. "우리가 생산 환경에서 X를 시도했고, 여기서 문제가 발생했습니다"라는 제목의 블로그 글 한 편이 공지의 10개를 능가합니다. 이 분야에서 정말 유용한 신호는 어떤 사람이 이를 위해 주말을 하나 잃어가며 투자한 분들로부터 얻어집니다.

이를 도입하면 기존의 추적, 다시 시도 메커니즘, 설정, 인증 시스템을 포기해야 합니까?
만약 그렇다면, 이는 자신을 플랫폼으로 만들려는 프레임워크입니다. 플랫폼으로서 자리잡으려는 프레임워크의 생존율은 약 90%입니다. 좋은 기본 원천은 당신의 기존 시스템에 통합될 수 있어야 하며 당신을 강제로 이주시키지 말아야 합니다.

6개월 동안 이를 건너뛴다면 어떤 비용이 드나요?
대부분의 출시에 대해, 대답은 아무 것도 없습니다. 6개월이 지난 후에는 더 많은 것을 알게 되며 이길 것 같은 버전도 더 명확해질 것입니다. 이 테스트는 당신으로 하여금 출시의 90%를 쉽게 건너뛸 수 있게 하지만 대부분의 사람들이 사용을 거부하는 이유이기도 합니다. 건너뜁니다라고 느끼게 만드는 것은 자신이 뒤쳐진 듯한 느낌을 주기 때문인데 실제로 그렇지 않습니다.

이를 통해 여러분의 에이전트가 실제로 더 나아졌는지 평가할 수 있습니까?
만약 할 수 없다면, 여러분은 추측에 불과합니다. 평가가 없는 팀은 직감에 의존하며 결국 회귀 문제를 온라인으로 가져오게 될 것입니다. 평가가 있는 팀은 데이터가 어떤 것이 이번 주에 이 특정 워크로드에서 GPT-5.5가 더 나은지 아니면 Opus 4.7이 더 나은지 자문해주게 할 것입니다.

만약 여러분이 이 글에서 단 하나의 습관만 가져간다면, 그것은 새로운 것이 출시될 때마다 6개월 후에 어떤 것을 보고 그것이 정말 중요한지를 믿는지 기록하는 것입니다. 그리고 6개월 후에 다시 돌아와서 확인합니다. 대부분의 시간, 문제는 스스로 답을 제시하고 있으며 여러분의 주의는 실제로 복리를 가져다주는 것에 집중될 것입니다.

이러한 테스트 뒤에 있는 진정한 능력은 어떤 테스트보다도 이름붙이기가 더 어려운 것입니다. 이것은 "세련되게 따라가려는" 능력입니다. Hacker News에서 이 주에 불타오르는 프레임워크는 14일 후에 야유단을 가질 것이며 그들은 모두 영리해 보일 것입니다. 그러나 6개월이 지난 후, 그 프레임워크의 절반은 이미 유지되지 않으며 그 야유단도 이미 다음 핫한 것으로 옮겨갈 것입니다. 참여하지 않은 사람들은 주의력을 보존하고 출시 열풍이 지나간 후에도 "지루해지는" 것에 맞서는 것을 제외하고는 모두가 발표 공지를 읽게 될 것입니다. 거의 아무도 이를 비판없이 받아들이는 데 능하지 않습니다.

무얼 배워아아할까

개념, 패턴, 물체의 형태. 진정한 복리를 가져다 주는 것들은 이런 것들이다. 이들은 모델 교체, 프레임워크 교체 및 패러다임 이동을 건너뛸 수 있다. 이들을 깊이 이해하면, 어떤 새로운 도구든 1주말 내에 습득할 수 있다. 이들을 건너뛰면, 영원히 표면적인 메커니즘을 다시 배우게 될 것이다.

컨텍스트 엔지니어링

지난 2년 동안 가장 중요한 이름 바꾸기 중 하나는 "프롬프트 엔지니어링"이 "컨텍스트 엔지니어링"으로 바뀐 것이었다. 이 변경은 실제로, 그냥 표현만 바뀐 것이 아니다.

모델은 더 이상 똑똑한 명령을 전달하는 것이 아니다. 모델이란, 각 단계마다 작동 가능한 컨텍스트를 조립해야 하는 것으로 바뀌었다. 이 컨텍스트에는 시스템 명령, 도구 스키마, 검색된 문서, 이전 도구의 출력, 스크래치패드 상태, 그리고 압축된 히스토리가 함께 포함된다. 에이전트의 행동은 당신이 해당 컨텍스트 창에 넣은 모든 것이 공동으로 나타나는 결과이다.

이 점을 철저히 체득해야 한다: 컨텍스트는 상태이다. 각각의 관련 없는 토큰은 추론 품질을 훼손시킨다. 컨텍스트 부패는 실제 생산 장애다. 10단계 작업의 제8단계에 도달했을 때, 초기 목표는 이미 도구 출력에 묻혀져 있을 수 있다. 신뢰성 있는 에이전트를 전달할 수 있는 팀은 적극적으로 컨텍스트를 요약, 압축, 가공할 것이다. 그들은 도구 설명을 버전 관리하며, 정적인 부분을 캐시하고, 변동성이 있는 부분을 캐시에서 배제할 것이다. 그들은 컨텍스트 창을 메모리를 다루는 노련한 엔지니어가 다루는 방식처럼 바라본다.

구체적인 느낌 방법은: 어떤 프로덕션 환경의 에이전트를 가져와서, 완전한 추적 로그를 열어라. 제1단계의 컨텍스트를 살펴보고, 그 다음 제7단계의 컨텍스트를 살펴봐라. 아직 작용하는 토큰이 얼마나 남아 있는지 세어보아라. 이 작업을 처음 수행할 때, 아마도 당신은 창피할 것이다. 그런 다음 당신은 이를 수정하러 가게 될 것이고, 동일한 에이전트는 모델 교체 없이 프롬프트 변경 없이 현저히 더 신뢰할 수 있어질 것이다.

관련 내용을 한 편만 읽는다면, Anthropic의 《Effective Context Engineering for AI Agents》를 읽어보라. 그 후, 시스템 규모를 확장한 후의 다중 에이전트 연구 시스템에 대한 그들의 회고록을 읽어보라. 그 기사에서는 시스템 규모가 확장된 후, 컨텍스트 격리가 얼마나 중요한지를 숫자로 설명하고 있다.

도구 디자인

도구는 에이전트가 비즈니스와 상호작용하는 지점이다. 모델은 도구 이름과 설명에 따라 도구를 선택하며, 오류 메시지에 따라 재시도 방법을 결정한다. 도구의 계약이 LLM이 표현하는 방식에 부합하는지 여부가 모델의 성공 또는 실패를 결정한다.

다섯 개에서 열 개의 잘 지어진 도구는 스무 개의 보통 도구보다 낫습니다. 도구의 이름은 자연스러운 영어에서의 동사구처럼 되어야 합니다. 설명은 언제 사용해야 하는지, 언제 사용해서는 안 되는지 명확히 작성되어 있어야 합니다. 오류 메시지는 모델이 이를 기반으로 조치를 취할 수 있는 피드백이어야 합니다. 「500 개 토큰 한도 초과, 요약 후 다시 시도하세요.」가 「Error: 400 Bad Request」보다 우수합니다. 공개 연구에서 한 팀이 오류 메시지만 다시 작성했을 때 재시도 루프가 40% 줄었다고보고했습니다.

Anthropic의 《Writing tools for agents》는 매우 좋은 시작점입니다. 읽고 나서 여러분의 도구에 관측을 덧붙여 실제 호출 패턴을 확인해 보세요. 에이전트 신뢰성 향상은 거의 항상 도구 측에서 일어납니다. 많은 사람들이 지속적으로 프롬프트를 조정하지만 실제 손잡이는 도구쪽에 있음을 무시합니다.

Orchestrator-Subagent 패턴

2024년과 2025년에 대한 다중 에이전트 논쟁은 결국, 오늘날 모두가 채택하고 있는 종합 솔루션으로 수렴했습니다. 소박한 다중 에이전트 시스템, 즉 여러 개의 에이전트가 공유 상태에 병렬로 쓰는 시스템은 재앙적인 실패를 가져올 수 있습니다. 오류가 지속적으로 증폭되기 때문입니다. 단일 에이전트 루프가 확장 가능한 정도는 종종 여러분이 상상하는 것 이상입니다. 실제로 생산 환경에서 작동할 수 있는 다중 에이전트 형태는 한 가지뿐입니다: orchestrator 에이전트는 범위가 좁고 읽기 전용 작업을 격리 된 subagent에게 위임하고 그들의 결과를 통합합니다.

Anthropic의 리서치 시스템은 이런 식으로 작동합니다. Claude Code의 subagents도 이와 같이 작동합니다. Spring AI와 대부분의 프로덕션 프레임워크는 현재 이 패턴을 표준화하고 있습니다. Subagent는 작고 집중적인 컨텍스트를 갖고 있으며 공유 상태를 수정할 수 없습니다. 쓰기는 orchestrator가 책임집니다.

Cognition의 《Don't Build Multi-Agents》와 Anthropic의 《How we built our multi-agent research system》은 보기에는 상반된 입장처럼 보이지만 실제로는 같은 주제를 다른 용어로 이야기하고 있습니다. 두 글 모두 읽을 가치가 있습니다.

기본적으로 단일 에이전트를 사용하세요. 실제로 단일 에이전트가 실제한 경계에 도달한 경우에만 orchestrator-subagent를 고려하세요: 예를 들어 컨텍스트 창압력, 순서 도구 호출로 인한 지연 또는 작업 이질성이 집중된 컨텍스트에서 이익을 얻을 수 있는 경우. 고통을 느끼기 전에 이러한 시스템을 구축하면 필요하지 않은 복잡성만 제공하게 됩니다.

Evals와 골드 데이터셋

신뢰할 수 있는 에이전트를 전달할 수 있는 모든 팀은 평가를 가지고 있습니다. 평가가 없는 팀은 일반적으로 신뢰할 수 있는 에이전트를 전달할 수 없습니다. 이것은이 분야에서 가장 높은 leverage의 습관이며, 내가 회사마다 가장 과소 평가 된 것으로 보는 것입니다.

효과적인 방법은: 프로덕션 환경 추적을 수집하고 실패 사례를 주석으로 달아 재현 세트로 사용하는 것입니다. 새로운 실패가 올라올 때마다 해당 사례를 추가합니다. 주관적 부분은 LLM-as-judge를 사용하고, 나머지 부분은 정확한 일치 또는 프로그래밍적 검사를 사용합니다. 모든 프롬프트, 모델 또는 도구 변경 전에 테스트 스위트를 실행합니다. Spotify 엔지니어 블로그 보고서에 따르면, 그들의 심사층은 대략 25%의 에이전트 출력이 온라인으로 향하기 전에 차단합니다. 그것이 없으면 매 네 가지 나쁜 결과 중 하나가 사용자에게 도달합니다.

이것을 정말로 뿌리내리게 만드는 마음 모델은: 평가는 다른 모든 것이 계속 변화할 때, 에이전트가 책임에서 벗어나지 않았는지 확인하는 단위 테스트입니다. 모델은 새로운 버전으로 업데이트되고, 프레임워크는 파괴적인 변경을 배포하며, 공급 업체는 특정 엔드포인트를 폐기합니다. 당신의 평가가 에이전트가 여전히 제대로 작동 중인지 안내하는 유일한 것입니다. 평가가 없으면 이해관계가 이동하는 대상에 달려있는 정확성을 작성하게 됩니다.

Evals 프레임워크 인 Braintrust, Langfuse evals, LangSmith는 모두 괜찮습니다. 그러나 그것들이 병목이 되는 것은 아닙니다. 진짜 병목은 먼저 주석이 달린 데이터 세트를 가지고 있는지입니다. 모든 것을 확장하기 전에처음부터 시작하십시오. 처음 50개 샘플은 오후에 수동으로 주석을 다는 데 충분합니다. 변명은 없습니다.

파일 시스템을 상태로 취급하고, Think-Act-Observe 루프

실제로 여러 단계 작업을 실행하는 모든 에이전트에 대해, 내구성 있는 아키텍처는 다음과 같습니다: 사고, 행동, 관찰, 반복. 파일 시스템 또는 구조화된 저장소는 사실 출처입니다. 각 작업은 기록되고 재생할 수 있습니다. Claude Code, Cursor, Devin, Aider, OpenHands, goose는 모두 이 지점으로 수렴하며, 이는 우연이 아닙니다.

모델 자체는 상태가 없습니다. 실행 프레임워크는 상태가 있어야 합니다. 파일 시스템은 모든 개발자가 이미 이해하고 있는 상태 기본 요소입니다. 이 프레임워크를 받아들인 후에는 전체 하네스 규율이 자연스럽게 전개됩니다: 체크포인트, 회복 가능성, 서브 에이전트 검증, 샌드박스 실행.

여기에 더 깊은 영감이 있습니다: 지불할만한 가치가 있는 모든 프로덕션 에이전트에서, harness가 하는 작업은 모델보다 훨씬 많습니다. 모델은 다음 단계 조치를 선택하고, harness는 그것을 검증하고, 샌드박스에서 실행하고, 출력을 캡처하며, 피드백을 결정하고, 언제 중지할지 결정하며, 언제 체크포인트를 가져갈지 결정하며, 언제 서브에이전트를 생성할지 결정합니다. 모델을 동등한 품질의 다른 모델로 바꾸면, 좋은 harness라면 여전히 제품을 제공할 수 있습니다. harness를 더 나쁜 것으로 바꿔도, 세계에서 가장 좋은 모델이라도 자신이 무엇을 하는지 잊어버릴 수 있는 에이전트가 생성됩니다.

일회성 도구 호출보다 복잡한 것을 구축 중이라면, 진정으로 시간을 투자해야할 곳은 harness입니다. 모델은 단지 구성 요소 중 하나에 불과합니다.

MCP 개념적으로 이해하기

MCP 서버를 호출하는 방법만 배우지 마십시오. 그것의 모델을 이해하십시오. 그것은 에이전트 능력, 도구 및 리소스 사이에 명확한 분리를 만들며 하부에 확장 가능한 인증 및 전송 솔루션을 제공합니다. 이를 이해한 후, 다른 "에이전트 통합 프레임워크"가 MCP의 하위 호환 버전처럼 보일 것이며, 각각을 개별적으로 평가할 시간을 절약할 수 있습니다.

Linux Foundation은 현재 MCP를 호스팅하고 있습니다. 모든 주요 모델 공급 업체가 이를 지원합니다. 이를 "AI의 USB-C"로 생각하면 둥글지만 실제로 더 가까워졌습니다.

샌드박스화는 기본 프리미티브입니다

모든 프로덕션 수준 코딩 에이전트는 샌드박스에서 실행됩니다. 모든 브라우저 에이전트는 간접 프롬프트 주입을 경험했습니다. 모든 다중 테넌트 에이전트는 어느 단계에서든 권한 범위 버그를 겪었습니다. 샌드박스화를 요구에서 추가 기능으로 처리하는 대신 기반 인프라 원시 프리미티브로 삼아야 합니다.

기본 사항을 배워야 합니다: 프로세스 격리, 네트워크 출구 제어, 키 범위 관리, 에이전트와 도구 간의 인증 경계. 임시로 추가하는 팀은 종종 거래를 잃게 됩니다. 첫 주에 이미 이를 구현한 팀만이 기업 구매 절차를 쉽게 통과할 것입니다.

무엇을 사용하여 구축해야 하는가

2026년 4월까지의 구체적인 선택 사항은 다음과 같습니다. 이러한 선택은 변할 수 있지만 너무 빨리 변하지는 않을 것입니다. 이 수준에서 "지루하지만 안정된" 것을 선택하려고 노력하십시오.

배치 레이어

LangGraph은 실제 운영 환경에서의 기본 선택지입니다. 대기업의 약 1/3는 이를 사용하고 있습니다. 이 방식은 agent 시스템의 실제 형태와 일치하며, 유형화된 상태, 조건부 엣지, 지속적인 작업 흐름, 그리고 human-in-the-loop 체크포인트를 포함합니다. 번거로운 측면이 쓰기 어려운 점이지만, 실제로 agent가 생산 환경에 진입하면 이러한 요소들을 제어해야 하므로, 이러한 번거로움은 정확히 이러한 제어 요구에 부합합니다.

TypeScript를 주로 사용하는 경우 Mastra가 사실상의 선택입니다. 이 솔루션은 이 생태계에서 가장 명확한 마인드 모델을 제공합니다.

만약 당신의 팀이 Pydantic을 좋아하고 유형 안정성을 주요 관심사로 삼는다면, Pydantic AI는 합리적인 greenfield 선택지입니다. 2025년 말에 v1.0을 출시했고, 실제로 기세가 있습니다.

컴퓨터 사용, 음성, 실시간 상호 작용과 같이 provider-native 작업인 경우 LangGraph 노드에서 Claude Agent SDK 또는 OpenAI Agents SDK를 사용할 수 있습니다. 이러한 SDK를 이질적 시스템의 최상위 조정자로 만들려고 하지 마십시오. 각각이 자신이 잘하는 시나리오에 최적화되어 있습니다.

프로토콜 레이어

MCP, 다른 선택지는 없습니다.

도구 통합을 MCP 서버로 만드세요. 외부 통합도 동일한 방식으로 처리하세요. 현재 MCP 레지스트리는 이미 임계점을 넘어섰습니다. 대부분의 경우, 직접 빌드하기 전에 이미 구성된 서버를 찾을 수 있습니다. 2026년에도 여전히 사용자 지정 도구 plumbing을 수작업으로 구축하는 것은 대부분 낭비입니다.

메모리 레이어

기억 시스템을 선택할 때는 인기에 따르지 말고, agent의 자율성에 따라 선택하세요.

Mem0는 채팅 기반 맞춤형에 적합합니다: 사용자 선호도, 가벼운 히스토리. Zep은 프로덕션 대화형 시스템에 적합하며, 특히 상태가 계속 변하고 엔티티 추적이 필요한 시나리오에 적합합니다. Letta는 몇 일이나 몇 주 동안 일관성을 유지해야 하는 agent에 적합합니다. 대부분의 팀이 이를 필요로 하진 않지만, 실제로 필요한 팀이면 이것이 필요한 것입니다.

흔한 실수는: 아직 메모리 문제가 없는데 먼저 메모리 프레임워크를 도입하는 것입니다. 컨텍스트 창이 수용할 수 있는 내용으로 시작하여 벡터 데이터베이스를 추가하세요. 어떤 실패 패턴을 해결해야 하는지 명확히 할 수 있는 경우에만 기억 시스템을 추가하세요.

관측 가능성과 Evals

Langfuse는 오픈 소스 기본 선택 사항입니다. 자체 호스팅이 가능하며 MIT 라이선스로 제공되며 추적, 프롬프트 버전 관리 및 기본 LLM-판정 evals를 포함합니다. LangChain 사용자인 경우 LangSmith 통합이 더 밀접할 것입니다. Braintrust는 연구 지향 eval 작업 흐름에 적합하며 특히 엄격한 비교가 필요한 시나리오에 적합합니다. OpenLLMetry/Traceloop은 vendor-neutral OpenTelemetry instrumentation이 필요한 다국어 기술 스택에 적합합니다.

추적과 evals를 동시에 보유해야 합니다. 추적은 다음을 대답합니다: "에이전트가 실제로 무엇을 했나요?" Evals는 다음을 대답합니다: "에이전트가 어제보다 나아졌나요, 아니면 나빠졌나요?" 이 두 가지가 없으면 배포하지 마십시오. 첫째 날에이 것들을 설정하면盲目적으로 실행한 후 보완하는 것보다 훨씬 저렴합니다.

런타임 및 샌드박스

E2B는 일반적인 샌드박스 코드 실행에 적합합니다. Browserbase와 Stagehand를 함께 사용하면 브라우저 자동화에 적합합니다. Anthropoc Computer Use는 실제 운영 체제 수준의 데스크탑 제어가 필요한 시나리오에 적합합니다. Modal은 단기 급격한 작업에 적합합니다.

절대로 샌드박스화되지 않은 코드 실행을 실행하지 마십시오. 프롬프트 주입 공격에 취약한 에이전트는 생산 환경에서 직접 실행되면 폭발 범위가 다른 사람에게 전할 수 없는 이야기가 될 수 있습니다.

모델

벤치마크를 추적하는 것은 매우 지루하며 대부분의 경우 별다른 도움이 되지 않습니다. 2026년 4월 현재:

·Claude Opus 4.7 및 Sonnet 4.6은 신뢰할 수있는 도구 호출, 다단계 일관성 및 우아한 오류 복구에 적합합니다. 대부분의 작업 부하에 대해 Sonnet은 비용과 성능 사이의 최적점입니다.

·GPT-5.4 및 GPT-5.5는 가장 강력한 CLI/터미널 추론 능력이 필요한 경우 또는 이미 OpenAI 인프라에 사는 경우에 적합합니다.

·Gemini 2.5 및 3은 장기 문맥 집중형 또는 다중 모드 집중형 작업에 알맞습니다.

· 비용이 최고 성능보다 중요할 때, 특히 경계가 명확하고 정의가 좁은 작업을 처리할 때, DeepSeek-V3.2 또는 Qwen 3.6을 고려할 수 있습니다.

모델을 교체 가능한 구성 요소로 간주하십시오. 당신의 에이전트가 특정 모델에서만 작동한다면, 이것은 모래성이 아니라 나쁜 냄새입니다. 평가를 사용하여 어떤 모델을 배포할지 결정하십시오. 매 분기마다 재평가하되, 매주 변경을 추구하지 마십시오.

건너뛸 수 있는 것들

아래 항목들을 학습하고 사용하라는 조언을 계속 받을 것입니다. 사실 그것들은 필요하지 않습니다. 이러한 것들을 건너 뛰는 비용은 매우 낮고, 많은 시간을 절약할 수 있습니다.

AutoGen 및 AG2는 생산용으로 사용하지 마십시오.
Microsoft의 이 프레임워크는 이미 커뮤니티 유지보수로 이권되었으며, 출시 속도가 둔화되었으며, 추상화 방식도 생산 팀이 실제로 필요로 하는 형태와 일치하지 않습니다. 학술적 탐구에 사용할 수 있지만 제품을 이에 맡길 필요는 없습니다.

CrewAI는 새로운 생산 빌드에 사용하지 마십시오.
데모로 사용하기에 적합하기 때문에 여기저기서 보일 것입니다. 실제로 생산 시스템을 구축할 엔지니어는 이미 그것을 이탈했습니다. 원형 모델로 사용하고 싶다면 할 수 있지만 장기적으로는 연결하지 마십시오.

Microsoft 시맨틱 커널은 이미 깊게 Microsoft 기술 스택에 묶여 있고 구매자가 그것을 신경 쓰는 경우가 아니라면 사용하지 마십시오.
그것은 생태계가 향하고 있는 방향이 아닙니다.

DSPy는 대규모 prompt 프로그램을 특별히 최적화하고자 하는 경우를 제외하고 사용하지 마십시오.
철학적인 가치는 있지만 대상이 매우 한정적입니다. 이는 범용 에이전트 프레임워크가 아니며 범용 프레임워크로 선택해서는 안 됩니다.

독립된 코드 작성 에이전트를 아키텍처 선택으로 삼지 마십시오.
코드-작동은 흥미로운 연구 방향이지만, 아직 생산 환경에서의 기본 모드는 아닙니다. 많은 도구 연쇄와 보안 문제에 직면할 것이며, 여러분의 경쟁자는 이러한 문제들에 대해 전혀 다뤄야 할 필요가 없을 수도 있습니다.

「자율 에이전트」 스타일의 홍보를 하지 마십시오.
AutoGPT와 BabyAGI의 그 제품 형태의 방향은 이미 사라졌습니다. 산업이 마침내 받아들인 정직한 주장은 「에이전트 공학」입니다: 지도가 있는, 경계가 있는, 평가가 있는 것. 2026년에 여전히 「배포 후 신경 쓸 필요 없음」인 자율 에이전트를 판매하는 사람은 본질적으로 2023년의 것을 판매하고 있습니다.

에이전트 앱 스토어와 마켓플레이스.
2023년부터이 사람들이 약속해 온 것이지만 실제로는 기업이 이용하는 데 성공하지 못했습니다. 기업은 일반적인 사전 제작된 에이전트를 구매하지 않습니다. 그들은 특정 결과에 바인딩된 수직 에이전트를 구매하거나 자체적으로 구축합니다. 비즈니스를 디자인하는 과정에서 앱 스토어 꿈을 중심으로 펼치지 마십시오.

고객으로서, 가로로 확장 가능한 "build any agent" 기업 플랫폼을 신중하게 선택하십시오.
예를 들어 Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio 와 같은 계층입니다. 나중에 유용해질 수 있지만 현재는 여전히 혼란스럽고 느리게 배포되며, buy-versus-build의 계산은 보통 여전히 좁은 에이전트를 직접 구축하거나 수직 에이전트를 구매하는 쪽으로 기울어 있습니다. Salesforce Agentforce와 ServiceNow Now Assist는 예외입니다. 왜냐하면 이미 사용 중인 워크플로 시스템에 통합되어 있기 때문입니다.

SWE-bench 및 OSWorld 랭킹을 추구하지 마십시오.
2025 년 버클리 연구원들에 따르면, 거의 모든 공개 벤치마크는 실제로 근본적인 작업을 해결할 필요 없이 조작될 수 있습니다. 현재 팀은 Terminal-Bench 2.0 및 자체 내부 평가를 더 신뢰할만한 신호로 여깁니다. 단일 숫자 벤치마크에 대한 기본적인 의심을 유지하십시오.

순진한 병렬 다중 에이전트 아키텍처.
공유 메모리 주변에 다섯 개의 에이전트가 대화하는 것은 데모에서 멋있어 보일 수 있지만, 프로덕션 환경에서는 붕괴될 것입니다. 오케스트레이터-서브 에이전트 그림을 명확히 그려내지 못하고 읽기 및 쓰기 경계를 표시할 수 없다면 출시하지 마십시오.

새로운 에이전트 제품은 좌석당 SaaS 가격 책정을 사용하지 마십시오.
시장은 결과 중심 및 사용량 중심으로 이동했습니다. 좌석당 요금은 매출을 줄이지만 제품이 결과를 전달할 수 있다고 믿지 않는다는 신호를 구매자에게 보냅니다.

Hacker News에서 이번 주에 본 다음 프레임워크.
6개월을 기다리세요. 그때도 중요하다면 명백히 될 것입니다. 중요하지 않다면 마이그레이션을 건너뛰십시오.

구체적인 추진 방향

에이전트를 따라잡기만 하기보다 정말로 에이전트를 채택하고 싶다면, 다음 순서가 효과적입니다. 지루하겠지만 유용합니다.

먼저 이미 중요한 결과를 선택하십시오. 달성 가능한 목표를 선택하십시오. 초심을 잊지 말고, 시장에서 중요하게 여기는, 평가 가능한 것을 선택하십시오: 고객 서비스 티켓 감소, 초안 법률 검토 의견 생성, 인바운드 리드 필터링, 월간 리포트 생성 등. 에이전트의 성공 여부는이 결과가 개선되었는지에 따라 달려 있습니다. 이것은 첫 날부터 귀하의 평가 대상입니다.

이 단계가 다른 단계보다 중요한 이유는 후속 모든 결정에 영향을 미칠 수 있기 때문입니다. 구체적인 결과가 있으면 「어떤 프레임워크를 선택할 것인가」는 더는 철학적인 문제가 아니라 해당 결과를 제공할 수 있는 가장 빠른 프레임워크를 선택하게 됩니다. 또한 「어떤 모델을 선택할 것인가」도 기준선 논쟁이 아닌 해당 작업에서 효과적임이 입증된 모델을 선택하게 됩니다. 「메모리, subagent, 맞춤형 harness가 필요한가」도 사고 실험이 아닌 구체적인 실패 패턴이 발생할 때에만 추가하게 됩니다.

이 단계를 건너뛴 팀은 결국 아무도 사용하지 않을 수평 플랫폼을 만들게 됩니다. 이 단계를 신중하게 다룬 팀은 일반적으로 쿼터 내에 투자 회수가 가능한 좁고 효과적인 에이전트를 전달하게 됩니다. 그리고 실제로 론칭된 이 에이전트는 두 년 동안 글을 읽는 것보다 훨씬 더 가르칠 것입니다.

어떤 것이든 온라인 상에 출시하기 전에 추적과 evals를 설정하세요. Langfuse 또는 LangSmith를 선택하고 이를 잘 연결하세요. 필요한 경우 손으로 소규모의 골든 데이터셋을 작성하세요. 50개의 주석이 달린 샘플이 출발하기에 충분합니다. 측정할 수 없는 것을 개선할 수 없습니다. 나중에 이 시스템을 추가하려면 비용은 현재보다 대략 10배 듭니다.

단일 에이전트 루프에서 시작하세요. LangGraph 또는 Pydantic AI를 선택하세요. 모델은 Claude Sonnet 4.6 또는 GPT-5를 선택하세요. 에이전트에게 디자인이 잘 된 도구 세트 중 3개에서 7개를 제공하세요. 상태로 파일 시스템 또는 데이터베이스를 사용하게 합니다. 먼저 소수의 사용자에게 배포하고 추적을 관찰하세요.

에이전트를 제품으로 생각하고 프로젝트로 생각하지 마세요. 그것은 예기치 못한 방식으로 실패할 것이며, 이러한 실패가 바로 여러분의 로드맵이 될 것입니다. 실제 프로덕션 추적을 사용하여 회귀 세트를 생성하세요. 각 프롬프트 변경, 모델 교체 및 도구 수정은 배포 전에 evals를 통해 이루어져야 합니다. 대부분의 팀은 이러한 투입을 과소 평가하며, 대부분의 신뢰성은 바로 이곳에서 나옵니다.

확장 가능한 범위를 확보한 상태에서만 복잡성을 더하세요. 컨텍스트가 병목 현상이 되었을 때 subagent를 도입하세요. 필요한 내용을 포용할 수 없을 때 메모리 프레임워크를 도입하세요. 하위 API가 실제로 존재하지 않을 때 computer use 또는 browser use를 도입하세요. 이러한 것들을 미리 설계하지 마세요. 실패 패턴을 통해 이러한 것들이 들어오게 하세요.

지루한 기반 시설을 선택하세요. 도구로는 MCP를 사용하십시오. 샌드박스로는 E2B 또는 Browserbase를 사용하십시오. 상태는 Postgres를 사용하거나 이미 운영 중인 데이터 스토리지를 사용하십시오. 인증 및 가시성은 기존 시스템을 최대한 활용하십시오. 독특한 기반 시설은 실제 승패의 요건이 거의 없습니다. 진정한 승패는 바로 규율에서 옵니다.

첫날부터 유닛 경제 모델을 주시하십시오. 각 action 비용, 캐시 히트율, 재시도 루프 비용, 모델 호출 분포마다. PoC 단계에서 Agent는 저렴해 보일 수 있지만, 초기에 결과에 따른 비용 모니터링을 시작하지 않았다면 규모가 100배 확장될 때 비용이 폭발적으로 증가할 수 있습니다. 0.50달러 비용이 드는 PoC는 중간 규모에서는 매월 5만달러가 될 수 있습니다. 이를 미리 보지 못한 팀은 마음에 들지 않는 CFO 회의를 맞이하게 될 것입니다.

매 분기마다 모델을 다시평가하십시오. 매주가 아니라 분기를 고정시키십시오. 분기 말에 현재 모델을 한 번 실행하면서 평가 스위트를 사용하십시오. 데이터가 변경해야 한다는 결론이 나오면 변경하십시오. 이렇게 하면 모델 진전의 이익을 얻을 수 있으면서도 각 릴리스마다 쫓아다니는 혼돈을 피할 수 있습니다.

트렌드를 판단하는 방법

다음은 어떤 것이 진짜인지 신호일 수 있는 구체적인 신호들입니다: 존경받는 엔지니어링 팀이 숫자와 함께 사후진단을 작성했을 때 기존 사용자 수만 언급하는 대신; 이것이 프로토콜, 패턴 또는 인프라와 같은 기본 원시인 경우이며, 그냥 포장된 것이 아닐 때; 이미 실행 중인 시스템과 상호 운용할 수 있는 경우이며, 시스템 대체가 아닐 때; 이슈된 실패 모델을 해결한다는 목적으로 제안되었을 때 그 변경 가능성이 있을 때; 충분히 오래 존재하여 이것이 실패한 지역을 설명할 수 있는 블로그를 작성할 수 있을 정도로.

다음은 어떤 것이 그냥 소음에 불과할 수 있는 구체적인 신호들입니다: 데모 비디오만 30일 이후에도 제공되는 경우, 제품 사례가 제공되지 않는 경우; 벤치마크 점프가 너무 부드러워 진짜 같지 않은 경우; 피치에 "autonomous", "agent OS" 또는 "build any agent"와 같은 제한 없이 사용되는 경우; 프레임워크 설명서가 기존 추적, 인증 및 구성을 버릴 것으로 가정하는 경우; 스타 수가 빠르게 증가하지만 커밋, 릴리스 및 기여자 수가 동기화되지 않는 경우; Twitter 속도는 빠르지만 GitHub 속도는 따라잡지 못하는 경우.

매주 할 가치 있는 습관은: 금요일에 이 분야를 30분 투자하십시오. 세 가지를 읽으십시오: Anthropic 엔지니어링 블로그, Simon Willison의 노트, Latent Space. 이번 주에 사후진단이 있는 경우, 추가 링크 몇 개를 확인하십시오. 다른 것들은 건너뛰어도 됩니다. 정말 중요한 것은 놓치지 않을 것입니다.

다음에 관심을 두어야 할 사항

앞으로 두 분기 동안 주목해야 할 이유는 반드시 이것이 우승할 것이라는 것이 아니라 "이게 정말 신호인가"라는 질문이 완전히 해결되지 않았기 때문입니다.

Replit 에이전트 4의 병렬 포킹 모델。
이는 '여러 개의 에이전트가 동시에 작동'을 진지하게 시도하지만 공유 상태에 막히지 않는 솔루션 중 하나입니다. 규모 확장 후에도 그 효과가 입증된다면, orchestrator-subagent 이 기본 모델이 변경될 수 있습니다.

결과 중심 가격 책정의 성숙도.
Sierra와 Harvey의 수익 트래젝터리는 좁은 수직적 분야에서이 모델을 검증했습니다. 문제는이를 다른 분야로 확장할 수 있는지 또는 수직적 시나리오에만 적합한지입니다.

기술을 능력 캡슐화 계층으로.
GitHub의 AGENTS.md 및 skills 디렉토리의 증가는 새로운 방식으로 에이전트 능력을 캡슐화하려는 추세를 보여줍니다. 이것이 MCP 표준 도구처럼 능력 계층을 표준화할 수 있을지 여부는 열린 문제입니다.

Claude Code 2026년 4월 품질 회귀 및 재검토.
산업 선도적인 에이전트가 47%의 성능 하락을 초래하는 버전을 출시했으며, 사용자가 먼저 발견하고 내부 모니터링 후에 발견되었습니다. 이는 선도 기업에서도 생산 수준의 에이전트 평가 실천이 여전히 성숙하지 않음을 보여줍니다.이 사건이 전체 산업이 온라인 평가를 개선하도록 밀어준다면,이 교정은 건강한 것입니다.

음성이 기본 고객 서비스 인터페이스로 등장.
Sierra의 음성 채널은 이미 2025년 말에 텍스트 채널을 앞질렀습니다.이 패턴이 다른 수직 분야에서 계속된다면, 지연, 방해, 실시간 도구 호출 등의 설계 제약이 1차 문제가 될 것이며, 많은 기존 아키텍처가 재작업해야 할 것입니다.

오픈 소스 모델 에이전트 능력의 격차 계속 축소.
DeepSeek-V3.2는 thinking-into-tool-use를 네이티브로 지원하며, Qwen 3.6 및 보다 넓은 오픈 소스 모델 생태계 모두 주목할 가치가 있습니다.좁은 범위의 에이전트 작업에서의 비용 성능 비율이 변화하고 있습니다. 닫힌 소스 모델이 기본적으로 우세한 상황은 영원히 계속될 수 없습니다.

이러한 사항 중 각각은 명확한 질문과 대응할 수 있습니다: '여섯 개월 후, 무엇을 볼 때 그것이 실제로 중요한지 믿을 것입니까?' 이것이 테스트입니다. 발표를 추적하는 것이 아니라 답변을 추적하십시오.

역설적인 도박

당신이 채택하지 않은 각 프레임워크는 미래에 이주해야 할 부채 한 통입니다. 추구하지 않은 각 벤치마크는 1/4의 집중력입니다. 현재 주기에서 승리하는 회사 - Sierra, Harvey, Cursor는 각각 자신들의 영역에서 - 좁은 목표를 선택했고 지루한 육군을 구축 한 다음 영역 소음이 곁을 지나가도록했습니다.

전통적인 경로는 다음과 같습니다: 기술 스택을 선택하고 그것을 여러 년 동안 숙달한 후에 계단식으로 올라가는 것입니다. 기술 스택이 10년 동안 안정적인 경우 이 방법은 효과적입니다. 그러나 지금은 기술 스택이 매 분기마다 변화합니다. 진정으로 성공한 사람들은 더 이상 "특정 기술 스택 습득" 능력을 최적화하지 않고, 대신 취향, 기본 구성 요소 및 제공 속도를 최적화합니다. 그들은 공개적으로 작은 것을 구축하고, 제공함으로써 배우는 것입니다. 다른 사람들은 이미 구축한 것 때문에 그들을 방송실로 데려갑니다. 작품 자체가 자격증입니다.

이것에 대해 진지하게 생각해보십시오. 왜냐하면 이것이 이 기사 전체가 실제로 말하고 싶은 것입니다. 대부분의 우리가 받아들인 작업 모델은 자질이 복리로 증가할 수 있을 만큼이 세계가 충분히 안정적일 것이라는 가정에 기초합니다. 당신은 학교에 다니고 학위를 취득하고, 사다리를 오른다. 여기서 두 해, 저기서 세 해, 이력서는 천천히 문을 열 수 있는 도구로 변모합니다. 전체 시스템의 전제는 그것의 반대 업계가 충분히 안정적이라는 것입니다.

그러나 agent 분야는 지금 하나의 안정된 "반대편"이 없습니다. 가입하려는 회사가 겨우 여섯 개월 된 경우가 있을 수 있습니다. 그들이 사용하는 프레임워크가 겨우 18개월의 역사를 가질 수 있습니다. 기본 프로토콜도 두 해밖에 안 될 수 있습니다. 이 분야에서 가장 자주 인용되는 글의 절반은 작성자가 세년 전에도 이 분야에 있지 않았을 수 있습니다. 부동의가 없기에 올라갈 사다리가 없습니다. 왜냐하면 건물도 끊임없이 층이 바뀌기 때문입니다. 사다리가 작동하지 않을 때 남은 것은 더 오래된 방식입니다: 무언가를 만들어내고, 인터넷에 배포하여 작품이 자신을 대신 소개하도록 하는 것입니다. 이것은 자격증 인증 시스템을 우회하는 역설적인 경로입니다. 그러나 계속 옮겨 다니는 분야에서는 유일한 복리로 성장할 수 있는 경로입니다.

이것이 내부에서 본 시대의 모습입니다. 심지어 거물들조차도 공개적으로 반복하고, 문제를 해결하여 재발행하며, 리플레이 분석을 합니다. 올해 가장 흥미로운 것을 제공하는 팀 중에는 18개월 전에 이 분야에 없던 사람들도 있습니다. 코드를 작성할 줄 모르는 사람들이 agent 와 협력하여 실제 소프트웨어를 제공하고 있습니다. 박사 학위 소유자는 올바른 기본 구성 요소를 선택하고 빠르게 행동해 시작하는 사람들에게 능가될 수 있습니다. 대문이 이미 열렸습니다. 대부분은 지원서를 아직 찾고 있습니다.

당신이 실제로 배워야 하는 기술은 "agents" 가 아니라, 계층이 계속 변화하는 분야에서 성장할 수 있는 일들을 식별하는 규율입니다. 컨텍스트 엔지니어링은 성장할 수 있습니다. 도구 설계는 성장할 수 있습니다. 조정자-하위 agent 모델은 성장할 수 있습니다. Eval 규율은 성장할 수 있습니다. Harness 사고는 성장할 수 있습니다. 지난 화요일에 출시된 프레임워크 API 는 성장하지 않습니다. 이를 구별할 수 있게 되면, 매주 다시 새로운 출시가 압박이 아니라 무시할 수 있는 소음이 된다.

모든 것을 배울 필요는 없습니다. 성장할 수 있는 일들을 배우고, 성장할 수 없는 일들은 건너뛰십시오. 목표를 선택하십시오. 추적 및 평가를 완료하고 온라인으로 올라가기 바로 전에. LangGraph를 사용하거나 팀 내 등가 도구를 사용하십시오. MCP를 사용하십시오. 런타임을 사각으로 넣으십시오. 기본 agent 로 시작하십시오. 실패 모델이 복잡성을 가져올 때에만 범위를 확장하십시오. 매 분기마다 모델을 재평가하십시오. 매주 금요일 세 가지를 읽으십시오.

이것이 플레이북입니다. 남은 것은 취향, 전달 속도, 그리고 관련 없는 것을 쫓지 않는 인내심입니다.

뭔가를 구축하세요. 그것들을 인터넷에 올려 놓으세요. 이 시대는 무언가를 하는 사람을 보상하며, 단순히 묘사만 하는 사람이 아닙니다. 지금이 「진정으로 무언가를 만드는 사람」이 되기 위한 최고의 찬스입니다.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia