turborepo는 가지치기가 필요해

call5h5ong 7달 전

서론

요즘 핫하고 핫한 모노레포 빌드 시스템이 있습니다. 이름하야 터보레포(turborepo), 무려 Nextjs를 만들고 있는 Vercel에서 제작했습니다.

Nextjs를 무진장 사랑하는 저는 반드시 찍어 먹어봐야 되겠다고 생각을 했습니다. 그래서 간단한 앱을 만들어 빌드까지 해보기로 했죠!

오늘의 주제는 바로 그 빌드와 관련 있습니다. 재밌는 부분을 찾았거든요!

간단하게 말씀드리자면, 터보레포는 가지치기가 필요합니다. 엥?

도커는 빠른 최적화를 원해요

갑자기 가지치기라니, 이게 무슨 말일까요? 터보레포가 드디어 그 사악한 속을 드러내고 우리의 소중한 코드를 잘라내 버리겠다는 의미일까요? 다행히도 그건 아닙니다.

터보레포의 가지치기에 대해 말하기에 앞서 우리는 도커가 어떻게 nodejs 환경에서 이미지를 만들어 내는지 살펴봐야 합니다.

 => [separator 2/4] RUN pnpm add turbo                                                                                           17.1s
 => [installer 2/5] COPY .gitignore .gitignore                                                                                    0.0s
 => [separator 3/4] COPY . .                                                                                                      0.4s
 => [separator 4/4] RUN pnpm turbo prune --scope=api --docker                                                                     1.0s
 => [installer 3/5] COPY --from=separator /app/out/json/ .                                                                        0.0s
 => [installer 4/5] COPY --from=separator /app/out/pnpm-lock.yaml ./pnpm-lock.yaml                                                0.0s
 => [installer 5/5] RUN pnpm install                                                                                             16.1s
 => [builder 2/4] COPY --from=installer /app .                                                                                    6.5s
 => [builder 3/4] COPY --from=separator /app/out/full .                                                                           0.0s
 => [builder 4/4] RUN pnpm turbo run build --filter=api                                                                           7.2s
 => [runner 2/2] COPY --from=builder /app .                                                                                       7.5s
 => CACHED [separator 2/4] RUN pnpm add turbo                                                                                     0.0s
 => CACHED [separator 3/4] COPY . .                                                                                               0.0s
 => CACHED [separator 4/4] RUN pnpm turbo prune --scope=api --docker                                                              0.0s
 => CACHED [installer 3/5] COPY --from=separator /app/out/json/ .                                                                 0.0s
 => CACHED [installer 4/5] COPY --from=separator /app/out/pnpm-lock.yaml ./pnpm-lock.yaml                                         0.0s
 => CACHED [installer 5/5] RUN pnpm install                                                                                       0.0s
 => CACHED [builder 2/4] COPY --from=installer /app .                                                                             0.0s
 => CACHED [builder 3/4] COPY --from=separator /app/out/full .                                                                    0.0s
 => CACHED [builder 4/4] RUN pnpm turbo run build --filter=api                                                                    0.0s
 => CACHED [runner 2/2] COPY --from=builder /app .                                                                                0.0s

도커는 package.json와 락파일(lockfile)을 전의 빌드와 비교해 변화가 있을 때 비로소 패키지를 설치합니다. 변화가 없다면 이전의 캐시된 결과를 그대로 가져다 쓰는 것이죠. 위의 로그가 그 예시 중 하나입니다.

첫번째는 package.json이 변경된 후 빌드된 이미지의 로그입니다. 옆의 시간을 확인해 보세요. 두번째는 첫번째 빌드 이후 package.json을 변경하지 않고 빌드한 이미지의 로그입니다. CACHED라고 나와 있는 것이 보이나요? 다시 한 번 시간을 확인해 보세요. 0.0s, 압도적 시간! 바로 도커가 이 전에 캐시된 것을 그대로 가져와 사용했기 때문에 가능했던 일입니다.

천방지축 어리둥절 빙글빙글 돌아가는 터포레포 디펜던시

이 좋은 방법을 터포레포에서도 사용해야 되겠죠. 그런데요, 문제가 하나 있습니다. 터보레포는 바로 모노레포 빌드 시스템이라는 겁니다!

모노레포, 즉 터보레포는 락파일을 전역으로 관리합니다. A, B 워크스페이스가 있을 때 B 워크스페이스에서 디펜던시가 변경된다면 그 사항이 그대로 락파일에 반영되는 것이죠. 이 때 디펜던시가 변경되지 않은 A 워크스페이스를 도커로 빌드한다면요? 아차차, 도커는 락파일이 변경된 것을 보고 새로 디펜던시들을 설치하기 시작합니다. 락파일! 락파일이 도커를 완벽하게 속여 먹인 겁니다!

대체 이 문제를 어떻게 해결해야 할까요, 맞습니다. 가지치기가 등장할 시간입니다.

가지치기된 모노레포

터포레포도 진작에 이 문제를 파악하고 있었습니다:

a. 터포레포는 락파일을 전역으로 관리하기 때문에 효율적인 도커 빌드가 불가능하다

b. 그럼 빌드할 워크스페이스만 똑때서 락파일을 만든다음 도커에게 주면 되는 거 아닌가

a. 헐

b. ?

이렇게 turbo prune가 탄생합니다. 그 이름에서도 보여지듯이 이 명령어의 기능은 간단합니다. 바로 특정 워크스페이스의 가지치기된 모노레포를 만들어 주는 것이죠!

.
├── apps/
│   ├── a-workspace/   // example-package-1만 사용
│   │   ├── package.json
│   │   └── src/
│   └── b-workspace/   // example-package-1, 2 둘 다 사용
│       ├── package.json
│       └── src/
├── packages/
│   ├── example-package-1/
│   │   ├── index.ts
│   │   └── package.json
│   └── example-package-2/
│       ├── index.ts
│       └── package.json
└── pnpm-lock.yaml

예제 앱의 디렉토리 구조입니다. a-workspace는 example-package-1 패키지만 사용하고 있고 a-workspace는 1, 2 둘 다 사용하고 있네요. 그렇다면 turbo prune을 사용해 a-workspace만 빼내봅시다.

turbo prune --scope="a-workspace"

이 명령어를 실행한다면:

.
├── apps/
│   └── a-workspaces/   // example-package-1만 사용
│       ├── package.json
│       └── src/
├── packages/
│   └── example-package-1/
│       ├── index.ts
│       └── package.json
└── pnpm-lock.yaml

A 워크스페이스의 가지치기된 모노레포를 만들어 줍니다. 물론 가지치기된 락파일도 같이요! 이 락파일은 오직 A 워크스페이스의 디펜던시만을 담고 있어 B 워크스페이스의 디펜던시가 변경된다고 하더라도 영향을 받지 않습니다.

이 가지치기된 모노레포를 도커로 빌드하게 된다면 더 이상 락파일에 머리를 감싸매지 않아도 됩니다!

TMI

도움이 됐나요?

다행입니다! 오늘도 좋은 하루 보내세요!

References

댓글을 작성해보세요.