Cloudflare Kitesurf란? AI 에이전트 브라우저 런타임의 3가지 혁신세션

AI 에이전트가 웹사이트를 검색하는 수준을 넘어 로그인하고, 폼을 작성하고, 파일을 업로드하며, 결제 직전까지 업무를 수행한다면 가장 먼저 필요한 것은 무엇일까요?

더 큰 모델, 더 긴 컨텍스트, 더 정교한 프롬프트일 수도 있습니다. 하지만 실제 운영 환경에서는 다른 문제가 먼저 등장합니다. Agent가 웹을 안정적으로 열고, 페이지를 이해하고, 필요한 행동을 끝까지 실행할 수 있는가라는 문제입니다.

사람에게 브라우저는 단순한 창입니다. 반면 AI Agent에게 브라우저는 외부 세계와 연결되는 실행 환경입니다. 웹페이지를 불러오고, 자바스크립트를 실행하고, 동적으로 바뀌는 화면을 해석하며, 버튼 클릭·입력·다운로드 같은 행동을 수행하는 장소이기 때문입니다.

기존에는 이러한 작업을 위해 Chromium 기반의 헤드리스 브라우저와 Playwright 같은 자동화 도구를 조합하는 방식이 일반적이었습니다. 다만 Agent를 수십 개, 수백 개 단위로 병렬 운영하려 하면 브라우저의 CPU·메모리 사용량이 곧 비용과 확장성의 병목이 됩니다. 웹 자동화가 늘어날수록 “모델 추론 비용”만큼이나 “브라우저 실행 비용”이 중요해지는 이유입니다.

이 지점에서 Cloudflare의 Kitesurf는 흥미로운 방향을 제시합니다. Kitesurf는 사람이 사용하는 범용 브라우저가 아니라, AI Agent의 웹 작업을 위해 설계된 브라우저 런타임입니다. Cloudflare Workers 기반의 에지 환경에서 동작하도록 설계됐으며, Chromium 기반 브라우저보다 CPU와 메모리 사용량을 약 3~7배 줄이는 것을 목표로 합니다.

핵심은 단순한 경량화가 아닙니다. 가벼운 런타임은 Agent가 더 많은 웹 작업을 동시에 수행할 수 있게 만들고, 장시간 실행되는 자동화 워크플로우의 운영 부담도 낮춥니다. 동시에 Kitesurf는 23만 5,000개 이상의 웹 플랫폼 테스트를 통과한 호환성을 내세웁니다. 이는 현대적인 SPA, 복잡한 프론트엔드 프레임워크, 다양한 웹 API가 사용되는 실제 서비스에서도 Agent가 행동할 기반을 확보하려는 접근입니다.

Agent의 경쟁력은 “무엇을 생각하는가”뿐 아니라 “생각한 일을 어디에서, 얼마나 안정적으로 실행하는가”에서 결정됩니다.

이 변화는 에이전트 아키텍처의 역할 분담을 더욱 분명하게 만듭니다.

• LLM과 플래너는 목표를 해석하고 다음 행동을 결정합니다.
• 그래프 기반 프레임워크는 작업 순서, 상태, 예외 처리, 인간 승인을 관리합니다.
• 브라우저 런타임은 실제 웹에서 클릭하고 입력하며 결과를 가져옵니다.
• 거버넌스 체계는 고위험 행동을 통제하고, 로그와 승인 기록을 남깁니다.

예를 들어 가격 모니터링 Agent를 생각해 볼 수 있습니다. 단순한 경우에는 웹페이지를 읽고 가격 변동을 요약하면 됩니다. 하지만 업무가 고도화되면 경쟁사 포털에 로그인하고, 특정 조건을 확인하고, 내부 시스템에 보고서를 등록해야 할 수 있습니다. 더 나아가 광고 예산 변경이나 주문 발주처럼 금전적·운영상 영향이 큰 행동도 요청될 수 있습니다.

