---
title: "알테릭스, 멀티클라우드·온프레미스까지 묶는 에이전틱 AI 운영 체계 공개"
published: 2026-05-25T20:30:04.763Z
canonical: https://jeff.news/article/3221
---
# 알테릭스, 멀티클라우드·온프레미스까지 묶는 에이전틱 AI 운영 체계 공개

알테릭스가 알테릭스 원을 중심으로 데이터, 분석 워크플로, 비즈니스 로직, AI 에이전트를 한 플랫폼에서 연결하는 운영 체계를 공개했음. 핵심은 모델 성능 자랑이 아니라 승인, 감사 추적, 데이터 접근 정책, 하이브리드 실행 위치까지 기업 운영에 필요한 통제 장치를 AI 실행 과정에 붙이는 것임.

## AI 운영의 초점이 ‘모델’에서 ‘운영 통제’로 넘어가는 중

- 알테릭스가 공개한 알테릭스 원 확장은 한마디로 기업용 AI 에이전트를 그냥 챗봇처럼 두지 않겠다는 얘기임
  - 데이터, 분석 워크플로, 비즈니스 로직, AI 실행을 한 플랫폼에서 묶겠다는 전략임
  - AI가 뭔가를 ‘답변’하는 수준을 넘어 실제 업무 실행과 데이터 처리에 들어가면 승인, 접근 권한, 감사 추적이 같이 따라와야 함

- 기사에서 계속 반복되는 키워드는 반복 가능성, 운영 일관성, 감사 추적성임
  - 프롬프트마다 비즈니스 규칙이 흩어지면 누가 뭘 바꿨는지 추적하기 어려움
  - 같은 질문을 슬랙에서 하든 팀즈에서 하든, 뒤에서 쓰는 업무 로직이 달라지면 기업 입장에서는 사고 포인트가 됨
  - 알테릭스는 이 문제를 기존에 검증된 분석 워크플로를 AI 실행 기반으로 재사용하는 방식으로 풀겠다고 함

- IDC 전망도 꽤 현실적임. 향후 3년 동안 AI 워크플로 책임이 중앙 조직에서 현업 부서로 약 11% 이동할 것으로 봄
  - 즉, AI 운영이 일부 데이터팀이나 중앙 AI 조직의 전유물이 아니라 현업으로 퍼진다는 뜻임
  - 그러면 현업 담당자가 직접 쓸 수 있으면서도, 중앙에서 정책과 감사 기준을 걸 수 있는 플랫폼이 필요해짐

## 알테릭스 원이 붙이려는 조각들

- 에이전트 스튜디오는 신뢰된 데이터셋과 비즈니스 로직을 재사용 가능한 AI 에이전트로 패키징함
  - 반복되는 데이터 처리와 의사결정 절차를 자동화 워크플로로 만들 수 있음
  - 벤 캐닝 알테릭스 최고제품책임자는 AI 품질이 아래에 있는 비즈니스 로직 수준에 달려 있다고 말함
  - 이건 모델을 바꾸기 전에 업무 규칙을 어디에 둘지부터 정해야 한다는 얘기와 가까움

- 알테릭스 원 MCP 서버는 이 에이전트를 실제 업무 도구와 연결함
  - 연결 대상은 슬랙, 마이크로소프트 팀즈, 오픈AI, 클로드 같은 환경임
  - 중요한 건 인터페이스가 여러 개여도 동일한 비즈니스 로직을 공통으로 쓴다는 점임
  - 사용자는 각 도구에서 AI를 쓰지만, 조직은 뒤쪽 규칙과 실행 흐름을 통제할 수 있음

```mermaid
sequenceDiagram
    participant 현업사용자
    participant 슬랙·팀즈
    participant MCP서버
    participant 알테릭스워크플로
    participant 데이터플랫폼

    현업사용자->>슬랙·팀즈: 자연어로 분석·업무 실행 요청
    슬랙·팀즈->>MCP서버: 에이전트 호출
    MCP서버->>알테릭스워크플로: 검증된 비즈니스 로직 실행
    알테릭스워크플로->>데이터플랫폼: 정책에 맞춰 데이터 조회
    데이터플랫폼-->>알테릭스워크플로: 결과 반환
    알테릭스워크플로-->>MCP서버: 감사 가능한 실행 결과 전달
    MCP서버-->>슬랙·팀즈: 사용자에게 응답
```

- 거버넌스 기능도 꽤 구체적으로 제시됨
  - 워크플로 자동 버전 관리, 소유권 지정, 인증 메타데이터, 승인 프로세스가 포함됨
  - 데이터 라벨과 자산 인증 기능으로 민감 데이터를 식별하고 정책을 적용함
  - 중앙집중형 연결 관리는 서버, 디자이너, 워크스페이스 전반의 인증정보와 데이터 접근을 통합 관리함

> [!IMPORTANT]
> 알테릭스 고객들은 지난해 3억8000만 개 이상의 워크플로를 실행했다고 함. 이 규모에서는 AI 결과가 맞냐 틀리냐보다, 누가 어떤 로직으로 어떤 데이터를 건드렸는지 남기는 게 운영의 핵심이 됨.

## 멀티클라우드·온프레미스까지 봐야 하는 이유

