2022 트렌트 리포트 (Framework, Library, 언어 변화)

[yoon-chaejin]

TIOBE Index

• Google 에 "Programming Language Ranking"을 검색했을 때 첫 결과
• https://www.tiobe.com/tiobe-index/
• 의외로 많은 알려진 언어들 중에서도 몇 년간 Top 20에 들어오지 못한 경우가 많음 이례적으로 Rust가 높은 인기를 보이는데, 주요 원인은 Rust만의 독특한 속도와 안정성의 조합 방식임

  For years now, we are waiting for languages such as Kotlin, Dart, Julia to work their way into the TIOBE index top 20, but without success.

The only exception to this seems to be Rust. Rust entered the top 20 last month and managed to keep its position this month. The main reason for Rust's rising popularity is its unique combination of speed and safety. Let's see whether Rust is here to stay.

[yoon-chaejin]

React 18

• Google에 "React 18"을 검색했을 때 Top 3 결과
• https://reactjs.org/blog/2022/03/29/react-v18.html
• https://tech.osci.kr/2022/05/03/react-18v/
• https://velog.io/@woodong/React-18-%EC%A3%BC%EC%9A%94-%EB%B3%80%EA%B2%BD%EC%A0%90

무엇이 다른가?

Our latest major version includes out-of-the-box improvements like automatic batching, new APIs like startTransition, and streaming server-side rendering with support for Suspense. 주요 기능으로는 자동 배치, 신규 API, SSR 스트리밍 등이 있다.

Many of the features in React 18 are built on top of our new concurrent renderer. 많은 기능들은 병행 렌더러에 기초한다.

React 팀이 18 버전을 통해서 개선하고자 했던 내용은 무엇일까요? 여러 가지 개선 사항이 있지만 그중 두 가지만 살펴보자면, 첫 번째는 Batching 작업을 통한 Rendering 퍼포먼스 향상, 두 번째는 새로운 기능인 Transition 을 통해 UI 업데이트에 우선순위를 부여하거나, 느린 네트워크 환경에서의 UX 향상을 살펴볼 수 있을 것 같습니다

좀 더 상세한 이야기를 영우 님 통해서 들을 수 있으려나...!

[syndersonlee]

개발 트렌드 2022

프론트엔드 트렌드

노마드코더

• https://www.youtube.com/watch?v=1XI7SB4YUj4
  • React, Vue.js, Svelte.js -> 컴파일 타임마다 사라짐
    • React -> Next.js (Gatsby, Remix, Redwood, Blitz)
    • Vue -> Nuxt
    • Svelte -> SvelteKit

백엔드 트렌드

DB

코딩애플

• https://www.youtube.com/watch?v=ZVuHZ2Fjkl4

노마드코더

• Strappi, KeyStoneJS
  • 어드민 패널 관리 시스템
• SASS 제품
  • AWS Amplify, supabase
• Serverless
  • Fauna DB
    • GraphQL, FQL 사용 (Not SQL)
  • Redis -> Redis JSON + Redi Search + Redi Cloud 를 결합하여
    • Document 형식 DB로 사용

모바일 트렌드

• React Native Skia
  • Flutter과 비슷한 개념 - GUI 적용

[ywoo-park]

모노레포를 활용한 모던 프론트엔드 프로젝트 구성

모노레포(Monorepo)

• 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략
• 즉, 단일 리포지터리에 여러 개의 서브 프로젝트가 존재하는 방식이다.

모노레포의 등장 배경

모놀리식 애플리케이션의 한계

• 코드가 서로 직접적으로 의존하며 단 하나의 버전으로 관리되면서 관심 분리(separation of concerns)가 어려워진다.
• 설계, 리팩터링, 배포 등의 작업을 매번 거대한 단위로 처리해야 하므로 개발상 많은 제약과 비효율이 있다.

  모듈화와 재사용성