이때 중요한 것은 Agent에게 무제한 권한을 주는 일이 아닙니다. 정보 수집과 분석은 자동으로 처리하되, 결제·배포·권한 변경 같은 행동 직전에는 사람의 승인을 거치게 해야 합니다. 즉, 웹 실행 환경의 효율성과 승인 기반의 통제 구조가 함께 설계되어야 합니다.

Kitesurf 같은 전용 런타임이 주목받는 이유도 여기에 있습니다. 이제 Agent는 채팅창 안에서 답변을 생성하는 도구를 넘어, 실제 웹 환경에서 업무를 수행하는 디지털 실행 주체가 되고 있습니다. 그리고 세상을 움직이는 Agent를 만들기 위해서는 더 똑똑한 두뇌만큼, 그 두뇌가 안전하고 효율적으로 행동할 수 있는 브라우저가 필요합니다.

Agent 시대, 3~7배 가벼운 실행 환경의 의미

에이전트 한 개가 웹페이지를 열고 정보를 확인하는 일은 큰 부담처럼 보이지 않습니다. 하지만 수십 개, 수백 개의 Agent가 동시에 검색하고, 대시보드를 읽고, 폼을 입력하고, 결과를 검증해야 한다면 이야기가 달라집니다. 이때 브라우저의 작은 자원 차이는 곧 서버 비용, 처리 속도, 그리고 자동화 규모의 차이로 이어집니다.

Cloudflare Kitesurf는 바로 이 문제를 겨냥합니다. 기존 Chromium 기반 브라우저보다 CPU와 메모리 사용량을 약 3~7배 낮추도록 설계된 AI 에이전트 전용 브라우저 런타임입니다. 단순히 “더 가벼운 브라우저”가 아니라, 대규모 Agent 운영을 전제로 웹 실행 환경 자체를 다시 설계했다는 점에 의미가 있습니다.

브라우저 비용은 Agent 수와 함께 급격히 커진다

일반적인 헤드리스 브라우저는 사람이 사용하는 웹을 거의 완전하게 재현하기 위해 많은 자원을 사용합니다. 렌더링 엔진, 자바스크립트 실행, 네트워크 처리, 탭과 세션 관리가 모두 필요하기 때문입니다.

문제는 Agent가 늘어날수록 이 비용이 거의 선형적으로 증가한다는 점입니다.

• Agent 1개가 브라우저 1개를 사용하고
• 각 Agent가 여러 웹페이지를 탐색하며
• 작업이 길어질수록 세션 유지 시간이 늘어나면

브라우저 인스턴스 자체가 인프라 비용의 중심이 될 수 있습니다. 특히 가격 모니터링, 시장 조사, 고객 지원 보조, 파트너 포털 관리처럼 반복적인 웹 작업을 자동화하는 경우, 모델 추론 비용만큼 브라우저 실행 비용도 중요해집니다.

Kitesurf의 경량성은 이 지점에서 실질적인 가치를 만듭니다. 동일한 서버 자원에서 더 많은 Agent를 실행하거나, 같은 규모의 작업을 더 적은 인프라로 처리할 여지가 생기기 때문입니다.

“가볍다”는 것은 단순한 비용 절감이 아니다

CPU와 메모리 사용량이 줄면 가장 먼저 보이는 효과는 비용 절감입니다. 그러나 운영 관점에서는 그보다 더 큰 변화가 뒤따릅니다.

운영 항목	경량 Agent 브라우저 런타임이 만드는 효과
동시 실행 수	같은 자원에서 더 많은 에이전트 세션 운영 가능
응답 지연	자원 경합이 줄어 작업 대기 시간 완화
인프라 비용	컴퓨팅·메모리 사용량 감소로 단위 작업 비용 절감
장애 격리	많은 작업을 작은 단위로 나누어 실행하기 쉬움
확장성	특정 시간대의 대량 작업을 더 유연하게 처리 가능

