목차

5 분 소요

이 장에서 배울 것

이번 장에서는 HPC와 클라우드(cloud)를 배웁니다. HPC는 고성능 컴퓨팅(high-performance computing)의 약자입니다. 많은 CPU, 큰 메모리, 큰 저장공간을 가진 공용 계산 장비라고 생각하면 됩니다. 클라우드는 AWS, Google Cloud, Azure처럼 인터넷으로 서버와 저장공간을 빌려 쓰는 방식입니다.

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

  • HPC: 연구기관이나 대학에서 운영하는 고성능 계산 클러스터입니다.
  • 클러스터(cluster): 여러 컴퓨터 노드를 묶어 큰 계산 자원처럼 쓰는 시스템입니다.
  • 노드(node): 클러스터 안의 개별 서버입니다.
  • 작업(job): 클러스터에 제출하는 계산 요청입니다.
  • 스케줄러(scheduler): 여러 사용자의 작업을 줄 세우고 자원을 배정하는 시스템입니다.
  • SLURM: HPC에서 자주 쓰이는 작업 스케줄러입니다. 앞으로는 SLURM이라고 부르겠습니다.
  • CPU: 일반 계산을 수행하는 장치입니다.
  • GPU: 딥러닝처럼 병렬 계산이 많은 작업에 유용한 장치입니다.
  • 메모리(memory): 프로그램이 실행 중 데이터를 올려 두는 작업 공간입니다.
  • walltime: 작업이 실행될 최대 시간 제한입니다.

HPC와 클라우드

가장 쉬운 비유: 개인 책상과 공동 작업장

노트북은 개인 책상입니다. 작은 계산은 충분히 할 수 있습니다. 하지만 유전체 데이터 수십 개를 정렬하거나, 단일세포 데이터 수백만 개를 처리하거나, 딥러닝 모델을 학습하려면 개인 책상으로 부족합니다.

HPC는 대학이나 연구소의 공동 작업장입니다. 여러 사람이 함께 쓰기 때문에 작업을 마음대로 바로 실행하지 않고, 스케줄러에 제출합니다.

SLURM 작업 제출의 기본

SLURM에서는 보통 작업 스크립트를 작성한 뒤 제출합니다.

#!/bin/bash
#SBATCH --job-name=rnaseq_qc
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G
#SBATCH --time=02:00:00

fastqc sample.fastq.gz

이 스크립트는 CPU 4개, 메모리 16GB, 최대 2시간을 요청하고 fastqc를 실행합니다. 제출은 다음처럼 합니다.

sbatch job.sh

작업 목록은 다음 명령으로 볼 수 있습니다.

squeue

작업을 취소할 때는 다음처럼 합니다.

scancel JOB_ID

자원 요청은 너무 작아도, 너무 커도 문제입니다

메모리를 너무 적게 요청하면 작업이 중간에 죽을 수 있습니다. 반대로 너무 크게 요청하면 대기 시간이 길어지고 공동 자원을 낭비합니다. 그래서 처음에는 작은 테스트 데이터로 필요한 자원을 대략 확인하고, 실제 분석에서 적절하게 요청하는 습관이 중요합니다.

예를 들어 1개 샘플 FASTQC에는 큰 메모리가 필요하지 않지만, 큰 단일세포 행렬을 처리할 때는 메모리가 많이 필요할 수 있습니다.

클라우드는 빌려 쓰는 계산 자원입니다

클라우드는 필요한 만큼 서버를 만들고 사용한 만큼 비용을 내는 방식입니다. 장점은 유연성입니다. 갑자기 큰 GPU가 필요하면 빌릴 수 있습니다. 단점은 비용 관리입니다. 서버를 켜 둔 채 잊으면 돈이 계속 나갈 수 있습니다.

클라우드에서 중요한 것은 계산 비용뿐 아니라 저장 비용과 데이터 이동 비용입니다. 유전체 데이터는 크기 때문에 업로드, 다운로드, 장기 저장 비용도 생각해야 합니다.

HPC와 클라우드의 차이

HPC는 보통 기관에서 제공하는 공용 자원입니다. 사용 규칙이 있고, 작업을 줄 서서 실행합니다. 클라우드는 필요한 자원을 직접 빌리는 방식입니다. 자유도는 높지만 비용 책임도 큽니다.

HPC: 연구기관의 공동 계산 자원
클라우드: 인터넷으로 빌려 쓰는 계산 자원

