언제, 어떤 DB를 써야 할까? 데이터베이스 개념 정리

데이터베이스는 말 그대로 정보를 저장하는 창고 같은 곳입니다. 우리가 원하는 정보를 빠르고 정확하게 꺼내 올 수 있어야 하고, 동시에 저장 용량이 커도 처리에 무리가 없어야 하죠. 오늘은 여러 종류의 데이터베이스가 어떤 특징이 있고, 실제 업무에서 어떻게 선택하면 좋을지 알아보겠습니다.

RDB(관계형 데이터베이스): 빠른 Update RDB(Relational Database)는 테이블 형태로 데이터를 저장합니다. 행과 열로 구분된 표를 생각하면 이해하기 쉽습니다. 마치 엑셀 시트처럼 생겼죠. 예를 들어, 쇼핑몰이 있다고 할 때, ‘고객’이라는 테이블과 ‘주문’이라는 테이블을 만들 수 있습니다. 고객 테이블에는 고객 ID, 이름, 연락처 등이 들어 있고, 주문 테이블에는 주문 ID, 주문 일시, 해당 주문이 어떤 고객의 것인지 등의 정보가 들어 있습니다. 이 둘을 연결할 때는 고객 ID를 기준으로 서로 이어줍니다.

RDB의 장점은 ACID Transactions를 지원한다는 점입니다. 예를 들어, 은행에서 돈을 송금한다고 생각해 볼게요. A라는 계좌에서 돈을 빼고, 그 돈을 B라는 계좌에 넣어야 하는데, 중간에 정전이 되거나 시스템에 문제가 생기면 어떻게 될까요? A 계좌에서는 돈이 빠졌는데 B 계좌에는 돈이 들어가지 않는다면 큰 문제가 되죠. RDB는 이런 상황을 방지하기 위해 “모두 성공하거나, 하나라도 실패하면 전부 취소”라는 원칙을 철저하게 지킵니다. 마치 도미노처럼 하나가 쓰러지면 전부 원위치로 돌아가는 거죠.

PostgreSQL namu.wiki >

하지만 데이터가 지나치게 커지거나, 분석 쿼리를 자주 돌려야 하는 환경에서는 속도가 떨어질 수 있는데요. 수십억 건 이상의 데이터를 다뤄야 한다면, RDB 하나만으로는 확장 비용이 커질 수 있음을 유념해야 합니다.

RDB의 대표적인 예시로는 MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server 등이 있으며, 클라우드에서는 Amazon Aurora, Azure SQL 같은 Managed Service로도 제공됩니다.

Columnar Database: 빅데이터 분석 Columnar Database는 데이터를 열 단위로 저장하고 처리하는 데이터베이스입니다. 학생들의 성적 데이터를 예로 들어볼게요. RDB는 한 학생의 모든 과목 점수를 한 줄에 저장하지만, Columnar DB는 과목별로 모든 학생의 점수를 따로 저장합니다.

이러한 저장 방식은 특히 대규모 데이터 분석에 유리합니다. “전교생의 수학 평균 점수는?”이라는 질문에 RDB는 모든 학생의 모든 과목을 읽어야 하지만, Columnar DB는 수학 점수만 쏙 빼서 계산할 수 있죠.

실제로 우버는 이 점을 활용해, Apache HBase를 도입했는데요. 전 세계 수많은 운행 기록과 사용자 데이터를 빠르게 분석할 수 있게 되었습니다. 넷플릭스도 Amazon Redshift를 사용해, 방대한 시청 기록과 사용자 행동 데이터를 효율적으로 분석하고 있죠.

Redshift

Amazon Redshift, ClickHouse 같은 Columnar Database는 이러한 특성을 활용해 대규모 분석 쿼리를 빠르게 처리합니다. 반면, 한 학생의 전체 성적을 보는 것은 RDB보다 느릴 수 있습니다. 마치 도서관에서 한 분야의 책을 모두 찾기는 쉽지만, 여러 분야에 걸친 책들을 한꺼번에 찾기는 어려운 것처럼요. 또 데이터를 자주 수정하는 작업도 RDB보다는 비효율적입니다.

