로그인 상태의 데이터 수집에는 여러 계정이 필요한 경우가 많으며, 제한의 원인이 항상 스크립트에 있는 것은 아닙니다. 연관 위험을 기기 특성, 네트워크 출구, 세션 상태, 요청 리듬으로 나누어 보면 실제로 통제 가능한 변수가 더 명확해집니다.
이커머스 데이터 수집은 크게 두 종류로 나눌 수 있습니다. 로그인 없이 공개 페이지를 수집하는 방식과, 경쟁사의 백오피스 데이터를 확인하거나 개인화 이후 표시되는 결과를 가져오는 것처럼 로그인 상태가 필요한 수집입니다.
첫 번째 유형은 대체로 빈도만 잘 관리하면 충분합니다. 두 번째 유형에서 여러 계정을 사용하게 되면 성패를 좌우하는 것은 스크립트가 얼마나 영리한지가 아니라 각 계정이 서로 독립적으로 존재할 수 있는지입니다. 이 계층이 제대로 구성되지 않으면 속도 제한과 차단이 무작위처럼 보이고, 스크립트를 바꾸거나 빈도를 낮추거나 selector를 변경해도 개선되지 않습니다.
위험은 어디에서 오는가
플랫폼은 여러 계정이 같은 주체에 의해 운영되는지 교차 검증으로 판단합니다. 네트워크 주소, 브라우저와 기기 특성, Cookie와 세션 데이터, 사용 패턴을 함께 비교하며, 어느 한 범주에서라도 높은 중복이 있으면 같은 운영자 아래의 계정으로 묶일 수 있습니다.
여기에는 분명한 경계가 필요합니다. 탐지 로직은 계속 바뀌므로 일시적인 요령으로 대응하는 방식은 효과가 짧고 비용이 큽니다. 따라서 여기서는 위험 통제를 우회하는 방법을 다루지 않습니다. 더 중요한 질문은 따로 있습니다. 위험의 원인을 명확히 한 뒤, 우리가 통제하면서 장기간 안정적으로 유지할 수 있는 변수는 무엇인가? 이 변수들이 여러 합법적인 계정이 서로 영향을 주는지를 결정합니다.
기기 및 브라우저 특성
문제가 생기기 쉬운 구성 중 하나는 같은 컴퓨터에서 여러 창을 열고 서로 다른 계정에 로그인하는 것입니다. 캐시를 지우거나 시크릿 모드를 사용해도 이 창들은 여전히 같은 시스템 환경과 브라우저 데이터를 공유합니다. 특성이 계속 겹치기 때문에 플랫폼에는 하나의 기기가 반복해서 신원을 바꾸는 것처럼 보입니다.
통제 가능한 방법은 계정마다 자체 환경을 제공하는 것입니다. 계정 하나에 독립 환경 하나를 대응시키고 fingerprint, Cookies, 로컬 저장소를 서로 분리합니다. 핵심은 이 환경을 계정에 고정하는 것이지, 실행할 때마다 임의의 구성을 새로 만드는 것이 아닙니다. 무작위 조합은 서로 모순되는 경우가 많습니다. 시간대, 언어, 해상도, UA가 맞지 않으면 안정적인 구성보다 오히려 더 비정상적으로 보일 수 있습니다.
결국 안정성은 무작위성이 아니라 일관성에서 나옵니다.
네트워크 출구
출구는 계정에 묶여야 합니다. 환경 하나에 출구 하나를 사용하고, 출구 지역은 계정 프로필, 시간대, 언어와 일치해야 합니다. 여러 계정의 환경을 분리했더라도 같은 출구를 공유하면 앞서 만든 격리의 상당 부분이 무의미해집니다.
출구 역시 비교적 안정적으로 유지해야 합니다. 지역을 자주 바꾸면 계정의 위치 신호를 설명하기 어려워집니다. 출구를 고를 때는 일반적으로 주거용 주소가 데이터센터 주소보다 정상 사용자 접속에 더 가깝게 보입니다. 이미 대량으로 사용된 주소도 피해야 합니다. 이런 주소는 자체적으로 더 집중적인 모니터링 대상이 되었을 수 있습니다.
Cookies와 세션
세션 상태 자체가 하나의 신원 기록입니다. 여러 계정이 같은 Cookies나 로컬 저장소를 공유하면, 다른 환경을 아무리 깔끔하게 분리해도 계정 사이에 직접적인 연결이 생깁니다.
새 환경의 세션도 처음부터 높은 강도로 사용하지 않는 편이 좋습니다. 먼저 정상적인 탐색 이력을 일정 기간 쌓고, 그다음 작업량을 단계적으로 늘립니다. 이 원칙은 데이터 수집 외의 상황에도 적용됩니다. 계정에 사용 이력이 있는지는 감당할 수 있는 활동량에 직접적인 영향을 줍니다.
요청 리듬
요청 밀도는 행동 신호입니다. 스크립트는 흔히 일정한 리듬을 보입니다. 접근 간격이 고정되어 있고, 페이지 순서가 늘 같으며, 수집 이외의 행동이 전혀 없습니다. 이런 규칙성은 임의의 숫자를 조금 넣는 것으로 해결되지 않습니다. 더 큰 문제는 전체 규모에 있기 때문입니다.
통제 가능한 방향은 작업량을 합리적인 범위에 두는 것입니다. 계정별 실행 시간을 분산하고, 모든 계정을 동시에 최대 부하로 돌리지 않으며, 페이지 사이에 적절한 간격을 두고, 우선순위가 높은 작업과 낮은 작업을 구분합니다. 경계는 명확합니다. 데이터 수집 때문에 대상 서비스에 부담을 주어서는 안 됩니다. 상대 서비스에 영향을 주는 대가로 얻는 수집 속도는 정당한 최적화가 아닙니다.
계정별 고정 환경이 무작위 전환보다 더 안정적인 이유
무작위 전환의 목적은 매번 다른 모습으로 보이는 것이지만, 연관 판정은 각 차원의 신호가 안정적으로 유지되는지, 서로 모순되지 않는지를 봅니다. 한 계정이 오늘은 한 지역에서 나가고 내일은 다른 지역에서 나가며 특성 조합도 매번 바뀐다면, 그 불일치 자체가 비정상 신호가 됩니다.
고정 환경은 반대의 논리를 따릅니다. 계정은 등록 시점부터 일관된 신원을 갖습니다. 고정된 환경과 출구, 서로 맞는 시간대와 언어, 서서히 쌓이는 세션 이력이 그것입니다. 이런 일관성이 오래 유지될수록 활동은 정상 사용자에 더 가까워 보입니다. 환경 계층의 가치는 바로 여기에 있습니다. 화려한 변화가 아니라 장기적인 안정성입니다.
이 점은 수집 스크립트가 브라우저 인스턴스를 직접 관리하면 안 되는 이유도 설명합니다. 서로 다른 계정에 전용 환경을 할당하려면 환경을 독립적으로 스케줄링할 수 있어야 하고, 비정상 환경과 유효하지 않은 계정을 찾으려면 상태를 조회할 수 있어야 합니다. 장시간 운영 중 zombie instance가 쌓이지 않도록 환경을 회수할 수도 있어야 합니다. 또한 수집 작업을 재시도할 때는 다른 환경으로 바꾸어야 하는 경우가 많으며, 이는 환경이 독립적으로 스케줄링될 때만 가능합니다. 이런 구조에서 PurpleMark는 환경 리소스 계층입니다. 스크립트는 수집 로직만 담당하고, 신원과 리소스는 환경 계층에 맡깁니다.
규정 준수 경계
다음 항목은 앞서 언급한 어떤 최적화보다 중요합니다.
대상 사이트의 서비스 약관과 robots 규칙을 준수해야 합니다. 많은 이커머스 플랫폼은 약관에서 자동화된 접근을 명시적으로 제한하므로, 시작 전에 예정된 사용 방식이 허용되는지 확인해야 합니다. 공개된 상품, 가격, 재고 정보만 수집하고 개인정보는 수집하지 않습니다. 기술적 보호 조치를 우회하지 않습니다. CAPTCHA나 암호화된 인터페이스 같은 보호 장치를 만나면 이를 깨려고 하기보다 수집 전략을 조정하거나 권한을 요청해야 합니다. 계정 수와 관계없이 요청 빈도를 통제하고 대상 서비스의 정상 운영에 영향을 주어서는 안 됩니다.
이 논의의 전제는 여러 합법적인 계정을 서로 독립적으로 유지하고 방해하지 않게 하는 방법이지, 플랫폼 규칙을 회피하는 방법이 아닙니다. 전자는 운영 위생의 문제이고, 후자는 다른 문제입니다.


