[연재] 서버 없이 어디까지 되나 — 정적 사이트라는 선택

오타 하나 고치자고 사이트를 통째로 다시 만들었어요

어제 글에서 오타를 하나 발견했어요. 글자 하나요.

그거 고치자고 제 컴퓨터가 한 일은 이렇습니다. 사이트 페이지 304장을 처음부터 전부 다시 만들고, 그걸 통째로 다시 인터넷에 올렸습니다. 글자 하나 때문에요.

무식하게 들리시죠. 그런데 이게 고장이 아니라 정상 동작입니다. 제 사이트는 원래 그렇게 굴러가요.

더 이상한 건 이겁니다.

그 무식한 짓에 걸린 시간이 3.25초예요. 올라간 파일은 3,528개 중 322개뿐이었고요. 나머지 3,206개는 "이건 이미 있는 거네" 하고 그냥 건너뛰었습니다.

오늘은 이 얘기를 해보려고 합니다. 서버 없이 사이트를 굴린다는 게 뭔지, 그래서 서버비가 왜 0원인지, 그리고 없어서 못 하는 게 뭔지요.

서버가 없다는 게 무슨 뜻이냐면요

보통 웹사이트는 이렇게 굴러갑니다. 누가 주소를 치고 들어오면, 어딘가에 있는 컴퓨터 한 대가 그때 그 사람을 위해 페이지를 만들어서 내줘요. 그 컴퓨터를 서버라고 부르고, 그게 24시간 켜져 있어야 하니까 매달 돈이 나갑니다.

제 사이트는 그 컴퓨터가 없습니다. 대신 페이지를 미리 다 만들어둡니다.

이게 만들어진 결과물이에요. posts 폴더 안에 글 폴더가 301개 있고, 그 폴더 하나하나에 index.html 파일이 딱 한 장씩 들어 있습니다. 그게 전부예요.

식당으로 비유하면 이렇습니다.

• 서버가 있는 사이트 = 손님이 주문하면 그때 요리를 시작하는 식당
• 제 사이트 = 도시락을 미리 다 싸놓고 집어가게 두는 곳

주문받고 요리하면 손님마다 다른 걸 내줄 수 있어요. 로그인한 사람에게는 "안녕하세요 OO님"이라고 인사하고, 장바구니도 사람마다 다르게 보여주고요. 대신 주방이 계속 돌아가야 합니다.

도시락은 그런 걸 못 합니다. 대신 주방이 필요 없어요. 그냥 쌓아두면 아무나 집어갑니다.

지금 이 화면도, 지금 읽고 계신 이 글도 전부 어제 미리 만들어둔 파일입니다. 들어오셨을 때 뭔가 계산해서 만든 게 아니라, 이미 만들어져 쌓여 있던 걸 그대로 받으신 거예요.

그래서 1년에 만 오천 원입니다

1편에서 서버비 얘기를 드렸는데요. 정확히 하자면 서버비는 0원입니다. 1년에 나가는 만 오천 원은 전부 도메인 값이에요. victor-house.com 이라는 이름값으로 1년에 10달러 46센트를 냈습니다.

파일을 쌓아두고 나눠주는 일은 Cloudflare Pages가 공짜로 해줍니다. 전 세계에 서버를 깔아둔 회사인데, 미리 만들어진 파일을 나눠주는 정도는 무료로 열어놨어요. 만드는 건 제 맥미니가 하고, 나눠주는 건 그쪽이 하는 구조입니다.

공짜인데 성능이 나쁘냐면 그것도 아니에요. 오히려 반대입니다. 미리 만들어둔 파일은 세상에서 제일 빠르게 나갈 수 있는 형태거든요. 계산할 게 없으니까요.

궁금해서 재봤습니다. 글 하나를 불러오는 데 걸린 시간이 0.19~0.22초, 받아온 크기가 57KB였어요. 이 중에 실제로 뭘 계산하느라 쓴 시간은 0초입니다. 이미 만들어져 있는 걸 집어서 건네준 게 전부니까요.

