TL;DR - 사용하고자 하는 기술의 특징이 현 상황에서 장점으로 다가올 수 있는지, 고민하고, 또 고민하자.
현재 재직중인 회사에서, 2019~2021년 사이에 생성된 프론트엔드 프로젝트는 모두 MobX를 사용하고 있었다. 나는 당시 백엔드로 입사했다가 얼떨결에 프론트엔드 직무로 배치받아서, 아무것도 모르는 쌩초보였다. 한 달 동안 프론트엔드 기초, React, MobX를 미친듯이 공부하여 업무에 투입되었다. 당시 나는 '왜'보다는 '무엇을', '어떻게'에 집중했고, MobX가 왜 채택되었는지, 그리고 왜 Redux 가 채택되지 않았는지에 대한 의문점을 해소할 생각조차 하지 않았다. 그리고 그 '왜'에 대해 충분히 생각해보지 않은 대가는...
'그 많은 상태관리 라이브러리 중에 왜 하필 MobX를 쓰셨나요?'
이 질문에 제대로 답하지 못함으로써 화끈거리는 나의 얼굴이었다. 이 질문을 들으면 나는 항상 MobX의 특징에 대해 읊기만 했다. 질문자는 Why(이유)에 대해 물었지만, 나는 What(특징)을 말하고 앉아있는, 동문서답을 하는 그림이었던 것이다.
정말 왜 MobX를 사용했을까? 궁금해서 당시 의사결정을 하셨던 분들과, 나의 뇌피셜을 조금씩 섞어서 이유를 추론해보았다.
입사년도인 2021년으로 돌아가보자
앞서 언급했듯이, 나는 원래 백엔드였다. 기술 면접도 백엔드로 보고 들어왔는데, 뜬금없이 회사에서는 프론트엔드 인력이 부족하다는 이유로 나를 프론트엔드로 배치했다. 지금은 상상하기 힘든 일이다. 쌩 신입인 나로서는 이 결정에 대한 이의제기를 할 위치가 아니었고, 속으로 'X됐다'만 반복하고 있었다. 프론트엔드에 대한 지식이 거의 없었던 나는, 학창시절 자바스크립트, 제이쿼리와 씨름했던, 좋지 않은 기억이 많았기 때문이다.
'아니 this가 있는데 왜 undefined냐고!!'
'데이터타입은 왜 멋대로 바뀌어?'
'근본없는 언어네'
이런 부정적인 이미지로 가득한 프론트엔드를 해야 한다니, 정말 막막했다. 그런데 막상 해보니...
프론트엔드... 할 만 하네?
한 달 동안 프론트엔드를 속성으로 공부해서 React, Typescript, MobX를 익히고, 간단한 버그처리 업무에 투입되었다. 그런데 코드를 분석해보니 매우 객체지향적으로 프로젝트가 설계되어 있었고, 스프링 공부를 했다면 익숙한 MVC 구조랑 비슷한 MVVM 구조로 이루어져 있었다. 여기서 MobX의 특징이 장점으로 빛을 발했다.
MobX는 객체지향이다 = 백엔드(자바, 스프링) 개발자에게 익숙하다 = 러닝 커브가 완만하다
러닝 커브가 완만하다는 것은 확실히 알겠는데, 이는 MobX를 선택한 이유로는 충분하지 않다고 생각했다. 좀 더 과거로 돌아가서, 당시의 상황을 파악해볼 필요가 있었다.
입사하기 전인 2019년으로 돌아가보자
앞서 말한 백엔드에서 프론트엔드로 강제 전향한 사건을 다시 되짚어보았다. 당시 채용 공고는 '프론트엔드', '백엔드'를 따로 뽑지 않았다. 그냥 '웹 개발자' 였다. 그리고 얼핏 들었던 말이 생각났다.
'프론트엔드와 백엔드의 경계가 명확해진 지는 얼마 안 되었다'
그렇다... 현재 다니는 회사는 당시 백엔드와 프론트엔드 간의 업무 바운더리를 잡아가는 과도기였던 것이다. 실제로 입사하고 난 지 1년 후부터는 백엔드와 프론트엔드를 확실히 구분하여 채용하기 시작했다.
그럼 2019년에도 다니고 계셨던 프론트엔드 선배님들은..?
원래 계시던 분들은 처음부터 프론트엔드 개발자가 아니었고, 다른 개발을 하셨던 분들이었다. MFC 개발, 안드로이드 개발, 서버 개발 등등... 다양한 분야의 개발을 하신 분들이 프론트엔드를 다시 배워서 전향하신, 회사에서는 개척자같은 분들이셨다.
MobX는 당시 최선의 선택이었다
MobX의 특징을 나열해보자.
- 간단하다 - Observer, Observable, Action과 같이 주된 개념만 알면 바로 사용 가능하다.
- 객체지향적이다 - 자바스크립트 ES6부터 나온 class를 적극 활용한다.
- 개발자가 신경쓸 부분이 적다 - Redux처럼 Reducer, Selector, Dispatch 등 복잡한 코드를 작성하지 않아도, MobX가 다 알아서 해준다.
생판 모르는 프론트엔드 분야로 뛰어들은 선배님들은, 새로운 기술을 공부할 시간이 많지 않았을 것이고, 빨리빨리 공부해서 바로 개발을 시작해야 했을 것이다.
그리고 여기서 MobX의 특징은 장점으로 발휘되었다.
- 간단하다 -> 금방 공부해서 바로 써먹을 수 있다.
- 객체지향적이다 -> 서버, 안드로이드 등 다른 분야의 개발자에게 익숙한 개념이기에 러닝 커브가 완만하다.
- 개발자가 신경쓸 부분이 적다 -> 빠른 개발이 가능하다.
이렇게 해서 최종적으로 MobX가 선택받았고, 이후로는 회사의 표준이 되다시피 모든 프로젝트들이 관성적으로 MobX를 사용하게 되었다.
2022년 이후부터 시작된 프로젝트는 MobX를 사용하지 않는다. MobX도 충분히 좋은 상태관리 라이브러리이지만, 상태관리 라이브러리의 선택지가 매우 많아졌고, MobX의 장점+@를 갖고 있는 라이브러리들을 선택하지 않을 이유가 없다. 더 나아가, 프론트엔드 개발자들의 지식 수준이 많이 상향 평준화 되어서, 신입들도 최근에 나온 기술스택(TanStack Query, Recoil, Zustand 등)을 이미 잘 다루기 때문에(해당 라이브러리들의 러닝 커브가 낮은 것도 한 몫 하는듯) 러닝 커브에 대한 걱정도 많이 줄었다. 선택지가 많아진 만큼, 각 선택지를 비교하면서 고민할 시간도 많아지게 된 것 또한 문제이긴 하다...
장점은 발휘되지 않으면 그냥 특징일 뿐이다
나는 애플워치 울트라를 사용한다. 왜 샀냐고 하면, '러닝을 할 때 더 정확한 GPS 측정을 하기 위해서' 라고 바로 말할 수 있다. GPS 측정이 일반 애플워치보다 더 정교하다는 특징이 러닝 활동에서 장점으로 발휘된 것이다. 아무런 스포츠 액티비티를 하지 않는 사람이 애플워치 울트라를 사용한다면, 그들에게는 정교한 GPS 측정, 수심 측정 등은 장점이 아니라 그냥 특징일 뿐이다.
애플워치 울트라를 살 때는 이렇게 Why가 명확했는데, 왜 기술을 채택할 때의 Why는 명확하지 못했을까 후회된다. (내 백만원돈이 걸린 문제여서 그랬을지도..)
'이 기술의 특징이 내 프로젝트, 내 상황 등에 장점으로 발휘될 수 있는가?' 에 대해 치열하게 고민해보자.
