📝Miniforge

Miniforge 알아보기

🚀 Introduction

conda를 쓰면서 이런 경험 한 번쯤 있다:

• 설치는 됐는데 실행하면 crash
• segmentation fault
• 환경이 재현이 안됨

Stack Overflow를 뒤져봐도 뚜렷한 답이 안 나오고, 패키지를 지웠다 깔았다 반복하다가 결국 환경 자체를 날려버린 경험. 이 문제의 본질은 단순하지 않다.

❗ 대부분의 문제는 Python이 아니라 ABI + linker 문제

우리가 흔히 “conda가 꼬였다”라고 표현하는 현상의 상당수는 Python 레벨이 아닌 그 아래, C/C++ 바이너리 레벨에서 발생하는 호환성 문제다. 이 글에서는:

• 왜 Miniforge가 더 안정적인지
• ABI / toolchain / linker 레벨에서 분석
• 실제로 왜 crash가 나는지
• 어떻게 해결되는지

를 단계적으로 설명한다.

---

📦 Conda Ecosystem 구조

먼저 구조를 정확히 이해해야 한다. conda 생태계는 크게 distribution(배포판)과 패키지 매니저 두 계층으로 나뉜다.

flowchart TD
    A[Miniforge / Anaconda] --> B[conda]
    B --> C[Environment]
    C --> D[Python + C++ libs]

👉 핵심:

• conda = 패키지 매니저
• Miniforge = distribution

흔히 conda와 Anaconda를 동일시하는 경우가 많은데, conda는 패키지를 설치하고 환경을 관리하는 도구이고, Anaconda나 Miniforge는 그 conda를 포함한 배포판이다. 어떤 배포판을 쓰느냐에 따라 기본적으로 어떤 채널(패키지 저장소)에서 패키지를 가져오는지가 달라진다.

---

🔥 핵심 질문

왜 같은 conda인데 환경이 깨질까?

👉 답:

패키지를 어디서 가져오는지가 다르기 때문

같은 conda install numpy라도, defaults 채널에서 가져온 numpy와 conda-forge에서 가져온 numpy는 빌드 환경 자체가 다르다. 이 차이가 단일 패키지에서는 드러나지 않지만, 여러 패키지가 서로 의존하면서 결합될 때 문제가 폭발한다.

---

⚖️ Miniforge vs Default Conda

기본 conda

Anaconda나 Miniconda를 설치하면 기본으로 defaults 채널을 사용한다.

• 채널: defaults

• 특징:

  • 보수적
  • 일부 proprietary

Anaconda사에서 관리하는 이 채널은 안정성을 우선시하지만, 패키지 업데이트가 느리고 상업적 사용 시 라이선스 제약이 있다. 또한 각 패키지가 반드시 동일한 빌드 환경에서 컴파일된다는 보장이 없다.

---

Miniforge

Miniforge는 conda-forge 커뮤니티에서 관리하는 경량 배포판이다.

• 채널: conda-forge

• 특징:

  • 최신 패키지
  • 오픈소스
  • mamba 포함

conda-forge는 수천 명의 컨트리뷰터가 참여하는 오픈소스 채널로, 패키지 빌드의 일관성을 시스템적으로 보장하는 인프라를 갖추고 있다. 또한 Miniforge에는 conda의 고속 대체재인 mamba가 기본 탑재되어 있어 의존성 해결 속도가 월등히 빠르다.

👉 중요한 차이:

ecosystem 자체가 다르다

단순히 “어떤 installer를 썼느냐”의 문제가 아니라, 패키지가 빌드되고 테스트되고 배포되는 전체 파이프라인이 다르다는 뜻이다.

---

🧠 The Real Problem: ABI

대부분의 문제 = ABI mismatch

Python 패키지 상당수는 내부적으로 C/C++ 라이브러리에 의존한다. numpy, scipy, pytorch, OpenCV 등 과학 계산이나 딥러닝에서 핵심적으로 사용되는 패키지들이 모두 그렇다. 이 패키지들이 서로 다른 버전의 C++ 라이브러리로 빌드되면 ABI mismatch가 발생한다.

