BioPlayground

🧬
목록으로

Conda solver를 30분 기다렸다면 이 편을 읽자: Pixi·uv·Mamba가 바꾼 실무 환경 관리

왜 Conda solver가 30분 멈추는가. Mamba·Pixi·uv가 이걸 어떻게 초 단위로 만들었나. bwa·samtools·scanpy가 한 파일에 담기는 Pixi.toml 실전 예제까지.

중급
|
18분
|
검증 완료 (2026-07-19)
PixiuvMambaBiocondareproducibility
진행률0/5 (0%)

이 편은 대학이 안 가르치는 편이다

BPD의 통합 인사이트에서 "학계 ↔ 산업 chasm(간극)"이라고 불렀던 그 지점이다. MIT · Harvard · Stanford 어디에도 "환경 관리 도구 3편"이라는 정규 강의는 없다. 왜? 이건 알고리즘도, 통계도, 생물학도 아니다. 그런데 실무 인포매티션의 하루 중 절반이 여기서 결정된다.

Conda가 새 라이브러리 하나 설치하려고 30분간 solver를 돌리고 있을 때, 아무 코드도 안 짠다. 슬랙에 "설치 중이라 미팅 5분 늦어요"를 쓴다. 이 편은 그 30분을 30초로 만든다. 훈선생 표현대로 "커피 몇 잔"의 문제다.

편이지만 논문이 아니다. 손을 움직여 자기 랩탑에 지금 설치하는 편이다.

Conda가 왜 그렇게 느린가

Conda의 solver는 각 패키지가 요구하는 의존성 제약을 만족하는 완전한 조합을 찾는다. 이게 CS에서 잘 알려진 SAT(Satisfiability) 문제의 사촌이다. Bioconda 채널만 해도 8,000개+ 패키지, 각 패키지 3~10개 버전, 각 버전마다 여러 파이썬 버전 · CUDA 버전 · OS 호환 제약. 조합 공간이 지수적으로 폭발한다.

Conda의 오리지널 solver는 파이썬으로 짜여 있어, 이 조합 공간을 순차 순회한다. Bioconda에서 흔한 "circular dependency" 상황에 걸리면 백트래킹이 폭발한다. 이게 30분 대기의 원흉이다.

진화 계보 — Rust가 들어오다

2020: Mamba (QuantStack) — Conda의 solver 알고리즘을 그대로 두고, C++로 재구현. 10배 빨라짐. 하지만 여전히 근본은 Conda.

2022: micromamba — Mamba를 단일 실행 파일로. Docker 이미지 안에 넣기 쉬워짐. 인프라 재현성 첫 걸음.

2023: Pixi (prefix.dev) — 완전히 다른 철학. Conda 채널과 PyPI를 통합. Rust로 처음부터 재작성. pixi.toml 프로젝트 파일에 모든 걸 담고 로컬 캐싱. Cargo(Rust) · npm(Node) · Poetry(Python)의 경험을 바이오에 이식.

2024: uv (Astral) — Python 전용이지만 극도로 빠름. pip 대비 10~100배. Rust. Pixi가 uv를 내부에서 사용해 파이썬 부분을 처리하기도 함.

핵심 원리 세 가지:

  1. Rust 병렬 비동기 다운로드 — 수십 개 tarball을 동시에 fetch.
  2. 하드링크 캐싱 — 이미 받은 패키지를 재사용. 새 프로젝트를 만들어도 디스크 복사 없음.
  3. 결정적 잠금 파일 (lock file) — 정확한 버전 조합을 파일로 박제. 6개월 후 · 다른 팀원 · CI가 정확히 같은 환경을 재현.

Pixi.toml — 하나의 파일에 담기는 파이프라인 환경

이제 실전이다. SageMaker Studio Lab을 열자. 신용카드 없이 가입 가능(v3 통합 인사이트 §2-4 참조).

1단계: Pixi 설치

bash
# macOS · Linux 공통
curl -fsSL https://pixi.sh/install.sh | bash


# 셸 재시작 후
pixi --version

Windows는 iwr -useb https://pixi.sh/install.ps1 | iex.

2단계: 파이프라인 프로젝트 초기화

BPD 실습용 fake 프로젝트를 만들자. Salmon으로 유사 정렬, Scanpy로 단일세포 후처리, 두 도구가 한 환경에서 돌아가야 한다.

bash
mkdir bpd-pipeline
cd bpd-pipeline
pixi init

기본 pixi.toml이 생긴다. 이걸 우리가 원하는 대로 편집한다.

toml
[project]
name        = "bpd-pipeline"
version     = "2026.1.0"
description = "BPD S17~S21 실습용 FASTQ to Paper 파이프라인 환경"
channels    = ["conda-forge", "bioconda"]
platforms   = ["linux-64", "osx-arm64"]

[dependencies]
# 리눅스 도구
python   = ">=3.11"
samtools = ">=1.19"
salmon   = ">=1.10"
bwa      = ">=0.7.17"
star     = ">=2.7.11"

# 파이썬 데이터 도구
numpy    = ">=1.26"
pandas   = ">=2.2"
scanpy   = ">=1.10"

[pypi-dependencies]
# Bioconda에 없거나 최신이 PyPI에만 있는 것
anndata  = ">=0.10"
scvi-tools = ">=1.1"

[tasks]
run-salmon = "salmon quant -i index -1 R1.fq -2 R2.fq -o out"
run-qc     = "python scripts/qc.py"

3단계: 설치

bash
pixi install

첫 실행이 1030초. Conda로 같은 걸 하면 515분이다. 정확히 같은 목표에 대해 100배 이상의 격차.

4단계: 실행

bash
# 파이프라인 태스크 실행 (환경 자동 활성화)
pixi run run-qc


