HCLTech·Anthropic 제휴, 기업용 Agentic AI 클라우드의 판을 바꿀까?

새벽 2시, 결제 서비스의 응답 시간이 급격히 느려졌다고 가정해 보겠습니다. 기존 방식이라면 당직자가 알림을 확인하고, 여러 대시보드와 로그를 오가며 원인을 찾은 뒤, 담당 개발자와 운영팀에 연락해야 합니다.

이제는 AI 에이전트가 이 과정의 상당 부분을 수행할 수 있습니다. 장애 티켓을 읽고, Cloud 모니터링 로그를 분석하며, 최근 배포 이력과 설정 변경 사항을 비교한 뒤, 가능한 원인과 수정안까지 정리할 수 있습니다.

문제는 그다음입니다. AI가 “수정안을 제안하는 것”과 “운영 환경을 직접 바꾸는 것” 사이에는 매우 큰 차이가 있습니다. 승인 없이 프로덕션 설정을 변경하거나, 잘못된 복구 스크립트를 실행한다면 생산성 혁신은 순식간에 보안 사고나 서비스 중단으로 이어질 수 있습니다.

AI 에이전트가 수행하는 Cloud 장애 대응 흐름

Agentic AI는 단순히 장애 원인을 설명하는 챗봇이 아닙니다. 기업 시스템에 연결된 에이전트는 목표를 해석하고, 필요한 도구를 호출하며, 여러 단계를 순서대로 수행합니다.

장애가 발생했을 때의 흐름은 대략 다음과 같습니다.

1. 장애 신호 감지
   모니터링 시스템의 경고, 사용자 문의, ITSM 티켓, 보안 이벤트를 수집합니다.

2. 상황 분석
   애플리케이션 로그, 인프라 메트릭, 네트워크 지표, 최근 코드 배포 기록, Cloud 설정 변경 이력을 함께 조회합니다.

3. 원인 후보 추론
   예를 들어 특정 API의 오류율 증가가 신규 배포 직후 시작됐는지, 데이터베이스 연결 수 급증과 관련이 있는지 분석합니다.

4. 대응안 생성
   롤백, 트래픽 우회, 캐시 확장, 설정 복구, 코드 수정안 등 가능한 조치를 제안합니다.

5. 검증 및 승인 요청
   샌드박스나 테스트 환경에서 수정안을 검증하고, 고영향 변경이라면 담당자에게 승인 요청을 보냅니다.

6. 제한적 실행과 결과 확인
   승인된 작업만 실행한 뒤, 오류율·응답 시간·서비스 상태가 정상화됐는지 다시 확인합니다.

이 과정에서 Claude, Claude Code 같은 모델은 로그를 이해하고 수정안을 작성하는 추론 엔진 역할을 합니다. 반면 실제 Cloud 운영에서 중요한 것은 모델의 답변 능력보다 어떤 도구를 호출할 수 있는지, 어떤 권한이 부여됐는지, 언제 실행을 멈춰야 하는지입니다.

“제안”과 “실행” 사이에 필요한 통제 장치

HCLTech와 Anthropic의 협력이 주목받는 이유도 여기에 있습니다. AI를 IT 지원, 코드 remediation, 보안, 자동화 업무에 연결하면서도 정책 기반 통제와 사람의 감독을 함께 설계하려 하기 때문입니다.

운영 환경에서 AI 에이전트가 안전하게 작동하려면 최소한 다음 장치가 필요합니다.

• Policy guardrails
  에이전트가 접근할 수 있는 시스템, 데이터, API 범위를 정책으로 제한합니다. 예를 들어 운영 데이터베이스 삭제나 보안 정책 변경은 기본적으로 금지할 수 있습니다.

• 권한 분리와 최소 권한 원칙
  AI 에이전트는 일반 사용자 계정이나 관리자 계정을 공유해서는 안 됩니다. 읽기 전용, 테스트 환경 실행, 운영 환경 변경 권한을 분리해야 합니다.

• Human oversight
  결제 로직, 고객 데이터, 생산 시스템 설정처럼 영향이 큰 변경은 반드시 사람이 검토하고 승인해야 합니다.

• Exception handling
  예상하지 못한 오류, 정책 위반 요청, 불확실한 분석 결과가 발생하면 자동 실행을 중단하고 사람에게 넘겨야 합니다.

