이 글은 AI가 단독으로 생성했으며 사람이 직접 작성하지 않았습니다. 내용을 신중히 판단하시거나, AI에 정확성 검증을 맡겨 보세요.
AI 번역简体中文한국어
주요 통찰
저자는 Kojima 등의 GPCR 구조 분석 도구 NOAH를 배포하면서 겪은 트러블슈팅 경험을 기록했다. 빌드 실패는 DSSP와 libmcfp 버전 비호환에서 비롯됐으며, 버전을 고정하고 동시에 설치해야 한다. 호스트에서 GPU가 보인다고 해서 Docker에서 GPU를 쓸 수 있는 것은 아니므로 NVIDIA Container Toolkit을 설정해야 한다. 빌드 시 --build-arg를 통해 프록시를 명시적으로 전달해야 한다. README의 파라미터 설명이 부족하므로 핵심 파라미터와 출력 위치를 보완해야 한다. 라이선스 제한 때문에 수정판을 공개 배포할 수는 없다. 최종 교훈: 의존성 버전 고정, 드라이버와 컨테이너 GPU 계층 구분, 요청 계층별 네트워크 프록시 설정이 있어야 안정적이고 재현 가능한 워크플로우를 만들 수 있다는 것이다.
들어가며
어제 우연히 Kojima 등이 방금 Nature Structural & Molecular Biology에 발표한 논문 Universal pipeline for high-resolution GPCR structure determination을 읽었다. 이 논문은 GPCR 구조 규명에서 아주 현실적인 문제를 다룬다. G protein처럼 안정적인 결합 파트너가 없는 inactive-state GPCR, 특히 antagonist-bound 상태에서는 TM5-ICL3-TM6 영역에서 서로 다른 융합 위치를 반복해서 시도해야만 발현·안정성·강성이 고해상도 cryo-EM 재구성을 뒷받침할 만큼 충분한 컨스트럭트를 찾을 수 있다. 그래서 실험 스크리닝 비용이 매우 높다.
저자의 접근 방식은 서로 보완하는 두 부분으로 구성된다. NOAH는 먼저 TM5-TM6 융합 컨스트럭트를 열거하고 ColabFold로 구조를 예측한 다음, 연결 부위가 연속된 α-helix를 유지하는지, 국소 pLDDT, helix phase, 그리고 융합 단백질과 막 경계 사이의 거리를 차례로 검사하여 수백 개의 조합 중에서 실험 검증을 해볼 만한 후보 몇 개를 추려낸다. 이어서 저자는 약 40 kDa로 더 강성이 높은 de novo 융합 파트너 ARK1을 설계해 cryo-EM 입자 정렬을 돕는 fiducial marker로 사용했고, 여러 Class A GPCR과 다양한 리간드 상태에서 검증을 마쳤다.
이 방법은 버튼 하나만 누르면 실험 구조가 바로 나오는 방식이 아니다. 이후에도 여전히 발현, 정제, 시료 제작, cryo-EM이 필요하고, 현재의 체계적인 검증도 주로 Class A GPCR에 집중되어 있다. 그렇지만 inactive-state GPCR이나 antagonist complex를 다루는 과제, 또는 융합 컨스트럭트 스크리닝에 오래 발이 묶여 있는 과제라면 초기 시행착오를 상당 부분 줄여줄 수 있다. 그래서 나는 먼저 NOAH의 계산 파이프라인을 재현해서, 손에 잡힌 과제나 주변 과제에 도움이 될 수 있을지 확인해 보려 한다. 이 글이 기록하는 것은 바로 그 배포 과정에서 겪은 문제들이다.
첫 단계로 NVIDIA GPU가 장착된 Linux 서버에 NOAH를 배포해 보았다. NOAH는 GPCRdb 데이터, DSSP, PPM3, ColabFold를 오케스트레이션하여 후보 컨스트럭트 스크리닝을 수행한다. 프로젝트에는 이미 Dockerfile이 제공되어 있어, 명령어 세 개만 실행하면 될 것처럼 보였다:
BASH
git clone https://github.com/hekato-lab/noah_gpcr
cd noah_gpcr
docker build -t noah_gpcr .
하지만 실제 배포는 그리 순조롭지 않았다. DSSP 의존성 비호환, Docker에서 NVIDIA GPU를 사용할 수 없는 문제, 서버의 외부 리소스 접근 불안정, 실행 파라미터 설명 부족 등의 문제를 차례로 겪었다. 이 글은 전체 원인 파악 과정과 최종적으로 재사용할 수 있는 배포 방법을 기록한 것이다.
NOAH의 현재 LICENSE는 비상업적 연구 및 교육 목적으로만 사용을 허용하며, 원본이든 수정본이든 제3자에게 재배포하는 행위(공개 GitHub 저장소에 업로드하는 것 포함)를 명시적으로 금지한다. 따라서 나는 수정된 내용을 공개할 수 없다. 이 글에서는 배포 접근 방식과 트러블슈팅 경험을 공유한다. 비슷한 문제를 겪고 있다면 이 글을 AI에 컨텍스트로 넘겨 주면 배포가 한결 수월해질 것이다.
1. 빌드 실패: DSSP와 libmcfp의 버전 조합 불안정
처음에 바로 docker build를 실행했을 때 문제는 DSSP 환경에서 발생했다: mkdssp와 dssp는 찾을 수 있었지만, 버전 확인이나 Biopython 호출 시 정상적으로 실행되지 않았다. 즉, 문제는 “DSSP가 설치되어 있지 않다”는 것이 아니라, DSSP와 그 하위 계층인 libmcfp의 바이너리 인터페이스 조합이 호환되지 않는다는 것이었다.
원래 Dockerfile은 먼저 NOAH의 Conda 환경을 만들고 DSSP를 설치한 뒤, gsutil을 별도로 설치한다. 두 번의 독립적인 Conda solve가 앞서 설치한 간접 의존성을 업데이트했을 수 있다. 또한 원래 PATH은 ColabFold 환경을 NOAH 환경보다 앞에 두고 있어, 잘못된 환경의 프로그램이나 동적 라이브러리를 호출할 위험도 커졌다.
최종적으로 적용한 처리 방식은 네 가지다:
dssp, libmcfp, gsutil을 한 번의 Conda solve에 함께 넣습니다.
검증된 호환 버전으로 고정합니다: dssp=4.6.1, libmcfp=2.0.1.
NOAH 환경을 ColabFold 환경보다 앞에 배치합니다.
이미지 빌드 단계에서 mkdssp --version, dssp --version을 직접 실행해, NOAH가 오래 실행된 뒤에야 실패하는 대신 오류를 최대한 일찍 드러내도록 합니다.
두 번째 문제는 GPU 계층에서 발생했다. 서버에서 nvidia-smi가 정상적으로 실행된다는 것은 NVIDIA 드라이버가 정상 작동한다는 증거일 뿐이다. Docker가 GPU를 컨테이너에 노출하려면 NVIDIA Container Toolkit을 설치하고 구성해야 한다.
먼저 Docker가 현재 어떤 runtime을 인식하는지 확인할 수 있다:
BASH
nvidia-smi
docker info | grep -i runtime
Ubuntu나 Debian 시스템에서는 NVIDIA Container Toolkit 공식 설치 문서를 따라 구성을 완료했다. 아래 버전 번호는 2026-08-30 기준으로 공식 문서에 적혀 있는 1.20.0-1이며, 이후 배포 시에는 먼저 공식 페이지에서 현재 버전을 확인해야 한다.
nvidia-ctk runtime configure는 호스트의 /etc/docker/daemon.json을 수정해 Docker가 NVIDIA runtime을 호출할 수 있게 한다. 구성한 뒤에는 docker info만 확인하지 말고, 실제로 임시 컨테이너를 하나 실행해 검증하는 것이 좋다. NVIDIA 공식 문서가 제시한 테스트 명령은 다음과 같다:
BASH
sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
이 명령이 컨테이너 안에서 GPU 정보를 출력해야 GPU runtime이 제대로 구성된 것이다. 해당 공식 검증 방법은 Running a Sample Workload에서 확인할 수 있다.
3. Docker 빌드 과정에 프록시 전달하기
NOAH의 이미지 빌드 과정에서는 Conda, PyPI, GitHub, Google Cloud Storage 등의 외부 서비스에 접근해야 한다. 서버 네트워크가 제한되어 있다면 먼저 호스트 터미널에서 프록시를 설정하면 된다:
이런 export는 현재 호스트 셸과 그 셸이 시작한 일반 프로세스에만 프록시를 설정하므로, 호스트에서 git clone 같은 명령의 네트워크 문제는 해결할 수 있다. 하지만 Docker는 이 환경 변수들을 이미지 빌드 과정의 Dockerfile RUN 환경에 자동으로 전달하지 않는다. 그래서 호스트에서는 저장소를 정상적으로 클론할 수 있는데, docker build 안의 wget, Conda, pip 또는 gsutil은 여전히 타임아웃이 나는 현상이 생길 수 있다.
여기서 $http_proxy, $https_proxy, $all_proxy는 호스트의 현재 셸에서 가져온 값이며, --build-arg로 빌드 환경에 전달된다. 자리 표시자를 자신의 프록시 주소로 바꾸기만 하면 된다. Docker에는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등 프록시 빌드 인자가 이미 정의되어 있으므로, 프록시 때문에 Dockerfile에 영구 ENV를 추가할 필요가 없다. 그렇지 않으면 프록시 주소가 이미지 구성에 남을 수 있다. 자세한 내용은 Docker CLI 프록시 문서를 참고하라.
4. README 보완
원래 README에는 최소한의 명령만 제시되어 있고, 어떤 파라미터가 필수인지, 기본값이 무엇인지, 결과가 어디에 기록되는지는 체계적으로 설명되어 있지 않다. 명령을 그대로 복사해 쓰다 보면 몇 가지 의문이 생기기 쉽다: -m을 빼면 어떻게 될까? -f는 필수인가? --reverse은 정확히 역방향 스크리닝을 켜는 것인지 끄는 것인지? 심지어 이런 파라미터가 있는지조차 모를 수 있다.
GPCR 이름; 데이터베이스 모드에서는 데이터베이스 디렉터리 이름과 일치해야 한다. 예: v2r.
-p, --ppm
예
없음
PPM3 코드 디렉터리로, 그 안에 immers이 포함되어야 한다.
-d, --database
조건부 필수
없음
NOAH/GPCRdb 데이터베이스 디렉터리; 데이터베이스를 사용하지 않을 때는 -s과 -j를 함께 제공해야 한다.
-s, --structure
조건부 필수
없음
사용자 정의 GPCR PDB 구조.
-j, --json
조건부 필수
없음
GPCRdb residues/extended 형식의 잔기 주석.
-m, --mode
아니요
Inactive
구조 상태로, Active 또는 Inactive만 허용한다.
-f, --fp
아니요
ARK1
융합 단백질로, ARK1, BRIL 또는 A2A_BRIL 중에서 고를 수 있다.
-r, --reverse
아니요
기본적으로 역방향 스크리닝 수행
이 이름은 오해하기 쉽다. 이 옵션을 전달하면 오히려 역방향 helix-phase 스크리닝을 끄는 것이 된다.
또 하나의 핵심은 NOAH에 별도의 --output 파라미터가 없다는 것이다. 결과는 현재 작업 디렉터리에 기록된다. 타깃, 구조 상태, 융합 단백질이 서로 다르면 각각 별도의 빈 디렉터리를 사용해야 한다. 기존 결과 디렉터리에서 그대로 다시 실행하면 일부 파일이 배타적(exclusive) 방식으로 생성되어 실패할 수 있다.
그래서 나는 타깃, 구조 상태, 융합 단백질을 RUN_ID에 담아 넣고, -m과 -f를 명시적으로 전달해 기본값에 의존하지 않는 편이 낫다고 본다:
여기서는 --gpus device=0를 사용해 0번 GPU만 컨테이너에 노출한다. 이 방식은 “모든 GPU를 노출한 다음 CUDA_VISIBLE_DEVICES=0”로 설정하는 방식보다 더 직접적이다. Docker에서 특정 GPU를 지정하는 방법에 대한 공식 설명은 GPU access에서 확인할 수 있다.
현재 NOAH는 ColabFold를 호출해 후보 컨스트럭트를 하나씩 처리하므로, 서버에 GPU가 여러 장 있고 명령에서 --gpus all을 사용한다고 해서 자동으로 거의 선형에 가까운 가속을 얻지는 못한다. 스케줄링 로직을 직접 수정하지 않았다면, 작업 하나에 GPU 한 장만 할당하는 편이 보통 더 명확하고, 서로 다른 작업을 서로 다른 GPU에 배분하기도 쉽다.
작업을 백그라운드 모드로 시작한 후에는 이렇게 진행 상황을 확인할 수 있다:
BASH
docker logs -f noah_v2r_ark1
nvidia-smi -l 2
5. 수정판 저장소를 공개하지 않는 이유
뒤따라오는 사람들이 같은 실수를 반복하지 않도록, 나는 Docker 의존성 고정과 README 파라미터 설명을 정리했고 개인 fork에 수정 사항을 커밋하기도 했다. 하지만 NOAH의 프로젝트 라이선스는 코드 재배포를 명시적으로 제한하며, 원본이든 수정본이든 공개 GitHub 저장소에 업로드할 수 없다고 특히 강조한다. GitHub가 공개 저장소의 네이티브 fork에 대해 별도의 플랫폼 조항을 두고 있긴 하지만, 라이선스 해석의 충돌을 피하고 저자가 밝힌 사용 범위를 존중하기 위해 나는 수정판 저장소를 공개 배포하지 않기로 했다. 수정 사항은 내부의 비상업적 연구 환경에서만 유지한다.
따라서 이 글은 배포 과정과 트러블슈팅 접근 방식만 공유하며, 수정판 저장소 링크는 제공하지 않는다. 독자는 원본 저장소에서 코드를 받아 그 라이선스를 준수해야 한다. 수정판을 공개하거나 제3자에게 배포하거나 상업적 용도로 사용하려면 먼저 저자의 명시적인 허락을 받아야 한다.
정리
이번 NOAH 배포는 결국 네 가지 경험으로 정리할 수 있다:
연구용 이미지는 Conda의 동적 solve에 전적으로 의존하지 말 것. 핵심 바이너리와 하위 라이브러리는 검증된 버전 조합으로 고정할 것.
호스트 드라이버, Docker Engine, NVIDIA Container Toolkit은 서로 다른 세 계층의 구성 요소이며, nvidia-smi가 정상이라고 해서 컨테이너가 GPU를 사용할 수 있는 것은 아니다.
네트워크 장애는 호스트, Docker daemon, 빌드 컨테이너의 세 계층으로 나누어 살펴야 한다. 프록시는 실제로 요청을 보내는 계층에 설정해야 한다.
NOAH 자체의 아이디어는 매우 가치가 있지만, 이를 안정적이고 재현 가능한 서버 워크플로우로 만들려면 환경 고정, GPU runtime, 네트워크 구성, 실행 문서가 하나도 빠져서는 안 된다.
들어가며
어제 우연히 Kojima 등이 방금 Nature Structural & Molecular Biology에 발표한 논문 Universal pipeline for high-resolution GPCR structure determination을 읽었다. 이 논문은 GPCR 구조 규명에서 아주 현실적인 문제를 다룬다. G protein처럼 안정적인 결합 파트너가 없는 inactive-state GPCR, 특히 antagonist-bound 상태에서는 TM5-ICL3-TM6 영역에서 서로 다른 융합 위치를 반복해서 시도해야만 발현·안정성·강성이 고해상도 cryo-EM 재구성을 뒷받침할 만큼 충분한 컨스트럭트를 찾을 수 있다. 그래서 실험 스크리닝 비용이 매우 높다.
저자의 접근 방식은 서로 보완하는 두 부분으로 구성된다. NOAH는 먼저 TM5-TM6 융합 컨스트럭트를 열거하고 ColabFold로 구조를 예측한 다음, 연결 부위가 연속된 α-helix를 유지하는지, 국소 pLDDT, helix phase, 그리고 융합 단백질과 막 경계 사이의 거리를 차례로 검사하여 수백 개의 조합 중에서 실험 검증을 해볼 만한 후보 몇 개를 추려낸다. 이어서 저자는 약 40 kDa로 더 강성이 높은 de novo 융합 파트너 ARK1을 설계해 cryo-EM 입자 정렬을 돕는 fiducial marker로 사용했고, 여러 Class A GPCR과 다양한 리간드 상태에서 검증을 마쳤다.
이 방법은 버튼 하나만 누르면 실험 구조가 바로 나오는 방식이 아니다. 이후에도 여전히 발현, 정제, 시료 제작, cryo-EM이 필요하고, 현재의 체계적인 검증도 주로 Class A GPCR에 집중되어 있다. 그렇지만 inactive-state GPCR이나 antagonist complex를 다루는 과제, 또는 융합 컨스트럭트 스크리닝에 오래 발이 묶여 있는 과제라면 초기 시행착오를 상당 부분 줄여줄 수 있다. 그래서 나는 먼저 NOAH의 계산 파이프라인을 재현해서, 손에 잡힌 과제나 주변 과제에 도움이 될 수 있을지 확인해 보려 한다. 이 글이 기록하는 것은 바로 그 배포 과정에서 겪은 문제들이다.
첫 단계로 NVIDIA GPU가 장착된 Linux 서버에 NOAH를 배포해 보았다. NOAH는 GPCRdb 데이터, DSSP, PPM3, ColabFold를 오케스트레이션하여 후보 컨스트럭트 스크리닝을 수행한다. 프로젝트에는 이미 Dockerfile이 제공되어 있어, 명령어 세 개만 실행하면 될 것처럼 보였다:
하지만 실제 배포는 그리 순조롭지 않았다. DSSP 의존성 비호환, Docker에서 NVIDIA GPU를 사용할 수 없는 문제, 서버의 외부 리소스 접근 불안정, 실행 파라미터 설명 부족 등의 문제를 차례로 겪었다. 이 글은 전체 원인 파악 과정과 최종적으로 재사용할 수 있는 배포 방법을 기록한 것이다.
NOAH의 현재 LICENSE는 비상업적 연구 및 교육 목적으로만 사용을 허용하며, 원본이든 수정본이든 제3자에게 재배포하는 행위(공개 GitHub 저장소에 업로드하는 것 포함)를 명시적으로 금지한다. 따라서 나는 수정된 내용을 공개할 수 없다. 이 글에서는 배포 접근 방식과 트러블슈팅 경험을 공유한다. 비슷한 문제를 겪고 있다면 이 글을 AI에 컨텍스트로 넘겨 주면 배포가 한결 수월해질 것이다.
1. 빌드 실패: DSSP와 libmcfp의 버전 조합 불안정
처음에 바로 docker build를 실행했을 때 문제는 DSSP 환경에서 발생했다: mkdssp와 dssp는 찾을 수 있었지만, 버전 확인이나 Biopython 호출 시 정상적으로 실행되지 않았다. 즉, 문제는 “DSSP가 설치되어 있지 않다”는 것이 아니라, DSSP와 그 하위 계층인 libmcfp의 바이너리 인터페이스 조합이 호환되지 않는다는 것이었다.
원래 Dockerfile은 먼저 NOAH의 Conda 환경을 만들고 DSSP를 설치한 뒤, gsutil을 별도로 설치한다. 두 번의 독립적인 Conda solve가 앞서 설치한 간접 의존성을 업데이트했을 수 있다. 또한 원래 PATH은 ColabFold 환경을 NOAH 환경보다 앞에 두고 있어, 잘못된 환경의 프로그램이나 동적 라이브러리를 호출할 위험도 커졌다.
최종적으로 적용한 처리 방식은 네 가지다:
핵심 수정 방향은 다음과 같다:
2. 호스트에서 GPU가 보인다고 Docker에서 GPU를 쓸 수 있는 것은 아니다
두 번째 문제는 GPU 계층에서 발생했다. 서버에서 nvidia-smi가 정상적으로 실행된다는 것은 NVIDIA 드라이버가 정상 작동한다는 증거일 뿐이다. Docker가 GPU를 컨테이너에 노출하려면 NVIDIA Container Toolkit을 설치하고 구성해야 한다.
먼저 Docker가 현재 어떤 runtime을 인식하는지 확인할 수 있다:
Ubuntu나 Debian 시스템에서는 NVIDIA Container Toolkit 공식 설치 문서를 따라 구성을 완료했다. 아래 버전 번호는 2026-08-30 기준으로 공식 문서에 적혀 있는 1.20.0-1이며, 이후 배포 시에는 먼저 공식 페이지에서 현재 버전을 확인해야 한다.
nvidia-ctk runtime configure는 호스트의 /etc/docker/daemon.json을 수정해 Docker가 NVIDIA runtime을 호출할 수 있게 한다. 구성한 뒤에는 docker info만 확인하지 말고, 실제로 임시 컨테이너를 하나 실행해 검증하는 것이 좋다. NVIDIA 공식 문서가 제시한 테스트 명령은 다음과 같다:
이 명령이 컨테이너 안에서 GPU 정보를 출력해야 GPU runtime이 제대로 구성된 것이다. 해당 공식 검증 방법은 Running a Sample Workload에서 확인할 수 있다.
3. Docker 빌드 과정에 프록시 전달하기
NOAH의 이미지 빌드 과정에서는 Conda, PyPI, GitHub, Google Cloud Storage 등의 외부 서비스에 접근해야 한다. 서버 네트워크가 제한되어 있다면 먼저 호스트 터미널에서 프록시를 설정하면 된다:
이런 export는 현재 호스트 셸과 그 셸이 시작한 일반 프로세스에만 프록시를 설정하므로, 호스트에서 git clone 같은 명령의 네트워크 문제는 해결할 수 있다. 하지만 Docker는 이 환경 변수들을 이미지 빌드 과정의 Dockerfile RUN 환경에 자동으로 전달하지 않는다. 그래서 호스트에서는 저장소를 정상적으로 클론할 수 있는데, docker build 안의 wget, Conda, pip 또는 gsutil은 여전히 타임아웃이 나는 현상이 생길 수 있다.
따라서 빌드를 실행할 때는 --build-arg로 프록시를 명시적으로 전달해야 한다:
여기서 $http_proxy, $https_proxy, $all_proxy는 호스트의 현재 셸에서 가져온 값이며, --build-arg로 빌드 환경에 전달된다. 자리 표시자를 자신의 프록시 주소로 바꾸기만 하면 된다. Docker에는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등 프록시 빌드 인자가 이미 정의되어 있으므로, 프록시 때문에 Dockerfile에 영구 ENV를 추가할 필요가 없다. 그렇지 않으면 프록시 주소가 이미지 구성에 남을 수 있다. 자세한 내용은 Docker CLI 프록시 문서를 참고하라.
4. README 보완
원래 README에는 최소한의 명령만 제시되어 있고, 어떤 파라미터가 필수인지, 기본값이 무엇인지, 결과가 어디에 기록되는지는 체계적으로 설명되어 있지 않다. 명령을 그대로 복사해 쓰다 보면 몇 가지 의문이 생기기 쉽다: -m을 빼면 어떻게 될까? -f는 필수인가? --reverse은 정확히 역방향 스크리닝을 켜는 것인지 끄는 것인지? 심지어 이런 파라미터가 있는지조차 모를 수 있다.
NOAH의 핵심 명령은 다음과 같이 요약할 수 있다:
가장 중요한 파라미터는 다음과 같다:
파라미터
필수 여부
기본값
의미
-n, --name
예
없음
GPCR 이름; 데이터베이스 모드에서는 데이터베이스 디렉터리 이름과 일치해야 한다. 예: v2r.
-p, --ppm
예
없음
PPM3 코드 디렉터리로, 그 안에 immers이 포함되어야 한다.
-d, --database
조건부 필수
없음
NOAH/GPCRdb 데이터베이스 디렉터리; 데이터베이스를 사용하지 않을 때는 -s과 -j를 함께 제공해야 한다.
-s, --structure
조건부 필수
없음
사용자 정의 GPCR PDB 구조.
-j, --json
조건부 필수
없음
GPCRdb residues/extended 형식의 잔기 주석.
-m, --mode
아니요
Inactive
구조 상태로, Active 또는 Inactive만 허용한다.
-f, --fp
아니요
ARK1
융합 단백질로, ARK1, BRIL 또는 A2A_BRIL 중에서 고를 수 있다.
-r, --reverse
아니요
기본적으로 역방향 스크리닝 수행
이 이름은 오해하기 쉽다. 이 옵션을 전달하면 오히려 역방향 helix-phase 스크리닝을 끄는 것이 된다.
또 하나의 핵심은 NOAH에 별도의 --output 파라미터가 없다는 것이다. 결과는 현재 작업 디렉터리에 기록된다. 타깃, 구조 상태, 융합 단백질이 서로 다르면 각각 별도의 빈 디렉터리를 사용해야 한다. 기존 결과 디렉터리에서 그대로 다시 실행하면 일부 파일이 배타적(exclusive) 방식으로 생성되어 실패할 수 있다.
그래서 나는 타깃, 구조 상태, 융합 단백질을 RUN_ID에 담아 넣고, -m과 -f를 명시적으로 전달해 기본값에 의존하지 않는 편이 낫다고 본다:
여기서는 --gpus device=0를 사용해 0번 GPU만 컨테이너에 노출한다. 이 방식은 “모든 GPU를 노출한 다음 CUDA_VISIBLE_DEVICES=0”로 설정하는 방식보다 더 직접적이다. Docker에서 특정 GPU를 지정하는 방법에 대한 공식 설명은 GPU access에서 확인할 수 있다.
현재 NOAH는 ColabFold를 호출해 후보 컨스트럭트를 하나씩 처리하므로, 서버에 GPU가 여러 장 있고 명령에서 --gpus all을 사용한다고 해서 자동으로 거의 선형에 가까운 가속을 얻지는 못한다. 스케줄링 로직을 직접 수정하지 않았다면, 작업 하나에 GPU 한 장만 할당하는 편이 보통 더 명확하고, 서로 다른 작업을 서로 다른 GPU에 배분하기도 쉽다.
작업을 백그라운드 모드로 시작한 후에는 이렇게 진행 상황을 확인할 수 있다:
5. 수정판 저장소를 공개하지 않는 이유
뒤따라오는 사람들이 같은 실수를 반복하지 않도록, 나는 Docker 의존성 고정과 README 파라미터 설명을 정리했고 개인 fork에 수정 사항을 커밋하기도 했다. 하지만 NOAH의 프로젝트 라이선스는 코드 재배포를 명시적으로 제한하며, 원본이든 수정본이든 공개 GitHub 저장소에 업로드할 수 없다고 특히 강조한다. GitHub가 공개 저장소의 네이티브 fork에 대해 별도의 플랫폼 조항을 두고 있긴 하지만, 라이선스 해석의 충돌을 피하고 저자가 밝힌 사용 범위를 존중하기 위해 나는 수정판 저장소를 공개 배포하지 않기로 했다. 수정 사항은 내부의 비상업적 연구 환경에서만 유지한다.
따라서 이 글은 배포 과정과 트러블슈팅 접근 방식만 공유하며, 수정판 저장소 링크는 제공하지 않는다. 독자는 원본 저장소에서 코드를 받아 그 라이선스를 준수해야 한다. 수정판을 공개하거나 제3자에게 배포하거나 상업적 용도로 사용하려면 먼저 저자의 명시적인 허락을 받아야 한다.
정리
이번 NOAH 배포는 결국 네 가지 경험으로 정리할 수 있다:
NOAH 자체의 아이디어는 매우 가치가 있지만, 이를 안정적이고 재현 가능한 서버 워크플로우로 만들려면 환경 고정, GPU runtime, 네트워크 구성, 실행 문서가 하나도 빠져서는 안 된다.