스타트업에서의 오버스펙 서버 개발

주니어인 내 입장에서 설계한 내용들이 찬찬히 살펴보면 오버스펙인 경우가 많다.

그 중 가장 큰 오버스펙이 무엇이였는지를 회고해보려고 한다.

 

"어떤 나라에서도 동작하는 서비스" 라는 요구사항을 하나 받았다. 즉, 글로벌 서비스를 만들자 라는 이야기다.

 

나는 요구사항을 받자마자, 어떻게 하면 나라에 상관없이 동작하는 서비스를 구현할 수 있을 까에 초점을 맞추었다.

기능적 구현에 초점을 맞춘 나는, 무의식적이든 의도이든 DB에 사용자의 time zone 정보 즉, 'Asia/Seoul' 과 같은 문자열을 설정 정보로 저장했다.

주된 이유는 다음과 같다.

 

1. 극초기 스타트업 상황 상, DB나 서버를 늘리면 적지 않은 비용이 들기에, 하나의 DB에 모든 데이터를 적재하기로 결정하였다.

2. 서비스 특성 상, 각 나라별 00시 ~ 23시 59분 까지의 데이터 만으로 별로 연산을 해주어야 했기 때문에, 사용자의 위치에 따라서 time zone을 적용하면 안되고, 제품이 설치된 나라의 time zone에 의해서 동작해야했다.

 

여기에서 바로 경험에 차이가 나오는데, 글로벌 서비스 임에도 불구하고 전혀 고려하지 못한 점이 있다.

 

1. 지금 단계에서 글로벌 서비스를 생각하는게 맞는가?

2. 글로벌 서비스를 하는게 맞다면, 글로벌 서비스를 위한 서버 아키텍처는 어떤 방법을 선택할 것인가?

3. 한국에 서버가 있다면, 한국과 먼 나라일 수록 속도가 느려지는데, 서비스에 지장이 없는가? 혹은, 심각한 유저 경험(UX)을 유발하는가?

 

기능적으로 "글로벌"에 초점을 맞춘 나머지, 여러 좋은 선택들이 있었음에도 불구하고, 기존 생각에 매몰되어 좋지 않은 선택을 해버렸다. 설상가상, 기획이 끊임없이 변경되며, 설계가 점점 꼬이기 시작했고, "글로벌" 이전에, 한국에서라도 잘 되는 서비스가 되어야 했다.

바로 이걸 깨닫는 시점에서, 고려할 필요도 없던 것을 고려했다는 "오버스펙"임을 깨달았다.

 

만약, 좀더 생각했다면 어떤 아이디어들이 있었을 까?

 

1. 시스템 내부적으로는 어떻게든 UTC 만으로 연산할 방법을 찾아서, UTC로 통일한 연산법들을 만들면, 개발자는 힘들지언정, 해당 시스템을 한국에 두든, 미국에 두든 얼마든지 리전을 확장하여, 속도와 글로벌 서비스 확장에 문제가 없도록 할 수 있을 것이다.

2. 각 나라별로 동작하는 시스템을 만들어서, time zone을 마치 환경변수처럼 넣어서 동작하도록 하는 것이다. 이 방법도 각 리전마다 확장이 가능하다.

3. time zone 정보가 무슨 일이 있어도 꼭 필요하다면, 차라리 UTC time column(timestamptz)말고도,  time zone time column(timestamp)을 추가해서, 용량을 포기하고, 개발 이점을 가져가는 방법도 가능하다.

 

이런 방법은 우선 한국에서 잘 되고, 해외로 나갈 수 있는 초석을 마련할 뿐더러, 글로벌 서비스를 만들 때 적은 공수로 복제하듯 만들어 낼 수 있을 것이다.

 

내가 겪은 사항에 대해서만 적어서, 다른 사람이 읽으면, 두서 없이 무슨 소리를 하는 건가 싶을 것이다.

그래도, 나는 이 글을 이후에도 계속 보면서, 나의 실수를 잊지 말자.