Document Database: 유연한 데이터 구조의 강자 Document Database는 JSON 같은 문서를 그대로 저장합니다. 서류 파일철을 생각하면 쉬운데요. 각각의 서류마다 들어있는 정보가 조금씩 다르더라도, 한 파일에 다 넣을 수 있죠. 이베이는 이런 특징을 활용해 수많은 상품 정보를 JSON 형태로 저장하고 있습니다. 의류부터 전자제품까지 제각각인 상품 속성을 유연하게 저장하고, 검색할 수 있기 때문이죠. 시스코도 MongoDB를 도입해 고객 지원 로그부터 네트워크 구성 정보까지, 다양한 형태의 데이터를 통합 관리하고 있습니다.

예를 들어, 쇼핑몰에서 다루는 상품 정보를 생각해 볼게요. 의류 상품에는 색상, 사이즈 같은 필드가 필요하고, 전자제품에는 전력 소비량, 크기 등의 필드가 필요합니다.

전통적인 RDB에서는 이렇게 다양한 속성을 처리하기가 까다롭습니다. 모든 가능한 속성에 대해 열을 만들어야 하는데, 그러다 보면 대부분의 열이 비어 있게 되죠. 이건 마치 모든 종류의 상품을 하나의 엑셀 시트에 넣으려고 하는 것과 같습니다. 반면, Document Database에서는 각 상품마다 필요한 정보만 JSON으로 저장할 수 있어 훨씬 효율적입니다.

의류 상품의 경우, 이렇게 저장할 수 있습니다.

Document DB 예시 데이터 구조

이렇게 각 상품의 특성에 맞는 정보만 자유롭게 저장할 수 있습니다. 마치 실제 상품 카탈로그처럼 말이죠. 또한 객체지향 언어로 개발할 때, 객체 형태로 만든 정보를 바로 JSON으로 변환해 저장할 수 있어 개발 속도도 올라갑니다. 다만 구조가 너무 자유로우면, 누가 어디에 어떤 데이터를 넣었는지 찾기 어려울 수 있으니, 어느 정도 규칙을 세워두는 것이 좋습니다.

Document Database는 MongoDB가 대표적인 예시로, 스타트업의 빠른 프로토타이핑부터 대규모 서비스까지 폭넓게 활용되고 있습니다.

MongoDB namu.wiki >

Graph Database: 복잡한 관계를 쉽게 풀다 Graph Database는 노드(node)와 엣지(edge)라는 개념으로 데이터의 관계를 저장합니다. 페이스북은 이 방식을 활용해 사용자, 페이지, 그룹 등을 노드로 표현하고, 그들 사이의 관계를 엣지로 연결해 친구 추천 시스템을 구현했습니다. 링크드인도 비슷한 방식으로 사용자들의 인맥 관계를 그래프로 저장해, ‘People You May Know’ 같은 추천 기능을 제공합니다.

영화에서 범인을 추적하는 장면을 보면, 인물 사진과 사건 정보를 벽에 붙이고 실로 연결하는 모습을 본 적이 있을 텐데요. 바로 이 방식을 데이터베이스로 구현한 것이 Graph Database입니다. RDB에서도 조인(join)으로 관계를 찾을 수 있지만, Graph Database는 훨씬 직관적으로 복잡한 관계를 추적할 수 있게 해줍니다. 추천 시스템이나 소셜 네트워크 분석 등에 자주 쓰이며, ArangoDB나 Neo4j 같은 것이 예로 꼽힙니다.

Vector Database: AI 시대의 새로운 주역 Vector Database는 텍스트, 이미지, 음성, 동영상 등 다양한 형태의 데이터를 임베딩(embedding) 기법으로 숫자 벡터로 변환하여 저장합니다. 넷플릭스는 이 기술을 활용해 사용자의 시청 이력을 벡터로 변환하고, 이를 기반으로 개인 맞춤형 콘텐츠를 추천합니다. 핀터레스트도 이미지를 벡터로 저장해 “이 이미지와 비슷한 다른 이미지”를 빠르게 찾아주는 검색 기능을 제공하고 있죠.

그리고 이 벡터들끼리의 거리를 계산해 비슷한 데이터를 찾을 수 있죠. 예를 들어, 이미지를 업로드했을 때 “이 이미지와 유사한 이미지”를 찾아주는 검색 엔진을 만드는 것이죠.

