TypeScript
- TypeScript를 사용하는 이유는 당연하지만 JavaScript가 이제 더 모던해 보이지 않기 때문이 아닙니다. TypeScript를 통해 JavaScript 코드를 기반으로 정적 타입 구조를 추가함으로써 개발자가 미연에 일으킬 수 있는 실수를 방지하고, 타입 추론 기능을 적극적으로 사용해 초기 도입 비용을 용인 가능한 수준까지 낮출 수 있기 때문입니다.
- TypeScript는 다른 JavaScript로 컴파일되는 정적 언어와 비교했을 때, Hindley-Milner 타입 추론등의 정적 타입 시스템의 편의 기능을 도입하지 않았습니다. 그렇지만 TypeScript만이 가질 수 있는 장점과 비교해봤을 때는 용인 가능한 수준의 가치라고 생각합니다. TypeScript만의 장점을 나열하자면 이 정도가 있습니다.
- 커뮤니티가 강력하고, 트러블슈팅에서 커뮤니티의 도움을 받기 쉽습니다. 2022년 3월 24일 현재 Stack Overflow 질문수를 비교하자면, TypeScript 태그의 질문 수는 177,664개입니다. 대표적인 경쟁자로 생각되는 Elm, Flow, ReScript는 각각 1,821, 983, 58개입니다.
- 개발자들이 사랑하고, 점점 인기가 증가하고 있는 언어입니다. Node.js를 개발한 Ryan Dahl이 Node.js에 관해 후회하는 10가지라는 컨퍼런스에서 얘기한 것 중에, ‘Node는 기본적으로 TypeScript를 지원하지 않는다’ 라는 내용이 있습니다. 동시기 그는 Rust를 사용한 새로운 JavaScript 런타임인 Deno를 만듭니다. 이 런타임은 TypeScript를 런타임 자체의 기능으로 지원하고 있습니다.
React
-
React를 사용하는 두 가지 이유는 반응성 유지와, 컴포넌트를 이용한 코드 재사용을 위해서입니다.
- 반응성이란 것은 쉽게 말하면 데이터가 바뀌면 화면도 바뀌는 개념을 의미합니다. 기존 jQuery나 JavaScript DOM API에서는 재렌더링 과정이 명시적으로 상태 관리와 연동되어 동작하지 않았기 때문에 개발자가 명시적으로 콜백 함수등을 통해 데이터가 갱신된 이후에 DOM 갱신을 직접 구현해야 했고, 이것은 생산성 저하와 사용자에게 좋지 않은 경험을 줄 수 있습니다. 이런 문제를 피하기 위해서 React는 useState 훅을 제공함으로써 상태 변화시 자체적으로 데이터 갱신을 처리합니다. React 내부에서 단순히 컴포넌트를 다시 렌더링함으로써 구현할 수 있습니다. 조금 더 알아보시고 싶으시다면, 다음 문서들을 참고하세요.
- 컴포넌트를 이용한 코드 재사용은 기존의 프론트엔드 라이브러리에서 제공해주지 않던 개념이었습니다. 저희는 Function Component를 사용하겠습니다. Class Component의 작동 원리인 Life Cycle은 프론트엔드 개발자를 혼란시키고, 생각으로 작동을 예상하는 것이 어려워 직관적이지 않습니다. FC에서 제공하는 Hooks를 사용하여 기본 공리를 조합하고 이용함으로써 수많은 비즈니스 로직을 작성할 수 있습니다. 기본 React Hooks의 목록과 상세 사항을 알아보시고 싶으시다면, 다음 문서를 참고하세요.
-
물론 이 두 가지 요소는 대부분의 모던 프론트엔드 프레임워크들이 제공하는 요소기도 합니다. 수많은 프레임워크중 React를 선택한 가장 큰 이유는, 프론트엔드 개발자들이 사랑하고 가장 인기를 끄는 프레임워크이기 때문입니다. Stack Overflow 2021 Developer Survey에서 React는 Web framework 분야중 1위를 차지했습니다.
Zustand
- Redux는 React 생태계의 비교적 초기부터 등장한 상태 관리 라이브러리로, Flux 패턴을 개선한 아키텍처를 가짐으로써 단방향 데이터 흐름과 순수 함수의 사용이라는 성취를 이루어냈습니다. 그러나 2022년 현재 Redux 및 그 생태계에 속하는 상태 관리 라이브러리를 사용하는 것은 좋지 못한 기술적 결정이라고 생각합니다.
- Redux의 학습 난이도는 높기 때문에, 경험이 적은 개발자들이 React를 사용한 프론트엔드 개발을 포기하게 되는 가장 큰 이유중 하나라고 생각합니다.
- 그래서 저희는 Zustand을 채택했습니다. Flux 패턴을 유지하면서 Redux보다 확연히 낮은 러닝 커브를 가지고 있으며, 비동기를 간편하게 적용할 수 있고 개발자가 Provider를 래핑할 필요 없이 전역 상태 관리를 편리하게 할 수 있습니다.
- 그 외에 개발자 친화적이고, 커뮤니티가 강력한 상태 관리 라이브러리로는 Recoil과 Jotai가 있습니다.
Next.js
- Create React App은 퍼포먼스적 문제가 큰 Babel을 사용하고 있고, devDependencies와 dependencies를 구분하지 않아서 좋지 못한 설계를 가진 라이브러리라고 생각합니다. 만족스러울 정도로 추상화를 하지 못한 탓에, 결국 개발자가 고생을 각오하고 추상을 걷어내기 위해
yarn eject라는 조치를 취하게 되는, 잘못 개발된 프로그램이라고 생각합니다. - 이런 문제를 피하기 위해, 저희는 Next.js를 누군가가 만들어둔 React 웹 애플리케이션의 Best Practice라는 개념으로 접근해서 채택했습니다. 서버 사이드 렌더링등의 부가 기능은 아직 깊게 고민하지 않아도 된다고 생각합니다.
SWR
- React 웹 앱에서 외부 데이터를 가져오는 방법은 여러가지가 있습니다. useEffect등을 사용해도 되고, Redux등을 사용한다면 그 로직을 이루는 코드에 같이 작성해도 됩니다. 그러나 Next.js를 도입한 이유와 비슷한 이치로 저희는 코드의 세부사항이 아니라 외부 데이터를 가져오는 행위 자체에만 신경쓰기 위해서 SWR이라는 라이브러리를 사용하려고 합니다.
- 대체재로 여겨지는 라이브러리로, React Query가 있습니다. 저희는 프로젝트에 Next.js를 도입하기로 결정했기 때문에 Next.js와의 호환성에 문제가 있는 React Query가 아닌 같은 Vercel사에서 만든 SWR을 선택했습니다.
MUI & Tailwind CSS
- 필요한 컴포넌트를 직접 만드는 것보다 수많은 개발자들이 관리하고, 사용하고 있는 컴포넌트 라이브러리의 구성요소를 가져오는 것이 안정성, 품질, 성능과 개발 생산성 면에서 더 나은 선택입니다.
- MUI는 커스텀 가능한 컴포넌트를 제공하고, Tailwind CSS는 커스텀 CSS 클래스를 제공하기 때문에, 다른 디자인 라이브러리 없이도 두 라이브러리의 조합으로 충분히 원하는 디자인을 퍼블리싱하기 쉽습니다.
Kakao Map or Naver Map
- 구글 지도와 애플 지도는 기본적으로 전세계를 다루고 있고, 국내법상으로 해외 기업이 국내 지도를 반출하는 것에 관련해서 규제에 적용받는 요소가 많아 국내 IT 대기업의 지도 서비스와 비교했을 때 정확성과 세밀함이 좋지 않습니다.
- 국내 지도 서비스중에서도 카카오와 네이버가 관련 산업을 통해 가장 발전된 디지털 지도를 보유하고 있는 기업이라고 생각합니다.
ESLint & Prettier
- 개발자가 가독성 있는 코드를 작성하고 그 컨벤션을 수동으로 관리하는 것 보다, 코드를 자유롭게 작성하고 린터와 포매터를 통해 자동으로 관리하는 것이 더 낫습니다.
- 다만, 개개인마다 이상적이라고 생각하는 코딩 스타일이 전부 다르기 때문에 정확히 어떤 규칙을 채택하고, 채택하지 않을 건지는 팀원들간의 논의의 여지가 있습니다.
Figma or Zeplin