Nextflow DSL2 완벽 이해 — 채널 기반 데이터 흐름 파이프라인

F27에서 한 걸음 더 — 파일 관계에서 데이터 흐름으로

F27의 Snakemake는 파일의 입력·출력 이름 패턴으로 파이프라인 순서를 추론했습니다. 이 방식은 강력하지만, 샘플이 수백～수천 개로 늘어나고 클러스터·클라우드에 분산 실행해야 하는 대규모 프로젝트에서는 파일 시스템 의존성 자체가 병목이 될 수 있습니다. Nextflow(2013~, Seqera·EMBL-EBI)의 DSL2는 관점을 바꿉니다 — 파일이 아니라, 데이터가 프로세스 사이를 흐르는 **채널(channel)**을 1급 객체로 설계합니다.

원리 — 채널과 프로세스로 구성하는 데이터플로우

process — 독립적인 계산 단위

Nextflow의 process는 Snakemake의 rule과 비슷하게 하나의 계산 단위를 정의하지만, 입출력을 파일 시스템 경로가 아니라 채널을 통해 주고받습니다.

groovy

// main.nf 예시 (DSL2)
process ALIGN {
    input:
    tuple val(sample_id), path(r1), path(r2)
    path ref

    output:
    tuple val(sample_id), path("${sample_id}.bam")

    script:
    """
    bwa mem ${ref} ${r1} ${r2} | samtools sort -o ${sample_id}.bam
    """
}

process MARK_DUPLICATES {
    input:
    tuple val(sample_id), path(bam)

    output:
    tuple val(sample_id), path("${sample_id}.dedup.bam")

    script:
    """
    gatk MarkDuplicates -I ${bam} -O ${sample_id}.dedup.bam -M metrics.txt
    """
}

workflow {
    reads_ch = Channel.fromFilePairs("reads/*_R{1,2}.fastq.gz")
    // 여러 reads에 같은 reference를 재사용하려면 queue channel이 아닌 value를 넘깁니다.
    ref = file("ref/genome.fa")

    ALIGN(reads_ch, ref)
    MARK_DUPLICATES(ALIGN.out)
}

채널 — 비동기 데이터 스트림

채널은 파일 경로, 값, 또는 튜플을 담아 프로세스 사이로 흘려보내는 **비동기 큐(asynchronous queue)**입니다. 한 프로세스가 결과를 채널에 내보내면, 그 채널을 입력으로 받는 다음 프로세스는 데이터가 도착하는 즉시(반드시 전체 배치가 끝나기를 기다리지 않고) 실행을 시작할 수 있습니다.

$\text{Snakemake}: \text{파일 존재} \to \text{규칙 트리거} \qquad \text{Nextflow}: \text{채널에 데이터 도착} \to \text{프로세스 인스턴스 생성}$

샘플 100개를 처리한다면, Nextflow는 각 샘플이 채널에 도착하는 대로 독립적인 프로세스 인스턴스를 만들어 실행합니다. 이는 명시적으로 "100개를 반복하라"는 반복문을 쓰지 않고도 자연스럽게 샘플 단위 병렬화를 얻는 방식입니다.

손 계산 예제: 채널 병렬성과 대기 시간

100개 샘플이 각기 다른 시점(전송 속도 차이 등)에 입력 채널에 도착한다고 합시다. 정렬(ALIGN) 프로세스 하나가 평균 10분 걸리고, 동시에 최대 20개까지 병렬 실행 가능한 클러스터라면, 전체 처리 시간은 대략

$\left\lceil \frac{100}{20} \right\rceil \times 10\text{분} = 5 \times 10 = 50\text{분}$

만약 순차 실행(직렬)이었다면

$100 \times 10\text{분} = 1{,}000\text{분} \approx 16.7\text{시간}$

채널 기반 데이터플로우가 자연스럽게 부여하는 병렬성 덕분에, 별도의 병렬화 로직을 직접 짜지 않고도 약 20배의 처리 속도 향상을 얻습니다. 물론 실제 이득은 클러스터의 가용 자원과 각 단계의 I/O 병목에 따라 달라집니다.

