AWS Strands Agents란? 오픈 소스 모델 기반 에이전트 SDK

거대한 if/else 상태 머신으로 AI 에이전트를 만들면 기능이 늘어날수록 라우팅, 예외 처리, 재시도 로직이 빠르게 취약해집니다. Strands Agents는 반대로 접근합니다. 사용자는 시스템 프롬프트와 도구 목록을 제공하고, 모델이 계획 수립과 도구 호출 순서를 결정하게 합니다. Strands Agents는 AWS의 오픈소스 SDK로, 2025년 5월 Apache License 2.0에 따라 공개되었으며 Amazon Q Developer 및 AWS Glue와 같은 Amazon 팀의 프로덕션 에이전트에도 사용됩니다.

지금 Apidog를 사용해 보세요

Strands Agents의 실제 동작 방식

Strands Agents는 몇 줄의 코드로 AI 에이전트를 만들고 실행하기 위한 SDK입니다. 기본 구성은 단순합니다.

1. 사용할 모델을 선택합니다.
2. 에이전트의 역할을 시스템 프롬프트로 정의합니다.
3. 모델이 호출할 수 있는 도구를 등록합니다.
4. 에이전트를 함수처럼 호출합니다.

실행 시 모델은 프롬프트를 읽고, 필요한 도구를 선택하고, 도구 실행 결과를 확인한 뒤, 작업이 끝났다고 판단할 때까지 이 루프를 반복합니다.

Strands는 Python과 TypeScript를 지원합니다. 이름은 에이전트를 구성하는 핵심 요소인 모델과 도구를 가리킵니다. AWS가 내부에서 운영한 뒤 오픈소스로 공개했기 때문에, 설계는 단순 데모보다 프로덕션 요구 사항에 가깝습니다. 미리보기 출시 이후 PyPI 다운로드 수가 15만 회를 넘었고, 다중 에이전트 기본 요소와 에이전트 간 A2A 프로토콜 지원을 포함한 1.0 릴리스에 도달했습니다.

이미 다른 에이전트 SDK를 검토했다면 Strands의 위치는 익숙할 수 있습니다. Strands는 LangGraph 및 Google ADK와 같은 범주에 있지만, 사용자가 직접 그래프를 설계하기보다 모델의 추론 루프에 더 많은 제어권을 줍니다.

모델 중심 방식과 하드코딩된 오케스트레이션 비교

초기 에이전트 프레임워크는 보통 워크플로우를 먼저 정의하도록 요구했습니다. 노드, 엣지, 조건, 라우팅 규칙을 작성하고, 모델은 그 안에서 선택을 수행합니다.

Strands는 이 책임을 모델 쪽으로 이동합니다. 최신 모델은 목표를 이해하고, 중간 단계를 계획하고, 도구를 호출하고, 결과를 바탕으로 다음 행동을 정할 수 있습니다. 따라서 개발자는 모든 분기를 코드로 인코딩하는 대신 다음 두 가지에 집중합니다.

• 좋은 시스템 프롬프트 작성
• 모델이 사용할 수 있는 도구 제공

접근 방식	개발자가 정의하는 것	제어 흐름 위치	새 기능 추가 비용
하드코딩된 오케스트레이션	노드, 엣지, 조건, 라우팅	사용자 그래프 코드	그래프 수정, 경로 재테스트
모델 중심 방식, 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 함수를 모델이 호출 가능한 도구로 변환합니다.

실무에서 확인해야 할 부분은 다음과 같습니다.

• 함수 이름은 모델이 이해하기 쉬워야 합니다.
• 독스트링은 도구의 목적을 명확히 설명해야 합니다.
• 타입 힌트는 입력 스키마로 사용되므로 가능한 한 정확해야 합니다.
• 도구는 예측 가능한 응답 형태를 반환해야 합니다.

예를 들어 외부 API를 호출하는 도구라면 다음처럼 실패 케이스를 명시적으로 반환하는 편이 디버깅에 유리합니다.

from strands import tool
import requests

