조용한 개발 노트

Kafka 시리즈의 마지막이다. 지금까지 우리는 Kafka의 설계 의도부터 Consumer Group, Offset, Exactly-once, 스토리지, OS, 관측, Kubernetes까지 한 바퀴를 돌았다.그럼에도 현장에서 가장 많이 듣는 말은 이것이다.“Kafka를 도입했는데, 오히려 장애가 더 늘어났다.”이 문장의 핵심은 Kafka가 아니다. 기대와 현실의 불일치다.이유 1. Kafka를 메시지 큐로 기대했다Kafka는 메시지를 전달하는 시스템이 아니라 이벤트를 기록하는 로그다.그럼에도 많은 설계는 다음을 전제로 한다.한 번만 처리될 것이다처리되면 사라질 것이다브로커가 상태를 관리해줄 것이다이 기대는 Kafka의 로그 모델과 충돌한다. 결과는 중복 처리, 오프셋 혼란, 리밸런스 폭증이다.이유 2...

9편에서 Kafka의 관측이 어려운 이유와 Consumer Lag이 왜 자주 오해되는지를 살펴봤다. 이제 많은 팀이 실제로 부딪히는 환경으로 들어가 보자.“Kafka를 Kubernetes에 올렸더니, 예전보다 장애가 더 잦아졌다.”이 문제는 Kafka나 Kubernetes 중 하나가 나빠서가 아니다. 상태를 가진 시스템(stateful system)을 무상태 플랫폼(stateless-first)에 올렸기 때문이다.Kubernetes는 본질적으로 무상태를 전제로 한다Kubernetes의 설계 전제는 명확하다.Pod는 언제든지 죽을 수 있다다시 뜨면 새 인스턴스다상태는 외부에 있어야 한다이 전제는 웹 서버나 API 서버에는 매우 잘 맞는다. 하지만 Kafka는 다르다.Kafka는 디스크에 상태를 가진 시스템..

48편에서는 운영 사고의 관점에서 Spring Boot 공식 문서를 재해석했다.이번 글은 Part 5의 정리이자, 이 시리즈 전체를 관통하는 질문에 대한 답이다. “Spring Boot 공식 문서는 어떻게 읽어야 의미가 생길까?” 같은 문서를 읽었는데 누군가는 ‘사용법’만 가져가고, 누군가는 ‘기준’을 가져간다. 그 차이는 읽는 순서와 관점에서 나온다.1) 처음부터 끝까지 읽지 말아야 하는 이유많은 개발자가 공식 문서를 이렇게 대한다.처음부터 순서대로 읽는다필요한 부분만 검색해서 본다두 방법 모두 나쁘지 않다.하지만 문제는, 이 방식으로는 Spring Boot가 전제로 삼는 ‘전체 그림’을 얻기 어렵다는 점이다.공식 문서는 설명서이면서, 동시에 설계 문서다. 설계 문서는 기능 순서가 아니라 의도를 중심으..

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의 출발..

45편에서는 애플리케이션 종료를 어떻게 설계해야 하는지를 다뤘다.이번 글에서는 실행과 종료의 경계에 위치한 주제, ApplicationEvent를 “운영 신호”로 사용하는 방법을 정리한다.ApplicationEvent는 잘 쓰면 운영 가시성을 높이는 도구가 되지만, 잘못 쓰면 구조를 망가뜨리는 트리거가 된다.1) ApplicationEvent의 본질은 “알림”이다ApplicationEvent는 Spring 내부에서 발생한 사실을 외부로 알리는 메커니즘이다.중요한 점은 이것이다. 이벤트는 “무언가를 하라”는 명령이 아니라, “무언가가 일어났다”는 신호다. 이 차이를 무시하는 순간, 이벤트는 제어 흐름의 일부가 되어버린다.2) Spring Boot가 제공하는 주요 라이프사이클 이벤트Spring Boot는 실..

44편에서는 Spring Boot Starter를 직접 만들 때의 기준을 통해 확장의 책임이 어디까지 커지는지를 살펴봤다.이번 글에서는 그 확장의 반대편, 애플리케이션의 “끝”을 다룬다.실행은 잘 설계하면서도, 종료는 거의 설계하지 않는 경우가 많다. 하지만 운영에서 사고가 나는 지점은 대부분 이 “끝”에서 시작된다.1) 애플리케이션 종료는 예외 상황이 아니다많은 코드가 애플리케이션 종료를 “비정상 상황”으로 취급한다.하지만 현대의 운영 환경에서는 종료는 매우 일상적인 이벤트다.배포로 인한 재시작오토스케일링노드 교체즉, 애플리케이션은 언제든지 종료될 수 있다는 전제 위에서 설계되어야 한다.2) Spring Boot는 언제 “종료 신호”를 받는가Spring Boot 애플리케이션은 외부에서 종료 신호를 받으..

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