파트 1: Hello World - 동영상 강의 스크립트

AI 지원 번역 - 자세히 알아보기 및 개선 제안

참고

이 페이지는 스크립트만 제공합니다. 전체 단계별 안내는 과정 자료를 참조하세요.

스크립트에 표시된 섹션 번호는 참고용으로만 제공되며, 자료의 모든 섹션 번호를 포함하지 않을 수 있습니다.

환영합니다

안녕하세요, 다시 돌아오신 것을 환영합니다.

지금부터 "Hello Nextflow" 과정의 파트 1인 "Hello World"를 시작합니다. 이 챕터에서는 Nextflow의 기본 개념을 단계적으로 학습합니다.

Codespaces 또는 이에 상응하는 환경에서 VS Code를 실행하고, 탐색기(Explorer)의 워크스페이스에 Hello Nextflow 폴더와 다양한 파일들이 준비되어 있다고 가정합니다.

먼저 터미널에서 Bash를 사용하여 기본적인 작업을 수행한 다음, Nextflow에서 동일한 작업을 수행하여 문법이 어떻게 생겼는지 살펴봅니다.

0. 준비 운동

아주 간단한 것부터 시작합니다. 터미널에 무언가를 출력하기 위해 "echo"를 사용합니다. "Hello World". 엔터를 누르면 터미널에 출력됩니다. Hello World. 이 과정을 수강하시는 분들께는 놀라운 일이 아닐 것입니다.

이제 이것을 활용해 봅니다. 터미널에 출력하는 것에 그치지 않고, 파일에 저장합니다. 키보드의 위쪽 방향키를 누르면 Bash 히스토리를 순환하여 마지막 명령을 불러올 수 있습니다. 명령 끝에 꺾쇠 기호(>)를 추가하면 이 명령의 출력을 파일로 리디렉션할 수 있으며, 파일 이름은 output.txt로 지정합니다.

엔터를 눌러 명령을 실행하면 터미널에는 아무것도 표시되지 않지만, 왼쪽에 output.txt라는 새 파일이 생성된 것을 확인할 수 있습니다.

터미널에서 cat 명령으로 파일 내용을 확인할 수 있습니다. cat output.txt를 실행하면 "Hello World"가 출력됩니다. 파일을 더블 클릭하면 VS Code의 코드 편집기에서 열립니다.

1.1. 코드 살펴보기

간단하죠? 다음 단계로 넘어갑니다. 이번에는 동일한 작업을 Nextflow 안에서 수행합니다.

앞서 말씀드린 것처럼, 이 과정의 각 챕터는 스크립트로 시작하며, 이번 스크립트는 Hello World입니다. Hello World 파일을 찾아 한 번 클릭하면 미리보기가 표시되고, 더블 클릭하면 편집기에서 열립니다. 터미널은 잠시 닫겠습니다.

이 스크립트는 매우 단순합니다. 22줄에 불과하며, 기본적으로 동일한 작업을 수행합니다. 실제로 일부 내용은 익숙하게 보일 것입니다. 방금 입력한 Bash 명령이 파일로 리디렉션되는 것을 확인할 수 있습니다.

이 파일에서 Nextflow의 핵심 개념들을 확인할 수 있습니다. 빨간색으로 표시된 process와 workflow가 있습니다. 이것들은 Nextflow의 특수 키워드이자 특수 용어입니다.

1.1.1. process 정의

워크플로우 내의 각 process는 워크플로우의 서로 다른 논리적 단위를 감쌉니다. 각 process는 하나의 작업을 수행합니다.

실행하면 하나 또는 여러 개의 작업(task)이 생성되며, 이것이 파이프라인의 실제 실행 단계입니다. 모든 process는 하단에 있는 workflow 블록 내에서 조율되며, 이 경우에는 해당 process 하나만 실행합니다.

process 이름은 이 키워드 뒤에 오며, 기본적으로 어떤 이름이든 사용할 수 있습니다. process의 내용은 중괄호 안에 있습니다.

process에 필요한 요소는 script 또는 exec 블록뿐입니다. 삼중 따옴표 안에 있는 내용이 바로 그것으로, 파이프라인을 실행할 때 작업 디렉토리에 작성되는 Bash 스크립트이며, 실제로 컴퓨터나 서버에서 실행됩니다.

일반적으로 Bash를 사용하지만, 상단의 shebang을 변경하여 Python 스크립트나 R 스크립트를 사용할 수도 있습니다. 이 스크립트 안에 있는 내용은 무엇이든 실행됩니다.

