부록 E24: 대규모 데이터 처리와 재현성

6 분 소요

이 장에서 배울 것

이번 장에서는 대규모 데이터 처리와 재현성(reproducibility)을 배웁니다. 재현성은 같은 데이터와 같은 절차를 사용했을 때 같은 결과를 다시 얻을 수 있는 성질입니다. 생물정보학에서 재현성은 선택이 아니라 연구 신뢰도의 핵심입니다.

핵심 용어를 먼저 정리하겠습니다.

원본 데이터(raw data): 분석을 시작하기 전의 최초 데이터입니다.
처리 데이터(processed data): 원본 데이터를 정리하거나 변환해 만든 데이터입니다.
메타데이터(metadata): 데이터에 대한 설명 정보입니다. 예를 들어 샘플 ID, 조직, 조건, 날짜가 있습니다.
데이터 출처(provenance): 데이터가 어디서 왔고 어떤 과정을 거쳐 만들어졌는지에 대한 기록입니다.
체크섬(checksum): 파일이 바뀌지 않았는지 확인하는 짧은 계산값입니다.
압축(compression): 파일 크기를 줄이는 방식입니다.
스트리밍(streaming): 큰 파일을 한 번에 다 올리지 않고 조금씩 읽는 방식입니다.
병렬 처리(parallel processing): 여러 작업을 동시에 실행하는 방식입니다.
무작위 시드(random seed): 무작위 계산을 다시 같은 방식으로 만들기 위해 고정하는 값입니다.

대규모 데이터 처리와 재현성

가장 쉬운 비유: 요리 대회 재현

어떤 요리가 맛있게 나왔는데 레시피, 재료 출처, 조리 시간, 오븐 온도를 아무것도 기록하지 않았다면 다시 만들기 어렵습니다. 분석도 같습니다. 결과 그림이 좋아 보여도 데이터, 코드, 환경, 실행 순서가 기록되지 않으면 믿기 어렵습니다.

원본 데이터는 함부로 덮어쓰지 않습니다

원본 데이터는 실험이나 공개 데이터베이스에서 받은 최초 상태입니다. 이 파일은 되도록 읽기 전용처럼 다루는 것이 좋습니다.

data/raw/        원본 데이터
data/processed/  처리 데이터
results/         분석 결과
scripts/         분석 코드
reports/         보고서

원본을 직접 수정하면 나중에 어떤 처리를 했는지 추적하기 어렵습니다. 처리 결과는 별도 폴더에 저장하는 습관이 좋습니다.

메타데이터 없이는 데이터가 반쪽입니다

유전자 발현 행렬만 있으면 숫자는 많지만 의미가 부족합니다. 샘플이 암인지 정상인지, 어떤 조직인지, 어떤 배치에서 실험했는지, 어떤 날짜에 만들어졌는지 알아야 해석할 수 있습니다.

sample_id   condition   tissue   batch
S1          normal      liver    B1
S2          cancer      liver    B1
S3          cancer      lung     B2

메타데이터가 부정확하면 좋은 알고리즘도 잘못된 결론을 낼 수 있습니다.

체크섬은 파일 지문입니다

큰 파일은 전송 중 깨지거나 잘못 복사될 수 있습니다. 체크섬은 파일 내용으로 계산한 짧은 값입니다. 파일이 조금만 바뀌어도 체크섬이 달라집니다.

md5sum sample.fastq.gz

이 명령은 파일의 MD5 체크섬을 계산합니다. 공개 데이터베이스에서 제공하는 체크섬과 비교하면 파일이 제대로 내려받아졌는지 확인할 수 있습니다.

큰 파일은 조금씩 읽어야 합니다

작은 CSV는 한 번에 메모리에 올려도 됩니다. 하지만 수십 GB 파일을 한 번에 읽으려 하면 메모리가 터질 수 있습니다. 이때는 스트리밍이나 청크(chunk) 단위 처리가 필요합니다.

import pandas as pd

for chunk in pd.read_csv("large_table.csv", chunksize=10000):
    print(chunk.shape)

이 코드는 큰 CSV를 1만 행씩 나눠 읽습니다. 한 번에 전체 파일을 올리지 않으므로 메모리 부담이 줄어듭니다.

병렬 처리는 빠르지만 조심해야 합니다

