오브젝트란 무엇인가

• 오브젝트 스토리지를 이해하려면 먼저 오브젝트가 무엇인지부터 알아야 합니다. 우리가 흔히 말하는 파일에, 그 파일을 설명해 주는 정보인 메타데이터를 함께 묶어 하나의 단위로 만든 것이 오브젝트라는 것이죠.
• 예를 들어 이미지 파일 하나를 저장한다고 할 때, 이미지만 담는 것이 아니라 이 파일이 언제 생성됐는지, 어떤 장비에서 만들어졌는지, 어떤 업무와 관련된 데이터인지 같은 설명을 함께 붙여 저장합니다.

오브젝트 스토리지의 특징

• 김서환 매니저는 스토리지를 크게 세 가지로 나눠 이해하면 좋다고 합니다. 블록 스토리지는 데이터를 블록 단위로 쪼개어 저장하는 방식으로, 서버에 디스크를 직접 붙여 쓰는 구조에 가깝다고 하죠. FC 같은 신뢰성 높은 프로토콜을 써서 데이터베이스나 계정계, ERP 같은 미션 크리티컬 업무에 많이 쓰인다고 합니다. 파일 스토리지는 익숙한 파일과 폴더 구조로, NFS나 SMB로 서버에 마운트해 사용합니다.
• 오브젝트 스토리지의 첫 번째 특징은 여기서 갈립니다. 네트워크 기반이지만 서버에 마운트하지 않고, S3 같은 RESTful API로 데이터를 업로드하고 다운로드한다는 점인데요. 홍승우 매니저는 웹하드를 떠올리면 쉽다고 설명합니다. 웹하드에 파일을 올릴 때 내 노트북에 디스크를 연결하지는 않으니까요.

효과적인 스토리지 운영 전략이란?

• AI 데이터라고 하면 무조건 빠른 스토리지에 올려야 할 것 같은데, 사실은 꼭 그렇지는 않다고 합니다. 
• 실제 학습이나 분석이 이뤄지는 순간에는 빠른 I/O가 중요하니 초고속 병렬 파일 시스템이나 고성능 스토리지가 필요한 구간이 분명 있다는 거죠. 그래서 학습이나 분석에 직접 사용되는 데이터는 고성능 영역에서 처리하고, 과거 데이터나 자주 쓰지 않는 콜드 데이터는 오브젝트 스토리지에 두는 편이 훨씬 효율적이라고 합니다.

모든 데이터를 항상 고성능 스토리지에 올려둘 필요는 없습니다.

-홍승우 매니저 (HS효성인포메이션시스템) -

• 김서환 매니저는 여기에 비용 관점을 덧붙이고 있는데요. 고성능 스토리지의 부담이 커지는 상황에서 데이터의 활용 빈도와 목적에 따라 저장 계층을 나누는 것이, 결국 전체 데이터 플랫폼의 비용 효율성을 좌우한다는 이야기였는데요. 저장 위치를 나누는 일이 곧 예산을 설계하는 일이라는 점이 인상적이었습니다.

• 그렇다면 실제로 이런 데이터 레이크하우스의 구조는 어떻게 구현할 수 있을까요? 여기에 HS효성인포메이션시스템의 오브젝트 스토리지인 VSP One Object의 차별적인 강점이 있다고 김서환 매니저는 말합니다. 
• 첫 번째는 Data Lifecycle입니다. AI 환경에서는 자율주행 영상이나 제조 이미지, 상담 음성 같은 데이터가 매일 생성되고 시간이 지나면 활용 빈도가 낮아지는 데이터도 함께 늘어나는데요. 라이프사이클 정책을 통해 일정 기간이 지난 데이터를 자동으로 이동하거나 삭제하고 공간을 회수한다고 합니다. 데이터를 무작정 쌓아두는 것이 아니라 정책에 따라 관리하는 것이죠.
• 두 번째는 S3 Tables와 Iceberg Catalog입니다. 저장된 데이터를 단순한 파일 덩어리가 아니라 테이블 형태로 관리해서, Spark나 Trino 같은 분석 엔진으로 바로 조회할 수 있게 해 준다고 합니다.

데이터 레이크에 쌓인 데이터를 별도 DW로 옮기지 않고 SQL로 분석하고 싶을 때, 이때 필요한 것이 S3 Tables입니다.

-홍승우 매니저 (HS효성인포메이션시스템) -

