개요

프로세스 하나

mcpd는 프로세스 하나로 두 가지 일을 합니다. 첫째, 지속성 실행을 단계 사이에서 붙들어 둡니다. 커서와 재시도와 타이머와 대기가 여기에 들어가고, 각 단계 안의 작업은 언어에 상관없이 직접 작성한 코드가 합니다. 둘째, 에이전트가 한 일을 받아 저장하고, 읽을 수 있는 실행으로 되돌려 줍니다. mcpd는 SQLite를 링크해 넣은 바이너리 하나입니다. 따로 세울 데이터베이스도, 옆에서 돌릴 컬렉터도 없고, 어디에도 계정이 필요 없습니다.

데몬은 4317 포트에서 듣고, 그 포트 하나로 다섯 가지를 제공합니다.

• /v1/traces와 /v1/logs와 /v1/metrics의 OTLP 수집. 이미 있는 OpenTelemetry 구성에는 새 코드가 필요 없습니다.
• /v1/ingest의 네이티브 수집. OTLP에 자리가 없는 데이터 모델 부분을 나르며, 점수와 사람의 피드백도 여기로 들어옵니다.
• /v1/api 아래의 읽기 API. 인터페이스와 SDK가 모두 이것을 씁니다. 공개된 것 뒤에 숨은 비공개 API는 없습니다.
• /v1/api/runs와 /v1/api/events와 /v1/api/steps 아래의 실행 인터페이스. 정의, 실행, 대기에 응답하는 이벤트, 그리고 워커가 쓰는 프로토콜입니다. 워크플로를 보십시오.
• /의 운영자 인터페이스. 바이너리 안에 들어 있습니다.

포트를 하나로 둔 것은 지름길이 아니라 배포에 관한 결정입니다. 컬렉터와 데이터베이스와 UI는 돌릴 것이 셋, 업그레이드할 것이 셋, 그리고 그 사이에서 트레이스가 사라질 수 있는 곳이 셋입니다.

일부러 하지 않는 것

여기서 얻는 가치의 대부분은 mcpd가 하지 않겠다고 정한 일에서 나옵니다. 거절 하나하나가 에이전트를 고쳐야 할 이유를 하나씩 없앱니다.

• 프레임워크가 아닙니다. mcpd는 모델을 실행하지도, 고르지도, 프로바이더 클라이언트를 감싸지도 않습니다. 단계 사이의 실행을 붙들 뿐, 단계 안의 모든 것은 각자의 코드에 맡깁니다. mcpd를 도입한 뒤에도 코드가 모델을 부르는 방식은 그 전과 같습니다.
• 요청 경로에 있지 않습니다. 에이전트와 프로바이더 사이에 끼어들지 않습니다. 사용자가 보는 것 가운데 mcpd가 살아 있어야 하는 것은 없습니다. 사용자가 보는 것은 mcpd를 지나가지 않기 때문입니다.
• 서비스가 아닙니다. 데몬은 기본 상태에서 아무 곳에도 요청하지 않습니다. 텔레메트리도, 라이선스 확인도, 벤더 엔드포인트도 없습니다. 밖으로 나가는 트래픽은 직접 설정한 것뿐입니다. --forward-endpoint, 모니터의 웹훅, 판정 모델이 그것입니다. 그중 무엇도 설정하지 않으면 프롬프트는 실행한 머신을 떠나지 않습니다.
• 필수 의존성이 아닙니다. 인프라에서 mcpd를 지우면 멈추는 것은 기록뿐입니다.

여섯 가지 시그널

mcpd는 여섯 종류를 저장하고, 그것들을 함께 저장합니다. 스팬은 무엇이 실행되었는지입니다. 로그는 실행이 남긴 줄입니다. 메트릭은 시간에 따른 숫자입니다. 점수는 실행에 대한 기계의 판단이고, 피드백은 사람의 판단입니다. 관점 노트는 모델이 끝난 실행 하나를 두고 쓴 한 문장입니다.

그것들을 한 저장소에 두는 것이 핵심입니다. 모든 시그널은 자신이 속한 트레이스 id와 스팬 id를 지니고 다닙니다. 그래서 "이 고객이 항의한 실행에서 모델이 실제로 뭐라고 말했고, 비용은 얼마였는가"라는 질문이 도구 네 개와 눈으로 맞추는 타임스탬프가 아니라 질의 하나가 됩니다.

