사용자와 모요 서비스의 접점을 만들어가는 
Frontend 챕터

모요에는 다양한 구성원이 좋은 사용자 경험을 제공하는 서비스를 만들기 위해  노력하고 있는데요. 

오늘은 그 중에서도 양명수 님과 함께 모요에서 프론트엔드 개발자(Frontend Developer)로 일한다는 것은 어떤 의미인지, 최근에는 어떤 문제를 해결하고 있는지에 대하여 이야기 나눠봤어요.

DRI(Directly Responsible Individual)는 책임과 권한의 주체를 의미하는데, DRI가 의사결정을 하는 과정에서 많은 챌린지를 받아요. 챌린지를 해소하기 위해 큰 노력을 하게 되는데, 이 과정에서 더 좋은 결정과 제품이 만들어진다고 생각해요. 제품을 만들어가는 과정에서 동료들의 다양한 챌린지를 받으며 충돌도 생기고 고민도 하게 되지만, DRI라는 명확한 기준을 갖고 충분히 의견을 공유하며 해결하고 있다고 느꼈어요.

명수 : 기본적으로 스쿼드 내에서는 제품을 만드는 일에 집중한다면, 챕터 차원에서는 프론트엔드 개발로서 챙겨야 할 여러 기술적인 부분들을 챙기고 있어요. 단순히 기술적인 이슈 자체에 집중하기 보다는, 기술을 통해서 더 빠르게, 제품을 잘 개발할 수 있도록 하는 부분에 집중하고 있어요.

구체적으로 이야기해 보면, 디자인 시스템, 공통 시스템, 모노레포, MSA 등을 시도하고 있고, 플러터로 앱을 개발하는 것도 FE챕터에서 챙기고 있어요. 다만 이러한 챕터 차원의 업무를 위해 별도로 특별한 시간을 보내지는 않고, 풀어야 할 문제의 우선순위를 정해 스쿼드 업무 사이사이에, 또는 피트스탑 기간에 나눠서 잘 해결하려고 노력하고 있어요.

명수 : 자율과 책임이 가장 중요한 것 같아요. 모요는 일을 잘, 그리고 빨리하기 위해서 많은 부분을 자율에 맡기고 있어요. 근무시간부터 장소, 무제한 휴가까지 완전 자율적으로 운영되고 있어요.

많은 분들이 이런 근무 제도를 복지라고 생각하실 수 있지만, 모요에서는 일을 더 효율적으로, 더 잘하기 위해서 많은 부분을 자율제로 운영하고 있어요. 사실 신뢰가 없다면 이런 시스템이 도입되기 힘든데요, 이런 신뢰를 지키기 위한 건 역시 항상 각자의 책임을 다하는 거라고 생각해요. 너무 기본적인 것들이라 일일이 나열하진 않을게요!

기본적으로 모요에는 모두 각자의 분야에서 확실한 경험과 경력을 쌓아온 분들이다 보니, 언제든 도움을 요청할 수 있는 동료들이 있다는 게 정말 든든해요. 특히 챕터 내부에서 필요한 일을 할 때 실감하는데요. 모두가 업무를 나눠서 할 때, 맡은 부분을 확실하게 끝내줄 것이라는 믿음이 있어서 부담 없이 맡길 수 있어요.

최근에 앱을 리빌딩하기 위해, React Native에서 Flutter로 변환하는 작업을 FE 챕터에서 진행했는데요. 이때, 짧은 기간 내에 이전하느라 파트를 명확히 나눠 작업했었어요. 각자 맡은 부분을 잘 끝낸 덕분에 기간 내에 잘 전환할 수 있었죠.

명수 : 모든 모요 제품의 프론트엔드는 기본적으로 React, TypeScript 로 개발하고 있어요. API 호출은 주로 axios와 fetch를 핸들링해서 사용하고 있는데요. 최근에는 ReactQuery를 사용하려 하고 있고, 상태 관리는 필요한 곳에만 일부 zustand를 쓰고 있어요. 스타일링은 이것저것 사용하는 과도기를 거쳐서 현재는 vanilla extract를 적극적으로 도입하고 있네요!

모요 홈은 Next.js를 활용해서 SSR이나 ServerComponent 같은 것들도 최대한 잘 활용하고 있는데요. 통신사들이 사용하는 파트너스 및 내부 어드민들은 Next.js를 사용하고 있진 않아요. 꼭 특정 기술 스택만 써야 한다고 정해져 있는 건 없어요!

더불어 프론트엔드 개발자라면 상태 관리를 구체적으로 어떻게 하는지도 궁금하실 텐데, 전 프로덕트에 걸쳐서 최대한 상태 관리를 사용하지 않는 쪽에 무게를 두고 있어요. 최대한 작게 유지해서 불필요한 상태 관리와 의존성을 만들지 않으려고 해요.