• 감사 로그와 롤백
  AI가 어떤 데이터를 조회했고, 어떤 판단을 거쳐 어떤 도구를 호출했는지 기록해야 합니다. 실행 결과가 잘못되었을 때는 즉시 이전 상태로 되돌릴 수 있어야 합니다.

특히 “사람이 감독한다”는 표현만으로는 충분하지 않습니다. 누가 승인자인지, 어떤 작업이 고영향 변경인지, 승인 전후의 로그가 남는지까지 실제 운영 절차로 정의돼야 합니다.

Cloud 운영의 새로운 단위는 ‘에이전트 워크플로우’

기존 Cloud 환경의 핵심 단위는 가상 머신, 컨테이너, 데이터베이스, 스토리지였습니다. 그러나 Agentic AI가 확산되면 운영의 핵심 단위는 에이전트와 에이전트 워크플로우로 확장됩니다.

이 워크플로우에는 단순한 모델 호출보다 많은 요소가 포함됩니다.

• 티켓·로그·모니터링 데이터 연결
• ITSM, 코드 저장소, CI/CD, 보안 도구 연동
• 장기 작업의 상태 관리
• 승인 단계와 담당자 지정
• 정책 평가와 권한 확인
• 테스트 환경 검증
• 실행 결과 모니터링
• 실패 시 자동 중단 및 롤백

즉, 기업이 평가해야 할 대상은 “AI가 장애 원인을 잘 맞히는가”에 그치지 않습니다. 더 중요한 질문은 AI가 틀렸을 때도 Cloud 운영 환경을 안전하게 보호할 수 있는가입니다.

가장 현실적인 시작점은 읽기 전용 자동화

모든 기업이 곧바로 AI에게 운영 변경 권한을 줄 필요는 없습니다. 초기에는 읽기 전용 업무부터 시작하는 것이 안전합니다.

예를 들어 AI 에이전트는 다음 업무에서 빠르게 가치를 낼 수 있습니다.

• 장애 티켓 자동 분류와 우선순위 지정
• 로그 및 경고 메시지 요약
• 과거 유사 장애 사례 검색
• 최근 배포·설정 변경 이력 비교
• 코드 리뷰와 취약점 수정안 초안 작성
• 장애 대응 절차와 운영 명령어 제안

그다음에는 사람이 승인하는 제안형 자동화로 확대할 수 있습니다. 충분한 검증과 감사 체계가 마련된 뒤에야 테스트 환경 배포, 사전 승인된 복구 절차 같은 저위험 작업을 자동 실행하는 방식이 바람직합니다.

AI가 새벽의 장애 티켓을 먼저 읽고 해결책을 준비하는 시대는 이미 시작됐습니다. 하지만 신뢰할 수 있는 Cloud 운영의 기준은 자동화 수준이 아닙니다. AI가 어디까지 할 수 있는지보다, 어디서 멈추고 누구에게 판단을 넘기는지가 더 중요합니다.

챗봇에서 업무 실행 엔진으로: Cloud 에이전트의 5계층

“이 장애 티켓을 분석하고, 원인을 찾은 뒤 수정안을 테스트해 줘.”

사람에게는 한 문장인 이 요청이 AI 에이전트에게는 여러 시스템을 오가는 복합 업무입니다. 티켓 내용을 읽고, 로그를 조회하며, 관련 코드를 분석하고, 수정안을 만들고, 테스트를 실행한 뒤, 필요하면 담당자에게 승인을 요청해야 합니다.

이 과정이 가능한 이유는 모델 하나가 모든 일을 하기 때문이 아닙니다. Cloud 환경에서 연결된 다섯 개의 기술 계층이 각자의 역할을 수행하기 때문입니다. HCLTech와 Anthropic의 협력은 바로 이 구조를 기업 환경에 적용하려는 시도입니다.

1. Foundation Model Layer: 이해하고 계획하는 두뇌

가장 아래에는 자연어를 이해하고 추론하는 기반 모델이 있습니다. Claude는 사용자의 요청을 해석하고, 업무 목표를 세부 작업으로 나누며, 다음 행동을 계획합니다.

예를 들어 “취약점이 있는 코드를 수정해 달라”는 요청을 받으면 모델은 다음과 같은 계획을 세울 수 있습니다.

• 취약점 보고서와 관련 코드 확인
• 영향을 받는 모듈 식별
• 수정 방향 제안
• 변경 코드 작성
• 테스트 케이스 생성
• 결과 요약 및 승인 요청

