Velopers
모든 블로그
flex

flex

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

활동 요약

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

최신 게시글 (20)

백엔드

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

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

#Kafka#CDC#Outbox
1900

기타

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

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

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

백엔드

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

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

#Liquibase#Testcontainers#Gradle
3400

기타

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

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

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

데브옵스

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

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

#GitOps#ArgoCD#Helm
17100

아키텍처

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

폴리레포에서 버전 관리 자동화를 가능하게 한 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
1300

데브옵스

[의존성의 방향을 따라 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
4000

아키텍처

[의존성의 방향을 따라 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

아키텍처

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

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

#Spring Boot#Kotlin#MySQL
4400

AI

[AI가 읽을 수 있는 코드베이스 5/5] AI 접근성 등급으로 보는 코드베이스

코드 품질이 높아도 AI 접근성은 낮을 수 있다고 설명했습니다. 빌드 가드레일과 모듈 경계, 패턴 일관성이 AI 친화적 코드베이스를 만든다고 정리했습니다.

#code quality#CI/CD#build
600