업무시간 밖 티켓 47%, Freshworks가 노린 에이전트 야간 근무

AI 요약

• 무슨 일: Freshworks가 Freshservice용 Freddy AI Agent Studio, MCP Gateway, AI Insights와 xLA를 공개했습니다.
  • 발표일은 2026년 5월 14일이며, 무대는 Freshworks의 연례 Refresh 컨퍼런스였습니다.
• 핵심 숫자: Freshworks는 IT 티켓의 47%가 표준 업무 시간 밖에 제출된다고 설명했습니다.
  • 이 숫자는 AI 에이전트가 단순 FAQ가 아니라 비동기 서비스 운영 계층으로 이동하는 근거로 쓰였습니다.
• 의미: ITSM은 이제 티켓 저장소가 아니라 에이전트가 권한, 맥락, 실행, 측정을 통과하는 런타임이 되고 있습니다.
• 주의점: 성공 기준은 "자동 응답 수"가 아니라 실패한 자동화가 사람에게 남기는 업무량까지 포함해야 합니다.

Freshworks가 2026년 5월 14일 Refresh 컨퍼런스에서 Freshservice용 Freddy AI Agent Studio를 확장했습니다. 표면적으로는 IT 서비스 관리 도구에 노코드 AI 에이전트 빌더가 붙은 발표처럼 보입니다. 하지만 이번 발표를 그렇게만 읽으면 중요한 변화가 빠집니다. Freshworks가 노리는 것은 챗봇 UI가 아니라 ServiceOps 자체를 AI 에이전트의 실행 계층으로 만드는 것입니다.

Freshworks의 공식 보도자료는 이 변화를 직원 서비스 운영의 문제에서 출발합니다. 회사는 자체 서비스 상호작용 분석을 근거로, IT 티켓의 47%가 표준 업무 시간 밖에 제출된다고 밝혔습니다. 업무는 더 비동기적으로 흩어졌고, 직원은 Slack, Teams, 포털, 이메일을 오가며 지원을 요청합니다. 그런데 기존 ITSM 운영은 여전히 사람이 근무 시간에 큐를 보고, 분류하고, 권한을 확인하고, 관련 시스템을 열어 처리하는 방식에 가깝습니다. 이 간극이 Freshworks가 말하는 "ghost shift"입니다.

이 숫자가 흥미로운 이유는 AI 에이전트의 실전 사용처를 꽤 정확히 보여주기 때문입니다. 많은 기업용 AI 발표는 "직원이 질문하면 답한다"에서 멈춥니다. 그러나 야간에 들어온 계정 권한 요청, 온보딩 체크리스트, 급여 정보 변경, 노트북 교체, 장애 알림 같은 업무는 답변만으로 끝나지 않습니다. 어떤 시스템에 접근할 수 있는지, 어떤 권한으로 행동해야 하는지, 결과를 어디에 기록해야 하는지, 실패하면 누구에게 넘겨야 하는지가 더 중요합니다. Freshworks는 이 지점을 AI Agent Studio, MCP Gateway, AI Insights, xLA라는 네 조각으로 묶었습니다.

노코드 에이전트 빌더보다 중요한 것

Freddy AI Agent Studio의 첫 번째 기능은 익숙합니다. 팀은 노코드 스튜디오에서 커스텀 AI Agent를 만들거나, 사전 구축된 도메인별 에이전트에서 시작할 수 있습니다. Freshworks는 이 에이전트가 Microsoft Teams, Slack, 직원 포털에서 요청을 받고, Workday나 Rippling 같은 HRIS와 연결해 온보딩이나 급여 같은 보안 워크플로를 처리할 수 있다고 설명합니다.

여기까지는 ServiceNow, Atlassian, Microsoft Copilot Studio, Salesforce Agentforce가 모두 말하는 방향과 크게 다르지 않습니다. "현업이 에이전트를 직접 만들 수 있다"는 메시지는 이미 시장의 기본 문법이 됐습니다. 따라서 Freshworks 발표의 진짜 관전 지점은 빌더 자체가 아니라, 그 빌더가 어디에 붙어 있는가입니다.

