저는 LG G5 실패의 공범자입니다.

전자기기를 좋아해서 테크 유튜버를 많이 구독하고 있다.

어느 날 절대 클릭하지 않을 수 없는 영상을 발견했다. 심지어 업로드된 지 몇 시간이 채 지나지 않은 따끈따끈한 영상이었다.

https://www.youtube.com/watch?v=mHrIwtdV7VI

내가 이 영상을 클릭할 수밖에 없었던 이유는 LG G5(이하 G5) 사용자였기 때문... 이라기보다는 G5의 개발에 아주 미미하나마 일조했기 때문이다. 그렇다. 나는 G5의 개발자 중 한 명이었다.

심지어 첫 회사에서 첫 프로덕트 코드가 탑재된 플래그십 모델이 바로 G5다. 이것만으로도 의미가 크다. 그런데 이게 끝이 아니다. 영상에도 등장하는 LG Friends와도 질긴 인연이 있다.

LG Action Cam이 굴린 스노볼

그 인연의 시작은 바로 LG Action Cam LTE Manager 앱이다.

신입으로 입사해서 처음 개발한 것이 SetupWizard 앱이었다. 해당 앱은 모든 폰에 탑재되는 앱이기 때문에 전 모델, 국가별, 다양한 통신사에 대한 지원이 필요하다. 당연히 G5에도 탑재되었다. 그 후 만 1년이 되지 않은 2년 차에 하게 된 일이 LG Friends 제품 중 하나인 LG Action Cam에 원격 CCTV 기능을 추가하는 것이었다. 당시 내부에선 원격 CCTV라고 불렀지만 범용적인 말로 표현하면 라이브 스트리밍이다. LG Action Cam이 처음 출시 되었을 때는 근거리에서 스마트폰과 연결하여 촬영하는 기능만 제공되었다. 당시의 고프로와 같은 방식이다. 그런데 여기에 원격으로 실시간 영상 전송 및 촬영을 하는 기능을 추가하는 것이 프로젝트의 핵심 목표였다. 최종적으로 LG Action Cam LTE Manager 앱을 통한 스트리밍뿐만 아니라 유튜브 등과 같은 플랫폼에 연동해서 스트리밍이 가능했다.

LG Action CAM LTE

이 프로젝트는 10년 차쯤 된 선임과 함께 시작했다. 추후에 다른 분들도 합류하였다. 이미 존재하는 앱 개발에 투입되면 기존에 있는 코드 베이스로 이슈 대응이나 신규 기능을 추가하는 작업을 한다. 하지만 라이브 스트리밍은 당시 내부적으로 참고할 만한 코드가 없는 완전히 제로 베이스의 신규 기술이었다. 나름 도전적인 과제였다. 그때는 WebRTC 안정화 버전이 나오기도 전인 시절이었다. 추후에 선행기술팀에서 WebRTC를 소개하는 것을 보고 우리가 하려던 것 대부분 지원하는 것 같다는 생각을 한 기억이 있다.

운이 좋다고 해야 할까? SetupWizard 앱을 개발할 당시에도 초반에는 외주에 의해서 개발된 코드로 매운맛을 보다가 추후에 내재화하는 작업을 거쳤다. 사실상 거의 새로 개발하는 것이었다. 주요한 로직은 재활용했다. 변화가 매우 큰 리팩터링이라고 생각해도 될 것 같다. 그런데 LG Action Cam 개발 건도 새롭게 개발하는 건이었다. 이렇게 대규모의 신규 개발은 다른 팀에서는 하기 어려운 경험이었던 것으로 기억한다. 더 나아가 제조사에서는 하기 힘든 네트워크 통신 관련 경험도 할 수 있었다.

잠깐 (아무도 궁금해하지 않을) 기술적인 이야기

라이브 스트리밍이니 당연히 네트워크 기술이 필요했다. 아마 많은 서비스 앱 개발자들이 떠올릴 네트워크 통신은 RESTful API를 활용하는 형태일 것이다. 하지만 이 프로젝트에서는 정말 다양한 프로토콜을 사용하는 경험을 했다. RESTful API를 통한 HTTP 프로토콜은 물론이고 TCP/UDP 소켓, WebSocket까지 사용했다. RESTful API는 Volley라는 HTTP 라이브러리를 활용했다. 왜 이렇게 다양한 프로토콜을 사용했을까? 그건 스마트폰(LG Action Cam LTE Manager 앱)과 카메라(LG Action Cam 앱)를 P2P(Peer-to-Peer)로 연결하기 위해서다. (LG Action Cam에도 안드로이드 OS가 탑재되어 있었고 따라서 LG Action Cam용 앱도 함께 개발했다.)

이때 Hole Punching이란 기술이 사용된다. Hole Punching은 NAT(Network Address Translation) 또는 방화벽이 있는 네트워크에서 두 피어가 직접 통신할 수 있도록 하는 기술이다. Hole Punching은 NAT를 통과하기 위해서 STUN(Session Traversal Utilities for NAT) 및 TURN(Traversal Using Relays around NAT)과 같은 프로토콜을 사용한다. STUN이 실패하면 TURN으로 대체한다.