이 process에 추가된 또 다른 요소는 output 선언입니다. 이것은 Nextflow에게 이 process가 output.txt라는 출력 파일을 생성할 것임을 알려줍니다. path로 지정되어 있으므로 파일처럼 처리됩니다. 만약 val이라면 변수나 값으로 처리됩니다.

이 선언은 파일을 생성하는 것이 아닙니다. 실제 파일 생성은 아래의 script에서 이루어집니다. 단지 Nextflow에게 이 파일 이름의 출력 파일을 기대하라고 알려주는 것입니다.

1.1.2. workflow 정의

하단에는 workflow가 있으며, 여기에도 선언이 있습니다. 이것은 Main이라고 불립니다. 이것은 workflow의 script 블록에 해당하는 부분으로, 실제로 무언가를 수행하는 부분입니다. 이 경우에는 sayHello라는 process를 실행합니다.

물론 실제 파이프라인은 이보다 훨씬 복잡합니다. 여러 개의 process가 있고, 채널을 사용하여 데이터 흐름을 조율합니다. 이에 대해서는 이 과정의 다음 파트에서 다루겠지만, 지금은 이것으로 충분합니다. 이것은 유효한 파이프라인이며 정상적으로 작동합니다.

VS Code에서 DAG 미리보기를 클릭할 수도 있습니다. DAG는 파이프라인의 데이터 흐름 구조를 나타내며, 사이드에 mermaid 다이어그램으로 렌더링됩니다. 이 경우에는 매우 단순합니다. workflow를 나타내는 박스 하나와 sayHello라는 process 하나가 있지만, 진행하면서 더 흥미로워질 것입니다.

1.2. 워크플로우 실행

워크플로우를 실행하여 결과를 확인합니다.

터미널을 다시 열고 출력을 지운 다음, nextflow run을 입력하고 스크립트 이름인 hello-world.nf를 입력한 후 엔터를 누릅니다.

상단에는 Nextflow가 실행된 버전, 스크립트 이름 등의 표준 정보가 표시됩니다.

가장 중요한 부분은 실행된 작업들의 요약입니다.

초록색 체크 표시가 보인다면 첫 번째 파이프라인을 성공적으로 실행한 것입니다.

실행된 process의 이름(Say Hello)과 한 번 실행되어 성공했음을 알 수 있습니다. 더 큰 파이프라인을 실행할 때는 진행 상황이 여기에 표시됩니다. 이 파이프라인은 매우 작기 때문에 거의 즉시 실행됩니다.

1.2.2. work 디렉토리에서 출력 및 로그 확인

Nextflow 파이프라인을 실행하면 각 process가 연결되고, 각 process는 앞서 말씀드린 것처럼 하나 또는 여러 개의 작업을 생성할 수 있습니다. 이 경우에는 이 process에서 단일 작업이 실행되었으며, 이 작업 해시(hash) 아래에서 완료되었습니다.

Nextflow는 작업 디렉토리의 파일을 직접 처리하지 않고, work라는 특수 폴더를 생성합니다. ls를 실행하면 work 폴더가 생성된 것을 확인할 수 있으며, 그 안에는 실행된 모든 작업에 대한 하위 디렉토리가 있습니다. 이것은 해시와 일치합니다. ls work/c4를 실행하면 203으로 시작하는 작업 디렉토리를 확인할 수 있으며, 이것이 파이프라인 실행 시 이 process가 생성한 작업 디렉토리입니다. 사이드바에서도 확인할 수 있습니다.

파일 목록을 보면 output.txt 파일이 생성된 것을 확인할 수 있습니다. 일반 ls 명령으로는 표시되지 않는 숨김 파일들도 있습니다.

output.txt를 클릭하면 출력 내용을 확인할 수 있습니다. 파이프라인이 정상적으로 작동했습니다.

본질적으로 한 줄짜리 Bash 스크립트를 실행하기 위해 상당한 양의 코드가 필요한 것처럼 보일 수 있지만, process가 복잡해질수록 그 의미가 명확해집니다. Nextflow의 work 디렉토리와 생성되는 파일들은 Nextflow를 강력하게 만드는 핵심입니다.

파이프라인의 각 작업, 각 요소는 다른 모든 작업과 격리되어 있습니다. 재현 가능하며, 서로 충돌하지 않고, 모든 것이 병렬로 실행될 수 있습니다. 이 격리 덕분에 단일 작업에 대해 정확히 무슨 일이 일어났는지 확인하고 디버그할 수 있어 익숙해지면 매우 편리합니다.

