AI가 짠 코드, 과학은 못 짠다 — OpenAI 필드 리포트로 본 AI 코딩 에이전트의 능력과 한계

지난 8월 1일 OpenAI가 학계 파트너들과 함께 공개한 한 필드 리포트는, 화려한 신모델 발표 대신 다소 소박해 보이는 제목을 달고 있었다. 낡고 방치된 과학 소프트웨어를 AI 코딩 에이전트가 어떻게 되살릴 수 있는지를 다룬 여덟 개의 실제 사례 보고서였다. 그런데 그 내용을 들여다보면, 최근 화제가 된 'AI가 수학 난제를 풀었다'는 소식보다 오히려 더 실감 나게 지금 AI가 무엇을 잘하고 무엇을 못하는지를 보여준다. 유전체 분석 파이프라인의 품질관리 도구 15종을 하나로 합쳐 처리 시간을 15시간 34분에서 14분 54초로, 60배 넘게 줄인 사례부터가 그렇다.

과학용 소프트웨어에는 오래된 골칫거리가 있다. 논문 하나를 위해 대학원생 한두 명이 급하게 짜놓은 코드가, 시간이 지나면서 그 분야 전체가 의존하는 핵심 도구가 돼버리는 일이 흔하다. 유지보수할 사람도 예산도 없이 방치되지만 그렇다고 버릴 수도 없는 처지가 되는 것이다. 실제로 발표된 R 스크립트 9000여 개를 조사한 한 대규모 연구에서는 74%가 깨끗한 환경에서 첫 실행조차 실패했고, 유전체 분석 도구 98종을 살펴본 다른 연구에서는 57%가 공식 설치 안내를 그대로 따라도 오류가 났다는 결과가 나온 적이 있다. 이런 소프트웨어 위기가 이번 리포트의 출발점이다. OpenAI의 코덱스(Codex)와 앤트로픽의 클로드 코드(Claude Code)를 하나씩, 또는 서로 맞세워 코드를 쓰고 검토하는 역할을 번갈아 맡기는 방식으로, 여덟 개 연구팀이 실제로 쓰는 소프트웨어를 현대화하는 실험을 진행했다.

가장 극적인 수치를 보여준 것은 시쿠에라(Seqera)의 필립 이웰스가 이끈 러스트QC(RustQC) 프로젝트다. RNA 염기서열 분석 파이프라인에서 쓰이는 품질관리 도구 15개는 원래 각자 따로 같은 대용량 파일을 읽고 각자 중간 결과를 써내려가는 구조였다. 이 비효율을 알아챈 팀이 이 도구들을 하나의 러스트(Rust) 프로그램으로 합쳐 파일을 한 번만 읽고 모든 계산을 동시에 처리하도록 다시 짰더니, 1억8600만 개 서열 데이터 기준으로 15시간 34분 걸리던 작업이 14분 54초로 끝났다. 처리량 병목의 원인이 연산 자체가 아니라 파일을 몇 번이나 다시 읽고 쓰느냐에 있었다는 것을, 에이전트가 정확한 사양을 받았을 때는 구현해낼 수 있었던 셈이다. 더 야심찬 사례는 호주 가반 연구소의 제임스 퍼거슨이 이끈 러스타얼라이너(rustar-aligner) 프로젝트였다. 20년 가까이 유전체 분석에 널리 쓰였지만 더 이상 관리자가 없는 2만 줄 분량의 C/C++ 프로그램 'STAR'를 클로드 코드로 처음부터 러스트로 다시 짠 것이다. 효모 유전체 서열 1만 개를 기준으로 기존 프로그램과 비교했을 때 단일 리드 기준 99.815%, 페어드 리드 기준 99.883%까지 일치율을 끌어올렸고, 어느 한쪽에서만 매핑에 실패한 서열은 하나도 없었다.

하지만 이 리포트가 정말로 하려는 이야기는 속도 자랑이 아니다. 참여 연구자들이 하나같이 강조하는 지점은, 에이전트가 아무리 빨리 코드를 써내도 그 결과가 과학적으로 맞는지는 스스로 판단하지 못한다는 사실이다. 러스타얼라이너 프로젝트는 90% 일치율에서 한동안 멈춰 섰는데, 남은 오류들이 서로 겹겹이 쌓여 있어 하나를 고치면 다른 곳이 틀어지는 상황이었다. 에이전트는 테스트가 실패하면 스스로 짜놓은 코드를 되돌리는 식으로 반응했을 뿐, 근본 원인을 찾아내지는 못했다. 결국 연구자가 직접 나서서 기존 STAR와 새 코드에 동시에 디버깅 코드를 심어 서열 하나하나를 양쪽에서 추적하는 방식으로 문제를 하나씩 짚어내야 했다. 유전체 데이터를 GPU에서 처리하도록 새로 만든 헬릭스포지(HelixForge) 프로젝트에서는 더 인상적인 사례가 나왔다. 검증 과정에서 이상 신호가 뜨자 에이전트는 곧바로 자신이 만든 GPU 코드를 고치기 시작했는데, 알고 보니 문제는 검증 코드 쪽의 다운샘플링 로직에 있는 버그였다. 에이전트는 실패한 테스트가 '무엇이 잘못됐다는 신호'인지는 인식했지만, '어느 쪽이 잘못됐는지'는 구분하지 못한 것이다. 이 프로젝트를 이끈 미노스AI(MinosAI) 팀은 결국 사람이 나서서 문제가 코드가 아니라 테스트에 있었음을 밝혀냈다.