• 이러한 모놀리식 구조의 한계는 모듈화(modularity)를 통해 해결할 수 있다.
• 일반적으로 모듈식 프로그래밍(modular programming)은 애플리케이션 로직의 일부를 재사용할 수 있도록 지원하고 전체 교체 없이 애플리케이션의 일부를 수정 또는 교체할 수 있게 해 유지 관리를 용이하게 한다.
• 멀티레포
  • 이렇게 만든 모듈이 다른 애플리케이션에도 사용될 수 있다면 소스를 어디에 위치시켜야 할까?
  • 아마도 해당 모듈을 위한 독자적인 저장소가 있다면 좀 더 관리하기 쉬울 것이다 -> 이 구조가 멀티레포(multirepo)

    멀티레포

• 분리된 각 모듈은 멀티레포 구조에서 고유한 저장소가 있는 독자적 프로젝트가 된다.
• 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.
• 멀티레포는 현재 대부분의 애플리케이션을 개발하는 표준적인 방법이다.
• 좋은 일인데 무엇이 문제일까?
  • 양날의 검처럼 이 자율성은 고립(isolation)에 의해 제공되고 고립은 협업을 방해한다.
  • 멀티레포를 통해 모놀리식 구조의 문제를 해결했지만 또다른 새로운 문제가 발생한다.

    멀티레포의 문제

1. 번거로운 프로젝트 생성
   • 새로운 공유 패키지를 생성할 때마다 다음과 같이 번거로운 과정을 거쳐야 한다.
   • 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
2. 관리 포인트 증가
   • 늘어난 프로젝트 저장소의 수만큼 관리 포인트가 늘어난다.
   • 린트, 테스트, 개발 모드 실행, 빌드, 게시, 배포 등의 과정을 저장소의 수만큼 반복해야 한다.
3. 일관성 없는 개발자 경험(DX)
   • 각 프로젝트는 테스트 실행, 빌드, 테스트, 린트, 배포 등을 위해 고유한 명령 집합을 사용한다.
   • 이러한 불일치는 여러 프로젝트에서 사용할 명령을 기억해야 하는 정신적 오버헤드를 만든다.
4. 다른 패키지의 변경 사항 파악
   • 관련 패키지의 변화를 지켜보거나 통지받지 않으면 문제가 발생할 수 있다.
5. 교차 저장소의 리팩터링 비용
   • 관련 패키지의 변화가 있을 때 여러 저장소에 걸쳐 변화를 반영하는 것은 쉬운 일이 아닐 것이다.
   • 이렇게 리팩터링된 각 패키지의 버전에 대한 관리 이슈도 있다.

모노레포가 해결하는 문제

모노레포의 특징

• 모노레포 구조는 두 개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략이다.

• 앞선 예시의 분리된 모듈들은 모노레포에서 여전히 독자 프로젝트로 존재하지만 저장소는 같은 곳을 사용한다

• 모노레포의 또 다른 중요한 특징 중 하나는 프로젝트 간의 관계

  • 단순히 여러 프로젝트가 하나의 저장소를 사용한다고 해서 모노레포 구조라고 부르기에는 부족하다.
  • 흔히 모노레포에서는 프로젝트 사이에 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재한다.

    모노레포가 해결하는 멀티레포의 문제

    1. 더 쉬운 프로젝트 생성
  • 멀티레포에서 공유 패키지를 만들 때 다음과 같은 과정을 거친다.
  • 저장소 생성 > 커미터 추가 > 개발환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
  • 모노레포에서는 저장소 생성 및 커미터 추가 과정이 필요 없고, 개발 환경, CI/CD, 빌드, 게시 등의 과정에 기존 DevOps를 이용하므로 새 프로젝트 생성에 대한 오버헤드가 없다.
    2. 더 쉬운 의존성 관리
  • 의존성 패키지가 같은 저장소에 있으므로 버전이 지정된 패키지를 npm registry와 같은 곳에 publish할 필요가 없다.
    3. 단일화된 관리 포인트
  • 개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있다.
    4. 일관된 개발자 경험 제공
  • 애플리케이션을 일관되게 구축하고 테스트할 수 있다.
  • 개발자는 다른 팀의 애플리케이션에 자신 있게 기여하고 변경 사항이 안전한지 확인할 수 있다.
    5. 프로젝트들에 걸친 원자적 커밋
  • 커밋할 때마다 모든 것이 함께 작동한다.
  • 변경 사항의 영향을 받는 조직에서 쉽게 변화를 확인할 수 있다.
    6. 서로 의존하는 저장소들의 리팩터링 비용 감소
  • 모노레포는 대규모 변경을 훨씬 더 간단하게 만든다.
  • 100개의 라이브러리로 만든 10개의 앱을 리팩터링하고 변경을 커밋하기 전에 모두 작동하는지 확인할 수 있다.

    그 밖의 모노레포의 특징

