Day12. 딜라이트룸에서 DB 기획하기 (삽질 덜 하기)

안녕하세요, 기획자 팥씨입니다 🥮

오늘은 DB 를 처음 설계하거나 변경, 개선하려 할 때 꼭 기억해야 할 3가지에 대해 다뤄보겠습니다.

 

다음 분기에 5개월 일하기 vs. 지금 5시간 논의하기

제품의 성장을 위해 좋은 글 써주신 Chan 님 감사합니다.☺️

최근에 사이드프로젝트를 시작하면서 DB 를 기획할 때 어려움을 겪었는데,

조금 더 빨리 읽으면 좋았을걸..!! 하는 생각이 들었습니다. 🥲

 

(아래의 예시는 알람앱 '알라미'로 설명되므로, 이를 참고해주세요.)

 

제품이 '잘' 성장하기 위한 DB 설계 시 질문법

1. 제품의 OOO 확인하기
2. OOO인 상황 상상해보기
3. 제품이 사용되는 OOO 확인하기

 

1. 제품의 [로드맵] 확인하기

 

@딜라이트룸 미디엄_ 새로운 컬럼을 계속 추가하게 된다면..?

 

 

새로운 컬럼을 추가한다는 것, DB Migration 은 시간과 비용이 드는 일입니다.

따라서, 애초에 이러한 확장성을 고려하여 적절한 DB를 설계하는 것이 중요한데요.

 

이러한 경우 필요한 것은 두 가지입니다.

1. '미래의 필요에 쉽게 대응할 수 있는 유연한 테이블'

2. 하나의 알람이 울리고 해제되기까지 한 세트로 묶이는 것은 유지

 

해당 요구사항에 맞춰 아래와 같이 테이블 구조가 바뀌었습니다.

1. 알람 관련된 기록들을 대등한 관계로 둔다.

2. 같은 알람에서 발생한 것이라면 같은 '울림 ID' 값을 갖도록 한다.

 

@딜라이트룸 미디엄 _ 기록들은 '이벤트'라는 이름 아래 대등한 관계로, 같은 알람이라면 같은 '울림 ID'를 가집니다.

 

이러한 적절한 DB 설계/변경을 위해서는, 앞으로의 전략과 방향성을 체크해보는 게 중요합니다.

"제품의 로드맵"을 확인하는 것이죠.

 

체크리스트는 아래와 같습니다.

 

(1) 앞으로 '이런 기능'을 추가하게 될 수도 있는데 문제 없을까?

(2) 반대로, '저런 기능'은 빼버릴 수도 있는데 이 칼럼이 없어져도 괜찮을까?

(3) 나중에 로드맵이 바뀌어도 지장이 적은 방법은 없을까?

🍯 앞으로의 로드맵이 명확하지 않다면, 비슷한 서비스에는 어떤 데이터가 있는지 둘러보기

 

2. [극단적]인 상황을 상상해보기

Hint : 이 데이터를 하루에 1000개, 매년 10년씩 쌓는다면?

 

수면기록을 1분 단위로 기록하게 되면 상세한 분석을 할 수 있지만,

매일 8시간 수면모드를 쓰면 10년 뒤에는 180만개 행이 됩니다. 220만 DAU가 모두 이만큼씩 사용한다면..(말잇못)

 

단순히 데이터가 많다는 것뿐만 아니라,

'다르게 구성하면 같은 데이터를 더 작은 양으로 담을 수 있다는 것'이 문제입니다.

현재 데이터에 낭비가 있을 수 있다는 것이죠. 

 

@ 딜라이트룸 미디엄

 

일반적인 상황에서는 문제가 없어 보이더라고, 극단적인 양과 시간을 가정해보면

현재 어느 부분에 비효율이 있는지 눈에 보입니다. 

이를 통해 지금의 구조를 효율화 해두면, 앞으로 DB 구조를 유지보수해나가는 과정에서의 시행착오를 줄일 수 있습니다.

 

(1) 이 기능을 10,000명의 유저가 하루에 1,000번 10년 내내 사용한다면?

(2) 지금 저장하고 있는 데이터의 목적이 무엇이지? 꼭 필요한가?

(3) 지금 저장하고 있는 데이터 중 하나로 통합할 수 있는 것은 없을까?

 

3. 제품이 사용되는 [플랫폼] 확인하기

Hint : 새로운 OS로 확장한다면? 웹/앱을 연결한다면?

 

개발 시점에 따라 iOS / AOS 에서 사용하는 DB 이름이 다를 수 있습니다.

하지만! 언젠가 안드로이드에 애플 로그인을, 아이폰에 구글 로그인을 붙인다면?

안드로이드 기기에서 울린 데이터를 아이폰에서 읽을 수 있어야 할 겁니다.

 

이러한 경우를 대비해 이름값을 통일해야 하며,

해당 이름값이 어떤 경우에 쓰이는지를 추적하여 동일하게 변경해줘야 합니다.

ex) 'memory'라는 값이 있다고 하면, 단순 저장할때만 쓰이는 게 아니라 알람 해제 화면을 띄울 때에도 쓰일 수 있습니다.

이러한 경우 모두를 고려하여 한번에 바꿔주어야, 나중에 오류가 나지 않을 것입니다.

 

@딜라이트룸 미디엄 _ 플랫폼간 이름값 통일

 

안드로이드, iOS 뿐만 아니라 제조사별 OS, 웹/앱 간 호환, Watch/Pad OS 등

우리가 사용할 수 있는 운영 체제는 생각보다 많습니다.

제품이 커지고 복잡도가 높아질수록, 지금 바꿀 값이 언제 어디에서 쓰일지 100% 확인하기 어려워집니다.

 

최선은 배포전에 값을 맞춰두는 것!

지금 5분 논의해서 나중에 정책파악/디버깅/수정하는 5시간을 아낄 수 있습니다.

 

(1) 지원하는 / 지원할 플랫폼에 어떤 것이 있는가? 여러 플랫폼에서 같은 형식과 값을 쓰고 있는가?

(2) 해당 값과 형식이, 쓰이는 모든 시점에 동일하게 저장되어 있는가?

🍯 DB에 사용할 컬럼 이름, 값 이름에 대해 원칙을 세워두면 이름 통일을 위한 논의 시간이 짧아진다.

 

🎇 이 모든 것은, 제품의 성장을 위해서

정리하면 아래와 같습니다.

1. 제품의 로드맵 확인하기 = 확장성
2. 극단적인 상황 상상해보기 = 지속성
3. 제품이 사용되는 플랫폼 확인하기 =  호환성

@딜라이트룸 미디엄 _ 시간이 지날수록 우상향할 수 있도록 하는 것.

 

3가지 속성 모두, 제품의 성장이라는 동일한 목적을 바라보고 있습니다.

성장 곡선이 최대한 가파르게 올라갈 수 있도록 '병목을 제거하는 것'이죠.

 

따라서, DB 에 대한 논의가 애초에 왜 필요한가?에 대한 답은

논리적으로 완벽한 구조를 짜기 위해서가 아니라

제품이 잘 성장할 수 있도록 기반을 다지기 위함입니다.