세상만사 관심/기술

데이터베이스에는 텍스트만 저장될까?

내가그리는인생 2025. 5. 23. 20:54
반응형

데이터베이스에는 텍스트뿐 아니라 이미지, 음악, PDF, ZIP 파일까지 저장할 수 있습니다. 저장 방식부터 BLOB, 경로 저장 차이까지 알아보도록 합시다.

데이터베이스에는 텍스트만 저장될까? 이미지, 음악, 압축파일도 저장될까?

평소에는 별다른 생각이 없이 데이터 베이스란 말을 듣기만하다가 많은 역할을 하는 오늘날 문득 어떤식으로 저장될까 하는 궁금증이 들었습니다.
“데이터베이스(DB)에는 당연히 텍스트가 저장되겠지. 그런데... 이미지나 음악 같은 파일도 저장할 수 있을까?”

사실 그동안은 그냥 텍스트 정보만 다루면 된다고 생각했거든요. 사용자 이름, 이메일, 상품명, 설명 같은 거요. 그런데 웹사이트나 앱을 자세히 들여다보면 거의 모든 서비스가 이미지를 쓰고, 음성 파일을 재생하고, PDF나 ZIP 파일을 다운로드하게 해줍니다. 그렇다면 이런 데이터는 어디에 저장되는 걸까요?

이번 글에서는 저와 함께 이런 궁금증을 하나하나 파헤쳐 보겠습니다. 데이터베이스에 저장되는 텍스트 이외의 다양한 데이터 형식과, 그 데이터들이 어떻게 저장되는지, 왜 그렇게 저장하는지까지 함께 알아보시죠.

데이터베이스에 저장 가능한 다양한 데이터 형식 시각화


텍스트는 기본, 그런데 그 외의 데이터는?

데이터베이스는 원래 "데이터를 저장하는 창고"입니다. 우리가 일반적으로 생각하는 텍스트 데이터는 이름, 이메일, 주소, 설명 같은 문자열인데요. 이건 DB에서 CHAR, VARCHAR, TEXT 같은 자료형으로 쉽게 저장할 수 있어요.

그런데 이미지나 음악처럼 텍스트가 아닌 파일들은 어떻게 처리할까요?

놀랍게도, 데이터베이스는 이런 비정형 데이터도 충분히 저장할 수 있습니다. 단, 우리가 보던 방식과는 조금 다른 개념이 등장합니다.


BLOB? 처음 들어보는 단어인데요?

데이터베이스에서 이미지, 오디오, PDF, ZIP 등 파일을 저장할 때 사용하는 자료형이 있습니다. 바로 BLOB입니다.

BLOB은 Binary Large Object의 줄임말로, **“큰 이진 데이터 덩어리”**라는 뜻이에요. 이 말만 들어도 느낌이 오시죠? 우리가 일반적으로 눈으로 읽을 수 있는 텍스트가 아니라, 0과 1로 구성된 순수한 바이너리 데이터입니다.

예를 들어 사용자의 프로필 사진을 데이터베이스에 저장하고 싶다고 해볼게요. 이때 BLOB 필드를 만들어 이미지 파일을 통째로 이진 데이터로 저장할 수 있습니다. 종류도 다양한데요:

  • TINYBLOB: 최대 255바이트
  • BLOB: 최대 64KB
  • MEDIUMBLOB: 최대 16MB
  • LONGBLOB: 무려 최대 4GB!

그래서, 기술적으로는 영화 한 편 분량의 영상도 BLOB으로 저장할 수 있긴 합니다.

BLOB을 이용한 이미지 데이터 저장 구조


그런데 왜 대부분의 서비스는 BLOB을 안 쓸까?

자, 이쯤에서 이런 의문이 생깁니다. “그럼 다 BLOB으로 저장하면 되지, 왜 굳이 복잡하게 서버에 파일 두고 URL만 DB에 저장하지?”

