StudyDad

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

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

기술 실무 설계 시리즈 2/8내부 운영 도구를 만들 때 가장 어려운 질문 중 하나는 이것이다.어디까지 설계해야 충분한가?너무 단순하게 만들면 나중에 운영 문제가 생긴다.반대로 처음부터 대규모 서비스처럼 만들면 개발 속도와 유지보수 비용이 과해진다.내부 도구에는 내부 도구에 맞는 "충분히 좋은 설계" 기준이 필요하다.완벽한 설계는 목표가 아니다운영 도구는 대개 제한된 시간 안에 만들어진다.대규모 사용자 트래픽보다 특정 업무를 안정적으로 처리하는 것이 목표다.그래서 완벽한 설계보다 중요한 것은 다음이다.업무를 막지 않는가문제가 생겼을 때 복구 가능한가담당자가 바뀌어도 이해할 수 있는가변경이 필요한 곳이 좁은가지금 규모에서 운영 부담이 과하지 않은가완벽함보다 복구 가능성이 더 중요할 때가 많다.기준 1. 사용..

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

자동화 워크플로우 시리즈 1/8운영 자동화를 시작할 때 가장 먼저 떠올리는 것은 도구다.폼을 만들까, 스프레드시트를 쓸까, 관리자 페이지를 만들까, 자동화 스크립트를 붙일까, 아니면 처음부터 데이터베이스와 백엔드를 갖춘 시스템을 만들까.하지만 자동화는 도구에서 시작하면 자주 실패한다.먼저 봐야 할 것은 업무 흐름이다.누가 입력하고, 누가 확인하고, 어떤 기준으로 상태가 바뀌고, 결과가 누구에게 공개되는지부터 정리해야 한다. 그다음에야 어떤 도구가 충분한지 판단할 수 있다.문제 상황신청을 받고, 내부에서 확인하고, 일정이나 결과를 공개하는 업무가 있었다.처음부터 완전한 백오피스 시스템을 만들 수도 있었다. 로그인, 신청 화면, 관리자 화면, 상태 관리, 데이터베이스, 알림, 공개 페이지를 모두 직접 구현하..

문서화와 인수인계 시리즈 9/9기술 블로그를 쓰려고 하면 종종 막막해진다.무엇을 써야 할지, 어디까지 공개해도 되는지, 이미 다른 사람이 더 잘 설명한 기술을 다시 써도 되는지 고민하게 된다.그럴 때 가장 좋은 재료 중 하나가 내가 실제로 남긴 실무 문서다.HANDOVER, 아키텍처 문서, ADR, 용어집, 트러블슈팅 가이드, 배포 가이드에는 내가 어떤 문제를 겪었고 어떻게 판단했는지가 들어 있다.이 문서들이 쌓이면 단순 기록을 넘어 개인의 일하는 방식을 보여주는 자산이 된다.기술 블로그는 지식 자랑이 아니다기술 블로그를 단순히 "내가 아는 것을 설명하는 공간"으로 보면 부담이 커진다.이미 공식 문서가 있고, 더 깊은 전문가의 글도 많다.하지만 실무 글의 가치는 다른 곳에 있다.내가 어떤 조건에서 어떤 ..

문서화와 인수인계 시리즈 8/9실무에서 만든 문서는 좋은 블로그 재료가 된다.아키텍처 문서, HANDOVER, 트러블슈팅 가이드, 배포 가이드, 용어집에는 실제 경험이 들어 있다. 검색해서 만든 글보다 훨씬 구체적이고, 판단의 흔적이 남아 있다.하지만 내부 문서를 그대로 공개하면 안 된다.실제 회사명, 도메인, 리소스 이름, API 경로, 인증 방식, 장애 날짜, 운영 데이터가 노출될 수 있다. 그래서 공개 글로 바꾸기 전에 익명화 과정이 필요하다.공개할 수 있는 것과 없는 것먼저 구분해야 한다.공개해도 좋은 것은 보편적인 판단 기준이다.왜 콘솔을 분리했는가왜 S3와 CloudFront를 썼는가왜 Lambda와 상주 서버를 나눴는가왜 job table로 비동기 작업을 관리했는가왜 CORS를 Gateway..

문서화와 인수인계 시리즈 7/9배포 가이드를 쓰다 보면 명령어만 나열하기 쉽다.npm run buildaws s3 sync build/ ...aws cloudfront create-invalidation ...물론 명령어는 필요하다. 하지만 배포 가이드가 명령어 모음으로 끝나면 위험하다.좋은 배포 가이드는 "무엇을 실행할지"뿐 아니라 "언제 실행하고, 무엇을 조심하고, 어떻게 확인하고, 실패하면 어떻게 되돌릴지"를 설명해야 한다.문제 상황운영 콘솔 배포에는 여러 종류가 있었다.React SPA 빌드 후 S3 업로드CloudFront 캐시 무효화Lambda 함수 코드 업데이트Lambda Layer 유지EC2의 Node API 서버 배포Google Apps Script 배포API Gateway stage 배..

문서화와 인수인계 시리즈 6/9장애가 나면 사람은 급해진다. 어디를 봐야 할지 기억나지 않고, 이전에 해결했던 문제도 다시 검색하게 된다. 로그 위치를 찾다가 시간을 쓰고, 같은 명령어를 다시 조합한다.그래서 트러블슈팅 문서는 장애가 난 뒤 쓰면 늦다.물론 실제 장애를 겪은 뒤 보강되는 부분은 있다. 하지만 최소한 자주 발생할 수 있는 증상과 확인 순서는 미리 정리해두는 것이 좋다.문제 상황운영 콘솔에서 반복적으로 나올 수 있는 문제는 대체로 정해져 있다.화면이 로딩되지 않는다.API 호출이 CORS 오류로 실패한다.데이터가 갱신되지 않는다.다운로드 작업이 끝나지 않는다.Lambda가 timeout 된다.DB 연결이 실패한다.배포했는데 이전 화면이 계속 보인다.이런 문제는 원인이 하나가 아니다. 화면이 ..

문서화와 인수인계 시리즈 5/9프로젝트 문서에 용어집이 필요한가?처음에는 과해 보일 수 있다. CORS, Lambda, CloudFront, API Gateway 같은 용어는 검색하면 정의가 나온다. 공식 문서도 있고, 블로그 글도 많다.하지만 프로젝트 안에서의 용어집은 일반 사전과 역할이 다르다.일반 사전은 "무엇인가"를 설명한다.프로젝트 용어집은 "이 프로젝트에서 왜 중요한가"를 설명한다.문제 상황운영 콘솔 문서를 정리하면서 여러 기술 용어가 반복해서 등장했다.CORSpreflightAPI GatewayLambda Function URLLambda LayerCloudFrontCache TTLinvalidationSSO cookiewithCredentialsSource of Truthjob tablec..