유저 주문 취소 기능 Java 전환기
프로젝트의 진행 과정을 기술하기 전에 저희가 지난 3월부터 5월까지 진행했던 다른 업무에 대한 회고 내용을 잠깐 공유하고 넘어가려고 합니다.
29CM 백엔드팀은 Python + Django 기반의 모놀리틱 서비스를 Java + Spring 기반의 MSA(Microservices Architecture) 로 전환을 진행하고 있습니다.
그 중 저희 스쿼드에서 담당하고 있는 취소/교환/반품 도메인에서는 ‘유저 주문 취소 기능’ 을 전환 과정의 첫 feature 로 정하고 개발을 진행하게 되었습니다.
6/1 회고 (구매 후 경험 스쿼드)
3월에 처음 구성된 저희 스쿼드는 지난 3개월 동안 같이 업무를 하며 느꼈던 점들에 관해 이야기를 나누는 자리를 가졌습니다. 기뻤던 점, 힘들었던 점, 화났던 점 들을 각자 포스트잇에 적어 보드에 붙이고 공감되는 내용에 스티커를 붙이는 형태로 진행했습니다. 그런 후에 스티커가 많이 붙어있는 내용을 중심으로 좀 더 깊은 이야기를 나누면서 모두가 느끼는 문제 상황을 도출하였고, 이런 문제 상황을 개선할 수 있는 Action Item을 뽑아 보았습니다.
많은 공감을 받았던 주제
- 기존 로직 분석이 너무 어렵다
- 레거시 코드에서의 신규 개발/수정이 어렵다
위 주제 중 첫번째 주제에 대해 다시 이야기 해보았습니다
- 품절 취소 후 즉시 환불 개발 과정에서는 기존의 코드 분석과 사용자 인터뷰 등을 통해 현재의 정책과 요구사항을 분석 했었는데, 다양한 상황에 맞는 정책이 무엇인지를 파악하는 것이 너무 어려웠음
- 개발을 진행하다가 기존의 정책을 누락시켜서 다시 개발하거나, QA 과정 중에 발견된 이슈를 다시 개선하는 식으로 업무가 진행되면서 전반적인 배포 일정이 계속 미뤄짐
- 관련 도메인 업무에 대한 명확한 정책 수립과 지속적인 문서화의 필요성을 깨닫게 됨
Action Item
위와 같은 내용을 근거로 하여 저희 스쿼드는 다음과 같은 개발 프로세스를 수립하고 운영하기로 하였습니다.
- 개발을 시작하기 전에 충분한 사전 조사 과정을 거쳐서 초기 정책 문서를 작성한다
- 작성된 정책 문서를 기반으로 개발 일정을 산정한다. 정책 문서가 충분히 작성되기 전까지는 개발 일정을 산정하지 않는다
- 개발 과정에서 예외 사항이 발견되면 처음에 작성한 정책 문서가 업데이트 될 수도 있음을 감안한다
- 정책의 수립과 변경, 코드 개발의 과정을 반복한다
- 개발을 완료하고 운영에 배포한다
- 이후에는 의도적인 업무 시간을 할당하여 개발의 전체 과정을 회고하고 정책 문서를 완성해 나간다
회고를 진행하고나서 얻은 결론은 문서화의 중요성을 알고 실행하자 였습니다. 그리고 회고 이후의 프로젝트 부터는 문서화를 잘 실천하면서 일해야겠다고 다짐하였습니다
회고 이후 다음 프로젝트 선정
6/1 회고 후 진행할 프로젝트는 ‘유저 주문 취소 개선’ 이었습니다. 해당 프로젝트는 기존 기능을 그대로 유지한 채 코드의 구조만 개선하는 것 이었지만 이를 기반으로 앞으로 진행할 전체 프로젝트의 개발 생산성을 향상시키고, 다음에 개발될 신규 기능인 유저 부분 취소 기능의 발판이 되는 프로젝트라고 판단하여 진행하게 되었습니다.
Python + Django 로 작성된 저희 메인 서비스 로직들은 대부분 Serializer 클래스에 모든 구현이 다 들어있습니다. 저희 스쿼드에서 담당하는 기능들은 대부분 책임이 크고 정책이 복잡하기 때문에 특정 Serializer 를 중심으로 대부분의 로직이 거대한 진흙과 같이 뭉쳐져 있었습니다. 그래서 간단한 수정사항에도 분석에 많은 시간이 소요되며, 사이드 이펙트를 발생시킬 여지가 많았습니다.
개발 관점에서 이러한 Pain Point 는 앞으로의 비즈니스 확장에 걸림돌이 될 것이라 판단하였고, 이를 개선하기 위한 첫 작업으로 유저 주문 취소 기능을 신규 서비스로 이전하면서 유지보수가 수월한 코드로 다시 만드는 것을 하기로 정했습니다.
작업 계획 및 도식화
전체적인 작업 순서는 아래와 같이 계획하였습니다.
- 코드 분석
- 취소 관련 정책 정리
- 취소 프로세스 도식화
- API 스펙 정의 및 공유
- 프로그램 설계 도식화
- 개발 세부 작업 생성 (일정 산정)
- 개발 작업
- Test 코드 작성 (자동화 테스트)
- QA (TC 작성 및 테스트)
3번 작업에 대한 내용은 아래와 같습니다.
대부분의 정책이 서버쪽 코드에 구현되어 있었기 때문에 정책 문서의 초안은 백엔드 개발자가 작성하였고, 이후 스쿼드 구성원 모두가 참여하여 진행한 여러 번의 정책 문서 리뷰를 통해 정책 및 프로세스 도식화 작성을 완료하였습니다
해당 문서를 통해 프로덕트 오너, 프론트엔드 개발자, 백엔드 개발자 모두가 비즈니스 도메인에 대한 지식을 일치시킬 수 있었으며, 이러한 과정이 있었기 때문에 한창 개발이 진행되는 시점에서 도메인 정책에 대해 서로 되묻는 일이 거의 없었습니다.
함께 개발하기 위한 방법
실제 개발을 진행하기 전에 정리해야 할 것이 하나 더 있었는데, 이는 해당 feature 개발을 위해 배정된 두 명의 백엔드 개발자가 ‘전체 개발을 어떻게 같이 진행할 것인가’ 에 대한 것이었습니다 (작업 계획 중 ‘5. 프로그램 설계 도식화’ 라는 항목은 이를 위한 작업입니다)
하나의 기능을 여럿이서 같이 개발해보신 경험이 있으신가요? 이런 경험은 규모가 큰 회사에 다니더라도 쉽게 접하기 힘든 것이라고 생각합니다. 개발 업무는 보통 작은 기능 단위로 나뉘게 되고, 하나의 기능당 한 명의 개발자가 온전히 도맡아서 개발하는 것이 일반적이기 때문입니다.
이러한 배경이 있었기 때문에 저희는 본격적으로 개발을 시작하기에 앞서 원활한 협업을 위한 업무 방식을 찾는 것부터 시작했습니다.
저희는 우선 아래와 같은 텍스트 기반의 개발 설계 문서를 작성해봤습니다. 문서 내용은 기존 코드를 분석하여 데이터 변경이 필요한 내용을 위주로 정리하였습니다.
이후에는 작성된 텍스트 설계 문서를 기반으로, 기능별로 각각의 책임 단위를 작게 분리하고 의미있는 단위로 묶어가면서 아래와 같은 Class Diagram 을 작성하였습니다.
위의 다이어그램은 기본적으로 Class Diagram 양식을 따르고 있지만, 저희는 해당 다이어그램을 살펴보는 사람들이 충분히 쉽게 이해할수만 있으면 세세한 형식은 굳이 고민하지 않아도 된다고 생각했습니다. 이에 따라 각각의 Class 에는 클래스명, 해당 클래스의 책임과 역할, 접근 제어자 (+ : public, — : private), 트랜잭션(Tx), 비동기(Async) 정도만 가볍게 표시하였습니다
또한 주문 취소라는 기능의 코드 볼륨이 워낙 크고 Python + Django 에만 익숙한 동료 개발자 분들이 Java + Spring 기반의 신규 서비스를 구축하는데 있어서 적응하는 시간이 필요했기 때문에 구현 과정에서는 지속적인 코드 리뷰와 구현에 대한 피드백을 주고 받는 시간을 가졌습니다
유저 전체 취소 기능에 대한 Class Diagram 과 개발 문서 작성이 완료되었을 때, 다른 스쿼드의 동료들도 해당 문서에 대해 큰 관심을 표현해주었고 아래와 같이 긍정적인 피드백을 주었습니다.
정책 문서와 Class Diagram 을 완성한 후에는 이를 기반으로 개발 업무를 sub-task 로 세세하게 나누고 각각의 일정을 산정해보았습니다. 작은 단위로 task 를 나누고 일정을 산정해보니 프로젝트 전체의 일정을 비교적 정확하게 예측할 수 있었습니다.
이제 IDE를 켜보자
개발을 위한 6단계의 사전 작업을 완료하기까지 대략 7~8일이 소요되었습니다. 짧게 생각하면 그 기간동안 코드 개발은 한줄도 진행하지 못했지만 저희는 그 시간들이 충분히 투자할만한 가치가 있었다고 생각합니다.
작성된 설계 문서에는 개발에 필요한 모든 정책과 로직이 정리되어 있었기 때문에, 코드 구현 과정에서는 도메인 요구사항을 발견하고 고민하는 시간이 거의 없었습니다. 코드 구현 시간도 기존의 개발 방식보다 훨씬 단축할 수 있었습니다.
신규 개발된 코드의 일부를 보여드리면 다음과 같습니다.
신규로 개발된 모든 코드는 정책 문서와 Class Diagram 을 토대로 작성되었습니다. public method 에는 상세한 로직보다는 전체의 흐름을 표현하도록 추상화 수준을 높여서 개발하였고, 상세한 로직은 private method 나 별도의 클래스에서 가장 작은 기능 단위로 나누어 개발하였습니다.
전체적인 패키지 구조 및 클래스들은 아래와 같이 되어있습니다. 모든 클래스는 주문 취소라는 하나의 기능을 위해 구현된 것들입니다.
개발을 완료한 직후에는 기존에 비해 상대적으로 많이 늘어난 클래스와 파일 갯수 때문에 ‘우리의 프로젝트가 기존의 코드보다 더 좋아진 것이 맞는지’ 에 대해 고민이 많았지만, 운영 배포 이후의 회고에서 동료 개발자들의 피드백을 받은 후에는 신규로 개발된 프로젝트가 성공적이었음을 확신할 수 있었습니다.
개발이 완료되고 나서
개발 관점에서는 기존 기능을 다른 언어와 프레임워크로 그대로 옮긴 것 뿐이었지만 기존 구현의 코드 볼륨이 워낙 큰 기능이었기 때문에, 충분한 테스트를 진행했음에도 운영 배포 직전까지는 걱정과 불안함을 떨칠 수가 없었습니다 (운영 오픈만큼 부담스럽고 무서운 단어가 또 있을까요…)
그리고 저희는… 배포를 했습니다…
오전 11시에 배포한 주문 취소 신규 로직은 오후 4시가 될 때까지 그 어떠한 버그와 이슈 없이 동작하였습니다.
기대 이상의 성공적인 배포 이후 주문 취소 신규 로직 개발 과정에 대한 회고 시간을 가졌습니다.
프로세스를 미리 도식화하고 이를 함께 리뷰하면서 정책 문서와 다이어그램을 완성해나갔던 경험이 정말 좋았다고 모든 구성원이 입을 모아 말했습니다. 특히, 29CM 에서 다년간 Legacy 를 유지보수 해오셨던 성원님 (a.k.a CS의 아버지) 은 새로 개발된 서비스를 보시면서 다음과 같은 말을 남겼습니다
기존에는 1시간 보던걸 10분만 봐도 좋을 정도로 좋아졌다.
마치며
제품을 개발하고 회고를 진행하면서 도출된 Action Item 을 바탕으로, 좀 더 나은 제품 개발의 방법을 찾아나간 저희 스쿼드의 이야기를 소개해드렸습니다.
좀 더 나은 개발과 유저 경험을 제공하기 위해 저희의 이야기가 누군가에게 도움이 되길 바라며 이만 마치겠습니다.
읽어주셔서 감사합니다.
함께 성장할 동료를 찾습니다.
29CM ((주)무신사)는 3년 연속 거래액 2배의 성장을 이루었습니다.
이제 더 큰 성장을 위해 기존 모놀리틱 서비스 구조를 마이크로서비스 구조로 전환하고, 앵귤러 기반 프론트엔드 코드를 리액트로 전환하는 등의 기술적인 시도를 진행하고 있습니다. 모바일 앱 내부 구조도 모듈러 아키텍처로 개선하는 과정에 있습니다. 함께 성장하고 유저 가치를 만들어낼 동료 개발자분들을 찾습니다.
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr/
