모든 도메인을 삼키는 어드민 공통 모듈을 피하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

어드민은 운영자가 넓은 화면을 필요로 하므로 회원, 메뉴, 리뷰, 마지막 로그인 정보와 다른 도메인을 한꺼번에 조회할 수 있다. 그렇다고 그 개념들이 하나의 도메인이 되는 것은 아니다. 어드민 공통 모듈로 모두 옮기면 서비스를 소비해야 할 도구에 오히려 모든 서비스가 의존할 수 있다.

사례 1: 서비스 모듈이 어드민 공통을 바라본다

가장 분명한 의존성 역전이다. 어드민이 여러 도메인을 조회한다는 이유로 공통 모듈이 모든 것을 알게 되고, 서비스 모듈이 자기 일을 하려고 그 패키지를 가져다 쓴다. 경계 없는 운영 뷰가 시스템의 중심이 된다.

질문에서 가정한 멀티 모듈 구조라면 이 모듈은 만들지 않는 편을 택한다. 도메인 소유권은 서비스에 남기고 어드민이 필요한 데이터를 조합하게 한다. 이미 분리된 저수준 데이터 접근은 재사용할 수 있지만, 어드민이 모든 것을 본다는 이유로 모든 모델을 옮길 필요는 없다.

사례 2: 여러 어드민 화면이 비슷해 보인다

여러 어드민 애플리케이션이 쓸 공통 패키지도 같은 문제가 생긴다. 회원 어드민은 마스킹이 필요하지만 슈퍼 어드민은 아닐 수 있다. 내부 운영자와 외부 가맹점은 다른 동작을 요구할 수 있다. 공통 구현에는 결국 버전과 소비자 전용 함수가 늘어난다.

요구가 서로 달라지는 동안에는 중복이 조금 생겨도 구현을 나눠 둔다. 실제로 함께 필요해진 구체적인 기능이 나타난 뒤에만 공유를 검토한다. 실제 공통 요구가 생겼는지, 계속 갈라지는지가 더 단순한 기준이다.

ERP나 운영 솔루션처럼 어드민 자체를 핵심 제품으로 고객에게 제공하는 경우도 있다. 단순한 내부 조회 도구가 아니므로 별도의 설계 논의가 필요하다. 그래도 하나의 일반 공통 모듈이 모든 개념을 가져야 한다는 결론으로 바로 이어지지는 않는다.

어드민 하나의 요구만 달라질 때는 작은 개별 구현이 거대한 공통 패키지보다 고치기 쉽다. 여러 도메인을 보는 것은 어드민의 역할이지만 여러 도메인을 소유할 필요는 없다.