웹사이트 크롤러 구축: Weglot기술 들여다보기

많은 Weglot 사용자는 웹사이트의 모든 URL이 정확하게 번역되기를 원합니다( Weglot 제공하는 첫 번째 기계 번역 레이어 이후). 많은 경우, 여러 언어로 번역된 대규모 웹사이트를 운영하는 경우 시간이 많이 소요될 수 있습니다.

또한 사용자들의 피드백을 통해 일부 사용자들이 처음 웹사이트 번역 프로젝트를 시작할 때 약간 혼란스러워한다는 사실을 알게 되었습니다. 번역 목록에 왜 자신의 홈페이지 URL만 표시되고 다른 페이지는 표시되지 않는지, 콘텐츠의 번역을 생성하는 방법은 무엇인지 궁금해하는 경우가 많았습니다.

그래서 저희는 이 부분에 개선의 여지가 있다는 것을 알고 있었습니다. 사용자가 더 쉽게 참여하고 프로젝트를 더 빠르고 효율적으로 관리할 수 있도록 도울 수 있지만, 아직 해결책이 없다는 것이 문제였습니다.

이미 짐작하셨겠지만... 이로 인해 URL 관리 기능이 출시되어 사용자가 웹사이트의 URL을 스캔하고 Weglot 대시보드에서 빠르고 효율적으로 번역된 콘텐츠를 생성할 수 있게 되었습니다.

최근 이 기능이 번역 목록에서 훨씬 더 유연하고 강력해진 새로운 URL별 번역 관리 페이지로 옮겨졌기 때문에 이 기능이 어떻게 구현되었는지 알려드릴 때가 되었다고 생각했습니다.

골랑을 구출하다

2020년 초, 팬데믹으로 인한 봉쇄로 인해 시간이 부족해 미뤄왔던 프로그래밍 언어 Golang을 배울 수 있는 기회가 생겼습니다.

골랑 (또는 줄여서 Go)은 구글에서 만든 언어로, 지난 몇 년 동안 많은 관심을 받고 있습니다.

정적으로 컴파일된 프로그래밍 언어로, 개발자가 빠르고 강력하며 동시적인 코드를 작성할 수 있도록 설계되었습니다. 그 단순성 덕분에 성능 저하 없이 크고 복잡한 프로그램을 작성하고 유지 관리할 수 있습니다: 골랑은 파이썬과 C의 의외의 자식으로 볼 수 있는데, 작성하기 쉽고 빠르게 실행할 수 있습니다.

제 생각에 새로운 프로그래밍 언어(또는 새로운 프레임워크 등)를 배우는 가장 좋은 방법은 배운 내용을 실습할 수 있는 좋은 프로젝트를 찾는 것입니다. 이 글을 읽고 있는 개발자라면 이것이 얼마나 어려운 일인지 잘 알고 있을 것입니다. 

좋은 사이드 프로젝트는 몇 가지 사양을 충족해야 합니다:

• 개발자가 프로그램을 구축하는 동안 학습하는 기술을 충분히 익힐 수 있도록 범위가 충분히 커야 합니다. 콘솔에 'Hello world'를 출력하는 것만으로는 새로운 언어를 이해하는 데 한계가 있습니다.
• 개발자가 프로젝트를 완료하기 전에 포기할 정도로 범위가 너무 크지 않아야 합니다(우리 모두 경험해 본 적이 있습니다).
• 마지막으로, 할 일이 재미있어야 합니다! 200번째로 할 일 목록을 프로그래밍하는 것은 그다지 재미있지 않을 것이며, 어떻게 해야 할지 구상하는 순간 포기할 가능성이 높습니다. 
• 보너스 포인트: 사이드 프로젝트는 실제 문제를 해결하는 것이 이상적이기 때문에 작업에 집중하는 데 도움이 됩니다.

이 얘기를 왜 하는 걸까요? 골랑을 배우기 위한 훌륭한 부업 프로젝트가 무엇일지 고민하던 중 웹 크롤러가 위의 설명에 완벽하게 부합할 수 있고 Weglot 사용자들을 위해 해결하고자 하는 몇 가지 문제를 해결할 수 있을 것 같다는 생각이 들었습니다.

웹 크롤러(흔히 '봇'이라고도 함)는 가장 간단한 형태로 웹사이트를 방문하여 정보를 추출하기 위해 만들어진 프로그램이라고 생각하면 됩니다.

웹 크롤러의 일반적인 사용 사례 중 하나는 웹사이트의 모든 페이지를 검색하고 방문한 다음 사이트맵을 생성하는 것입니다. 또는 Google 봇처럼 콘텐츠를 색인화할 수도 있습니다.

저희의 경우, 사용자가 웹사이트를 스캔하고 사이트의 모든 URL을 다시 가져오는 데 사용할 수 있는 무언가가 필요했습니다. 