예를 들어 매일 수백 개 경쟁사 페이지를 확인해야 하는 운영 Agent를 생각해볼 수 있습니다. 기존 방식에서는 브라우저 인스턴스 수가 늘어날수록 서버 증설과 세션 관리 부담도 커집니다. 반면 더 가벼운 런타임을 사용하면 병렬 처리 규모를 높이면서도 시스템의 자원 압박을 낮출 수 있습니다.

이는 “자동화를 할 수 있는가”의 문제가 아니라, 자동화를 어느 수준까지 확장할 수 있는가의 문제입니다.

웹 호환성이 뒷받침되어야 경량화가 의미를 갖는다

가볍기만 한 런타임은 실무에서 한계가 있습니다. 오늘날 웹 서비스 대부분은 자바스크립트, 비동기 API 호출, 복잡한 SPA 구조, 동적 폼과 인증 흐름에 의존합니다. 따라서 Agent가 실제 업무를 수행하려면 단순 HTML 읽기를 넘어 현실적인 웹 호환성이 필요합니다.

Kitesurf가 235,000개 이상의 웹 플랫폼 테스트를 통과했다고 알려진 이유도 여기에 있습니다. 경량성을 확보하면서도 표준 웹 기능을 폭넓게 지원하려는 접근입니다. 즉, 단순한 스크래핑 도구가 아니라 다음과 같은 행동을 수행할 수 있는 실행 기반을 목표로 합니다.

• 동적 웹페이지 로드와 자바스크립트 실행
• 로그인 이후의 세션 기반 작업
• 검색, 스크롤, 클릭, 입력 같은 UI 상호작용
• 대시보드와 포털에서의 데이터 확인
• 웹 애플리케이션 기반의 반복 업무 자동화

결국 Agent 환경에서 중요한 것은 “브라우저를 띄울 수 있는가”가 아닙니다. 낮은 비용으로 충분한 웹 호환성을 유지하면서, 얼마나 많은 작업을 안정적으로 병렬 처리할 수 있는가가 핵심입니다.

대규모 Agent 운영의 기본 단위가 바뀐다

과거 웹 자동화는 소수의 봇이 정해진 절차를 반복하는 구조에 가까웠습니다. 이제는 조사 담당 Agent, 검증 Agent, 실행 Agent, 감독 Agent가 역할을 나누고 동시에 움직이는 구조가 현실적인 선택지가 되고 있습니다.

이런 환경에서는 브라우저가 더 이상 부수적인 도구가 아닙니다. Agent가 외부 세계와 접촉하는 핵심 실행 레이어입니다. Kitesurf처럼 자원 효율을 우선하는 런타임은 대규모 웹 자동화의 경제성을 높이고, 더 많은 업무를 Agent 기반으로 전환할 수 있는 기반이 됩니다.

한마디로 3~7배의 자원 절감은 숫자 이상의 의미를 가집니다. 그것은 하나의 Agent를 더 빠르게 실행하는 기술이 아니라, 수백 개의 Agent가 실제 웹에서 일할 수 있게 만드는 확장성의 조건입니다.

Agent를 위한 235,000개의 테스트가 말하는 웹 호환성

가벼운 브라우저 런타임은 흔히 “기능이 제한적일 것”이라는 의심을 받습니다. 특히 JavaScript가 복잡하게 얽힌 SPA, 실시간 데이터가 갱신되는 대시보드, 동적으로 생성되는 폼을 다뤄야 하는 Agent라면 더 그렇습니다. 페이지를 열 수는 있어도, 실제 업무 흐름을 끝까지 수행하지 못한다면 자동화 가치가 크게 떨어지기 때문입니다.

Kitesurf는 이 질문에 235,000개 이상의 웹 플랫폼 테스트 통과라는 수치로 답합니다. 이는 단순히 HTML을 렌더링하는 수준을 넘어, 현대 웹 서비스가 의존하는 폭넓은 표준 웹 기능과의 호환성을 목표로 했다는 의미입니다.

