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다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video