1. 목표/아키텍처 (React + Node + Nginx + Auth)
인프노트랩
인프라 자동화 & 협업 도구/인프라 관리 포털·대시보드
1. 목표/아키텍처 (React + Node + Nginx + Auth)
2025. 12. 28. 18:54

A. “인프라 포털 만들기” 시즌 1 — 1화

목표/아키텍처 (React + Node + Nginx + Auth)

이 글은 “기술 설치서”가 아니라, 운영자 관점에서 왜 이런 구조를 선택했는지를 남기는 케이스 스터디다. (설정/코드 디테일은 Tech Note로 분리해서 링크로 연결한다.)

Case Study Single Entry RBAC First Observability
시리즈 바로가기: 0화(왜 만들었나) · 1화(현재글) · 2화(Nginx) · 3화(RBAC) · 4화(대시보드) · 5화(배포/운영)
개요(3줄 요약)
• 포털의 목표는 “예쁜 화면”이 아니라 운영 흐름을 단축하는 것이었다.
• React는 “운영 위젯”을 쌓기 좋고, API(Node/Python)는 데이터·권한·감사를 통제하기 좋다.
• Nginx는 단일 진입점(라우팅/헤더/인증 프록시)이고, Auth는 처음부터 RBAC로 설계했다.

목차

  1. 포털의 목표: “단일 시작점”을 만든다
  2. 현실 제약(운영 환경): 이상보다 “지속 가능성”
  3. 사용자/권한 모델: readonly/operator/admin
  4. 개념 아키텍처(그림): 단일 진입점 + 분리된 역할
  5. 설계 원칙 7가지: 운영자가 계속 쓸 수 있게
  6. Tech Note로 연결: 깊은 설정은 분리
  7. 다음 편 예고

1) 포털의 목표: “단일 시작점”을 만든다

시즌0(0화)에서 “왜 포털이 필요했는가”를 얘기했다면, 시즌1은 “그래서 어떤 형태로 만들었는가”를 기록한다. 내가 포털에서 기대했던 효과는 딱 4가지로 압축된다.

① 단일 시작점

“오늘 뭐부터 보지?”가 아니라 여기 들어오면 끝 — 업무 흐름의 첫 화면을 고정한다.

② 결정 속도

수치/로그/리포트를 “해석 가능한 형태”로 요약해서 판단 시간을 줄인다.

③ 자동화의 UI화

스크립트/워크플로우를 버튼/폼으로 바꿔 팀원이 누구나 실행할 수 있게 만든다.

④ 권한/감사

“누가/언제/무엇을” 조회·실행했는지 남겨 운영 안전장치로 만든다.

운영 포털의 성패는 “기능의 개수”가 아니라, 확인→판단→조치 흐름을 얼마나 짧게 만드는가에서 갈린다.

2) 현실 제약(운영 환경): 이상보다 “지속 가능성”

운영 포털은 개발 프로젝트처럼 “깔끔하게 갈아엎는 방식”으로 진행하기 어렵다. 이미 존재하는 장비/시스템/규정 위에서 굴러야 하고, 보안/감사/권한이 먼저다.

운영 환경에서 자주 부딪히는 제약 4가지
  • 서로 다른 데이터 소스: SIEM/WAF/FW/IPS/리포트 파일/모니터링 등
  • 보안 우선: 내부망, 접근통제, 감사로그, “실행” 기능의 권한 분리
  • 유지보수: 서비스가 늘어도 운영 방식은 단순해야 함(표준화 필요)
  • 배포/롤백: 장애가 나면 즉시 원복할 수 있어야 함(운영 루틴 필요)

이 제약 때문에 “최신 프레임워크”보다 “운영 가능한 구조”가 우선이었다.

3) 사용자/권한 모델: readonly/operator/admin

운영자는 다 같은 운영자가 아니다. 조회만 필요한 사람, 실행 가능한 사람, 정책을 바꾸는 사람이 섞이면 사고가 난다. 그래서 권한 모델을 초기에 단순하게 고정했다.

역할의미예시
readonly조회/열람 중심대시보드 보기, 일일 리포트 확인
operator제한된 실행/운영워크플로우 실행, 조회 범위 확장
admin계정/권한/설정 관리그룹/역할 관리, 주요 정책 변경
RBAC는 UI가 아니라 운영 안전장치다. 버튼 숨김은 보안이 아니고, 정책은 프록시/API 레벨에서 강제되어야 한다.

4) 개념 아키텍처(그림): 단일 진입점 + 분리된 역할

구현은 여러 방식이 가능하지만, 내가 선택한 구조는 단순하다. Nginx(단일 진입점) 아래로 React(화면), Node/Python(API), 그리고 인증 구성을 역할별로 분리한다.

사용자(브라우저) HTTPS / 단일 URL NGINX (Edge) 라우팅 · 헤더 · 정책 · 로그 React SPA /portal 정적 Node API /api 집계/권한/감사 Python API /sec 리포트/인텔리전스 외부/내부 연동 SIEM / WAF / FW / IPS WHOIS / VT 등 PDF/CSV 리포트 모니터링/알람 Auth (RBAC) OAuth2-Proxy Keycloak(SSO/그룹) 헤더 계약으로 정책 강제

포인트는 “툴을 대체”하는 게 아니라, 운영자가 매일 보는 흐름을 포털로 묶고 각 시스템은 API로 연결해 하나의 경험으로 만드는 것.

5) 설계 원칙 7가지: 운영자가 계속 쓸 수 있게

  • 첫 화면은 요약: 클릭은 최소화, 중요한 것만 크게
  • 정책은 Edge에서 강제: “어디로 라우팅하고 어떤 헤더를 믿을지”를 먼저 고정
  • 실행은 서버에서: 브라우저가 아니라 API에서 권한/감사/제어
  • 에러는 숨기지 않기: 운영자에겐 “왜 안 되는지”가 시간 절약
  • 느려도 안전하게: 보안/권한/감사는 타협하지 않기
  • 관측 가능성: 로그/헬스체크/지표가 없으면 “운영”이 아니라 “기도”가 됨
  • 확장 가능성: 위젯/페이지/데이터 소스 추가가 쉬운 구조

6) Tech Note로 연결: 깊은 설정은 분리

이 글은 선택의 이유를 남기는 용도다. “설정/옵션/실전 템플릿”은 Tech Note에서 재현 가능하게 제공한다.

Tech Note(추천 읽기 순서)

Auth(Keycloak/OAuth2-Proxy) Tech Note는 IAM-Keyclock 카테고리로 분리해서 이어갈 예정이다.

공식 문서(레퍼런스)

7) 다음 편 예고

다음 글: 포털의 “정문” 역할을 하는 Nginx 리버스 프록시 이야기. 포털은 결국 “어디로 라우팅되고, 어떤 헤더를 믿을지”가 생명이다.
→ [시즌1-2] Nginx 리버스프록시 기본 골격 + 헤더 설계

'인프라 자동화 & 협업 도구 > 인프라 관리 포털·대시보드' 카테고리의 다른 글

5. 배포/운영 (systemd, 로그, 헬스체크)  (0) 2025.12.28
4. 운영 대시보드 (일일 리포트/캘린더/위험도 요약)  (0) 2025.12.28
3. 인증/권한(RBAC) 적용 (Keycloak + OAuth2-Proxy)  (0) 2025.12.28
2. Nginx 리버스프록시 기본 골격 + 헤더 설계  (0) 2025.12.28
0. 인프라 운영자가 왜 React 포털을 만들게 됐나  (0) 2025.12.28

티스토리툴바