푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 333편 · 1 / 34 페이지)
-
Spring 은 *하나 의 프레임워크* 가 아니다 — 생태계 지도 읽는 법
“Spring 쓴다” 고 하면 사람 마다 다른 걸 떠올린다. 누구 는 웹 MVC, 누구 는 배치, 누구 는 Cloud Gateway. 그도 그럴 것 이 — Spring 은 하나 의 프레임워크 가 아니라 수십 개 프로젝트 의 우산 이기 때문이다. 이 글 은 아래 생태계 지도 를 어떻게 읽고, 무엇 을 언제 고르는지 를 정리 한다.
-
스프링 의 서비스 추상화(PSA) — 기술 을 바꿔도 *코드* 는 그대로
스프링 을 “DI 컨테이너” 로만 아는 사람 이 많다. 하지만 스프링 을 스프링 답게 만드는 세 다리 는 IoC/DI · AOP · PSA 다. 이 중 가장 덜 조명 되지만, 실무 에서 매일 덕 보는 게 세 번째 — PSA(Portable Service Abstraction, 이식 가능한 서비스 추상화) 다.
-
객체지향 설계 를 그림 한 장 으로 읽기 — *책임* 과 *의존성 의 방향*
객체지향 설계 를 “상속·다형성·캡슐화” 같은 문법 으로만 배우면, 정작 왜 그렇게 나누는지 를 놓친다. 객체지향 의 본질 은 두 가지 다 — 책임 을 어떻게 나누고, 의존성 이 어느 방향 으로 흐르게 하는가. 이 글 은 아래 그림 한 장 으로 그 두 가지 를 읽는다.
-
주니어 RFC vs 시니어 RFC — 같은 기능, 다른 *문서*
같은 기능 을 설계 했다. 파일 업로드 — POST 엔드포인트 하나, S3 저장, DB 메타, URL 반환. 코드 로 짜면 비슷 하다. 근데 RFC 는 완전히 다르다.
-
Transactional Outbox 패턴 — *DB 커밋 과 메시지 발행* 을 하나 로 묶는 법
이벤트 기반 시스템 에는 조용한 함정 이 하나 있다. “DB 에 저장 하고, 메시지 를 발행 한다” 는 이 두 줄 이, 사실 원자적 이지 않다는 것. 이 글 은 그 함정(dual write problem) 과, 그걸 푸는 Transactional Outbox 패턴 을 내 정산 시스템 구현 과 함께 정리 한다.
-
좋아 보이는데, 운영 에서 아픈 설계 6 가지 — *RFC 첫 장 에서 잡아라*
설계 리뷰 를 하다 보면, 발표 자료 에선 멋진데 6 개월 뒤 운영 에서 피 를 흘리는 패턴 들 이 있다. 공통점 은 “만들 때 는 좋아 보이고, 운영 할 때 아프다” 는 것. 그래서 RFC 첫 장 에서 잡으면 한 분기 를 아낀다. 이 글 은 그 6 가지 를 정리 한다.
-
MSA 의 기준 — *쪼갤 수 있는 것* 과 *쪼개야 하는 것* 은 다르다
“우리 도 MSA 로 가야죠.” — 이 말 은 세련 되게 들린다. 하지만 MSA 는 트로피 가 아니라 도구 다. 그리고 도구 를 필요 없을 때 꺼내면 손 을 벤다. 이 글 은 “언제 쪼개야 하는가” 를 비용 과 신호 로 고찰 한다.
-
기술 도입비용 을 매출 로 환산 하기 — 비동기 인프라 5개 질문
-
RFC 템플릿 — 설계 결정 을 한 장 에 담는 법
좋은 설계 결정 은 이유 없이 가파르게 난다. 최종 결정 을 보면 “왜 이거?” 라는 질문 이 따라붙는데, 그 이유 를 설명 하려면 결정 과정 전체 를 다시 풀어야 한다. RFC(Request For Comments) 는 이 과정 을 한 장 으로 압축 해서, 결정 을 재현 가능 하게 하는 템플릿 이다.
-
백엔드 설계 의 세 축 — *성능↔복잡도 · 결합도↔일관성 · 가역성↔속도*
백엔드 설계 에 정답 은 거의 없다. 있는 건 트레이드오프 다. “이게 맞나요?” 의 답 은 대부분 “무엇 을 포기 할 건데요?” 로 되물어야 한다. 이 글 은 백엔드 설계 결정 을 세 개 의 축 으로 압축 해서, 각 축 을 실제 시스템 사례 로 풀어본다.