Notice
Recent Posts
Recent Comments
Link
«   2024/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Tags
more
Archives
Today
Total
관리 메뉴

마로의 개발일지

픽업 서비스 개발 회고 본문

기록

픽업 서비스 개발 회고

maro0201 2023. 4. 30. 19:21

픽업 서비스

 현재 내 경력에서 가장 많은 비중을 차지하고 우여곡절도 많았던 프로젝트인 픽업 서비스에 대한 회고이다. 픽업 서비스는 편의점에 물건을 맡기고 찾아갈 수 있도록 하는 서비스로 22년 7월부터 시작해 23년 1월에 끝난 질긴 프로젝트였다. 계획대로라면 22년 8월에 작업을 시작하여 22년 11월에 오픈 예정이었지만 여러 사정으로 인해 연기되었다. 여러 협력사들이 함께 진행하는 프로젝트다보니 서로간의 의사소통이나 일정 산출에 좀 더 많은 영향을 받았던 것 같다. 다른 회사와 협업을 한다는 자체가 역시 쉽지 않았다. 이번 회고는 개발 과정에 좀 더 중점을 둬서 작성할 예정이다. 테이블 설계나 구체적인 코드가 있으면 좋겠지만 개인적인 목적으로 사용하기엔 부담스러운 점이 있어 제외하고 기록하기로 했다.

 

개발 시작전에 고민하기

 처음엔 서비스 부분을 혼자 담당하고 백오피스를 시니어 분이 담당해주실 예정이었기에 대략적인 설계를 먼저 진행했다.

  • 테이블은 아직 기획도 제대로 나오지 않은 시점이었기에 대략적인 틀만 잡아놓았다. 픽업 거래 정보를 저장할 테이블, 거래 편의점 정보를 저장할 테이블, 상품에 등록할 편의점 테이블 등을 설계했고 추후 틀은 유지한채 항목들만 변경해서 사용했다.
  • 기존에 있던 택배 거래에 끼워 넣을지 새로 만들지를 고민했다. 고민결과 이건 새로운 거래 방식이므로 픽업 거래를 새롭게 만들기로 했다. 이 선택으로 인해 작업양이 상당히 늘어났고 혼자 담당하기엔 큰 분량이 되어 나 포함 주니어 둘과 시니어 한 분이 함께 작업하게 되었다.
  • 기존의 main-api에 함께 있던 배송 관련 로직을 MSA 형태로 만들기 위해 delivery-api를 만들어 픽업 서비스를 개발하고 이후 배송 관련 로직을 delivery-api로 옮기기로 했다.
  • 개발이 필요한 부분을 분석했고 개발 영역은 상품, 주문, 배송(픽업), 메인, 백오피스가 있었으며 내가 맡은 부분은 주문과 픽업의 수신부분이었다. (처음엔 몰랐지만 작업 분량으로 따지면 40~50% 사이의 어딘가 정도라고 생각되는 양이었고 그만큼 많은 양을 개발할 수 있어서 좋았다. 덕분에 개발 실력도 늘고 큰 프로젝트에 많은 기여를 했다는 기분을 느낄 수 있었다.)

환경 구성하기

 구체적인 문서들이 나오기전이라 대략적인 가닥을 이렇게 잡아두었고 이후 delivery-api를 생성하는 작업을 진행했다. 새로운 서비스는 기존의 멀티 모듈로 구성된 order-api쪽에 추가하기로 했고 생성 후 환경설정들을 진행했다. 거의 대부분의 코드들을 기존에 있던 order-api를 참고해서 작성하긴 했지만 대략적인 구성 요소들을 알 수 있는 좋은 경험이었다. 환경설정을 진행한 뒤 몇가지 테스트를 진행해서 정상 동작을 확인했다.

 팀장님이 이전에 혼자 시간될때 틈틈히 최신 spring framework와 java를 이용해서 환경구성을 해보고 새로운 서비스에 적용하면 좋을것 같다고 하셨지만, 시간이 없어 진행하지 못했다. 시간이 없었던 이유는 이전에 작업했던 부분들은 모두 Mybatis를 사용했는데 주문서 부분은 JPA를 사용했기에 JPA 공부에 모든 시간을 투자하고 있었기 때문이었다. 최신기술을 사용해서 환경 구성을 처음부터 하는 경험은 전부터 해보면 좋겠다는 생각이 있었는데 그러지 못해서 아쉬웠지만, 덕분에 JPA에 대한 기본적인 지식들을 습득한 채로 개발해서 좀 더 빠르고 정확하게 개발할 수 있었다.

 

