기술은 수단이지 목적이 아닙니다

들어가며

최근 웹 애플리케이션의 복잡도는 그 어느 때보다 빠르게 증가하고 있습니다. 이와 함께 이를 해결하고 개선하기 위한 다양한 기술과 아키텍처가 매일같이 등장하고 있죠. 특히 프론트엔드 분야는 그 변화의 속도가 놀라울 정도로 빠르다고 느껴집니다. 매년 새로운 프레임워크, 상태 관리 라이브러리, 디자인 패턴이 쏟아지면서, 개발자들은 트렌드를 따라가기 위해 끊임없이 공부하고 고민하게 됩니다.

그렇다면, 정말 모든 새로운 기술을 고려하고 도입해야 할까요? 이번 포스팅에서는 기술 선택의 기준에 대해 이야기하며, 트렌드에만 의존하지 않고 프로젝트에 정말 필요한 기술을 선택하는 방법에 대해 고민해보려 합니다.

• next14(app router)
• Feature-Sliced Design (FSD)
• Zustand

나름대로 요즘 주목받고 있다고 생각되는 기술과 아키텍처를 간단히 나열해봤습니다. 여러분은 기술을 도입하고 사용할 때 어떤 기준을 가지고 선택하시나요? 요즘 핫한 기술이라서, 주변 개발자분들이 많이 사용해서 등 다양한 이유가 있을 수 있습니다.

이러한 이유로 새로운 기술을 접하는 것은 자연스러운 일이지만, 위 이유만으로 기술 스택을 도입하고 사용하는 것은 위험하다고 생각합니다. 최소한 그 기술이 널리 사용되는 이유와 현재 사용하고 있는 기술과 비교했을 때 어떤 장단점이 있는지와 해당 기술이 가진 한계점에 대해 충분히 고려한 후 도입해야 된다 생각합니다.

트렌드가 정답은 아니다

사실 당연한 말이지만, 막상 주변에서 여러 사람들이 특정 기술이 좋다고 추천할 때, 나만 그 기술을 쓰지 않으면 뒤처지는 것 같은 느낌이 들기 마련입니다. 그러다 보면 새로운 기술로 바꿀 핑계를 찾기 위해, 지금까지 잘 사용해오던 기술에 괜히 트집을 잡게 되는 경우도 종종 생기죠. 하지만 이럴 때일수록 문제 해결에 정말 필요한 기술인지, 프로젝트의 요구 사항에 적합한 기술인지를 판별하는 것이 제일 중요하다고 생각합니다.

나무 대신 숲을 보자

새로운 기술은 마치 숲 속에서 자라나는 나무와 같습니다. 나무가 숲에 뿌리를 내리고 성장하듯, 새로운 기술도 기존 기술을 기반으로 발전하고 파생되는 경우가 많습니다. 예를 들어, Zustand는 Redux의 useSelector 훅과 비슷한 역할을 하지만, 컴포넌트 트리에 종속되지 않고 상태를 다루는 것을 개선한 useStore 훅을 사용하여 React 컴포넌트가 아닌 비 UI 로직에서도 상태를 쉽게 사용할 수 있다는 장점을 제공합니다. Jotai는 Recoil과 유사하게 atom 개념을 사용하지만, 이를 더욱 단순화하여 상태 관리의 유연성과 직관성을 높였습니다. 이처럼 새로운 라이브러리들은 기존 기술에 뿌리를 두고 발전하면서, 특정 문제를 해결하거나 개선하는 방향으로 진화합니다.

그렇기에, 기존 기술의 원리와 작동 방식을 충분히 이해하고 있다면, 새 기술도 그 연장선에서 자연스럽게 받아들일 수 있기에 너무 조급하거나 불안해하지 않아도 된다 생각합니다.

기술 선택 기준

기술을 선택하는 기준은 사람마다, 혹은 상황에 따라 다를 수 있지만, 제가 생각하는 기술 선택 요소는 다음과 같습니다

1. 현재 프로젝트의 문제를 해결할 수 있는 기술인가?
도입하려는 기술이 실제로 프로젝트에서 직면한 문제를 해결할 수 있는지 신중하게 검토해야 합니다. 기술 자체가 목적이 되어서는 안 되며, 문제 해결과 효율성 향상을 위한 목적으로 접근해야 합니다. 해당 기술이 프로젝트의 문제를 구체적으로 어떻게 해결할 수 있는지, 그리고 기존에 사용 중인 기술보다 더 나은 방법을 제공하는지 고민하는 것이 중요합니다.

2. 팀 프로젝트라면, 팀원들이 쉽게 사용할 수 있는 기술인가?
혼자 진행하는 프로젝트라면 문제가 없겠지만, 팀 단위로 작업하는 경우라면 팀원들이 새로운 기술을 쉽게 습득하고 적용할 수 있는지 고려해야 합니다. 러닝 커브가 너무 높으면, 학습에 드는 시간과 비용이 커져 프로젝트 일정에 부담을 줄 수 있기에 해당 기술 도입전 팀원들과 충분한 상의를 겨처 도입해야 합니다.

3. 기술의 단점도 충분히 파악했는가?
모든 기술에는 장점뿐만 아니라 단점도 존재합니다. 도입하려는 기술의 장점만큼이나 한계와 단점을 충분히 이해하고, 그것이 프로젝트에 어떤 영향을 미칠지 어느정도 예측해보면 도입 여부를 보다 확실하게 선택할 수 있습니다.

기술 학습 방법

기술을 도입하기로 결정했다면, 이제는 그 기술을 학습하기 시작할 텐데요, 공식문서, 블로그, 유튜브, 인터넷 강의 등 학습 방법은 다양하지만, 저는 공식문서가 있다면 항상 공식문서를 우선적으로 참고합니다.

공식문서를 먼저 읽어보자

기술 도입 시 가장 먼저 공식문서를 참고하는 이유는, 해당 기술을 개발한 개발자들이 직접 작성한 문서이기 때문에 신뢰성과 정확성 면에서 뛰어나기 때문입니다. 그럼에도 불구하고 많은 사람들이 공식 문서를 읽는 것을 주저하는 가장 큰 이유는 언어 장벽에서 오는 거부감이라고 생각합니다. 저 역시 과거에는 개인 블로그나 번역된 자료를 더 선호했지만, 종종 잘못된 정보가 포함된 경우가 많았고, 이를 해결하는 데 오히려 더 많은 시간이 들었던 경험이 있습니다. 시간이 조금 더 걸리더라도 공식문서를 먼저 읽는 것이 결국에는 시간을 절약하는 방법이라 생각합니다.

영어 울렁증이 있어요…

영문서가 부담스러운 경우에는, 해당 기술의 공식 문서를 번역한 오픈소스나, 아티클이 있는지를 먼저 검색하거나 DeepL과 같은 번역 확장 프로그램을 통해 번역에 도움을 받는 방식을 사용하는 것을 추천합니다. React, NextJs, TanstackQuery와 같이 국내에서 많이 이용하는 기술의 경우에는 오픈소스를 통해 번역이 잘 되어있습니다.

맺음말

기술은 빠르게 발전하고 새로운 트렌드는 끊임없이 등장합니다. 트렌드를 따라가는 것도 중요하지만, 궁극적으로는 우리에게 맞는 도구를 선택해 문제를 해결하는 것이 더 중요한 목표입니다. 결국, 기술은 수단일 뿐이며, 문제 해결을 위한 도구로서 그 본질을 이해하고 사용한다면 더 현명한 판단을 내릴 수 있을 것이라 생각합니다.