- 기업 AI 운영은 생각보다 깔끔하게 클라우드 하나로 끝나지 않음
  - 금융, 제조, 공공, 헬스케어는 데이터 이동 제한과 감사 요건이 강함
  - 국내 대기업과 제조업도 멀티클라우드와 온프레미스 혼합 운영이 늘어나는 흐름임
  - 그래서 실행 위치를 고르는 기능이 단순 인프라 옵션이 아니라 규제 대응 수단이 됨

- 데이터 브리지는 온프레미스와 프라이빗 네트워크 데이터를 이동 없이 클라우드 워크플로와 연결함
  - 데이터 위치는 유지하면서 분석과 AI 실행만 연결하는 방식임
  - 빅쿼리, 데이터브릭스, 스노우플레이크 같은 데이터 플랫폼도 라이브 쿼리와 엔터프라이즈 커넥터로 직접 활용한다고 함
  - 빅쿼리 네이티브 AI 기능과 연계해 비정형 데이터 처리도 한다고 밝힘

- 향후 제공될 서버 실행 기능은 관리와 실행 위치를 분리하는 방향임
  - 클라우드에서 워크플로를 관리하되 실제 실행은 온프레미스 서버에서 유지할 수 있음
  - 승인 절차, 종속성 검증, 테스트 체크포인트, 버전 기반 배포 관리가 포함된 SDLC 패키지도 예고됨
  - 결국 AI 운영을 소프트웨어 배포처럼 다루겠다는 쪽에 가까움

> [!TIP]
> 기업에서 에이전틱 AI를 붙일 때는 “어느 모델을 쓸까”보다 “업무 로직, 승인, 데이터 접근, 실행 기록을 어디에 남길까”를 먼저 정해야 함. 이걸 안 잡으면 PoC는 빨라도 운영 전환에서 바로 막힘.

- 국내 기업에도 꽤 직접적인 시사점이 있음
  - 생성AI 기반 업무 자동화와 데이터 분석 프로젝트가 늘수록, 현업이 직접 AI 워크플로를 만지는 상황이 많아짐
  - 금융과 공공은 데이터 이동 제한과 내부 감사 요건 때문에 실행 기록과 승인 관리가 특히 중요함
  - 제조업도 현장 데이터와 클라우드 분석을 같이 써야 하는 경우가 많아서 하이브리드 실행 구조가 현실적인 선택지가 됨

---

## 기술 맥락

- 알테릭스가 고른 방향은 모델을 직접 앞세우는 게 아니라, 이미 기업 안에서 검증된 워크플로를 AI 실행 계층으로 올리는 방식이에요. 왜냐면 기업 업무에서는 답이 그럴듯한 것보다, 같은 조건에서 같은 규칙으로 다시 실행되는지가 더 중요하거든요.

- MCP 서버가 중요한 이유는 AI 인터페이스가 계속 늘어나기 때문이에요. 슬랙, 팀즈, 오픈AI, 클로드처럼 입구가 여러 개가 되면 각각에 비즈니스 로직을 심는 순간 관리가 깨져요. 공통 서버를 두면 로직과 감사 추적을 한곳에서 잡을 수 있어요.

- 데이터 브리지는 클라우드 전환이 어려운 조직을 겨냥한 선택이에요. 금융이나 공공처럼 데이터를 마음대로 옮기기 어려운 곳에서는 데이터 위치를 유지한 채 워크플로만 연결해야 규제와 자동화를 같이 만족시킬 수 있어요.

- 버전 관리와 승인 프로세스가 붙는 것도 같은 맥락이에요. AI 에이전트가 실제 업무를 실행하면 결과만 저장해서는 부족하고, 어떤 버전의 워크플로와 어떤 데이터 권한으로 실행됐는지까지 남아야 나중에 설명할 수 있어요.

- 그래서 이 기사의 본질은 에이전틱 AI 신기능 발표라기보다, AI 운영을 기존 엔터프라이즈 소프트웨어 운영 방식 안으로 끌어들이는 이야기예요. 현업이 더 많이 쓰게 만들되, 중앙 조직이 통제와 감사를 놓치지 않게 하려는 균형점이라고 보면 돼요.

## 핵심 포인트

- 알테릭스 원은 검증된 데이터·분석 워크플로를 AI 에이전트 실행 기반으로 재사용함
- 에이전트 스튜디오와 MCP 서버를 통해 슬랙, 팀즈, 오픈AI, 클로드 환경에 동일한 비즈니스 로직을 연결함
- 고객들은 지난해 3억8000만 개 이상의 워크플로를 실행했고, 대규모 운영에서 버전 관리와 감사 추적이 핵심 과제로 제시됨
- 데이터 브리지는 온프레미스와 프라이빗 네트워크 데이터를 이동 없이 클라우드 워크플로와 연결함
- 금융, 제조, 공공, 헬스케어처럼 데이터 통제와 감사 요건이 강한 산업에서 특히 의미가 큼

## 인사이트

기업용 AI의 다음 싸움은 ‘어떤 모델이 더 똑똑한가’보다 ‘누가 실행 권한과 감사 추적을 제대로 묶는가’에 가까워지고 있음. 국내 기업도 생성AI PoC에서 운영 단계로 넘어가면 결국 이런 워크플로 거버넌스 문제를 피하기 어려움.
