회원 도메인 공통 모듈화

만든 것

• 공통 모듈사이트와 무관하게 같은 의미를 갖는 회원 · 인증 기능
• 사이트별 모듈지마켓 · 옥션 각각의 정책
• 통합 모듈두 사이트를 함께 다루는 기능
• 조합 배포필요한 모듈을 묶어 사이트별 서비스로
• API 게이트웨이인증 · 권한 검증, 멀티테넌시 라우팅, 모니터링

DB가 하나라고 개발이 한 번은 아니었다

지마켓과 옥션은 통합 DB를 쓰고 있었지만 API 계층은 나뉘어 있었습니다. 구조가 같은 기능도 사이트마다 두 번 만들고 두 번 검증해야 했습니다. 팀에서 회원정보 · 로그인 · 캐싱 API를 공통 모듈과 사이트별 모듈로 나누고, 필요한 모듈을 조합해 사이트별 서비스로 배포하는 구조를 함께 설계했습니다.

공통화의 기준은 코드가 비슷한가가 아니라 업무 의미와 변경 이유가 같은가로 잡았습니다. 그래야 나중에 한쪽만 바뀌어야 할 때 공통 모듈이 발목을 잡지 않습니다.

내가 맡은 자리

이 구조 위에서 제휴 · 인증 모듈을 주로 개발했습니다. 전체 아키텍처는 팀 공동 작업이고, 제 판단이 들어간 범위는 제휴와 인증 모듈 안에서 어떤 기능을 공유하고 어떤 정책을 사이트별로 남길지 정한 부분입니다.

서비스가 분화되면서 인증 · 권한 검증을 서비스마다 반복하기 어려워져, Gravitee API 게이트웨이 도입에도 참여했습니다. 호출자 인증을 게이트웨이로 모으더라도 특정 회원 데이터에 접근해도 되는지 같은 도메인 권한은 애플리케이션이 따로 판단해야 한다는 경계를 의식했습니다.

지금 상태

프로덕션에 배포되어 운영 중이고, 새 연동을 붙일 때 공통 모듈을 재사용하는 기반이 생겼습니다. 공수를 얼마나 줄였는지 측정한 수치는 없어서, 그 부분은 재사용된 사례로만 설명합니다. 공통 모듈의 결함은 두 사이트에 함께 번질 수 있어서 배포 순서와 버전 관리가 더 중요해졌습니다.

돌아보면

공통화는 중복을 줄이는 대신 공통 결함의 영향 범위를 넓힙니다. 무엇을 합치고 무엇을 남길지 정하는 일이 구조 설계의 핵심이라는 걸 배웠습니다.