해당 글에선 테넌트(Tenant)라는 용어와 환경(Environment)이라는 용어를 동일하게 사용합니다 🙇🏻‍♂️

배경

모두싸인에서 근무하며 계약 관리, API 연동, 그로스팀 등 다양한 목적을 가진 팀을 경험했다.
그러던 중 온프레미스(on-premise) 형태로 서비스를 제공할 수 있는 구축형 서비스가 필요해졌고, 내가 Frontend Engineer로 참여하게 되었다.

여러 테넌트에서 모두싸인 서비스를 각 환경의 특성에 맞게 제공할 수 있어야 했고, 기능적인 부분은 주로 “A, B, C 기능 중 A와 B만 동작한다” 와 같은 분기 처리가 필요했다.
이러한 요구사항은 기존 기능 중 일부만 노출하거나, 기능 동작을 조금씩 수정해 제공하는 형태여야 했기 때문에 흔히 생각할 수 있는 MicroFrontend 방식은 적합하지 않았다(인적·금전적 리소스 문제도 있었다).

그 결과, 하나의 코드로 여러 테넌트 환경에 맞는 서비스를 제공하고 운영할 수 있는 구조를 설계하게 되었다.

내용

개인 블로그에는 보안 정책으로 인해 구체적인 작업 내용을 작성하기 어려워, 사내 기술 블로그에 정리해 공유했다.

👉🏻 사내 기술 블로그 - 하나의 코드로 멀티 테넌트 서비스 운영하기 👈🏻

느낀점

테넌트 시스템을 설계하면서 다방면으로 챌린지가 있었다.

1. 문서화 & 설득

온프레미스 프로젝트는 Frontend Engineer가 나 혼자였지만, 변경 범위는 프론트엔드 챕터 전체에 영향을 주었기 때문에 변경 사항을 자주 공유하고, 팀원들의 의견을 반영하며, 불가능한 부분은 설득해야 했다.
초반에는 어려웠지만 점차 적응하면서 점점 더 잘 해낼 수 있었다.
중요했던 것은 왜 이런 선택을 하려는지, 다른 선택지와 비교했을 때 어떤 트레이드오프가 있는지를 명확히 하고, 설득할 수 있는 근거 자료를 충분히 모아 문서화하는 일이었다고 생각한다.

2. 시스템 설계

작은 프로젝트에서는 시스템을 쉽게 수정·개선할 수 있었지만, 이렇게 방대한 코드가 쌓여 있는 프로젝트에서 시스템을 개선하고 설계한 것은 처음이었다.
다른 도메인 팀에서는 실시간으로 개발과 배포가 이루어지고 있었기 때문에 영향 범위 최소화, 하위 호환성 유지, 이슈 발생시 빠른 대응 등 고려해야 할 요소가 많아 접근 자체가 쉽지 않았다. 다행히 경험이 많은 CTO님과 DevOps 엔지니어(전 Frontend Engineer) 한 분의 도움으로 이러한 요소들을 꼼꼼히 체크하며 설계할 수 있었다.
앞으로 다시 비슷한 상황이 온다면, 이번 경험이 큰 자산이 될 것이라 생각한다.