책에 포함된 노트AlphaFold 실전 사용법: 서열 준비부터 구조 해석, AlphaFold 3와 재현 가능한 보고까지

로컬·HPC·클라우드에서 AlphaFold 3 실행하기

2026-05-12Views 135약 11분생성형 AI 활용

Summary

AlphaFold 3를 직접 실행한다는 말은 단순히 프로그램 하나를 설치한다는 뜻이 아닙니다. 작은 연구실 안에 구조 예측용 미니 계산 시설을 하나 들여놓는 일에 가깝습니다. AlphaFold Server를 사용할 때는 웹페이지가 뒤에서 처리해 주던 것들, 예를 들어 유전 데이터베이스 검색, GPU 추론, 결과 저장, 파일 권한, 라이선스 관리, 보안 정책을 이제 사용자가 직접 책임져야 합니다.

그 대신 얻는 것도 큽니다. 미공개 서열을 외부 서버로 보내지 않아도 되고, 같은 입력을 여러 seed로 반복하거나, 대량 배치 작업을 돌리거나, HPC와 클라우드 GPU를 섞어 비용을 줄일 수 있습니다. 특히 단백질만이 아니라 DNA, RNA, 리간드, 이온, 변형 잔기까지 포함하는 복합계를 반복적으로 다루는 연구실이라면 로컬 또는 기관 계산 환경의 장점이 뚜렷해집니다.

다만 이 장의 핵심은 분명합니다. AlphaFold 3 로컬 실행은 강력하지만, 하드웨어, 데이터베이스, 라이선스, 컨테이너 관리가 모두 필요합니다. 앞 장에서 JSON 입력 형식을 배웠다면, 이제 그 JSON이 실제 계산 환경에서 어떤 경로를 지나 구조 파일로 바뀌는지 살펴볼 차례입니다.

로컬·HPC·클라우드에서 AlphaFold 3 실행하기

직접 실행하기 전에 먼저 결정할 것

AlphaFold 3를 직접 돌릴지 말지는 "설치할 수 있는가"보다 "운영할 수 있는가"로 판단해야 합니다. 공식 소스 코드는 가장 유연한 방법이지만, 그만큼 고성능 GPU와 큰 저장 공간, 리눅스 운영 경험이 필요합니다. EBI 교육 자료도 로컬 설치를 가장 강력하고 적응성 높은 방식으로 설명하면서, 동시에 큰 GPU 메모리와 상당한 컴퓨팅 숙련도를 요구한다고 안내합니다.¹

먼저 작업의 성격을 나누어 봅시다. 한 달에 몇 개의 단백질을 확인하는 정도라면 AlphaFold Server나 ColabFold 계열 도구가 더 편할 수 있습니다. 그러나 미공개 표적을 다루거나, 같은 복합체를 여러 리간드·돌연변이·seed 조합으로 반복하거나, 수백 개 이상의 입력을 배치로 처리해야 한다면 직접 실행 환경을 고민할 만합니다.

직접 실행 환경은 크게 세 가지입니다. 연구실 워크스테이션은 접근성이 좋고 실험적인 설정을 바꾸기 쉽습니다. 기관 HPC는 데이터베이스와 컨테이너를 중앙에서 관리할 수 있어 여러 사용자가 안정적으로 쓰기 좋습니다. 클라우드는 A100, H100 같은 고성능 GPU를 필요할 때만 빌릴 수 있지만, 데이터베이스 다운로드와 저장 비용, 보안 정책, GPU 사용 요금이 함께 따라옵니다.

중요한 점은 세 환경 모두에서 AlphaFold 3의 실제 실행 구조가 거의 같다는 것입니다. 입력 JSON이 있고, 모델 파라미터 디렉터리가 있고, 공개 데이터베이스 디렉터리가 있고, 결과를 쓸 출력 디렉터리가 있습니다. 실패의 상당수는 알고리즘 때문이 아니라 이 네 경로가 컨테이너 안에서 서로 다르게 보이는 데서 시작됩니다.

하드웨어 요구 사항을 숫자로 이해하기

공식 설치 문서는 AlphaFold 3가 리눅스 환경을 요구하며, 전체 설치에는 유전 데이터베이스를 저장하기 위해 최대 1TB 정도의 디스크 공간이 필요하다고 설명합니다. 또한 Docker 컨테이너 사용 시 호스트에 CUDA 12.6 환경이 필요하며, NVIDIA GPU는 Compute Capability 8.0 이상을 요구합니다. 긴 표적에서는 유전 검색 단계가 많은 RAM을 쓸 수 있어 최소 64GB RAM을 권장하고, A100 80GB 또는 H100 80GB에서 최대 5,120 token 입력의 수치 정확도를 검증했다고 안내합니다.²

여기서 token은 대략 구조 예측 모델이 처리하는 생체분자 구성 단위라고 생각하면 됩니다. 단백질에서는 아미노산 잔기 하나가 주된 단위가 되고, 핵산이나 리간드가 들어오면 그만큼 전체 입력 크기가 커집니다. "1,000개 아미노산짜리 단백질"과 "500개 아미노산 단백질 두 개, DNA, 리간드, 이온이 함께 있는 복합체"는 단순히 서열 길이만으로 비교하기 어렵습니다. AlphaFold 3에서는 전체 생체분자 조립체의 크기와 상호작용 후보가 GPU 메모리 부담을 결정합니다.

