[회고] 개발자, 플레이윙즈, 2017년
2017년. 이 글을 읽는 여러분들은 어떤 해였는지 우선 질문을 드려본다. 머리 속에서 제일 먼저 생각나는 순간들을 기억해보고 단어들로 정리를 하면 그것이 2017년 보냈던 의미들을 정리하는 것이 될 것이다.
나한테 있어서 2017년은 ‘도전, 커뮤니케이션, 정복’ 으로 정리되는 해였다고 생각한다. 이 단어들이 어떻게 나왔는지는 나날이 적으면서 2017년을 돌아보기로 하자.
도전
엔지니어 커리어의 시작은 Android였다. 전자재료학과를 나온 나로써 Android를 개발을 할 수 있게 된 것만으로도 많은 흥분과 학습에 대한 욕구를 채울 수 있었다. 그리고 2016년 중반부터 안드로이드를 개발하기 위해 쓰이는 Java 언어를 활용하여 Spring Boot, Java8, JPA(Hibernate), Redis, MySQL(AuroraDB)를 활용하여 Production Server 및 신규 서버들의 개발 및 유지보수를 할 수 있게 되었다.
하지만 2017년은 여러 욕심이 커지는 해였다. 나와 개발팀이 개발하고 있는 Product들을 떳떳하게 공개해도 될 만큼 양질의 코드들과 안정적인 서비스가운영되기를 희망하였다.
Android는 여러 신규 라이브러리 도입을 통한 안정적인 서비스 관리를 시작 할 수 있었다. 수많은 작업들이 있었지만, 기억에 남는 것 중에서는 우선 Realm을 도입을 하였다. Production Server와의 통신 중에서도 불필요한 서버 통신을 줄일 수 있도록 한번 받은 정보에 대해 Realm에 저장하여 활용할 수 있도록 하였다. 또한 RxJava와 연동하여 비동기적으로 insert 및 select, update와 관련된 처리를 할 수 있도록 하였다. Bitrize를 통해코드 테스트 및 플레이스토어까지 5% 릴리즈를 할 수 있도록 하였다.
Server는 이전 개발자의 코드의 울타리에서 벗어나 명확성을 증가시킬 수 있도록 Clean Architecture를 할 수 있도록 노력하였다. 여기서 Clean Architecture의 정의는 1) 이해하기 쉽고 2) 유지보수하기 쉬운 구조를 뜻한다. 난잡하게 짜여져 있었던 코드들을 Controller단에서 Service단으로 모두 이동하였고, Service 내 동일한 코드들은 Util로 이동하고 Redis의 다양한 key값들을 깔끔하게 정리하는 등의 노력을 기울였다. 하지만 안타까운 점은 꾸준히 진행하였음에도 모자란 부분이 있어서 2018년에도 꾸준한 노력이 필요할 것이라 생각한다.
커뮤니케이션
사람간에 오가는 똑같은 단어는 어쩌면 그렇게 각자 마음속에 다르게 울릴지 모르겠다. 굵직굵직한 기획들이 많았던 해인만큼 다양한 팀들과 다양한 방식의 이야기들을 진행해야 했다.
원론적인 이야기겠지만 말하고 싶은 점은 기획을 위한 커뮤니케이션을 위한 스탭들이 존재한다는 점을 깨달았다. 처음에는 배경과 기획의 목표를 설정하는 것부터 시작한다. 배경과 목표가 정리 되었다면 스케쥴링과 세부 목표들 및 완료시 체크해야 할 것들을 정리해야 한다. 이후 스케쥴대로 개발에 대한 집행을 하며 체크일에 맞춰 목표들을 점검하는 방식을 채용하는 것이다.
물론 아직도 커뮤니케이션을 위한 길은 멀고도 험하기에 2018년에는 사람들을 ‘잘’ 설득시키고 하나의 방향으로 나아가길 희망한다.
정복
데이터. 많이 쌓으면 쌓을수록 좋기는 하지만 막상 쓰려면 어디서부터 열어서 활용해야 할지 모르는 데이터. 데이터 사이언티스트가 합류한 이후로 플레이윙즈는 사용자들에게 더 적합한 상품을 푸시로 보내거나 상품이 노출되기를 꿈꾸기 시작했다.
하지만 클러스터링을 구성하기 위한 작업은 험난하였다. 우선 사용자에게 필요한 정보들을 선별하는 작업부터 시작하였다. 가정은 각각의 유저마다 각각의 특징이 있다고 가정하였다. 이 가정이 중요한 것은, 특히 다른 서비스에서 이 기획을 진행할지 판단할때, 사용자들의 행동 패턴에 특별한 의미가 없거나 모두 동일한 행동을 하고 있다고 판단된다면 클러스터링을 할 의미가 없어지게 된다.
앞의 가정을 토대로 사용자들의 행동들은 익명으로 서버에 보고 되었으며 이 raw 정보들을 fluentd에 취합하여 s3에 저장하였다. 대용량의 정보들을 수집하는데 많은 고민들을 하여 반영하였고 이에 대한 자료들은 많은 편이었다.
그리고 기획을 통해서 정했던 유저의 행동에 대한 의미 부여 테이블이 존재하며, 이를 기반으로 기록 및 분석을 하였다. 최종적으로 분석된 정보를 통해 유저의 특징에 따라 클러스터링하였고 세부적으로 유저의 활동도에 따라 세부군을 다시 재분류하였다.
결과적으로 클러스터링 정보를 통해 컨텐츠 노출과 사용자 푸시에 활용되었다. 실제 이를 활용하여 컨버전률을 관리하고 있으며 기획 의도대로 작동하고 있다고 판단하고 있다.
만약 다른 서비스에서도 클러스터링을 기획한다면, 이야기하고 싶은 점은 생각보다 개발보다 기획적 측면에서 많은 시간이 소요될 것이다. 또한 클러스터링을 통해 얻고 싶은 점을 명확히 한다면 생각보다 쉽게 클러스터링을 할 수 있을 것이다.
2018년에는
무엇을 하고 싶은가. 나는 Coder로서 발전 욕심도 있고 Lead Developer로서 기획과 의견조율 및 비저닝을 하고 싶은 욕심 또한 있다. 그렇기 때문에 2018년에는 길을 다시 한번 체크하고 점검하고 방향을 다시 재정립하는 해가 되기를 기도한다.