웹 호환성이 Agent 자동화의 성패를 가르는 이유

오늘날 업무용 웹 서비스는 정적인 문서가 아닙니다. 대부분의 SaaS와 내부 운영 도구는 다음과 같은 구조를 사용합니다.

• React, Vue, Angular 기반의 SPA
• JavaScript로 비동기 데이터를 불러오는 화면
• 동적으로 활성화되는 버튼과 입력 폼
• 사용자 행동에 따라 바뀌는 DOM 구조
• 브라우저 API, 세션, 쿠키, 인증 흐름에 의존하는 서비스

이 환경에서 Agent는 단순히 페이지 내용을 읽는 데 그치지 않습니다. 검색 조건을 입력하고, 필터를 적용하고, 대시보드의 수치를 확인하며, 필요한 경우 보고서 다운로드나 폼 제출까지 수행해야 합니다.

따라서 브라우저 런타임의 호환성은 곧 Agent의 실행 성공률과 연결됩니다. 특정 웹 API가 빠져 있거나 JavaScript 실행이 불완전하면, 자동화 워크플로우는 사소한 화면 변화에도 멈출 수 있습니다.

235,000개 테스트가 의미하는 것

Kitesurf가 통과했다고 밝힌 235,000개 이상의 웹 플랫폼 테스트는 경량화와 호환성이 반드시 상충할 필요는 없다는 메시지를 담고 있습니다. 일반적으로 브라우저를 가볍게 만들수록 기능을 줄이기 쉽지만, Kitesurf는 AI Agent가 실제 웹에서 행동할 수 있도록 표준 웹 기능 지원 범위를 넓히는 방향을 택했습니다.

이 특성은 특히 다음과 같은 환경에서 중요합니다.

Agent 활용 환경	필요한 웹 호환성
경쟁사·시장 리서치	동적 페이지 로드, 무한 스크롤, 검색·필터 기능
운영 대시보드 자동화	JavaScript 기반 차트, 실시간 데이터 갱신, 인증 세션
파트너 포털 업무	폼 입력, 파일 업로드·다운로드, 다단계 화면 전환
SaaS 기반 RPA	SPA 라우팅, 모달 창, 동적 DOM 요소 제어

예를 들어, Agent가 가격 모니터링 업무를 수행한다고 가정해 보겠습니다. 단순한 웹 크롤러라면 페이지의 초기 HTML만 읽을 수 있습니다. 반면 실제 가격 정보가 JavaScript 실행 이후에 표시되거나, 국가·통화·상품 옵션을 선택해야 나타난다면 브라우저 수준의 상호작용이 필요합니다.

Kitesurf의 호환성 목표는 바로 이런 간극을 줄이는 데 있습니다. 웹사이트가 사람을 위해 만든 인터페이스를 Agent도 보다 안정적으로 이해하고 조작할 수 있게 만드는 것입니다.

경량성과 호환성을 함께 가져가는 구조

Kitesurf의 차별점은 Chromium 기반 브라우저보다 CPU와 메모리 사용량을 약 3~7배 줄이도록 설계됐다는 점입니다. 동시에 광범위한 웹 플랫폼 테스트를 통과하며, “가볍지만 실제 웹에서는 약한 런타임”이라는 기존 우려를 줄이려 합니다.

이 조합은 대규모 Agent 운영에서 특히 유리합니다.

• 여러 Agent가 동시에 웹 작업을 수행할 수 있습니다.
• 장시간 실행되는 리서치·모니터링 작업의 인프라 부담을 낮출 수 있습니다.
• 복잡한 SPA와 대시보드 기반 업무도 하나의 표준 런타임으로 통합할 수 있습니다.
• 브라우저 환경이 표준화되어 운영, 로깅, 보안 점검이 쉬워집니다.

