MSA 품질관리 CI게이트로 풀어내기
MSA 품질관리를 CI 게이트로 옮겨 일관된 기준으로 강제하는 방법을 정리했습니다. 변경 범위 검증, 차단 강도 분리, immutable artifact 승격을 통해 운영 신뢰성을 높였습니다.

Kotlin 태그가 달린 국내 IT 기업 기술 블로그 글을 최신순으로 모았습니다.
20개 표시
MSA 품질관리를 CI 게이트로 옮겨 일관된 기준으로 강제하는 방법을 정리했습니다. 변경 범위 검증, 차단 강도 분리, immutable artifact 승격을 통해 운영 신뢰성을 높였습니다.

terraform plan만으로는 인프라의 실제 동작을 확인할 수 없다는 문제를 다뤘습니다. 로컬 클러스터 검증과 재현 가능한 선언으로 apply 전 신뢰도를 높이는 방법을 소개했습니다.
![[인프라를 소프트웨어처럼 4/5] plan은 동작을 모른다: 인프라를 테스트·재현한다는 것](https://static.flex.team/v2/landing-2024/og/main.jpg)
Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.
![[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유](https://flex.team/blog/og/main.jpg)
OpenRewrite로 규칙 기반 변환을 먼저 적용하고, 실패한 빌드는 Claude가 보완했습니다. 빌드 가드레일 안에서 50개 레포를 안전하게 버전업하는 구조를 설명했습니다.
![[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다](https://flex.team/blog/og/main.jpg)
레포 간 의존성을 그래프로 복원해 변경 전파 순서를 자동 계산하는 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)
PR 리뷰의 첫 질문인 동작 확인을 E2E와 데모 녹화로 자동화했습니다. 그 결과 리뷰어가 설계와 구조 검증에 더 집중하도록 전환했습니다.
![[AI가 읽을 수 있는 코드베이스 4/5] Acceptance 증명이 리뷰를 바꾼다](https://cdn.sanity.io/images/v31psllp/production/6705c41b0f4dc43d0e1f65c9a632db8d0f8246c7-1684x1030.png)
Hexagonal Architecture로 Issue 도메인을 standalone-app으로 독립 실행해 핵심 비즈니스 로직만 검증하는 구조를 소개했습니다. AI 에이전트의 빠른 피드백 루프와 격리된 검증 환경을 만드는 방법을 설명했습니다.
![[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행](https://cdn.sanity.io/images/v31psllp/production/c72e37fd2798380477938778b0b7d6bfedb91235-1684x1030.png)
AI 코딩 에이전트가 받는 빌드 피드백을 유형별로 비교하며 정보 품질 차이를 분석했습니다. 가장 중요한 규칙은 컴파일 타임에 강제하고, 에러 메시지와 테스트 실패를 더 명확하게 설계해야 한다고 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 2/5] 빌드 피드백이 AI를 가르친다](https://flex.team/blog/og/main.jpg)
AI 코딩 에이전트에게 빌드 피드백 유형별 정보 품질이 어떻게 다른지 분석했습니다. 컴파일 타임 검증과 맥락 있는 에러 메시지가 가장 효과적이라고 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 2/5] 빌드 피드백이 AI를 가르친다](https://cdn.sanity.io/images/v31psllp/production/3d96b197bc8207cb19daa7120faefb616f656785-1684x1030.png)
프롬프트보다 코드베이스 구조가 AI 활용의 하한선을 결정한다는 관점을 설명했습니다. 빌드 가드레일과 모듈 경계로 에이전트의 잘못된 의존성을 즉시 차단하는 방법을 다뤘습니다.
![[AI가 읽을 수 있는 코드베이스 1/5] 프롬프트보다 구조가 먼저다](https://flex.team/blog/og/main.jpg)
AI 코딩 에이전트의 성능은 프롬프트보다 코드베이스 구조에 더 크게 좌우된다고 설명했습니다. 빌드 가드레일과 모듈 경계가 에이전트의 잘못된 수정을 빠르게 막는 핵심이라고 정리했습니다.
![[AI가 읽을 수 있는 코드베이스 1/5] Agentic Engineering: 빌드가 에이전트를 가르친다](https://cdn.sanity.io/images/v31psllp/production/8c8e4c82ffacf0453ef46f35bdbe0b0d828d9082-1684x1030.png)
테스트 인프라에서 variant와 스냅샷 캐시로 프로덕션의 분리를 그대로 재현하는 구조를 설명했습니다. 경계를 명확히 하면 교체 가능성이 높아지고 실험 속도도 빨라진다고 정리했습니다.
![[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합](https://cdn.sanity.io/images/v31psllp/production/05ffda096002d40620c7bc75e64174185b7d8a1d-1684x1030.png)
Spring Data JDBC의 Composite ID 적용을 계기로 Spring Boot 4와 Spring Batch 6 업그레이드를 진행했습니다. 복합키 매핑, 배치 메타데이터 변경, Kotlin·Jackson·Gradle 호환성까지 함께 정리했습니다.
HR SaaS에서 시간을 비즈니스 입력으로 보고, 요청 헤더와 `Clock` Adapter로 현재 시점을 교체하는 타임머신 구조를 설명했습니다. 비동기 경계 전파와 환경별 활성화, 서드파티 시계 호출의 한계도 함께 다뤘습니다.
![[코드가 환경을 모르는 구조 4/7] 타임머신 — 시간 축을 교체한다](https://flex.team/blog/og/main.jpg)
HR SaaS에서는 시간이 급여와 연차 결과를 바꾸는 입력이므로 요청 단위로 교체 가능하게 만들었습니다. Clock 포트와 헤더 기반 Adapter, 비동기 컨텍스트 전파, 환경별 활성화로 타임머신을 구현했습니다.
![[코드가 환경을 모르는 구조 4/7] 타임머신 — 시간 축을 교체한다](https://cdn.sanity.io/images/v31psllp/production/6a70f8e2c090762cbd4b1a9d470f573cbc0fc038-1684x1030.png)
IaC를 헥사고날 구조로 재해석해 spec과 클라우드 구현을 분리하는 방식을 소개했습니다. Kotlin 타입 검증과 스택 분리로 오류를 줄이고 멀티클라우드 확장성을 높였습니다.
![[코드가 환경을 모르는 구조 3/7] IaC에도 헥사고날이 관통한다](https://flex.team/blog/og/main.jpg)
IaC에서도 헥사고날 구조를 적용해 `spec`를 Port, 클라우드 모듈을 Adapter로 분리했습니다. 컴파일 타임 검증과 스택 분리로 경계 오류와 블라스트 반경을 줄였습니다.
![[코드가 환경을 모르는 구조 3/7] IaC에도 헥사고날이 관통한다](https://cdn.sanity.io/images/v31psllp/production/b2a8cb4606e7b21da6b7f074f0c8238e9d02de14-1684x1030.png)