Snakemake 재현 파이프라인 — rule·wildcard·DAG로 NGS 워크플로 자동화

TL;DR — Snakemake는 파이썬 기반 워크플로 관리자로, FastQC·fastp·정렬·samtools처럼 손으로 순서대로 돌리던 NGS 도구들을 하나의 Snakefile에 규칙(rule)으로 적어 자동·재현 가능하게 엮습니다. 규칙은 입력(input)→출력(output)→명령(shell)의 세 칸으로 정의하고, 파일 이름의 {sample} 같은 와일드카드(wildcard)로 여러 샘플에 같은 규칙을 일반화합니다.

Snakemake는 규칙들의 입출력을 훑어 의존성 그래프(DAG)를 스스로 그리고, 이 그래프대로 실행합니다. 그래서 snakemake -n으로 무엇이 돌지 미리 보고(dry-run), snakemake --dag | dot -Tsvg로 그래프를 그림으로 뽑을 수 있죠. 파일 타임스탬프를 비교해 바뀐 것만 다시 돌리는 증분 실행, --cores N으로 독립 작업을 동시에 돌리는 병렬화, conda·컨테이너로 도구 버전까지 고정하는 재현성이 핵심 강점입니다.

이 글은 애기장대(Arabidopsis thaliana) 공개 데이터를 예로, conda 설치부터 첫 규칙 작성·와일드카드·expand()·config.yaml·DAG 시각화·병렬 실행까지 한 줄씩 따라간 뒤, FASTQ → FastQC → fastp → 정렬 → samtools 정리를 하나의 Snakefile로 묶습니다. 명령은 Snakemake 8/9 기준입니다(현재 안정 버전 9.x).

🔗 관련 글  ·  이 글이 자동화하는 개별 도구들은 이미 따로 다뤘습니다 — 리드 품질검사·트리밍은 FastQC·fastp 편, 참조 정렬의 원리는 서열 정렬이란?, 정렬 결과 정리는 samtools·bcftools 편, 변이 호출은 GATK 편에서 이어집니다  ·  정렬을 우회하는 유사정렬 정량은 salmon으로 전사체 정량에서 다뤘습니다

이 글에서 만들 것

NGS 분석을 처음 손으로 돌려 보면 대체로 이런 식입니다. FastQC로 품질을 보고, fastp로 어댑터를 자르고, BWA나 STAR로 정렬하고, samtools로 BAM을 정렬·인덱싱하고… 샘플이 하나면 견딜 만한데, 12개·96개로 늘면 명령을 복사·붙여넣기 하다 어느 샘플에서 한 단계를 빠뜨렸는지도 헷갈립니다. 중간에 참조를 바꾸면 처음부터 다 다시 돌려야 하나 고민되고, 몇 달 뒤 "그때 그 결과 어떻게 냈더라"를 재현하기도 어렵죠.

Snakemake는 이 문제를 정면으로 풉니다. 각 단계를 규칙(rule)으로 한 번만 적어 두면, 어떤 샘플이든 같은 규칙이 알아서 적용되고(와일드카드), 도구 사이의 의존성은 Snakemake가 파일 이름을 보고 스스로 잇습니다. 바뀐 입력만 골라 다시 돌리고, 독립적인 샘플들은 병렬로 처리하며, Snakefile 하나가 곧 분석의 명세이자 재현 레시피가 됩니다.

이 글은 그 Snakemake를 처음부터 만듭니다. 구체적으로 ① conda로 Snakemake를 깔고, ② input→output→shell로 첫 규칙을 쓰고, ③ {sample} 와일드카드와 expand()로 여러 샘플에 일반화하고, ④ config.yaml로 경로·샘플 목록을 밖으로 빼고, ⑤ snakemake -n(dry-run)·--dag로 실행 계획을 확인하고, ⑥ --cores로 병렬 실행한 뒤, ⑦ FASTQ → FastQC → fastp → 정렬 → samtools를 하나로 묶은 실전 Snakefile을 완성합니다.

