유저의 확보 -> 소셜 디스커버리 = 짬뽕 2 ~ 3일 -> 현재 가설을 위해선 유저 유지(며칠동안 탈퇴 x)가 필요하다 -> how? 탐색 -> 사용성 -> 탐색이 자유롭게 되어야 한다

프론트엔드의 아키텍처는 개발에 있어 상당히 중요하다. 다양한 이유가 있지만 역시 이후 개발의 편의성, 유지 보수가 가장 큰 중요점이다. MVVM이건 MVC건 FLUX건 모든 개발 아키텍처의 중점은 거기에 있다고 생각한다. 첫 회사에선 Redux를 이용해서 중앙 데이터 관리를 활용한 Flux패턴을 사용했고 이후 Angular를 사용하여 MVVM 비슷한 패턴을 쓰는 회사도 다녀봤고 지금은 mobx를 이용해서 Service-Store 방식으로 아키텍처를 관리하고 있다. 당연히 정답은 없지만 한가지 확실한 것은 이것을 지키기가 너무 어렵다는 점이다. 오늘은 미션 기능을 추가하면서 서비스-스토어 패턴으로 구현하기 위해 고민했던 부분을 이야기해본다.

앱에 채팅 시스템을 도입하려한다. 우리는 sendbird라는 솔루션을 사용하기로 했고 공식문서를 쭉 훝어보니 "음 생각보다 할만하겠는데?"라는 생각이 들었다. 그리고 그게 문제의 시작이었다. sendbird란 sendbird란 업계 1위의 채팅 솔루션으로 sendbird의 커넥션 자 sendbird의 과금 시스템은 MAU(월 사용자)와 Concurrent Connection(한순간의 총 커넥션)으로 결정된다. CC는 MAU의 5%로 가장 저렴한 서비스를 사용하면

서비스에서 가장 중요한 인사이트는 당연히 유저 정보와 유저의 이벤트(액션)이다. 이런 데이터들이 추가한 기능에 대한 평가, 다음 기획의 방향성을 결정하게 된다. 특히 사업 초기 정량적인 평가가 어려운 경우 인사이트를 얻기위해 이러한 이벤트는 생각보다 유용하게 활용된다. 마케팅 팀의 주장으로 앱에 Amplitude라는 분석 솔루션을 도입하게 되었다. 도입하기 전에 기존에 GA(구글 에널리틱스)가 앱에 심어져야 있었는데 앰플리튜드를 심는 이유가 궁금하여 찾아보니 해당과 같은 글을 찾아볼 수 있었다. 반쯤은 못 알아들었지만 결국 조금 더 쉽고 서비스 중심적인 솔루션으로 보인다.

오늘은 가벼운 이야기, 피처를 추가할 때 어떤식으로 할까를 이야기해보자. 기능, 소위 피처(feature)를 추가할 때 작업은 언제나 어려움, 갈등, 변경의 연속이다. 기획레벨에서 모든게 정리되어 개발팀과 디자인팀으로 내려오면 이상적이겠지만 그럴리가 전혀 구체화되지 않은 아이디어 레벨의 기획이 내려오는 경우도 종종 있고, 개발 도중 기획이 바뀌는 경우도 적지않다. 개발일을 처음 했을 때는 이러한 부분에 맹목적인 불만을 가졌지만 지금에서는 이러한 부분이 서로 잘 모르기 때문에 발생하는 것이라는 것을 알기에 어떻게 잘 풀어나갈지를 고민하게 된다. 물론 스타트업 레벨의 회사만 다녔고 가장 큰 회사가 대략 80명 내외에 개발팀이 30여명 쯤 되는 회사였으니 더 큰 규모나 다른 회사의 경우는 어떨지 모르지만 적어도 내경험이 다른 사람에게 도움이 됬으면 한다. 피처의 정의 일단 피처의 개발은 2가지가 있다고 생각하는 편인데, 하나는 기존 기능의 개선, 두번째는 아예 새로운 기능의 추가이다.

앱 개발에서 가장 번거롭고 귀찮은 시간을 꼽자면 앱이 심사되고 배포될때까지의 시간일 것이다. 구글의 경우 체감상 2시간 내외면 심사가 마무리되지만 애플은 통상 하루의 시간이 걸리고 반려되는 경우엔 며칠을 소모하는일도 빈번하다. 평상시에는 그냥 늦어지나보다 싶지만 크리티컬한 버그가 발생한다면 이야기가 달라진다. 앱 출시 초기에 발생한 끔찍한 버그가 있었는데, 앱의 강제 업데이트를 위해 띄워뒀던 모달이 터치가 되지 않던 버그였다. 버그 자체는 react-native-gesture-handler와 react-native의 TouchableOpacity가 혼용되면서 발생한 문제로 간단히 해결할 수 있었지만 수정된 다음버전이 배포되고 업데이트 되기 전까지 모든 유저는 앱을 사용할 수 없을것이고 버전이 올라간다한들 직접 앱스토어/플레이스토어에서 검색하여 업데이트 해야했을 것이다. 다행히도 앱엔 코드푸시가 적용되어 있었고 코드푸시를 통한 업데이트를 통해 빠르게 문제를 픽스할 수 있었다. 물론 이 코드푸시가 더 큰 문제를 나중에 야기하지만 그건 나중 이야기...

웹 개발에서 하이브리드 앱 개발로 첫 입사하여 가장 먼저 한 일은 개발/테스트/배포 환경의 정리였다. 입사 당시엔 앱이 출시하기 전이었기에 앱을 각각 testflight와 playconsole에 올려 테스트했으며 환경변수의 설정도, 코드푸시의 반영도 모두 수동으로 진행하고 있었다. 이 부분을 정립하고 자동화하는 것이 첫번째 목표였다. 어플리케이션 서비스의 개발과 출시에 대해 생각해보자. 먼저 우리는 앱을 로컬에서 개발한다. 개발된 앱은 QA를 진행한 후 각각의 앱 퍼블리싱(앱스토어, 플레이스토어)에 배포되어야 할 것이다. 그럼 적어도 우리는 3개의 stage가 개발에 요구된다. 개발을 위한 stage, QA를 위한 stage, 실제 프로덕션 stage.