물론 테스트 통과 수치가 모든 웹사이트에서의 완벽한 동작을 보장하는 것은 아닙니다. 사이트별 인증 정책, 봇 탐지, 비표준 구현, 외부 플러그인 등은 별도의 검증이 필요합니다. 그럼에도 235,000개 이상의 테스트는 Kitesurf가 단순한 경량 헤드리스 도구가 아니라, 실제 Agent 워크플로우를 위한 웹 실행 기반을 지향한다는 강력한 신호입니다.

결국 핵심은 분명합니다. Agent가 웹에서 안정적으로 일하려면 똑똑한 모델만으로는 부족합니다. 복잡한 웹 표준과 동적 인터페이스를 감당할 수 있는, 가볍고 호환성 높은 런타임이 함께 필요합니다.

Agent의 두뇌와 Kitesurf의 손, 그리고 인간의 브레이크

에이전트가 웹에서 자유롭게 행동할수록 생산성은 커집니다. 검색 결과를 비교하고, 대시보드에서 데이터를 내려받고, 파트너 포털에 정보를 입력하는 작업까지 사람의 개입 없이 처리할 수 있기 때문입니다. 하지만 자율성이 커진 만큼 실수와 공격의 반경도 함께 넓어집니다.

잘못된 대상에게 폼을 제출하거나, 의도하지 않은 파일을 업로드하거나, 악성 웹페이지의 지시를 신뢰하는 순간 Agent는 단순한 자동화 도구가 아니라 실제 비즈니스 리스크가 됩니다. 그래서 2026년의 핵심은 “더 자율적인 에이전트” 자체가 아닙니다. 에이전트가 어디까지 행동할 수 있고, 누가 언제 멈출 수 있는지를 먼저 설계하는 통제 구조입니다.

두뇌: 무엇을 할지 결정하는 그래프 기반 Agent

에이전트의 두뇌는 LLM 하나로 완성되지 않습니다. 실제 운영 환경에서는 작업을 단계별 그래프로 나누고, 각 단계의 입력·출력·분기 조건을 관리해야 합니다.

예를 들어 경쟁사 가격을 조사하는 Agent라면 다음과 같은 흐름을 가질 수 있습니다.

대상 목록 확인
→ 웹사이트 접속
→ 가격 정보 추출
→ 이상치 검증
→ 보고서 초안 생성
→ 담당자 승인
→ 최종 공유

LangGraph, Microsoft Agent Framework, Google ADK, Amazon Bedrock AgentCore 같은 프레임워크는 이러한 실행 흐름을 그래프로 정의하는 데 초점을 둡니다. 특히 중요한 것은 human-in-the-loop, 즉 인간 승인 노드입니다.

정보를 읽고 요약하는 단계는 자동화할 수 있습니다. 반면 외부 시스템에 변경을 가하거나, 계약·결제·권한과 관련된 행동을 수행하는 단계는 사람의 확인을 거치게 해야 합니다. 에이전트의 판단 능력이 높아져도, 책임이 필요한 결정까지 자동으로 넘기는 것은 별개의 문제입니다.

손: 웹에서 실제 행동하는 Kitesurf

그래프 기반 프레임워크가 Agent에게 “무엇을 할지” 지시한다면, Kitesurf는 “웹에서 어떻게 행동할지”를 담당합니다.

Cloudflare Kitesurf는 AI 에이전트용으로 설계된 브라우저 런타임입니다. 사람을 위한 일반 브라우저가 아니라, 에이전트가 페이지를 열고, DOM을 읽고, 스크롤하고, 버튼을 클릭하고, 폼을 입력하는 실행 환경에 집중합니다. Workers 기반 에지 환경에서 동작하도록 설계됐으며, 기존 Chromium 기반 브라우저 대비 CPU와 메모리 사용량을 약 3~7배 줄이는 것을 목표로 합니다.

