파트 1: Hello World - 비디오 스크립트

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

중요 사항

이 페이지는 스크립트만 표시합니다. 전체 단계별 지침은 과정 자료로 돌아가세요.

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

환영합니다

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

지금부터 "Hello Nextflow" 과정의 파트 1인 "Hello World"를 시작합니다. 이 장에서는 Nextflow의 기본 개념에 대한 이해를 쌓아가겠습니다.

이제 Codespaces나 이와 동등한 환경에서 VS Code가 실행되고 있고, 탐색기의 작업 공간에 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. 프로세스 정의

워크플로우 내의 각 프로세스는 워크플로우의 논리적 단위를 감쌉니다. 각 프로세스는 한 가지 작업을 수행합니다.

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

프로세스 이름은 이 키워드 뒤에 오며, 기본적으로 무엇이든 될 수 있습니다. 그리고 프로세스의 내용은 이 중괄호 안에 있습니다.

프로세스에는 실제로 한 가지 요구사항만 있는데, 어떤 종류의 script 또는 exec 블록을 포함해야 한다는 것입니다. 이것은 여기 삼중 따옴표 안에 있으며, 워크플로우를 실행할 때 작업 디렉토리에 작성되는 bash 스크립트이고, 컴퓨터나 서버에서 실제로 실행되는 것입니다.

일반적으로 bash이지만, 상단에 다른 shebang을 넣을 수도 있으며, Python 스크립트나 R 스크립트가 될 수도 있습니다. 상관없습니다. 이 스크립트에 있는 것은 무엇이든 실행됩니다.

이 프로세스에 추가한 다른 것이 하나 있는데, 바로 output 선언입니다. 이것은 Nextflow에게 이 프로세스가 output.txt라는 출력 파일을 예상한다고 알려줍니다. path라고 되어 있으므로 파일처럼 처리되어야 하며, 예를 들어 val이었다면 변수나 값처럼 처리된다는 의미입니다.

이것이 이 파일을 생성하는 것은 아닙니다. 실제로 생성하지 않습니다. 그것은 여기 아래 스크립트에서 수행됩니다. 단지 Nextflow에게 이 파일명을 가진 출력 파일을 예상하라고 알려주는 것입니다.

1.1.2. 워크플로우 정의

좋습니다. 그리고 하단에 workflow가 있으며, 다시 선언이 있습니다. 이것은 Main이라고 합니다. 이것은 무언가를 수행하는 워크플로우의 일부입니다. 원한다면 script 블록에 해당하는 워크플로우라고 할 수 있습니다. 이 경우 sayHello라는 프로세스를 호출한다고 말하고 있습니다.

물론 일반적으로 파이프라인은 이것보다 훨씬 더 복잡해 보일 것입니다. 아마도 하나 이상의 프로세스가 있을 것이고, 채널을 사용하여 프로세스 간의 데이터 흐름을 조율할 것입니다. 이것은 이 과정의 다음 파트에서 다루겠지만, 지금은 이것으로 충분합니다. 이것은 작동해야 하는 유효한 파이프라인입니다.

VS Code에서 여기 DAG 미리보기를 클릭할 수도 있습니다. DAG는 파이프라인의 데이터 흐름 구조를 나타내며, mermaid 다이어그램으로 렌더링된 것을 측면에서 볼 수 있습니다. 이 경우 매우 간단합니다. 워크플로우인 상자 하나와 sayHello라는 프로세스 하나가 있지만, 진행하면서 더 흥미로워질 것입니다.

1.2. 워크플로우 실행

좋습니다, 이 워크플로우를 실행하여 어떤 일이 일어나는지 봅시다.

하단에 터미널을 다시 불러오고, 출력을 지우고, Nextflow Run을 입력하겠습니다. 그리고 스크립트 이름인 hello-world.nf를 입력하겠습니다. 그리고 엔터를 누르겠습니다.

좋습니다, 상단에 표준 내용이 있으며, Nextflow가 실행되었고 어떤 버전이 실행되었는지, 스크립트 이름이 무엇인지 등을 알려줍니다.