flowchart LR
    A[Python package] --> B[C/C++ lib]
    B --> C[ABI mismatch]
    C --> D[Crash / Segfault]

---

ABI란?

ABI(Application Binary Interface)는 컴파일된 바이너리들이 서로 소통하기 위한 저수준 약속이다. 소스코드 레벨의 API와 달리, ABI는 컴파일 이후의 바이너리 호환성을 다룬다.

ABI = 바이너리 간의 약속

• 함수 이름 (symbol)
• 메모리 구조
• calling convention
• libc / libstdc++ 버전

예를 들어, 같은 std::string이라도 컴파일러 버전이나 빌드 옵션에 따라 내부 메모리 레이아웃이 완전히 달라질 수 있다. 소스코드는 동일해도 바이너리는 서로 호환되지 않는 것이다.

---

💥 ABI mismatch가 발생하면

설치 OK
import OK
실행 → crash

👉 가장 디버깅 어려움

이게 ABI 문제의 가장 악질적인 특성이다. 설치도 되고, import도 되고, 심지어 간단한 연산까지는 잘 돌아간다. 하지만 특정 함수 호출 경로를 타는 순간 segfault가 터진다. 에러 메시지도 불친절하고, Python traceback으로는 원인을 추적할 수 없다.

---

🧨 실제 예 (C++ ABI)

C++ ABI 문제의 대표적인 사례를 하나 살펴보자. 아래와 같은 단순한 함수가 있다고 하자:

std::string foo();

이 함수를 컴파일할 때, GCC 5 이후로 도입된 _GLIBCXX_USE_CXX11_ABI 플래그에 따라 결과가 완전히 달라진다.

컴파일 옵션:

-D_GLIBCXX_USE_CXX11_ABI=0
vs
=1

결과:

_ZNSs...              (old ABI)
_ZNSt7__cxx11...      (new ABI)

👉 linker 입장:

“다른 함수”

같은 std::string foo()인데, mangled symbol이 완전히 다르다. 라이브러리 A는 old ABI로 빌드하고 라이브러리 B는 new ABI로 빌드했다면, 링킹 단계에서 “undefined symbol” 에러가 나거나, 운이 나쁘면 링킹은 성공하되 런타임에 메모리 레이아웃 불일치로 segfault가 발생한다.

---

🏗️ Why conda-forge Works

그렇다면 conda-forge는 이 문제를 어떻게 해결할까? 크게 네 가지 메커니즘이 있다.

1. Unified Toolchain

flowchart TD
    A[gcc] --> B[All packages]
    B --> C[Same ABI]

👉 모든 패키지가 동일 compiler로 빌드

conda-forge는 자체적으로 관리하는 compiler toolchain을 사용해서 모든 패키지를 빌드한다. 예를 들어, conda-forge에서 빌드되는 모든 C++ 패키지는 같은 버전의 GCC와 같은 _GLIBCXX_USE_CXX11_ABI 설정을 사용한다. 이것만으로도 ABI mismatch의 대부분이 원천 차단된다.

---

2. Global Pinning

numpy = 1.26
python = 3.10

👉 ecosystem 전체가 맞춰짐

conda-forge는 conda-forge-pinning이라는 중앙 설정 파일로 핵심 라이브러리의 버전을 ecosystem 전체에 걸쳐 통일한다. 특정 시점에 conda-forge에서 빌드되는 모든 패키지는 동일한 numpy 버전, 동일한 Python 버전에 맞춰진다. 개별 패키지 관리자가 제각각 버전을 선택하는 것이 아니라, 생태계 전체가 하나의 버전 세트를 공유하는 것이다.

---

3. Mass Rebuild

flowchart TD
    A[numpy update] --> B[scipy rebuild]
    B --> C[pytorch rebuild]

👉 ABI propagation 해결

