웹호스팅에서 서버리스까지 — 비용보다 달라진 개발자의 책임

예전에는 웹호스팅 계정 하나를 만들고 파일을 올리면 서비스가 시작됐습니다. 지금은 서버리스 함수, 오브젝트 스토리지, CDN, 관리형 데이터베이스를 조합해 훨씬 빠르게 시작할 수 있습니다. 대신 어디서 문제가 생겼는지 추적해야 할 지점도 늘었습니다.

저는 비용이 싸다는 이유만으로 구조를 고르지 않으려고 합니다. 월 요금보다 중요한 것은 장애가 났을 때 누가 무엇을 확인해야 하는지, 데이터가 어디에 있고 어떻게 복구하는지 알 수 있는가입니다.

호스팅 시대에는 책임이 한 덩어리였습니다

공유 호스팅에서는 운영자가 관리할 수 있는 범위가 제한적이었습니다. 웹 서버 설정과 데이터베이스가 이미 준비돼 있었고, 사용자는 파일과 애플리케이션에 집중했습니다. 문제가 생기면 고객센터에 문의하는 것도 운영의 일부였습니다.

이 구조는 단순하지만 확장과 세밀한 관찰이 어렵습니다. 어떤 요청이 느린지, 특정 경로의 비용이 얼마나 되는지, 데이터가 어떤 상태인지 직접 확인하기 어려운 경우가 많았습니다.

• 장점: 시작이 빠르고 운영 대상이 적습니다.
• 한계: 성능·보안·백업 정책을 세밀하게 바꾸기 어렵습니다.
• 운영 질문: 장애가 생겼을 때 제공업체와 내 코드의 경계를 확인해야 합니다.

서버리스는 서버를 없애지 않고 책임을 나눕니다

서버리스는 서버가 없다는 뜻이 아니라, 서버의 프로비저닝과 확장을 제공업체에 맡긴다는 뜻에 가깝습니다. 개발자는 함수 실행 시간, 동시성, 로그, 호출량, 권한을 관리해야 합니다. 서버를 직접 패치하지 않는 대신 사용량과 경계를 더 자주 확인합니다.

특히 요청이 늘면 비용도 함께 늘어날 수 있습니다. 무료 한도만 보고 시작하지 말고, 호출량 상한과 실패 시 응답을 먼저 설계해야 합니다.

구성편해진 책임새로 생긴 책임

함수	서버 패치·확장	실행 시간·재시도·동시성
오브젝트 저장소	디스크 관리·복제	권한·키 구조·보존
엣지 제한	기본 방어 인프라	경로별 제한·오탐·관찰

오브젝트 스토리지는 백업과 서비스 데이터를 구분해야 합니다

파일을 저장하기 쉽다는 이유로 원본과 백업을 같은 버킷에 섞으면 복구가 어려워집니다. 저는 원본, 공개 자산, 백업을 키 접두사부터 나눕니다. 수명주기 규칙도 각 영역의 보존 목적에 맞게 다르게 둡니다.

Cloudflare R2 같은 저장소는 S3 호환 API와 에그레스 비용 구조가 장점일 수 있지만, 권한과 삭제 정책은 직접 설계해야 합니다. 관리형이라는 말이 데이터 책임까지 없애 주지는 않습니다.

• 키 구조: 원본·공개·백업을 접두사와 버킷으로 구분합니다.
• 권한: 애플리케이션에 필요한 최소 권한만 부여합니다.
• 복구: 삭제하지 않은 복사본으로 실제 복구 절차를 시험합니다.

비용표보다 먼저 장애 시나리오를 적습니다

인프라를 선택할 때 저는 ‘어느 쪽이 더 싼가’보다 ‘무엇이 고장 날 수 있는가’를 먼저 적습니다. 함수 호출이 폭증했을 때, 저장소 권한이 잘못됐을 때, 로그가 없어 원인을 모를 때의 대응을 한 줄씩 써 봅니다.

이 기록이 있으면 비용이 조금 높더라도 운영자가 감당할 수 있는 구조를 고를 수 있습니다. 1인 서비스에서 가장 비싼 비용은 예상하지 못한 새벽 장애일 때가 많기 때문입니다.

작게 시험하고 다음 주에 다시 봅니다

생활과 일의 문제는 한 번에 해결되지 않습니다. 저는 새 원칙을 정할 때 먼저 일주일 동안 확인할 수 있는 행동으로 줄입니다. 예를 들어 일거리의 범위를 정리한다면 모든 계약을 다시 쓰기보다, 이번 주에 들어온 요청 세 건을 같은 표에 기록해 봅니다. 창작 경계를 세우는 경우에도 하루 전체를 바꾸지 않고 알림을 끄는 시각 하나만 정합니다. 작은 실험은 실패했을 때 비용이 작고, 성공했을 때 무엇이 영향을 주었는지 설명하기 쉽습니다.

실험이 끝난 뒤에는 결과를 성과와 실패로만 나누지 않습니다. 예상보다 쉬웠던 점, 예상보다 오래 걸린 점, 다른 사람에게 설명하기 어려웠던 점을 적습니다. 이 기록이 있어야 다음 주에 같은 실수를 반복하지 않고 조건을 조정할 수 있습니다. 다른 사람의 조언을 참고하더라도 내 생활과 서비스의 제약을 먼저 적어야 합니다.

• 현재 상태: 지금 어떤 일이 반복되고 무엇이 가장 자주 막히는지 사실로 적습니다.
• 작은 실험: 일주일 안에 확인할 행동 하나와 하지 않을 행동 하나를 정합니다.
• 관찰 신호: 시간·체력·집중·요청 수처럼 실제로 기록할 수 있는 신호를 고릅니다.
• 다음 결정: 계속·축소·중단 중 하나를 다음 회고에서 선택합니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

웹호스팅에서 서버리스로 옮겨 온 변화는 서버가 사라진 것이 아니라 책임의 위치가 달라진 것입니다. 다음 인프라 선택에서는 가격표 옆에 장애·권한·복구 질문을 함께 적어 보시기 바랍니다.

참고한 문서: Cloudflare R2 개요 · Cloudflare Rate Limiting