비즈니스 로직 분산

입사 초에 있던 일을 공유해보려고 한다.

 

우리 회사는 백로그 단위로 일을 하며, 각 분야별로 1명씩 붙는다. 예를 들어 1개의 백로그에 기획, 백엔드, 프론트엔드 이런 식으로 붙는다.

입사 후 사수와 같이 계속 작업을 하다가, 어느 정도 적응을 하고 처음 혼자 맡게된 백로그였다.

 

개발해야 하는 백로그는 주문 지연 알림톡이라고, 주문이 20분 이상 지연될 경우 관계자들한테 일괄적으로 알림톡을 보내는 기능이였다.

지금 다시 한다면 쉽게 구현이 가능하겠지만, 그 때는 경험이 없어서 어려웠던 것 같다.

 

주문은 새벽에 발생할 수도 있는데, 주문 알림톡이 새벽에 온다면 짜증나지 않을까? -> 그래서 시간 조건도 존재하였다.

마트와 마트 관계자는 1:N 관계이다. 최종적으로 알림톡을 보내는 시간 조건은 마트의 운영 시간에 속하면서, 마트 관계자가 알림톡을 받을 수 있는 시간이면 알림톡을 발송하도록 하였다.

 

마트와 관계자 알림톡의 고려해야 할 시간 범위는 아래와 같았다.

오전 ~ 오후: 시작 시간이 종료 시간보다 작은 것
오후 ~ 새벽: 종료 시간이 시작 시간보다 작은 것

24시간: 시작 시간과 종료 시간이 같은 것

여기에 현재 시간이 오전이냐 오후냐도 고려해야 한다.

즉, 2 * 3(마트 시간 경우의 수) * 3(관계자 시간 경우의 수) = 18개의 경우의 수가 존재한다.

 

이를 어떻게 구현했을까?

MyBatis로 SQL 조건문에 모두 때려 박았다.

결과적으로 새벽 시간 대 알림톡이 발송되는 오류 발생 -> CS 인입 -> 멘붕

 

문제가 왜 발생했을까?
근본적인 이유는 모든 경우를 테스트하지 못한 나의 실수 였다.

모든 경우의 수를 sql 문에 다 담으려고 하니, 모든 조건을 고려하지 못하였고 SQL에서 조건을 하나 누락하는 실수를 하게되었다.

위에서는 18개의 경우의 수를 정리하였는데, 그 때 당시에는 저렇게 경우의 수를 계산하고 개발한 것이 아니였다.

아마도 m.startTime > m.endTime and m.startTime < now() and m.endTime > now() and mm.startTime < now() and mm.endTime > now() 이런 느낌으로 여러 줄 썼었다.

 

이 문제를 해결하기위해 접근 방식을 바꿔보았다.

위의 시간 조건을 SQL 조건문 내에서 모두 해결해야 할까? 즉, 복잡한 비즈니스 로직을 데이터베이스 쿼리에 의존하게 해야할까?

문제의 근본 원인을 이해한 후, SQL에서 시간 조건문을 모두 제거하였고 애플리케이션에서 필터링하도록 구조를 변경하였다.

xml로 작성하다가, 코틀린으로 작성하니 신세계였다. 정말 편했다.

즉, 애플리케이션으로 끌고와 처리하니 코드의 가독성이 향상되었다.

 

 

이 경험전까지 나는 비즈니스 로직을 SQL 쿼리 내에서 처리하는 경향이 있었다.

해당 방식은 복잡한 조건을 다룰 때 SQL 쿼리가 과도하게 복잡해지는 문제를 야기

이 문제 해결과정을 통해 비즈니스 로직을 적절히 분산시켜 처리하는 것의 중요성을 깨달았다.