손으로 도구를 이어 붙이는 방식과 뭐가 다른지 한 줄로 보면 이렇습니다. 셸 스크립트는 "명령을 이 순서로 실행하라"는 명령형이지만, Snakemake는 "이 출력 파일을 만들려면 이 입력과 이 명령이 필요하다"는 선언형입니다. 무엇을 만들지만 적으면 순서·의존성·재실행 판단은 Snakemake가 알아서 하죠.

# 핵심 흐름 한눈에
snakemake -n                              # ① dry-run — 무엇이 실행될지 미리 확인
snakemake --dag | dot -Tsvg > dag.svg     # ② 의존성 그래프(DAG)를 그림으로
snakemake --cores 8                       # ③ 실제 실행 (8코어 병렬, 바뀐 것만)

그림 1. rule의 세 칸(input·output·shell)과 와일드카드 — 출력 파일 이름에서 {sample} 값을 정하고, 그 값을 입력·명령에 그대로 채운다.

1. 사전 준비 — 설치와 예제 데이터

Snakemake는 파이썬 패키지라 conda (권장) 또는 pip로 설치합니다. bioconda 채널의 conda를 쓰면 뒤에서 규칙별 conda 환경을 자동으로 만들어 주는 기능까지 매끄럽게 이어져, 여기서는 conda로 통일합니다.

# conda (bioconda) — 권장, 전용 환경에 격리 설치
conda create -n smk -c conda-forge -c bioconda snakemake
conda activate smk

# 설치 확인 (버전 출력)
snakemake --version

9.5.1

실습용 도구와 데이터도 같은 환경에 준비합니다. 이 글의 실전 예제(FastQC·fastp·BWA·samtools)를 그대로 돌리려면 도구들이 있어야 하지만, 개념을 익히는 앞 절들은 도구 없이도 따라올 수 있게 구성했습니다.

# 실전 파이프라인용 도구 (개념 학습만 할 거면 건너뛰어도 됨)
conda install -c bioconda fastqc fastp bwa samtools

작업 폴더 구조는 이렇게 잡습니다. 원시 리드는 data/에, 결과는 results/에 쌓고, 파이프라인 명세인 Snakefile과 설정 config.yaml을 폴더 맨 위에 둡니다.

project/
├── Snakefile          # 파이프라인 명세 (규칙 모음)
├── config.yaml        # 경로·샘플 목록 등 설정
├── data/
│   ├── sampleA.fastq.gz
│   └── sampleB.fastq.gz
└── results/           # 실행하면 여기에 결과가 쌓인다

2. 첫 규칙 — input → output → shell

Snakemake의 기본 단위는 규칙(rule)입니다. 규칙 하나가 "어떤 입력으로, 어떤 출력을, 어떤 명령으로 만드는가"를 적습니다. 가장 단순한 예로, FASTQ에 FastQC를 돌려 품질 리포트를 만드는 규칙을 봅시다. Snakefile이라는 이름의 파일에 다음을 적습니다.

# Snakefile — 규칙 하나: FASTQ → FastQC 리포트
rule fastqc:
    input:
        "data/sampleA.fastq.gz"          # 입력 파일
    output:
        "results/qc/sampleA_fastqc.html" # 만들 출력 파일
    shell:
        "fastqc {input} -o results/qc/"  # 실제 실행할 명령

세 칸의 뜻이 곧 Snakemake의 문법 전부에 가깝습니다. input:은 이 규칙이 필요로 하는 파일, output:은 이 규칙이 만들어 낼 파일, shell:은 실제로 돌릴 셸 명령입니다. 명령 안의 {input}·{output}은 위에 적은 경로로 자동 치환됩니다 — 경로를 두 번 적지 않아도 되죠. 규칙 이름(fastqc)은 사람이 알아보기 위한 라벨입니다.

이제 실행해 봅니다. Snakemake는 인자로 만들고 싶은 출력 파일을 받고, 그 파일을 만들 수 있는 규칙을 거꾸로 찾아 실행합니다.

# 원하는 출력 파일을 목표(target)로 지정해 실행
snakemake --cores 1 results/qc/sampleA_fastqc.html

Building DAG of jobs...
Job stats:
job       count
------    -----
fastqc    1
total     1

rule fastqc:
    input: data/sampleA.fastq.gz
    output: results/qc/sampleA_fastqc.html