점수와 피드백을 따로 두는 것은 의도한 것입니다. 스코어러의 0.8과 사람이 누른 '싫어요'는 서로 다른 것을 재고, 둘을 평균 내면 아무 뜻도 없는 숫자가 나옵니다.

왜 프레임워크가 아니라 데몬인가

프레임워크가 함께 주는 관측 가능성은 좋습니다. 다만 그 프레임워크에 붙어서 옵니다. 관측되려면 에이전트가 그 프레임워크로, 대개 한 가지 언어로 만들어져 있어야 합니다. 새 프로젝트에는 받아들일 만한 거래이지만, 이미 있고 이미 잘 도는 에이전트에는 불가능한 거래입니다. 프레임워크의 워크플로도 같은 거래입니다. 모든 단계를 그 프레임워크의 언어로 쓰고 그 프로세스 안에서 돌리는 한에서만 실행이 이어집니다.

데몬은 그 둘을 모두 뒤집습니다. 워크플로의 그래프는 데몬이 들고 있는 데이터이고, 단계 본체는 각자의 프로세스가 들고 있는 코드입니다. 어떤 언어로든 말할 수 있는 HTTP 프로토콜을 통해 리스를 하나씩 받아 가져갑니다. 데몬은 모델도, 프롬프트도, 자격 증명도 보지 않습니다. 워크플로와 워커를 보십시오.

데몬은 그 거래 자체를 뒤집습니다. mcpd가 쓰는 OTLP는 의존성이 아니라 프로토콜입니다. 그래서 어떤 언어로 어떤 프레임워크로 쓴 에이전트든 기록하고, mcpd가 있기 전에 쓴 에이전트도 기록합니다. 에이전트가 이미 OpenTelemetry를 내보내고 있다면 OTEL_EXPORTER_OTLP_ENDPOINT를 mcpd로 향하게 하는 것이 연동의 전부입니다.

SDK가 있는 이유는 OTLP에 프롬프트, 응답, 토큰 수, 점수를 가리킬 말이 없기 때문입니다. 그런데 그 필드들이야말로 여기까지 찾아온 이유입니다. SDK를 쓰는 것은 선택이지 조건이 아닙니다. 여섯 개 모두 똑같이 동작합니다. 스팬을 기록하면 크기가 정해진 큐에 넣고 바로 돌아오며, 네트워크 작업은 백그라운드 워커에서 일어나고, 계측 경로에서는 어떤 것도 예외를 던지지 않습니다. 관측 대상 시스템을 죽일 수 있는 관측 가능성은 없느니만 못합니다.

바이너리 하나, 배포 형태 둘

노트북에서 돌리는 컨테이너가 곧 누군가의 클러스터에서 Deployment로 도는 컨테이너입니다. 보존 기간과 마스킹과 샘플링과 API 키는 모두 같은 바이너리의 플래그입니다. 다른 빌드도 아니고 라이선스 등급도 아닙니다. 손에 넣을 수 없는 버전에만 있는 기능은 없습니다.

기본값은 노트북에 맞춰져 있습니다. 그래서 키를 하나도 설정하지 않으면 수집과 읽기가 열려 있습니다. 그 상태로 루프백이 아닌 주소에서 듣고 있으면 mcpd는 시작할 때 크게 경고합니다. 그래도 시작은 합니다. 시작을 거부하면 이 문서가 겨냥하는 사람의 5분 경로가 깨지기 때문입니다. 그렇다고 아무 말도 하지 않는 것은 무책임한 일입니다.

다음에 볼 곳

• 지금 돌려 보려면: 빠른 시작은 직접 만든 에이전트에서 나온 트레이스를 화면에 띄우고, 설치는 들어오는 모든 길을 다룹니다.
• 용어를 익히려면: 개념이 트레이스, 스팬, 종류, 상관 정보를 정의합니다. 나머지 문서는 그것을 전제합니다.
• 실행을 단계 사이에 붙들어 두려면: 워크플로, 그다음 워커와 실행.
• 이미 OpenTelemetry가 있다면: OTLP 경로 전체. mcpd가 표준 속성에서 무엇을 추론하는지까지 담았습니다.
• 다른 사람들을 위해 운영하려면: Docker와 Kubernetes, 그다음 마스킹과 보존 기간.

mcpd는 Apache-2.0 라이선스입니다. 들어오는 프로토콜도, 나가는 형식도, 그것을 감싼 라이선스도 모두 공개되어 있습니다. 그래서 떠나는 비용은 들어오는 비용만큼 쌉니다.