이 경량성은 단순한 비용 절감 이상의 의미를 가집니다. 기존 방식에서는 브라우저 하나를 띄우는 비용이 커서 병렬 작업 수를 쉽게 늘리기 어려웠습니다. 반면 가벼운 런타임을 활용하면 여러 Agent가 동시에 리서치, 모니터링, 운영 업무를 수행하는 구조를 설계하기 쉬워집니다.

또한 Kitesurf는 235,000개 이상의 웹 플랫폼 테스트를 통과한 것으로 알려져 있습니다. 이는 단순한 정적 페이지뿐 아니라 자바스크립트 기반 SPA, 복잡한 프론트엔드 프레임워크, 다양한 웹 API 환경에서도 동작할 수 있도록 웹 호환성을 강화하려는 방향으로 해석할 수 있습니다.

브레이크: 인간 승인과 런타임 정책을 분리해야 한다

중요한 원칙은 하나입니다. 판단, 실행, 승인을 한 계층에 몰아넣지 않는 것입니다.

• Agent 프레임워크는 작업 순서와 조건을 관리합니다.
• Kitesurf 같은 브라우저 런타임은 웹 상의 실제 조작을 수행합니다.
• 인간 승인 체계는 위험한 행동을 멈추거나 허용합니다.
• 로깅·감사 시스템은 누가, 어떤 근거로, 어떤 웹 액션을 실행했는지 남깁니다.

이 분리는 보안과 운영 양쪽에서 중요합니다. 예를 들어 Agent가 “가격 데이터를 수집하라”는 업무를 수행하는 것은 비교적 낮은 위험의 작업일 수 있습니다. 그러나 “관리자 페이지에 접속해 가격을 변경하라”는 명령은 전혀 다른 수준의 통제가 필요합니다.

따라서 다음과 같이 위험도별 권한을 나누는 설계가 현실적입니다.

행동 유형	예시	권장 통제 방식
읽기 중심 작업	검색, 페이지 분석, 가격 모니터링	자동 실행 및 로그 기록
제한적 입력 작업	문의 초안 작성, 내부 시스템 임시 저장	정책 검증 후 실행
외부 영향 작업	폼 제출, 파일 업로드, 게시물 발행	사전 승인 또는 2단계 확인
고위험 작업	결제, 권한 변경, 배포, 계정 설정 수정	인간의 명시적 승인 필수

이때 승인 단계는 단순한 “확인 버튼”이어서는 안 됩니다. 승인자는 Agent가 무엇을 하려는지, 대상 웹사이트가 어디인지, 입력·업로드할 데이터가 무엇인지, 실행 결과가 어떤 영향을 낼지를 확인할 수 있어야 합니다.

자율성은 권한이 아니라 조건부 능력이다

최근 강화되는 AI 안전성과 규제 환경은 Agent 설계 방식에도 변화를 요구합니다. 특히 위험 관리, 인간 감독, 투명성, 감사 가능성이 중요해지면서 “에이전트가 할 수 있는 일”보다 “에이전트가 허용된 조건에서만 하도록 보장하는 방법”이 핵심 경쟁력이 되고 있습니다.

Kitesurf는 이 구조에서 웹 실행 계층을 표준화할 수 있는 후보입니다. 조직은 다양한 헤드리스 브라우저와 개별 자동화 스크립트를 무분별하게 운영하는 대신, 웹 액션을 상대적으로 일관된 런타임에 집중할 수 있습니다. 그 결과 자원 사용량을 관리하고, 실행 정책을 적용하며, 웹 상호작용 로그를 수집하기가 쉬워집니다.

결국 2026년형 Agent 스택은 다음과 같은 역할 분담으로 이해할 수 있습니다.

두뇌는 계획하고, 손은 실행하며, 인간은 멈출 수 있어야 합니다.