이 계층에는 일반 업무용 Claude, 소프트웨어 엔지니어링에 특화된 Claude Code, 협업과 생산성 업무를 지원하는 Cowork가 포함됩니다. 다만 모델은 스스로 기업 시스템에 접근하거나 변경을 실행하지 않습니다. 실제 업무 수행에는 다음 계층이 필요합니다.

2. Agent Orchestration Layer: 일을 순서대로 움직이는 지휘자

에이전트 오케스트레이션 계층은 모델의 계획을 실제 작업 흐름으로 바꿉니다. 쉽게 말하면 “무엇을 해야 하는지”를 이해한 모델과 “어떤 순서로, 어떤 도구를 사용해 실행할지”를 관리하는 운영 로직 사이의 연결부입니다.

이 계층은 보통 다음 기능을 담당합니다.

• 작업을 여러 단계로 분해
• 로그, 티켓, 코드 저장소, 데이터베이스 등 적절한 도구 선택
• 작업 상태와 중간 결과 저장
• 실패한 단계의 재시도 또는 대체 경로 실행
• 조건에 따라 사람에게 승인 요청
• 최종 결과의 검증과 보고

가령 IT 장애 대응 에이전트는 티켓을 읽은 후 곧바로 서버 설정을 바꾸지 않습니다. 먼저 모니터링 로그를 조회하고, 최근 배포 이력을 확인하며, 원인 후보를 좁힙니다. 이후 테스트 환경에서 수정안을 검증한 뒤에야 운영 변경 요청을 생성합니다.

이처럼 에이전트의 핵심 가치는 답변 생성이 아니라 여러 업무 단계를 안전하게 연결하고 상태를 관리하는 능력에 있습니다.

3. Enterprise Application Layer: 기존 업무 도구 안으로 들어가는 실행부

AI 에이전트가 실제 업무 가치를 만들려면 기업이 이미 사용하는 시스템과 연결돼야 합니다. HCLTech는 Claude와 Claude Code를 HCL BigFix, HCL AppScan, Actian AI analyst, AI Force 같은 제품에 통합할 계획입니다.

이 계층에서 AI는 별도의 챗봇 화면에 머물지 않습니다. 사용자가 익숙한 업무 도구 안에서 다음과 같은 역할을 수행합니다.

업무 영역	에이전트 활용 예시
IT 운영	장애 티켓 분류, 로그 분석, 표준 복구 절차 제안
소프트웨어 개발	코드 분석, 취약점 수정안 생성, 테스트 코드 작성
보안	보안 경고 우선순위화, 영향 범위 분석, 대응 절차 지원
데이터 분석	자연어 질의를 데이터 분석 작업으로 변환
직원 서비스	계정·권한 요청 처리, 내부 정책 및 절차 안내

특히 Cloud 기반 업무 환경에서는 API, 데이터 저장소, ID 관리 시스템, 모니터링 도구가 연결되어 있기 때문에 에이전트가 활용할 수 있는 실행 범위가 넓습니다. 동시에 잘못된 호출 하나가 실제 운영 장애나 데이터 노출로 이어질 수 있어 통제 계층의 중요성도 커집니다.

4. Governance and Control Layer: 자동화에 브레이크를 거는 안전장치

기업용 에이전트에서 가장 중요한 계층은 거버넌스와 통제입니다. 모델이 뛰어나더라도 권한 없이 실행하거나, 잘못된 상황에서 자동 변경을 수행하면 위험은 커집니다.

이번 구조에서 강조되는 통제 장치는 세 가지입니다.

• Policy guardrails: 에이전트가 접근할 수 있는 데이터, 호출 가능한 도구, 실행 금지 작업, 승인 조건을 정책으로 정의합니다.
• Exception handling: 정책 위반, 예상 밖의 입력, 도구 오류, 신뢰도 부족 상황에서 작업을 중단하거나 사람에게 넘깁니다.
• Human oversight: 결제, 고객 데이터, 생산 환경 설정, 보안 정책처럼 영향이 큰 변경은 담당자의 검토와 승인을 거치게 합니다.

예를 들어 에이전트가 애플리케이션 코드의 오류를 수정하는 것은 허용할 수 있습니다. 그러나 해당 변경을 운영 환경에 배포하거나 데이터베이스 스키마를 수정하려면 별도의 승인이 필요하도록 설계할 수 있습니다.

실효성 있는 거버넌스를 위해서는 선언적 정책만으로 충분하지 않습니다. 기업은 최소한 다음 요소를 확인해야 합니다.

