AI 에이전트에게도 업무용 PC가 필요하다: AWS WorkSpaces가 보여주는 기업 자동화의 변화

똑똑한 모델이 있어도 ERP 화면은 저절로 열리지 않는다

AI 에이전트에게 “지난달 매출 자료를 확인해 ERP에 입력하고, 처리 결과를 사내 백오피스에 등록하라”고 지시했다고 가정해 보자. 모델은 요청을 여러 단계로 나누고 필요한 데이터를 찾으며 입력 순서를 계획할 수 있다. 그러나 그것만으로 업무가 끝나지는 않는다. ERP에 로그인할 계정, 프로그램이 설치된 운영체제, 사내망으로 이어지는 네트워크 경로, 화면을 읽고 클릭할 수단, 처리 결과를 저장할 공간이 필요하다. 중간에 경고창이 뜨거나 세션이 끊겼을 때 어떻게 대응할지도 정해야 한다.

여기서 드러나는 간극은 ‘추론’과 ‘실행’의 차이다. 챗봇은 잘못된 답을 내놓을 수 있지만, 실행 권한을 가진 에이전트는 잘못된 금액을 입력하고 고객 레코드를 변경하거나 외부로 파일을 전송할 수 있다. 모델의 출력이 곧 시스템의 상태 변경으로 이어지기 때문이다. 에이전트가 소프트웨어를 사용할 수 있게 만드는 순간, 기업은 모델 품질뿐 아니라 컴퓨팅 환경, 신원, 권한, 네트워크, 관찰 가능성, 복구 절차를 함께 운영해야 한다.

AWS가 정식 출시한 Amazon WorkSpaces for AI agents는 이 간극을 겨냥한다. AWS의 공식 설명은 AI 에이전트가 관리형 WorkSpaces 환경을 통해 데스크톱 애플리케이션에 안전하게 접근하고 조작할 수 있게 한다는 것이다. 이 글에서 쓰는 ‘AI 에이전트용 업무 PC’는 이해를 돕기 위한 해석적 비유다. AWS의 공식 제품명은 Amazon WorkSpaces for AI agents이며, 이를 인간 직원과 동등한 책임 주체인 ‘디지털 직원’으로 간주해서는 안 된다. 출처: Announcing general availability of Amazon WorkSpaces for AI agents, Secure Desktops for AI Agents – Amazon WorkSpaces

기업 AI 스택에 빠져 있던 네 번째 질문

기업의 AI 도입 논의는 대체로 세 층을 거쳐 확장돼 왔다. 첫째는 어떤 모델이 필요한 정확도와 비용, 지연시간을 충족하는가라는 모델 계층이다. 둘째는 사내 데이터와 업무 도구를 어떻게 연결할 것인가라는 연결 계층이다. MCP는 이 지점에서 도구와 리소스를 표준화된 방식으로 노출하는 수단으로 주목받았다(관련 글: 기업 SaaS의 MCP 대응 전략). 셋째는 여러 에이전트가 역할을 나누고 정보를 교환하는 상호운용 계층이다. Agent2Agent 같은 접근은 이 문제를 다룬다.

그러나 연결 명세가 있다고 실행 장소가 생기는 것은 아니다. 도구가 API로 제공되지 않거나, 업무가 특정 Windows 프로그램과 브라우저 화면을 오가며 이뤄지거나, 사내망에서만 열리는 시스템이라면 별도의 질문이 남는다.

모델 계층       무엇이 판단하는가
     ↓
연결 계층       어떤 데이터·도구와 연결하는가
     ↓
상호운용 계층   다른 에이전트와 어떻게 협업하는가
     ↓
실행 환경 계층  어디에서, 어떤 권한과 통제 아래 행동하는가

에이전트 실행 환경은 단순한 가상 머신을 뜻하지 않는다. 업무 애플리케이션이 설치된 실행 공간, 인증된 세션, 허용된 네트워크 경로, 파일 보관 정책, 입력·화면 인식 수단, 행동 로그, 중단 장치를 묶은 운영 경계다. WorkSpaces for AI agents가 의미 있는 이유는 새 모델을 내놓아서가 아니라 이 네 번째 질문을 별도 인프라 문제로 드러냈기 때문이다.

