우분투에서 프로젝트 폴더를 만들고 가상 환경으로 실행·관리하기 (완전 기초)

우분투에서 프로젝트 폴더를 만들고 가상 환경으로 실행·관리하기 (완전 기초)

한눈에 보는 요약

이 글에서 말하는 “가상화 시스템”은 특정 프로젝트만을 위한 개발용 가상 환경(virtual environment)을 의미합니다. 대표적인 예가 Python의 venv입니다. 하나의 프로젝트 폴더 안에 자기만의 패키지·라이브러리 공간을 만들어 두고, 다른 프로젝트와 섞이지 않도록 격리하는 방식입니다.

우분투에서는 터미널에서 mkdir로 프로젝트 폴더를 만들고, 그 안에서 python3 -m venv .venv 같은 명령으로 손쉽게 가상 환경을 만들 수 있습니다. 이후에는 source .venv/bin/activate로 켜고, deactivate로 끄는 식으로 관리합니다.

이 글을 끝까지 따라 하시면 “프로젝트용 폴더 만들기 → 가상 환경 생성 → 실행(활성화) → 패키지 설치 → 비활성화·삭제”까지 한 흐름으로 이해하시게 됩니다. 완전 초보를 기준으로 천천히 설명하니, 그대로 따라만 하셔도 됩니다.

목차

• 1. 핵심 포인트
• 2. 상세 설명
• 3. 시스템 전역 설치 vs 가상 환경 비교 표
• 4. 전체 예제 코드 한 번에 보기
• 5. 실행 단계(따라 하기)
• 6. 추가로 생각해볼 점
• 7. 블로그 최적화 정보

---

핵심 포인트

• 프로젝트 폴더는 ~/projects/내프로젝트처럼 한 곳에 모아서 관리하면 나중에 찾기 쉽습니다.
• 가상 환경은 “그 프로젝트만 쓰는 작은 OS”라고 생각하면 됩니다. 패키지 충돌을 막고, 삭제·백업도 훨씬 간단해집니다.
• 우분투에서는 python3 -m venv .venv로 가상 환경을 만들고, source .venv/bin/activate로 활성화합니다.
• 가상 환경이 켜져 있으면 터미널 프롬프트 앞에 (.venv)처럼 이름이 붙습니다. 이 상태에서 설치하는 패키지는 모두 이 프로젝트 안에만 들어갑니다.
• deactivate 명령 한 줄로 가상 환경을 끌 수 있고, 필요 없어진 환경은 폴더(.venv)만 지우면 깔끔하게 제거됩니다.

상세 설명

1. 왜 프로젝트마다 가상 환경이 필요할까?

처음 개발을 시작하면 보통 이렇게 작업합니다. 우분투에 Python이나 기타 언어를 설치하고, pip install 패키지명을 그냥 실행합니다. 이렇게 하면 패키지가 시스템 전역에 설치됩니다. 문제는 프로젝트마다 필요한 버전이 다를 수 있다는 점입니다.

• A 프로젝트는 django 3.x가 필요하고, B 프로젝트는 django 4.x가 필요할 수 있습니다.
• 전역에 설치하면 한 쪽에 맞춰버리는 순간, 다른 프로젝트가 깨질 수 있습니다.

이런 문제를 막기 위해 “프로젝트마다 자기만의 가상 환경을 하나씩 둔다”는 것이 현대적인 표준입니다. 각 가상 환경은 자기만의 site-packages 폴더를 갖고, 그 안에서만 라이브러리를 관리합니다.

2. 우분투에서 프로젝트 폴더 구조 잡기

개인/업무 프로젝트를 뒤섞지 않으려면 폴더 구조를 먼저 정리하는 것이 좋습니다. 예시 구조는 다음과 같습니다.

# 홈 디렉터리로 이동
cd ~

# 공통 프로젝트 폴더 생성 (없다면)
mkdir -p ~/projects

# 새 프로젝트 폴더 생성
mkdir -p ~/projects/my_first_project

# 해당 폴더로 이동
cd ~/projects/my_first_project

위와 같이 해 두면, 나중에 ~/projects만 백업하거나 다른 PC로 옮겨도 프로젝트들을 한 번에 관리하기가 쉽습니다. 이제 이 my_first_project 폴더 안에 가상 환경을 만들 것입니다.

3. Python 및 venv 모듈 설치 확인

예제로 Python 기반 프로젝트를 기준으로 설명하겠습니다. 다른 언어(Node.js, Ruby 등)도 개념은 같고, 가상 환경을 만드는 도구만 다를 뿐입니다.

# Python3 버전 확인
python3 --version

# 필요한 경우, python3-venv 패키지 설치 (Ubuntu)
sudo apt update
sudo apt install -y python3-venv

