Theory Under Construction: Orchestrating Language Models for Research Software Where the Specification Evolves

새로운 종류의 자동차를 만들려고 하지만 완성된 설계도가 없는 상황을 상상해 보세요. 대신 엔진을 그리고, 부품을 제작하며, 소유자 매뉴얼을 동시에 작성할 수 있는 천재적이고 사고가 빠른 엔지니어들 (AI) 팀이 있습니다.

문제는 이 엔지니어들이 두 가지 특정 실수를 저지르기 쉽다는 점입니다:

1. "Fake It Till You Make It (해낼 때까지 속여라)" 함정: 그들은 실제로 엔진을 만들어 증명하기 전에 매뉴얼에 "이 차는 시속 200 마일로 달린다"고 적을 수 있습니다. 그다음 엔지니어는 그 주장을 읽고 그것이 사실이라고 가정하며 시속 200 마일을 견딜 수 있도록 차체를 설계합니다. 만약 엔진이 실제로 그 속도를 낼 수 없다면, 전체 프로젝트는 거짓 위에 세워진 것이 됩니다.
2. "번역 중 분실 (Lost in Translation)" 함정: 엔진을 설계한 엔지니어가 작동 방식에 대해 생각을 바꿀 수 있지만, 매뉴얼을 작성하는 사람은 이를 모릅니다. 이제 매뉴얼은 구형 엔진을 설명하고, 설계도는 신형 엔진을 보여주며, 조립 라인에 있는 실제 자동차는 완전히 다른 무언가가 됩니다. 그들은 서로 멀어지게 됩니다.

이 논문인 "Orchestrating Language Models for Research Software Where the Specification Evolves (명세가 진화하는 연구용 소프트웨어를 위한 언어 모델의 오케스트레이션)" 는 이러한 문제들을 해결하기 위해 Comet-H라는 새로운 시스템을 소개합니다. 이 시스템은 연구를 직선으로 보지 않고, 음악, 춤사위, 그리고 무용수들이 서로에게 끊임없이 조정해야 하는 춤으로 다룹니다.

핵심 아이디어: AI 를 위한 "지휘자"

단순히 AI 에게 "코드를 작성하라"고 요청하는 대신, 저자들은 전체 오케스트라를 관리하는 지휘자 (컨트롤러) 를 구축했습니다. 이 지휘자는 AI 에게 무엇을 해야 하는지 알려주는 것을 넘어, 코드, 수학 이론, 벤치마크, 그리고 논문이 포함된 "작업 공간"을 끊임없이 점검하여 무엇이 누락되었거나 동기화가 깨졌는지 확인합니다.

다음은 Comet-H 가 작동하는 방식을 간단한 비유로 설명한 것입니다:

1. "사라지는 할 일 목록 (Obligation Decay)"

책을 쓰고 있다고 상상해 보세요. "이 장의 사실 확인이 필요하다"는 스티커 메모가 있습니다.

• 구식 방식: 확인을 잊어버리면 메모는 책상 위를 어지럽히며 영원히 남아 있거나, 무시하고 넘어갑니다.
• Comet-H 방식: 메모에는 반감기가 있습니다. 프로젝트에서 한 걸음 전진할 때마다 메모는 조금씩 희미해집니다. 만약 곧바로 처리하지 않으면 사라집니다. 하지만 매우 최근의 것이라면 선명한 붉은색으로 빛납니다.
• 왜 중요한가: 이는 AI 가 아직 생생한 동안 미해결 과제 (예: "이 주장을 증명하라") 를 처리하도록 강제합니다. AI 가 부채를 무시하려 하면 "빛"이 더 밝아지고, 지휘자는 AI 가 다음 단계로 넘어가기 전에 멈추고 이를 수정하도록 강제합니다.

2. "현실 점검 (Reactive Grounding)"

AI 가 프로젝트의 "공식적인 얼굴" (예: README 파일이나 연구 논문) 을 변경할 때마다 Comet-H 는 일시 정지 버튼을 누릅니다.

• 규칙: 사실을 확인하지 않고는 이야기를 바꿀 수 없습니다.
• 과정: AI 가 "우리의 도구는 10 배 더 빠릅니다"라고 작성하면, 시스템은 즉시 멈추고 "좋습니다, 경주 결과를 보여주세요"라고 말합니다. 이는 AI 가 코드를 실행하여 주장을 입증하는 "grounding ledger (기계 판독 가능한 영수증)"를 생성하도록 강제합니다.
• 결과: 이는 "해낼 때까지 속여라" 함정을 막습니다. 거짓말은 잡히고 수정되기 전까지 한 단계만 생존할 수 있습니다.