그리고 이 구조에는 이런 성질도 있습니다. 사람이 많이 몰려도 느려지지 않아요. 주문받고 요리하는 식당은 손님이 몰리면 주방이 밀리는데, 도시락은 그냥 집어가는 거라 백 명이 와도 천 명이 와도 하는 일이 똑같거든요. 언젠가 글 하나가 갑자기 퍼지더라도 사이트가 죽을 걱정은 안 해도 됩니다.

물론 그래서 다들 정적으로 가면 되느냐면, 그건 아니에요. 손님마다 다른 걸 보여줘야 하는 사이트는 이렇게 못 만듭니다. 쇼핑몰의 장바구니, 회원제 서비스, 실시간 채팅 같은 건 주방이 계속 돌아가야 하거든요. 제 사이트는 누가 봐도 같은 걸 보여주는 사이트라 이 방식이 맞았을 뿐입니다.

이건 성경 아틀라스라는 도구인데요. 지형 지도 위에 시대별 국경과 영향력을 겹쳐 그리고, 성경 구절로 장소를 찾아가는 물건입니다. 꽤 복잡해 보이시죠.

이것도 서버가 없습니다. 지도도, 국경도, 구절 데이터도 전부 미리 만들어둔 파일이에요. 브라우저가 그걸 받아서 자기 안에서 그립니다. 제 쪽에서 도는 컴퓨터는 한 대도 없어요.

없어서 못 하는 것들

여기까지만 들으면 "그럼 다 이렇게 하지 왜 서버를 쓰나" 싶으실 텐데요. 못 하는 게 분명히 있습니다.

미리 만들어둔 파일은 누가 뭘 해도 안 바뀝니다. 그러니까 이런 게 전부 안 돼요.

• 로그인 — 누가 누군지 기억할 데가 없습니다
• 댓글 — 누가 글을 남겨도 받아 적을 데가 없습니다
• 조회수 — 몇 명이 봤는지 셀 데가 없습니다
• 문의 접수 — 폼을 채워 보내도 받을 데가 없습니다
• 글 검색 — 285편 중에서 찾아줄 놈이 없습니다

이게 정적 사이트의 정직한 대가입니다. 그런데 제 사이트에는 댓글이 있어요.

로그인 없이 쓸 수 있고, 조회수도 세고 있고요.

방법은 그 부분만 남의 것을 빌려 쓰는 것이었습니다. 댓글과 조회수는 Supabase라는 데이터 보관소를, 문의 접수는 Web3Forms라는 서비스를 빌렸어요. 제 서버는 여전히 없고, 브라우저가 필요할 때만 그쪽에 직접 물어봅니다.

이 "직접"이 중요한데요. 원래는 이렇게 굴러갑니다.

[보통]   브라우저 →  내 서버  →  데이터 보관소
[제 것]  브라우저 ──────────→  데이터 보관소

중간에 있던 제 서버가 통째로 빠진 거예요. 그래서 돈이 안 나가는 거고요. 그리고 같은 이유로, 원래 그 자리에서 문지기 노릇을 하던 것도 같이 사라졌습니다.

3편 끝에 "메일 버튼을 눌러도 아무 일이 없다"는 제보 얘기를 드렸잖아요. 그걸 고칠 때 우상단의 신고·제안 위젯으로 바꿨는데, 그것도 같은 방식입니다. 메일 앱을 거치지 않고 브라우저가 그 서비스로 바로 쏘는 구조예요.

공짜로 얻은 게 아니라 구멍을 하나씩 메운 겁니다. 그리고 그렇게 메우면 새로운 문제가 따라옵니다 — 서버가 중간에 없으니까 "누가 아무거나 마구 쓰는 것"을 막아줄 문지기도 없거든요. 그 얘기는 25편에서 제대로 하겠습니다. 오늘은 "빌려서 메웠다"까지만요.

