☁️ 웹 도구 네 개를 서버 없이 운영합니다 — 한 달 비용은 도메인값뿐

혼자 웹 도구를 만들어 운영하고 있습니다. PDF 용량을 줄이는 OptiPDF, 이미지를 다루는 OptiImage, 생활 계산과 환율을 묶은 OptiCalc, QR 코드를 만드는 OptiQR까지 네 개예요. 사람들이 파일을 올리고 결과를 받아 가는 도구들이니 서버가 필요할 것 같지만, 없습니다. 정확히는 처음부터 안 쓰기로 정하고 만들었습니다. 비용 때문이기도 했고, 그보다 다른 이유가 컸어요.

파일을 서버로 보내지 않으면 두 문제가 같이 사라집니다

보통 온라인 변환 도구는 이렇게 돕니다. 사용자가 파일을 올리면 서버가 받아서 처리하고 결과를 돌려줘요. 이 구조에는 문제가 둘 있습니다.

비용. 파일이 오가는 만큼 트래픽이 나가고, 처리하는 동안 서버가 돌아야 합니다. 사람이 몰리면 비용도 따라 오릅니다.

개인정보. 남의 파일이 내 서버를 거쳐 갑니다. 계약서일 수도, 신분증 사진일 수도 있어요. 안 들여다본다고 말하는 것과 애초에 들어올 수 없게 만드는 건 다른 얘기입니다.

그래서 방향을 바꿨습니다. 처리를 사용자 브라우저 안에서 하는 겁니다. 요즘 브라우저는 이미지 인코딩이나 PDF 조작 정도는 충분히 해내요. 파일은 사용자 컴퓨터를 떠나지 않고, 제 쪽으로는 아무것도 오지 않습니다.

이렇게 하니 서버가 할 일이 없어졌습니다. 남은 건 HTML과 자바스크립트 파일을 사용자에게 전달하는 일뿐이에요. 그건 정적 호스팅으로 됩니다.

Cloudflare Pages를 고른 이유

정적 사이트를 무료로 올려주는 곳은 여럿입니다. 그중 Cloudflare Pages로 간 이유는 트래픽 제한이 없어서였어요.

정적 파일 요청은 무료·무제한입니다. 방문자가 늘어도 요금이 붙지 않아요. 다른 곳들은 월 몇 GB 식으로 한도가 있는데, 도구 사이트는 자바스크립트 용량이 커서 방문자당 전송량이 블로그보다 큽니다. 여기가 마음 편했습니다.

무료 플랜의 실제 한도는 이렇습니다 (출처: Cloudflare Pages 공식 문서 — Limits).

항목	무료 플랜 한도
월 빌드 횟수	500회
빌드 시간 제한	회당 20분
사이트당 파일 수	20,000개
단일 파일 크기	25MiB
프로젝트당 사용자 도메인	100개

걸릴 만한 건 빌드 횟수뿐입니다. 하루 16번꼴인데, 고치고 올리기를 반복하는 날엔 생각보다 빨리 씁니다. 저는 아직 여유가 있지만 한 번씩 확인은 합니다.

실제로 나가는 돈

서버비는 0원입니다. 다만 완전히 공짜는 아니에요. 도메인 값이 듭니다. 연 단위로 내는 그것 하나가 제가 이 도구들에 쓰는 전부입니다.

숨은 비용이 될 수 있는 지점도 하나 적어둡니다. Pages에서 서버 쪽 코드를 돌리는 기능(Functions)을 쓰면 얘기가 달라집니다. Functions 요청은 정적 파일과 달리 Workers 할당량에 포함되거든요. 무료 범위가 있지만 무제한은 아닙니다.

저는 이 기능을 안 씁니다. 대시보드 사용량 화면을 열어보면 요청도 CPU 시간도 전부 0으로 찍혀 있어요. 도구가 넷이나 돌아가는데 이 숫자가 0이라는 게 이 구조의 핵심입니다. 서버 없는 설계가 비용을 0으로 유지하는 조건 자체인 셈이죠.

배포는 저장소에 올리면 끝납니다

