[실전 서버리스 22] Pages에서 Workers로, 언제, 어떻게 옮기나

드디어 이 시리즈의 마지막이다. 스물두 편에 걸쳐 서버 없이 사이트를 만드는 이야기를 밑바닥부터 다뤘다. 이 마지막 편은 페이지스에서 워커스로 옮기는 이야기, 그리고 이 시리즈 전체를 관통하는 결론을 정리한다. 서버리스로 사이트를 만들고 굴려온 여정의 마무리다.

앞서 여러 번 워커스와 페이지스를 언급했는데, 이 둘의 관계와 이전을 정리하며 시리즈를 닫는다.

1. 페이지스와 워커스 다시 보기

페이지스는 원래 정적 사이트 배포에 특화된 도구였다. 프론트엔드 정적 사이트를 올리기 좋았고, 간단한 백엔드 기능도 함수로 붙일 수 있었다. 반면 워커스는 코드 실행이 중심인 도구였다. 처음엔 둘의 역할이 어느 정도 나뉘어 있었다.

그런데 워커스가 정적 자산 서빙까지 품으면서 경계가 흐려졌다. 이제 워커스 하나로 정적 자산과 동적 처리를 다 할 수 있게 됐고, 그래서 새 풀스택 프로젝트라면 워커스로 통합하는 게 권장 방향이 됐다. 페이지스가 하던 걸 워커스가 상위 호환으로 품은 셈이다.

내가 사이트를 만들 때는 이 두 가지가 섞인 구조로 시작했다. 정적인 부분과 동적인 부분을 각각 다루다가, 방향이 워커스 통합 쪽으로 정리되는 걸 지켜봤다. 지금 새로 시작한다면 처음부터 워커스 기반으로 통합하는 걸 고려하는 게 좋다. 도구의 방향이 그쪽으로 모이고 있기 때문이다.

페이지스와 워커스의 경계가 흐려진 게 최근의 큰 흐름이다. 워커스가 정적 자산 서빙까지 품으면서, 새 풀스택 프로젝트라면 워커스로 통합하는 게 권장 방향이 됐다. 페이지스가 하던 걸 워커스가 상위 호환으로 품은 셈이다. 그래서 지금 새로 시작한다면 워커스 기반 통합을 고려하는 게 좋다.

조금 더 배경을 주면, 페이지스와 워커스의 관계가 헷갈릴 수 있는데 실용적으로는 단순하다. 지금 새로 시작하면 워커스 통합을 보고, 이미 페이지스로 잘 돌아가면 굳이 안 옮겨도 된다. 두 도구의 세부 차이를 다 알 필요 없이, 프론트와 백엔드를 한 흐름으로 다룬다는 개념만 잡으면 충분하다.

이 시리즈가 앞선 SEO 시리즈와 계속 이어졌다는 걸 느꼈을 것이다. 상태 코드, 캐시, URL, 봇 트래픽 같은 주제가 두 시리즈에 걸쳐 나왔다. 사이트를 만드는 일과 검색에 노출시키는 일은 결국 하나로 얽혀 있다. 좋은 사이트는 잘 만들어지고 잘 노출되는, 이 둘이 함께 가는 것이다. 두 시리즈를 다 읽었다면 그 연결이 보일 것이다.

2. 언제 옮기나

이미 페이지스로 사이트를 운영 중이라면, 언제 워커스로 옮길지가 고민이다. 결론부터 말하면 구체적인 이유가 있을 때 옮긴다. 잘 돌아가는 걸 굳이 옮길 필요는 없다. 이전에는 항상 비용과 위험이 따르니, 명확한 이득이 있을 때만 하는 게 맞다.

옮길 만한 구체적 이유는 몇 가지다. 백엔드 로직이 상당히 늘어나 정적 중심 구조로는 벅찰 때, 프론트와 백엔드가 나뉜 걸 하나로 통합하고 싶을 때, 또는 페이지스에서는 안 되는데 워커스로는 되는 기능이 필요할 때다. 이런 명확한 필요가 있으면 옮기는 게 값어치가 있다.

반대로 지금 잘 돌아가고 특별한 불편이 없다면, 굳이 옮기지 않아도 된다. 새로운 게 권장된다고 무조건 따라갈 필요는 없다. 이전 자체가 시간과 위험을 쓰는 일이라, 그만한 이득이 없으면 안 하는 게 낫다. 도구 선택은 유행이 아니라 필요로 하는 것이다.

언제 옮기느냐는 구체적 이유가 있을 때다. 잘 돌아가는 걸 굳이 옮길 필요는 없다. 백엔드 로직이 크게 늘거나, 프론트와 백엔드를 통합하고 싶거나, 페이지스에서 안 되는 기능이 필요할 때 옮긴다. 반대로 지금 불편이 없으면 안 옮겨도 된다. 도구 선택은 유행이 아니라 필요로 하는 것이다.

3. 어떻게 옮기나

옮기기로 했다면 신중하게 한다. 이건 앞서 SEO 시리즈에서 다룬 큰 구조 변경과 비슷한 위험을 안는다. 특히 URL이 바뀌지 않게 조심해야 한다. 이전하면서 주소가 바뀌면 검색 색인이 무너질 수 있다. 앞서 강조한 URL을 함부로 바꾸지 말라는 원칙이 여기서도 적용된다.

이전은 한 번에 다 바꾸기보다 단계적으로 하는 게 안전하다. 일부를 먼저 옮겨 검증하고, 문제없으면 나머지를 옮기는 식이다. 그리고 이전 전후로 사이트가 정상인지, 주요 기능과 페이지가 잘 도는지 꼼꼼히 확인한다. 큰 변경일수록 배포 후 확인이 배포 자체보다 중요하다는 걸 여러 번 강조했다.