내부적으로는 STUN 방식을 시도하는 서버는 Hole Punching 서버라고 불렀다. n회 시도를 실패하면 TURN 방식으로 전환되는데 이때 사용하는 중계 서버를 Relay 서버라고 불렀다. Hole Punching 시도 또한 TCP/UDP 방식 모두 시도한다. 그래서 TCP/UDP 소켓 프로그래밍이 필요했다. 구조를 대략적으로 도식화하면 아래와 같다.

아마 어떤 사람들은 구조를 보고 WebSocket이 어디에 사용되었는지 짐작을 했을 것이다. WebSocket은 클라이언트와 서버 간에 지속적인 연결을 유지하고, 양방향 통신을 가능하게 하는 프로토콜이다.

WebSocket은 Push Server와 통신할 때 사용했다. 스마트폰은 사용자가 LG Action Cam LTE Manager 앱을 통해서 연결을 시작한다는 이벤트를 발생할 수 있다. 그러면 원거리 어딘가에 있는 LG Action Cam 단말기도 P2P 연결을 위해 Hole Punching 서버에 연결을 해야 한다. 이때 연결하라는 트리거를 LG Action Cam 단말기에 전달을 해야 한다. 이러한 연결 요청은 사용자가 언제 스마트폰을 통해 요청할지 모르는 일이다. 그래서 LG Action Cam 단말기는 늘 Push Server에 연결되어 있어야 한다. 이러한 연결 유지를 위해서 주기적으로 데이터를 전달하는데 그것을 WebSocket을 통해서 하는 것이다.

참 힘든 시기였다. 기술적으로 모자라는 부분 그 자체보다는 거기서 기인한 나 자신의 쓸모와 능력에 관한 고민 때문이었다. 겨우 2년 차였던 주제에 선임에게 더 많은 도움이 되지 못하는 것이 늘 아쉬웠고 죄송했다. 그런 마음 때문에 힘들었다. 그 누구도 질책한 적이 없다. 오히려 선임은 늘 충분히 잘하고 있다고 말씀해 주셨다. 당연히(?) 경험이 적은 내 퍼포먼스가 상대적으로 낮은 것이 이상하지 않은 것인데 말이다. 그땐 왜 그랬을까? 지금도 종종 생각한다. 지금의 내가 그때로 돌아가면 좀 더 잘할 수 있지 않을까 하는. 재미없는 기술 이야기는 여기서 끝! (야야.. 다른 것도 재미없어.)

LG Friends Manager 앱 전부요? 아.. 네...

매년 조직 개편이 있는데 이때 LG Friends 관련 앱을 개발하는 파트에 속하게 되었다. LG Friends 중 하나인 LG Action Cam에 발을 담근 것이 요인이 아닐까 싶다.

LG Friends 뿐만 아니라 스마트 워치와 태블릿과 연동하는 앱도 뭔가 주변기기라는 카테고리에 묶여서 그런지 자연스럽게 같은 파트에 속해 있었다. 이 시기에는 LG Action Cam 관련 이슈 대응을 하면서 SetupWizard 신규 개발 건도 잠시 지원했던 것 같다. 그러다가 WiFi Settings을 메인 업무로 하게 되었다. 투입 초기에 업무는 WiFi Settings의 신규 OS 업데이트에 대한 대응이었다. 신규 UI/UX 및 기능을 추가하고 신규 OS 구조에 맞게 마이그레이션 작업을 했다.

아무래도 WiFi 관련은 안드로이드 OS 코드 기반으로 커스텀 되는 부분이다 보니 구글 코드가 꽤 많았다. 이때 기억에 남는 것이 몽키 테스트를 통해서 버그를 발견했던 것이다. 수정하고 생각해 보니 그 부분이 구글 순정 코드일 수도 있겠다 싶어서 찾아보니 맞았다. 그렇다면 컨트리뷰터가 될 수 있는 건가 싶어서 좀 더 찾아보니 OS 최신 버전에서는 수정되어 있었다. 멀티 스레드에 의한 동시성 문제로 ConcurrentModificationException가 발생했던 것 같은데 synchronized 처리하고 끝냈는데 구글 대응도 다를 바가 없었다. 잠깐 이야기가 다른 길로 샜다.

아무튼 메인으로 담당하고 있는 앱이 있는 상태였는데 기존에 LG Friends 개발자들이 하나 둘 사라지기 시작했다. 결국 최후에는 모든 앱의 유지보수가 내 몫이 되었다.

앱 목록: LG Friends Manager, 360 Cam Manager, 360 VR Manager, LG Action Cam Manager, LG Hi-Fi Plus Manager, LG Cam Plus Manger, LG Watch Manager, LG QPair

LG Friends 제품, 롤링봇은 결국 정식 출시하지 않았다.

