pipenv로 의존성 관리 개선하기: requirements.txt에서의 전환 경험

Onechain 거래소에서 의존성 관리를 위한 도구로 기존의 requirements.txt 대신 pipenv를 도입하게 되었습니다. 이 글에서는 왜 이 전환을 하게 되었는지, 어떤 변화가 있었는지, 그리고 얻은 이점과 고려할 점들을 공유하려고 합니다.

1. 기존의 requirements.txt 방식

많은 Python 개발자들이 의존성 관리 도구로 requirements.txt를 사용합니다. 간단하고 익숙한 방식이기 때문에 널리 사용되어 왔죠. requirements.txt 파일은 프로젝트에서 필요한 패키지들을 명시하고, pip 명령어를 사용해 한 번에 설치할 수 있게 해줍니다.

$ pip install -r requirements.txt

그러나 이 방식은 다음과 같은 한계를 가지고 있었습니다:

• 환경 격리 부족: virtualenv를 함께 사용해야 했지만, 환경 관리를 체계적으로 할 수 있는 툴이 부족했습니다.
• 개발 및 프로덕션 환경의 불일치: 개발용 패키지와 프로덕션용 패키지를 따로 관리하기 어렵습니다.
• 잠재적인 의존성 충돌: 의존성 충돌 해결이 어렵고 복잡한 프로젝트에서는 관리가 까다롭습니다.

2. pipenv로 전환한 이유

pipenv는 pip와 virtualenv의 장점을 결합한 도구로, Python 공식 프로젝트에서 권장하는 패키지 관리 방법입니다. 다음과 같은 이유로 전환을 결정하게 되었습니다:

• 가상 환경 자동 생성: pipenv는 프로젝트별로 가상 환경을 자동으로 설정해 주어, 의존성 격리와 관리가 더욱 용이해졌습니다.
• 개발 및 프로덕션 의존성 분리: pipenv는 개발용 패키지와 프로덕션용 패키지를 Pipfile과 Pipfile.lock에서 명확히 구분하여 관리할 수 있습니다.
• 의존성 버전 고정 및 충돌 방지: pipenv lock을 통해 모든 의존성의 버전을 고정하고 충돌 문제를 사전에 해결할 수 있습니다.

3. 전환 과정과 주요 차이점

requirements.txt에서 pipenv로 전환하는 과정은 비교적 간단했습니다. requirements.txt 파일이 있다면, 이를 Pipfile로 쉽게 변환할 수 있습니다:

$ pipenv install -r requirements.txt

이후 프로젝트는 Pipfile을 통해 관리되며, 종속성 설치 및 관리가 훨씬 수월해졌습니다.requirements.txt vs. Pipfile:

• **requirements.txt**는 단순한 패키지 목록이지만, Pipfile은 패키지의 설치 버전과 범위까지 포함한 정보가 들어있습니다.
• **Pipfile.lock**을 통해 의존성의 버전을 명확히 고정하고, pipenv는 설치할 때 충돌을 방지합니다.

4. 장점 및 얻은 이점

1. 환경 관리 간소화: pipenv는 프로젝트 별로 가상 환경을 자동 생성하고 관리해 줍니다. 덕분에 여러 프로젝트에서의 의존성 충돌 문제가 줄어들었고, 환경 세팅이 간편해졌습니다.
2. 버전 충돌 최소화: Pipfile.lock 파일을 통해 설치된 패키지들의 버전을 고정하고, 동일한 환경에서 작업할 수 있게 되었습니다. 특히 협업 시 모든 팀원이 동일한 의존성을 사용하도록 보장하는 것이 훨씬 쉬워졌습니다.
3. 개발 및 프로덕션 환경 구분: 개발용 패키지와 프로덕션용 패키지를 분리해서 관리할 수 있어, 불필요한 패키지가 프로덕션 환경에 설치되는 일을 방지할 수 있었습니다.
4. 의존성 설치 속도 개선: 프로젝트의 패키지 관리와 설치 속도가 눈에 띄게 빨라졌습니다. pipenv는 캐시와 락 파일을 사용해 불필요한 설치 과정을 줄이고, 더 효율적으로 패키지를 관리합니다.

5. 전환 시 고려할 점

pipenv는 강력한 도구이지만, 전환 시 다음 사항들을 고려해야 합니다:

• 프로젝트 구조 변경: 기존의 requirements.txt 방식에서 pipenv로 전환하려면 프로젝트의 패키지 구조를 약간 변경해야 합니다.
• 기존 도구와의 호환성: 일부 CI/CD 환경에서는 requirements.txt를 요구할 수 있으므로, 이 부분에 대한 조정이 필요할 수 있습니다.

 이 외에도 Pipenv로 전환하면서, Docker 파일도 수정하게 되었습니다. 이때 주의해야 할 중요한 점 중 하나는 Docker 이미지의 레이어링 순서입니다. Docker는 각 명령어를 레이어로 저장하고, 변경된 부분만 다시 빌드하는 캐싱 방식을 사용합니다.

캐싱을 통한 빌드 시간 단축을 위해, Pipfile.lock에 변경이 생겼을 때만 패키지를 재설치하도록 Dockerfile을 구성해야 합니다. 아래는 현재 프로젝트에서 사용하고 있는 도커파일입니다:

Dockerfile.web

위 Dockerfile에서는 Pipfile과 Pipfile.lock을 먼저 복사한 후 의존성을 설치합니다. 이 순서로 하면 코드가 변경되지 않은 경우, 이미 설치된 의존성을 캐싱하여 빌드 속도를 크게 단축할 수 있습니다.

 

참고자료: https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/