검색은 아예 다른 방법으로 풀었습니다. 글이 285편이라 찾는 기능이 필요한데, 서버가 없으니 "찾아줘"라고 물어볼 데가 없잖아요.

그래서 찾는 일을 브라우저한테 시켰습니다. 글 목록 페이지를 만들 때 285편의 제목·첫 문단·카테고리를 페이지 안에 같이 넣어두고, 검색창에 뭘 치면 브라우저가 그 자리에서 걸러냅니다. 서버에 물어보는 게 아니라 이미 손에 들고 있는 목록을 훑는 것이라 누르는 즉시 결과가 나와요.

이건 글이 285편이라 되는 방법입니다. 몇 만 편이 되면 목록을 통째로 들고 다닐 수가 없어서 다른 수를 써야 해요. 지금 규모에 맞는 답이 뭔지를 보고 고른 것이지, 원래 이렇게 하는 게 정석이라서는 아닙니다.

대신 인터넷 없이도 열립니다

정적 사이트에는 좀 이상한 성질이 하나 있습니다. 파일이 곧 사이트라서, 파일만 있으면 인터넷이 없어도 돌아갑니다.

3편에서 만든 육아휴직 계산기를 제 컴퓨터에서 그냥 더블클릭해서 연 화면이에요.

그리고 이건 같은 물건을 인터넷 주소로 연 화면입니다.

똑같죠. 같은 파일이니까요. 비행기 안에서도, 인터넷이 끊겨도 계산은 그대로 됩니다.

3편에서 제가 "요즘 방식 대신 옛날 방식으로 짰다"고 지나가듯 말씀드린 게 있는데요. 요즘 방식으로 짜면 파일을 직접 열었을 때 브라우저가 보안 규칙으로 막아버립니다. 그때는 그냥 제약이었는데, 여기서 값을 하더라고요. 서버 없이 열리는 성질이 그 선택 덕에 남았습니다.

"예약 발행"이라는 기능은 없습니다

지금 읽고 계신 이 글이 예입니다.

이 글은 어제 오후에 썼고, 오늘 아침 9시에 나왔습니다. 블로그 서비스라면 "예약 발행" 버튼을 누르면 끝날 일이죠. 그런데 서버가 없으면 그날이 됐다고 알아서 공개해줄 놈이 없습니다. 미리 만들어둔 파일은 만들어진 그 순간부터 그냥 거기 있을 뿐이거든요.

그래서 이렇게 흉내를 냅니다.

글 머리에 작성일을 적어두고요. 사이트를 만들 때 아직 날짜가 안 된 글은 아예 만들지 않습니다. 그리고 매일 아침 9시에 사이트를 통째로 다시 만들어 올려요. 그날이 되면 그 글이 자연히 딸려 나갑니다.

연재 목차를 보시면 아직 안 쓴 편이 회색으로 있잖아요. 저 회색이 하나씩 검은 글씨로 바뀌는 게 그 방식으로 일어나는 일입니다.

무식한 방법 같은데, 여기서 뜻밖의 게 하나 붙었어요. 글을 전날 오후에 써두면 하룻밤이 남습니다.

자고 일어나 다시 읽으면 어제는 안 보이던 게 보이더라고요. 문장이 길어서 숨이 찬 데, 설명을 건너뛴 데, 사진이 엉뚱한 자리에 붙은 데 같은 것들이요. 어제의 저는 그게 다 말이 된다고 생각했거든요.

원래는 서버가 없어서 어쩔 수 없이 택한 방식이었는데, 결과적으로 하루를 묵히는 습관이 됐습니다. 버튼 하나로 바로 올라가는 구조였으면 아마 안 했을 일이에요.

용량이 곧 배포입니다

정적 사이트의 또 다른 성질은 가진 걸 전부 올려야 한다는 겁니다. 서버가 있으면 필요할 때 꺼내 쓰면 되지만, 여기서는 파일이 전부 올라가 있어야 하거든요.

