우리는 무엇을 만들고 있는가 (공개 가능한 부분만)
세 명이 풀스택으로 운영하는 서비스의 구조와 방향에 대해, 외부에 공개할 수 있는 범위 안에서 솔직하게 이야기한다.
소개할 수 있는 것과 없는 것
우리 팀이 만드는 서비스는 일부 계약상, 일부는 현재 운영 중인 특성상 세부 내용을 공개하기 어렵다. 그래서 이 글은 서비스 자체가 아니라, 서비스를 만들면서 우리가 취하고 있는 방향과 기술적 선택에 초점을 맞춘다.
무엇을 만들고 있는가
B2B 성격의 웹 서비스다. 복수의 사업자가 하나의 플랫폼 위에서 각자의 고객에게 서비스를 제공하는 구조다. 간단히 말해 멀티 테넌트 구조의 운영 플랫폼이다.
정산, 권한 관리, 이력 추적이 핵심 도메인이다. 이 세 가지는 “잘 됐을 때는 아무도 모르지만 잘못되면 바로 티 나는” 도메인이라는 공통점이 있다.
기술 스택 선택의 기준
스택을 고를 때 우리가 세운 기준은 두 가지였다.
하나는 팀원 모두가 유지보수할 수 있는가다. 특정 팀원만 이해하는 코드나 도구가 생기면 버스 팩터가 낮아진다. 세 명이 운영하는 팀에서 버스 팩터 1은 치명적이다.
다른 하나는 운영 부담이 얼마나 되는가다. 우리는 개발과 운영을 동시에 한다. 화려한 기능보다 운영이 조용한 스택이 실제로 더 낫다.
그 결과 일부 기능에서 최신 트렌드를 포기했다. 예를 들어 이벤트 소싱이나 CQRS 같은 패턴을 검토하다가 현재 팀 규모와 요구사항에는 오버킬이라는 결론을 내렸다.
현재 단계에서 가장 신경 쓰는 것
지금 우리가 가장 많은 에너지를 쓰는 부분은 데이터 정합성이다. 멀티 테넌트 환경에서 테넌트 간 데이터 격리가 완벽하게 작동하는지, 잔액 계산이 어떤 타이밍에도 틀리지 않는지를 반복적으로 검증하고 있다.
기능을 더 빠르게 추가하는 것보다 지금 있는 것이 확실하게 동작하는 것을 우선순위에 둔다. 규모가 작을 때 데이터 문제를 정리해두지 않으면 나중에 훨씬 큰 비용을 치르게 된다.
앞으로 공개할 수 있는 것들
몇 달 안에 서비스의 일부 영역을 더 구체적으로 이야기할 수 있을 것 같다. 기술적 결정 과정, 데이터 모델 설계, 운영 중에 발견한 엣지 케이스들을 이 블로그에 계속 올릴 예정이다.
만드는 것 자체보다 만드는 과정에서 배운 것을 공유하는 것이 더 오래 남는다고 생각한다.
— by mings