• 테스트 및 빌드 범위 최소화

  • 소스 변경 시 모든 프로젝트를 다시 빌드하거나 다시 테스트하지 않는다.
  • 대신 변경 사항의 영향을 받는 프로젝트만 다시 테스트하고 빌드한다.

모노레포 도구 알아보기

Yarn

• Yarn(1.x) 또는 npm(7.x)의 workspaces 필드를 사용해 간단히 모노레포를 구성할 수 있다.
• yarn link 또는 npm link 기능을 선언적으로 사용하는 것으로 node_modules 디렉터리에 workspace에 대한 심볼릭 링크가 생성된다.
• 이를 통해 하나의 저장소에 있는 여러 프로젝트가 서로 쉽게 상호 참조할 수 있다.

  용어

  • project
    • = 저장소
    • 하나 이상의 worktree 포함
    • 최소 한 개의 workspace(즉, 루트 workspace) 존재
  • workspace
    • = 모노레포 패키지
  • worktree
    • = 자식 workspace를 갖는 workspace

      worktree 선언

  • worktree를 구성하는 workspace의 위치를 glob 패턴의 배열로 나타낸다.
  • 예를 들어 packages 폴더 내의 모든 폴더가 workspace가 되도록 하려면 다음과 같이 설정한다.

    {
    "private": true,
    "workspaces": ["packages/*"]
    }

    workspace 추가

  • 그림과 같이 client, server, common 세 개의 workspace를 추가하고 루트 경로에서 yarn 명령을 실행하면 루트 경로에 node_modules 디렉터리에 workspace들에 대한 심볼릭 링크가 생성된다.

workspace에 대한 명령 실행

• 특정 workspace에 정의된 스크립트를 실행한다.
  • yarn workspace <WORKSPACE_NAME> <COMMAND_NAME>

workspace를 의존성으로 추가

• client 패키지가 common 패키지를 의존하게 하려면 package.json에 의존성을 명시하거나 바로 위에서 설명한 yarn workspace 명령을 이용하면 된다.
  • yarn workspace client add common@1.0.0
• npm 레지스트리에 publish된 common이란 이름의 패키지가 있다 해도, 의존성 버전을 충족한다면 로컬에 존재하는 common workspace를 우선하여 설치한다.

workspace 의존 관계 확인

• yarn workspace info 명령을 실행해 workspace들의 의존 관계를 알아볼 수 있다.
  • yarn workspaces info

모든 workspace에 대해 명령 실행

• yarn workspaces run \를 사용하면 모든 workspace에 대해 명령을 실행할 수 있다. 다음 명령은 모든 workspace들을 순회하며 test 스크립트를 실행한다.
  • yarn workspaces run test

루트 프로젝트에 의존성 추가

• workspace가 아니라 루트 프로젝트에 의존성을 추가하려면 다음 명령을 실행한다.
  • yarn add <PACKAGE_NAME> -W

호이스팅(의존성 끌어올리기)

• npm, yarn 등은 중복 의존성 설치를 방지하기 위해 호이스팅(hosting) 기법을 사용한다.

