Vecura형 Agentic AI Drug Discovery는
모델 모음이 아니라 과학 실행 운영체제다

서비스의 기본 흐름

Vecura형 Agentic AI Drug Discovery의 서비스 흐름은 다음과 같이 잡는 것이 가장 자연스럽다.

이 흐름은 고정 pipeline이 아니다. 사용자가 이미 target과 PDB를 제공하면 target discovery와 structure prediction을 건너뛰어야 하고, hit compound가 있다면 screening이 아니라 lead optimization부터 시작해야 한다. 따라서 orchestration은 조건부 Scientific DAG를 생성해야 한다.

자연어 연구목표를 기계가 실행할 수 있는 객체로 바꾼다

“KRAS G12C의 switch-II pocket에 결합하면서 hERG 위험이 낮고 oral exposure 가능성이 높은 신규 저분자를 찾아줘”라는 요청을 곧바로 docking tool에 넘기면 안 된다. 먼저 명시적 goal schema로 변환해야 한다.

Disease/Context       : cancer
Target                : KRAS G12C
Target site           : switch-II pocket
Modality              : small molecule
Mechanism             : inhibitor
Desired activity      : binding / inhibition
Constraints           : low hERG, oral exposure
Excluded chemistry    : ...
Novelty requirement   : ...
Search strategy       : known + analog + de novo
Budget / Compute      : ...
Validation level      : docking + affinity + ADMET

필요한 구성요소는 Intent Parser, Constraint Extractor, Entity Resolver, Scientific Planner, Tool Router이다. TxGemma는 therapeutic task에 특화된 LLM 계층 후보지만, LLM이 과학 계산의 결과값을 대신 만들게 해서는 안 된다. LLM은 “무엇을 할지”를 판단하고 Boltz, Vina, ADMET-AI, OpenMM 같은 도구가 “계산 결과가 무엇인지”를 반환해야 한다.

Agent는 tool name이 아니라 scientific capability를 계획해야 한다

서비스가 커질수록 “Vina를 호출한다” 같은 tool-specific plan은 유지보수가 어렵다. 대신 M10 Dock 같은 capability를 계획하고, 실제 backend는 Vina, GNINA, 향후 다른 docking engine으로 교체할 수 있게 만드는 것이 좋다.

일반 RAG가 아니라 Evidence-aware RAG

Target 또는 disease가 입력되면 시스템은 알려진 mechanism, 기존 drug, binding site, resistance mutation, supporting literature, failed evidence까지 먼저 조사해야 한다. PubMed/PMC, Europe PMC, OpenAlex는 이 계층의 공개 기반을 구성한다.

문헌 chunk만 vector DB에 저장해서는 부족하다. 최소한 claim, source, PMID/DOI, publication date, entity IDs, evidence type, supporting/contradicting, assay condition, confidence, license, retrieved_at를 함께 저장해야 한다.

Claim
Source / PMID / DOI
Publication date
Entity IDs
Evidence type
Experimental | Computational
Supporting | Contradicting
Assay context
Confidence
License
Retrieved_at

이렇게 해야 retrieval 결과가 “읽을 문서”에서 의사결정 가능한 과학적 근거로 바뀐다.

Open Targets를 중심으로 genetics·pathway·PPI를 결합한다

Target이 지정되지 않은 질의에서는 Open Targets를 중심 허브로 두고 GWAS Catalog, UniProt, STRING, Reactome을 결합하는 구조가 실용적이다. Open Targets는 disease–target association을 genetics, known drug, variant 등 다양한 evidence와 연결하고 bulk/API 접근을 지원한다.

UniProt은 sequence, function, domain, variant identity의 기준점으로 쓰고, STRING은 주변 protein association network를, Reactome은 pathway-level mechanism을 설명한다. production 환경에서는 database release와 version-specific endpoint를 고정해야 재현성이 보장된다.

Target Evidence Card

Disease genetic evidence       0.xx
Known drug evidence            0.xx
Tissue specificity             0.xx
Cancer dependency              0.xx
Pathway relevance              0.xx
PPI support                    0.xx
Druggability                   0.xx
Safety concern                 0.xx

