#1. 프로젝트 실행환경 만들기(복습)

개발을 하다보면 기존에 다른 사람들이 작업한 프로젝트를 이어받아서 작업해야 하는 경우도 생긴다. 

이때 라이브러리 버전 관리, 환경변수 설정 등이 알맞게 되어야만 이전 사람들이 프로젝트를 진행하던 똑같은 환경에서 개발을 진행할 수 있다.

오늘은 간단하게 그 순서에 대해서 알아보겠다. 

 

📒가상 환경

✅가상환경 만들기

우선 가상환경을 하나 만들어준다. 

 

가상환경을 만들기 위해서는 virtualenv라는 라이브러리가 필요하다. 없다면 아래 커맨드를 이용해서 virtualenv 라이브러리를 설치하자. 

이때 커맨드를 실행하는 위치는 프로젝트 root 디렉토리로 되어 있어야 한다. 

pip install virtualenv

 

 

이제 가상환경을 만들어준다. 지금 만든 가상환경 안에서 프로젝트에 쓰일 라이브러리와 버전을 관리할 것이다. 

virtualenv 뒤에는 가상환경의 이름을 붙여주면 된다. 보통은 venv를 많이 사용한다. 

virtualenv venv		// 가상환경 이름: venv
virtualenv myenv	// 가상환경 이름: myenv

 

때때로 python 버전에 따라서 사용 가능한 라이브러리가 달라지기도 한다. 

이 경우엔 가상환경을 만들 때 어떤 버전을 사용해서 가상환경을 운영할지도 따로 정할 수 있다. 

virtualenv venv --python=3.8	// python 3.8을 사용하는 가상환경 설치

 

✅가상환경을 만드는 이유

가상환경(virtual environment)을 사용하는 이유는 여러 가지가 있을 수 있다. 대표적인 이유는 여러 개의 프로젝트를 동시에 진행할 때 라이브러리 버전 관리가 쉽기 때문이다. 

 

예를 들어 프로젝트 A는 django-rest-framework 0.0.1 버전을 사용하고 프로젝트 B는 0.0.2 버전을 사용할 경우, 버전이 다르기 때문에 프로젝트를 바꿔 가면서 작업할 경우 버전에 혼동이 생긴다. 심한 경우는 버전이 맞지 않아서 실행되지 않을 수 있다. 

 

그러나 프로젝트별로 개별의 가상 환경을 만들고 그 안에서 작업하면, 가상환경마다 사용하는 라이브러리와 버전이 다르고, 프로젝트별로 어떤 버전을 사용하건 다른 프로젝트에 영향을 주지 않는다. 

 

✅가상환경 실행하기

위에서는 가상환경을 만들었다. 앞으로 프로젝트를 작업할 때마다 이 가상환경을 실행한 상태에서 작업해야 한다. 

(가상환경에 프로젝트에 필요한 라이브러리가 모두 포함되기 때문에, 가상환경을 실행하지 않으면 어차피 프로젝트를 실행할 수 없다.)

 

윈도우에서 가상환경을 실행하는 방법은 Command Prompt에서 실행하는 방법과 PowerShell에서 실행하는 방법 두 가지가 있다. 

 

Command Prompt(cmd 창)에서 실행하는 방법은, 가상환경 이름\Scripts\activate.bat

venv\Scripts\activate.bat

 

PowerShell에서 실행하는 방법은, .\가상환경 이름\Scripts\Activate.ps1 

.\venv\Scripts\Activate.ps1

나는 항상 cmd로 작업해서 위의 방법을 사용했다. 그러나 powershell이 mac과 linux에서 사용하는 커맨드를 사용한다고 들어서, 앞으로는 powershell 명령어도 많이 익힐 필요가 있겠다. 

아무튼 이 과정을 마치면 터미널 창에서 뜨던 디렉토리 앞에 (venv) 가 붙는다. 이는 가상환경이 현재 실행 중이라는 뜻이다. 이제 작업하면 된다!

 