work 디렉토리의 다른 파일들을 살펴봅니다. 위에서부터 .command.begin 파일이 있습니다. 이것은 비어 있으며, Nextflow가 작업을 시작했음을 알리는 센티넬(sentinel) 파일입니다. 특별히 흥미로운 내용은 없습니다.

그 다음에는 .command.error, .command.log, .command.out이 있습니다. 이것들은 모두 실행된 Bash 명령 또는 스크립트의 출력입니다. 각각 표준 오류(stderr), 표준 출력(stdout), 그리고 두 가지가 출력된 순서대로 결합된 것입니다.

이것들도 이 경우에는 비어 있어 특별히 흥미롭지 않지만, .command.run에서는 더 흥미로운 내용을 확인할 수 있습니다.

이것은 일반적으로 매우 긴 스크립트입니다. Nextflow가 실제로 실행하는 것으로, 여기에서 Nextflow의 내부 로직과 process 실행 방식을 확인할 수 있습니다. 로컬에서 실행하는지, SLURM에 job으로 제출하는지에 따라 달라지며, SLURM의 경우 상단에 SLURM 헤더가 있습니다.

일반적으로 이 파일을 직접 살펴볼 필요는 없습니다. Nextflow가 자동으로 생성하며, 파이프라인에 특별히 고유한 내용은 없습니다. 하지만 실행의 핵심입니다.

다음 파일이 훨씬 더 흥미롭습니다. .command.sh는 process에서 생성된 스크립트로, Nextflow가 Bash 헤더를 추가하고 script 블록에 있던 명령을 실행한 것을 확인할 수 있습니다.

.command.run 파일이 하는 일은 바로 이 .command.sh 파일을 실행하는 것입니다.

이것은 디버깅할 때 가장 자주 확인하게 되는 파일로, Nextflow 파이프라인의 로직이 예상대로 동작하는지 확인하는 데 매우 유용합니다.

마지막으로 .exitcode 파일이 있으며, 이것은 작업의 종료 코드를 기록합니다. 이 경우에는 성공했으므로 종료 코드는 0입니다.

메모리 부족 등의 이유로 실패한 경우, 무엇이 잘못되었는지 파악하는 데 매우 유용합니다.

1.3. 워크플로우 다시 실행

work 디렉토리에 대해 한 가지 더 이해해야 할 것이 있습니다. 이 파이프라인을 반복해서 실행하면, 즉 nextflow run hello-world.nf를 실행하면 동일한 작업을 수행하지만 이번에는 새로운 작업 ID가 생성됩니다. 해시가 다른 것을 확인할 수 있으며, work 디렉토리에는 이제 두 개의 해시 디렉토리가 있습니다. 이것들도 서로 분리되어 있습니다.

따라서 Nextflow 워크플로우를 실행할 때마다, 나중에 다룰 cache를 사용하는 resume을 사용하지 않는 한, 서로 분리된 새로운 work 디렉토리에서 process를 다시 실행합니다. 파일 이름 충돌이 발생하지 않으며, 모든 것이 격리되고 깔끔하게 유지됩니다.

이 디렉토리에 들어가면 동일한 파일들과 처음부터 다시 생성된 동일한 output.txt를 확인할 수 있습니다.

2. 출력 게시

Nextflow가 파이프라인을 실행하는 동안 모든 것을 분리하고 깔끔하게 관리하는 것은 훌륭합니다.

하지만 결과를 탐색하려는 사람에게는 수천 개의 work 디렉토리를 뒤져 결과 파일을 찾는 것이 불편합니다. 실제로 그렇게 할 필요도 없습니다. work 디렉토리는 파일의 최종 저장 위치가 아닙니다.

파일을 게시(publish)하여 이 문제를 해결합니다.

2.1.1. sayHello process의 출력 선언

스크립트로 돌아가서 workflow 블록에서 작업합니다. 어떤 파일을 기대하는지, 어떤 파일이 필요한지 지정하고, 아래에 output 블록이라는 새 블록을 만듭니다.

이것은 Nextflow 버전 26.04에서 기본으로 제공되는 새로운 문법 분석기와 함께 도입된 새로운 문법입니다. Nextflow를 이전에 사용해 보셨다면, 이것이 새로운 기능 중 하나입니다.

main 블록이 있고, 다음으로 publish를 선언하여 게시할 내용을 Nextflow에 알립니다. first_output이라고 부르고, sayHello.out으로 지정합니다.