실무적으로는 다음 기준으로 시작하면 안전합니다.

운영체제는 리눅스가 기본입니다. 공식 실행 경로는 Linux 기반 환경을 전제로 하며, macOS나 Windows에서의 비공식 포트는 이 책의 표준 워크플로로 보지 않습니다.
GPU는 NVIDIA Ampere 이상급을 기준으로 생각하는 것이 좋습니다. A100, H100처럼 VRAM이 큰 데이터센터 GPU가 가장 안정적이고, RTX 3090·4090·L40S 같은 고성능 GPU는 입력 크기에 따라 유용할 수 있습니다.
RAM은 최소 64GB를 출발점으로 잡되, 깊은 MSA가 생기는 단백질군이나 긴 복합체에서는 128GB 이상이 필요할 수 있습니다.
저장 장치는 빠른 SSD 또는 NVMe가 좋습니다. 데이터베이스 검색은 큰 파일 하나를 순서대로 읽는 작업이 아니라, 많은 서열·구조 파일을 반복적으로 훑는 작업이라 느린 네트워크 디스크에서 시간이 크게 늘어납니다.
디스크 공간은 데이터베이스만 압축 전후로 수백 GB가 필요합니다. 공식 문서는 전체 다운로드가 약 252GB, 압축 해제 후 약 630GB라고 안내하므로, 운영 여유와 출력·캐시까지 고려해 1TB를 준비하는 편이 낫습니다.²

이 숫자들은 겁을 주기 위한 것이 아닙니다. 오히려 실패를 줄이기 위한 안전선입니다. AlphaFold 3 설치에서 가장 허무한 실패는 "거의 다 받았는데 디스크가 찼다", "MSA 검색 중 네트워크 파일시스템이 너무 느려졌다", "GPU 노드에 올라갔는데 모델 파라미터 파일을 읽을 권한이 없다" 같은 것들입니다.

소스 코드, 모델 파라미터, 라이선스

AlphaFold 3 공식 소스 코드는 Google DeepMind의 GitHub 저장소에서 받을 수 있습니다. 그러나 소스 코드만으로는 예측을 실행할 수 없습니다. 학습된 model parameters, 즉 모델 파라미터 파일을 별도 신청 절차로 받아야 합니다. 공식 문서와 여러 HPC 안내 문서가 공통적으로 강조하는 점은 모델 파라미터를 Google DeepMind로부터 직접 받아야 하며, 기관이나 HPC 센터가 임의로 재배포할 수 없다는 것입니다.²

기본 절차는 단순합니다.

git clone https://github.com/google-deepmind/alphafold3.git
cd alphafold3

그다음 공식 안내에 따라 모델 파라미터 접근을 신청합니다. 승인을 받으면 보통 af3.bin.zst 같은 압축 파일을 받게 됩니다. 이 파일을 해제해 model_dir로 사용할 디렉터리에 배치합니다.

mkdir -p $HOME/af3/models
# 예: 승인 후 받은 링크에서 다운로드했다고 가정
mv af3.bin.zst $HOME/af3/models/
zstd -d $HOME/af3/models/af3.bin.zst
ls $HOME/af3/models
# af3.bin 이 보여야 한다

여기서 가장 중요한 것은 파일 자체보다 정책입니다. 모델 파라미터는 연구실 공유 폴더에 아무렇게나 올려 둘 파일이 아닙니다. 비상업적 사용 조건, 기관 내 공유 가능 범위, 외부 협력자 접근 여부, 클라우드 업로드 가능 여부를 실행 전에 확인해야 합니다. 특히 HPC에서는 공개 읽기 권한이 있는 디렉터리나 삭제 주기가 짧은 scratch 공간에 모델 파라미터를 두지 않도록 주의해야 합니다. 어떤 기관은 소프트웨어 컨테이너와 데이터베이스는 중앙에서 제공하지만, 모델 파라미터만은 각 사용자가 직접 받은 뒤 개인 또는 그룹 권한으로 배치하도록 요구합니다.³

권한은 보수적으로 잡는 편이 좋습니다.

chmod 700 $HOME/af3/models
chmod 600 $HOME/af3/models/af3.bin

공동 프로젝트라면 개인 홈이 아니라 승인된 그룹 디렉터리에 두고, 그룹 권한만 허용합니다. "돌아가기만 하면 된다"는 생각으로 권한을 777로 여는 것은 피해야 합니다. 구조 예측 프로그램 설치에서 보안 사고가 난다면 대개 알고리즘이 아니라 파일 관리에서 시작됩니다.

데이터베이스: 630GB가 필요한 이유

AlphaFold 3는 입력 서열만 보고 마법처럼 구조를 그리는 도구가 아닙니다. 단백질과 RNA의 진화적 힌트를 찾기 위해 여러 유전·구조 데이터베이스를 검색합니다. 공식 설치 문서는 BFD small, MGnify, PDB mmCIF, PDB seqres, UniProt, UniRef90, NT, RFam, RNACentral 같은 데이터베이스를 사용한다고 설명합니다.²

