데이터 전송 비용의 함정

포갬은 사진과 동영상을 클라우드에 저장하는 서비스다. 공유 캘린더도 함께 제공한다.

그래서 포갬을 만들면서 스토리지에 대한 고민을 꽤 많이 했다. 파일을 잘 저장하는 것도 중요했지만, 그 파일을 얼마나 자주 꺼내서 보여주게 될지가 더 신경 쓰였다.

혼자 쓰는 서비스라면 내가 올린 사진을 내가 다시 보는 정도로 생각할 수 있다. 그런데 공유 캘린더에서는 같은 사진과 동영상을 여러 사람이 열어볼 수 있다. 사진 한 장을 저장했다고 해서, 전송도 한 번으로 끝나는 게 아니었다.

DB는 이미 Supabase를 사용하고 있었다. 그래서 스토리지도 가장 먼저 Supabase Storage를 검토했다. 같은 서비스 안에서 DB와 인증, 파일까지 연결하면 개발하는 입장에서는 꽤 편하기 때문이다.

결론부터 말하자면... DB는 Supabase를 사용하고, 사진과 동영상을 저장하는 스토리지는 결국 Cloudflare R2로 선택했다.

그 선택에서 가장 크게 본 건 저장 용량보다 전송량이었다.

사진은 한 번 올렸는데, 전송은 계속 일어난다

처음에는 스토리지 비용을 보면 “몇 GB까지 저장할 수 있지?”부터 보게 된다.

그런데 파일을 보관하는 비용과, 그 파일을 사용자에게 보내는 비용은 따로 계산해야 했다. 서버 밖으로 나가는 데이터 전송량을 보통 egress라고 부른다.

3MB짜리 사진 한 장을 저장했다고 해보자. 저장한 파일은 3MB다. 하지만 이 사진을 여러 사람에게 합쳐서 1만 번 보내면 전송량은 약 30GB가 된다. 매번 원본 전체를 보낸다는 단순한 계산이다.

공유 캘린더에서 특히 신경 쓴 부분이 이거였다. 새로운 사진이 많이 올라오지 않아도, 기존 사진을 여러 사람이 다시 보는 것만으로 전송량이 늘어날 수 있었다. 동영상까지 생각하면 차이는 더 커진다.

바이브코딩으로 업로드 기능을 붙이는 건 빨라졌다. 사진이 잘 올라가고 화면에 잘 보이면 일단 기능은 완성된 것처럼 느껴진다. 그런데 그 화면을 사람들이 매일 열었을 때의 비용은 따로 계산해봐야 했다.

Supabase가 제일 편해 보이긴 했다

이미 DB를 Supabase로 쓰고 있으니, Storage도 같이 쓰는 게 가장 자연스러웠다.

인증과 연결하기 편하고, 파일 접근 권한도 RLS 정책으로 관리할 수 있다. 다른 서비스를 추가로 연결하고 권한을 구현하는 시간을 줄일 수 있다는 건 분명한 장점이었다.

다만 요금표에서 저장 공간 다음으로 봐야 하는 항목이 있었다. 전송량이었다.

Supabase Pro에는 저장 공간 100GB가 포함된다. 전송량은 캐시된 전송과 캐시되지 않은 전송에 각각 월 250GB가 포함되고, 초과분은 각각 GB당 $0.03, $0.09다. 비캐시 전송량은 Storage뿐 아니라 DB와 Auth 등의 사용량과도 합산된다.

숨겨진 비용이라고 느끼기 쉽지만, 요금표에 없는 비용은 아니다. 개발할 때 저장 용량만 보면 지나치기 쉬운 비용에 가까웠다.

S3와 R2도 같이 놓고 봤다.

S3가 항상 비싸고 Supabase가 항상 싸다고 말할 수는 없다. 어디에 저장하고, 어떤 경로로 보내고, 캐시가 얼마나 동작하는지에 따라 달라진다. 그래서 포갬처럼 사진과 동영상을 자주 보여주는 상황을 하나 가정해서 계산해봤다.

DAU 1,000명이 매일 사진과 동영상을 본다면

DAU는 하루에 서비스를 사용하는 사람 수다. 1,000명이라는 숫자만으로 비용이 정해지는 건 아니다. 한 사람이 하루에 얼마나 많은 데이터를 내려받는지까지 가정해야 한다.

여기서는 아래 조건을 놓고 비교했다. 포갬의 실제 사용량이나 청구액이 아니라, 스토리지 선택을 설명하기 위한 예상 시나리오다.

동영상 하나만 열어봐도 수십 MB가 오갈 수 있다. 사진 목록의 썸네일만 보는 사용자와 원본 사진·동영상을 보는 사용자는 전송량이 다르다. 여기서는 그 차이를 평균 100MB로 묶었다.

비교는 Supabase Pro를 DB 때문에 이미 사용한다고 가정하고, 스토리지 때문에 추가로 드는 비용만 봤다. Pro 기본 요금과 DB 비용은 제외했다. Supabase와 AWS의 전송 무료 포함량은 다른 기능에서 아직 쓰지 않았다고 가정했다.

