Skip to main content
계정 대시보드, 내부 포털, 회원 디렉터리, 저장된 검색, 주문 내역, 비공개 보고서처럼 유용한 많은 페이지는 로그인 뒤에 있습니다. 스크래퍼의 관점에서 문제는 단순히 “사용자 이름과 비밀번호를 입력하는 것”이 아닙니다. 실제 과제는 안정적으로 페이지를 탐색하고 데이터를 추출할 수 있을 만큼 오랫동안 유효한 인증 세션을 유지하는 것입니다. 인증된 스크래핑은 접근 권한이 있는 데이터로 제한해야 합니다. 로그인한다고 해서 법률, 계약, 개인정보 보호, 플랫폼 정책 의무가 사라지는 것은 아닙니다. 이를 고위험 워크플로로 취급하세요. 승인된 계정을 사용하고 접근 제어를 준수하며 계정에 부여된 권한을 벗어난 데이터는 수집하지 마세요.

로그인 후 달라지는 요소

공개 페이지는 일반적인 HTTP 요청으로 가져올 수 있는 경우가 많습니다. 로그인된 페이지에는 대개 다음과 같은 여러 브라우저 상태가 필요합니다.
  • 사용자가 이미 인증했음을 증명하는 세션 쿠키
  • 양식 제출 및 API 호출 시 사이트에서 요구하는 CSRF 토큰 또는 요청 헤더
  • 단일 페이지 애플리케이션에서 사용하는 로컬 스토리지 또는 세션 스토리지
  • 인증되지 않은 방문자를 /login으로 돌려보내는 리디렉션 로직
  • 시간, 비활동, IP 변경 또는 보안 이벤트에 따라 세션을 무효화하는 만료 규칙
로그인된 URL을 스크래퍼에 복사하는 것만으로는 실패하는 이유가 바로 여기에 있습니다. URL은 눈에 보이는 부분일 뿐이며, 페이지를 로드할 수 있게 하는 것은 세션 상태입니다.

접근 방식 1: 실제 세션의 쿠키 재사용

가장 일반적인 접근 방식은 한 번 로그인한 뒤 생성된 쿠키를 저장하고 이후 스크래핑 실행에서 재사용하는 것입니다. 사이트가 세션을 몇 시간 또는 며칠 동안 유지하고 세션을 특정 기기나 IP 주소에 지나치게 강하게 결합하지 않을 때 효과적입니다. 코드에서는 다음과 같은 패턴을 사용합니다.
프로덕션 환경에서는 소스 파일에 쿠키를 하드 코딩하지 마세요. 쿠키를 안전하게 저장하고 만료되면 교체하며 자격 증명처럼 취급하세요. 대상 페이지가 대부분 서버에서 렌더링되거나 기반 API가 브라우저와 같은 세션 쿠키를 허용할 때 쿠키 재사용이 가장 효과적입니다. 사이트가 수명이 짧은 토큰, 기기 검사, 잦은 재인증 메시지를 사용하면 쉽게 불안정해집니다.

접근 방식 2: 브라우저로 로그인

일부 사이트에는 실제 브라우저 로그인 절차가 필요합니다. 스크래퍼가 로그인 페이지를 열고 양식을 입력한 다음 제출하고 계정 페이지가 나타날 때까지 기다린 뒤, 나중에 실행할 수 있도록 브라우저 상태를 저장합니다.
이후 실행에서는 저장된 상태를 불러올 수 있습니다.
브라우저 기반 로그인은 쿠키만 사용하는 요청보다 느리지만 JavaScript를 많이 사용하는 로그인 페이지, 리디렉션, 스토리지 값을 더 안정적으로 처리합니다.

접근 방식 3: 로그인 API 재현

로그인 양식이 인증 엔드포인트에 단순한 POST 요청을 보내는 경우가 있습니다. 절차가 간단하고 사이트 약관에서 허용된다면 HTTP 클라이언트로 해당 요청을 직접 재현하고 반환된 쿠키를 수집한 뒤 사이트 탐색을 계속할 수 있습니다. 인증 절차에는 CSRF 토큰, 봇 검사, 기기 핑거프린팅, 계속 바뀌는 숨겨진 필드가 포함되는 경우가 많아 이 방법은 일반적으로 브라우저 로그인보다 불안정합니다. Network 탭을 검사하면 로그인 요청이 재현할 만큼 단순한지, 아니면 브라우저 세션을 사용하는 편이 안전한지 판단할 수 있습니다.