이 데이터베이스들은 두 가지 일을 돕습니다. 첫째, MSA, 즉 multiple sequence alignment를 만듭니다. MSA는 비슷한 서열들을 나란히 놓고 어떤 위치가 함께 보존되거나 함께 변했는지 보는 표입니다. 단백질이 접힐 때 서로 가까워지는 잔기들은 진화 과정에서도 함께 변하는 경향이 있으므로, MSA는 구조 예측에 중요한 단서를 줍니다. 둘째, PDB 구조 데이터베이스에서 template을 찾습니다. template은 이미 실험적으로 풀린 유사 구조로, 모델이 가능한 구조 배치를 추론할 때 참고할 수 있는 힌트입니다.

공식 저장소에는 데이터베이스를 내려받는 스크립트가 제공됩니다.

cd alphafold3
./fetch_databases.sh /data/af3/public_databases

이때 데이터베이스 디렉터리를 AlphaFold 3 소스 저장소 안에 두지 않는 것이 좋습니다. Docker 이미지를 빌드할 때 빌드 컨텍스트에 거대한 데이터베이스가 포함되어 이미지 빌드가 비정상적으로 느려질 수 있기 때문입니다. 공식 문서도 데이터베이스 다운로드 위치를 저장소 하위 디렉터리로 두지 말라고 안내합니다.²

데이터베이스 다운로드가 끝나면 대략 다음과 같은 파일과 디렉터리가 보여야 합니다.

public_databases/
├── mmcif_files/
├── bfd-first_non_consensus_sequences.fasta
├── mgy_clusters_2022_05.fa
├── nt_rna_2023_02_23_clust_seq_id_90_cov_80_rep_seq.fasta
├── pdb_seqres_2022_09_28.fasta
├── rfam_14_9_clust_seq_id_90_cov_80_rep_seq.fasta
├── rnacentral_active_seq_id_90_cov_80_linclust.fasta
├── uniprot_all_2021_04.fa
└── uniref90_2022_05.fa

HPC에서는 이 데이터베이스를 사용자마다 내려받지 않는 것이 좋습니다. 10명이 각각 630GB를 받으면 6TB가 넘습니다. 게다가 같은 파일을 네트워크 스토리지에서 중복으로 읽으면 전체 클러스터 성능에도 부담이 됩니다. 가능하다면 연구실 또는 기관 단위로 중앙 데이터베이스를 하나 만들고, 사용자는 읽기 전용으로 바인딩해 쓰는 방식이 좋습니다. 여러 HPC 문서도 AlphaFold 3 데이터베이스는 매우 크므로 중앙 또는 공유 워크스페이스에 한 벌만 유지하는 방식을 권장합니다.⁵

다만 중앙 데이터베이스가 느린 HDD나 혼잡한 네트워크 파일시스템에 있다면 계산 시간이 크게 늘 수 있습니다. AlphaFold 계열의 서열 검색은 작은 랜덤 접근이 많아 SSD 계열 저장소에서 훨씬 안정적입니다. ETH Zurich HPC 문서도 AlphaFold 데이터베이스 접근 성능에서 SSD 기반 저장소가 중요하다는 점을 설명합니다.⁴

마지막으로 권한을 확인합니다.

chmod -R a+rX /data/af3/public_databases

공식 문서는 데이터베이스에 충분한 읽기·쓰기 권한이 없으면 MSA 도구가 불투명한 외부 오류를 낼 수 있다고 경고합니다.² 특히 일부 도구는 임시 인덱스나 캐시 파일을 만들려고 하므로, 읽기 전용 중앙 DB와 작업용 임시 디렉터리를 분리해 두면 좋습니다.

Docker로 공식 실행 흐름 잡기

개인 워크스테이션이나 클라우드 VM에서는 공식 Docker 기반 실행이 가장 관리하기 쉽습니다. 컨테이너는 "이 프로그램은 이런 라이브러리 조합에서 돌아간다"는 약속을 이미지로 묶어 둔 것입니다. CUDA, JAX, Python 패키지, HMMER 같은 도구의 버전 충돌을 줄일 수 있습니다.

먼저 호스트에서 GPU가 보이는지 확인합니다.

nvidia-smi

그다음 Docker 컨테이너에서도 GPU가 보이는지 확인합니다.

docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

이 명령이 실패하면 AlphaFold 3 문제가 아니라 Docker와 NVIDIA Container Toolkit 설정 문제입니다. GPU가 컨테이너 안에서 보이지 않으면 모델 추론은 시작조차 할 수 없습니다.

이미지는 공식 저장소에서 빌드합니다.

cd alphafold3
docker build -t alphafold3 -f docker/Dockerfile .

이제 네 개의 호스트 디렉터리를 준비합니다.

mkdir -p $HOME/af3/input
mkdir -p $HOME/af3/output
mkdir -p $HOME/af3/models
mkdir -p /data/af3/public_databases

여기서 $HOME/af3/input에는 앞 장에서 만든 fold_input.json을 넣습니다. $HOME/af3/models에는 af3.bin이 있어야 합니다. /data/af3/public_databases에는 방금 내려받은 데이터베이스가 있어야 합니다. $HOME/af3/output은 결과가 쌓일 곳입니다.

Docker 실행 예시는 다음과 같습니다.

docker run --rm --gpus all \
  --volume $HOME/af3/input:/root/af_input \
  --volume $HOME/af3/output:/root/af_output \
  --volume $HOME/af3/models:/root/models \
  --volume /data/af3/public_databases:/root/public_databases \
  alphafold3 \
  python run_alphafold.py \
    --json_path=/root/af_input/fold_input.json \
    --model_dir=/root/models \
    --db_dir=/root/public_databases \
    --output_dir=/root/af_output

