으앙망!

으앙 망했어!

공부/Ubuntu 24.04

Python과 NCL을 하나의 conda 가상환경에 구축

euangmang 2026. 6. 22. 08:13

CPU: Intel Core i9-9900X (10 cores, 20 threads, x86_64)

RAM: 64GB (16GB * 4ea)

OS: Ubuntu 24.04

Kernel: Linux 6.17.0-23-generic (x86_64)

conda 버전: 25.11.1

 

설치 목표 Python 버전: 3.11

설치 목표 NCL 버전: 6.6.2


요약

NCL 6.6.2와 Python 3.11 및 라이브러리를 하나의 conda 가상환경에 구축할 때

이미 Python이 설치된 기존 환경에 NCL을 추가 설치하는 순간(conda install)

"Solving environment" 단계가 상당히 오래 지속되어

마치 멈춘 것처럼 보이는 문제가 발생한다.

근본적인 원인은 NCL의 의존성(ESMF)이 요구하는 MPI(mpich) 변종과

기존 환경에 깔려 있던 nompi 변종이  충돌하여

의존성 해결(solve)이 조합적으로 폭증하기 때문으로 추정된다.

이에 대한 해결책은 기존 환경에 NCL을 추가 설치하거나 그 반대로도 하지 말고

NCL을 포함한 모든 패키지를 conda-forge 단일 채널 + strict 우선순위로 한 번에 명시해서

새 환경으로 재생성(통합 solve)하는 것이 가장 깔끔하고 빠르다.

아래 한 줄이면 끝난다.

conda create -n myenv -c conda-forge --strict-channel-priority \
    python=3.11 numpy scipy matplotlib pandas xarray \
    netcdf4 dask cartopy ncl=6.6.2

참고로 줄 마지막에 있는 백슬래쉬( \ )는 단순 줄바꿈이니까

줄바꿈 넣기 싫다면 지우고 그냥 쭉 이어서 써도 된다.


NCL과 Python에 대한 설명은 생략한다.

어차피 이 글을 보는 사람은 이미 잘 다루는 사람들

혹은 필요에 의해서 설치하는 사람들이기 때문에.

 

일반적으로 NCL과 Python 및 numpy, xarray, scipy 같은 라이브러리들은

서로 다른 환경에 분리해 두는 것이 가장 깔끔하다.

하지만 하나의 환경에 모두 설치해야 하는 경우가 분명 존재한다.

 

일단, NCL 6.6.2 바이너리 자체는 Python에 의존하지 않는다.

이 말인 즉슨, NCL의 동작은 Python의 버전과는 무관하다.

그럼에도 불구하고 통합 설치/구축이 까다로운 이유는

NCL과 Python 패키지가 공유하는 하위 라이브러리(HDF5, NETCDF, PROJ 등)가

서로 합의된 버전으로 맞춰져야 하기 때문이다.

즉 같이 사용할 수 있는 버전으로 모두 설치가 되어야 한단 소리다.

 

참고로 NCL은 실행에 있어 libgfortran 런타임을 필요로 하며(문제가 없다면 자동으로 같이 설치됨)

gfortran 컴파일러는 WRAPIT으로 사용자 Fortran 코드를 래핑할 때에만 필요로 한다.


문제 발생

나는 항상 했던 방법대로 가상환경을 만들어 Python 3.11 및 라이브러리들을 설치했고,

그 후 바로 NCL을 설치하려 했다.

설치 과정 중 에러는 발생하지 않았지만 다음과 같은 문제가 있었다.

- "Solving environment" 단계에서 30분 이상 진행 멈춤

- top 명령어로 확인 결과 프로세스는 100%로 CPU를 사용하고 있었음 (즉 멈춘 게 아님)

- Ctrl+C로 즉시 취소되지 않고 한참 뒤에야 종료됨

 

정리하자면, 설치 단계에서 실패하는 건 아니지만

의존성 해결 단계 자체가 비정상적으로 오래 걸린다는 것이 문제였다.


문제 원인

문제 원인은 단순히 하나만 있는 게 아니라더라.

 

- MPI 변종(variant) 충돌 (가장 핵심)

기존 환경의 입출력 스택(HDF5, NETCDF4, LIBNETCDF)은 모두 nompi로 설치되어 있더라.