DSL1과 DSL2의 차이 — 모듈화

초기 Nextflow(DSL1)는 전체 파이프라인을 하나의 스크립트에 절차적으로 기술했습니다. DSL2는 process를 재사용 가능한 **모듈(module)**로 분리하고, workflow 블록에서 이 모듈들을 조합하는 구조를 도입했습니다. 이 모듈화가 F29에서 다룰 nf-core 생태계(수백 개 파이프라인이 공통 모듈을 재사용하는 구조)를 가능하게 한 전제 조건입니다.

실습: 파일 쌍 채널 구성하고 dry-run으로 확인하기

bash

# SageMaker Studio Lab. Nextflow는 자바 런타임 위에서 동작합니다.
curl -s https://get.nextflow.io | bash
./nextflow -v

# -preview 옵션으로 실제 실행 없이 워크플로우 구조만 확인합니다.
./nextflow run main.nf -preview

# 실제 실행. -resume은 F27의 Snakemake 재실행 최적화와 동일한 발상으로,
# 캐시된 이전 실행 결과를 재사용해 실패 지점부터 이어갑니다.
./nextflow run main.nf -resume

-resume 플래그는 각 프로세스 실행의 해시값을 캐시해두고, 입력이 바뀌지 않은 프로세스는 재실행을 건너뜁니다. F27에서 다룬 Snakemake의 타임스탬프 기반 재실행 최적화와 목적은 같지만, 구현은 콘텐츠 해시 기반이라는 차이가 있습니다.

CS 매핑

데이터플로우 프로그래밍(dataflow programming): 계산을 노드(process)와 그 사이를 흐르는 데이터(channel)로 표현하는 것은 데이터플로우 프로그래밍 패러다임의 정의 그 자체입니다.
리액티브 스트림(reactive streams): 채널에 데이터가 도착하는 대로 다음 단계가 반응해 실행되는 방식은 RxJava·RxJS 같은 리액티브 프로그래밍 라이브러리의 Observable 패턴과 동일한 논리입니다.
콘텐츠 기반 캐싱: -resume의 해시 기반 재사용은 소프트웨어 빌드 시스템(Bazel 등)에서 입력 콘텐츠 해시로 빌드 캐시 히트를 판단하는 전략과 같은 계보입니다.

자주 만나는 결함

DSL1 문법과 DSL2 문법 혼용: 오래된 튜토리얼이나 예제가 DSL1 문법으로 작성된 경우가 많아, 최신 DSL2 프로젝트에 그대로 붙여넣으면 오류가 납니다. Nextflow 버전과 nextflow.enable.dsl=2 설정을 항상 확인해야 합니다.
여러 queue channel을 process 입력에 함께 넘김: 여러 queue channel은 값이 도착하는 순서에 따라 비결정적으로 짝지어질 수 있습니다. process에 여러 입력이 필요하면 하나만 queue channel로 두고, 공통 reference·설정값은 Channel.value() 또는 일반 값으로 넘깁니다. DSL2에서는 한 채널을 여러 process가 구독하는 경우 자동으로 fork되므로, 이를 예전의 "한 번만 소비" 규칙과 혼동하지 않습니다.

더 깊게 파고 싶다면

본문은 BPD 연구진이 직접 재구성한 서술입니다. 원 논문과 공식 자료로 심화해봅시다.

Nextflow 원 논문: Di Tommaso et al. (2017), Nextflow enables reproducible computational workflows, Nature Biotechnology 35.
Nextflow 공식 문서: DSL2 마이그레이션 가이드와 채널 연산자 레퍼런스.
Wellcome Sanger — Nextflow 실무 교육 자료: 공식 트레이닝 코스.

다음 편(F29)에서는 이 DSL2 모듈화 위에 구축된 표준 파이프라인 생태계, nf-core를 실제로 투어합니다.

BioPlayground

Nextflow DSL2: 파일이 아니라 데이터 흐름 자체를 설계하기