이 명령에서 가장 많이 틀리는 부분은 --volume과 실행 옵션의 관계입니다. 왼쪽은 호스트 경로이고, 오른쪽은 컨테이너 내부 경로입니다. 예를 들어 $HOME/af3/input을 /root/af_input으로 연결했다면, 컨테이너 안에서는 JSON 파일을 /root/af_input/fold_input.json으로 불러야 합니다. 호스트 경로인 $HOME/af3/input/fold_input.json을 그대로 --json_path에 넣으면 컨테이너 안에서는 그 경로가 보이지 않을 수 있습니다.

권한도 확인해야 합니다. 컨테이너가 출력 디렉터리에 파일을 쓸 수 없으면 예측이 끝나기 직전에 실패할 수 있습니다.

ls -ld $HOME/af3/output

공동 서버에서는 Docker가 root로 파일을 만들면서 사용자가 지우기 어려운 출력이 생기기도 합니다. 이 경우 --user $(id -u):$(id -g) 옵션을 검토할 수 있지만, 컨테이너 내부 권한과 충돌할 수 있으므로 기관 가이드를 따르는 것이 좋습니다.

HPC에서는 Singularity 또는 Apptainer로 생각하기

기관 HPC에서는 보안상의 이유로 일반 사용자가 Docker 데몬을 직접 쓰지 못하는 경우가 많습니다. 대신 Singularity 또는 Apptainer가 널리 쓰입니다. 이름은 다르지만, 사용자 입장에서는 "컨테이너 이미지를 실행하되, HPC 파일시스템과 스케줄러에 맞게 바인딩한다"고 이해하면 됩니다.

HPC에서 AlphaFold 3를 쓸 때는 먼저 기관에 이미 설치된 모듈이 있는지 확인합니다.

module avail alphafold
module avail alphafold3

중앙 설치가 있다면 문서가 최우선입니다. 같은 AlphaFold 3라도 컨테이너 안의 소스 경로, 데이터베이스 경로, 실행 래퍼 이름이 기관마다 다를 수 있습니다. 어떤 곳은 run_alphafold3라는 래퍼를 제공하고, 어떤 곳은 /app/alphafold/run_alphafold.py를 직접 호출하게 합니다. TACC 문서처럼 모듈을 로드한 뒤 사용자가 입력, 출력, 모델 파라미터 디렉터리를 환경 변수로 지정하는 방식도 흔합니다.³

기관 문서가 없다면 기본 Slurm 스크립트는 다음 모양에서 시작할 수 있습니다.

#!/bin/bash
#SBATCH --job-name=af3_test
#SBATCH --partition=gpu
#SBATCH --gres=gpu:a100:1
#SBATCH --cpus-per-task=16
#SBATCH --mem=128G
#SBATCH --time=04:00:00
#SBATCH --output=af3_%j.out
#SBATCH --error=af3_%j.err

module load singularity
# 또는 module load apptainer

export AF3_INPUT_DIR=$SCRATCH/af3_project/input
export AF3_OUTPUT_DIR=$SCRATCH/af3_project/output
export AF3_MODEL_DIR=$WORK/af3_models
export AF3_DB_DIR=/shared/databases/alphafold3
export AF3_IMAGE=/shared/containers/alphafold3.sif

mkdir -p $AF3_OUTPUT_DIR

singularity exec --nv \
  --bind $AF3_INPUT_DIR:/root/af_input \
  --bind $AF3_OUTPUT_DIR:/root/af_output \
  --bind $AF3_MODEL_DIR:/root/models \
  --bind $AF3_DB_DIR:/root/public_databases \
  $AF3_IMAGE \
  python /app/alphafold/run_alphafold.py \
    --json_path=/root/af_input/fold_input.json \
    --model_dir=/root/models \
    --db_dir=/root/public_databases \
    --output_dir=/root/af_output

--nv는 Singularity/Apptainer 컨테이너 안에서 NVIDIA GPU를 사용할 수 있게 해 주는 핵심 옵션입니다. 이 옵션이 빠지면 GPU 노드에 배정받았더라도 컨테이너 안의 JAX가 GPU를 찾지 못할 수 있습니다.

바인딩은 HPC 실행의 심장입니다. 컨테이너는 기본적으로 호스트 파일시스템 전체를 자동으로 알지 못합니다. 따라서 입력 JSON, 출력 디렉터리, 모델 파라미터, 데이터베이스를 각각 컨테이너 내부 경로에 연결해야 합니다. Tel Aviv University HPC 문서도 Singularity bind mount를 "호스트 경로를 컨테이너 내부 경로로 보이게 하는 작업"으로 설명하며, --json_path는 반드시 컨테이너 내부에서 보이는 경로를 써야 한다고 안내합니다.⁶

실행 전에는 짧은 대화형 작업으로 컨테이너를 열어 확인하는 것이 좋습니다.

singularity exec --nv \
  --bind $AF3_INPUT_DIR:/root/af_input \
  --bind $AF3_OUTPUT_DIR:/root/af_output \
  --bind $AF3_MODEL_DIR:/root/models \
  --bind $AF3_DB_DIR:/root/public_databases \
  $AF3_IMAGE \
  python /app/alphafold/run_alphafold.py --helpfull

