[WHY 시리즈 1] E.004 — 서버 분리, 데이터 모델 관계, API Resource
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
호찌민(사이공)에서의 4주 차가 시작되었다. 한 달이 되어가니 여기에서의 생활에도 나만의 패턴이 생기기 시작했다. 이번 주는 프로덕트의 첫 릴리즈를 위한 Phase 3가 시작되는 한 주였으며, 동료들과 시스템 개발을 위한 설계에 대해 본격적으로 시작한 한 주였다. 주로, 동료들과의 논의에서 재미있는 주제가 나왔으며 그 주제의 결론에 대해 Why를 던져본다.
Why?
1. API 서버 분리
서버 백로그 그루밍(Backlog grooming) 작업을 하던 중, 다른 서버 개발자 동료와 현재의 Monolithic 서버 구조를 변경하는 일에 대해 이야기를 나누었다. [WHY 시리즈 1] E.002에서 언급한 것처럼 분산 시스템은 현재까지의 고려대상이 아니었다. 자연스럽게, 해당 백로그를 남은 Phase 3, Phase 4의 태스크로 결정할 것인가 아닌가에 대한 이야기가 오고 갔다. 결론은 Phase 3, Phase 4의 태스크로 포함시키지 않기로 했다.
- Why? 도메인을 어떻게 분리시킬 지에 대한 학습이 필요하다. 단순히 엔드 포인트 별로 서버를 분리한다면(예를 들어, 일반 사용자 / 에이전트 / 관리자 / 라이더 등) 분산된 monolith 구조가 될 가능성이 크다(이러고 나중에 이런 생각을 하겠죠. ‘어랏, 난 분명 서버를 분리했는데 왜 자꾸 여러 서버에 같이 배포하는 거지..’)
- Why? 지금까지의 에피소드에서 계속 언급한 것처럼, 첫 릴리즈 전까지의 목표는 일반 사용자가 서비스를 이용하는데 기능적으로 문제없는 시스템을 개발하는 것이다. 이 관점에서 생각했을 때 API 서버 분리는 높은 우선순위가 아니라고 판단했다. 도메인 분리를 어떻게 가져갈지에 대한 학습 시간이 중요하다고 생각했으며, 비록 남은 Phase 3와 Phase 4의 태스크로 포함시키지는 않았지만, 부지런히 이에 대한 고민과 학습은 병행되어야 한다고 생각한다.
Note: Distributed Monolith vs. Microservices Architecture: 4 Ways New Relic Can Tell You Which Is Which 확인
2. 데이터 모델 관계 설정
프로덕트를 위한 Phase 3가 시작되었고, 지금부터는 프로모션 관련 시스템이 함께 개발되어야 한다. 추가적인 시스템 개발이 필요하게 되면서 데이터 모델 구조에 대해 동료들과 논의하는 시간을 갖게 되었다. 여러 가지 논의 중, 프로모션 데이터 모델과 다른 데이터 모델의 관계를 데이터베이스 레벨에서 설정할 것인가 아니면 애플리케이션 레벨에서 코드로 처리할 것인가에 대한 이야기가 있었다. 데이터베이스 레벨에서 설정한다면 Aggregation과 같은 기능을 통해 비교적 쉬운 방법으로 데이터를 조회할 수 있지만, 애플리케이션 레벨에서 코드로 처리하는 것으로 결정했다.
- Why? 프로모션과 관련된 다른 데이터 모델이 증가할 때, 유연한 구조를 가져갈 필요가 있다. 현재는 첫 릴리즈에 꼭 필요한 요구사항만 도출하여 설계 및 개발을 진행하고 있기 때문에 프로모션과 관련된 데이터 모델이 많지 않은 상황이다. 하지만 프로모션이라는 개념은 충분히 다른 데이터 모델과 많은 관계를 맺을 가능성이 높고, 그때 마다 관련된 데이터 모델의 구조를 함께 변경해야 하는 상황은 피하는 것이 좋다고 판단했다.
- Why? 서버 분리 시, 방해가 될 요소를 제거해야 했다. 현재는 API 서버 분리는 높은 우선순위의 고려대상이 아니라고 말했지만, 프로모션이라는 도메인 자체는 추후에 독립적으로 분리될 가능성이 크다고 판단했다. 자연스럽게 데이터베이스 레벨에서 다른 도메인 영역의 데이터 모델과의 관계를 최소화하는 것이 현명하다고 판단했다. (데이터 마이그레이션 작업을 위한 필요 이상의 리소스 사용, 서버를 분리했다면서 데이터베이스를 공유하는 잘못된 구조 등에 대한 리스크를 최소화하기 위함)
처음에는 데이터베이스 레벨에서 결정할 수 있는 선택사항들에 대해서만 논의를 했다. 애플리케이션 레벨에서 코드로 처리하는 선택사항까지 논의를 확장하게 된 계기는 이런 생각을 하면서부터였다. ‘첫 릴리즈 이후, 프로모션과 관련된 데이터 모델은 빠르게 증가할 것이다.’
3. API Resource 표현
특정 기능을 위해 API를 설계하다가 API Resource를 표현하는 일이 난감해져서 동료에게 도움을 요청했다. ‘이게 이렇게 시간을 잡아먹을 일인가?’ 라는 생각이 들어 동료의 시간을 요청했고, 왜 Resource를 표현하는 일이 어려웠는지 알게 되었다.
- Why? 해당 API는 (역시나) 부족한 시간으로 인해, 임시로 추가된 기능이었다. 즉, 이 API는 사용될 엔드 포인트나 도메인 영역이 명확하지 않은 상황이었다. API URI 설계 시, 정보의 자원과 자원에 대한 행위가 표현되어야 한다는 기준을 갖고 있는데, 이 기준으로 쉽게 Resource를 표현할 수 없다는 것은 ‘이 API의 대상 자원이 있을 곳은 여기가 아닌가 봐..’ 라고 판단을 하게 만들었다.
당장은 해당 API가 포함되어야 하는 도메인 영역을 명확하게 설계하고 개발할 수 없는 상황이라, 처음 결정대로 임시적인 기능으로써 진행할 수밖에 없다. 하지만 Resource에 대한 표현은, 명확한 도메인 영역이 존재한다는 전제하에 표현하는 것으로 마무리 지었다.
Note: Microsoft Azure API design — Organize the API around resources
설계를 진행하는 과정에서 동료들과의 논의는 항상 충만하다. 서로의 의견을 공유하고, 피드백을 주고받는 과정에서 생각의 폭이 넓어진다. 이제 다가오는 새로운 한 주에는 우아한 코드를 작성하게 될 테니 기대하지 않을 수 없다.