네이버 블로그에서 옮겨온 사진이 3,116장이었습니다. 원본 그대로면 1,063MB예요.

그래서 올리는 사본만 가로 1,400픽셀로 줄이고 품질을 82로 낮췄습니다. 1,063MB가 315MB가 됐어요. 원본은 제 컴퓨터에 그대로 있고, 올라가는 건 줄인 사본입니다.

블로그 글 사진은 화면에서 보이는 크기가 정해져 있어서, 그보다 큰 원본을 올려봐야 독자는 차이를 못 느낍니다. 대신 느려지는 건 확실히 느끼고요. 이건 사람이 정해야 하는 값이었어요. 어디까지 줄여도 티가 안 나는지는 자기 사진을 보면서 판단하는 수밖에 없습니다.

화면은 멀쩡한데 안이 깨져 있는 경우

정적 사이트에는 무서운 구석이 하나 있습니다. 뭔가 잘못돼도 아무도 안 알려준다는 거예요.

서버가 있으면 오류가 났을 때 기록이 남습니다. 그걸 보고 "아 여기가 터졌구나" 하고 알죠. 그런데 제 쪽에는 돌아가는 컴퓨터가 없으니까 기록도 없습니다. 파일은 조용히 잘못된 채로 놓여 있고, 그걸 받아 간 사람의 브라우저 안에서만 조용히 고장 납니다.

제일 골치 아픈 형태가 이거예요. 화면은 멀쩡해 보입니다. 글도 잘 나오고 사진도 잘 뜨고요. 그런데 댓글 폼에 글을 쓰고 등록을 눌러도 아무 일이 안 일어납니다. 눌리기만 하고요.

한글 문장 하나가 줄바꿈을 잘못 먹으면 실제로 이런 일이 납니다.

위쪽이 그 상태고요. 이걸 배포하면 사이트는 정상으로 보이는데 댓글만 죽어 있게 됩니다. 저는 며칠 뒤에 "댓글이 안 달리는데요"라는 제보를 받고 알게 되겠죠.

그래서 사이트를 만드는 마지막 단계에 검사를 하나 넣어뒀습니다. 만들어진 페이지 306장을 하나씩 열어서 안에 든 스크립트가 문법적으로 말이 되는지 확인하고, 하나라도 깨져 있으면 배포 자체를 멈춥니다. 아래쪽이 그 메시지예요.

이건 AI가 알아서 넣어준 게 아닙니다. "이게 깨지면 내가 어떻게 알게 되지?"를 한 번 물어봐야 나오는 장치예요. 서버가 없으면 그 질문을 아무도 대신 해주지 않습니다.

망가뜨려도 옛날 것은 그대로 남아 있어요

통째로 다시 만들어 올린다는 건, 뒤집어 말하면 한 번에 통째로 망가뜨릴 수 있다는 뜻이기도 합니다. 잘못 만든 사이트를 올리면 304장이 한꺼번에 잘못됩니다.

그런데 여기에 안전장치가 하나 딸려 있어요.

배포할 때마다 그때 그 사이트가 자기 주소를 하나씩 받습니다. 위에 보이는 8594b59e.victor-house.pages.dev 같은 주소요. 저건 하루 전 배포인데, 지금 열어봐도 그대로 열립니다(응답 200). 새로 올린다고 옛날 게 지워지는 게 아니라, 옛날 것들이 자기 주소를 달고 그대로 쌓여 있는 거예요.

그러니까 뭘 잘못 올렸을 때 "어제 것으로 돌려놔"가 가능합니다. 백업을 따로 뜨지 않았는데도요.

미리 만들어둔 파일 덩어리라서 생긴 성질입니다. 서버가 도는 사이트는 어제 상태로 되돌리는 게 훨씬 큰일이거든요. 그 안의 데이터도 같이 어제로 가야 하니까요.

