[미리캔버스 백엔드 개발자 일기] 우당탕탕 정산 개발 회고록 - 절망편

이상민·2022년 7월 22일
5
post-thumbnail

1. 미리캔버스 유료화

지난 5월, 드디어 미리캔버스 유료화가 오픈되었다! 난 당시 유료화 팀은 아니지만, 옆에서 팀원들이 노력한 것을 봐서 그런지 나까지 감격스러웠다. 이번 유료화는 프리미엄 컨텐츠의 구매정기 구독 서비스 2가지로 나뉜다.

컨텐츠 구매는 사용자가 원하는 만큼의 컨텐츠를 디자인에서 사용한 후 이를 구매할 수 있는 기능이다. 구매를 하지 않아도 저장과 사용이 가능은하나, 워터마크가 적용이된다. 이를 제거하려면 아래처럼 구입을 해야한다.

정기 구독 서비스는 '플랜'이라는 단위로 다양한 기능을 제공하는 정기 결제 요금제이다. 흔히 사용하는 넷플릭스 같은 걸 생각하면 된다. 가장 대표적인 기능은 아무래도 프리미엄 콘텐츠를 마음껏 사용할 수 있는 것이다. 이외에도 다양한 기능이 있다. 각 플랜 별 자세한 기능은 여기서 확인할 수 있다.


2. 새로운 요구사항 - 정산

유료화를 통해 고객에게 편익을 제공하기 위해서는 다양한 프리미엄 콘텐츠가 필요하다. 이 많은 콘텐츠를 회사 내에서 생산할 수는 없고, 다른 곳에서 구해오기도 하는데 이때 정산에 대한 요구사항이 발생한다. 사용했으니 마땅히 돈을 줘야지. 아래 이미지를 보면 콘텐츠의 출처가 게티라는 곳임을 알 수 있다. 참고로 왕관 표시가 있는 콘텐츠들이 프리미엄 콘텐츠들이다.

나는 정산을 위한 데이터 가공을 담당하게 되며 유료화 팀으로 오게 되었다. 처음에는 매우 단순한 업무일 것으로 예상했다. 하지만 알아야할 도메인 지식이 많고 관련 변경이 자주 있어 조금 고생했다.


3. 고통의 정산 업무

가장 처음에 한 일은 정산을 위해 도메인을 이해하고, 필요한 데이터를 파악하는 것이었다. 유료화 작업 처음부터 정산을 생각하고 개발한 것이 아니었기 때문에, 필요한 로우 데이터가 부족한 경우도 있어 이를 수집할 수 있도록 수정하는 등 여기저기 소통할 일이 잦았다. 이후 필요한 데이터가 모두 있으니 그냥 스윽하고 개발하면 될 줄 알았는데, 그렇게 호락호락 하지는 않았다.

개발을 하며 주문 데이터를 위주로 정산을 하게 되었는데, 이 주문 데이터가 유료화 오픈 이후에도 많은 요구사항 속에서 계속 변해 갔다. 코드 상에서 정산 관련 부분은 분리가 되어있었으나, 데이터를 공유하면서 유료화 요구사항에 많은 영향을 받게 되었다. 결국 유료화가 바뀌면 정산이 영향을 받으니 어떤 작업을 하기전 나에게 먼저 확인을 요청하는 경우가 많아졌다. 이런 경우가 조금 많았다... 무언가 바뀐다 해서 고치고나니 또 다른 것이 바뀌고, 그것을 대응하니 이번에는 알지도 못했던 새로운 것이 문제를 일으키고 하는 등 이걸 몇번을 반복했는지 모르겠다. 정산 데이터를 사용하는 입장에서는 이를 모를테니 나한테 문의가 들어왔고, 뭔가 계속 부끄럽고 죄송스러웠다.

지금 생각해보면 경계가 다르기 때문에 데이터를 분리했어야 했는데, 코드 의존성만 생각했지 영속성 계층의 의존성을 생각하지 못했다. 또 한편으로는 유료화 요구사항 변화로 영향을 받은 데이터가 결국 정산의 근간이 되는 데이터이기 때문에, 데이터를 분리해 저장했어도 여전히 영향을 받지 않았을까 싶기도 하다. 워낙 유료화 초기이니 많이 영향을 받고 하는게 당연한거 같기고 하고, 스스로도 오락가락한다. 결국 또 '어떻게 하는게 정답이었을까...'하는 고민만 늘어났다.


4. 오늘의 교훈

데이터를 분리하는게 정답인지는 모르겠지만, 확실히 강한 데이터 수준의 결함으로 인한 영향은 덜 받았을 것 같다. 만약 새로운 도메인 개발을 하는데 다른 도메인에 의해 영향을 크게 받는다? 뭔가 경계 설정을 잘못하고 있을 가능성이 높다. 마치 나처럼...

이번 기회를 통해 의존성의 무서움을 약 4개월동안 뼈저리게 느꼈는데, 앞으로는 의존성에 대해 훨씬 더 깊은 고민을 할 것이다. 현재도 사실 만족스러운 구조가 아니기 때문에 앞으로 업무를 더 진행하면서 리팩토링하여 다음에는 희망편 회고록으로 다시 돌아올 수 있으면 좋겠다.

마지막으로 정산 기능을 개발하면서 들었던 생각을 정리하자면 아래와 같다

잘한 점

  • 테스트 주도 개발을 통해 요구사항을 정리하며 개발
  • 테스트 케이스마다 주석으로 다이어그램을 그려 요구사항을 명확히 전달
  • 정산 요구사항에 허점을 발견하고 보완
  • 주문에서 누락하고 있는 정보를 파악
  • 테스트로 복잡한 요구사항에 대한 문서화 역할

아쉬운 점

  • 정산을 온전한 별도 도메인으로 보지 않아 별도 데이터를 쌓을 생각을 못함
  • 정산 관련 기능에 대한 오너십을 잘 협상하지 못해 기능들이 위치하는 서버가 나뉨
profile
편하게 읽기 좋은 단위의 포스트를 추구하는 개발자입니다

3개의 댓글

comment-user-thumbnail
2022년 7월 28일

리팩토링 내용도 기대할게요!

답글 달기
comment-user-thumbnail
2022년 9월 2일

희망편 회고록 기다리고 있을게요!

답글 달기