• 여기에 한 가지 더 체크해야 할 내용이 있습니다. 퍼블릭 클라우드에서 AWS S3가 사실상 표준으로 자리 잡았지만, 보안과 비용, 내부 시스템 연계 때문에 모든 데이터를 클라우드에 둘 수는 없겠죠. S3처럼 쓰면서도 우리 데이터센터에서 운영하고 싶다는 요구가 커지고 있고, VSP One Object는 바로 그런 고민을 해결할 수 있다고 강조합니다. 

• 이제 랜섬웨어 얘기로 넘어갈까 합니다.  랜섬웨어는 시스템에 침투한 뒤 연결된 저장소의 파일 확장자를 바꾸거나 데이터를 암호화하는 방식으로 피해를 일으키는데요. 김서환 매니저는 특히 서버에 마운트된 파일 시스템이나 네트워크 드라이브가 주요 공격 대상이 된다고 지적했습니다. 백업 서버가 감염됐는데 그 서버에 NAS가 연결되어 있다면 백업 데이터까지 피해가 번질 수 있다는 것이죠.
• 오브젝트 스토리지는 이 지점에서 다릅니다. 마운트해서 쓰는 방식이 아니라 API로 데이터를 주고받기 때문에, 파일 시스템을 따라가며 암호화하는 경로에서 오브젝트 스토리지는 벗어나 있다는 설명입니다. 백업 서버의 감염 여파가 오브젝트 스토리지까지는 도달하기 어려운 구조이죠.

• 요즘 백업 소프트웨어도 Immutable Backup 기능을 제공하는데, 왜 오브젝트 스토리지가 또 필요한가라는 질문도 많이 받는다고 합니다. 이유는 백업 소프트웨어가 설치된 서버 자체가 랜섬웨어에 감염될 수도 있기 때문입니다. 이런 상황에서 백업 데이터가 서버에 마운트된 NAS나 일반 파일 시스템에 저장되어 있다면 백업 데이터까지 함께 영향을 받을 수 밖에 없겠죠. 실제로 백업 소프트웨어로 방비를 철저히 했다고 판단했다가 결국 감염된 뒤 오브젝트 스토리지를 도입한 고객사도 있었다고 하네요.
• 그래서 제안되는 것이 세 단계 구조입니다. 첫 번째는 백업 소프트웨어가 이상 징후를 탐지하는 단계, 두 번째는 Immutable Backup을 구성하는 단계, 세 번째는 오브젝트 스토리지의 WORM과 버저닝으로 백업 데이터를 한 번 더 보호하는 단계입니다. 특히 병원과 금융, 공공기관처럼 데이터 복구가 곧 서비스 연속성과 직결되는 곳에서 이런 구조가 더욱 중요하겠죠. 

랜섬웨어 대응은 백업 소프트웨어 하나로 끝나는 것이 아니라, 백업 데이터를 저장하는 최종 저장소까지 함께 고려하는 다층적 보안 구조를 고민해야 합니다.

-김서환 매니저 (HS효성인포메이션시스템) -

• 장점이 이렇게 많다면 왜 진작 모두가 쓰지 않았을까요. 이유는 오브젝트 스토리지의 사용 방식이 담당자들에게 익숙하지 않기 때문이라고 말합니다. 파일 스토리지라면 서버에 마운트된 경로에서 파일을 읽어 오면 되지만, 오브젝트 스토리지라면 업무 서버가 API를 호출해 파일을 요청하고 응답을 받아 화면에 보여줘야 합니다. 과거에는 이 연동을 위해 고객사 업무별로 개발이 필요했고, 그것이 오브젝트 스토리지 도입의 진입 장벽이었다고 하죠.
• 그런데 최근 세 가지 변화가 이 장벽을 낮추고 있다고 합니다. 첫 번째는 S3 프로토콜의 확산입니다. 예전에는 개발을 해야 한다는 이야기가 먼저 나왔지만, 지금은 이 애플리케이션이 S3를 지원하느냐를 확인하는 방식으로 바뀌었다고 합니다.
• 두 번째는 GUI 기반 관리 도구의 확대입니다. S3 Browser 같은 도구를 쓰면 개발자가 아니어도 데이터를 올리고 내려받을 수 있습니다. 세 번째는 활용 사례의 증가입니다. 전자문서 보관과 백업을 넘어 데이터 레이크, AI 데이터 저장, 클라우드 스토리지까지 오브젝트 스토리지의 쓰임이 넓어졌다고 하네요.