DevOps 엔지니어 B씨는 AI 앱 하나를 만들 때마다 수십 개의 API 호출 순서를 짜고 대화 상태를 관리하는 일에 진을 뺐다. 단순한 아이디어로 시작했지만, 어느새 자연어 처리와 분산 시스템 같은 전문 지식이 없으면 손댈 수 없는 거대한 프로젝트로 불어났다. 머신러닝 박사 학위가 있거나 복잡한 아키텍처와 몇 달을 씨름해야만 겨우 돌아가는 구조였다.

하지만 이제는 30줄의 코드만으로 자율적으로 리서치를 수행하는 AI 어시스턴트를 만들 수 있게 됐다. AWS가 공개한 Strands Agents(에이전트가 스스로 판단해 작업을 수행하게 돕는 도구 모음)를 활용하면 복잡한 설계 과정 없이도 지능형 앱을 빠르게 구현한다. 모델이 직접 논리를 짜고 도구를 선택하게 만들어 개발자가 일일이 경로를 지정할 필요가 없기 때문이다. 이런 곤란을 겪는 개발자가 늘고 있다.

30줄의 코드로 구현하는 Strands Agents와 Kiro

개발자가 AI 리서치 어시스턴트를 하나 만들려면 보통 수개월을 매달려야 했다. 여러 개의 API(소프트웨어 간 통신 규칙)를 연결하고 대화의 맥락을 유지하는 상태 관리 시스템을 직접 설계해야 했기 때문이다. 단순한 아이디어라도 실제 구현 단계에 들어가면 자연어 처리와 분산 시스템이라는 높은 진입장벽에 부딪히는 경우가 많았다. 하지만 Strands Agents를 쓰면 이 모든 과정이 단 30줄의 코드로 압축된다. 이 도구는 Apache-2.0 라이선스를 가진 오픈소스 프레임워크(소프트웨어 개발의 기본 뼈대)다. 개발자가 모든 동작 단계를 일일이 명령어로 적는 하드코딩 방식 대신, 거대언어모델이 스스로 계획을 세우고 적절한 도구를 선택하게 만드는 모델 기반 방식을 쓴다. 터미널에서 아래 명령어를 입력하는 것만으로 준비가 끝난다.

bash
pip install strands-agents

코드 작성 효율은 Kiro라는 AI IDE(인공지능 기반 통합 개발 환경)와 결합했을 때 극대화된다. 개발자가 특정 요구사항을 자연어로 요청하면 Kiro가 Strands Agents의 문법에 맞는 코드를 즉시 생성한다. 사람이 일일이 API 명세서를 읽고 문법을 맞추는 수고를 덜고, 어떤 기능을 넣을지 결정하는 기획에만 집중하게 돕는 구조다. 특히 특정 AI 모델에 갇히지 않는 설계가 특징이다. Amazon Bedrock은 물론 Anthropic이나 OpenAI 등 다양한 LLM(거대언어모델) 제공자를 자유롭게 선택해 연결할 수 있다. 사용자는 자신의 목적에 맞는 모델을 골라 Strands Agents의 유연한 구조 위에 얹기만 하면 된다.

실제 기업 환경에서도 이미 성능 검증을 마친 상태다. AWS 팀은 Amazon Q나 AWS Glue 같은 실제 서비스에 이 프레임워크를 적용해 운영하고 있다. 단순한 일대일 대화형 챗봇을 넘어, 여러 개의 에이전트가 서로 협력하는 네트워크 형태나 상하 관계를 가진 계층 시스템까지 구현할 수 있어 프로젝트 규모가 커져도 대응이 가능하다. 로컬 컴퓨터에서 테스트한 코드를 수정 없이 그대로 실제 서비스 서버에 올릴 수 있어 배포 과정의 시행착오가 적다. 또한 응답이 완성될 때까지 기다리지 않고 글자가 생성되는 대로 바로 보여주는 실시간 스트리밍 방식을 지원한다. 덕분에 사용자는 AI가 생각하고 답하는 과정을 즉각적으로 확인하며 상호작용할 수 있다.