또한 번역을 생성하는 새로운 방법을 찾고 있었습니다. Weglot익숙하지 않은 분들을 위한 참고 사항... '번역 생성'이란 URL(및 그 안에 포함된 콘텐츠)이 Weglot 번역 목록에 표시되어 번역을 수동으로 편집할 수 있다는 의미입니다.

그 당시에는 사용자가 번역된 언어로 웹사이트를 방문해야 했습니다. 웹사이트의 페이지 수가 적고 번역된 언어가 많지 않은 경우에는 매우 효과적이지만, 수천 페이지에 달하는 대규모 웹사이트를 운영하는 경우에는 금세 부담스러운 작업이 될 수 있습니다.

이 작업을 자동화하기 위해 웹 크롤러를 사용한다는 아이디어가 이상적인 솔루션처럼 보이기 시작했고, 이는 Golang 동시 프로그래밍 기능의 완벽한 사용 사례가 될 것입니다!

그래서 2020년 1월에 Golang의 기초를 배우면서 웹 크롤러의 프로토타입을 만들기 시작했고, 얼마 지나지 않아 WeglotCTO인 레미에게 보여줄 수 있는 무언가가 생겼습니다. 

URL을 입력으로 받아 웹사이트를 크롤링하여 동일한 도메인 링크를 찾을 때마다 방문하는 간단한 프로그램이었지만, 빠르고 효율적이었습니다.

간단한 데모 후, 레미는 제공된 솔루션에 대한 기대감과 함께 연구 개발에 필요한 시간을 갖고 POC(개념 증명)를 마무리한 다음 향후 프로덕션 사용을 위해 솔루션을 호스팅할 수 있는 방법을 고민하게 되었습니다.

소프트웨어 엔지니어로서 혼자서 무언가를 작업하다가 제품을 완전히 개발할 수 있는 시간이 주어지면 정말 기분이 좋습니다. 인정받는다는 기분은 정말 좋았고,아직 갈 길이 멀었지만 프로덕션에 사용할 수 있는 제품이 나올 때까지 계속 동기를 부여해 주었습니다.

호스팅 문제

콘텐츠 생성 기능과 다양한 CMS 및 통합 간의 차이점을 고려하기 위한 추가 작업이 필요한 봇을 완성하는 동시에 봇을 호스팅하고 사용자에게 노출하는 방법에 대해 생각하기 시작했습니다.

가장 먼저 생각한 것은 AWS에서 컴퓨팅 인스턴스를 회전시키고 웹 서버 뒤에 봇을 노출하는 고전적이고 검증된 솔루션을 사용하는 것이었습니다. 좋은 아이디어처럼 보였지만 생각할수록 몇 가지 문제가 더 걱정되었습니다.

처음에는 서버가 얼마나 많은 비용을 부담해야 하는지, 얼마나 많은 사용자가 동시에 이 기능을 사용할지 전혀 몰랐습니다. 프로비저닝된 용량은 충분한데 갑자기 많은 사용자가 한꺼번에 여러 개의 초대형 웹사이트를 크롤링한다면 어떻게 될까요?

저는 이전에 바둑 프로그램을 호스팅한 경험이 없었기 때문에 어떤 리소스(CPU, RAM 등)가 훌륭한 사용자 경험을 제공하기에 충분한지 판단하기가 어려웠습니다.

또한 기존의 '항상 가동' 웹 서버는 가장 효율적인 솔루션이 아니라고 생각했습니다. 사람들이 웹사이트를 항상 크롤링하지는 않을 것이기 때문에 URL을 가져와 콘텐츠를 생성한 후에는 새 콘텐츠나 업데이트된 콘텐츠를 자주 게시하더라도 매일 봇을 사용할 필요가 없습니다.

생각해보니 서버리스 호스팅의 완벽한 사용 사례처럼 보였습니다.

몇 년 전 서버리스 트렌드를 놓친 분들을 위해 서버리스가 어떻게 작동하는지 간단히 요약해 보겠습니다:

• 서버리스라는 이름에도 불구하고 코드는 여전히 서버에서 실행됩니다.
• 항상 실행되고 연결을 대기하는 서버와 달리 서버리스 코드는 온디맨드 방식으로 실행되며, 서버리스 코드가 트리거되면 클라우드 공급자가 코드 실행을 위해 일부 리소스를 프로비저닝하고 할당합니다.

이 호스팅 모델에는 두 가지 주요 이점이 즉시 제공됩니다:

• 개발자는 인프라를 관리할 필요가 없으며 공급자가 모든 작업을 수행합니다. 즉, 서버 보안이나 구성에 대해 걱정할 필요가 없다는 뜻입니다.
• 가장 중요한 것은 설계상 확장성이 뛰어나다는 것입니다! 

