Velopers
모든 블로그
flex

flex

도메인flex.team
주요 카테고리 아키텍처 · AI · DevOps

활동 요약

대표 인기 포스트[미래를 담아낸 뼈대 5/7] 코드가 환경을 모르는 구조454 조회
최근 30일
3개
평균 조회
56
누적 조회
4,626
전체 글
83개
마지막 발행
2026. 11. 5.
블로그 방문

flex 기술 블로그 글 (38)

아키텍처

QA 팀이 아니라 Quality Platform 팀을 만든 이유

AI 에이전트로 늘어난 코드 변경에 맞춰 QA 외주화 구조를 Quality Platform 방식으로 전환했습니다. 개발자가 테스트·데이터·회귀 검증 도구로 품질과 성능을 직접 확인하도록 지원합니다.

#Spring Boot#CI/CD#test
5600

아키텍처

코딩 에이전트가 Spring을 못 짠다면, component scan부터 걷어내 보세요

component scan으로 테스트 설정이 자동 등록돼 발생한 빈 충돌을 분석했습니다. 명시적 빈 등록과 컨텍스트 검증으로 에이전트 작업의 예측 가능성을 높였습니다.

#Spring Boot#Kotlin#component scan
5200

아키텍처

설정값에서 OpenFeature까지, 피처 플래그는 어떻게 바뀌어 왔을까요

피처 플래그가 설정값에서 용도별 관리와 OpenFeature 표준 API로 발전한 과정을 정리했습니다. 배포·공개 분리의 장점과 오래된 플래그, 배포 누락을 관리하는 방법을 설명합니다.

#OpenFeature#OFREP#피처 플래그
1900

아키텍처

모놀리식인데, 도메인 하나만 따로 띄웁니다

모듈러 모놀리식에서 이슈 도메인만 따로 기동하는 standalone 구조를 소개했습니다. 빌드 조립과 트랜잭션 경계 분리를 통해 빠른 검증 환경을 만드는 방법을 설명했습니다.

#모듈러 모놀리식#MSA#Spring Boot
5700

아키텍처

헥사고날 아키텍처, Adapter만 바꾸면 될까

AWS S3에서 다른 오브젝트 스토리지로 이전하며, Adapter 교체가 성립하려면 어떤 전제가 필요한지 확인했습니다. 헥사고날 아키텍처는 애플리케이션 코드를 지켜주지만 인프라와 데이터 이전은 별도로 대응해야 했습니다.

#헥사고날 아키텍처#AWS S3#오브젝트 스토리지
4000

아키텍처

경계를 빌드로 못 박으면, 경계를 옮기는 일도 빌드가 붙잡습니다

Gradle 멀티모듈로 경계를 강하게 고정하면 잘못된 의존은 막을 수 있지만, 경계를 옮기는 비용도 커졌습니다. 그래서 함께 바뀌는 리듬을 기준으로 모듈 경계를 다시 설계하는 방법을 정리했습니다.

#Gradle#멀티모듈#refactoring
3400

아키텍처

되도록 최신 버전을 사용하는게 왜 이렇게 어려울까?

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

#Gradle#pol리레포#versioning
15000

아키텍처

[인프라를 소프트웨어처럼 5/5] 다섯 축의 운영 총합, 그리고 AI 시대의 플랫폼팀

여섯 축의 공통 원리를 하나의 표로 정리하며 인프라를 소프트웨어처럼 다루는 관점을 설명했습니다. 사람과 AI 에이전트가 안전하게 변경하고 되돌릴 수 있는 피드백 루프의 중요성을 강조했습니다.

#AWS#Kubernetes#CI/CD
3000

아키텍처

[의존성의 방향을 따라 5/5] Evergreen이 가능했던 이유

Evergreen 자동화가 가능했던 구조적 전제를 Convention Plugin과 구조적 일관성 관점에서 정리했습니다. 대규모 변경 전파가 왜 일관된 빌드·CI 구조 위에서만 성립하는지 설명했습니다.

#Spring Boot#Gradle#Kotlin
2300

아키텍처

[의존성의 방향을 따라 2/5] 의존 그래프를 읽는 Planner

레포 간 의존성을 그래프로 복원해 변경 전파 순서를 자동 계산하는 Planner를 설명했습니다. 또한 Kotlin과 Spring Boot처럼 변경 유형에 따라 upstream-first와 downstream-first를 구분하는 방법을 정리했습니다.

#Gradle#Kotlin#Spring Boot
1900

아키텍처

[의존성의 방향을 따라 1/5] 버전업이 고통인 이유

50개 레포와 3,500개 모듈에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제인지 설명했습니다. 수동 전파의 한계를 보여주고, 자동화된 recipe 기반 구조를 제안했습니다.

#Spring Boot#MySQL#Kotlin
14000

아키텍처

[의존성의 방향을 따라 1/5] 버전업이 고통인 이유

50개 레포와 3,500개 모듈 환경에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제가 되는지 설명했습니다. 수동 전파의 병목을 줄이기 위해 자동화와 빌드 검증 중심의 Evergreen 구조를 제안했습니다.

#Spring Boot#Kotlin#MySQL
5400

아키텍처

[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행

Issue 도메인을 독립 실행 가능한 standalone-app으로 조립해 핵심 로직만 빠르게 검증하는 구조를 소개했습니다. 프로덕션 Adapter만 교체하고 시드 데이터, Swagger, React 프론트엔드를 묶어 AI 협업 검증 환경을 만들었습니다.

#Hexagonal Architecture#Spring Boot#React
1200

아키텍처

[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행

Hexagonal Architecture로 Issue 도메인을 standalone-app으로 독립 실행해 핵심 비즈니스 로직만 검증하는 구조를 소개했습니다. AI 에이전트의 빠른 피드백 루프와 격리된 검증 환경을 만드는 방법을 설명했습니다.

#Hexagonal Architecture#Kotlin#Spring Boot
4000

아키텍처

[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합

테스트 인프라를 프로덕션 구조에 맞춰 variant와 스냅샷 캐시로 분리·재사용하는 방법을 정리했습니다. 경계를 깎아 교체 가능성을 만들면 CI와 개발 이터레이션이 함께 빨라졌습니다.

#MySQL#Kafka#Elasticsearch
13600

아키텍처

[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다

MSA 로컬 개발의 병목을 줄이기 위해 Rewrite Host로 수정 중인 서비스만 노트북 인스턴스로 교체하는 방식을 소개했습니다. 디버그 헤더와 응답 피드백으로 부분 검증과 라우팅 전환을 단순화했습니다.

#MSA#Spring Cloud Gateway#Service Discovery
1500

아키텍처

[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다

MSA 환경에서 전체 시스템을 띄우지 않고 수정 중인 서비스만 로컬로 교체하는 Rewrite Host를 소개했습니다. 디버그 헤더로 라우팅을 바꾸고, 응답 헤더로 적용 여부를 알려주는 방식입니다.

#MSA#Spring Cloud Gateway#Redis
3800

아키텍처

[코드가 환경을 모르는 구조 4/7] 타임머신 — 시간 축을 교체한다

HR SaaS에서 시간을 비즈니스 입력으로 보고, 요청 헤더와 `Clock` Adapter로 현재 시점을 교체하는 타임머신 구조를 설명했습니다. 비동기 경계 전파와 환경별 활성화, 서드파티 시계 호출의 한계도 함께 다뤘습니다.

#헥사고날 아키텍처#Spring Boot#Kotlin
1600