MFA, SSO 및 보안 메시지

다단계 인증은 설계 방식을 바꿉니다. 스크래퍼가 MFA를 우회하려 해서는 안 됩니다. 대신 다음과 같이 설계하세요.
  • 사람이 로그인 과정에 참여한 다음 인증된 세션을 저장합니다.
  • 사이트에서 제공한다면 공식 API나 서비스 계정을 우선적으로 사용합니다.
  • 세션 만료를 예상하고 새로 고침 또는 재로그인 워크플로를 구축합니다.
  • 무인 프로덕션 작업에는 개인 계정을 사용하지 않습니다.
싱글 사인온 절차는 도메인을 넘나들거나 조직 정책을 요구하고 브라우저 ID가 변경될 때 보안 메시지를 표시할 수 있어 제약이 더 클 수 있습니다. 이러한 경우에는 원시 HTTP 클라이언트보다 지속형 브라우저 프로필이나 공식 연동이 더 안정적인 경우가 많습니다.

세션 안전

인증된 스크래핑을 가볍게 다루면 계정이 잠기고 알림이 발생하거나 민감한 데이터가 노출될 수 있습니다. 다음 보호 조치를 적용하세요.
  • 작업별로 계정을 분리하세요. 같은 로그인 세션에 관련 없는 스크래핑 작업을 혼합하지 마세요.
  • 한 세션 안에서 IP와 브라우저 ID를 안정적으로 유지하세요. 세션 도중 프록시를 전환하면 계정 탈취처럼 보일 수 있습니다.
  • 작업 속도를 제한하세요. 로그인 영역은 공개 페이지보다 엄격하게 모니터링되는 경우가 많습니다.
  • 로그아웃 페이지를 감지하세요. 스크래퍼는 로그인 페이지를 실제 데이터로 파싱하지 않도록 로그인 화면으로 리디렉션된 사실을 인식해야 합니다.
  • 비밀 정보를 안전하게 저장하세요. 자격 증명, 쿠키, 스토리지 상태 파일은 모두 민감한 정보입니다.
  • 접근 로그를 신중하게 기록하세요. 실패를 진단할 수 있을 만큼 실행 기록을 보존하되 비공개 페이지 콘텐츠나 자격 증명을 로그에 기록하지 마세요.

Octoparse 활용 방식

시각적 스크래핑 도구는 일반적으로 두 가지 방식으로 인증된 페이지를 처리합니다. 내장 브라우저에서 사용자가 로그인하게 한 뒤 생성된 쿠키와 브라우저 세션을 보존하거나, 추출을 시작하기 전에 스크래퍼가 로그인하도록 로그인 단계를 작업의 일부로 시뮬레이션합니다. Octoparse도 이 일반적인 방식을 따릅니다. 로그인 상태를 유지할 수 있는 사이트에서는 내장 브라우저에서 인증한 다음 저장된 쿠키/세션을 여러 실행에서 재사용할 수 있습니다. 새로운 로그인 절차가 필요한 사이트에서는 대상 페이지로 이동하기 전에 작업이 로그인 동작을 시뮬레이션할 수 있습니다. 하지만 실용적인 제한은 그대로 적용됩니다. MFA에는 사람의 개입이 필요할 수 있고 세션은 만료될 수 있으며, 계정에는 수집할 데이터에 대한 접근 권한이 있어야 합니다.

로그인 뒤의 페이지를 스크래핑하면 안 되는 경우

권한이 없거나, 데이터가 다른 사용자의 것이거나, 사이트 약관에서 사용 사례를 금지하거나, 공식 내보내기/API가 있고 그것이 적절한 경로라면 인증된 콘텐츠를 스크래핑하지 마세요. 로그인된 상태의 스크래핑은 계정 소유자가 자신에게 접근 권한이 있는 데이터를 수집하거나 승인된 비즈니스 프로세스 안에서 작업하는 경우에만 사용하는 것이 가장 좋습니다. 기술적 패턴은 간단합니다. 인증하고, 세션 상태를 보존하며, 페이지를 탐색하고, 만료를 감지한 뒤, 필요할 때 갱신합니다. 어려운 부분은 이를 책임감 있게 운영하는 것입니다.