AWS re:Invent 2025 키노트로 보는 '에이전트 AI'의 진짜 판도

에이전트가 LLM과 다른 점, 그리고 왜 이제야 산업이 움직이기 시작했는가

요즘 ChatGPT를 써도 업무가 정말로 줄어들지 않는다고 느끼는 사람이 많습니다. 글은 대신 써주는데 프로젝트는 여전히 사람 손을 타기 때문입니다. 이 간극을 이번 re:Invent 키노트가 정면에서 건드렸습니다. 키워드는 단순한 챗봇이 아니라 "에이전트"입니다.

에이전트라는 말은 이미 국내에서도 많이 사용되지만, 스와미가 설명한 정의를 그대로 받아들이면 오해가 생깁니다. 단지 도구 여러 개를 부르는 LLM이 아니라, 목표를 이해하고, 계획을 세우고, 필요한 도구를 스스로 선택해 실행하는 일종의 디지털 동료로 보는 시각이 핵심입니다. "왜 트래픽이 40% 줄었는지 알려줘"라는 질문에, 챗봇은 조언을 늘어놓지만, 에이전트는 실제 로그를 조회하고 이슈를 찾고 티켓을 생성해버리는 차이입니다.

이 지점이 중요한 이유는, 더 이상 "프롬프트를 잘 쓰는 사람"이 생산성을 좌우하는 시대가 아니라는 점입니다. 자연어로 목표를 설명하면, 에이전트가 계획 수립과 실행까지 가져가는 구조로 바뀌고 있습니다. 한국 기업 입장에서 보면, 영어 기반 LLM 프롬프트 스킬을 사내에서 키우느냐 마느냐보다, 업무 프로세스를 어떤 에이전트에게 맡길지 설계하는 역량이 더 중요한 질문이 되는 순간입니다.

에이전트를 구성하는 세 가지 축

스와미는 에이전트를 모델, 코드, 도구라는 세 가지 축으로 단순하게 설명했습니다. 모델은 두뇌 역할을 맡고, 코드가 정체성과 행동 규칙을 정의하며, 도구가 실제 세계를 조작하는 손발이 됩니다. 흥미로운 부분은 이 세 가지를 어떻게 "오케스트레이션할 것인가"를 AWS가 아예 플랫폼 수준의 문제로 끌어올렸다는 점입니다.

예전에는 개발자가 상태 머신을 직접 짜고, 각 단계에서 어떤 API를 호출할지 일일이 코드에 박아 넣어야 했습니다. 모델이 충분히 똑똑하지 못해 다음 행동을 스스로 결정하지 못했기 때문입니다. 이제는 모델의 추론 능력을 전제로, 사람이 짰던 복잡한 분기 로직을 SDK와 플랫폼으로 걷어내려는 시도가 시작됐습니다. 다시 말해, "비즈니스 프로세스를 코드로 박제하던 시대"에서 "모델이 상황에 맞게 행동을 조합하는 시대"로 설계 철학이 이동하고 있습니다.

LLM 시대의 진짜 전환점은 '누가'와 '얼마나 빨리'이다

키노트의 첫 머리에서 스와미는 두 가지를 강조했습니다. 누가 만들 수 있는지의 범위와, 얼마나 빨리 만들 수 있는지의 속도입니다. 문법과 API를 외워야만 개발자가 될 수 있었던 시대와 달리, 이제는 자연어로 목적을 표현할 수 있으면 에이전트를 만들 수 있는 방향으로 이동하고 있습니다.

여기서 놓치기 쉬운 포인트가 있습니다. "누구나 만든다"는 말이 "누구나 잘 만든다"는 뜻은 아니라는 점입니다. 인터넷이 누구나 웹사이트를 만들 수 있게 했지만, 결국 트래픽과 매출은 소수에게 몰린 것과 똑같은 구조가 재연될 가능성이 큽니다. 자연어로 만들 수 있는 시대일수록, 업무를 어떻게 쪼개고, 어떤 책임을 어느 에이전트에게 위임할지 설계하는 능력이 진짜 격차를 만들 가능성이 높습니다.

AWS가 그리는 에이전트 기술 스택: Strands와 AgentCore, 그리고 커스터마이징

많은 팀이 지금 노트북 위에서 멋진 에이전트 POC를 만들지만, 실제 서비스에 올리려 하면 발이 묶입니다. AWS는 이 단절을 "POC 감옥"이라고 부르며, 이번 발표의 상당 부분을 여기에 할애했습니다. 흥미로운 점은 이 감옥을 빠져나오는 길을 두 층으로 나눴다는 점입니다. 개발자 편의성과 운영·거버넌스입니다.