프롬프트와 도구 목록만으로 작동하는 모델 중심 설계

개발자가 며칠 밤을 새우며 짜야 했던 복잡한 조건문 코드는 곧 인건비이자 시간 비용이다. 기존 방식은 사용자가 A라고 말하면 B라는 API를 호출하라는 규칙을 수천 줄씩 적어야 했으며, 이는 머신러닝 전문 지식이 없는 개발자에게 큰 진입장벽이었다. Strands Agents는 이런 하드코딩 대신 모델 중심 접근법을 적용해 개발 공수를 획기적으로 줄인다. 개발자가 프롬프트와 도구 목록만 제공하면 LLM(거대언어모델)이 스스로 상황을 판단해 실행 계획을 세운다. 모델은 사용자의 의도를 분석하고, 어떤 순서로 작업을 처리할지 논리적인 단계를 직접 구성한다. 사람이 모든 경우의 수를 계산해 경로를 설계하지 않아도 AI가 목적지까지 가는 길을 직접 찾게 만든 구조다.

외부 기능을 연결할 때는 `@tool`이라는 데코레이터(함수 위에 붙여 기능을 정의하는 표식)를 사용한다. 이 표식을 붙인 파이썬 함수나 API는 LLM이 사용할 수 있는 도구 상자에 자동으로 등록된다. 모델은 함수의 이름과 설명을 읽고 사용자의 질문에 어떤 도구를 꺼내 쓸지, 어떤 인자값을 넣어야 할지 직접 결정한다. 예를 들어 최신 논문을 찾아달라는 요청이 오면 모델은 도구 목록에서 웹 검색 API를 찾아 적절한 검색어를 생성해 호출한다. 특히 모델 중심 설계 덕분에 Amazon Bedrock, Anthropic, OpenAI 등 어떤 모델 제공자를 선택해도 도구 연결 방식은 동일하게 유지된다. 개발자는 도구의 사용법만 명확히 적어주면 되고, 실제 호출 시점과 방법은 AI의 추론 영역으로 완전히 넘긴다.

시스템 규모에 따라 단일 에이전트에서 다중 에이전트 네트워크, 혹은 상위 모델이 하위 모델을 관리하는 계층 구조까지 자유롭게 확장한다. 단순한 질의응답을 넘어 한 AI는 자료를 찾고 다른 AI는 이를 검토하는 협업 체계를 구축할 수 있다. 작업의 복잡도에 맞춰 AI들의 역할 분담을 설계하면 대규모 프로젝트도 효율적으로 처리한다. AWS 환경에서는 Amazon Bedrock이나 AWS Lambda(서버 없이 코드를 실행하는 서비스)와 자연스럽게 통합되어 실제 서비스 환경에 바로 적용할 수 있는 수준의 안정성을 갖췄다. 여기에 실시간 스트리밍 응답 방식을 더해 사용자가 전체 답변이 완성될 때까지 기다리지 않고 생성되는 내용을 즉시 확인하게 한다. 정적인 프로그램이 아니라 사용자와 실시간으로 대화하며 결과물을 만들어가는 인터랙티브 앱을 구현할 수 있는 기반이 된다.

고정된 경로 설계에서 자율적 도구 선택 구조로의 전환

사용자가 예상치 못한 질문 하나만 던져도 프로그램이 멈추거나 엉뚱한 답을 내놓는 경험은 개발자에게 가장 큰 스트레스다. 예전에는 이런 상황을 막으려고 모든 가능성을 미리 계산해 코드로 짰다. 외부 프로그램 간의 연결 통로인 API를 호출할 때 어떤 순서로 데이터를 주고받을지, 현재 대화 단계가 어디인지 일일이 지정하는 하드코딩 방식이다. 사용자가 A라고 말하면 B API를 부르고, 결과가 C면 D 단계로 넘어가라는 식의 거대한 흐름도를 코드로 구현했다. 마치 여행객에게 갈림길마다 어디로 가야 할지 적힌 아주 상세한 매뉴얼을 쥐여주는 것과 같다. 매뉴얼에 없는 길이 나오거나 작은 변수만 생겨도 프로그램은 즉시 오류를 뱉으며 멈춰 섰다. 개발자는 이 흐름도를 유지보수하기 위해 수천 줄의 조건문을 관리하며 시간을 보냈다.