둘 중 하나만 정답은 아닙니다. 연구실 환경, 데이터 보안, 비용, 분석 규모에 따라 선택합니다.

데이터 보안과 권한

인간 유전체 데이터, 임상 데이터, 환자 정보는 민감할 수 있습니다. HPC나 클라우드에 데이터를 올릴 때는 기관 규정, 접근 권한, 암호화, 데이터 반출 규칙을 확인해야 합니다. 계산을 잘하는 것보다 먼저 데이터를 안전하게 다루는 태도가 중요합니다.

실전 보강: CPU, 메모리, walltime을 숫자로 읽기

SLURM 스크립트의 자원 요청은 계산 자원 계약서와 비슷합니다.

#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --time=04:00:00

이 요청은 CPU 8개, 메모리 32GB, 최대 실행 시간 4시간을 뜻합니다. 프로그램이 32GB보다 많은 메모리를 쓰면 작업이 죽을 수 있고, 4시간을 넘으면 아직 계산 중이어도 종료될 수 있습니다.

자원을 무조건 크게 요청하는 것도 답은 아닙니다. 실제로 4GB만 쓰는 작업에 128GB를 요청하면 대기 시간이 길어지고 공동 자원을 낭비합니다.

실전 보강: CPU를 늘려도 항상 빨라지지 않는다

어떤 프로그램은 여러 CPU를 잘 사용하지만, 어떤 프로그램은 CPU 1개만 사용합니다. CPU 8개를 요청해도 프로그램이 병렬 처리를 지원하지 않으면 7개는 놀 수 있습니다.

저장공간도 계산 자원입니다. 샘플 20개가 각각 임시 파일 8GB를 만들면 필요한 임시 저장공간은 다음과 같습니다.

20 × 8GB = 160GB

중간 파일까지 고려하지 않으면 작업 중간에 디스크가 꽉 차 실패할 수 있습니다.

초보자가 자주 하는 오해

  • 오해 1: CPU를 많이 요청하면 무조건 빨라진다. 프로그램이 병렬 처리를 지원해야 합니다.
  • 오해 2: 메모리 부족과 시간 초과는 같은 문제다. 하나는 작업 공간 부족, 다른 하나는 제한 시간 초과입니다.
  • 오해 3: 클라우드는 싸고 무제한이다. 켜 둔 시간, 저장공간, 데이터 전송에 비용이 듭니다.
  • 오해 4: GPU는 모든 계산을 빠르게 한다. 딥러닝처럼 GPU에 맞는 계산에서 특히 유용합니다.

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

HPC와 클라우드는 E13~E15의 대용량 분석, E16의 복잡도, E21 워크플로우 실행과 직접 연결됩니다. 어떤 자원을 요청할지는 알고리즘, 데이터 크기, 워크플로우 구조를 함께 보고 결정해야 합니다.

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

생물정보학 데이터는 점점 커지고 있습니다. 노트북에서 연습은 할 수 있지만, 실제 연구에서는 서버, HPC, 클라우드를 써야 하는 상황이 많습니다. 그래서 작업 제출, 자원 요청, 로그 확인, 비용 관리, 데이터 보안은 연구자의 기본기가 됩니다.

어려운 개념 보강: CPU, 메모리, walltime 요청을 계산 감각으로 잡기

HPC 작업 스크립트에서 자원 요청은 감으로만 쓰면 안 됩니다. 너무 작게 쓰면 작업이 죽고, 너무 크게 쓰면 대기 시간이 길어지거나 공동 자원을 낭비합니다. 입문 단계에서는 “작은 테스트 → 사용량 확인 → 본 작업 요청” 순서로 접근하면 됩니다.

SLURM 예시를 다시 봅시다.

#SBATCH --cpus-per-task=4
#SBATCH --mem=16G
#SBATCH --time=02:00:00

각 줄의 의미는 다음과 같습니다.

  • --cpus-per-task=4: 이 작업 하나에 CPU core 4개를 요청합니다.
  • --mem=16G: 작업 전체에 메모리 16GB를 요청합니다.
  • --time=02:00:00: 최대 2시간 동안 실행되게 요청합니다.

간단한 계산 예시를 봅시다. 샘플 1개를 처리할 때 메모리 3GB 정도가 필요하고, 동시에 샘플 4개를 처리하려고 한다면 최소 감각은 다음과 같습니다.