Finished job 0.
1 of 1 steps (100%) done

여기서 두 가지가 중요합니다. 첫째, --cores(또는 -c)는 Snakemake 8부터 반드시 지정해야 하는 옵션입니다. 몇 개의 코어를 써도 되는지 알려 주지 않으면 실행을 거부하죠(예전 5~7.x에서는 생략 시 1코어였지만, 8부터는 명시가 필수입니다). 둘째, 목표 파일이 이미 최신 상태면 Snakemake는 "Nothing to be done"이라며 다시 돌리지 않습니다 — 이 판단이 뒤에서 볼 증분 실행의 핵심입니다.

shell 대신 파이썬 코드로 처리하고 싶으면 run:을, 파이썬 스크립트나 R 스크립트를 부르려면 script:를 쓸 수 있습니다. 명령이 길거나 옵션이 많으면 params:로 값을 빼두고, 스레드 수는 threads:, 로그는 log:로 관리합니다.

# 옵션을 갖춘 규칙: fastp 트리밍 (params·threads·log 활용)
rule fastp:
    input:
        "data/{sample}.fastq.gz"
    output:
        trimmed="results/trimmed/{sample}.fastq.gz",
        report="results/trimmed/{sample}.fastp.html"
    params:
        quality=20                       # 품질 컷오프 (params로 분리)
    threads: 4                           # 이 규칙이 쓸 스레드 수
    log:
        "logs/fastp/{sample}.log"        # 로그 파일
    shell:
        "fastp -i {input} -o {output.trimmed} "
        "-h {output.report} -q {params.quality} "
        "--thread {threads} 2> {log}"

출력이 여럿이면 이름을 붙여(trimmed=·report=) {output.trimmed}처럼 골라 쓸 수 있습니다. {params.quality}·{threads}·{log}도 같은 방식으로 명령 안에서 참조됩니다. 문자열을 여러 줄로 나눠 적으면 파이썬이 이어 붙이니, 긴 명령을 읽기 좋게 쪼갤 수 있죠.

3. 와일드카드와 expand() — 여러 샘플로 일반화

앞 규칙에 이미 답이 나와 있습니다. data/{sample}.fastq.gz의 {sample} — 이게 와일드카드(wildcard)입니다. 특정 샘플 이름을 박아 두는 대신 {sample}이라는 자리표시자를 쓰면, 하나의 규칙이 모든 샘플에 적용됩니다.

작동 방식이 꽤 영리한데, Snakemake는 출력 파일 이름에서 와일드카드 값을 거꾸로 알아냅니다. 예컨대 results/trimmed/sampleA.fastq.gz를 만들라는 요청이 오면, 출력 패턴 results/trimmed/{sample}.fastq.gz와 맞춰 {sample}=sampleA로 정하고, 그 값을 입력 패턴 data/{sample}.fastq.gz에도 그대로 채워 data/sampleA.fastq.gz를 입력으로 잡습니다. 즉 출력에서 입력으로 와일드카드가 전파되죠.

# 와일드카드 규칙: {sample} 하나로 모든 샘플 처리
rule fastqc:
    input:
        "data/{sample}.fastq.gz"
    output:
        "results/qc/{sample}_fastqc.html"
    shell:
        "fastqc {input} -o results/qc/"

이제 snakemake --cores 1 results/qc/sampleB_fastqc.html을 하면 같은 규칙이 sampleB에 적용됩니다. 그런데 샘플이 열 개면 목표 파일을 열 번 타이핑할까요? 그래서 expand()가 있습니다. 샘플 목록을 주면 파일 이름 리스트를 한 번에 펼쳐 줍니다.

# Snakefile 맨 위 — 샘플 목록과 최종 목표 정의
SAMPLES = ["sampleA", "sampleB", "sampleC"]

# 규칙 all: 최종적으로 원하는 파일들을 모아 두는 '목표 규칙'
rule all:
    input:
        expand("results/qc/{sample}_fastqc.html", sample=SAMPLES)