Evidence: GWAS · Open Targets · DepMap · Reactome · ...

Target biology를 조직과 세포 맥락으로 내려보낸다

GTEx는 정상 조직 expression/eQTL, Human Protein Atlas는 tissue·cancer·cell line 수준의 RNA/protein expression, GEO는 disease/perturbation transcriptomics, DepMap은 암 세포주의 CRISPR dependency와 mutation·expression·drug screen을 제공한다.

분석도구는 Scanpy, scvi-tools, pandas/Polars, GSEApy, decoupler, NetworkX/PyTorch Geometric 등을 capability로 등록할 수 있다. 중요한 것은 omics 결과를 독립 dashboard로 끝내지 않고 target evidence graph에 귀속시키는 것이다.

Compound–Target 관계는 단순 triple이 아니다

“Compound A – Target X – IC50 30 nM”와 “IC50 800 nM”은 곧바로 contradiction이 아니다. biochemical/cellular, species, construct, ATP concentration, endpoint, protocol에 따라 의미가 달라질 수 있다.

Compound
 └─ inhibits
      ├─ Target
      ├─ IC50 / Ki / Kd
      ├─ assay type
      ├─ species
      ├─ construct
      ├─ concentration
      ├─ endpoint
      ├─ protocol
      ├─ source
      └─ timestamp

이 때문에 Vecura형 시스템에는 단순 Knowledge Graph보다 qualifier를 보존하는 Hyper-Relational Evidence Graph가 특히 잘 맞는다.

“latest”는 재현 가능한 과학 데이터 버전이 아니다

BindingDB, Open Targets, GTEx, HPA, DepMap, STRING처럼 지속 갱신되는 데이터는 프로젝트 실행 시점의 snapshot을 고정해야 한다. 예를 들어 bindingdb_2026_08, opentargets_26_06, gtex_v11, depmap_26q1처럼 저장하는 방식이다.

Experimental → Public Predicted → New Prediction 순으로 탐색한다

Target이 결정되면 구조를 무조건 새로 예측하지 않는다. 우선 RCSB PDB에서 실험구조를 검색하고, 없으면 AlphaFold Database 같은 공개 predicted structure를 확인하며, 마지막으로 Boltz-2/OpenFold3 같은 모델을 실행하는 것이 합리적이다.

RCSB는 Search API, Data API, ModelServer 등을 제공해 chain, ligand, metadata를 자동화하기 좋다. Boltz-2는 complex structure와 binding affinity를 함께 다루며 code/weights가 MIT로 공개돼 service backend에 매력적이다. OpenFold3는 Apache 2.0 공개 구현으로 상용/연구 통합에 유리하다.

반면 AlphaFold 3 weights에는 non-commercial 조건이 존재하므로, “공개 접근 가능”과 “상용 서비스에서 자유롭게 사용 가능”을 구분해야 한다.

Prediction 직후 docking을 시작하지 않는다

PDBFixer, PROPKA/PDB2PQR, fpocket/P2Rank, RDKit/Meeko, Mol* 등을 이용해 structure QC, missing atom/residue, water/ion/cofactor policy, protonation, pocket detection, docking box 생성 단계를 명시적으로 둔다.

Pocket object
source = co-crystal ligand | known residues | pocket detector
residue_set
center_xyz
box_xyz
confidence
source_structure
preparation_protocol

Agent가 좌표를 언어적으로 “상상”하는 대신 pocket source와 confidence를 구조화해 저장해야 한다.

RDKit을 화학 표준화의 중심에 둔다

RDKit은 parsing, canonicalization, fingerprint, descriptor, substructure, conformer generation의 기본 계층으로 적합하다. Raw SMILES를 그대로 식별자로 사용하지 말고 sanitization, salt removal, charge normalization, stereochemistry, tautomer handling, canonical isomeric SMILES, InChIKey를 거치는 표준화 pipeline을 만든다.

ChEMBL + PubChem + BindingDB를 기본 삼각형으로 본다

