작은 관리자 페이지도 아키텍처가 필요한 이유

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

관리자 페이지는 종종 작게 시작한다.

목록 하나, 상세 화면 하나, 상태 변경 버튼 하나. 처음에는 단순 CRUD처럼 보인다.

그래서 "이 정도는 그냥 만들면 되지 않을까?"라고 생각하기 쉽다.

하지만 실제 운영에 쓰이는 관리자 페이지는 생각보다 빨리 복잡해진다. 인증, 권한, 배포, 캐시, API, 파일 다운로드, 장애 대응, 데이터 원천 같은 문제가 화면 뒤에 붙기 시작한다.

작은 관리자 페이지에도 아키텍처가 필요한 이유는 규모 때문이 아니다.

업무가 그 도구에 의존하기 때문이다.

사용자 수보다 업무 중요도가 중요하다

운영 도구는 사용자가 많지 않을 수 있다.

하루에 몇 명만 쓰는 화면일 수도 있다.

하지만 그 몇 명이 매일 중요한 업무를 처리한다면 시스템의 중요도는 낮지 않다.

예를 들어:

• 운영자가 매일 확인하는 대시보드
• 월말에 반드시 생성해야 하는 리포트
• 외부 사용자에게 공개되는 신청 결과
• 내부 데이터와 연결된 상태 변경 화면

이런 기능은 대중 서비스처럼 트래픽이 크지 않아도 멈추면 업무가 멈춘다.

따라서 설계 기준을 사용자 수만으로 잡으면 안 된다.

작은 도구에서 자주 만나는 문제

작은 운영 도구도 금방 이런 질문을 만난다.

• 로그인은 어떻게 처리할 것인가
• 외부 사용자와 내부 사용자를 어떻게 나눌 것인가
• React SPA는 어디에 배포할 것인가
• API는 Lambda로 만들 것인가, 상주 서버로 둘 것인가
• 파일 다운로드가 오래 걸리면 어떻게 처리할 것인가
• 데이터 원천은 DB인가, 스프레드시트인가, 외부 시스템인가
• 배포 후 캐시 문제는 어떻게 해결할 것인가
• 장애가 나면 누가 어떤 로그를 볼 것인가

이 질문들은 단순 화면 구현을 넘어선다.

그래서 아키텍처가 필요하다.

아키텍처는 거창한 그림이 아니다

아키텍처라고 하면 대규모 분산 시스템이나 복잡한 다이어그램을 떠올릴 수 있다.

하지만 작은 운영 도구에서 아키텍처는 더 실용적인 의미다.

• 무엇을 같은 애플리케이션에 둘 것인가
• 무엇을 별도 배포 단위로 나눌 것인가
• 어떤 데이터가 원천인가
• 어떤 작업은 동기로 처리하고 어떤 작업은 비동기로 처리할 것인가
• 장애가 어디까지 번지게 둘 것인가
• 나중에 바꿀 수 있는 부분은 어디인가

즉, 아키텍처는 책임 경계를 정하는 일이다.

과한 설계와 부족한 설계 사이

작은 도구에서 가장 어려운 것은 균형이다.

너무 과하게 설계하면 개발 속도가 느려지고 운영 부담이 커진다.

처음부터 Kubernetes, 복잡한 event bus, 다중 환경, 완전한 모니터링 체계를 모두 넣으면 작은 팀이 감당하기 어렵다.

반대로 너무 단순하게 만들면 나중에 업무가 붙을 때 구조가 무너진다.

모든 기능을 하나의 서버와 하나의 DB와 하나의 관리자 화면에 밀어 넣으면 권한, 배포, 장애 영향 범위가 섞인다.

좋은 설계는 현재 규모에 맞게 단순하지만, 바꿔야 할 조건을 알고 있는 구조다.

책임 경계가 먼저다

기술 선택보다 먼저 봐야 할 것은 책임 경계다.

예를 들어 두 화면이 모두 관리자 페이지처럼 보여도 다음이 다르면 분리할 수 있다.

• 사용자가 다르다.
• 데이터 원천이 다르다.
• 배포 주기가 다르다.
• 장애 영향 범위가 다르다.
• 보안 정책이 다르다.

이 기준이 맞으면 같은 React SPA라도 별도 콘솔로 나누는 것이 더 나을 수 있다.

반대로 기술 스택이 다르다는 이유만으로 무조건 나눌 필요는 없다.

분리 기준은 기술이 아니라 책임이다.

변경 가능성을 설계하기

운영 도구는 요구사항이 자주 바뀐다.

운영 방식이 바뀌고, 리포트 형식이 바뀌고, 외부 입력 항목이 바뀌고, 권한 정책이 바뀐다.

따라서 처음부터 완벽한 구조보다 변경 가능한 구조가 중요하다.

예를 들어:

• 정적 프론트엔드는 S3와 CloudFront에 둔다.
• 잦은 조회 API는 상주 서버로 둔다.
• 오래 걸리는 파일 생성은 worker로 분리한다.
• 외부 입력 데이터는 원천과 캐시를 나눈다.
• 아키텍처 결정은 문서로 남긴다.

이런 구조는 변경 지점을 좁힌다.

장애 영향 범위를 줄이기

작은 도구에서도 장애는 난다.

중요한 것은 장애가 어디까지 번지는가다.

리포트 다운로드가 실패해도 대시보드는 살아 있어야 할 수 있다.

외부 신청 화면에 문제가 생겨도 내부 리포트 기능은 영향받지 않아야 할 수 있다.

정적 파일 배포가 데이터 파일을 덮어쓰면 안 된다.

이런 판단은 구현 중 자연스럽게 해결되지 않는다.

처음 설계할 때 경계를 잡아야 한다.

정리

작은 관리자 페이지에도 아키텍처가 필요하다.

그 이유는 시스템이 커서가 아니라, 실제 업무가 그 도구에 의존하기 때문이다.

좋은 설계는 거창한 기술 조합이 아니다.

다음 질문에 답하는 것이다.

• 무엇을 같은 경계 안에 둘 것인가
• 무엇을 분리할 것인가
• 어떤 데이터가 원천인가
• 어떤 작업은 비동기로 처리할 것인가
• 장애가 어디까지 번지게 둘 것인가
• 나중에 어떤 조건이 되면 바꿀 것인가

관리자 페이지가 작을 때 이 질문을 해두면, 나중에 커졌을 때 덜 흔들린다.

함께 볼 GitHub 저장소

• practical-system-design-playbook