실수로 오타를 냈지만, 이것은 Nextflow VS Code 확장의 기능을 보여줄 좋은 기회입니다. 즉시 빨간 물결선이 표시되어 문제가 있음을 알려줍니다. 마우스를 올리면 변수가 정의되지 않았다는 메시지가 표시됩니다.

이 경우에는 오타가 명확합니다. sayHello라고 입력하면 물결선이 사라집니다.

이제 보라색으로 표시됩니다. Nextflow 문법 분석기가 이것이 process임을 인식하고, 마우스를 올리면 이 process의 간략한 표현을 보여줍니다. 입력이 없고 이 출력을 제공한다는 것을 한눈에 확인할 수 있습니다. VS Code에서 이 확장을 사용하면 코드를 작성하는 동안 많은 컨텍스트 정보를 얻을 수 있습니다.

.out 문법을 사용하여 이 process의 출력을 참조할 수 있습니다. 현재는 임의의 변수 이름으로 원하는 이름을 사용할 수 있습니다.

2.1.2. 스크립트에 output: 블록 추가

이것이 중요해지는 것은 새 블록을 추가할 때입니다. 이 블록은 workflow 블록 아래에 있으며, 더 이상 workflow 안에 있지 않습니다. 중괄호를 사용하며, 여기서 워크플로우가 생성한 모든 파일을 어디에 저장할지 Nextflow에 알립니다.

앞서 만든 변수 이름을 가져와 여기에 넣고 중괄호를 추가합니다. Nextflow에게 path를 사용하도록 지정합니다. 따옴표 안에 점(.)을 사용하면 Nextflow가 파일을 results 디렉토리의 루트에 저장합니다. 하위 디렉토리 없이 저장됩니다.

워크플로우를 다시 실행합니다. nextflow run hello-world.nf를 실행하면 기본적으로 동일하게 보일 것입니다. Nextflow에서 실제로 변경된 것은 없습니다. 동일한 작업을 수행하며, work 디렉토리에서 실행됩니다.

하지만 이제 ls results/를 실행하면 results라는 새 디렉토리가 생성된 것을 확인할 수 있습니다. 이것이 워크플로우 게시의 기본 디렉토리입니다. 그 안에 output.txt 파일이 있습니다.

ls -l results를 실행하면 이것이 실제로 work 디렉토리에 대한 소프트 링크임을 확인할 수 있습니다. 실제 파일이 아니라 work 디렉토리에 링크되어 있으며, 모든 파일이 수집되어 있습니다.

2.2. 사용자 정의 위치 설정

"results"는 이 경로의 기본 이름입니다. 워크플로우를 다시 실행할 때 단일 하이픈을 사용하면(코어 Nextflow 옵션이므로) "-output-dir myresults"와 같이 지정할 수 있습니다. 줄여서 "-o"를 사용할 수도 있습니다. 그러면 파일이 저장되는 기본 디렉토리가 변경되며, myresults/ 아래에 output.txt가 생성됩니다.

좋지만, 모든 파일을 루트에 저장하는 것은 바람직하지 않습니다. 구조화가 필요하므로 하위 디렉토리를 만들 수 있습니다. "path 'hello_world'"와 같이 지정하고 다시 실행합니다. nextflow run hello-world.nf를 실행하면 results 디렉토리의 하위 디렉토리에 저장되며, 이제 results 아래에 hello_world/ 디렉토리와 output.txt가 있습니다.

중요한 점은 기존의 output.txt 파일이 여전히 존재한다는 것입니다. results 디렉토리는 재실행 시 초기화되지 않습니다. 새 파일이 복사되며, 동일한 파일 이름이 있으면 덮어쓰지만 기존 파일을 삭제하지는 않습니다. 따라서 파이프라인을 재실행할 때 기존 파일 위에 덮어쓰지 않으려면 비어 있는 디렉토리를 사용해야 합니다.

2.3. 게시 모드를 copy로 설정

앞서 언급했듯이 이 파일들은 소프트 링크입니다. ls -l results/hello_world/를 실행하면 work 디렉토리에 소프트 링크되어 있음을 확인할 수 있습니다. HPC와 같은 환경에서 매우 큰 파일을 다룰 때는 파일 시스템에 한 번만 저장되므로 일반적으로 좋은 방법입니다.

하지만 work 디렉토리를 삭제하면, 즉 rm -r work를 실행하여 생성된 모든 중간 파일을 삭제하면, results/hello_world/의 파일을 읽으려 할 때 더 이상 존재하지 않는 파일을 가리키는 소프트 링크가 되어 데이터가 영구적으로 손실됩니다. 이것은 바람직하지 않습니다.

