[실전 서버리스 01] 서버 없이 사이트를 만든다는 것, 서버리스·엣지가 뭐길래

개인 프로젝트로 커뮤니티 사이트를 만들 때, 나는 서버를 한 대도 빌리지 않았다. 그런데도 사이트는 전 세계 어디서든 빠르게 돌아가고, 트래픽이 몰려도 알아서 늘어나고, 놀고 있을 땐 돈이 거의 안 나간다. 이게 서버리스와 엣지 컴퓨팅으로 만든 사이트다. 이번 시리즈는 그 밑바닥부터 실제로 굴리며 배운 이야기다. 첫 편은 서버리스가 대체 뭔지부터 정리한다.

앞서 SEO 시리즈를 쓸 때 계속 개발한 사이트라고만 했는데, 그 사이트를 실제로 어떻게 지었는지가 이번 시리즈의 주제다. 검색 노출 이전에, 사이트 자체를 서버 없이 만드는 이야기다.

1. 서버리스가 서버가 없다는 뜻은 아니다

먼저 오해부터 풀자. 서버리스라고 서버가 진짜 없는 건 아니다. 서버는 있는데, 내가 그걸 빌리고 관리하지 않는다는 뜻이다. 코드만 올리면 클라우드가 알아서 서버를 띄워 실행하고, 요청이 끝나면 정리한다. 서버를 신경 쓸 필요가 없어진다는 의미에서 서버리스다.

전통적인 방식은 서버 한 대를 통째로 빌린다. 그러면 그 서버는 요청이 없어도 24시간 켜져 있고, 그동안 계속 돈이 나간다. 트래픽이 몰리면 감당을 못 해 느려지거나 죽고, 반대로 새벽에 아무도 안 와도 똑같은 비용을 낸다. 서버 관리, 보안 패치, 확장까지 다 내 몫이다.

서버리스는 이 부담을 통째로 클라우드에 넘긴다. 요청이 오면 그때 코드가 실행되고, 요청이 없으면 아무것도 안 돌고 돈도 안 나간다. 트래픽이 열 배로 뛰면 클라우드가 알아서 열 배로 늘려 실행한다. 나는 코드만 신경 쓰면 된다. 개인 개발자에게 이건 게임 체인저다.

조금 더 풀어 설명하면, 서버리스는 관리의 책임을 넘기는 것이지 서버를 없애는 게 아니다. 식당에 비유하면, 예전엔 주방을 직접 차리고 요리사를 고용하고 재료를 관리했다면, 서버리스는 필요할 때만 주방을 빌려 쓰고 안 쓰면 반납하는 것이다. 주방이 없는 게 아니라 내가 소유하지 않는 것이다.

조금 더 배경을 주면, 서버리스라는 말은 마케팅 용어처럼 들리지만 실제 개발 방식의 전환을 담고 있다. 인프라를 다루던 시간을 코드와 제품에 온전히 쓸 수 있게 되는 것이다. 개인 개발자에게 시간은 곧 전부라, 이 전환이 실질적으로 무엇을 만들 수 있는지의 범위를 넓혀준다.

2. 엣지 컴퓨팅, 사용자 가까이서 실행

여기에 엣지라는 개념이 더해진다. 전통적인 서버는 보통 한 곳, 예를 들어 미국의 어느 데이터센터에 있다. 그러면 한국 사용자가 접속할 때 요청이 태평양을 건너갔다 와야 한다. 그 왕복 시간만큼 느려진다.

엣지 컴퓨팅은 코드를 전 세계 수백 개 도시에 뿌려둔다. 한국 사용자는 한국이나 가까운 도시의 서버에서, 유럽 사용자는 유럽 서버에서 실행된다. 사용자와 물리적으로 가까운 곳에서 코드가 도니, 왕복 거리가 짧아 훨씬 빠르다. 내가 쓴 플랫폼은 330개가 넘는 도시에 코드를 자동으로 배치해준다.

이게 개인 개발자에게 주는 의미가 크다. 예전엔 전 세계 사용자에게 빠른 서비스를 주려면 여러 지역에 서버를 두고 관리해야 했다. 엄청난 비용과 노력이다. 그런데 엣지 서버리스는 코드 한 번 올리면 그게 전 세계에 깔린다. 개인이 글로벌 인프라를 공짜에 가깝게 쓰는 것이다.

전통 서버의 부담을 조금 더 나열하면 이렇다. 서버가 다운되면 새벽에도 일어나 고쳐야 하고, 보안 취약점이 나오면 패치해야 하고, 트래픽이 늘면 서버를 증설하고 부하 분산을 설정해야 한다. 이 모든 게 개인 개발자에겐 큰 짐이다. 서버리스는 이걸 다 클라우드가 알아서 해준다.

엣지 컴퓨팅이 개인에게 준 또 하나의 선물은 운영 지식의 부담이 줄었다는 것이다. 예전엔 여러 지역에 서버를 두려면 부하 분산, 지역 간 데이터 동기화, 장애 대응 같은 깊은 인프라 지식이 필요했다. 지금은 그걸 플랫폼이 감춰주니, 개발자는 코드에만 집중하면 된다. 인프라 전문가가 아니어도 글로벌 서비스를 만들 수 있게 된 것이다.

3. 내가 쓴 스택

구체적으로 내가 쓴 건 클라우드플레어의 서버리스 생태계다. 핵심은 몇 가지로 나뉜다. 코드를 실행하는 워커스(Workers), 데이터를 담는 SQL 데이터베이스 D1, 이미지나 파일을 저장하는 오브젝트 스토리지 R2, 그리고 이것들을 묶어 사이트로 만드는 구조다.

