카드 정지는 성공했는데, 고객에게 알림이 안 갔다고요? – MSA 환경의 설계 딜레마

 

나무위키 - 딜레마

---

금융 시스템에서 알림 발송 실패 시 어떻게 해야 할까?

금융권 시스템에서 카드 분실 및 정지 프로세스처럼 고객에게 필수 알림을 전달하는 상황이 있습니다.

최근 카드 결제 시스템을 설계하며 흥미로운 고민을 마주하게 되었는데요.

카드 도난 분실 신고 및 카드 정지 또는 해제와 같은 프로세스는 고객 보호와 금융 사고 예방을 위해 필수적으로 빠르게 처리되어야 하는 업무입니다.

또한, 고객에게 처리 결과에 대한 알림이 발송되지 않으면 금융 감독원 민원 등 중요한 규제 이슈로 이어질 수 있기에 알림의 중요성이 높습니다.

그런데 알림 발송을 처리하는 UMS는 별도의 시스템으로, 발송 성공을 항상 보장하지는 않습니다.

이럴 때 메시지 발송 실패가 메인 비즈니스 처리에도 영향을 줘야 하는지 고민하게 됩니다.

(ex. 중요한 알림이 발송 실패하면 비즈니스도 실패하게 할 것인가?)

---

왜 카드 정지 알림이 중요한 걸까?

카드 분실이나 도난 시, 고객은 매우 불안한 상황에 처합니다. 이때 카드가 즉시 정지되었다는 알림 메시지를 받으면 고객은 안심할 수 있죠.

만약 알림을 받지 못했다면 고객은 실제 카드가 제대로 정지되었는지 의심하게 되고, 결국 불안감 때문에 고객센터로 직접 전화하거나 민원을 제기할 가능성이 있습니다.

최악의 경우, 금융감독원 민원으로까지 이어져 회사 차원에서 부담이 되는 상황도 생길 수 있죠.

그렇기 때문에 금융권에서는 고객 알림을 단순한 안내 메시지가 아니라 고객과의 신뢰 및 규제 기관 대응이라는 중요한 문제로 바라봅니다.

---

메시지 발송 실패를 시스템 처리 실패로 봐야 할까?

실무를 하다 보면 이런 고민이 꽤 자주 발생합니다.

위에서 설명한 이유처럼 고객에게 메시지가 전달되는 것은 중요하기에 비즈니스가 실패했다고 봐야 하는 입장도 있죠.

반대로, 핵심 업무의 중요성을 고려하면 알림 발송 실패 때문에 카드 정지 처리 자체가 실패해서는 안 된다는 의견이 대다수일겁니다.

만약 메시지 발송 시스템 장애로 인해 카드가 즉시 정지되지 않으면, 훨씬 더 심각한 피해가 발생할 수 있기 때문이죠.

 

실제로 카드 도난 사고가 발생한 상황에서 메시지 발송 실패로 정지가 되지 않으면 고객의 피해뿐 아니라, 회사에 매우 큰 법적, 재정적 책임 문제로 돌아올 수 있습니다.

즉, 알림 발송 실패로 정지 프로세스 자체를 실패로 처리하는 로직은 오히려 더 큰 문제를 발생시킬 위험이 크죠.

 

이 문제는 결국, 업무 로직과 부가 로직의 결합도를 어떻게 관리해야 하는지에 대한 본질적인 문제로 바라볼 수 있습니다.

---

의견 충돌 사례

UMS 발송 관련 로직은 모든 클라이언트에서 필요한 부분이기에 공통 라이브러리에서 관리하고 있습니다.

그래서 이 주제로 공통 라이브러리(유틸 클래스)를 관리하는 두 동료의 견해 차이가 뚜렷했고 두 의견에 모두 공감되어 정말 난처했었습니다.

 

동료A

• 금융 시스템은 메시지 발송 실패 상황을 대비해야 한다
• 재발송 로직을 마련하고, 필요시 수동 발송까지 가능한 백오피스도 필요하다
• 금융감독원 민원 발생 시 소명 가능한 자료가 필요하기에 재처리를 했다는 것을 남겨두는 것이 중요하다

동료B

• 이 요구사항은 서비스마다 중요도가 달라 마이너한 문제다
• 발송 재시도 여부나 허용 지연 시간이 비즈니스마다 다르기 때문에 공통 라이브러리에 구현하면 복잡성이 증가한다(이미 너무 많은 것들을 공통화했기에 좀 더 신중해져야 한다)
• 모든 상황을 커버하기 위해 공통 유틸로 관리하면, 설정과 관리 비용이 지나치게 높아질 수 있다
• 알림 발송에 실패하면 실패한대로 두고 대응하면 된다

