외부 툴 변경에 휘둘리지 않는 서버 코드 작성기

Context

강남언니는 Braze라는 외부 마케팅 자동화 도구를 도입하면서, Braze의 업데이트 필드 수 비례 과금 정책으로 인한 비용 최소화와 향후 다른 툴로의 전환 가능성에 대응해야 했다. 구서버(레거시)와 신서버 2개의 API 서버에서 운영되는 환경에서 새로운 도구 연동이 기존 도메인 모델에 영향을 미치는 문제를 해결해야 했다.

Technical Solution

• Design V1: 구서버에서 Internal Event 발행 → AWS SNS로 메시지 전달 → SQS 적재 → 신서버 Listener가 수신해 Braze API 호출 (필드별 SQS 분리로 비용 최소화 시도)
• Design V2: 단일 SQS로 통합하고, 신서버의 Logic 레이어에서 실제 변경 필드만 구별해 Braze에 동기화 (구서버에서 Braze 컨텍스트 제거)
• Design V3: Dependency Inversion Principle 적용으로 MemberConsentLogic이 BrazeMemberConsentNotifier 구현체 대신 MemberConsentNotifier 추상 인터페이스에 의존하도록 재설계
• 모듈 세분화: 외부 인터페이스(SQS Listener) → api module, 필드 변경 감지 로직 → logic module, Braze 통신 → braze module로 역할 분리
• 추상화 계층 도입: 마케팅 자동화 도구 변경 시 logic module은 수정 불필요하고 braze module만 다른 구현체로 교체 가능하도록 설계

Key Takeaway

외부 도구 도입 시 도구 특화 로직(가격 정책, API 명세)이 내부 도메인 코드에 침투하지 않도록 추상 인터페이스를 중간에 두는 것이, 향후 도구 변경이나 요구사항 변경에 대응하는 지속 가능한 구조를 만드는 핵심이다. 다만 변경 가능성이 낮은 의존 관계에 DIP를 적용하는 것은 오버 엔지니어링이므로 변경 시나리오가 실제로 존재할 때만 적용해야 한다.