Freshservice는 티켓, 자산, 인시던트, 서비스 카탈로그, 지식 베이스, 승인 흐름을 이미 갖고 있는 ITSM/ESM 플랫폼입니다. 이 데이터는 기업 안에서 가장 정돈된 업무 요청 기록에 가깝습니다. 누가 어떤 서비스를 요청했는지, 어떤 자산과 연결되는지, 어느 부서가 승인해야 하는지, 과거에 어떻게 해결했는지가 축적됩니다. AI 에이전트가 기업 안에서 실제로 행동하려면 바로 이런 맥락이 필요합니다.

그래서 Freshworks의 메시지는 "AI가 Freshservice에 추가됐다"보다 "Freshservice가 AI 에이전트의 업무 상태 저장소가 된다"에 가깝습니다. 직원 요청은 티켓으로 들어오고, 에이전트는 정책과 데이터를 읽고, 외부 시스템을 호출하고, 결과를 다시 서비스 기록과 지표로 남깁니다. 단일 채팅창에서 끝나는 AI가 아니라, 업무 운영 시스템 안에 남는 AI입니다.

MCP Gateway는 왜 들어갔나

이번 발표에서 가장 개발자적인 조각은 MCP Gateway입니다. Freshworks는 Freddy AI가 Notion, ClickUp, Linear 같은 외부 도구에서 맥락을 가져올 수 있다고 설명했습니다. Freshservice 지원 문서에서는 Freshworks MCP 서버가 Cursor, Claude, Microsoft Copilot Studio 같은 AI 도구와 Freshservice를 안전하게 연결하는 방향도 안내합니다.

MCP는 이제 에이전트 도구 연결의 사실상 표준 후보가 됐습니다. 하지만 기업 환경에서 MCP를 그대로 열어두는 것은 위험합니다. 에이전트가 어떤 도구를 호출했는지, 어떤 계정 권한을 썼는지, 어떤 데이터에 접근했는지, 실패했을 때 누가 승인하거나 차단했는지를 관리해야 합니다. 이 때문에 최근 기업용 AI 발표에는 "gateway"라는 단어가 자주 등장합니다. 모델이 똑똑해지는 것만으로는 충분하지 않고, 도구 호출을 통제하는 중간 계층이 필요하기 때문입니다.

Freshworks의 MCP Gateway도 그 흐름에 있습니다. Notion에 정책 문서가 있고, Linear에 엔지니어링 이슈가 있고, ClickUp에 업무 계획이 있으며, Freshservice에 직원 요청이 있다면 에이전트는 이 조각들을 함께 읽어야 합니다. 예를 들어 신규 입사자의 접근 권한 요청이 들어왔을 때, 에이전트는 HRIS에서 고용 상태를 확인하고, Freshservice 자산 정보를 보고, Notion의 보안 정책을 읽고, Linear의 프로젝트 배정 정보를 참고한 뒤, 필요한 승인 흐름을 시작할 수 있습니다. 이때 핵심은 "연결"이 아니라 "통제된 연결"입니다.

이 지점에서 Freshworks는 UiPath나 Red Hat이 같은 주에 말한 것과 비슷한 문제를 다른 영역에서 풀고 있습니다. UiPath는 코딩 에이전트를 기업 자동화 플랫폼에 얹어 배포와 감사를 강조했고, Red Hat은 로컬 에이전트 샌드박스와 하이브리드 클라우드 개발 도구를 내세웠습니다. Freshworks는 ITSM/ESM을 그 실행 계층으로 삼습니다. 서로 다른 시장처럼 보이지만 모두 같은 질문을 다룹니다. 에이전트가 실제 시스템을 만질 때, 실행 권한은 어디에서 관리되는가?

SLA에서 xLA로, 지표도 바뀐다

Freshworks가 함께 꺼낸 AI Insights와 xLA도 중요합니다. 기존 ITSM은 SLA(Service Level Agreement)에 익숙합니다. 응답 시간, 해결 시간, 위반률 같은 지표입니다. Freshworks는 여기에 xLA, 즉 Experience Level Agreement를 붙여 서비스 성능과 직원 경험을 연결하려 합니다.

