서론

소프트웨어 개발에서는,

• MySQL 등의 RDB (Relational Database)
• MongoDB 등의 NoSQL (Not Only SQL)
• Redis와 같은 인메모리 DB (In-memory DB)

등 다양한 DB가 사용됩니다. 중요한 것은 "어떤 DB가 최강인가"가 아닙니다.

실제 설계에서는 무엇을 우선하고 무엇을 버릴 것인가라는 "트레이드오프 (Trade-off)" 판단이 매우 중요해집니다.

"정합성 (Consistency)을 우선할 것인가", "스케일 (Scale)을 우선할 것인가", "개발 속도를 우선할 것인가", "검색 성능을 우선할 것인가"에 따라 최적의 DB는 달라집니다.

AI 코딩 시대이기에 설계 판단이 매우 중요해지고 있으며, 메가 벤처나 외자계 기업의 면접에서는 이러한 판단력을 상당히 유심히 살펴봅니다.

왜 DB 선정은 그렇게 중요한가

DB는 소프트웨어의 토대입니다.

나중에 UI를 바꾸는 것은 비교적 간단하지만, DB는 사용자가 증가하고 소프트웨어에 깊게 통합되면 쉽게 변경할 수 없습니다.

따라서 초기 설계 판단을 그르치면 서비스 성장 후에 큰 문제가 됩니다.

DB 선정을 잘못하면 어떤 일이 발생하는가

① 퍼포먼스 (Performance) 문제

예를 들어, SNS의 타임라인 기능을 생각해 봅시다.

모든 포스트 데이터를 MySQL로 직접 읽으러 가는 설계로 하면, 사용자 증가와 함께 Read 부하가 급증합니다.

그러면 API 응답이 느려지고 UX (User Experience) 악화 등의 문제가 발생합니다.

특히 SNS는 "쓰기 (Write)"보다 "읽기 (Read)"가 압도적으로 많기 때문에, DB가 금방 병목 (Bottleneck) 지점이 됩니다.

예를 들어,

• Redis로 타임라인을 캐싱 (Caching) 한다
• Read Replica로 읽기를 분산한다

등의 대책이 취해집니다.

즉 중요한 것은 "대량의 Read가 발생하는 설계에서 모든 것을 RDB로 직접 던지지 않는 것"입니다.

이 부분을 상정하지 않고 DB를 설계하면 서비스 성장 시 성능 문제가 발생하기 쉽습니다.

② 스케일 (Scale)할 수 없게 됨

예를 들어 EC 사이트를 생각해 봅시다. 초기 단계에서는 많은 경우 "주문", "결제", "재고" 등을 하나의 MySQL로 관리합니다.

이것은 틀린 것이 아닙니다.

오히려 처음부터 샤딩 (Sharding)이나 복잡한 분산 구성을 도입하면,

• 개발 속도 저하
• 운영 복잡화
• 장애 조사 곤란

등의 다른 문제가 발생합니다.

따라서 실제 현장에서도 "우선 단일 RDB로 시작하는" 케이스는 매우 많습니다.

하지만 "장래에 어디서 한계가 올 것인가"를 의식하며 설계하는 것은 잊어서는 안 됩니다.

서비스 성장 후에는,

• 쓰기 집중
• 거대 테이블화
• JOIN 증가
• 락 경합 (Lock Contention)

등이 발생할 가능성이 있습니다.

여기서 문제가 되는 것이 "나중에 분산하기 어려운 설계"가 되어 있는 케이스입니다.

• JOIN 의존이 너무 강함
• 특정 테이블에 액세스 집중
• ID 설계가 분산을 전제로 하지 않음

이러한 구조는 나중에 샤딩이나 DB 분할을 어렵게 만듭니다.

③ 개발 속도가 떨어진다

예를 들어 사양 변경이 격심한 서비스를 엄격한 RDB 설계만으로 진행하는 케이스를 생각해 봅시다.

