StudyDad

기술 실무 설계 시리즈 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 에러 처리 방식이 통일된다.배포 스크립트를 재사용할 수 있다.새 콘솔을 만들 때 속도가 빨라질 수 있다.그래서 비슷한 화면이 두세 개 생기면 바로 공통 라이브러리를 만들고 싶어진다.하지만 공통화는 공짜가 아니다.너무 이른 공통화의 문제아직 요구사항이 안정되지 않..

기술 실무 설계 시리즈 5/8API Gateway는 종종 Lambda 앞에 붙이는 프록시처럼 여겨진다.요청을 받아 Lambda로 넘겨주는 역할 말이다.하지만 브라우저 기반 운영 콘솔에서는 API Gateway를 단순 프록시로 보면 부족하다.CORS, 라우팅, 스로틀링, 로그, 인증 확장성, 백엔드 교체 가능성까지 포함한 운영 경계로 보는 편이 더 맞다.API 앞단에는 정책이 필요하다프론트엔드가 API를 호출할 때 단순히 백엔드 함수만 있으면 되는 것이 아니다.운영 중에는 다음 정책이 필요하다.어떤 path를 허용할 것인가어떤 method를 허용할 것인가어떤 origin에서 호출할 수 있는가preflight는 어디서 처리할 것인가요청이 너무 많으면 어떻게 제한할 것인가어떤 로그를 남길 것인가나중에 백엔드를..

Volume 01. 나와 아이의 내면이 글들을 쓰기 시작한 건, 아이에게 뭔가 대단한 말을 남기고 싶어서가 아니었다.처음에는 그저 매일 반복되는 집 안의 장면들이 마음에 걸렸다. 숙제 앞에서 지친 아이, 옆에서 함께 날카로워지는 아내, 그 사이에서 무슨 말을 해야 할지 몰라 서성이는 나. 부모로서 더 좋은 답을 알고 있는 사람처럼 굴고 싶었지만, 사실 나도 자주 몰랐다.그래서 하나씩 적어보기 시작했다.AI 앞에서 정답을 빨리 얻는 것보다 먼저 자기 생각을 세우는 일이 왜 중요한지. 카톡 화면에 남은 몇 줄의 말만으로 아이의 관계 전체를 단정할 수 없다는 것. 아침마다 반복되는 준비물과 시간의 문제 뒤에는 아이의 느슨함뿐 아니라 부모의 불안도 함께 있다는 것. 내가 지쳤을 때 그 피로가 가족에게 어떻게 새..

기술 실무 설계 시리즈 4/8관리자 페이지를 만들다 보면 모든 기능을 하나로 합치고 싶어진다.공통 레이아웃을 쓰고, 로그인도 한 번만 만들고, 메뉴만 추가하면 될 것처럼 보인다.하지만 화면이 비슷하다고 같은 애플리케이션이어야 하는 것은 아니다.사용자, 데이터 원천, 권한, 배포 주기, 장애 영향 범위가 다르면 콘솔을 나누는 편이 더 안정적일 수 있다.하나로 합치면 생기는 장점하나의 관리자 페이지로 합치면 장점이 있다.공통 레이아웃을 재사용할 수 있다.인증 처리가 한 곳에 모인다.배포 단위가 하나다.메뉴 이동이 쉽다.초기 개발이 빠를 수 있다.작은 규모에서는 이 장점이 크게 보인다.그래서 처음에는 통합 관리자가 자연스러워 보인다.하지만 책임이 섞인다문제는 시간이 지나면서 나타난다.서로 다른 업무가 같은 애..

기술 실무 설계 시리즈 3/8운영 도구를 만들 때 백엔드를 어떻게 구성할지 고민하게 된다.모든 것을 Lambda로 만들까?EC2나 ECS 같은 상주 서버를 둘까?React SPA는 서버에서 서빙해야 할까?이 질문에는 하나의 정답이 없다.요청의 성격에 따라 실행 모델을 나누는 것이 더 현실적이다.먼저 워크로드를 나눈다기술을 고르기 전에 작업을 분류해야 한다.운영 콘솔에는 보통 다음 종류의 작업이 섞여 있다.정적 화면 제공짧고 잦은 조회 API인증과 쿠키 처리오래 걸리는 파일 생성이벤트성 동기화월별 통계 적재이 작업들은 같은 실행 모델을 요구하지 않는다.정적 화면은 S3와 CloudFront가 잘 맞는다.짧고 잦은 API는 상주 서버가 나을 수 있다.드물고 무거운 작업은 Lambda worker가 적합할 수..

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

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

AWS 실전 운영 시리즈 12/12WAF를 붙였다고 해서 시스템 전체가 자동으로 보호되는 것은 아니다.WAF는 어디에 연결되어 있는지에 따라 보호 범위가 달라진다.CloudFront에 WAF를 붙이면 CloudFront를 통과하는 요청은 검사할 수 있다. 하지만 CloudFront를 우회하는 API Gateway나 origin 직접 접근 경로는 별도 보안 정책이 필요하다.이 차이를 이해하지 못하면 "WAF가 있으니 안전하다"고 착각할 수 있다.문제 상황운영 콘솔 앞단에는 CloudFront가 있었다.프론트엔드 SPA는 CloudFront를 통해 S3에서 제공되었다.API 일부도 CloudFront를 거쳐 origin API 서버로 전달되었다.여기에 사무실 IP만 허용하는 WAF 정책을 붙일 수 있다.구조..