이 파일 하나로 개발 환경 문제 해결 (Devbox)

한국어العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 Português Русский 中文

Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00README 파일이 거짓말을 하고 있네요. 5분이면 설치된다고 해놓고,

00:00:07Node 버전은 틀리고, Python도 안 맞고, Postgres는 없고, Docker는 한참 걸리고,

00:00:13시작하기도 전에 디버깅부터 해야 하죠. 개발 환경은 README가 아니라 Git에 있어야 합니다.

00:00:20그게 바로 Devbox가 하는 일입니다. devbox.json 파일 하나와 명령어 하나면 끝이죠.

00:00:28전역 설치 없이 모두에게 동일한 환경을 제공합니다. Nix 지식도 필요 없죠. 보여드릴게요.

00:00:30처음 보면 Devbox는 너무 단순해 보입니다. devbox.json을 만들고 프로젝트에 필요한 도구들을 나열하기만 하면 되죠.

00:00:42Node, Go, Python, Postgres 등 필요한 스택을 적고 파일을 커밋하면,

00:00:50다른 사람들도 devbox shell을 실행해 똑같은 환경을 바로 사용할 수 있습니다. 동일한 버전과 도구, 스크립트까지요.

00:00:58전역 설치를 하거나, 몇 년 된 Homebrew 상태에 의존할 필요가 없습니다.

00:01:03환경 설정이 누군가의 기억이 아니라, 레포지토리 안에 살아있게 되는 거죠. 별거 아닌 것 같지만,

00:01:09망가진 로컬 환경 때문에 반나절을 날려본 적 있다면 이게 얼마나 중요한지 아실 겁니다.

00:01:16워크플로우를 개선하는 코딩 도구에 관심이 있다면 구독해 주세요. 계속 새로운 영상이 올라옵니다.

00:01:20이제 시작해 보죠. 빈 프로젝트 폴더를 하나 만들겠습니다.

00:01:25이름은 devbox demo로 할게요. 폴더로 이동한 뒤, Devbox가 설치되어 있다면 다음 명령만 실행하면 됩니다.

00:01:31devbox init을 입력하세요. Devbox가 devbox.json 파일을 생성합니다. 지금은 아주 기본적인 내용만 들어있죠.

00:01:39이제 프로젝트에 필요한 도구들을 추가해 볼까요? 도구를 추가하려면,

00:01:45devbox add를 사용하면 됩니다. Go, Node.js, Python을 설치해 볼게요. 여기서 중요한 건,

00:01:52이것들을 전역에 설치하는 게 아니라는 점입니다. 제 시스템의 Node나 Python을 건드리지 않죠.

00:02:00이 도구들은 오직 이 프로젝트에만 귀속됩니다. devbox shell을 실행하면 깨끗한 프로젝트 환경 안으로 들어가게 되죠.

00:02:09이 환경에 들어온 뒤 버전을 확인해 볼 수 있습니다. go version, node version,

00:02:14python version까지요. 다 잘 작동하는지 확인할 수 있죠. 이게 바로 큰 장점입니다.

00:02:19프로젝트가 요구하는 도구를 Devbox가 정확히 제공하는 거죠. 이제 스크립트를 추가해 볼까요? devbox.json 안에,

00:02:27테스트 명령어를 정의할 수 있습니다. 저는 단순히 테스트 실행 메시지와 함께 Node와 Go 버전을 출력하도록 할게요.

00:02:34devbox run test를 실행하면 됩니다. 이제 이 레포를 사용하는 누구든 똑같은 명령어를 실행할 수 있죠.

00:02:42같은 스크립트, 같은 도구, 같은 환경입니다. 이제 환경을 떠날 때는 exit을 입력하면 됩니다.

00:02:48그럼 환경을 빠져나오게 되고, 다시 원래 제 로컬 환경으로 돌아옵니다. 정말 간단하죠?

00:02:53그럼 Devbox는 실제로 무엇을 하는 걸까요? Devbox는 기반으로 Nix를 사용합니다. Nix는 재현성이 뛰어나죠.

00:03:00그저 최신 버전을 설치하는 대신, 프로젝트에 정확히 필요한 도구들을 고정(pin)할 수 있습니다.

00:03:06여기까지는 아주 좋습니다. 하지만 어려운 점은,

00:03:12Nix는 처음 접하면 완전히 새로운 세상처럼 느껴진다는 겁니다. 훌륭한 개념들이 많지만,

00:03:18단지 적절한 Node 버전이 필요했을 뿐인데 너무 복잡할 수 있죠. Devbox는 조금 다른 접근을 합니다.