두 가지 관례가 여기 담겨 있습니다. 첫째, expand("....{sample}....", sample=SAMPLES)는 리스트의 각 값을 끼워 넣어 ["results/qc/sampleA_fastqc.html", ...]처럼 펼칩니다. 둘째, Snakefile의 맨 첫 규칙이 기본 목표(default target)가 됩니다. 관례상 아무것도 만들지 않고 input에 "최종 산출물"만 모아 두는 rule all을 맨 위에 두면, 그냥 snakemake --cores 8만 쳐도 all이 요구하는 모든 파일이 만들어집니다.

# 목표 파일 없이 실행 → 첫 규칙(all)이 기본 목표가 되어 전체 샘플 처리
snakemake --cores 8

4. config.yaml — 설정을 코드 밖으로

샘플 목록·참조 경로·파라미터를 Snakefile에 박아 두면, 프로젝트가 바뀔 때마다 코드를 고쳐야 합니다. 이런 값은 config.yaml로 빼는 게 관례입니다. YAML 파일에 설정을 적고, Snakefile에서 configfile:로 불러오면 config 딕셔너리로 접근할 수 있죠.

# config.yaml — 경로·샘플·파라미터 설정
samples:
  - sampleA
  - sampleB
  - sampleC
genome: "ref/TAIR10.fa"
fastp_quality: 20

# Snakefile — config.yaml 불러와 값 참조
configfile: "config.yaml"

rule all:
    input:
        expand("results/qc/{sample}_fastqc.html",
               sample=config["samples"])       # config에서 샘플 목록 가져오기

이제 샘플이 늘거나 참조가 바뀌어도 config.yaml만 고치면 됩니다. config["samples"]·config["genome"]·config["fastp_quality"]처럼 키로 값을 꺼내 규칙 곳곳에서 재사용하죠. 명령줄에서 --configfile other.yaml로 다른 설정을 바꿔 끼우거나, --config genome=ref/hg38.fa로 개별 값을 덮어쓸 수도 있습니다.

5. DAG·dry-run — 실행 계획을 미리 본다

규칙을 여럿 적으면 Snakemake는 어느 규칙의 출력이 어느 규칙의 입력인지를 파일 이름으로 이어, 방향성 비순환 그래프(DAG, directed acyclic graph)를 스스로 만듭니다. 이 그래프가 곧 실행 계획입니다 — 노드는 작업(job), 화살표는 의존 관계죠.

실제로 돌리기 전에 계획부터 확인하는 게 안전합니다. snakemake -n(또는 --dry-run)은 아무것도 실행하지 않고 무슨 작업이 어떤 순서로 돌지만 보여 줍니다. 오타·경로 실수·빠진 입력을 실행 전에 잡는 필수 습관이죠.

# dry-run — 실행하지 않고 계획만 출력
snakemake -n --cores 8

Building DAG of jobs...
Job stats:
job       count
------    -----
all       1
fastqc    3
fastp     3
total     7

This was a dry-run (flag -n). The order of jobs does not reflect the order of execution.

그래프를 눈으로 보고 싶으면 --dag로 DOT 형식을 뽑아 Graphviz의 dot으로 이미지를 만듭니다. 작업이 많아 복잡하면 규칙 수준으로만 요약하는 --rulegraph가 더 읽기 좋습니다.

# 작업 수준 DAG를 SVG 이미지로 (Graphviz 필요: conda install -c conda-forge graphviz)
snakemake --dag | dot -Tsvg > dag.svg

# 규칙 수준으로 간단히 (샘플이 많을 때 권장)
snakemake --rulegraph | dot -Tsvg > rulegraph.svg

그림 2. 자동 생성된 DAG — Snakemake는 규칙들의 output·input을 파일 이름으로 이어 실행 순서를 스스로 세운다(순서를 명시하지 않아도 됨).

6. 증분 실행·병렬화 — 바뀐 것만, 동시에

Snakemake가 손으로 돌리기보다 나은 결정적 이유 두 가지가 증분 실행과 병렬화입니다.

증분 실행은 기본적으로 Make식 타임스탬프 비교에서 출발합니다. 출력 파일이 이미 있고 그 입력보다 새것(타임스탬프가 더 최근)이면, 그 작업은 이미 끝난 것으로 보고 건너뜁니다. 반대로 입력을 고치거나(더 최근이 됨) 출력을 지우면, 그 작업과 그 뒤에 딸린 작업들만 다시 돌죠. 그래서 100개 샘플 중 3개 리드만 교체하면, 그 3개 계보만 다시 흐릅니다 — 나머지 97개는 그대로 두고요.