이 명령이 성공하면 적어도 Python, 컨테이너, 실행 스크립트 경로는 맞는 것입니다. 그다음 ls /root/models, ls /root/public_databases처럼 컨테이너 내부에서 파일이 보이는지 확인하면 경로 문제를 초기에 잡을 수 있습니다.

데이터 파이프라인과 추론을 분리하기

AlphaFold 3 실행은 크게 두 단계로 나눌 수 있습니다. 첫 번째는 데이터 파이프라인입니다. 여기서는 입력 JSON을 바탕으로 MSA를 만들고 template을 찾습니다. CPU와 RAM, 그리고 대용량 데이터베이스 I/O가 중요합니다. 두 번째는 추론입니다. 여기서는 학습된 모델 파라미터를 사용해 3차원 구조를 생성합니다. GPU 메모리와 계산량이 중요합니다.

이 둘을 같은 GPU 노드에서 한 번에 실행하면 편합니다. 그러나 HPC나 클라우드에서는 비쌀 수 있습니다. GPU가 필요한 것은 주로 추론 단계인데, MSA 검색이 오래 걸리는 동안 비싼 GPU가 기다리기만 할 수 있기 때문입니다. TACC 문서는 AlphaFold 3를 MSA 단계와 inference 단계로 나누어 실행할 수 있으며, CPU 노드에서 MSA를 먼저 수행하고 GPU 노드에서 추론만 실행하는 전략을 소개합니다.³

CPU 노드에서 전처리만 실행하는 예시는 다음과 같습니다.

python /app/alphafold/run_alphafold.py \
  --json_path=/root/af_input/fold_input.json \
  --db_dir=/root/public_databases \
  --output_dir=/root/af_output \
  --norun_inference

이 단계는 모델 파라미터와 GPU가 필요 없거나, 적어도 GPU 사용의 핵심 병목이 아닙니다. 결과 디렉터리에는 보통 입력 이름을 딴 하위 디렉터리와, 전처리된 *_data.json 파일이 생깁니다. 이 파일에는 다음 추론 단계에 필요한 MSA와 template 정보가 정리되어 있습니다.

그다음 GPU 노드에서 추론만 실행합니다.

python /app/alphafold/run_alphafold.py \
  --json_path=/root/af_output/my_job/my_job_data.json \
  --model_dir=/root/models \
  --output_dir=/root/af_output/my_job \
  --norun_data_pipeline

옵션 이름은 AlphaFold 3 버전이나 기관 래퍼에 따라 다르게 감싸져 있을 수 있습니다. 어떤 컨테이너는 --run_inference=false, --run_data_pipeline=false 형태를 쓰기도 합니다. 따라서 실제 실행 전 --helpfull로 현재 설치본의 옵션을 확인해야 합니다.

두 단계 실행의 장점은 큽니다. 첫째, CPU 큐와 GPU 큐를 따로 사용할 수 있습니다. HPC에서 GPU 큐 대기가 길다면, CPU 노드에서 MSA를 미리 만들어 두고 GPU가 잡히는 순간 추론만 빠르게 끝낼 수 있습니다. 둘째, 같은 표적을 여러 seed나 설정으로 다시 돌릴 때 데이터 파이프라인 결과를 재사용할 수 있습니다. 셋째, 클라우드에서는 GPU 인스턴스가 켜져 있는 시간을 줄여 비용을 낮출 수 있습니다.

이 전략은 배치 작업에서 특히 강력합니다. 예를 들어 100개의 돌연변이 단백질을 예측한다면, 먼저 CPU 노드 여러 개에서 전처리를 분산해 끝내고, GPU 노드에서는 준비된 *_data.json 파일을 순서대로 추론하게 만들 수 있습니다. GPU는 비싼 배우입니다. 무대 뒤에서 소품을 찾는 시간까지 배우에게 출연료를 줄 필요는 없습니다.

GPU 메모리, XLA, FlashAttention

AlphaFold 3 실행 실패 중 가장 흔한 것은 OOM, 즉 out of memory입니다. GPU 메모리가 부족하다는 뜻입니다. 여기서 중요한 것은 pLDDT가 낮아서 실패한 것도 아니고, 입력 JSON 문법이 틀린 것도 아니라는 점입니다. 모델이 계산 중간에 만들어야 하는 텐서가 GPU 메모리에 올라가지 못한 것입니다.

A100 80GB나 H100 80GB는 AlphaFold 3에서 가장 안정적인 선택지입니다. 공식 문서는 이 두 GPU에서 큰 입력의 수치 정확도를 검증했다고 밝힙니다.² H100은 메모리 대역폭과 계산 성능이 더 좋아 큰 복합체에서 유리할 수 있습니다. 그러나 VRAM이 같다면 모든 문제가 자동으로 해결되는 것은 아닙니다. 입력 token 수, MSA 깊이, seed 수, 샘플 수, 리간드와 핵산 포함 여부가 모두 메모리 사용량에 영향을 줍니다.

JAX와 XLA도 알아야 합니다. JAX는 AlphaFold 3가 사용하는 고성능 수치 계산 프레임워크이고, XLA는 계산 그래프를 GPU에 맞게 최적화해 주는 컴파일러입니다. 기본 설정에서는 JAX가 GPU 메모리를 미리 많이 잡아둘 수 있습니다. 이 동작은 속도에는 유리하지만, 큰 입력에서는 메모리 관리가 까다로워질 수 있습니다.