이 변화는 AI 에이전트 시대에 더 중요해집니다. 자동화가 늘면 표면 지표는 좋아질 수 있습니다. 첫 응답 시간은 거의 0초가 될 수 있고, 티켓 분류도 빠르게 끝날 수 있습니다. 그런데 사용자가 실제로 문제를 해결했는지, 봇이 엉뚱한 질문을 반복해 사람에게 더 긴 로그를 남겼는지, 담당자가 실패한 자동화의 맥락을 다시 해석하느라 시간을 잃었는지는 SLA만으로 잘 보이지 않습니다.

Freshservice 커뮤니티에서도 이 문제는 이미 보입니다. 한 사용자는 Freddy AI를 붙인 뒤 tier-1 MTTR이 줄지 않고 오히려 늘었다고 토론을 열었습니다. 봇이 시도하고 실패한 뒤 사람이 이어받으면, 담당자는 전체 대화 맥락을 다시 읽어야 합니다. 자동화가 "시도"된 것은 맞지만, 사람의 업무량은 줄지 않을 수 있습니다. 이것은 AI 에이전트 운영에서 반복될 문제입니다.

따라서 xLA는 마케팅 용어로만 볼 수 없습니다. AI 에이전트 도입의 성패는 "몇 건을 자동 응답했나"보다 "사람이 실제로 덜 기다렸나", "재작업이 줄었나", "권한 있는 담당자에게 더 정확히 넘어갔나", "실패한 자동화가 다음 시도에 반영됐나"에 달려 있습니다. Freshworks가 AI Insights를 함께 강조한 것은 이 때문입니다. 에이전트가 일을 한다면, 에이전트의 일도 운영 지표의 대상이 되어야 합니다.

Freshworks의 포지션: ServiceNow를 정면으로 겨냥

Freshworks는 발표에서 legacy platform과 data cleanup을 여러 번 겨냥했습니다. 회사의 논리는 단순합니다. 여러 도구를 억지로 붙인 복잡한 ITSM에서는 AI 에이전트가 충분한 맥락을 갖기 어렵고, Freshservice의 통합 데이터 레이어는 서비스, 자산, 지식, 인시던트를 한곳에서 제공한다는 것입니다.

이 주장은 ServiceNow와 Atlassian을 직접 겨냥합니다. ServiceNow는 대기업 ITSM의 강자이고, Now Assist와 AI Agent Studio를 통해 비슷한 방향으로 가고 있습니다. Atlassian은 Jira Service Management와 Rovo를 통해 개발·서비스·문서 데이터를 연결하려 합니다. Microsoft는 Copilot Studio와 Teams를 통해 현업 자동화를 잡으려 하고, Glean은 엔터프라이즈 지식 검색에서 Agent Development Lifecycle을 말합니다.

Freshworks의 차별점은 가격과 단순성, 그리고 중견기업까지 내려오는 배포 속도입니다. 공식 발표는 "weeks, not quarters"라는 표현을 사용합니다. 즉 대형 SI 프로젝트처럼 몇 분기 동안 데이터 정리를 하고 프로세스를 재설계한 뒤 AI를 붙이는 방식이 아니라, 기존 Freshservice 데이터 위에서 빠르게 도메인 에이전트를 만들겠다는 약속입니다.

하지만 이 약속은 양날의 검입니다. 빠른 도입이 가능하려면 기본 데이터 품질과 권한 모델이 충분히 정리돼 있어야 합니다. 티켓 카테고리가 엉망이거나, 자산 관리가 최신이 아니거나, HRIS와 ITSM의 책임 경계가 불명확하면 에이전트는 더 빠르게 잘못 행동할 수 있습니다. MCP Gateway가 외부 도구를 연결할수록 이 문제는 커집니다. 연결이 늘면 맥락은 풍부해지지만, 잘못된 맥락과 과도한 권한도 함께 들어옵니다.

개발자와 AI 팀에게 주는 신호