따라서 가능하다면 소프트 링크 대신 파일을 복사하는 것이 더 안전한 방법입니다. 단, work 디렉토리를 삭제하지 않으면 디스크 공간을 두 배로 사용한다는 점을 유의하세요.

output 블록에서 이를 설정하려면 첫 번째 출력으로 이동합니다. 앞서 path를 설정했고, 이제 mode를 설정합니다. VS Code 확장이 출력 지시문임을 인식하여 제안을 표시합니다. copy를 선택하고 저장합니다.

워크플로우를 다시 실행합니다. 새 work 디렉토리에 파일이 다시 생성됩니다.

이제 ls -l results/hello_world/를 실행하면 실제 파일이며 소프트 링크가 아님을 확인할 수 있습니다. Nextflow가 파일을 복사했습니다. path와 mode는 자주 사용하게 될 설정입니다.

물론 이것은 매우 단순한 예시입니다. 진행하면서 더 복잡하고 강력하게 만들 것이며, 이러한 설정을 동적으로 만들고 너무 장황하지 않게 하는 방법을 살펴볼 것입니다.

2.4. process 수준의 publishDir 지시문에 대한 참고 사항

앞서 언급했듯이, 이것은 비교적 새로운 문법입니다. 이 글을 작성하는 시점에서 최신 버전의 Nextflow에서만 사용 가능하며, Workflow Outputs라고 불립니다.

이것을 사용하면 Nextflow Lineage와 같은 다른 유용한 기능들이 활성화되어 파일이 생성될 때 그 출처를 추적하는 데 도움이 됩니다. 곧 26.04에서 기본값이 될 것이며, 향후에는 워크플로우를 작성하는 유일한 방법이 될 것입니다.

하지만 현재 이 전환 단계에서는 publishDir이라는 이전 방식을 사용하는 파이프라인을 접할 수 있습니다. 이것은 workflow 및 output 수준이 아닌 process 수준에서 정의됩니다.

이 선언은 기본적으로 동일한 내용을 말합니다. results라는 디렉토리에 결과 파일을 게시하고 copy 모드를 사용합니다. 문법이 매우 유사하지만, 새 파이프라인을 작성할 때는 AI 결과나 문서, 다른 파이프라인에서 보더라도 이 publishDir 지시문을 사용하지 않도록 하세요. 그것은 이전 방식입니다.

2026년에는 모두 workflow outputs를 사용해야 합니다.

이에 대한 문서는 nextflow.io/docs/에서 확인할 수 있습니다. 튜토리얼 섹션으로 스크롤하면 Migrating to Workflow Outputs라는 튜토리얼이 있습니다.

매우 유용한 튜토리얼로, 모든 문법과 이전 문법과의 동등성, 변경 이유, 타임라인 등을 다루며 다양한 시나리오와 많은 예제를 제공합니다. 기존 Nextflow 코드를 새 문법으로 쉽게 변환할 수 있습니다.

3.1. sayHello process가 변수 입력을 받도록 변경

지금까지 process를 실행하고, 파일을 생성하고, Nextflow에 출력임을 알리고, 파일 저장 위치를 지정하는 간단한 스크립트를 작성했습니다. 좋은 시작입니다.

하지만 모든 것이 하드코딩되어 있으면 흥미롭지 않습니다. 다음으로, 워크플로우를 실행할 때 런타임에 제어할 수 있는 변수 입력을 process에 전달하는 방법을 살펴봅니다.

이를 위해 몇 가지 작업이 필요합니다.

먼저, 이 process가 입력 변수를 받을 수 있음을 알려야 합니다. 새 선언 블록으로 input을 추가하고 "val greeting"으로 지정합니다.

val은 여기서 path에 해당하는 것으로, Nextflow에게 이것이 변수(이 경우 string)임을 알려줍니다. 마우스를 올리면 확장이 이것의 의미를 알려줍니다.

다음으로 Nextflow에게 이것으로 무엇을 할지 알려야 합니다. 변수가 있다고 선언하는 것만으로는 충분하지 않습니다. script에서 해당 변수를 어떻게 사용할지 지정해야 합니다. 하드코딩된 문자열을 제거하고 변수를 넣습니다.

중괄호 없이 먼저 보여드리겠습니다. 이것은 허용되는 이전 방식입니다. 하지만 새 문법에서는 중괄호 안에 넣는 것을 권장하며, 이렇게 하면 Nextflow가 여기서 보간(interpolation)하고 있음이 명확해집니다.

