조용한 개발 노트

47편에서는 Actuator · Security · Observability가 하나의 운영 계약으로 설계되어야 한다는 기준을 정리했다.이번 글에서는 그 기준을 한 단계 더 밀어붙여, 운영 사고 이후에야 비로소 이해되는 Spring Boot 공식 문서의 문장들을 다시 읽어본다.이 글은 새로운 기능 설명이 아니다. 이미 문서에 있었지만, 사고를 겪기 전에는 그냥 지나쳤던 내용들에 대한 이야기다.1) “production-ready”라는 표현을 너무 가볍게 읽었던 순간Spring Boot 공식 문서에는 Actuator를 설명하며 자주 이런 표현이 등장한다. “production-ready features” 많은 개발자는 이 문장을 “운영에 도움이 되는 기능 모음” 정도로 읽는다.하지만 실제 사고를 겪고 나면,..

46편에서는 ApplicationEvent를 로직이 아닌 운영 신호로 사용하는 기준을 정리했다.이번 글에서는 그 신호들이 실제로 모이는 장소, Actuator를 중심으로 보안(Security)과 관측(Observability)을 어떻게 함께 설계해야 하는지를 다룬다.이 영역은 실무에서 사고가 가장 자주 발생하는 교차 지점이기도 하다.1) Actuator는 “상태 API”이지 “디버그 도구”가 아니다많은 팀이 Actuator를 문제 생겼을 때만 켜는 디버그 도구처럼 취급한다.하지만 Spring Boot에서 Actuator의 본질은 애플리케이션의 상태를 설명하는 API다.즉:개발자만을 위한 도구 ❌운영 시스템과의 계약 ⭕이 관점이 없으면, 노출과 보안은 항상 땜질이 된다.2) Observability의 출발..

29편에서는 Spring Boot Security Auto-Configuration을 통해 왜 기본적으로 “막혀 있는 상태”가 출발점인지를 살펴봤다.이번 글에서는 그 보안의 연장선, 운영에서 사고를 가장 자주 만드는 영역인 Actuator 보안 설계를 다룬다.Actuator는 운영에 필수지만, 동시에 노출되는 순간 가장 위험한 인터페이스가 된다.1) Actuator는 “관리 API”이지 “일반 API”가 아니다Actuator Endpoint는 일반 비즈니스 API와 성격이 다르다.사용자를 위한 API ❌운영 시스템을 위한 API ⭕이 차이를 무시하고 동일한 접근 정책을 적용하면, 보안 사고는 시간문제다.Actuator는 사람보다 시스템이 먼저 소비하는 인터페이스다.2) 기본 노출 정책이 보수적인 이유Sp..

14편에서는 Health Indicator를 통해 언제 트래픽을 받아야 하고, 언제 빠져야 하는지를 다뤘다.이번 글에서는 그 다음 단계, “그래서 지금 시스템 상태는 어떤가?”에 답해주는 Metrics와 Monitoring을 정리한다.메트릭은 많이 모을수록 좋은 것처럼 보이지만, 실제 운영에서는 정반대인 경우가 많다.1) Metrics의 목적은 “관찰”이지 “기록”이 아니다처음 모니터링을 도입할 때 흔히 생기는 오해는 이것이다.“일단 다 모아두면 언젠가 쓰겠지.”하지만 Metrics의 목적은 나중을 위한 로그 저장이 아니다. 지금 시스템이 어떤 상태인지, 문제가 생기고 있는지 빠르게 판단하기 위함 이 목적에서 벗어난 메트릭은 비용만 늘리고 판단을 흐리게 만든다.2) Spring Boot Metrics의 ..

13편에서는 Actuator가 왜 Spring Boot의 핵심 기능인지, 그리고 “production-ready”가 무엇을 의미하는지 살펴봤다.이제 그중에서도 운영에 가장 직접적으로 영향을 미치는 주제, Health Indicator를 다뤄보자.Health Indicator는 단순한 상태 체크가 아니다. 잘 설계되면 장애를 빠르게 복구하게 만들고, 잘못 설계되면 멀쩡한 서비스를 스스로 죽이기도 한다.1) Health Check는 “살아있다”의 정의부터 다르다많은 서비스가 Health Check를 이렇게 생각한다.“요청 하나 보내서 200이면 OK”하지만 Spring Boot Actuator가 말하는 Health는 훨씬 더 구체적이다.지금 프로세스가 살아 있는가?필수 의존성은 정상인가?지금 트래픽을 받아도..

12편에서는 Spring Boot 애플리케이션의 Startup 단계 전체 흐름를 해부했다.이제 관점을 한 단계 더 넓혀보자.애플리케이션이 “실행된 이후”에 무엇이 필요한가?이 질문에 대한 Spring Boot의 대답이 바로 Actuator다.1) Actuator는 “있으면 좋은 옵션”이 아니다많은 사람들이 Actuator를 “모니터링용 부가 기능” 정도로 생각한다.하지만 Spring Boot 공식 문서에서 Actuator는 명확히 production-ready 기능으로 분류된다.이 말의 의미는 단순하다. “운영에 필요한 기능은 나중에 붙이는 것이 아니라, 애플리케이션의 일부다.” Actuator는 애플리케이션이 살아 있는 동안 스스로의 상태를 외부에 설명할 수 있게 해준다.2) Spring Boot가 말..

1편에서는 Spring Boot가 무엇을 해결하기 위해 등장했는지를 살펴봤다. 정리하면 핵심은 하나였다.“Spring으로 서비스를 만들 때 반복되는 초기 세팅·표준화·운영 준비 비용을 줄이자.”이번 글에서는 Spring Boot가 이 문제를 해결하기 위해 제공하는 세 가지 핵심 도구를 살펴본다.StarterAuto-ConfigurationActuator이 세 가지를 이해하면, Spring Boot를 “왜 이렇게 동작하는지 아는 상태”로 사용할 수 있게 된다.1) Starter: 의존성 선택 비용을 없애다Spring 프로젝트를 처음 만들 때 가장 귀찮은 작업 중 하나는 의존성 조합을 고르는 일이다.웹 프로젝트에 필요한 라이브러리는 무엇인가?로그는 어떤 구현체를 쓰는가?테스트 라이브러리는 어디까지 포함해야 ..

Spring을 처음 쓸 때 가장 많이 듣는 말이 있습니다.“Spring은 좋은데… 설정이 너무 많아.”“프로젝트 시작하려면 먼저 골격 잡다가 하루가 간다.”“로컬/개발/운영 환경 설정 분리하다가 결국 사람이 실수한다.”Spring Boot는 딱 이 지점, 즉 “잘 만들 수는 있는데 시작/표준/운영 준비가 너무 비싸다”는 비용을 줄이기 위해 등장했다. 공식 문서에서도 Spring Boot는 stand-alone 형태로 실행 가능하고, production-grade 애플리케이션을 최소한의 번거로움으로 만들기 위한 도구라고 설명한다.1) “Spring 자체가 어렵다”가 아니라, “프로젝트의 기본값이 없다”가 문제였다Spring Framework는 강력하지만 선택지가 많다.웹 서버: Tomcat? Jetty?설..