구성은 단순합니다. 코드를 깃허브에 두고 Cloudflare Pages와 연결해두면, 저장소에 올릴 때마다 알아서 빌드하고 배포합니다.

git add .
git commit -m "이미지 편집기 크롭 기능 수정"
git push

이게 배포 명령의 전부예요. 나머지는 Cloudflare 쪽에서 알아서 합니다.

연결은 대시보드에서 합니다. Workers 및 Pages 메뉴에서 프로젝트를 만들고 깃허브 저장소를 고른 뒤, 빌드 명령과 결과물 폴더를 지정하면 됩니다. 정적 HTML만 있는 도구라면 빌드 명령 없이 폴더만 지정해도 되고요.

도구는 각각 별도 프로젝트로 두고 서브도메인을 하나씩 붙였습니다. pdf. img. calc. qr. 이런 식으로요. 블로그까지 하면 프로젝트가 다섯 개입니다. 경로로 나누는 방법도 있지만 이렇게 하니 편한 점이 있었습니다. 한 도구를 고쳐도 다른 도구는 다시 빌드되지 않아요. 무료 플랜의 빌드 횟수를 아끼는 데도 도움이 되고, 하나가 잘못돼도 나머지는 멀쩡합니다. 무료 플랜도 프로젝트당 도메인을 100개까지 붙일 수 있으니 이 방식으로 한도에 걸릴 일은 없습니다.

올리고 나면 반드시 배포 결과를 확인하세요. 이건 제가 데인 부분입니다. 코드는 멀쩡히 고쳐졌는데 사용자에게 도달하지 않은 적이 있었어요. 수정한 코드가 실제 서비스가 바라보는 브랜치가 아닌 곳에 올라가 있었고, 그 사이 저장소 연결까지 끊겨 있었습니다. 로컬에서는 잘 되는데 사이트에서만 안 되는 상황이었죠.

대시보드의 배포 목록에서 최신 커밋이 초록 체크로 성공했는지 봅니다. “No deployment available”이면 실패한 겁니다. 고쳤다와 사용자가 쓸 수 있다 사이에는 배포라는 단계가 하나 더 있습니다. 이 얘기는 AI에게 코딩을 맡기며 배운 것에 더 자세히 적었어요.

서버가 없어서 못 하는 것들

정직하게 적어둡니다. 이 구조로는 안 되는 게 있어요.

• 사용자 계정과 저장 기능 — 서버에 보관할 곳이 없으니 로그인도 없고, 작업 내역도 안 남습니다
• 무거운 처리 — 브라우저에서 도니까 사용자 기기 성능을 탑니다. 오래된 휴대폰에서는 느려요
• 외부 API 호출의 제약 — OptiCalc에 환율을 넣을 때 걸렸습니다. 브라우저가 직접 외부 주소를 부르는데, 그 주소가 다른 곳으로 넘겨보내는 응답을 하면 브라우저가 보안 정책상 차단합니다. 서버가 있으면 서버가 대신 부르면 되는데, 없으니 우회할 방법이 마땅치 않았어요

세 번째가 이 구조의 가장 뚜렷한 한계입니다. 서버 없는 설계는 내 코드가 남의 서비스를 부를 때 부딪힙니다. 처리를 브라우저에 맡긴 대가예요.

그래도 남기기로 했습니다. 계정이 없다는 건 불편이 아니라 회원가입 없이 바로 쓸 수 있다는 뜻이기도 하니까요.

정리

서버를 안 쓰기로 한 결정 하나가 여러 개를 정리해줬습니다. 비용이 0이 됐고, 남의 파일을 보관할 일이 없어졌고, 관리할 서버도 없어졌어요. 새벽에 서버가 죽었다는 알림을 받을 일이 없다는 게 생각보다 큽니다.

대신 못 하는 것도 분명합니다. 계정도, 저장도, 무거운 처리도 안 돼요. 만들려는 게 그런 걸 필요로 한다면 이 구조는 맞지 않습니다.

다만 “파일 하나 넣고 결과 받아 가는” 종류의 도구라면, 서버는 생각보다 필요 없었습니다. 여기서 다룬 것들은 홀로라도 도구 모음에서 직접 써보실 수 있어요.