테스트, 테스트, 테스트
출시 전 서비스 고도화 하기
앞에 글에서 이어지는 글입니다.
1. 애널리틱스4를 신뢰하지 않는 이유
2. 네이버페이 데이터 수집은 불가능?
3. 서버사이드 GTM이 정답일까요?
4. 개발자센터를 사용해 봅시다.
5. 개발하면서 만난 문제점들
6. 테스트, 테스트, 테스트
7. 리글린(RE:GLEAN)을 소개합니다.
대기업에서 개발자로 오래 일하신 아는 형님이 했던 말씀이 생각납니다.
개발자가 갖추어야 할 덕목은
첫째도 테스트, 둘째도 테스트, 셋째도 테스트 다.
테스트를 얼마나 꼼꼼히 하느냐가 완성도를 결정한다.
저도 백프로 동의합니다. 그래서, 저는 테스트 기간을 두달을 잡았습니다. 테스트하면서 서비스를 고도화할 예정이라서 충분한 시간이라고 생각이 들었습니다.
이번에는 테스트를 계속 진행하면서, 서비스 고도화시켰던 내용을 이야기해보겠습니다.
1. 기본은 웹GTM 으로 처리, 웹GTM 이 처리하지 못한 주문을 서버GTM 이 보완
모든 데이터를 서버GTM 으로 처리하는 게 아니라, 기본적으로는 웹GTM 을 사용하여 애널리틱스4 데이터를 수집합니다. 웹GTM 에서 처리하지 못하거나 누락된 주문들, 예를 들어 네이버페이 같은 주문과 광고 차단 프로그램 또는 사이트 오류로 누락된 주문들을 서버GTM 으로 처리합니다.
웹GTM 으로 이미 기록된 주문들은 서버에서 중복제거를 하여, 이중으로 처리되지 않도록 만들었습니다. 애널리틱스4 의 주문 중복제거가 잘못 작동할 여지를 전혀 남겨놓지 않았다고 생각하시면 됩니다.
따라서, 해당 서비스는 웹GTM 과 서버GTM 이 통합되어 작동합니다. 서로 독립적으로 작동하지만, 한쪽에서 아예 수집이 안되는 경우가 발생한다면, 정합성에 문제가 발생할 수 있습니다. 하지만, 문제가 발생되면 바로 로그를 기록하도록 처리해놓았기에 오히려 웹GTM 만 처리할때보다 더 안정적으로 서비스가 가능할 것 같습니다.
2. 안전장치를 꼼꼼하게 설계하여 전송 오류를 원천차단 합니다.
서비스는 기본적으로 정합성을 99% 이상 맞추는 것 을 목표로 설계되었습니다. 따라서, 예상하지 못한 오류가 발생해도 안정적으로 작동하도록 만들었습니다.
API 호출로 받은 JSON 데이터는 서버에서 중복 여부를 체크합니다. 중복된 주문이면, 스킵하고 새로운 주문만 처리합니다. 여기에서 별도 마커를 생성합니다.
새로운 주문들은 서버GTM 에 보낼 데이터로 가공합니다. 끊어진 사용자 정보를 이어 붙이는 작업도 이때 진행됩니다.
서버GTM 에 데이터를 정상적으로 전송했다면, 로그에 전송에 대한 로그를 남기도록 설계했습니다.
만약, 새로운 주문 마커에 실패하거나, 가공에 실패하거나, 전송을 실패하는 등, 단계별로 오류가 발생한다면 모든 과정을 롤백하도록 처리했습니다. 그리고, 어디에서 롤백이 되었는지 로그를 남기도록 설계하였습니다.
롤백된 주문은 다시 수집하여 위 과정을 처음부터 진행합니다. 즉, 알 수 없는 오류가 발생하거나 심지어 서버가 박살나도 정상적으로 전송이 될 때까지 로직이 계속 굴러가도록 설계하였습니다.
3. 쇼핑몰마다 독립적인 서비스 컨테이너로 작동합니다.
처음부터 3천개 이상의 쇼핑몰도 안정적으로 작동할 수 있는 서비스로 설계하였습니다. 계획한 로직을 처리하면서 조금이라도 가벼울 수 있도록 최신 기법을 사용하였습니다.
추가로, 앞에서 설명한 로직이 안정적으로 돌아갈 수 있도록, 공용 서비스 컨테이너가 아닌 독립적인 컨테이너로 설계하였습니다. 한번에 데이터가 모일 것도 감안하여, 비동기 병렬처리 로직도 추가하였습니다.
일 4~5천 건의 데이터도 안정적으로 처리되며, 심지어 동시 1000건의 과부하 테스트도 안정적으로 통과 테스트를 완료하였습니다. 이 정도면 실 서비스에서도 아무런 문제가 없을 것으로 생각됩니다.
4. 환불과 취소 건도 같이 처리합니다.
이렇게 잘 만든 서비스에서 구매만 처리하는건 너무 아깝다고 생각이 들었습니다. 그래서, 주문취소 및 환불건도 수집하여 애널리틱스4 refund 이벤트로 전송을 추가하였습니다.
애널리틱스에는 취소와 환불 구분이 없습니다. 그래서, refund 로 통일해서 보내고, 결제수단에서 cancel 과 return 을 별도로 구분하도록 처리하였습니다.
애널리틱스4 에서 환불건과 취소건에 대한 데이터를 보고 싶었던 클라이언트들이면 아주 만족하실 것으로 생각합니다.
5. META CAPI 와 TikTok EVENT API 를 추가하였습니다.
처음부터 확장을 고려하고 설계하였기에 테스트하면서 메타와 틱톡의 API 연동 기능도 추가하였습니다. 메타와 틱톡 API 는 정말 까탈스럽더군요. 조금만 이상해도 그냥 오류를 뱉어내서 고생이 많았습니다.
사실 처음에는 서버GTM 에 공식 태그가 있는 것 을 보고 쉬울 것 같다고 생각했습니다.
커뮤니티 템플릿 갤러리의 공식 태그들결론부터 이야기하자면, 메타는 그래도 쓸만합니다. 하지만, 틱톡 공식 태그는 기본 상태로 사용하지 못합니다. 공식 템플릿인데 잘못된 부분이 꽤 많이 있습니다. 뭐, 어쩌겠습니까? 위에 이미지에 보이시죠? 네. 맞습니다. 태그 자체를 제가 수정하였습니다. 그러니까 좀 낫네요.
추가로, 메타와 틱톡 전부 서버 이벤트 테스트를 지원하는데, 이벤트 테스트에서는 오히려 메타가 좀 이상했습니다. 틱톡은 반응이 바로바로 오는데, 메타는 조금 굼뜨더군요. 왜 안되지? 생각했는데 나중에 이벤트가 잡히는 경우도 더러 있었습니다.
6. 운영을 위한 몇 가지 서비스를 추가했습니다.
기본적으로 서버로 작동하는 서비스라서, 매일매일 서버운영에 대한 비용이 발생합니다. 따라서, 정해진 기간이 지나면 만료 알림이 필요했습니다.
이 부분을 관리할 라이선스 매니저라는 이름의 서비스를 하나 추가로 개발했습니다. 지정한 날짜가 되기 전에 메일로 알림을 해주고, 만료되면 서비스를 닫아버리는 아주 강력한 녀석을 만들었는데, 걱정했던 것보다 쉬웠고 생각보다 잘 작동하더군요.
만료 7일 전에 보내는 메일입니다.서비스를 시작하면서 로그를 계속 확인해야 할 텐데, 이왕 확인해야하는 것 조금 이쁘면 좋겠다는 생각이 들었습니다. 그래서, 데이터를 BigQuery 로 수집하고, Looker Studio 로 연동했습니다.
역시 보기 좋은 떡이 먹기도 좋다고 했습니다. 생각했던 것보다 결과물이 이쁘게 나와서 자주자주 확인할 수 있을 것 같습니다. 추후 서비스를 적용한 몰 별로도 공유를 해줄까 고민이 되기도 하네요.
마지막으로 이 잘 만든 서비스에 이름이 필요했습니다. 웹GTM 이 수집하지 못했거나 누락한 데이터들을 다시 수집한다는 것에 집중하였고, 다음의 단어를 선정하였습니다.
glean
1. (원래) 추수 끝난 밭에서 이삭을 줍다.
2. (확장) 정보나 사실을 여기저기서 조금씩 모으다. 수집하다
단어 자체가 제가 만든 서비스 컨셉과 미친듯이 맞는다고 생각합니다. 추가로 제가 운영하는 사이트 이름을 결합하였습니다. 그렇게 만든 서비스 이름은
RE:GLEAN(리글린)
입니다.
열심히 서비스해보겠습니다. 많이 응원해주세요~
그럼, 마지막 글로 이어가겠습니다.
➡️ 리글린(RE:GLEAN)을 소개합니다.
