장애 영향 범위를 줄이는 콘솔 분리 전략

기술 실무 설계 시리즈 4/8

관리자 페이지를 만들다 보면 모든 기능을 하나로 합치고 싶어진다.

공통 레이아웃을 쓰고, 로그인도 한 번만 만들고, 메뉴만 추가하면 될 것처럼 보인다.

하지만 화면이 비슷하다고 같은 애플리케이션이어야 하는 것은 아니다.

사용자, 데이터 원천, 권한, 배포 주기, 장애 영향 범위가 다르면 콘솔을 나누는 편이 더 안정적일 수 있다.

하나로 합치면 생기는 장점

하나의 관리자 페이지로 합치면 장점이 있다.

• 공통 레이아웃을 재사용할 수 있다.
• 인증 처리가 한 곳에 모인다.
• 배포 단위가 하나다.
• 메뉴 이동이 쉽다.
• 초기 개발이 빠를 수 있다.

작은 규모에서는 이 장점이 크게 보인다.

그래서 처음에는 통합 관리자가 자연스러워 보인다.

하지만 책임이 섞인다

문제는 시간이 지나면서 나타난다.

서로 다른 업무가 같은 애플리케이션에 들어오면 책임이 섞인다.

예를 들어:

• 외부 사용자도 보는 공개 페이지
• 내부 운영자만 보는 리포트 화면
• 스프레드시트 기반 신청 데이터
• RDB 기반 운영 데이터
• 짧은 조회 API
• 오래 걸리는 파일 생성

이것들이 하나의 라우터, 하나의 배포, 하나의 권한 모델 안에 섞이면 예외가 늘어난다.

분리 기준 1. 사용자

사용자가 다르면 분리를 검토한다.

예를 들어 외부 파트너가 접근하는 화면과 내부 운영자만 접근하는 화면은 보안 기준이 다르다.

외부 사용자는 공개 가능한 데이터만 봐야 한다.

내부 운영자는 더 많은 정보와 기능을 본다.

이 둘을 같은 애플리케이션에서 계속 조건 분기하면 실수 가능성이 커진다.

사용자 그룹이 다르면 콘솔 경계도 달라질 수 있다.

분리 기준 2. 데이터 원천

데이터 원천이 다르면 분리를 검토한다.

한 콘솔은 스프레드시트와 S3 JSON을 원천처럼 사용할 수 있다.

다른 콘솔은 RDB와 내부 API를 직접 조회할 수 있다.

데이터 원천이 다르면 장애 지점과 운영 방식도 달라진다.

스프레드시트 동기화 실패와 RDB connection 문제는 전혀 다른 문제다.

같은 데이터 계층으로 묶으면 오히려 추상화가 흐려질 수 있다.

분리 기준 3. 배포 주기

배포 주기가 다르면 분리를 검토한다.

공개 신청 화면은 특정 기간 전에 안정화가 중요할 수 있다.

내부 리포트 화면은 운영 요청에 따라 자주 바뀔 수 있다.

같은 애플리케이션에 있으면 내부 리포트 수정이 공개 화면 배포에도 영향을 줄 수 있다.

분리하면 각 콘솔을 독립적으로 배포하고 롤백할 수 있다.

분리 기준 4. 장애 영향 범위

가장 중요한 기준은 장애 영향 범위다.

한 기능의 장애가 다른 업무를 멈추게 하면 안 된다.

예를 들어:

• 리포트 다운로드 실패가 신청 확인 화면을 막지 않아야 한다.
• 공개 페이지 배포 문제가 내부 대시보드에 영향을 주지 않아야 한다.
• 외부 동기화 실패가 내부 운영 DB 조회를 막지 않아야 한다.

분리는 장애의 전파를 줄이는 방법이다.

중복을 감수할 수 있는가

콘솔을 나누면 중복이 생긴다.

• 레이아웃
• API 클라이언트
• 에러 처리
• 배포 스크립트
• UI 컴포넌트

하지만 모든 중복이 나쁜 것은 아니다.

책임 경계를 유지하기 위한 중복은 감수할 수 있다.

특히 초기에는 너무 빨리 공통화하지 않는 편이 낫다.

반복이 충분히 보인 뒤, 정말 안정된 부분만 공통 라이브러리로 빼면 된다.

분리의 비용

분리에도 비용이 있다.

• 저장소나 폴더가 늘어난다.
• 배포 스크립트가 늘어난다.
• 환경 변수가 늘어난다.
• 공통 UI가 중복된다.
• 문서가 더 필요하다.

따라서 단순히 화면이 많다는 이유로 나누면 안 된다.

분리 기준은 사용자, 데이터 원천, 배포 주기, 보안 정책, 장애 영향 범위여야 한다.

이 중 둘 이상이 다르면 분리를 검토할 만하다.

정리

콘솔 분리는 화면 개수의 문제가 아니다.

책임 경계의 문제다.

하나로 합치면 초기 개발은 쉬울 수 있다.

하지만 사용자, 데이터, 권한, 배포, 장애 영향 범위가 다르면 시간이 지날수록 예외가 늘어난다.

좋은 분리는 중복을 조금 감수하고, 변경과 장애의 범위를 줄인다.

관리자 페이지도 도메인이 다르면 나눌 수 있다.

중요한 것은 기술 스택이 아니라 책임 경계다.

함께 볼 GitHub 저장소

• practical-system-design-playbook