개발하면서 만난 문제점들
개발이 끝나지 않는다.
앞에 글에서 이어지는 글입니다.
1. 애널리틱스4를 신뢰하지 않는 이유
2. 네이버페이 데이터 수집은 불가능?
3. 서버사이드 GTM이 정답일까요?
4. 개발자센터를 사용해 봅시다.
5. 개발하면서 만난 문제점들
6. 테스트, 테스트, 테스트
7. 리글린(RE:GLEAN)을 소개합니다.
API 호출까지 진행하고, 응답 파일들을 뜯어보면서 서버GTM 으로 전송할 데이터들을 설계했습니다. 생각나는 문제점 중에서 굵직한 것 들을 정리해 보겠습니다.
1. 테스트할 쇼핑몰이 없었습니다.
API 호출은 잘 되는지, 응답 데이터는 어떤 구조인지 테스트를 위해서는 실제 주문량이 많은 쇼핑몰이 필요했습니다. 카페24는 쇼핑몰을 쉽게 만들 수 있기 때문에, 테스트용 쇼핑몰을 만들어서 무통장입금으로 주문을 만들어서 테스트했습니다.
근데!! 그런데!!
어느날 갑자기 무통장입금이 안되더군요.
무통장입금 설정이 비활성화 되었습니다.주문서작성에서도 사라지고, 결제수단에서도 아예 선택조차 안되도록 바뀌었습니다. 그래서, 카페24 고객센터에 1:1 문의를 올렸습니다. 그리고 받은 답에는
오 마이 갓... 정말 오 마이 갓 이었습니다.
정말 눈앞이 깜깜했습니다.
그래서, 어차피 무통장입금으로 주문 몇 건 테스트하는 건 답이 아니다는 생각에 처리했던 업체 중에서 주문이 많고, 담당자와 소통이 잘되는 쇼핑몰에 부탁을 해보았습니다. 혹시 제가 개발하고 있는 서비스를 위해서 쇼핑몰을 테스트해도 되냐는 부탁이었습니다.
정말 흔쾌히 허락해 주시더군요. 심지어, 해당 쇼핑몰은 일평균 200건 이상 주문이 발생하는 쇼핑몰이었습니다. 나중에 알았지만, 이벤트를 진행하면 일 3~4,000건의 주문도 발생하는 엄청난 쇼핑몰이었습니다.
해당 쇼핑몰의 주문정보를 테스트할 수 있어서, 원하는 데이터를 넘치도록 얻을 수 있었습니다. 운이 좋았다고 생각합니다.
2. 정보가 너무 부족했습니다.
다시 언급하지만 네이버페이, 카카오 톡체크아웃의 주문을 수집하는 방식은 국내에만 존재하는 특이한 형태입니다. 그래서, 해당 문제를 해결하기 위한 정보가 턱없이 부족했습니다.
해외의 자료를 뒤지고 뒤지고 뒤져봐도 도움이 되는 자료는 많이 없었습니다. 그나마 애널리틱스4 전문가로 유명한 Simo Ahava(https://simoahava.com) 라도 있어서 다행이었다고 생각합니다.
애널리틱스4 전문가 Simo Ahava서버GTM 에 대한 자료는 대부분 웹GTM 에서 서버GTM 으로 보내고, 다시 애널리틱스4 로 전송하는 내용에 대한 것이었습니다.
일반적인 서버GTM 활용방식(출처: Google)왜 굳이 웹GTM 에서 다시 서버GTM 으로 데이터를 보내서
전송을 하는지 도저히 이해할 수 없었습니다.
이렇게 전송을 하는 최소한의 이득이 있어야 할 텐데, 서버GTM 에서 여러 도착지(예를 들어 Meta 나 TikTok 등)로 전송한다는 것 을 제외하면 어떤 이득이 있을까 의문만 생겼습니다. 그리고, 이 방식이 과연이 서버GTM 을 사용하는 옳은 방식인지도 궁금해지더군요.
그리고, 또 다른 정보들은 대부분 마케팅을 잘했는지 Stape(https://stape.io) 를 사용하는 방식에 대한 소개였습니다.
Stape Server GTM Hosting(출처: Stape.io)제가 처리하려는 방식은 쇼핑몰에서 API 로 주문정보를 수집하고 가공하여 서버GTM으로 전송하려는 것이라서 해외에서 찾은 대부분의 사례가 해당하지 않았습니다. 자료를 찾으면 찾을수록 앞이 보이지 않는 길을 걷는 느낌이 강했습니다.
그래서, 진짜 맨땅에 헤딩하면서 하나하나 테스트하면서 개발했습니다. 이 과정이 너무 힘들었던 기억이 납니다.
3. 애널리틱스4의 주문 제거가 잘 이루어지지 않았습니다.
어떻게어떻게 서버GTM 을 통해서 애널리틱스4 에 전송을 해보았습니다. 실시간 데이터에 데이터가 확인되어서 이제 끝났다 싶었습니다. 하지만, 열심히 테스트해보고 다음날 애널리틱스4를 열어보고 깜짝 놀랐습니다.
동일한 주문번호로 결제금액이 엄청나게 높게 잡혀 있었습니다.
그리고, 알았습니다. 애널리틱스4 의 주문 중복제거는 단순히 주문번호 즉, transaction_id 로만 처리하는 게 아니라는 것 을..
동일한 transaction_id 라도 완전히 새로운 데이터라면, 합산되거나 새로 기록됩니다. 그래서, 이 문제를 해결하기 위해서 서버에서 중복을 확인하고 제거하는 로직을 추가하였습니다. 이 부분을 처리하면서 애널리틱스4 구조와 서버에서의 작동방식에 대해서 꽤 많이 이해하게 된 것 같습니다.
몇차례 개선을 한 결과, 중복제거 로직은 아주아주 잘 작동하는 것 을 확인하였습니다.
4. 데이터가 (not set) 으로 기록됩니다.
개발을 전부 완료했습니다.
그리고, 몇 가지 추가적인 기능을 붙이고 있었습니다. 인증 방식과 라이선스 매니저등 서비스에 필요한 기능들을 하나하나 추가했습니다.
데이터는 아주아주 잘 수집되고 있었습니다.
모든 게 완벽해 보였습니다.
우연하게 거래처에 해당 서비스에 대한 설명을 하려고 보여주다가 아주아주 이상한 부분을 발견했습니다.
서버에서 전송한 모든 데이터가 (not set) 으로 기록되고 있었습니다. API 에서 가져온 정보를 애널리틱스4 로 전송하니 어떻게보면 (not set) 이 당연한건데, 발견하기 전까지는 전혀 예상하지 못했습니다.
사실 조금 절망적이었습니다.
어떻게 해결해야 할지도 모르겠고, 해결이 가능한지도 전혀 알 수 없었습니다. 이렇게되면 매출 기록은 잘되겠지만, 어디에 쓸 수 있을까? 쓸모없는 데이터가 아닐까 싶었습니다.
며칠 동안 수정하고 테스트하고, 수정하고 테스트해도 문제가 해결되지 않더군요. 진짜 절망적이었습니다. 이건 나 혼자 해결할 수 있는 문제가 아니다고 판단이 들었습니다. 그래서, 아는 전문가에게 도움을 요청하였습니다.
바로 허들러스(https://hurdlers.kr)의 유성민 대표님입니다.
(주) 허들러스 유성민 대표(출처: 허들러스 홈페이지)오랜만이었지만 바로 본론부터 이야기했습니다. 네이버페이를 수집하기 위해서 개발을 하고 있는데, 막힌 부분이 있어서 조언을 얻고자 연락했다고 했습니다.
그리고, 알았죠.
허들러스도 이미 비슷한 서비스를 개발하다가 바로 이 (not set) 때문에 포기했다는 것 을요. 심지어, 시장에 나와있는 많은 업체들도 이 부분에서 막혀서 포기했거나 불완전하게 서비스하고 있다는 것도 알게 되었습니다.
대표님은 본인들이 겪었던 문제점을 아주아주 상세하게 알려주었고, 해결하기 위해서 했던 노력까지도 아낌없이 공유해 주셨습니다. 허들러스는 이미 개발중인 프로젝트가 너무 많아서, 끝까지 만들지 못했다면서 응원한다는 말씀까지 해주시더군요.
그렇게 내용을 전달받고, 다시 방법을 찾고찾고 수정하고
테스트하고 드디어 해당 문제를 해결했습니다.
끊어진 사용자 정보를 다시 서버에서 이어붙이는 로직을 추가하여 적용하였고 애널리틱스4 보고서에도 정상적으로 기록되는 것 을 확인하였습니다.
유성민 대표님은 본인은 몇 마디 해주었을 뿐, 실제로는 도움 준 게 없다고 합니다. 저는 그렇게 생각하지 않습니다.
유성민 대표님의 인사이트 덕분에 이 서비스가 나올 수 있었다고 생각합니다. 진심으로 고마운 마음을 전합니다.
사실 개발하면서 만난 문제점들은 엄청나게 많이 있습니다만, 대부분은 갖고있는 지식내에서 해결할 수 있는 부분이었다고 생각하기에 이번 글도 이 정도에서 마치도록 하겠습니다.
다음 글은 테스트를 하면서, 서비스를 고도화시켰던 내용을 이야기해보겠습니다.
