flex

"다 됐습니다" 알림, 대체 언제 보내야 맞나

배치 완료 알림이 너무 일찍 나가는 문제를 해결한 사례를 다루셨습니다. 처리 순간의 사실을 기록하고 실제 조회 가능 시점을 기준으로 완료를 판정하셨습니다.

#batch#비동기#cache

2800

2026년 9월 15일

#Spring Boot#transaction#event

@TransactionalEventListener는 왜 조용히 무시될까

`@TransactionalEventListener`는 커밋 이후 실행이 아니라 트랜잭션이 있을 때만 등록됩니다. 트랜잭션 밖 발행 누락은 `fallbackExecution`과 발행 지점의 트랜잭션 검사를 성격에 맞게 선택해야 합니다.

7200

2026년 9월 8일

격리 안 된 테스트의 초록불은, 에이전트가 믿을 수 없습니다

AI 에이전트가 스스로 수정하려면 먼저 테스트 결과를 믿을 수 있어야 했습니다. 그래서 테스트 격리와 실행 경로 통일로 오염과 환경 차이를 줄였습니다.

#test#격리#CI/CD

3200

2026년 9월 1일

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

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

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

5200

2026년 8월 25일

#Spring Boot#Kubernetes#Redis

@Scheduled 한 줄로 버티다, 트리거를 밖으로 꺼낸 이야기

@Scheduled 기반 배치가 Pod 확장 시 중복 실행과 유실 문제를 드러내자, 트리거를 애플리케이션 밖으로 분리했습니다. 실행은 선점과 체크포인트로 나눠 맡겨 여러 Pod가 작업을 분담하도록 전환했습니다.

7400

2026년 8월 18일

사람도 에이전트도, 덜 읽을수록 더 잘 고칩니다

도메인별 모듈 경계가 에이전트의 탐색 범위를 줄여 덜 읽고 더 잘 고치게 하는 사례를 소개했습니다. 로그 분석과 연구 결과를 통해 컨텍스트 효율의 중요성을 설명했습니다.

#Kotlin#AI 에이전트#module

6000

2026년 8월 11일

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

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

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

3700

2026년 8월 4일

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

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

#Gradle#멀티모듈#refactoring

3000

2026년 7월 30일

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

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

#Kafka#CDC#Outbox

4600

2026년 7월 27일

기타

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

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

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

5900

2026년 7월 23일

#Liquibase#Testcontainers#Gradle

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

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

4200

2026년 7월 20일

기타

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

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

#Platform Engineer#SDK#배포 자동화

4100

2026년 7월 16일

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

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

#GitOps#ArgoCD#Helm

17700

2026년 7월 9일

#Gradle#pol리레포#versioning

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

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

14800

2026년 7월 9일

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

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

#AWS#Kubernetes#CI/CD

2600

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

2026년 7월 6일

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

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

#Terraform#Pulumi#Kotlin

2400

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

2026년 7월 2일

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

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

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

#ArgoCD#Kubernetes#Git

13100

2026년 6월 29일

#Terraform#YAML#JSON Schema

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

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

1000

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

2026년 6월 24일