실제 현실에서는 파일 경로(URL) 저장 방식이 훨씬 많이 사용됩니다. 이유는 간단합니다:

  • BLOB은 읽고 쓰는 데 속도가 느립니다.
  • DB에 대용량 파일이 많아지면 성능 저하가 심해집니다.
  • 백업 및 복구도 어려워져요.
  • 반면 URL 방식은 파일은 파일대로 관리하고, DB에는 가볍게 경로만 저장하면 되니 훨씬 효율적이죠.

예를 들어 아래처럼 저장하는 식입니다.

INSERT INTO users (name, photo_url) VALUES ('홍길동', '/uploads/profile1.jpg');
 

그리고 프론트엔드에서는 <img src="/uploads/profile1.jpg">로 불러오는 거예요.


음악, PDF, ZIP도 저장할 수 있을까?

이건 저도 이번에 찾아보면서 알게 된 건데요, MP3, PDF, DOCX, ZIP 파일도 모두 BLOB으로 저장 가능합니다. 그냥 텍스트가 아닌 바이너리 데이터면 다 저장이 된다는 거죠.

하지만 마찬가지로 음악 스트리밍 서비스나 전자책 플랫폼 등에서는 일반적으로 파일을 서버나 클라우드(AWS S3, Google Cloud Storage)에 저장하고, 그 위치(URL)를 데이터베이스에 저장하는 방식을 선호합니다.

게다가 요즘은 전 세계 사용자에게 빠르게 콘텐츠를 제공하기 위해 **CDN(Content Delivery Network)**도 같이 쓰니까요. 이런 구조에서는 BLOB보다 URL 방식이 훨씬 실용적입니다.


NoSQL은 어떻게 다를까?

전통적인 관계형 데이터베이스(RDBMS)와는 달리, NoSQL 데이터베이스는 이런 비정형 데이터에 훨씬 강합니다.

예를 들어 MongoDB에는 GridFS라는 기능이 있어요. 이건 파일을 작게 잘라서 여러 문서(document)로 나눠 저장한 뒤, 필요할 때 다시 조립해서 사용하는 방식이에요. 덕분에 16MB를 초과하는 대용량 파일도 무리 없이 저장하고 읽어올 수 있죠. 저는 이거 처음 보고 “오 이건 좀 대단하다…” 싶었습니다.

MongoDB 외에도 Amazon DynamoDB나 Couchbase 같은 NoSQL DB도 다양한 형태의 데이터를 유연하게 다룰 수 있어, 이미지/음성 기반 앱이나 IoT 시스템에서 자주 사용됩니다.

MongoDB GridFS의 대용량 파일 저장 구조


결국 어떤 방식이 좋은 걸까?

정답은 없습니다. 대신 상황에 맞는 선택이 중요합니다.

상황 추천 방식
웹사이트 사용자 사진 파일 경로(URL) 저장
의료 영상, 전자서명 BLOB (보안 강화)
음악/영상 스트리밍 파일 서버 + URL 저장
계약서 PDF 저장 BLOB 또는 암호화 URL 저장
대용량 파일 관리 NoSQL(GridFS 등) 활용
 

파일을 다루는 목적, 보안 수준, 트래픽 양, 유지보수 편의성 등 다양한 요소를 고려해서 저장 전략을 짜는 게 핵심이에요.


마무리하며

예전엔 데이터베이스는 그냥 “텍스트 저장소”라고만 생각했는데, 이번에 알아보면서 정말 많은 걸 새로 알게 됐어요. 이미지도 저장되고, 음악도 되고, ZIP 파일도 가능하다니… BLOB이라는 자료형도 신기했고, GridFS처럼 대용량 파일도 쪼개서 저장하는 구조가 있다는 것도 인상 깊었습니다.

데이터가 단순한 텍스트를 넘어 점점 복잡하고 풍부해지는 시대인 만큼, 이런 저장 방식의 이해도 점점 더 중요해지겠죠?

이외에도 비슷한 방식들에 대해 의문이 생긴다면 함께 알아보도록 하겟습니다.