[실전 서버리스 04] 첫 Worker 배포하기, fetch 핸들러와 라우팅

이론은 앞에서 충분히 다뤘으니 이제 실전이다. 워커스의 세계는 사실 놀랄 만큼 단순한 데서 시작한다. 함수 하나가 요청을 받아 응답을 돌려주는 것, 그게 전부다. 이번 편은 첫 번째 워커를 실제로 만들고 배포하는 과정, 그리고 그 안에서 여러 경로를 나누는 라우팅을 다룬다.


복잡해 보이는 서버리스도 결국 이 작은 함수 하나에서 출발한다. 이 기본 구조를 확실히 이해하면 나머지는 여기에 살을 붙이는 것이다.

1. 워커의 기본 구조, fetch 핸들러

워커의 핵심은 fetch 핸들러다. 요청이 들어오면 이 핸들러가 호출되고, 요청 객체를 받아 응답 객체를 돌려준다. 들어오는 요청과 나가는 응답, 이 두 가지만 다루면 된다. 웹의 가장 근본적인 요청과 응답 구조를 그대로 코드로 옮긴 것이다.


이 단순함이 워커의 강점이다. 복잡한 프레임워크나 서버 설정 없이, 함수 하나가 요청을 받아 처리하고 응답한다. 처음엔 이게 너무 단순해서 오히려 어색할 정도였다. 서버를 세팅하고 라우터를 붙이고 미들웨어를 설정하던 방식에 익숙했다면, 이 간결함이 낯설게 느껴질 수 있다.


요청 객체에는 사용자가 보낸 모든 정보가 담겨 있다. 주소, 메서드, 헤더, 본문 같은 것들이다. 이걸 읽어서 무엇을 할지 정하고, 응답 객체를 만들어 돌려주면 된다. 응답에는 상태 코드, 헤더, 본문을 담는다. 앞서 SEO 시리즈에서 다룬 상태 코드가 바로 여기서 정해진다.


함수 하나가 요청을 받아 응답한다는 이 단순함이, 처음엔 오히려 불안하게 느껴질 수 있다. 이렇게 간단해도 되나 싶은 것이다. 하지만 웹의 본질이 원래 요청과 응답이라, 이 단순한 모델이 웹 서비스의 거의 모든 걸 표현할 수 있다. 복잡함은 필요할 때 얹으면 되고, 시작은 이 단순함에서 하는 게 맞다.


조금 더 배경을 주면, 이 fetch 핸들러 모델은 웹 표준을 그대로 따른다. 요청과 응답 객체가 브라우저에서 쓰는 것과 같은 형태라, 웹을 알던 사람이라면 새로 배울 게 적다. 서버리스 전용의 낯선 개념이 아니라 익숙한 웹 표준 위에 서 있다는 게, 진입 장벽을 낮춰준다.


한 가지 더, 워커의 이 단순한 구조는 테스트하기도 좋다. 요청을 넣으면 응답이 나오는 순수한 함수에 가까워서, 입력과 출력을 확인하는 방식으로 검증하기 쉽다. 복잡한 서버 환경을 통째로 띄우지 않아도 함수 단위로 동작을 확인할 수 있다. 이 테스트 용이성도 워커의 숨은 장점이다.

2. 배포는 명령어 한 줄

워커를 배포하는 건 놀랍도록 간단하다. 코드를 작성하고 배포 명령어를 실행하면, 몇 초 만에 그 코드가 전 세계 엣지에 올라간다. 서버를 프로비저닝하고 배포 파이프라인을 구성하던 것에 비하면 허무할 정도로 쉽다.


이 배포 도구가 랭글러다. 랭글러는 워커를 개발하고 배포하고 관리하는 명령줄 도구인데, 이걸로 로컬에서 테스트하고, 배포하고, 로그를 보고, 설정을 관리한다. 워커스 생태계의 스위스 army knife 같은 존재라, 이 도구에 익숙해지는 게 서버리스 개발의 기본기다.


배포하면 랭글러가 시작 시간 같은 정보를 알려준다. 여기서 중요한 게 하나 있다. 워커는 핸들러 밖의 최상위 코드, 즉 전역 스코프를 1초 안에 실행해야 한다. 이걸 넘으면 배포가 거부된다. 그래서 무거운 초기화를 전역에서 하면 안 되고, 필요할 때 핸들러 안에서 하는 게 원칙이다.


배포가 명령어 한 줄이라는 게 개발 리듬을 바꾼다. 고치고 배포하고 확인하는 사이클이 짧아지니, 작은 변경을 자주 배포하며 다듬게 된다. 큰 배포를 두려워하며 미루는 대신, 작게 자주 배포하는 습관이 든다. 이 빠른 피드백 루프가 개발 속도와 안정성을 동시에 높여준다.

3. 라우팅, 경로를 나누기

함수 하나가 모든 요청을 받으니, 그 안에서 어떤 요청인지에 따라 처리를 나눠야 한다. 이게 라우팅이다. 요청의 주소와 메서드를 보고, 이건 글 목록 요청, 저건 글 작성 요청, 하는 식으로 갈래를 나눈다.


간단한 사이트라면 요청 주소를 조건문으로 분기하는 것만으로 충분하다. 주소가 이걸로 시작하면 이 함수, 저걸로 시작하면 저 함수를 부르는 식이다. 처음엔 나도 이렇게 조건문으로 시작했다. 규모가 작으면 이게 가장 단순하고 명확하다.