API가 우선이지만, 기업의 모든 업무가 API로 정리돼 있지는 않다

구조화된 API 호출은 가능한 경우 가장 먼저 검토할 방식이다. 입력과 출력 형식이 명확하고, 권한 범위를 작업 단위로 제한하기 쉬우며, 멱등성 키나 트랜잭션, 오류 코드로 실패를 다루기 좋다. 주문 조회 API에 읽기 권한만 주거나, 결제 실행 API 앞에 승인 절차를 두는 식의 통제가 가능하다. MCP를 사용하더라도 그 뒤의 도구가 잘 설계된 API라면 동일한 장점을 살릴 수 있다.

GUI 기반 자동화는 성격이 다르다. 에이전트는 화면의 현재 상태를 해석하고 좌표나 요소를 선택해 클릭하며 텍스트를 입력한다. 팝업, 해상도, 지연, 화면 개편, 예외 메시지에 따라 다음 행동이 달라진다. 사람이 보기에 작은 UI 변경도 자동화에는 상태 공간의 변화다. 잘못된 화면에서 동일한 버튼 모양을 클릭하는 ‘오인 실행’도 생길 수 있다.

그럼에도 GUI 조작이 필요한 현실적 이유가 있다. 오래된 ERP·CRM 클라이언트, 메인프레임 접속 도구, 사내망 전용 프로그램, API가 공개되지 않은 백오피스, 계약상 수정하기 어려운 패키지 소프트웨어가 기업의 핵심 프로세스에 남아 있기 때문이다. 시스템을 전면 현대화하는 비용과 시간이 자동화의 편익보다 클 수도 있다. 이때 관리형 데스크톱은 기존 애플리케이션을 그대로 두고 에이전트가 사람이 사용하던 인터페이스를 통과하게 하는 ‘호환 계층’이 될 수 있다.

따라서 “API냐 가상 PC냐”는 양자택일이 아니다. 업무 단계를 분해해 조회와 계산은 API로, API가 없는 최종 등록만 데스크톱으로 처리할 수 있다. 에이전트가 화면을 조작할 수 있다는 이유로 기존 API를 우회하면 안정성, 비용, 감사 가능성을 스스로 낮추게 된다. 실행 환경은 레거시 현실을 흡수하는 장치이지, 인터페이스 설계 원칙을 폐기하는 면허가 아니다.

WorkSpaces for AI agents는 실제로 무엇을 제공하는가

공식 문서에서 확인되는 중심 구조는 Amazon WorkSpaces Applications의 스트리밍 세션과 관리형 MCP 서비스다. 에이전트는 스트리밍 URL을 사용해 세션에 연결하고, MCP를 통해 데스크톱 애플리케이션과 상호작용한다. 스택을 만들 때 에이전트 접근을 활성화하며, 관련 설정은 인간 사용자를 위한 일반 구성과 구분된다. 출처: Provide agents access to WorkSpaces, Learn more about agents accessing WorkSpaces

1. Computer input과 Computer vision

`Computer input`은 클릭, 텍스트 입력, 스크롤을 가능하게 하고, `Computer vision`은 스트리밍 세션의 화면을 스크린샷으로 보게 한다. 둘 중 적어도 하나를 스택 수준에서 활성화해야 한다. 이 조합을 이용하면 에이전트는 애플리케이션을 열고 폼을 채우며 결과 화면을 확인하는 흐름을 수행할 수 있다.

여기서 중요한 설계 원칙은 ‘보는 것’과 ‘행동하는 것’을 분리해 권한으로 다루는 것이다. 검증 에이전트에는 화면 확인만 허용하고, 실행 에이전트에만 입력을 허용하는 식의 역할 분리가 가능하다. 다만 시각 모델이 화면을 해석한다는 사실 자체가 정확한 상태 인식을 보장하지는 않는다. 파괴적 작업 직전에는 대상 레코드, 금액, 최종 버튼의 의미를 별도 규칙이나 승인으로 다시 확인해야 한다. 출처: Learn more about agents accessing WorkSpaces

