Ionic & Cookie

아이오닉에서는 쿠키를 사용할 수 없다. 정확히는, 요즘 안드로이드 웹뷰에서는 보안상의 문제로 쿠키를 사용할 수 없게 막아놨고, 그로인해 안드로이드로 출시할 생각이 있다면 (아이오닉으로 개발하는 사람이 안그럴리가 없지만) 쿠키를 사용하지 않는 코드로 짜야한다는 것. 다행히 어지간한 플랫폼의 웹뷰는 localStorage를 지원하고, 좀 더 하드한 스토리지를 원한다면 Mozilla의 오픈소스 프로젝트인 localForage를 사용하도록 하자.

…라고 간단하게 끝나는 문제였으면 좋았을 것을. 생각보다 많은 자바스크립트 라이브러리들이 쿠키를 사용하는 방식이다. 왜냐하면 어지간한 상용 라이브러리라면 브라우저 지원범위가 가장 넓은 쿠키를 사용하는 것이 보편적이게 된 것. 그래서 유저 트래킹을 하기 위해 도입하려던 ahoy(이하 아호이)에서 프론트를 ahoy.js로 커버하려고 했는데, 웹에서야 자연스럽게 코드를 작성할 수 있었지만 앱에서 작성하려고 하니 내부적으로 쿠키를 사용하더라고.

그래서 ahoy.js 코드를 읽어보면서 조금 더 고민해봤다. 코드를 보다보니 쿠기뿐만 아니라, n개의 로그 데이터를 n번의 요청으로 처리하는 코드 등, 고쳐야할 부분이 적잖아 보였다. 쓰려고 하면 쓸 수야 있겠는데, 과연 angular-dependent 하지 않은 코드로 짤 수 있을까? 짜는게 의미가 있을까? 짜면서 잃는 나의 기회비용은 어떤게 있을까?

angular2와 rails5가 발표되고 적당히 안정되는 시점에 프론트엔드와 백엔드의 프레임워크를 몽땅 교체할 생각인데, (이것도 확정은 아니다, 리액트도 고려중…) 굳이 이 느린 angular1에 의존적인 코드를 짜는 게 맞을까. 그래도 이왕 짠다면 앵귤러 도움없이 xhr로 짜는게 어떨까… 등등

그러던 중에 기존에 루즈하게 사용하던 mixpanel에서 localStorage로 init할 수 있는 옵션이 있다는 것을 알게 되어 믹스패널을 유저 트래킹에 사용하는 것을 적극적으로 고려하는 중이다. 사실, 믹스패널로 revenue 추적하는 것이 디비에서 긁어온 것과 너무 다른 결과를 보여줘서 버려버릴 생각이었는데, 극단적으로 로그가 20% 쯤 누락되어도 경향만 파악하면 되는 것이 프론트엔드 유저 트래킹이라서 믹스패널이 결국 무난하지 않을까하고 고민 중. 가격을 떠나서 믹스패널의 기능은 강력하니까!

 

Leave a Reply