그리고 정말 중요한 것은 여기에 있는데, 실행된 다양한 작업의 요약입니다.

여러분의 것이 작은 녹색 체크 표시와 함께 이렇게 보인다면, 잘하셨습니다. 방금 첫 번째 파이프라인을 실행하셨습니다. 훌륭합니다.

여기에 실행된 프로세스의 이름이 표시되는데, Say Hello라고 하며, 한 번 실행되었고 성공했다고 알려줍니다. 이것은 진행하면서 업데이트되므로 더 큰 파이프라인을 실행할 때 여기에 진행 상황이 표시됩니다. 하지만 이것은 너무 작아서 기본적으로 즉시 실행됩니다.

1.2.2. work 디렉토리에서 출력과 로그 찾기

Nextflow 파이프라인을 실행하면 각 프로세스가 함께 연결되고, 앞서 말했듯이 각 프로세스는 하나 또는 여러 개의 작업을 생성할 수 있습니다. 이 경우 이 프로세스에서 단일 작업이 있었습니다. 한 번만 실행되었고 이 작업 해시 아래에서 수행되었습니다.

Nextflow는 작업 디렉토리의 파일을 직접 다루지 않고, work라는 특수 폴더를 생성합니다. "ls"를 실행하면 여기에 나타난 것을 볼 수 있습니다: work, 그리고 그 안에는 실행되는 모든 단일 작업에 대한 하위 디렉토리가 있습니다. 그리고 이것은 이 해시와 일치합니다. "ls work/c4"를 실행하면, 그리고 잘려 있지만 203으로 시작하며, 이것이 파이프라인을 실행할 때 이 프로세스에 의해 생성된 작업 디렉토리입니다. 측면에서도 볼 수 있습니다.

이 파일들을 나열하면 output.txt 파일이 생성된 것을 볼 수 있습니다. 여기서도 볼 수 있습니다. 그리고 일반 "ls"로는 표시되지 않는 숨겨진 파일들이 많이 있습니다.

output.txt를 클릭하면, 확실히 출력이 있습니다. 훌륭합니다. 파이프라인이 작동했습니다.

본질적으로 한 줄짜리 bash 스크립트를 실행하는 데 상당히 많은 보일러플레이트처럼 보일 수 있지만, 프로세스가 더 복잡해지면 더 이해가 될 것입니다. 그리고 Nextflow의 이 work 디렉토리와 생성되는 이 파일들이 실제로 Nextflow를 매우 강력하게 만드는 핵심입니다.

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

work 디렉토리의 다른 파일들을 빠르게 살펴봅시다. 위에서 아래로, .command.begin이라는 파일이 있습니다. 이것은 비어 있습니다. Nextflow가 작업을 시작한다고 말하며 생성한 센티널 파일일 뿐입니다. 흥미로운 것은 없습니다.

그 다음 .command.error, .command.log, .command.out이 있습니다. 이것들은 모두 실행된 bash 명령이나 이 스크립트의 출력입니다. 이것은 표준 에러입니다. 이것은 표준 출력이고, 이것은 나온 대로 두 개를 결합한 것입니다. 따라서 논리적 순서를 얻습니다.

좋습니다, 이것들도 모두 비어 있어서 별로 흥미롭지 않지만, .command.run에 도달하면 더 흥미로워집니다.

이것은 일반적으로 매우 긴 스크립트입니다. 그리고 이것이 Nextflow가 실제로 실행하는 것입니다. 여기에 들어가면 Nextflow의 모든 내부 로직을 보기 시작하고 무엇을 하고 있는지, 프로세스를 어떻게 실행하는지 볼 수 있습니다. 이것은 로컬에서 실행하는지 또는 SLURM에 작업으로 제출하는지에 따라 달라지며, 그 경우 상단에 SLURM 헤더가 있을 것입니다. 이 모든 다양한 설정들입니다.

