신약개발 AI 에이전트 설계: 생성보다 검증 루프가 먼저다 | DAKER 커뮤니티

신약개발 AI 에이전트는 답변을 잘 쓰는 챗봇이 아닙니다. 목표를 작은 작업으로 나누고, 필요한 데이터와 도구를 선택하고, 결과를 검증한 뒤 다음 행동을 결정하는 실행 시스템에 가깝습니다.

LangChain의 영상에서 Abridge 제품 총괄 Janie Lee는 고위험 의료 AI를 운영할 때 생성 모델 하나보다 상태 그래프, 평가기, 추적, 재시도가 중요하다고 설명합니다. 임상 AI가 환자나 증상을 잘못 연결하고 근거 없는 내용을 만들 수 있듯, 신약개발 에이전트도 표적–질환 관계를 잘못 연결하거나 검증되지 않은 기전·분자·합성 경로를 확신에 차서 제시할 수 있습니다.

설계 원칙
에이전트의 품질은 첫 답의 유창함이 아니라, 근거를 남기고 오류를 감지하며 안전하게 다음 행동을 선택하는 구조에서 나옵니다.

1. 하나의 프롬프트 대신 상태 그래프로 나누기

복잡한 과정을 한 번의 프롬프트에 넣으면 어느 단계에서 오류가 생겼는지 알기 어렵습니다. LangGraph 같은 상태 그래프에서는 각 단계를 독립된 노드로 만듭니다.

목표 입력 → 계획 수립 → 근거 검색 → 도구 실행 → 결과 검증 → 재시도 또는 보고서 생성

2. 에이전트 상태는 구조화된 데이터로

노드 사이에 긴 자연어만 전달하면 오류가 누적됩니다. objective, plan, evidence, tool_calls, candidates, constraints, validation, retry_count를 명시적인 필드로 관리하는 편이 좋습니다.

AgentState = { objective, plan[], evidence[], tool_calls[], candidates[], constraints[], validation, retry_count, final_report }

이 구조를 쓰면 특정 후보가 어떤 근거와 계산을 거쳐 선택됐는지 추적할 수 있고, 실패한 단계만 다시 실행할 수 있습니다.

3. 도구 호출은 계약처럼 설계하기

에이전트가 도구 이름과 설명만 보고 자유롭게 호출하게 두면 잘못된 단위, 누락된 입력, 존재하지 않는 식별자가 들어가기 쉽습니다. 각 도구에 입력·출력 스키마와 실패 조건을 둡니다.

4. 생성 경로와 평가 경로를 분리하기

답을 만든 모델에게 스스로 맞았는지 묻는 것만으로는 충분하지 않습니다. 생성 그래프와 별도의 평가 그래프를 두고 두 종류의 검사를 결합합니다.

평가기 역시 오류를 낼 수 있으므로 전문가가 판정한 소규모 예시로 먼저 보정하고, 평가기 간 결론이 다르거나 고위험 조건에 걸린 사례만 사람에게 전달합니다.

5. 실패를 그래프의 정상 경로로 만들기

좋은 에이전트는 실패하지 않는 시스템이 아니라 실패를 처리하는 시스템입니다. 검색 근거 충돌, 인용 불일치, 화학적 제약 위반, 도구 결과의 단위 오류, 반복 횟수 초과를 예외 메시지로 끝내지 말고 그래프의 분기 조건으로 사용합니다.

실패 원인을 상태에 기록한 뒤 검색 질의를 바꾸거나, 대체 도구를 호출하거나, 후보를 폐기하거나, 사람의 검토를 요청해야 합니다.

6. 신약개발 작업에 적용한 예시

‘질환 X의 새로운 표적 후보를 찾고 기존 약물의 재창출 가능성을 평가하라’는 목표는 다음처럼 실행할 수 있습니다.

  1. Planner가 질환 기전, 표적 근거, 약물–표적 관계, 안전성 검토로 작업을 분해합니다.
  2. Retriever가 각 주장에 source ID를 붙여 근거를 수집합니다.
  3. 후보 생성 노드가 표적과 약물을 연결하되 최소 근거 수를 요구합니다.
  4. 도구 노드가 구조·물성·상호작용 정보를 계산하고 표준 스키마로 저장합니다.
  5. Verifier가 주장–근거 일치, 데이터 충돌, 제약 위반을 검사합니다.
  6. Router가 통과 후보만 보고서로 보내고, 불확실한 후보는 추가 검색 또는 전문가 검토로 보냅니다.

운영 전 기술 체크리스트

출처

Redirecting to 신약개발 AI 에이전트 설계: 생성보다 검증 루프가 먼저다 | DAKER 커뮤니티...