샘플 100개를 하나씩 처리하면 오래 걸립니다. 여러 CPU를 사용하면 동시에 처리할 수 있습니다. 하지만 병렬 처리는 자원 사용량을 늘립니다. CPU를 16개 쓴다고 항상 16배 빨라지는 것은 아니고, 메모리나 디스크 속도가 병목이 될 수 있습니다.

빠른 실행 = CPU 수만의 문제가 아님
메모리, 디스크, 네트워크, 알고리즘도 함께 중요함

무작위 시드는 결과 재현에 중요합니다

클러스터링, 머신러닝, 데이터 분할에는 무작위성이 들어갈 수 있습니다. 같은 코드를 실행했는데 결과가 조금씩 달라질 수 있습니다. 이때 무작위 시드를 고정하면 같은 무작위 선택을 다시 만들 수 있습니다.

import numpy as np

np.random.seed(42)

시드는 마법이 아닙니다. 모든 도구와 모든 병렬 환경에서 완벽한 재현을 보장하지는 않지만, 재현성을 높이는 기본 습관입니다.

재현 가능한 분석의 최소 구성

재현 가능한 분석에는 최소한 다음이 필요합니다.

1. 원본 데이터 위치와 버전
2. 메타데이터
3. 분석 코드
4. 실행 환경
5. 파이프라인 또는 실행 순서
6. 주요 파라미터
7. 결과 파일과 보고서

이 중 하나라도 빠지면 나중에 같은 결과를 만들기 어려울 수 있습니다.

노트북과 스크립트의 균형

주피터 노트북은 탐색과 설명에 좋습니다. 하지만 실행 순서가 꼬이면 숨은 상태 때문에 결과가 달라질 수 있습니다. 중요한 최종 분석은 스크립트나 워크플로우로 정리하고, 노트북은 보고서나 탐색용으로 쓰는 것이 안전합니다.

실전 보강: chunk와 메모리 계산

큰 파일을 한 번에 메모리에 올리면 실패할 수 있습니다. 그래서 일정한 크기로 나눠 읽습니다.

전체 파일 크기 = 50GB
한 번에 읽는 chunk = 1GB
필요한 chunk 수 = 50 / 1 = 50개

chunk 처리는 느려 보일 수 있지만, 메모리 부족으로 작업이 죽는 것보다 훨씬 안전합니다. pandas에서도 chunksize를 사용하면 큰 CSV를 조금씩 읽을 수 있습니다.

for chunk in pd.read_csv("large_counts.csv", chunksize=100000):
    process(chunk)

실전 보강: 병렬 처리와 재현성 체크리스트

병렬 처리는 여러 작업을 동시에 실행해 시간을 줄일 수 있습니다. 하지만 각 작업이 4GB 메모리를 쓰고 8개를 동시에 실행하면 필요한 메모리는 대략 다음과 같습니다.

4GB × 8 = 32GB

CPU만 보고 병렬 수를 늘리면 메모리나 디스크가 먼저 터질 수 있습니다.

재현 가능한 분석을 남기려면 최소한 다음을 기록해야 합니다.

원본 데이터 위치와 checksum
메타데이터와 샘플 제외 기준
코드 버전 또는 commit hash
실행 환경과 패키지 버전
워크플로우/스크립트 실행 명령
주요 파라미터
최종 결과 파일과 생성 날짜

초보자가 자주 하는 오해

오해 1: random seed만 고정하면 완전 재현된다. 데이터, 코드, 환경, 병렬 처리 방식도 영향을 줍니다.
오해 2: 노트북 파일 하나만 있으면 충분하다. 실행 순서가 꼬이면 위에서 아래로 다시 실행했을 때 다른 결과가 나올 수 있습니다.
오해 3: raw data를 조금 고쳐도 괜찮다. 원본을 덮어쓰면 추적이 끊깁니다.
오해 4: checksum은 보안 전문가용이다. 큰 생물정보학 파일이 제대로 복사됐는지 확인하는 기본 도구입니다.

이전 개념과 다음 개념의 연결

이 장은 부록 E의 마무리입니다. E19 Git은 코드 기록, E20 환경관리는 실행 조건, E21 워크플로우는 절차, E22 HPC/클라우드는 계산 자원, E23 소프트웨어 공학은 안전한 코드 작성으로 이어집니다. 이 요소들이 함께 있어야 분석 결과를 다시 만들 수 있습니다.

생물정보학에서 왜 중요한가

