기능 상세 보고

Silo A — 3-Arm 가상스크리닝 (NVIDIA NIM)

SILO A 청색 계열. 본 페이지의 모든 사실 주장은 코드 file:line 또는 산출물 경로로 인용한다. 신뢰등급: 실측 HIGH / surrogate-상대 MED / surrogate-절대 LOW.

핵심 결론

• 설계·코드는 완성, 실행 사례는 0건. Silo A 3-Arm(소분자·펩타이드·de novo) 6개 모듈이 모두 구현되어 단위테스트(mock) 9건을 통과했으나 [근거: docs/meet_preparation/inspect_evidence/silo_a.md:174], end-to-end 실행은 단 한 번도 없다(outputs/silo_a/ 미존재) [근거: docs/meet_preparation/inspect_evidence/silo_a.md:171].
• 실행 차단 원인은 NVIDIA NIM API 키 부재. Arm1·Arm3가 클라우드 NIM에 의존하며, 활성 라우터는 _has_nim_api_key()=os.getenv("NVIDIA_NIM_API_KEY")로 키 유무를 게이트한다 [근거: AgenticAI4SCIENCE_pyrosetta_track/repos/ai4sci-kaeri/backend/routers/silo_a.py:65-66]. 현재 환경에 키 미설정 [근거: docs/meet_preparation/inspect_evidence/silo_a.md:195].
• NIM 3-arm 전체는 비활성이나, 활성 통합 파이프라인은 로컬 de novo 경로(_run_silo_a)를 실제 호출한다. NIM 의존 3-arm(소분자·펩타이드·de novo)은 백업·스텁 상태이지만, pipeline_local/orchestrator.py:_run_silo_a()는 Arm3에 해당하는 RFdiffusion+ProteinMPNN을 NIM 없이 로컬 GPU로 가동한다 [근거: pipeline_local/orchestrator.py:1395-1454, 843-853]. 실제 발굴 성과는 대부분 Silo B(PyRosetta) 경로 산물 — "NIM 3-arm 미실행 / 로컬 de novo 부분 가동" 으로 정직 표기.

1. 위치: "설계"가 아니라 "구현됨, 미실행"

주장 → 근거 → 함의

• 주장: Silo A는 설계만 있는 것이 아니라 실제 코드까지 존재한다. 다만 어떤 위치에서도 end-to-end로 돌아간 적은 없다.
• 근거:
• 설계 문서: docs/SYSTEM_ARCHITECTURE.md (3-arm 구조 ASCII 도식) [근거: docs/SYSTEM_ARCHITECTURE.md:25, 34-46]
• 실제 코드(백업, 비활성): _backup/orphaned_20260609/pipelines/silo_a/src/ 6개 모듈 [근거: _backup/orphaned_20260609/pipelines/silo_a/README.md:17-26]
• 활성 HTTP API(스텁): backend/routers/silo_a.py — Phase 1 dry-run만 노출 [근거: AgenticAI4SCIENCE_pyrosetta_track/repos/ai4sci-kaeri/backend/routers/silo_a.py:1-7]
• 함의: "Silo A = 미구현"은 사실이 아니다. 정확한 상태는 "코드 완성 · 실행 0건 · API 스텁". PI 보고 시 "설계 단계"로 뭉뚱그리지 않고 구현 수준을 분리 표기해야 정직하다.

1.1 위치 맵 — 4곳에 분산

[데이터: _workspace/report_site2/_evidence/EV08_silo_a_trace.md §2] — 위 맵은 EV08 추적 결과를 요약한 것.

2. 3-Arm 아키텍처 도식

도식 출처: 코드 구조(arms.py 3 Runner + scoring.py UnifiedScorer) [근거: _backup/orphaned_20260609/pipelines/silo_a/src/arms.py:24-284, scoring.py:9-76]. rank → outputs/silo_a는 계획 단계(미실행) [근거: docs/meet_preparation/inspect_evidence/silo_a.md:171].

3. Arm별 구현 상세 (코드 흐름: 목적 → 입력 → 연산 → 출력)

각 Arm은 추상 베이스 ArmRunner.run(config, clients)를 구현하며, 진입 시 cfg.enabled가 False면 즉시 RunStatus.SKIPPED를 반환하고, 예외는 errors 리스트에 누적해 SUCCESS/PARTIAL로 상태를 분기한다 [근거: _backup/orphaned_20260609/pipelines/silo_a/src/arms.py:13-21, 35-40, 90-97].

Arm 1 — 소분자 (MolMIM 생성 → QED 정렬 → DiffDock 도킹)

