되도록 최신 버전을 사용하는게 왜 이렇게 어려울까?
폴리레포에서 버전 관리 자동화를 가능하게 한 Version Family 설계와 전제 조건을 설명했습니다. 빌드 동형성과 단방향 의존 구조가 있어야 최신 버전 수렴이 가능하다고 정리했습니다.

폴리레포에서 버전 관리 자동화를 가능하게 한 Version Family 설계와 전제 조건을 설명했습니다. 빌드 동형성과 단방향 의존 구조가 있어야 최신 버전 수렴이 가능하다고 정리했습니다.
여섯 축의 공통 원리를 하나의 표로 정리하며 인프라를 소프트웨어처럼 다루는 관점을 설명했습니다. 사람과 AI 에이전트가 안전하게 변경하고 되돌릴 수 있는 피드백 루프의 중요성을 강조했습니다.
terraform plan만으로는 인프라의 실제 동작을 확인할 수 없다는 문제를 다뤘습니다. 로컬 클러스터 검증과 재현 가능한 선언으로 apply 전 신뢰도를 높이는 방법을 소개했습니다.
공유 dev 병목을 없애기 위해 브랜치 하나로 격리 환경을 만드는 Environment Variant 설계를 소개했습니다. ArgoCD ApplicationSet으로 생성과 회수를 자동화해 환경 생명주기를 git과 연결했습니다.
플랫폼팀이 코드 바깥의 환경 실체를 선언으로 만드는 방식을 설명했습니다. Kafka 토픽 선언과 검증, 추적 가능한 거버넌스 사례를 다뤘습니다.
Terraform plan은 변경점만 보여 주고 실제 동작은 보장하지 못한다고 설명했습니다. IaC를 넘어 테스트 가능성과 재현 가능성을 갖춘 IaS 관점이 필요하다고 강조했습니다.
![[인프라를 소프트웨어처럼 1/5] Infrastructure as Code, 그리고 그다음](https://flex.team/blog/og/main.jpg)
Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.
![[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유](https://flex.team/blog/og/main.jpg)
50개 이상의 레포에 흩어진 버전업 PR을 Wave 순서에 맞춰 자동 전파하고 머지하는 방식을 설명했습니다. CI, flaky test, 에스컬레이션까지 묶어 대규모 업그레이드 운영을 자동화했습니다.
![[의존성의 방향을 따라 4/5] PR을 전파하는 Distributer](https://flex.team/blog/og/main.jpg)
OpenRewrite로 규칙 기반 변환을 먼저 적용하고, 실패한 빌드는 Claude가 보완했습니다. 빌드 가드레일 안에서 50개 레포를 안전하게 버전업하는 구조를 설명했습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://flex.team/blog/og/main.jpg)
OpenRewrite로 규칙 기반 변환을 먼저 적용하고, Claude가 예외적 수정과 빌드 에러를 보완하는 구조를 설명했습니다. 50개 레포에 안전하게 같은 변환을 재현하기 위한 recipe 설계와 가드레일 운영 방식도 다뤘습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://cdn.sanity.io/images/v31psllp/production/513466e8841f7be5ac64a4a39112acafe4a63c6d-1684x1030.png)
레포 간 의존성을 그래프로 복원해 변경 전파 순서를 자동 계산하는 Planner를 설명했습니다. 또한 Kotlin과 Spring Boot처럼 변경 유형에 따라 upstream-first와 downstream-first를 구분하는 방법을 정리했습니다.
![[의존성의 방향을 따라 2/5] 의존 그래프를 읽는 Planner](https://flex.team/blog/og/main.jpg)
레포 간 의존성을 그래프로 읽어 안전한 변경 순서와 전파 방향을 계산하는 Planner를 설명했습니다. 변경 유형에 따라 upstream-first, downstream-first, 병렬 계획이 달라지는 점을 다뤘습니다.
![[의존성의 방향을 따라 2/5] 의존 그래프를 읽는 Planner](https://cdn.sanity.io/images/v31psllp/production/cfc2fee7bc9a333e841c5c5cf5cc07721137979c-1684x1030.png)
50개 레포와 3,500개 모듈에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제인지 설명했습니다. 수동 전파의 한계를 보여주고, 자동화된 recipe 기반 구조를 제안했습니다.
![[의존성의 방향을 따라 1/5] 버전업이 고통인 이유](https://flex.team/blog/og/main.jpg)
50개 레포와 3,500개 모듈 환경에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제가 되는지 설명했습니다. 수동 전파의 병목을 줄이기 위해 자동화와 빌드 검증 중심의 Evergreen 구조를 제안했습니다.
![[의존성의 방향을 따라 1/5] 버전업이 고통인 이유](https://cdn.sanity.io/images/v31psllp/production/6b5c6a4d92aeec8eb1400140ea58d591749ec8ee-1684x1030.png)
코드 품질이 높아도 AI 접근성은 낮을 수 있다고 설명했습니다. 빌드 가드레일과 모듈 경계, 패턴 일관성이 AI 친화적 코드베이스를 만든다고 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 5/5] AI 접근성 등급으로 보는 코드베이스](https://flex.team/blog/og/main.jpg)
코드 품질만으로는 AI 코딩 에이전트의 작업 가능성을 설명할 수 없다는 점을 다뤘습니다. 구조적 일관성과 빌드 가드레일이 AI 접근성을 높이는 핵심이라고 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 5/5] AI 접근성 등급으로 보는 코드베이스](https://cdn.sanity.io/images/v31psllp/production/fa5b3c7e2429ae8264908c69c7d665726ffd5940-1684x1030.png)
AI가 만든 PR의 동작 검증을 E2E와 데모 녹화로 자동화해 리뷰의 초점을 설계 판단으로 옮겼습니다. 또한 반복 실행 가능한 Acceptance 인프라와 그 한계까지 함께 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 4/5] Acceptance 증명이 리뷰를 바꾼다](https://flex.team/blog/og/main.jpg)
PR 리뷰의 첫 질문인 동작 확인을 E2E와 데모 녹화로 자동화했습니다. 그 결과 리뷰어가 설계와 구조 검증에 더 집중하도록 전환했습니다.
![[AI가 읽을 수 있는 코드베이스 4/5] Acceptance 증명이 리뷰를 바꾼다](https://cdn.sanity.io/images/v31psllp/production/6705c41b0f4dc43d0e1f65c9a632db8d0f8246c7-1684x1030.png)
Issue 도메인을 독립 실행 가능한 standalone-app으로 조립해 핵심 로직만 빠르게 검증하는 구조를 소개했습니다. 프로덕션 Adapter만 교체하고 시드 데이터, Swagger, React 프론트엔드를 묶어 AI 협업 검증 환경을 만들었습니다.
![[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행](https://flex.team/blog/og/main.jpg)
Hexagonal Architecture로 Issue 도메인을 standalone-app으로 독립 실행해 핵심 비즈니스 로직만 검증하는 구조를 소개했습니다. AI 에이전트의 빠른 피드백 루프와 격리된 검증 환경을 만드는 방법을 설명했습니다.
![[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행](https://cdn.sanity.io/images/v31psllp/production/c72e37fd2798380477938778b0b7d6bfedb91235-1684x1030.png)