요약: OpenAI가 GPT-5.4를 고처리량 실험실과 연결해 의약화학 반응 수율을 개선한 사례를 공개했다. 개발자 관점에서 중요한 포인트는 '모델이 똑똑해졌다'가 아니라, LLM이 실제 장비·데이터·검증 루프와 연결될 때 어떤 운영 구조가 필요한지다.
OpenAI는 Molecule.one의 Maria AI 및 자동화 실험실과 GPT-5.4를 연결해 Chan-Lam coupling 반응을 개선하는 연구를 진행했다. 이 반응은 탄소-질소 결합을 만드는 의약화학 작업에서 쓰이지만, primary sulfonamide와 boronic acid 조합에서는 수율이 낮은 편이었다. 이번 결과에서 시스템은 연구 제안 생성, 실험 설계, 데이터 분석, 후속 실험 제안을 수행했고, 사람 화학자가 제안 선택과 실험 계획 보정, 벤치 스케일 재현을 맡았다.
숫자가 핵심이다. OpenAI 공개 자료에 따르면 Maria Lab은 OAI-M1-03 제안 검증을 위해 총 10,080건의 반응을 실행했다. 최적화 조건에서는 테스트한 boronic acid의 88%, sulfonamide의 83%에서 수율이 개선됐다. 평균 수율은 16.6%에서 25.2%로 올랐고, 30% 이상 수율을 보인 반응 비중은 15.6%에서 37.5%로 증가했다. 이후 사람이 14개 대표 substrate pair를 벤치 스케일에서 재현했고, 11개에서 수율 증가가 확인됐다.
개발팀이 봐야 할 지점은 'AI가 과학자를 대체한다'가 아니다. 이 사례는 LLM이 물리 세계의 실행 시스템과 연결될 때 필요한 인터페이스, 승인 흐름, 검증 데이터, 실패 처리, 보안 경계를 보여준다. 코드 에이전트, 데이터 분석 에이전트, 사내 운영 자동화 에이전트를 만들 때도 같은 문제가 반복된다.
일반적인 챗봇 사용에서는 답변 품질이 낮아도 사용자가 눈으로 확인하고 끝낼 수 있다. 하지만 실험 자동화, 배포 자동화, 재무 처리, 고객 지원 조치처럼 외부 상태를 바꾸는 시스템에서는 다르다. 모델의 제안은 실행 비용과 위험을 만든다. 잘못된 실험 계획은 시약과 시간을 낭비하고, 잘못된 운영 액션은 서비스 장애나 데이터 손실로 이어질 수 있다.
이번 연구에서 사람은 완전히 빠지지 않았다. 사람 화학자는 스티어링과 채점 프롬프트를 설계했고, 상위 제안 중 실험할 것을 선택했으며, DMSO 용매 사용처럼 위험하거나 부적절한 실험 조건을 보정했다. 최종 결과도 독립 벤치 실험으로 확인했다. 이 구조는 실무 AI 시스템의 기본 패턴과 같다.
개발팀이 가져갈 원칙은 명확하다. 모델은 제안하고, 실행 시스템은 제한된 범위에서 수행하며, 사람 또는 검증기가 게이트를 잡고, 결과는 다시 구조화된 데이터로 모델에 돌아간다. 이 네 단계가 없으면 에이전트는 데모에서는 멋져 보이지만 운영에서는 위험한 자동화가 된다.
실험 최적화가 어려운 이유는 탐색 공간이 크고, 개별 결과의 노이즈가 높고, 작은 샘플에서는 착시가 생기기 때문이다. 소프트웨어도 비슷하다. 한 번의 벤치마크, 한 번의 A/B 테스트, 한 명의 고객 피드백만으로 제품 결정을 내리면 쉽게 틀린다. 그래서 이번 사례에서 10,080건의 고처리량 실험이 중요했다. 모델의 아이디어 자체보다 그 아이디어를 반복적으로 검증할 수 있는 장비와 데이터 파이프라인이 성과를 만들었다.
AI 기능 개발에서도 같은 구조가 필요하다. 예를 들어 코드 리뷰 에이전트를 만든다면 단순히 '코드 냄새를 찾아줘'라고 호출하는 것으로 끝나지 않는다. 과거 PR, 버그 이력, 테스트 실패 로그, 리뷰어 코멘트, 배포 후 장애 데이터를 연결해야 한다. 고객 상담 에이전트라면 상담 로그, 환불 정책, 계정 상태, 금칙 액션, 에스컬레이션 기준이 필요하다.
즉, 에이전트 품질은 모델명만으로 결정되지 않는다. 모델 앞뒤의 데이터 수집, 액션 제한, 평가 루브릭, 재현성 검증이 품질을 결정한다. OpenAI AI Chemist 사례는 이 점을 과학 실험이라는 강한 검증 환경에서 보여준 셈이다.
실무에서 적용하려면 먼저 모델이 직접 실행할 수 있는 액션과 반드시 사람 승인이 필요한 액션을 분리해야 한다. 읽기 전용 분석, 후보 생성, 리포트 초안 작성은 자동화하기 쉽다. 반면 배포, 결제, 데이터 삭제, 외부 메시지 발송, 물리 장비 제어는 게이트가 필요하다.
두 번째는 결과를 자유 텍스트가 아니라 구조화된 단위로 받아야 한다. 이번 연구도 제안, 실험 조건, 원자료, 분석 결과, 후속 가설이 루프를 돌았다. 개발 시스템에서는 JSON 스키마, 작업 ID, 근거 링크, confidence, rollback plan 같은 필드가 필요하다. 그래야 로깅, 재시도, 승인 UI, 사후 분석이 가능하다.
세 번째는 평가 지표를 미리 정해야 한다. AI Chemist는 수율, substrate coverage, bench-scale replication 같은 지표가 있었다. 개발 조직에서는 테스트 통과율, 장애 감소, 처리 시간, 비용, 사용자 재문의율, human override 비율 등을 써야 한다. 지표가 없으면 모델이 개선됐는지 감으로 판단하게 된다.
예를 들어 데이터 품질 에이전트를 만든다고 하자. 모델은 매일 ETL 로그와 샘플 데이터를 읽고 이상 징후 후보를 제안한다. 실행 시스템은 읽기 전용 쿼리와 샘플링만 허용한다. 모델이 제안한 수정 SQL은 바로 실행하지 않고 PR 또는 승인 큐로 보낸다. 승인된 쿼리만 staging에서 돌리고, 행 수 변화와 검증 쿼리 결과를 다시 모델과 사람에게 제공한다.
고객지원 에이전트도 비슷하다. 모델은 환불 가능성, 정책 근거, 응답 초안을 만들 수 있다. 하지만 실제 환불 처리, 계정 제한, 외부 발송은 정책 엔진과 사람 승인 뒤에 실행한다. 모든 판단은 티켓 ID, 정책 버전, 근거 문서, 이전 대화 링크와 함께 저장한다. 이렇게 해야 나중에 왜 그런 결론이 나왔는지 추적할 수 있다.
코딩 에이전트도 마찬가지다. 모델이 수정안을 제안하고 테스트를 실행할 수는 있지만, main 브랜치 병합과 배포는 별도 게이트를 둔다. 에이전트가 만든 변경은 테스트 결과, diff 요약, 위험 파일 목록, 롤백 방법과 함께 리뷰된다. 이 구조가 없으면 작은 자동화가 커질수록 운영 리스크가 커진다.
이번 결과는 완전 자율 과학자가 등장했다는 뜻이 아니다. OpenAI도 near-autonomous라고 표현했다. 사람의 고수준 판단, 실험 인프라, 제안 선택, 실험 계획 수정, 벤치 검증이 필요했다. 또한 특정 반응과 substrate 범위에서 나온 결과이므로 다른 반응이나 제조 조건으로 일반화하려면 추가 검증이 필요하다.
AI 제품도 같은 식으로 봐야 한다. 특정 데모에서 성공했다고 제품 전체에 바로 붙이면 안 된다. 입력 분포가 바뀌면 실패 방식도 바뀐다. 특히 모델이 외부 도구를 호출하는 경우, 실패는 답변 품질 문제가 아니라 상태 변경 문제가 된다. 따라서 초기에는 읽기 전용, 낮은 권한, 작은 범위, 강한 로깅으로 시작해야 한다.
출처: OpenAI, A near-autonomous AI chemist improves a challenging reaction in medicinal chemistry, 2026-06-17.
