프론트엔드 개발자가 되다.

올해 2월 나는 약 1년의 취준 기간을 거쳐 프론트엔드 개발자가 되었다. 입사하고 4개월동안 2개의 프로젝트를 진행하며 정말 쉴새 없이 달려왔다. 바쁜 일정탓에 되새김질 할 여유가 없었는데 이번에 그동안 내가 배운것들을 정리하고, 반성하고, 또 앞으로 나아가야 할 방향에 대해 생각해보려 한다.

소통하는 법

1주일정도의 온보딩을 마치고 나는 바로 신규 프로젝트에 투입되었다. 우리 팀은 백엔드 개발자, 디자이너, 기획자, 프론트엔드 개발자(나) 로 이루어져 있었다. 다행히 좋은 팀원분들을 만나서(정말 감사) 빠르게 적응해 나갔다. 초반에는 매일매일 미팅의 연속이였는데, 디자이너, 개발자 할것없이 모두 적극적으로 의견을 제시하고 기획에 참여하는 모습이 인상적이였다. 그동안 내가 꿈꿔왔던 환경이였고, 그런 분위기속에서 일 할 수 있어 정말로 기뻤다.

나는 적극적으로 미팅에 참여하였고 실제로 부딪히며 그 과정에서 어떻게 의견을 제시하고 소통해야 하는지 많이 배울 수 있었다.

기획적인 의견과 별개로, 개발자로서 미팅에 참여해보면 나에게 오는 질문들은 대체로 기술적으로 구현 가능한지 불가능한지에 대한 사항들이였다. 가능한 사항들은 크게 문제가 되지 않았지만, 불가능한 사항들에 대해서 나는 개발자로서 팀원분들을 설득하고 이해시켜야 할 필요가 있었다. 안된다면 왜 안되는지 명확하게 설명해야 했다. 그래서 나는 그 이유에 대해 문서를 만들어 공유하기도 하고, 개발자의 언어가 아닌 일반 언어로 바꿔 잘 이해할 수 있도록 설명하려고 노력하였다.

하지만 그보다 더 중요한게 있었다. 안된다고 설명하고 끝나는게 아니라, 대체 할 수 있는 방안에 대해 제시할 수 있어야 한다는 점이다. 안된다고 설명하고 끝나버리다 보니 부정적 의견만이 남고 아무런 진척이 없었다. 일정적으로든 기술적으로든 불가능하다면 우선 나는 가능한 방안에 대해 검토해보겠다고 얘기하였다. 그리고 그것들에 대해 조사하고 스터디 하였다. 그러다 보면 대체할 수 있는 기술이나 내가 몰랐던 방법들까지 함께 알 수 있었고, 그런 부분들을 공유하며 진행시켜 나갔다.

100% 올인

그렇게 기획과 디자인이 마무리 되고 개발일정을 잡았다. 하지만 대표님이 정하신 마감기한은 이미 정해져있었고 일정은 정말 너무나도 타이트했다. 마감기한을 늘려달라고 말씀드려봤지만 "일정이 늘어난다고 제품의 퀄리티가 늘어나는 것은 아니다" 라는 말이 돌아왔다. 물론 맞는 말이다. 하지만 주니어 개발자인 내가 혼자서 개발해야 할 부분들은 너무 많고 난이도는 높은데, 일정을 타이트하게 할 수 밖에 없는 현실에 잠시 낙담도 하고 겁도 많이 났다. 하지만 그럼에도 나는 의욕이 넘쳤고 이 서비스를 사람들이 사용한다고 생각을 하면 가슴이 뛰었다. 어떻게든 기한 안에 제품을 잘 만들어 내고 싶은 마음 뿐이였다.

이때 개발자는 기한 안에 주어진 요구사항을 개발해내는 사람이라는 것을 많이 느꼈다. 그래도 일정이 타이트했지만 안정성과 확장성을 모두 포기할 수는 없었다. 그래서 나는 일정과 제품의 퀄리티, 안정성, 확장성등을 고려하며 기술스택을 선정하고 환경셋팅을 하였다. 그렇게 나는 프로젝트에 100% 올인 하게 되었다.

웹이 아니고 앱이요? (리액트 네이티브)

