StudyDad Loop 제품을 만들며 배운 운영과 설계를 기록합니다.

FamBlend를 중심으로 실제 구현, 운영 메모, GitHub 포트폴리오를 연결해 쌓아가는 StudyDad의 작업 기록입니다.

관리자페이지 4

관리자 페이지 배포에 서버가 꼭 필요할까?

운영 콘솔 아키텍처 시리즈 3/9React로 만든 관리자 페이지를 배포한다고 하면 자연스럽게 웹 서버를 떠올리기 쉽다. EC2 인스턴스를 만들고, Nginx를 설치하고, 빌드된 파일을 복사하고, HTTPS 인증서를 붙이는 식이다.하지만 React SPA의 빌드 결과물은 대부분 정적 파일이다. 서버가 매 요청마다 HTML을 렌더링하지 않는다면, 24시간 떠 있는 웹 서버가 꼭 필요하지 않을 수 있다.문제 상황운영 콘솔은 React SPA였다. SEO가 중요하지 않았고, 서버 사이드 렌더링도 필요하지 않았다. 브라우저가 index.html과 JavaScript 번들을 받은 뒤, 이후 화면 전환은 클라이언트 라우터가 처리했다.필요한 것은 다음 정도였다.커스텀 도메인HTTPS정적 파일 캐싱SPA 라우팅 fall..

같은 관리자 페이지처럼 보여도, 도메인이 다르면 콘솔을 나눠야 한다

운영 콘솔 아키텍처 시리즈 2/9운영 도구를 만들다 보면 처음에는 "관리자 페이지 하나에 메뉴만 추가하면 되지 않을까?"라는 생각을 하기 쉽다. 실제로 화면만 보면 비슷해 보인다. 로그인하고, 목록을 보고, 상태를 바꾸고, 파일을 내려받는다.하지만 관리자 페이지가 비슷한 모양을 하고 있다고 해서 같은 애플리케이션이어야 하는 것은 아니다. 내가 운영 콘솔을 설계하면서 가장 먼저 내린 결정은 콘솔을 하나로 합치지 않는 것이었다.문제 상황만들어야 했던 도구는 크게 두 종류였다.첫 번째는 외부 파트너가 신청한 데이터를 내부 운영자가 확인하고, 일정이나 결과를 공개하는 신청 관리 콘솔이었다. 데이터 원천은 외부 폼과 스프레드시트였고, 변경은 특정 기간에 몰렸다. 외부 사용자가 보는 공개 페이지도 필요했다.두 번째..

작은 운영 콘솔을 안정적으로 굴리기 위한 아키텍처 결정들

운영 콘솔 아키텍처 시리즈 1/9관리자 페이지는 겉으로 보기에는 단순해 보인다. 목록을 보여주고, 상태를 바꾸고, 파일을 내려받고, 내부 사용자가 필요한 데이터를 확인한다.하지만 실제로 운영되는 콘솔을 만들다 보면 생각보다 많은 질문을 만나게 된다.React로 만든 관리자 페이지는 어디에 배포하는 것이 좋을까?모든 데이터를 RDB에 넣어야 할까?Lambda만으로 백엔드를 구성해도 괜찮을까?API Gateway는 꼭 필요한가?오래 걸리는 리포트 생성은 어떻게 처리해야 할까?CORS와 쿠키 인증은 왜 자꾸 문제를 일으킬까?이런 결정들은 어떻게 문서로 남겨야 할까?이 시리즈는 그런 질문에 답하기 위해 작성했다.이 시리즈에서 다루는 것이 시리즈는 특정 기술 조합을 자랑하기 위한 구축기가 아니다. 운영 콘솔을 만..

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

기술 실무 설계 시리즈 1/8관리자 페이지는 종종 작게 시작한다.목록 하나, 상세 화면 하나, 상태 변경 버튼 하나. 처음에는 단순 CRUD처럼 보인다.그래서 "이 정도는 그냥 만들면 되지 않을까?"라고 생각하기 쉽다.하지만 실제 운영에 쓰이는 관리자 페이지는 생각보다 빨리 복잡해진다. 인증, 권한, 배포, 캐시, API, 파일 다운로드, 장애 대응, 데이터 원천 같은 문제가 화면 뒤에 붙기 시작한다.작은 관리자 페이지에도 아키텍처가 필요한 이유는 규모 때문이 아니다.업무가 그 도구에 의존하기 때문이다.사용자 수보다 업무 중요도가 중요하다운영 도구는 사용자가 많지 않을 수 있다.하루에 몇 명만 쓰는 화면일 수도 있다.하지만 그 몇 명이 매일 중요한 업무를 처리한다면 시스템의 중요도는 낮지 않다.예를 들어..