필요 메모리 ≈ 3GB × 4개 = 12GB
여유분 포함 요청 ≈ 16GB

CPU도 마찬가지입니다. 어떤 도구가 -t 8 또는 --threads 8을 사용한다면, SLURM에도 CPU를 8개 정도 요청해야 합니다.

#SBATCH --cpus-per-task=8
hisat2 -p 8 -x genome -U sample.fastq.gz -S sample.sam

여기서 -p 8은 도구에게 8개 스레드를 쓰라고 말하는 것이고, --cpus-per-task=8은 스케줄러에게 8개 CPU를 배정해 달라고 말하는 것입니다. 둘 중 하나만 맞고 다른 하나가 틀리면 자원 사용이 꼬일 수 있습니다.

walltime은 실제 실행 시간을 예측해 제한을 거는 값입니다. 테스트에서 1개 샘플이 20분 걸렸고 비슷한 샘플 6개를 순차 처리한다면 단순 추정은 다음과 같습니다.

20분 × 6개 = 120분 = 2시간
여유분 포함 요청 = 3시간 정도

다만 병렬 처리, 파일 입출력, 큐 대기, 서버 상태에 따라 실제 시간은 달라질 수 있습니다. 그래서 처음부터 거대한 전체 작업을 던지기보다 작은 샘플로 자원 사용량을 확인하는 것이 안전합니다.

미니 실습 블록: HPC job script로 분석 작업 제출하기

이 실습은 HPC job script로 분석 작업 제출하기를 직접 손으로 확인하는 연습입니다. 왜 필요한가 하면, 대용량 생물정보학 분석은 개인 노트북보다 HPC에서 실행하는 경우가 많고, CPU·메모리·시간 요청이 필요하기 때문입니다.

#!/bin/bash
#SBATCH --job-name=fastqc
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=02:00:00
#SBATCH --output=logs/fastqc_%j.out

mkdir -p results/fastqc logs
fastqc data/raw/sample01_R1.fastq.gz -o results/fastqc

각 코드 요소의 의미를 풀어보면 다음과 같습니다. #SBATCH 줄은 스케줄러에게 필요한 자원을 알려 줍니다. %j는 job ID를 파일명에 넣어 로그가 덮어써지지 않게 합니다.

생물정보학/계산생물학에서 쓰이는 장면은 분명합니다. FASTQC, alignment, variant calling처럼 오래 걸리는 작업을 서버 큐에 제출할 때 씁니다.

흔한 오해 또는 주의점도 있습니다. 메모리를 너무 작게 요청하면 작업이 죽고, 너무 크게 요청하면 대기 시간이 길어질 수 있습니다.

핵심 정리

HPC는 기관의 고성능 계산 클러스터이고, 클라우드는 인터넷으로 빌려 쓰는 계산 자원입니다. SLURM은 HPC 작업을 제출하고 관리하는 대표 스케줄러입니다. 큰 분석에서는 CPU, GPU, 메모리, 시간, 저장공간을 명확히 이해해야 합니다.

문제 풀이

HPC와 클라우드

0 / 42
Gemini AI 채점

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