두 가지 입장 모두 현실적이고 합리적이라고 느꼈습니다.

 

먼저 동료A가 말한 내용은 현실적인 금융 시스템의 상황과 매우 밀접한 의견이었는데요.

금융 산업은 안정성과 신뢰성은 물론이고, 특히 규제기관(금융감독원) 대응이라는 비즈니스적인 문제까지 고려해야 하기에 재발송 로직과 백오피스를 준비해야 한다는 주장이 설득력 있다고 느꼈습니다.

 

반면 동료B가 말한 부분도 공감이 됐습니다. 공통 유틸이 너무 많은 부분까지 공통화하거나 지나치게 복잡해지면 결국 서비스마다 불필요한 옵션까지 고민하게 되는 오버헤드를 유발할 수 있으니까요.

실제로 모든 서비스를 하나의 공통 규격으로 해결하기 어렵고, 서비스마다 민감도와 긴급성이 다르기 때문에 공통화된 접근이 지나치게 복잡성을 높일 수도 있지요.

 

제 생각은, 업무 로직과 부가 로직을 철저히 분리하되, 최소한의 공통 대응을 가능하게 하는 구조로 결론 내는 게 가장 현실적이고 이상적인 설계라고 생각이 들었고 결국 이 문제는 기술적 설계 문제일 뿐만 아니라, 금융권 특유의 비즈니스 리스크 관리 측면에서도 중요하게 다뤄야 하는 이슈라는 생각도 들었습니다.

---

기존의 공통 유틸 상황과 현실적인 고민

현재 사용하고 있는 공통 유틸인 UmsSendUtil.send() 메서드는 메시지 발송을 1회만 간편하게 처리할 수 있게 제공하고 있습니다.

발송에 실패하면 클라이언트에서 간단한 예외 처리만 할 수 있도록 CheckedException을 구현하게 해두었어요.

만약 재처리까지 공통으로 지원하려면 복잡성이 크게 증가하게 되죠.

// 기존 공통 유틸 사용법
public void doSomething() {
  try {
    UmsSendUtil.send(message);
  } catch (UmsException e) {
    // 실패 시, 예외 처리
  }
}

 

만약, 재처리 옵션을 공통 유틸에서 제공해 준다면 아래와 같이 바뀔 수 있겠네요.

public void doSomething() {
  // 개선된 옵션 제공 예시
  UmsSendOptions options = UmsSendOptions.builder()
    .retryEnabled(true)             // 자동 재발송 여부
    .maxRetryCount(3)               // 최대 재발송 횟수
    .retryInterval(Duration.ofMinutes(1)) // 재발송 간격
    .alertOnFinalFailure(true)      // 최종 실패 시 담당자 알림
    .businessCritical(true)         // 업무 긴급성 설정
    .build();

  UmsSendUtil.send(message, options);
}

 

이렇게 옵션을 제공하면, 각 마이크로서비스(클라이언트)에서는 자신들의 업무 성격과 상황에 맞게 알림 발송 로직을 유연하게 선택할 수 있습니다.

하지만 동시에, 이러한 옵션 제공으로 인해 서비스별로 알림 발송 실패에 대한 고민의 폭이 더 넓어질 수도 있습니다.

이러한 고민들 말이죠.

• 재처리가 필요한 비즈니스인가?
• 몇 번 재시도할까?
• 수동 처리는 누가, 언제 하지?
• 재시도하게 되면 지연 발송이 될 수 있을 텐데, 지연발송 되어도 괜찮은가?

---

재처리 로직이 쉽지 않은 이유

동료B의 부담도 쉽게 공감할 수 있었던 이유가, UMS 발송 실패 시 재처리 기능은 간단해 보이지만, 실제로 아키텍처적으로는 생각보다 쉽지 않은 문제이기 때문입니다.

재발송 기능을 구현할 때 반드시 고민해야 하는 복잡성이 존재합니다.

 

가령, 재발송 기능을 구현하려면 어떤 방식으로든 메시지를 다시 처리할 수 있는 메커니즘이 필요합니다. 단순히 메소드 호출을 반복하면 자칫 시스템 부하나 장애 확산 위험도 생기기에, 보통은 메시지 큐나 이벤트 드리븐을 하게 됩니다.

 

