스토리지와 CDN이란 무엇인가 — 파일은 어디에 두는가

왜 이미지를 표에 넣지 않는가

앞 편에서 데이터베이스가 엑셀처럼 생겼다고 했다. 이름과 날짜와 숫자를 한 줄씩 쌓기 좋은 구조다.

사진과 영상은 그 칸에 넣을 물건이 아니다. 개념적으로는 넣을 수 있다. 그런데 효율이 안 난다.

이유는 꺼내 오는 방식에 있다. 목록 화면 하나를 그리려고 스무 줄을 조회하는데, 각 줄에 이미지가 통째로 들어 있으면 화면에 안 보일 이미지까지 전부 끌려 나온다. 데이터베이스는 그런 무거운 덩어리를 자주 오가라고 만든 도구가 아니다.

그래서 갈라 둔다. 파일 자체는 파일 보관소에 두고, 데이터베이스에는 그 파일이 어디 있는지 경로만 적는다.

posts 테이블
─────────────────────────────────────────────
id  title        cover_path
1   첫 글        /uploads/2026/09/cover-1.webp
2   둘째 글      /uploads/2026/09/cover-2.webp

① 화면이 posts 를 조회해 cover_path 를 읽는다
② 그 경로로 스토리지에 파일을 따로 요청한다

스토리지와 두 번의 요청

파일을 두는 보관소를 스토리지라고 한다. 서비스가 작으면 서버 안의 폴더일 수도 있고, 커지면 파일 전용 서비스를 따로 쓴다.

이 구조에서 화면은 요청을 두 번 한다. 먼저 백엔드에 값을 물어 경로를 받고, 그다음에 그 경로로 파일을 따로 요청한다. 브라우저가 이미지 주소를 만나면 알아서 두 번째 요청을 보내므로 사람이 신경 쓸 일은 아니다.

값을 주는 쪽과 파일을 주는 쪽을 나눠 두면 서버를 따로 둘 수도 있다. 값은 값대로 잘 응답하는 서버가 맡고, 파일은 파일대로 잘 내보내는 서버가 맡는다. 성격이 다른 일이라 나누는 편이 각자 잘한다.

CDN — 거리와 빈도를 다루는 층

여기에 한 가지가 더 붙는다. 거리 문제다.

미국에 있는 서버에 이미지를 올려 두었는데 한국에서 보는 사람이 있다고 하자. 요청은 해저 케이블을 타고 태평양을 건너간다. 텍스트 한 줄이면 몰라도 이미지나 영상처럼 큰 덩어리가 매번 그 거리를 왕복하면 느리다.

그래서 사본을 미리 뿌려 둔다. 자주 쓰이는 파일을 세계 곳곳의 거점에 복사해 두고, 요청이 오면 그 사람에게서 가장 가까운 거점이 내보낸다. 이 그물을 CDN이라고 한다. 콘텐츠 전송 네트워크의 줄임말이다.

빈도도 다룬다. 사이트 로고는 방문자마다 불러 가지만 인기 없는 글의 이미지는 거의 안 불려 간다. 앞의 것은 늘 가까이 준비해 두고 뒤의 것은 요청이 올 때 원본에서 가져오는 편이 낫다. 그 판단을 대신해 주는 것이 이 층이 하는 일이다.

사이트가 느리다는 말의 상당수는 여기서 시작된다

느리다는 신고를 받으면 코드부터 열기 쉽다. 그런데 실제로는 이 층인 경우가 많다.

확인할 것이 몇 가지 정해져 있다. 이미지가 원본 크기 그대로 나가고 있지는 않은가. 화면에서 가로 400픽셀로 보이는 자리에 4000픽셀짜리 파일을 보내면 그만큼의 시간이 그냥 버려진다.

형식도 본다. 같은 그림이라도 웹용으로 만들어진 형식이 훨씬 가볍다. 그리고 거리와 캐시를 본다. 사본이 가까운 곳에서 나가고 있는지, 한 번 받은 파일을 브라우저가 다시 안 받아도 되게 설정돼 있는지다.

브라우저 개발자 도구의 네트워크 탭을 열면 어떤 파일이 얼마나 걸렸는지가 그대로 보인다. 코드를 고치기 전에 여기부터 보면 대개 답이 나온다. 다음 편은 마지막으로, 이 전체를 다른 컴퓨터로 옮기는 이야기다.