00:03:23재현성은 유지하면서 워크플로우를 더 친숙하게 만드는 거죠. Nix 표현식을 일일이 작성하는 대신,

00:03:29devbox add, search, shell, run, services와 같은 명령어를 사용하면 됩니다. 이 명령어들은 훨씬 더 간단하며,

00:03:37프로젝트에 중요한 파일 두 개가 생성됩니다. json 파일과 lock 파일이죠.

00:03:44devbox.json은 환경이 무엇을 필요로 하는지, lock 파일은 정확히 어떤 버전을 쓰는지 고정해 줍니다.

00:03:52이 둘을 커밋하면 여러분의 환경 설정은 README 속의 긴 글이 아니라,

00:03:58실제 프로젝트의 일부가 됩니다. Devbox는 macOS, Linux, WSL에서 작동하고, VS Code와도 통합되며,

00:04:06스크립트 정의는 물론 데이터베이스 같은 서비스 관리도 가능합니다. 필요할 땐 Docker나 CI 워크플로우로 내보낼 수도 있죠.

00:04:12이 도구의 가치는 단지 '멋지다'는 게 아니라 '엄청나게 간단하다'는 점입니다. 무엇보다도 가치는 바로 '시간'을 아껴준다는 거죠.

00:04:19첫 번째 문제는 앞서 말한 README입니다. README에는 무엇이든 적을 수 있죠.

00:04:26Node 18을 설치하라고 되어 있어도 실제 앱은 Node 20이 필요할 수 있거든요. 두 번째 문제는,

00:04:32온보딩 과정입니다. 입사 첫날에는 쉽게 시작할 수 있어야 하잖아요.

00:04:37하지만 현실은 그렇지 않죠. 어떤 Node 버전을 써야 하는지 물어볼 필요도 없고,

00:04:43어떤 Python 버전을 쓰는지, 로컬에 Postgres를 꼭 깔아야 하는지, 왜 누구는 되고 누구는 안 되는지 고민할 필요가 없습니다.

00:04:48그저 레포를 클론하고, 쉘에 들어가서,

00:04:52프로젝트를 실행하면 됩니다. 문제가 생겨도 모두가 똑같은 환경에서 시작하고 있는 거죠. 또 다른 문제는

00:04:58전역 환경 오염입니다. 도구를 테스트한다고 노트북 환경을 망치면 안 되잖아요. 어떤 레포는 Go 1.22가 필요하고,

00:05:06어디는 Node 20이 필요할 수 있죠. 문제없습니다. 도구들이 프로젝트 안에 머무르니까요. 시스템은 깨끗하게 유지됩니다.

00:05:13Devbox를 사용하면 로컬 개발과 자동화 환경 간의 정의를 공유할 수 있습니다.

00:05:18모든 CI 문제를 해결할까요? 그건 아니지만, 정말 멍청한 문제들은 대부분 사라집니다.

00:05:26우리를 가장 괴롭히는 건 거창한 오류가 아니라 그런 단순한 문제들이거든요. 여전히 자주 겪는 문제들이죠.

00:05:32마지막으로 Docker를 무겁게 쓰는 로컬 워크플로우를 생각해 봅시다. 컨테이너가 꼭 필요하다면 물론 Docker를 써야죠.

00:05:40하지만 많은 팀이 더 나은 도구 관리 방법을 몰라서 로컬에서 무리하게 Docker를 씁니다.

00:05:46Devbox는 워크플로우가 정말 간단합니다. Add, Shell, Run만 기억하면 되죠. 많이 배울 필요도 없습니다.

00:05:52환경 자체가 실제 파일로서 프로젝트의 일부가 되는 겁니다.

00:05:57모두가 동일한 버전과 스크립트를 사용하게 되면 디버깅이 훨씬 쉬워지죠. 하지만 그건 정말 좋습니다.

00:06:03아주 간단하죠. 조금 성가실 수 있는 점은 처음 Nix를 다운로드할 때 시간이 좀 걸린다는 점입니다.

00:06:09뭐, 첫 한 번이니까 괜찮습니다. JSON은 단순하지만 너무 많이 추가하면 보기에 안 좋아질 수 있죠.

00:06:15기본 스크립트는 괜찮지만 복잡한 설정 로직이라면 너무 긴 쉘 명령어를 JSON 안에 넣지 마세요.

00:06:22로직은 별도의 sh 파일로 만들고 Devbox에서 호출하는 게 좋습니다. 그리고 Devbox는 완전한 클라우드 IDE가 아닙니다.

