Agent 자동화가 규모가 커지면서 갑자기 멈추거나 실패한다면 원인은 모델이나 스크립트가 아니라 브라우저 환경 계층에 있을 때가 많습니다. 이 글은 자주 나타나는 네 가지 실패 패턴과 관찰 가능한 징후, 대응하는 엔지니어링 방법을 설명합니다.
LangChain, AutoGen 또는 CrewAI로 Agent를 만들고 Playwright나 Puppeteer를 통해 웹사이트를 조작하게 하는 일 자체는 어렵지 않습니다. 어려운 점은 이를 지속적으로 안정되게 실행하는 것입니다.
처음 배포했을 때는 문제가 잘 보이지 않는 경우가 많습니다. 작업량이 늘어나면 이상 현상이 집중해서 나타납니다. 사이트가 작업을 차단하거나, 계정의 로그인 세션이 갑자기 만료되거나, 여러 Agents가 동시에 실행되면서 서로의 상태에 영향을 줍니다. 많은 경우 첫 반응은 코드를 다시 살펴보는 것이지만, 끝에 가서는 코드 자체에는 문제가 없다는 사실을 알게 됩니다.
문제는 브라우저 환경 계층에 있는 경우가 많습니다. 대량으로 실행하는 프로젝트에서는 실패 형태가 실제로 몇 가지 반복되는 패턴으로 모입니다. 이를 알아볼 수 있으면 대응 자체는 크게 복잡하지 않습니다.
환경이 준비되기 전에 실행하기
새로 만든 브라우저 환경을 첫 작업부터 바로 사용하면 로그인 실패, 페이지 요소의 불완전한 로딩, 첫 단계에서의 인증 요청이 흔히 발생합니다. 이유는 단순합니다. 이 환경에는 이전 방문 기록도, Cookie도, 브라우징 이력도 없습니다. 플랫폼 입장에서는 완전히 낯선 기기로 보이므로 신뢰 수준이 자연스럽게 낮습니다.
관찰 가능한 특징은 환경을 만든 직후 처음 몇 번의 작업에 실패가 집중된다는 점입니다. 같은 작업을 일정 기간 사용해 온 환경으로 옮기면 정상적으로 완료되는 경우가 많습니다.
적절한 방법은 환경 준비 상태를 명시적인 상태로 관리하고, 기본적으로 바로 사용할 수 있다고 가정하지 않는 것입니다. 환경을 만든 뒤에는 먼저 낮은 강도의 브라우징을 일정 기간 수행하게 하고 상태가 안정된 뒤 실제 작업을 배정합니다. 스케줄러도 환경을 받자마자 사용하는 것이 아니라 작업을 배포하기 전에 이 준비 상태를 확인해야 합니다.
여러 작업이 같은 환경을 놓고 경쟁하기
동시 실행 수가 늘어나면 가장 눈에 띄는 증상은 프로세스가 쌓이고 메모리가 소모되며 시스템이 느려지는 것입니다. 더 까다로운 것은 숨은 문제입니다. 두 작업이 같은 Cookie와 로컬 스토리지를 순서대로 사용하면서 A의 로그인 상태가 B의 상태를 밀어내고, 로그에서는 어떤 작업이 불규칙하게 가끔 실패하는 것처럼 보입니다. 원인을 찾기 어렵습니다.
이 경우 브라우저 환경을 할당하고 회수할 수 있는 리소스로 취급해야 합니다. 작업이 시작될 때 하나의 환경을 할당받고 종료되면 반납하며, 작업과 환경을 일대일로 연결합니다. 환경 간에는 저장소가 서로 보이지 않으므로 한 작업의 로그인 상태가 다른 작업으로 흘러가지 않습니다. 수십 개의 Agents를 병렬로 확장하면 “스크립트 안에서 브라우저 프로세스를 여러 개 직접 띄우는 방식”과의 차이가 매우 분명해집니다.
여러 계정을 다루는 시나리오라면 격리를 더 철저히 해야 합니다. 각 계정마다 고정된 환경을 사용하고, fingerprint 파라미터와 저장소가 다른 계정과 겹치지 않도록 합니다. PurpleMark는 계정과 환경이 안정적인 일대일 대응을 유지하도록 환경 격리와 중앙 스케줄링 계층을 제공합니다.
세션이 만료됐지만 아무도 알아채지 못하기
이 유형은 오류가 반드시 발생하지 않기 때문에 특히 놓치기 쉽습니다. 작업은 계속 실행되고 로그도 계속 출력되지만 실제로는 로그인 페이지나 빈 데이터가 반환됩니다. 결과가 데이터 파이프라인에 들어간 뒤에야 문제가 발견되어 downstream부터 거꾸로 추적해야 하므로 비용이 큽니다.
해결 방법은 로그인 상태를 명시적인 사전 조건으로 확인하는 것입니다. 작업 시작 전에 현재 세션이 여전히 유효한지 확인하고, 만료되었다면 잘못된 상태로 작업을 계속하지 말고 전체 로그인 절차를 수행합니다. 상태 자체는 환경 계층에 두어야 합니다. Cookie, 로컬 스토리지, 브라우징 이력을 환경에 저장하고 다시 시작할 때 완전히 복구하면 계정 작업마다 매번 초기화할 필요가 없습니다.
실무적인 경험 하나는 장기간 운영되는 계정에서 로그인 상태가 자주 바뀌는 것 자체가 플랫폼에는 비정상 신호로 보일 수 있고 추가 인증을 유발할 수 있다는 점입니다. 필요 없는 재로그인은 가능한 한 피하는 것이 좋습니다.
차단 한 번으로 전체 배치가 멈추기
또 다른 실패 유형은 갑자기 묶음으로 발생해 많은 작업이 동시에 결과를 내지 못하는 경우입니다. 사이트가 반드시 명확한 거절을 반환하는 것은 아닙니다. 오히려 축소된 콘텐츠나 빈 페이지를 돌려주고, Agent는 의미 없는 데이터를 가지고 계속 진행하다가 데이터 처리 단계에서야 문제가 드러나는 경우가 많습니다.
이런 상황에서는 먼저 차단과 일반적인 실패를 구분해야 합니다. 같은 환경 그룹이 비슷한 시간대에 동시에 이상해진다면 문제는 환경 계층에 있을 가능성이 높습니다. 계속 재시도하면 영향 범위만 넓어지므로 먼저 해당 환경들을 중지하고 격리한 뒤 트리거 원인을 조사해야 합니다.
흔한 트리거는 세 방향입니다. 여러 환경이 WebGL, Canvas, 글꼴 목록, 엔진 버전 등 거의 동일한 fingerprint 설정을 사용하는 경우, 출구 IP·시간대·언어가 서로 맞지 않는 경우(예: 미국 IP에 아시아 시간대), 그리고 동작 간격이 너무 규칙적이어서 리듬 자체가 특징이 되는 경우입니다. 설정의 일관성을 맞추고 실행 속도를 관리하며 환경 상태와 작업 결과를 모두 로그로 남겨야 대규모 실패 전에 징후를 확인할 수 있습니다.
이 계층을 별도로 분리하기
성숙한 프로젝트는 보통 브라우저 환경을 Agent에서 분리해 독립 계층으로 다룹니다. Agent는 계획과 의사결정을 담당하고, 환경 계층은 ID와 상태를 관리하며, 실행 계층은 기존처럼 Playwright나 Puppeteer를 사용합니다. 이렇게 분리하면 ID가 타당한지, 상태를 복구할 수 있는지, 작업 간 격리가 유지되는지를 관리할 명확한 위치가 생깁니다.
돌아보면 위 네 가지 실패 유형에는 공통점이 있습니다. 모두 모델 안에 있는 문제도, 스크립트 로직 안에 있는 문제도 아닙니다. 모델과 코드는 물론 계속 개선해야 하지만, 자동화가 장기간 안정적으로 실행될 수 있는지를 결정하는 것은 종종 더 아래에 있는 이 계층입니다.
본 내용은 기술 연구와 개발 실무 공유를 목적으로 합니다. 자동화는 합법적이고 규정을 준수하는 범위에서 사용해야 하며, 대상 플랫폼의 서비스 약관과 해당 지역의 법률 및 규정을 따라야 합니다.