기획과 연동 문서가 나온 후 설계 수정 및 보완하기

 이후 연동 문서와 기획이 나왔고 참고해서 이전의 설계들을 수정 보완했다. 테이블 설계에서 부족한 부분들을 채워 넣고, 기존에 설계했던 API를 보완하고, 추가적으로 개발해야하는 API를 추가했다. 그리고 기존 로직을 분석한 것을 바탕으로 클라이언트에 요청할 내용과 내부적으로 관리할 상태를 작성했다. 픽업 서비스는 회사 <-> 중계사 <-> 편의점 형태로 구성되어 있었고 필요한 요청을 하려면 중계사와 편의점 모두에게 요청을 해야했다. 필요한 내용들을 중계사와 편의점에 요청을 하고 기획팀과도 회의를 통해 기획 내용을 수정 보완했다.

 최근에 느낀 거지만 이 부분이 가장 큰 비중을 차지하는 중요한 부분이라고 생각한다. 예전에는 단순히 좋은 코드, 클린 코드를 짜기 위해 노력했고 사용하는 기술에 대해 충분히 알고 써야한다는 생각이 강했었다. 동작하는 기능을 구현하는데 좀 더 중점을 두고 개발을 진행했었고 좀 더 효율적인 코드는 무엇일까에 대해서 고민했었다. 그런 고민들을 하다보니 기능 구현에 관한 실력은 점점 늘어갔고 설계 단계에서도 코드 레벨에서부터 생각하게 되어 좋은점도 있었지만, 그러다보니 기획 단계에서부터 좀 더 나은 설계를 하는 것이 아니라 '가능'과 '불가능'으로만 생각을 하고 있는 나 자신을 발견했다. 더 나은 개발자가 되기 위해선 기능적인 측면에서만 고려하는 것이 아닌 사용자의 입장에서도 고려해야 한다는 것을 깨달았기에 요즘은 기획 리뷰에서 좀 더 많은 고민을 하고 사용자를 위한 설계를 하려고 노력하고 있다.

 