ChEMBL은 molecule, assay, activity, target, cell line, binding site를 연결하는 중심 bioactivity DB다. PubChem은 chemical identity와 BioAssay를 대규모로 제공하고 PUG REST를 통한 programmatic search가 가능하다. BindingDB는 protein–ligand binding affinity 측정값에 집중돼 affinity model과 validation에 특히 유용하다.

필요에 따라 ZINC, SureChEMBL, 공개 vendor/building-block subset을 추가한다. 그러나 provenance와 license가 불분명한 웹 수집 chemical catalog는 production evidence source로 섞지 않는 것이 좋다.

수백만 molecule을 모두 docking하지 않는다

Hit discovery는 cheap-to-expensive funnel로 설계한다. 먼저 RDKit 기반 physicochemical/risk filtering, fingerprint similarity/substructure, ML pre-screen을 수행한 뒤 구조 기반 docking으로 넘어간다.

PAINS나 Lipinski rule은 절대 탈락 판정기보다 risk feature로 다루는 것이 좋다. 탐색공간의 다양성을 과도하게 훼손할 수 있기 때문이다.

Vina baseline과 GNINA rescoring으로 검증 가능한 시작점을 만든다

AutoDock Vina는 공개 라이선스와 넓은 사용경험 덕분에 MVP baseline으로 적합하다. GNINA는 Vina/smina 계열에 CNN scoring/refinement를 결합한다. 초기에는 Vina pose generation → GNINA rescoring/refinement → Boltz-2 cross-check 같은 이질적 방법의 합의를 활용할 수 있다.

Docking provenance
receptor version
protein preparation
ligand preparation
pocket coordinates
engine / version
seed / exhaustiveness
poses
raw score / rescoring score
interaction residues
runtime / hardware

Docking score만 저장하면 재현이 불가능하다. pose coordinate와 preparation, seed, box, tool version까지 같은 run object에 포함해야 한다.

Generator는 후보를 제안할 뿐 최종 결정을 내리지 않는다

Pocket2Mol, TargetDiff 계열, diffusion SBDD, graph/SMILES/SELFIES generative model을 플러그인할 수 있다. 다만 MVP에서는 known ligand retrieval, similarity, scaffold hopping, analog exploration을 먼저 안정화하는 편이 검증 가능성이 높다.

Docking score와 affinity를 분리한다

추천 계층은 learned affinity(Boltz-2, Chemprop/D-MPNN 또는 자체 model) → consensus/pose rescoring → 상위 후보에 대한 physics calculation이다. Boltz-2는 complex structure와 affinity를 함께 예측하는 공개 도구로 유용하지만, learned affinity를 FEP 그 자체와 동일시해서는 안 된다.

Drug-likeness 한 숫자보다 therapeutic context가 먼저다

ADMET-AI와 TDC를 기반으로 Caco-2, HIA, P-gp, bioavailability, BBB, plasma protein binding, CYP inhibition/substrate, clearance, hERG, Ames, DILI, ClinTox 등 다양한 endpoint를 계산한다.

CNS drug와 peripheral oncology drug는 같은 ADMET profile을 목표로 하지 않는다. 따라서 Therapeutic Context → Desired Property Profile → Multi-objective Filtering 순으로 설계해야 한다.

MD는 모든 후보가 아니라 불확실성이 큰 상위 후보에 쓴다

OpenMM은 Python 애플리케이션에 simulation을 통합하기 좋고, GROMACS는 production-grade MD engine, MDAnalysis는 trajectory 후처리에 적합하다. Agent가 “MD passed”라고 요약하기 전에 ligand RMSD, protein RMSD, contact persistence, H-bond occupancy, interaction persistence, energy 등 구조화된 결과를 저장해야 한다.

Agent는 계산하지 않고 해석한다. 이 역할 분리가 scientific reliability를 지킨다.

최고 점수 한 개가 아니라 Pareto Front를 보여준다

사용자는 “affinity를 조금 희생하더라도 hERG와 synthesis를 우선하자”처럼 우선순위를 바꿀 수 있어야 한다. 이 steering을 반영하려면 ranking engine이 고정 weighted score 하나에 종속되지 않아야 한다.

합성 불가능한 생성물은 후보가 아니다