2. MCP tool forwarding

`MCP tool forwarding`을 활성화하면 WorkSpaces 애플리케이션 세션 안에서 제공되는 MCP 도구를 에이전트에 전달할 수 있다. 에이전트는 화면 조작 도구만 사용하는 대신, 세션 안에서 이용 가능한 직접 MCP 호출을 함께 쓸 수 있다. 이는 중요한 혼합형 설계다. 화면을 여러 번 클릭하는 것보다 구조화된 도구 호출이 더 확실한 단계는 도구로 처리하고, GUI에만 남은 부분만 Computer Use 방식으로 처리할 수 있기 때문이다.

실무적으로는 화면 자동화의 범위를 최소화하는 데 활용해야 한다. 예컨대 파일 검색과 데이터 검증은 전달된 MCP 도구로 수행하고, API가 없는 회계 프로그램의 최종 입력만 화면으로 처리한다. 이렇게 하면 화면 변화에 노출되는 단계를 줄이고, 각 호출의 의도를 로그에서 더 명확히 식별할 수 있다. 출처: Learn more about agents accessing WorkSpaces

3. 세션 지속성과 증거 보관

선택적으로 홈 폴더와 애플리케이션 설정 지속성을 활성화할 수 있다. 홈 폴더를 사용하면 에이전트 파일을 고객 AWS 계정의 Amazon S3 버킷에 저장할 수 있고, 애플리케이션 설정 지속성을 사용하면 세션 사이에 애플리케이션 사용자 설정과 Windows 설정을 유지할 수 있다. 반복 업무에서 매번 초기 설정을 되풀이하지 않아도 된다는 의미다.

스크린샷 저장도 선택 사항이다. 활성화하면 에이전트 세션에서 캡처한 화면을 지정한 S3 버킷에 저장한다. 이는 결과 증빙과 사고 분석에 유용하지만, 화면에 고객 정보나 자격 증명, 영업 비밀이 나타날 수 있다는 뜻이기도 하다. 보존 기간, 암호화, 버킷 접근 권한, 삭제 정책, 법적 보존 요구를 먼저 정해야 한다. 기록을 많이 남기는 것이 자동으로 더 안전한 것은 아니다. 민감한 기록을 불필요하게 축적하면 새로운 공격 표면이 된다. 출처: Learn more about agents accessing WorkSpaces

4. 인간의 실시간 관찰과 중단

`User control mode`는 브라우저의 스트리밍 URL을 통해 사람이 에이전트 세션을 실시간으로 보게 한다. `VIEW_ONLY`는 관찰, `VIEW_STOP`은 관찰과 중단, `DISABLED`는 둘 다 비활성화한다. `VIEW_STOP`에서 사람이 에이전트를 멈추면 작업을 재개하려면 새 세션을 시작해야 한다.

이 기능은 인간 참여형 통제를 구체적인 운영 장치로 바꾼다. 하지만 모든 세션을 사람이 계속 지켜보는 방식은 확장성이 낮다. 위험 등급에 따라 저위험 조회는 사후 표본 감사, 중위험 입력은 정책 기반 검증, 고위험 전송·삭제·승인은 실행 직전 인간 승인과 실시간 중단 가능 상태로 나누는 편이 현실적이다. 관찰 버튼은 통제 체계의 한 요소이지 통제 체계 전체가 아니다. 출처: Provide agents access to WorkSpaces, Learn more about agents accessing WorkSpaces

5. 모니터링과 현재의 제약

공식 문서에 따르면 에이전트의 연결, 사용 도구, 세션 종료 같은 이벤트는 AWS CloudTrail에서 확인할 수 있다. 도구 호출은 데이터 이벤트이므로 이를 기록하도록 trail을 설정해야 한다. Amazon CloudWatch에는 호출 수, 지연, 클라이언트·서버 오류, MCP 세션 시작과 지속시간 관련 지표가 제공된다. 스크린샷 저장을 켰다면 S3의 화면 자료와 이 이벤트를 결합해 실행 타임라인을 재구성할 수 있다.