Strands Agents는 개발자가 경로를 짜는 대신 모델이 상황을 판단해 도구를 고르게 만든다. 개발자는 모델에게 줄 지침인 프롬프트와 사용할 수 있는 도구 목록만 제공하면 된다. 그러면 거대언어모델인 LLM이 사용자의 의도를 분석해 어떤 도구를 어떤 순서로 쓸지 스스로 계획을 세우고 실행한다. 기존 방식이 정해진 레일을 따라 움직이는 기차였다면, 이제는 목적지만 알면 알아서 길을 찾는 자율주행차에 가깝다. 복잡한 조건문을 수백 줄 쓰는 대신 모델의 추론 능력에 실행 권한을 넘긴 결과다. 개발자는 이제 모든 시나리오를 예측해 코딩하는 중노동에서 벗어나, 에이전트가 사용할 도구의 성능을 높이는 일에만 집중하면 된다.

실제 구현 단계에서도 개발자의 수고를 덜어주는 장치들이 들어갔다. 로컬 개발 환경에서 작성한 코드를 수정 과정 없이 그대로 운영 환경에 올려 실행할 수 있는 구조다. 서버 환경이 바뀌었다고 해서 코드를 다시 뜯어고치거나 환경 변수 설정으로 씨름하며 밤을 새우는 일이 사라졌다. 여기에 파이썬 기반 웹 UI 프레임워크인 Streamlit을 더하면 복잡한 웹 개발 지식 없이도 빠르게 결과물을 시각화할 수 있다. 터미널의 검은 화면에서 텍스트만 보는 대신, 웹 브라우저 상에서 AI 에이전트가 어떻게 추론하고 도구를 선택하는지 실시간으로 확인한다. 설치는 아래 명령어로 간단히 해결된다.

bash
pip install streamlit

이처럼 도구 선택의 자율성과 환경의 일관성이 결합하면서, 아이디어를 실제 작동하는 서비스로 만드는 시간이 획기적으로 줄어들었다.

IDE 통합으로 빨라진 반복 개발과 배포 주기

코드를 완벽하게 이해하고 짜야 속도가 난다는 믿음이 오히려 개발을 늦출 때가 있다. Kiro(키로, AI 기반 통합 개발 환경)에서는 자연어 프롬프트만으로 리서치 어시스턴트의 전체 코드를 자동으로 생성한다. 개발자가 구현하고 싶은 요구사항을 일상 언어로 설명하면 Kiro가 Strands Agents와 Streamlit을 조합해 작동하는 애플리케이션 구조를 바로 만들어낸다. 개발자는 파이썬 문법이나 라이브러리 간의 연결 방식을 일일이 고민하며 한 줄씩 적는 대신, 어떤 기능을 넣을지 결정하는 설계 단계에 더 많은 시간을 할애한다. 도구가 구현의 짐을 덜어주면서 아이디어를 실제 작동하는 코드로 바꾸는 시간이 획기적으로 줄어든다.

생성된 코드의 내부 로직을 파악하는 과정도 대화로 해결한다. Kiro의 코드 문맥 설명 기능을 쓰면 복잡한 함수나 클래스가 전체 흐름에서 어떤 역할을 하는지 즉시 알 수 있다. 이는 새로운 프로젝트에 투입된 개발자가 기존 코드를 분석하는 시간을 줄여주는 효과를 낸다. 실제 개발 과정에서 에이전트의 응답이 웹 화면뿐 아니라 터미널 창에도 동시에 출력되어 화면이 지저분해지는 문제가 발생했다. 이때 개발자는 코드를 직접 수정하는 대신 Kiro에게 상황을 설명하고 표준 출력(stdout, 프로그램이 내보내는 기본 결과물) 리다이렉션 설정을 요청해 이 문제를 해결했다. 대화형 피드백을 통해 예상치 못한 예외 상황을 빠르게 수정하며 최적화하는 방식이다.

