거대한 if/else 상태 머신을 연결하여 AI 에이전트를 구축해 본 경험이 있다면, 그것이 얼마나 빠르게 취약해지는지 아실 겁니다. Strands Agents는 정반대의 접근 방식을 취합니다: 모델이 계획을 세우도록 하고, 사용자는 프롬프트와 도구 목록을 제공합니다. 이는 AWS의 오픈소스 SDK로, 2025년 5월 Apache License 2.0에 따라 출시되었으며, Amazon Q Developer 및 AWS Glue와 같은 Amazon 팀 내에서 프로덕션 에이전트를 지원합니다.
Strands Agents의 실제 모습
Strands Agents는 몇 줄의 코드로 AI 에이전트를 구축하고 실행하기 위한 SDK입니다. 에이전트에게 모델, 시스템 프롬프트, 도구 세 가지를 제공합니다. 모델은 프롬프트를 읽고, 호출할 도구를 결정하고, 실행하고, 결과를 확인한 다음, 작업이 완료될 때까지 계속 진행합니다. 이 주기가 전체 제품의 핵심입니다.

Python과 TypeScript를 지원합니다. 이 이름은 에이전트를 구성하는 두 가지 요소인 모델과 도구에 대한 언급입니다. AWS는 이를 내부적으로 운영한 후 오픈소스로 공개했으므로, 그 설계는 데모가 아닌 프로덕션 요구 사항을 반영합니다. 미리보기 출시 이후 PyPI 다운로드 수가 15만 회를 넘었으며, 다중 에이전트 기본 요소와 에이전트 간(A2A) 프로토콜 지원을 추가한 1.0 릴리스에 도달했습니다.
다른 에이전트 SDK에 대해 읽어 보셨다면, 이 형태가 익숙하게 느껴질 것입니다. Strands는 LangGraph 및 Google ADK와 같은 범주에 속하지만, 사용자가 직접 그래프를 그리도록 요구하는 대신 모델에 제어 흐름을 주도하도록 더 강력하게 의존합니다.
모델 중심 철학 vs 하드코딩된 오케스트레이션
대부분의 초기 에이전트 프레임워크는 워크플로우를 사전에 정의하도록 요구했습니다. 노드, 엣지, 조건을 구축한 다음, 모델을 통해 이들을 라우팅했습니다. 이는 작동하지만, 새로운 기능이 추가될 때마다 유지보수해야 할 그래프가 늘어납니다.
Strands는 책임을 바꿉니다. 최신 모델은 이미 계획을 세우고, 추론을 연결하며, 도구를 호출하고, 결과에 대해 숙고합니다. 따라서 그 로직을 수동으로 인코딩하는 대신, 목표를 설명하고 도구를 넘겨주면 됩니다. 모델이 단계를 파악합니다.
다음은 간단한 용어로 비교한 내용입니다:
| 접근 방식 | 정의할 것 | 제어 흐름 위치 | 새 기능 추가 비용 |
|---|---|---|---|
| 하드코딩된 오케스트레이션 | 노드, 엣지, 조건, 라우팅 | 사용자 그래프 코드 | 그래프 편집, 경로 재테스트 |
| 모델 중심 (Strands) | 프롬프트 + 도구 목록 | 모델의 추론 루프 | 도구 추가, 프롬프트 업데이트 |
트레이드오프는 분명합니다. 모델 중심 에이전트는 구축 및 적용 속도가 빠르지만, 일부 결정론을 포기해야 합니다. 매번 동일하게 실행되어야 하는 워크플로우의 경우, 다중 에이전트 패턴과 훅을 사용하여 구조를 추가할 수 있습니다. 그래프가 잘못되었다는 것이 아니라, 기본적으로 사용하는 대신 필요할 때만 그래프를 사용한다는 점입니다.
최소한의 에이전트
가장 작은 유용한 Strands 프로그램은 짧습니다. `Agent` 클래스를 임포트하고, 선택적으로 `@tool` 데코레이터로 도구를 정의한 다음, 함수처럼 에이전트를 호출합니다.
from strands import Agent, tool
@tool
def word_count(text: str) -> int:
"""Count the words in a block of text."""
return len(text.split())
agent = Agent(
system_prompt="You are a concise writing assistant.",
tools=[word_count],
)
response = agent("How many words are in this sentence?")
print(response)
`@tool` 데코레이터는 일반 Python 함수를 모델이 호출할 수 있는 형태로 변환합니다. 사용자의 독스트링과 타입 힌트는 도구의 설명 및 입력 스키마가 되어, 모델이 언제 어떻게 도구를 사용해야 할지 알 수 있도록 합니다. 별도로 유지보수해야 할 레지스트리가 없습니다. `agent(...)`를 호출하면 모델이 완료되었다고 판단할 때까지 루프가 실행됩니다.
도구 및 모델 제공업체
도구는 에이전트가 외부 세계와 상호작용하는 방법입니다. 도구는 사용자가 작성한 Python 함수, 커뮤니티에서 제공하는 패키지 도구, 또는 에이전트에 노출된 전체 모델 컨텍스트 프로토콜(MCP) 서버일 수 있습니다.
모델 측면에서 Strands는 제공업체에 유연합니다. 기본 제공업체는 Amazon Bedrock이며, 기본적으로 에이전트는 `us-west-2` 리전의 Claude Sonnet 모델을 사용합니다(정확한 기본 모델 ID는 SDK 버전마다 달라졌으므로 하드코딩하는 대신 설치된 버전을 확인하세요). 다른 곳으로 지정할 수 있습니다:
- 도구 사용 및 스트리밍을 지원하는 모든 Amazon Bedrock 모델
- Anthropic API를 통한 Anthropic Claude 제품군
- Llama API를 통한 Llama 모델
- 로컬 개발을 위한 Ollama
- LiteLLM을 통한 OpenAI와 같은 다른 제공업체
제공업체를 바꾸는 것은 모델 객체 변경이지, 재작성이 아닙니다. 에이전트 루프, 도구, 프롬프트는 동일하게 유지됩니다. 이는 로컬 Ollama 모델에 대해 개발하고 Bedrock에 배포하는 것을 실용적으로 만듭니다.
다중 에이전트 및 MCP 지원
단일 에이전트가 많은 것을 처리할 수 있지만, 실제 시스템에서는 여러 에이전트가 필요한 경우가 많습니다. Strands 1.0은 다중 에이전트 애플리케이션을 위한 기본 요소를 추가했습니다. 여기에는 한 에이전트가 다른 도구를 호출하는 것과 동일한 방식으로 다른 에이전트를 호출하는 '도구로서의 에이전트(Agent-as-Tool)' 패턴과, 문제를 함께 해결하는 에이전트 그룹을 위한 스웜(Swarm) 스타일 조정 기능이 포함됩니다. 또한 A2A 프로토콜을 지원하여 Strands 에이전트가 다른 프레임워크로 구축된 에이전트와 통신할 수 있습니다.
MCP는 일등 시민(우선적으로 지원되는 기능)입니다. 모델 컨텍스트 프로토콜(MCP)은 모델을 도구 및 데이터 소스에 연결하기 위한 개방형 표준입니다. Strands를 사용하면 게시된 MCP 서버에 연결하여 해당 도구를 직접 사용할 수 있습니다. 이는 사용자 정의 글루 코드 없이 수천 개의 기존 통합을 사용할 수 있음을 의미합니다. MCP 클라이언트를 통해 연결을 관리하고, 다른 도구 목록처럼 해당 도구를 에이전트에 전달합니다.
이미 MCP 서버를 실행 중이라면, 이는 에이전트에 새로운 기능을 부여하는 가장 저렴한 방법입니다. 트레이드오프는 이제 해당 서버의 동작에 의존하게 된다는 점인데, 이것이 기본 엔드포인트 테스트가 중요한 이유 중 하나입니다.
Strands 에이전트 배포하기
Strands는 프레임워크 변경 없이 노트북에서 프로덕션 환경으로 전환되도록 구축되었습니다. 로컬에서 테스트한 다음, 스택에 맞는 대상에 배포합니다:
- 관리형 에이전트 런타임을 위한 Amazon Bedrock AgentCore
- 이벤트 기반의 단기 에이전트를 위한 AWS Lambda
- 컨테이너화된 장기 실행 서비스를 위한 AWS Fargate 또는 Amazon EKS
- 컨테이너를 실행할 수 있는 모든 곳에서 일반 Docker
에이전트가 일반 Python 또는 TypeScript이므로, 패키징은 다른 모든 앱과 동일한 규칙을 따릅니다. AWS는 또한 관찰성 훅(observability hooks)을 문서화하여, 에이전트가 활성화된 후 모델이 무엇을 결정했는지, 어떤 도구를 호출했는지 추적할 수 있습니다.
Apidog의 역할
Strands는 에이전트를 구축합니다. 하지만 에이전트가 호출하는 API를 구축하지는 않으며, 이것이 바로 계획해야 할 부분입니다. 모든 Strands 에이전트는 두 가지 종류의 HTTP 엔드포인트에 의존합니다: 모델 뒤에 있는 LLM 제공업체 API와 `@tool` 함수 및 MCP 서버 뒤에 있는 REST 또는 도구 API입니다. 이러한 엔드포인트가 제대로 작동하지 않으면, 에이전트는 모델 문제처럼 보이지만 실제로는 그렇지 않은 방식으로 실패합니다.