물론 저물어가는 앱이라 신규 개발 건이나 이슈가 많은 것은 아니었다. 어떤 앱은 한 번도 대응할 일이 없기도 했다. 그렇다고 해도 총 8개의 앱이었다. 그 앱들의 코드는 그전에 본 적도 없다. 메인으로 담당하는 앱도 있었기 때문에 부담이 없다고 하면 거짓말이었다. (그때 도움을 주신 분들에게 감사의 말을 전합니다.)

심지어 빌드하는 방법도 각양각색이었다. 빌드도 자주 할 일이 없으니 gradle 명령어를 수첩에 적어 놓고 빌드할 때마다 찾아보고 했다. 여러 앱에 사용되는 자체적으로 만든 코어 AAR 라이브러리의 경우 버전을 올려 빌드하면 해당 라이브러리 의존성이 명시된 pom.xml에서 버전명을 수정하고 앱도 다시 빌드해야 하는 과정이 번거롭고 헷갈리는 경우가 많았던 기억이 있다. (지금에서야 드는 생각이지만 그때 여유가 더 있었다면 그런 빌드 구조도 잘 공부해 뒀으면 얼마나 좋았을까 싶다.)

그리고 또 번거로운 것이 있었다. 보통 제조사 또는 통신사 앱은 Pre-load 된다. 이런 앱들을 system app 또는 privileged app이라고 부른다. 하지만 LG Friends 앱들은 구글 플레이 스토어에 배포되었다. 그래서 버그를 수정하면 빌드의 산을 넘어 배포의 계곡을 건너야 했다. 스토어에 apk 올리는 게 뭐 그리 대수냐 싶겠지만 배포할 때는 늘 묘한 긴장감이 있었다. 그리고 배포를 위한 검수 과정(QA)도 적지 않은 피로도를 유발한다. 내부 프로세스와 시스템이 있어서 QA 의뢰하는 과정부터 다소 귀찮은 작업이다.

기억에 남는 일

1) LG Friends에 대한 부담이 가장 큰 시점은 OS 업데이트가 있을 때다. 실제로 (LG Friends 앱은 아니지만) LG Watch Manager의 경우 Notification 방식에 변경이 있었을 때 알림이 워치로 제대로 전달되지 않는 문제가 있었다. 관련 이슈 때문에 해외여행 후 귀국하자마자 통화하느라 공항버스 막차도 놓치고 택시 타고 집에 왔던 기억이 난다. 귀국한 날이 금요일이라 다음 날 주말 특근을 하게 되었다.

2) LG QPair의 경우는 스마트폰과 태블릿 연결을 하는 앱이라 양쪽 기기에 대한 apk가 필요했고 태블릿 UI에 대한 작업도 해야 했던 것이 기억이 난다.

3) LG G5의 경우 모듈과 본체 사이 단차 이슈가 있었다. 당시에 이미 알려진 사실이지만 해당 이슈 검수를 위해서 연구소 일부 연구원들이 평택 공장에 지원을 간 적이 있다. 검수 물량 대비 인원이 부족하니 연구원까지 동원한 것이다. 밤샘 야간 근무도 해보고 지금은 나름 신선하고 재미난 추억으로 남아있다.

4) LG Action Cam LTE는 글로벌 출시 제품이었기 때문에 국가별 정책에 따라 상이한 시나리오가 있었다. 그런데 이 국가를 나누는 기준에서 많은 논의가 있었다. 글로벌 모델에 한국 유심을 장착해서 한국에서 접속하면? 한국 모델을 미국에 들고 가서 미국 유심을 장착해서 사용하면? 당시 이런저런 상황에 대해 치열하게 고민했는데 기억력이 좋지 않아서 최종 결정이 무엇인지 모르겠다. 아마 해당 국가의 정책이니 연결된 통신망을 제공하는 통신사의 소속 국가를 기준으로 했던 것 같다.

그래서 해당 유튜브 영상이 특별했다.

이런 특별한(?) 인연이 있으니 LG G5와 LG Friends에 관한 영상을 어떻게 클릭하지 않을 수가 있겠나?!

뭔가 거창하게 이야기한 것 같은 부분도 있지만, 다시 말하자면 나는 이 모든 제품에 아주 미미하게 일조한 한 명의 개발자일 뿐이다. 실패에 대한 면책을 하기 위한 말이 아니다. 정말 많은 사람들의 노력과 수고가 더해져서 나온 제품들이라는 말을 하고 싶은 것이다.

성공을 했다면 모두가 함께 이룬 성공이라고 하듯이 실패 역시 모두가 함께 저지른 일임에는 변함이 없다.

제품의 실패가 죄는 아니지만 만약 죄라면 나는 실패의 공범자다.

결과적으로 실패라는 세간의 평가를 받았지만 관련된 사람들이 노력하지 않아서 그런 것은 아니라고 생각한다. 모두 각자의 자리에서 최선을 다했을 것이다. 그리고 또 지금 어딘가에서 고군분투하고 있을 그들에게 박수를 보낸다. 수고하셨습니다.