이렇게 다듬어진 코드는 터미널에서 명령어 한 줄로 즉시 실행된다.

bash
streamlit run research_assistant.py

에서 보듯 사용자는 웹 인터페이스를 통해 주제를 입력하고 AI가 생성한 연구 보고서를 바로 확인할 수 있다. 기존에는 오류를 발견하고 수정하기 위해 코드를 읽고, 수정하고, 다시 실행하는 반복 작업에 많은 시간이 소요됐다. 이제는 IDE 내에서 AI와 대화하며 수정 사항을 바로 반영하므로 개발과 배포 사이의 간격이 극도로 짧아진다. 개발자가 겪는 시행착오의 주기가 분 단위에서 초 단위로 압축되는 셈이다. 실무자 입장에서는 단순 반복 작업이 줄어들어 제품의 완성도를 높이는 디테일에 더 집중할 수 있는 환경이 마련됐다.

한국 AI 실무자가 주목할 엔터프라이즈급 보안과 확장성

로컬 환경에서 잘 돌아가던 AI 에이전트를 실제 서비스로 옮길 때 가장 먼저 부딪히는 벽은 보안이다. 개발자 PC에 저장해둔 API 키나 자격 증명이 서버로 옮겨가는 과정에서 유출될까 봐 전전긍긍하며 설정 파일을 일일이 수정하는 일이 흔하다. 이 불편함을 해결하려면 Amazon Bedrock AgentCore(베드락 에이전트코어, AI 모델과 외부 도구를 연결하는 관리형 서비스)를 통해 원격 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 서버를 활용하면 된다. MCP 서버를 개별 프로세스로 완전히 분리해 격리시키고 인증 체계를 중앙에서 관리하는 방식이다. 개인 PC의 설정 파일에 비밀번호를 적어둘 필요가 없어 자격 증명이 외부에 노출될 위험을 원천적으로 차단한다. 오픈소스의 자유로운 도구 연결성과 클라우드의 강력한 보안망을 동시에 챙기며 엔터프라이즈 수준의 안정성을 확보하는 전략이다.

배포 단계에서는 서버를 직접 띄우고 24시간 관리하는 운영 부담을 덜어내는 것이 핵심이다. Strands Agents는 AWS Lambda(람다, 서버를 직접 관리하지 않고 코드만 올려 실행하는 서버리스 서비스)와 자연스럽게 맞물려 작동한다. 요청이 들어오는 순간에만 코드가 실행되고 사용한 자원만큼만 비용을 지불하는 구조라 초기 구축 비용을 획기적으로 낮출 수 있다. 복잡한 인프라 설계나 서버 사양 고민 없이도 에이전트의 기능을 클라우드 환경에 즉시 올릴 수 있다. 이는 빠른 실행력을 중시하는 한국 AI 실무자들이 프로토타입을 실제 서비스로 전환하는 시간을 단축하는 데 결정적인 역할을 한다.

개발 단계에서 Streamlit(스트림릿, 파이썬으로 빠르게 웹 UI를 만드는 도구)을 사용할 때 간과하기 쉬운 보안 허점이 있다. 기본 설정인 127.0.0.1은 내 컴퓨터에서만 접속 가능하지만, 편의를 위해 이를 0.0.0.0으로 바꿔 외부 네트워크에 노출하는 순간 위험에 노출된다. 별도의 인증 절차나 CSRF(Cross-Site Request Forgery, 사용자가 의도하지 않은 요청을 서버에 보내게 하는 공격) 보호 조치 없이 주소를 공개하면 외부인이 내 에이전트를 마음대로 조작할 수 있다. 특히 브라우저의 DNS-rebinding(디엔에스 리바인딩, 도메인 이름을 조작해 로컬 호스트에 접근하는 공격) 방식의 위협은 로컬 개발 도구에서 자주 발생하는 문제다. 이를 막으려면 인증 게이트웨이를 앞에 두거나 Amazon Bedrock의 비용 캡(Cost Cap, 최대 지출 한도 설정)을 설정해 예상치 못한 요금 폭탄을 방지하는 안전장치를 반드시 갖춰야 한다.