Study Note

API는 한 번 배포되면 **계약(Contract)**이 됩니다. 함부로 수정하면 클라이언트가 오작동합니다. 그래서 우리는 v1, v2를 만듭니다.하지만 이 버전 정보를 어디에 두느냐에 따라 API의 사용성(DX)과 캐싱 전략, 그리고 RESTful 원칙 준수 여부가 완전히 달라집니다.1. 방식 1: URI 버저닝 (URI / Path Versioning) - "가장 실용적인 접근"트위터, 페이스북, 구글 등 대다수의 **공용 API(Public API)**가 사용하는 방식입니다. URL 경로 자체에 버전 숫자를 박아버립니다.특징직관성: URL만 봐도 몇 번째 버전인지 알 수 있습니다.리소스 분리: v1/users와 v2/users는 아예 다른 자원 취급을 받습니다.코드 예시 (Spring Boot)Ja..

"객체 A가 객체 B를 사용하려면, A가 B를 new로 생성해야 합니다."하지만 이렇게 하면 A와 B가 강하게 결합되어 테스트나 확장이 어려워집니다.이를 해결하기 위해 "외부에서 B를 만들어서 A에게 넣어주는(Inject)" 것이 **의존성 주입(DI)**입니다. 스프링에서는 @Autowired 어노테이션이 이 역할을 하는데, 이걸 어디에 붙이느냐에 따라 코드의 품질이 결정됩니다.1. 방식 1: 필드 주입 (Field Injection) - "달콤한 독사과"코드가 가장 짧고 간결해서, 예제 코드나 초보 개발자들이 가장 많이 사용하는 방식입니다. 멤버 변수(필드) 위에 바로 @Autowired를 붙입니다.코드 예시Java @Servicepublic class OrderService { // 필드에 바..

"비행기들이 서로 통신하며 착륙 순서를 정한다면 공항은 아수라장이 될 것입니다. 비행기는 오직 관제탑(Controller)하고만 교신해야 합니다."소프트웨어도 마찬가지입니다. 회원 서비스가 주문 서비스를 부르고, 주문 서비스가 다시 포인트 서비스를 부르고, 포인트가 메일을 보낸다면... 의존성이 거미줄처럼 꼬이게 됩니다(Spaghetti Code).이 복잡한 관계를 끊고 **"모든 대화는 나를 통하라"**고 정리해 주는 것이 중재자 패턴입니다. 하지만 이 중재자를 구현하는 방식은 크게 두 가지로 나뉩니다.1. 방식 1: 클래식 중재자 (Direct Reference) - "채팅방 스타일"GoF 디자인 패턴의 정석입니다. 중재자(Mediator)가 모든 참여자(Colleague)의 참조(Reference)..

"주문 버튼 하나를 눌렀을 뿐인데, 내부적으로는 재고 확인, 결제 요청, 포인트 차감, 이메일 발송, 배송 요청이 동시에 일어납니다."클라이언트(프론트엔드 또는 컨트롤러)가 이 복잡한 로직을 모두 알게 하면 결합도가 너무 높아집니다. 이를 해결하기 위해 건물의 정면(Facade) 처럼 복잡한 내부를 가리고 **"통합된 인터페이스 하나만 제공"**하는 것이 퍼사드 패턴입니다.하지만 이를 구현할 때, 자바 개발자는 Static Method의 유혹과 Spring Bean의 정석 사이에서 고민하게 됩니다. 1. 방식 1: 정적 퍼사드 (Static Helper) - "간편함"흔히 ~Util, ~Helper라는 이름으로 만드는 방식입니다. 객체 생성 없이 어디서든 호출할 수 있어 편리하지만, 객체지향적인 관점에서..

"상태가 변할 때마다, 관련된 다른 객체들에게 알려줘야 한다."이 요구사항을 해결하기 위해 우리는 **옵저버 패턴(Observer Pattern)**을 사용합니다. 유튜브의 '구독 알림'이나 엑셀의 '수식 자동 계산'이 대표적입니다.하지만 면접이나 실무 아키텍처 회의에서 "옵저버 패턴과 Pub/Sub 패턴의 차이가 뭔가요?"라는 질문을 받으면 말문이 막히는 경우가 많습니다. 오늘은 이 두 가지 방식의 결정적인 차이와, 실무(Spring)에서의 적용법을 정리해 봅니다.1. 고전적 옵저버 패턴 (Classic Observer) - "직거래"GoF 디자인 패턴에서 정의하는 원형입니다. 주체(Subject)와 관찰자(Observer)가 서로를 인지하고 직접 소통합니다.구조Subject (주체): 이벤트를 발생시..

개발자 블로그에 바로 발행하실 수 있도록, 기본(GoF) 방식부터 실무 최적화(Smart/Map) 방식까지 완벽하게 정리한 통합본입니다.복사해서 사용하기 편하도록 마크다운 포맷으로 작성했습니다.[디자인패턴] 전략 패턴(Strategy Pattern) 완벽 정리: if-else 지옥에서 탈출하는 4가지 방법개발을 하다 보면 비즈니스 로직이 복잡해질수록 if-else나 switch 문이 끝도 없이 길어지는 경험을 하게 됩니다.Java// 이런 코드가 보인다면 리팩토링이 필요합니다.if (type.equals("KAKAO")) { // 카카오 결제 로직...} else if (type.equals("NAVER")) { // 네이버 결제 로직...} else if (type.equals("TOSS")..

마이크로서비스 환경에서는 Kafka를 이용한 비동기 이벤트 처리 패턴이 널리 사용됩니다. 그런데 하나의 이벤트로 여러 비즈니스 로직을 수행해야 할 때가 있습니다. 예를 들어 "회원가입" 이벤트가 발생했을 때:환영 이메일을 전송하고,가입 통계를 갱신하며,외부 마케팅 시스템과 연동해야 할 수 있습니다.그렇다면 이런 액션 수만큼 Kafka 토픽을 별도로 발행해야 할까요? 정답은 **"필수는 아니다"**입니다.1. 기본 설계 원칙단일 토픽 + 멀티 컨슈머: 하나의 토픽에 여러 컨슈머 그룹을 붙여서 각자 다른 액션을 수행하게 할 수 있습니다.액션별 토픽 분리: 액션마다 다른 서비스나 팀이 관리한다면, 각 액션별로 별도의 토픽을 두는 것이 운영상 유리할 수 있습니다.이벤트 내용이 포괄적일수록 하나의 토픽, 세분화될..