• 역할 기반 접근 제어(RBAC)
• 에이전트 전용 ID와 최소 권한 설정
• 변경 전후의 감사 로그
• 승인 워크플로
• 자동 롤백과 복구 절차
• 프롬프트 인젝션 및 악성 문서 대응
• 모델 업데이트 후 결과 변화 검증

5. Deployment and Operations Layer: Cloud에서 안전하게 배포하고 운영하는 기반

마지막 계층은 에이전트를 실제 기업 환경에 배포하고 지속적으로 관리하는 운영 영역입니다. 여기에는 보안 샌드박스, 테스트 환경, 관측성, 성능 관리, 직원 교육, 현장 배포 지원이 포함됩니다.

HCLTech가 추진하는 secure sandbox와 Center of Excellence(CoE)는 이 계층의 대표적인 구성입니다. 기업은 에이전트에 운영 권한을 주기 전에 격리된 환경에서 다음을 검증해야 합니다.

1. 에이전트가 어떤 데이터와 도구에 접근하는지
2. 정책 위반 요청을 제대로 차단하는지
3. 예외 상황에서 작업을 중단하고 승인자에게 알리는지
4. 생성한 코드와 운영 명령이 테스트를 통과하는지
5. 비용, 응답 시간, 성공률이 서비스 기준을 충족하는지

이 운영 계층은 단순한 구축 단계가 아닙니다. 모델이 바뀌고, 업무 정책이 변경되며, 새로운 보안 위협이 등장할 때마다 지속적으로 평가하고 조정해야 하는 영역입니다.

핵심은 모델의 지능만이 아닙니다.
기업용 Cloud 에이전트의 경쟁력은 모델, 오케스트레이션, 업무 시스템 통합, 거버넌스, 운영 체계가 하나의 흐름으로 연결될 때 만들어집니다.

결국 챗봇은 질문에 답하지만, 에이전트는 제한된 권한과 명확한 정책 아래에서 업무를 수행합니다. 앞으로 기업이 평가해야 할 기준도 “가장 똑똑한 모델인가”에서 “우리의 시스템과 권한 체계 안에서 얼마나 안전하고 검증 가능하게 일하는가”로 이동할 가능성이 큽니다.

Cloud 환경에서 가장 중요한 기능은 더 똑똑한 모델이 아니라 ‘멈출 줄 아는 AI’

코드 수정안을 만드는 일은 AI가 충분히 해낼 수 있습니다. 로그를 분석하고, 원인을 추론하며, 수정된 코드를 제안하는 것도 가능합니다. 하지만 질문은 그다음입니다. 결제 로직이나 운영 환경의 핵심 설정을 바꾸는 순간에도 AI에게 실행 권한을 맡겨도 될까요?

기업용 Agentic AI에서 가장 중요한 역량은 항상 더 많은 일을 처리하는 능력이 아닙니다. 오히려 권한의 경계를 이해하고, 위험한 순간에는 스스로 멈춘 뒤 사람에게 판단을 넘기는 능력입니다.

HCLTech와 Anthropic의 협력이 주목받는 이유도 여기에 있습니다. Claude와 Claude Code를 IT 운영, 보안, 개발 업무에 연결하면서도 정책 기반 가드레일, 예외 처리, 사람의 감독을 핵심 구조로 제시했습니다. 이는 AI를 단순한 답변 도구가 아니라, 실제 Cloud 업무를 수행하는 실행 주체로 다루기 시작했다는 뜻입니다.

실행 능력보다 중요한 것은 권한 통제

AI 에이전트가 기업 시스템에 연결되면 할 수 있는 일은 빠르게 늘어납니다.

• 장애 티켓을 읽고 우선순위를 분류합니다.
• 서버 로그와 설정 값을 조회합니다.
• 취약한 코드 구간을 찾아 수정안을 만듭니다.
• 테스트 환경에 배포를 시도합니다.
• 계정 생성이나 권한 요청을 처리합니다.
• 운영 스크립트를 실행합니다.

문제는 마지막 단계입니다. 정보를 읽고 분석하는 권한과 실제 시스템을 바꾸는 권한은 위험도가 전혀 다릅니다.

예를 들어 AI가 “이 설정을 변경하면 장애가 해결될 가능성이 높다”고 판단할 수 있습니다. 그러나 그 설정이 생산 환경의 네트워크 정책, 고객 데이터 접근 권한, 결제 승인 규칙과 연결되어 있다면 단 한 번의 잘못된 실행도 큰 사고로 이어질 수 있습니다.

