[front-end] 기술에 잡아먹히지 마세요.

Sming·2024년 4월 21일

frontend

⚠️ 이 글은 매우 주관적인 의견을 작성한 것입니다.

요즘 사이드 프로젝트를 보다 보면 매력적인 기술, 아키텍처들이 많습니다.

사실 저도 여기서 키워드 정도와 사용 용도는 알지만 실제로 사용해보지는 않은 것들이 대부분입니다.

최근에 본 것이라고 하면 다음과 같은 기술, 아키텍처들이 핫한 것 같더라고요.

funnel
xstate
feature slice design pattern
next 14(app router)
compound component pattern
monorepo
그 외 등등..

벌써 모두 사용만 해본다면 취업을 당해버릴 거 같은 기술 스택이네요.. 기업의 자격 요건 및 우대 사항에도 본 것 같은 기술들도 간간이 있군요.

그렇다면 이것들을 모두 사용한다면 잘하는 개발자이며 좋은 곳으로 취직하는 사람일까요?

뭐 물론 그럴수도 있다고 생각합니다. 프론트엔드 개발자의 핵심 중 하나는 새로운 기술을 빠르게 익히고, 이러한 기술에 관한 탐구를 하는 것 이라고 생각하기 때문이죠.

하지만 이것은 내가 어떤 이유로 사용했는지, 제품을 정해진 기간에 ＇잘＇ 만들어야 하는 경우 를 모두 전제돼야 한다고 생각합니다.

지난번에 작성한 공통의 저주 글과 유사하게 너무 많은 기술을 알게 된 프론트엔드 개발자가 겪는 기술의 저주라고 할 수 있겠네요.

이번에는 A라는 가상의 인물을 두어 한번 살펴보겠습니다.

A 씨는 프론트엔드 3명이서 간단한 페이지들을 개발하는데 nextjs 14(app router)를 사용하고 unit test 까지 달아주었습니다.

기술의 저주 - 내가 이유에 맞게 사용했는가?

먼저 얘기해볼것은 기술 선택의 이유입니다.

nextjs 14 (app router)

A씨는 왜 nextjs 14(app router)는 사용했을까요? 이에 먼저 nextjs는 왜 사용했을까요?

react를 보다 쉽고 설정에 대해서 좀 덜 고민하면서 개발할 수 있고, ssr, isr, ssg 같은 렌더링 전략을 통해 api를 fetch할시 사용자가 깜빡이는 ui를 보지 않을 수 있고, 서버에서 완성된 html을 제공하기에 seo에도 도움이 될 수 있겠죠.

하지만 이와 반대로 서버를 이용하기에 기존 간단하게 s3로 설정하던 react 배포가 nextjs가 되며 ec2, 더 나아가서 ecr, ecs 설정까지 해야될 수 있으며 그에 따른 서버 비용마저 고려를 해야 합니다.

만약 A씨가 단점보다 장점을 더 크게보아 선택을 한다면 정당한 이유가 되겠죠? 충분히 개발의 용이함만으로도 nextjs를 선택할 수도 있을 것입니다.

그렇다면 nextjs 14(app router)는 어떨까요?

제가 생각하는 장점은 다음과 같습니다.
컴포넌트별로 isr, ssr, ssg의 전략을 선택하여 사용할 수 있다는 것 정도 있을 것 같네요. server component의 zero-bundle은 실제 개발해보면 크게 체감이 되지 않기에 큰 장점이라고 하기에는 어려울 것 같네요.

그렇다면 단점으로는 무엇보다 개발의 피로도 증가가 있겠네요. 서버 컴포넌트의 등장으로 개발의 난도가 올라가고, 잘못 서버 컴포넌트를 사용하는 때도 매우 많습니다.

만약 A씨가 app router를 저 장점을 목적으로 사용했고, app router 개발에 매우 익숙한 사람이라면 충분히 선택할만한 가치가 있겠군요.

하지만 fetch도 많지 않고 그런 고려까지 할 필요없는 간단한 사이트라면 이는 당연히 불필요한 기술이라고 생각이 되는군요.

unit test

그렇다면 A씨는 왜 unit test를 이용하였을까요?

