TechNote · NGINX · 00 왜 인프라 운영자는 NGINX를 ‘정책 엔진’으로 봐야 할까 NGINX를 단순 웹서버가 아니라, 인증·정책·관측을 담당하는 ‘경계(Edge) 운영 레이어’로 정리해 보겠습니다. 대상: 운영자 포커스: 개념/관점 키워드: 정책 엔진이 글의 목적NGINX를 “리버스 프록시” 한 단어로 끝내지 않고, 운영·보안·장애 대응의 중심(Policy Enforcement Point)으로 보는 관점을 정리해 보겠습니다.1) NGINX는 웹서버가 아니라 ‘경계(Edge)의 운영 레이어’다인프라 운영을 하다 보면, 결국 모든 요구는 한 곳으로 모입니다. “접속이 느리다”, “권한이 이상하다”, “로그가 없다”, “장애 시 우회가 필요하다”, “보안팀이 헤더를 통일해달라 한다”…이..

A. “인프라 포털 만들기” 시즌 1 — 4화 운영 대시보드 (일일 리포트/캘린더/위험도 요약) 대시보드는 “데이터를 많이 보여주는 화면”이 아니라 결정을 빠르게 만드는 화면이어야 한다. 그래서 첫 화면은 오늘 확인할 것을 고정했다: 리포트, 캘린더, 위험도 요약. Case Study Decision First Calendar = Time Axis Risk = Priority 시리즈 바로가기: 0화 · 1화 · 2화 · 3화 · 4화(현재글) · 5화 개요(3줄 요약) • 첫 화면은 “대시보드”가 아니라 오늘의 운영 체크..

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줄 요약) • 포털의 목표..