생물정보학 연구는 데이터가 크고 단계가 많으며, 도구 버전도 자주 바뀝니다. 재현성 없이는 결과를 검증하기 어렵고, 논문 심사나 협업에서도 신뢰를 얻기 어렵습니다. 재현성은 연구자의 양심이 아니라 연구 방법의 일부입니다.

어려운 개념 보강: 재현성 최소 세트와 provenance를 점검표로 만들기

재현성은 “코드를 저장했다”만으로 충분하지 않습니다. 같은 결과를 다시 만들려면 최소한 데이터, 코드, 환경, 실행 순서, 결과 해석 기록이 함께 있어야 합니다.

가장 작은 재현성 세트는 다음처럼 생각할 수 있습니다.

1. 원본 데이터 위치와 체크섬
2. metadata table
3. 실행 코드 또는 workflow 파일
4. environment.yml 또는 Dockerfile
5. 실행 명령어와 실행 날짜
6. 주요 결과 파일
7. README 또는 재현성 보고서

provenance는 데이터의 이력입니다. 즉, “이 파일이 어디서 와서 어떤 과정을 거쳐 만들어졌는가”를 기록하는 것입니다.

raw FASTQ
→ trimming
→ trimmed FASTQ
→ alignment
→ BAM
→ counting
→ count matrix
→ differential expression
→ result table

각 화살표마다 사용한 도구, 버전, 명령어, 입력 파일, 출력 파일이 기록되어야 나중에 추적할 수 있습니다.

체크섬은 파일의 지문입니다. 예를 들어 원본 FASTQ를 내려받은 직후 체크섬을 기록해 두면, 나중에 파일이 바뀌었는지 확인할 수 있습니다.

sha256sum sample.fastq.gz > checksums.txt
sha256sum -c checksums.txt

첫 줄은 현재 파일의 체크섬을 저장하고, 둘째 줄은 나중에 같은 파일인지 검사합니다. MD5도 많이 쓰이지만, 새로 기록할 때는 SHA-256처럼 더 강한 해시를 쓰는 편이 좋습니다.

README에는 사람이 다시 실행할 수 있는 문장이 있어야 합니다. 예를 들어 다음 질문에 답해야 합니다.

이 프로젝트의 목적은 무엇인가?
원본 데이터는 어디에 있는가?
어떤 순서로 실행하는가?
필요한 환경은 어떻게 만드는가?
최종 결과 파일은 무엇인가?
주의해야 할 제한점은 무엇인가?

흔한 오해는 결과 파일만 잘 보관하면 충분하다고 생각하는 것입니다. 결과 파일은 중요하지만, 원본 데이터와 절차가 없으면 그 결과가 어떻게 만들어졌는지 검증하기 어렵습니다. 생물정보학에서 재현성은 친절한 문서화가 아니라 연구 결과를 믿을 수 있게 만드는 안전장치입니다.

미니 실습 블록: checksum과 README로 분석 재현성 점검하기

이 실습은 checksum과 README로 분석 재현성 점검하기를 직접 손으로 확인하는 연습입니다. 왜 필요한가 하면, 원본 파일이 바뀌지 않았는지 확인하고, 다른 사람이 분석을 다시 실행할 수 있게 최소 정보를 남겨야 하기 때문입니다.

sha256sum data/raw/sample01_R1.fastq.gz > checksums.txt
sha256sum -c checksums.txt

cat > README.md <<'EOF'
# RNA-seq mini project

## Input
- data/raw/sample01_R1.fastq.gz
- data/raw/metadata.tsv

## Environment
- environment.yml

## Run
snakemake -j 4

## Output
- results/counts.tsv
- figures/pca.png
EOF

각 코드 요소의 의미를 풀어보면 다음과 같습니다. checksum은 파일 내용의 지문입니다. 같은 파일이면 같은 checksum이 나오고, 한 글자라도 바뀌면 값이 달라집니다. README는 입력, 환경, 실행법, 출력을 설명합니다.

생물정보학/계산생물학에서 쓰이는 장면은 분명합니다. 논문 보충자료, 분석 인수인계, 장기 프로젝트 보관에서 필수에 가깝습니다.

흔한 오해 또는 주의점도 있습니다. 결과 파일만 보관하고 원본, 코드, 환경, 실행 명령을 잃어버리면 재현 가능한 분석이라고 보기 어렵습니다.

핵심 정리

