고민보단 실천을

프론트 번들 사이즈 줄이기: tree-shaking, code splitting, 분석 도구로 체감 성능 개선번들은 한 번 커지면 줄이기 어렵다. 측정->원인 찾기->구조 개선 순서로 접근해야 한다.code splitting 예시import { lazy, Suspense } from 'react';const AdminPage = lazy(() => import('./pages/AdminPage'));// 라우트/기능 단위로 지연 로딩tree-shaking이 망가지는 패턴commonjs 의존성이 크다(ESM 우선).barrel export(index.ts)가 사이드이펙트를 만든다.필요 없는 폴리필을 전역으로 넣는다.분석이 먼저번들 최적화는 '무엇이 커졌는지'를 먼저 보는 게 가장 빠르다. 큰 의존성 1개를..

CORS 프리플라이트 최적화: 왜 OPTIONS가 폭주하고 어떻게 줄이나CORS는 허용/차단만의 문제가 아니다. 운영에서는 OPTIONS 프리플라이트가 트래픽을 잡아먹는 경우가 있다. 발생 조건과 줄이는 방법을 정리한다.프리플라이트 발생 조건(요약)simple request가 아니다(커스텀 헤더, 특정 Content-Type 등).Authorization 헤더 사용.PUT/DELETE 같은 메서드.Access-Control-Max-Age로 캐시Access-Control-Allow-Origin: https://app.example.comAccess-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONSAccess-Control-Allow-Headers: Content-T..

SSO 선택 기준: OIDC vs SAML, 엔터프라이즈 로그인에서 자주 헷갈리는 포인트엔터프라이즈 SSO는 표준이지만, 구현은 항상 케이스 바이 케이스입니다.OIDC와 SAML의 차이를 '실무 선택 기준'으로 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)보안은 '켜면 끝'이 아니라, 환경(도메인/HTTPS/프록시)과 결합된 실제 동작이 중요합니다. 그래서 단계적 도입과 관측이 핵심입니다.보안 설정은 예외가 생기기 쉬우므로, 예외를 '운영 프로세스'로 관리(만료/승인/감사)하지 않으면 시간이 지날수록 사고 확률이 커집니다.실전 내용(바로 적용)엔터프라이즈 SSO는 표준이지만, 구현은 항상 케이스..

보안 헤더 실전: CSP/HSTS/X-Content-Type-Options를 언제 어떻게 켤까보안 헤더는 켜면 좋지만, 잘못 켜면 서비스가 깨집니다. 그래서 '순서'가 중요합니다.CSP/HSTS 등 자주 쓰는 헤더를 운영 가능하게(깨지지 않게) 도입하는 방법을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)보안은 '켜면 끝'이 아니라, 환경(도메인/HTTPS/프록시)과 결합된 실제 동작이 중요합니다. 그래서 단계적 도입과 관측이 핵심입니다.보안 설정은 예외가 생기기 쉬우므로, 예외를 '운영 프로세스'로 관리(만료/승인/감사)하지 않으면 시간이 지날수록 사고 확률이 커집니다.실전 내용(바로 적용)보..

레이트리밋 응답 설계: 429 + RFC 9331 RateLimit 헤더로 클라이언트 재시도 폭주 막기레이트리밋은 '막는 것'이 아니라 '안전하게 실패시키는 것'입니다.429 응답에 RateLimit 헤더(RFC 9331)와 Retry-After를 어떻게 넣어야 클라이언트 재시도 폭주를 줄일 수 있는지 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이..

API 에러 응답 표준화: RFC 9457 Problem Details로 error format 통일하기에러 응답이 엔드포인트마다 다르면, 프론트는 화면마다 예외 처리를 다시 씁니다.RFC 9457(Problem Details)을 기준으로 에러 포맷을 통일하고, 운영에서 디버깅이 쉬워지는 형태로 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해..

Contract Testing(Pact) 입문: API 변경을 '사고'가 아니라 '검증'으로 바꾸기API 변경이 무서운 이유는, 언제 깨질지 모르기 때문입니다. 계약 테스트는 그 불확실성을 줄입니다.Pact를 기준으로 소비자/제공자 테스트를 어떻게 운영하면 효과가 나는지 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지..

CDN 캐시 키 설계 실전: 쿼리스트링/헤더/쿠키를 캐시 키에 넣는 기준CDN을 붙였는데도 느리다면, 대부분 캐시 키가 잘못돼서 적중률이 낮습니다.캐시 키 설계를 '넣을 것/빼야 할 것' 기준으로 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)CDN을 붙였는데도 느리다면, 대부분 캐시 키가 잘못돼서 적중률이 낮습니다.캐시 키 설계를 '넣을 것/빼야 할 것' 기준으로 정..

API Mocking 실전: MSW vs WireMock, 프론트/백엔드에서 언제 무엇을 쓰나API mocking은 테스트 편의가 아니라 개발 속도를 지키는 장치입니다.MSW(프론트)와 WireMock(백엔드)로 어디까지를 mock하고, 어디부터는 실제 통합으로 검증할지 기준을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 ..