@tool
def get_user_status(user_id: str) -> dict:
    """Fetch the current status for a user by user_id."""
    try:
        res = requests.get(
            f"https://api.example.com/users/{user_id}/status",
            timeout=5,
        )
        res.raise_for_status()
        return {
            "ok": True,
            "data": res.json(),
        }
    except requests.RequestException as exc:
        return {
            "ok": False,
            "error": str(exc),
        }

이렇게 하면 모델이 도구 실패를 일반 예외가 아니라 처리 가능한 결과로 볼 수 있습니다.

모델 제공업체 선택하기

Strands는 모델 제공업체에 유연합니다. 기본 제공업체는 Amazon Bedrock이며, 기본적으로 에이전트는 us-west-2 리전의 Claude Sonnet 모델을 사용합니다. 정확한 기본 모델 ID는 SDK 버전에 따라 달라질 수 있으므로 코드에 하드코딩하기보다 설치된 SDK 문서를 확인하는 것이 좋습니다.

지원 가능한 모델 경로는 다음과 같습니다.

• 도구 사용 및 스트리밍을 지원하는 Amazon Bedrock 모델
• Anthropic API를 통한 Claude 제품군
• Llama API를 통한 Llama 모델
• 로컬 개발용 Ollama
• LiteLLM을 통한 OpenAI 등 기타 제공업체

실무에서는 다음 흐름이 유용합니다.

1. 로컬에서는 Ollama 또는 개발용 모델로 빠르게 반복합니다.
2. 도구 스키마와 프롬프트를 안정화합니다.
3. 프로덕션에서는 Bedrock 또는 관리형 제공업체로 전환합니다.
4. 에이전트 코드와 도구 코드는 최대한 그대로 유지합니다.

제공업체 전환은 보통 모델 객체 변경에 가깝고, 에이전트 루프나 도구 자체를 다시 작성하는 작업은 아닙니다.

도구 설계 체크리스트

Strands에서 도구는 에이전트가 외부 세계와 상호작용하는 인터페이스입니다. 도구는 다음 중 하나일 수 있습니다.

• 직접 작성한 Python 함수
• 커뮤니티 패키지에서 제공하는 도구
• MCP 서버를 통해 노출된 도구
• REST API를 감싼 래퍼 함수

도구를 작성할 때는 다음 기준을 적용하세요.

@tool
def search_orders(customer_id: str, limit: int = 10) -> dict:
    """
    Search recent orders for a customer.

    Args:
        customer_id: The customer identifier.
        limit: Maximum number of orders to return.
    """
    ...

권장 사항:

• 입력 파라미터를 작게 유지합니다.
• 반환값은 JSON 직렬화 가능한 구조로 유지합니다.
• 성공과 실패 응답의 형태를 일관되게 만듭니다.
• 외부 API 호출에는 timeout을 설정합니다.
• 인증 정보는 코드에 직접 넣지 말고 환경 변수나 시크릿 관리자를 사용합니다.
• 모델이 오해하지 않도록 독스트링에 도구의 목적과 제한을 적습니다.

다중 에이전트와 MCP 사용하기

단일 에이전트로도 많은 작업을 처리할 수 있지만, 실제 서비스에서는 역할 분리가 필요할 수 있습니다. Strands 1.0은 다중 에이전트 애플리케이션을 위한 기본 요소를 제공합니다.

대표적인 패턴은 다음과 같습니다.

• Agent-as-Tool: 한 에이전트를 다른 에이전트가 호출 가능한 도구처럼 사용합니다.
• Swarm 스타일 조정: 여러 에이전트가 하나의 문제를 함께 해결합니다.
• A2A 프로토콜: Strands 에이전트가 다른 프레임워크로 만든 에이전트와 통신할 수 있습니다.

예를 들어 고객 지원 시스템에서는 다음처럼 역할을 나눌 수 있습니다.

• 라우터 에이전트: 사용자 요청을 분류
• 주문 조회 에이전트: 주문 API 호출
• 환불 정책 에이전트: 정책 문서 검색
• 응답 작성 에이전트: 최종 답변 정리