이 뉴스는 IT 운영팀만의 이야기가 아닙니다. AI 제품을 만드는 팀에게도 중요한 신호가 있습니다. 첫째, 에이전트 제품의 경쟁력은 모델 선택보다 업무 시스템에 얼마나 깊이 들어가 있는가로 이동하고 있습니다. Freshworks는 자체 모델을 전면에 내세우지 않습니다. 대신 Freshservice의 데이터와 MCP Gateway, Slack·Teams 표면, HRIS 연결, 인시던트 관리, 지표 계층을 말합니다. 이것이 기업 고객에게는 더 직접적인 가치일 수 있습니다.

둘째, MCP는 "개발자 편의 프로토콜"을 넘어 기업 거버넌스 문제가 되고 있습니다. 로컬 개발자 도구에서 MCP 서버를 붙이는 것과, 직원 서비스 에이전트가 MCP Gateway를 통해 회사 데이터를 읽고 행동하는 것은 위험 수준이 다릅니다. 앞으로 AI 플랫폼 팀은 MCP 서버 목록을 관리하는 정도가 아니라, 도구별 권한, 호출 로그, 승인 정책, 데이터 분류, 실패 시 롤백 방식을 설계해야 합니다.

셋째, 에이전트 도입의 평가 지표는 점점 운영 지표와 합쳐질 것입니다. 코딩 에이전트는 테스트 통과율, PR 머지율, 리뷰 수정 횟수로 평가받고, 서비스 에이전트는 MTTR, 재오픈율, 직원 만족도, SLA/xLA, 사람 개입률로 평가받습니다. "AI가 답했다"는 지표는 너무 약합니다. AI가 실제로 업무 루프를 닫았는지가 더 중요합니다.

남은 질문

Freshworks 발표에서 아직 열려 있는 질문도 많습니다. MCP Gateway의 권한 모델이 얼마나 세밀한지, 에이전트가 외부 도구에서 읽은 데이터를 Freshservice 안에 어떻게 기록하는지, 실패한 액션의 감사 로그와 재현성이 어느 수준인지, 고객이 어떤 LLM을 선택하거나 제한할 수 있는지 등은 실제 도입 단계에서 확인해야 합니다.

또 하나는 인간 승인 흐름입니다. 급여, 접근 권한, 장비 지급, 인시던트 대응은 모두 민감한 업무입니다. 에이전트가 초안을 만들고 사람이 승인하는 수준인지, 특정 저위험 작업은 자동 실행하는지, 위험도에 따라 승인 정책을 다르게 설정할 수 있는지가 중요합니다. 발표문은 "secure enterprise workflows"와 "controlled orchestration"을 말하지만, 구체적인 제어 수준은 제품 문서와 실제 배포 사례를 더 봐야 합니다.

마지막으로, Freshworks가 말한 47%의 after-hours 티켓은 강력한 문제 정의이지만, AI 에이전트가 그 문제를 얼마나 해결하는지는 별개의 문제입니다. 야간 요청이 많다는 사실은 자동화 수요를 보여주지만, 모든 야간 티켓이 자동 처리에 적합하다는 뜻은 아닙니다. 어떤 티켓은 정책 확인만 필요하고, 어떤 티켓은 보안 예외이며, 어떤 티켓은 사람의 판단을 요구합니다. 좋은 에이전트 플랫폼은 이 차이를 구분해야 합니다.

Freshworks의 이번 발표는 AI 에이전트가 기업 안에서 어디에 자리 잡을지 보여주는 또 하나의 사례입니다. 모델은 점점 더 강력해지고 있지만, 실제 업무는 모델 바깥의 시스템에서 끝납니다. 티켓, 자산, 인시던트, HRIS, 협업 채널, 승인 정책, 지표가 모두 연결될 때 에이전트는 비로소 "답변자"가 아니라 "운영자"가 됩니다.

그래서 Freshworks AI Agent Studio의 의미는 Freshservice에 새 기능이 붙었다는 데 있지 않습니다. ITSM이 AI 에이전트의 야간 근무지를 자처하기 시작했다는 데 있습니다. 이제 경쟁은 누가 더 똑똑한 봇을 만들었는가가 아니라, 누가 더 안전하고 측정 가능한 업무 실행 루프를 제공하는가로 옮겨가고 있습니다.