StudyDad

운영 콘솔 아키텍처 시리즈 7/9운영 콘솔에는 버튼을 누르면 파일을 만들어 내려받는 기능이 자주 있다. 엑셀, CSV, 집계표, 분석 리포트 같은 것들이다. 처음에는 단순하게 생각하기 쉽다.사용자가 요청한다. 서버가 데이터를 조회한다. 파일을 만든다. 응답으로 내려준다.작은 데이터라면 이 방식도 괜찮다. 하지만 작업이 수 초에서 수십 초 걸리기 시작하면 동기 HTTP 요청 안에서 끝내는 방식은 금방 한계에 부딪힌다.문제 상황리포트 생성은 다음 특성을 가졌다.여러 테이블에서 데이터를 조회한다.파일 생성 시간이 데이터 양에 따라 달라진다.브라우저가 응답을 기다리는 동안 사용자는 아무것도 알 수 없다.API Gateway나 프록시에는 timeout이 있다.실패했을 때 어디까지 진행됐는지 추적해야 한다.동기 A..

운영 콘솔 아키텍처 시리즈 6/9서버리스는 운영 부담을 크게 줄여준다. 트래픽이 없을 때 비용이 거의 없고, 갑작스러운 요청도 자동으로 확장된다. 그래서 운영 콘솔을 만들 때 모든 API를 Lambda로 만들고 싶어질 수 있다.하지만 모든 요청이 Lambda에 잘 맞는 것은 아니다. 반대로 모든 요청을 상주 서버로 처리하는 것도 답은 아니었다.문제 상황운영 리포트 콘솔에는 성격이 다른 API가 섞여 있었다.하나는 대시보드나 목록 조회처럼 짧고 자주 호출되는 API다. 내부 운영자가 화면을 이동할 때마다 호출되고, 응답은 빠를수록 좋다. 내부 인증 쿠키를 확인하고, RDB 커넥션 풀을 사용해 여러 집계 쿼리를 실행한다.다른 하나는 리포트 생성처럼 드물지만 오래 걸리는 API다. 사용자가 버튼을 누르면 수 ..

운영 콘솔 아키텍처 시리즈 5/9Lambda를 HTTP로 호출하려면 가장 단순한 방법은 Lambda Function URL이다. 별도 게이트웨이 없이 함수에 HTTPS URL을 붙일 수 있다. 작은 API라면 이 방식이 충분할 때도 많다.그런데 운영 콘솔의 API 앞에는 API Gateway를 뒀다. 단순히 "원래 그렇게 하니까"가 아니라, 브라우저 기반 콘솔에서 필요한 운영 기능을 한곳에서 처리하기 위해서였다.문제 상황운영 콘솔 API는 브라우저에서 호출된다. 정적 SPA는 console.example.com에서 서빙되고, API는 api.example.com 또는 클라우드 API 도메인에서 제공된다. 이 순간 CORS가 발생한다.또한 API는 하나의 엔드포인트가 아니었다. 동기화, 조회, 리포트 생성..

운영 콘솔 아키텍처 시리즈 4/9운영 도구를 만들 때 가장 먼저 데이터베이스를 떠올리는 경우가 많다. 목록이 있고, 상태가 있고, 조회 화면이 있으면 자연스럽게 RDB 테이블을 설계하게 된다.하지만 모든 운영 콘솔에 데이터베이스가 필요한 것은 아니다. 어떤 경우에는 데이터베이스를 추가하지 않는 것이 더 단순하고 안전한 결정이 될 수 있다.문제 상황신청 관리 콘솔의 데이터 원천은 이미 외부에 있었다. 외부 파트너는 폼 도구로 신청했고, 운영자는 스프레드시트에서 데이터를 검수하고 상태를 관리했다. 스프레드시트가 사실상 Source of Truth였다.콘솔은 이 데이터를 더 보기 좋게 보여주고, 공개 가능한 일부 데이터를 외부에 노출하면 됐다. 데이터 규모는 크지 않았고, 변경도 특정 시점에 몰렸다. 초당 수..

운영 콘솔 아키텍처 시리즈 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와 쿠키 인증은 왜 자꾸 문제를 일으킬까?이런 결정들은 어떻게 문서로 남겨야 할까?이 시리즈는 그런 질문에 답하기 위해 작성했다.이 시리즈에서 다루는 것이 시리즈는 특정 기술 조합을 자랑하기 위한 구축기가 아니다. 운영 콘솔을 만..

기술 실무 설계 시리즈 8/8좋은 설계는 영구적인 정답이 아니다.당시의 조건에서 합리적이었던 선택도 시간이 지나면 다시 볼 수 있다.사용자가 늘고, 작업량이 늘고, 보안 요구사항이 바뀌고, 운영 인력이 달라지면 설계도 달라져야 한다.그래서 설계 회고에는 "다시 설계한다면 무엇을 볼 것인가"가 필요하다.지금 구조가 틀렸다는 뜻은 아니다다시 설계한다는 말은 현재 구조가 틀렸다는 뜻이 아니다.현재 구조는 당시 조건에서 합리적일 수 있다.예를 들어 작은 운영 콘솔에서는 다음 선택이 충분히 현실적이다.React SPA를 S3와 CloudFront에 배포이벤트성 작업은 Lambda잦은 조회는 상주 API 서버결과 파일은 object storage초기 자동화는 Apps Script와 Sheets 활용job table..

기술 실무 설계 시리즈 7/8클라우드 비용은 숫자로 보인다.월 몇 달러, 인스턴스 비용, Lambda 호출 비용, S3 저장 비용처럼 계산할 수 있다.하지만 운영 복잡도는 잘 보이지 않는다.배포할 때마다 사람이 확인해야 하는 절차, 장애 때마다 찾아야 하는 로그, 헷갈리는 도메인, 수동으로 맞춰야 하는 설정도 모두 비용이다.작은 운영 도구에서는 이 보이지 않는 비용을 더 중요하게 봐야 할 때가 있다.비용은 돈만이 아니다기술 선택을 할 때 클라우드 비용만 비교하면 판단이 좁아진다.예를 들어 어떤 구조가 월 비용은 조금 싸지만 다음을 요구한다면 실제로는 비쌀 수 있다.매번 수동 배포복잡한 서버 패치장애 때마다 콘솔 검색문서 없는 환경 변수사람이 직접 정리해야 하는 파일원인을 찾기 어려운 로그사람의 시간도 비..

기술 실무 설계 시리즈 6/8비슷한 운영 콘솔을 여러 개 만들면 공통화 욕구가 생긴다.같은 React를 쓰고, 비슷한 레이아웃을 쓰고, API 호출 방식도 비슷하다면 공통 패키지를 만들고 싶어진다.하지만 처음부터 완벽한 공통화를 하는 것이 항상 좋은 선택은 아니다.특히 도메인이 다른 운영 도구에서는 중복 제거보다 책임 경계가 더 중요할 때가 있다.공통화가 매력적인 이유공통화에는 분명한 장점이 있다.중복 코드가 줄어든다.UI 일관성이 생긴다.API 에러 처리 방식이 통일된다.배포 스크립트를 재사용할 수 있다.새 콘솔을 만들 때 속도가 빨라질 수 있다.그래서 비슷한 화면이 두세 개 생기면 바로 공통 라이브러리를 만들고 싶어진다.하지만 공통화는 공짜가 아니다.너무 이른 공통화의 문제아직 요구사항이 안정되지 않..