• 목적: 기존 SSTR2 리간드 SMILES를 시드로 약물유사 신규 소분자를 생성하고, 포켓에 도킹해 결합 신뢰도를 매긴다. 실측 HIGH(코드 존재)
• 입력: config의 arm1.seed_molecules(이름·SMILES 쌍), 생성 파라미터(molmim_num_molecules=10, molmim_algorithm="CMA-ES", molmim_property="QED", molmim_min_similarity=0.3), 그리고 도킹 타깃 pocket.complex_pdb [근거: config.py:36-46].
• 흐름: 1. 각 시드마다 clients.molmim.generate(...)로 분자 집단을 받고, 응답 dict에서 sample(SMILES)과 score(QED)를 추출해 CandidateRecord로 적재 [근거: arms.py:42-61]. 2. 전체 후보를 qed 내림차순 정렬 후 상위 top_k_for_docking(기본 15)만 도킹 대상으로 선별 [근거: arms.py:65-66, config.py:43]. 3. 선별된 각 후보를 clients.diffdock.dock_smiles(protein_pdb_path, smiles, num_poses=5)로 도킹하고 응답의 confidence를 피처에 병합 [근거: arms.py:71-81, config.py:44]. 도킹 예외 시 해당 후보는 dock_confidence=0, dock_success=0으로 폴백 적재 [근거: arms.py:82-88].
• 출력: dock_confidence/dock_success가 채워진 CandidateRecord 리스트 + 집계 피처(total_generated, total_docked)를 담은 ArmResult [근거: arms.py:90-97].
• 함의: 골격은 완비됐으나 molmim.generate·diffdock.dock_smiles 모두 NIM 클라우드 호출이라 키 부재 시 전량 예외 폴백 → 사실상 미가동. 1차 타깃이 펩타이드(SST-14)라 우선순위가 낮았던 것으로 보임 — [미검증: 우선순위 결정 근거 문서 없음].

Arm 2 — 펩타이드 (변이체 → 변이 추출 → FlexPepDock, 조건부)

• 목적: wildtype 대비 변이체 펩타이드의 결합 에너지를 PyRosetta 도킹으로 평가한다. PyRosetta가 없으면 변이 개수만 기록하는 조건부 구현. 조건부
• 입력: arm2.wildtype 서열, arm2.variants(이름·서열), 게이트 플래그 use_pyrosetta(기본 True)·complex_pdb·relax_after_dock [근거: config.py:49-60].
• 흐름: 1. use_pyrosetta=True 이고 complex_pdb가 지정된 경우에만 pipelines.silo_b.src.docking.PyRosettaDockingRunner를 import해 도킹 러너를 초기화. import 실패 시 경고만 남기고 서열 분석 모드로 강등, complex_pdb 미설정 시 도킹 비활성 경고 [근거: arms.py:121-144]. 2. 각 변이체에 대해 wildtype과 길이를 검증(불일치 시 error 적재 후 skip)하고, 위치별 차이를 {wt}{i+1}{mt} 형식 변이 문자열로 추출 [근거: arms.py:146-160]. 3. 도킹 러너가 있으면 dock_candidate(...)로 ΔG(delta_energy)·성공 여부를 산출하고, 성공+relax_after_dock이면 PyRosettaComplexRelaxer.relax(...)로 ΔG를 갱신하며 clash/interface/RMSD를 추가. 도킹 러너가 없으면 dock_success=0만 기록 [근거: arms.py:162-184].
• 출력: 변이 개수와(가능 시) 도킹/relax 피처를 담은 CandidateRecord 리스트의 ArmResult [근거: arms.py:185-197].
• 함의: Arm2는 Silo B(PyRosetta 변이+도킹)와 동일 자원에 의존하므로(코드상으로도 silo_b.src.docking을 직접 import), 실제 발굴은 Silo B가 전담하고 Arm2는 Silo A 내부에서 중복·미가동 상태가 됨.

Arm 3 — de novo (RFdiffusion 백본 → ProteinMPNN 서열 → ESMFold pLDDT)

