Mise: 개발 도구, 환경 변수, 작업 실행기

 (github.com/jdx)
3P by GN⁺ | ★ favorite | 댓글 1개
  • mise는 명령 실행 전 개발 환경을 준비하고, 프로젝트 도구·환경 변수·작업을 하나의 mise.toml에 모아 새 셸, 체크아웃, CI 작업이 같은 설정에서 시작되게 함
  • node, python, cmake, terraform 등 개발 도구와 수백 개 도구를 설치하고 버전을 전환할 수 있음
  • 프로젝트 디렉터리별 환경 변수를 로드하며, .env 파일과 다른 소스의 값도 사용할 수 있음
  • 빌드, 테스트, 린트, 배포 같은 작업 실행기로 동작하며, mise run build처럼 mise.toml에 정의한 작업을 실행함
  • GitHub Issues는 제출량 때문에 유지가 어려워졌고, 프로젝트 커뮤니케이션은 Announcements, Ideas, Troubleshooting & Bug Reports용 GitHub Discussions로 옮겨짐

mise가 하는 일

  • mise는 명령이 실행되기 전에 개발 환경을 준비하는 CLI임
  • 프로젝트별 도구, 환경 변수, 작업 정의를 하나의 mise.toml 파일에 보관함
  • 새 셸, 새 체크아웃, CI 작업이 모두 같은 설정으로 시작하도록 구성할 수 있음

개발 도구 관리

  • dev tools 기능으로 node, python, cmake, terraform 같은 도구와 수백 개 도구를 설치하고 전환할 수 있음
  • 데모는 같은 시스템에서 여러 node 버전을 관리하는 방식을 보여줌
  • which node를 실행하면 shim이 아니라 실제 node 경로가 반환됨
  • jq, terraform, go 같은 다른 도구도 설치할 수 있음
  • 특정 도구 버전으로 명령을 실행하는 예시는 다음과 같음
mise exec node@26 -- node -v

설치와 셸 연동

  • 설치 예시는 curl https://mise.run | sh를 사용함
  • 설치 후 mise --version으로 버전을 확인할 수 있음
  • README의 예시 버전은 2026.6.15 macos-arm64 (2026-06-26)임
  • 셸에서 mise를 활성화하려면 사용하는 셸에 맞춰 mise activate를 설정함
    • bash
    • zsh
    • fish
    • pwsh

환경 변수 관리

  • mise.toml의 [env] 섹션에서 환경 변수를 정의할 수 있음
[env]
SOME_VAR = "foo"
  • mise set SOME_VAR=bar로 값을 설정하고 셸에서 사용할 수 있음
  • .env 파일을 로드하는 기능도 env directives로 제공됨

작업 정의와 실행

  • mise.toml의 [tasks.*] 섹션에서 작업을 정의할 수 있음
[tasks.build]
description = "build the project"
run = "echo building..."
  • 정의한 작업은 다음처럼 실행함
mise run build
  • 작업 기능 문서는 tasks에서 제공됨

mise.toml 통합 예시

  • 예시 프로젝트는 도구, 환경 변수, 작업을 한 파일에 함께 둠
  • [tools]에는 terraform = "1", aws-cli = "2"를 지정함
  • [env]에는 TF_WORKSPACE, AWS_REGION, AWS_PROFILE을 지정함
  • [tasks.plan]은 terraform init, terraform workspace select, terraform plan을 실행함
  • [tasks.validate]는 AWS 자격 증명과 Terraform 설정을 검증함
  • [tasks.deploy]는 validate와 plan에 의존하고 terraform apply -auto-approve를 실행함
  • 실행 흐름은 다음과 같음
mise install
mise run deploy