3. "안전한 걸음 (Adjacency Constraints)"

때로는 AI 가 흥분하여 "자전거를 만드는 것"에서 "우주선을 만드는 것"으로 뛰어오르고 싶어 할 때가 있습니다.

• 규칙: Comet-H 는 인접한 이동만 허용합니다. AI 는 한 걸음만 앞으로 나아갈 수 있습니다 (예: "자전거에 기어를 추가한다"). 하지만 완전히 다른 우주로 점프할 수는 없습니다.
• 왜 중요한가: 이는 프로젝트를 현실에 발붙이게 합니다. AI 가 핵심 이론을 변경하고 싶다면, 어제 구축한 것과 여전히 연결되는 방식으로 수행해야 합니다. 이는 팀이 원래 무엇을 만들려 했는지 잊을 정도로 서로 너무 멀어지는 것을 방지합니다.

결과: "a3" 사례 연구

저자들은 46 개의 다양한 연구용 소프트웨어 프로젝트를 구축하여 이 시스템을 테스트했습니다. 이 중 주인공은 Python 코드에서 버그를 찾는 프로그램인 a3입니다.

• 도전 과제: 일반적으로 버그 찾기 도구는 시끄러운 이웃과 같습니다. 문제가 없어도 모든 것에 "버그!"라고 외칩니다. 이로 인해 많은 오보가 발생합니다.
• Comet-H 접근법: 이 시스템은 단순히 도구를 구축하는 것을 넘어, 그 뒤의 이론을 진화시켰습니다. 단순한 아이디어로 시작했으나 계산이 너무 어렵다는 것을 깨닫자, 지휘자는 팀이 실제로 작동하는 새로운 수학적 접근법 ("안전 인증서" 사용) 으로 전환할 수 있도록 했습니다.
• 결과: 최종 도구는 놀라울 정도로 정확했습니다. 고장 난 것이 아닌 것에 대해 외치지 않으면서 실제 버그를 포착했습니다 (높은 정밀도). 테스트 척도에서 0.768점을 기록한 반면, 그다음으로 좋은 도구는 0.364점만 기록했습니다.

AI 행동에 대해 배운 점

이 46 개의 프로젝트에서 AI 가 작동하는 것을 지켜보면서 저자들은 몇 가지 흥미로운 패턴을 발견했습니다:

• "정리 팀"은 실재합니다: 초기에는 AI 가 새로운 기능을 구축하는 데 바쁘지만, 프로젝트가 막바지에 가까워질수록 AI 는 대부분의 시간을 감사 및 수정에 보냅니다. 마치 건설 팀이 프로젝트 마지막 주에 새로운 벽을 짓는 대신 페인트가 마르고 문이 열리는지 확인하는 것과 같습니다.
• 정직성이 발현됩니다: 주장을 증명하도록 강요받으면 AI 는 놀랍도록 정직해졌습니다. 실패를 숨기는 대신 "우리는 아직 이 특정 유형의 문제를 해결할 수 없습니다"라고 명시적으로 진술하기 시작했습니다. 이 시스템은 정직성을 프로그래밍한 것이 아니라, "현실 점검"이 거짓말을 너무 어렵게 만들었기 때문에 발현된 것입니다.
• 자기 조직화: 시간이 지남에 따라 AI 는 누구에게도 명시적으로 지시받지 않았음에도 불구하고 자신의 코드를 더 깔끔하고 논리적인 구조로 조직하기 시작했습니다.

큰 그림

이 논문은 연구용 소프트웨어를 구축하는 것이 문서의 오타를 수정하는 것과 다르다고 주장합니다. 이는 공진화 (co-evolution) 과정입니다. 이론, 코드, 테스트, 그리고 이야기는 함께 성장해야 합니다.

단순히 AI 에게 "논문과 코드를 작성하라"고 요청하면, AI 는 아마도 방향을 잃고, 환각을 보며, 동기화가 깨질 것입니다. 하지만 점수를 끊임없이 확인하고, 현실 점검을 강제하며, 걸음들이 연결되도록 보장하는 지휘자를 제공한다면, 실제로 작동하는 복잡하고 신뢰할 수 있는 연구용 도구를 구축할 수 있습니다.

간단히 말해: Comet-H 는 AI 가 공상하는 것을 막고 약속을 지키도록 강제하여, AI 가 말하는 이야기가 작성하는 코드와 일치하도록 보장하는 시스템입니다.