Velopers
모든 블로그
flex

flex

도메인flex.team
주요 카테고리 Architecture · AI · DevOps

활동 요약

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

최신 게시글 (20)

아키텍처

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

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

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

아키텍처

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

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

#Gradle#멀티모듈#refactoring
2300

백엔드

사람은 떠났는데 권한은 남았다

관계 원천과 인가 튜플을 Outbox·CDC·Kafka로 동기화해 잔존 권한 문제를 줄이는 구성을 다뤘습니다. 부분 실패, 캐시, 감사 이력까지 함께 고려한 운영 포인트도 정리했습니다.

#Kafka#CDC#Outbox
3800

기타

AI가 하한선을 올린 순간, 저희는 직무를 다시 그리기로 했습니다

AI로 직무 경계가 낮아진 상황에서 FE·BE 통합 실험을 통해 프로덕트 엔지니어 역할을 재정의하려고 했습니다.교차 온보딩, 페어링, 회고로 가능성과 한계를 점검하며 기술이 제품의 경계를 막지 않게 하려 했습니다.

#FE#BE#프로덕트 엔지니어
5400

백엔드

DDL이 코드 밖에서 온다면, 테스트 DB 구성을 빌드 안에 선언한다

Liquibase 기반 스키마를 테스트에서 다루기 위해, 테스트 DB 구성을 빌드의 variant로 선언하는 구조를 정리했습니다. 실제 마이그레이션 검증과 덤프 캐시를 함께 써서 정확성과 속도를 모두 확보했습니다.

#Liquibase#Testcontainers#Gradle
3800

기타

제품을 만드는 시스템을 만드는 사람

Platform Engineer를 제품 개발을 받치는 시스템 설계자로 설명하며, 표준화와 자동화로 조직의 기준선을 높이는 역할을 강조했습니다. 추상화, 안전, 확산 가능성을 함께 판단하는 역량을 중요하게 보았습니다.

#Platform Engineer#SDK#배포 자동화
3900

데브옵스

GitOps 하시면서, 배포 전에 뭐가 바뀔지 알고 계신가요

GitOps에서 PR 단계에 배포 결과 diff를 미리 보여주는 방법을 소개했습니다. 또한 Helm 렌더와 values 출처 추적으로 리뷰 화면에서 변경 영향을 바로 확인하도록 했습니다.

#GitOps#ArgoCD#Helm
17300

아키텍처

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

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

#Gradle#pol리레포#versioning
14400

아키텍처

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

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

#AWS#Kubernetes#CI/CD
2100

데브옵스

[인프라를 소프트웨어처럼 4/5] plan은 동작을 모른다: 인프라를 테스트·재현한다는 것

terraform plan만으로는 인프라의 실제 동작을 확인할 수 없다는 문제를 다뤘습니다. 로컬 클러스터 검증과 재현 가능한 선언으로 apply 전 신뢰도를 높이는 방법을 소개했습니다.

#Terraform#Pulumi#Kotlin
2100

데브옵스

[인프라를 소프트웨어처럼 3/5] 환경은 브랜치에서 태어난다: Environment Variant

공유 dev 병목을 없애기 위해 브랜치 하나로 격리 환경을 만드는 Environment Variant 설계를 소개했습니다. ArgoCD ApplicationSet으로 생성과 회수를 자동화해 환경 생명주기를 git과 연결했습니다.

#ArgoCD#Kubernetes#Git
13000

데브옵스

[인프라를 소프트웨어처럼 2/5] 코드가 모르는 그 '환경'은 누가 만드는가

플랫폼팀이 코드 바깥의 환경 실체를 선언으로 만드는 방식을 설명했습니다. Kafka 토픽 선언과 검증, 추적 가능한 거버넌스 사례를 다뤘습니다.

#Terraform#YAML#JSON Schema
800

데브옵스

[인프라를 소프트웨어처럼 1/5] Infrastructure as Code, 그리고 그다음

Terraform plan은 변경점만 보여 주고 실제 동작은 보장하지 못한다고 설명했습니다. IaC를 넘어 테스트 가능성과 재현 가능성을 갖춘 IaS 관점이 필요하다고 강조했습니다.

#Terraform#IaC#cloud
1800

아키텍처

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

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

#Spring Boot#Gradle#Kotlin
1400

데브옵스

[의존성의 방향을 따라 4/5] PR을 전파하는 Distributer

50개 이상의 레포에 흩어진 버전업 PR을 Wave 순서에 맞춰 자동 전파하고 머지하는 방식을 설명했습니다. CI, flaky test, 에스컬레이션까지 묶어 대규모 업그레이드 운영을 자동화했습니다.

#Spring Boot#Claude#CI/CD
2100

AI

[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다

OpenRewrite로 규칙 기반 변환을 먼저 적용하고, 실패한 빌드는 Claude가 보완했습니다. 빌드 가드레일 안에서 50개 레포를 안전하게 버전업하는 구조를 설명했습니다.

#OpenRewrite#Claude#AST
1300

AI

[의존성의 방향을 따라 3/5] OpenRewrite와 Claude가 코드를 변환한다

OpenRewrite로 규칙 기반 변환을 먼저 적용하고, Claude가 예외적 수정과 빌드 에러를 보완하는 구조를 설명했습니다. 50개 레포에 안전하게 같은 변환을 재현하기 위한 recipe 설계와 가드레일 운영 방식도 다뤘습니다.

#OpenRewrite#Claude#AST
4100

아키텍처

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

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

#Gradle#Kotlin#Spring Boot
900

백엔드

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

레포 간 의존성을 그래프로 읽어 안전한 변경 순서와 전파 방향을 계산하는 Planner를 설명했습니다. 변경 유형에 따라 upstream-first, downstream-first, 병렬 계획이 달라지는 점을 다뤘습니다.

#Spring Boot#Kotlin#Gradle
14200

아키텍처

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

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

#Spring Boot#MySQL#Kotlin
13000