HPC 문서들은 큰 입력에서 unified memory를 사용할 수 있는 설정을 소개합니다. unified memory는 GPU 메모리가 부족할 때 일부 데이터를 호스트 RAM으로 넘겨 쓰게 하는 방식입니다. 속도는 느려질 수 있지만, GPU 메모리 부족으로 즉시 죽는 작업을 살릴 수 있습니다. TACC 문서는 다음 환경 변수를 예시로 제시합니다.³

export XLA_PYTHON_CLIENT_PREALLOCATE=false
export TF_FORCE_UNIFIED_MEMORY=true
export XLA_CLIENT_MEM_FRACTION=3.2

XLA_CLIENT_MEM_FRACTION=3.2는 GPU 메모리의 몇 배까지 호스트 메모리를 포함해 사용할지에 관한 설정입니다. 숫자를 무작정 키우면 호스트 RAM을 압박하고 시스템이 느려질 수 있으므로, 기관 권장값이 있다면 그것을 따르는 편이 좋습니다.

FlashAttention도 자주 등장합니다. Attention은 모델이 입력의 각 부분이 다른 부분과 어떻게 관계되는지 계산하는 핵심 연산입니다. FlashAttention은 이 연산을 GPU에서 더 빠르고 메모리 효율적으로 수행하기 위한 구현입니다. 그러나 모든 GPU와 드라이버 조합에서 같은 방식으로 안정적인 것은 아닙니다. ETH Zurich HPC 문서는 특정 GPU에서 추가 XLA 옵션과 함께 --flash_attention_implementation=xla를 사용하는 예를 제시합니다.⁴

singularity exec --nv \
  --env=XLA_FLAGS="--xla_disable_hlo_passes=custom-kernel-fusion-rewriter" \
  ... \
  python /app/alphafold/alphafold-3.0.1/run_alphafold.py \
    --json_path=/root/af_input/input.json \
    --model_dir=/root/models \
    --db_dir=/root/public_databases \
    --output_dir=/root/af_output \
    --flash_attention_implementation=xla

이런 설정은 만능 치료제가 아닙니다. 기본값이 가장 빠른 경우도 많고, 특정 클러스터에서는 기관 관리자가 이미 적절한 옵션을 래퍼에 넣어 두었을 수 있습니다. 따라서 원칙은 간단합니다. 먼저 기본 설정으로 작은 입력을 성공시킵니다. 그다음 큰 입력에서 OOM이나 GPU 커널 오류가 생기면 unified memory, FlashAttention 구현 변경, XLA 플래그를 순서대로 검토합니다.

OOM이 발생했을 때는 다음 순서로 줄이는 것이 좋습니다.

입력 크기를 줄입니다. 생물학적으로 중요하지 않은 긴 무질서 꼬리, 과도한 linker, 반복적인 tag를 제거한 버전으로 먼저 시험합니다.
seed와 샘플 수를 줄입니다. 여러 seed는 불확실성을 보는 데 유용하지만, 첫 실행부터 모든 seed를 넣으면 비용과 시간이 늘어납니다.
데이터 파이프라인 결과를 재사용합니다. MSA와 template 검색을 다시 하지 않으면 실패 후 재시도가 훨씬 가벼워집니다.
더 큰 VRAM의 GPU를 사용합니다. RTX급 GPU에서 반복 실패하는 입력은 A100 80GB 또는 H100 80GB로 옮기는 편이 빠를 수 있습니다.
복합체를 부분 문제로 나눕니다. 전체 조립체를 한 번에 예측하기 전에 도메인, 이합체, 리간드 결합부 등으로 나누어 구조적 단서를 얻습니다.

여기서 "입력을 줄인다"는 말은 마음대로 생물학을 잘라내라는 뜻이 아닙니다. 먼저 전체 서열에서 어떤 영역이 신호 peptide, transmembrane helix, 긴 무질서 영역, affinity tag인지 주석을 확인합니다. 그런 다음 연구 질문에 직접 관련 없는 부분을 제거한 시험 입력과 전체 입력을 구분해 기록합니다. 나중에 보고서에 "계산 편의를 위해 residues 1–35 signal peptide를 제외했다"처럼 명확히 써야 재현성이 유지됩니다.

클라우드 GPU에서 실행할 때의 설계

클라우드에서 AlphaFold 3를 실행하는 일은 매력적입니다. A100이나 H100이 없는 연구실도 필요한 순간에 GPU를 빌릴 수 있습니다. 그러나 클라우드에서는 시간이 곧 비용입니다. 특히 데이터베이스 다운로드와 전처리를 GPU 인스턴스에서 해 버리면, 비싼 GPU가 거의 놀고 있는 동안 요금이 계속 나갑니다.

공식 설치 문서는 Google Cloud에서 Ubuntu 22.04 LTS, A100 80GB GPU, 1TB 디스크를 갖춘 VM을 예로 들어 설치 절차를 설명합니다.² AWS, Azure, 다른 GPU 클라우드에서도 원리는 같습니다. 필요한 것은 GPU VM, 충분한 디스크, Docker 또는 컨테이너 런타임, 모델 파라미터, 공개 데이터베이스, 그리고 보안 설정입니다.

