AI 에이전트, 블랙프라이데이, 그리고 2026년을 준비해야 하는 이유는?

2025년, 모두가 말하는 '에이전트의 해'는 맞지만

코드 쓰는 사람들 사이에서만 보면 2025년은 이미 에이전트의 해입니다. Claude 4.5 Opus, GPT‑5.1, Gemini 3 Pro 같은 모델이 잇달아 공개됐습니다. 특히 Claude Code나 코덱스(CodeX) 계열 도구는 실무 개발자의 키보드 사용 시간을 눈에 띄게 줄이고 있습니다. 기업 내부에서는 반품 처리 같은 반복 업무에 에이전트가 투입되고 있습니다. 사용자는 예전보다 훨씬 빨리 환불을 받고 있습니다. 겉으로는 잘 느끼지 못할 뿐입니다.

그런데 소비자 시선으로 보면 얘기가 달라집니다. 올해 블랙프라이데이에서 "에이전트가 대신 쇼핑을 끝까지 알아서 해준다"는 식의 경험을 기대하기는 여전히 어렵습니다. 모델의 성능은 올라갔지만, 결제와 물류까지 이어지는 완결된 상거래 흐름은 아직 여러 조각으로 흩어져 있습니다. 기술이 없어서라기보다, 플랫폼과 생태계의 정리가 덜 되어 있다는 쪽이 더 가깝습니다.

왜 '에이전틱 커머스'는 아직 풀 버전이 아닌가

지금 상황을 한 문장으로 요약하면 이렇습니다. 모델과 API는 준비됐지만, 상거래 인프라는 분산된 상태입니다. OpenAI는 이미 자체 인터페이스 안에서 쇼핑 기능을 실험 중입니다. Shopify 같은 파트너도 붙었습니다. 다만 미국 중심입니다. 커버되는 리테일러도 제한적입니다. Google은 Agentic Commerce Protocol을 내놓았습니다. 브라우저 차원에서 에이전트를 얹으려는 시도입니다. 실제 쇼핑에 적용하려면 시간이 더 필요합니다.

결제 자동화 자체는 문제가 아닙니다. 카드 번호 넣는 일은 이미 충분히 간소화되어 있습니다. 사람이 진짜로 시간을 쓰는 부분은 "무엇을 살지 결정하는 과정"입니다. 예산, 용도, 사이즈, 브랜드, 배송 조건이 얽혀 있습니다. 현재의 범용 챗봇은 이 과정을 완벽하게 대체하기 어렵습니다. 제품 카탈로그와 사용자 의도를 충분히 학습한 모델도 부족합니다. 특정 리테일러 기준으로 최적화된 워크플로우도 아직은 실험 수준입니다.

결국 올 블랙프라이데이의 현실적인 그림은 이 정도입니다. 사용자는 웹 검색과 LLM을 섞어 더 나은 상품 후보를 찾습니다. 결제는 기존 장바구니에서 진행합니다. "버튼 하나로 끝나는 완전 자동 쇼핑"은 1년 정도 더 지켜봐야 할 대상에 가깝습니다.

에이전트는 이미 우리 옆에 있다. 다만 B2B 쪽에서

소비자에게 보이는 에이전트는 아직 어색합니다. 반대로 엔터프라이즈 영역에서는 에이전트 적용이 훨씬 공격적입니다. 특히 반복적이고 규칙이 분명한 프로세스에 집중됩니다. 대형 리테일러의 반품 접수, 티켓 분류, 콜센터 1차 응답 같은 부분이 대표적입니다. 이미 많은 작업이 백엔드 에이전트 워크로드로 바뀌고 있습니다. 사용자는 단지 처리 속도가 빨라졌다고 느낄 뿐입니다.

개발 쪽은 더 극단적입니다. 패널 토론에서도 공통으로 나오는 관찰은 단순합니다. "코딩에는 Claude 4.5가 가장 많이 쓰인다. 연구에는 Gemini. 리뷰와 생성에는 GPT‑5.1." 업무별로 모델을 나누는 패턴입니다. 특히 Claude 4.5 Opus는 토큰 효율과 가격이 개선됐습니다. 기존 Opus 4.1 대비 토큰 사용량를 절반 수준으로 줄였다는 평가도 있습니다. 덕분에 복잡한 리팩터링이나 테스트 케이스 생성에 부담 없이 투입됩니다.

더 눈에 띄는 부분은 기본값의 변화입니다. 예전에는 "가벼운 모델로 먼저 시도. 필요하면 상위 모델 호출" 구조가 일반적이었습니다. 이제는 IDE나 Claude Code 같은 도구에서부터 고사양 모델을 기본으로 세팅하는 흐름이 늘어납니다. 그만큼 비용과 인프라 측면의 자신감이 생겼다는 의미입니다. Azure, Google Cloud, AWS 같은 하이퍼스케일러와의 파트너십이 이를 뒷받침합니다.

에이전트 개발은 쉽다. 배포가 어렵다

에이전트 생태계를 현실적으로 가르는 기준은 단순합니다. "로컬에서 돌려보는 수준"과 "서비스로 내보내는 수준"의 간극입니다. 전자는 이미 충분히 쉬운 단계에 도달했습니다. LangChain, LangGraph, Crew AI, Autogen, Semantic Kernel 같은 프레임워크가 풍부합니다. 심지어 LangFlow 같은 비주얼 도구는 코드 없이도 흐름을 설계할 수 있게 합니다. 프로토타입을 만들고 시험해 보는 일은 더 이상 큰 장벽이 아닙니다.

