같은 관리자 페이지처럼 보여도, 도메인이 다르면 콘솔을 나눠야 한다

운영 콘솔 아키텍처 시리즈 2/9

운영 도구를 만들다 보면 처음에는 "관리자 페이지 하나에 메뉴만 추가하면 되지 않을까?"라는 생각을 하기 쉽다. 실제로 화면만 보면 비슷해 보인다. 로그인하고, 목록을 보고, 상태를 바꾸고, 파일을 내려받는다.

하지만 관리자 페이지가 비슷한 모양을 하고 있다고 해서 같은 애플리케이션이어야 하는 것은 아니다. 내가 운영 콘솔을 설계하면서 가장 먼저 내린 결정은 콘솔을 하나로 합치지 않는 것이었다.

문제 상황

만들어야 했던 도구는 크게 두 종류였다.

첫 번째는 외부 파트너가 신청한 데이터를 내부 운영자가 확인하고, 일정이나 결과를 공개하는 신청 관리 콘솔이었다. 데이터 원천은 외부 폼과 스프레드시트였고, 변경은 특정 기간에 몰렸다. 외부 사용자가 보는 공개 페이지도 필요했다.

두 번째는 내부 운영자가 매일 사용하는 운영 리포트 콘솔이었다. 이 콘솔은 내부 데이터베이스를 조회하고, 리포트를 만들고, 오래 걸리는 파일 생성 작업도 처리해야 했다. 접근 권한은 내부 인증 체계와 연결되어야 했다.

두 도구는 모두 React SPA로 만들 수 있었다. 하지만 사용자, 데이터 원천, 장애 영향 범위, 배포 리듬이 달랐다.

선택지

첫 번째 선택지는 하나의 거대한 관리자 페이지로 합치는 것이었다. 공통 레이아웃과 인증, 라우팅을 공유할 수 있고, 저장소도 하나만 관리하면 된다. 초기 개발 속도만 보면 이 선택이 가장 쉬워 보인다.

두 번째 선택지는 콘솔을 도메인별로 나누는 것이었다. 각 콘솔이 별도 SPA, 별도 배포 단위, 별도 API 경계를 갖는다. 중복되는 설정은 조금 생기지만, 장애와 변경의 영향 범위가 좁아진다.

나는 두 번째 방식을 선택했다.

최종 결정

신청 관리 콘솔과 운영 리포트 콘솔을 분리했다.

분리 기준은 기술 스택이 아니라 책임 경계였다.

기준	신청 관리 콘솔	운영 리포트 콘솔
주요 사용자	외부 파트너, 내부 운영자	내부 운영자
데이터 원천	폼, 스프레드시트, 파일 저장소	내부 RDB
변경 빈도	특정 기간에 집중	상시 운영
주요 작업	신청 확인, 공개 데이터 조회	조회, 분석, 리포트 생성
장애 영향	공개 신청 흐름에 영향	내부 운영 업무에 영향

얻은 것

가장 큰 장점은 배포 영향 범위가 작아진 것이다. 운영 리포트 콘솔에서 리포트 다운로드 기능을 바꾸다가 문제가 생겨도, 신청 관리 콘솔의 공개 페이지에는 영향을 주지 않는다. 반대로 신청 기간이나 공개 화면을 수정해도 내부 리포트 기능은 그대로 유지된다.

권한 모델도 단순해졌다. 외부 사용자가 접근할 수 있는 공개 영역과 내부 운영자만 접근하는 영역은 보안 관점에서 전혀 다르다. 이를 하나의 라우터 안에서 계속 분기하면 시간이 갈수록 예외가 늘어난다. 콘솔을 나누면 경로, 캐시, 인증 정책을 더 명확하게 둘 수 있다.

데이터 모델의 차이도 분리할 수 있었다. 신청 관리 콘솔은 스프레드시트가 Source of Truth이고, 애플리케이션은 그 데이터를 읽기 좋게 캐싱해 보여주는 역할에 가깝다. 운영 리포트 콘솔은 내부 RDB를 직접 조회하고 리포트 작업 상태를 관리해야 한다. 이 둘을 같은 데이터 접근 계층으로 묶으면 추상화가 오히려 흐려진다.

포기한 것

공통 레이아웃, 디자인 시스템, 배포 스크립트 일부는 중복될 수밖에 없다. 두 콘솔이 모두 React SPA라면 라우팅, API 클라이언트, 에러 처리 방식도 비슷해진다.

하지만 이 중복은 감수할 만했다. 공통화를 너무 빨리 하면 서로 다른 도메인의 요구사항이 하나의 공통 모듈에 섞인다. 운영 도구에서는 코드 몇 줄의 중복보다 권한과 장애 범위가 섞이는 비용이 더 컸다.

다시 설계한다면

처음부터 공통 패키지를 만들지는 않을 것이다. 대신 두 콘솔이 충분히 안정된 뒤, 반복되는 UI 컴포넌트나 API 에러 처리만 작은 공통 라이브러리로 빼는 순서를 택하겠다.

콘솔 분리는 되돌리기 어렵기 때문에 기준도 명확해야 한다. 단순히 메뉴가 많다는 이유로 나누는 것은 부족하다. 사용자, 데이터 원천, 배포 주기, 보안 정책 중 둘 이상이 다르면 분리를 검토할 만하다.

정리

관리자 페이지를 하나로 만들지 여러 개로 나눌지는 화면 개수의 문제가 아니다. 책임 경계의 문제다.

사용자가 다르고, 데이터 원천이 다르고, 장애 영향 범위가 다르면 같은 React SPA라도 별도 콘솔로 나누는 편이 운영하기 쉽다. 아키텍처의 첫 결정은 어떤 기술을 쓸지가 아니라 무엇을 같은 경계 안에 둘지 정하는 일이었다.

함께 볼 GitHub 저장소

• ops-console-architecture-playbook