API KEY 미등록
  1. 1. [객관식] 객관식

    HPC의 설명으로 적절한 것은?

    선택지
  2. 2. [객관식] 객관식

    클러스터(cluster)의 설명으로 적절한 것은?

    선택지
  3. 3. [객관식] 객관식

    노드(node)의 의미로 적절한 것은?

    선택지
  4. 4. [객관식] 객관식

    작업(job)의 설명으로 적절한 것은?

    선택지
  5. 5. [객관식] 객관식

    스케줄러(scheduler)의 역할은?

    선택지
  6. 6. [객관식] 객관식

    SLURM의 설명으로 적절한 것은?

    선택지
  7. 7. [객관식] 객관식

    sbatch job.sh의 의미로 적절한 것은?

    선택지
  8. 8. [객관식] 객관식

    squeue의 역할로 적절한 것은?

    선택지
  9. 9. [객관식] 객관식

    scancel JOB_ID의 역할은?

    선택지
  10. 10. [객관식] 객관식

    CPU의 역할에 가까운 것은?

    선택지
  11. 11. [객관식] 객관식

    GPU가 특히 유용한 작업으로 적절한 것은?

    선택지
  12. 12. [객관식] 객관식

    메모리(memory)의 설명으로 적절한 것은?

    선택지
  13. 13. [객관식] 객관식

    walltime의 의미로 적절한 것은?

    선택지
  14. 14. [객관식] 객관식

    자원을 너무 적게 요청하면 생길 수 있는 문제는?

    선택지
  15. 15. [객관식] 객관식

    자원을 너무 크게 요청하면 생길 수 있는 문제는?

    선택지
  16. 16. [객관식] 객관식

    클라우드의 설명으로 적절한 것은?

    선택지
  17. 17. [객관식] 객관식

    클라우드 사용 시 특히 조심할 점은?

    선택지
  18. 18. [객관식] 객관식

    HPC와 클라우드 차이로 적절한 것은?

    선택지
  19. 19. [객관식] 객관식

    민감한 인간 유전체 데이터를 서버에 올릴 때 확인할 것은?

    선택지
  20. 20. [객관식] 객관식

    작은 테스트 데이터로 먼저 실행해 보는 이유는?

    선택지
  21. 21. [객관식] 객관식

    SLURM 옵션 --cpus-per-task=8의 의미는?

    선택지
  22. 22. [객관식] 객관식

    --mem=32G의 의미는?

    선택지
  23. 23. [객관식] 객관식

    --time=04:00:00로 제출한 작업이 5시간 걸리면 어떻게 될 수 있는가?

    선택지
  24. 24. [객관식] 객관식

    샘플 20개가 각각 임시 파일 8GB를 만든다. 필요한 임시 저장공간은?

    선택지
  25. 25. [객관식] 객관식

    각 작업이 메모리 6GB를 쓰고 5개를 동시에 실행하면 대략 필요한 총 메모리는?

    선택지
  26. 26. [객관식] 객관식

    CPU를 16개 요청했는데 프로그램이 1개 CPU만 사용한다면 문제는?

    선택지
  27. 27. [객관식] 객관식

    GPU가 특히 유리한 작업은?

    선택지
  28. 28. [객관식] 객관식

    클라우드 인스턴스를 켜 둔 채 방치하면 생기는 대표 문제는?

    선택지
  29. 29. [객관식] 객관식

    민감한 환자 데이터를 클라우드에 올릴 때 중요한 고려사항은?

    선택지
  30. 30. [객관식] 객관식

    job array가 유용한 상황은?

    선택지
  31. 31. [실전] 객관식

    SLURM script에서 #SBATCH --mem=8G의 의미는?

    선택지
  32. 32. [실전] 객관식

    HPC 작업 로그 파일을 남기는 이유는?

    선택지
  33. 주관식 33. [응용] 주관식 · Gemini 채점

    HPC를 개인 노트북과 비교해 설명하라.

  34. 주관식 34. [응용] 주관식 · Gemini 채점

    SLURM에서 sbatch, squeue, scancel의 차이를 설명하라.

  35. 주관식 35. [응용] 주관식 · Gemini 채점

    CPU, GPU, 메모리의 차이를 간단히 설명하라.

  36. 주관식 36. [응용] 주관식 · Gemini 채점

    HPC 작업에서 자원을 너무 적게 또는 너무 크게 요청하면 왜 문제인지 설명하라.

  37. 주관식 37. [응용] 주관식 · Gemini 채점

    클라우드가 유용하지만 비용 관리가 필요한 이유를 설명하라.

  38. 주관식 38. [응용] 주관식 · Gemini 채점

    인간 유전체 데이터를 HPC나 클라우드에서 다룰 때 보안을 확인해야 하는 이유를 설명하라.

  39. 주관식 39. [응용] 주관식 · Gemini 채점

    SLURM 요청 --cpus-per-task=8, --mem=32G, --time=04:00:00의 의미와, 작업이 40GB 메모리를 쓰면 어떤 문제가 생기는지 설명하라.

  40. 주관식 40. [응용] 주관식 · Gemini 채점

    샘플 20개가 각각 8GB 임시 파일을 만들고, 각 작업이 6GB 메모리를 쓰며 5개를 동시에 실행할 때 필요한 저장공간과 메모리를 계산하라.

  41. 주관식 41. [실습] 주관식 · Gemini 채점

    FASTQC를 실행하는 간단한 SLURM job script를 작성하라.

  42. 주관식 42. [실습] 주관식 · Gemini 채점

    HPC에서 CPU와 메모리 요청을 기록해야 하는 이유를 설명하라.