영상통화가 되는 앱을 만들려고 했다
회사에서 자회사 서비스로 영상통화 앱을 만들던 때였다. 앱을 만들 사람이 줄어 있었고, 서버를 개발하던 나도 테스트할 앱이 필요했다. 상급자의 지시도 있어 React Native를 배우며 앱 쪽 일을 맡게 됐다.
게임 엔진으로 안드로이드 앱을 내본 경험이 있었고, 안드로이드에서 하드웨어를 다뤄본 적도 있었다. React를 따로 공부해 관리 화면에 쓰고 있어서 React 기반의 React Native에도 도전해볼 만하다고 생각했다. 실시간 스트리밍 예제로 먼저 시험했다.
시도한 방식은 세 갈래였다. 오픈소스로 직접 구성했을 때는 아이폰에서 되던 것이 안드로이드에서 안 됐다. 소리가 나오는 채널처럼 기기 쪽 문제가 반복됐다. 사용료를 내는 외부 서비스도 살폈지만 통화당 비용이 사업 모델과 맞지 않았다. 마지막에는 관리형 영상 스트리밍을 사용하며 기존 네이티브 코드를 React Native에 연결했다. 이 방식이 가장 괜찮았지만, 아이폰의 화면 전환이 자연스럽지 않은 문제도 남았다.
방식을 바꿔가며 검토해도 질문은 남았다. 기기에서 동작하는지, 통화 비용을 감당할 수 있는지, 그 기능으로 어떤 서비스를 만들 것인지는 각각 살펴야 했다.
연결 뒤에도 일이 남았다
영상통화에는 두 앱이 서로 연결할 방법을 알아내고 음성과 영상을 주고받는 과정이 필요하다. WebRTC는 이런 통신을 다루지만, 연결에 필요한 정보를 상대에게 전달하는 시그널링은 별도로 마련해야 한다. 직접 연결이 어려운 네트워크에서는 트래픽을 중계하는 TURN 서버를 사용할 수 있다. 당시에는 외부 인력과 협업해 TURN·STUN 서버를 구성하는 일도 했다. WebRTC 연결 설명, TURN 서버 설명
중계가 들어가면 연결됐는지만 볼 수는 없다. 어떤 네트워크에서 중계를 거치는지, 사용량이 늘면 비용을 감당할 수 있는지도 함께 따져야 한다. 비용을 내는 서비스가 구현 부담을 덜어주더라도 그 비용이 내가 만들 서비스와 맞는지는 별개의 질문이었다. 당시 외부 서비스의 단가가 맞지 않았다는 판단을, 지금도 모든 관리형 서비스가 비싸다는 이야기로 넓힐 수는 없다.
기존 안드로이드·아이폰 코드를 React Native에서 쓰려면 연결할 부분도 있었다. 당시 만들었던 네이티브 브리지는 자바스크립트 쪽에서 각 운영체제의 기능을 부르고, 그 결과나 이벤트를 다시 받게 하는 통로였다. React Native 공식 문서에서도 네이티브 모듈을 통해 기존 라이브러리를 자바스크립트에 노출하는 방법을 설명한다. 네이티브 코드와의 통신
예를 들어 앱에서 통화 화면을 열었는데 사용자가 곧바로 뒤로 갔다고 해보자. 자바스크립트 화면은 닫혔지만 네이티브 쪽에서 처리하던 작업의 결과가 늦게 올 수 있다. 그 결과를 어느 화면에 전달할지, 이미 닫힌 화면은 어떻게 다룰지까지 생각해야 한다. 이는 브리지의 역할을 설명하기 위한 예다. 함수를 한 번 부를 수 있게 연결하는 것과 두 쪽의 화면·작업 상태를 맞추는 것은 다른 수고였다.
이 작업은 동료와 함께 했다. iOS에 익숙한 동료에게 배우면서 네이티브 코드를 공부했다. 관리형 영상 기능을 골랐다고 앱 안의 이런 연결까지 없어지지는 않았다.
기술을 고쳐도 남아 있던 질문
서비스는 끝내 출시하지 못했다. 기술의 안정성과 유지 비용을 살피는 동안 인력과 조직의 우선순위도 달라졌다.
지금 돌아보면 당시 질문을 조금 더 나눠볼 수 있었을 것 같다. 어느 기기와 네트워크에서 어느 정도로 동작해야 하는지, 그때 예상하는 통화 비용은 감당할 만한지, 사용자는 무엇 때문에 이 앱에서 통화해야 하는지. 하나의 데모가 잘 된다고 세 질문의 답이 함께 나오지는 않는다.
다시 검토한다면 먼저 작은 범위를 정해보고 싶다. 통화를 시작하고 끝내는 한 과정을 두 운영체제에서 확인하고, 화면 전환과 연결 종료까지 살피는 식이다. 통화 시간이 늘어났을 때의 비용도 같은 사용 가정으로 비교해야 할 것이다. 이것으로 서비스의 필요성까지 증명할 수는 없으니, 사용 목적에 관한 판단은 따로 남겨두어야 한다.
앱을 접었다고 배운 것까지 사라진 것은 아니었다. 이후 앱에서 광고·화면 밝기·시간 표시를 React Native 모듈로 연결할 때 이 경험이 이어졌다. 광고 브리지도 동료와 공동으로 만들었다. 나는 다음 앱의 iPhone 전환과 빌드·심사·제출을 맡았고, 이후 다른 앱의 개발에도 참여했다.
출시하지 못한 앱에서 익힌 기술이 다음 작업에 쓰였다는 것은 실제로 남은 결과다. 그와 별개로 이 앱을 출시하지 못한 이유를 기술의 부족 하나로 설명하기는 어렵다. 무엇을 더 만들지뿐 아니라 어디까지 만들면 판단할 수 있을지, 그 기준을 함께 정했어야 했다는 생각이 남는다.
댓글
댓글은 GitHub 토론을 사용하며, 열면 GitHub 로그인이 필요합니다. 고객·사람이 드러나는 정보는 남기지 말아 주세요.