천문 데이터 아카이브용 MCP 서버 MANNA: 도구 호출 3분의 1, 정확도 2배를 만든 설계와 평가

핵심 메시지

• 천문 아카이브들은 같은 IVOA 표준 위에 올라가 있으면서도 스키마와 질의 문법이 제각각이고 표준을 벗어나는 지점도 있어, 여러 파장대를 함께 보려면 아카이브별 맥락 지식이 필요하다.
• 발표자는 가까운 적외선 밝은 은하 12개 중 두 전파 관측 시설로 볼 수 있으면서 아직 데이터가 없는 곳을 찾는 평범한 질문 하나가 아카이브 세 곳에 40번 가까운 질의를 요구한다고 예를 들었다.
• MANNA는 20개 미만의 도구로 이뤄진 가볍고 상태를 남기지 않는 MCP 서버로, 일부 도구는 아카이브 맥락을 모델에 주입하고 일부는 TAP 질의나 이미지 검색을 실행한다.
• MCP는 만들기는 쉬워도 잘 만들기는 어렵다는 문제의식에서, 도구 선택과 과제 성공, 강건성을 층으로 나눈 자체 평가 프레임워크를 만들고 서버를 켠 경우와 끈 경우를 비교했다.
• 한 오픈소스 모델 기준으로 도구 호출 수는 약 3분의 1로 줄고 정확도는 약 두 배가 됐으며, 실패한 호출도 눈에 띄게 줄었다. 다른 모델들에서도 비슷한 개선이 나타났다고 밝혔다.

쉽게 이해하기

문제의식은 명확하다. 천문 데이터 아카이브는 공개돼 있고 대체로 표준화돼 있지만, 실제로 데이터를 꺼내려면 ADQL 질의를 쓸 줄 알아야 하고 해당 아카이브의 스키마를 알아야 하며 표준에서 벗어난 부분을 우회할 줄도 알아야 한다. 그래서 여러 파장대를 묶어 보는 연구가 까다로워지고, 평소 쓰지 않던 망원경으로 관측 제안을 준비하려는 탐색적 작업은 특히 진입이 어렵다.

발표자가 든 예는 구체적이다. 가장 가까운 적외선 밝은 은하 열두 곳 가운데 두 전파 관측 시설 모두로 관측할 수 있으면서 아직 데이터가 없고 이미 전파와 깊은 광학 자료는 있는 곳이 어디인지 묻는 질문은 연구자가 관측 공백을 메우려 할 때 흔히 나오는데, 이 하나를 답하려면 서로 스키마가 다르고 ADQL 해석도 조금씩 다른 아카이브 세 곳에 40번 가까운 질의를 던져야 한다. MANNA는 그 부담을 도구 계층으로 흡수하려는 시도로, 이름은 NOIRLab과 NSF NRAO 아카이브를 위한 MCP 아키텍처의 약자이고 여름 석 달 동안 만들어졌다.

스무 개가 안 되는 도구 가운데 일부는 아카이브 맥락을 모델의 작업 흐름에 주입하고, 나머지는 TAP 질의나 단순 이미지 검색 같은 실행을 맡는다. 모두 IVOA 프로토콜 위에 세워져 있어 새 아카이브를 붙이려면 그 표준을 따라야 하고, 인증이나 호출 사이의 상태 보존이 없는 가벼운 무상태 패키지로 유지했다. 그렇다면 요즘 모델이 알아서 다 하는데 왜 서버가 필요한가. 발표자의 답은 최전선 모델이라면 MCP 없이도 전체 작업 흐름을 해내지만, MCP는 정답까지 가는 가장 짧은 경로를 준다는 것이다. 도구 호출 횟수와 토큰 비용이 줄어드는 것도 있지만 더 중요한 이유는 조용한 실패를 막는다는 데 있다. ADQL 문법이 조금 어긋나면 질의가 0행을 반환하는데, 그것이 정말 해당하는 천체가 없어서인지 질의를 잘못 써서인지 겉으로는 구분되지 않기 때문이다.

여름의 상당 부분은 평가 프레임워크를 만드는 데 들어갔다. 모델 벤치마크는 많아도 MCP 서버 자체의 품질을 직접 재는 방법은 널리 합의된 것이 없어서, 어떤 도구를 골랐는지와 과제를 실제로 끝냈는지, 흔들림에 얼마나 견디는지를 층으로 나누고 현실적인 아카이브 작업을 본뜬 시험마다 검증된 정답을 붙였다. 그런 다음 서버를 켠 경우, 단순한 TAP 도구만 준 경우, 아예 끈 경우를 비교했다. 한 오픈소스 모델에서는 도구 호출이 약 3분의 1로 줄고 정확도가 약 두 배가 됐으며, 실패한 호출도 크게 줄었다.

배포는 두 갈래로 진행 중이다. 하나는 Astro Data Lab 플랫폼의 주피터 환경에 채팅 기반 에이전트를 붙여 노트북을 만들고 코드를 실행하게 하는 것으로, 자체 GPU에 올린 오픈소스 모델과 짝지어 시험하고 있다. 시연에서는 특정 왜소은하 주변 6각분 이내 광원을 가져와 색-등급 도표를 그리라는 요청에 도구 호출 열다섯 번으로 결과를 냈다. 다른 하나는 원격 서버 배포와 PyPI 공개로, 각자 쓰는 에이전트 클라이언트에 직접 붙여 쓸 수 있게 하겠다는 계획이다.

주요 인사이트

• 이 발표의 알맹이는 'LLM이 천문학을 한다'가 아니라, 표준이 있는데도 구현이 제각각인 데이터 창구를 도구 계층이 대신 흡수한다는 접근법이다. 같은 구조는 스펙과 실제가 어긋나 있는 어느 분야의 레거시 API에도 그대로 옮겨 붙는다.
• 조용한 실패를 MCP 도입의 주된 명분으로 든 점이 눈에 띈다. 에러가 뜨는 실패는 알아채기라도 하지만, 잘못 쓴 질의가 빈 결과를 정상적으로 돌려주는 상황은 결과가 그럴듯하게 보이기 때문에 더 위험하다.
• 여름 작업의 상당 부분이 구현이 아니라 평가 프레임워크에 들어갔다는 대목은, MCP 서버의 실제 난이도가 어디 있는지를 보여준다. 발표자 표현대로 하나 만드는 것은 쉽고 좋은 것을 만드는 것이 어렵다.
• 자체 호스팅한 오픈소스 모델과 최전선 모델 양쪽에 같은 서버를 붙여 시험했다는 점은, 기관이 데이터를 밖으로 내보내지 않으면서도 에이전트 작업 흐름을 굴릴 경로가 있다는 뜻이다.

자주 묻는 질문

관련 AI 소식