왜 그 데이터베이스를 애플리케이션에 선택했나요?
Source: Dev.to
Resume‑Driven Development, “Google Scale” 오류론, 그리고 결국 우리는 언제나 Postgres를 쓰게 되는 이유에 대한 고백.
신선한 커피 한 잔을 따르고, 손가락 관절을 꺾고, mkdir my-next-billion-dollar-idea 를 입력한 뒤… 몸이 굳는다.
Persistence의 벽에 부딪힌 것이다. 이제 데이터베이스를 골라야 할 때다. 그리고 솔직히 말해서, 시스템 설계 면접에서 내는 답변은 사이드 프로젝트에서 실제로 데이터베이스를 고른 이유와는 거의 다르다.
100 % 정직하게 말한다면, 대부분의 아키텍처 결정 문서는 이렇게 적혀 있을 것이다: “우리는 리드 개발자가 JOIN 문을 무서워해서 MongoDB를 선택했다.” 혹은 “우리는 Netflix에서 일하는 느낌을 내고 싶어서 Cassandra를 선택했다.”
하지만 실제로 선택을 해야 한다. 데이터베이스를 고르는 혼란스러운 의사결정 트리를 살펴보고, 스스로에게 하는 거짓말들, 그리고 눈물 없이 올바른 선택을 하는 방법을 알아보자.
나쁜 데이터베이스 결정의 삼대 악당
1. “Google Scale” 착각
고양이를 위한 할 일 목록 앱을 만든다. 현실적으로 예상되는 사용자는 세 명뿐이다: 나, 파트너, 그리고 만든 테스트 계정. 그런데도 이렇게 생각한다:
“하지만 샤딩은 어떨까? 내 고양이가 인플루언서가 되면 AWS us‑east‑1의 세 가용 영역에 걸쳐 쓰기 가용성을 확보해야 할 수도 있잖아?”
현실 점검: 당신에게는 빅데이터가 없다. 스몰 데이터가 있다. “RAM에 들어가는” 데이터다. 아마 “텍스트 파일에 들어가는” 데이터일 것이다. 5년 뒤에 생길 수도 있는 문제를 위해 최적화하지 말고, 다음 주 화요일에 배포할 수 있도록 최적화하라.
2. Resume‑Driven Development (RDD)
해커 뉴스에서 새로운 벡터 데이터베이스를 본다. Rust로 작성됐고 로고는 멋진 기하학적 여우다. 벡터 임베딩이 뭔지는 모르지만, 이걸 이력서에 넣으면 리크루터가 실수로 20만 달러를 제안할 수도 있다.
현실 점검: 지루한 기술은 돈을 만든다. 흥미로운 기술은 장애를 만든다.
3. “Schema‑less” 함정
“스키마를 정의하고 싶지 않아. 빨리 움직이고 부숴야 해.”
그래서 문서형 저장소를 선택한다. 6개월 뒤, 데이터베이스에는 user_id 가 절반은 문자열, 절반은 정수, 그리고 피곤했던 그 화요일에 만든 레코드에는 null 로 들어 있다.
현실 점검: 스키마는 언제나 존재한다. 데이터베이스가 강제하는 경우(좋음)도 있고, 애플리케이션 코드에 if (typeof x === 'undefined') 같은 난잡한 조건문으로 강제하는 경우(나쁨)도 있다.
실제 메뉴: 당황한 사람들을 위한 가이드
1. 관계형 데이터베이스 (SQL)
후보: PostgreSQL, MySQL, MariaDB
분위기: 세금도 제때 내는 책임감 있는 형/누나.
사용 시점: 95 %의 경우. 데이터에 관계가 있다면(예: Users → Orders → Items) SQL을 사용한다. ACID를 보장하고 구조를 강제한다.
피하는 이유: SQL을 배워야 한다.
사용해야 하는 이유: SQL은 데이터의 공통어다. 우주의 열죽음이 와도 살아남을 것이다.
프로 팁: PostgreSQL을 써라. 이제 JSON 블롭도 지원하니, 사실상 관계형 DB와 NoSQL DB를 겉옷 하나에 입은 셈이다.
2. 문서형 저장소 (NoSQL)
후보: MongoDB, Firestore, DynamoDB
분위기: 혼돈의 예술가 작업실. 모든 걸 한 무더기로 던져두고 나중에 정리한다.
사용 시점:
- 데이터 구조가 급격히 변하는 프로토타이핑.
- 데이터가 진정으로 문서 중심일 때(예: 블로그 포스트와 댓글, 태그를 하나의 객체로).
- ID 하나만으로 거대한 JSON 블롭을 즉시 가져오고 싶은 읽기‑중심 워크로드.
경고: 비관계형 DB에 관계형 데이터를 넣는 것은 애플리케이션 코드에 중첩 루프를 짜는 지옥이다.
3. 키‑값 저장소
후보: Redis, Memcached
분위기: 카페인 주입을 받은 아드레날린 중독자.
사용 시점: 캐싱, 세션 관리, 리더보드.
주된 용도로 쓰지 말 것: 진짜 데이터 원본. 서버가 재시작돼 Redis 인스턴스를 잃어버리면(거기에 사용자 계정이 있었음) … 축하한다, 이제 사용자가 사라졌다.
4. 그래프 데이터베이스
후보: Neo4j, Amazon Neptune
분위기: 빨간 실로 핀을 연결한 음모론 보드.
사용 시점: 데이터 자체보다 관계가 더 중요한 경우—소셜 네트워크, 사기 탐지, 추천 엔진.
수학적 직관: SQL 쿼리에 JOIN 문이 14개나 나오고 실행 시간이 20 초라면, 그래프 DB가 필요할 가능성이 크다.
최종 결론
어떻게 선택할까? 몇 주짜리 리서치를 절약해 주는 간단한 알고리즘을 소개한다:
- AI 앱을 위해 벡터 기반 복잡 검색이 필요합니까? 벡터 DB(Pinecone, Weaviate, 혹은 pgvector)를 사용한다.
- 데이터가 문자 그대로 소셜 그래프입니까? 그래프 DB를 사용한다.
- IoT 센서에서 초당 5천만 건의 쓰기가 발생합니까? 시계열 DB를 사용한다.
- 그 외 모든 경우? 관계형 데이터베이스를 사용한다.
“그럼 어느 관계형 DB를 골라야 하지?” 라는 질문이 떠오를 것이다.
호스팅 방법을 아는 DB를 고르면 된다. 아무것도 모른다면 Postgres를 선택하고, 월 $15 정도면 관리형 인스턴스를 구매해 실제 기능 구현에 바로 들어가라.
사용자는 당신이 어떤 DB를 쓰는지 신경 쓰지 않는다. 로그인 버튼이 동작하는지에만 관심 있다.