Adaptive agentic intelligence framework using Strands Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Strands Agents 기반 AAIF는 일상 요청을 로컬 소형 언어 모델(SLM)로 처리하고 복잡한 요청만 Amazon Bedrock으로 보내 비용과 로컬 지연 시간을 줄이는 것을 목표로 한다.

📌 핵심 요약

• AAIF는 llama3.2:1b 기반 오케스트레이터, Ollama 기반 로컬 처리, Amazon Bedrock 기반 클라우드 처리의 3개 계층으로 구성되며, 모델이 요청을 해석해 적절한 도구로 전달한다.
• IoT 모니터링 예제는 get_device_telemetry로 모의 장치 데이터를 조회하고, analyze_camera_feed에서 llama3.2-vision으로 이미지를 로컬 분석하며, get_expert_insights로 복잡한 분석을 Amazon Bedrock에 요청한다.
• 로컬 처리는 낮은 지연 시간과 클라우드 비의존성을 지향하고 카메라 영상을 장치 안에 유지한다. 클라우드 처리는 더 넓은 맥락과 다단계 추론을 제공하지만 네트워크 왕복이 필요하며, 원문은 구체적인 지연 시간 측정치를 제시하지 않는다.
• 배포 방식은 전체 클라우드, 하이브리드, 완전 로컬로 조정할 수 있다. 원문은 하이브리드에서 약 80%의 트래픽이 유료 API를 거치지 않아 비용을 절감할 수 있다고 설명하지만, 이를 뒷받침하는 실험 결과는 제시하지 않는다.
• 완전 로컬 구성에서는 충분한 메모리를 갖춘 하드웨어에서 3B 모델로 중간 수준의 복잡한 작업을 처리할 수 있으나 가장 어려운 질문의 추론 깊이는 낮아질 수 있다. 여러 에이전트의 도구 공유를 위한 MCP 서버 도입도 제안하지만, 제공된 원문은 해당 설명 도중 끊긴다.

🧩 주요 포인트

1. 라우팅과 처리 도구의 분리 → llama3.2:1b 오케스트레이터와 로컬·Amazon Bedrock 도구를 독립적으로 바꿔 하드웨어와 연결 조건에 맞출 수 있다.
2. 작업 복잡도에 따른 처리 위치 선택 → 일상적인 IoT 조회와 영상 분석은 로컬 처리의 지연 시간·데이터 보존 이점을 얻고, 복잡한 분석은 클라우드의 추론 역량을 활용한다.
3. 약 80%의 유료 API 우회 가능성과 3B 모델의 추론 한계 → 비용 절감과 완전 로컬 운영의 적합성은 실제 요청 구성, 하드웨어 메모리, 어려운 질문의 요구 수준에 따라 판단해야 한다.

🧠 상세 정리

1. 단일 대형 모델에 집중되는 요청의 문제

원문은 단순한 상태 확인부터 복잡한 분석까지 모든 요청을 하나의 크고 비싼 모델로 보내는 에이전트 설계의 문제에서 출발한다. 이런 방식은 API 비용을 높이고 지연 시간을 예측하기 어렵게 만들며, 로컬에서 해결할 수 있는 요청에도 클라우드 모델까지의 네트워크 왕복을 요구해 오프라인 운영 가능성을 없앤다고 설명한다. Strands Agents로 구축한 Adaptive Agentic Intelligence Framework(AAIF)는 일상적인 작업을 로컬 소형 언어 모델(SLM)에 맡기고 더 복잡한 요청을 Amazon Bedrock으로 전달하는 대안을 제시한다. 이 접근은 에이전트 시스템의 많은 호출에서 SLM이 충분한 역량과 적합성, 경제성을 갖춘다고 주장한 NVIDIA의 Belcak 등 연구진의 입장을 근거로 삼는다. 글의 목표는 모든 작업을 작은 모델로 대체하는 것이 아니라, IoT 모니터링 예제를 통해 로컬 처리의 낮은 지연 시간을 유지하면서 모델 조정으로 비용을 줄일 가능성을 보여주는 데 있다.

2. 세 계층 구조와 도구의 역할 분리

