본 글은 AWS Summit Seoul 세션 “200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS”의 내용을 기반으로 작성되었습니다. 개요 생성형 AI는 실험적 프로토타입에서 벗어나, 이제 프로덕션 환경에서 대규모로, 실제 성능 제약 속에서 안정적으로 동작할 것을 요구받고 있습니다. Strands Agents SDK, LangGraph, CrewAI, LlamaIndex 같은 오픈소스 프레임워크의 등장으로 누구나 하루 만에 인상적인 에이전트 […] ||
본 글은 AWS Summit Seoul 세션 “200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS”의 내용을 기반으로 작성되었습니다.
개요
생성형 AI는 실험적 프로토타입에서 벗어나, 이제 프로덕션 환경에서 대규모로, 실제 성능 제약 속에서 안정적으로 동작할 것을 요구받고 있습니다. Strands Agents SDK, LangGraph, CrewAI, LlamaIndex 같은 오픈소스 프레임워크의 등장으로 누구나 하루 만에 인상적인 에이전트 프로토타입을 만들 수 있게 되었습니다. 이들 프레임워크는 오케스트레이션, 도구 실행, 멀티 에이전트 협업, 컨텍스트 관리까지 에이전트 개발에 필요한 핵심 기능을 제공합니다.
그러나 실제 서비스를 운영하려고 하면 이야기가 완전히 달라집니다. 프로토타입과 프로덕션 사이에는 분명한 간극이 존재합니다. 수백 명의 동시 사용자에게 안정적으로 응답해야 하고(성능), 새로운 에이전트나 데이터소스가 추가될 때 유연하게 대응해야 하며(확장성), 운영 환경의 민감 데이터에 대한 접근 제어가 되어 있어야 하고(보안), 에이전트가 어떤 판단을 내렸고 어떤 도구를 호출했는지 추적할 수 있어야 합니다(거버넌스).
이 글에서는 삼성전자 TV Apps Service 팀이 LangGraph로 구축한 자연어 질의 에이전트를 기존 코드를 거의 그대로 유지하면서 Amazon Bedrock AgentCore 위에 올려 프로덕션 수준의 운영 자동화를 확보한 과정을 공유합니다. 다른 팀이 같은 전환을 시도할 때 바로 참고할 수 있도록, 실제 구성과 코드, 그리고 시행착오에서 얻은 교훈을 함께 담았습니다.
배경: 프로토타입에서 프로덕션으로 가는 길
삼성 Smart TV 앱 생태계와 비즈니스 과제
삼성 Smart TV의 앱 서비스는 앱 설치와 스토어 운영을 담당하는 대규모 콘텐츠 배포 플랫폼입니다. 그 규모는 전 세계 200여 개국, 수천 종의 앱, 수만 종의 TV 모델과 펌웨어 버전에 이릅니다. 각 앱은 TV 환경에 따라 지원 여부가 결정되고 환경마다 설치되는 최상위 버전이 달라지기 때문에, 데이터 조합의 경우의 수가 대단히 큽니다.
이 방대한 데이터를 여러 팀의 담당자 수백 명이 매일 조회하며 업무를 수행합니다. 문제는 데이터가 한곳에 있지 않다는 점입니다. 검증계·운영계 관계형 DB, 사내 API, 그리고 KPI 분석용 데이터 스토어 등 서로 다른 시스템에 정보가 파편화되어 있습니다. 매일 이런 문의가 쏟아집니다.
문의 하나당 담당자가 검증계 DB, 운영계 DB, KPI 시스템을 개별적으로 조회해야 했고, 응답까지 수십 분이 소요됐습니다. 데이터 파편화로 같은 질문이 여러 담당자에게 분산되어 도착하는 비효율도 컸습니다. 즉, 문제는 “데이터가 없다”가 아니라 “데이터가 어디에 있는지, 어떻게 조합해야 하는지를 사람이 매번 찾아야 한다”는 데 있었습니다.
팀은 이를 해결하기 위해 LangGraph 기반의 자연어 질의 에이전트를 PoC로 구축했습니다. Supervisor 아래에 KPI 조회, 앱 지원 확인, 앱 검색을 담당하는 하위 에이전트를 두는 멀티 에이전트 구조였습니다. PoC는 자동화의 가능성을 성공적으로 입증했습니다.
에이전트 프레임워크의 프로덕션 전환 시 한계
PoC를 실제 프로덕션으로 옮기려 하자 다섯 가지 구조적 한계가 드러났습니다. 이는 어떤 에이전트 프레임워크로 PoC를 하든 프로덕션 문턱에서 공통적으로 마주치는 한계입니다. 프레임워크는 에이전트의 로직(두뇌)을