일반적으로 이 파일을 실제로 볼 필요는 없습니다. Nextflow에 의해 자동 생성되며 파이프라인에 고유한 것은 실제로 없습니다. 하지만 그것이 실제로 실행되는 핵심입니다.

다음 것이 훨씬 더 흥미롭습니다. .command.sh는 프로세스에서 나온 생성된 스크립트이며, 여기서 Nextflow가 Bash 헤더를 추가한 다음 script 블록에 있던 명령을 실행한 것을 볼 수 있습니다.

그리고 .command.run 파일이 하는 일은 이 .command.sh 파일을 실행하는 것뿐입니다.

이것은 정말 유용한 것으로, 무언가를 디버그하고 Nextflow 파이프라인의 로직이 예상대로 작동하는지 확인하려고 할 때 일반적으로 가장 많이 보게 되는 것입니다.

마지막으로 .exitcode라는 파일이 있으며, 이것은 작업의 종료 코드를 캡처하는데, 이 경우 성공했으므로 종료 코드는 0이었습니다.

메모리가 부족하거나 다른 문제가 발생하여 실패하면, 무엇이 잘못되었는지 이해하는 데 매우 유용합니다.

1.3. 워크플로우 다시 실행

work 디렉토리에 대해 이해해야 할 한 가지가 더 있습니다. 이 파이프라인을 반복적으로 계속 실행하면, "nextflow run hello-world.nf"를 실행하면, 정확히 같은 작업을 수행하지만 이번에는 새로운 작업 id를 갖게 됩니다. 여기 이 해시가 다른 것을 볼 수 있으며, 이제 work를 보면 두 개의 해시 디렉토리가 있습니다. 그리고 이것들은 다시 서로 분리되어 있습니다.

따라서 Nextflow 워크플로우를 실행할 때마다, 나중에 다룰 캐시를 사용하는 resume을 사용하지 않는 한, 새로운 work 디렉토리에서 해당 프로세스를 다시 실행할 것이며, 이것들은 서로 분리되어 있습니다. 파일명 충돌이 발생하지 않으며, 그런 문제가 없습니다. 모든 것이 격리되고 깨끗합니다.

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

2. 출력 게시

좋습니다, 파이프라인을 실행하는 동안 Nextflow 자체에게는 훌륭합니다. 모든 것이 서로 분리되어 있고 깨끗하며 관리될 수 있습니다.

하지만 결과를 탐색하려는 사람에게는 그다지 유용하지 않습니다. 결과 파일을 찾기 위해 수천 개의 다른 work 디렉토리를 뒤지고 싶지는 않을 것입니다. 그리고 실제로 그렇게 하도록 의도되지 않았습니다. work 디렉토리는 파일이 생성되는 최종 상태가 되도록 의도되지 않았습니다.

파일을 게시하여 이를 수행합니다.

2.1.1. sayHello 프로세스의 출력 선언

스크립트로 돌아가면, workflow 블록에서 작업하겠습니다. 어떤 파일을 예상할지, 어떤 파일에 관심이 있는지 알려주고, 그 다음 output 블록이라는 새 블록을 아래에 만들겠습니다.

이것은 Nextflow 버전 26.04에서 기본값인 구문 분석기와 함께 제공된 새로운 구문입니다. 따라서 이전에 Nextflow를 조금 사용해본 적이 있다면, 이것이 새로운 것 중 하나입니다.

main 블록이 있고, 다음으로 publish라고 하고 게시에서 무엇을 예상할지 Nextflow에게 알려주겠습니다. first_output이라고 부르고, sayHello.out이라고 하겠습니다.

실수로 오타를 냈는데, 이것은 Nextflow VS Code 확장의 기능 중 일부를 지적할 좋은 기회이기도 합니다. 즉시 아래에 작은 빨간 물결선이 나타나 무언가 잘못되었다고 알려줍니다. 그리고 마우스를 올리면 이 변수가 정의되지 않았다고 알려줍니다. 무엇인지 모릅니다.

