--- title: "AX 데모의 함정, 텔레그램 봇을 에이전트 혁명으로 착각하면 생기는 일" published: 2026-05-26T08:05:03.415Z canonical: https://jeff.news/article/3265 --- # AX 데모의 함정, 텔레그램 봇을 에이전트 혁명으로 착각하면 생기는 일 국내 대기업 AX 강연에서 텔레그램 봇 기반 업무 보조 도구가 에이전트처럼 소개됐지만, 실제로는 외부 모델 API와 오픈소스 스킬을 묶은 반복 호출 구조에 가깝다는 비판이 나왔다. 기사는 기업 AX의 핵심이 화려한 연결이 아니라 실제 업무 절감, 토큰 비용, 데이터 이동, 벤더 종속, 절단 가능성을 검증하는 데 있다고 짚는다. ## 텔레그램 봇을 에이전트라고 부르면 생기는 착시 - 국내 대기업 AX 강연에서 텔레그램 기반 업무 보조 도구가 “에이전트 시스템”처럼 소개됐다는 분석이 나옴 - 메일, 캘린더, 사내 업무 데이터를 연결함 - 일정 충돌을 보고, 메일을 요약하고, 누락된 컨텍스트를 표시하고, 회의 후 할 일을 정리하는 식임 - 겉으로 보면 꽤 그럴듯하고, 실제로 유용할 수 있는 기능들임 - 문제는 이런 자동화 묶음이 “스스로 판단하는 에이전트”처럼 포장될 때임 - 실제 구조는 외부 모델 API와 오픈소스 스킬을 연결한 반복 호출 시스템에 가깝다는 지적임 - 메신저 UI 위에서 모델이 메일을 읽고, 컨텍스트를 붙이고, 이전 브리프를 다시 읽고, 누락 여부를 재검사함 - 사용자는 텔레그램 창에서 짧은 브리프만 보지만 뒤에서는 호출과 재처리가 계속 돈다는 얘기임 > [!WARNING] > 워크플로를 많이 연결했다고 지능이 생기는 건 아님. 메일, 캘린더, ERP, 메신저, 외부 API가 긴 호출 체인으로 엮이면 생산성보다 비용과 장애 전파 범위가 먼저 커질 수 있음. - 기사에서 계속 강조하는 포인트는 “연결”과 “지능”은 다르다는 것임 - 컨텍스트를 길게 이어붙이고 툴을 여러 개 연결해도 새로운 의미 구조가 생기는 건 아님 - 상당수 에이전틱 워크플로는 기존 업무 흐름 위에 토큰 반복 루프를 덧씌운 구조에 가깝다고 봄 - 그래서 화려한 데모가 실제 운영 효율을 보장하지 않음 ## 토큰 비용과 데이터 이동량은 조용히 커짐 - 기업 단위로 확산되면 비용 문제가 더 커짐 - 메일 하나, 일정 하나, 회의록 하나는 가벼워 보임 - 하지만 에이전트 구조에서는 각 단계마다 모델 호출이 발생함 - 이전 브리프 비교, 누락 탐지, 재요약, 우선순위 정렬, 알림 생성이 반복되면 토큰 비용과 데이터 이동량이 누적됨 - 기능이 늘어날수록 사용자는 편해질 수 있지만 회사 입장에서는 다른 장부가 생김 - API 비용 - 외부 모델 의존 - 데이터 이동 경로 증가 - 벤더 종속 구조 - 보안 검토 범위 확대 - 기사에서는 기업 AX 전략에서 먼저 봐야 할 체크리스트를 꽤 현실적으로 제시함 - 어떤 기능이 실제로 사람 업무를 줄이는가 - 어떤 호출이 반복되는가 - 데이터가 어디를 거쳐 이동하는가 - 컨텍스트 길이가 얼마나 커지는가 - 장기 운영비가 어떻게 누적되는가 ## “절단 가능성”이 AX 설계의 핵심으로 등장함 - 기사에서 대비 사례로 나온 건 셀트리온식 접근임 - 메신저 UI 위에 외부 모델 API와 반복 호출 루프를 길게 얹는 대신, 신약 개발, 제조, 사무 영역별로 자동화 효과가 검증되는 구조부터 적용한다는 설명임 - 전자문서관리시스템(EDMS) 챗봇은 문서 검색과 비교 같은 반복 업무를 줄이는 데 집중함 - 제조 부문은 자율이송로봇(AMR), 자동화 물류, 협동로봇 같은 물리적 자동화와 연결됨 - 여기서 핵심 키워드는 절단 가능성임 - 특정 자동화 기능의 비용 대비 효과가 낮으면 그 기능만 분리하거나 중단할 수 있어야 함 - 보안 문제가 생겨도 전체 시스템을 멈추지 않고 문제 구간을 잘라낼 수 있어야 함 - 반대로 과하게 연결된 에이전트 체인은 장애와 비용이 연쇄적으로 번질 가능성이 큼 - 삼성전자, MS, 토스 사례도 위험 신호로 언급됨 - 삼성전자는 외부 생성형 AI로 코드와 회의 자료가 유출되며 사내 사용 제한 조치를 검토한 바 있음 - MS 내부에서도 전체 프로젝트 컨텍스트를 외부 API로 보내는 코딩 에이전트 구조가 보안 리스크로 거론됐다고 함 - 토스처럼 전사 AI 실험 체계를 넓히는 경우에도 외부 LLM 기반 개발 지원과 내부 업무 흐름 연결이 커질수록 비용, 보안, 종속 리스크가 따라올 수 있음 ## 결국 AX는 덜 연결하는 능력 싸움일 수 있음 - 기사 후반부의 주장은 꽤 날카로움. 미래 AX 경쟁력은 얼마나 거대한 워크플로를 연결했느냐가 아니라, 얼마나 적은 호출로 실제 업무를 끝내느냐에 달렸다는 것임 - 장문 컨텍스트와 재시도 루프 기반 에이전트 연결은 토큰과 GPU를 계속 태움 - 작은 수정에도 전체 코드베이스를 다시 읽고, 테스트를 반복하고, 실패하면 재호출하는 구조가 될 수 있음 - 모델이 더 똑똑해지는 게 아니라 단순 반복 호출이 늘어나는 상황이 생김 - 대안으로 제시되는 건 사람이 연산 흐름을 절단하고 통제하는 사내 AI 조직화임 - 직원이 업무 목표에 맞게 필요한 로그와 문맥만 선별적으로 넣음 - 보고서 작성, 자료 조사, 문서 정리, 회의 요약, 코드 분석 같은 반복 업무를 압축해서 AI에 맡김 - 업무 유형별 시스템 프롬프트, 역할 분리, 컨텍스트 압축, 출력 형식 통제가 중요해짐 - 결론은 단순함. AX의 핵심은 화려한 데모가 아님 - 사람이 몸으로 때우던 반복 업무를 실제로 얼마나 줄였는지 - 그 과정에서 어떤 비용 구조가 새로 생겼는지 - 데이터가 어디로 나가는지 - API 연결을 통한 정보 유출 가능성은 없는지 따져야 함 --- ## 기술 맥락 - 이 기사에서 말하는 기술적 선택은 에이전트형 워크플로를 길게 연결할지, 기능 단위 자동화로 잘라서 운영할지예요. 둘 다 AI를 쓰지만 운영 결과는 꽤 달라져요. - 긴 에이전트 체인은 데모가 멋져 보이는 장점이 있어요. 메일을 읽고, 캘린더를 보고, 이전 회의록을 참고하고, 다시 알림을 보내면 마치 조직 운영이 자동화된 것처럼 보이거든요. 하지만 매 단계가 모델 호출이면 토큰 비용과 데이터 이동 경로도 같이 늘어나요. - 절단 가능한 구조는 덜 화려해 보여도 운영 통제에는 유리해요. 문서 검색, 일정 정리, 재고 확인처럼 업무 단위를 나누면 어떤 자동화가 돈값을 하는지 따로 측정할 수 있고, 문제가 생긴 기능만 끊어낼 수 있어요. - 기업에서 중요한 건 AI가 얼마나 자율적으로 보이느냐가 아니라, 반복 업무를 얼마나 적은 호출과 작은 컨텍스트로 끝내느냐예요. 이 차이를 못 보면 AX는 생산성 도구가 아니라 토큰 비용 증폭기가 될 수 있어요. ## 핵심 포인트 - 메일, 캘린더, 메신저, 외부 모델 API를 연결한다고 곧바로 자율형 에이전트가 되는 것은 아니다 - 에이전틱 워크플로는 컨텍스트 재주입과 반복 호출로 토큰 비용과 데이터 이동량을 키울 수 있다 - 기업 AX에서는 전체 연결보다 기능 단위로 성과와 비용을 검증하고 필요하면 끊어낼 수 있는 구조가 중요하다 ## 인사이트 기업 AI 도입에서 제일 위험한 착각은 ‘많이 연결하면 똑똑해진다’는 믿음이다. 실제 운영에서는 적은 호출로 반복 업무를 줄이는 구조가 더 강하고, 끊어낼 수 없는 에이전트 체인은 비용과 보안 리스크를 같이 키운다.