서윤혁
저는 프로젝트를 선택할 때 최대한 안해봤던거를 선택하는데, 이번에는 제목이 셀메이트 API이여서 우리 회사 자체 API가 있었나 궁금해서 이번 프로젝트를 선택하게 되었습니다. 그런데 알고보니 기존에 사용해왔던 Common API가 셀메이트 API였습니다. 평소에도 코드를 좀 봐왔던지라 크게 프로젝트를 진행하면서 어려웠던 점은 없었고, 무난하게 진행이 되었습니다. 그렇게 프로젝트가 잘 마무리 되는가 싶었는데 코드리뷰를 받고 나니 내가 Common API의 기존 설계를 무시한채 코드를 작성해왔다는 것을 알게되었고, 코드를 고치면서 Common API의 구조와 설계 컨셉에 대해서 알게되었습니다. 그 후 코드를 프로젝트 구조와 설계에 맞게 수정하였습니다. 이번 프로젝트를 통해서 Common API를 더 잘알게 되어서 좋았고, 앞으로 Common API와 관련된 프로젝트를 하게 되면 더 잘할 수 있을거 같습니다. 여러모로 배울점도 많았고, 재밌는 프로젝트였습니다.
개발과정중 배운점
개발 과정중에 수정된 주문을 조회하는 API가 있었는데, 셀메이트 DB에는 수정된 주문 기록을 남기는 테이블이 없어서 Temporal 테이블을 사용하게 되었는데 이를 통해 수정된 시간과 수정된 주문들을 쉽게 찾아낼 수 있었습니다.
양선경
API 접근 제어를 위한 미들웨어 추가
COMMON-API 프로젝트에 미들웨어를 추가하여 접근이 가능한 고객사만 API데이터를 조회할 수 있도록 하는 작업이었다. API접근가능여부는 NURIA의 업체관리>부가서비스에서 설정할 수 있으며, 신서버이주명단에 등록된 업체의 commonapi_use 컬럼값을 통해 해당 업체가 데이터에 접근이 가능한지 판단하여 외부 요청을 걸러낼 수 있도록 구현하였다.
주문조회 시 출고분류구분에 대해 조회
업체가 API요청 시 원하는 출고분류명을 입력하여 구분된 주문 데이터를 조회할 수 있도록 하는 기능이다. COMMON-API 내의 필터링 스펙을 이용하고 싶었으나 출고분류를 구분할 수 있는 값이 컬럼으로 존재하지 않았고, relation을 맺어 구현하기에도 기존 기능과 완전히 동일하게 작동하도록 하는 것이 쉽지 않아 raw쿼리를 사용하였다. 처음에는 쿼리빌더로 넘어오는 값을 모델이 아닌 job에서 처리하도록 구현했었는데 코드리뷰 이후 데이터 조회에 관한 로직은 모델에 구현하도록 하는 것이 나을 것이라는 판단에 scope method를 사용하는 방향으로 코드를 수정하였다.
입출고 수정 및 삭제 API 추가
입출고서 수정 및 삭제 기능으로 이미 어느 정도 코드 작업이 되어있었지만, 업체가 직접 입출고서를 수정하는 것에 대한 위험성 때문에 사용하지 않고 있었다. 하지만 기획 요청에 따라 현재에는 FASTBOX에만 수정, 삭제 기능을 제공하고 추후 입출고서 수정이 되지 않는 방향으로 기능을 보완할 예정이다.
5차 프로젝트를 마치며
기존 로직의 일부를 수정하거나 아예 새로운 기능을 만드는 등 다양한 개선 작업이 진행되었는데 API개선이다 보니 가시적으로 보이는 성과는 크지 않았지만 일감을 하나씩 완수해나가면서 뿌듯함을 느꼈다. 시간의 압박과 구조적인 부분에 대한 이해 부족으로 원하는 수준의 코드 퀄리티가 나오지는 못한 것 같아 아쉬움이 남지만 앞으로는 작업 과정에서 더 좋은 대안이 있진 않을지 자주 고민해보며 코드 품질의 수준을 높이기 위해 노력해야겠다고 생각했다.