하지만 아래와 같은 고민을 필수적으로 거쳐야만 합니다.

• 원자성을 보장하려면 어떻게 해야 할까?
• 이벤트가 유실되지 않게 하는 방법은 뭐가 있을까?
• 재처리를 시도하다가 장애가 발생하면 해당 이벤트는 어디다 쌓아야 할까?

그래서 아웃박스 패턴도 사용해 볼 것이고, 에러 로깅이나 담당자가 즉각 대응할 수 있도록 알림 프로세스도 설계해야 하죠.

이러한 기술적이고 아키텍처적인 운영적인 고민들이 동반되기에, 재처리 기능은 단순히 "옵션 하나 추가"의 문제가 아니라 시스템의 복잡성 증가로 이어질 수 있다는 점을 분명히 인지해야 합니다.

 

(주된 주제는 아니기에 여기서는 짧게 설명했지만 하나하나 규모가 큰 것들이죠..)

---

제 생각은요

지금까지 이야기를 기술적 관점으로만 좁혀서 바라보면, 발송 실패 시의 재처리, 장애 대응과 같은 기술적인 접근에만 머무를 수 있습니다.

하지만 좀 더 넓은 시각에서 바라보면 기술적 고려 이전에 더 중요한 아래의 질문들을 던져야 합니다.

 

이 알림 발송 재처리 기능이 과연 우리 비즈니스에 정말로 중요한가?

 

왜냐면 각 마이크로서비스마다 제공하는 업무의 성격과 중요도가 근본적으로 다르기 때문이죠.

 

• 첫째, 이 알림 메시지는 정말 긴급한 업무인가?
  예컨대 카드 도난 분실과 같이 즉각적인 처리가 중요한 경우에는 재처리와 즉시 알림이 필요합니다. 그러나 단순히 안내성 메시지라면 재발송이 필요하지 않을 수 있습니다.
• 둘째, 발송 실패 시 업무를 중단할 만큼 중요한 메시지인가?
  만약 발송이 지연되는 경우 더 큰 피해를 초래할 위험이 있다면 재처리 로직이 필수겠죠. 하지만 마케팅 메시지와 같은 알림은 단순히 실패로 끝내도 업무에 큰 영향이 없습니다.
• 셋째, 지연 발송이 허용 가능한가? 허용한다면 얼마나?
  긴급성이 높은 알림은 1분 이내 재발송을 요구할 수 있지만, 그렇지 않은 업무는 몇 시간 이후 발송되어도 문제가 없을 수 있습니다. 지연 발송을 허용할 수 있는 기준이 명확히 정의되어야 합니다.

결국 더 넓은 관점에서는 모든 서비스를 하나의 기술적 해결책으로 접근하는 것이 아니라, 서비스마다 메시지 발송 실패가 미치는 비즈니스적 영향과 민원 대응 가능성, 고객 만족도와 리스크 수준까지도 모두 함께 고려하여 최적의 설계를 결정해야 합니다.

 

정리하자면, 업무 프로세스는 명확하게 핵심 로직과 부가 로직을 나누고, 공통 유틸에서는 최소한의 옵션과 로그를 제공하는 방식으로 지원해야 한다고 생각합니다.

즉, 공통 유틸에서 재처리 옵션을 제공하는 이유는 기술적 편리함 때문이 아니라, 각 서비스가 자신들의 비즈니스 성격과 현실적인 요구사항에 따라 메시지 처리 방식을 자유롭게 선택하고, 그 결과에 책임질 수 있게 하기 위함입니다. 

---

마무리

실무를 하다 보면 이와 같은 딜레마(트레이드오프) 상황에 종종 노출되곤 합니다.

이 글에서 말씀드리고 싶었던 것은, 작은 기술적 이슈가 결국 프로젝트 전체의 비즈니스 리스크나 고객 신뢰도 문제로 확대될 수 있다는 것이며, 중요한 건 기술적 완벽성이 아니라, 기술이 비즈니스에 어떤 가치를 줄 수 있는지를 명확히 바라보는 넓은 시각이죠.

 

종종 기술에만 매몰되는 제 자신을 보며 아직 갈 길이 멀다는 것을 체감합니다.

 

이번 글이 여러분이 시스템 설계 시 더 넓은 시야와 현실적인 판단력을 가질 수 있도록 작은 도움이 되었으면 좋겠습니다.