이 경우 매우 명백합니다. 오타를 냈습니다. sayHello를 입력하려고 했고, 그러면 물결선이 사라집니다.

이제 보라색입니다. Nextflow 구문 분석기는 이것이 프로세스라는 것을 알고 있으며, 마우스를 올리면 이 프로세스가 어떻게 생겼는지 축약된 표현을 제공합니다. 따라서 입력을 받지 않고 이 출력을 제공한다는 것을 한눈에 매우 빠르게 볼 수 있습니다. 따라서 이 확장으로 VS Code에서 작업하면 코드를 작성하면서 많은 맥락 정보를 얻을 수 있습니다.

.out 구문으로 이 프로세스의 출력을 참조할 수 있다는 점에 유의하세요. 그리고 현재로서는 이것을 원하는 대로 부를 수 있으며, 단지 임의의 변수 이름일 뿐입니다.

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

중요해지는 것은 여기서 새 블록을 만들 때이며, 이것은 이제 workflow 블록 아래에 있습니다. 더 이상 workflow 내부가 아닙니다. 다시 중괄호입니다. 그리고 여기서 워크플로우에 의해 생성된 모든 파일을 어디에 둘지 Nextflow에게 알려주기만 하면 됩니다.

이제 여기서 만든 이 변수 이름을 가져와서 거기에 넣고 중괄호를 넣겠습니다. 그리고 Nextflow에게 path를 사용하라고 알려주겠습니다. 앗. 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 블록으로 그렇게 하려면, 여기 first output으로 가겠습니다. 이전에 경로를 설정했고 이제 모드를 설정하겠습니다. 입력하면 VS code 확장이 제안하는 것을 볼 수 있습니다. 여기가 output 지시문이라는 것을 알고 있습니다. 그리고 copy라고 하겠습니다. 저장을 누릅니다.

워크플로우를 다시 실행해봅시다. 파일을 다시 생성할 것이며, 새 work 디렉토리입니다.

이제 "ls -l results/hello_world/"로 가면 이것이 실제 파일이고 더 이상 소프트 링크가 아니며, Nextflow가 그것을 복사했다는 것을 볼 수 있습니다. 알아두면 좋습니다. 따라서 path와 mode는 자주 작성하게 될 것입니다.

물론 이것은 매우 간단합니다. 진행하면서 이것을 더 복잡하고 강력하게 만들 것이며, 이것들을 동적으로 만들고 너무 장황하지 않게 만드는 방법을 보게 될 것입니다.

2.4. 프로세스 수준 publishDir 지시문에 대한 참고

이제 시작할 때 말했듯이, 이것은 상당히 새로운 형태의 구문입니다. 제가 이것을 녹화하는 시점에서 최신 버전의 Nextflow에서만 사용할 수 있으며, Workflow Outputs라고 합니다.

이것을 사용하면 훌륭합니다. Nextflow 내에서 많은 다른 멋진 기능을 잠금 해제합니다. 예를 들어 Nextflow Lineage는 이 파일들이 생성될 때 그 계보를 추적하는 데 도움이 되며, 곧 26.04에서 기본값이 될 것입니다. 그리고 나중에 미래에는 이것이 워크플로우를 작성하는 유일한 방법이 될 것입니다.

그러나 지금 이 전환 단계에 있으므로, publishDir이라는 것을 사용하는 실제 파이프라인을 볼 수 있으며, 이것은 이전 방식이고, 이 선언은 workflow 및 output 수준이 아니라 프로세스 수준에서 정의됩니다.

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

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

이것은 모두 문서화되어 있으며, 이것을 하고 있고 이전에 Nextflow를 사용한 적이 있다면, nextflow.io/docs/의 Nextflow 문서로 갈 수 있습니다. 그리고 튜토리얼로 스크롤하면 Migrating to Workflow Outputs라는 튜토리얼이 있습니다.