사이트가 커지면 라우팅 전용 도구를 쓰는 게 편해진다. 경량 라우팅 프레임워크를 얹으면 주소별 처리를 깔끔하게 정리할 수 있다. 다만 도구를 얹는 건 필요해졌을 때 하면 된다. 처음부터 무거운 프레임워크를 올리기보다, 단순하게 시작해 필요에 따라 키우는 게 서버리스답다.


라우팅을 조건문으로 시작하라는 게 프레임워크를 무시하라는 뜻은 아니다. 규모에 맞게 도구를 고르라는 것이다. 작을 때 무거운 프레임워크를 얹으면 배보다 배꼽이 크고, 클 때 조건문만 고집하면 관리가 어렵다. 지금 규모에 맞는 가장 단순한 도구를 쓰고, 커지면 그때 바꾸는 유연함이 필요하다.


라우팅을 실제로 짜다 보면, 주소 설계가 중요하다는 걸 알게 된다. 어떤 기능을 어떤 주소에 둘지가 곧 라우팅 구조가 되기 때문이다. 앞서 SEO 시리즈에서 URL을 함부로 바꾸지 말라고 했는데, 그 URL 설계가 여기 라우팅과 직결된다. 주소를 잘 설계하면 라우팅도 깔끔하고 SEO에도 이롭다.

4. 정적 파일과 동적 처리

사이트는 정적인 것과 동적인 것이 섞여 있다. HTML, CSS, 이미지 같은 정적 파일과, 데이터베이스를 조회해 만드는 동적 응답이다. 워커는 이 둘을 한 곳에서 처리할 수 있다. 정적 파일 요청은 저장된 파일을 그대로 내주고, 동적 요청은 코드로 처리해 응답한다.


예전엔 정적 파일은 웹 서버가, 동적 처리는 애플리케이션 서버가 따로 맡는 경우가 많았다. 워커는 이걸 하나로 합친다. 최근 방향은 워커가 정적 자산까지 함께 서빙하는 것인데, 이러면 프론트엔드와 백엔드가 한 배포로 통합된다. 이 통합 방식은 다음 편에서 자세히 다룬다.


이 구조 덕에 내 커뮤니티는 정적 페이지 골격과 동적 데이터를 한 워커가 함께 다룬다. 봇이 오면 서버에서 완성된 HTML을 만들어 내주고, 사람에겐 그 위에서 자바스크립트가 동적으로 동작한다. 앞서 SEO 시리즈에서 강조한 서버 사이드 렌더링이 이 구조에서 자연스럽게 나온다.


정적과 동적을 한 워커가 다룬다는 게 구조를 얼마나 단순하게 하는지는 겪어보면 안다. 예전엔 정적 서버와 앱 서버를 따로 두고 그 사이를 연결하느라 설정이 복잡했다. 지금은 한 워커 안에서 요청 성격에 따라 갈리니, 그 연결 자체가 사라졌다. 관리할 조각이 줄면 실수할 여지도 준다.

5. 작게 시작해서 키운다

첫 워커를 배포하고 나면, 서버리스 개발이 생각보다 어렵지 않다는 걸 느낀다. 함수 하나로 시작해서, 라우팅으로 갈래를 나누고, 데이터베이스와 스토리지를 연결하며 점점 키워가면 된다. 처음부터 완성된 구조를 짜려 하지 말고, 작동하는 최소한에서 출발하는 게 좋다.


이건 서버리스의 철학과도 맞는다. 무겁게 미리 설계하기보다, 가볍게 시작해 필요에 따라 확장하는 것이다. 워커 하나가 잘 돌면 거기에 데이터베이스를 붙이고, 스토리지를 붙이고, 정기 작업을 붙인다. 각 조각이 독립적이라, 하나씩 더해가며 이해할 수 있다.


정리하면 워커는 fetch 핸들러 하나로 요청을 받아 응답하는 단순한 구조이고, 배포는 명령어 한 줄이며, 라우팅으로 갈래를 나눈다. 다음 편에서는 이 워커가 프론트엔드까지 함께 서빙하는 방식, 즉 정적 자산 통합을 다룬다. 프론트와 백엔드를 한 배포로 묶는 최근의 권장 방식이다.


작게 시작해 키운다는 게 이 편의 핵심 태도다. 서버리스는 조각들이 독립적이라 하나씩 더해가며 이해하기 좋다. 워커 하나로 시작해 데이터베이스를 붙이고 스토리지를 붙이며, 각 단계를 소화하며 나아간다. 처음부터 전체를 완벽히 설계하려는 욕심을 버리면, 오히려 더 튼튼한 구조가 만들어진다.


첫 워커를 배포하고 나면 자신감이 붙는다. 그 막연하던 서버리스가 실은 함수 하나에서 시작한다는 걸 몸으로 알기 때문이다. 이 작은 성공이 다음 단계로 나아갈 발판이 된다. 그래서 나는 서버리스를 처음 접하는 사람에게 개념 공부보다 일단 워커 하나를 배포해보라고 권한다. 해보면 안다.


덧붙이면, 처음 워커를 배포할 때 가장 큰 벽은 기술이 아니라 심리다. 서버리스라는 낯선 개념에 겁먹는 것이다. 그런데 막상 함수 하나를 배포해 응답이 오는 걸 보면, 그 막연한 두려움이 사라진다. 그래서 개념을 완벽히 이해하려 미루기보다, 일단 가장 단순한 워커 하나를 띄워보는 게 최고의 첫걸음이다.