▲

Mise: 모노레포 작업(Task) 기능 소개

 (github.com/jdx)
6P by GN⁺ 7일전 | ★ favorite | 댓글 2개
  • mise가 새로운 모노레포 작업 기능을 발표
  • 다수 프로젝트에서 각각의 환경, 도구, 작업을 손쉽게 관리할 수 있는 통합 작업 네임스페이스를 제공함
  • 강력한 와일드카드 패턴, 환경/도구 상속, 일관된 실행 컨텍스트 등 다양한 기능을 포함함
  • 다양한 언어나 복잡한 환경을 가진 모노레포에 간편함과 유연성을 제공함
  • 기존 Bazel, Turborepo 등과 비교해 언어 비종속성, 쉬운 설정, 통합 관리가 강점임

소개: 모노레포 작업 기능 발표

  • mise에서 모노레포 작업(Monorepo Tasks) 이라는 새로운 기능을 도입
  • 다수 프로젝트가 포함된 저장소에서 각 프로젝트별로 도구, 환경변수, 작업을 독립적으로 유지하고 효율적으로 관리할 수 있는 일류급 모노레포 지원을 제공

주요 기능

  • 통합 작업 네임스페이스: 모노레포 내 모든 작업을 자동으로 발견하고, 위치별로 프리픽스를 붙여 명확히 구분함
    예시:
    mise //projects/frontend:build
    mise //services/api:deploy
  • 스마트 도구 및 환경 상속: 루트에서 공통 도구를 정의하고, 필요시 하위 프로젝트에서 재정의 가능함
    • 예: 루트 mise.toml의 node=20, python=3.12 설정을 모든 하위 프로젝트에 자동 상속
    • 특정 프로젝트(mise.toml)에서 node=14로 오버라이드 할 수 있으며, 상위 python 세팅은 계속 상속
  • 강력한 와일드카드 패턴:
    • 모든 프로젝트의 테스트 실행: mise //...:test
    • services/ 이하 모든 빌드 실행: mise //services/...:build
    • frontend 내 모든 작업 실행: mise '//projects/frontend:*'
    • 작업명에 따라 그룹 실행 가능
  • 언제든지 일관성 있는 실행: 어느 위치에서 작업을 실행하더라도 해당 작업의 config_root에서 정의된 환경과 도구 그대로 실행됨
  • 자동 신뢰 전파: 모노레포 루트만 신뢰 등록(Trust)하면 하위 구성들은 자동으로 신뢰됨

빠른 시작 가이드

  1. 루트 mise.toml에서 experimental_monorepo_root=true 설정
  2. 실험 플래그(MISE_EXPERIMENTAL=1) 활성화
  3. 각 프로젝트의 mise.toml에 tasks 추가
    • 예:
      [tasks.build]
      run = "npm run build"
  4. 루트 및 아무 경로에서 원하는 작업 실행
    • mise //projects/frontend:build
    • mise //...:test

예시 모노레포 구조

  • myproject/
    ├── mise.toml (experimental_monorepo_root = true)
    ├── services/
    │ ├── api/mise.toml
    │ ├── worker/mise.toml
    │ └── scheduler/mise.toml
    └── apps/
    ├── web/mise.toml
    └── mobile/mise.toml
  • 모든 서비스 빌드 실행: mise //services/...:build
  • 모든 앱 테스트: mise //apps/...:test
  • 전체 작업: mise '//...:*'

도입 배경 및 효과

  • 모노레포 관리의 복잡성과 반복적인 스크립트에 대한 고민에서 출발함
  • once 정의, anywhere 실행으로 중복 최소화
  • 각 프로젝트별로 정확한 도구/환경 자동 적용
  • 강력한 와일드카드로 CI/CD 파이프라인 단순화
  • 작업 네임스페이스로 탐색과 이해도 향상

기존 주요 도구와의 비교

  • Simple Task Runners (Taskfile, Just 등)

    • 단일 프로젝트 자동화에 최적화, 모노레포에선 통합 네임스페이스·상속·와일드카드 미지원
    • mise는 자동 작업 발견 및 강력한 패턴 지원 제공

  • JavaScript 중심 도구 (Nx, Turborepo, Lerna)

    • JS/TS 모노레포에서 강력함 (dependency graph, codegen, cache 등)
    • mise는 언어 비종속, 다양한 언어/스택에 대응, 통합 도구/환경 변수 관리 지원

  • 대규모 빌드 시스템 (Bazel, Buck2)

    • 분산 캐시, 원격 실행 등 제공하지만 복잡도 및 학습 곡선 높음, 구조 제약 많음
    • mise는 비은밀성(non-hermetic) 접근, 유연한 설정과 쉬운 도입 가능

  • 기타 (Rush, Moon 등)

    • Rush: JS 전용 빌드 orchestration
    • Moon: Rust 기반, 다중 언어 지원 지향