정말 좋습니다. 모든 구문, 이전 구문과 어떻게 동등한지, 왜 변경했는지, 타임라인과 모든 것을 다룹니다. 그리고 많은 예제와 함께 모든 다양한 시나리오를 다룹니다. 따라서 기존 Nextflow 코드를 새 구문으로 쉽게 변환할 수 있습니다.

3.1. sayHello 프로세스가 변수 입력을 예상하도록 변경

좋습니다, 프로세스를 실행하고, 파일을 생성하고, Nextflow에게 출력이라고 알려주고, 그 다음 Nextflow에게 그 파일을 어디에 저장할지 알려주는 간단한 스크립트가 있습니다. 좋은 시작입니다.

하지만 모두 하드코딩되지 않았다면 더 흥미로울 것입니다. 다음으로, 이 프로세스가 런타임에 워크플로우를 시작할 때 제어할 수 있는 변수 입력을 받을 수 있다고 Nextflow에게 알려주는 방법에 대해 생각해봅시다.

이것을 실현하기 위해 몇 가지 다른 작업을 수행해야 합니다.

먼저, 이 프로세스가 입력 변수를 받을 수 있다고 알려주어야 하며, 여기에 새 선언 블록으로 input을 입력합니다. 그리고 "val greeting"이라고 하겠습니다.

val 부분은 아래의 path와 동등합니다. Nextflow에게 이것이 이 경우 문자열 같은 변수라고 알려줍니다. 그리고 다시 마우스를 올리면 확장에서 이것이 무엇을 의미하는지 알려줍니다.

다음으로 Nextflow에게 이것으로 무엇을 할지 알려주겠습니다. 변수가 있다고 말하는 것만으로는 충분하지 않습니다. 스크립트에서 그 변수를 어떻게 사용할지 말해야 합니다. 따라서 여기 하드코딩된 문자열을 제거하고 변수를 넣겠습니다.

중괄호 없이 빠르게 해보겠습니다. 이것이 허용된다는 것을 보여주기 위해서입니다. 이것이 이전 스타일 방식입니다. 하지만 이제 새 구문으로는 이렇게 중괄호 안에 넣는 것을 정말 권장하며, 이것이 Nextflow에 의해 보간되고 있다는 것을 매우 명확하게 합니다.

좋습니다. 따라서 "input greeting"이 ${greeting}으로 들어갑니다. 마지막으로 workflow 수준에서 이 프로세스가 이제 입력을 받는다고 Nextflow에게 알려주어야 합니다. 그리고 그렇게 하기 위해 기본적으로 변수를 제공할 것입니다.

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

Hello World처럼 다시 하드코딩할 수 있으며, 그것은 잘 작동할 것입니다. 하지만 명백히 실제로 어떤 이점도 제공하지 않습니다. 런타임에 구성할 수 있기를 원했으므로 Nextflow를 시작할 때 CLI에서 할 수 있기를 원합니다.

그리고 그렇게 하는 방법은 params라는 특수 Nextflow 개념입니다. params.input이라고 하겠습니다.

이것이 하는 일은 CLI에서 이 input 변수를 노출하는 것이며, Nextflow를 시작할 때 이중 대시를 사용하는 곳입니다.

원하는 대로 부를 수 있으며, hello, greeting이라고 부를 수 있습니다. 상관없습니다. 거기서 하는 것은 무엇이든 파이프라인을 시작할 때 CLI 옵션으로 노출될 것입니다. 그리고 이것은 Nextflow의 진정한 마법 트릭인데, 이 매개변수로 워크플로우 스크립트를 매우 빠르게 구축할 수 있으며, 본질적으로 파이프라인을 위한 사용자 정의 CLI를 구축하여 시작할 때 다양한 옵션을 즉석에서 사용자 정의하기 매우 쉽게 만들기 때문입니다.

그럼 시도해봅시다. 터미널로 돌아갑니다. 여기에 "nextflow run" 명령이 있습니다. 그리고 이제 이전에 본 "params.input"과 일치하는 "--input"을 하겠습니다. 문서에서는 프랑스어로 되어 있다고 생각합니다. Geraldine은 프랑스어를 좋아합니다. 저는 스웨덴에 살기 때문에 스웨덴어로 하겠습니다. "Hej Världen"이라고 하고 엔터를 누르겠습니다.