그래서 사람은 어디에 있었나

오늘 편은 코드보다 선택에 관한 얘기였습니다. 정리하면 이렇게 됩니다.

AI가 잘한 것. 정적 사이트로 가면 뭘 못 하게 되는지 목록을 뽑아준 것, 그 각각을 어떻게 우회할 수 있는지 방법을 준 것, 이미지를 줄이고 바뀐 것만 올리는 배포 절차를 짜준 것. 이런 건 정확하고 빠릅니다.

사람이 정해야 했던 것.

• 애초에 서버를 안 쓰기로 한 것. 이건 기술 판단이 아니라 "매달 돈 나가는 걸 감당할 마음이 있느냐"는 생활 판단이었습니다
• 못 하게 되는 것들 중에 뭘 메우고 뭘 미룰지. 댓글은 남의 것을 빌려 메웠고, 검색은 브라우저에 떠넘겨 풀었습니다
• 사진을 어디까지 줄여도 되는지. 숫자로는 답이 안 나옵니다. 자기 사진을 보고 정해야 해요
• "이게 깨지면 내가 어떻게 알게 되지?"를 물어본 것. 오류가 안 알려지는 구조라는 걸 알아채고 검사를 끼워 넣은 것
• 예약 발행이 없다는 걸 불편으로 볼지, 검토 시간으로 쓸지

특히 마지막 게 이 편에서 제일 마음에 드는 대목입니다. 제약이 생겼을 때 그걸 없애려고만 들면 서버를 하나 빌리게 됩니다. 그런데 "이 제약이 나한테 뭘 주고 있나"를 한 번 보면 다른 답이 나오기도 하더라고요.

AI는 제약을 없애는 방법을 잘 찾아줍니다. "예약 발행이 없다"고 하면 그걸 만들 방법을 몇 가지 대줄 거예요. 그런데 그 제약을 그냥 두는 편이 나은 경우가 있다는 건, 아직 사람이 판단해야 하는 것 같습니다. 없애야 할 불편인지 지켜야 할 여유인지는, 그걸로 뭘 하며 사는지를 아는 쪽이 정하는 거니까요.

한 가지 더 붙이자면, 오늘 얘기한 것 중에 "이렇게 하면 싸고 빠릅니다"에 해당하는 건 절반뿐이었어요. 나머지 절반은 못 하는 것, 깨져도 모르는 것, 통째로 망가질 수 있는 것이었습니다. 공짜인 데는 이유가 있고, 그 이유를 알고 고르는 것과 모르고 고르는 것은 나중에 아주 달라지더라고요.

다음 편에

여기까지가 "무엇으로, 어떻게, 어디에" 였습니다. 이제 실제로 도구 하나가 처음부터 끝까지 어떻게 나오는지를 볼 차례예요.

다음 편은 도구 하나가 나오기까지 — 기획·코드·검증의 실제 흐름입니다. 3편이 계산기 하나의 하루를 시간순으로 따라간 거였다면, 다음 편은 그 흐름을 틀로 정리해봅니다. 제가 도구를 열몇 개 만들면서 매번 반복하게 된 순서가 있거든요. 그게 왜 그 순서인지, 건너뛰면 어디서 터지는지를 적을게요.

읽다가 궁금한 게 있으면 댓글로 남겨주세요. 로그인 없이 쓸 수 있습니다.

#정적사이트 #StaticSite #클라우드플레어 #CloudflarePages #무료호스팅 #서버비 #도메인 #웹사이트만들기 #홈페이지제작 #개인홈페이지 #블로그이전 #네이버블로그 #Supabase #웹개발 #프론트엔드 #HTML #AI코딩 #클로드 #ClaudeCode #바이브코딩 #1인개발 #사이드프로젝트 #자동배포 #예약발행 #이미지최적화 #휴먼인더루프 #AI활용법 #AI와사이트만들기 #개발일지 #빅터하우스