반면 NCL 6.6.2의 의존성인 ESMF는 MPI_MPICH 변종의 HDF5/NETCDF를 요구한다.

그 결과, solver는 전체 입출력 스택을 nompi와 mpich 사이에서 서로 맞추려고 시도를 하게 되고,

이 과정에서 검토해야 할 조합이 폭발적으로 증가해

solve 단계가 극단적으로 길어진 것으로 추정 중이다.

단순히 옛 버전 대 새 버전의 문제가 아니라는 것이다.

 

- 채널 혼합

가상환경의 기본 채널이 defaults인 상태에서 명령어에 -c conda-forge를 덧붙여 두 채널을 섞을 때

strict 우선순위가 설정되지 않으면 solver는 동일 패키지에 대해 여러 채널의 후보를 함께 비교해야 하므로

solve 단계에서 부담이 더 커질 수 밖에 없다더라.

 

- 기존 환경에 덧붙여 설치(in-place)하는 방식

기존 환경에 패키지를 추가해서 설치하는 건 사실 평범하다.

누가 처음부터 가상환경에 모든 라이브러리/패키지를 단 한 번의 명령어로 설치하겠는가.

사용하다가 필요하면 설치하고 업데이트하고 그러는 게 정상이지.

하지만 이 경우는 조금 특수한 경우라고 생각하는 게 마음 편하다.

그래서 빈 환경에서 처음부터 필요한 라이브러리를 한 번에 풀고

더 이상 추가하지 않는 게 정신건강에 이롭기 때문에

만약 기존 Python 환경에 NCL을 설치하고자 한다면

그냥 따로 하나 새로 만드는 게 낫다.


문제 해결

결국 해결은 새 환경을 구성하는 게 가장 쉽고 빠르다.

이렇게 하면 빈 환경에서 solver가 설치하고자 하는 것들 전체를 동시에 보고

한 번에 풀고자 하기 때문에 수 분 내에 설치가 끝날 것이다.

혹은 NCL을 먼저 설치하고 단계적으로 설치하는 것도 방법이 될 순 있다.

일단 가상환경 구성 단계부터 하나씩 보자.

 

- 본 설치 이전에 dry-run으로 검증을 한다.

실제 설치 전에 --dry-run으로 조합이 잘 풀리는지,

어떤 패키지가 영향을 받는지,

시간이 얼마나 걸리는지 등을 미리 확인하는 게 좋다.

conda create --dry-run -n myenv -c conda-forge --strict-channel-priority \
    python=3.11 numpy scipy matplotlib pandas xarray \
    netcdf4 dask cartopy ncl=6.6.2

 

- conda-forge 단일 채널 및 strict 우선순위 설정

가상환경을 생성할 때부터 conda-forge 채널을 고정하고 strict 우선순위를 주면

채널 혼합 문제를 어느 정도 해결할 수 있다. (완전히 해결인지는 나도 잘 모름)

단일 채널을 사용하면 solve 단계가 더 빠르고 일관적이라나...

가상환경 이름을 myenv라고 한다면 다음과 같이 가상환경을 생성할 수 있다.

conda create -n myenv -c conda-forge --strict-channel-priority \
    python=3.11 numpy scipy matplotlib pandas xarray \
    netcdf4 dask cartopy ncl=6.6.2

 

- NCL과 Python 통합 환경에 따른 비용 인지

어쩔 수 없이 NCL과 Python을 하나의 가상환경에 설치하는 것이기 때문에

두 녀석이 같이 사용하는 입출력 스택을 사용하는 건 거의 필수라고 봐야한다.

하지만 걱정할 필요는 딱히 없는 게, 정상 동작에는 지장이 없다.

물~론 일반적인 사용자의 경우.

애초에 이 입출력 라이브러리에 대한 세세한 컨트롤이 필요한 전문가는 이 글 안 봄.


나는 이와 같은 방법으로 해결했다.

참고로 Mac의 경우는 살짝 경우가 다르다.

아마 C compiler 문제도 있던 것 같은데...

Mac은 빈 가상환경에 NCL만 단독으로 설치해도 실행파일이 생성되지 않더라.

그건 다른 포스트에서 작성했으니 그걸 참고.

 

- 끝 -