서비스 초기에는 요구사항 변경이나 컬럼 추가가 빈번하게 일어납니다.

하지만 테이블 설계가 너무 복잡하면 Migration (마이그레이션)이나 Query (쿼리) 수정이 대량으로 발생할 가능성이 있습니다.

결과적으로 "기능 추가를 할 때마다 개발 속도가 떨어지는" 상태가 됩니다.

만약 처음부터 일부를 NoSQL화하거나 이를 내다본 느슨한 결합 (Loose Coupling) 설계 등 유연성을 갖추는 방향으로 했다면 더 좋았을지도 모릅니다.

특히 스타트업 초기에는 "장래에 변할 것을 전제"로 설계하는 것도 중요합니다.

④ 데이터 정합성 (Data Integrity) 문제

예를 들어 EC 사이트에서 재고만 줄어들거나 결제만 성공하는 상황이 발생하면 치명적입니다.

이러한 케이스에서는 "데이터의 정확성"이 최우선이 됩니다.

예를 들어 레이턴시 (Latency)나 스케일러빌리티 (Scalability)를 우선하여 분산 DB나 비동기 처리 등을 안이하게 도입하면 "일시적으로 데이터가 어긋나는" 케이스도 일어날 수 있습니다.

SNS라면 다소 어긋나도 문제없을지 모르지만, 결제와 같이 돈이 얽힌 서비스에서는 이는 허용되지 않습니다.

이러한 케이스에서는,

• MySQL/PostgreSQL
• 트랜잭션 (Transaction)
• 강한 정합성 (Strong Consistency)

을 중시하는 경우가 많습니다.

그럼 어떻게 생각해야 하는가

중요한 것은 그 시스템에서 무엇이 중요한가로부터 역산하는 것입니다.

예를 들어 데이터 정합성을 중시한다면 RDB가 좋을 수도 있고, 유연한 데이터 구조를 원한다면 NoSQL이 적절할 수도 있습니다.

여기에 "정답"은 없습니다. 시스템 디자인은 모두 트레이드오프입니다.

MySQL와 같은 RDB가 적합한 케이스

MySQL 등의 RDB는,

• 결제
• 사용자 정보
• 재고 관리
• 계약 데이터

와 같이, "정확성이 극도로 중요한" 상황에서 강력합니다.

이유는 강력한 일관성 (Consistency) 등에 뛰어나기 때문입니다. 그렇기 때문에 많은 서비스에서 중심 DB로 사용됩니다.

NoSQL이 적합한 케이스

반면, NoSQL은,

• 유연한 데이터 구조
• 대량 데이터
• 고스케일 (High Scale)

이 요구되는 상황에서 사용됩니다. SNS나 실시간 데이터를 처리하는 서비스 등이 이에 해당합니다.

스키마 (Schema) 변경이 많은 서비스에서는 개발 속도를 높이기 쉽다는 장점도 있습니다.

다만 그 대신, JOIN이 약하거나 일관성 설계가 어렵다는 등의 트레이드오프 (Trade-off)도 존재합니다.

마지막으로

DB 선정은 단순한 기술 비교가 아닙니다.

기술을 알고 있는가가 아니라, 미래의 문제를 예측하며 설계할 수 있는가입니다.

• 퍼포먼스 (Performance)
• 스케일 (Scale)
• 개발 속도
• 일관성 (Consistency)
• 운용 (Operation)

등, 시스템 전체와 비즈니스에 장기적으로 영향을 미치는 설계 판단을 올바르게 내릴 수 있는가입니다.

홍보가 되자면, 제가 만든 DevPay에서는,

• DeNA
• Mercari
• CyberAgent
• LINE Yahoo

등 일본의 주요 메가 벤처를 비롯한 다종다양한 채용 경험을 수집하고 있습니다.

"어느 기업에서 어떤 설계 능력이 요구되는가"를 알고 싶은 분들은 꼭 활용해 보시기 바랍니다.