Strands: 에이전트 SDK의 리팩터링 선언

Strands는 AWS가 공개한 에이전트 SDK로, "모델 주도형 에이전트"라는 표현이 반복됐습니다. 의미를 풀어보면, 상태 머신과 분기 로직을 사람 손으로 설계하는 대신, 최대한 LLM에게 위임해 보자는 선언에 가깝습니다. AWS 내부 에이전트 시스템에서 수천 줄의 오케스트레이션 코드를 없앴다고 강조하는 것도 같은 맥락입니다.

타입스크립트 지원과 엣지 디바이스 지원 소식도 나왔지만, 실무 관점에서 더 중요한 포인트는 따로 있습니다. 오픈소스로 공개되어 있다는 점과, 다수의 커뮤니티 기여가 이미 들어왔다는 점입니다. 한국 개발자에게는 "AWS가 만든 LangChain 비슷한 것" 정도로 들릴 수 있지만, 실상은 그보다 더 전략적인 의미가 있습니다. 플랫폼 종속을 최소화하면서도 AWS 생태계와 자연스럽게 이어지도록 설계된, 일종의 관문 역할을 노리고 있기 때문입니다.

국내 팀들이 직접 SDK를 선택할 때는, 단순히 기능 목록만 비교하기보다 "내가 이 SDK로 만든 에이전트가 내일 다른 클라우드로도 옮겨갈 수 있는가"를 기준으로 보는 것이 좋습니다. Strands는 이 지점에서 비교적 균형 잡힌 위치를 차지하고 있습니다.

AgentCore: 에이전트의 운영체제 같은 존재

Strands가 에이전트의 개발 도구에 가깝다면, AgentCore는 배포 이후의 세계를 책임지는 운영 플랫폼입니다. 스케일 아웃, 세션 격리, 메모리, IAM, 도구 연결, 관측과 디버깅까지, 에이전트 운영 과정에서 발생하는 귀찮은 문제를 모듈로 쪼개 관리할 수 있게 했습니다.

재미있는 사례는 Cox Automotive와 Blue Origin 같은 고객 이야기입니다. 수천 개 에이전트를 마켓플레이스 형태로 돌리는 조직에서, 개별 팀이 각자 인증·권한·로그 수집을 구현한다면 유지보수가 사실상 불가능해집니다. AgentCore는 이 공통 분모를 서비스로 끌어올려, 팀이 에이전트 기획과 도메인 로직에만 집중하도록 하는 역할을 맡습니다. 한국 기업 입장에서는 "사내 에이전트 허브"를 구축할 때, 이와 유사한 구조를 어떻게 재현할지 고민하는 참고 사례로 보는 것이 유용합니다.

기억, 그리고 강화학습으로 가는 길목

키노트 후반부에서 흥미로웠던 장면은 '에피소딕 메모리' 이야기였습니다. 짧은 대화 맥락과 장기 선호를 넘어서, 특정 상황과 감정이 묶인 경험 단위로 기억을 저장하겠다는 개념입니다. 출장 혼자 갈 때와 아이 둘과 함께 갈 때, 공항 도착 시간을 다르게 추천하는 예시가 대표적입니다. 이 수준의 개인화는 단순 RAG로는 구현이 어렵고, 에이전트 플랫폼 차원에서 설계해야 할 문제입니다.

여기에 강화학습 기반 커스터마이징이 덧붙습니다. Amazon Bedrock의 Reinforcement Fine Tuning은, 복잡한 RL 파이프라인을 몰라도 로그와 평가 함수만 있으면 모델을 튜닝할 수 있게 만든 접근입니다. 대형 조직이 아니라도, "이 도메인에서는 이런 답이 좋은 답이다"라는 기준만 정의할 수 있다면, 점점 에이전트의 행동이 조직 문화를 닮아가도록 학습시킬 수 있다는 의미입니다. 다만 이 지점에서 한 가지 조건이 생깁니다. 로그를 남기고, 평가 기준을 정의하고, 이를 피드백 루프로 돌리는 문화가 없는 조직에는 이 기능이 거의 쓸모가 없습니다.

현장에서 드러난 가능성과 위험: 우주 기업과 프론트엔드 플랫폼이 보여준 것