단일 따옴표나 이중 따옴표를 사용할 수 있으며, Bash가 해석하는 방식에만 영향을 줍니다.

Nextflow 파이프라인을 정확히 같은 방식으로 실행합니다. 작업 디렉토리와 모든 것이 같은 것을 볼 수 있습니다. 하지만 이제 "results/hello_world/output"으로 가면 대신 멋진 스웨덴어를 볼 수 있습니다.

따라서 CLI에서 매개변수로 입력을 동적으로 전달했습니다. 그것을 프로세스에 입력으로 전달했고 프로세스는 그것을 해석하여 script 블록에 넣었으며, 그것이 그 스크립트 결과의 출력을 동적으로 변경했습니다. 꽤 멋집니다.

여기 매우 적은 구문으로 상당히 복잡한 로직입니다. 그리고 이것이 이제 어떻게 확장되기 시작하는지 볼 수 있기를 바랍니다. 그리고 이것이 우리가 실제로 파이프라인의 로직과 사용자 정의 가능성을 Nextflow 스크립트에 구축하는 방법입니다.

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

좋습니다, 훌륭합니다. 하지만 이제 문제는 이 파이프라인을 실행할 때마다 실행하려면 dash, input을 해야 한다는 것입니다.

이 매개변수 없이 실행하려고 하면, 이제 Nextflow는 이 매개변수가 필요했고 설정되지 않았다고 말하며 오류를 발생시킬 것입니다. 그래서 무엇을 해야 할지 몰랐습니다.

그런데 이것은 멋진 새로운 것입니다. 과거에는 Nextflow가 빈 문자열로 실행했을 것이고, 이해하기 어려운 온갖 이상한 오류가 발생했을 것입니다. 하지만 새로운 Nextflow 구문 분석기에서는 조금 더 신중하며 즉시 알려줍니다.

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

이것을 작성할 때 params.input을 사용하는 곳에 바로 넣었다는 것을 알 수 있습니다. 따라서 명백한 해결책은 기본값을 정의하는 것이며, workflow의 특수 params 블록에서 스크립트 상단에서 수행합니다. 이것은 여기 workflow 스크립트에 있습니다.

다시 여기 새로운 구문이 있으므로 주의하세요. 정말 멋진 것입니다. 여기에 예상될 매개변수의 이름이 있습니다.

그리고 이 콜론 문자 뒤에 변수의 타입을 정의하고 있습니다. 이것을 할 필요는 없으며, 그냥 비워둘 수 있지만, 정말 좋습니다. Nextflow에게 문자열을 예상하고 그렇게 처리하라고 알려줍니다.

예를 들어 대신 숫자를 원한다면 float라고 쓸 수 있으며, 그것은 부동 소수점 숫자를 원한다고 말할 것입니다. 그리고 그것으로 실행하려고 하면 오류가 발생할 것입니다. float가 아닌 문자열을 제공하면 말입니다. 그리고 그렇게 전달할 것입니다. string을 하면 문자열이라는 것을 알고 있습니다. 그리고 선행 0이 있고 모두 숫자이더라도 여전히 실제 문자열로 전달할 것입니다.

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

그 다음 등호 기호가 있고 여기에 기본값이 있습니다. Nextflow는 원래 바르셀로나에서 작성되었으므로 기본값으로 스페인어인 "Holà mundo!"가 있는 것이 적절해 보입니다.

스크립트를 저장하고, 돌아가서 --input 없이 스크립트를 다시 실행하겠습니다. 그리고 이번에는 실행되어야 하며 results에 새 파일을 생성할 것입니다. 그리고 이 파일에는 이제 "Holà mundo!"라고 되어 있습니다.

