ScienceIDE는 전 세계에 흩어진 과학 코드 저장소(repository)를, AI 에이전트가 실제로 실행하고 검증하며 배울 수 있는 '프로그래밍 가능한 환경'으로 바꾸는 인프라다. 이렇게 만들어진 환경에서 얻은 검증된 상호작용 기록으로 PhAI-IDE-72B·9B·4B 세 개 모델을 훈련했고, held-out 과학 코드 수리(held-out scientific-code repair, 학습·검증에 포함하지 않은 과제)뿐 아니라 코드·추론·지식 같은 일반 벤치마크에서도 성능이 올랐다고 보고한다. 즉 '과학 경험'으로 배운 능력이 더 넓은 능력으로 옮겨간다는 증거(positive transfer)를 제시한 연구다.
과학 코드 저장소에는 수십 년치 인간 지식이 실행 가능한 형태로 담겨 있다. 물리 시뮬레이션, 통계 모델, 분석 도구가 전부 코드로 굳어져 있는 셈이다. 문제는 이 지식을 AI가 '학습 경험'으로 삼기가 매우 어렵다는 데 있다. 논문은 이 어려움을 세 가지로 정리한다.
이 세 가지 때문에, 방대한 과학 코드가 있어도 그것을 '믿을 수 있는 학습 경험'으로 변환하기가 힘들다. 논문은 이 병목을 과학 경험 병목(scientific experience bottleneck)이라고 이름 붙였다.
비유하자면 이렇다. 세계 최고 연구실들의 실험 노트와 장비가 창고에 가득 쌓여 있는데, 각 노트가 서로 다른 언어와 약어로 쓰여 있고, 장비마다 켜는 법이 다르며, "실험 성공"의 기준도 연구실마다 다르다. 신입 연구원(AI 에이전트)이 이걸 스스로 익히기란 거의 불가능하다. 정리되지 않은 지식은 아무리 많아도 '경험'이 되지 못한다. ScienceIDE는 바로 이 창고를 '들어가서 실제로 실험해 볼 수 있는 실험실'로 개조하려는 시도다.
ScienceIDE의 발상은 "코드를 읽게 하지 말고, 코드를 실행하고 채점받는 환경으로 만들자"는 것이다. 핵심 흐름은 초록 기준으로 다음과 같다.
먼저 전문가가 과학적 사례(scientific cases)와 수용 기준(acceptance criteria)을 정의한다. 이것이 일종의 채점 기준표이자 문제 출제 지침 역할을 한다. "이 저장소에서 이런 과제를 풀 수 있어야 하고, 그 결과가 이런 조건을 만족하면 정답으로 인정한다"는 가이드를 사람이 먼저 세워 두는 것이다.
그다음 에이전트가 이 가이드를 참고해 저장소를 실행 가능한 환경(executable environments)으로 변환한다. 이 환경은 세 가지를 지원한다.
| 기능 | 하는 일 |
|---|---|
| 과제 생성(task generation) | 저장소에서 풀 만한 문제를 만들어 낸다 |
| 실행(execution) | 에이전트가 실제로 코드를 돌려 본다 |
| 과학적 검증(scientific verification) | 결과가 수용 기준을 만족하는지 채점한다 |
이렇게 만들어진 환경은 세 가지 학습 방식이 공유하는 공통 토대(shared foundation)가 된다. 지도 미세조정(SFT, 정답 예시를 보고 배우기), 강화학습(RL, 시도와 보상으로 배우기), 그리고 평가(evaluation, 실력 측정)를 같은 환경 위에서 할 수 있다.
핵심은 검증된 상호작용 기록(verified interaction trajectories)이다. 에이전트가 환경 안에서 문제를 풀며 남긴 행동 궤적 중, 과학적 검증을 통과한 것만 골라 학습 재료로 쓴다. 요리에 비유하면, 그냥 아무 요리 과정이나 흉내 내게 하는 게 아니라, '실제로 맛을 통과한 레시피 과정'만 모아서 가르치는 셈이다. 논문은 이 재료로 PhAI-IDE-72B, PhAI-IDE-9B, PhAI-IDE-4B라는 크기가 다른 세 모델을 훈련했다.
여기서 중요한 설계 철학은 '검증 가능성'이다. 일반적인 코딩 데이터는 "그럴듯해 보이는 코드"에 그치기 쉽지만, 과학 환경은 실행과 수용 기준이라는 객관적 채점기를 갖고 있어 '진짜 맞았는지'를 가려낼 수 있다. 자기 채점이 가능한 학습장이라는 점이 이 접근의 힘이다.
초록이 밝히는 성과는 크게 두 갈래다. 구체적 수치는 초록에 제시되지 않았으므로, 여기서는 정성적으로만 정리한다.
첫째, held-out 과학 코드 수리(held-out scientific-code repair)에서 성능이 향상됐다. 다만 여기서 held-out은 미학습 저장소를 뜻하지 않는다 — 논문 §3.3은 기존 코드베이스 안에서 학습·검증에 포함하지 않은 과제로 평가했다고 명시한다. 따라서 이 결과는 훈련에 쓰지 않은 과제를 더 잘 푼다는 증거이며, 처음 보는 저장소에 대한 일반화의 증거로 해석할 수는 없다.
둘째, 그리고 이 논문에서 가장 흥미로운 부분인데, 선별된 일반 목적 벤치마크(code, reasoning, knowledge)에서도 향상이 나타났다. 과학 코드라는 좁은 영역에서 배운 경험이 코딩·추론·지식이라는 더 넓은 영역의 능력으로 옮겨갔다는 것이다. 논문은 이를 과학 경험에서 더 넓은 능력으로의 긍정적 전이(positive transfer)의 증거라고 표현한다.
의미를 정리하면 이렇다. 지금까지 AI 훈련용 데이터는 사람이 일일이 만들거나 웹에서 긁어모아야 했다. ScienceIDE는 '이미 세상에 존재하는 과학 소프트웨어' 자체를 채점 가능한 학습 기반(shared substrate)으로 바꾸자고 제안한다. 인류가 축적한 과학 코드를 에이전트가 스스로 실행하며 배우는 재료로 전환한다면, 학습 데이터의 공급원이 근본적으로 넓어진다. 논문은 이것이 에이전트 학습과 과학 실무를 하나로 잇는 통합 작업 공간(integrated workspace)의 토대가 된다고 본다.
초록만으로 판단할 때, 솔직하게 짚어야 할 지점이 있다.
이런 유보에도 불구하고, '실행·검증 가능한 환경을 학습의 1차 재료로 삼는다'는 방향 자체는 검증 가능한 데이터가 귀한 시대에 설득력이 있다.
온틀(ONTLE)은 AI 프로젝트 매니저를 파견하는 SaaS다. ScienceIDE의 발상은 우리가 에이전트 제품을 만드는 방식에 직접적인 시사점을 준다.
첫째, 코드베이스를 '읽는 대상'이 아니라 '실행하고 채점받는 환경'으로 다루라는 통찰이다. AI PM이 고객사의 저장소를 다룰 때, 코드를 요약해 읽는 것을 넘어 실제로 돌려 보고 수용 기준으로 결과를 검증하는 루프를 갖추면 훨씬 믿을 수 있는 조수가 된다. "그럴듯한 답"과 "실행으로 통과한 답"의 차이는 실무에서 결정적이다.
둘째, 검증된 상호작용 기록만 학습·개선의 재료로 쓴다는 원칙이다. 온틀 에이전트가 실제 업무를 처리하며 남긴 궤적 중, 명시적 수용 기준을 통과한 사례만 골라 축적하면 조직 고유의 신뢰할 수 있는 경험 자산이 된다. 이는 우리가 강조해 온 '근거 우선·검증 가능성' 문화와 정확히 맞닿는다.
셋째, RAG 관점에서의 함의다. 단순히 문서를 검색해 붙이는 RAG를 넘어, 검색 대상 자체를 '실행 가능하고 채점 가능한 환경'으로 승격시키면 답변의 사실성이 실행으로 뒷받침된다. 즉 회수(retrieval)와 검증(verification)을 한 파이프라인에 묶는 설계가, 도메인 특화 에이전트의 신뢰도를 높이는 실용적 경로가 될 수 있다.
넷째, 전문가가 먼저 수용 기준을 정의한다는 점은 사람과 에이전트의 역할 분담 모델로 참고할 만하다. 사람은 '무엇을 맞다고 볼지'를 정하고, 에이전트는 그 기준 안에서 반복 실행·검증·개선을 자동화한다. 온틀의 AI PM이 지향하는 협업 구조와 결이 같다.
둘 다에 걸쳐 있습니다. ScienceIDE는 과학 코드 저장소를 실행 가능한 학습 환경으로 바꾸는 인프라이고, 그 환경에서 얻은 검증된 기록으로 훈련한 결과물이 PhAI-IDE-72B·9B·4B 모델군입니다. 인프라가 먼저이고 모델은 그 위에서 나온 산출물입니다.
과학 코드에는 방대한 지식이 담겨 있지만, 파편화된 툴체인·암묵적 도메인 관례·특수한 정확성 기준 때문에 그것을 믿을 수 있는 학습 경험으로 바꾸기 어렵다는 문제를 말합니다. 지식은 많은데 학습 재료로 전환이 막혀 있다는 의미입니다.
초록은 held-out 과학 코드 수리와 함께 선별된 일반 벤치마크(코드·추론·지식)에서도 향상이 나타났다고 보고하며, 이를 긍정적 전이(positive transfer)의 증거로 제시합니다. 다만 구체적 수치나 전이가 일어나는 메커니즘은 초록에 명시되어 있지 않아 본문 확인이 필요합니다.
코드가 GitHub(aitofound/ScienceIDE)에 공개되어 있어 살펴볼 수 있습니다. 다만 전문가가 수용 기준을 먼저 정의해야 한다는 초기 비용이 있고, 초록에는 적용 범위·규모에 대한 정량 정보가 없으므로, 도입 전 자신의 도메인에 맞는 검증 기준 설계가 선행되어야 합니다.