najang 님의 블로그

🧠 이번 주에 새로 배운 것시퀀스 다이어그램의 적정 수준: 설계 단계에서 API 명세나 SQL 쿼리 같은 세부 구현에 매몰되면 오히려 전체 흐름을 놓칠 수 있다는 걸 배웠습니다. 추상화 단계를 높여 "어떤 기능이 어떤 흐름으로 이어지는지"를 명확히 정의하는 것이 설계의 핵심임을 깨달았습니다.동시성 제어 전략의 트레이드 오프: 재고 차감처럼 데이터의 정확성이 생명인 도메인에서는 처리량(Throughput)을 조금 포기하더라도 비관적 락(Pessimistic Lock)이 더 안전한 선택지가 될 수 있음을 학습했습니다. 💭 이런 고민이 있었어요낙관적 락 vs 비관적 락: 충돌이 잦을 것으로 예상되는 주문 도메인에서 SELECT FOR UPDATE를 활용한 비관적 락을 선택했습니다.데드락(Deadlock) ..

목차 TL;DR지도 앱의 실시간은 연동이 아니라 연출이다! 들어가며“1분 뒤 도착이라 했는데, 왜 안 오지”? 혹은 “곧 도착이라 했는데, 왜 이미 지나갔지?”지도 앱을 쓰며 누구나 한 번쯤 품어봤을 의문입니다.오늘도 어김없이 출근을 하기 위해 지도 앱을 켜고 대중교통을 기다리던 와중, 근본적인 궁금증이 들었습니다.지도 앱의 ‘실시간’은 정말 실시간일까?오늘은 이 간극 속에 숨겨진 데이터 파이프라인에 대해 얘기해보고자 합니다.1. ’실시간‘의 정의: 우리가 속고 있는 걸까?실제 흐르는 시간과 같은 시간. (표준국어대사전) 사전적 의미의 실시간은 '오차 없는 동시성'을 뜻하지만, 기술의 세계에선 조금 다릅니다. 물리적 지연(Latency)이 존재하는 한, 완벽한 실시간은 불가능하기 때문이죠. 따..

🧠 이번 주에 새로 배운 것테스트를 Unit / Integration / E2E 세 단계로 나눠서 작성하니, 각 테스트가 검증하는 책임 범위가 훨씬 명확해진다는 걸 체감했습니다.UnitMockito를 사용해 UserService의 비즈니스 로직만을 독립적으로 검증IntegrationTestContainers(MySQL)를 활용해 Spring Context와 JPA Repository를 함께 띄우고, 실제 DB 연동까지 포함한 영속석 계층 통합 검증E2ETestRestTemplate으로 애플리케이션을 실제로 실행한 뒤, HTTP 요청부터 인증 필터/인터셉터를 거쳐 응답이 반환되기까지의 전체 흐름 검증PasswordPolicy처럼 검증 로직을 별도 객체로 분리하니, 정책 변경 시 서비스 코드를 건드리지 않..

목차 들어가며: “테스트가 나를 괴롭히기 시작했다”처음 테스트 코드를 작성했을 때, 테스트의 개수가 늘어나는 것만으로도 마냥 뿌듯했습니다.초록색 체크 표시✅가 늘어날수록 제 코드가 안전하다고 말해주는 것 같았거든요.그런데 어느 순간부터 테스트가 저의 발목을 잡기 시작했습니다.로직은 그대로인데 리팩터링만 하면 테스트가 우수수 깨지고,verify()가 줄줄이 달린 테스트 코드는 읽기도, 고치기도 어려웠으며,무엇보다 “이 테스트로 무엇을 검증하고 싶은 거지?” 라는 의문이 계속 들었습니다.문제는 테스트 더블(Test Double)을 쓰는 방식에 있었습니다.특히 Mock을 너무 많이 쓴 것과 검증 포인트를 잘못 잡은 것이 가장 큰 원인이었습니다. 이 글은 제가 테스트 코드를 작성하면서 부딪힌 시행착오를 바탕으로..