AiZynthFinder는 공개 retrosynthesis baseline으로 유용하다. Open Reaction Database는 구조화된 reaction data layer로 활용할 수 있다. ASKCOS는 연구 비교에는 유용하지만 공개 model/data의 non-commercial 조건을 서비스 설계에서 별도로 확인해야 한다.

실제 procurement까지 제공하려면 공개 데이터만으로 충분하지 않으며 vendor building-block catalog, 가격·재고·조달 정보에 대한 정식 라이선스 계층이 필요하다.

최종 순위는 LLM 투표가 아니라 Evidence Bundle 위에서 계산한다

Candidate C-017

Chemical identity
├─ canonical structure / scaffold / novelty
Target evidence
├─ genetics / pathway / literature
Structural evidence
├─ structure / pocket / docking / affinity
Developability
├─ ADME / toxicity / physicochemical
Physics
├─ MD stability / interaction persistence
Synthesis
├─ route / steps / precursors
Counter-evidence
├─ conflicting assays / toxicity / failed analogs
Uncertainty
└─ per-evidence confidence

좋은 출력은 “A가 0.87점이라 최고”가 아니다. “A는 affinity와 synthesis에서 강하지만 hERG uncertainty가 크므로 B와 함께 secondary assay로 넘기는 것이 합리적”처럼 trade-off와 다음 실험을 설명하는 결정이어야 한다.

초기에는 최소 일곱 역할로 분리한다

이들을 독립 LLM이 자유롭게 대화하도록 두기보다, 역할별 허용 tool과 input/output schema를 제한하는 것이 더 안전하고 재현 가능하다.

실제 핵심 IP는 모델보다 Registry와 Router가 될 수 있다

tool_id / name / version
scientific_task
input_schema / output_schema
method_type = physics | ML | database | heuristic
required_compute = CPU | GPU | memory
expected_latency / estimated_cost
valid_domain / limitations
uncertainty_output
license / commercial_use
container_digest
validation_dataset / validation_metrics

이 메타데이터를 가지고 Router는 “10만 후보이므로 저비용 Vina를 병렬 실행하고 상위 0.5%만 GNINA/Boltz-2로 재평가한다” 같은 결정을 할 수 있다. 이는 LLM tool calling을 Cost-Based Scientific Query Optimization으로 확장하는 문제다.

비결정적 판단과 결정적 실행을 분리한다

Agent는 next action, tool selection, hypothesis, interpretation, exception strategy를 담당한다. Workflow Engine은 container execution, retry, dependency, GPU scheduling, timeout, checkpoint, provenance를 담당한다.

Agent framework는 planning/control plane에, Argo Workflows 같은 container-native engine은 compute execution plane에 배치하는 구조가 실용적이다.

한 종류의 DB로 모든 것을 해결하지 않는다

모든 결과에 “왜 이 결과가 나왔는가”를 붙인다

Run UUID / Parent Run UUID
User hypothesis / Scientific Goal Object
Input checksum / source
Dataset name / release / retrieval date / license
Tool / version / Git commit / container digest
Model / weights hash / model license
Parameters / random seed
Hardware / runtime
Output checksum
Uncertainty / validation status
Evidence citations
Reviewer / approval status

몇 달 뒤 “왜 Candidate 017을 선택했는가?”라는 질문에 완전히 재현 가능한 답을 제공하는 것이 scientific provenance의 목적이다.

Human gate는 optional UI가 아니라 시스템 제어점이다

• Gate 1 — Target selection: 실제 프로그램으로 진행할 target인지 승인한다.
• Gate 2 — High-cost compute: MD/FEP 같은 고비용 계산을 실행할 가치가 있는지 승인한다.
• Gate 3 — Candidate nomination: 어떤 후보를 실제 assay로 넘길지 결정한다.
• Gate 4 — Experimental interpretation: 실패가 단순 failure인지 새로운 hypothesis인지 판단한다.
• Gate 5 — External action: 합성, 구매, 외부 실험 같은 실제 비용 행위를 승인한다.

내부 assay와 SAR가 축적되기 시작할 때 플랫폼의 성격이 바뀐다

