[WHY 시리즈 1] E.002 — Monolith, 요구사항, Pull Request
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
호찌민 시티에서의 2주 차 생활에 접어들었다. 환경 설정의 1주 차를 지나고, 본격적으로 나의 업무 및 현재 프로젝트에 대한 이해를 시작했다. 기존의 코드를 구체적으로 살펴보기 시작했고, 현재 프로젝트에 나의 코드를 조금씩 작성하기 시작했다. 5개월의 공백 기간을 지내고, ‘아 다시 개발을 시작하는구나’ 체감했다. 이번 주도 역시 동료의 선택과 나의 선택에 Why를 던져본다.
Why?
1. 시작은 Monolithic
현재까지 구축된 시스템은 Monolithic 시스템이다. 여러 가지 도메인이 결합할(아직은 그렇지 않다는 이야기) 서비스를 위한 시스템이기에 분산 시스템을 고려할 수도 있다. 서비스 복잡도가 증가할수록 Monolithic 시스템 구조로 인한 문제가 발생할 수 있다(특정 프로젝트의 장애가 전체 서비스의 장애로 이어질 수 있거나, 항상 전체 배포를 수행해야 한다거나, 코드 분석 복잡도의 증가라던가, 오랜 빌드 시간으로 인한 개발 시 불편함이라던가..). 그럼에도 불구하고, 현재는 Monolithic 시스템이며 분산 시스템을 구체적으로 고려하고 있지 않다.
- Why? 현재 우리는 최대한 빠르게 서비스를 구축해서 시장의 반응을 보는 것이 중요하다. 또한, 개발 리소스가(인력, 시간) 충분한 상황이 아니다. 지금 보유한 리소스로 최대한 빠르게 서비스를 구축한다는 목표를 달성하기 위해, 분산 시스템은 아직 고려대상이 아니다.
- Why? 현재 리소스로 어떻게든 꾸역꾸역 분산 시스템을 설계하고 구축한다 하더라도, 문제가 많은 설계를 결과로 내놓지 않을 자신이 없다. 오히려 Monolithic 시스템 구조로 가져가되, 그 안에서 도메인이 잘 분리될 수 있는 구조를 유지하며 개발하는 것이 낫다고 생각한다. (설계 원칙들을 제대로 공부하고 적용하면서)
결국, 현재는 분산 시스템으로 굳이 설계하고 구축할 이유가 없다는 것이 결론이다.
2. 요구사항 제안
Voucher 서비스의 결합이 필요했고, 이를 위한 리서치를 수행하고 우리가 구축할 수 있는 서비스의 유형을 PM에게 선제안(?)했다. 흔히 우리는 기획하는 과정에서 요구사항이 결정되면, 개발자는 이를 전달받아 설계 후 개발을 진행하게 된다. 요구사항이 결정되는 과정에서 기획을 수행하는 사람과 개발자 간에는 수많은 미팅을 통해 서로가 이해하고 있는 것 그리고 할 수 있는 것을 동기화하는 과정이 필요할 수도 있다. 하지만, 우리가 현재 구축하고 있는 서비스는 (위에서 언급한 것처럼) 최대한 빠르게 서비스를 구축해야 하며, 동기화하는 시간을 최소화할 수 있다면 그렇게 하는 것이 좋다.
- Why? 개발자가 리서치를 수행한 후, 우리가 할 수 있는 것을 선제안(?) 한다면, 우리가 현재 할 수 없는 것을 인지하지 못한 상황에서 나온 무리한 요구사항의 리스크를 감소시킬 수 있다.
- Why? 이는 결국, 불필요한 시간을 최소화시킬 수 있다.
3. Pull Request
호찌민에 온지 2주차, 동료의 Pull Request 리뷰를 시작했고 가능한 꼼꼼하게 코멘트를 남기려고 노력했다. ‘아, 이렇게 구현이 가능하구나’ 생각하며 LGTM을 남기고 끝난 리뷰도 있었고, 하나의 코멘트에 10개 이상의 쓰레드가 남겨져 있는 리뷰도 존재했다. 각자가 맡은 기능에 대해 구현하기도 바쁜 와 중에 왜 우리는 서로의 코멘트에 의견을 달고, 또 달고, 리뷰를 지속했을까?
- Why? 동료의 PR을 리뷰하면서 신규 입사자인 나는 현재 프로젝트 및 구조에 대해 더 깊게 이해할 수 있다. 기존 개발자들에게는 익숙하고 당연한 코드도, 나에게는 궁금증의 대상이 되었고 관련 코드들을 찾아가다 보면 현재 프로젝트에 대해 자연스럽게 공부하는 시간을 갖게 됐다.
- Why? 동일한 기능의 구현 방법에 대해 서로 다른 의견을 갖고 있을 수 있다. 그리고 우리는 각자의 서비스를 구현하는 것이 아니며, 서로의 코드를 통해 하나의 서비스를 구현하는 것이다. 즉, 우리의 PR 리뷰는 서비스를 더 잘 만들기 위한 동일한 목표를 위해 노력하는 것이다.
코드 리뷰를 통해 다양한 구현 방법에 대한 의견으로 생각의 폭을 넓힐 수도 있고, 코드 자체의 명료함과 품질도 향상시킬 수 있으며, 자칫 놓칠 수 있는 오류도 사전에 발견할 수 있는 등 다양한 효과를 누릴 수 있다. 기회를 잡아서 우리 팀의 Pull Request 및 코드 리뷰 프로세스 정리를 위한 시간을 보내기를 희망한다.
