OpenAI와 학계 협력자들이 발표한 새로운 현장 보고서는 AI 코딩 도구가 과학에서 소홀하지만 중요한 문제, 즉 많은 연구실이 의존하지만 제대로 지원할 시간은 거의 없는 연구 소프트웨어의 유지와 현대화에 유용해지고 있다고 주장한다. 8개의 사례 연구에서 연구자들은 코딩 에이전트를 사용해 설치 시스템을 업데이트하고, 레거시 코드를 더 새로운 프레임워크로 포팅하고, 성능을 최적화하고, 심지어 오래된 도구를 새 언어로 다시 작성하기도 했다.

핵심 결론은 승리 선언보다 경고에 가깝다. 보고서에 따르면 Codex, Claude Code, GPT-5.5, GPT-5.2 같은 시스템은 구현 작업을 때로는 큰 폭으로 가속할 수 있지만, 결과물인 소프트웨어가 과학적으로 올바른지를 판단하도록 믿을 수는 없다. 실제로 이는 병목을 코드 작성에서 테스트 설계, 출력 검증, 장기 유지 책임 배분으로 옮긴다.

보고서가 말하는 변화

The Decoder가 공식적인 대표 조사라기보다 현장 기록으로 설명한 이 보고서는 주로 생물학 관련 소프트웨어에 초점을 맞춘다. 많은 연구 도구가 단일 논문이나 프로젝트를 위해 작성된 코드로 시작한 뒤, 상업용 소프트웨어에 흔한 인력이나 엔지니어링 규율 없이 더 넓은 워크플로에 편입되었기 때문에 이 점은 중요하다.

그런 환경에서 코딩 에이전트는 작업이 명확하고 검증 목표를 미리 정의할 수 있을 때 가장 유용해 보인다. 한 예로 cyvcf2라는 유전 데이터를 읽는 Python 라이브러리에서 GPT-5.5를 사용해 오래된 빌드 및 설치 구성을 더 현대적인 것으로 바꿨다.

더 복잡한 예는 면역 세포가 어떤 표적을 인식할 수 있는지 예측하는 면역학 모델 MHCflurry였다. 보고서에 따르면 Claude Code와 Codex는 TensorFlow에서 PyTorch로 약 1만 줄의 코드를 포팅하는 동안 구현과 검토 역할을 번갈아 맡았다. 이런 마이그레이션은 유지보수성과 성능을 위해 자주 필요하지만, 과학 소프트웨어는 겉보기에는 정상 작동하는 것처럼 보여도 미묘하게 잘못된 출력을 낼 수 있어 위험하다.

가장 야심찬 사례는 STAR를 Rust로 다시 쓴 rustar-aligner였다. STAR는 시퀀싱 리드를 게놈 위치에 매핑하는 데 널리 쓰이며, 보고서는 원래 코드베이스가 2만 줄이 넘는 C와 C++로 되어 있고 더 이상 적극적으로 유지보수되지 않는다고 말한다. 1만 개의 짧은 효모 세포 시퀀싱 리드를 대상으로 한 테스트에서, 보고서의 비교 기준에 따르면 rustar-aligner는 단일 엔드 케이스의 99.815%, 페어 엔드 케이스의 99.883%에서 STAR와 일치했다. 저자들은 또한 한 도구가 완전히 매핑하지 못한 리드를 다른 도구도 전혀 매핑하지 못한 경우는 없었다고 밝혔다.

큰 속도 향상에는 대가가 있었다

보고서에서 강조한 성능 향상은 상당하지만, 여러 팀을 대상으로 한 통제된 벤치마크가 아니라 개별 프로젝트에서 나온 것이다.

15개의 품질관리 도구를 하나의 프로그램으로 통합한 RustQC는 대형 데이터셋에서 실행 시간을 15시간 34분에서 14분 54초로 줄여, 60배 이상 빨라졌다고 보고됐다. 또 다른 프로젝트 HelixForge는 합성 게놈 데이터 생성을 위한 BamSurgeon을 GPU 기반 버전으로 대체했다. 인용된 테스트에서는 한 기증자의 데이터와 1,000만 염기쌍 게놈 구간을 사용했으며, 전체 파이프라인은 BamSurgeon보다 59.6배 빨랐고 주요 계산 단계는 98.6배 빨랐다.

다른 프로젝트들은 덜 극적이지만 여전히 주목할 만했다. 게놈 조립 도구 hifiasm에서는 연구자가 먼저 별도의 훈련 및 검증 데이터셋을 만든 뒤, GPT-5.5가 실제 인간 게놈 데이터에서 실행 시간을 거의 15% 줄이는 최적화를 찾았다고 보고됐다. HI.SIM에서는 GPT-5.2와 그보다 새로운 모델이 프로그램의 서로 다른 부분을 최적화해, 출력은 바꾸지 않으면서 실행 시간을 총 약 31% 개선했다고 보고서는 밝힌다.