Apidog는 에이전트가 기본 API에 접근하기 전에 이들을 테스트하고 모의(mock)하는 곳입니다. 몇 가지 구체적인 사용 사례는 다음과 같습니다:
- 루프를 반복하는 동안 **모델 또는 도구 엔드포인트를 모의**하여, 매 실행마다 토큰을 소모하거나 속도 제한에 걸리지 않도록 합니다. Apidog로 AI 에이전트 테스트 하네스 구축에 관한 문서에서 이 패턴을 보여줍니다.
- **도구 응답 형태를 단언**하여, 잘못된 페이로드를 반환하는 도구가 프로덕션 환경이 아닌 테스트에서 감지되도록 합니다. 필드, 타입 및 상태 코드를 검증하는 방법에 대한 API 단언 가이드를 참조하세요.
- **실제 서비스의 응답을 모방하는** **모의 API**를 구축합니다. 여기에는 에이전트가 정상적으로 처리해야 하는 오류 사례도 포함됩니다.
- **환경별 API 키를 관리**하여, 개발, 스테이징, 프로덕션 에이전트가 코드에 자격 증명을 유출하지 않고 올바른 백엔드에 인증하도록 합니다.
분명히 말하자면, Apidog는 에이전트 프레임워크가 아니며 어떤 것도 오케스트레이션하지 않습니다. Strands가 두뇌 역할을 합니다. Apidog는 그 아래의 배관을 위한 작업대입니다. Apidog를 다운로드하고 몇 분 만에 도구 엔드포인트에 대한 모의를 설정할 수 있습니다.
Strands Agents 사용 시점
빠르게 움직이고 모델의 계획을 신뢰하고 싶을 때 Strands를 사용하세요. AWS를 사용하고 Bedrock을 이미 쓰고 있다면, 하나의 에이전트로 시작하여 나중에 다중 에이전트로 확장하고 싶다면, 또는 통합 코드 작성 없이 MCP 도구를 사용하고 싶다면 잘 맞습니다.
모든 분기가 미리 정의되어야 하는 엄격하고 감사 가능한 결정론적 흐름이 필요할 때는 적합하지 않을 수 있습니다. 훅과 다중 에이전트 구조를 통해 여전히 달성할 수 있지만, 그래프 우선 프레임워크가 더 직접적인 해결책일 수 있습니다. 솔직히 말해서, 모델 중심 접근 방식과 그래프 중심 접근 방식은 서로 다른 문제를 해결하며, Strands는 모델 중심 접근 방식입니다.
자주 묻는 질문
Strands Agents는 무료이며 오픈소스인가요?
네. Strands Agents는 GitHub에 소스가 공개되어 있는 Apache License 2.0 하의 오픈소스입니다. SDK 자체에는 라이선스 비용이 없습니다. 모델 및 Bedrock 추론 또는 Lambda 실행과 같이 배포하는 모든 클라우드 리소스에 대해서는 비용을 지불하지만, 프레임워크 자체는 무료입니다.
Strands와 함께 Amazon Bedrock을 사용해야 하나요?
아니요. Bedrock이 기본 제공업체이지만, Strands는 Anthropic API, Llama API, 로컬 실행을 위한 Ollama, 그리고 LiteLLM을 통한 다른 제공업체도 지원합니다. 모델 객체를 변경하고 나머지 코드는 그대로 유지할 수 있습니다. 이는 로컬에서 프로토타입을 만들고 프로덕션을 위해 관리형 제공업체로 전환하기 쉽게 만듭니다.
Strands와 그래프 기반 프레임워크의 차이점은 무엇인가요?
Strands는 모델 중심입니다: 프롬프트와 도구를 제공하면 모델이 단계를 결정합니다. 그래프 기반 프레임워크는 제어 흐름을 노드와 엣지로 정의하도록 요구합니다. Strands는 구축 및 적응 속도가 빠르며, 그래프 프레임워크는 더 엄격하고 예측 가능한 실행을 제공합니다. 많은 팀이 서로 다른 서비스에 두 가지를 모두 사용합니다.
Strands 에이전트가 의존하는 API는 어떻게 테스트하나요?
개발 전과 개발 중에 에이전트와 독립적으로 테스트하세요. LLM 및 도구 엔드포인트를 모의(mock)하고, 응답 형태를 단언하며, CI에서 이러한 검사를 실행하세요. Apidog와 같은 도구는 모의 및 단언을 처리하며, Apidog로 ChatGPT API 테스트하기에 대한 안내는 인증, 스트리밍, 그리고 에이전트 백엔드에 직접 매핑되는 도구 호출 테스트를 다룹니다.
결론
Strands Agents는 에이전트 구축에 대한 깔끔한 접근 방식입니다: 모델, 프롬프트, 도구를 정의한 다음 모델이 루프를 실행하도록 합니다. 단일 에이전트에서 다수의 에이전트로 확장되고, MCP 및 A2A를 지원하며, 재작성 없이 AWS 스택 전체에 배포됩니다. 프레임워크가 추론을 처리합니다. 사용자의 역할은 그 아래에 있는 API가 견고한지 확인하는 것이며, 바로 이 지점에서 Apidog가 빛을 발합니다. 에이전트가 호출하는 엔드포인트를 모의하고 테스트하여 프로덕션이 아닌 테스트에서 실패가 드러나도록 합니다.
