정신없는 한 달이 지나갔다. 2023년의 3월은 아쉬움이 많은 달이었다. 개인적으로 힘든 일도 있었고, 자꾸 잡생각이 들어서 내가 해야할 것에 온전히 집중하지 못했다. 취업의 불확실성이 자꾸만 불안함의 감정을 만들었고 집중하려는 나를 방해했다. 적당한 스트레스는 좋지만 집중을 방해할 정도라면 마음을 다잡을 필요가 있는 것 같다.
회사에서의 한달
200개에 육박하는 데이터베이스 테이블, 십 여개의 monolithic한 모듈, 그 속에 난해한 스파게티 코드와 버그를 일으키는 코드들. 코드 퀄리티는 정말 너무나도 아쉽다. 회사 대표님은 지금보다 더 크고 원대한 꿈을 가지고 계시지만 감히 한마디 하자면 이제는 서비스를 확장할 때가 아니라 난잡한 코드들을 클린하게 리팩토링 해야할 때라고 생각한다. 급박하게 굴러가는 스타트업에서 힘든 결정일테지만 이런 시간이 필요하다고 확신한다.
업무 정리
결제 취소 API 분리
직접 필요성을 느껴서 결제 취소 API 분리를 요청했다. 현재는 결제 취소를 요청하면 (사용자가 결제 취소 요청 후 바코드를 가져다 댄다.) 하나의 API 안에서 Validation을 체크한 뒤 통과하면 결제를 취소한다. 해당 API는 키오스크와 연동이 되어 있는데, 키오스크 내에서 결제 취소 중간에 취소를 해버리면 우리의 API는 호출이 되어 취소 처리가 되고 키오스크 내에선 결제 취소를 취소했다고 판단하여 정상 결제건으로 취급해버린다. 그래서 프로세스를 다음과 같이 바꾸자고 제안했다.
- 결제 취소 가능 여부 API와 결제 취소 API로 분리
- 결제 취소 가능 여부 API 호출하여 가능 여부 판단
- 결제 취소 가능한 경우, 키오스크 내에서 먼저 결제 취소 처리
- 그 뒤에, 우리의 결제 취소 API를 호출하여 실제 결제 취소 처리
위와 같은 프로세스로 수정하기로 결정이 됐고, 이미 짜여져 있는 API를 분리하는 작업이라 어렵지 않게 끝낼 수 있었다. 다만 왜 처음부터 분리를 해놓지 않았는 지 의문이 들었고, 실제 메소드 명이랑 다른 작업을 하는 코드가 간간히 보여서 아쉬움이 남는다.
기업체 설정 정보 수정
UPDATE query를 날릴 때 AdjustType이라는 타입을 갱신해주는 데 String 취급해서 빈 문자열인지 확인한 뒤에 값을 입력해주는 방식으로 코드가 짜여져 있었다. 이는 Invalid Comparison Error를 야기했고 개발 당시 단위 테스트를 했다면 충분히 잡을 수 있는 에러였을 거라고 생각한다.
의문의 결제 취소 요청
식당 매니저 말에 따르면, 키오스크 내에서 결제 취소 요청을 하지 않았는데 결제가 취소되었다고 CS가 들어왔다. 의문을 품고 로그를 확인해봤는데 결제 취소 API가 호출이 되었음을 확인했다. 해당 작업을 하면서 아무런 의문을 품지 않고 결제 취소 API에 문제가 있구나 판단하여 몇 시간 동안 관련 코드를 뒤져보았다. 결론부터 말하면 잘못된 가정이었다. 논리적으로 생각해보면 결제 취소 API 로그를 확인했으면 우리 쪽 문제가 없음을 인지했어야 했는데 로그를 확인하며 디버깅하는 것이 익숙하지 않아 실수를 범했다. (이로 인해 5시간동안 뻘짓함..)
에러가 발생한 이유는 정말 놀랍게도 우연의 일치였다.
상품을 주문하여 결제를 하면 키오스크에서 externalOrderId를 생성하여 우리에게 전달하고 우리쪽에서는 externalOrderId를 사용하여 결제 취소를 요청한다. 우리 회사는 2개의 키오스크 회사와 계약을 맺었는데 다음과 같은 이유로 에러가 발생했다.
- 2개의 키오스크 회사는 전혀 다른 회사임에도 externalOrderId 만드는 방식이 우연의 일치로 같았는데 현재 시간의 ms초를 사용하여 orderId를 생성한다.
- 어떤 두 개의 주문이 각각 다른 장소에서 ms까지 같은 시간에 주문을 하여 externalOrderId가 생성이 되었고 unique 해야하는 값이 그렇지 못하게 되어 우리쪽 DB에 저장됐다.
- 두 개의 주문 중 하나의 주문이 취소를 요청했는데 다른쪽 주문이 결제가 취소가 된 것이다.
사전 결제 취소 관련 에러
1 ) 고구마츄 사전구매수량 5개 -> 5명이 구매후 1명이취소 -> 구매가능수량 1개인데 구매가 안됨 2) 구매가안되서 사전구매수량 5개-> 6개로 변경 3) 그래도 구매가 안됨
먼저 후자의 경우, 사전구매수량 5개를 6개로 변경했음에도 반영이 안된 이유에 대해 코드를 분석했다. 처음 사전결제 메뉴를 등록할 때 사용하는 TABLE이랑 이후에 사전결제 메뉴를 구매할 때 수량 체크를 위해 보는 TABLE이랑 분리가 되어 있는데 두 개의 TABLE다 반영하지 못하고 등록할 때 사용하는 TABLE에서 수량만 변경해주는 오류를 찾아 수정했다.
전자의 경우, 구매 취소를 누르면 수량 체크를 위해 보는 TABLE의 구매 수량을 ++해주어야 하는데 UPDATE query에서 parameter를 적절히 전달하지 못해 update가 안되어 수정을 해주었다.
이번 주는 에러가 많이 발생해서 CS 업무만 주로 보았다. 그래서 새롭게 배운 점은 딱히 없었고, 코드 분석을 더 빨리할 수 있는? 능력을 기를 수 있었던 것 같다.
어느정도 업무에 적응을 해서, 앞으로는 사소한 업무까지는 기록하지 않으려고 한다. 주로 배웠던 것, 그리고 앞으로 공부해야할 것 위주로 회고를 적을 예정이다.
