'멤버십 환불/해지' 프로젝트를 마치며.

'멤버십 해지/환불' 고도화 프로젝트를 마치며

[TOC]

이 포스트를 통해 무엇을 말하고 싶은지?

• 왜 이것을 하게 되었는가?
• 스스로 생각하길 잘하지 못한 부분
• 스스로 생각하길 잘한 부분

왜 이것을 하게 되었는가?

트레바리는 오프라인 서비스이다. 대다수의 많은 유저는 약 4번의 오프라인 서비스 이용을 위해 20만원 이상의 금액을 낸다.

20만원 이상의 금액을 사용하는 하는 유저에게는 클럽에 참여할 수 있는 권한. 즉 멤버십 이 생겨난다.

만약, 해당 유저가 '더 이상 모임에 참여를 원하지 않는 경우에는?' 어떻게 되는가? 유저에게는 모임에 참여할 수 없도록 멤버십이 해지되고, 결제한 금액에서 수수료를 제외한 일부 금액을 환불받게 된다.

대부분이 '더 이상 모임에 참여를 원하지 않는 경우' 에 멤버십 해지와 환불이 동시에 일어난다. 그러나, 트레바리 시스템은 멤버십 해지와 환불이 같은 트랜잭션에(동시에 일어난다) 묶여있지만, 코드 베이스상으로는 멤버십 해지와 환불이 멀리 떨어져 있다. 그러므로, 이를 가깝게 하기 위한 작업을 진행했다.

어떻게 고도화를 했는가?

기존 트레바리에서는 더 이상 모임에 참여를 원하지 않는 경우 의 시스템 프로세스는 아래와 같다.

AS-IS

TO-BE

AS-IS 에서 TO-BE로 변하게 되면서 무슨 장점이 생겼을까?

• 멤버십 해지와 환불이 코드 베이스로 가깝게 두어, 직관적으로 볼 수 있게 되었다.
• 각 멤버십 해지와 환불의 정책이 직관적(Specification)으로 변하게 되었다.
• 기존에는 환불 > 해지 순이였다면, 이제는 멤버십을 해지 > 환불 순으로 변경됨에 따라 비지니스가 코드로 표현되었다.

기술적으로 적용한 부분은 무엇인가?

• 해지/환불 정책을 리팩토링하는 과정에서 IF 문으로 표현되는 것을 Specification 패턴을 활용해, 명시적으로 코드에 드러나게 했다.
• 핵사고날 아키텍쳐를 적용해, 의존도를 방향성을 명확히 하고 유즈케이스를 드러냈다.

스스로 생각하길 잘하지 못한 부분

이번 프로젝트의 Lead Engineer 로 참여했다. 그리고 일정을 약 4일 지연시켰다. 즉 명확한 시점에 가치를 전달하지 못했다.

구체적으로 내가 잘하지 못한 부분으로는

• API Spec 을 사전에 설정하지 못했다.
• 업무를 할당받아야할 개발자에게 해야될 업무에 대해서 interface 로 제공해주지 못했다. (= 오케스트레이션을 잘하지 못했다.)
• 한명 한명의 개발자가 자신이 풀어야할 숙제를 해결한 뒤 나에게 확인 요청할 때, 빠르게 피드백을 주지 못했다.
• 핵사고날 아키텍쳐에 치중된 나머지, 큰 그림을 바라보지 못하고 중복된 코드를 만듬으로써 관리 포인트를 늘렸다.

핵사고날의 장점은 영속성 계층과 도메인을 분리한다고 생각했다. 그래서 기존 코드에서 도메인이라 불리오는 곳에 변경을 가하기 보다는, 새로운 New 도메인을 만드려는 시도를 했다. 그것도 같은 코드를 복사 붙여넣기해서 말이다.

스스로 생각하길 잘한 부분

• 이번에 핵사고날 아키텍쳐의 모델링이 도입함으로써, 의존성의 방향을 명확하게 했다.
• 타 개발자와 페어프로그래밍을 통해 모델링의 작은 부분은 빠르게 검증했다.