MCP도 Strands에서 중요한 통합 방식입니다. 모델 컨텍스트 프로토콜, MCP는 모델을 도구 및 데이터 소스에 연결하기 위한 개방형 표준입니다. Strands는 게시된 MCP 서버에 연결하고, 해당 서버의 도구를 에이전트에 전달할 수 있습니다.

이미 MCP 서버를 운영 중이라면 새 기능을 에이전트에 붙이는 가장 빠른 방법이 될 수 있습니다. 단, MCP 서버의 응답 안정성에 에이전트 품질이 직접 의존하므로 엔드포인트 테스트와 모의 응답 검증이 중요합니다.

Strands 에이전트 배포하기

Strands는 노트북이나 로컬 스크립트에서 시작해 프로덕션 환경으로 이동할 수 있도록 설계되었습니다. 에이전트는 일반 Python 또는 TypeScript 애플리케이션이므로 기존 배포 방식을 그대로 적용할 수 있습니다.

배포 대상 예시는 다음과 같습니다.

• 관리형 에이전트 런타임을 위한 Amazon Bedrock AgentCore
• 이벤트 기반 단기 작업을 위한 AWS Lambda
• 컨테이너화된 장기 실행 서비스를 위한 AWS Fargate 또는 Amazon EKS
• 컨테이너를 실행할 수 있는 일반 Docker 환경

배포 전에는 최소한 다음 항목을 확인하세요.

# 예시: 환경 변수 확인
echo $AWS_REGION
echo $MODEL_PROVIDER
echo $TOOL_API_BASE_URL

운영 환경에서는 다음을 분리하는 것이 좋습니다.

• 모델 설정
• 도구 API의 base URL
• 인증 토큰
• timeout 및 retry 정책
• 로깅 레벨
• 관찰성 설정

AWS는 관찰성 훅도 문서화하고 있으므로, 운영 중에는 다음 정보를 추적해야 합니다.

• 모델이 선택한 도구
• 도구 호출 입력값
• 도구 응답 상태
• 실패한 외부 API
• 최종 응답 생성까지 걸린 시간

Apidog로 Strands 에이전트의 API 의존성 테스트하기

Strands는 에이전트를 구축하는 SDK입니다. 하지만 에이전트가 호출하는 API 자체를 검증해 주지는 않습니다. 실제 Strands 에이전트는 보통 두 종류의 HTTP 엔드포인트에 의존합니다.

1. 모델 뒤에 있는 LLM 제공업체 API
2. @tool 함수 또는 MCP 서버 뒤에 있는 REST API 및 도구 API

이 엔드포인트가 불안정하면 에이전트는 모델 문제처럼 보이는 방식으로 실패할 수 있습니다. 실제 원인은 잘못된 상태 코드, 변경된 응답 필드, 인증 실패, timeout일 수 있습니다.

Apidog는 에이전트가 실제 API에 접근하기 전에 엔드포인트를 테스트하고 모의할 수 있는 작업 공간입니다.

실무에서 사용할 수 있는 패턴은 다음과 같습니다.

• 모델 또는 도구 엔드포인트 모의
  
  개발 루프에서 매번 실제 모델 호출 비용을 쓰거나 rate limit에 걸리지 않도록 합니다. 관련 패턴은 Apidog로 AI 에이전트 테스트 하네스 구축 문서에서 확인할 수 있습니다.

• 도구 응답 형태 검증
  
  도구가 잘못된 payload를 반환하면 프로덕션이 아니라 테스트 단계에서 발견해야 합니다. 필드, 타입, 상태 코드 검증은 API 단언 가이드를 참고하세요.

• 모의 API 구성
  
  실제 서비스와 유사한 정상 응답, 오류 응답, 빈 결과, 인증 실패 케이스를 만들어 에이전트가 어떻게 반응하는지 테스트합니다. 자세한 내용은 모의 API를 참고하세요.

• 환경별 API 키 관리
  
  개발, 스테이징, 프로덕션 에이전트가 서로 다른 백엔드에 안전하게 인증하도록 구성합니다. 인증 정보를 코드에 직접 넣지 않는 것이 핵심입니다.

예를 들어 Strands 도구가 다음 API에 의존한다고 가정합니다.