이러한 결과는 연구 엔지니어링에서 AI 에이전트의 실용적인 단기 역할을 시사한다. 즉, 자율 과학이 아니라 코드 현대화, 의존성 복구, 성능 튜닝, 프레임워크 마이그레이션이다. 파이프라인이 취약한 연구실에는 보고서의 최고 사례에 못 미치더라도 의미 있는 개선이 될 수 있다.

모델이 실패한 곳

보고서의 가장 중요한 메시지는 소프트웨어가 과학적 가정을 담고 있을 때, 테스트를 통과하거나 그럴듯한 출력을 내는 것만으로는 충분하지 않다는 점이다.

bayesm 사례 연구가 그 문제를 보여준다. Rust로 다시 작성한 버전은 원본보다 2배에서 20배까지 빨랐다고 하지만, 두 고급 방법의 초기 버전에는 출력만으로는 알아내기 어려운 오류가 여전히 남아 있었다. 한 경우 코딩 에이전트가 제어 매개변수를 반대로 뒤집어 의도한 값의 역수를 사용했다. 별도의 계산 버그도 함께 빠져나갔다. 연구자들은 알려진 결과를 가진 수천 개의 합성 데이터셋으로 세밀한 보정을 수행한 뒤에야 이런 문제를 발견했다.

bayesm의 또 다른 방법인 HART는 전반적으로 그럴듯한 결과를 내면서도, 지나치게 비용이 큰 계산과 잘못 스케일된 보정 계수 등 여러 결함을 포함하고 있었다. 이 사례의 교훈은 분명하다. 소프트웨어는 수치적으로 안정적이고 과학적으로도 타당해 보일 수 있지만, 후속 해석에 중요한 방식으로 여전히 틀릴 수 있다.

프로젝트 참여자들도 이 우려를 분명히 했다. cyvcf2 개발자 Brent Pedersen은 코딩 에이전트가 빠르게 움직이게 해 주지만 과학에는 여전히 “expert guidance, understanding, taste, and care”가 필요하다고 썼다. RustQC를 이끈 Philip Ewels는 이 시스템들을 “eloquent, convincing, and confidently wrong in ways that are easy to miss”라고 설명했다. The Decoder의 보도에 따르면 그는 모델이 자기 정확성을 평가하게 두지 않았고 대신 독립적인 테스트 하네스를 사용했다.

이러한 역할 분담은 사례 연구 전반에서 반복된다. 인간은 목표, 수용 기준, 검증 방법을 정의하고, 에이전트는 구현을 생성한 뒤, 전문가가 소프트웨어가 실제로 올바른 과학 작업을 수행하는지 확인한다.

증거, 한계, 그리고 이 주장들의 출처

이 이야기에서 가장 강한 주장은 The Decoder의 설명에 따르면 OpenAI와 학계 파트너가 만든 현장 보고서에서 나온다. 사례 연구는 참가자들의 회고적 기록일 뿐, 연구 소프트웨어 작업에 대한 무작위 또는 대표 조사 자료가 아니다. 이 한계는 중요하다.

따라서 RustQC, HelixForge, hifiasm, HI.SIM, bayesm, rustar-aligner, MHCflurry, cyvcf2의 성능 수치는 관련 팀이 보고한 프로젝트별 결과다. 이는 신중하게 범위를 정한 조건에서 무엇이 가능한지를 보여 주는 예시로 읽어야 하며, 다른 코드베이스에서도 코딩 에이전트가 같은 이득을 안정적으로 제공한다는 일반적 증거로 읽어서는 안 된다.

같은 주의는 보고서의 경제적 추정에도 적용된다. 저자들은 100개의 연구 패키지에서 설치 문제의 4분의 1에서 절반을 에이전트가 해결한다면 회수되는 연구 시간의 가치는 60만 달러에서 거의 500만 달러에 이를 수 있다고 제안한다. 또 NumPy의 연간 유지보수 시간 절감 효과를 약 650시간으로 추산한다. 이 수치는 보고서의 방향성 추정치일 뿐, 외부 검증된 시장 데이터는 아니다.