따라서 기업은 AI에게 모든 권한을 한 번에 주는 대신, 업무의 영향도에 따라 권한을 세분화해야 합니다.

업무 유형	AI 역할	권장 통제 수준
로그 요약, 문서 검색	읽기·분석	자동 수행 가능
코드 수정안, 장애 원인 분석	제안	사람 검토 필요
테스트 환경 배포	제한적 실행	사전 정의된 정책 필요
운영 환경 설정 변경	실행 요청	다단계 승인 필요
결제·보안 정책·고객 데이터 변경	고위험 작업	사람의 최종 승인 필수

Cloud 운영의 핵심은 ‘실행 전 멈춤’이다

Governed Agentic AI는 AI의 행동을 단순히 차단하는 기술이 아닙니다. AI가 무엇을 할 수 있는지, 언제 멈춰야 하는지, 멈춘 뒤 누구에게 넘겨야 하는지를 운영 정책으로 정의하는 구조입니다.

여기에는 세 가지 장치가 필요합니다.

첫째, 정책 기반 가드레일입니다.
AI가 접근할 수 있는 데이터, 호출할 수 있는 API, 변경할 수 있는 시스템 범위를 명확히 제한해야 합니다. 예를 들어 개발 환경에서는 코드 수정과 테스트 배포를 허용하되, 생산 환경에서는 변경 요청까지만 생성하도록 설정할 수 있습니다.

둘째, 예외 처리입니다.
AI가 예상하지 못한 상황을 만났을 때 무리하게 작업을 계속하면 안 됩니다. 권한 부족, 정책 충돌, 데이터 민감도 상승, 도구 호출 실패가 발생하면 자동으로 작업을 중단하고 담당자에게 전달해야 합니다.

셋째, 사람의 감독입니다.
사람이 모든 작업을 직접 수행할 필요는 없습니다. 하지만 고영향 변경에는 승인자가 반드시 개입해야 합니다. 특히 결제, 개인정보, 보안 설정, 생산 시스템 배포처럼 되돌리기 어렵거나 피해 범위가 큰 작업은 AI의 자동 실행 대상이 되어서는 안 됩니다.

‘승인 버튼’만으로는 충분하지 않다

사람의 승인을 받는다고 해서 거버넌스가 완성되는 것은 아닙니다. 승인자는 AI가 왜 그 결론에 도달했는지, 무엇을 변경하려는지, 실패하면 어떤 영향이 있는지를 확인할 수 있어야 합니다.

이를 위해 기업은 Cloud 기반 AI 운영 환경에 다음 요소를 갖춰야 합니다.

• RBAC 기반 권한 관리: 사용자·에이전트·도구별 최소 권한 적용
• 승인 워크플로우: 고위험 변경에 대한 담당자와 승인 단계 지정
• 변경 전 검증: 테스트, 시뮬레이션, 정책 검사를 통한 사전 확인
• 불변 감사 로그: 누가 어떤 요청을 했고, AI가 어떤 도구를 호출했는지 기록
• Rollback 체계: 잘못된 변경을 즉시 이전 상태로 되돌리는 복구 절차
• 실시간 모니터링: 비정상적인 도구 호출과 권한 사용을 탐지하는 관측성 체계

결국 신뢰할 수 있는 AI는 멈추지 않는 AI가 아닙니다. 필요할 때 빠르게 실행하고, 위험 신호가 보이면 즉시 멈추며, 판단이 필요한 순간에는 책임 있는 사람에게 권한을 돌려주는 AI입니다.

기업용 Cloud AI의 경쟁력도 여기서 갈립니다. 더 뛰어난 모델을 도입하는 것만으로는 충분하지 않습니다. AI가 실제 업무를 수행하는 만큼, 기업은 AI의 능력보다 먼저 AI를 안전하게 멈출 수 있는 운영 구조를 설계해야 합니다.

Cloud 경쟁의 다음 무대는 AI 운영이다

클라우드 경쟁을 좌우하던 기준은 컴퓨팅 성능, GPU 확보 능력, 스토리지 가격, 모델 API의 품질이었습니다. 하지만 Agentic AI가 기업의 실제 업무 시스템으로 들어오면서 질문이 달라지고 있습니다.

“우리 업무 안에서 AI가 안전하게 실행되고, 문제가 생기면 즉시 멈추고 되돌릴 수 있는가?”

