고민보단 실천을

Trivy로 컨테이너 취약점 스캔 CI 만들기: 실패 기준(Severity)과 예외 운영법취약점 스캔은 '0개'가 목표가 아니라, 팀이 운영 가능한 기준을 만드는 게 목표입니다.Trivy를 CI에 붙이고, 실패 기준과 예외(allowlist) 운영을 어떻게 하면 덜 괴로운지 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)취약점 스캔은 '0개'가 목표가 아니라, 팀이 운..

Supply Chain 보안 입문: SBOM과 SLSA를 '지금 팀'에 맞게 도입하는 방법요즘 보안은 코드보다 '빌드/배포 파이프라인'이 먼저 털립니다.SBOM과 SLSA를 유행어가 아니라, 팀이 운영 가능한 최소 단위로 도입하는 방법을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.실전 내용(바로 적용..

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

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

OpenAPI 3.1로 API 문서/검증 자동화: 스키마 드리프트 막는 운영법목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람API 계약이 자주 깨져서(혹은 깨질까봐) 변경을 두려워하는 팀성능/운영 이슈가 나는데 원인이 '네트워크/헤더/캐시/정책' 쪽인지 헷갈리는 상황문서를 '참고'가 아니라 '계약'으로 쓰고 싶은 팀추천 기본값(실무에서 안전한 시작점)정책(기준)을 먼저 정하고, 구현/도구는 그 다음에 선택한다관측(로그/지표)을 먼저 ..

Docker 이미지 최적화: 멀티스테이지 빌드, distroless, 취약점 스캔까지목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람배포/운영 중 5xx/타임아웃/리소스 고갈이 간헐적으로 터지는 팀Kubernetes/Nginx/Docker 같은 인프라 설정에서 원인 찾는 시간이 긴 팀장애를 '재현/측정/완화' 순서로 표준화하고 싶은 팀추천 기본값(실무에서 안전한 시작점)시간 예산(타임아웃)과 종료(드레인)를 먼저 정렬한다운영 설정은 '..

Spring Boot Testcontainers 실전: PostgreSQL/Redis 통합테스트를 CI에서 안정화하기Testcontainers는 '내 컴퓨터에서는 되는데 CI에서는 실패'를 줄여주는 통합테스트 표준 패턴이라 검색 유입이 꾸준합니다. 이 글은 Spring Boot에서 Postgres/Redis 컨테이너를 기반으로 통합테스트를 안정화하는 포인트를 정리합니다.컨테이너 기반 통합테스트는 환경 차이를 줄여 회귀를 빨리 잡습니다.옵션/핵심 요소(3~6개)항목의미언제 쓰는지(실무 상황)PostgreSQLContainerDB 컨테이너마이그레이션+JPA까지 포함한 검증Redis 컨테이너캐시/락 검증운영과 동일한 Redis 동작을 테스트CI Docker실행 환경러너에서 Docker 사용 가능 여부 확인랜덤..

Sentry 소스맵 배포 트러블슈팅: release/url prefix 불일치로 스택이 난독화될 때Sentry 이벤트는 올라오는데 스택트레이스가 minified로 보이는 문제는 검색 수요가 매우 큽니다. 원인은 대부분 release 불일치, 소스맵 업로드 누락, url prefix(경로) 불일치입니다. 이 글은 CI에서 소스맵을 안정적으로 붙이는 체크리스트를 제공합니다.소스맵은 빌드 결과와 Sentry 아티팩트가 정확히 매칭되어야 합니다.옵션/핵심 요소(3~6개)항목의미언제 쓰는지(실무 상황)release배포 식별자코드에서 보내는 release와 업로드 release 일치upload sourcemaps소스맵 업로드CI에서 빌드 후 업로드를 강제url prefix경로 매칭브라우저가 로드하는 JS URL과 ..

GitHub Actions 캐시가 안 먹힐 때 점검: pnpm/npm/gradle key 설계와 cache miss 원인CI가 느린 이유 1순위는 의존성 설치입니다. 그런데 캐시를 넣었는데도 매번 install이 도는 경우가 많습니다. 이 글은 GitHub Actions 캐시가 안 먹히는 이유를 '키 설계' 관점에서 정리하고, pnpm/npm/gradle 예시를 제공합니다.캐시는 결국 key hit/miss 게임이고, key를 어떻게 묶느냐가 성능과 안정성을 좌우합니다.옵션/핵심 요소(3~6개)항목의미언제 쓰는지(실무 상황)path캐시할 디렉터리pnpm store, npm cache, gradle caches 등 실제 설치 비용을 줄이는 위치key캐시 식별자lockfile이 바뀌면 무효화되도록 hashF..