0. 인프라 운영자가 왜 React 포털을 만들게 됐나

 

개요

• 운영자는 “툴”이 많아질수록 오히려 일이 느려지고, 같은 확인을 반복하게 된다.
• 그래서 운영 흐름(업무의 순서) 자체를 웹 포털로 묶어 “하루에 꼭 보는 것”을 한 화면에 모았다.
• React(프론트) + Node/Python(API) + Nginx(프록시) + 인증(RBAC) 조합은 운영환경에서 가장 현실적인 답이었다.

이 글은 “기술 설명서”가 아니라, 왜 만들었는지에 대한 운영자 관점의 기록이다.
구현/설정은 별도의 “기술 노트(Tech Note)” 글로 분리해서 링크로 연결할 예정이다.

목차

1. 왜 포털이 필요했나
2. 운영 현장의 “진짜” 불편함
3. 포털이 해결해야 했던 목표
4. 왜 React + API + Nginx 였나
5. 전체 구조(개념 아키텍처)
6. 글 운영 규칙(사례 글 vs 기술 노트)
7. 다음 글 예고

---

1) 왜 포털이 필요했나

인프라 운영을 하다 보면 툴이 계속 늘어난다. 모니터링, 로그, 보안, 장비 관리, 배포, 문서… 문제는 툴이 많아질수록 “정보는 늘지만”, 운영자가 결정을 내리는 속도는 느려진다는 점이다.

어느 순간부터 나는 “툴을 잘 쓰는 사람”이 아니라, “탭을 잘 넘기는 사람”이 되어 있었다. 그래서 생각을 바꿨다.

툴을 더 추가하는 게 아니라, 운영 흐름을 하나의 화면으로 묶자.

2) 운영 현장의 “진짜” 불편함

• 반복: 매일 같은 시간에 같은 지표를 확인한다.
• 분산: 지표/로그/리포트가 서로 다른 시스템에 흩어져 있다.
• 컨텍스트 스위칭: 로그인/권한/URL/메뉴가 달라 “확인만 하다” 시간이 끝난다.
• 공유의 어려움: 팀원에게 “어디 들어가서 뭘 봐”를 설명하는 비용이 크다.
• 자동화의 파편화: 스크립트는 있는데, 사람이 접근하기 쉽지 않다(경로/옵션/실행법).

특히 보안/네트워크 운영은 “지금 당장 판단”이 중요한데, 판단을 위한 근거가 흩어져 있으면 결국 확인 비용이 사고를 만든다.

3) 포털이 해결해야 했던 목표

목표	설명
하나의 시작점	“오늘 뭐부터 보지?”가 아니라 “여기 들어오면 끝”
읽기 쉬운 요약	숫자/그래프/리스크를 ‘한 화면’에서 판단 가능
자동화의 UI화	스크립트를 버튼/폼으로 제공해서 팀원 누구나 실행
권한 기반	운영자/관리자/조회자 권한 분리(RBAC)
운영 가능한 구조	로그/배포/롤백/모니터링까지 현실적으로 유지

4) 왜 React + API + Nginx 였나

운영 포털은 “예쁜 웹사이트”가 아니라 업무 도구다. 그래서 선택 기준도 실무적으로 잡았다.

React를 선택한 이유

• 대시보드/테이블/필터/검색/상태표시 같은 UI를 만들기 편하다.
• 컴포넌트로 “운영 위젯”을 재사용할 수 있다(예: 오늘의 위험도, 일일 리포트, 장애 체크리스트).
• 팀원이 늘어도 유지보수 구조가 비교적 안정적이다.

API(Node/Python)를 분리한 이유

• 대부분의 운영 데이터는 결국 API 호출/로그 조회/리포트 생성으로 귀결된다.
• 보안/네트워크 자동화는 “실행권한/감사로그”가 중요해서 서버단에서 통제하는 편이 낫다.
• Python은 SIEM/리포트/데이터 파싱에 강하고, Node는 프론트와의 연동에 편하다.

Nginx를 프론트에 둔 이유

• 리버스 프록시로 단일 진입점을 만들 수 있다.
• 헤더 전달/경로 라우팅/캐시/압축 등 운영적인 설정을 중앙에서 한다.
• 인증 프록시(OAuth2-Proxy 등)와 결합해 RBAC를 깔끔하게 붙일 수 있다.

5) 전체 구조(개념 아키텍처)

아래는 실제 구성의 “개념도”다. (상세 설정은 기술 노트로 분리 예정)

사용자(브라우저)
  ↓ HTTPS
Nginx (reverse proxy + route + headers)
  ├─ /portal  → React SPA
  ├─ /api     → Node API (인증/권한 체크, 집계)
  └─ /sec     → Python API (로그/리포트/인텔리전스)
        ├─ SIEM / WAF / FW / IPS 연동
        ├─ IP 인텔리전스(WHOIS/VT 등)
        └─ 리포트 생성(PDF/CSV)

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

6) 글 운영 규칙(사례 글 vs 기술 노트)

이 블로그는 앞으로 아래 원칙으로 글을 쌓을 예정이다.

사례 글 (Case Study)

• 운영에서 어떤 문제가 있었고(배경), 어떻게 판단했고, 어떤 구조로 해결했는지(전략)를 중심으로 쓴다.
• 코드는 핵심만 넣고, 상세 구현은 기술 노트로 링크한다.
• 독자가 “비슷한 상황에서 같은 선택을 할 수 있게” 만드는 게 목적이다.

기술 노트 (Tech Note)

• 진짜 구현/설정/코드만 깊게 쓴다(재현 가능한 형태).
• 하나의 글은 하나의 주제만: 예) Nginx 헤더 설계 / RBAC 설계 / 타입 모델링 / systemd 운영
• 사례 글에서 링크로 연결한다.

앞으로 이 글 하단에는 이런 식으로 “기술 노트” 링크가 붙는다:

• Tech Note: (예정) Nginx Reverse Proxy 기본 골격
• Tech Note: (예정) Keycloak 기반 RBAC(조회/운영/관리) 설계
• Tech Note: (예정) React 대시보드 컴포넌트 설계 패턴