# 인터랙티브 셸 진입
pixi shell

pixi run이 자동으로 환경을 활성화한다. conda activate 잊고 헤매는 실수가 사라진다. 프로젝트 루트에 pixi.toml과 pixi.lock이 있으면 그 환경이 결정된다.

5단계: 팀원에게 넘기기

bash
# 팀원의 자기 컴퓨터에서
git clone <repo>
cd bpd-pipeline
pixi install   # pixi.lock을 읽고 정확히 같은 환경 재구성

pixi.lock이 정확한 버전 · 해시 · 채널을 기록하고 있어 1년 후에도 같은 환경이 나온다. 논문의 재현성(reproducibility)이 코드가 아닌 환경 수준에서 담보된다.

uv — 파이썬 전용의 극한 속도

Pixi가 Conda 채널(리눅스 도구 포함)까지 통합하는 것과 달리, uv는 순수 파이썬 프로젝트 전용이다. 그러나 pip 대비 10~100배 빠르다.

bash
# uv 설치
curl -LsSf https://astral.sh/uv/install.sh | sh


# 프로젝트 초기화
uv init my-analysis
cd my-analysis
uv add scanpy anndata numpy pandas
uv run python -c "import scanpy; print(scanpy.__version__)"

uv add가 몇 초 안에 끝난다. Pixi 내부에서도 파이썬 부분을 uv가 처리하기 때문에, 사실 우리는 이미 위에서 uv를 간접적으로 쓰고 있었다.

Pixi vs uv 언제 뭘 쓰나:

  • Bioconda의 리눅스 CLI 도구(bwa, samtools 등)가 필요 → Pixi
  • 순수 파이썬 프로젝트, PyPI만으로 완결 → uv
  • 팀 · CI에서 결정적 재현성 필수 → 둘 다 lock 파일 자동 생성

Mamba도 여전히 유효한가

Mamba (특히 micromamba)는 다음 경우에 여전히 유효하다.

  • 기존 Conda 프로젝트 유지보수: mamba install로 conda를 그대로 대체.
  • Docker 이미지 안에 단일 실행 파일 넣기: micromamba 하나면 conda 전체를 시뮬레이션.
  • CI/CD에서 conda 채널 필요: mamba가 여전히 표준 선택.

새 프로젝트를 시작한다면 Pixi가 우선. 레거시라면 Mamba로 전환. Pure Python이면 uv.

CS 매핑

  • SAT solver: 의존성 제약 만족 문제는 SAT의 일종. Pixi는 resolvo라는 Rust SAT solver를 채택.
  • 의존성 그래프 · 위상 정렬: 패키지 A가 B를 요구, B가 C를 요구 → DAG. 순환 의존 시 에러.
  • 하드링크 캐싱: 리눅스 파일시스템의 inode 공유. 새 프로젝트 생성 시 실제 데이터 복사가 아닌 참조.
  • 결정론적 잠금 파일: 함수형 프로그래밍의 순수 함수와 유사. 입력(.toml)이 같으면 출력(.lock)이 같음.

자주 만나는 결함

  • pip install을 pixi 프로젝트 안에서 실행 — lock 파일이 갱신 안 됨. 재현성 깨짐. 반드시 pixi add.
  • .gitignore에 pixi.lock 넣기 — 절대 X. lock은 반드시 커밋. .pixi/ 폴더가 gitignore 대상.
  • Bioconda 채널 우선순위 뒤바뀜 — channels의 순서가 우선순위. bioconda 먼저 · conda-forge 다음이 표준.
  • 플랫폼별 lock 미생성 — platforms = ["linux-64"]만 있으면 macOS에서 pixi install 실패. 필요한 플랫폼 모두 명시.
  • 컨테이너 안에서 GLIBC 미스매치 — Pixi 자체는 문제 없지만, 매우 오래된 Docker base 이미지(예: CentOS 7)에서는 glibc 버전 이슈. Ubuntu 22.04+ 권장.

다음 편으로 이어지는 갈래

  • F27~F28: Snakemake · Nextflow DSL2 — 파이프라인 오케스트레이션. 환경 관리 위에 얹는 실행 그래프.
  • F29: nf-core 표준 파이프라인 투어. rnaseq · sarek · scrnaseq 등 상용 검증된 것들.
  • F30: Docker · Apptainer/Singularity — 환경을 넘어 커널까지 격리. HPC에서 필수.
  • F31: HPC · Slurm — 대량 병렬 실행. 클라우드 온디맨드.

더 깊게 파고 싶다면

본 편은 대학 정규 강의가 부재하다. 참고 자료가 곧 도구 공식 문서다.

  • pixi.sh — Pixi 공식 문서. 튜토리얼이 잘 쓰여 있음.
  • docs.astral.sh/uv — uv 공식 문서.
  • mamba.readthedocs.io — Mamba/micromamba.
  • bioconda.github.io — Bioconda 채널 규약 · 패키지 등록법.
  • EMBL-EBI Training — Nextflow and Containers for Scalable Workflows (42분, 자막 완비). 다음 편 F28로 이어지는 다리.
  • Broad Institute — How to Run GATK4 in a Docker Container (40분, 자막 완비). F30 실습 준비.
  • 참고 블로그: Joseph Guhlin의 Pixi/uv: Bioinformatics Powerhouse (2024). 실무자 관점의 마이그레이션 경험담. Rust 진영이 왜 바이오를 삼키기 시작했는지 감이 온다.

여기서 30분 대기지옥에서 벗어난 다음, F27부터 실제 파이프라인 오케스트레이션의 세계로 진입하자. pixi.toml 하나에 이 편의 결과가 응축된다. 그걸 팀에 공유하면 그 팀의 재현성 문제가 반쯤 해결된다.