• 목적: 포켓을 타깃으로 백본을 디자인하고(RFdiffusion) 그 위에 서열을 입혀(ProteinMPNN) 접힘 신뢰도(ESMFold pLDDT)로 거르는 신규 바인더 3단 설계. 실측 HIGH(코드 존재)
• 입력: pocket.complex_pdb, arm3.num_designs(기본 5), seqs_per_backbone(4), diffusion_steps(50), plddt_threshold(70.0), 그리고 config.seed [근거: config.py:63-70].
• 흐름: 1. num_designs회 clients.rfdiffusion.design_binder(pdb_path, contigs="B1-369/0 10-30", hotspot_res=[], diffusion_steps, random_seed=seed+i)를 호출해 백본 PDB를 수집 [근거: arms.py:217-231]. 2. 각 백본에 clients.proteinmpnn.predict(input_pdb, num_seq_per_target, sampling_temp=0.2)로 서열을 디자인하고, 응답이 FASTA 문자열이면 parse_fasta로, 리스트면 그대로 파싱 [근거: arms.py:233-252]. 3. 각 서열을 clients.esmfold.predict(seq)로 접고 mean_plddt(리스트면 평균)를 계산, plddt >= plddt_threshold(70.0)인 서열만 CandidateRecord로 채택 [근거: arms.py:254-272, config.py:67].
• 출력: pLDDT≥70 서열의 CandidateRecord + 집계 피처(backbones, designed_seqs)를 담은 ArmResult [근거: arms.py:276-283].
• 함의: 가장 야심찬 경로이나 3개 NIM(RFdiffusion/ProteinMPNN/ESMFold)이 모두 필요 → NIM 키 없이는 가동 불가. 단, 같은 RFdiffusion+ProteinMPNN 조합이 활성 레포의 로컬 경로(pipeline_local)에서는 NIM 없이 실제로 가동된다(§8 참조).

4. 오케스트레이션 — Arm 순차 실행 → 통합 랭킹 → UnifiedCandidate 변환

• 목적: 3개 Arm을 순서대로 돌려 후보를 모으고, 단일 점수로 통합 랭킹한 뒤, 사일로 간 비교용 표준형(UnifiedCandidate)으로 환산한다. 실측 HIGH(코드 존재)
• 입력: config 경로 + NimClientBundle(주입형 클라이언트 묶음) [근거: _backup/orphaned_20260609/pipelines/silo_a/src/orchestrator.py:30-41].
• 흐름: 1. _build_arms()가 [Arm1, Arm2, Arm3]를 생성하고 execute()가 각 Arm을 순차 실행 — Arm이 예외를 던져도 RunStatus.FAILED로 감싸 다음 Arm으로 진행(부분 실패 격리) [근거: orchestrator.py:43-68]. 2. 모든 Arm 후보를 합쳐 UnifiedScorer.rank_candidates(...)로 점수·순위 부여 [근거: orchestrator.py:70]. 3. Arm별 상태·후보수·에러수를 요약한 manifest를 JSON으로 기록하고 PipelineResult 반환 [근거: orchestrator.py:72-97]. 4. to_unified()가 Arm→Modality 매핑과 함께 피처를 bridge 지표(dg_est, clash, stability, feasibility)로 환산해 UnifiedCandidate 리스트 생성 [근거: orchestrator.py:99-144].
• 출력: run_manifest.json + 랭킹된 후보 + 사일로 통합용 UnifiedCandidate 리스트.
• 함의: 부분 실패를 격리하는 구조라 일부 Arm만 가동돼도 파이프라인이 완주하도록 설계됨. 단 §6대로 end-to-end 실행 자체가 0건이라 manifest 산출물은 미존재.

5. UnifiedScorer — 이질 Arm 점수 통합 (정규화 → 가중합산 → 정렬)

• 목적: 3개 Arm의 서로 다른 피처(QED, dock_confidence, ΔE, pLDDT)를 공통 0–1 척도로 정규화·가중합산해 Arm 간 직접 비교가 가능한 단일 점수를 산출하고 순위를 매긴다. 실측 HIGH(코드 존재)
• 입력: ScoringConfig.weights(qed 0.15·dock_confidence 0.35·delta_energy 0.25·plddt 0.15·diversity 0.10) + 각 후보의 features dict [근거: _backup/orphaned_20260609/pipelines/silo_a/src/config.py:73-80].
• 흐름: 1. score_candidate(features, arm)가 Arm 종류에 따라 해당 피처만 normalize(value, lo, hi)로 minmax 정규화 후 가중치를 곱해 arm_score/arm_max를 누적 [근거: scoring.py:21-36]. 2. arm_max>0이면 arm_score/arm_max로 0–1 재정규화(clamp) [근거: scoring.py:38-44]. 3. 다양성 항과 결합: score = (1 − w.diversity)·normalized_arm + w.diversity·diversity 후 0–1 clamp + 4자리 반올림 [근거: scoring.py:46-49]. 4. rank_candidates(...)가 전 후보에 점수를 부여하고 내림차순 정렬해 1부터 rank를 채워 새 CandidateRecord로 재생성 [근거: scoring.py:51-76].
• 출력: score·rank가 채워진 정렬된 CandidateRecord 리스트.