핵심 라이브러리(예: numpy, Python)의 버전이 올라가면, 그에 의존하는 수천 개의 패키지를 일괄 리빌드(mass rebuild) 한다. 이 과정을 통해 ABI 변경이 생태계 전체에 균일하게 전파되어, “A는 새 버전인데 B는 아직 옛 버전”이라는 불일치가 발생하지 않는다.

---

4. run_exports

run_exports:
  - libpng

👉 dependency 자동 전파

run_exports는 conda-forge의 레시피 메커니즘으로, 빌드 타임 의존성이 런타임에도 필요하다는 것을 자동으로 선언한다. 예를 들어 libpng을 빌드 시 사용했다면, 해당 패키지를 설치할 때 호환되는 libpng이 자동으로 런타임 의존성에 추가된다. 이를 통해 “빌드할 때 쓴 라이브러리”와 “실행할 때 로드되는 라이브러리”의 버전 불일치를 방지한다.

---

🔗 Linker Level Deep Dive

한 단계 더 깊이 들어가보자. 실제로 바이너리가 로드될 때 어떤 일이 일어나는지 살펴본다.

문제 상황

ldd 명령어로 바이너리의 공유 라이브러리 의존성을 확인해보면, 일부는 conda 환경 내부에서, 일부는 시스템에서 로드되는 것을 볼 수 있다.

ldd binary

libstdc++ → conda
libc → system

👉 문제:

ABI mismatch

conda 환경 안의 libstdc++와 시스템의 libc가 서로 다른 ABI를 기대하는 상황이 발생할 수 있다. 이런 혼합 로딩은 특히 CUDA나 MKL 같은 무거운 네이티브 라이브러리를 사용할 때 빈번하게 문제를 일으킨다.

---

해결: RPATH

flowchart TD
    A[Binary] --> B[$ORIGIN]
    B --> C[conda libs]

👉 conda 내부 라이브러리 우선 사용

conda-forge에서 빌드된 패키지들은 RPATH(Runtime Library Search Path)를 $ORIGIN 기반으로 설정한다. 이렇게 하면 바이너리 실행 시 시스템 라이브러리 대신 conda 환경 내부의 라이브러리를 우선적으로 로드하게 되어, 시스템 라이브러리와의 충돌을 피할 수 있다.

---

⚠️ defaults에서 깨지는 이유

반면 defaults 채널에서는 이런 일이 생길 수 있다:

flowchart TD
    A[Package A] --> B[gcc 9]
    C[Package B] --> D[gcc 11]
    B --> E[ABI mismatch]
    D --> E

👉 toolchain 불일치

Package A는 gcc 9로, Package B는 gcc 11로 빌드되면, 각각은 잘 동작하지만 같은 환경에 함께 설치하는 순간 ABI가 충돌한다. defaults 채널에서는 패키지별 빌드 환경이 통일되지 않기 때문에 이런 상황이 발생할 여지가 conda-forge보다 훨씬 크다.

---

🧨 Real-world Failure

실제로 가장 흔하게 마주치는 시나리오 하나를 보자:

conda install pytorch -c pytorch
conda install scipy

첫 번째 명령은 PyTorch 공식 채널에서, 두 번째는 defaults 채널에서 패키지를 가져온다. 이 두 채널의 패키지는 서로 다른 toolchain으로 빌드되었을 가능성이 높다.

결과:

• OpenMP 충돌
• libstdc++ mismatch
• segfault

특히 OpenMP 관련 충돌이 악명 높다. PyTorch는 자체 OpenMP를 번들하는 경우가 많고, scipy나 numpy가 사용하는 OpenMP와 심볼이 겹치면서 런타임에 예측 불가능한 동작을 일으킨다.

---

🤖 Robotics / RL에서 더 중요한 이유

로보틱스나 강화학습 분야에서는 이 문제가 특히 치명적이다. 일반적인 데이터 분석과 달리, 이 분야의 소프트웨어 스택은 여러 계층의 네이티브 코드를 거쳐야 한다.

