미스트랄은 9월 9일 유럽 에너지 사업자의 저류 시뮬레이터를 포트란77에서 C++로 이전하면서 자사 AI 에이전트를 어떻게 활용했는지 담은 고객 사례를 공개했다. 전체 코드베이스는 30만 줄이며, 이번에 손을 댄 것은 그중 4만 줄이다. 프로젝트 시작 시점에는 테스트 스위트도 없었고, 문서도 한곳에 정리돼 있지 않았다.
보고서는 포트란77이 다루기 까다로운 이유를 구체적으로 정리했다. 모듈도, 네임스페이스도, 구조체도 없다. 프로그램 상태는 COMMON 블록에 저장되는데, 이는 프로그램 전체가 공유하는 전역 메모리나 마찬가지다. 변수는 첫 글자에 따라 암묵적으로 타입이 정해지고, 변수명은 최대 6자로 제한돼 있어 코드를 읽는 것은 거의 추측에 가깝다.
첫 시도는 작업 전체를 에이전트 혼자 맡기는 방식이었지만 일주일이 걸리고도 성공하지 못했다. 이후 사람이 개입해 모듈 단위로 작업을 쪼개는 방식으로 바꿨다. 각 모듈은 기획, 구현, 테스트, 코드 품질 검토라는 네 가지 역할로 나뉘었고, '계획 → 구현 → 테스트 → 재시도'의 루프로 진행됐다. 사람이 계속 개입한 주된 역할은 에이전트가 막혔을 때 풀어주는 것이었다.
코드보다 문서가 먼저
문서 작업은 Vibe CLI 위에서 100개가 넘는 에이전트를 동시에 띄워 진행했다. 각 에이전트는 문서 라이브러리와 미스트랄 OCR을 통해 관련 PDF를 가져와 읽을 수 있었다. 산업용 소프트웨어의 물리적 가정은 종이 보고서나 스캔본에만 적혀 있는 경우가 많은데, 이는 문서가 한곳에 정리돼 있지 않은 프로젝트에서 가장 손이 많이 가는 부분이다.
모듈 분할은 경험적으로 정한 기준을 따랐다. 포트란 코드는 모듈당 약 1만 줄 이내로 유지한다.
수치 일치를 검증 기준으로
이 프로젝트를 지탱한 것은 세 부분으로 이뤄진 대조 검증 장치다. 포트란 코드베이스의 실행 상태를 내보내는 서브루틴 모음, 그 체크포인트를 C++로 불러오는 테스트 프레임워크, 그리고 이 둘을 올바르게 쓰도록 에이전트를 안내하는 여러 개의 Skill.md 파일이다.
보고서가 제시한 구체적인 사례는 이렇다. 한 에이전트가 포트란 코드에 한 줄을 추가해 변수 RHOG의 값을 출력하게 했고, 그 실행에서 나온 값은 42.71834였다. 이후 같은 숫자를 참조 체크포인트로 삼아 이전된 C++ 모듈을 테스트했다.
"Numerical agreement is the cheapest, most convincing proof that a module is done."
수치가 일치한다는 것은 모듈 이전이 끝났음을 증명하는 가장 값싸고도 가장 설득력 있는 방법이다.
여기서 핵심은 미스트랄이 어떤 모델을 썼는가가 아닐 수도 있다. 전력, 석유, 기상, 항공 같은 분야의 핵심 연산 코드에는 1970~80년대에 짜인 포트란 코드가 지금도 대량으로 남아 있다. 테스트도 문서도 없고 원저자는 이미 은퇴한 경우가 대부분이라는 점도 똑같다. 지난 십수 년간 '다시 짜자'는 이야기는 대개 검수 단계에서 막혔다. 비교할 기준이 없으니 다시 짠 결과물에 누구도 서명하려 하지 않았기 때문이다. 미스트랄의 방식은 그 서명 권한을 수치 체크포인트에 넘긴 것이다. 이 부분은 어느 회사의 에이전트를 쓰느냐와는 무관하며, 실행 가능한 레거시 코드만 있으면 직접 구축할 수 있다.
전제 조건에 대해서도 보고서는 솔직하게 밝힌다. 미스트랄 스스로도 이번 출발 조건이 유리했다고 인정한다. 포트란 코드베이스가 그 자체로 완결돼 있었고 실제로 실행 가능했다는 것이다. 보고서는 이보다 확실히 더 어려운 세 가지 경우를 꼽는다. 외부 시스템에 의존하는 경우, 비교할 실행 가능한 기준선이 아예 없는 경우, 물리적 가정이 전혀 문서화돼 있지 않은 경우다. 수작업으로 다시 짜는 것보다 얼마나 빠른지에 대해서는 보고서에 구체적인 수치가 나와 있지 않다.
참고 출처: 미스트랄 공식 블로그, CocoLoop; 코드 줄 수, 모듈 분할 기준, 에이전트 역할 구성, RHOG 체크포인트 수치는 공식 사례 보고서를 바탕으로 확인.