조용한 개발 노트

2편에서 Trace와 Span을 통해 요청 하나의 흐름을 연결해서 볼 수 있다는 이야기를 했다. 그런데 실제 환경에서는 이런 경험을 자주 하게 된다.“분명 트레이싱을 붙였는데, 서비스 A까지만 보이고 서비스 B부터는 trace가 끊긴다.”이 문제의 핵심은 Trace도 Span도 아니다. Context Propagation이다.traceId는 왜 저절로 이어지지 않을까흔히 하는 오해가 있다. “같은 요청이면 traceId는 자동으로 따라다니는 것 아닌가?”하지만 분산 시스템에서 요청은 하나의 프로세스-하나의 스레드 안에서 끝나지 않는다.HTTP 요청으로 들어왔다가다른 서비스로 HTTP 또는 gRPC 호출을 하고비동기 작업이나 메시지 큐를 거치고다시 다른 스레드에서 처리된다이 경계들을 넘는 순간, 아무 작업..

1편에서 다뤘던 문제를 다시 떠올려보자. 로그도 있고 메트릭도 있는데, 막상 장애가 나면 "어떤 요청이 어디서 느려졌는지"를 한 번에 설명하기가 어렵다.이 문제를 해결하기 위해 OpenTelemetry는 요청 단위 관측을 핵심 개념으로 삼는다. 그리고 그 중심에 있는 신호가 바로 Trace다.왜 요청 단위 관측이 중요한가메트릭은 전체를 요약한다. 예를 들어 p95 latency, error rate 같은 값은 시스템의 상태를 빠르게 감지하는 데 매우 유용하다.하지만 메트릭만으로는 다음 질문에 답하기 어렵다.느려진 요청은 모두 그런가, 일부만 그런가?특정 사용자-특정 기능에서만 발생한 문제인가?느려진 요청이 어떤 내부 호출 경로를 거쳤는가?이 질문들은 모두 "요청 하나"를 기준으로 시스템을 보고 싶다는 요..

