리캡차(recapcha) 대응

리캡차에 대응하는 방법은 현재까지는 딜레이 시간을 늘리는 것이 가장 효과적인 듯. 설령 리캡차를 완벽하게 회피하거나 돌파할 수 있는 방법이 있다고 하더라도 서비스 제공자의 관점에서 보았을 때 그것은 탐탁치 않다. 크롤링은 대상 서버에 짧은 시간에 큰 트래픽을 초래하는 부담스러운 작업이므로 서비스 제공자에게 큰 손해를 미칠 수 있다. 따라서 리캡차와 같은 방법을 통한 트래픽 차단 행위는 서비스 제공자에 입장에서는 너무나도 당연한 조치이므로 데이터를 취하고자 하는 사람은 트래픽 차단 조치를 존중해줘야 한다.

리캡차가 발생하였을 때 증상은 명확하다. 리캡차가 발생하였을 때는 데이터가 하나도 수집되지 않는다. 여러 종류의 데이터 수집 태스크가 수집기에 전달되었음에도 불구하고 수집된 데이터가 0으로 나타난다면 리캡차를 의심해야 한다. 이러한 리캡차에 의한 장애는 수집 대상 서버가 우리의 제어권에서 완전히 벗어나 있기 때문에 우리가 완벽하게 제거해낼 수 없다는 사실을 솔직하게 인정해야 한다. 믿을 수 없지만 세상에는 이런 믿을 수 없는 일이 간혹 있긴 있더라!

리캡차에 대해서는 ‘완벽한 장애의 제거’가 아니라 ‘장애 발생 횟수를 감소’하는 방식으로 대응해야 한다. 전자는 ‘디버깅에 집중’하지만 후자는 ‘버그 발견’에 집중해야 하기 때문에, 수집 모듈의 동작상태를 확인하고 제어하기 위한 써드 파티의 모니터링 프로그램이 반드시 필요하다. 우리는 지금까지 디버깅에만 집중했므로 이러한 ‘사후 대응’에 대한 조치에는 소홀하였음을 솔직하게 인정해야 한다.

많은 사람들은 애석하게도 기계가 만능일 것을 기대하지만 애석하게도 기계는 만능이 아니다. 만능하지 않은 사람이 만든 건데 만능일 수 없다. 그러니 사용자 역시도 기계의 불완점함만을 탓해서는 안된다. 따라서 기계를 만들고 제어하고 관리하는 사람들은 그런 사용자들을 교육시켜 기계의 메커니즘이나 부족함을 가르쳐야 할 책임이 있다고 생각한다.

주절주절 얘기했지만 결론은 리캡차에 의해 데이터 수집이 불가능한 경우가 발생할 수도 있음을 자연스럽게 받아들이고 버그를 없애는 노력 만큼이나 버그에 빠르게 대응할 수 있는 조치 역시 함께 취해 나가야 하며, 또한 시스템에 내재하는 버그에 의해 시스템이 불완전할 수 있음을 사용자들에게도 말할 수 있어야 한다는 것이다.