정식 출시가 곧 제약이 없다는 뜻은 아니다. 현재 공식 문서에는 Windows Server 이미지만 지원하고, 멀티 세션 및 Elastic fleet은 지원하지 않으며, 한 세션에는 에이전트 하나만 연결할 수 있다는 제한이 적혀 있다. 에이전트 접근 구성에서는 VPC endpoint도 지원하지 않는다고 명시돼 있다. 반면 일반 WorkSpaces Applications의 네트워크 격리 문서는 VPC와 서브넷, private subnet, interface endpoint 활용을 설명한다. 따라서 일반 서비스의 네트워크 기능을 에이전트 접근 경로에 그대로 적용된다고 가정하지 말고, 해당 구성의 제약과 실제 데이터 경로를 별도로 검증해야 한다. 출처: Learn more about agents accessing WorkSpaces, Network Isolation – Amazon WorkSpaces Applications

RPA와 VDI의 결합이지만, 운영 방식은 같을 수 없다

이 접근은 완전히 새로운 발명이라기보다 기존 기술의 재조합에 가깝다. VDI는 애플리케이션과 데스크톱을 중앙에서 제공하고 관리하는 오래된 기업 인프라 패턴이다. RPA 역시 사람이 사용하는 화면을 자동으로 조작해 왔다. 브라우저 자동화와 Computer Use는 소프트웨어 화면을 기계가 직접 다루는 흐름을 확장했다. Amazon WorkSpaces 자체도 특정 사용 사례에 맞는 클라우드 기반 VDI 선택지를 제공하는 서비스군으로 설명된다. 출처: Virtual Desktop Infrastructure – Amazon WorkSpaces

차이는 자동화 주체의 행동 범위다. 전통적 RPA는 대체로 미리 정의된 화면과 규칙, 분기 안에서 움직인다. AI 에이전트는 자연어 목표를 해석하고 화면 상황에 따라 다음 행동을 선택할 수 있다. 이 유연성은 예외 처리 범위를 넓히지만, 테스트하지 않은 경로로 진입할 가능성도 키운다. 같은 목표라도 실행 순서가 달라질 수 있고, 화면의 문구를 잘못 해석해 예상하지 못한 조작을 선택할 수 있다.

따라서 기존 RPA 봇의 계정과 가상 머신을 그대로 에이전트에 넘기는 방식은 위험하다. 결정 가능성이 커진 만큼 허용 행동의 경계는 더 명시적이어야 한다. ‘업무를 완료하라’는 목표와 ‘무엇은 절대 하지 말라’는 정책을 분리하고, 단계별 상태 검증과 최대 실행 횟수, 허용 애플리케이션, 외부 통신 목적지, 금액·건수 한도를 기계적으로 강제해야 한다.

VDI도 그 자체로 보안 통제가 완성된 것은 아니다. 중앙 관리와 세션 격리는 좋은 기반이지만, 과도한 계정 권한이나 열린 인터넷 경로, 공유 자격 증명, 무제한 파일 반출이 남아 있다면 격리된 데스크톱 안에서도 사고가 발생할 수 있다. AWS 역시 WorkSpaces 보안을 공동 책임 모델로 설명하며, 고객이 데이터 민감도와 법규, 서비스 설정에 맞춰 ‘클라우드 안의 보안’을 책임져야 한다고 명시한다. 출처: Security in Amazon WorkSpaces

실행 환경이 거버넌스의 핵심 단위가 되는 이유

에이전트 거버넌스를 프롬프트 검토만으로 해결할 수 없는 이유는 실제 권한이 모델 바깥에 있기 때문이다. 모델이 “이 작업은 허용된다”고 판단해도 운영 계정과 네트워크가 막으면 실행되지 않는다. 반대로 프롬프트에 금지 문구가 있어도 세션에 관리자 권한과 외부 전송 경로가 열려 있으면 오류나 프롬프트 인젝션이 실제 사고로 이어질 수 있다. 강한 통제는 지시문이 아니라 실행 인프라에서 집행돼야 한다.