다만 요즘 Snakemake는 타임스탬프 하나만 보지 않는다는 점이 Make와 다릅니다. 기본값으로 다섯 가지 방아쇠(trigger) — 파일 수정 시각(mtime)·입력 집합(input)·params 값·규칙 코드(code)·소프트웨어 환경(software-env) — 중 무엇이라도 바뀌면 재실행합니다. 그래서 입력 타임스탬프가 그대로여도 규칙의 shell 명령이나 params를 고치면 다시 돕니다. Make만 써 본 사람이 흔히 놀라는 지점인데, 결과가 항상 코드·설정과 일치하도록 보장하려는 설계죠. 순수하게 옛 Make처럼 타임스탬프만 보게 하려면 --rerun-triggers mtime을 줍니다.

# sampleB의 입력만 새로 바뀐 상황 → 그 계보만 재실행
snakemake --cores 8

Building DAG of jobs...
Job stats:
job       count
------    -----
fastp     1
total     1

# sampleB만 다시 돌고, sampleA·sampleC는 최신이라 건너뜀

병렬화는 --cores N(또는 -c N, -j N) 한 방입니다. Snakemake는 DAG에서 서로 의존하지 않는 작업을 골라 동시에 돌립니다. 코어 8개를 주면 독립적인 샘플들의 FastQC를 한꺼번에 처리하죠. 규칙에 threads:를 준 경우엔 그 값과 --cores를 함께 저울질해 배분합니다.

# 8코어로 병렬 실행 — 독립 작업을 동시에
snakemake --cores 8

강제로 전부 다시 돌리고 싶으면 --forceall(또는 -F), 특정 규칙만 다시 돌리려면 --forcerun 규칙이름을 씁니다.

7. 실전 — FASTQ→QC→트리밍→정렬→정리 한 파일로

이제 앞 조각들을 모아 실전 파이프라인을 만듭니다. FASTQ에서 시작해 FastQC·fastp 품질검사·트리밍, BWA-MEM 정렬, samtools 정렬·인덱싱까지 다섯 단계를 하나의 Snakefile로 묶습니다. 각 단계는 규칙 하나이고, 앞 규칙의 출력이 뒤 규칙의 입력으로 자연히 이어집니다. 각 도구의 옵션·개념은 앞선 글들에서 다뤘으니, 여기서는 그것들을 어떻게 자동으로 엮는지에 집중합니다.

# Snakefile — FASTQ → QC → 트리밍 → 정렬 → BAM 정렬·인덱싱
configfile: "config.yaml"

# 최종 목표: 모든 샘플의 정렬·인덱싱된 BAM과 QC 리포트
rule all:
    input:
        expand("results/sorted/{sample}.bam.bai", sample=config["samples"]),
        expand("results/qc/{sample}_fastqc.html", sample=config["samples"])

# 1) FastQC — 원시 리드 품질검사
rule fastqc:
    input:
        "data/{sample}.fastq.gz"
    output:
        "results/qc/{sample}_fastqc.html"
    shell:
        "fastqc {input} -o results/qc/"

# 2) fastp — 어댑터·저품질 염기 트리밍
rule fastp:
    input:
        "data/{sample}.fastq.gz"
    output:
        "results/trimmed/{sample}.fastq.gz"
    threads: 4
    log:
        "logs/fastp/{sample}.log"
    shell:
        "fastp -i {input} -o {output} --thread {threads} 2> {log}"

# 3) BWA-MEM — 트리밍된 리드를 참조에 정렬 → BAM
#    (미리 bwa index {genome} 로 참조 색인이 만들어져 있어야 함)
rule bwa_map:
    input:
        reads="results/trimmed/{sample}.fastq.gz",
        ref=config["genome"]
    output:
        "results/mapped/{sample}.bam"
    threads: 8
    shell:
        "bwa mem -t {threads} {input.ref} {input.reads} "
        "| samtools view -b - > {output}"