대규모 데이터 처리에서는 원본 데이터 보존, 메타데이터 관리, 체크섬 확인, 청크 처리, 병렬 처리, 환경 기록이 중요합니다. 재현 가능한 분석은 데이터, 코드, 환경, 실행 순서, 결과를 함께 남기는 분석입니다.

Gemini AI 채점

주관식 답안은 Gemini API로 채점합니다. API 키는 이 브라우저에만 저장됩니다.

API KEY 미등록

1. [객관식] 객관식

재현성(reproducibility)의 설명으로 적절한 것은?

선택지 같은 데이터와 절차로 같은 결과를 다시 얻을 수 있는 성질입니다. 단백질을 접는 힘입니다. raw data를 덮어써도 처리 과정을 나중에 항상 복원할 수 있다는 해석 random seed만 고정하면 데이터와 환경이 달라도 완전 재현된다는 해석
2. [객관식] 객관식

원본 데이터(raw data)의 설명으로 적절한 것은?

선택지 항상 최종 그림 파일입니다. 테스트 코드입니다. 분석을 시작하기 전의 최초 데이터입니다. Git 커밋 메시지입니다.
3. [객관식] 객관식

처리 데이터(processed data)의 설명으로 적절한 것은?

선택지 항상 삭제해야 하는 파일입니다. 원본 데이터를 정리하거나 변환해 만든 데이터입니다. chunk 처리는 메모리 사용량과 무관한 파일 이름 변경이라고 보는 해석 CPU의 물리적 위치입니다.
4. [객관식] 객관식

메타데이터(metadata)의 예로 적절한 것은?

선택지 체크섬 불일치를 무시해도 파일 무결성에는 문제가 없다고 보는 해석 마우스 소리입니다. 의자 높이만입니다. 샘플 ID, 조직, 조건, 배치 정보입니다.
5. [객관식] 객관식

데이터 출처(provenance)의 의미로 적절한 것은?

선택지 단백질의 알파나선입니다. SQL의 WHERE 절입니다. 병렬 작업 수만 늘리면 메모리와 디스크 I/O 제한은 사라진다는 해석 데이터가 어디서 왔고 어떤 과정을 거쳤는지에 대한 기록입니다.
6. [객관식] 객관식

체크섬(checksum)의 역할은?

선택지 유전자를 단백질로 바꿉니다. 파일이 바뀌지 않았는지 확인하는 짧은 계산값입니다. 서버 비용을 결제합니다. 그래프 축 이름입니다.
7. [객관식] 객관식

md5sum sample.fastq.gz의 역할로 적절한 것은?

선택지 노트북 셀 실행 순서가 결과 재현성과 무관하다고 보는 해석 SQL 테이블을 조인합니다. 파일의 MD5 체크섬을 계산합니다. raw data를 덮어써도 처리 과정을 나중에 항상 복원할 수 있다는 해석
8. [객관식] 객관식

압축(compression)의 설명으로 적절한 것은?

선택지 파일 크기를 줄이는 방식입니다. 파일 의미를 완전히 없애는 방식입니다. 유전자를 발현시키는 실험입니다. HPC 작업 취소 명령입니다.
9. [객관식] 객관식

스트리밍(streaming)의 설명으로 적절한 것은?

선택지 모든 데이터를 동시에 삭제하는 방식입니다. DNA를 RNA로 바꾸는 방식입니다. 큰 파일을 한 번에 다 올리지 않고 조금씩 읽는 방식입니다. random seed만 고정하면 데이터와 환경이 달라도 완전 재현된다는 해석
10. [객관식] 객관식

pd.read_csv(..., chunksize=10000)의 의미로 적절한 것은?

선택지 CSV를 1만 행씩 나누어 읽는 것입니다. CSV를 단백질로 변환합니다. 파일을 GitHub에 push합니다. chunk 처리는 메모리 사용량과 무관한 파일 이름 변경이라고 보는 해석
11. [객관식] 객관식

병렬 처리(parallel processing)의 설명으로 적절한 것은?

선택지 작업을 항상 하나씩만 실행하는 방식입니다. 모든 파일을 원본으로 되돌리는 방식입니다. 세포를 염색하는 방식입니다. 여러 작업을 동시에 실행하는 방식입니다.
12. [객관식] 객관식

병렬 처리가 항상 CPU 수만큼 빨라지지 않는 이유는?