이 조합이 좋은 이유는 하나의 생태계 안에서 다 해결된다는 점이다. 코드 실행, 데이터베이스, 파일 저장, 정기 작업, 비동기 처리까지 한 플랫폼 안에 있어서 서로 매끄럽게 연결된다. 여러 서비스를 짜깁기하지 않아도 되니 개인이 관리하기 편하다.

이 시리즈에서는 이 스택을 하나씩 실제로 쓰며 겪은 것을 다룬다. 워커스로 코드를 올리고, D1으로 데이터를 다루고, R2로 파일을 올리고, 비용을 관리하고, 함정을 피하는 전 과정이다. 완벽한 교과서가 아니라, 직접 굴리며 삽질한 실전 기록이다.

엣지 방식의 자동 배치가 개인에게 왜 혁명적인지 하나만 더 짚으면, 예전엔 이런 글로벌 인프라가 대기업의 전유물이었다는 점이다. 여러 대륙에 데이터센터를 두는 건 막대한 자본이 필요했다. 그런데 지금은 코드 한 번 올리는 것으로 개인이 그 인프라 위에 올라탄다. 자본의 장벽이 사라진 것이다.

스택을 통합 생태계로 고른 또 다른 이유는 학습 곡선이다. 서로 다른 회사의 서비스를 조합하면 각각의 문서와 개념을 따로 익혀야 하지만, 한 생태계는 개념이 일관돼 하나를 배우면 나머지도 쉽다. 배울 시간이 부족한 개인에게 이 일관성은 생각보다 큰 도움이 됐다.

4. 서버리스가 안 맞는 경우

서버리스가 만능은 아니다. 안 맞는 경우도 분명히 있다. 대표적으로 무겁고 오래 걸리는 연산이다. 서버리스는 짧고 빠른 요청 처리에 최적화돼 있어서, 한 요청이 몇 분씩 CPU를 붙잡는 작업엔 부적합하거나 비싸질 수 있다. 대용량 영상 인코딩이나 무거운 머신러닝 추론 같은 게 그렇다.

또 서버에 상태를 계속 들고 있어야 하는 작업도 서버리스와는 결이 다르다. 서버리스는 기본적으로 요청마다 새로 시작하고 끝나는 구조라, 메모리에 뭔가를 계속 쌓아두는 방식과는 안 맞는다. 이런 건 별도의 상태 저장 도구를 써야 한다.

그래서 서버리스를 택할 땐 내 작업이 짧고 빠른 요청 위주인지를 봐야 한다. 웹사이트, API, 커뮤니티처럼 요청 하나하나가 가볍고 빠르게 끝나는 서비스엔 서버리스가 최적이다. 커뮤니티 사이트가 딱 그런 경우라, 나는 서버리스를 택했고 후회하지 않았다.

내가 이 스택을 고른 데는 실용적 이유가 있었다. 여러 서비스를 조합하면 각각의 요금과 설정, 연동을 다 관리해야 하는데, 한 생태계 안에서 해결되면 그 복잡도가 확 준다. 개인 개발자는 시간이 가장 부족한 자원이라, 관리 부담이 적은 통합 생태계가 큰 이점이었다.

5. 이 시리즈가 다룰 것

정리하면 서버리스는 서버 관리 부담을 클라우드에 넘기고, 엣지는 그 코드를 사용자 가까이서 실행하는 것이다. 둘이 합쳐지면 개인 개발자도 전 세계에 빠르고 저렴하며 알아서 확장되는 사이트를 만들 수 있다. 이게 내가 서버 한 대 없이 커뮤니티를 굴리는 방법이다.

다음 편부터 하나씩 파고든다. 다음 편에서는 엣지가 왜 그렇게 빠른지, 콜드 스타트라는 개념과 함께 구체적인 숫자로 살펴본다. 서버리스의 가장 큰 약점으로 꼽히던 콜드 스타트가, 엣지에서는 어떻게 사실상 사라졌는지를 다룬다.

이 시리즈가 서버 없이 사이트를 만들어보고 싶은 개인 개발자에게, 막연한 개념이 아니라 실제로 손에 잡히는 실전 안내가 되면 좋겠다. 나도 처음엔 다 헤매며 배웠으니, 그 삽질을 최대한 담아보겠다.

서버리스가 안 맞는 경우를 미리 아는 것도 중요하다. 무작정 다 서버리스로 하려다 오히려 고생하는 경우가 있기 때문이다. 그래서 내 작업의 성격을 먼저 보는 게 맞다. 짧고 빠른 요청 위주면 서버리스, 무겁고 긴 연산이나 상태 유지가 핵심이면 다른 선택지도 함께 고려하는 것이다.

이 시리즈가 완벽한 정답서가 아니라는 걸 다시 밝혀둔다. 나도 처음엔 개념부터 헷갈렸고, 배포 한 번에 며칠을 헤맸고, 비용 폭탄도 맞아봤다. 그 삽질을 숨기지 않고 담는 게 이 시리즈의 방향이다. 정제된 교과서보다, 실제로 부딪힌 사람의 기록이 더 도움이 될 때가 있다고 믿는다.

덧붙이면, 서버리스로 옮기면서 가장 크게 달라진 건 마음의 여유였다. 서버가 언제 죽을지 조마조마하던 데서, 인프라는 클라우드가 알아서 한다는 신뢰로 바뀌었다. 그 여유가 생기니 기능과 콘텐츠에 집중할 수 있었다. 도구가 개발자의 심리 상태까지 바꾼다는 걸, 서버리스로 옮기고 나서야 알았다.