품질관리 도구를 만든 이웰스는 이런 특징을 두고 에이전트가 "말은 그럴듯하고 설득력 있지만, 놓치기 쉬운 방식으로 확신에 차서 틀린다"고 표현했다. 그는 실제로 모델이 원래 도구와 수치가 조금씩 어긋나는 걸 알고도 그 차이를 "과학적으로 타당하다"거나 "허용 가능하다"고 스스로 판단해버리는 경향을 발견하고, 에이전트에게 자기 작업의 정확성을 절대 판단하게 하지 않았다고 밝혔다. 대신 실제 공개된 서열 데이터를 여러 생물종에 걸쳐 대규모로 돌려보는 독립적인 검증 장치를 따로 구축해, 에이전트가 지나치려 했던 차이를 걸러냈다. cyvcf2 프로젝트를 담당한 브렌트 페더슨의 말은 이 리포트 전체를 관통하는 결론에 가깝다. "에이전트가 있으면 빠르게 가는 건 꽤 쉬워졌다. 다만 지금 단계에서 과학적으로 멀리까지 가려면, 여전히 전문가의 지도와 이해, 감각, 그리고 정성이 필요하다."

이 발견은 단순히 'AI가 아직 부족하다'는 이야기로 끝나지 않는다. 리포트는 에이전트 덕분에 절약되는 시간을 수치로도 제시했는데, 연구 소프트웨어 100개에 걸쳐 설치 오류의 25~50%를 에이전트가 해결해준다고 가정하면 절약되는 연구 시간의 가치가 60만~490만 달러에 이르고, 널리 쓰이는 파이썬 라이브러리 넘파이(NumPy) 하나만 봐도 연간 약 650시간의 유지보수 작업이 줄어들 수 있다고 추산했다. 문제는 이 절감액에 정작 가장 품이 많이 드는 작업, 즉 에이전트의 결과물을 검증할 별도의 기준과 장치를 만드는 비용이 빠져 있다는 점이다. 여덟 개 사례 중 일곱 개에서, 사람이 가장 많은 시간을 쏟은 일은 에이전트를 지도하거나 코드를 검토하는 것이 아니라 바로 이 검증 인프라를 처음부터 구축하는 작업이었다. 누가 새로 만들어진 코드를 계속 관리할 것인가 하는 문제도 아직 정리되지 않았다. 더 이상 관리자가 없던 STAR의 후속 버전인 러스타얼라이너는 결국 개인이 아니라 연구 컨소시엄에 넘겨져 여러 기관이 함께 관리하는 체계로 옮겨졌는데, 이는 저렴해진 재작성 비용이 오히려 비슷한 도구들을 우후죽순 늘려 전문가들의 관심을 여러 갈래로 흩어놓을 수 있다는 우려에 대한 나름의 답이었다.

결국 이 필드 리포트가 보여주는 그림은 '코드를 짜는 일'과 '그 코드가 과학적으로 맞는지 아는 일'이 완전히 다른 종류의 작업이라는 사실이다. AI 코딩 에이전트는 앞의 일을 사람이 감당할 수 없던 규모로 해치우기 시작했지만, 뒤의 일은 여전히, 그리고 어쩌면 앞으로 더 오랫동안 사람의 몫으로 남아 있을 가능성이 크다. OpenAI의 과학 부문을 이끄는 케빈 와일은 2025년이 소프트웨어 엔지니어링에서 AI가 도약한 해였다면 2026년은 과학이 그런 해가 될 것이라고 말했지만, 이 리포트가 실제로 증명하는 것은 그보다 좀 더 신중한 이야기다. 병목이 '코드를 누가 쓰느냐'에서 '그 결과를 누가, 어떻게 검증하느냐'로 옮겨가고 있을 뿐, 과학에서 사람이 빠져나가는 것은 아니라는 것이다.