선택지 컴퓨터는 동시에 아무 일도 못 하기 때문입니다. 메모리, 디스크, 네트워크, 알고리즘이 병목이 될 수 있기 때문입니다. 파일은 항상 0바이트이기 때문입니다. pandas는 숫자를 못 읽기 때문입니다.
13. [객관식] 객관식

무작위 시드(random seed)의 역할은?

선택지 서버의 물리적 위치입니다. 무작위 계산을 다시 같은 방식으로 만들기 위해 고정하는 값입니다. 단백질의 질량입니다. SQL 테이블 이름입니다.
14. [객관식] 객관식

np.random.seed(42)의 의미로 적절한 것은?

선택지 Git 저장소를 초기화합니다. BAM 파일을 정렬합니다. API 요청을 보냅니다. numpy의 무작위 선택을 재현 가능하게 고정합니다.
15. [객관식] 객관식

원본 데이터를 함부로 덮어쓰면 안 되는 이유는?

선택지 처리 과정을 추적하거나 다시 시작하기 어려워지기 때문입니다. 원본 데이터는 항상 틀렸기 때문입니다. 파일 크기가 너무 작기 때문입니다. Git이 원본을 싫어하기 때문입니다.
16. [객관식] 객관식

data/raw, data/processed, results를 나누는 이유는?

선택지 모든 파일을 숨기기 위해서입니다. CPU를 늘리기 위해서입니다. 원본, 처리 데이터, 결과를 구분해 추적하기 위해서입니다. 체크섬 불일치를 무시해도 파일 무결성에는 문제가 없다고 보는 해석
17. [객관식] 객관식

메타데이터가 없으면 생기는 문제는?

선택지 항상 분석이 더 쉬워집니다. 병렬 작업 수만 늘리면 메모리와 디스크 I/O 제한은 사라진다는 해석 파일이 압축되지 않습니다. 숫자 데이터가 어떤 샘플과 조건을 뜻하는지 해석하기 어렵습니다.
18. [객관식] 객관식

재현 가능한 분석의 최소 구성으로 적절한 것은?

선택지 노트북 셀 실행 순서가 결과 재현성과 무관하다고 보는 해석 원본 데이터, 메타데이터, 코드, 환경, 실행 순서, 결과 기록입니다. 커밋 메시지 없이 결과 그림만입니다. 비밀번호와 개인 정보 공개입니다.
19. [객관식] 객관식

주피터 노트북만으로 최종 분석을 관리할 때 주의할 점은?

선택지 노트북은 절대 코드를 실행하지 못합니다. 노트북은 텍스트를 쓸 수 없습니다. 실행 순서가 꼬이면 숨은 상태 때문에 결과가 달라질 수 있습니다. 노트북은 그림을 못 그립니다.
20. [객관식] 객관식

재현성이 연구 신뢰도와 연결되는 이유는?

선택지 다른 사람이나 미래의 내가 같은 절차로 결과를 검증할 수 있어야 하기 때문입니다. 결과를 숨기기 위해서입니다. 분석 기록을 없애기 위해서입니다. 서버 비용을 늘리기 위해서입니다.
21. [객관식] 객관식

50GB 파일을 1GB chunk로 읽으면 chunk 수는?

선택지 50개 5개 100개 500개
22. [객관식] 객관식

각 병렬 작업이 4GB 메모리를 쓰고 8개를 동시에 실행하면 필요한 메모리는 대략?

선택지 4GB 8GB 32GB 12GB
23. [객관식] 객관식

체크섬이 공개 데이터베이스 제공값과 다르면 가장 적절한 판단은?

선택지 항상 더 좋은 파일이라는 뜻이다. 파일이 잘못 다운로드되었거나 변경되었을 가능성을 의심한다. 체크섬은 비교하면 안 된다. 파일을 그대로 논문에 사용한다.
24. [객관식] 객관식

raw data를 직접 덮어쓰면 생기는 문제는?

선택지 재현성이 자동으로 좋아진다. 파일 크기가 항상 줄어든다. checksum이 영원히 고정된다. 원본 상태와 처리 과정을 추적하기 어려워진다.
25. [객관식] 객관식

random seed를 고정해도 완전 재현이 보장되지 않을 수 있는 이유는?

선택지 데이터, 코드, 환경, 병렬 처리 방식 등 다른 요소도 결과에 영향을 줄 수 있기 때문이다. seed는 숫자가 아니기 때문이다. seed는 FASTQ에서만 쓰기 때문이다. seed를 쓰면 항상 오류가 나기 때문이다.
26. [객관식] 객관식

