푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1471편 · 115 / 148 페이지)
-
객체지향 설계 를 그림 한 장 으로 읽기 — *책임* 과 *의존성 의 방향*
객체지향 설계 를 “상속·다형성·캡슐화” 같은 문법 으로만 배우면, 정작 왜 그렇게 나누는지 를 놓친다. 객체지향 의 본질 은 두 가지 다 — 책임 을 어떻게 나누고, 의존성 이 어느 방향 으로 흐르게 하는가. 이 글 은 아래 그림 한 장 으로 그 두 가지 를 읽는다.
-
주니어 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) 는 이 과정 을 한 장 으로 압축 해서, 결정 을 재현 가능 하게 하는 템플릿 이다.
-
백엔드 설계 의 세 축 — *성능↔복잡도 · 결합도↔일관성 · 가역성↔속도*
백엔드 설계 에 정답 은 거의 없다. 있는 건 트레이드오프 다. “이게 맞나요?” 의 답 은 대부분 “무엇 을 포기 할 건데요?” 로 되물어야 한다. 이 글 은 백엔드 설계 결정 을 세 개 의 축 으로 압축 해서, 각 축 을 실제 시스템 사례 로 풀어본다.
-
에러 를 묻기 전 에 — 질문 보내기 전 다시 보는 10가지
-
금요일 10 분, 학습 일지 — *미래 의 나* 에게 보내는 검색 가능한 메모
지난 글 의지 vs 루틴 에서 90/20/10 루틴 의 마지막 칸, 주 10 분 복기 를 “곱셈기” 라고 불렀다. 이 글 은 바로 그 10 분 — 금요일 학습 일지 — 하나 만 깊게 판다. 작아 보이지만, 1 년 의 학습 을 남길지 흘려보낼지 가 여기서 갈리기 때문이다.