데이터 엔지니어라면 이런 상황을 겪어본 적 있을 거다. AI 팀에서 “이거 어디 올려놨어? 다운로드 링크 줄 수 있어?” 하면서 물어오고, 보안팀은 “공개 접근? 절대 안 돼. 데이터 유출 위험 있어”라고 말한다. 그 사이에서 어떻게 적절히 관리할지 고민하다가 결국 복잡한 권한 설정에 빠져든다.
지난 2년간 여러 AI 프로젝트를 하면서 Azure Blob Storage를 많이 다뤘다. 처음엔 단순히 “파일 저장 공간이구나”라고 생각했는데, 실제로는 훨씬 복잡하고 전략적인 부분이 많더라. 특히 AI 학습 데이터를 다룰 때는 더 그렇다. 대용량의 파일들을 효율적으로 관리하면서도 보안을 지켜야 하니까.
이 글에서는 실제 경험을 바탕으로 Blob Storage를 AI 데이터 파이프라인에 어떻게 통합하는지, Public Access를 언제 쓸 수 있고 언제 피해야 하는지, 그리고 실제로 효과가 있는 보안 설정이 뭔지를 정리했다.
Blob Storage가 AI 팀의 필수 인프라가 된 이유
처음엔 왜 Blob Storage를 쓸까 싶을 수 있다. 그냥 NAS나 파일 서버에 데이터 놓으면 되지 않나? 하지만 AI 프로젝트는 조금 다르다.
먼저 규모가 다르다. 이미지 데이터셋 하나가 100GB를 넘는 게 일상이다. 텍스트 데이터라면 몇 테라바이트도 가능하다. 이 정도 규모를 로컬 서버로 관리하면 네트워크 병목이 심하다. 그럼 다운로드 속도가 느려져서 개발자들이 답답해한다.
Azure Blob Storage는 이 문제를 해결한다. 대역폭이 충분해서 대용량 파일도 빠르게 다운로드할 수 있다. 특히 Azure 내부의 다른 서비스(Azure ML, Databricks, 컴퓨팅 인스턴스)에서 접근할 때는 매우 빠르다. 같은 리전 내에서 움직이니까 지연시간도 거의 없다.
또 하나의 장점은 비용이다. 저장 비용이 매달 몇 천 원대에서 몇 만 원대 정도로 매우 저렴하다. NAS 같은 하드웨어를 직접 구매하고 유지보수할 때보다 훨씬 싸다. 게다가 Hot, Cool, Archive 같은 다양한 스토리지 티어가 있어서, 자주 쓰는 데이터와 오래된 데이터를 분리해서 비용을 최적화할 수 있다.
그리고 무엇보다 중요한 게 접근성이다. VPN 없이도 권한 있는 사람이라면 어디서든 데이터에 접근할 수 있다. 팀 내에 원격 근무자가 있거나, 협력사와 데이터를 공유해야 할 때 정말 편하다.
Public Access, 언제 써야 하고 언제 피해야 하나
Blob Storage의 가장 간단한 설정이 Public Access다. 인터넷만 있으면 누구나 파일에 접근할 수 있게 하는 거다. 처음에는 이게 편해 보인다. SAS 토큰도 안 만들어도 되고, 권한 설정도 안 해도 되니까.
하지만 AI 데이터에서는 이게 위험할 수 있다. 학습 데이터에는 민감한 정보가 들어있을 수 있다. 예를 들어 의료 AI를 학습시킨다면 환자 정보가 들어있고, 금융 데이터라면 거래 정보가 들어있다. 이런 게 공개되면 규제에 걸릴 수도 있고, 회사 신뢰도가 떨어진다.
그래서 처음에는 무조건 Public Access를 비활성화하는 게 맞다. Azure는 기본적으로 모든 Blob Storage 계정의 “Anonymous public access”를 차단하도록 권고한다. 이 설정만으로도 기본 보안은 확보된다.
그런데 실제로는 특정 상황에서 Public Access가 필요할 수 있다. 예를 들어 모델 가중치를 공개 저장소로 배포하거나, 데모 데이터를 공유할 때다. 이럴 때는 정확한 설정이 필요하다.
Container 수준에서 Public Access를 켤 수는 있지만, 전체 계정 수준에서는 끄는 게 좋다. 즉, 특정 컨테이너만 공개하고 나머지는 전부 비공개로 두는 거다. 이렇게 하면 실수로 민감한 데이터가 노출될 위험을 줄일 수 있다.
또 하나의 방법은 SAS(Shared Access Signature) 토큰을 쓰는 것이다. 이건 마치 시간 제한이 있는 특별한 열쇠다. “이 파일만 30일 동안 다운로드 가능”이라는 식으로 설정할 수 있다. 이렇게 하면 공개 접근처럼 보이지만 실제로는 통제된 접근이다. 누가 언제 뭘 다운로드했는지도 로그에 남는다.
실제 AI 데이터 파이프라인에서의 설정
내가 다루던 프로젝트를 예로 들자면, 보통 세 개의 컨테이너를 만들었다.
첫 번째는 “raw-data” 컨테이너다. 여기엔 원본 데이터를 그대로 저장한다. 의료 이미지, 금융 거래 기록 같은 민감한 데이터들이다. 이 컨테이너의 Access Level은 Private이다. Azure Active Directory의 특정 그룹만 접근할 수 있게 한다. 즉, 회사 직원들 중에서도 AI 팀에만 접근 권한을 준다.
두 번째는 “processed-data” 컨테이너다. 원본 데이터를 전처리한 후 저장하는 곳이다. 민감한 정보는 제거되고, 학습에 필요한 형식으로 정제된 데이터다. 이 컨테이너는 여전히 Private이지만, 좀 더 많은 사람들이 접근할 수 있다. 데이터 분석 팀, ML Ops 팀, 심지어 일부 분석가들도 접근 가능하게 한다.
세 번째는 “model-artifacts” 컨테이너다. 학습된 모델의 가중치나 추론에 필요한 파일들을 저장한다. 이 컨테이너는 경우에 따라 Public Access를 활성화할 수도 있다. 특히 오픈소스 모델이나 데모용 모델이라면 말이다. 어차피 누구나 다운로드해서 쓸 수 있게 배포할 거니까.
각 컨테이너마다 권한 설정을 다르게 하는 게 핵심이다. 민감도에 따라 Access Level을 조정한다. 이렇게 하면 보안과 편의성 사이의 균형을 맞출 수 있다.
Azure Active Directory를 통한 정교한 접근 제어
진짜 강력한 보안을 원한다면 Azure Active Directory(이제는 Entra ID라고 부르는데)를 활용해야 한다. 이건 단순한 공개/비공개 구분이 아니라, 사용자 수준의 세밀한 통제다.
먼저 Azure 계정의 모든 사용자를 Active Directory에 등록한다. 그리고 역할 기반 접근 제어(RBAC)를 설정한다. 예를 들어 “Data Scientist” 역할을 만들고, 이 역할을 가진 사람들만 processed-data 컨테이너에 접근할 수 있도록 한다.
이렇게 하면 누군가가 퇴사할 때 관리가 쉽다. 그냥 Active Directory에서 그 사람의 계정을 비활성화하면, Blob Storage의 모든 권한이 자동으로 없어진다. 복잡한 수동 작업이 필요 없다.
또한 감사(Audit) 로그가 자동으로 기록된다. 누가 언제 어떤 파일을 다운로드했는지 전부 남는다. 데이터 유출 의심이 생기면 이 로그를 확인해서 원인을 찾을 수 있다.
실제로 이런 기능이 정말 유용하다는 걸 느꼈다. 한 번은 한 직원이 어떤 데이터셋을 과도하게 다운로드하는 패턴이 보였다. 조사해보니 자신이 맡은 프로젝트가 아닌데 데이터를 복사하려고 했더라. 감시라는 게 좋지는 않지만, 이렇게 문제를 조기에 발견할 수 있다.
SAS 토큰, 외부 협력사와의 안전한 데이터 공유
때때로 외부 협력사나 다른 팀과 데이터를 공유해야 할 때가 있다. 이럴 때 SAS 토큰은 정말 유용하다.
SAS 토큰은 시간 제한, 권한 제한, IP 제한 같은 여러 조건을 걸 수 있다. 예를 들어 “이 URL은 30일 동안만 유효하고, 읽기 권한만 있고, 1.2.3.0/24라는 IP 범위에서만 접근 가능”이라고 설정할 수 있다.
외부 협력사에게 데이터를 줄 때 이렇게 설정한 SAS 토큰 URL을 주면, 그들은 제한된 범위 안에서만 데이터에 접근할 수 있다. 만약 토큰이 유출되더라도 기간이 지나면 자동으로 무효화된다.
실제로 한 번은 다른 회사와 AI 모델 공동 개발을 했다. 그들에게 학습 데이터의 일부를 줘야 했는데, 전체 데이터를 줄 수는 없었다. SAS 토큰을 써서 특정 폴더만, 특정 기간만 접근 가능하게 했다. 그리고 한 달 뒤 프로젝트가 끝났을 때 그 토큰을 무효화했다. 간단하면서도 효과적이었다.
비용 최적화와 데이터 티어 활용
Blob Storage는 저장 비용 외에도 고려할 게 많다. 데이터를 얼마나 자주 접근하는가에 따라 비용이 크게 달라진다.
Hot 티어는 자주 접근하는 데이터용이다. 저장 비용은 높지만 접근 비용은 싼다. 현재 진행 중인 AI 프로젝트의 학습 데이터라면 Hot 티어에 두는 게 맞다.
Cool 티어는 가끔 접근하는 데이터용이다. 저장 비용이 Hot보다 훨씬 싸지만, 접근 비용은 비싸다. 그리고 최소 30일 보관 기간이 있다. 즉, 30일 안에 지우면 페널티를 맞는다. 완료된 프로젝트의 데이터를 보관할 때 좋다.
Archive 티어는 거의 접근하지 않는 데이터용이다. 저장 비용은 엄청 싸지만, 접근하려면 시간이 걸린다. Rehydration이라는 과정을 거쳐야 해서 몇 시간까지 기다려야 한다. 규정상 보관해야 하는 과거 데이터를 여기 놓으면 좋다.
실제로 비용을 계산해보면 이 차이가 생각보다 크다. 100TB의 데이터를 1년 동안 보관한다면, Hot로는 월 2000달러 정도지만, Cool로는 월 500달러 정도다. 연간 18000달러를 절감할 수 있다. 이건 무시할 수 없는 금액이다.
따라서 생명주기 관리 정책을 만드는 게 좋다. 예를 들어 “90일 이상 접근이 없는 데이터는 자동으로 Cool 티어로 이동”이라는 정책을 설정하면, 비용을 절감하면서도 필요할 때 데이터를 복구할 수 있다.
데이터 파이프라인과의 통합
실제로는 Blob Storage가 독립적으로 작동하지 않는다. Azure ML, Databricks, Azure Data Factory 같은 다른 서비스들과 함께 작동한다.
Azure ML에서 학습할 때는 Dataset을 만들어서 Blob Storage의 데이터를 가리킨다. 이렇게 하면 매번 직접 파일을 다운로드할 필요 없이, ML 파이프라인에서 바로 접근할 수 있다.
Databricks를 쓸 때는 mount point를 설정해서 Blob Storage를 마치 로컬 파일시스템처럼 접근할 수 있다. 즉, /mnt/data/dataset.csv 이런 식으로 파일을 읽을 수 있다. Spark 작업에서도 효율적으로 대용량 데이터를 처리할 수 있다.
Azure Data Factory는 데이터 이동을 자동화한다. 예를 들어 매일 특정 시간에 온프레미스 데이터베이스에서 새로운 데이터를 가져와서 Blob Storage에 저장하도록 파이프라인을 만들 수 있다. 이렇게 자동화하면 수동으로 관리할 필요가 없어진다.
이런 통합들이 결국 전체 데이터 파이프라인의 효율성을 높인다. Blob Storage는 단순한 저장소가 아니라, 전체 AI 인프라의 중심이 된다.
보안 베스트 프랙티스 정리
지금까지의 경험을 정리하면 몇 가지 핵심 규칙이 있다.
첫째, 기본 설정은 Private으로 시작한다. 그리고 필요한 것만 공개한다. 반대로 하면 실수로 데이터를 노출시킬 위험이 있다.
둘째, 민감도에 따라 컨테이너를 분리한다. 원본 데이터, 처리 데이터, 모델 같은 식으로 말이다. 이렇게 하면 각각에 맞는 접근 제어를 적용할 수 있다.
셋째, Active Directory를 활용해서 사용자 기반의 접근 제어를 한다. 역할 기반 접근이 훨씬 관리하기 쉽다.
넷째, 외부와 데이터를 공유할 때는 SAS 토큰을 쓴다. 시간 제한, 권한 제한 같은 조건을 설정해서 위험을 최소화한다.
다섯째, 생명주기 관리를 설정해서 비용을 최적화한다. 자동으로 데이터를 적절한 티어로 이동시킨다.
여섯째, 감사 로그를 활성화하고 정기적으로 검토한다. 문제 발생 시 추적할 수 있도록 해야 한다.
결론: Blob Storage는 전략적으로 써야 한다
Azure Blob Storage는 정말 강력한 도구다. 하지만 강력하기 때문에 조심해서 써야 한다. 무작정 Public Access를 켜거나, 모든 팀에게 같은 권한을 주면 문제가 생긴다.
AI 팀이 효율적으로 데이터를 다루면서도, 보안팀이 안심할 수 있는 환경을 만드는 것이 목표다. 이는 초기 설계를 제대로 하고, 적절한 도구들을 활용하면 충분히 가능하다.
지금 당신의 회사가 Azure를 쓰고 있다면, Blob Storage를 더 전략적으로 활용할 기회가 있다. 작은 프로젝트부터 시작해서 이런 패턴들을 적용해보자. 처음엔 복잡해 보일 수 있지만, 한 번 설정하고 나면 장기적으로 엄청나게 효율적이다.
데이터 보안과 접근성의 균형은 한 번 맞추면 계속 유지되는 게 아니다. 조직이 성장하고, 데이터가 늘어나고, 팀이 변하면서 계속 조정이 필요하다. 하지만 올바른 기초 위에 서 있다면, 그런 변화들도 수월하게 대응할 수 있다.