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

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

전체 글 202

API Gateway OPTIONS MOCK으로 CORS 비용 줄이기

AWS 실전 운영 시리즈 5/12브라우저에서 API를 호출할 때 CORS 오류를 만나면 당황스럽다.서버는 멀쩡한 것 같은데 브라우저가 요청을 막는다. Postman에서는 되는데 화면에서는 안 된다.운영 콘솔처럼 React SPA와 API 도메인이 분리된 구조에서는 CORS가 설계 요소다.특히 JSON 요청이 많다면 preflight OPTIONS 요청을 어떻게 처리할지 정해야 한다.CORS preflight란 무엇인가브라우저는 다른 origin으로 특정 요청을 보내기 전에 OPTIONS 요청을 먼저 보낼 수 있다.이 요청을 preflight라고 한다.예를 들어 다음 조건에서는 preflight가 발생한다.Content-Type: application/jsonAuthorization 헤더 사용PUT, DE..

번아웃은 갑자기 오지 않았다

며칠 전, 거실에서 내 목소리가 갑자기 커진 적이 있다.아이에게 화를 낸 것은 아니었다. 아내에게 화를 낸 것도 아니었다. 다른 일 때문에 마음이 잔뜩 올라와 있었고, 통화를 하거나 메시지를 확인하는 과정에서 나도 모르게 언성이 높아졌다. 말끝에는 평소 아이 앞에서 잘 하지 않으려던 거친 말까지 섞였다.거실에는 아이도 있었고 아내도 있었다.순간 분위기가 어색하게 가라앉았다. 아이는 자기 하던 일을 계속하는 척했고, 아내도 별말을 하지 않았다. 그런데 나는 알 수 있었다. 방금 내 목소리가 이 공간을 한 번 흔들고 지나갔다는 것을.그날 밤, 마음이 오래 불편했다.아이에게 직접 화를 낸 것은 아니니 그냥 넘어갈 수도 있었다. 하지만 그건 조금 비겁한 정리처럼 느껴졌다. 가족이 함께 있는 공간에서 갑자기 높아..

API Gateway REST API와 HTTP API 선택 기준

AWS 실전 운영 시리즈 4/12AWS API Gateway에는 크게 REST API와 HTTP API가 있다.HTTP API는 더 가볍고 저렴하고 빠르다. 그래서 새로 만들 때는 HTTP API가 먼저 떠오를 수 있다.하지만 항상 HTTP API가 정답은 아니다.운영 콘솔처럼 브라우저 기반 SPA, 여러 endpoint, CORS preflight, API Key, 요청 검증, MOCK 응답 같은 요소가 중요하다면 REST API가 더 나을 수 있다.문제 상황운영 콘솔의 프론트엔드는 별도 도메인에서 동작했다.API는 Lambda를 통해 제공되었고, 여러 path와 method가 있었다.필요한 것은 단순히 Lambda를 HTTP로 호출하는 것만이 아니었다.path별 라우팅CORS preflight 처리O..

Lambda 배포 파일을 가볍게 만든 이유

AWS 실전 운영 시리즈 3/12Lambda는 배포가 단순하다.코드를 zip으로 묶고 update-function-code를 실행하면 된다.하지만 Python Lambda에서 엑셀 생성 라이브러리나 데이터베이스 드라이버를 함께 넣기 시작하면 배포 파일이 금방 무거워진다.작은 코드 하나를 고쳤을 뿐인데 매번 큰 zip 파일을 만들고 올려야 한다면 배포가 느려지고 실수 가능성도 커진다.그래서 Lambda Layer를 사용해 함수 코드와 의존성을 분리했다.문제 상황운영 콘솔에는 리포트 파일을 생성하는 Lambda가 있었다.이 함수는 단순 API 응답만 하는 것이 아니라 다음 작업을 했다.데이터베이스 조회엑셀 파일 생성object storage 업로드작업 상태 갱신Python 코드 자체는 크지 않았다.하지만 엑..

CloudFront 캐시는 성능 기능이 아니라 운영 기능이다

AWS 실전 운영 시리즈 2/12CloudFront를 처음 쓸 때는 캐시를 성능 기능으로만 생각하기 쉽다.사용자 가까운 엣지에서 파일을 제공하니 더 빠르다. 트래픽이 줄고, origin 부하도 줄어든다.맞는 말이다.하지만 운영 콘솔에서 CloudFront 캐시는 성능 기능이면서 동시에 운영 기능이다.캐시 정책에 따라 배포 반영 속도, 데이터 최신성, 장애 대응 방식이 달라지기 때문이다.문제 상황React SPA를 S3에 올리고 CloudFront로 서빙했다.정적 파일은 잘 캐시되었고, 화면 로딩도 빨랐다.그런데 운영 중에는 이런 질문들이 생겼다.배포했는데 왜 이전 화면이 보일까?JSON 데이터가 바뀌었는데 왜 화면에 반영되지 않을까?어떤 파일은 오래 캐시해도 되고 어떤 파일은 짧게 해야 할까?매번 inv..

React SPA를 S3와 CloudFront에 올릴 때 먼저 정해야 할 것들