• 함의: Arm 간 직접 비교가 가능한 공통 척도를 설계한 점은 강점. 단, 모든 점수는 상대 순위용 surrogate — 절대 친화도/활성을 의미하지 않음 surrogate-상대 MED.

⚠️ 알려진 결함: diversity 가중치(scoring.py:46-47)가 합산에 들어가나, 어떤 Arm도 diversity 피처를 산출하지 않음 → features.get("diversity", 0.0)이 항상 0으로 귀결, 즉 다양성 항이 점수에 기여하지 않고 최대 점수를 0.9로 깎는 효과만 남음 [미검증: 의도 미구현인지 사후 추가 계획인지 불명] [근거: scoring.py:47, docs/meet_preparation/inspect_evidence/silo_a.md:156-165, EV08 §4].

6. NVIDIA NIM 의존성 — 실행 차단의 핵심

주장 → 근거 → 함의

• 주장: Arm1·Arm3는 NVIDIA NIM 클라우드 API에 직접 의존하며, 이것이 Silo A 미실행의 근본 원인이다.
• 근거:
• 5개 NIM 클라이언트가 bionemo/에 구현됨 (MolMIM, DiffDock, ProteinMPNN, ESMFold, RFdiffusion 5개 *_client.py 파일 모두 실재 확인) [근거: _backup/orphaned_20260609/bionemo/{molmim,diffdock,proteinmpnn,esmfold,rfdiffusion}_client.py]
• 엔드포인트 예: MolMIM https://health.api.nvidia.com/v1/biology/nvidia/molmim, DiffDock …/mit/diffdock [근거: EV08 §2.C]
• 활성 API의 dry-run 게이트 — _has_nim_api_key() = os.getenv("NVIDIA_NIM_API_KEY") [근거: backend/routers/silo_a.py:65-66], 키 없으면 dry-run 강제 [근거: backend/routers/silo_a.py:69-70]
• 현재 환경 키 미설정 [근거: docs/meet_preparation/inspect_evidence/silo_a.md:195]
• 함의: Silo A 실행 = 외부 클라우드 자격증명 확보가 선행조건. 온프레미스(KAERI) 운영 정책상 클라우드 의존이 부담이었던 것으로 보이며, 실제 활성 파이프라인은 NIM을 제거하고 로컬 경로로 전환됨(§8).

7. 활성 HTTP API — Phase 1 스텁 (목적 → 입력 → 연산 → 출력)

• 목적: 활성 레포의 Silo A FastAPI 라우터는 실제 추론 없이 dry-run 잡 수락과 환경 헬스 프로브만 노출한다. 실제 모델 호출은 Phase 2 워커로 유보. 스텁
• 입력: SiloARunRequest(sequences·use_nim·arms) [근거: AgenticAI4SCIENCE_pyrosetta_track/repos/ai4sci-kaeri/backend/routers/silo_a.py:25-28].
• 흐름:
• 헤더 주석이 의도를 명시: "Phase 1 intentionally exposes dry-run orchestration and health probes only…Real ProteinMPNN, RFdiffusion, ESMFold, and DiffPepBuilder calls are reserved for the Phase 2 worker integration." [근거: backend/routers/silo_a.py:1-7]
• POST /run은 _nim_dry_run_enabled(use_nim)(= use_nim and not _has_nim_api_key())로 dry-run 여부를 판정하고, 새 job_id(uuid4)와 "inference is deferred to Phase 2" 메시지만 반환 — 실제 추론 호출 없음 [근거: backend/routers/silo_a.py:69-70, 119-129].
• GET /status/{job_id}·GET /results/{job_id}는 빈 stub 응답 [근거: backend/routers/silo_a.py:132-150].
• GET /health는 _has_nim_api_key()와 _discover_conda_env_names()(conda env list --json subprocess)로 NIM 키 유무·필수 conda env 4종(proteinmpnn/rfdiffusion/esmfold/diffpepbuilder) 가용성을 점검해 보고 [근거: backend/routers/silo_a.py:22, 73-116, 153-168].
• 출력: dry-run 판정·job_id·헬스 상태 등 메타데이터 JSON (모델 산출물 없음).
• 함의: API 계약(스키마·라우트)은 정의됐으나 워커 통합(Phase 2)은 미구현. PI 관점에서 "API가 있다 ≠ 추론이 돈다"를 분명히 구분해야 함.

8. 활성 로컬 경로 — pipeline_local._run_silo_a() (NIM 없이 실제 가동)

중요 정정: Silo A가 100% 비활성인 것은 아니다. 활성 통합 파이프라인(pipeline_local)은 NIM을 제거한 로컬 de novo 경로를 실제로 호출한다. (Arm1 소분자·Arm2 펩타이드는 미포함, Arm3에 해당하는 백본+서열 설계만)