AAIF는 스마트 오케스트레이션, 로컬 처리, 클라우드 처리라는 세 계층으로 작업을 나눈다. 의사결정 계층의 llama3.2:1b는 들어온 요청을 분류하고, 로컬 계층은 Ollama에서 실행되는 모델과 도구로 장치 데이터 조회나 이미지 분석을 수행하며, 클라우드 계층은 Amazon Bedrock의 모델로 복잡한 패턴 분석과 전략적 권고를 처리한다. 중심의 Strands 에이전트는 Ollama 런타임에 연결되고 get_device_telemetry, analyze_camera_feed, get_expert_insights라는 세 도구를 노출한다. 원문은 라우팅 로직과 처리 도구를 분리했기 때문에 하드웨어와 네트워크 조건에 따라 도구를 독립적으로 교체하거나 재구성할 수 있다고 설명한다. 또한 메모리 8GB의 Raspberry Pi 같은 엣지 장치부터 전체 클라우드와 하이브리드까지 적용할 수 있다고 소개하지만, 각 구성의 모델별 메모리 사용량이나 실제 성능 측정치는 제공하지 않는다.

3. 실행 환경과 예제 준비

예제를 실행하려면 AWS 계정, 필요한 리전의 Amazon Bedrock 모델 접근 권한, Python 3.10 이상, 적절한 자격 증명으로 설정한 AWS CLI가 필요하다. 로컬 추론을 위해 Ollama를 설치하고 오케스트레이터용 llama3.2:1b와 영상 분석용 llama3.2-vision을 내려받으며, Python 패키지로 strands-agents, strands-agents-tools, boto3도 설치한다. 환경 구성은 aaif-demo 디렉터리를 만들고 Ollama 서버를 실행한 뒤 필요한 모델을 준비하는 순서로 제시된다. 이어 aaif_agent.py 파일에 로컬 도구, 클라우드 도구, 모델 설정과 에이전트 구성을 차례로 추가한다. 이 준비 과정은 로컬 모델 실행 환경과 AWS 접근 환경을 함께 요구하며, 본문의 기본 예제가 두 환경을 결합한 하이브리드 구성임을 보여준다.

4. 로컬 텔레메트리 조회와 영상 분석

Strands Agents는 @tool 데코레이터로 에이전트가 호출할 기능을 정의하며, 첫 번째 도구인 get_device_telemetry는 예제에 저장된 모의 IoT 데이터를 반환한다. 데이터에는 sensor-001 온도 센서, camera-001 보안 카메라, hvac-001 HVAC 제어기가 포함되고, 도구는 이 중 하나를 무작위로 선택해 위치와 상태, 장치별 수치를 보고한다. 따라서 이 코드는 실제 센서 연결을 구현한 것이 아니며, 원문도 운영 환경에서는 실제 IoT 센서와 연결해야 한다고 설명한다. 두 번째 도구인 analyze_camera_feed는 이미지 경로를 받아 llama3.2-vision에 한 문장 설명과 가장 중요한 세 가지 요소를 요청하고, 스트리밍 응답을 모아 반환한다. 영상 분석 모델이 로컬 하드웨어에서 실행되므로 민감한 카메라 영상이 장치를 벗어나지 않는다는 점이 이 구성의 주요 이점으로 제시된다.

5. 복잡한 분석을 위한 Amazon Bedrock 호출

get_expert_insights는 로컬 모델이 처리하기 어려운 요청을 위해 마련한 클라우드 도구로, 맥락 데이터와 질문을 받아 Amazon Bedrock에 전달한다. 구현은 boto3로 us-east-1 리전의 bedrock-runtime 클라이언트를 만들고, 두 입력을 하나의 사용자 메시지로 구성해 converse를 호출한다. 추론 설정은 maxTokens 512, temperature 0.5, topP 0.9이며, 응답에서 텍스트를 추출해 전문가 분석이라는 표시와 함께 반환한다. 모델 식별자는 예시 자리표시자로 남아 있어 실제 사용할 모델의 ID를 지정해야 하며, 본문은 특정 클라우드 모델의 성능을 비교하지 않는다. 원문은 이 도구를 더 넓은 맥락과 다단계 추론이 필요한 분석에 사용한다고 설명하며, 로컬 처리와 달리 네트워크 왕복에 따른 추가 지연이 생긴다는 점을 함께 제시한다.

6. SLM의 요청 해석과 에이전트 실행

오케스트레이터는 Strands의 OllamaModel을 통해 localhost:11434의 llama3.2:1b에 연결하며, max_tokens는 300, temperature는 0.3으로 설정한다. 시스템 프롬프트는 장치 상태와 텔레메트리에는 get_device_telemetry, 이미지나 데이터 분석에는 analyze_camera_feed, 전문가 조언이나 복잡한 질문에는 get_expert_insights를 사용하도록 안내한다. 따라서 원문이 강조하는 명시적 라우팅 규칙의 불필요성은 코드의 키워드 매칭 대신 모델이 프롬프트와 요청 의미를 해석해 도구를 선택한다는 뜻으로 이해할 수 있다. 실행 예시는 장치 상태 확인, camera-001 영상 분석, 현재 텔레메트리 패턴에 따른 최적화 전략 요청을 순서대로 보여주며, 도구 결과 전체를 사용자에게 직접 반환하도록 설정한다. 표에서는 로컬 추론의 지연을 낮음, 클라우드 호출의 지연을 상대적으로 높음으로 표현하지만, 라우팅 정확도나 실제 응답 시간에 대한 정량 결과는 제시하지 않는다.