클라우드에서는 세 저장 위치를 분리해 생각하면 좋습니다. 컨테이너 이미지는 Artifact Registry, ECR, ACR 같은 컨테이너 레지스트리에 둡니다. 모델 파라미터는 라이선스 조건에 맞게 암호화된 디스크나 제한된 접근 권한의 스토리지에 둡니다. 공개 데이터베이스는 1TB 이상의 영구 디스크 또는 고성능 파일시스템에 둡니다. 오브젝트 스토리지는 보관에는 좋지만, MSA 검색 중 직접 랜덤 접근하는 저장소로는 느릴 수 있으므로 실행 전 로컬 SSD나 고성능 디스크로 동기화하는 전략이 필요합니다.

비용을 줄이는 기본 흐름은 다음과 같습니다.

CPU 인스턴스 또는 저렴한 관리 노드에서 데이터베이스를 다운로드하고 압축을 풉니다.
데이터베이스 디스크를 스냅샷으로 만들어 재사용합니다.
입력 JSON을 모아 CPU 인스턴스에서 데이터 파이프라인을 먼저 실행합니다.
생성된 *_data.json과 필요한 캐시를 영구 디스크나 오브젝트 스토리지에 저장합니다.
GPU 인스턴스를 켜서 추론만 실행하고, 끝나면 즉시 중지하거나 삭제합니다.

이 구조는 HPC의 두 단계 실행과 같은 생각입니다. CPU가 잘하는 일은 CPU에, GPU가 잘하는 일은 GPU에 맡깁니다. GPU 인스턴스에서 데이터베이스를 몇 시간 내려받고 있다면, 고급 스포츠카를 빌려 놓고 주차장에서 짐 정리를 하는 셈입니다.

스팟 인스턴스나 preemptible 인스턴스를 사용할 때는 중간 결과가 사라지지 않도록 해야 합니다. 데이터 파이프라인 결과, 출력 디렉터리, 로그를 인스턴스 내부 임시 디스크에만 두면 강제 종료 시 모두 잃을 수 있습니다. 출력은 주기적으로 영구 디스크나 오브젝트 스토리지에 동기화하고, 작업 단위는 "입력 하나당 하나의 출력 디렉터리"처럼 재시작하기 쉽게 쪼갭니다.

클라우드 보안도 계산 성능만큼 중요합니다. 미공개 단백질 서열, 환자 유래 변이 정보, 독점 리간드 SMILES, 공동연구 계약상 비공개인 복합체 정보는 모두 민감 데이터가 될 수 있습니다. 클라우드 리전에 따른 데이터 반출 정책, 기관의 개인정보·유전체 데이터 처리 규정, 모델 파라미터 라이선스의 업로드 허용 범위를 확인해야 합니다. "내 계정의 VM에 올렸으니 괜찮다"는 말은 기관 보안 심사에서 충분하지 않을 수 있습니다.

입력 JSON에서 출력까지 경로를 추적하기

AlphaFold 3 실행을 안정화하는 가장 좋은 방법은 계산을 검은상자로 보지 않는 것입니다. 입력 JSON이 어떤 파일로 바뀌고, 그 파일이 다음 단계에서 어떻게 사용되는지 추적해야 합니다.

예를 들어 fold_input.json의 name이 kinase_atp_mg라면 출력 디렉터리 아래에 이 이름을 바탕으로 한 폴더가 생깁니다. 데이터 파이프라인만 실행하면 그 안에 kinase_atp_mg_data.json 같은 전처리 파일이 만들어집니다. 추론만 실행할 때는 원래 JSON이 아니라 이 data JSON을 입력으로 넣어야 합니다. 이 파일을 다른 경로로 옮겼다면, 그 안에서 참조하는 MSA나 template 파일 경로가 함께 유효한지도 확인해야 합니다.

실무에서는 프로젝트 디렉터리를 다음처럼 구성하면 관리하기 쉽습니다.

af3_project/
├── input/
│   ├── kinase_atp_mg.json
│   └── mutant_panel/
├── output/
│   ├── kinase_atp_mg/
│   └── mutant_panel/
├── logs/
├── slurm/
│   ├── run_msa.sbatch
│   └── run_inference.sbatch
└── README_run_notes.md

README_run_notes.md에는 실행 날짜, AlphaFold 3 버전 또는 Git commit, 컨테이너 이미지 해시, 데이터베이스 위치와 생성 날짜, 모델 파라미터 수령·배치 위치, 주요 환경 변수를 기록합니다. 이 기록은 논문 작성 때만 필요한 것이 아닙니다. 3개월 뒤 같은 입력을 다시 돌릴 때 "왜 지난번에는 됐는데 이번에는 안 되지?"라는 질문을 해결하는 데 가장 강력한 단서가 됩니다.

자주 보이는 실패와 빠른 진단법

실패 로그는 처음 보면 무섭습니다. JAX, XLA, HMMER, CUDA, Python traceback이 한꺼번에 쏟아지기 때문입니다. 하지만 대부분은 몇 가지 유형으로 나뉩니다.

File not found가 보이면 먼저 컨테이너 내부 경로를 의심합니다. 호스트에는 파일이 있지만 컨테이너 안에는 바인딩되지 않았을 수 있습니다. singularity exec ... ls /root/af_input 또는 docker run ... ls /root/af_input으로 확인합니다.