mise Monorepo Tasks의 특별함

기능 Simple Runners JS 전문 Build Systems mise
멀티 언어 지원 ✅ ❌ ✅ ✅
쉬운 학습 ✅ ⚠️ ❌ ✅
통합 작업 발견 ❌ ✅ ✅ ✅
와일드카드 패턴 ❌ ⚠️ ✅ ✅
도구 버전 관리 ❌ ❌ ⚠️ ✅
환경 상속 ❌ ⚠️ ❌ ✅
최소 설정 ✅ ⚠️ ❌ ✅
작업 캐싱 ❌ ✅ ✅ ❌
  • 언제 Mise를 선택해야 할까?
    • 언어 혼합 모노레포
    • 통합 도구 및 작업 관리
    • 간결함을 선호하는 경우
    • mise 사용 경험자에게 적합
  • 다른 걸 고려해야할때
    • JS/TS만 집중 → Nx, Turborepo
    • 초대형 엔터프라이즈 (Google/Meta 등) → Bazel, Buck2
    • 고도화된 작업 캐싱 필요 → Nx, Turborepo, Bazel

결론

  • mise의 모노레포 작업 기능은 단일 언어에 국한되지 않고, 다양한 언어 환경의 복잡한 모노레포를 쉽고 일관성 있게 관리할 수 있도록 설계됨
  • 최소한의 설정과 강력한 작업 패턴으로 개발자의 생산성과 경험 모두를 향상시킴
  • 복잡한 엔터프라이즈 솔루션에 비해 훨씬 간결하고 유연함
