푸른영혼의 별 | Tech Blog

---

Posts (총 336편 · 1 / 34 페이지)

• 2026-07-09

  장애 하나 를 당기니 버그 다섯 이 딸려 나왔다 — K8s·Java 운영 하루 의 시니어 회고

  “정산 이 왜 안 되지?” — 이 한 문장 으로 시작 한 하루 가, 서로 다른 버그 다섯 개 를 꿰어 놓은 체인 이었다. 프로덕션 500, 시한폭탄 테스트, Docker Hub rate limit, 유틸 컨테이너 함정, Dockerfile 드리프트. 이 글 은 그 하루 를 10년차 백엔드 시니어 의 관점 으로 복기 한다 — 무엇 을 고쳤는지 보다, 어떤 순서 로 생각 했는지 를 남기기 위해.

  #kubernetes #java #ci-cd #incident #debugging #testcontainers #gitops #senior #war-story
• 2026-07-08

  Loop Engineering 의 loop 는 cron 인가 ralph 인가 — 둘 다 아니고, *층* 이다

  요즘 화제 인 loop engineering — 그런데 이 말 의 loop 가 정확히 뭘 가리키는지 는 사람 마다 다르게 쓴다. 나 도 헷갈려서 Fable 5 에게 두 해석 을 놓고 물었고, 지금까지 본 설명 중 가장 명쾌 한 답 을 받아서 기록 으로 남긴다.

  #loop-engineering #ralph-loop #ai-agent #automation #claude #langchain #agentic-coding
• 2026-07-08

  PSA 렌즈 로 본 JPA — *표준 하나 아래, 겹겹 이 쌓인 이식성*

  Spring 의 삼대 요소 는 IoC/DI · AOP · PSA 다. 이 중 PSA(Portable Service Abstraction, 이식 가능한 서비스 추상화) 는 가장 조용히 일 하는 요소다. 그리고 우리 가 매일 쓰는 JPA 야말로, PSA 가 어떻게 겹겹이 작동 하는지 를 보여주는 최고 의 교재다.

  #jpa #psa #spring-data-jpa #hibernate #transaction #exception-translation #abstraction #orm
• 2026-07-07

  Spring 은 *하나 의 프레임워크* 가 아니다 — 생태계 지도 읽는 법

  “Spring 쓴다” 고 하면 사람 마다 다른 걸 떠올린다. 누구 는 웹 MVC, 누구 는 배치, 누구 는 Cloud Gateway. 그도 그럴 것 이 — Spring 은 하나 의 프레임워크 가 아니라 수십 개 프로젝트 의 우산 이기 때문이다. 이 글 은 아래 생태계 지도 를 어떻게 읽고, 무엇 을 언제 고르는지 를 정리 한다.

  #spring #spring-boot #spring-cloud #spring-data #spring-batch #ecosystem #architecture
• 2026-07-07

  스프링 의 서비스 추상화(PSA) — 기술 을 바꿔도 *코드* 는 그대로

  스프링 을 “DI 컨테이너” 로만 아는 사람 이 많다. 하지만 스프링 을 스프링 답게 만드는 세 다리 는 IoC/DI · AOP · PSA 다. 이 중 가장 덜 조명 되지만, 실무 에서 매일 덕 보는 게 세 번째 — PSA(Portable Service Abstraction, 이식 가능한 서비스 추상화) 다.

  #spring #psa #transaction #cache #exception-translation #abstraction #jpa #backend
• 2026-07-07

  객체지향 설계 를 그림 한 장 으로 읽기 — *책임* 과 *의존성 의 방향*

  객체지향 설계 를 “상속·다형성·캡슐화” 같은 문법 으로만 배우면, 정작 왜 그렇게 나누는지 를 놓친다. 객체지향 의 본질 은 두 가지 다 — 책임 을 어떻게 나누고, 의존성 이 어느 방향 으로 흐르게 하는가. 이 글 은 아래 그림 한 장 으로 그 두 가지 를 읽는다.

  #oop #object-oriented #solid #hexagonal #dependency-inversion #design #abstraction
• 2026-07-07

  주니어 RFC vs 시니어 RFC — 같은 기능, 다른 *문서*

  같은 기능 을 설계 했다. 파일 업로드 — POST 엔드포인트 하나, S3 저장, DB 메타, URL 반환. 코드 로 짜면 비슷 하다. 근데 RFC 는 완전히 다르다.

  #rfc #design-decision #communication #junior-vs-senior #trade-off #documentation
• 2026-07-07

  Transactional Outbox 패턴 — *DB 커밋 과 메시지 발행* 을 하나 로 묶는 법

  이벤트 기반 시스템 에는 조용한 함정 이 하나 있다. “DB 에 저장 하고, 메시지 를 발행 한다” 는 이 두 줄 이, 사실 원자적 이지 않다는 것. 이 글 은 그 함정(dual write problem) 과, 그걸 푸는 Transactional Outbox 패턴 을 내 정산 시스템 구현 과 함께 정리 한다.

  #outbox #transactional-outbox #kafka #eventual-consistency #idempotency #dual-write #msa #cdc
• 2026-07-07

  좋아 보이는데, 운영 에서 아픈 설계 6 가지 — *RFC 첫 장 에서 잡아라*

  설계 리뷰 를 하다 보면, 발표 자료 에선 멋진데 6 개월 뒤 운영 에서 피 를 흘리는 패턴 들 이 있다. 공통점 은 “만들 때 는 좋아 보이고, 운영 할 때 아프다” 는 것. 그래서 RFC 첫 장 에서 잡으면 한 분기 를 아낀다. 이 글 은 그 6 가지 를 정리 한다.

  #anti-pattern #architecture #operations #code-review #msa #observability #rollback #design-review
• 2026-07-07

  MSA 의 기준 — *쪼갤 수 있는 것* 과 *쪼개야 하는 것* 은 다르다

  “우리 도 MSA 로 가야죠.” — 이 말 은 세련 되게 들린다. 하지만 MSA 는 트로피 가 아니라 도구 다. 그리고 도구 를 필요 없을 때 꺼내면 손 을 벤다. 이 글 은 “언제 쪼개야 하는가” 를 비용 과 신호 로 고찰 한다.

  #msa #microservices #monolith #modular-monolith #architecture #bounded-context #tradeoff