[AI가 읽을 수 있는 코드베이스 4/5] Acceptance 증명이 리뷰를 바꾼다
PR 리뷰의 첫 질문인 동작 확인을 E2E와 데모 녹화로 자동화했습니다. 그 결과 리뷰어가 설계와 구조 검증에 더 집중하도록 전환했습니다.
![[AI가 읽을 수 있는 코드베이스 4/5] Acceptance 증명이 리뷰를 바꾼다](https://cdn.sanity.io/images/v31psllp/production/6705c41b0f4dc43d0e1f65c9a632db8d0f8246c7-1684x1030.png)

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)
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와 스냅샷 캐시로 분리·재사용하는 방법을 정리했습니다. 경계를 깎아 교체 가능성을 만들면 CI와 개발 이터레이션이 함께 빨라졌습니다.
![[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합](https://flex.team/blog/og/main.jpg)
테스트 인프라에서 variant와 스냅샷 캐시로 프로덕션의 분리를 그대로 재현하는 구조를 설명했습니다. 경계를 명확히 하면 교체 가능성이 높아지고 실험 속도도 빨라진다고 정리했습니다.
![[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합](https://cdn.sanity.io/images/v31psllp/production/05ffda096002d40620c7bc75e64174185b7d8a1d-1684x1030.png)
실제 DB를 쓰는 통합 테스트는 신뢰도가 높지만, 컨텍스트 분화로 컨테이너가 복제되며 CI가 느려졌습니다. 이를 Gradle BuildService로 공유하고 스키마를 분리해 속도와 격리를 함께 확보했습니다.
![[코드가 환경을 모르는 구조 6/7] 컨테이너는 왜 폭발하는가](https://flex.team/blog/og/main.jpg)
실제 DB를 쓰는 통합 테스트가 dirty context로 컨테이너를 복제하며 느려지는 문제를 다루었습니다. Gradle BuildService로 컨테이너를 공유하고 모듈별 스키마를 분리하는 해법을 소개했습니다.
![[코드가 환경을 모르는 구조 6/7] 컨테이너는 왜 폭발하는가](https://cdn.sanity.io/images/v31psllp/production/84f3d9c344480bec28c26726a1ef04c0407b32cd-1684x1030.png)
MSA 로컬 개발의 병목을 줄이기 위해 Rewrite Host로 수정 중인 서비스만 노트북 인스턴스로 교체하는 방식을 소개했습니다. 디버그 헤더와 응답 피드백으로 부분 검증과 라우팅 전환을 단순화했습니다.
![[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다](https://flex.team/blog/og/main.jpg)
MSA 환경에서 전체 시스템을 띄우지 않고 수정 중인 서비스만 로컬로 교체하는 Rewrite Host를 소개했습니다. 디버그 헤더로 라우팅을 바꾸고, 응답 헤더로 적용 여부를 알려주는 방식입니다.
![[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다](https://cdn.sanity.io/images/v31psllp/production/880cbd1201bc94d8f408147dcd135aef78e683b4-1684x1030.png)
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)
배포 코드가 환경 이름을 직접 읽지 않도록 Helm values와 GitOps 규율로 분리한 구조를 설명했습니다. Jenkinsfile까지 같은 원칙을 적용해 배포 이력을 Git으로 남기는 방법을 다뤘습니다.
![[코드가 환경을 모르는 구조 2/7] 배포 코드가 환경을 모르는 구조](https://flex.team/blog/og/main.jpg)