• 호이스팅 이해하기

  • package-1의 의존성 정보를 보면, A를 바로 의존성 모듈로 이용하면서도, A를 의존성으로 가지고 있는 C모듈 역시 의존성 모듈로 이용하고 있다.
  • 여러 곳에서 동일한 의존성을 가지는 모듈은 중복으로 설치될 필요가 없으므로, 함께 참조되어 사용할 수 있도록 node_modules 최상단 계층으로 Hoisting 된다.
  • 대부분의 모듈은 root에서 node_modules 트리를 탐색하여 모듈을 매우 효율적으로 찾을 수 있게 된다.
  • 일부 모듈 로더는 심볼릭 링크를 지원하지 않기 때문에 B(2.0)을 탐색할 수 없다. 이때는 nohoist 필드를 사용하면 된다.
  • noHoist를 이용하면, 각 프로젝트의 의존성 모듈을 프로젝트 내 각 로컬 node_modules에 설치되기 때문에 문제를 해결 할 수 있다.

    {
    "workspaces": {
    "packages": ["packages/*"],
    "nohoist": [ "**/react-native" ]
    }
    }

• 효과

  • 기본적으로 모노레포 내 각 프로젝트는 각각 프로젝트에 node_modules를 가지고 Dependency를 설치하지만, 여러 프로젝트에서 중복으로 사용되는 모듈은 중복 설치할 필요 없이 최상단 node_modules로 Hoisting을 하게 된다.
  • 이를 통해 중복되는 의존성을 root node_modules로 끌어올려 하위의 프로젝트 간에 모듈을 공유할 수 있게 된다.
  • 이처럼 yarn workspace를 이용하면, 각 프로젝트에서 중복되는 모듈 설치를 줄이고 전체적인 Dependency 사이즈를 줄일수 있다.

Lerna

• Lerna는 Babel 개발자에 의해 개발되어 2015년부터 다수의 프로젝트에서 모노레포 관리 도구로 사용되어 왔다.
• Lerna는 저수준의 Yarn, npm 위에 있는 고수준 레이어로 볼 수 있다.
• Yarn으로 모노레포를 구성할 수는 있지만 여러 workspace의 버전 관리, 테스트, 빌드, 배포, 게시 등의 작업은 일일이 구성해야 한다.
  • Lerna는 이러한 작업을 최적화한다.
• Lerna에 대해 자세히 알아보기
  • https://lerna.js.org/docs/introduction
  • 배포와 버전관리는 Lerna로 패키지 간 의존성 설치 및 관리는 Yarn 으로 함께 사용하는 케이스가 많이 보임

FE 모노레포 도입

현실적인 도입에 따른 장점이 무엇이 있을까?

• 코드 리뷰 향상
  • 각 프로젝트의 작업 사항을 하나의 Repository에서 한눈에 확인할 수 있으니, 자연스레 다른 프로젝트의 코드를 들여다보며 코드 리뷰에 적극 참여할 수 있는 계기가 만들어지면서, 평소 내가 접하지 않던 프로젝트의 컨텍스트도 함께 쌓을 수 있는 환경이 마련될 수 있다.
• 모든 웹 프로젝트의 최신화 상태 유지
  • 모노레포 환경을 통해, 오랫동안 건드리지 않는 프로젝트도 주기적으로 함께 관리할 수 있는 환경이 되면서 모든 웹 프로젝트를 최신화 상태로 보존할 수 있게 된다.
• 팀 컨벤션 통일 및 업무 능률 향상
  • 각 프로젝트별로 align이 되지 않던 eslint와 prettier의 환경이 모노레포로 통일되면서 드디어 모든 팀원이 동일한 코드의 컨벤션을 가져갈 수 있게 되었으며, 더 이상 린트 환경 및 설정에 대해 신경 쓰지 않게 됨으로써 실제 코드 작업에 더욱 집중할 수 있다.
  • 각기 독립된 프로젝트의 컨벤션을 맞추고자 사용했던 Boilerplate, eslint-config와 같은 모듈을 더 이상 사용하지 않아도 된다.

점진적인 도입?

• 도입을 생각한다면 프론트엔드 서비스에서 공통으로 사용하면서 관리가 필요한 공통 모듈 위주로 migration을 하는 것이 바람직해 보임.