00:06:30브라우저 기반 코딩이나 즉각적인 프리뷰 URL이 필요하다면 CodeSpaces 같은 서비스가 여전히 나을 수 있습니다.

00:06:36Devbox는 로컬 및 CI 재현성에 최적화되어 있습니다. 모든 개발 문제를 해결해주지는 않죠.

00:06:42하지만 우리를 가장 괴롭히는 문제, 즉 '프로젝트 실행 자체'를 해결하는 데는 효과적입니다.

00:06:46프로젝트에서 여러 언어나 CLI 도구를 쓴다면 한번 써볼 만한 가치가 있습니다.

00:06:51이런 개발 도구 영상을 좋아하신다면 Better Stack 채널을 구독해 주세요.

00:06:56다음 영상에서 뵙겠습니다.

Key Takeaway

Devbox는 devbox.json 파일 하나로 프로젝트에 필요한 언어와 도구의 버전을 고정하여, 개발 환경 설정의 불확실성을 없애고 재현 가능한 개발 워크플로우를 제공합니다.

Highlights

README 파일 기반의 환경 설정은 버전 불일치와 의존성 오류를 유발하므로 코드화해야 합니다.
Devbox는 Nix를 기반으로 프로젝트마다 고유한 개발 환경을 제공하며, 전역 시스템 설정을 건드리지 않습니다.
devbox.json과 lock 파일을 레포지토리에 커밋하면 팀원 모두가 정확히 동일한 도구와 버전을 공유할 수 있습니다.
devbox shell을 통해 프로젝트별로 분리된 깨끗한 개발 환경을 즉시 활성화할 수 있습니다.
로컬 개발 환경과 CI 환경 간의 설정을 일치시켜 환경 차이로 발생하는 단순 오류를 제거합니다.

Timeline

개발 환경 설정의 문제점과 Devbox의 역할

README 파일은 버전 관리나 도구 의존성 정보가 실제 환경과 달라 오류를 유발합니다.
개발 환경 설정은 사람의 기억이 아닌 소스 코드 레포지토리 내에 파일로 존재해야 합니다.
Devbox는 devbox.json 파일 하나와 간단한 명령어로 모든 팀원에게 동일한 환경을 제공합니다.

문서로 된 가이드는 Node.js 버전이나 데이터베이스 설치 여부 등 실제 필요한 환경과 불일치할 가능성이 높습니다. Devbox는 프로젝트에 필요한 도구들을 정의하고 이를 커밋함으로써 개발 환경을 코드처럼 관리하게 합니다. 이를 통해 개발자는 로컬 환경이 망가지는 두려움 없이 즉시 프로젝트를 시작할 수 있습니다.

Devbox 활용 워크플로우

devbox init 명령어로 설정 파일을 생성하고, devbox add 명령어로 필요한 도구를 추가합니다.
추가된 도구는 전역 시스템에 설치되지 않고 해당 프로젝트 내부에서만 격리되어 작동합니다.
devbox shell을 실행하여 각 프로젝트에 최적화된 격리 환경으로 즉시 진입할 수 있습니다.

프로젝트 폴더에서 devbox init을 입력하면 기본적인 설정 파일이 생성됩니다. 여기에 필요한 언어나 도구를 추가하면 시스템 전체에 영향을 주지 않고 해당 프로젝트에만 귀속된 도구가 설정됩니다. devbox shell을 사용하면 프로젝트에 명시된 버전의 도구들만 활성화된 깨끗한 셸 환경을 사용할 수 있습니다.

기술적 기반과 효과적인 활용법

Devbox는 재현성이 뛰어난 Nix 기술을 기반으로 하되 더 쉬운 명령어를 제공합니다.
devbox.json과 lock 파일은 환경과 도구의 버전을 정확하게 고정합니다.
복잡한 로직은 JSON 내부에 직접 넣지 않고 별도의 스크립트 파일을 작성하여 호출하는 것이 권장됩니다.

Nix의 강력한 재현성 기능을 활용하면서도 사용자가 복잡한 Nix 표현식을 배울 필요가 없도록 설계되었습니다. 단순한 스크립트라면 JSON 내부에 정의할 수 있으나, 설정이 복잡해질 경우 외부 sh 파일을 사용하는 것이 유지보수에 유리합니다. 로컬 환경뿐만 아니라 CI 워크플로우에서도 동일하게 동작하여 환경 차이로 인한 디버깅 시간을 획기적으로 단축합니다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video