프로젝트 관리는 지금 과도기인 것 같아요. 각 프로젝트 성격에 맞춰서 잘 관리할 수 있는 방식을 고민하고 있어요. 비슷한 케이스가 반복되는 어드민 및 파트너스를 비롯한 고객사 제품군은 모노레포, MSA 형태로 관리 중이고, 모요 홈은 Next를 더 잘 사용하기 위해 구조를 개선하고 있고요.

배포와 관련해서도 많은 시도를 해보고 있어요. 기본적인 자동화들은 다 되어있지만, 배포가 잦은 회사의 특성상 조금 더 개선하기 위해 여러 시도를 하고 있어요. 최근에는 빠른 배포가 필요한 테스트 환경에만 Vercel을 도입하려고 테스트하고 있네요.

명수 : 레거시 코드를 잘 정리하기 위해 여러 노력을 하고 있어요. 최대한 관심사를 잘 분리하고 반복되는 영역을 줄이려 하고 있죠. 그 일환으로 디자인 시스템과 모노레포, 유저 활동 로거, 여러 시스템적인 요소를 놓치지 않고 잘 챙기고 있는데요. 이 모든 기술적인 활동의 목표가 완성도 높은 시스템이 아닌 ‘좋은 프로덕트를 만들기 위해서’라는 게 강점인 것 같아요.

실제로 어드민 사이트들도 모노레포 안에 MSA형태로 여러 패키지를 결합해서 서비스하고 있는데요. 본격적으로 전체를 갈아엎는 건 아니지만, 가능한 부분들은 좋은 아키텍처를 적용하기 위해 노력하고 있어요.

그리고 디자인 시스템이 잘 되어있다는 점도 이야기하고 싶어요! 디자인 시스템은 사실 프론트엔드 개발자 보다 디자이너의 역량이 훨씬 중요한 파트인데요. 모요에서는 디자이너분들도 적극적으로 참여해 주셔서 개발 및 유지가 잘 되고 있거든요.

마지막으로 ”사용성”을 최대한 챙기려고 하고 있는데요. 모요 앱을 ReactNative에서 플러터로 전환하는 작업을 진행한 것도 이런 목표를 달성하기 위한 방안 중 하나예요. 처음에 만들어진 모요 앱은 React Native로 개발되었었는데, 개발 텍스트를 유지하는 어려움이 있어서 일종의 버스팩터(Bus Factor)*처럼 FE챕터에 남아있는 문제 중 하나였어요 손대기 어려워서 점점 방치되는 문제를 되풀이하지 않기 위해서 개발 환경 설정이 편한 플러터로 전환하게 되었습니다. 그리고 여러 명의 프론트엔드 개발자들이 틈틈이 앱의 사용성 개선하는 작업을 하고 있어요.

이를 위해 여러 방향에서 관련된 목소리를 많이 내려고 하고 있어요. 조직문화의 변화는 쉽게 이루어지기 어려운 만큼 꾸준히 이야기하는 게 중요하다고 생각해요. 더불어 개발적으로도 챙길 수 있는 부분도 고민하고 있어요. 아무래도 가설을 검증하기 위해 A/B 테스트를 많이 하다 보니 반복적으로 이루어지는 일들이 많은데요. 이 부분을 효율화하면서도 A/B 테스트의 장점은 잘 유지할 수 있을지 고민하고 있어요. 이런 고민은 FE챕터에서 많이 다뤄보려고 하고 있고요!

명수 : 비즈니스적으로 성장하는 동시에, 개발적으로도 성장하는 것은 어려운 일이라고 생각해요. 특히 초기 스타트업은 생존과 성장이 우선이기 때문에 개발적인 부분을 잘 챙기기는 정말 어려운 것 같고요. 그래서 제 목표는 회사의 성장을 잘 챙기면서 기술적인 부분도 잘 챙기는 것이에요. 나중에 모요가 성공해서 돌아봤을 때, “아 우리 기술적으로도 많은 성공을 이뤘다”는 느낌을 받고 싶어요. 물론 성공했다고 하려면 유니콘은 돼야 하니 아직 멀었지만요! (웃음)

명수 : 협업의 가치를 잘 알고, 팀을 통해 뭔가 잘 이루고 싶은 분이라면 잘 맞을 것 같아요. 개발 관점으로 좁혀서 이야기해 보면, 기술적으로 깊이 파고 들어가기보다 좋은 제품을 만드는 것이 더 중요하다고 생각하는 분이 잘 맞을 것 같고요. 기술은 제품을 만드는 하나의 도구라고 생각하시는 분이면 좋을 것 같아요.