이제 Cloud의 핵심 경쟁력은 모델을 호출할 수 있는 환경을 제공하는 데서 끝나지 않습니다. AI 에이전트가 티켓을 분석하고, 로그를 조회하고, 코드를 수정하며, 보안 정책이나 운영 도구를 실행할 때 이를 어떻게 통제하고 감사하며 복구할 것인가가 중요해졌습니다.

HCLTech와 Anthropic의 협력은 이러한 변화를 잘 보여줍니다. Claude, Claude Code, Cowork를 기업의 IT 운영·보안·소프트웨어 개발 업무에 연결하되, 정책 기반 가드레일과 예외 처리, 사람의 승인을 기본 구조로 두겠다는 접근입니다. 이는 AI를 단순한 대화형 도구가 아니라, 실제 업무를 수행하는 운영 주체로 바라보는 방식입니다.

인프라 경쟁에서 실행 신뢰성 경쟁으로

기존 Cloud 환경에서는 주로 다음 요소가 경쟁력이었습니다.

• 더 빠른 컴퓨팅과 확장 가능한 인프라
• 안정적인 네트워크와 데이터 저장소
• 컨테이너, Kubernetes, 데이터베이스 같은 플랫폼 서비스
• 고성능 LLM API와 낮은 추론 지연시간

그러나 AI 에이전트는 답변만 생성하지 않습니다. 여러 시스템에 접근해 데이터를 읽고, 도구를 호출하며, 작업 순서를 계획하고, 경우에 따라 변경을 실행합니다. 따라서 기업이 평가해야 할 기준도 확장됩니다.

기존 Cloud 평가 기준	Agentic AI 시대의 추가 평가 기준
컴퓨팅 성능	에이전트 작업 실행의 안정성
모델 정확도	정책 준수와 권한 통제
API 사용 편의성	승인 워크플로와 예외 처리
인프라 가용성	감사 로그와 변경 이력 추적
비용 효율성	실패 시 rollback 및 복구 능력

예를 들어 AI가 장애 티켓을 분류하고 로그를 요약하는 업무는 비교적 위험이 낮습니다. 반면 AI가 운영 서버의 설정을 변경하거나, 결제 로직을 수정하거나, 보안 권한을 부여한다면 이야기가 달라집니다. 이때 필요한 것은 더 똑똑한 모델만이 아니라 실행 권한을 세밀하게 나누고, 고위험 작업에서 사람의 승인을 강제하는 운영 체계입니다.

AI 운영 계층이 새 Cloud 차별화 요소가 된다

앞으로 기업용 Cloud는 크게 세 층에서 경쟁할 가능성이 높습니다.

1. AI Compute
   GPU, 네트워크, 데이터센터, 추론 비용처럼 AI를 실행하기 위한 기반 인프라입니다.

2. AI Platform
   모델 API, 에이전트 런타임, 도구 연결, 워크플로 오케스트레이션이 포함됩니다.

3. AI Operations
   정책, 보안, 감사, 승인, 모니터링, 평가, 장애 복구를 담당하는 계층입니다.

이 가운데 가장 빠르게 중요성이 커지는 영역은 세 번째인 AI Operations입니다. 모델 성능은 시간이 갈수록 상향 평준화될 수 있지만, 복잡한 기업 환경에서 AI를 안전하게 운영하는 역량은 쉽게 복제하기 어렵기 때문입니다.

특히 다음 기능은 엔터프라이즈 AI 도입의 필수 조건이 될 가능성이 큽니다.

• 역할 기반 접근 제어(RBAC)와 최소권한 정책
• 고영향 변경을 위한 다단계 승인 절차
• 변경 전 테스트와 샌드박스 검증
• 변경 후 자동 검증 및 실시간 모니터링
• 변경 이력을 보존하는 감사 로그
• 정책 위반 또는 비정상 행동 시 즉시 중단
• 오류 발생 시 이전 상태로 되돌리는 rollback 체계
• 모델 업데이트 이후 결과 변화를 확인하는 지속적 평가

사람의 감독은 ‘승인 버튼’보다 넓은 개념이다

기업이 “human oversight”를 도입한다고 해서 모든 문제가 해결되는 것은 아닙니다. 단순히 마지막 단계에 승인 버튼 하나를 추가하는 방식은 충분하지 않습니다.