하지만 이것은 단지 기본값일 뿐이므로 이전과 같은 작업을 여전히 할 수 없다는 의미는 아닙니다. 돌아가서 여기 이전 스크립트 "Hej Världen"을 찾으면, 명령줄에서 --input을 하기 때문에 그 기본값을 덮어쓰고 output.txt 파일에서 다시 사용할 것입니다.

따라서 스크립트의 이것은 제가 설정하는 기본값일 뿐입니다.

워크플로우를 더 복잡하게 구축하고 더 많은 매개변수를 포함하면, 스크립트 상단의 이 params 블록이 한 곳에 모두 수집하기 시작할 것입니다.

그리고 스크립트에서 꽤 좋은 대칭을 갖게 되는데, 여기에 모든 워크플로우 입력이 있고 하단에 워크플로우 출력이 있습니다. 그리고 외부 세계에 대한 워크플로우의 인터페이스가 무엇인지 매우 명확합니다. 따라서 새 구문으로 새 파이프라인을 매우 빠르게 파악하고 사용 방법을 이해할 수 있습니다.

마지막으로 멋진 것 하나. 이것으로 기본값을 설정할 필요가 없습니다. params input을 하지만 기본값을 설정하지 않으면, Nextflow에게 이 매개변수가 필수라고 알려주며, 다시 파이프라인은 그것 없이 실행되지 않지만, null에 대한 것보다 더 유용한 오류 메시지를 제공할 것입니다.

따라서 입력이 필요하지만 명령줄에서 지정되지 않았다고 예상한다고 말합니다. 매우 좋습니다.

좋습니다, 이제 변수 입력과 매개변수로 Nextflow 파이프라인을 설정하는 방법, 기본값을 설정하는 방법, 타입을 설정하는 방법, Boolean true false 플래그나 정수 또는 여기 다른 타입이 될 수 있는 방법이 명확해지기를 바랍니다. 워크플로우에 전달하는 방법, 어디를 거쳐가는지, 그 다음 프로세스에 보간되는 방법. 그리고 Nextflow를 시작할 때 명령줄에서 사용자 정의하는 방법도 알고 있습니다. 이것은 간단한 bash 명령보다 더 흥미로워 보이기 시작합니다.

4. 워크플로우 실행 관리

좋습니다. 다음은 무엇일까요? 이 장의 마지막 부분에서는 모든 다양한 워크플로우 실행을 관리하는 방법에 대해 조금 이야기하겠습니다. 여기 사이드바와 work 아래의 탐색기를 보면, 여러 다른 파이프라인을 실행했고 이 work 디렉토리가 꽤 길어지고 있으며, 많이 있습니다.

그리고 다른 것은, 앞서 말했듯이, 이 파이프라인을 다시 실행할 때마다 새로운 work 디렉토리 세트를 생성하고 있으며, 처음부터 모든 프로세스를 다시 실행하고 있는데, 이것은 좋은 일입니다. 의도된 동작입니다. 재현 가능하며 모든 것을 새로 재생성하고 있습니다. 하지만 명백히 매우 오래 실행되는 프로세스를 실행하고 있다면, 중간에 충돌하거나 파이프라인 끝에서 무언가를 변경하는 경우 항상 파이프라인을 처음부터 시작해야 한다면 짜증날 것입니다.

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에 대한 첫 번째 풀 리퀘스트를 받는 정말 좋은 방법입니다.

어쨌든, 그렇게 했고 돌아가서 이 워크플로우 실행의 캐시된 결과를 보고, 여전히 재사용할 수 있다는 것을 깨달았고, 그렇게 했습니다. 따라서 다시 캐시된 결과를 얻었습니다.

4.3. 이전 work 디렉토리 삭제

좋습니다. 이 work 디렉토리를 정리하고 싶다면 어떻게 할까요? 여기에 많이 있습니다. 파일이 많습니다. 아마도 마지막 몇 번의 파이프라인 실행에서 재개하고 싶다는 것을 확실히 알고 있지만, 그 전의 모든 것은 신경 쓰지 않습니다.