기술 데모보다 중요한 것은, 실제 회사가 무엇을 버리고 무엇을 얻었는지입니다. 이번 키노트에는 Blue Origin과 Vercel이 차례로 등장해, 에이전트와 AI 인프라를 어떻게 사용 중인지 비교적 구체적으로 보여줬습니다. 두 회사의 환경은 극단적으로 다르지만, 공통된 패턴이 뚜렷하게 보였습니다.

Blue Origin: 전문 지식이 LLM 밖에 있을 때 생기는 일

우주 발사체와 달 표면 인프라를 만드는 조직의 지식은 인터넷에 거의 없습니다. 키노트에서도 "우리가 필요한 지식은 대부분 사내 시스템과 데이터베이스, 그리고 암묵지 안에 있다"는 표현이 나왔 위반# AWS re:Invent 2025 키노트로 보는 '에이전# AWS re:Invent 2025 키노트로 보는 '에이전 여부를 기계적으로 검증할 수 있는 장치가 있어야 한다는 점입니다. 그래서 마지막에 뉴로심볼릭 AI와 자동 추론 이야기가 등장합니다. LLM이 짠 정책을 형식 논리로 검증하고, API 호출이 오작동하지 않도록 수학적으로 확인하는 층이 없으면, 신뢰 문제 때문에 에이전트의 자유도를 거의 열어줄 수 없습니다.

에이전트 도입 전 반드시 점검할 것: 우리 조직에 맞는 전략은 무엇인가

에이전트 이야기를 듣고 나면 많은 조직이 바로 "우리도 사내 에이전트 플랫폼을 만들겠다"는 결심을 합니다. 그러나 몇 가지 현실적인 조건을 살펴보지 않으면, 또 하나의 POC 감옥이 하나 더 생기기 쉽습니다. 화려한 데모와 성공 사례 뒤에 숨어 있는 전제 조건을 차분하게 짚어볼 필요가 있습니다.

기술보다 먼저 점검해야 할 조직의 습관

에이전트 플랫폼의 본질은 업무를 코드와 데이터로 정의하는 능력입니다. 그런데 많은 조직은 여전히 "선배가 하던 대로" 일을 처리합니다. 체크리스트도 없고, 의사결정 기준도 문서화돼 있지 않습니다. 이런 상태에서는 아무리 뛰어난 SDK와 플랫폼을 도입해도, 에이전트에게 맡길 업무를 구조화 자체하기 어렵습니다.

또 하나의 현실적인 제약은 데이터 품질입니다. 강화학습이든 에피소딕 메모리든, 전제는 로그가 잘 쌓여 있고, 그 로그를 비즈니스 관점에서 해석할 사람이 있다는 점입니다. 한국 기업이 에이전트 전략을 세울 때, "어떤 에이전트를 먼저 만들까"보다 "어떤 업무가 이미 데이터와 규칙의 형태로 정리돼 있는가"를 먼저 묻는 편이 훨씬 효율적입니다.

첫 번째 행동: 작은 에이전트, 명확한 도메인, 끝까지 운영해 보기

현실적으로 가장 좋은 출발점은, 범위를 지나치게 넓히지 않는 것입니다. 전사 챗봇 대신, 한 팀 또는 한 프로세스에 집중된 "단일 임무 에이전트"를 고르는 편이 좋습니다. 예를 들어 코드 리뷰 요약, 특정 제품군에 한정된 고객 문의 분류, 내부 문서 작성 템플릿 자동화처럼 시작과 끝이 분명한 업무가 적합합니다.

이때 꼭 포함해야 할 단계가 하나 더 있습니다. 바로 운영 단계에 대한 계획입니다. 모델을 무엇으로 쓸지, 로그를 어디에 남길지, 잘못된 행동을 어떻게 피드백할지, 사람 개입은 어느 지점에서 할지 같은 항목이 미리 정리돼야 합니다. AgentCore나 Strands 같은 도구를 쓰든, 오픈소스 스택을 직접 엮든, 결국 관건은 "운영을 반복할수록 에이전트가 나아지는 구조"를 만들 수 있는지입니다.

에이전트 AI는 이미 일부 조직에서는 일상이 되어 가고 있습니다. 다만 그 속도와 범위는 업계와 회사 규모에 따라 크게 달라질 것입니다. 한국 기업과 개인 개발자가 지금 할 수 있는 최선은, 거대한 약속에 압도되기보다, 데이터와 프로세스를 정리해 작은 에이전트를 성공적으로 운영해 보는 경험을 쌓는 일입니다. 이 경험이 쌓여야, AWS가 제시한 거대한 에이전트 생태계 그림에서 어디를 선택해 올라탈지 제대로 판단할 수 있습니다.

출처 및 참고 :