사진·첨부 파일 저장
손님이 올린 사진이나 첨부 파일은 데이터베이스가 아니라 따로 있는 파일 창고에 두고, 데이터베이스에는 그 파일이 어디 있는지 주소만 적어요. 장부에는 글자를, 창고에는 물건을 두는 거예요.
쉽게 말하면
손님 명부에는 이름과 연락처를 글자로 적죠. 그런데 손님이 준 사진까지 명부에 풀로 붙이기 시작하면 어떻게 될까요. 명부가 금세 두꺼워져서 넘기기도 힘들고, 한 장 찾으려면 한참 뒤져야 해요. 그래서 사진은 창고의 앨범 선반에 따로 보관하고, 명부에는 "이 손님 사진은 3번 선반"이라고 위치만 적어요. 서비스도 똑같아요. 글자와 숫자는 데이터베이스에, 사진과 첨부 파일은 파일 창고(스토리지)에 두고, 데이터베이스에는 파일의 주소만 남겨요.
엑셀로 바꿔 말하면 더 분명해요. 엑셀 시트는 칸마다 글자와 숫자를 넣으라고 만든 표예요. 그런데 칸마다 사진을 통째로 붙여 넣으면, 파일이 수백 메가로 부풀어서 여는 데만 몇 분씩 걸려요. 데이터베이스도 같은 성격이에요. 표는 글자용이고, 사진은 표 바깥에 두는 게 정상이에요.
표가 사진 무게에 눌려요. 이름 하나 찾는 검색까지 같이 느려지고, 백업도 몇 배로 무거워져요.
표는 글자만 있으니 계속 빨라요. 사진은 사진 전용 창고가 맡아서, 몇만 장이 돼도 각자 제 속도를 내요.
무엇을 어디에 두나
나누는 기준은 간단해요. 눈으로 읽는 글자·숫자는 데이터베이스, 파일 그 자체는 창고예요. 헷갈릴 때는 "이걸 엑셀 칸에 타이핑할 수 있나?"를 물어보세요. 타이핑할 수 있으면 데이터베이스, 없으면 창고예요.
| 이것은 | 어디에 | 왜 |
|---|---|---|
| 손님 이름·연락처·예약 날짜 | 데이터베이스 | 글자와 숫자예요. 검색하고 정렬하는 게 일이에요 |
| 손님 프로필 사진 | 파일 창고 (표에는 주소만) | 파일이에요. 표에 넣으면 표가 무거워져요 |
| 리뷰 글 | 데이터베이스 | 글자예요 |
| 리뷰에 첨부된 사진 3장 | 파일 창고 (표에는 주소 3줄) | 파일이에요. 리뷰 글과 사진 주소가 표에서 짝을 이뤄요 |
| 메뉴판 PDF·계약서 스캔본 | 파일 창고 | 역시 파일이에요. 첨부 문서는 전부 창고행이에요 |
| 가게 로고·대표 사진 몇 장 | 코드와 함께 배포 | 사장님이 넣는 고정 이미지는 창고 없이도 돼요. 아래에서 다시 설명해요 |
표에 남기는 "주소"는 인터넷 주소(URL) 한 줄이에요. 예를 들어 손님 표의 사진 칸에는 사진 원본 대신 `https://…/photos/1042.jpg` 같은 글자 한 줄이 들어가요. 화면은 그 주소를 보고 창고에서 사진을 꺼내 와 보여줘요. 명부에 적힌 "3번 선반"을 보고 창고에 가는 것과 똑같아요.
실제로 보게 될 이름들
파일 창고를 파는 회사들이 있고, 저마다 부르는 이름이 달라요. 개발자나 AI가 이 단어들을 쓰면 전부 "파일 창고" 이야기라고 알아들으면 돼요.
| 이름 | 무엇인가 |
|---|---|
| 스토리지(storage) | 파일 창고를 부르는 가장 일반적인 말이에요. "저장소"라고도 해요 |
| 오브젝트 스토리지 | 창고의 정식 명칭이에요. 파일 하나하나를 물건(오브젝트)처럼 넣고 꺼내는 방식이라 붙은 이름이에요 |
| S3 | 아마존이 파는 파일 창고 상품명이에요. 워낙 유명해서 창고의 대명사처럼 쓰여요. "S3에 올릴게요"는 "창고에 넣을게요"라는 뜻이에요 |
| 버킷(bucket) | 창고 안의 큰 구역 하나예요. 보통 서비스 하나가 버킷 하나를 써요. "버킷 만들었어요"는 "우리 창고 한 칸 계약했어요"예요 |
| CDN | 창고 물건의 복사본을 손님 가까이에 미리 가져다 두는 배송망이에요. 전 세계에 복사본 두기 문서에서 자세히 다뤄요 |
바이브캠퍼스에서는요
바이브캠퍼스 스튜디오에서 "손님이 사진을 올릴 수 있게 해 줘"라고 주문하면, 창고 계약이나 버킷 만들기 같은 밑작업은 AI가 알아서 짜요. 사장님이 이 단어들을 외울 필요는 없고, 대화에 나왔을 때 알아들을 수 있으면 충분해요.
증상이 보이면 이렇게 말하세요
파일 저장이 잘못돼 있으면 증상이 꽤 뚜렷하게 나타나요. 증상을 알아보고, AI에게 그대로 옮겨 말할 수 있는 문장을 짝지어 뒀어요.
| 이런 증상이면 | AI에게 이렇게 말하세요 |
|---|---|
| 사진을 올리면 화면이 한참 멈추거나, 목록 화면이 갈수록 느려져요 | "사진이 데이터베이스에 통째로 저장되고 있는지 확인하고, 파일 저장소로 옮긴 다음 데이터베이스에는 주소만 남겨 줘" |
| 새로 배포하고 나면 손님들이 올렸던 사진이 전부 사라져요 | "업로드 파일이 서버 폴더에 저장되고 있는 것 같아. 배포해도 지워지지 않는 외부 파일 저장소에 저장하도록 바꿔 줘" |
| 사진 자리가 엑스 표시(깨진 그림)로 나와요 | "데이터베이스에 저장된 사진 주소와 실제 파일 위치가 어긋난 곳을 찾아서 고쳐 줘" |
| 아무 파일이나 올라가는 게 불안해요 | "업로드는 이미지 파일만 받고, 한 장에 10MB 넘으면 막고, 올릴 때 자동으로 압축해 줘" |
| 저장 용량 요금이 계속 늘어요 | "업로드할 때 사진을 화면에 필요한 크기로 줄여서 저장하고, 탈퇴한 손님의 파일을 정리하는 기능을 만들어 줘" |
이 문장들의 공통점이 보이시나요. 원인을 사장님이 진단할 필요가 없어요. 증상을 말하고 "확인하고 고쳐 줘"라고 하면, 어디에 저장되고 있는지 찾는 일은 AI의 몫이에요.
사장님이 실제로 겪는 장면
장면 1 · 외주 개발자가 말했다
“이미지는 S3 버킷에 올리고, DB에는 URL만 저장하는 구조로 갈게요.”
이제 한 문장씩 해석돼요. 사진은 아마존 파일 창고의 우리 구역에 넣고, 장부(데이터베이스)에는 주소만 적겠다는 뜻이에요. 이 문서에서 배운 바로 그 정석 구조라서, "네, 그렇게 해 주세요"가 정답이에요.
지금은 신경 쓰지 않아도 되는 때
겁먹기 전에 이것부터 확인하세요. 손님이 파일을 올리는 기능이 없다면, 이 문서 내용은 아직 사장님 일이 아니에요. 소개 페이지, 메뉴판, 예약 폼처럼 사장님이 만든 화면에 사장님이 고른 사진 몇 장이 들어가는 서비스는 그 사진들이 코드와 함께 배포돼요. 창고가 따로 필요 없고, 사라질 일도 없어요.
- 1손님이 올리기 시작하는 순간 신경 쓸 일이 돼요. 리뷰 사진, 프로필 사진, 문의 첨부 파일. 손님 손에서 파일이 들어오는 기능을 만들 때가 창고가 필요해지는 첫 순간이에요.
- 2파일이 수백 장을 넘어가는 순간 정리 규칙이 필요해져요. 용량 요금, 오래된 파일 청소, 사진 줄여서 저장하기 같은 것들이요.
- 3신분증·계약서처럼 민감한 첨부를 받는 순간 급이 달라져요. 이건 사진 저장 문제가 아니라 개인정보 문제라서, 접근 제한과 보관 기간까지 챙겨야 해요.
즉 순서가 있어요. 처음에는 몰라도 되고, 손님 업로드 기능을 붙이는 날 이 문서를 다시 열면 돼요. 그날이 오기 전까지는 "사진은 창고, 장부에는 주소" 한 줄만 기억해 두세요.
지우기와 보관 기간
파일 저장에는 조용한 함정이 하나 있어요. 손님이 탈퇴하거나 글을 지웠을 때, 장부의 줄만 지우고 창고의 파일은 그대로 남는 경우예요. 주소를 아는 사람은 여전히 그 사진을 열 수 있으니, 손님 입장에서는 지워 달라고 했는데 안 지워진 거예요. 삭제 기능을 주문할 때는 "데이터베이스 기록을 지울 때 창고의 파일도 같이 지워 줘"라고 한 문장을 덧붙이세요.
보관 기간은 단정하지 않을게요
손님의 사진과 첨부 파일도 개인정보에 해당할 수 있고, 개인정보는 법으로 보관 기간과 파기 의무가 정해져 있어요. 업종과 파일 종류에 따라 달라서 여기서 "며칠"이라고 단정하면 오히려 위험해요. 개인정보보호위원회 누리집과 개인정보 포털의 안내를 확인하시고, 애매하면 그쪽 상담 창구에 물어보세요. 서비스의 개인정보처리방침에 적은 기간과 실제 파기가 일치하는지가 핵심이에요.
자주 묻는 것
- Q. 제가 직접 창고 회사와 계약해야 하나요?
- 처음에는 아니에요. 바이브캠퍼스에서 업로드 기능을 주문하면 저장까지 동작하는 형태로 만들어져요. 서비스가 커져서 파일이 많아지면 그때 전용 창고(S3 같은 것)를 연결하는 걸 검토하면 되고, 그것도 "파일 저장소를 연결해 줘"라고 주문하는 일이에요.
- Q. 사진이 몇 장 안 되는데도 꼭 나눠야 하나요?
- 사장님이 넣는 고정 사진 몇 장이면 안 나눠도 돼요. 나누는 기준은 장수보다 "누가 올리느냐"예요. 손님이 올리는 구조라면 열 장일 때 백 장이 되는 건 순식간이라, 처음부터 창고 구조로 만드는 게 나중에 뜯어고치는 것보다 훨씬 싸요.
- Q. 손님이 아무 파일이나 올리면 위험하지 않나요?
- 위험할 수 있어요. 그래서 받는 쪽에서 거르는 게 기본이에요. 이미지만 받기, 크기 상한 두기, 파일 이름을 서버가 새로 짓기. 이 세 가지를 업로드 기능 주문에 같이 넣으세요. "이미지만, 10MB까지만 받게 해 줘" 한 문장이면 돼요.
- Q. 창고 요금은 어떻게 나오나요?
- 보통 두 갈래예요. 쌓아 둔 양(저장 용량)과 꺼내 간 양(전송량)이요. 창고에 물건을 두는 값과 배송비가 따로인 것과 같아요. 사진을 올릴 때 줄여서 저장하면 두 요금이 같이 줄어서, 사진 가볍게 만들기가 곧 요금 절약이에요.
- Q. 손님 사진을 지우면 진짜 지워지는 건가요?
- 장부의 줄과 창고의 파일을 둘 다 지워야 진짜 삭제예요. 둘 중 하나만 지워지는 사고가 흔해서, 삭제 기능을 만들 때 "파일도 같이 지워 줘"라고 명시하는 게 안전해요. 다만 백업본에는 한동안 남아 있을 수 있어요.
- Q. 동영상도 같은 방식인가요?
- 원리는 같고 무게가 달라요. 동영상은 사진의 수십 배라서 창고 저장이 필수고, 손님에게 틀어 줄 때 전송량 요금이 크게 나올 수 있어요. 동영상 기능을 붙일 때는 요금 이야기를 먼저 꺼내는 게 좋아요.
확인해 보세요
손님 리뷰 기능을 만들어요. 리뷰 글과 첨부 사진은 각각 어디에 저장하는 게 정석일까요?
하나 더
새 버전을 배포했더니 손님들이 올린 사진이 전부 사라졌어요. 가장 그럴듯한 원인은?
직접 해보기
스튜디오에서 업로드 기능을 말로 주문해 보세요
"손님이 리뷰에 사진을 올릴 수 있게 해 줘. 이미지만, 한 장에 10MB까지만 받고, 올릴 때 자동으로 압축해 줘." 이 한 문장에 이 문서의 핵심이 다 들어 있어요. 지금 만들 계획이 없어도, 어떻게 만들어지는지 구경만 해도 돼요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
비유가 안 맞는 지점 · 사실 데이터베이스도 파일을 통째로 저장할 수는 있어요. 기술적으로 불가능해서 나누는 게 아니라, 각자 잘하는 일이 달라서 나누는 거예요. 데이터베이스는 검색과 정렬이 특기고, 파일 창고는 큰 덩어리를 싸게 쌓아 두고 빠르게 내보내는 게 특기예요. 아주 작은 파일(수 KB짜리 아이콘 같은 것)은 데이터베이스에 넣어도 티가 안 나지만, 손님 사진처럼 수가 늘어나는 것은 창고가 정답이에요.
서명된 주소라는 장치 · 창고 주소를 아는 사람 누구나 파일을 열 수 있으면 곤란한 경우가 있어요. 계약서 스캔본 같은 것이요. 그래서 창고에는 "이 주소는 10분 동안만, 이 사람에게만 유효"라는 임시 출입증을 끊어 주는 기능이 있어요. 개발자들이 "presigned URL" 또는 "서명된 URL"이라고 부르는 게 이거예요. 민감한 첨부 기능을 주문할 때 "파일은 아무나 열 수 없게 해 줘"라고 말하면 AI가 이 장치를 써요.
고아 파일과 창고 청소 · 장부에서는 지워졌는데 창고에만 남아 있는 파일을 고아 파일이라고 불러요. 요금은 계속 나가고 개인정보 문제도 될 수 있어서, 규모가 커지면 주기적으로 장부와 창고를 대조해서 짝 없는 파일을 지우는 청소 작업을 둬요. 반대로 장부에는 있는데 창고에 파일이 없으면 화면에 엑스 표시가 떠요. 둘 다 "장부와 창고가 어긋난" 같은 병의 다른 증상이에요.
이것만 기억하세요
- ·글자와 숫자는 데이터베이스에, 사진과 첨부 파일은 파일 창고에 둬요
- ·데이터베이스에는 파일의 주소 한 줄만 남겨요. 명부에 적는 "3번 선반"이에요
- ·서버 폴더에 저장된 파일은 배포 때 사라져요. 외부 창고가 답이에요
- ·손님이 파일을 올리는 기능이 없다면 아직 신경 쓸 일이 아니에요
- ·삭제할 때는 장부의 줄과 창고의 파일을 같이 지워야 진짜 삭제예요