전체 계정 등록 흐름을 실행해 보면 경계가 분명해집니다. 폼 입력, 날짜 선택, 이메일 인증 코드 읽기는 자동화할 수 있지만 영상 셀피 인증에서 멈춥니다. 완전 자동화를 좇기보다 각 계층의 비용 차이를 이해하는 편이 현실적입니다.
브라우저 자동화를 만드는 사람들은 흔히 낙관적으로 생각합니다. 작업을 충분히 작은 단계로 나누기만 하면 자동화하지 못할 과정은 없다고 보는 것입니다.
하지만 전체 흐름을 처음부터 끝까지 실제로 실행해 보면 다른 모습이 나타납니다. 앞부분은 놀랄 만큼 순조롭다가 마지막에 넘기 어려운 벽에 막힐 수 있습니다. 한 계정 등록 테스트가 전형적이었습니다. 폼 입력, 날짜 선택, 인증 코드 수신, 보안 검사를 모두 1분 이내에 처리했고 전체의 약 85%를 자동화했습니다. 남은 단계는 카메라 앞에서 실제 사용자가 수행해야 하는 영상 셀피 인증이었습니다.
이 흐름을 비용 기준으로 나누면 경계가 생각보다 훨씬 선명해집니다.
한 페이지 안의 결정적 작업은 스크립트로 대부분 안정적으로 처리된다
이름, 이메일, 비밀번호, 생년월일 같은 입력은 가장 안정적인 계층입니다. 필드 사이에 약간의 간격을 두고 키보드 입력을 흉내 내면 전체 단계는 약 5초가 걸립니다.
가장 큰 함정은 요소 위치 지정입니다. 현대적인 프런트엔드에는 의미 있는 name 속성이 없는 입력창이 많아 인덱스나 구조로 찾아야 합니다. 우아한 방식은 아니지만 자동화 상황에서는 오히려 안정적일 수 있습니다.
첫 번째 유형의 작업은 이렇습니다. 페이지 구조가 고정되어 있고, 동작이 명확하며, 결과를 예측할 수 있습니다. 이 범위의 작업은 스크립트 성공률이 대체로 높습니다.
커스텀 컴포넌트에서는 페이지 구조 자체가 비용이 된다
생년월일이나 성별 같은 드롭다운 선택이 실제로 시간을 많이 잡아먹습니다.
겉으로는 일반 선택 메뉴처럼 보여도 내부에는 접근성 역할을 사용하는 커스텀 컴포넌트가 있을 수 있습니다. 그러면 표준 방식이 차례로 실패합니다. 일반 select 방식이 통하지 않고, 접근성 라벨로 찾는 것도 안 되며, 대상 요소를 직접 클릭하는 것도 실패할 수 있습니다. 안정적인 방법은 실제 사람의 작업 순서를 그대로 재현하는 것입니다. 드롭다운을 열고, 옵션이 렌더링될 때까지 기다리고, 텍스트로 대상을 찾은 다음 클릭합니다.
코드는 몇 초 만에 작성할 수 있어도 디버깅에는 몇 시간이 걸릴 수 있습니다. 이 계층의 경계는 단순히 기술 수준이 아니라 페이지 구조가 얼마나 협조적인지에 달려 있습니다. 커스텀 컴포넌트를 만나면 기존 방식에 집착하지 않는 것이 시간을 가장 많이 아낄 수 있습니다.
사이트를 넘나들며 상태를 유지할 때 비용이 뚜렷하게 올라간다
인증 코드가 이메일로 오는 단계의 논리는 간단합니다. 메일함을 열고, 가장 최근 메시지를 찾고, 숫자 코드를 추출해 다시 입력합니다. 전체는 약 20초가 걸립니다.
함정도 복잡하지 않습니다. 스크립트가 오래된 메일을 읽으면 코드가 틀립니다. 따라서 시간 기준으로 가장 최신 메일을 가져와야 합니다.
이후 많은 플랫폼은 추가 확인 페이지로 이동시키고 새 코드를 한 번 더 보냅니다. 처리 로직은 재사용할 수 있지만 이전 단계의 코드 값은 재사용하면 안 됩니다.
진짜 어려운 부분은 두 개의 사이트와 두 개의 세션이 있다는 점입니다. 이메일 로그인 상태를 유지해야 하고, 플랫폼 세션도 단계 사이에 보존해야 하며, 프록시 IP, 시간대, 언어도 환경과 맞아야 합니다. 사이트 간 상태 유지 비용은 이런 식으로 조금씩 쌓입니다. 각 단계만 보면 어렵지 않지만 연결하면 실패율이 눈에 띄게 높아집니다.
여기서 스크립트는 실행자일 뿐이며 웹사이트에 어떤 신원으로 보일지 스스로 결정할 수 없습니다. 기기 지문과 IP가 환경에 맞는지는 플랫폼이 판단에 활용하는 요소입니다. 여러 계정을 운영하는 팀이 환경 격리를 별도 계층으로 분리하는 이유도 여기에 있습니다. 각 환경마다 독립된 지문과 IP를 둡니다. PurpleMark 같은 도구는 이 환경 계층을 제공하고, 스크립트는 그 안에서 동작만 수행합니다.
페이지를 이해해야 하는 작업은 순수 스크립트로는 분기문에 의존하게 된다
더 진행하면 문제의 성격이 바뀝니다.
페이지 문구나 구조가 계정, 지역, 단계적 실험에 따라 달라지면 하드코딩한 셀렉터가 묶음으로 실패합니다. 선택지는 두 가지입니다. 가능한 모든 분기를 코드에 계속 쌓아 유지보수를 어렵게 하거나, 페이지 의미를 이해할 수 있는 모델에 해당 단계를 맡기는 것입니다. 한 줄의 안내 문구나 버튼의 의미는 사람에게는 상식이지만 셀렉터에는 노이즈입니다.
플랫폼이 적극적으로 대응하면 순수 스크립트는 반복해서 다시 깨진다
쉽게 놓치는 비용이 하나 더 있습니다. 상대도 계속 움직입니다.
플랫폼이 보는 것은 폼을 채울 수 있는지뿐만이 아닙니다. 기기 지문이 정상적인지, IP와 기기 환경이 일치하는지, 행동이 사람처럼 보이는지, 대량 작업 흔적이 있는지 등을 볼 수 있습니다. 위험 관리가 한 번 업데이트되면 어제까지 동작하던 셀렉터나 행동 패턴을 다시 작성해야 할 수도 있습니다.
즉 순수 스크립트 방식에는 진정한 의미의 완료 시점이 없습니다. 한 번 전달하고 끝나는 개발이 아니라 계속 따라가야 하는 유지보수 작업입니다.
얼굴 인증은 단순한 기술 문제가 아니다
마지막 관문은 실제 사람이 카메라 앞에서 수행해야 하는 인증이며 자동화는 여기서 멈춥니다.
스크립트는 폼을 채우고, 버튼을 누르고, 메일을 읽고, 코드를 입력할 수 있지만 사람의 생체 특징이 필요한 동작을 정당하게 대신할 수는 없습니다. 이유는 기술력이 부족해서만이 아닙니다. 이 인증의 목적 자체가 화면 앞에 실제 사람이 있는지 확인하는 것이기 때문에 자동화 목표와 정면으로 충돌합니다. 얼굴 인증을 자동으로 통과할 수 있다고 주장하는 방식은 대개 위조된 생체 정보를 수반하며, 얻는 이익보다 훨씬 큰 규정 준수 또는 법적 위험을 만들 수 있습니다.
어떤 단계가 기술적으로 가능하더라도 플랫폼의 이용약관이 허용하는지 확인해야 합니다. 많은 플랫폼은 자동 등록 행위를 명확히 제한합니다. 이는 기술 역량이 아니라 규칙의 제약입니다.
결론은 완전 자동화가 아니라 계층별로 도구를 선택하는 것이다
흐름을 계층별로 정리하면 선택이 명확해집니다.
- 페이지가 고정되어 있고 동작이 결정적인 일은 스크립트에 맡깁니다. 비용이 가장 낮고 안정적입니다.
- 사이트 간 로그인 상태와 세션을 유지해야 한다면 브라우저 환경을 별도 계층으로 관리하고, 환경 문제를 스크립트 디버깅과 섞지 않습니다.
- 페이지 구조가 고정되어 있지 않고 의미를 이해해 다음 행동을 판단해야 한다면 코드에 분기를 쌓는 것보다 모델에 맡기는 편이 실용적일 수 있습니다.
- 실제 사람이 필요하거나 이용약관이 명확히 금지하는 단계는 엔드투엔드 자동화를 억지로 하지 않습니다.
먼저 전체 과정을 수동으로 한 번 진행해 넘을 수 없는 단계가 있는지 확인한 뒤, 어느 정도 개발에 투자할지 결정하는 것이 좋습니다. 자동화의 경제성이 가장 높은 곳은 반복적이고 결정적이며 판단이 필요 없는 작업입니다.