초기에는 공개 데이터로 대부분의 기능을 구축할 수 있다. 그러나 장기적으로 경쟁력을 만드는 것은 내부 positive assay, inactive compound, failed synthesis, toxicity, failed target hypothesis, SAR, protocol, batch, experimental condition이다.

따라서 ELN/LIMS/CSV/SDF/API로 들어오는 실험결과를 자동 ingestion하고 upstream evidence와 연결하는 pipeline이 필요하다.

성공한 것만 기억하는 Agent는 연구자의 절반만 흉내 낸다

Candidate X
Docking          Strong
Boltz affinity   Strong
MD               Stable
ADMET            Acceptable
Wet-lab          INACTIVE

→ conformation mismatch?
→ assay condition mismatch?
→ permeability / target engagement?
→ OOD affinity prediction?
→ revise hypothesis

실패를 discarded sample이 아니라 새로운 hypothesis를 생성하는 evidence로 저장해야 한다. Experiment → Observation → Contradiction → Hypothesis Revision이 closed-loop AI Co-Scientist의 핵심이다.

Agent, RAG, Target, Docking, Affinity, ADMET, Generation을 따로 평가한다

최종 KPI는 모델 정확도가 아니라 연구 생산성이다

Scientific KPI로 hit enrichment, novel hit rate, experimental confirmation, lead progression rate를 두고, Agentic KPI로 workflow success, tool-selection accuracy, recovery, evidence-grounded claim ratio, unsupported claim rate, human intervention rate를 측정한다.

Operational KPI는 time-to-candidate, cost per candidate, GPU-hour per nominated hit, reproducibility rate를 포함할 수 있다.

이 지표는 Agent가 더 많은 tool을 호출했는지가 아니라 실험적으로 확인되는 후보를 얼마나 효율적으로 만들었는가를 직접 측정한다.

먼저 18개의 과학 capability를 안정화한다

M01 LiteratureSearch       M10 Dock
M02 TargetEvidence         M11 AffinityPredict
M03 ProteinAnnotation      M12 ADMETPredict
M04 ProteinInteraction     M13 MolecularDynamics
M05 StructureSearch        M14 MoleculeGenerate
M06 StructurePredict       M15 Retrosynthesis
M07 PocketDetect           M16 EvidenceVerify
M08 CompoundSearch         M17 CandidateRank
M09 SimilaritySearch       M18 Report

이렇게 구성하면 Planner는 implementation name에 종속되지 않고 과학적 capability를 계획할 수 있다. 도구 교체는 Registry에서 처리한다.

Phase 1 — Grounded Agentic Drug Discovery MVP

Natural-language goal → Goal Parser → PubMed/Open Targets/ChEMBL/PubChem RAG → target/compound evidence → PDB/AFDB/Boltz → RDKit → Vina → ADMET-AI → evidence-grounded ranking → report를 하나의 서비스로 완성한다. TxGemma, PostgreSQL/pgvector, Tool Registry, Provenance를 공통 기반으로 둔다.

Phase 2 — Multi-Agent Discovery Intelligence

Target, Evidence, Structure, Chemistry, Critic agent를 분리하고 STRING/Reactome, GTEx/HPA, GEO/DepMap, BindingDB, GNINA, Boltz-2 affinity, generative design, AiZynthFinder, OpenMM을 추가한다. 이 시점부터 기능적으로 Vecura에 가까운 플랫폼이 된다.

Phase 3 — Closed-Loop AI Co-Scientist

여기에 internal assay ingestion, ELN/LIMS integration, active learning, uncertainty-aware tool routing, negative-result memory, counter-evidence agent, scientific belief graph, automated benchmark, cost-aware scientific planner를 추가한다.

공개 도구인 TxGemma, Open Targets, ChEMBL/PubChem/BindingDB, UniProt/PDB/AFDB, RDKit, Boltz-2/OpenFold3, Vina/GNINA, ADMET-AI/TDC, OpenMM/GROMACS, AiZynthFinder/ORD만으로도 강력한 1차 플랫폼을 구축할 수 있다. 이후 내부 assay, SAR, negative results가 축적될수록 시스템은 공개 도구를 연결한 서비스에서 기관 고유의 연구경험을 축적하는 AI Co-Scientist로 변한다.