또 이전 중에 상태 코드와 캐시 같은 걸 그대로 유지해야 한다. 앞서 다룬 상태 코드 처리, 캐시 계층이 이전 후에도 똑같이 작동하는지 확인한다. 구조를 옮기면서 이런 세부가 어긋나면 SEO나 성능에 문제가 생긴다. 옮기되 동작은 그대로 유지하는 게 안전한 이전의 조건이다.

어떻게 옮기느냐는 신중하게, 단계적으로다. 특히 URL이 바뀌지 않게 조심한다. 이전하며 주소가 바뀌면 검색 색인이 무너지니, 앞서 강조한 URL을 함부로 바꾸지 말라는 원칙이 여기서도 적용된다. 일부를 먼저 옮겨 검증하고, 상태 코드와 캐시가 그대로 작동하는지 확인하며 나머지를 옮긴다.

조금 더 강조하면, 이전은 앞서 SEO 시리즈에서 다룬 큰 구조 변경과 같은 위험을 안는다. 특히 URL 유지가 생명이다. 옮기면서 주소가 바뀌면 애써 쌓은 검색 색인이 무너진다. 그래서 이전할 때는 URL을 그대로 유지하고, 단계적으로 검증하며, 배포 후 확인을 철저히 한다. 큰 변경일수록 신중함이 답이다.

4. 스물두 편을 돌아보며

이 시리즈를 돌아보면, 서버 없이 사이트를 만든다는 게 처음엔 막연했지만 하나씩 풀어보니 손에 잡히는 것이었다. 왜 서버리스인지에서 시작해, 워커스로 코드를 올리고, 데이터베이스와 스토리지를 다루고, 비동기와 정기 작업을 붙이고, 운영과 최적화까지 왔다. 각 조각이 모여 하나의 사이트가 됐다.

이 과정에서 반복된 원리가 있다. 작게 시작해 필요에 따라 키운다, 무거운 건 뒤로 미룬다, 측정하고 최적화한다, 자동화로 반복을 없앤다. 이 원리들은 서버리스만이 아니라 시스템을 만드는 일 전반에 통한다. 서버리스라는 도구를 배우며 이 보편적 원리도 함께 익힌 셈이다.

그리고 이 시리즈가 앞선 SEO 시리즈와 계속 이어졌다는 걸 느꼈을 것이다. 상태 코드, 캐시, URL, 봇 트래픽 같은 주제가 두 시리즈에 걸쳐 나왔다. 사이트를 만드는 일과 검색에 노출시키는 일은 결국 하나로 얽혀 있다. 좋은 사이트는 잘 만들어지고 잘 노출되는, 이 둘이 함께 가는 것이다.

스물두 편을 돌아보면 반복된 원리가 있다. 작게 시작해 키운다, 무거운 건 뒤로 미룬다, 측정하고 최적화한다, 자동화로 반복을 없앤다. 이 원리들은 서버리스만이 아니라 시스템을 만드는 일 전반에 통한다. 서버리스라는 도구를 배우며 이 보편적 원리도 함께 익힌 것이다. 도구는 바뀌어도 원리는 남는다.

5. 개인 개발자에게

마지막으로 하고 싶은 말은, 서버리스와 엣지가 개인 개발자에게 연 가능성이다. 예전엔 전 세계에 빠르게 서비스하는 사이트를 개인이 만들고 유지하기 어려웠다. 서버 비용과 관리, 인프라 지식이 벽이었다. 그런데 서버리스는 그 벽을 크게 낮췄다.

이제 개인이 취미로 시작한 사이트도, 전 세계에 빠르게 서비스하면서 거의 공짜로 유지하다가, 성장에 맞춰 비용을 감당해갈 수 있다. 이 도구들을 이해하고 제대로 쓰면, 혼자서도 대형 서비스 못지않은 사이트를 만들 수 있다. 나도 그렇게 커뮤니티를 만들었고, 이 시리즈에 그 과정을 담으려 했다.

스물두 편의 서버리스 이야기를 여기서 닫는다. 완벽한 교과서는 아니지만, 실제로 부딪히고 삽질하며 배운 걸 담으려 했다. 이 기록이 서버 없이 자기 사이트를 만들어보고 싶은 누군가에게, 막연한 두려움을 걷어내고 첫걸음을 떼는 계기가 되면 좋겠다. 긴 시리즈를 끝까지 함께해주셔서 감사하다.

개인 개발자에게 서버리스가 연 가능성이 이 시리즈의 진짜 메시지다. 예전엔 전 세계에 빠르게 서비스하는 사이트를 개인이 유지하기 어려웠는데, 서버리스가 그 벽을 낮췄다. 취미로 시작해 거의 공짜로 유지하다 성장에 맞춰 감당해간다. 이 도구를 이해하고 쓰면, 혼자서도 대형 서비스 못지않은 사이트를 만들 수 있다.

긴 시리즈를 쓰면서 느낀 건, 서버리스가 어렵다기보다 낯설 뿐이라는 것이다. 개념 하나하나는 단순한데, 다 처음이라 막막해 보였을 뿐이다. 워커 하나를 배포하고, 데이터베이스를 붙이고, 스토리지를 연결하며 하나씩 해보니 손에 잡혔다. 그래서 서버리스를 배우는 가장 좋은 방법은, 완벽히 이해하려 미루지 말고 일단 작은 것부터 만들어보는 것이다.