LLM이 로켓 과학을 풀다 — GTOC 12 도전과제 분석

LLM이 로켓 과학을 풀다 — GTOC 12 도전과제 분석
안내: 본 포스트의 한글 요약 및 분석 리포트는 AI 기술을 통해 자동 생성되었습니다. 정보의 정확성을 위해 하단의 [원본 논문 뷰어] 또는 ArXiv 원문을 반드시 참조하시기 바랍니다.

초록

본 논문은 최신 대형 언어 모델(LLM)이 12번째 글로벌 궤도 최적화 대회(GTOC 12)와 같은 고차원 물리 제약 환경에서 자율적인 다단계 계획을 수행할 수 있는지를 평가한다. MLE‑Bench를 궤도역학에 맞게 변형하고 AIDE 기반 에이전트를 구축해 GPT‑4‑Turbo, Gemini 2.5 Pro, o1 등 여러 모델을 실험하였다. 전략적 타당성 점수는 2년 사이 9.3→17.2점으로 크게 상승했지만, 물리 단위 오류·경계조건 실수·디버깅 비효율 등 구현 단계에서 지속적인 실패가 관찰됐다. 결론은 LLM이 개념적 설계와 전략 수립에서는 뛰어나지만, 완전한 자동 엔지니어링을 위해서는 구현 장벽을 극복해야 함을 강조한다.

상세 분석

논문은 먼저 LLM 평가의 기존 한계를 지적한다. 전통적인 코딩·코드 생성 벤치마크는 제한된 입력‑출력 형태에 머물러 있어, 물리적 제약이 복합적으로 얽힌 최적화 문제를 충분히 검증하지 못한다. 이를 보완하기 위해 저자들은 MLE‑Bench 프레임워크를 GTOC 12의 궤도 설계 과제로 변형하였다. 구체적으로, Kaggle‑형 데이터셋·CSV 제출 방식을 궤도 상태·추진력·자원 수집 스케줄을 기술한 텍스트 파일 형식으로 교체하고, 공식 GTOC 12 검증기를 서브프로세스로 호출해 즉시 물리적 타당성을 피드백한다. 이 과정에서 Docker 환경을 천체역학 라이브러리(예: poliastro, Astropy)와 고성능 수치 해석 도구로 재구성했다.

에이전트 측면에서는 AIDE의 트리 탐색 구조를 유지하면서, 내부 프롬프트를 “데이터 사이언티스트”에서 “궤도·제어 엔지니어”로 전환하였다. 검색 노드마다 생성된 파이썬 스크립트를 실행하고, 검증기 로그를 파싱해 오류 유형(단위 불일치, 시간 범위 초과, 추력 제한 위반 등)을 식별한다. 이후 “Best‑First Search” 전략으로 가장 유망한 노드를 선택해 개선안을 제시하도록 설계했다. 또한, 물리적 단위 일관성 검증, 파일 포맷 안정성, 계산 비용 제한 등을 시스템 프롬프트에 명시해 디버깅 루프를 최소화했다.

실험에서는 GPT‑4‑Turbo, Gemini 2.5 Pro, Google o1‑preview 등 5가지 모델을 10회씩 실행했다. 전략적 타당성 평가는 도메인 전문가가 만든 5가지 구조 카테고리(목표 선정, 궤도 설계, 추진 시스템, 자원 채취 일정, 함대 규모)별로 0‑5점 척도로 채점한 루브릭을 사용했다. 평균 점수는 2024년 초 9.3점에서 2025년 말 17.2점으로 크게 상승했으며, 특히 목표 선정·궤도 설계 단계에서 의미 있는 개선이 관찰되었다. 그러나 실제 검증기 통과 점수는 0점에 머물렀다. 주요 실패 원인은 (1) 물리 단위(예: km → m) 변환 오류, (2) 시간 윈도우(2035‑2050) 위반, (3) 추력·특정 충량 제한을 초과하는 가정, (4) 중복된 파일 출력으로 검증기 파싱 오류, (5) 디버깅 루프에서 동일 오류를 반복적으로 수정하지 못하는 비효율성이다. 이러한 결과는 LLM이 “전략 설계”와 “구현 실행” 사이에 존재하는 격차를 명확히 보여준다.

결론적으로, 현재 LLM은 복잡한 물리 모델을 이해하고 고수준 전략을 제시하는 데는 충분히 능숙하지만, 정밀한 수치 구현과 오류 처리에서는 인간 엔지니어 수준의 신뢰성을 아직 달성하지 못한다. 향후 연구는 (가) 물리‑코드 자동 검증 도구와의 tighter integration, (나) 체계적인 단위 관리 프레임워크, (다) 오류‑우선 탐색 전략을 도입해 구현 단계의 성공률을 높이는 방향으로 진행될 필요가 있다.


댓글 및 학술 토론

Loading comments...

의견 남기기