처음에 인터뷰와 입사할 당시 내가 담당할 업무는 신규 프로젝트 앱에서 웹뷰로 보여지는 부분을 리액트로 개발하게 될거라고 들었다. 하지만 막상 팀에 합류하고 회의를 진행하다보니 앱 부분을 담당하려고 했던 분이 다른 업무 때문에 못하게 되었고, 결국 백엔드를 제외한 앱 전체를 내가 개발해야 한다는 것을 알게 되었다.

당시 백엔드 개발자인 팀장님도 디자이너님도 내가 리액트 개발자니까 리액트 네이티브도 쉽게 할 수 있다고 생각하신 것 같았다.(난감)

첫번째 위기가 찾아왔다. 나는 지난 1년 넘게 웹 프론트엔드 부분을 집중적으로 공부해왔기 때문에 앱을 제대로 만드는 것은 처음 이였다. 이때 선택지는 크게 두가지였다.

1. 리액트 네이티브로 앱을 만들고, 웹뷰를 감싸서 웹뷰(React)에서 모든 서비스를 개발

2. 리액트 네이티브로 처음부터 앱 개발

처음엔 원래 하려고 했던 대로 1번 방법을 떠올렸다. 하지만 UI/UX적으로 웹에서 앱스러운 경험을 선사하는 것은 쉬운일이 아니였다. 특히 페이지 간의 이동(navigation)을 앱처럼 구현하는 것은 꽤나 복잡하고 어려운 일이다. 당근마켓에서 만든 stackFlow 같은 웹에서 앱 navigation을 구현하는 라이브러리들이 있었지만 여전히 한계점은 존재해 보였다. 결국 리액트 네이티브로 스크린을 만브로 모든 페이지의 navigation을 만들고 각각의 screen에 웹뷰를 매칭해야 하는데 굉장히 비효율적으로 느껴졌다.

게다가 앱을 만들다보면 여러 페이지(screen)들 간의 다양한 인터렉션 또한 개발해야 하는데 (예를들어 게시판 목록 스크린에서 특정 게시글을 터치했을 때 상세 게시글 페이지가 화면 옆에서 transition 등장), 이를 일일히 웹뷰와 리액트 네이티브가 통신하며 동작하게 만드는 것은 더더욱 비효율적으로 느껴졌다.

또한 기획에서 웹이 배제되었다. 웹이 기획에서 빠지자, 통일된 경험을 줄 필요도 없기 때문에 굳이 웹뷰로 개발할 필요가 없다고 느껴졌다.

게다가 기획에서 인앱결제, 로컬푸쉬알림, 달력기능 등 native 기능들이 많았다. 때문에 어차피 리액트 네이티브 혹은 swift까지 개발해야 하는 상황이였기 때문에 웹뷰와 리액트네이티브 둘을 나눠서 개발하는 것이 개발속도, 유지보수, 성능 등 모든 면에서도 좋지 못하다고 판단했다.

내가 생각했을 때 웹뷰의 유일한 장점은 빠른 배포로 인한 유저의 피드백 반영이였는데 이 점 또한 리액트 네이티브의 코드푸시로 어느정도 보완이 가능하다고 판단했다.

반면 리액트 네이티브는 학습비용을 제외하면 모든면에서 합리적인 선택이라고 느껴졌다. 물론 리액트와 리액트 네이티브는 다른점도 많았고 학습해야 할 것도 많았다.

리액트 네이티브는 기존 리액트에서 사용하는 컴포넌트 개발 방식, 생명주기, hook 등 거의 모든게 동일하게 사용 하지만 css style에서 차이점이 많았다. 또한 엄연한 앱이기 때문에 react native의 javascript 스레드가 native 스레드와 어떻게 유기적으로 동작하는지 Bridge 등 생소한 개념들을 학습해야 했다. (대충 알고 넘어갔다가 애니메이션 개발, 라이브러리 커스텀 할때 피봤다.) 그리고 그러한 앱의 특성과 UI/UX 리액트 네이티브의 동작 등을 공부하다 보니 결국 native(IOS/ANDROID) 도 공부해야 한다는 것을 알게 되었다.

다행히 개발 시작 전 1주일정도 학습할 수 있는 시간이 있었고, 1주일동안 퇴근후에도 매일 리액트 네이티브를 학습하였다. 그리고 1주일 뒤 나는 할 수 있다는 확신을 얻었다. 그렇게 기술스택 선정과 이유 사용할 라이브러리 와 환경 세팅에 대한 문서를 작성하여 공유하였고, 리액트 네이티브로 앱 개발을 시작하게 되었다.