프로토타입 발표 (1차) 회고

무엇을 만들었는가?

이번에 만들게 된 기능은 단순히 어드민 페이지에 들어가는 조그마한 기능이 아닌, 유저를 대상으로 하는 웹 페이지에 탑재될 서비스였다. 아직까지는 실제 웹 페이지에 탑재 이전이기 때문에 자세히 얘기할 수는 없지만, ‘아고라(Agora)’라는 회사의 SDK를 사용하여 만드는 실시간 오디오/ 비디오 채팅 기능이라고 말할 수 있다.

 

이전에 클럽 하우스(Club house) 라는 서비스가 각광받던 시기가 있었다. 나는 사용해보지 않았지만, 프라이빗 하게 초대를 받은 유저들끼리 자유롭게 오디오를 녹음하여 소통하는 서비스라고 전해 들었다. 위 서비스 또한 ‘아고라’의 SDK를 사용했는데 우리는 이 서비스에 영감을 받아 우리가 만들어가고 있는 전시 서비스에도 실시간으로 큐레이터가 전시를 소개하거나, 해당 작가 또는 전시에 관심이 있는 유저들끼리 서로 대화를 하는 공간을 만들고 싶었다.

 

이러한 오디오/ 비디오 채팅 서비스는 퇴사하신 이전 개발자 분이 MVP(minimum viable product) 급으로 만들어 두셨고, 이미 개발 서버에까지 배포가 된 상태였지만, 내부의 문제로 퇴사하시게 됐고 추가적으로 이를 보완하여 만들겠다는 것이 이 일을 맡게 된 시발점이었다.

 

하지만 ‘아고라’ 라는 기업은 중국 기업이기도 했고, 내가 합류하기 전 이미 피드백 사항으로 치명적 문제가 있어서 다시 ‘아고라’ SDK를 사용하여 만들어야 할지 고민되던 시점이었다. 따라서 우리는 이런 실시간 오디오/비디오 채팅 기능을 제공하는 다른 기업 (A, B 기업)들을 조사 및 가벼운 기능 구현으로 발표를 했지만, 결과적으로 우리의 기획에 가장 잘 맞는 것은 ‘아고라’였다. 따라서 우리는 아고라 SDK를 바탕으로 새로운 프로토타입을 만들기로 결정했고, 내가 이를 도맡아 하는 것으로 결론지었다.

 

우리의 화두는 제공되는 SDK를 바탕으로 직접 구현할지, 온전히 아고라에서 제공하는 PaaS를 커스텀해서 사용할지 결정할 필요가 있었다. 전자를 선택할 경우, 기획에 따른 모든 기능을 SDK를 바탕으로 직접 구현해야 했고, 아고라에서 제공하는 기능 들 중 필요한 기능만 사용하기 때문에 상대적으로 가벼운 상태 및 가벼운 의존성 관계를 유지할 수 있었다. 후자를 선택할 경우 PaaS(Platform As a Service) 형태의 서비스에 단순히 테마, 이미지 등만 바꿔서 사용할 경우, 바로 도입할 수 있는 장점이 있지만 해당 PaaS의 번들링 된 파일의 크기가 18mb에 육박했다. 모든 코드를 제공받기 때문에 아고라에 코드가 종속되어있는 만큼 우리가 필요로 하지 않는 많은 기능 들이 포함되어 있어, 이를 적절히 떼고 원하는 기능을 추가하기가 불가능에 가까웠다.

 

따라서 우리는 SDK를 바탕으로 기획에 맞춰 직접 구현하는 방법을 택했다.

얼마만큼의 시간이 필요했는가?

첫 프로토타입이 나오기 전에는 단순히 자료 조사 및 아고라 내부 기능을 만들기 위한 2-3주 간의 시간을 가졌다. 이후 대표님과 미팅을 가졌다.

“기획에 적힌 필수 기능들을 구현하기까지 얼마나 시간이 걸릴 것 같나요?”

 

이미 기획자 분과 어떤 필수 기능(반드시 들어가야 하는 기능) 들이 있고 어떤 부분이 가능하고 불가능한지 여부를 판단하기 위한 요구사항 (필수 기능) 리스트를 작성해 두었고, 이를 바탕으로 “이제 시작해볼까?” 와 같은 상태인 것으로 기억이 한다.

 

이전까지는 단순히 마크업 비슷한 작업을 하거나, 재사용한 컴포넌트를 만들기 위한 리팩터링, 어드민을 위한 내부 기능 페이지 등의 작업을 했었다. 짧게는 2-3일에서 길게는 2주(10 영업일) 안쪽으로 끝나던 일이었다.

 

따라서 내가 일정을 산출하여 대표님께 말씀드리는 순간, 이것은 반드시 지켜야 하는 약속이고 나에게 주어지는 첫 큰 프로젝트가 되는 것이었다.

“한 달이면 가능할 것 같습니다”

 

사실 넉넉하게 잡는다면 6주 정도는 필요할 것으로 보였다. 하지만, 6주라는 말이 입에서 떨어지지 않았다. 이전까지의 작업에 대한 호흡은 2주가 안됐기 때문에 정확히 얼마나 걸릴지 몰랐던 게 가장 크지만, 뭔가 할 수 있을 것 같다는 생각이 들었다.

 

이전에 아고라 외의 다른 서비스를 비교하면서 직접 구현해 본 내용 들이 필수 구현 사항에 포함되어 있었기 때문에 1 달이면 가능할 것이라고 생각했다. 그리고 이런 압박을 겪었을 때 조금 더 성장할 수 있다고 생각해서 대표님께 1 달이라고 말씀드렸다.

 