▲
GN⁺ 7일전  [-]
Hacker News 의견

  • 이전에 Python을 주로 쓸 때는 Mise의 매력을 잘 못 느꼈음, uv로 충분하다고 생각했음
    하지만 Node처럼 각 디렉토리별로 버전을 맞추고, 언어나 프로젝트 종류 상관없이 mise build나 mise test 같은 공통 엔트리포인트가 필요할 때 Mise의 진가를 실감했음
    Just도 작업용 러너로 정말 좋아하고, 덕분에 Make에서 벗어날 수 있었음
    Make는 강력하지만 개발 경험 면에서 아쉬움이 있었음
    Just가 Mise의 task 기능보다 기능적으로 더 강력할 수도 있지만, Mise는 꽤 괜찮은 task 기능과 뛰어난 툴 관리 기능이 함께 있어 나에게는 최고의 조합임

    • 간단한 Makefile을 좋아하는 팬으로서 궁금한 점이 있는데, Make에서 Just를 거쳐 Mise로 이동하면서 어떤 장점이 있었는지 궁금함

    • just를 정말 좋아했지만, just task에서 정확한 환경 세팅이 번거로웠고, 가상환경을 로딩하는 것도 귀찮았음
      그래서 비슷한 이유로 mise로 전환함

  • mise에 엄청난 기대감을 가지고 있음
    새로운 프로젝트를 시작할 때마다 필수 도구로 빠르게 자리잡았음
    하나의 설정파일로 node, python, rust, go 등 여러 툴 관리와 쉽게 쓸 수 있는 makefile 대체를 한 번에 할 수 있어서 매우 편리함
    대체로 postinstall hook을 설정해서, 누가 내 프로젝트를 받을 때 mise install만 실행하면 맞는 툴 버전 및 의존 패키지까지 자동으로 다 깔려서 정말 손쉬움
    nix는 진입 장벽이 높다고 느끼는 반면, mise는 훨씬 실용적임

    • Nix 방식이 부담스럽다면 devenv.sh 같은 도구가 접근성을 크게 높여줌
      예를 들어 languages.rust.enable = true로 rust 개발 환경 바로 세팅 가능함
      추가적으로 스크립트, 태스크, 패키지도 넣을 수 있음

    • 예시 설정을 공유해줄 수 있는지 궁금함
      내용이 흥미로움
      monorepo 프로젝트에서 just와 docker(-compose)를 써왔고, moon & proto 시도는 짧고 다소 실망스러웠음
      just의 단순함은 좋지만, 여러 플랫폼에서 신규 멤버 온보딩할 때는 여전히 번거로움

    • 나도 mise로 새 프로젝트를 셋업해봄
      신규 입장자들이 수동 단계 없이 훨씬 수월하게 시작할 수 있어서 정말 최고임

    • mise에서 postinstall hook을 사용하는 내용이 흥미로움
      주로 무엇을 넣는지 궁금함

  • task 캐시를 지원하지 않는 점은 꽤 큰 아쉬움임
    작업 그래프에 의존성이 생기면, 이미 완료된 태스크는 다시 돌리지 않고 캐시로 처리해야 반복 실행에서 효율적인데, 특히 중형 monorepo에서 중요함
    해당 기능 계획이 있는지 찾아봤지만, Mise 저장소에는 issue가 비활성화되어 있었고 README에도 관련 언급이 없어 신뢰감이 적음
    만약 single-language npm monorepo를 쓴다면 Wireit을 추천함
    Wireit은 npm 스크립트에 의존성과 로컬/깃헙 액션 캐시 기능을 더하고, 장기 실행되는 서비스 타입 태스크를 제공함
    Wireit GitHub

    • Mise도 Make같은 태스크의 로컬 캐시는 지원함
      sources와 outputs를 지정하면 가능하고, mise 태스크 설정 가이드에서 볼 수 있음
      sources만 지정해도 source 변화 자동 추적이 됨
      이 기능은 docker 빌드 가속을 위해 오래전에 요청했고, 정말 유용하게 사용 중임

    • 오히려 mise가 프로젝트 소스 코드나 라이브러리 의존성에 신경을 덜 쓰는 게 심플함의 매력임
      보통 해당 경계까지만 기능을 제공함

    • task 캐싱은 mise의 지향점과는 다름
      anti-goals 공식 문서 참고
      turbopack, moonrepo 등에서 이미 이 문제에 집중함
      mise는 단순히 스크립트 실행에 중점을 둔 경량 태스크 러너로 남을 가능성이 높음

    • Mise 저장소의 issue가 꺼진 이유는 나도 모르겠음
      예전엔 "maintainer는 issues보단 discussion을 선호"라는 이슈가 있었는데 지금은 사라짐
      관련 내용으로 이 토론을 시작했음
      나처럼 몇 년 써본 입장에선 해당 프로젝트에 신뢰가 크고 주변에도 추천함
      discussions와 실제 사용 경험을 참고해보는 걸 추천함

    • mise에 빌드 시스템(bazel류) 기능을 요구하는 것과 비슷함
      이미 어쩌면 그런 역할도 하고 있다고 볼 수 있음
      캐시 기능은 유용하긴 하지만 기능 추가로 복잡도가 커질 수 있으니 조심해야 함
      기존 빌드 시스템과 연동하는 방법도 생각해봄직함

  • mise가 꽤 괜찮아 보임
    다만 현재 asdf 유저 입장에선, mise가 다양한 것(PATH 조작 등)을 과하게 관리하려는 것 같아 살짝 망설여짐
    여러 툴이 PATH를 각기 다르게 건드리는 게 정말 번거로워서 직접 .zprofile에 PATH를 고정하고 각종 초기화 스크립트도 다 빼버렸음
    mise가 프로그래밍 언어와 언어에서 설치되는 CLI 앱(cargo, go, uv 등)까지 한 번에 관리해준다면 좋겠지만, 그 부분이 전환 시 조금 귀찮을 것도 같음

    • 여러 툴이 PATH 우선순위로 조작하는 게 불편했다고 했는데, mise는 그렇게 하지 않음
      원하면 shim도 쓸 수 있음
      언어별 툴과 언어 자체 관리 모두 지원함

    • 이전에 asdf에서 mise로 왜 바꿨는지 딱히 기억은 안 나지만, 몇 년 써오며 아무 문제 없었음

  • mise를 정말 최고로 생각함
    자동화와 동일한 환경 세팅, 새로운 프로젝트 빠른 부트스트랩에 진심인 사람들에게 딱임
    특히 Ruby/Python/Node 환경에서 발생하는 각자 셋업 방식 차이, 반복 환경 재현 등의 이슈를 Docker 같은 것 없이도 간단하게 해결해줌
    작은 팀이나 개인 프로젝트에서 CI 환경, 빌드 시스템(Bazel, Gradle 등) 없이도 반복 수행 환경을 손쉽게 구축할 수 있음
    chezmoi와 조합하여 로컬 시스템 툴 관리에도 잘 쓰고 있음

  • 최근 just에서 mise로 옮겼음
    just도 훌륭하지만 단순히 커맨드 러너 기능만 제공하고, 나는 mise의 추가 기능이 필요했음
    전환하길 잘했다는 생각임
    다만 초심자가 이해하기 쉽게 유즈케이스, 히스토리, 다른 도구(nix, docker 등)와의 비교와 구조적인 설명이 더 잘 되어 있으면 좋겠음
    실제 미세한 차이를 예시로 살펴보며 ‘왜’ mise가 필요한지, 이미 있는 다른 툴들과의 차별점이 좀 더 명확하게 문서화되길 바람

  • 이 소식에 정말 기대가 큼
    just/taskfile 같은 단순한 태스크 러너의 장점과 bazel/buck2 같은 강력함을 적절히 조합한 느낌임
    다른 사람들은 어떻게 활용할지 궁금하고, 새로운 시도가 기대됨

    • 나도 mise를 주로 사용하고 거의 만족하고 있음
      환경 관리 워크플로우가 많이 간소화되었음
      하지만 task runner 기능은 굳이 필요하지 않음
      Make나 just가 그 역할을 충분히 해주고 있음
      실제로 monorepo에서 써보진 않았지만, 두 도구 모두 task/recipe 파일의 import와 확장을 지원하기 때문에 필요에 따라 셋업이 가능하다고 생각함
      UX가 맞춤형 도구만큼 매끄럽진 않을 수 있겠지만, 각 도구가 단일한 역할에 집중하길 선호함
      mise는 이미 환경 관리자 역할에서 많은 기능을 품고 있으므로 그쪽에 집중해주면 좋겠음
      참고로 상대방이 mise 저자인 것 같음, 감사함

  • 만약 저장소의 태스크를 단일 진입점으로 관리하고 싶다면 내가 만든 dela를 고려해볼 만함
    pyproject.toml, package.json, makefile 등 다양한 태스크 파일 정의를 스캔해서, 태스크 이름으로 바로 CLI에서 실행 가능하게 해줌
    여러 레포에서 내가 개선 없이 바로 쓸 수 있어 매우 편리했고, 레포 구조를 바꾸지 않아도 되는 점도 장점임
    아직 mise의 태스크는 지원하지 않지만, 수요가 있다면 바로 추가할 용의가 있음
    최근 집계에 따르면, mise는 스타 많은 github 레포 10만 개 중 94개에서 쓰이고 있음
    자세한 데이터는 2025 task runners census 참조 바람

    • 멋져 보이는데, 태스크 전체 목록도 지원하는지 궁금함
      Node 프로젝트 저장소에 들어가면 항상 제일 먼저 'npm run'으로 스크립트 목록부터 확인함
      Makefile이 있으면 들여다보는데, 타겟이나 의존성이 전부 변수로 되어 있으면 바로 나와버림

  • 막상 mise에도 이런 기능이 있으면 좋겠다고 생각하던 참에 새로 나왔다니 반가움
    mise를 써보며 가장 좋았던 점은 npm, go, cargo 등으로 백엔드에서 전역 툴을 설치할 수 있는 기능임
    예를 들어 "mise use -g npm:prettier" 같은 단순한 명령어로 쉽게 설치 가능함
    예전엔 nvm을 쓸 때마다 어떤 node 버전에 글로벌 패키지를 설치했는지 항상 기억해야 했는데, mise 덕분에 훨씬 편해짐
    다만 최근에 node 최신 버전 설치하려 했더니 두 번째로 최신인 버전이 깔리는 작은 버그가 있었음

  • pure Nix-shell을 쓸 수 있다면 mise는 조금 매력도가 떨어질 수 있음
    그래도 Nix보다 학습 곡선이 낮아서 더 널리 퍼질 수도 있을 것 같음

    • 자신이나 자신의 PC가 아닌, 다양한 사람이 프로젝트를 쉽게 부트스트랩하는 데에 특화되어 있다는 관점에서 mise가 정말 돋보임
      toml 기반 설정도 사람들이 이해하기에 아주 단순함
      예전 README 뒤지며 수동으로 환경 맞추고, 언어 별로 설치방법 달라서 번거로웠던 것들이 mise에서는 문제되지 않음
      Node/Ruby/Python 쪽 환경을 관리할 때 특히 유리함

    • nix-darwin을 1년간 써보고 결국 mise로 갈아탐
      mise는 전체 필요 기능 중 90%를 1%의 번거로움만으로 충족해줌
      nix의 개념도 좋고, 미래 소프트웨어 빌드 방식은 분명 이런 흐름으로 갈 거라 생각함
      다만 당장은 그 주체가 nix가 아닐 수도 있다고 생각함

답변달기