새소식

업무경험

주도적으로 의견을 내며 리딩했던 경험

  • -

코로나 시대에 음성채팅이 새로운 커뮤니케이션으로 주목받았던 때가 잠깐! 있었다. 그때가 기업용 메신저를 개발하고 있었을 때였는데 음성채팅 기능을 2~3개월 안에 급하게 추가해달라는 요구사항이 내리 꽂혔다. 갑자기 모든 과제가 밀리면서 음성채팅 과제가 가장 중요한 몇개의 과제 중 하나로 떠올랐고 모든 리더들이 달려들어 회의를 하기 시작했다.

당시 일부 가입, 로그인 페이지를 제외하고는 앱의 대부분의 코드는 네이티브였고 웹페이지와의 인터페이스도 웹에서의 리다이렉션 URL의 파라미터를 통해 몇몇 정보들을 받아오는 정도가 전부였다.

그런데 과제가 꾸려지면 기본적으로 iOS, Android, Windows, MacOS 4종 클라이언트 개발자를 비롯해서 REST API 서버팀, 기획, 디자인과 협업이 필요한데, 음성채팅 화면을 개발하면서 개발 효율성 측면에서인지 본격적인 웹뷰 도입을 시작하는 것으로 의사결정이 나 있었기 때문에 팀에서는 처음으로 웹 개발자와도 협업을 하면서 상호간의 인터페이스를 만들어야 하는 상황에 직면하게 되었다. 게다가 음성 채팅의 특성상 음성 스트리밍 솔루션을 개발하는 팀과도 소통을 해야했고, 실시간으로 변하는 유저들의 상태를 갱신하기 위해 주로 소켓 통신을 담당하는 메시징서버팀도 붙었고, 중요과제이다보니 UX팀에서도 사람이 투입되었다. 아마도 경험했던 과제 중 역대급으로 유관부서가 많았던 과제가 아니었나 싶다. 설상가상으로 약간의 시간차가 있긴 했지만 거의 동시에 시작된 웹뷰 협업 과제가 하나 더 있었는데 그것도 내가 맡게 되었다.

그 중에서도 내 입장에서 가장 중요했던 부분은 빠른 시간 내에 웹과 인터페이스 스펙을 잘 맞추는 부분이었다. 서버 백엔드 쪽이야 워낙 그쪽에서 API 스펙을 관리하고 문서도 만들어주는데 반해 웹과 네이티브의 관계는 협업이 처음이기도 하고 API를 서로 제공하고 제공받아야 하는 상황이었기 때문에 어느 쪽에서 주도권을 가져가도 이상하지 않은 상황이었다. 그런데 이럴 때 가장 애매한 순간이 찾아온다. 아무도 나서지 않는 상황 말이다. 그래서 보다 못해 내가 나섰다.

먼저 사전 조사로 웹뷰와 네이티브 간의 데이터를 주고 받을 수 있는 기술적인 방법이 뭐가 있는지 조사했다.

js call, post message, local storage, 앱 스킴 등이 있었다. 그 중에 기존에 사용하고 있던 몇가지 앱스킴을 제외하고 js call과 post message 방식으로 인터페이스를 정의하기로 합의가 되었다.

그리고 API 스펙을 공유할 수 있는 가장 빠르고 간단하게 할 수 있는 방법으로 엑셀시트를 하나 만들었다. 기능, 인터페이스 방식, 호출명, 파라메터 등 필요한 것을 빠르게 정의하여 공유할 수 있도록 했다. 그리고 어떤 기능이 필요한지 사용하는 쪽에서 기능명을 적어주면 호출명과 파라메터 등은 제공하는 쪽에서 적도록 제안했다. 작업하면서 스펙에 변경사항이 있을 때마다 엑셀에 업데이트하고 메신저로 다시 통보해 주는 그라운드 룰도 정의했다.

어느 정도 작업이 진척되다보니 macOS의 경우는 웹에서 빌드환경을 갖추고 있지 못해서 어떤 작업을 해놓고 결과를 확인하려면 꼭 네이티브 개발자인 나에게 확인을 요청해야만 하는 상황이 반복되었다. 그래서 웹에서 로그를 추가하면 네이티브에서 출력해주는 스펙을 추가하자고 제안했다. 웹 개발자가 매우 만족스러워했다. 

다른 웹뷰 협업 과제에서도 비슷한 일이 벌어졌다. 아무도 나서지 않는 상황이 반복되었고 나는 거기서도 같은 일을 했다. 엑셀을 만들어 인터페이스 스펙을 정의해 나갔고 일도 잘 진행되는 듯 했다.

그런데 한 번 이상 배포가 되고 난 후에는 인터페이스를 바꾸면 하위호환성 문제가 발생하게 되었다. 웹과 앱의 배포 시기도 꼭 맞춰야만 했다. 이것은 여간 번거로운 문제가 아니었다. QA 팀에서 한참 테스트를 하고 있는데 웹에서 스펙을 하나 변경해서 배포하면 주루룩 이슈가 올라오게 되고 그건 앱이 새로 배포되면 해결될 것이라고 설명해야 하는 상황이 만들어진다.

그래서 이번에는 웹 클라이언트 URL path에 버전을 달았다. https://.../voicechat/v1 이런식이다. 이렇게하면 이전에 배포된 앱이 사용하는 웹 클라이언트와 새로 변경된 스펙을 적용한 웹 클라이언트가 구분될 수 있었다.

이렇게 짧은 시간에 거대한 스펙의 요구사항을 수많은 멤버가 함께 작업해야 했던 음성채팅 과제는 성공적으로 마칠 수 있었다. 물론 서비스가 많은 사람들에게 사랑받았는가 하는 것은 별개의 문제다. 아쉽게도 음성채팅 서비스는 그러지 못했다.

물론 엑셀시트로 만들어진 스펙 문서는 나중에 보기 좋게 따로 잘 정리했어야 했는데, 몇 번 그 일의 필요성을 리더들에게 어필했었고 그 일은 리더 중 한명이 담당했던 것으로 알고 있다.

반응형
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.