에이전트의 성과는 얼마나 많은 일을 자동화했는지가 아니라, 자동화된 행동을 얼마나 안전하고 추적 가능하게 운영했는지로 평가받게 될 것입니다.

Agent가 이끄는 RPA 2.0의 도착과 도입 조건

가격을 감시하고, 파트너 포털을 업데이트하고, 경쟁사 변화를 추적하는 일을 사람이 반복하지 않아도 된다면 조직의 업무 방식은 어떻게 달라질까요?

단순히 시간을 절약하는 수준을 넘어, 팀은 데이터를 찾고 화면을 옮겨 다니는 업무 대신 판단·전략·예외 처리에 더 집중할 수 있습니다. 이것이 AI Agent와 경량 브라우저 런타임이 결합한 RPA 2.0의 핵심입니다.

기존 RPA가 정해진 화면, 고정된 좌표, 반복 규칙에 의존했다면, RPA 2.0은 웹 페이지의 맥락을 이해하고 변화하는 화면에 대응하는 Agent 중심 자동화에 가깝습니다. 동적인 SPA 대시보드, 로그인 기반 파트너 포털, 복잡한 검색 결과처럼 기존 자동화가 취약했던 환경에서도 활용 가능성이 커집니다.

기존 RPA와 Agent 기반 RPA 2.0의 차이

기존 RPA는 “어디를 클릭하고 무엇을 입력할지”를 사람이 세밀하게 지정해야 했습니다. 화면 구조가 조금만 바뀌어도 봇이 멈추고, 유지보수 비용이 빠르게 증가하는 문제가 있었습니다.

반면 Agent 기반 RPA 2.0은 목표 중심으로 작동합니다. 예를 들어 “경쟁사 가격 변동을 매일 확인하고, 기준 이상 변하면 담당자에게 보고하라”는 업무를 다음과 같은 흐름으로 수행할 수 있습니다.

1. 웹사이트에 접속해 대상 상품을 탐색합니다.
2. 가격, 재고, 프로모션 문구를 수집합니다.
3. 이전 데이터와 비교해 변화를 판단합니다.
4. 기준을 충족하면 보고서를 작성합니다.
5. 담당자의 승인을 받은 뒤 알림, 등록 또는 후속 조치를 실행합니다.

이때 그래프 기반 Agent 프레임워크는 업무 순서와 예외 처리를 관리하고, Kitesurf 같은 에이전트 전용 브라우저 런타임은 실제 웹페이지 로드, 스크롤, 클릭, 폼 입력 같은 실행을 담당하는 구조가 자연스럽습니다.

먼저 자동화할 업무는 무엇인가

도입 초기에는 모든 업무를 자동화하려 하기보다, 반복 빈도는 높지만 위험도는 낮은 작업부터 선택하는 편이 좋습니다. 대표적인 후보는 다음과 같습니다.

• 가격·재고 모니터링: 경쟁사 가격, 상품 재고, 할인 이벤트 변화를 정기적으로 추적
• 파트너 포털 운영: 정형화된 정보 입력, 상태 확인, 파일 다운로드·업로드
• 운영 데이터 수집: 여러 웹 대시보드에서 지표를 수집해 보고서 초안 생성
• 리드·문의 분류: 웹 폼 또는 CRM 화면의 신규 요청을 확인하고 담당 부서로 배정
• 컴플라이언스 점검 보조: 공개 정보의 변경 사항을 수집하고 검토 대상 표시

반대로 결제 실행, 권한 변경, 외부 공개, 계약 체결, 배포 작업처럼 영향이 큰 업무는 완전 자동화 대상으로 두기보다 반드시 승인 단계를 포함해야 합니다.

성공적인 Agent 자동화의 조건

성공적인 자동화는 Agent를 곧바로 풀어놓는 데서 시작되지 않습니다. 중요한 것은 업무 경계, 승인 기준, 실행 기록을 먼저 설계하는 일입니다.

명확한 업무 범위

