Ubuntu에서 Docker 없이도 가벼운 개발 환경 만드는 법

요즘은 “개발 환경 = Docker”라는 인상이 강합니다. 팀 위키나 블로그 글을 보면 “일단 컨테이너로 띄우고 보자”는 식의 내용도 많고요. 그런데 Ubuntu 한 대에서 혼자 개발하거나, 소규모 프로젝트를 돌리는 정도라면 꼭 Docker까지 쓰지 않아도 충분히 가벼운 개발 환경을 만들 수 있습니다. 저는 지난 5년 정도 Ubuntu를 메인 개발용 OS로 쓰면서, 일부 서버 작업을 제외하면 대부분의 일을 그냥 로컬 Ubuntu 환경에서 해결하고 있습니다.

이 글은 “Docker를 절대 쓰지 말자”는 이야기가 아니라, Ubuntu 자체를 개발 환경으로 쓰되 최소한으로만 세팅하는 방법을 정리한 것입니다. 컨테이너를 도입하기 전에, 일단 이렇게 한 번 만들어 보고 나서 진짜 필요한지 판단해도 늦지 않습니다.

Docker가 없어도 되는 상황부터 구분하기

먼저 “내가 하는 개발이 정말로 Docker를 필요로 하는가”를 구분해 보는 게 좋습니다. 제가 작업했던 사례들을 기준으로 나눠보면 대략 이런 느낌이었습니다.

• 로컬에서만 돌리는 개인 웹 서비스, 사이드 프로젝트
• 단일 언어/런타임만 사용하는 스크립트나 CLI 도구
• 외부 의존성이 거의 없는 간단한 백엔드·API 서버
• 회사 서버 쪽 배포는 어차피 다른 사람이 담당하는 경우

이 정도 범위라면 Ubuntu에 필요한 언어 런타임과 라이브러리만 깔아도 충분히 작업이 가능합니다. 반대로, 아래 상황에 가까울수록 Docker 같은 도구가 의미가 커집니다.

• 서버 환경이 전부 컨테이너 기반으로 운영되고 있는 팀
• 개발·테스트·운영 환경을 이미지 하나로 맞춰야 하는 배포 파이프라인
• 여러 언어·여러 데이터베이스를 동시에 띄우는 복잡한 시스템

제가 개인 프로젝트나 소규모 업무용 도구를 만들 때는 대부분 전자에 가까웠습니다. 그래서 “일단 Ubuntu를 최대한 깔끔하게 세팅해 놓고, Docker는 정말 필요할 때만 쓴다”는 기준으로 정리해 두니 관리가 훨씬 편했습니다.

Ubuntu 기본 저장소만으로 개발 도구 최소 세트 만들기

Ubuntu는 배포판 자체가 개발자 친화적인 편이라, 기본 저장소에 이미 많은 개발 도구가 들어 있습니다. 이 부분은 공식 문서로 확인할 수 있는 내용이고, gcc, g++, make, Python, Git 같은 것들은 별도 외부 저장소 없이 설치가 가능합니다.

저는 새로 설치한 Ubuntu에서 보통 다음 네 가지 정도를 가장 먼저 챙깁니다.

• 컴파일러·빌드 도구: build-essential 패키지 계열
• 버전 관리: Git
• 주 언어 런타임: Python, Node.js, Go, 등 실제로 쓸 언어 한두 개
• 에디터/IDE: VS Code, Neovim, 또는 본인이 선호하는 도구

중요하게 보는 포인트는 “최소 세트”입니다. 쓰지도 않을 언어 런타임, 프레임워크, 데이터베이스를 미리 다 깔아두면, 나중에 꼬이는 원인을 추적하기 어려워집니다. 실제로 저는 “당장 쓸 것만 먼저 설치 → 프로젝트를 진행하다가 정말 필요해지면 그때 하나씩 추가”라는 순서를 지키는 편이었고, 이쪽이 문제를 추적하기에도 훨씬 수월했습니다.

언어 버전 관리는 꼭 필요할 때만 가볍게

한 시스템에서 여러 버전의 언어를 동시에 써야 하는 상황이라면 pyenv, nvm, rbenv 같은 버전 관리 도구가 도움이 됩니다. 실제로도 많은 개발자들이 이런 도구를 쓰고 있고, Ubuntu에서도 잘 작동합니다.

다만, Docker 없이 로컬 개발 환경을 가볍게 유지하고 싶다면 “정말 여러 버전이 필요할 때만” 이런 도구를 쓰는 것도 하나의 선택입니다. 제 경험을 기준으로 나누면 다음과 같습니다.

• 개인 프로젝트 한두 개, 사용하는 언어 버전도 하나라면: Ubuntu 저장소에서 제공하는 LTS 버전 하나만 설치해도 충분합니다.
• 회사/프로젝트마다 Node.js, Python 버전이 제각각이라면: 그때는 nvm, pyenv 같은 도구를 도입하는 쪽이 오히려 깔끔합니다.