• 목적: 듀얼 사일로 루프에서 Silo A 몫으로 RFdiffusion 백본 설계 + ProteinMPNN 서열 설계를 로컬 GPU로 실행해 서열 후보를 공급한다. 실측 HIGH(코드 존재)
• 입력: step01_out(receptor_pdb_path, pocket_residues), iteration, 그리고 config["dual_silo"]["silo_a"](gpu_device 기본 2, 선택적 n_backbone·k_seq_per_backbone) [근거: pipeline_local/orchestrator.py:1395-1426].
• 흐름: 1. dual 전용 파라미터로 config를 덮어쓰고 device="cuda:{gpu_device}" 설정 [근거: pipeline_local/orchestrator.py:1414-1426]. 2. step02_backbone.generate_backbones(receptor_pdb, pocket_info, config) 실행 — 백본 PDB가 없으면 경고 후 빈 리스트 반환(Silo B만으로 진행) [근거: pipeline_local/orchestrator.py:1428-1438]. 3. step03_sequence.design_sequences(backbones, config)로 서열 설계, 실패 시 빈 리스트 반환 [근거: pipeline_local/orchestrator.py:1441-1450]. 4. 호출부에서 로그 "Silo A (RFdiffusion + ProteinMPNN) 실행 중..." 후 결과를 듀얼 분기로 전달 [근거: pipeline_local/orchestrator.py:843-853].
• 출력: SequenceEntry 리스트(실패 시 빈 리스트). 이후 후보에는 source="silo_a" 태그가 부여되어 Silo B 산물과 구분·통합된다 [근거: pipeline_local/orchestrator.py:983-990, 1217-1228].
• 함의: 백업의 NIM 3-arm과 달리, 활성 로컬 경로는 Arm3 골격(RFdiffusion+ProteinMPNN)만 로컬로 운영하며 ESMFold·MolMIM·DiffDock·FlexPep은 빠져 있다. 즉 "Silo A 전량 미실행"이 아니라 "NIM 3-arm 미실행 / 로컬 de novo 부분 가동 가능"으로 정직 표기해야 한다.

9. 정직 표기: 의도 구조 vs. 실제 활성 코드 (P5 괴리)

주장 → 근거 → 함의

• 주장: docs/SYSTEM_ARCHITECTURE.md가 기술한 Silo A/B 분리 구조는 현재 활성 코드베이스에 존재하지 않는다.
• 근거:
• 의도: 최상위 pipelines/silo_a/·pipelines/silo_b/ [근거: docs/SYSTEM_ARCHITECTURE.md:24-30]
• 실제: 최상위 pipelines/ 부재, 활성 코드는 독립 레포 …/ai4sci-kaeri/의 pyrosetta_flow/ + AG_src/pipeline/ 단일 통합 [근거: EV14 §1, docs/SYSTEM_ARCHITECTURE.md vs 실제 ls 결과]
• NIM 클라이언트는 활성 레포에 부재(백업에만 존재), runner는 "ESMFold 필요 → OFF" 등 NIM 비활성 명시 [근거: EV14 §3]
• 함의: Silo A는 초기 아키텍처(클라우드 NIM 3-arm)의 유산으로, 온프레미스 PyRosetta 통합 파이프라인으로 진화하며 비활성 보존됨. 본 보고는 실제 코드 위치 기준으로 작성하고 이 괴리를 명시한다(원칙 P5).

도식 출처 [근거: _workspace/report_site2/_evidence/EV14_arch_gap.md §1, §3].

10. 종합 상태표 (정직 등급)

총평: Silo A = NIM 3-arm 설계+구현 완료 / NIM 경로 실행 0건 / 활성 로컬 de novo(Arm3) 부분 가동 가능. 실제 발굴 성과는 대부분 Silo B 경로 산물이며, NIM 3-arm 전체는 클라우드 키 재도입 또는 워커(Phase 2) 통합 시 재활성 가능한 자산.

용어

• NIM (NVIDIA Inference Microservice): NVIDIA가 호스팅하는 생물학 모델 추론 클라우드 API (MolMIM·DiffDock·RFdiffusion·ProteinMPNN·ESMFold).
• QED: Quantitative Estimate of Drug-likeness (약물유사성 0–1).
• pLDDT: ESMFold 구조 예측 신뢰도 (0–100, 70 이상 채택).
• FlexPepDock: PyRosetta 기반 유연 펩타이드 도킹 프로토콜.
• dry-run: 실제 추론 없이 오케스트레이션 경로만 검증하는 모의 실행.