![[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유](https://flex.team/blog/og/main.jpg)

[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유
Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.
![[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유](https://flex.team/blog/og/main.jpg)

Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.
![[의존성의 방향을 따라 4/5] PR을 전파하는 Distributer](https://flex.team/blog/og/main.jpg)

50개 이상의 레포에 흩어진 버전업 PR을 Wave 순서에 맞춰 자동 전파하고 머지하는 방식을 설명했습니다. CI, flaky test, 에스컬레이션까지 묶어 대규모 업그레이드 운영을 자동화했습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://flex.team/blog/og/main.jpg)

OpenRewrite로 규칙 기반 변환을 먼저 적용하고, 실패한 빌드는 Claude가 보완했습니다. 빌드 가드레일 안에서 50개 레포를 안전하게 버전업하는 구조를 설명했습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://cdn.sanity.io/images/v31psllp/production/513466e8841f7be5ac64a4a39112acafe4a63c6d-1684x1030.png)

OpenRewrite로 규칙 기반 변환을 먼저 적용하고, Claude가 예외적 수정과 빌드 에러를 보완하는 구조를 설명했습니다. 50개 레포에 안전하게 같은 변환을 재현하기 위한 recipe 설계와 가드레일 운영 방식도 다뤘습니다.
![[의존성의 방향을 따라 2/5] 의존 그래프를 읽는 Planner](https://flex.team/blog/og/main.jpg)

레포 간 의존성을 그래프로 복원해 변경 전파 순서를 자동 계산하는 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, 병렬 계획이 달라지는 점을 다뤘습니다.
![[의존성의 방향을 따라 1/5] 버전업이 고통인 이유](https://flex.team/blog/og/main.jpg)

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 보다 작으면 비활성 연결이 먼저 끊길 수 있음을 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행](https://flex.team/blog/og/main.jpg)

Issue 도메인을 독립 실행 가능한 standalone-app으로 조립해 핵심 로직만 빠르게 검증하는 구조를 소개했습니다. 프로덕션 Adapter만 교체하고 시드 데이터, Swagger, React 프론트엔드를 묶어 AI 협업 검증 환경을 만들었습니다.
![[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행](https://cdn.sanity.io/images/v31psllp/production/c72e37fd2798380477938778b0b7d6bfedb91235-1684x1030.png)

Hexagonal Architecture로 Issue 도메인을 standalone-app으로 독립 실행해 핵심 비즈니스 로직만 검증하는 구조를 소개했습니다. AI 에이전트의 빠른 피드백 루프와 격리된 검증 환경을 만드는 방법을 설명했습니다.
![[AI가 읽을 수 있는 코드베이스 1/5] Agentic Engineering: 빌드가 에이전트를 가르친다](https://cdn.sanity.io/images/v31psllp/production/8c8e4c82ffacf0453ef46f35bdbe0b0d828d9082-1684x1030.png)

AI 코딩 에이전트의 성능은 프롬프트보다 코드베이스 구조에 더 크게 좌우된다고 설명했습니다. 빌드 가드레일과 모듈 경계가 에이전트의 잘못된 수정을 빠르게 막는 핵심이라고 정리했습니다.