"input greeting"이 ${greeting}으로 전달됩니다. 마지막으로 workflow 수준에서 이 process가 이제 입력을 받는다는 것을 Nextflow에 알려야 합니다. 이를 위해 변수를 전달합니다.

3.2. 사용자 입력을 받기 위한 명령줄 매개변수 설정

Hello World와 같이 다시 하드코딩할 수도 있지만, 그것은 별다른 이점이 없습니다. 런타임에 설정할 수 있도록, 즉 Nextflow를 실행할 때 CLI에서 지정할 수 있도록 하고 싶습니다.

이를 위해 params라는 특수 Nextflow 개념을 사용합니다. params.input으로 지정합니다.

이것은 CLI에서 이 입력 변수를 노출시키며, Nextflow를 실행할 때 이중 대시(--)를 사용합니다.

이름은 hello, greeting 등 원하는 것으로 지정할 수 있습니다. 지정한 이름이 파이프라인을 실행할 때 CLI 옵션으로 노출됩니다. 이것은 Nextflow의 정말 유용한 기능으로, 이러한 매개변수를 사용하여 워크플로우 스크립트를 빠르게 구축하고, 파이프라인을 위한 사용자 정의 CLI를 만들어 실행 시 다양한 옵션을 쉽게 맞춤화할 수 있습니다.

터미널로 돌아가서 "nextflow run" 명령에 "--input"을 추가합니다. 이것은 앞서 본 "params.input"과 일치합니다. 문서에는 프랑스어로 되어 있지만, 저는 스웨덴에 살고 있으므로 스웨덴어로 "Hej Världen"을 입력하고 엔터를 누릅니다.

작은따옴표나 큰따옴표를 사용할 수 있으며, Bash가 해석하는 방식에 영향을 줍니다.

Nextflow 파이프라인이 동일하게 실행됩니다. work 디렉토리 등 모든 것이 동일합니다. 하지만 이제 "results/hello_world/output"을 확인하면 스웨덴어가 표시됩니다.

CLI에서 입력을 동적으로 매개변수에 전달하고, 이것을 process의 입력으로 전달하고, process가 이를 해석하여 script 블록에 넣어 스크립트 결과의 출력을 동적으로 변경했습니다. 매우 유용합니다.

매우 적은 문법으로 상당히 복잡한 로직을 구현했습니다. 이것이 어떻게 확장되는지 이해하셨을 것입니다. 이것이 바로 Nextflow 스크립트에 파이프라인의 로직과 맞춤화 가능성을 구축하는 방법입니다.

3.4. 명령줄 매개변수의 기본값 사용

좋습니다. 하지만 이제 문제가 있습니다. 이 파이프라인을 실행할 때마다 --input을 지정해야 합니다.

이 매개변수 없이 실행하면 Nextflow가 이 매개변수가 필요하지만 설정되지 않았다는 오류를 발생시킵니다.

참고로, 이것은 새로운 기능입니다. 이전에는 Nextflow가 빈 문자열로 실행되어 이해하기 어려운 오류가 발생했습니다. 하지만 새 Nextflow 문법 분석기에서는 더 신중하게 처리하여 즉시 알려줍니다.

항상 모든 옵션을 지정하고 싶지는 않습니다. 합리적인 기본값을 설정하는 것이 좋은 방법입니다. 스크립트에서 어떻게 설정할까요?

앞서 작성할 때 params.input을 사용하는 곳에 바로 넣었습니다. 명확한 해결책은 기본값을 정의하는 것으로, 스크립트 상단의 workflow 내 특수 params 블록에서 설정합니다.

새로운 문법이므로 주의 깊게 살펴보세요. 여기에 기대되는 매개변수 이름이 있습니다.

콜론(:) 문자 뒤에 변수의 타입을 정의합니다. 필수는 아니지만, 매우 유용합니다. Nextflow에게 string을 기대하고 그렇게 처리하라고 알려줍니다.

숫자가 필요한 경우 float를 사용하면 부동소수점 숫자를 기대합니다. string을 전달하면 오류가 발생합니다. string으로 지정하면 선행 0이 있고 모두 숫자인 경우에도 실제 string으로 처리됩니다.

이 타입 안전성은 Nextflow의 매우 새로운 기능이지만, 코드를 더 안전하게 작성하고 실행하는 데 매우 강력합니다.

그 다음에는 등호(=)와 기본값이 있습니다. Nextflow는 원래 바르셀로나에서 개발되었으므로, 기본값으로 스페인어 "Holà mundo!"를 사용하는 것이 적절합니다.