일반적인 우분투 데스크톱/서버라면 Python3는 이미 설치되어 있는 경우가 많지만, python3-venv 패키지가 없으면 python3 -m venv 명령이 동작하지 않을 수 있으므로 한 번 확인해 주시는 것이 좋습니다.

4. 프로젝트 폴더 안에 가상 환경 만들기

이제 실제로 가상 환경을 만들어 보겠습니다. 관례적으로 폴더 이름을 .venv 또는 venv로 많이 사용합니다.

# 반드시 프로젝트 폴더 안에서 실행
cd ~/projects/my_first_project

# .venv 라는 이름으로 가상 환경 생성
python3 -m venv .venv

명령이 끝나면 my_first_project 폴더 안에 .venv라는 디렉터리가 생깁니다. 이 안에는 Python 실행 파일, 표준 라이브러리, 패키지를 설치할 전용 폴더 등이 들어 있습니다. 앞으로 이 프로젝트는 이 .venv 안에서만 패키지를 설치하고 사용할 것입니다.

5. 가상 환경 활성화(실행)와 비활성화

가상 환경을 만들었다고 해서 자동으로 사용되는 것은 아닙니다. 매번 작업을 시작할 때 터미널에서 “이 가상 환경을 쓰겠다”고 알려 줘야 합니다. 이를 활성화(activate)라고 부릅니다.

# 가상 환경 활성화
cd ~/projects/my_first_project
source .venv/bin/activate

성공했다면 터미널 프롬프트가 다음과 같이 바뀝니다.

(.venv) user@ubuntu:~/projects/my_first_project$

앞에 (.venv)가 붙어 있으면, 지금 이 터미널에서 실행하는 Python과 pip는 전부 이 가상 환경 내부 것을 사용한다는 뜻입니다.

작업이 끝났을 때는 다음 한 줄로 가상 환경을 끌 수 있습니다.

# 가상 환경 비활성화
deactivate

프롬프트에서 (.venv) 표시가 사라지면 전역 Python으로 되돌아온 것입니다.

6. 패키지 설치와 requirements.txt 관리

가상 환경이 활성화된 상태에서 패키지를 설치하면, 전역이 아니라 .venv 폴더 안에 설치됩니다.

# 예: Django와 requests 설치
(.venv) pip install django requests

# 현재 가상 환경에 설치된 패키지 목록을 파일로 저장
(.venv) pip freeze > requirements.txt

requirements.txt 파일은 “이 프로젝트가 어떤 패키지와 버전을 쓰고 있는지”를 기록해 둔 목록입니다. 다른 개발자가 이 프로젝트를 가져왔을 때는 다음 두 줄만 실행하면 동일한 환경을 재현할 수 있습니다.

# 가상 환경 활성화 후
pip install -r requirements.txt

이렇게 하면 “같은 프로젝트는 항상 같은 버전의 패키지”를 사용하게 되어, 배포 환경과 로컬 환경이 달라서 생기는 문제를 크게 줄일 수 있습니다.

7. 가상 환경 관리: 이름, 위치, 삭제

가상 환경은 기본적으로 “폴더 하나”이기 때문에 관리가 매우 단순합니다.

• 이름: .venv, venv, .env 등 어떤 이름도 가능하지만, 팀 내에서 하나로 통일하는 것이 좋습니다.
• 위치: 대부분 “프로젝트 루트 바로 아래”에 둡니다. 그래야 프로젝트만 압축하거나 백업할 때 함께 관리하기 쉽습니다.
• 삭제: 더 이상 쓸 일이 없다면 가상 환경 폴더만 지우면 됩니다.

# 가상 환경 삭제 (주의: 되돌릴 수 없음)
cd ~/projects/my_first_project
rm -rf .venv

나중에 다시 필요해지면 동일한 폴더에서 python3 -m venv .venv를 실행해 새로 만들고, requirements.txt가 있다면 pip install -r requirements.txt로 패키지를 다시 설치하면 됩니다.

---

3. 시스템 전역 설치 vs 가상 환경 비교 표

아래 표는 “전역 설치”와 “프로젝트별 가상 환경”을 직관적으로 비교한 것입니다. 실무에서는 거의 항상 오른쪽 방식(가상 환경)을 사용합니다.