보고서는 또 하나의 중요한 조직적 위험을 지적한다. 저렴한 재작성은 파편화를 만들 수 있다는 점이다. 연구실이 커뮤니티가 유지관리할 수 있는 속도보다 더 빨리 기존 도구의 대체 버전을 만들어 낸다면, 사용자를 분열시키고 유지보수자의 시간을 더 많이 소모할 수 있다. 이 우려는 사례들에서도 나타났다. 일부 개선은 원래 프로젝트에 다시 병합되었지만, 그렇지 않은 경우도 있었다. STAR는 더 이상 유지보수되지 않았기 때문에 rustar-aligner는 scverse로 옮겨갔다. 다른 경우에는 FastQC 작성자가 원래 도구를 Rust 재작성 버전으로 대체하는 것을 거부했고, 팀은 대신 발견된 개선 사항을 기존 Java 버전에 적용해 같은 3배 속도 향상을 얻었다.

빌더와 기업 AI 팀에 왜 중요한가

AI 빌더에게 이 보고서는 코딩 에이전트를 끝에서 끝까지 자율적인 개발자라기보다 인프라 보조 도구로 보는 논리를 강화한다. 유용한 패턴은 “에이전트가 코드를 작성하고 배포한다”가 아니라 “에이전트가 엄격한 검증 루프 안에서 변경을 제안한다”는 것이다. 이는 의료, 바이오텍, 금융, 산업 시스템처럼 규제되거나 위험이 큰 영역에서 일하는 기업 AI 팀에 특히 중요하다.

Codex, Claude Code, GPT-5.5, GPT-5.2를 평가하는 제품 팀에게 실용적인 시사점은 신뢰성이 모델 자체보다 주변 프로세스에 더 크게 좌우된다는 점이다. 독립적인 테스트 하네스, 골드 스탠더드 데이터셋, 공식 수용 기준, 인간 검토는 여전히 필수다. 과제를 더 명확하게 명세할수록 코딩 에이전트가 더 큰 가치를 제공하는 것으로 보인다.

연구 기관과 기업 구매자에게는 순수한 속도 향상보다 유지보수 측면이 더 중요할 수 있다. 많은 기관은 원저자가 떠난 오래되었지만 필수적인 소프트웨어에 의존한다. AI 코딩 도구가 업그레이드, 프레임워크 포팅, 의존성 수정, 성능 튜닝의 비용을 낮출 수 있다면 중요한 도구의 수명을 연장할 수 있다. 하지만 구매자는 검증과 향후 관리의 부담도 함께 떠안게 된다.

다음에 주목할 점

다음으로 지켜볼 신호는 이런 사례 연구 방식이 반복 가능한 워크플로로 바뀌는지 여부다. 이는 더 나은 모델만으로는 부족하다. 표준화된 평가 하네스, 더 명확한 책임 모델, 재작성된 도구를 신뢰할 수 있는 기준선과 비교하는 더 강력한 관행이 필요하다.

또 AI 지원 재작성에 제도적 안식처를 제공하는 scverse 모델을 더 많은 커뮤니티가 따를지도 지켜볼 만하다. 또 다른 지표는 NumPy나 PyTorch 주변의 과학 라이브러리 같은 중요한 프로젝트의 유지관리자들이 일상 작업에는 에이전트 기반 유지보수를 도입하면서도 알고리즘 변경에는 더 엄격한 인간 검토를 유지할지 여부다.

마지막으로 모델의 진보도 여전히 중요하다. MHCflurry 작업에 참여한 한 사람은 2025년 초의 이전 시도가 당시 사용 가능한 모델이 아직 충분히 유능하지 못해 실패했다고 말했다고 전해진다. 그 평가가 맞다면, 더 새로운 세대는 에이전트가 처리할 수 있는 작업 범위를 넓힐 수 있다. 하지만 이 보고서는 향상된 코딩 유창성이 과학적 판단이라는 더 어려운 문제를 해결해 주지는 않는다고 시사한다.

Creati.ai 관점

이 보고서는 AI 에이전트 논쟁에서 중요한 순간에 나온다. 종종 혼동되는 두 개념, 즉 그럴듯하게 올바른 소프트웨어를 생성하는 것과 과학적으로 신뢰할 수 있는 소프트웨어를 생산하는 것을 분리해 보여 주기 때문이다. 연구 환경에서 이 둘은 같지 않다. 코딩 에이전트가 더 설득력 있어질수록 구현 품질과 도메인 정확성을 혼동하는 것은 더 위험해진다.

AI 산업에 이는 더 현실적인 기회를 가리킨다. 당장의 시장은 완전 자율 연구 엔지니어링이 아니다. 취약한 소프트웨어 스택을 현대화하고, 레거시 코드를 이전하며, 유지보수 적체를 줄이는 동시에 검증을 더 체계적으로 만드는 도구다. 강력한 코드 생성에 더해 견고한 테스트, 추적성, 검토 워크플로를 결합하는 공급업체가 자율성만 파는 업체보다 더 지속적인 가치를 만들 가능성이 높다.