pandas에서 큰 CSV를 조금씩 처리하는 코드로 가장 적절한 것은?

선택지 `pd.read_csv("file.csv", all_memory=True)` `for chunk in print("file.csv"):` `for chunk in pd.read_csv("file.csv", chunksize=100000): ...` `pd.delete_csv("file.csv")`
27. [객관식] 객관식

재현 가능한 분석 패키지에 포함되어야 할 것으로 가장 적절한 조합은?

선택지 최종 그림만 데이터 출처/checksum, 코드 버전, 환경, 파라미터, 실행 명령, 결과 분석자의 기억만 파일 이름 없이 압축 파일 하나만
28. [객관식] 객관식

노트북 분석에서 실행 순서가 꼬이면 생기는 문제는?

선택지 노트북은 항상 순서를 자동 보장한다. 실행 순서는 결과와 무관하다. 셀을 많이 만들수록 재현성이 무조건 좋아진다. 위에서 아래로 다시 실행했을 때 다른 결과가 나오거나 오류가 날 수 있다.
29. [객관식] 객관식

압축 파일을 사용할 때 주의할 점으로 적절한 것은?

선택지 압축하면 파일 내용이 생물학적으로 변한다. 압축 파일은 checksum을 계산할 수 없다. raw data를 덮어써도 처리 과정을 나중에 항상 복원할 수 있다는 해석 압축 여부와 파일 형식을 도구가 지원하는지 확인한다.
30. [객관식] 객관식

대규모 데이터에서 병렬 처리 수를 늘릴 때 CPU 외에 함께 봐야 할 것은?

선택지 파일명 글자 수만 메모리, 디스크 I/O, 임시 저장공간, 도구의 병렬 지원 여부 README의 제목 길이만 random seed만 고정하면 데이터와 환경이 달라도 완전 재현된다는 해석
31. [실전] 객관식

checksum을 저장하는 주된 이유는?

선택지 원본 데이터를 덮어써서 파일 수를 줄이는 것이다. 분석 결과를 해석 없이 바로 생물학적 결론으로 확정하는 것이다. 원본 파일이 분석 전후로 바뀌지 않았는지 확인하기 위해서다. 샘플 ID와 파일명을 일부러 무작위로 바꾸는 것이다.
32. [실전] 객관식

재현 가능한 분석 README에 최소한 들어가야 할 정보로 적절한 것은?

선택지 원본 데이터를 덮어써서 파일 수를 줄이는 것이다. 분석 결과를 해석 없이 바로 생물학적 결론으로 확정하는 것이다. 샘플 ID와 파일명을 일부러 무작위로 바꾸는 것이다. 입력 파일, 실행 환경, 실행 명령, 주요 출력 파일
주관식 33. [응용] 주관식 · Gemini 채점

재현성을 요리 레시피 비유로 설명하라.
주관식 34. [응용] 주관식 · Gemini 채점

원본 데이터와 처리 데이터를 분리해야 하는 이유를 설명하라.
주관식 35. [응용] 주관식 · Gemini 채점

메타데이터가 생물정보학 분석에서 중요한 이유를 설명하라.
주관식 36. [응용] 주관식 · Gemini 채점

체크섬이 파일 관리에 유용한 이유를 설명하라.
주관식 37. [응용] 주관식 · Gemini 채점

큰 CSV를 chunksize로 읽는 이유를 설명하라.
주관식 38. [응용] 주관식 · Gemini 채점

재현 가능한 분석을 위해 남겨야 할 최소 기록을 설명하라.
주관식 39. [응용] 주관식 · Gemini 채점

50GB 파일을 1GB chunk로 읽는 경우 chunk 수를 계산하고, chunk 처리가 메모리 문제를 줄이는 이유를 설명하라.
주관식 40. [응용] 주관식 · Gemini 채점

재현 가능한 생물정보학 분석을 위해 데이터, 코드, 환경, 실행 기록 측면의 체크리스트를 작성하라.
주관식 41. [실습] 주관식 · Gemini 채점

원본 FASTQ의 SHA256 checksum을 만들고 나중에 검증하는 명령어를 작성하라.
주관식 42. [실습] 주관식 · Gemini 채점

재현 가능한 분석을 위해 함께 보관해야 할 최소 파일 목록을 작성하라.