Strands Agents SDK

혹시 LLM API로 에이전트를 직접 만들어보신 분 계신가요? 루프를 돌리고 응답을 파싱하다 보면 에이전트마다 똑같은 기반 코드를 반복해서 짜게 됩니다. 그래서 프레임워크가 나왔는데, 이번에는 그래프와 상태 머신을 설계하는 부담이 새로 생겼죠. 그 사이 모델의 추론 능력이 크게 좋아지면서, 흐름 자체를 모델에게 맡겨도 되는 시점이 온 겁니다. 이 세 번째 접근을 AWS가 구현한 것이 오늘 다룰 Strands Agents SDK입니다.

이 슬라이드가 오늘 강의의 핵심 한 장입니다. 왼쪽을 보시면 개발자가 하는 일이 도구 등록에서 끝나고, 어떤 도구를 언제 어떤 순서로 부를지는 오른쪽의 모델이 결정합니다. 그래서 docstring과 타입 힌트가 단순한 주석이 아니라 모델이 읽는 설명서가 되는 거죠. 도구 설명을 대충 쓰면 모델이 엉뚱한 도구를 고르는 걸 직접 경험하시게 될 텐데, 그만큼 설명서의 품질이 곧 에이전트의 품질입니다.

실무 감각으로 말씀드리면, 2세대 프레임워크로 에이전트를 만들 때는 설계 문서부터 노드와 엣지를 그리는 일로 시작합니다. Strands에서는 그 자리를 필요한 도구 목록을 정리하는 일이 대신하죠. 시작 코드도 보일러플레이트 수십 줄에서 3줄로 줄어듭니다. 아래 인용이 Strands의 출발점인데, Amazon 내부 팀들이 에이전트를 운영하면서 얻은 결론입니다. 단순함이 곧 배포 속도라는 겁니다.

숫자 몇 개만 짚고 가겠습니다. 2025년에 오픈소스로 공개됐고, 월간 PyPI 다운로드가 3,400만을 넘습니다. 신생 프레임워크치고는 채택 속도가 상당히 빠른 편이죠. 그리고 중요한 포인트는 AgentCore와의 관계인데, Strands는 AgentCore의 기반 오케스트레이션 엔진이라서 로컬에서 만든 에이전트를 코드 수정 없이 관리형 런타임으로 올릴 수 있습니다. 핵심 원칙 세 가지 중에서는 점진적 확장을 기억해 주세요. 3줄로 시작해서 프로덕션 요구가 생길 때 Hooks를 붙여가는 방식입니다.

패키지 구조를 보시면 설계 철학이 그대로 보입니다. 코어인 strands-agents 하나만 설치해도 에이전트가 돌아가고, 나머지는 전부 선택이에요. 도구가 필요하면 tools 패키지를, 품질 측정이 필요하면 evals 패키지를 더하는 식입니다. 웹 서비스나 프론트엔드에 붙이실 분들은 TypeScript SDK도 있다는 점 참고하시고요. 오늘 다루는 범위는 코어와 tools 두 개면 충분합니다.