개발할 때 있었던 어려움과 느낀점

  • 결제 프로세스를 작업하는게 이번이 처음이라 모든 프로세스를 익히는데 시간이 꽤 소요되었다. 결제쪽 로직이 꽤나 복잡하기 때문에 코드 파악도 힘들었고 돈과 직접적으로 관련된 부분이기 때문에 더 신중하게 분석했다. 정책적으로 모르는 부분은 물어봤지만 대부분은 코드 분석을 통해 프로세스를 습득했다. 프로세스를 습득한 이후 픽업 서비스에 관한 로직을 추가적으로 작성했는데 새로운 거래 방법이 추가되다 보니 주문서쪽에 새로 작성해야 하는 부분이 많았다. 주문서는 현재 결제 서비스에서 가장 복잡한 부분인데 이 부분을 실수없이 수정하기 위해 많은 노력을 했었다.
  • MSA 형식으로 기존에 main-api에 집중되어 있던 로직을 분리하고 있었기 때문에 채팅 알림 기능을 delivery-api에 추가했다. 알림쪽도 기존에 꽤나 복잡하게 구현되어 있어 좀 더 깔끔하고 알아보기 쉽게 만들려면 어떻게 할지를 고민했고 Enum과 공통 메서드를 이용해 다른 서비스에서도 이용하기 편하게 구현했다.
  • 픽업의 수신부분을 작업할 때에는 유효성 검사를 많이 신경썼다. 사실 수신부분을 설계하는게 힘들지 구현이 어렵지는 않기 때문에 기능은 금방 구현했다. 하지만 해당 요청에 대한 중복 호출이나 잘못된 호출을 막는것이 좀 더 중요하고 놓치면 안되는 부분이라 생각해서 좀 더 중점적으로 신경써서 개발했다. 덕분에 통합테스트나 엔드투엔드 테스트를 진행할 때에도 유효하지 않은 데이터가 들어왔을 때 쉽게 파악해서 수정할 수 있었다.
  • 기존의 결제 취소 프로세스가 main-api에 있어서 order-api로 옮겼는데 해당 로직에서 예외가 발생했을 때 상태값이 변한채로 유지되는 버그가 발생했다. 그 이유는 기존에 상태를 변경하는 부분이 존재해 추가적으로 상태를 변경하는 부분을 해당 메서드로 옮겼는데 메서드가 예외 상황을 고려하지 않은 상태로 작성되어 있었다. 기존에 작성되어 있는 코드기에 당연히 정상적인 코드라 믿었는데 그 생각이 잘못된 것을 깨달았다. 덕분에 기존에 있던 코드라도 제대로 작성이 된 코드인지 먼저 확인하게 되었다.
  • 편의점과 우리 서비스의 픽업 상태가 같은지에 대한 데이터 정합성 배치를 만들어야 했는데 기간이 매우 촉박했다. 이전에 픽업 관련해서 배치들을 만들어 본 상태로 빠르게 만들수 있었지만 오픈이 3일 남았는데 작업해야 하는 양이 꽤 많았다. 화장실 갈 시간도 아껴가며 집중해서 작업했고 너무 열심히 일해서 퇴근할 때 쯤엔 체력이 방전되어 머리가 띵했다. 그래도 다행히 기능은 시간안에 구현할 수 있었고 이후 리팩토링을 통해 로직을 개선했다. 이렇게까지 일정에 쫓겨본적은 없었는데 덕분에 좋은 경험을 한 것 같다.
  • 테스트를 하기가 까다로웠다. 에러가 발생하면 중계사에서 발생했는지 편의점에서 발생했는지 확인하는 과정에서 시간이 소요되었고, 응답도 즉시 하지 않아 답답한 점이 많았다. 당일에 주기로 했던 데이터를 기다리면서 오후 9시까지 있었지만 다른 곳은 모두 퇴근하고 답장도 없어 시간을 축낸 적도 있었다. 이전까지는 카톡을 통해서만 연락했었고 최종 테스트를 할 때에서야 줌 회의를 통해 함께 진행할 수 있었다. 원래 협업이 이런건가라고 생각했지만 그래도 결과는 좋으니 좋은 경험이라고 생각하고, 다음에 협업할 땐 좀 더 나은 방법을 통해 진행할 수 있도록 고민을 해봐야겠다고 느꼈다.

어쨋든 성공?

 해당 프로젝트 덕분에 협업의 어려움을 알았고 많은 것들을 느꼈다. 많은 시간과 노력을 들여 출시한 서비스가 그래도 꽤 성공적으로 서비스되고 있어 만족하고 있다. 내가 만든 서비스를 누군가가 이용한다는 것은 뿌듯한 일인 것 같다. 앞으로도 많은 사람들이 이용하는 서비스를 만들어나가고 싶다는 생각이 들었고, 많은 사람들이 이용하는 대규모 트래픽이 발생하는 서비스는 어떻게 만들어지는지 궁금해졌다. 그런 서비스를 만드는 곳에 가기 위해선 대규모 트래픽을 처리하는 방법을 먼저 익혀야 할 것 같으니 좀 더 열심히 공부해야겠다.

Comments