신원과 자격 증명: 사람 계정의 대리 사용을 피하라

에이전트별 또는 업무 역할별 비인간 신원을 부여하고, 사람의 계정을 공유하지 않아야 한다. 그래야 누가 어떤 권한으로 변경했는지 추적할 수 있다. 자격 증명은 프롬프트, 스크린샷, 로컬 파일에 직접 노출하지 않고 비밀 관리 체계에서 짧게 발급하는 방식을 우선 검토해야 한다. 장기 비밀번호가 불가피한 레거시 프로그램은 접근 주체, 회전 주기, 세션 주입 방식, 화면 노출 방지를 별도로 설계해야 한다.

최소 권한: ‘앱에 접근 가능’보다 세밀해야 한다

애플리케이션 실행 권한만 제한해서는 충분하지 않다. 같은 ERP에서도 조회, 입력, 승인, 삭제의 위험이 다르다. 가능하면 서로 다른 계정과 역할로 분리하고, 에이전트가 수행할 업무 범위에 맞는 메뉴와 데이터만 노출해야 한다. 하나의 범용 에이전트에 여러 부서의 애플리케이션과 관리자 권한을 몰아주는 설계는 편리하지만 사고 반경을 크게 만든다.

네트워크 경계: 목적지 허용 목록이 필요하다

세션에서 접근 가능한 사내 시스템과 외부 주소를 업무에 필요한 범위로 제한해야 한다. 인터넷 전체를 열어 두면 화면에 표시된 악성 지시를 따라 파일을 외부로 전송하거나, 승인되지 않은 서비스를 호출할 수 있다. DNS, 프록시, 방화벽, 서브넷 정책을 사용해 목적지를 제한하고, 수신과 송신을 따로 검토해야 한다. 에이전트 접근 기능의 현재 네트워크 제약도 도입 시 반드시 시험해야 한다. 출처: Network Isolation – Amazon WorkSpaces Applications, Learn more about agents accessing WorkSpaces

관찰 가능성: ‘무엇을 봤고 왜 눌렀는가’를 연결하라

운영 로그는 모델 요청, 계획, MCP 도구 호출, 화면 캡처, 입력 이벤트, 애플리케이션의 최종 상태를 하나의 상관관계 ID로 연결해야 한다. CloudTrail 이벤트만으로는 모델이 왜 행동했는지 알기 어렵고, 스크린샷만으로는 어떤 호출과 권한이 사용됐는지 알기 어렵다. 반대로 추론 로그를 모두 저장하면 민감 데이터가 재노출될 수 있다. 필요한 증거 수준과 보존 기간을 업무 위험도에 따라 차등화해야 한다.

중단과 복구: 정지 버튼 이후를 설계하라

세션을 멈추는 것과 업무를 복구하는 것은 다르다. 에이전트가 송장 100건 중 57건을 처리한 뒤 멈췄다면, 완료된 항목과 미완료 항목을 구분하고 중복 실행을 막아야 한다. 각 작업에 멱등성 키나 체크포인트를 두고, 변경 전후 값을 기록하며, 되돌릴 수 없는 단계 전에 승인을 요구해야 한다. 자동 재시도는 조회나 일시적 네트워크 오류에는 유효하지만, 결제·삭제·전송 같은 상태 변경에는 중복 피해를 낼 수 있다.

실무 적용은 ‘업무 한 건의 위험 모델’에서 시작해야 한다

가상 데스크톱을 먼저 구매하고 적용 업무를 찾는 순서는 적절하지 않다. 한 개 프로세스를 선택해 아래처럼 실행 경로와 실패 영향을 분석해야 한다.

시나리오 1: 레거시 ERP 월말 입력

• 상황: API가 없는 Windows ERP에 승인된 집계값을 입력한다.
• 입력: 결재가 끝난 정형 파일과 대상 회계 기간.
• 실행: 파일 검증은 구조화된 도구로 처리하고, ERP 로그인과 메뉴 이동, 최종 입력만 데스크톱 세션에서 수행한다.
• 출력: 처리 번호, 입력 전후 화면, 성공·실패 항목 목록.
• 주의점: 금액과 회계 기간을 입력 직전 다시 비교하고, 최종 확정은 인간 승인을 거친다. 재실행 시 중복 전표를 막는 식별자가 필요하다.

