Agent가 판단하고 Playwright가 브라우저를 조작해도 환경 계층은 자주 간과됩니다. 장시간 데이터 수집 작업에서는 실패가 이 계층에 집중되는 경우가 많습니다.
Agent 프레임워크로 브라우저를 구동해 데이터를 수집할 때 구조는 보통 세 계층으로 나뉩니다. Agent가 계획하고 판단하며, Playwright가 클릭·입력·데이터 추출을 담당하고, 마지막으로 워크플로가 대상 사이트와 상호작용합니다. 짧은 작업은 대체로 매끄럽게 돌아가고 로컬 테스트도 통과합니다. 하지만 실행 시간이 길어지고 작업이 확장되면, 좀처럼 충분한 관심을 받지 못하던 곳, 즉 브라우저 환경에 실패가 집중되기 시작합니다.
실제 운영에서 겪은 문제를 되짚어 보면 환경 계층의 문제는 대략 세 가지 형태로 나뉩니다.
환경이 이상 상태로 판단되어 전체 파이프라인이 멈춘다
한 가지는 플랫폼이 환경 자체를 처리하는 경우입니다. 항상 명확한 차단으로 나타나는 것은 아니고, 단순화된 페이지를 반환하거나 결과가 비어 있거나 추가 인증을 요구하는 식의 성능 저하로 나타날 수 있습니다. 스크립트는 오류를 내지 않지만 가져온 데이터는 이미 의미가 없습니다. 그런데도 이후 단계는 그대로 실행되고, 잘못된 데이터가 최종 테이블까지 전달됩니다.
문제는 이런 환경을 여러 작업이 공유하는 경우가 많다는 점입니다. 환경 하나에 문제가 생기면 여기에 연결된 모든 작업이 멈출 수 있습니다. 원인이 스크립트에 있지 않으므로 재시도해도 해결되지 않습니다.
여러 작업이 한 환경에 몰리면 세션 상태가 섞인다
동시 실행 작업이 같은 브라우저 인스턴스를 공유하면 Cookie, localStorage, IndexedDB가 서로 덮어쓰면서 로그인 상태를 밀어낼 수 있습니다. 짧게 실행할 때는 드러나지 않지만 며칠 동안 돌리면 이유를 알기 어려운 재로그인 요청이 나타나기 시작합니다.
더 은밀한 드리프트도 있습니다. 오래 실행되는 브라우저에서는 캐시, 저장소, 심지어 WebGL 렌더링 상태까지 변화가 누적됩니다. 같은 환경이라도 오늘과 사흘 뒤의 특성이 달라질 수 있습니다. 많은 사람이 Cookie 만료라고 생각하지만 실제로는 환경 자체가 이전과 달라진 것입니다. 그래서 매번 새 브라우저를 띄우기보다 환경을 지속적이고 재사용 가능한 객체로 만드는 편이 더 효율적입니다.
체크포인트에서 재개할 때 기존 환경을 더 이상 사용할 수 없을 수 있다
데이터 수집 작업은 한 번에 끝나는 경우가 드뭅니다. 중단 후 체크포인트에서 재개하는 것은 흔하지만, 이때 작업이 쉽게 낭비됩니다. 스크립트를 다시 시작하면서 새 브라우저 인스턴스를 만들면 로그인 상태가 사라질 수 있고, 반대로 기존 환경을 계속 사용해도 플랫폼이 이미 표시한 상태라면 계속 돌릴수록 리소스만 소모하게 됩니다.
핵심은 재시도 횟수가 아니라 복구의 세분화 정도입니다. 작업이 어느 단계까지 진행됐는지, 어떤 데이터를 이미 가져왔는지, 어떤 환경을 사용했는지를 스크립트 외부에 기록하지 않으면 재시작할 때 처음부터 다시 할 수밖에 없습니다.
환경 계층에서 할 수 있는 대응
위 세 가지를 함께 보면 대응 방식도 세 가지로 정리할 수 있습니다.
작업별로 환경을 그룹화합니다. 여러 작업을 하나의 인스턴스에 몰아넣지 말고, 작업 하나에 환경 그룹 하나를 할당합니다. 그룹을 나누면 작업마다 네트워크 출구, 시간대, 언어를 각각 설정할 수 있습니다. 이런 파라미터를 따로 수동 지정하는 것보다 하나의 세트로 맞추는 편이 더 안정적입니다. 이런 구조에서 PurpleMark는 환경 계층을 담당합니다. 브라우저 환경을 일괄 생성하고, 각 환경에 독립적인 네트워크 출구를 연결한 다음 API를 통해 작업 오케스트레이션 계층이 스케줄링할 수 있도록 전달합니다.
실패를 격리합니다. 환경 하나가 이상 상태로 판단되더라도 그 환경에 연결된 작업만 영향을 받게 해야 합니다. 일반적으로 각 환경에 상태 정보를 두고 정기적으로 확인하며, 문제가 발견되면 해당 환경을 빼고 예비 환경으로 교체합니다. 상위 스크립트가 같은 불량 환경을 계속 재시도하게 두지 않는 것입니다. 이렇게 하면 문제가 환경 때문인지, 페이지 구조가 바뀐 것인지도 더 명확하게 구분할 수 있습니다.
상태를 복구 가능하게 만듭니다. 진행 상황, 중복 제거 fingerprint, 환경 식별자를 스크립트 외부에 영구 저장합니다. 재시작할 때 먼저 이 기록을 읽고 어디서 계속할지, 어떤 환경을 사용할지 결정합니다. 작업을 발견, 로딩, 추출 같은 단계로 나눠 각각 장애를 처리하면 한 지점의 실패 때문에 전체 실행을 다시 해야 하는 일을 줄일 수 있습니다. 리소스도 살펴야 합니다. 장시간 실행되는 인스턴스에서는 메모리 누수, 페이지 멈춤, 연결 시간 초과가 생길 수 있으므로 무효 세션을 정기적으로 회수해야 합니다.
명확히 구분해야 할 경계
환경이 안정적인 것과 데이터를 수집해도 되는 것은 별개의 문제입니다. 먼저 대상 사이트의 robots 규칙과 서비스 약관을 확인해야 합니다. 자동화 접근을 명시적으로 제한하는 사이트가 많기 때문입니다. 요청 빈도는 상대 서비스에 영향을 주지 않는 수준으로 유지하고, 개인정보를 수집하지 말아야 하며, 기술적 보호 조치를 만났을 때는 우회 방법을 찾기보다 전략을 조정하거나 승인을 받아야 합니다. 기술적 안정성이 준수 판단을 대신할 수는 없습니다.
이 내용은 기술 연구와 개발 실무 교류만을 목적으로 합니다. 대상 사이트의 약관과 사용 지역에 적용되는 법규를 따르십시오.