특정 모듈을 만들어 그것을 계속 검증해야 하거나 복잡한 상태를 지닌 컴포넌트에 대한 렌더 테스트를 진행할 때 unit test가 용이합니다.
하지만 간단한 상태만을 가진 페이지를 만들 때 굳이 unit test를 붙히는 것은 필요 없지 않을까라는 생각이 듭니다.

지금은 간단하게 app router, unit test를 사용한 가상의 A씨를 기준으로 알아보았는데 실제로는 이것 외에도 다양한 기술이 오용되고 있는 경우가 많습니다.

간단한 페이지, 구조에서의 feature sliced design (fsd)
확장성이 필요없는 컴포넌트에 compound component pattern
context api를 사용해도 충분할 규모에 recoil, jotai, zustand등의 상태관리 라이브러리 이용
굳이 monorepo로 분리하지 않고 관리해도 될 프로젝트를 monorepo로 관리

기술의 저주 - 제품을 고려하였는가?

다음은 제품을 고려하였는가 입니다.

아까 가상의 A씨를 다시 한번 불러와 보겠습니다.

A씨는 프론트엔드 3명이서 간단한 페이지들을 개발하는데 nextjs 14(app router)를 사용하고 unit test 까지 달아주었습니다.

프론트엔드 3명이서 페이지를 개발하고 있는 상황이군요. 하나의 조건을 추가하여 3주 뒤에 mvp를 만드는 것이 목표라고 가정하겠습니다.

여기서 만약 A씨는 app router에 대한 이론만 가볍게 알고, 나머지 두 사람이 app router에 대해서 전무한 상황이면 어떨까요?

3주안에 개발을 해야 되는데 기술 사용에 대한 어려움 때문에 제대로 된 제품 개발을 하지 못할 수 도 있습니다.

비슷하게 당장 돌아가는 제품을 내야 될 때 unit test를 붙이는 것도 목표한 개발기간에 맞추지 못하게 되는 원인이 될 수 있습니다.

물론 회사에서 넉넉한 기간을 잡고 기술적인 도전을 할 프로젝트인 경우 새로운 기술을 적용해보는 것이 좋은 선택일 겁니다.

하지만 다음과 같이 짧은 개발기간 안에 제품을 만들어야 하는 경우는 모든 팀원이 익숙한 기술이거나 러닝 커브가 적은 기술을 선택하는 게 최선일 것 같습니다.

항상 기술은 제품을 위한 수단이지 기술이 우선 돼서는 안된다는 것을 명심하시기를 바랍니다.

학습을 위한 기술 사용

하지만 기술 사용의 목적이 학습 인 경우가 종종 있습니다.

물론 새로운 기술을 학습하기 위하여 개인 프로젝트로 실습을 해보는 것은 매우 좋은 방법이라고 생각합니다.

하지만 이렇게 학습을 목적으로 사용한 프로젝트는 이력서나 포트폴리오에 기재하지 않는 것을 추천합니다.

새롭고 요즘 떠오르는 기술들을 사용하여 이력서에 기재한다면 당장은 서류가 아름다워 보일 수 있겠지만, 면접에서 그 프로젝트는 공격의 타겟이 될 가능성이 높습니다.

나에게 새롭고 떠오르는 기술이라면 당연히 면접관에게도 1순위 질문이 왜 이 기술을 사용하여 프로젝트를 구성하였는가? 일 수 있습니다.

만약 내가 어떠한 문제를 만났고 그 문제를 해결하기 위해서 이 기술을 선택하였고 그렇게 해결된 과정이 프로젝트에 녹여져 있다면 이 질문은 당연히 플러스가 될 것입니다.

반대로 그저 사용해보고 싶어서, 학습을 목적으로 사용한 프로젝트일 경우에는 최선의 대답이 사용해보고 싶었다, 학습을 목적으로 사용했다. 일 것입니다.
오히려 문제해결의 이유 없이 사용한 프로젝트에서 이러한 목적으로 해결했다고 하면 그것은 기술을 잘 모르고 사용했다라는 인식을 줄 수 있죠.

그렇기에 개인적인 프로젝트에서 특정 기술을 실습하면서 체화하고 실제 제품을 만들 때 문제를 만나면 그때 사용해봤던 기술을 적용해보는 게 좋다고 생각합니다.