# 4) samtools sort — 좌표순 정렬
rule samtools_sort:
    input:
        "results/mapped/{sample}.bam"
    output:
        "results/sorted/{sample}.bam"
    threads: 4
    shell:
        # -T: 임시파일 접두어 (파일 목록이 아니라 접두어라 {wildcards.sample} 사용)
        "samtools sort -@ {threads} -T results/sorted/{wildcards.sample} "
        "{input} -o {output}"

# 5) samtools index — BAM 인덱싱(.bai)
rule samtools_index:
    input:
        "results/sorted/{sample}.bam"
    output:
        "results/sorted/{sample}.bam.bai"
    shell:
        "samtools index {input}"

이 한 파일이 파이프라인 전부입니다. snakemake -n --cores 8로 계획을 확인하고, 문제없으면 snakemake --cores 8로 돌리면 됩니다. Snakemake는 rule all이 요구하는 .bam.bai를 만들려면 정렬된 BAM이, 그러려면 매핑된 BAM이, 그러려면 트리밍된 리드가 필요하다는 걸 파일 이름만으로 역추적해 fastp→bwa_map→samtools_sort→samtools_index 순서를 스스로 세웁니다. 순서를 어디에도 명시하지 않았는데도요.

재현성을 한 단계 더 올리려면 규칙마다 conda:로 도구 환경을 고정합니다. 규칙에 환경 YAML을 물리고 --software-deployment-method conda(짧게 --sdm conda)로 실행하면, Snakemake가 규칙별로 그 환경을 만들어 그 안에서 명령을 돌립니다. 도구 버전까지 파이프라인에 박히니, 몇 달 뒤 다른 컴퓨터에서도 같은 결과가 재현되죠.

# 규칙에 conda 환경 지정 (envs/fastp.yaml에 fastp 버전 명시)
rule fastp:
    input:  "data/{sample}.fastq.gz"
    output: "results/trimmed/{sample}.fastq.gz"
    conda:  "envs/fastp.yaml"
    shell:  "fastp -i {input} -o {output}"

# 규칙별 conda 환경을 자동 생성·사용해 실행 (재현성↑)
snakemake --cores 8 --software-deployment-method conda

그림 3. 손 실행 vs Snakemake — 바뀐 입력의 계보만 다시 돌리는 증분 실행(재계산 최소화)과, 서로 의존하지 않는 작업을 코어 수만큼 병렬로 처리.

8. 자주 발생하는 에러 & 해결

• --cores를 안 줘서 실행 거부 — Snakemake 8부터는 코어 수를 반드시 지정해야 합니다. 그냥 snakemake만 치면 실행을 멈추고 코어를 명시하라고 요구하죠. snakemake --cores 8(또는 전부 쓰려면 --cores all)처럼 항상 코어 수를 붙이세요.
• MissingInputException — 입력 파일이 없음 — Snakemake가 목표를 만들려면 어떤 입력이 필요한데 그 파일도, 그걸 만들 규칙도 없을 때 납니다. 대개 경로 오타이거나(data/ vs data), 파일 이름 규칙이 실제 파일과 안 맞는 경우입니다. 메시지에 어떤 파일을 찾다 실패했는지 나오니, 그 경로가 실제로 존재하는지·와일드카드 패턴과 맞는지 확인합니다(경로의 ~는 확장되지 않으니 작업 폴더 기준 상대경로를 쓰세요).
• AmbiguousRuleException — 규칙이 겹침 — 같은 출력 파일을 만들 수 있는 규칙이 둘 이상이면, Snakemake가 어느 것을 쓸지 몰라 멈춥니다. 출력 패턴이 서로 겹치지 않게 하거나, ruleorder: 규칙A > 규칙B로 우선순위를 정해 해결합니다.
• 와일드카드가 예상과 다르게 잡힘 — {sample}은 기본적으로 /를 포함해 욕심껏(greedy) 매칭하므로, 경로가 복잡하면 엉뚱하게 잡힐 수 있습니다. wildcard_constraints로 정규식을 걸어(예 sample="[A-Za-z0-9]+") 매칭 범위를 좁히면 안전합니다.
• 중간 파일이 자꾸 지워지거나 남음 — 용량 큰 중간 산출물은 temp("...")로 감싸면, 그걸 쓰는 뒷 작업이 끝난 뒤 Snakemake가 자동으로 지웁니다. 반대로 실수로 덮어쓰면 안 되는 최종 결과는 protected("...")로 감싸 쓰기 방지를 걸 수 있죠.