라이브러리 설치

본인이 처음부터 끝까지 프로젝트를 만드는 경우라면 가상환경 작업을 끝내고 바로 프로젝트를 만들어도 되지만, 다른 사람들과 같이 개발하는 경우는 추가 작업이 필요하다. 

 

✅현재 프로젝트 가상환경에서 사용한 라이브러리를 파일로 저장하기

여러 명이 프로젝트 하나를 개발하는 경우, 사람들이 작업하던 환경과 같은 환경에서 프로젝트를 개발해야 한다. 이때 라이브러리의 버전 관리 등을 쉽게 하기 위해서는 사용한 라이브러리의 버전을 모아서 관리할 필요가 있다. 

 

이럴 때 pip의 freeze 기능을 사용한다. 

pip freeze > requirements.txt

freeze를 하면 현재 프로젝트에서 사용된 라이브러리와 버전을 requirements.txt 파일을 만들어서 그 안에다 저장해 준다. 

이러면 나중에 다른 사람이 이 프로젝트를 작업하게 되었을 때, requirements.txt 파일을 사용하여 똑같은 라이브러리와 버전을 가상환경에 설치하여 사용할 수 있다. 

 

✅프로젝트에서 사용한 라이브러리를 설치하기

이 경우는 위의 경우와는 반대로, 다른 사람이 작업했던 프로젝트를 이어받아 작업할 때 사용한다. 

앞서 작성된 requirements.txt 파일에 설치된 라이브러리와 버전을 하나하나 다운받지 않고, 다음 명령어를 사용한다. 

(파일명을 다르게 하고 싶으면 뒤의 부분을 바꾸면 된다.)

pip install -r requirements.txt

requirements.txt 파일에 입력된 라이브러리와 버전을 현재 가상환경에 설치해 준다. 

 

⚠️설정 파일(requirements.txt)은 딱 하나만 두고 관리하자. 

여러 사람이 작업하다 보면 여러 개의 설정 파일이 생길 수 있다. 그러면 때론 파일을 혼동하여, 가장 최근의 라이브러리 설치 상태를 반영한 파일이 아닌 다른 파일에 작성된 라이브러리를 설치하게 될 수 있다. (내가 했던 실수...)

따라서 설정 파일(requirements.txt)은 꼭 하나만 두고 관리하자. 

 

위의 두 과정에서 별다른 오류가 없었다면, 프로젝트 실행을 위한 기본적인 작업은 끝났다. 이제는 환경변수 작업만 남았다. 

 

📒환경변수(.env)

프로젝트를 실행하기 위해서 필요한 중요한 정보를 담고 있는 변수. 

보통 데이터베이스의 포트 번호, 비밀번호 등을 포함하기 때문에 절대 외부에 공유해서는 안 된다. (비밀번호 다 털림. 계정 털림.)

 

환경변수 파일 이름은 보통 .env 로 사용한다. 

 

✅gitignore 사용해서 환경변수 파일이 github/git에 공유되지 않게 하기

이 파일을 공유하지 않으려면 gitignore를 활용해야 한다. 

.gitignore 파일을 만들고, 이 안에다가 깃허브에 공유하고 싶지 않은 파일 이름 또는 확장자를 적어주면 된다. 

 

예를 들어서, .gitignore 파일에 다음과 같이 입력해 보자.

.env
.venv
info.py

그리고 프로젝트를 깃허브에 등록할 때, 확장자가 env 또는 venv인 파일과 info.py 파일은 깃허브에 등록되지 않는다. 

 

⚠️예외 경우

다만 예외인 경우도 있다. 이미 git에 등록되어 관리되던 파일이라면, 관리된 이후에 .gitignore 파일에 추가된다고 해서 업로드에서 제외되지 않는다. 

 

이 경우 추가적인 git 명령어를 사용해서 작업해야 한다. 

 

작업 과정