스크립트를 저장하고 --input 없이 다시 실행합니다. 이번에는 정상적으로 실행되어 results에 새 파일이 생성됩니다. 파일에는 "Holà mundo!"가 표시됩니다.

하지만 이것은 기본값일 뿐이므로, 이전과 동일하게 사용할 수 있습니다. 이전 스크립트로 돌아가서 "Hej Världen"을 사용하면, 명령줄에서 --input을 지정하면 기본값을 덮어쓰고 output.txt 파일에 해당 값이 사용됩니다.

스크립트의 이 값은 설정하는 기본값일 뿐입니다.

워크플로우가 더 복잡해지고 더 많은 매개변수를 포함하게 되면, 스크립트 상단의 params 블록에 모든 매개변수가 한 곳에 모이게 됩니다.

스크립트에서 모든 워크플로우 입력이 상단에, 워크플로우 출력이 하단에 있는 대칭적인 구조가 만들어집니다. 워크플로우의 외부 인터페이스가 매우 명확하게 표현됩니다. 새 문법으로 새 파이프라인을 빠르게 파악하고 사용 방법을 이해할 수 있습니다.

마지막으로 한 가지 더. 기본값을 설정하지 않아도 됩니다. params input을 설정하되 기본값을 지정하지 않으면, Nextflow에게 이 매개변수가 필수임을 알려줍니다. 파이프라인은 이 매개변수 없이 실행에 실패하지만, null에 관한 것보다 더 유용한 오류 메시지를 제공합니다.

입력이 필수이지만 명령줄에서 지정되지 않았다는 메시지가 표시됩니다. 매우 유용합니다.

이제 변수 입력과 매개변수로 Nextflow 파이프라인을 설정하는 방법, 기본값 설정 방법, 타입 설정 방법(Boolean true/false 플래그, integer 또는 다른 타입), 워크플로우에 전달하는 방법, process에서 보간되는 방법, 그리고 Nextflow를 실행할 때 명령줄에서 맞춤화하는 방법을 이해하셨을 것입니다. 단순한 Bash 명령보다 훨씬 흥미로워지고 있습니다.

4. 워크플로우 실행 관리

다음 단계입니다. 이 챕터의 마지막 부분에서는 다양한 워크플로우 실행을 관리하는 방법에 대해 살펴봅니다. 사이드바의 탐색기(Explorer)에서 work 아래를 보면 여러 파이프라인을 실행했고 work 디렉토리가 상당히 많아진 것을 확인할 수 있습니다.

또한 앞서 말씀드린 것처럼, 이 파이프라인을 재실행할 때마다 새로운 work 디렉토리 세트가 생성되고 모든 process가 처음부터 다시 실행됩니다. 이것은 의도된 동작으로 재현 가능하고 모든 것을 새로 생성합니다. 하지만 매우 오래 실행되는 process가 있는 경우, 파이프라인이 중간에 실패하거나 파이프라인 끝부분을 변경했을 때 항상 처음부터 시작해야 하는 것은 불편합니다.

4.1. -resume으로 워크플로우 재시작

다행히 Nextflow는 이전에 실행된 것과 사용 가능한 것을 잘 파악하고 있으며, 이전 결과를 재사용하는 것은 매우 간단합니다. 명령 끝에 "-resume" 플래그를 추가하기만 하면 됩니다.

input에는 이중 대시(--)를 사용하는데, 이것은 매개변수이기 때문입니다. resume에는 단일 하이픈(-)을 사용하는데, 이것은 코어 Nextflow 옵션이기 때문입니다.

Nextflow를 오래 사용한 사람들도 자주 혼동하는 부분입니다. 코어 Nextflow 옵션인지 여부에 따라 하이픈 하나 또는 두 개를 사용합니다.

-resume을 추가하고 동일한 워크플로우를 다시 실행합니다. 이번에는 한 가지 중요한 차이점을 제외하고 거의 동일하게 보일 것입니다.

출력에서 결과가 캐시되었음을 확인할 수 있습니다. 실제로 이 작업 해시는 이전 실행과 정확히 동일하며, 해당 work 디렉토리를 그대로 재사용했습니다. 입력, 출력, 스크립트가 모두 변경되지 않았으므로 해당 파일을 사용하고, 파이프라인에 다운스트림 단계가 있다면 다음 단계로 전달합니다.

전체 파이프라인을 처음부터 끝까지 실행하지만, 가능한 경우 각 작업에 대해 캐시된 결과를 사용합니다.