장애가 났다. 알람도 울렸고, 대시보드도 빨갛다. 로그도 남아 있다. 그런데 막상 "왜 느려졌는지"를 한 문장으로 말하기가 어렵다. 특히 서비스가 여러 개로 쪼개진 분산 환경에서는 이 문제가 더 자주-더 오래 반복된다.이 글은 OpenTelemetry 공식 문서의 관점(telemetry를 통해 내부 상태를 이해한다)을 빌려, 왜 이런 일이 생기는지-그리고 무엇이 빠져 있는지를 "문제 중심"으로 정리한다. 다음 글부터는 OpenTelemetry의 핵심 개념을 하나씩 붙여서, 실제로 원인을 추적 가능한 형태로 만들어갈 예정이다.현실: 로그-메트릭은 있는데 "요청 흐름"이 없다우리가 흔히 갖고 있는 관측 데이터는 보통 두 가지다.로그: 특정 시점에 어떤 일이 발생했는지(텍스트로 기록)메트릭: 어떤 값이 얼마나..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로 진행한 1~9편 내용을 하나의 판단 프레임으로 정리한 마무리 편입니다.Spring 테스트의 핵심은 “많이 작성하는 것”이 아니라 적절한 테스트를, 적절한 위치에 배치하는 것입니다. 이 글의 목적은 그 기준을 명확히 하는 것입니다.들어가며지금까지 이 시리즈에서는 반복해서 같은 질문을 던졌습니다.이 테스트는 무엇을 보장하는가?이 검증은 어디까지 필요한가?테스트 실패 시 원인을 바로 좁힐 수 있는가?10편에서는 이 질문들을 한 번에 판단할 수 있는 지도로 정리합니다.1. 테스트 타입 선택의 기본 원칙Spring 테스트 전략의 출발점은 단순합니다.검증하고 싶은 범위만 로딩한다이를 기준으로 테스트 타입을 나누면 ..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, 실무에서 반복적으로 등장하고, 결국 테스트 신뢰도를 무너뜨렸던 테스트 안티 패턴들을 설계 관점에서 정리합니다.이 안티 패턴들의 공통점은 하나입니다. 처음에는 합리적으로 보였다는 것입니다.안티 패턴 1. 모든 테스트를 @SpringBootTest로 시작하는 경우Spring 테스트를 처음 도입할 때 가장 흔한 선택입니다.설정 고민이 없다실제 환경과 가장 비슷해 보인다하지만 이 선택의 결과는 보통 다음과 같습니다.테스트 실행 시간이 급격히 증가실패 원인을 좁히기 어려움Context 캐싱이 쉽게 깨짐@SpringBootTest는 기본값이 아니라 최후의 선택이다안티 패턴 2. 테스트 목적이 섞인 경우하나의 테스..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)와 Reactor 공식 문서를 기반으로, 비동기 및 Reactive 환경에서 테스트가 왜 어려운지, 그리고 어떻게 접근해야 하는지를 설계 관점에서 정리합니다.비동기 테스트는 기술 문제가 아니라 실행 모델을 이해하는 문제입니다.들어가며동기 코드 테스트에 익숙한 상태에서 Reactive 코드를 처음 테스트하면 다음과 같은 혼란을 겪게 됩니다.테스트가 끝났는데 로직은 아직 실행 중이다예외가 발생했는데 테스트는 통과한다SecurityContext가 사라진다이 문제들은 우연이 아닙니다. 비동기 테스트는 완전히 다른 사고 방식을 요구합니다.1. 비동기 테스트가 어려운 근본적인 이유동기 코드 테스트의 전제는 단순합니다.메서드가 ..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)와 Mockito의 기본 개념을 바탕으로, 테스트에서 자주 사용하는 Mock, Stub, Spy의 차이와 @MockBean / @SpyBean을 언제 어떻게 사용해야 하는지를 설계 관점에서 정리합니다.Mocking은 테스트를 빠르게 만들 수 있지만, 기준 없이 사용하면 테스트의 신뢰도를 무너뜨리는 가장 빠른 방법이 됩니다.들어가며Spring 테스트를 작성하다 보면 다음과 같은 상황을 쉽게 만나게 됩니다.DB를 안 띄우고 싶어서 Repository를 Mock으로 바꾼다외부 API가 귀찮아서 전부 Mock 처리한다테스트가 깨질까 봐 Stub을 잔뜩 만든다이 선택들이 모두 틀린 것은 아닙니다. 문제는,왜 Mock을 쓰는지..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, DB가 포함된 테스트를 언제 작성해야 하고, 어떻게 설계해야 하는지를 트랜잭션과 격리 관점에서 정리합니다.DB 테스트는 신뢰도를 크게 높여주지만, 잘못 설계하면 테스트 속도와 안정성을 동시에 무너뜨립니다.들어가며DB 테스트를 도입할 때 가장 흔한 고민은 이것입니다.H2 같은 Embedded DB로 충분할까?실제 DB와 완전히 동일해야 할까?모든 Repository 테스트가 필요한가?이 질문에 대한 답은 하나가 아닙니다. DB 테스트 역시 검증 목적에 따라 전략이 달라져야 합니다.1. DB 테스트의 목적부터 분리하자DB가 포함된 테스트는 다음 세 가지 목적 중 하나를 가집니다.쿼리와 매핑 검증트랜잭션 동..

이 글은 Spring Security 공식 문서(Test)와 Spring Test 공식 문서를 기반으로, Spring Security가 적용된 애플리케이션을 테스트 코드에서 어떻게 검증해야 하는지를 설계 관점에서 정리합니다.보안 테스트는 “어떻게 통과시키는가”가 아니라, “무엇을 검증해야 하는가”가 핵심입니다.들어가며Spring Security를 붙인 이후, 테스트에서 가장 자주 마주치는 상황은 이것입니다.모든 요청이 401 또는 403으로 실패한다테스트를 위해 보안을 꺼버리고 싶어진다@WithMockUser를 아무 데나 붙이게 된다이 반응은 자연스럽지만, 그대로 따라가면 보안 테스트는 무의미해집니다.1. 보안 테스트의 목적부터 다시 정의하자보안 테스트에서 가장 먼저 정리해야 할 질문은 이것입니다.이 테..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, Spring에서 Web API를 테스트할 때 사용하는 MockMvc, TestRestTemplate, WebTestClient를 비교 설명하는 대신, 언제 어떤 도구를 선택해야 하는지를 설계 기준으로 정리합니다.Web 테스트 도구 선택은 문법 취향의 문제가 아니라 테스트 범위와 신뢰도의 문제입니다.들어가며Spring에서 Web 테스트를 시작하면 가장 먼저 이런 고민에 부딪힙니다.MockMvc로 충분할까?실제 서버를 띄워야 할까?WebTestClient는 언제 쓰는 걸까?이 질문에 대한 답은무엇을 검증하려는가?에 따라 달라집니다.1. MockMvc - 컨트롤러 레이어를 빠르게 검증하기MockMvc는서버를..