GPU를 찾지 못하면 --gpus all 또는 --nv가 빠졌는지 확인합니다. 호스트 nvidia-smi는 되는데 컨테이너 안에서 안 된다면 NVIDIA Container Toolkit, Singularity GPU 지원, 드라이버와 CUDA 호환성 문제일 수 있습니다.

MSA 단계에서 불투명한 오류가 나면 데이터베이스 파일 권한과 디스크 공간을 봅니다. 공식 문서도 데이터베이스 권한이 부족하면 외부 도구 오류가 불명확하게 나타날 수 있다고 경고합니다.² 중앙 DB는 읽을 수 있어야 하고, 작업 디렉터리는 쓸 수 있어야 합니다.

작업이 지나치게 느리면 GPU보다 저장소를 먼저 의심합니다. 특히 MSA 단계가 오래 걸린다면 데이터베이스가 HDD, 혼잡한 NFS, 원격 오브젝트 스토리지에 있지 않은지 확인합니다. 추론 단계가 느리다면 GPU 종류, unified memory 사용 여부, XLA 컴파일 시간, 입력 크기를 확인합니다.

OOM이면 입력을 줄이거나 더 큰 GPU로 옮깁니다. unified memory는 생존 장치이지 가속 장치가 아닙니다. 켜면 통과할 수는 있지만 느려질 수 있습니다.

마지막으로 버전 문제도 있습니다. 2026년 5월 기준으로도 AlphaFold 3 저장소와 HPC 모듈은 계속 업데이트되고 있습니다. 기관 문서가 특정 버전, 예를 들어 3.0.1 또는 3.0.2를 기준으로 작성되어 있다면, 그 버전의 옵션과 현재 GitHub main 브랜치의 옵션이 다를 수 있습니다. 배치 스크립트에는 "어느 버전에서 성공했는지"를 반드시 남겨야 합니다.

운영 체크리스트

AlphaFold 3를 직접 실행하기 전, 아래 질문에 모두 "예"라고 답할 수 있어야 합니다.

리눅스 기반 실행 환경이 있고, 컨테이너 안에서 NVIDIA GPU가 보이는가?
GPU가 입력 크기에 충분한 VRAM을 갖고 있으며, 필요할 때 A100 80GB 또는 H100 80GB 같은 큰 GPU를 사용할 수 있는가?
RAM은 최소 64GB 이상이며, 긴 표적이나 깊은 MSA에 대비해 더 큰 메모리 노드를 선택할 수 있는가?
공개 데이터베이스를 저장할 630GB 이상, 운영 여유를 포함해 약 1TB의 빠른 SSD/NVMe 공간이 있는가?
모델 파라미터를 Google DeepMind로부터 직접 받았고, 라이선스와 기관 공유 정책을 확인했는가?
model_dir, db_dir, json_path, output_dir가 컨테이너 내부 경로 기준으로 정확히 지정되어 있는가?
데이터 파이프라인과 추론을 분리할지, 한 번에 실행할지 결정했는가?
OOM 발생 시 입력 축소, seed 조정, unified memory, 더 큰 GPU 사용, 파이프라인 재사용 전략을 준비했는가?
클라우드 사용 시 데이터베이스 다운로드, 전처리, 추론을 분리해 GPU 비용을 낭비하지 않도록 설계했는가?
미공개 서열, 리간드, 유전체·개인정보 관련 데이터의 반출과 저장 정책을 확인했는가?

이 체크리스트는 귀찮아 보이지만, 실제로는 가장 빠른 길입니다. AlphaFold 3는 잘 준비된 환경에서는 놀라울 만큼 매끄럽게 돌아갑니다. 반대로 경로 하나, 권한 하나, 디스크 하나가 어긋나면 종일 로그만 들여다보게 됩니다.

다음 장으로 이어지는 지점

이제 우리는 AlphaFold 3를 어디서, 어떤 자원으로, 어떤 경로를 통해 실행할지 이해했습니다. 로컬 워크스테이션에서는 Docker로 시작하고, HPC에서는 Singularity 또는 Apptainer와 Slurm을 이용하며, 클라우드에서는 저장소와 GPU 비용을 분리해 설계합니다. 또한 데이터 파이프라인과 추론을 나누면 GPU 시간을 아낄 수 있고, 큰 입력에서는 VRAM, unified memory, XLA, FlashAttention 설정이 성공 여부를 가를 수 있다는 점도 보았습니다.

하지만 계산 환경이 완성되었다고 어려운 예측이 모두 해결되는 것은 아닙니다. 어떤 단백질은 MSA가 얕고, 어떤 복합체는 가능한 배치가 여러 개이며, 어떤 리간드는 입력 표현 하나가 결과를 크게 바꿉니다. 다음 장에서는 템플릿, 커스텀 MSA, seed를 활용해 이런 까다로운 예측을 어떻게 개선할지 살펴보겠습니다.

참고

¹Using the AlphaFold 3 source code | AlphaFold

²AlphaFold 3 installation guide (GitHub)

³AlphaFold3 at TACC

⁴AlphaFold 3 | ETH Zurich HPC Docs

⁵AlphaFold3 | UBELIX User Guide

⁶Alphafold3 | HPC Guide

책 목록

AlphaFold 실전 사용법: 서열 준비부터 구조 해석, AlphaFold 3와 재현 가능한 보고까지

전체 목차 보기