문제는 그다음입니다. 실제 트래픽을 받는 환경에 에이전트를 올리려면, 두 가지 전혀 다른 성격의 인프라를 붙여야 합니다. 하나는 에이전트의 로직과 상태를 다루는 애플리케이션 영역입니다. 다른 하나는 고비용 LLM 추론 영역입니다. 이 둘의 확장성과 장애 대응 방식을 따로 설계해야 합니다. 에이전트가 외부 도구를 과도하게 호출하지 않도록 제어하는 장치도 필요합니다. 이 부분에서 개발자 경험은 아직 초기 단계입니다.

또 하나의 난제는 계획과 실행의 분리입니다. 요즘 상위권 모델 대부분은 내부에 일종의 플래너를 두고 있습니다. 복잡한 요청이 들어오면 먼저 계획을 세웁니다. 그 후 단계별로 도구를 호출합니다. 현실에서는 모델이 이 계획을 잘 지키지 않습니다. 툴을 너무 자주 쓰거나 건너뛰는 사례가 반복됩니다. 자체 지식에만 의존해서 답을 단정하는 경우도 많습니다. 결국 프로덕션 수준에서는 LLM의 자유도를 줄이고, 결정적인 부분은 규칙 기반이나 가드 모델로 감싸는 설계가 필요합니다. 이 역시 숙련된 개발자가 아니면 손대기 어렵습니다.

누가 이 시장을 가져갈 것인가

플랫폼 관점에서 보면 질문은 두 갈래로 나뉩니다. 어떤 모델 혹은 모델 조합이 에이전트에 가장 적합한가. 어떤 실행 환경이 그 에이전트를 가장 저렴하고 안정적으로 돌려 줄 수 있는가. 지금은 Frontier 모델이 사실상 필수에 가깝습니다. 복잡한 계획 수립과 장기 추론을 요구하는 에이전트에게 중소형 모델은 아직 한계가 분명합니다.

다만 이 구조가 계속 유지된다는 보장은 없습니다. 패널이 언급한 것처럼 '계획 전용 모델' 같은 특화형 소형 모델이 등장할 가능성이 큽니다. 큰 모델은 상황 이해와 창의적 제안에 집중합니다. 작은 모델은 도구 호출 순서 관리와 예외 처리에 집중합니다. 이런 구조가 자리 잡으면 비용 구조가 크게 바뀝니다.

승자 구도에 대한 전망은 엇갈립니다. 하나의 거대 사업자가 모든 에이전트를 장악하는 그림은 가능성이 낮습니다. 오히려 여러 모델 제공자가 흥망을 반복하면서, 그 위에 반복 가능한 에이전트 패턴과 툴 조합을 제공하는 플레이어가 등장할 여지가 큽니다. 과거 AWS가 자사 인프라를 정제해 퍼블릭 클라우드로 내놓았던 흐름과 유사한 시나리오입니다. 특정 도메인의 에이전트를 압도적으로 잘 만드는 회사가, 거기서 추출한 공통 패턴을 수평 플랫폼으로 확장하는 방식입니다.

그 위에 있는 더 큰 축은 마켓플레이스에 가깝습니다. 개별 사용자가 자신만의 데이터와 브랜드, 툴 조합으로 에이전트를 구성하고 이를 하나의 제품처럼 유통하는 구조입니다. 이 지점에서 승자는 특정 모델 회사가 아니라, 조합과 배포를 쉽게 해주는 생태계가 될 가능성이 큽니다.

현실적으로 따져봐야 할 부분들

에이전트를 둘러싼 담론은 빠르게 과대평가와 과소평가를 오갑니다. 소비자 경험 관점에서 보면 "생각보다 별 것 없다"는 평가가 나오기 쉽습니다. 기업 내부에서 보면 이미 사람 손을 대체하는 영역이 조용히 늘어나고 있습니다. 이 두 인식의 간극을 이해하는 것이 먼저 필요합니다.

실무 관점에서 중요한 포인트는 몇 가지입니다. 첫째, 2025년 블랙프라이데이에는 에이전틱 커머스를 과신하지 않는 편이 안전합니다. 추천과 검색 보조 역할에는 충분히 쓸 만합니다. 결제부터 배송까지 전 과정을 맡기기에는 예외 상황 처리와 책임 소재가 정리되지 않았습니다. 둘째, 에이전트 도입의 핵심은 여전히 비용 구조입니다. 사람을 완전히 대체하지 못하는 상태에서 에이전트가 추가 계층으로 붙으면, 생산성이 아니라 비용만 늘어날 수 있습니다. 고가의 Frontier 모델을 장시간 붙들어두는 설계는 특히 검토가 필요합니다.

셋째, 개발 조직 입장에서는 에이전트 자체보다 플로우와 거버넌스를 먼저 설계해야 합니다. 어떤 단계까지는 규칙 기반으로 고정할지, 어디서부터 LLM에게 판단을 맡길지, 실패 시 롤백 전략은 무엇인지 같은 부분입니다. 이 구조가 정리되지 않으면, 프레임워크를 몇 개 더 붙여도 프로덕션에서는 불안한 시스템이 됩니다.

마지막으로, 승자 예측보다 중요한 것은 잠금(lock-in) 구조를 최소화하는 선택입니다. 특정 모델이나 특정 클라우드에 종속된 에이전트 아키텍처는 1~2년 뒤 비용과 성능 측면에서 발목을 잡을 가능성이 큽니다. 에이전트 시대의 진짜 수혜자는 한두 개의 초거대 기업이 아니라, 상황에 따라 모델과 툴을 교체할 수 있는 선택지를 유지한 조직일 가능성이 더 큽니다. 지금 시점에서 해야 할 일은 요란한 데모를 좇는 것이 아니라, 그런 선택지를 열어두는 기본 설계를 차분히 준비하는 일입니다.

출처 및 참고 :