AWS 실전 운영 시리즈 1/12React로 만든 관리자 페이지를 배포할 때 꼭 애플리케이션 서버가 필요한 것은 아니다.빌드가 끝난 React SPA는 결국 HTML, JavaScript, CSS, 이미지 같은 정적 파일이다. 이 파일들은 Node 서버나 Nginx가 없어도 S3와 CloudFront만으로 충분히 서빙할 수 있다.하지만 "S3에 올리면 끝"이라고 생각하면 운영 중에 여러 문제를 만난다.HTTPS, 커스텀 도메인, SPA 라우팅, 캐시 정책, 배포 후 무효화, 데이터 파일 보호 같은 것들을 미리 정해야 한다.문제 상황운영 콘솔은 React SPA로 만들었다.사용자는 많지 않았지만, 내부 업무에 매일 쓰이는 화면이었다. SEO는 중요하지 않았고, 서버 사이드 렌더링도 필요하지 않았다.이런 조..

아침마다 무너지는 건 아이의 준비물만이 아니었다

Volume 01. 나와 아이의 내면아침은 우리 집에서 가장 자주 폭발하는 시간이다.출근 준비로 모두가 바쁘다. 정해진 시간 안에 씻고, 밥을 먹고, 교복을 입고, 가방을 챙기고, 집을 나서야 한다. 어른에게도 빠듯한 시간인데, 아이는 그 긴박함과는 다른 세계에 사는 사람처럼 보일 때가 있다.“일어나야지.”“이제 씻으러 가.”“가방 챙겼어?”“체육복 넣었어?”“물통은?”“밥 한 숟갈 먹고 옷 입어.”“양치할 때 물고만 있지 말고 닦아.”이 말들이 거의 매일 반복된다.아이의 움직임은 느긋하다. 아침밥을 앞에 두고도 숟가락을 들 생각이 없어 보인다. TV 화면에 눈이 가 있고, 게임 생각이 남아 있고, 해야 할 일들은 어른들의 입에서 하나씩 호명될 때까지 자기 차례를 기다리는 것처럼 보인다.그 옆에서 아내는..

자동화가 실패했을 때 사람이 복구할 수 있게 만들기

자동화 워크플로우 시리즈 8/8자동화의 목표는 사람이 하지 않아도 되는 일을 줄이는 것이다.하지만 좋은 자동화는 사람을 완전히 배제하지 않는다.오히려 실패했을 때 사람이 어디를 보고, 무엇을 다시 실행하고, 어떤 상태로 되돌릴 수 있는지 준비해둔다.자동화는 언젠가 실패한다. 네트워크가 끊길 수 있고, API가 실패할 수 있고, 스크립트 제한에 걸릴 수 있고, 원천 데이터가 잘못될 수도 있다.그래서 자동화 시스템에는 수동 복구 경로가 필요하다.문제 상황스프레드시트 기반 자동화 흐름은 여러 계층을 지난다.폼 제출-> 스프레드시트 기록-> Apps Script 실행-> API 호출-> Lambda 처리-> S3 JSON 저장-> 화면 반영이 중 하나만 실패해도 화면 데이터가 갱신되지 않거나, 공개 데이터가 오..

공개 데이터와 내부 데이터를 분리하는 법

자동화 워크플로우 시리즈 7/8운영 자동화에서 자주 놓치는 지점이 있다.내부에서 보는 데이터와 외부에 보여줄 데이터는 같지 않다.같은 원천에서 만들어졌더라도 공개 화면에 나가는 데이터는 반드시 별도로 가공해야 한다.화면에서 숨기는 것만으로는 충분하지 않다. API 응답이나 JSON 파일에 포함된 정보는 사용자가 개발자 도구로 볼 수 있다.문제 상황운영자는 신청 데이터를 자세히 봐야 한다.신청자 정보, 내부 상태, 검토 메모, 처리 결과, 예외 여부 같은 정보가 필요하다.하지만 외부 사용자에게 공개해야 하는 정보는 훨씬 제한적이다.예를 들어 공개 페이지에는 일정, 신청 가능 여부, 집계 결과, 가격 범위, 상태 정도만 보여주면 될 수 있다.이때 내부 데이터를 그대로 내려주고 화면에서 일부 필드를 숨기면 위..

최신 데이터, 월별 스냅샷, 감사 백업을 나눠 저장하기

자동화 워크플로우 시리즈 6/8운영 자동화에서 데이터를 파일로 저장할 때 흔히 하나의 JSON만 만들고 싶어진다.data.json처음에는 충분해 보인다. 화면은 최신 데이터만 읽으면 되고, 동기화할 때 파일을 덮어쓰면 된다.하지만 운영하다 보면 최신 데이터 하나만으로는 부족하다.언제 어떤 데이터가 동기화되었는지, 월별로 어떤 상태였는지, 문제가 생겼을 때 어디로 되돌아가야 하는지 알 수 있어야 한다.그래서 최신 데이터, 월별 스냅샷, 감사 백업을 나눠 저장하는 구조가 필요하다.문제 상황스프레드시트를 원천 데이터로 두고, 화면 제공을 위해 JSON 파일을 생성해야 했다.필요한 데이터는 하나가 아니었다.운영자 화면이 읽는 최신 데이터월별 화면이나 기록을 위한 스냅샷외부 사용자에게 보여줄 공개용 데이터동기화 ..