7. 전체 클라우드·하이브리드·완전 로컬의 선택

전체 클라우드 구성은 Ollama 모델 설정을 BedrockModel로 바꿔 모든 추론을 Amazon Bedrock으로 보내며, 로컬 GPU 없이 관리형 추론의 자동 확장을 활용하는 방식이다. 원문은 지연이 낮고 안정적인 연결을 갖추며 데이터 상주 제약이 없는 팀에 이 구성이 적합하다고 설명한다. 기본 하이브리드 구성은 로컬 SLM 오케스트레이터를 유지하고 로컬 역량을 넘는 요청만 클라우드에 보내며, 약 80%의 트래픽이 유료 API를 거치지 않아 비용을 절감할 수 있다고 서술하지만 해당 비율의 측정 근거는 제시하지 않는다. 완전히 격리된 환경이나 엄격한 데이터 주권 요건이 있는 경우에는 클라우드 도구를 더 큰 로컬 모델로 대체해 모든 처리를 장치 안에서 수행하도록 제안한다. 충분한 메모리를 갖춘 하드웨어의 3B 모델은 1B 오케스트레이터가 넘겨야 했던 중간 수준의 복잡한 작업을 처리할 수 있지만, 가장 어려운 질문에서는 추론 깊이가 줄어드는 절충이 따른다.

8. MCP를 통한 도구 공유와 설명의 범위

마지막 부분은 예제 코드 안에 직접 정의한 로컬 도구 호출에서 출발해, 여러 에이전트가 서비스 전반의 도구를 공유하는 운영 환경으로 논의를 확장한다. 이를 위해 도구를 Model Context Protocol(MCP) 서버로 노출하는 방식을 제안하며, MCP가 도구 검색과 호출에 표준화된 인터페이스를 제공한다고 설명한다. 다만 제공된 원문은 도구 관리의 중앙화를 설명하려는 문장 중간에서 끊겨, 그 이후의 구현 방법이나 운영상 결론을 확인할 수 없다. 본문에서 실제로 제시된 구현 범위는 Strands 에이전트에 세 도구를 직접 연결하고, 로컬 Ollama 모델과 Amazon Bedrock 호출을 조합하는 참조 예제까지다. 따라서 MCP 부분은 향후 확장 방향으로 구분하고, 비용 절감 가능성이나 낮은 로컬 지연 시간에 관한 설명 역시 이 글이 제시한 구조와 정성적 비교의 범위에서 해석해야 한다.

🧾 핵심 주장 / 시사점

• AAIF의 핵심은 작은 모델 하나의 성능보다 요청 분류와 도구 분리에 있다. 같은 구조에서 처리 도구와 모델 설정을 바꾸면 서로 다른 배포 조건에 대응할 수 있다는 것이 원문의 설계 논리다.
• 로컬 처리는 비용과 지연 시간뿐 아니라 카메라 영상의 외부 전송 여부에도 영향을 준다. 다만 완전 로컬 구성에서는 가장 어려운 질문에 대한 추론 깊이를 함께 고려해야 한다.
• 예제는 구조를 이해하기 위한 출발점이다. 모의 텔레메트리, 정량 지연 시간의 부재, 약 80%라는 비율의 실험 근거 부재를 고려하면 운영 효과가 검증된 결과로 해석하기는 어렵다.

✅ 액션 아이템

• IoT 요청의 복잡도를 기준으로 로컬 처리와 Amazon Bedrock 처리의 배분 검토.
• 실제 요청 구성에서 약 80%의 유료 API 우회 가능성과 비용 절감 효과 평가.
• 하드웨어 메모리와 어려운 질문의 요구 수준을 기준으로 3B 모델을 사용하는 완전 로컬 구성의 적합성 판단.

❓ 열린 질문

• llama3.2:1b 오케스트레이터는 실제 IoT 요청을 로컬 도구와 Amazon Bedrock으로 얼마나 정확하게 분류할 수 있는가?
• 실제 요청 구성에서도 약 80%의 트래픽이 유료 API를 거치지 않으며 비용 절감으로 이어지는가?
• 3B 모델을 사용하는 완전 로컬 구성에서 가장 어려운 질문의 추론 깊이 저하는 어느 정도까지 허용할 수 있는가?