1 달이라고 말하면 사수 분께서도 분명 좋아하시진 않을 것 같았다. 모든 말에는 책임이 있듯이, 필수 기능 들에 대해서는 기술적으로 불가능한 사항이 아닌 이상, 온전히 동작시켜야 하기 때문이다. 또한, 내부 QA 도 진행해야 하고, 테스트 서버에 까지 올려 동작시켜야 하기 때문에 반신반의했던 것 같다.

완성 여부?

결과적을 말하자면, 기한 내에 온전히 프로토타입을 만들었다. 안에는 너무 많은 과정이 있지만, 자세히 설명할 수는 없을 것 같다. 보통 리스트화 한 작업이 있다면 SDK에 따른 알고리즘 기획 및 구현에 1-2 일, 코드 리팩터링 및 QA 1 일 씩 작업을 했던 것 같다. ‘오늘 못하면 집에 못 가’와 같은 강요되는 분위기는 아니기 때문에 내가 말한 ‘한 달’에 대해서는 자율성을 많이 부여해주셨다. 온전히 기능을 구현하지 못한 날에는 집에 가는 길에도, 집에 가서 샤워하는 동안에도, 자고 일어나서 씻고 다시 출근하는 동안에도 어떻게 구현할지 생각했다. 또한 아고라에서도 다양한 커뮤니티를 통해 기술적인 답변을 주기 때문에 어려웠지만 해결할 수 있었다.

 

 

아고라는 ‘agora ticket’이라는 서비스를 제공하는데, 이 서비스를 통해 질문하면, 적절한 document 또는 예시 코드를 제공해준다.

힘들었던 점?

힘들었던 점은 ‘예상치 못한 일’에 대해 핸들링하는 것, ‘내가 짜는 코드에 대한 확신이 부족하다는 것’ 등이었다.

 

‘예상치 못한 일’

아고라에서는 web-socket 통신 연결로 데이터를 주고받을 때 https 환경을 갖추는 것을 요구하는데, 따라서 로컬 이외에는 모두 테스트 서버에 올린 상태에서 확인해야 했다. 일반적으로 내가 로컬 환경에서 모바일로 테스트를 하고 싶은 경우에는 IP에 접근하는 방식을 채택했는데, 해당 환경은 http 환경이기 때문에 모바일로 테스트하려면 반드시 https 설정이 된 테스트 서버를 통해 접근해야 했다. 정말 실제로 구현해보지 않고서는 예상할 수 없는 일이었다.

내가 짠 코드가 모바일 환경, 실제 모바일 기기에서 온전히 동작하는 지를 확인하기 위해서는 테스트 서버가 필요했다. 앞으로도 개선돼야 하는 상황이지만, 시간이 촉박했기 때문에 개발 서버에 지속적으로 코드를 수정하고 올리면서 직접 눈으로 확인했다.

 

‘내가 짜는 코드에 대한 확신’

사실 이 부분이 가장 신경 쓰이고 또한, 아직도 가장 많이 신경 쓰고 있는 부분이다. 개발자의 의도와는 다르게 내부 QA만 진행하더라도 정말 다양한 환경에서 서비스에 접근하게 된다. WIFI를 사용하다가 갑자기 WIFI가 끊기는 상황이 있을 수도 있고, 웹 캠이나 스피커가 없는 상황에서 방에 참여하고 싶을 수도 있다. 내가 알지 못하는(직접 경험하지 못한) 수많은 상황들이 있는데 어떻게 대응할지 막막했다. 이럴 때마다 사수 분과 면담을 요청하기도 하고, 많은 조언을 듣기도 했다. 결론으로 말하자면 아직까지도 확신을 가지기는 어렵다. 그렇기에 더욱 공부해야 할 방향이 생기고, 프로젝트에 대한 애정이 생기는 것 같다.

얻은 점은 무엇인가?

물론 큰 틀에서의 기획은 존재하지만, 내부 코드를 알고리즘을 어떻게 구현할지는 모두 개발자의 몫이다.’ 어떻게 재사용 가능한 코드를 만들 것인가’, ‘어떻게 하면 이해하기 쉬운 코드를 짤 것인가’, ‘어떻게 하면 런타임 에러를 최대한 방지하며 온전히 동작시킬 수 있을 것인가’, ‘기획 및 요구 사항을 어떻게 구현할 것인가’ 등 정말 이전까지는 경험해보지 못한 수 많은 문제들에 대한 ‘문제 해결 능력’이 매우 필요했던 시간인 것 같다.

 

훅 함수를 작성하고 이를 바탕으로 비즈니스 로직과 뷰 로직과 분리하는 작업도 기능 개발을 하며 리팩터링이 아닌 상황으로 처음 진행해 본 것 같다. 이전에는 단순한 형태의 데이터 구조를 다뤘다면, 이번에는 필요에 따라 자바스크립트의 객체(Object)에서 사용할 수 있는 다양한 데이터 구조 (Set, Dictionary 등)를 바탕으로 구현한 것도 있었다.

혼자서 이런 큰 일을 해본 적도 처음이기 때문에 다른 팀원 분들 앞에서 발표를 하는 시간도 가졌고, 그렇기 때문에 대충 해서는 안 되겠다는 책임감도 얻게 되는 것 같다.

 

아직은 개발 중인 단계고 결과를 도출해내기 위해 많은 과정이 필요하지만, 내가 온전히 만든 서비스라는 것에 대해 자부심이 생긴다. 우리 회사가 B2C로 가는 길에 다리를 하나 더 놓아주는 서비스라고 생각하고, 이런 마음 가짐을 통해 나 스스로 엄청 많은 동기부여를 가져가고 있다.

 

잘 해낼 수 있고, 반드시 해낼 것이다. 이후의 프로토타입은 본격적으로 백엔드 연동과 관련된 부분인데, 두 번째 프로토타입이 완성되면 이에 대한 회고 또한 작성해 봐야겠다.