9. 확장 — 더 해 볼 것

• 모듈화(include·rules/) — 규칙이 많아지면 Snakefile 하나가 길어집니다. 규칙을 주제별 .smk 파일로 나눠 include: "rules/mapping.smk"로 불러오면 관리가 쉬워집니다.
• --use-conda에서 --software-deployment-method로 (버전 주의) — 재현 환경을 붙이는 플래그가 Snakemake 8에서 이름이 바뀌었습니다. 예전 --use-conda·--use-singularity는 8부터 --software-deployment-method conda·apptainer(짧게 --sdm)로 통합됐죠(옛 --use-conda도 당분간 별칭으로 동작하지만 권장되지 않습니다). 인터넷의 오래된 튜토리얼은 --use-conda를 쓰니, 버전에 맞는 플래그를 확인하세요.
• 컨테이너로 완전 재현(container:) — conda보다 더 강하게 고정하려면 규칙에 container: "docker://..."로 도커·Apptainer 이미지를 물려, OS 라이브러리까지 통째로 담습니다. --sdm apptainer로 실행하면 그 이미지 안에서 명령이 돕니다.
• 클러스터·클라우드 실행 — Snakemake 8부터 실행 백엔드를 플러그인으로 분리했습니다. 예전 --cluster "sbatch ..."·--kubernetes 대신, snakemake-executor-plugin-slurm 같은 플러그인을 깔고 --executor slurm으로 같은 Snakefile을 SLURM 클러스터나 클라우드에 그대로 던져 대규모로 돌릴 수 있죠. 로컬에서 검증한 파이프라인을 코드 수정 없이 확장하는 게 핵심입니다.
• 리포트 자동 생성(--report) — 실행이 끝난 뒤 snakemake --report report.html을 하면, 결과·통계·DAG·각 작업의 로그를 담은 HTML 리포트를 자동으로 만듭니다. 협업이나 재현 근거 남기기에 유용합니다.
• 다른 워크플로 관리자와 비교 — 같은 결의 도구로 Nextflow (그루비 기반, nf-core 생태계가 강함)·WDL (Cromwell, 브로드연구소 표준)이 있습니다. Snakemake는 파이썬 친화적이고 Make식 파일 기반 의존성이 직관적이라, 파이썬에 익숙한 연구자가 개인·중소 규모 파이프라인을 빠르게 세우기에 특히 잘 맞습니다.

다음 학습

🎓 이어서 읽기
• (파이프라인 1단계) FastQC·fastp로 리드 품질검사·트리밍 — Snakemake가 첫 규칙으로 감싼 QC 단계
• (정렬 원리) 서열 정렬이란? — BWA·MAPQ, 리드를 유전체에 맞추는 법
• (정렬 결과 정리) samtools·bcftools 실전 — BAM 정렬·인덱싱·flagstat과 변이 필터링
• (변이 호출) GATK으로 변이 호출하기 — BAM에서 VCF까지, best practices
• (정렬 우회 정량) salmon으로 전사체 정량 — 유사정렬로 RNA-seq를 바로 카운트

References

1. Mölder, F., Jablonski, K. P., Letcher, B., Hall, M. B., Tomkins-Tinch, C. H., Sochat, V., ... & Köster, J. (2021). Sustainable data analysis with Snakemake. F1000Research, 10, 33. (Snakemake 방법론·재현성)
2. Köster, J., & Rahmann, S. (2012). Snakemake — a scalable bioinformatics workflow engine. Bioinformatics, 28(19), 2520–2522. (Snakemake 원논문)
3. Snakemake developers. (2026). Snakemake documentation — rules · wildcards · configuration · deployment · CLI. snakemake.readthedocs.io
4. Snakemake developers. (2026). Migrating to Snakemake 8 (software-deployment-method · executor plugins). 7→8 migration guide

Pipette & Pipeline · A bio portfolio journal