단순히 프롬프트를 입력하고 결과를 기다리는 것만으로 수십억 달러가 투입되는 신약 개발의 난제가 해결될 수 있을까. 벤치마크 점수가 높은 모델이 곧바로 실험실의 유효한 데이터로 치환되지 않는다는 사실을 깨닫는 데는 그리 오랜 시간이 걸리지 않았다. 모델이라는 ‘부품’이 아니라, 실제 연구 워크플로우에 맞물려 돌아가는 ‘시스템’의 부재가 지금의 AI 신약 개발이 마주한 진짜 벽일지도 모른다.
모델이 아닌 시스템으로서의 AI 접근법
최근 2,500만 달러의 시리즈 A 투자를 유치한 Converge Bio의 행보는 흥미롭다. Bessemer Venture Partners를 필두로 Meta, OpenAI, Wiz의 임원들이 투자자로 참여했다는 점은 이들이 단순한 바이오 벤처가 아니라, 고도의 소프트웨어 엔지니어링 역량을 갖춘 팀이라는 점에 베팅했음을 시사한다. CEO 도브 게르츠(Dov Gertz)가 강조하듯, 챗GPT처럼 프롬프트 하나로 약물을 설계하는 시대는 아직 오지 않았다.
이들이 구축한 플랫폼은 DNA, RNA, 단백질 서열 데이터를 학습한 생성 모델을 기반으로 하지만, 이를 단일 모델로 사용하지 않는다. 대신 생성 모델이 새로운 항체를 만들면, 예측 모델이 분자 특성을 필터링하고, 마지막으로 물리 기반의 도킹 시스템이 3차원 상호작용을 시뮬레이션하는 파이프라인 형태로 구성되어 있다. 이는 전형적인 마이크로서비스 아키텍처(MSA)나 데이터 파이프라인 설계 방식과 매우 유사하다.
신약 개발 워크플로우의 엔지니어링 구현
엔지니어의 관점에서 Converge Bio의 접근법을 해석하면, 생물학적 데이터를 처리하는 일종의 ‘컴파일러’나 ‘최적화 엔진’을 만드는 것과 같다. 특히 항체 설계나 단백질 수율 최적화 같은 작업은 고도의 계산 자원을 필요로 하며, 이를 위해 분산 처리 환경과 GPU 가속 인프라가 필수적이다.
만약 우리가 유사한 분자 데이터 처리 파이프라인을 구축한다면, 먼저 대규모 서열 데이터를 효율적으로 처리할 수 있는 환경을 설정해야 한다. 예를 들어, Python 기반의 바이오인포매틱스 라이브러리를 활용해 특정 단백질 서열의 특성을 추출하고 이를 모델의 입력값으로 넣는 기초적인 워크플로우는 다음과 같은 구조를 가질 것이다.
# 분자 데이터 전처리를 위한 가상환경 설정 및 라이브러리 설치
conda create -n bio_ai python=3.10
conda activate bio_ai
pip install biopython torch transformers
# 간단한 서열 데이터 로드 및 토큰화 예시 스크립트 (preprocess.py)
from Bio import SeqIO
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("facebook/esm2_t33_650M_UR50D")
def process_sequences(file_path):
sequences = []
for record in SeqIO.parse(file_path, "fasta"):
# 서열 데이터를 모델이 이해할 수 있는 토큰으로 변환
tokens = tokenizer.encode(str(record.seq), return_tensors="pt")
sequences.append(tokens)
return sequences
# 실행: python preprocess.py --input ./data/protein_seqs.fasta
실제 운영 환경에서는 이러한 전처리 과정이 수만 개의 서열에 대해 병렬로 일어나야 하며, 이를 위해 Kubernetes 기반의 잡(Job) 스케줄링이나 Ray 같은 분산 프레임워크가 도입된다. Converge Bio가 제공하는 시스템은 생물학자가 코드를 직접 짜지 않고도 이러한 복잡한 인프라 위에서 결과물을 얻을 수 있게 하는 추상화 계층(Abstraction Layer)을 제공하는 것이 핵심이다.
인프라 구축 시의 시행착오와 해결책
AI 기반의 바이오 시스템을 구축할 때 가장 흔하게 발생하는 문제는 메모리 부족(OOM, Out of Memory)과 데이터 정렬 오류다. 특히 단백질 서열의 길이가 가변적이기 때문에, 고정 길이의 텐서로 변환하는 과정에서 패딩(Padding) 전략을 잘못 세우면 모델의 성능이 급격히 저하되거나 런타임 에러가 발생한다.
가장 빈번하게 발생하는 CUDA 메모리 에러와 그 대처법을 정리하면 다음과 같다.
- 에러 발생:
RuntimeError: CUDA out of memory. Tried to allocate ... - 원인 분석: 배치 사이즈가 너무 크거나, 긴 서열 데이터가 GPU 메모리 한계를 초과함.
- 해결 방법:
gradient_accumulation_steps를 늘려 실질적인 배치 사이즈를 유지하면서 물리적 배치를 줄인다.torch.utils.checkpoint를 사용하여 연산 그래프의 일부를 포기하고 메모리를 확보한다.- 데이터 로더 단계에서 서열 길이에 따라 버킷팅(Bucketing)을 수행해 패딩 낭비를 줄인다.
또한, 모델의 예측값이 실제 실험 결과와 일치하지 않는 ‘데이터 드리프트’ 현상이 발생할 수 있다. 이를 해결하기 위해 Converge Bio는 실험 결과가 다시 모델의 학습 데이터로 들어오는 타이트한 검증 루프(Experimental Validation Loop)를 구축했다. 이는 소프트웨어 공학의 CI/CD(지속적 통합/지속적 배포) 개념을 생물학적 실험 단계에 이식한 것으로 볼 수 있다.
시스템 통합을 위한 API 설계 관점
Converge Bio의 플랫폼이 제약사 워크플로우에 ‘플러그인’처럼 작동하려면 표준화된 인터페이스가 필요하다. 내부적으로는 REST API나 gRPC를 통해 모델 서버와 통신하며, 다음과 같은 형태의 엔드포인트를 통해 항체 설계 요청을 처리할 가능성이 높다.
# 항체 설계 요청을 보내는 가상 API 호출 예시
curl -X POST https://api.converge-bio.com/v1/antibody/design \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"target_protein_id": "P12345",
"optimization_goal": "binding_affinity",
"constraints": {
"max_length": 120,
"avoid_sequences": ["AGCT..."]
},
"sampling_strategy": "nucleus_sampling"
}'
이 요청이 서버에 도달하면 내부적으로는 앞서 언급한 생성-필터링-도킹의 3단계 파이프라인이 트리거된다. 각 단계는 독립적인 컨테이너에서 실행되며, 결과값은 S3와 같은 오브젝트 스토리지에 저장된 후 최종 사용자에게 전달된다. 단순한 모델 호출이 아니라, 일련의 오케스트레이션 과정이 포함된 시스템인 셈이다.
다음에 고민해볼 점
결국 AI 신약 개발의 승부처는 ‘누가 더 똑똑한 모델을 가졌는가’가 아니라 ‘누가 더 효율적인 데이터 루프와 시스템을 구축했는가’로 옮겨가고 있다. 구글의 알파폴드(AlphaFold)가 길을 열었다면, 이제는 그 길 위에 실제 공장을 짓는 엔지니어들의 시대가 온 것이다. 그렇다면 우리는 단순히 LLM을 사용하는 수준을 넘어, 특정 도메인의 문제를 해결하기 위한 전용 AI 시스템을 어떻게 설계해야 할까. 데이터의 수집부터 검증, 그리고 모델의 업데이트까지 이어지는 이 거대한 파이프라인을 자동화하는 것이 우리 엔지니어들에게 주어진 다음 과제가 아닐까 싶다.