1. .gitignore 파일에 깃허브에 올리지 않을 파일명 추가

2. git 캐시 삭제

--cached 옵션을 추가하지 않으면 로컬 저장소에 있는 파일과 원격 저장소(깃허브)에 있는 파일이 모두 삭제된다. 

지금은 원격 저장소인 깃허브에 등록된 파일만 삭제하려는 것이므로 꼭 --cached 옵션을 붙여주자. 

git rm -r --cached .

3. git에 현재 작업한 내용을 임시로 저장

: add 뒤에는 현재 디렉토리를 명시하기 위해서 . 하나를 붙인다. 

git add .

4. 현재 git 프로젝트의 상태 확인

: 현재 등록된 커밋(commit)이 있는지를 보여준다. 

git status

5. 변경사항 저장하기

git commit

 

.env 파일 간단하게 생성하는 방법

gitignore.io - 자신의 프로젝트에 꼭 맞는 .gitignore 파일을 만드세요 (toptal.com)

이 링크에서 본인의 운영체제와 사용하는 언어/프레임워크를 검색어로 입력하면 그에 맞는 .env 파일 형식을 생성해 준다. 

이를 참고하여 제외할 부분은 제외하고, 추가할 부분은 추가로 작성하는 방식으로 .env 파일을 작성할 수 있다. 

 

📒Git(깃)

Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.

 

로컬 저장소와 원격 저장소

여러 명의 사용자는 각자의 로컬 PC에서 작업을 진행하고, 이를 원격 저장소에 공유하는 방식으로 작업한다. 

즉 각자의 PC=로컬 저장소, Github 계정=원격 저장소 이다. 

 

✅파일 업로드 과정

개인 PC에서 작업한 이후에는 작업내용을 공동 저장소인 깃허브에도 저장해야 한다. 

이 과정을 보통 '커밋을 한다'고 하지만, 구체적으로는 네 가지 상태로 나눠진다. 

 

0) Working Directory

작업하면서 생긴 변경사항들이 아무 영역에도 반영되지 않은 상태이다. 

 

1) Staging

작업하면서 생긴 변경사항이 '임시저장' 된 단계이다. Github Desktop 등의 프로그램을 사용하면 변경사항이 생기자마자 바로 staging 영역으로 등록된다. 

그렇지 않은 경우, git add . 명령어를 사용해서 현재 디렉토리에서 발생한 변경사항을 임시저장인 staging 영역으로 등록해 준다. 

 

2) Commit

Staging 영역으로 등록된 변경사항들이 기록으로 남는 영역이다. 아직 깃허브에 변경사항이 저장된 상태는 아니다. git commit 명령어를 통해 실행할 수 있다. 

다만 Staging 단계와의 차이점은 Commit부터는 깃허브에서 작업 기록으로 남는다는 것이다. Staging 단계에서는 add를 남발해도 임시저장의 개념이라 아무런 기록이 남지 않지만, commit을 남발하면 그 변경사항이 모두 기록된다. 

따라서 보통의 공동작업에서는 커밋을 남발하지 않고, 기능 추가/기능 개선/오류 처리 등 여러 기준을 세우고 그에 따라서 커밋을 하는 것이 일반적이다. 

 

3) Push

commit 된 사항에 대해서 push를 하도록 권장한다. push 된 내용은 깃허브에 반영될 수 있다. 

git push 명령어를 통해 실행할 수 있다.

다만 프로젝트에 따라서 개인이 push하면 바로 깃허브에 반영이 되도록 할 수도 있고, 여러 사용자가 확인 뒤 승인(?)하면 변경사항이 반영되도록 할 수도 있다. 

 

 

참고한 포스트

[Git] gitignore란 무엇일까? :: Gyun's 개발일지 (tistory.com)

git rm --cached 파일 삭제 :: 마이구미 :: 마이구미의 HelloWorld (tistory.com)

[GIT] area, add, commit, push, stage (velog.io)