AI나 ML 모델에서는 단어나 문장을 벡터로 바꿔서 “이 말과 의미가 비슷한 다른 말”을 찾는 데 활용하곤 합니다. Vector Database는 이러한 벡터들을 효율적으로 저장하고, 거리 계산을 최적화해 유사도 검색을 돕습니다.

최근 Vector Database가 주목받는 이유는 크게 두 가지인데요. 첫째는 ChatGPT로 대표되는 LLM(Large Language Model)의 부상입니다. 기업들은 LLM을 자사의 서비스나 내부 업무에 활용하고 싶어 하지만, LLM은 학습된 데이터 이외의 정보는 알 수 없고 때로는 잘못된 정보를 생성하기도 합니다.

둘째 이러한 한계를 극복하기 위해 RAG(Retrieval-Augmented Generation)가 등장했습니다. RAG는 질문이 들어오면 먼저 Vector Database에서 관련 정보를 찾고, 이를 바탕으로 LLM이 답변을 생성하는 방식입니다. 예를 들어, 회사의 최신 제품 정보나 내부 문서에 관한 질문에도 정확하게 답할 수 있게 되는 거죠.

현재 시장에는 다양한 Vector Database가 있는데요. 그중 Pinecone는 마이크로소프트, 액센츄어, 노션이 활용하고 있고, Milvus는 세일즈포스와 그랩이, Weaviate는 디스코드, 존슨앤존슨, 퍼플렉시티 등이 실제로 활용하고 있습니다. 이처럼 AI나 생성형 모델이 인기를 끌면서 Vector Database의 활용 사례도 계속 늘어나고 있는 상황입니다.

Key-Value Database: 단순함이 주는 강력함 Key-Value Database는 이름처럼 Key와 Value 쌍으로 데이터를 보관합니다. X는 Redis를 활용해 사용자의 타임라인과 세션 정보를 캐싱하여 빠른 응답 속도를 제공합니다. 아마존은 자체 개발한 DynamoDB로 쇼핑카트 정보를 저장하고, 대규모 트랜잭션을 처리하고 있죠. 이처럼 실시간성이 중요한 서비스에서 Key-Value Database가 많이 활용됩니다.

예를 들어, 웹사이트의 세션을 관리할 때 세션 ID를 Key로 잡고, 그 안에 담을 세션 정보를 Value로 넣으면, 세션 ID만 알면 해당 정보를 곧바로 가져올 수 있어 로그인 상태를 유지할 수 있습니다. 대부분 메모리에 저장하기 때문에 접근 속도가 매우 빠르며(서브 밀리초), 특히 분산 시스템에서 설정 정보나 상태 정보를 저장하는 데 유용합니다.

Document Database도 내부적으로는 Key-Value와 유사하지만, Document Database는 JSON 형태로 구체적인 필드 조회가 가능하다는 차이가 있습니다. Key-Value Database는 구조가 단순해 빠르고, 캐싱이나 세션 관리 같은 곳에서 자주 씁니다. Memcached, Redis 등이 대표적이며, Kubernetes가 etcd라는 Key-Value Database를 사용해 내부 클러스터 정보를 저장하기도 하죠.

Key-Value Database는 실시간 서비스에서 특히 유용합니다. 예를 들어, 게임 서버에서는 사용자의 상태 정보를 Key-Value Database에 저장하고, 실시간으로 조회합니다. Key-Value Database는 이러한 실시간 조회를 빠르게 처리할 수 있기 때문에, 많은 게임 서버에서 활용되고 있습니다.

Time-Series Database: 시간의 흐름을 담다 Time-Series Database는 시계열(time-stamped) 데이터를 처리하기에 최적화된 데이터베이스입니다. 사운드클라우드는 InfluxDB를 사용해 서비스의 성능과 트래픽 지표를 시간순으로 모니터링합니다. 에어비앤비도 Prometheus를 도입해, 예약 수나 접속량 같은 중요 지표들을 실시간으로 추적하고 있죠. 이건 마치 병원에서 환자의 체온을 시간대별로 기록하는 차트나, 기상청에서 매 시간 기온을 기록하는 것과 비슷합니다.

예를 들어, 서버 모니터링 시스템을 생각해 볼게요. 매 분마다 이런 정보들이 쌓입니다.