문서와 커뮤니티 운영

  • 전체 문서는 mise.en.dev에 있음
  • GitHub Issues는 제출량 때문에 프로젝트에 지속 가능하지 않게 됨
  • 프로젝트는 커뮤니티 중심의 커뮤니케이션과 유지관리 부담 감소를 위해 GitHub Discussions를 사용함
  • Discussions 카테고리는 다음과 같음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • rtx라고 불리던 시절부터 mise를 쓰기 시작했는데, asdf의 자잘한 특성이 거슬리던 차에 같은 동작을 더 빠르고 셸 설정을 덜 침범하는 방식으로 제공해서 좋았음
    이후 내가 가장 필요로 하던 작업 실행과 환경 변수 기능까지 들어왔고, 기존 도구와의 호환성을 챙기면서도 미래 기능을 쌓는 방식이 마음에 듦
    최근 추가된 백엔드 기능도 꼭 필요했지만 다른 데서 못 찾던 기능이었음. Rust와 R 개발을 많이 하는데, 라이브러리로 쓰지는 않고 실행 파일만 필요한 개발 도구들이 있어서 새 환경에서 의존성을 보장하기 어려웠는데, 이제 mise.toml에 적어두기만 하면 설치와 설치 가능성이 보장됨

    • 가장 체감되는 개선은 셸 시작 시간이었음. 5년 만에 코어가 4배 많은 컴퓨터를 샀는데도 nvm과 pyenv가 같은 bash 파일들을 디스크에서 읽고 파싱하느라 똑같이 굼뜨게 느껴지는 건 불쾌했음
      Mise 덕분에 돈을 허공에 던진 건 아니라고 느끼게 됨
    • 머리와 수염의 흰머리가 늘어나는 입장에서 굳이 말하자면, Nix/NixOS와 Guix도 이 문제에 대한 탄탄한 해법임. 완전히 독립적이고 불변인 환경을 띄워 주기 때문임
      여러 dotfile 중 하나에 있는 문자열에 따라 올바른 npm이나 ruby 실행 파일을 바꾸려고 셸 해킹을 할 필요가 없음
      대략 Python 가상 환경을 훨씬 강화한 형태에 가깝고, Python만 격리되는 게 아니라 전체 구성, 모든 도구와 설정이 격리됨. 여기에 direnv를 붙이면 편집기와 GUI 도구도 그 환경을 인식하게 만들 수 있음
      초기의 유일한 골칫거리는 가져올 패키지가 있는지 확인하는 일임. 배포판에 있으면 쉽지만, 도구가 NPM, RubyGems, Crates, GitHub에만 올라와 있고 go install을 돌려야 하는 식이면 좀 번거로움. 그래도 Debian 소스를 최신으로 유지하는 배포판 관리자들이 겪는 것과 같은 종류의 번거로움임

  • 최근 JS, Ruby, Python, Java SDK 관리를 모두 Mise로 옮겼고 지금까지 아주 만족스러움
    RVM, NVM, Python 환경이 될 때까지 여러 설치 도구를 뒤섞는 일, SDKMan을 따로 설치하지 않아도 되는 게 정말 상쾌함

    • brew install uv면 Python 문제는 더 이상 생기지 않음
    • uv는 별도 도구지만, 요즘은 direnv와 source .venv/bin/activate 조합도 단순함
      Direnv가 요즘 정말 많은 고통을 덜어줌

  • 팀의 도구 체인을 통일하려고 쓰고 있으며, nix를 쓰거나 모든 걸 Docker에서 돌리지 않아도 돼서 좋음
    서비스 실행에는 여전히 Docker를 쓰고 Nix의 아이디어도 좋아하지만, mise의 개발자 경험이 너무 좋음. 작업 기능도 훌륭해서 이제 저장소 스크립트들이 모두 자동 완성을 갖게 됨

    • https://devenv.sh/는 써봤는지 궁금함. 내부적으로 Nix를 쓰지만 개발자 경험을 개선한 도구임
      개인적으로는 Nix만으로 충분해서 직접 쓰지는 않았지만, 그래도 devenv보다 mise를 선택할지 궁금함

  • 이런 류의 도구에 대한 내 경험상, 모든 걸 하려고 하면 아무것도 제대로 못 하게 됨
    밑단 추상화가 크게 새어나오지 않고, 언젠가 반드시 실패했을 때 원인 파악을 어렵게 만들 가능성이 0에 가깝다고 보기는 힘듦
    대부분의 사람은 한 생태계의 패키징 난제조차 깊이 알지 못함. Python만 해도 그 전부를 제대로 아는 사람은 전 세계에 십여 명 정도일 것임
    이 도구의 개발자들은 너무 많은 걸 알아야 함. 당연히 그렇지 않으니 기존 도구를 감싸는 방식이 되고, 그래서 앞서 말한 문제가 생김

    • “패키징 난제”를 말하는 걸 보니 mise가 무엇인지 오해한 것 같음. mise는 언어 런타임과 개발 도구를 다루며, 의존성을 관리하거나 패키징하지 않음
      mise를 써보지 않은 사람들에게서 이런 의심을 자주 듣는데, 놀랍지는 않음. 그래도 나는 개발자 생산성 영역에서 10년 넘게 일했고, 지난 2년 동안 mise에 수백 시간에서 수천 시간을 썼음. 이걸 만들 수 있는 사람이 있다면 내가 적임자에 가까움
      특히 개발 도구 쪽에서는 mise가 오래전부터 이 문제를 해결해 왔음. 공급망 보안과 Python 사용성 같은 부분은 계속 개선 중이지만, Python 커뮤니티 자체도 개발자 경험을 제대로 정리했다고 보기는 어려움
      물론 버그는 꽤 꾸준히 고치고 있고 아마 계속 그럴 것임. 그래도 수십만 명의 개발자가 mise를 쓰고 있다고 보며, 그들에게 잘 동작하고 있음. 지금 Homebrew에서 상위 100개 도구 안에 들어감: https://formulae.brew.sh/analytics/install-on-request/30d/
      이건 대충 만든 프로젝트가 아님. 내 삶의 큰 부분을 이 문제에 쏟았고, 모든 증거가 큰 성공을 가리킨다고 봄
    • mise는 많은 부분을 제대로 해낸다고 봄. 나는 환경 변수, Python 가상 환경 생성과 활성화, 작업 스크립트에 쓰고 있음
      20년 넘게 소프트웨어 개발자로 일했고 보통 새 도구 도입을 꺼리는 편인데, mise는 내 개발 흐름에 훌륭하게 들어맞았음
    • “대부분의 사람이 한 생태계의 패키징 난제조차 깊이 모른다”는 말은, 적어도 이 도구와 관련해서는 문제를 크게 과장한 것 같음
      예를 들어 Python은 패키지가 설치되는 prefix가 설치 자체에 박혀 있음. pip, ux, poetry 무엇을 쓰든 Python 패키지는 거기에 설치됨
      이 도구는 패키지 설치에는 관심이 없고, 인터프리터를 설치하고 어떤 것이 $PATH에 올라갈지 관리하는 데만 관심이 있음
      말 그대로 새어나올 추상화가 없음
      기존 도구를 감싼다는 점을 mise나 비슷한 도구의 단점처럼 보는 것도 맞지 않음. 오히려 바퀴를 다시 발명했다면 그때 새어나올 수 있고, 관심사의 분리는 좋은 일임
    • 불평하기 전에 도구를 직접 써보면 좋을 듯함
      나는 mise를 몇 년째 쓰고 있고 아주 잘 동작함. Go, Node, Deno, Java, Python, Ruby, Rust에 쓰고 있음
    • “그런 도구”에 대한 경험에 Mise 사용 경험도 포함되는 건지, 아니면 그냥 가정하는 건지 궁금함
      내 Mise 경험은 훌륭한 도구라는 쪽임

  • 나는 “개발자”가 아니라서 이런 도구들의 사용 사례를 잘 이해하지 못했고, 대신 거기서 말하는 asdf와 make를 그대로 씀
    모노레포 안의 모든 프로그램 버전 관리는 Asdf로 하고 있음. 잘 동작함. 사실 asdf의 사용성은 끔찍하지만 안정적으로 돌아가고 플러그인 설계는 훌륭함
    개발할 때 현재 셸 세션에 환경 변수를 절대 로드하지 않음. 필요한 변수를 로드하고 일을 한 뒤 종료하는 스크립트나 Makefile을 실행함. 현재 셸 세션에 X 변수가 들어 있는지 계속 확인해야 한다면 악몽일 것임
    디렉터리마다 달라지는 반복 가능한 작은 명령, 단순 병렬 실행이나 순서 있는 실행에는 Make를 씀. Helm 설치를 처리하는 큰 Makefile이 하나 있고, Terraform, Packer, asdf용도 몇 개 있음. 계층적 환경 디렉터리에서 배포할 때도 쓰며, 환경 변수는 부모 디렉터리에서 로드됨. Make가 가진 기능들을 좋아하는데, 결국 “그냥 작업 실행기”에는 없는 기능이 필요해지는 순간이 늘 오고 삶을 쉽게 해줌
    Make 대상보다 조금 길거나 복잡한 조합 가능한 도구가 필요하면 셸 스크립트를 씀. Python 같은 걸로 쓰는 대신 셸로 이런 도구를 만들면서 시간과 노력을 많이 아꼈고, Python 쪽은 결국 버그와 의존성이 훨씬 많아짐. 셸보다 복잡한 것이 필요했던 때는 JSON을 다루는 API가 많을 때뿐이었음. 복잡도가 크면 curl/jq보다 낫지만, 작은 작업 하나라면 curl/jq가 더 좋음
    결과적으로는 잘 돌아감. 전체 환경은 Homebrew 같은 걸로 설치한 asdf만 있으면 됨. 기본 Make와 기본 Bash v3만으로 모든 걸 자동 관리할 수 있고, 모든 버전은 고정되고 자동화되며, 변수는 필요할 때 실행 시점에 로드되고, 단순한 Makefile 몇 개만 읽으면 전체를 이해할 수 있음
    지금 고치고 싶은 건 디렉터리마다 있는 불필요한 Makefile을 없애는 것뿐임. 전부 하나의 Makefile로 심볼릭 링크되어 있는데, 디렉터리 구조를 바꾸면 다시 링크해야 해서 번거로움. 그냥 스크립트를 하나 써야 할 듯함

    • 나는 Mise를 asdf 대체품으로 바로 끼워 넣어 씀. .tool-versions와 다른 설정 파일과 완전히 하위 호환되고, asdf와 달리 shim 대신 PATH 기반 접근을 씀
    • 모든 기능은 선택 사항임. 나는 나쁜 사용성 없는 asdf 같은 걸 원해서 mise를 쓰기 시작했고, mise는 asdf 플러그인을 사용할 수 있음
      환경 변수도 원하지 않으면 셸에 로드할 필요 없음. 작업을 실행하면 mise가 설정의 환경 변수가 잡히도록 보장하니 신경 쓸 일이 줄어듦
      설명한 것처럼 나도 셸 스크립트를 계속 쓰고, mise가 거기에 약간의 힘을 더해줌. 스크립트에 필요한 도구, 예를 들어 jq가 팀원들에게 설치되어 있는지 보장해야 할 때, 도구 목록에 선언해두면 mise가 명령 실행 전에 설치를 보장함
      지금 구성이 잘 맞는다면 그걸로 좋음
    • asdf를 쓰고 있다면 mise를 그대로 넣어도 같은 방식으로 동작하면서 더 빠르고 공급망 보안도 더 나음. 사람들이 거의 2년 동안 이렇게 써왔고, mise는 그 사용 사례에 아주 잘 맞음
      환경 변수나 작업 기능은 건드릴 필요 없음
    • mise에 한 번 기회를 주면 좋겠음. 작업 흐름 개선에 도움이 될 수 있다고 봄
      도구 관리는 asdf보다 낫고, direnv에 매우 가깝고, 작업 실행기로는 make보다 뛰어남. 더 장황하긴 하지만 훨씬 이해하기 쉬움
      장점 중 하나는 mise 작업이 독립 파일이 될 수 있다는 점임. 원하면 Python으로 파일 작업을 작성할 수도 있음: https://mise.jdx.dev/tasks/file-tasks.html
    • 나도 트리 안에 하나의 대상물을 가리키는 심볼릭 링크들이 있는 비슷한 구조를 쓰는데, 각 x를 ../x로 링크하고 트리의 루트 x만 실제 파일로 두는 식으로 처리함. 다른 장치에 있다면 루트도 없을 수 있음. 이렇게 하면 구조를 여전히 tar로 묶거나 아카이브할 수 있음
      이런 방식도 가능함:
      $ MAKEFLAGS="-f /that/root/makefile" make
      또는 다소 거칠게:
      $ alias make="make -f /that/rooty/makefile"
      다만 -f somemakefile을 또 추가하면 지정된 파일들이 둘 다 로드된다는 점은 조심해야 함
      그와 별개로 Make에 대한 가장 큰 불만은 파일 이름의 공백을 처리하지 못한다는 것임. 설계상 그렇다

  • Windows에서 mise 지원이 어떤지 더 명확히 알고 싶음. 특히 WSL을 사용한 개발에서 그렇다
    아마 동작할 것 같지만 문서가 꽤 빈약함
    “현재 Windows 지원은 매우 제한적임”
    https://mise.jdx.dev/installing-mise.html#windows

  • mise를 asdf 대체품으로만 써도 만족스러움
    같은 기능인데 훨씬 빠르고 사용성이 더 좋음

  • 프로젝트 README를 읽었지만 남는 건 “왜?”라는 질문뿐임
    나는 Devbox[1]를 쓰고 전체 Nix 생태계에 접근하면 끝임
    [1] https://github.com/jetify-com/devbox

    • 이 영역에는 여러 도구가 있고, Devbox에도 직접 경쟁자가 있음. mise에서는 격리된 환경을 기대하기보다 메타 패키지 관리자를 기대함
      많은 도구를 사용자 셸에 직접 설치할 수 있음. Nix로 그걸 원한다면 Devbox가 아니라 Nix 사용자 설치를 쓸 것임
      결국 가장 마음에 드는 걸 고르면 됨. mise는 팬층이 꽤 큰 것 같음
    • 내 경험상 Mise는 그냥 잘 동작하고, 팀원 컴퓨터에서 설명하고 도구 하나 돌리기까지 1~2분이면 충분함
      Nix는 너무 복잡해서 익숙해지지 못했고, 아직 “이해됐다”는 느낌을 주는 자료도 못 찾았음. 그렇게 된 뒤라면 팀에도 권하겠지만, mise가 워낙 쉽고 더 대중적이어서 아마 계속 이것을 쓸 듯함
      그래도 Devbox는 살펴보겠음. 추천 고마움

  • 요즘 “mise 같은 작업 실행기를 GitHub Actions 흐름에 통합하거나 사용하는 최선의 방법은 뭘까”를 생각하고 있었음
    mise 저장소의 워크플로 파일을 보니 포기하고 몇 개의 run: mise 단계만 넣은 것처럼 보였음. 의존성 등을 다시 써야 하거나 쓸 수 없는 느낌임
    워크플로 파일을 생성할 수 있으면 더 좋을 것 같은데, 아직 그런 프로젝트는 못 찾았음

    • mise generate github-action 명령이 있고, https://github.com/jdx/mise-action을 사용함
      “mise 단계들, 의존성을 다시 써야 하거나 못 쓴다”는 말이 정확히 무슨 뜻인지는 잘 모르겠음

  • 1년 넘게 내 삶을 편하게 해준 단순한 도구임. 만든 사람들과 기여자들에게 고마움

답변달기