@tool
def get_invoice(invoice_id: str) -> dict:
    """Get invoice details by invoice_id."""
    ...

Apidog에서는 다음 케이스를 먼저 정의할 수 있습니다.

케이스	예상 상태	에이전트가 처리해야 할 동작
정상 invoice 조회	200	금액, 상태, 만기일을 사용자에게 요약
존재하지 않는 invoice	404	찾을 수 없다고 명확히 응답
인증 실패	401	내부 인증 문제로 안내하거나 재시도 중단
서버 오류	500	일시적 실패로 처리하고 안전하게 종료

분명히 말하면 Apidog는 에이전트 프레임워크가 아니며 오케스트레이션을 수행하지 않습니다. Strands가 에이전트의 두뇌라면, Apidog는 그 아래 API 배관을 검증하는 작업대입니다. Apidog를 다운로드해 도구 엔드포인트에 대한 모의를 빠르게 설정할 수 있습니다.

Strands Agents를 사용할 시점

Strands는 다음 상황에 잘 맞습니다.

• 모델의 계획 능력을 활용해 빠르게 에이전트를 만들고 싶을 때
• AWS와 Bedrock을 이미 사용 중일 때
• 단일 에이전트로 시작해 나중에 다중 에이전트로 확장하고 싶을 때
• MCP 도구를 별도 통합 코드 없이 사용하고 싶을 때
• 도구 목록과 프롬프트를 중심으로 에이전트를 반복 개선하고 싶을 때

반대로 다음 상황에서는 신중해야 합니다.

• 모든 분기가 사전에 정의되어야 할 때
• 감사 가능한 결정론적 실행 흐름이 필수일 때
• 모델이 제어 흐름을 선택하면 안 되는 규제 환경일 때
• 그래프 기반 워크플로우가 이미 명확하게 정의되어 있을 때

Strands에서도 훅과 다중 에이전트 구조로 제어를 추가할 수 있습니다. 하지만 기본 철학은 그래프 우선이 아니라 모델 중심입니다.

구현 전 체크리스트

Strands로 첫 에이전트를 만들기 전에 다음 항목을 정리하면 시행착오를 줄일 수 있습니다.

• [ ] 에이전트가 해결할 작업을 한 문장으로 정의했는가?
• [ ] 시스템 프롬프트에 역할, 제한, 출력 형식을 명시했는가?
• [ ] 각 도구의 입력과 출력이 명확한가?
• [ ] 도구 함수에 타입 힌트와 독스트링이 있는가?
• [ ] 외부 API 호출에 timeout이 있는가?
• [ ] 실패 응답 형태가 일관적인가?
• [ ] 실제 API 대신 사용할 mock이 있는가?
• [ ] 개발, 스테이징, 프로덕션 환경 변수가 분리되어 있는가?
• [ ] 모델 호출과 도구 호출 로그를 추적할 수 있는가?

자주 묻는 질문

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 및 도구 엔드포인트를 모의하고, 응답 형태를 단언하며, CI에서 검사를 실행하세요. Apidog 같은 도구는 mock과 assertion을 처리할 수 있습니다. Apidog로 ChatGPT API 테스트하기 가이드는 인증, 스트리밍, 도구 호출 테스트와 같은 에이전트 백엔드에 직접 연결되는 내용을 다룹니다.

결론

Strands Agents는 에이전트 구축을 단순화합니다. 모델, 시스템 프롬프트, 도구를 정의하면 모델이 추론 루프를 실행합니다. 단일 에이전트에서 다중 에이전트로 확장할 수 있고, MCP 및 A2A를 지원하며, AWS 스택 또는 일반 컨테이너 환경으로 배포할 수 있습니다.

구현에서 중요한 부분은 에이전트 자체만이 아닙니다. 에이전트가 호출하는 API가 안정적이어야 합니다. 도구 엔드포인트를 모의하고, 응답 형태를 검증하고, 실패 케이스를 미리 테스트하면 모델 문제가 아닌 API 문제를 더 빨리 발견할 수 있습니다. 이 지점에서 Strands와 Apidog를 함께 사용하면 에이전트 개발 루프를 더 안전하게 만들 수 있습니다.