flowchart TD
    A[Python] --> B[C++]
    B --> C[CUDA]
    C --> D[GPU runtime]

👉 복잡도 ↑

Python에서 시작해 C++ 바인딩을 거치고, CUDA 커널을 호출하고, GPU 런타임까지 내려가는 이 긴 체인에서, 어느 한 지점이라도 ABI가 맞지 않으면 전체가 무너진다.

👉 ABI 깨지면:

• simulation crash
• NaN
• 학습 실패

특히 NaN이 조용히 퍼지는 경우가 가장 위험하다. crash는 그나마 발견이 되지만, ABI 불일치로 인한 미묘한 수치 오류는 학습이 한참 진행된 후에야 발견되기도 한다.

---

✅ Best Practice

Miniforge를 설치한 후, 아래 설정으로 conda-forge를 기본 채널로 고정하는 것을 권장한다.

conda config --add channels conda-forge
conda config --set channel_priority strict

channel_priority strict은 conda-forge에 있는 패키지가 있으면 무조건 거기서 가져오도록 강제한다. 이렇게 하면 채널 간 혼합으로 인한 ABI 문제를 원천 차단할 수 있다.

환경 생성 시에는 mamba를 활용하면 의존성 해결이 훨씬 빠르다.

mamba create -n rl python=3.10

---

🛠️ Installation (Ubuntu 24.04)

1. 다운로드

curl -L -O "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"

👉 공식 installer 방식 (Ask Ubuntu)

uname과 uname -m을 사용해 현재 OS와 아키텍처에 맞는 installer를 자동으로 선택한다. ARM(aarch64) 환경에서도 동일한 명령어로 설치할 수 있다.

---

2. 설치

bash Miniforge3-$(uname)-$(uname -m).sh

설치 과정에서 라이선스 동의, 설치 경로 지정 등의 질문이 나온다.

• conda init → YES (NETL Multiphase Flow Science)

conda init을 YES로 선택하면 셸 설정 파일(.bashrc 등)에 conda 초기화 스크립트가 자동으로 추가되어, 터미널을 열 때마다 conda가 활성화된다.

---

3. 적용

source ~/.bashrc

설치 직후에는 셸을 재시작하거나 위 명령어로 설정을 반영해야 conda 명령어를 사용할 수 있다.

---

4. 확인

conda --version
mamba --version

두 명령어 모두 버전이 출력되면 설치가 정상적으로 완료된 것이다.

---

⚠️ Notes

• Mambaforge deprecated (2024 이후) (GitHub)
• Miniforge 권장

과거에는 mamba를 사용하기 위해 별도의 Mambaforge를 설치해야 했지만, 2024년부터 Miniforge에 mamba가 기본 포함되면서 Mambaforge는 더 이상 유지되지 않는다. 신규 설치 시에는 반드시 Miniforge를 사용하자.

---

🧾 Final Takeaway

이 글의 핵심:

Miniforge는 단순한 installer가 아니라 ABI가 통제된 binary ecosystem이다

conda-forge의 unified toolchain, global pinning, mass rebuild, run_exports 메커니즘이 결합되어, 수천 개의 패키지가 하나의 일관된 바이너리 환경을 이루게 된다. 이것이 “그냥 잘 되는” 환경의 비밀이다.

---

📌 Final Recommendation

Miniforge + conda-forge + mamba

이 세 가지 조합이면 대부분의 Python 과학 계산, 딥러닝, 로보틱스 환경을 안정적으로 구축할 수 있다.

---

💬 Closing

conda에서 겪는 이상한 문제들은 대부분:

👉 코드 문제가 아니라 👉 ABI 문제다

그리고 그 문제는:

Miniforge로 대부분 해결된다

다음에 conda 환경에서 원인 모를 crash를 만나면, 패키지를 의심하기 전에 먼저 어떤 채널에서 설치했는지를 확인해보자.

Reference

• https://mamba.readthedocs.io/en/latest/installation/mamba-installation.html#fresh-install-recommended