딴곳 펀딩은 다 10시에 일괄 취소되던데요?

주니어 기획자의 이해를 돕기 위한 비유설명법

*본 시리즈는 우리 주니어들에게 제가 설명하는 방식들을 정리한 내용으로, 기획자가 딱 일할 수 있을 정도로만 문과적 비유를 들어 설명합니다.

오프라인만 해오던 마케터가 한 분이 찾아와서 야심차게 소셜펀딩 상품을 만들어달라고 했다. 이미 있는 기능이었다. 아 그러냐면서 자신이 생각한 것과 기능적 차이를 묻기 시작했다. 그러다가 깜짝 놀라면서 오류리스트에 처크를 하며 말했다.

"펀딩실패하면 다른 곳은 다음날 10시에 취소되요! 근데 왜 여기는 실패 즉시 취소되요??"

흠.. 나는 상황을 파악하고 되물었다.

"아.. 흠. 마케터님은 왜 그게 항상 10시가 되서야 취소되었다고 생각하세요? 이미 펀딩은 실패했는데요??"

" 아 그냥 제가 몇군데에서 해봤는데 다들 다음날 10시에 취소되던데요?"

"다른 곳도 펀딩실패되면 그 뒤로 다시 되돌릴수 있는 건 아니잖아요? 왜 바로 취소가 되면 안되죠?? 깨진 펀딩을 빨리 알게 되고 환불도 빠른 쪽이 고객에게 더 좋을 수도 있지 않을까요? 이건 선택의 문제거나 아마 펀딩실패 판단시점이 다음날 10시로 모두 동일하기 때문일거에요."

"그 부분까지는 생각안해봤어요"

---

정해진 시간에 일괄 처리 vs 실시간처리

만약에 A에서 B를 거쳐서 C로
야구공을 100개 옮긴다고 가정해봐요.
먼저 A에서 B로 공을 던지겠죠?
B에서 C로 옮길 사람이 1명이에요.
그럼 방법은 2가지죠.
B에다가 다 모아놨다가 C로 가져가거나
B에 올 때마다 C로 던지는거지.

전자가 일괄 배치(batch)처리고
후자가 실시간 처리라고 생각하면 돼요.

규모가 큰 서비스는 수많은 이용자가 동시에 이용한다. 이용은 필연적으로 데이터를 생성한다. 동시다발적으로 생성된 데이터를 일괄적으로 처리해야할 때가 있다.

커머스에서는 생성된 주문을 배송데이터로 판매자에게 전달한다거나, 2일이나 지나도 결제하지 않은 주문건을 자동으로 취소할 때다.

물론 발생할 때마다 처리를 해주면 제일 좋다.

그러나 변경사항을 아예 체크하지 못하는 상황에서는 앞에서 쓴 글처럼 트리거가 있어야한다.

위의 상황도 그렇다. 그냥 펀딩에 해당하는 결제 주문이 생성되어서 쌓인다. 어느 순간 펀딩상품의 종료시점에 진행인지 실패인지 판단하고 데이터를 바꿔줘야 한다. 그 시점이 오기까지 취소를 진행할 기준이 없다.

누가 공을 던져줘야 또 던질 수있다.

담당자가 봤다는 그 회사는 아마도 이 실패판단을 매일 아침 10시에 처리하는 것이다. 아니면 그 시간에 실패된 펀딩에 걸려서 살아있는 결제들을 모아서 일괄로 하나하나 취소처리해주거나. 그러니까 이미 지난 밤 9시에 종료되고 실패에 해당하는데도 가만히 있었겠지.

그런데 대부분의 배치처리는 일괄 변경처럼 보이지만 사실 1개씩 처리된다. 대상은 한번에 찾아놓고 처리는 순서대로 하는것이다. 저 위에 예시대로면 B에 모여있는 공을 모두 확인하면 C로 한개씩 던진다. 그래서 개중에는 실패하거나 하는 경우도 당연히 발생한다.

그런데 왜 우리 사이트는 이걸 실시간으로 취소해줄 수 있었을까?? 그건 MSA구조로 인해서 서로 구조가 떨어진 사이트였기 때문이다. 펀딩 성공여부를 처리하는 프로세스가 매 시간 돌고 실패를 찾으면 실패라고 주문결제 데이터가 쌓은 곳으로 알려주었다. 그럼 받을 때마다 취소처리가 가능해진다.

이게 뭔 소리냐고??

그러니까 이런 데이터 상태값이 실시간으로 바뀌는 게 아닌 경우 대량의 데이터를 순서에 맞게 움직이려면 내부 시스템의 상황을 이해하고 있어야한다는 점이다.

어떤 방식을 택하든 그건 고객편의와 시스템의 관점에서 선택된 것뿐이다. 중요한건 어떻게 동작하게 될 것인지 미리 개발설계자와 충분히 이야기해서 그게 이용에 불편이 없는지 판단해야한다는 점이다.

그리고 타사의 기준이 우리의 기준이 되서도 안된다. 1만원짜리 펀딩과 100만원 펀딩의 실패후 취소환불에 바라는 소요 시간은 굉장히 다를테니까.