-resume을 사용하면 작업 디렉토리에서 마지막 파이프라인 실행을 재개합니다. 하지만 실제로는 이전에 실행한 특정 실행에서 재개할 수 있습니다.

4.2. 과거 실행 로그 확인

모든 실행을 확인하려면 "nextflow run" 대신 "nextflow log"를 실행합니다. 화면을 조금 작게 만들어야 볼 수 있는데, 모든 실행, 실행 시간, 세션 ID, 명령 등이 표시됩니다.

여기서 특정 실행의 실행 이름을 가져와 해당 실행에서 재개할 수 있습니다. hungry_ekeblad라는 실행으로 돌아가서 resume 뒤에 해당 이름을 추가합니다.

참고로, 이 형용사와 과학자 이름들은 모두 Nextflow 소스 코드에 있습니다. 좋아하는 과학자를 찾아 추가하는 것이 Nextflow에 첫 번째 pull request를 제출하는 좋은 방법입니다.

이렇게 하면 해당 워크플로우 실행의 캐시된 결과를 확인하고, 여전히 재사용할 수 있음을 인식하여 캐시된 결과를 다시 사용합니다.

4.3. 오래된 work 디렉토리 삭제

좋습니다. 이 work 디렉토리들을 정리하고 싶다면 어떻게 할까요? 디렉토리가 많고 파일도 많습니다. 마지막 몇 번의 파이프라인 실행에서 재개하고 싶지만 그 이전 것들은 필요 없다고 확신한다면 어떻게 할까요?

특정 실행을 선택하고 "nextflow clean" 명령을 사용합니다. "-before"와 특정 실행 이름(이 경우 reverent_pike)을 지정하고, "-n"을 추가하면 드라이 런(dry run)을 수행합니다. 실제로 아무것도 삭제하지 않고 삭제될 항목만 표시합니다.

합리적으로 보입니다. 동일한 명령을 다시 실행하되 "-n" 대신 "-f"를 사용하여 실제로 정리합니다. 이번에는 모든 디렉토리가 실제로 삭제됩니다. work 디렉토리를 확인하면 훨씬 가벼워진 것을 확인할 수 있습니다.

이것이 캐시를 완전히 삭제하지 않고 로컬 work 디렉토리를 안전하게 정리하는 방법입니다. 원하면 여전히 재개할 수 있습니다.

각 Nextflow 명령의 플래그가 기억나지 않으면 "nextflow help"와 명령 이름을 사용합니다. "nextflow help clean"을 실행하면 -after, -before, -but 등 이 정리 동작을 설정하는 다양한 옵션을 확인할 수 있습니다.

핵심 정리

Hello Nextflow의 파트 1이 끝났습니다. 과정의 시작치고는 상당히 집중적이었지만, 이제 Nextflow 스크립트의 모습, 즉 process, workflow, output, 매개변수 등 핵심 구성 요소에 대해 잘 이해하셨을 것입니다. 명령줄에서 기본 재정의로 설정하는 방법, 동적 script가 있는 동적 input 블록을 만드는 방법, 모든 워크플로우 실행을 관리하는 방법(이전 실행 확인, 재개, 정리)을 알게 되었습니다. 많은 내용을 다루었습니다. 정말 많이 발전하셨습니다. 잠시 휴식을 취하고 산책을 하거나 차 한 잔을 준비하셔도 좋습니다. 충분히 그럴 자격이 있습니다.

앞으로는 이 기반 위에서 계속 발전시켜 나갑니다. 더 복잡하고 강력하며 유연하게 만들어 원하는 분석을 대규모로 수행하는 방법을 살펴봅니다.

퀴즈

웹 페이지의 파트 1, Hello World 섹션으로 스크롤하면 퀴즈가 있습니다. 이것은 이번 버전의 Nextflow 교육을 위해 새롭게 추가된 기능입니다. 이 챕터에서 다룬 모든 내용을 이해했는지 스스로 확인할 수 있습니다.

퀴즈 결과는 저희에게 전송되지 않으며, 브라우저에만 저장됩니다. 놓친 내용이나 잘못 이해한 내용이 없는지 확인하는 자가 점검 도구입니다. 원하는 만큼 여러 번 시도할 수 있습니다.

터미널에서 VS Code 인스턴스를 사용하고 싶다면 quiz 명령을 입력하고 챕터를 지정합니다. "Hello World"를 입력하면 웹 브라우저와 동일한 퀴즈 문제를 터미널에서 풀 수 있습니다.

즐겁게 참여하시고, 잠시 후 다음 챕터인 Nextflow 채널에 대한 내용으로 돌아오겠습니다.

​