봇을 실행하는 데 서버에 필요한 리소스를 예측하기 어렵다고 말씀드렸던 것을 기억하시나요? 이제 더 이상 신경 쓸 필요가 없습니다. 모든 요청에 대해 새로운 상태 비저장 격리 컨테이너가 생성되어 그 안에서 코드를 실행하기 때문에 서버 용량을 초과할 위험이 없으며, 모든 요청은 자체 컨테이너에서 실행됩니다.

그렇다면 모든 것이 최선이라고 할 수 있을까요? 거의 그렇죠!

2020년에 서버리스 컴퓨팅은 5분으로 제한되어 있었습니다(적어도 AWS의 경우, 저는 Google Cloud Platform이나 Microsoft Azure에서 서버리스 호스팅을 사용해 본 경험이 없습니다). 이 호스팅 모델은 예를 들어 PDF 생성이나 이미지 자르기 같은 짧은 작업을 위해 설계되었기 때문에 완벽하게 이해가 됩니다. 

하지만 저희의 경우 5분이라는 시간은 어려운 문제였습니다. 응답 속도가 빠른 소규모 웹사이트를 크롤링하는 데는 충분하지만, 페이지 수가 수만 페이지에 달하고 응답 속도가 다소 느린 대규모 전자상거래 웹사이트의 경우 작업을 완료하기 전에 한계에 부딪힐 가능성이 높습니다.

2020년 초에 AWS가 5분 제한을 15분으로 늘린다는 발표를 했을 때 서버리스를 포기하려던 참이었습니다! 

안타깝게도 AWS는 새로운 기능을 발표할 때 새로운 기능에 대한 자세한 정보를 제공하지 않는 경우가 많기 때문에 기한이 연장되었지만 이를 얻는 방법에 대한 설명이 없었습니다.

제한 시간을 15분으로 늘리는 방법을 찾기 위해 많은 시행착오와 연구를 했지만 쉽지 않았다는 것을 말씀드리겠습니다 🙂.

5분 제한은 실제로 인프라 수준에서 시행된 제한으로, AWS는 서로 다른 서비스 간에 5분 이상 HTTP 연결을 유지하지 않으며, 해결책은 단순히 HTTP 호출로 서버리스 코드를 트리거하지 않는 것이었고, 다른 많은 방법이 있으며, 우리의 경우 AWS 메시지 큐 서비스인 SQS로 트리거하도록 설정했습니다.

결과 전달

호스팅 문제가 해결된 후, 하루를 마무리하기 전에 완료해야 할 작업이 하나 더 있었습니다. 

지금까지는 확장 가능하고 비용 효율적인 방식으로 호스팅되는 봇이 작동하고 있었으며, 마지막으로 필요한 것은 봇이 생성한 데이터를 사용자에게 다시 전송하는 것이었습니다.

가능한 한 대화형 기능을 원했기 때문에 봇과 Weglot 대시보드 간의 실시간 커뮤니케이션을 선택했습니다.

이런 종류의 기능에는 실시간이 필수는 아니며, 긴 폴링과 같은 더 간단한 솔루션으로 만족할 수도 있지만 크롤러가 작업을 시작하자마자 사용자가 피드백을 받을 수 있도록 하고 싶었고, 솔직히 말해서 봇이 빛을 발하고 잠재력을 보여줄 수 있는 방법이기도 했습니다 🙂.

당시에는 실시간 통신을 처리할 수 있는 솔루션이 없었기 때문에 검증된 솔루션을 사용하기로 결정했고, nodejs로 간단한 웹소켓 서버를 작성하여 EC2 AWS 인스턴스에서 호스팅했습니다.

웹소켓 서버와의 통신을 구현하고 배포를 자동화하기 위해 봇에 대한 몇 가지 작업을 거친 후 마침내 프로덕션에 출시하기 전에 테스트를 진행할 준비가 되었습니다.

사이드 프로젝트로 시작한 것이 결국 대시보드에 적용되었습니다. 

크롤러를 작성하고 수많은 문제를 해결하면서 정말 즐거웠습니다. 결국 새로운 프로그래밍 언어와 AWS 에코시스템의 새로운 기술 등 많은 것을 배웠습니다.

Go는 네트워킹 작업과 협동 프로그래밍에서 정말 빛을 발하는 언어이기 때문에 다시 사용하고 싶은 언어입니다. 또한 Js, PHP, Python과 같은 언어에 비해 메모리 사용량이 적어 서버리스 컴퓨팅과 함께 사용하기에 매우 좋은 언어이기도 합니다.

봇을 통해 새로운 시각을 갖게 된 만큼 앞으로 몇 가지 계획이 있습니다. 더 효율적이고 성능이 뛰어난 단어 수 도구를 재작성할 계획이며, 캐시를 워밍업(데이터로 채우는 것)하는 데도 사용할 수 있습니다.

이 기사를 작성하는 것만큼이나 Weglot기술에 대한 이 엿보기가 즐거웠기를 바라며, 봇을 직접 사용해 보시기 바랍니다!