효과적인 감독 체계는 AI가 수행한 작업의 근거, 사용한 데이터, 호출한 도구, 변경 대상, 예상 영향도를 사람이 확인할 수 있어야 합니다. 또한 승인자는 자신의 권한 범위 안에서만 결정을 내릴 수 있어야 하며, 승인 이후에도 결과를 검증하고 필요하면 즉시 되돌릴 수 있어야 합니다.

즉, 사람의 감독은 다음 흐름으로 설계돼야 합니다.

정책 정의 → 권한 확인 → 작업 제안 → 사전 검증 → 사람 승인 → 제한적 실행 → 결과 검증 → 감사 기록 → 필요 시 rollback

이 구조가 없다면 AI 에이전트는 생산성을 높이는 도구가 아니라, 권한을 가진 자동화 리스크가 될 수 있습니다.

기업이 지금 준비해야 할 것은 모델 교체가 아니다

기업이 Agentic AI를 검토할 때 가장 먼저 물어야 할 질문은 “어떤 모델이 가장 뛰어난가”가 아닙니다. 더 중요한 질문은 다음과 같습니다.

• AI 에이전트는 어떤 시스템과 데이터에 접근하는가?
• 읽기·제안·실행 권한은 어떻게 분리되는가?
• 운영 환경 변경 전 테스트와 승인은 가능한가?
• 누가 어떤 결정을 승인했는지 추적할 수 있는가?
• 모델이나 워크플로가 바뀌었을 때 결과를 검증하는가?
• 문제가 발생했을 때 몇 분 안에 중단하고 복구할 수 있는가?

HCLTech와 Anthropic의 협력이 주목받는 이유도 여기에 있습니다. 이 발표는 단순한 모델 도입 사례가 아니라, 기업용 Cloud AI의 승부처가 AI의 성능에서 AI 운영의 신뢰성으로 이동하고 있음을 보여줍니다.

앞으로 가장 경쟁력 있는 Cloud 서비스는 AI를 가장 많이 연결한 서비스가 아니라, AI가 실제 업무를 수행하는 과정에서 권한·보안·감사·승인·복구를 가장 정교하게 관리하는 서비스가 될 것입니다.

Cloud 자동화의 속도보다 신뢰의 단계를 먼저 설계하라

AI 에이전트가 기업의 Cloud 환경에서 티켓을 분류하고, 로그를 분석하며, 코드를 수정하고, 운영 시스템까지 변경할 수 있다면 강력한 생산성 향상을 기대할 수 있습니다. 그러나 도입 첫날부터 에이전트에 광범위한 실행 권한을 부여할 필요는 없습니다.

오히려 기업용 Agentic AI의 현실적인 출발점은 “무엇을 자동화할 것인가”보다 “어디까지 신뢰할 것인가”를 먼저 설계하는 것입니다. HCLTech와 Anthropic이 강조한 policy guardrails, exception handling, human oversight도 결국 이 원칙을 구현하기 위한 운영 장치입니다.

읽기 전용: 가장 안전한 첫 단계

초기에는 AI 에이전트가 시스템을 변경하지 못하도록 하고, 정보를 읽고 해석하는 역할에 집중시키는 것이 좋습니다.

대표적인 업무는 다음과 같습니다.

• 장애 티켓 분류 및 우선순위 추천
• 운영 로그 요약과 이상 징후 탐지
• 보안 경고의 위험도 분석
• 내부 문서와 지식베이스 검색
• 코드 리뷰 초안 및 취약점 설명
• 변경 요청의 영향 범위 분석

이 단계에서 에이전트는 Cloud 인프라, 코드 저장소, ITSM 도구, 보안 관제 시스템의 데이터를 조회할 수 있습니다. 하지만 배포 실행, 계정 생성, 정책 변경, 데이터 삭제 같은 쓰기 작업은 수행하지 않습니다.

이 방식의 장점은 명확합니다. 기업은 실제 업무 데이터에서 AI의 정확도와 한계를 검증할 수 있고, 직원은 결과를 검토하면서 에이전트의 판단 방식을 학습할 수 있습니다.

제안형 자동화: 실행 권한은 사람이 가진다

다음 단계에서는 AI가 문제를 진단하는 데서 그치지 않고, 실행 가능한 조치안을 제시하도록 확장할 수 있습니다.

예를 들어 에이전트는 다음과 같은 제안을 만들 수 있습니다.

1. 장애 로그를 기반으로 원인 후보를 정리한다.
2. 수정이 필요한 설정값 또는 코드 구간을 제안한다.
3. 실행할 Cloud 명령어와 예상 영향을 설명한다.
4. 테스트 환경에서 검증할 절차를 생성한다.
5. 담당자에게 승인 요청을 전달한다.

