AI 에이전트의 경쟁력은 어디에 쌓이는가

이 리포트가 묻는 것

에이전트 제품의 시연에서는 질문을 받아 검색하고 도구를 호출하는 장면이 눈에 띈다. 실제 업무에서는 그 뒤가 더 길 수 있다. 주문 상태를 잘 읽었는지, 사용자가 그 주문을 바꿀 권한이 있는지, 시스템이 응답하지 않았을 때 변경이 이미 처리됐는지 확인해야 한다.

이 글의 질문은 “어느 회사가 이길까”가 아니다. 여러 제품이 비슷한 모델에 접근할 수 있을 때, 고객이 계속 쓸 이유가 어느 층에 쌓일 수 있는가다. 공개 기술 문서와 시스템 원리에 기초한 편집 분석이며, 기업 매출·시장 점유율·고객 인터뷰를 직접 조사한 투자 보고서는 아니다. 뒤의 비용 수치는 계산을 설명하기 위한 가정이다.

핵심 가설은 업무를 아는 연결과 완료를 확인하는 체계가 모델의 능력을 제품 가치로 바꾸는 데 중요하다는 것이다. 다만 이것이 특정 업체의 지속적인 우위를 보장하지는 않는다. 표준화와 플랫폼의 기능 통합이 같은 이점을 약하게 만들 수 있다.

먼저 자동화와 에이전트의 경계를 나눈다

고정된 순서로 자료를 읽고 요약을 만드는 파이프라인도 유용한 AI 제품이다. 다음 행동과 도구를 모델이 상황에 맞게 고르는 시스템은 다른 수준의 변동성을 갖는다. Anthropic의 에이전트 구축 글은 미리 정해진 경로의 워크플로와 모델이 동적으로 과정을 이끄는 에이전트를 구분한다. 이 구분은 제품의 품질 순위가 아니라 통제 방식의 차이다.

ReAct 연구는 추론과 행동, 환경에서 얻은 관측을 이어 가는 구조를 다룬다. 이 반복은 한 번의 생성으로 알 수 없었던 정보를 다음 행동에 반영할 수 있게 한다. 그러나 반복 자체가 성공을 보장하지 않는다. 틀린 검색을 계속하거나 동일한 변경을 다시 실행할 수도 있다.

따라서 정해진 입력으로 정해진 결과를 내는 작업에 항상 높은 자율성이 필요한 것은 아니다. 경로가 명확한 부분은 코드로 제한하고, 모호한 부분만 모델의 판단에 맡기는 조합도 가능하다. 제품의 이름보다 어떤 결정을 모델에 넘겼는지 살펴보면 설계가 더 잘 보인다.

경쟁력을 세 층으로 읽는다

층	고객이 체감하는 가치	확인할 근거
모델과 추론	어려운 요청 이해, 계획, 도구 선택	같은 업무 평가에서의 성공·실패 유형
업무 연결	필요한 정보를 가져오고 실제 시스템에 반영	데이터 갱신, 권한, 쓰기 동작의 범위
운영과 완료	결과를 확인하고 실패를 복구	검증된 완료율, 사람 개입, 재시도·복구 비용

첫 층이 좋아지면 두 번째와 세 번째의 일부 부담이 줄 수 있다. 예를 들어 모델이 도구 인자를 더 잘 만들면 입력 오류가 줄어든다. 하지만 조직의 환불 권한, 중복 요청 처리, 오래된 데이터의 폐기 규칙까지 모델 점수 하나로 결정할 수는 없다. 이런 규칙은 업무 시스템과 운영 정책에도 걸쳐 있다.

업무 연결은 커넥터 수만으로 평가하기 어렵다. 같은 주문 조회 API가 있어도 현재 상태를 읽기만 하는 것과 상태 변경까지 안전하게 수행하는 것은 다르다. 필드의 의미, 작업의 선행 조건, 오류 응답의 해석을 연결해야 한다. 제품이 다루는 작업 범위를 구체적으로 볼수록 “수백 개 도구 연결” 같은 개수 지표의 한계가 드러난다.

이 세 층은 편집상 분석 틀이다. 제품마다 소유하거나 외부에 맡기는 범위가 다르며, 한 층의 강점이 다른 층의 약점을 언제나 상쇄하는 것도 아니다.

재시도가 많을수록 더 똑똑한 시스템일까

