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

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

보안 3

WAF는 어디에 붙어 있고, 어디까지 보호하는가

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

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

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

내부 문서를 블로그 글로 바꾸기 위한 익명화 체크리스트

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