데모라면 Agent 하나와 브라우저 창 하나로 충분합니다. 하지만 운영 환경에서 수십 개 작업을 동시에 돌리려면 환경을 분리해야 하며, 공유하면 로그인 상태가 섞이고 탭이 충돌하며 장애 원인 파악이 어려워집니다.
AI Agent가 무엇을 할 수 있는지 보여 주는 데는 브라우저 창 하나면 충분합니다. 하지만 실제 업무에 투입하면 요구사항은 곧 수십 개의 창으로 늘어나고, 서로 간섭하지 않아야 합니다. 원인은 Agent 자체가 아니라 그 아래에서 동작하는 브라우저 환경에 있습니다.
하나의 환경을 공유하면 어떤 문제가 생기는가
가장 눈에 띄는 문제는 Cookie와 로그인 상태가 서로 오염되는 것입니다. 같은 브라우저 데이터 디렉터리에서 두 작업이 서로 다른 계정에 차례로 로그인하면 뒤의 로그인이 앞선 작업의 세션을 덮어쓸 수 있습니다. 한 작업이 캐시를 지우면 다른 작업의 페이지 상태도 사라질 수 있습니다.
그다음은 리소스 경합입니다. 하나의 브라우저 인스턴스에서는 탭, 포커스, 다운로드 디렉터리, 팝업이 모두 공유 자원입니다. 두 작업이 동시에 새 탭을 열면 어느 작업이 어느 페이지를 조작하는지 불분명해집니다. 한 작업이 띄운 대화상자 때문에 다른 작업의 스크립트가 멈출 수도 있습니다. 로그인 상태 충돌, 데이터 덮어쓰기, 작업 간 간섭은 동시 실행 환경에서 거의 필연적으로 발생합니다.
세 번째 문제는 장애가 발생한 뒤에 나타납니다. 스크립트 로직이 잘못된 것인지, 아니면 특정 단계에서 다른 작업이 환경을 건드린 것인지 판단하기 어렵습니다. 여러 작업이 하나의 프로세스와 하나의 로그를 공유하면 장애 증상도 일관되지 않을 수 있어 문제 해결 비용이 크게 늘어납니다.
또 하나 덜 직관적인 위험이 있습니다. 여러 신원이 오랫동안 같은 환경에서 동작하면 서로 연관된 흔적을 남깁니다. 장치 파라미터, 저장소 상태, 네트워크 출구가 모두 같기 때문에 플랫폼은 이를 동일한 장치에서 수행되는 일괄 작업으로 보기 쉽습니다. 한 계정이 비정상으로 판단되면 다른 계정도 영향을 받을 수 있습니다.
창을 여러 개 여는 것만으로는 격리가 아니다
많은 사람이 처음 떠올리는 방법은 창을 여러 개 수동으로 여는 것입니다. 겉보기에는 분리되어 있지만 실제로는 같은 브라우저 프로필을 공유합니다. 즉 같은 Cookie, 같은 로컬 저장소, 같은 장치 정보를 사용합니다. 창끼리 서로의 로그인 상태를 볼 수 있고 한 창의 작업이 다른 창에 영향을 줄 수도 있습니다.
진정한 격리는 데이터 디렉터리와 환경 파라미터까지 분리해야 합니다. 각 환경에는 자체 저장소 디렉터리, 자체 장치 파라미터—해상도, 언어, 시간대, 글꼴, Canvas, WebGL 등—그리고 자체 네트워크 출구가 필요합니다. 이 세 가지 중 하나라도 빠지면 격리는 완전하지 않습니다. 환경을 분리해도 하나의 출구를 공유하면 연관성 판단은 여전히 작동할 수 있습니다.
격리에 드는 비용과 그 대가로 얻는 것
격리는 공짜가 아닙니다. 각 환경 뒤에는 독립된 브라우저 프로세스와 별도의 데이터 디렉터리가 있습니다. 환경 수가 늘어나면 메모리와 CPU가 먼저 압박을 받습니다. 한 대의 머신에서 수십 개 환경을 돌리려면 장애가 난 뒤 보완하기보다 사전에 남은 여유 자원을 계산하는 편이 일반적입니다.
조정할 수 있는 방법은 몇 가지가 있습니다. 자주 쓰지 않는 환경은 회수했다가 필요할 때 다시 시작하고, 작업 부하에 따라 여러 머신으로 분산해 한 대에 모두 몰아넣지 않으며, 환경마다 명확한 수명 주기를 정해 수백 개를 계속 켜 두지 않는 방식입니다. 작업 구조도 중요합니다. 같은 계정에서 순차적으로 실행되는 작업은 여러 환경으로 나눌 필요가 없으며, 분리해 봐야 리소스만 낭비됩니다.
반대편에는 이점이 있습니다. 격리를 제대로 구현하면 장애 양상이 안정됩니다. 문제가 특정 환경에 속한다는 점이 분명해지고 원인을 알 수 없는 현상이 아니게 됩니다. 규모가 커질수록 이러한 예측 가능성은 공유로 아끼는 소량의 리소스보다 훨씬 큰 가치를 가집니다.
규모가 커진 뒤 환경 계층에 있어야 할 세 가지
첫째는 일괄 스케줄링입니다. 환경은 컴퓨팅 리소스처럼 요청하고 해제할 수 있어야 하며, 필요 시 생성, 일괄 시작, 동시 실행 제어, 실패 재시도, 자동 회수를 지원해야 합니다. 스크립트 안에서 하나씩 만들고 하나씩 정리하는 방식이어서는 안 됩니다.
둘째는 독립적인 네트워크 출구입니다. 각 환경을 자체 출구에 연결하고, 출구 지역과 환경의 지리 파라미터가 일치하도록 해야 합니다. 놓치기 쉬운 항목이지만 전체 격리를 성립시키는 전제 조건입니다.
셋째는 조회 가능한 상태입니다. 어떤 환경이 실행 중인지, 어떤 환경이 비어 있는지, 어떤 환경에 이상이 있는지 언제든 알 수 있어야 합니다. Agent는 무인으로 동작하므로 상태를 조회할 수 없다면 문제가 생겼을 때 추측에 의존할 수밖에 없습니다.
이 세 가지를 스크립트 안에서 처리하는 것은 매우 번거롭습니다. 환경 수준의 저장소, 구성, 스케줄링이 필요하기 때문입니다. 여러 환경을 관리하는 일부 도구는 바로 이 계층에서 동작합니다. PurpleMark도 그중 하나로, 브라우저 환경을 격리 가능하고 일괄 스케줄링할 수 있으며 인터페이스로 호출 가능한 리소스로 만듭니다.
여러 환경이 필요하지 않은 경우
Agent가 하나의 계정만 낮은 빈도로 사용한다면 일반 브라우저로도 충분하고, 추가 격리는 유지보수 부담만 늘립니다. 그러나 다음 중 하나라도 해당한다면 환경 계층을 독립시킬 필요가 있습니다. 작업을 병렬로 실행해야 하는 경우, 여러 신원으로 같은 플랫폼에 접근해야 하는 경우, 로그인 상태를 장기간 유지해야 하는 경우, 또는 동시 실행 규모가 계속 커질 경우입니다.
이 상황들의 공통점은 같습니다. 문제는 Agent가 충분히 똑똑한지가 아니라, 그 아래 환경이 충분히 깨끗하고 분리되어 있는지입니다.
경계
어떤 방식을 선택하더라도 규칙상의 경계는 달라지지 않습니다. 각 플랫폼의 서비스 약관과 robots 규칙을 준수하고, 허위 신원 정보를 사용하지 않으며, 기술적 보호 조치를 우회하지 않고, 요청 빈도를 통제하며, 상대방 서비스의 정상 운영에 영향을 주지 않아야 합니다.