조회 요청이 실패하면 다시 읽으면 되는 경우가 많다. 상태를 바꾸는 요청은 다르다. 서버가 처리를 끝냈지만 응답이 사라졌다면, 같은 명령을 한 번 더 보내는 것이 중복 실행을 만들 수 있다.

AWS의 멱등 API 설명은 이런 상황에서 재시도를 안전하게 만드는 설계를 다룬다. 에이전트에서도 동일한 업무 의도를 식별하는 키, 처리 상태의 조회, 중복 실행 방지 같은 장치가 필요할 수 있다. 모델에 “실패하면 다시 시도하라”고 쓰는 것만으로 시스템의 부작용이 사라지지는 않는다.

가상의 고객지원 업무를 예로 들면 다음 상태들을 구분할 수 있다.

요청 접수 → 자료 조회 → 변경안 작성 → 권한·조건 확인
                                  ↓
                            변경 실행 → 결과 조회 → 완료
                                  ↓
                         결과 불명 → 상태 확인 → 재시도 판단

여기서 실행 도구가 200을 반환했다는 사실과 고객이 요청한 최종 상태가 맞다는 사실은 다를 수 있다. 응답이 비동기 접수 확인인지 완료 확인인지도 구별해야 한다. 완료의 정의가 없으면 재시도 횟수가 많아진 것을 개선으로 착각하기 쉽다.

이 예시는 특정 서비스에서 관측한 사고가 아니라 설계 상황을 설명한 것이다. 금전·계정·외부 전송처럼 되돌리기 어려운 작업에서는 오류의 크기까지 반영해 권한과 확인 절차를 정해야 한다.

공급자가 운영을 제품 안으로 가져오는 두 사례

이 분석은 실제 제품 구조와 어디서 만날까. 2026년 4월 공개된 Anthropic의 Managed Agents 설계 설명은 세션 로그, 에이전트의 실행 루프, 코드를 실행하는 샌드박스를 분리한다. 로그를 실행 루프 밖에 두어 루프가 중단돼도 기록을 바탕으로 다시 시작할 수 있게 하는 구조다. 이는 모델 호출을 감싸는 코드만이 아니라 상태 보관과 장애 경계를 서비스의 일부로 제공하는 사례다.

GitHub의 Copilot Agents 공식 문서는 cloud agent가 임시 개발 환경에서 코드를 고치고 테스트를 실행하며 브랜치와 PR을 만드는 흐름을 설명한다. 산출물은 기존 저장소의 검토 과정으로 들어가며, 생성된 코드를 검토·검증할 책임은 사용자에게 남는다고 명시한다. 여기서는 개발 환경과 협업 경로가 에이전트의 작업을 제품 경험으로 연결한다.

두 제품은 목적과 제공 범위가 달라 일대일 성능 비교 대상이 아니다. 문서에 나온 설계를 놓고 보면 아래처럼 서로 다른 경계가 드러난다.

관찰한 구조	제공자가 제품에 포함한 부분	도입 조직이 여전히 정할 부분
Managed Agents의 구성 요소 분리	작업 기록과 실행 환경·루프의 연결 및 복구 기반	업무의 성공 조건, 도구 권한, 외부 시스템 변경의 타당성
Copilot cloud agent의 PR 흐름	임시 작업 환경과 저장소 변경·검토 경로	요구사항 충족, 테스트의 충분성, 병합·배포 판단

오른쪽 열은 공개 구조를 바탕으로 한 이 글의 분석이다. 범용 실행 환경과 복구 기능을 공급자가 제공할수록, 외부 제품이 그 기능만으로 차별화하기는 어려워질 수 있다. 그때 남는 질문은 어떤 업무를 이해하고 어떤 결과를 책임지는가다. 다만 두 사례만으로 전체 시장의 방향이나 특정 기업의 우위를 확정할 수는 없다. 이 글에서는 해당 제품을 직접 실행해 성능이나 비용을 비교하지 않았다.

토큰 단가에서 검증된 완료 비용으로

호출 한 번의 비용이 낮아도 여러 번 실패하거나 사람이 오랫동안 수정해야 하면 업무 전체 비용은 커질 수 있다. 비교 단위를 바꾸면 제품 선택의 기준도 달라진다.

검증된 완료 1건당 비용
= (모델 + 도구·인프라 + 재시도 + 사람 검토·복구 비용)
  ÷ 정해진 품질 기준을 통과한 완료 건수

