나는 지난주 대부분의 시간을 모든 ML 엔지니어가 실제로 엔지니어링을 해야 할 때 하는 행동을 하며 보냈다. 바로 웹 대시보드에서 중첩된 폴더들을 클릭하며, 화요일의 특정 실행(run)이 왜 다른 것들보다 약간 더 나은 정밀도(precision)를 보였는지 찾으려고 애쓰는 일 말이다.

이것은 지루한 반복이다. 브라우저를 열고, 워크스페이스 계층 구조를 탐색하고, 프로젝트를 찾아 헤매고, 실험(experiment)을 클릭한 다음, 새벽 2시에 수정했던 그 하나의 하이퍼파라미터(hyperparameter) 조정을 찾기 위해 로그나 파라미터를 끝없이 스크롤한다. 이것은 단순히 지루할 뿐만 아니라, 당신의 흐름(flow)을 깨뜨린다. Cursor나 Claude에서 코딩 세션에 깊이 몰입해 있을 때, 브라우저 탭으로 전환하는 모든 컨텍스트 스위칭(context switch)은 당신의 생산성에 세금(tax)을 매기는 것과 같다.

문제는 데이터가 없다는 것이 아니다—Comet ML은 그것을 훌륭하게 추적한다. 문제는 우리가 그것에 어떻게 접근하느냐이다. 우리는 실험 추적을 '우리에게 오는' 무언가가 아니라, 우리가 '찾아가야 하는' 무언가로 취급한다.

나는 Model Context Protocol (MCP)을 사용하여 이 간극을 메울 방법을 연구해 왔다. AI 에이전트를 당신의 Comet ML 인스턴스에 직접 연결함으로써, 당신은 탐색자(navigator)가 아닌 감사자(auditor)가 된다. 당신은 브라우징을 하는 것이 아니라, 질문을 하는 것이다.

실험의 토폴로지 (The Topology of Experiments)

대부분의 사람들은 MCP 서버를 단순한 API 래퍼(wrapper)로 생각한다. 하지만 Comet ML과 같은 것을 다룰 때, 진짜 가치는 자신이 어디에 있는지 모르는 상태에서도 계층 구조를 탐색할 수 있다는 점에 있다.

내가 Vinkius에 배포한 Comet ML MCP 서버는 단순히 데이터를 쏟아내는 것이 아니다. list_workspaces 및 list_projects와 같은 도구를 통해 에이전트가 당신의 조직 구조를 이해할 수 있도록 한다. 당신은 말 그대로 "research-team 워크스페이스에서 내가 실행 중인 프로젝트는 무엇인가요?"라고 물을 수 있고, 에이전트가 당신을 대신해 구조적 추출(structural extraction)을 수행한다.

에이전트가 전체적인 상황을 파악하고 나면, 본격적인 작업이 시작됩니다. 실험 ID(experiment ID)를 수동으로 찾아 헤매는 대신, list_experiments를 사용하여 특정 프로젝트 범위 내에 정확히 어떤 실행(runs)들이 존재하는지 찾아낼 수 있습니다. 만약 특정 태그나 타임스탬프(timestamp)가 있는 특정 실행을 찾고 있다면, 에이전트는 Comet이 제공하는 라우팅 배열(routing arrays)을 파싱하여 이를 찾아냅니다.

자연어를 통한 감사 (Auditing via Natural Language)

진정한 마법은 탐색(navigation)에서 검사(inspection)로 넘어갈 때 일어납니다. 바로 이 지점에서 '엔지니어-대-에이전트(engineer-to-agent)' 워크플로우가 강력한 힘을 발휘합니다.

만약 제가 모델 수렴(convergence) 문제를 디버깅하고 있다면, 메트릭(metrics)을 일일이 찾아다니고 싶지 않을 것입니다. 대신 다음과 같이 질문하고 싶을 것입니다: "실험 'exp_abc123'의 현재 메트릭을 가져와줘." get_experiment_metrics 도구를 사용하면 에이전트가 손실(loss), 정확도(accuracy), 학습률(learning rate) 곡선과 같은 정밀한 수치 엔드포인트(numeric endpoints)를 채팅 컨텍스트(chat context)로 직접 가져올 수 있습니다. 만약 45 에포크(epoch)에서 손실(loss)이 급증하는 것을 발견했다면, 다시 대시보드로 돌아갈 필요 없이 에이전트에게 그 정확한 순간에 파라미터(parameters)에 어떤 일이 일어났는지 물어보면 됩니다.

여기서 get_experiment_params가 등장합니다. 자연어를 사용하여 실험의 내부 속성—학습률(learning rates), 배치 크기(batch sizes), 또는 옵티마이저(optimizer) 설정—을 감사(audit)할 수 있습니다. 저는 이를 사용하여 로컬 학습 스크립트의 최근 변경 사항이 Comet의 이전 성공적인 실행에서 기록된 내용과 실제로 일치하는지 확인하는 데 사용했습니다. 에이전트는 하이퍼파라미터(hyperparameter)의 API 분류 체계(taxonomy)를 가져와 명확하게 나열해 줍니다.

이것이 MLOps에 중요한 이유

MLOps 팀에게 이것은 단순한 편의성의 문제가 아니라, 대규모 환경에서의 관측 가능성(observability)에 관한 문제입니다. 여러 워크스페이스(workspaces)에 걸쳐 수백 개의 실행(runs)이 있을 때, 사람이 주도하는 감사(auditing)는 불가능해집니다. 에이전트는 실험 메타데이터(metadata)를 프로그래밍 방식으로 스캔하여, 사람이 탭을 클릭하며 지나칠 때 단순히 간과할 수 있는 이상치(outliers)나 성능 메트릭의 드리프트(drift)를 식별할 수 있습니다.

에이전트에게 실험 키(experiment key)를 제공하며 다음과 같이 말할 수 있습니다: "이 프로젝트의 모든 실험을 감사(Audit)하고, 배치 크기(batch size)를 32로 사용했지만 정확도(accuracy) 90%에 도달하지 못한 실험이 무엇인지 알려줘." 이는 수동으로 작업하면 20분이 걸리는 일이지만, 자연어 명령으로는 5초면 충분한 작업입니다.

설정 (The Setup) (군더더기 없이)

저는 복잡한 설정을 싫어합니다. ML 메트릭(metrics)을 확인하기 위해 OAuth 콜백(callback)을 설정해야 한다면, 그 도구는 이미 저를 실망시킨 것입니다.

이 서버의 설정은 세 단계로 이루어집니다:

2. Comet ML API 키(계정 설정에 있는 것)를 입력합니다.
3. 연결 토큰을 Claude 또는 Cursor에 붙여넣습니다.

그게 끝입니다. 로컬 Python 환경을 관리할 필요도 없고, MCP 실행을 위한 복잡한 의존성 지옥(dependency hell)을 처리할 필요도 없습니다. 모든 것을 내장된 거버넌스(governance)를 갖춘 격리된 V8 샌드박스(sandboxes)에서 실행하기 때문에 그냥 작동합니다. DLP(데이터 유출 방지) 및 감사 체인(audit chains)과 같은 사항을 내부적으로 처리하므로, 여러분은 배관 작업(plumbing)이 아닌 과학(science)에 집중할 수 있습니다.

전체 서버와 문서는 여기에서 확인할 수 있습니다: https://vinkius.com/mcp/comet-ml

탭을 클릭하며 돌아다니는 것을 멈추세요. 모델을 감사(auditing)하기 시작하세요.

MCP는 AI 에이전트의 음악입니다. 저희가 그 카탈로그를 만들었습니다. Vinkius MCP Catalog를 확인해 보세요.