Blob은 파일 한 덩어리입니다
AI에게 ‘영수증을 올리고 조회하는 앱을 만들어줘’라고 부탁하면 ‘파일은 Blob Storage에 저장하겠습니다’라는 답이 돌아올 수 있습니다. 업로드 버튼 하나 만들려는데 저장소까지 알아야 할까요? 코드를 직접 짤 필요는 없습니다. 하지만 내 파일이 어디에 들어가고 누가 볼 수 있는지는 알아야 합니다. 영수증과 공개 홍보 이미지는 보관 규칙이 달라야 하기 때문입니다.
BLOB은 Binary Large Object의 약자입니다. 입문 단계에서는 사진 한 장, PDF 한 개처럼 저장하는 데이터 한 덩어리라고 이해하면 됩니다. 이름에 Large가 들어가지만 작은 파일도 저장합니다. Blob Storage는 이런 파일을 보관하고 필요할 때 꺼내주는 저장 서비스입니다. 사진·문서·영상뿐 아니라 텍스트도 저장할 수 있습니다.
Microsoft의 Azure에서는 저장소 전체를 Storage Account, 파일을 묶어두는 구역을 Container, 그 안의 개별 파일을 Blob이라고 부릅니다. 창고, 보관 구역, 물건 하나의 관계로 생각하면 됩니다.
출처: Microsoft Blob Storage 소개 — https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction
DB가 있는데 왜 따로 저장할까요?
DB, 즉 데이터베이스는 정보를 정리해두고 조건에 맞게 찾는 시스템입니다. 영수증 앱에서 ‘지난달 교통비만 보여줘’라고 했을 때 필요한 것은 날짜·분류·금액입니다. 반면 ‘영수증 원본 보기’를 눌렀을 때 필요한 것은 사진 파일입니다. 아래는 이 두 역할을 나누는 설계 예시입니다.
사진은 보관함에, 사진을 찾는 정보는 장부에 두는 셈입니다. DB에 파일을 넣을 수 없어서 나누는 것은 아닙니다. 파일 보관과 정보 검색의 역할을 분리하려는 설계입니다. 작은 파일을 관련 데이터와 함께 관리해야 한다면 DB에 저장하는 선택도 가능합니다.
| 영수증 앱에 필요한 것 | 저장할 곳 |
|---|---|
| 영수증 사진 원본 | Blob Storage |
| 사용 날짜·금액·비용 분류 | DB |
| 올린 사람과 사진의 저장 위치 | DB |
업로드보다 중요한 것은 누가 열 수 있느냐입니다
Private은 접근 권한이 있어야 읽을 수 있는 설정입니다. Public은 허용된 범위에서 로그인 없이 읽을 수 있는 설정입니다. 회사 로고처럼 누구나 봐도 되는 자료와 고객 계약서를 같은 공개 구역에 넣어서는 안 됩니다. Azure는 기본적으로 익명 접근을 막으며, 필요하지 않다면 공개 읽기를 허용하지 말 것을 권고합니다. Public 읽기를 허용해도 누구나 수정·삭제할 수 있는 것은 아닙니다.
‘우리 앱에 로그인해야 보이는 화면’과 ‘파일 자체가 비공개’는 별개입니다. 화면에는 로그인 기능이 있어도 파일 주소를 복사해 누구나 열 수 있다면 원본은 공개된 상태일 수 있습니다.
Private 파일을 잠시 공유할 때는 SAS라는 제한된 접근권을 쓸 수 있습니다. 예를 들어 특정 파일을 짧은 시간 동안 읽는 권한만 링크에 담는 방식입니다. 다만 링크를 전달받은 사람도 그 권한을 사용할 수 있으므로 링크 자체를 보호해야 합니다.
출처: Microsoft 공개 접근 설정 — https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure
출처: Microsoft SAS 안내 — https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview
AI에게 업로드해줘 대신 이렇게 요청해보세요
이미 만들고 있는 앱이 있다면 코드를 고치기 전에 아래 내용을 그대로 물어보세요. 이 문장은 실제 서비스를 점검하기 위한 요청 예시이며, 특정 앱의 보안을 검증했다는 뜻은 아닙니다.
이 앱의 파일 업로드 구조를 점검해줘.
아직 코드나 설정은 변경하지 마.
1. 업로드한 원본 파일은 어디에 저장되는지 설명해줘.
2. DB에는 파일과 관련된 어떤 정보가 저장되는지 알려줘.
3. 로그인하지 않은 사람이 일반 파일 주소만으로 원본을 열 수 있는지 확인해줘.
4. 다른 계정으로 로그인한 사람이 내 파일을 볼 수 없는지도 확인해줘.
5. 공유 링크에 만료 시간과 읽기 전용 제한이 있는지 확인해줘.
6. 파일 업로드는 성공했는데 DB 저장이 실패하면 어떻게 처리하는지 설명해줘.
실제로 확인한 결과와 추측을 구분하고,
비밀번호·저장소 키·접근 가능한 공유 링크는 답변에 노출하지 마.테스트 파일 하나로 세 가지를 확인하세요
직접 시험할 때는 실제 영수증이나 계약서 대신 개인정보가 없는 테스트 파일을 쓰세요. 본인이 관리하는 앱에서 로그아웃 상태와 별도 테스트 계정으로 접근을 확인하면 됩니다.
일반 주소가 막히는 것만으로 모든 보안이 검증되는 것은 아닙니다. 다른 사용자가 내 파일의 공유 링크를 발급받을 수 없는지도 중요합니다.
바이브 코딩 입문자가 먼저 알아야 할 것은 저장소의 모든 기능이 아닙니다. ‘어디에 저장되는가, 누가 볼 수 있는가, 실패하면 어떻게 되는가.’ 이 세 가지를 AI에게 물을 수 있으면 업로드 버튼이 작동하는 앱에서 파일을 제대로 관리하는 앱으로 한 걸음 나아갈 수 있습니다.