Agent가 접근할 사이트, 수행할 액션, 사용할 계정, 처리 가능한 데이터 범위를 사전에 제한해야 합니다. “웹에서 필요한 일을 처리하라”는 식의 넓은 지시는 예외 상황과 보안 위험을 키웁니다.

예를 들어 파트너 포털 자동화라면 다음처럼 범위를 구체화할 수 있습니다.

• 허용된 특정 포털에서만 실행
• 지정된 상품 정보만 수정
• 저장 전 변경 내역 검증
• 최종 등록은 담당자 승인 후 실행
• 오류 또는 예상 밖의 화면은 즉시 중단하고 보고

Human-in-the-Loop 승인

RPA 2.0의 핵심은 무인 실행 자체가 아니라, 필요한 순간에 사람의 판단을 연결하는 것입니다. 그래프 기반 워크플로우에서 고위험 단계 앞에 승인 노드를 배치하면 자동화 속도와 통제력을 함께 확보할 수 있습니다.

예를 들어 가격 변경 제안, 고객 메시지 발송, 대량 데이터 업로드는 Agent가 초안을 만들고 근거를 제시하되, 실제 실행은 담당자가 승인한 뒤에만 이루어지도록 설계할 수 있습니다.

표준화된 웹 실행 환경

웹 자동화가 늘어날수록 브라우저 운영 비용과 관리 복잡도도 커집니다. 이때 Kitesurf처럼 AI Agent의 웹 작업에 맞춰 설계된 경량 런타임은 중요한 인프라 선택지가 됩니다.

Cloudflare는 Kitesurf가 Chromium 기반 브라우저 대비 CPU와 메모리 사용량을 약 3~7배 줄이도록 설계됐다고 설명합니다. 또한 폭넓은 웹 플랫폼 테스트 통과를 통해 실제 웹 환경과의 호환성을 목표로 합니다. 수십 개 이상의 Agent가 동시에 웹을 탐색해야 하는 리서치, 운영, 모니터링 업무에서는 이런 경량성과 일관성이 특히 중요합니다.

감사 가능한 로그와 모니터링

자동화가 실제 업무를 수행한다면 “무엇을 했는가”를 나중에 확인할 수 있어야 합니다. 최소한 다음 정보는 통합적으로 기록하는 것이 바람직합니다.

• Agent의 요청 목적과 실행 계획
• 접근한 웹사이트와 사용한 도구
• 입력·조회·다운로드·업로드 등 주요 액션
• 승인 요청 및 승인자 기록
• 오류, 중단 사유, 재시도 결과
• 최종 산출물과 후속 조치

이러한 기록은 운영 개선뿐 아니라 인간 감독, 위험 관리, 투명성 요구가 강화되는 규제 환경에 대응하는 기반이 됩니다.

PoC는 작게, 운영 설계는 크게

가장 현실적인 접근은 제한된 업무로 PoC를 시작하는 것입니다. 예를 들어 한 개의 경쟁사 사이트에서 가격을 수집해 내부 슬랙 채널에 보고하는 워크플로우부터 검증할 수 있습니다.

이후 안정성이 확인되면 대상 사이트를 늘리고, 데이터 검증 규칙을 추가하며, 승인 단계와 감사 로그를 강화하는 방식으로 확장합니다. 중요한 것은 자동화 범위를 빠르게 넓히는 것이 아니라, 각 단계에서 성능·정확성·보안·책임 소재를 확인하는 것입니다.

RPA 2.0은 사람을 완전히 배제하는 기술이 아닙니다. 반복적인 웹 업무는 Agent와 런타임에 맡기고, 사람은 목표 설정과 예외 판단, 중요한 승인에 집중하도록 역할을 재설계하는 기술입니다. 결국 경쟁력은 더 많은 봇을 배치하는 조직이 아니라, 더 안전하게 일하는 Agent 시스템을 설계하는 조직에서 나올 것입니다.