WebView는 웹이라는 자유롭고 성능좋은 도구를 어플리케이션에서 활용할 수 있도록 하는 도구입니다. 그리고 이 웹뷰를 활용하는 방법은 놀라울 만큼 간단합니다. 각 OS 웹뷰 모듈을 호출해서 원하는 웹페이지 주소를 입력하면 끝이에요. 웹만 잘 만들어 놓았다면 호출하는 순간 잘 만들어진 서비스가 됩니다.
하지만 앱에서만 처리할 수 있는 일이 있고, 앱에서 처리하면 더 좋은 문제들이 있습니다. 그러기 위해선 앱과 웹이 소통하면서 서로가 필요한 일을 잘 수행해야해요. 그렇기 때문에 앱-웹 간 통신은 정말 중요한 문제에요.
오늘 다뤄볼 문제는 앱-웹 간 통신하기입니다.
이벤트 트래킹은 데이터 기반 의사결정을 위해 필수적인 장치입니다. 우리의 설계 내에서 유저가 어떤 액션을 하거나 노출되었을 때 특정 이벤트가 발생했다고 생각하고 서버에 기록합니다.
그럼 이벤트의 트리거일 때 전송하면 되는거 아닌가?
이게 일반적인 생각이고, 제가 처음 합류했을 시기에도 그렇게 작성되어 있었으며 별 문제가 없었습니다. 허나 시간이 지나니까 문제가 되더라구요. 수집하고 싶은 데이터가 많아지고 하고싶은 실험의 수가 많아지고 컴포넌트끼리 겹치다보니 클릭 한 번, 페이지 진입 한번에 수십개의 API가 호출되고 있었고, 이벤트 처리 서버가 툭하면 죽었습니다.
제가 이벤트 대량 전송 문제를 해결하기 위해 고민했던 내용에 대해 함께 알아봅시다.
기술적 정복자에 대한 아티클을 본 적 있습니다. 당신이 아무리 뛰어난 기술을 가진 엔지니어라고 한들, 이를 다른 조직에 적용하는 과정에서 그 집단 구성원에 대한 존중이 없다면 한낱 정복자에 지나지 않다고.
이 글이 충격적이었던 사실은, 제가 현재 조직에 처음 와서 여러 기술과 방법론을 도입했을 때의 상황과 비슷했다는 점 때문이었습니다. 당시 옛날 기술로 도배가 되어 있어 고통받던 동료 개발자들을 위해 개발자 경험을 올릴 수 있도록 기여해야겠다는 생각에 야근까지 자처하면서 다양한 신문물을 들여와서 적용시켰습니다.
그 결과 우리 팀 기술 스택은 꽤 많이 바뀌었고, 개발이나 관리에 있어 효율을 얻을 수 있었죠. 하지만 그 과정이 순탄치는 않았습니다. 기술 자체를 이해하지 못하는 사람도 있었고, 딱히 니즈가 없으신 분들도 있었어요. 오히려 과거의 기술들이 장점을 가진 경우도 있었죠. 어쩌면 저는 앞뒤사정을 확인하지 않고 무자비하게 회사 기술을 갈아엎었던 정복자라고 볼 수 있는 거에요.
플랫폼 서비스를 이용하는 사용자들이 제일 짜증나는 상황이 장애상황이라면, 개발자들에게는 그 장애상황이 왜 발생했는지 모르는 상황일거에요. 마치 형사들이 사건의 실마리를 하나하나 찾아가며 단서를 찾고, 범인과 그 동기 등을 분석하듯 저희도 장애가 발생하면 가장 효율적인 포인트부터 의심해가며 장애를 추적하고, 범인을 검거합니다. 물론 항상 잘 잡진 못하고요. 미제사건도 많아요.
오늘 알아볼 것은 이 에러 추적의 시발점이 되어주는 Sentry라는 에러 추적 도구를 잘 사용하는 방법입니다.
금요일에 회사의 한 개발자님이 멘토님을 한분 섭외해서 성장 세미나를 열어주셨는데 그때 들었던 말들을 곱씹어봅니다. 당연히 모든 게 정답이라고는 생각하지 않고 몇몇 이야기들은 알고 있었지만, 한번 다시 정리할 수 있었고 좋은 말들을 많이 들어서 감사한 시간이었어요.
세미나의 연사로 오신 분은 꽤나 유명하신 분이었는데, 개발 커리어도 탄탄하고 주니어 개발자나 대학생 멘토로서도 오래 활동하셔서 그런지 참석했던 주니어 개발자들의 고민을 잘 알고 있었고 질문에도 막힘없이 대답해 주셨던 것 같았습니다.