저는 “Python 3.x 한 버전 + Node.js 한 버전”만으로 해결되는 시기에는 굳이 버전 관리 도구를 쓰지 않았습니다. 그러다가 프로젝트 요구사항이 갈라지는 시점이 오면 그때 pyenv·nvm을 도입했습니다. 이렇게 하면 초기 설정이 단순해지고, 문제 발생 시 “버전 관리 도구 탓인지, 패키지 탓인지” 헷갈리는 상황도 줄어듭니다.

프로젝트별 격리는 Docker 대신 디렉터리·가상환경으로

Docker를 쓰는 가장 큰 이유 중 하나는 “프로젝트별 격리”입니다. 하지만, 언어별로 이미 프로젝트 단위 격리 수단을 제공하는 경우가 많습니다. 이건 공식 문서와 여러 실전 사례에서 확인할 수 있는 내용입니다.

예를 들어 Python은 venv 가상환경을 제공합니다. 프로젝트 디렉터리 안에 가상환경을 만들고, 그 안에만 패키지를 설치하면 다른 프로젝트에 영향을 주지 않습니다. Node.js 에코시스템에서는 기본적으로 각 프로젝트 디렉터리 안에 node_modules가 생성되고, 전역 설치를 최소화하면 프로젝트 간 의존성 충돌을 줄일 수 있습니다.

저는 Ubuntu에서 다음 정도의 룰만 지켜도 충분히 “가볍지만 격리된” 개발 환경을 만들 수 있었습니다.

• 각 프로젝트마다 전용 디렉터리를 만들고, 그 안에서만 패키지를 설치한다.
• Python은 가능하면 venv를 기본으로 사용한다.
• Node.js는 전역 설치를 최소화하고, 프로젝트별 package.json에 의존성을 모두 기록한다.
• 시스템 전역에 설치하는 것은 Git, 컴파일러, 에디터처럼 진짜 공용 도구로 한정한다.

이렇게 했을 때 실제 문제 해결이 더 쉬웠습니다. 어떤 프로젝트가 깨지면 그 프로젝트 디렉터리 안만 보면 되고, 시스템 전체를 의심할 일은 훨씬 줄어듭니다.

개발용 계정과 설정을 분리해 두면 더 깔끔해진다

Ubuntu 한 대를 업무와 개인용으로 같이 쓰고 있거나, 실험용 설정을 자주 바꾸는 편이라면 “개발용 계정”을 하나 따로 만드는 것도 좋은 선택입니다. 이 방법은 제가 실제로 써 봤을 때, 생각보다 관리 부담을 줄여줬습니다.

구체적으로는 이런 식입니다.

• 일반 사용자 계정: 평소 웹 브라우징, 문서 작성, 간단한 작업
• dev 계정: 개발 도구, SDK, 각종 설정 파일(.gitconfig, .bashrc, .ssh 등)

이렇게 두 계정을 분리해 두면, 개발 환경을 실험하다가 셸 설정이나 PATH를 망가뜨려도 dev 계정 안에서만 문제를 해결하면 됩니다. 그리고 중요한 SSH 키나 토큰도 개발 계정 안에만 두고, 일반 계정에서는 접근하지 않도록 나눌 수 있습니다. 반대로, 계정을 여러 개 쓰는 것이 번거롭다고 느낀다면 이 방법은 필요 없을 수도 있습니다. 실제로는 “내가 개발 환경을 얼마나 자주 갈아엎는 타입인지”에 따라 선택이 달라졌습니다.

제가 실제로 쓰는 Ubuntu 가벼운 개발 환경의 모습

마지막으로, 글에서 말한 내용을 실제로 어떻게 쓰고 있는지 간단히 정리해 보겠습니다. 어느 정도 정리된 뒤에는 패턴이 이렇게 굳었습니다.

• Ubuntu LTS 한 버전을 기준으로 쓰고, 중간에 재설치를 자주 하지 않는다.
• 시스템 전역에는 Git, 컴파일러, 에디터, 주 언어 런타임 정도만 설치한다.
• 프로젝트별로 디렉터리를 분리하고, Python은 venv, Node는 프로젝트별 node_modules로 해결한다.
• 버전이 갈라질 필요가 생길 때만 pyenv·nvm 같은 도구를 도입한다.
• 서버와 완전히 동일한 환경이 필요한 경우에만 Docker를 쓴다.

이렇게 해두니, 개발 환경이 “보이지 않는 거대한 컨테이너 스택”이 아니라, 눈으로 이해할 수 있는 범위 안에서 유지되는 느낌이었습니다. 문제도 대부분 디렉터리 단위, 프로젝트 단위에서 해결할 수 있었고, OS 자체를 갈아엎어야 하는 상황은 훨씬 줄어들었습니다.

Ubuntu에서 Docker 없이도 충분히 가벼운 개발 환경을 만드는 건 어렵지 않습니다. 오히려 처음부터 컨테이너를 복잡하게 얹기 전에, 로컬 환경만으로 어디까지 갈 수 있는지 한 번 체험해 보는 것이 이후 선택에도 도움이 됩니다. 그 다음에 “이제 진짜 Docker가 필요하겠다”는 지점이 보이면, 그때는 이미 Ubuntu 자체를 잘 다루고 있을 가능성이 크기 때문에 훨씬 수월하게 넘어갈 수 있습니다.