개요
환불에 대부분의 시간을 보내고,
파트너 페이지 기본 페이지 작업에 들어갔다.
그 이후에는, Admin에서 채팅을 오랫동안 보고 있지 않은 유저나,
튜터 or 셀러가 앱내 채팅을 오랫동안 보지 않을 경우,
카카오톡 알림톡을 보내도록 하는 기능을 구현했다.
3차 스프린트 기간: 24.08.02(금) ~ 24.08.16(금)
업무
환불 기능 추가
환불을 개발하고 있는데 옆에서 따르릉~ 따르릉~ 소리가 들렸다.
환불 담당자에게 환불 전화가 온 것이었다.
잠시 시간이 흐른 뒤, 따르릉~ 따르릉~ 소리가 다시 들렸다.
또다시 환불 담당자에게 환불전화가 왔다.
환불전화는 일반적인 CS와 달리, 종종 감정소모가 필요한 경우가 있고,
이미 대화가 양측이 합의된 경우에는 전화 패턴이 비슷해 같은 대답을 반복한다.
비로소 깨달았다.
이 기능 내가 늦게 만들수록 저 전화가 계속 오겠구나!
그렇다! 이 기능은 돈 뿐만이 아니라,
우리 팀원의 cs(Cㅡ트레Sㅡ)를 덜어주겠구나라는 생각이 들면서,
내가 얼른 잘 만들어야 우리 팀원이
조금이라도 점심시간에 기분 좋게 밥을 먹을 수 있겠다는 생각이 들었다.
하지만 생각만큼 빠르게 구현이 되지 않았다.
기획이 완벽하게 구성이 되어있지 않고, 큰 틀에서만 정해져 있었기 때문에,
세부적인 내용을 구현하고 피드백받고, 다시 바꾸는 일이 계속 반복이 되었다.
구현하다가 아주 작은 부분이지만, 약간의 오류처럼 느껴질 부분들일 것 같아
그냥 내보내기 양심이 찔려 CTO님께 보여드리면서 말씀드리면,
"음... 그렇다면 그러면 안되지 않을까요?" 라는 대답이 돌아왔다.
사실 자세하게 보면 모를수도 있는 사안들이지만
세세한 것까지 캐치하려면 만들던 것의 구조를 바꿔야하는 사안들이 있었어서,
할까말까하는 생각이 들었지만 그럴때마다 찔려서 여쭤보면
바로 반려를 해주셔서 초기에 이런 마음속 습관들을 고칠 수 있었다.
내가 편하면 유저는 불편함을 느끼고, 내가 불편해야 유저가 편하다.
조금은 더 어렵고 힘들더라도, 그것이 올바른 길이라고 느껴진다면 걷자.
편한 길에서는 성장이 없고,
불편한 가시밭속에서 배울 것이 많고 성장이 많다.
그래서 나는 이 정글같은 스타트업을 첫 회사로 입사한 것이 좋다고 느껴졌다.
이후 기능 개발과 개발팀의 QA라는 산을 넘어 완료되어,
서버 먼저 배포가 됐다. 새로 패치된 어드민 환불은 먼저 사용을 해보기 위해서였다.
결과는....!!!!!
머지한지 5분도 안되서 새로운 환불 코드에 error in lagacy라는 주석이 붙었다.
이전 환불기능으로 다시 롤백이 되었다.
(진짜 눈물 한 방울 나올뻔했다...)
그리고 오류를 발생시키는 원인을 스스로 찾아내야했다.
다행히 30분도 안되서 발견했는데 그 원인은,
기존 존재하던 로직을 건드린 곳에서 발생했다.
기존 존재하던 로직을 수정했으면, 새로운 로직과의 호환성을 테스트했어야했는데
그 부분이 수행되지 않았다.
그리고 해당부분을 새로운 로직과 호환이 되도록 한 뒤,
테스트를 거쳐 다음날 다시 서버에 배포되었다.
이제는 유저에게로 환불 권한을 일부 위임한 플로우에 대한 QA가 기다리고 있었다.
그동안 다른 티켓을 가져와 업무를 수행했다.
터득한 Point.
- 기존 로직을 수정할 때는, 새로운 로직과의 호환성을 생각하자.
- 기존 로직을 수정할 때는 정말 수정해야하는가 다시 한 번 생각하자.
- 때로는 100줄의 코드작성보다 5줄 코드 작성이 더 오래걸릴 수 있다.
- 불편하고 어려운 길 속에 성장의 기회가 있으니, 회피하지 말자.
(어차피 나중에는 가야하는 길이다.)
파트너 어드민 기본세팅 보완작업
이번 보완작업에는 아래와 같은 기능을 추가했다.
원래 예정되어 있던 것은 Bugsnag과 404페이지 개발만이지만,
추가적으로 아래의 기능들도 있으면 좋을 것 같아 추가 개발했다.
- Bugsnag 연동
- 404 페이지 개발
- MetaHelmet 컴포넌트 개발
- import/order 규칙 설정
Bugsnag연동
현재 우리 서비스는 Bugsnag과 Relic을 이용하여 모니터링을 하고 있다.
때문에, 해당 프로젝트에도 모니터링을 위해 Bugsnag과 연동을 해야했다.
그리고 이 Bugsang을 이용하여, Errorboundary를 작성하여
에러가 발생할 경우, 404페이지로 이동하도록 작업했다.
404페이지 개발
에러가 발생할 경우 이동할 페이지가 필요하여,
해당 페이지는 기존 우리 서비스의 404페이지를 기반으로,
필요없는 부분들을 제거하여 경량화한 버전으로 개발했다.
그리고 404페이지에서 이전페이지로 돌아가도록 할 때,
오류가 있던 페이지를 건너뛰고 뒤로 갈 수 있도록 했다.
MetaHelmet 컴포넌트 개발
기존 페이지의 제목을 useEffect를 사용하여,
처음에 마운트 될 때 페이지에 맞게 제목을 넣어주는 방식으로 수정했다.
같은 행동을 각 페이지마다 계속해야하는 방식이 불편하게 느껴져,
해당 프로젝트에서는 처음부터 이를 수정하는 컴포넌트를 개발하여
책임분리를 명확히 하고자 했다.
그리고 그와 동시에 해당 페이지의 메타 태그들을 수정할 것들이 있다면,
수정할 수 있도록 Option을 매개변수로 받도록 했다.
(react-async-helmet 라이브러리를 사용했다.)
import/order 규칙 설정
기존에 존재하는 이전 페이지들은 import하고자 하는 파일들이
어떤 것들이 있는지 명확히 눈에 들어오지 않았다.
import/order 규칙을 설정하여
파일구조를 통해 기능들을 분리한 것의 이점을 더 가져오도록 했다.
(@trivago/prettier-plugin-sort-imports 라이브러리를 사용했다.)
터득한 Point.
- 주어진 일만 하지말고, 현재의 상황을 개선할 방법을 찾자.
채팅 리마인드 기능 개발
처음으로 카카오톡 알림톡 기능을 개발을 맡게 되었는데,
기능을 구현하다 보니 복잡한 작업은 아니었다.
다이렉트 메시지를 통해 승인된 메시지 템플릿에 맞춰
서버에서 클라이언트로부터 필요한 데이터들을 받아 가공한 뒤,
@nestjs/axios를 통해 알림톡 URL주소와 가공한 데이터들을 post로 보낸 뒤,
반환된 Observable를 rxjs의 lastValueFrom 메소드를 통해 Promise로 변환하여 실행하고 난 return값을 토대로 에러핸들링을 하면 끝이 났다.
터득한 Point.
- Observable과 Promise의 차이
- rxjs의 toPromise, firstValueFrom, lastValueFrom 메소드 차이
