JVM 힙은 정상인데 컨테이너가 OOMKilled되는 원인을 네이티브 메모리에서 추적했습니다. 스트림 close 누락과 zlib Inflater 버퍼가 핵심이었고, 도구 조합으로 범인을 찾았습니다.
의료 설문 플랫폼에서 설문 정의와 수집을 담당하는 서비스를 헥사고날 구조와 CQRS로 설계했습니다. Master/Snapshot, Kafka, Outbox 등을 적용해 정합성과 운영 안정성을 확보했습니다.
메뉴 권한처럼 변경은 적고 조회는 많은 데이터를 싱글톤 인메모리 캐시로 관리하는 방법을 소개했습니다. 이를 통해 로그인 시 DB 부하를 줄이고 응답 속도와 유지보수성을 개선했습니다.
![[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유](https://flex.team/blog/og/main.jpg)
Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.
50개 이상의 레포에 흩어진 버전업 PR을 Wave 순서에 맞춰 자동 전파하고 머지하는 방식을 설명했습니다. CI, flaky test, 에스컬레이션까지 묶어 대규모 업그레이드 운영을 자동화했습니다.
OpenRewrite로 규칙 기반 변환을 먼저 적용하고, 실패한 빌드는 Claude가 보완했습니다. 빌드 가드레일 안에서 50개 레포를 안전하게 버전업하는 구조를 설명했습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://cdn.sanity.io/images/v31psllp/production/513466e8841f7be5ac64a4a39112acafe4a63c6d-1684x1030.png)
OpenRewrite로 규칙 기반 변환을 먼저 적용하고, Claude가 예외적 수정과 빌드 에러를 보완하는 구조를 설명했습니다. 50개 레포에 안전하게 같은 변환을 재현하기 위한 recipe 설계와 가드레일 운영 방식도 다뤘습니다.
레포 간 의존성을 그래프로 복원해 변경 전파 순서를 자동 계산하는 Planner를 설명했습니다. 또한 Kotlin과 Spring Boot처럼 변경 유형에 따라 upstream-first와 downstream-first를 구분하는 방법을 정리했습니다.
![[의존성의 방향을 따라 2/5] 의존 그래프를 읽는 Planner](https://cdn.sanity.io/images/v31psllp/production/cfc2fee7bc9a333e841c5c5cf5cc07721137979c-1684x1030.png)
레포 간 의존성을 그래프로 읽어 안전한 변경 순서와 전파 방향을 계산하는 Planner를 설명했습니다. 변경 유형에 따라 upstream-first, downstream-first, 병렬 계획이 달라지는 점을 다뤘습니다.
50개 레포와 3,500개 모듈에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제인지 설명했습니다. 수동 전파의 한계를 보여주고, 자동화된 recipe 기반 구조를 제안했습니다.
![[의존성의 방향을 따라 1/5] 버전업이 고통인 이유](https://cdn.sanity.io/images/v31psllp/production/6b5c6a4d92aeec8eb1400140ea58d591749ec8ee-1684x1030.png)
50개 레포와 3,500개 모듈 환경에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제가 되는지 설명했습니다. 수동 전파의 병목을 줄이기 위해 자동화와 빌드 검증 중심의 Evergreen 구조를 제안했습니다.
Aurora MySQL에서 HikariCP의 idle connection 검증 실패 원인을 추적해 비표준 timeout 동작을 확인했습니다. interactive_timeout 이 keepalive 보다 작으면 비활성 연결이 먼저 끊길 수 있음을 정리했습니다.
