[WHY 시리즈 1] E.001 — mLab, 업무분석, API
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
1/2 수요일, 약 6시간의 비행 끝에 베트남 호찌민 시티에 도착했다. 새로운 환경, 새로운 직장에서 새로운 일을 맞이하게 됐다. 1/3 목요일, 오피스로 첫 출근을 하고 동료들과 인사를 나누었다. 목요일, 그리고 금요일 이틀 동안 업무 환경에 적응하고 동료 엔지니어가 기존에 구축한 서버에 대해 동기화하는 시간을 가졌다. 동료의 선택 혹은 나의 선택에 Why를 던져본다.
Why?
1. mLab
기존에는 AWS EC2 인스턴스에서 직접 DB를 설치하고, 수동으로 관리하고 있었다. Phase 1 개발이 종료되면서, 기본적인 아키텍처 구성이 완료되었다. 앞으로 서비스가 커지고, 다양해짐에 따라 수동으로 유지보수하는 일이 많아진다면 장애 발생 가능성 또한 높아질 것이다 (난 나의 손을 믿지 않아..). 또한, DB를 전문적으로 다루는 별도의 팀이 존재하지 않는 이상, 작은 개발 조직의 DB 수작업은 여간 부담스러운 것이 아니다. 그래서, 클라우드 데이터베이스 서비스인 mLab을 사용하게 되었다고 한다.
- Why? 개발 관점이 아닌 유지보수 관점에서 불필요한 사람의 실수를 예방하기 위함.
- Why? 자동화 혹은 대체 서비스를 통해 주 역할에 집중하기 위함.
- Why? (아직 미래의 일이지만) Backup, Replication, Sharding 설정의 간편함을 위함.
하지만, mLab is becoming a part of MongoDB, Inc.에 따라 MongoDB가 mLab을 인수함으로써, Migrating to MongoDB Atlas 작업이 예상된다.
2. 약 40개의 API 실행
입사 1일 차, 업무 환경을 위해 수많은 계정을 생성하고 확인했다. 개발 환경을 설정하고 로컬에서 서버가 실행되는 것을 확인한 후 퇴근했다. 입사 2일 차, Phase 2를 위해 개발되어 있던 API 서버를 확인하기 시작했다. 약 40개의 API를 로컬 서버에서 하나씩 직접 실행하고 결과를 확인했다. POSTMAN을 통해 API가 잘 정리되어 있었기 때문에 예상보다 오랜 시간이 걸리지 않았다.
- Why? 비즈니스 로직을 파악할 수 있음. 비즈니스 흐름의 각 단계에서 ‘누가’ ‘무엇을 위해’ 어떤 API를 사용하는지 확인함으로써 더욱 깊이 있는 이해가 가능함.
- Why? 현재 시스템의 깊은 이해를 위한 질문 도출 가능. 단순하게 API를 실행하고 결과 Response를 확인하는 것에서 끝나지 않음. ‘이 API 로직은 어떻게 구현되어 있을까?’ ‘이 Response 데이터와 관련된 DB 스키마는 어떻게 설계되어 있을까?’ 등의 궁금증이 생기면 자연스럽게 코드 및 DB 스키마를 확인하게 되고 다양한 질문이 도출됨. (예를 들어, 인증 레벨은 어떻게 설계되었나? 이 API에 권한이 필요한 이유가 있을까? 수정 불가능한 상태에서 API 요청 처리는 어떻게 해야 할까? 등..)
이번주에 도출한 질문에 대해 이야기할 다음 주가 기대된다.
3. 동일한 기능에 대한 API 분리
업무 내용이기 때문에 PayPal API를 예로 들어 설명한다. 결제 상세정보를 조회하기 위한 API가 필요하다고 가정했을 때, Customer를 위한 API와 Merchant를 위한 API 2개로 분리된 형태를 발견했다. 아직 이 궁금증에 대해서는 동료와 이야기를 나누지 않았기 때문에 나의 생각만 정리하도록 한다.
2개의 API로 분리하지 않고, 결제 상세정보를 위한 API 1개만 유지할 수 있지 않을까 생각한다 (GET /v1/payments/{payment_id}).
- Why? 이미 access token을 통해 사용자 권한 및 정보를 확인할 수 있음.
- Why? API URI의 복잡도가 증가하면 유지 보수하기 어려워질 수 있으며, 변화에 유연하지 못할 수 있음 (현재 그렇다는 것이 아니며, 앞으로의 가능성).
Note: Microsoft Azure API design, Microsoft REST API Guidelines 확인