리전을 선택할 수 있는 서비스는 서울을 기준으로 봤다. Supabase는 서울 프로젝트를 가정해 Pro의 공통 Storage 단가를 적용했고, S3는 서울 리전(ap-northeast-2)의 Standard에서 사용자에게 직접 전송하는 경우로 계산했다. R2는 지역별 요금표가 따로 없어 Standard 공통 단가를 적용했다. Supabase는 캐시가 전혀 없는 경우와 전송 바이트의 80%가 캐시된 경우를 나눠봤다.

2026년 9월 요금을 적용한 단순 추정이다. GB 단위 차이와 시간별 집계는 단순화했고, 세금·프로모션 크레딧·이미지 변환·CDN·앱 서버 비용은 제외했다. 쓰기 요청은 추가 멀티파트·목록 요청 등을 포함하지 않는 기본 요청 수로 가정했다.

계산에서 차이가 컸던 건 저장 비용이 아니었다.

Supabase의 비캐시 전송은 3,000GB에서 포함량 250GB를 빼고, 남은 2,750GB에 $0.09를 곱했다. 전송 비용만 $247.50이었다.

캐시된 전송이 80%라면 캐시 전송 2,400GB와 비캐시 전송 600GB를 따로 계산한다. 각각의 250GB 포함량을 빼면 전송 비용은 $64.50 + $31.50, 총 $96으로 줄어든다. 캐시가 비용에 미치는 영향도 꽤 컸다.

S3는 서울 리전에서 인터넷으로 직접 보내는 첫 유료 구간의 단가인 GB당 $0.126을 적용했다. AWS 전체에서 공유하는 월 100GB 무료 전송량을 빼면, 전송 비용만 약 $365.40이다. CloudFront 같은 CDN이나 별도 플랜을 쓰면 계산은 달라진다.

R2는 평균 보관량 500GB에서 무료 10GB-month를 빼고, 490GB에 $0.015를 곱했다. 읽기 200만 회와 쓰기 10만 회는 각각 월 무료 포함량인 1,000만 회와 100만 회 안에 들어간다. 이 가정에서는 약 $7.35가 남았다.

물론 하루에 100MB가 아니라 10MB만 내려받는다면 월 전송량도 300GB로 줄어든다. 캐시 비율이나 기존 포함량 사용 여부에 따라서도 결과가 달라진다. 그래도 사진과 동영상을 여러 사람이 반복해서 보는 서비스에서는, 저장 단가 몇 센트보다 전송 요금이 더 크게 영향을 줄 수 있다는 점은 분명했다.

그래서 파일은 R2에 저장하기로 했다

포갬에서는 공유 캘린더를 쓰는 사람이 늘고, 사진과 동영상을 더 자주 열어보는 상황을 생각해야 했다.

그때마다 전송 비용까지 같이 커지는 구조는 신경이 쓰였다. 저장 비용과 요청 비용은 남더라도, R2 자체의 egress 요금이 없다는 점이 선택에 가장 크게 작용했다.

그래서 DB는 이미 쓰고 있는 Supabase로 두고, 파일 저장은 R2로 나눴다. DB와 스토리지를 꼭 같은 서비스에서 해결할 필요는 없었다.

다만 R2를 선택했다고 파일을 보여주는 방식을 대충 만들어도 되는 건 아니었다.

작은 사진 목록에 원본을 매번 내려주면 화면도 느려지고 사용자의 데이터도 많이 쓴다. 3MB 원본 대신 300KB 썸네일을 보내면 같은 횟수의 조회에서도 데이터 양은 10분의 1로 줄어든다. 썸네일을 만들고 보관하는 비용은 따로 고려해야 한다.

파일이 지나가는 경로도 중요하다. R2의 파일을 앱 서버가 받아서 다시 사용자에게 보내면 앱 서버 쪽 전송 비용이 생길 수 있다. 비공개 파일은 사용자 권한을 확인하고 임시 접근 URL을 발급하는 흐름도 필요하다.

결국 포갬에서 고민한 건 “어디가 가장 싸지?”만은 아니었다. 지금 만들기 편한 선택과, 사람들이 매일 사용했을 때 감당할 수 있는 선택을 같이 봐야 했다.

스토리지도 한 번 고르고 끝나는 문제가 아니었다. 사용자가 늘고 사진과 동영상을 보는 방식이 바뀌면 비용도 달라진다. 그래서 운영하면서 사용량을 계속 확인하고, 불필요한 저장과 요청, 전송을 줄이는 쪽으로 인프라 비용을 꾸준히 최적화해야 한다.

AI에게 지시할 때도 마찬가지다. “파일 업로드 기능을 만들어줘”라고만 하면, 비용까지 고려한 구조가 나올 거라고 기대하기 어렵다. 어떤 스토리지를 쓸지, 파일은 어떤 경로로 전달할지, 원본과 썸네일은 언제 불러올지까지 명확하게 정해줘야 한다.

바이브코딩으로 기능을 만드는 속도는 빨라졌다. 하지만 서비스 운영은 공짜가 아니다. 빠르게 만드는 것만큼, 계속 감당할 수 있는 비용으로 운영하는 것도 개발의 일부라고 생각한다.