항목	시스템 전역 설치	프로젝트별 가상 환경
설치 위치	/usr/local, /usr/lib 등 공용 위치	각 프로젝트 폴더 내부(./.venv)
프로젝트 간 영향	한 프로젝트가 버전을 바꾸면 다른 프로젝트에 영향 가능	서로 완전히 격리되어 영향 없음
삭제/정리	어느 프로젝트가 쓰는지 헷갈리면 삭제하기 어려움	폴더 하나만 지우면 깨끗하게 정리
배포 재현성	“내 PC에서는 되는데 서버에서 안 된다” 문제가 자주 발생	requirements.txt로 같은 환경을 재현하기 쉬움
권장 여부	아주 간단한 실험 수준에서만 권장	실제 프로젝트에서는 필수에 가까움

---

4. 전체 예제 코드 한 번에 보기

지금까지 조각으로 본 명령들을 한 번에 정리한 버전입니다. 복사해서 자신의 환경에 맞게 경로/프로젝트 이름만 바꾸셔도 됩니다.

# 1) 공통 프로젝트 폴더 및 새 프로젝트 폴더 생성
cd ~
mkdir -p ~/projects
cd ~/projects
mkdir -p my_first_project
cd my_first_project

# 2) Python venv 모듈이 없다면 설치 (한 번만 수행)
sudo apt update
sudo apt install -y python3-venv

# 3) 가상 환경 생성
python3 -m venv .venv

# 4) 가상 환경 활성화
source .venv/bin/activate

# 5) 필요한 패키지 설치 예시
pip install django requests

# 6) 현재 패키지 목록 저장
pip freeze > requirements.txt

# 7) 작업 종료 후 가상 환경 비활성화
deactivate

이 흐름만 익숙해지면, 새로운 프로젝트를 시작할 때마다 “폴더 만들기 → 가상 환경 만들기 → 활성화 → 패키지 설치”가 자연스러운 루틴이 됩니다.

---

5. 실행 단계(따라 하기)

1. 프로젝트 저장 위치를 정합니다.
   홈 디렉터리 아래에 ~/projects처럼 모든 프로젝트를 모아둘 상위 폴더를 하나 정합니다. 이렇게 해두면 나중에 백업·이동이 쉬워집니다.
2. 새 프로젝트 폴더를 만듭니다.
   mkdir -p ~/projects/my_first_project로 폴더를 만들고, cd로 해당 폴더 안으로 들어갑니다. 이 폴더가 소스 코드, 가상 환경, 설정 파일의 “집”이 됩니다.
3. Python3 및 venv 모듈을 확인합니다.
   python3 --version 으로 버전을 확인하고, 필요하다면 sudo apt install python3-venv로 venv 기능을 설치합니다. 이 과정은 시스템 전체에서 한 번만 해 주면 됩니다.
4. 프로젝트 폴더 안에서 가상 환경을 생성합니다.
   python3 -m venv .venv 명령을 실행하면 .venv 폴더가 생깁니다. 이 폴더가 바로 프로젝트 전용 가상 환경이며, 다른 프로젝트와 완전히 분리된 공간입니다.
5. 작업을 시작할 때마다 가상 환경을 활성화합니다.
   source .venv/bin/activate 를 실행해 프롬프트 앞에 (.venv)가 붙었는지 확인합니다. 이제 pip install로 설치하는 모든 패키지는 이 프로젝트 안으로만 설치됩니다.
6. 필요한 패키지를 설치하고 requirements.txt를 생성합니다.
   예를 들어 웹 프로젝트라면 pip install django로 설치한 뒤, pip freeze > requirements.txt로 패키지 목록을 파일로 저장합니다. 이 파일은 향후 다른 PC나 서버에서 같은 환경을 재현하는 데 사용합니다.
7. 작업이 끝나면 가상 환경을 정리합니다.
   그날의 작업이 끝나면 deactivate로 가상 환경을 끈 뒤 터미널을 닫습니다. 프로젝트를 더 이상 사용하지 않게 되면 rm -rf .venv로 가상 환경 폴더를 삭제해 디스크 공간을 정리합니다.

---

6. 추가로 생각해볼 점

• Python 외에 Node.js, Ruby, PHP 등도 각각의 가상 환경/버전 관리 도구(nvm, rbenv 등)를 제공하므로, 프로젝트 수가 많아질수록 “프로젝트별 격리” 원칙을 지키는 것이 장기적으로 훨씬 안전합니다.
• 여러 명이 함께 작업하는 팀이라면, 가상 환경 이름, 폴더 구조, requirements.txt 관리 방법 등을 팀 규칙으로 문서화해 두면 환경 차이로 인한 문제를 크게 줄일 수 있습니다.
• 나중에는 Docker 컨테이너까지 도입해 “OS 수준”까지 격리하는 방식도 고려할 수 있습니다. 하지만 기본 개념은 지금 배운 것과 같습니다. “프로젝트별로 독립된 공간을 만들고, 그 안에서만 실행한다”는 생각을 잊지 않으시면 됩니다.

---