시간: 2024-12-27 10:50:00

CPU 사용률: 75%

메모리 사용량: 8.2GB

디스크 사용량: 256GB

네트워크 트래픽: 150Mbps

시간: 2024-12-27 10:51:00

CPU 사용률: 82%

메모리 사용량: 8.5GB

디스크 사용량: 256GB

네트워크 트래픽: 180Mbps

데이터는 시간이 지날수록 계속 쌓이는데, Time-Series Database는 이 특성에 맞춰 다양한 최적화 기능을 제공합니다. 디스크 사용량처럼 자주 변하지 않는 값은 특별히 압축해서 저장하고, 오래된 데이터는 자동으로 1분 단위에서 1시간 평균으로 변환하는 식으로 해상도를 낮춰서 보관합니다. 또한 “최근 1시간 동안 CPU 사용률이 90%를 넘은 시점이 언제인가?”와 같은 시계열 특화 쿼리도 빠르게 처리할 수 있죠.

그래서 언제, 어떤 DB를 사용해야 할까? 그렇다면 언제 어떤 DB를 사용해야 할까요? 데이터베이스를 새로 도입하거나, 교체할 때는 여러 가지 조건을 꼼꼼하게 따져봐야 합니다. 무작정 새로운 기술에 끌려가다가는 운영 안정성이나 예산 측면에서 낭패를 볼 수 있기 때문이죠.

처음부터 새로운 DB로 갈아타는 대신, 지금 사용하는 DB를 조금 더 손봐서 문제를 해결할 수 있는지부터 확인해야 합니다. 예를 들어, RDB라면 테이블에 적절한 인덱스를 추가하거나, 쿼리 최적화를 하면 속도를 크게 개선할 수 있습니다.

혹은 캐싱 레이어를 추가해서 자주 쓰는 데이터를 메모리에서 처리하면, 데이터베이스 본체에 가해지는 부하를 줄일 수도 있습니다. 이렇게 간단한 튜닝만으로도 꽤 많은 문제를 해결할 수 있죠. 마이그레이션은 시간이 오래 걸리고 잘못되면 서비스 장애로 이어질 위험도 크기 때문에, 우선 현재 시스템을 어떻게 고칠 수 있는지 살펴보면 좋습니다.

그리고 “현재 업무가 어떤 유형의 데이터를 다루고, 어떤 기능을 가장 필요로 하는가?”를 살펴봐야 합니다. 다음은 그 예시입니다.

RDB: 금융이나 재고처럼 트랜잭션 안정성이 매우 중요한 분야일 때 Columnar Database: 대규모 로그나 분석 같은 통계성 작업을 빠르게 처리해야 할 때 Document Database: 상품 속성이 각기 다를 때 Graph Database: 소셜 관계나 추천 시스템처럼 복잡한 연결고리를 찾야 할 때 Vector Database: AI나 ML 모델을 쓰고 있을 때 Key-Value Database: 세션이나 캐싱처럼 단순 조회가 중요할 때 Time-Series Database: 시간대별로 쌓이는 로그나 센서 데이터일 때

이렇게 각 DB마다 잘하는 일이 달라서, 우리 비즈니스 상황에 맞춰 가장 적합한 것을 선택해야 합니다. 때로는 하나의 시스템에서 여러 데이터베이스를 함께 사용하는 것도 좋은 선택이 될 수 있습니다.

마치며 지금까지 RDB, Columnar, Document, Graph, Vector, Key-Value, Time-Series 같은 다양한 데이터베이스 유형을 살펴보았습니다. 각 DB는 저장 방식부터 트랜잭션 처리, 확장성, 그리고 데이터 조회 방식 등에 이르기까지 특성이 모두 다릅니다.

그래서 데이터베이스를 선택할 땐 우선 기존 환경을 튜닝할 수 있는지 살펴보고, 과연 다른 DB로 갈아탈 만한 이유가 있는지 생각해 봐야 합니다. 그리고 실제 업무에서 요구하는 기능이 무엇인지, 데이터 유형은 어떤지 분석하여, 각 DB의 강점과 맞춰봐야 합니다. 마지막으로 마이그레이션 계획과 테스트까지 철저히 해둔다면, 서비스 중단이나 속도 저하 같은 문제를 줄일 수 있습니다.