그러면 여기서 하나를 선택할 수 있고 다른 Nextflow 명령인 "nextflow clean"을 사용할 수 있으며, "nextflow clean"을 할 수 있습니다. "-before"를 하고, 이 경우 reverent_pike인 특정 실행 이름을 하고 "-n"을 하겠습니다. 이것은 Nextflow에게 드라이 런만 하라고 알려줍니다. 따라서 실제로 아무것도 하지 않고 무엇을 삭제할지만 알려줍니다. 따라서 이 work 디렉토리를 제거할 것입니다.

합리적으로 보입니다. 따라서 같은 명령을 다시 하겠지만 "-n" 대신 "-f"를 하여 실제로 정리를 수행하겠습니다. 그리고 이번에는 실제로 이 모든 디렉토리를 제거했습니다. 그리고 들어가서 work 디렉토리를 보면, 이제 훨씬 가벼워 보입니다. 훌륭합니다.

따라서 캐시를 완전히 파괴하지 않고 꽤 안전한 방식으로 모든 로컬 work 디렉토리를 정리하는 방법입니다. 따라서 원한다면 여전히 재개할 수 있습니다.

이 플래그가 무엇인지 잊어버린 경우 모든 Nextflow 명령에 대해 "nextflow help"를 한 다음 명령 이름을 할 수 있습니다. "nextflow help clean"을 하면 모든 다양한 옵션을 볼 수 있습니다: -after, -before, -but, 이 정리 동작을 구성하는 모든 다양한 방법. 꽤 멋집니다.

핵심 정리

좋습니다, Hello Nextflow의 파트 1의 끝입니다. 과정의 시작으로는 꽤 강렬하지만, 이제 Nextflow 스크립트가 어떻게 생겼는지에 대한 꽤 좋은 이해를 갖게 되기를 바랍니다. 프로세스, 워크플로우, 출력 및 매개변수와 같은 다양한 핵심 부분. 명령줄에서 기본 재정의로 구성하는 방법, 동적 script 블록으로 동적 input 블록을 만드는 방법을 알고 있으며, 모든 워크로드 실행을 관리하는 방법을 알고 있습니다: 이미 실행한 것 보기, 재개, 정리. 많은 것들이 있습니다. 먼 길을 왔습니다. 따라서 휴식을 취하고 잠깐 산책하고 차 한 잔을 마시고 싶다면, 지금이 아마도 좋은 시간일 것입니다. 그럴 자격이 있습니다.

여기서부터는 기본적으로 이 기초 위에 구축하고 있습니다. 어떻게 더 복잡하고 더 강력하게 만들 수 있을까요? 어떻게 더 유연하게 만들 수 있을까요? 대규모로 분석을 수행하기 위해 원하는 작업을 수행합니다.

퀴즈

이제 웹페이지의 파트 1, hello world로 스크롤하면 작은 퀴즈가 보일 것이며, 이것은 이 버전의 Nextflow 교육을 위해 새로 만든 것입니다. 그리고 이 장에서 수행한 모든 자료를 이해했는지 확인하기 위해 스스로 퀴즈를 풀 수 있습니다.

이것은 우리에게 전송되거나 하지 않으며, 브라우저에만 저장됩니다. 따라서 우리는 여러분의 답변이 무엇인지 모르지만, 아무것도 놓치지 않았거나 오해하지 않았는지 확인하기 위한 작은 자가 점검일 뿐입니다. 그리고 원하는 만큼 여러 번 시도할 수 있습니다.

저처럼 VS Code 인스턴스의 터미널에 머물고 싶다면, quiz 명령을 입력한 다음 어느 장에 있는지 알려주기만 하면 됩니다. 따라서 "Hello World"를 하면, 웹 브라우저에 있는 것과 정확히 같은 퀴즈 질문을 터미널에서 할 수 있습니다.

멋집니다. 좋습니다. 즐기시기 바라며, 조금 재미있게 보내시고, 잠시 후 다음 장에서 Nextflow 채널에 대해 이야기하기 위해 뵙겠습니다.