시나리오 2: 고객지원 백오피스 갱신

• 상황: 여러 웹 화면에 흩어진 배송 상태를 확인해 고객 레코드에 반영한다.
• 입력: 고객 요청 번호와 읽기 전용 조회 결과.
• 실행: 조회 가능한 시스템은 API로 우선 확인하고, API가 없는 백오피스의 상태 필드만 화면에서 변경한다.
• 출력: 변경 필드, 이전 값, 새 값, 근거 링크와 세션 기록.
• 주의점: 환불·계정 폐쇄 같은 고위험 메뉴는 계정 권한에서 제거한다. 고객 개인정보가 담긴 스크린샷의 보존 정책을 별도로 둔다.

시나리오 3: 사내망 전용 보고서 수집

• 상황: 사내망에서만 실행되는 클라이언트로 보고서를 내려받아 분석 파이프라인에 전달한다.
• 입력: 보고 기간과 승인된 보고서 종류.
• 실행: 격리 세션에서 보고서를 생성하고 허용된 저장소로만 이동한다. 이후 분석은 별도 환경에서 수행한다.
• 출력: 원본 파일의 해시, 생성 시각, 전달 상태.
• 주의점: 세션의 외부 인터넷 접근을 막고, 파일 형식과 크기, 악성 코드 검사를 통과한 산출물만 반출한다.

이 세 사례의 공통점은 에이전트에게 넓은 목표만 주지 않는다는 것이다. 입력 계약, 허용 도구, 성공 조건, 중단 조건, 증거, 승인 지점을 먼저 정의한다. 이것이 PoC의 시연 성공을 운영 가능성으로 바꾸는 작업이다.

CTO와 아키텍트가 도입 전에 답해야 할 질문

앞서 다룬 신원·최소 권한·네트워크·관찰 가능성·중단·복구 원칙을 다시 풀어 설명하는 대신, 도입 검토 단계에서 실제로 확인할 일곱 가지 질문으로 좁혀서 점검표처럼 쓰면 된다.

첫째, 정말 화면 조작이 필요한가. API·워크플로 엔진·MCP 도구로 더 안정적으로 처리할 수 있는 단계가 있는지 먼저 분리한다.

둘째, 세션의 격리 단위는 무엇인가. 에이전트·업무·고객별로 세션을 나누고, 서로 다른 데이터 등급과 부서 권한을 같은 이미지·계정에 섞지 않는다. 한 세션에 한 에이전트만 연결된다는 제품 제한도 처리량·비용 산정에 반영한다. 출처: Learn more about agents accessing WorkSpaces

셋째, 권한의 발급·회수 소유자는 누구인가. IAM, 애플리케이션 계정, 비밀, 네트워크 허용 목록의 소유자를 정하고 정기적으로 재검토한다.

넷째, 성공을 어떻게 판정하는가. 화면의 ‘완료’ 표시로 끝내지 말고, 대상 시스템 상태를 다시 조회해 기대값과 비교한다.

다섯째, 인간 승인은 어디에서 요구하는가. 금액, 고객 수, 데이터 민감도, 되돌릴 수 있는지 여부에 따라 승인 기준을 계층화한다.

여섯째, 감사 자료는 충분하면서 과도하지 않은가. CloudTrail·CloudWatch·스크린샷·애플리케이션 로그를 하나의 사건 타임라인으로 연결하되, 보존 종료 시 삭제한다. 출처: Learn more about agents accessing WorkSpaces

일곱째, 실패 후 재개와 책임은 누구에게 있는가. 세션 중단, 모델 오류, UI 변경, 계정 잠금, 부분 완료를 각각 운영 절차로 만들고, 업무 소유자와 운영 책임자를 지정한다.

이번 발표를 어떻게 해석해야 하는가