이 식은 비용을 생각하기 위한 분석 틀이다. 사람의 시간은 같은 단가로 환산하고, 모델·인프라 항목 사이에 중복 계산이 없는지 확인해야 한다. 완료 건수가 0이면 비용 비율을 계산하지 않고 실패 상태로 기록한다. 큰 사고의 예상 손실을 단순 평균으로 가리는 용도로 써서도 안 된다.

다음은 요청 100건을 처리한다고 가정한 예시다. 실제 제품의 비용이나 성능이 아니다.

가상 구성	총 처리 비용	검증된 완료	완료 1건당 비용
A	10,000 비용 단위	80건	125 비용 단위
B	7,000 비용 단위	50건	140 비용 단위

B의 총비용은 적지만 이 가정에서는 통과한 완료 한 건을 얻는 비용이 더 크다. 반대로 A가 완료하지 못한 20건에 중대한 손실이 몰려 있다면 125라는 숫자만으로 A를 선택해서는 안 된다. 성공 정의, 작업 난도 구성, 실패의 영향, 응답 시간 요구가 같아야 비교가 의미를 갖는다.

제품의 가격표는 이런 비교의 일부다. 도입 전에는 대표 업무의 정답과 완료 조건, 포기 조건, 사람에게 넘기는 조건을 먼저 정하고 비용을 기록하는 편이 유용하다.

무엇이 오래 남는 강점이 될 수 있을까

특정 모델을 먼저 연결했다는 사실은 시간이 지나면 다른 업체도 따라갈 수 있다. 반면 업무 과정에서 반복해서 생기는 예외를 정리하고, 승인된 데이터와 연결하며, 실패 후 복구하는 운영 지식은 축적 비용이 든다. 이 지식이 고객의 완료 비용을 꾸준히 줄인다면 재사용 이유가 될 수 있다.

그러나 데이터가 많다는 것만으로 우위가 생기지는 않는다. 사용할 권리가 있고, 품질이 유지되며, 실제 제품 개선에 연결돼야 한다. 고객이 데이터를 옮기기 어렵다는 사실과 제품이 더 좋은 결과를 낸다는 사실도 구분해야 한다.

이 가설에 대한 반대 시나리오도 있다. 업무 플랫폼이 기본 기능으로 에이전트를 제공하고 기존 권한·기록을 직접 활용하면 외부 제품의 연결 비용 이점이 줄어들 수 있다. 도구 인터페이스가 표준화되면 연결 개발 자체의 희소성도 약해질 수 있다. 반대로 여러 플랫폼을 가로지르는 업무에서는 중립적인 조합과 일관된 완료 관리가 가치가 될 수 있다. 어느 쪽이 우세한지는 실제 고객의 작업 구조를 봐야 한다.

따라서 “데이터가 많다”, “모델이 좋다”, “연결이 많다”를 각각 경쟁력의 결론으로 삼기보다, 그것이 어떤 업무의 어느 실패를 줄였는지 추적하는 편이 낫다. 이 글의 전망은 그 관계가 관측될 때 지지되는 조건부 분석이다.

제품과 도입안을 읽을 때 남길 질문

에이전트의 가치를 평가하려면 시연에서 멈추지 않고 업무의 시작과 끝을 정해야 한다. 다음 질문은 제품을 만드는 쪽과 도입하는 쪽에 모두 적용할 수 있다.

• 어떤 부분의 경로가 고정돼 있고, 어떤 결정이 모델에 맡겨져 있는가.
• 실제로 읽고 바꾸는 데이터와 권한의 범위는 어디까지인가.
• 결과를 별도로 확인하는가, 아니면 실행 응답을 완료로 세는가.
• 실패·중복·시간 초과 때 어느 상태에서 다시 시작하는가.
• 사람의 개입과 복구 시간을 포함해 완료 비용이 줄었는가.
• 모델·플랫폼이 바뀌어도 남는 이점은 무엇이며, 어떤 변화가 그 이점을 없앨 수 있는가.

모델 발전은 계속 중요하다. 그 능력을 고객의 완료된 업무로 연결하는 과정까지 함께 봐야 제품의 구조와 경제성을 읽을 수 있다. 향후 갱신에서는 공개된 실제 업무 평가와 비용 자료를 확보할 때 이 분석 틀에 대입하며, 현재 예시를 실측 결과로 바꾸어 표현하지 않는다.