올바른 데이터베이스 선택이 중요한 이유
비개발자를 위한 데이터베이스 선택 기준. 가장 유명한 제품이 왜 정답이 아닌지, RTO/RPO, 총소유비용, 벤더 락인까지 제품 이름보다 먼저 물어야 할 열 가지 질문을 정리합니다.
가장 유명한 제품이 정답은 아니다
"비개발자가 알아야 할 데이터베이스 이야기" 12부작 중 5편입니다. 데이터베이스 선택이 왜 기술 취향이 아니라 사업 결정인지, 그리고 제품 이름보다 먼저 물어야 할 질문들을 정리합니다.
심화 읽기: 구체적인 제품 비교와 비용 구조 분석은 현대식 클라우드 데이터베이스 선택 가이드에서 다룹니다.
새 서비스를 시작할 때 "어떤 데이터베이스가 가장 빠른가?"라고 묻기 쉽다. 그러나 이 질문만으로는 올바른 답을 얻기 어렵다. 승용차와 화물차 중 무엇이 더 좋은지 묻는 것과 비슷하다. 목적지와 짐을 말하지 않으면 답이 없는 질문이다.
데이터베이스 선택은 단순한 기술 취향이 아니다. 서비스 속도, 장애 위험, 개발 기간, 운영 인력, 보안, 비용, 그리고 나중에 제품을 바꾸는 어려움에 영향을 준다. 그리고 그 영향은 개발팀이 아니라 사업 전체가 떠안는다.
잘못 고르면 어떤 일이 생길까?
1. 중요한 정보가 서로 다르게 보인다
정확한 거래가 필요한 업무에 일관성 관리가 약한 방식을 무리하게 적용하면 재고, 잔액, 예약 상태가 화면마다 다르게 보일 수 있다. 2편에서 본 정확성 장치가 약한 선택의 결과다.
2. 사용자가 늘수록 속도가 급격히 떨어진다
처음에는 모든 제품이 빨라 보일 수 있다. 그러나 데이터 양, 동시 사용자, 검색 방식이 늘면 차이가 드러난다. 특히 자주 하는 질문과 맞지 않는 구조라면 서버를 늘려도 비용만 커질 수 있다. 페이지 로딩이 느려지는 것은 기술 지표가 아니라 이탈률과 매출의 문제다.
3. 작은 변경도 어렵고 비싸진다
상품 항목이 계속 바뀌는데 지나치게 고정된 구조를 사용하면 매번 큰 수정이 필요할 수 있다. 반대로 회계 자료처럼 기준이 분명해야 하는 곳에 구조를 너무 자유롭게 두면 데이터 정리가 어려워진다. 경직된 구조와 방만한 구조, 어느 쪽도 대가가 있다.
4. 운영할 사람이 없다
기능이 뛰어나도 팀이 설치, 모니터링, 백업, 장애 복구를 감당하지 못하면 좋은 선택이 아니다. 채용 시장의 규모, 외부 지원, 문서, 관리형 서비스의 수준도 함께 봐야 한다. 최신 기술일수록 전문가가 드물어 장애 대응과 인력 충원이 어려워진다는 점을 기억하자.
5. 예상하지 못한 비용이 생긴다
저장 공간만 보고 가격을 계산하면 안 된다. 읽기·쓰기 요청, 데이터 전송, 백업, 복제본, 로그, 기술 지원, 운영 인력도 비용이다. 특히 클라우드 밖으로 데이터를보낼 때 부과되는 전송 비용을 놓치기 쉽다. "구입 비용"이 아니라 **3~5년간의 총소유비용(TCO)**으로 비교해야 한다.
6. 나중에 옮기기 어렵다
특정 제품만 제공하는 기능을 깊게 사용하면 이전 비용이 커진다. 이를 **공급업체 종속(vendor lock-in)**이라고 한다. 데이터베이스 교체는 "비행 중인 비행기의 엔진을 교체하는 것"에 비유될 정도로 어렵다. 종속이 무조건 나쁜 것은 아니다 — 독자 기능으로 더 빨리 가치를 만들 수 있다면 합리적일 수 있다. 다만 그 선택과 탈출 비용을 알고 결정해야 한다.
제품 이름보다 먼저 물어야 할 열 가지
- 무엇을 저장하는가? 고객, 결제, 문서, 센서 값, 이미지 중 무엇인가?
- 가장 자주 하는 질문은 무엇인가? 고객 한 명을 찾는가, 수년치 자료를 분석하는가?
- 정확성이 어느 정도 중요한가? 몇 초의 차이를 허용할 수 있는가?
- 얼마나 빨라야 하는가? 사용자가 기다릴 수 있는 시간은 얼마인가?
- 얼마나 많이 들어오는가? 하루 총량뿐 아니라 가장 몰리는 순간(피크)도 봐야 한다.
- 데이터 구조가 자주 바뀌는가? 새로운 항목과 관계가 얼마나 자주 생기는가?
- 서비스가 멈춰도 되는 시간은 얼마인가? 장애 후 언제까지 복구해야 하는가?
- 얼마만큼의 데이터를 잃어도 되는가? 전혀 잃을 수 없는가, 최근 몇 분은 감당할 수 있는가?
- 누가 운영하는가? 팀의 경험과 24시간 대응 능력은 어느 정도인가?
- 법과 계약상 조건은 무엇인가? 저장 지역, 보관 기간, 암호화, 감사 기록 요구가 있는가?
7번은 복구 목표 시간(RTO), 8번은 **복구 목표 시점(RPO)**이라고 부른다. RTO가 2시간이면 장애 후 2시간 안에 서비스를 되살리는 것이 목표다. RPO가 15분이면 최악의 경우 최근 15분 이내의 데이터 손실을 감수하는 설계다. 이 숫자는 기술팀이 아니라 비즈니스가 정해야 한다 — "우리 고객은 몇 시간의 중단을 용인하는가"는 사업의 질문이기 때문이다.
작은 팀에 필요한 현실적인 원칙
새로운 기술이 항상 더 나은 선택은 아니다. 많은 일반 업무에서는 널리 쓰이는 관계형 데이터베이스와 관리형 서비스를 조합하는 것만으로 충분하다. 서비스의 특별한 요구가 분명해질 때 검색, 캐시, 벡터 저장소 등을 추가해도 늦지 않다.
데이터베이스를 하나 더 추가할 때마다 백업, 권한, 모니터링, 버전 관리, 장애 대응 대상도 하나씩 늘어난다. 기술의 수가 곧 역량은 아니다.
비교 시험은 실제 업무로 한다
제품 소개 자료의 성능 숫자만 비교하지 말고, 우리 서비스에서 자주 일어날 작업을 작게 재현해 보는 편이 낫다. 예상 데이터 양, 동시 접속자 수, 가장 복잡한 검색, 장애 복구 절차를 시험한다. 기술 검증(PoC)의 목적은 멋진 시연이 아니라 중요한 가정을 확인하는 데 있다. "사용자가 10배로 늘어도 버티는가", "담당자가 한 명뿐인데 운영이 가능한가" 같은 가정 말이다.
핵심 정리 올바른 데이터베이스는 가장 빠르거나 최신인 제품이 아니라 업무의 정확성, 속도, 규모, 운영 능력, 비용, 규제 조건에 맞는 제품이다. 선택 전에 저장할 데이터와 자주 할 질문을 먼저 정의해야 한다. 작은 팀은 단순하게 시작하고, 분명한 문제가 생길 때 새로운 저장 방식을 추가하는 편이 안전하다.
의사결정 회의에서 물을 질문
- 이 선택이 해결하는 가장 중요한 문제는 무엇인가?
- 같은 문제를 현재 데이터베이스로 해결할 수 없는 이유는 무엇인가?
- 3년간의 총비용에는 인력, 백업, 데이터 전송, 지원 비용이 포함되어 있는가?
- 장애가 나면 누가 어떤 순서로 복구하는가?
- 이 제품에서 나와야 할 때 데이터와 기능을 어떻게 옮길 것인가?
다음 글: 어떤 데이터베이스를 선택해도 피할 수 없는 데이터 모델과 품질 문제를 다룬다. 좋은 창고에 나쁜 물건을 담으면 무슨 일이 생기는지 — "Garbage In, Garbage Out"의 이야기다.
시리즈 목차
- 데이터베이스란 무엇인가 — 엑셀 파일과 무엇이 다를까?
- 데이터베이스는 어떻게 정확성을 지킬까
- 데이터베이스에는 어떤 종류가 있을까
- 데이터베이스, 데이터 웨어하우스, 데이터 레이크
- 올바른 데이터베이스 선택이 중요한 이유 ← 현재 글
- 데이터 모델과 데이터 품질
- 데이터 거버넌스란 무엇인가
- 개인정보는 적게, 필요한 만큼만
- 데이터 보안의 기본
- 데이터 침해는 왜 일어나며, 발생하면 무엇을 해야 할까
- 클라우드와 서버리스 데이터베이스
- AI 시대의 데이터베이스