WorkSpaces for AI agents의 정식 출시는 기업 AI 경쟁이 모델 계층에만 머물지 않는다는 신호다. 클라우드 사업자가 에이전트의 데스크톱 실행, 도구 연결, 화면 입력과 관찰, 세션 모니터링을 별도 제품 경험으로 묶었다는 점은 실제 시스템에서 행동하는 AI가 새로운 인프라 수요를 만들 가능성을 보여준다. 프리뷰 발표 뒤 정식 출시로 이어졌다는 사실도 AWS가 이를 독립된 사용 사례로 다루고 있음을 나타낸다. 출처: Amazon WorkSpaces now lets AI agents operate desktop applications (Preview), Announcing general availability of Amazon WorkSpaces for AI agents

다만 단일 제품의 출시를 산업 표준의 확정으로 읽어서는 안 된다. 모든 에이전트에 가상 데스크톱 한 대가 필요한 것도 아니다. API 중심으로 현대화된 기업에서는 구조화된 호출이 더 효율적이고 검증 가능하다. GUI 기반 실행은 화면 변화에 취약하고, 세션 비용과 이미지 관리, 패치, 처리량, 증거 보관이라는 운영 부담을 추가한다. 현재 제품 제약도 아키텍처 선택에 영향을 준다.

더 정확한 해석은 이렇다. 기업 자동화의 병목이 ‘모델이 업무를 이해하는가’에서 ‘그 판단을 기존 시스템 안에서 얼마나 안전하게 실행할 수 있는가’로 이동하고 있다. WorkSpaces for AI agents는 그 문제에 대한 한 가지 관리형 접근이다. 향후 경쟁도 단순한 모델 정확도뿐 아니라 신원 연결, 정책 집행, 세션 격리, 관찰 가능성, 인간 개입, 실패 복구를 얼마나 일관되게 제공하는지로 넓어질 가능성이 있다.

결론: 모델 선정표 옆에 실행 통제표를 놓아야 한다

기업이 에이전트 도입을 챗봇 PoC의 연장으로 보면 가장 중요한 질문을 놓친다. 모델이 좋은 답을 내는지 시험하는 것과 운영 시스템의 상태를 바꾸도록 허용하는 것은 다른 수준의 결정이다. 후자는 보안 아키텍처이자 업무 통제 설계이며, 장애 복구와 감사의 문제다.

실무자는 “어떤 모델을 쓸 것인가”와 동시에 물어야 한다. 에이전트는 어디에서 실행되는가. 어떤 애플리케이션과 데이터에 접근하는가. 자격 증명은 어떻게 발급·회수되는가. 읽기와 쓰기, 승인 권한은 분리됐는가. 화면과 도구 호출을 연결해 추적할 수 있는가. 잘못된 행동을 누가, 어떤 신호로 멈추는가. 부분 완료된 업무는 어떻게 복구하는가.

AWS WorkSpaces for AI agents의 의미는 AI가 인간과 같은 직원이 됐다는 데 있지 않다. 기업이 관리해야 할 컴퓨팅 주체가 하나 더 생기고 있으며, 그 주체의 행동을 담을 실행 환경과 통제 경계가 필요해졌다는 데 있다. API가 가능한 곳에서는 API를 우선하고, 화면이 유일한 인터페이스인 곳에서는 격리된 데스크톱을 신중하게 사용해야 한다.

AI 에이전트의 실무 경쟁력은 얼마나 똑똑하게 생각하는지만으로 결정되지 않는다. 기업 안에서 어디까지 접근하고, 어떻게 행동하며, 그 행동을 얼마나 안전하게 통제할 수 있는지가 실제 자동화의 성패를 가를 수 있다.

참고 출처

• Announcing general availability of Amazon WorkSpaces for AI agents
• Amazon WorkSpaces now lets AI agents operate desktop applications (Preview)
• Secure Desktops for AI Agents – Amazon WorkSpaces
• Provide agents access to WorkSpaces
• Learn more about agents accessing WorkSpaces
• Virtual Desktop Infrastructure – Amazon WorkSpaces
• Network Isolation – Amazon WorkSpaces Applications
• Security in Amazon WorkSpaces