이 단계의 핵심은 AI가 행동을 제안하지만 최종 실행은 사람이 승인한다는 점입니다. 특히 네트워크 정책, IAM 권한, 데이터베이스 설정, 결제 시스템, 프로덕션 배포처럼 영향 범위가 큰 작업은 승인 워크플로가 필수입니다.

승인 과정은 단순한 “확인” 버튼이 되어서는 안 됩니다. 승인자는 최소한 다음 정보를 확인할 수 있어야 합니다.

• 에이전트가 참조한 데이터와 근거
• 제안된 변경 내용
• 예상되는 영향 범위
• 실행 전후 검증 방법
• 실패 시 rollback 절차
• 관련 정책 및 감사 기록

제한적 자동 실행: 반복적이고 검증된 업무부터

사람의 검토를 거친 자동화 패턴이 축적되면, 위험이 낮고 표준화된 업무에 한해 실행 권한을 단계적으로 부여할 수 있습니다.

적합한 사례는 다음과 같습니다.

• 테스트 Cloud 환경의 임시 리소스 생성 및 삭제
• 사전 승인된 패치 적용
• 만료된 개발용 계정의 비활성화
• 표준 템플릿 기반의 인프라 배포
• 비핵심 서비스의 자동 재시작
• 반복적인 직원 요청 처리

이때 중요한 것은 “자동 실행” 자체가 아니라 명확한 경계 안에서만 실행되도록 제한하는 것입니다. 에이전트는 지정된 도구, 특정 리전, 정해진 시간대, 제한된 리소스 그룹에서만 작업하도록 구성해야 합니다.

예를 들어 개발 환경에서는 자동 배포를 허용하더라도, 운영 환경에서는 승인된 CI/CD 파이프라인을 통해서만 변경하도록 분리할 수 있습니다. 또한 에이전트별로 별도의 identity를 부여하고, 일반 사용자 계정이나 관리자 계정을 공유하지 않아야 합니다.

고영향 변경: 자동화보다 통제 가능성이 우선이다

프로덕션 데이터, 결제 로직, 보안 정책, 고객 정보, 핵심 네트워크 구성처럼 고영향 영역은 자동화의 편의성보다 통제 가능성이 우선되어야 합니다.

이 영역에서 AI 에이전트를 활용하려면 다음 조건이 필요합니다.

• 역할 기반 접근 제어(RBAC)와 최소권한 원칙
• 변경 전 시뮬레이션 또는 샌드박스 테스트
• 다단계 승인 워크플로
• 변경 불가능한 감사 로그(immutable audit log)
• 실시간 모니터링과 이상 행위 탐지
• 즉시 중단할 수 있는 kill switch
• 자동 또는 수동 rollback 절차
• 모델 업데이트 이후 재평가 체계

특히 에이전트가 외부 문서, 이메일, 티켓, 웹 콘텐츠를 읽는 환경에서는 prompt injection 위험을 고려해야 합니다. 악성 문서에 포함된 지시문이 에이전트의 도구 호출로 이어지지 않도록, 데이터 읽기 권한과 실행 권한을 분리하는 설계가 필요합니다.

신뢰는 한 번에 부여하는 권한이 아니라 축적되는 운영 데이터다

기업이 Agentic AI를 도입할 때 가장 피해야 할 접근은 “에이전트가 똑똑해 보이니 모든 업무를 맡기자”는 판단입니다. 모델 성능이 높더라도 기업 환경에서는 권한, 데이터, 예외 상황, 책임 소재가 함께 작동해야 합니다.

따라서 Cloud 기반 AI 에이전트의 도입 순서는 다음과 같이 설계하는 것이 바람직합니다.

조회 → 분석 → 제안 → 승인 기반 실행 → 제한적 자동 실행 → 고영향 업무의 엄격한 통제

이 과정에서 축적되는 것은 단순한 자동화 성공 사례가 아닙니다. 어떤 업무에서 AI가 신뢰할 수 있는지, 어떤 예외에서 사람이 개입해야 하는지, 어떤 정책이 실제 운영에서 효과적인지에 대한 조직의 경험입니다.

자동화의 속도는 기술로 높일 수 있습니다. 하지만 기업이 장기적으로 확보해야 할 경쟁력은 더 빠른 실행이 아니라, 안전하게 실행할 수 있다는 신뢰입니다.