CI는 항상 뭔가 깨져 있다. 문제는 '어떤 실패가 릴리스를 막는가'다
CI를 열면 뭔가 빨간 불이 켜져 있다. 이건 현실이다. 진짜 문제는 실패를 찾는 게 아니라, 847개 테스트 중 5개가 실패했을 때 그게 릴리스를 막는 5개인지, 그냥 넘겨도 되는 5개인지를 20분 안에 판단하는 것이다. 지금까지 그 판단은 개발자가 로그를 뒤지고, 지난주 실행 기록을 뒤지고, PR 변경 파일을 비교하면서 손으로 했다.
dev.to에 공개된 release-readiness-triage-mcp는 이 판단을 AI 에이전트에게 위임하기 위한 MCP 서버다. 핵심 아이디어는 단순하다. CI 실패 트리아지에 실제로 필요한 세 가지 신호—에러 시그니처 중복 제거, flakiness 이력, 코드 변경 상관관계—를 동시에 교차 분석해서 하나의 판정을 내린다.
구체적으로 보면, aggregate_suite_failures가 40개 테스트의 ECONNREFUSED 실패를 '데이터베이스 미기동' 1개 문제로 압축하고, cross_reference_flakiness가 flaky 확률 73%짜리 테스트의 실패는 무시해도 된다고 판단하며, correlate_code_changes가 Button.test.tsx 실패와 Button.tsx 변경의 상관관계를 잡아낸다. 최종 generate_release_recommendation은 이렇게 나온다: "NO_GO (75% 신뢰도). 코드 변경과 직접 연관된 리그레션 1건. 릴리스 불가." 5개 실패 중 무시해도 되는 4개와 실제로 막아야 할 1개를 분리하는 데 걸리는 시간은 0분이다.
이 구조에서 중요한 건 MCP가 단일 도구가 아니라 메타 오케스트레이터로 설계됐다는 점이다. flakiness-knowledge-graph-mcp가 flakiness DB를 만들고, ast-impact-mapper-mcp가 TypeScript AST로 영향 받는 테스트를 계산하며, playwright-trace-decoder-mcp가 NO_GO 판정 이후 실제 원인을 파고든다. 각 MCP는 하나씩만 잘한다. 에이전트가 체인을 엮는다. 이게 AI 에이전트를 CI 파이프라인에 얹는 현실적인 아키텍처다.
Docker MCP Catalog: '컨테이너 레지스트리 패턴'이 에이전트 세계로 이식된다
CI 자동화의 실행 레이어 문제가 어느 정도 풀린다면, 다음 질문은 거버넌스다. 에이전트가 어떤 MCP 서버에 접근할 수 있는지, 누가 승인했는지, 어떻게 버전 관리하는지. dev.to의 다른 분석이 이 지점을 정확하게 짚는다. Docker가 발표한 Custom MCP Catalogs와 Profiles는 표면적으로는 편의 기능이지만, 구조적으로는 플랫폼 팀이 오랫동안 다뤄온 문제의 반복이다.
패턴이 익숙하다. Backstage, Port, Cortex 같은 Internal Developer Portal이 해결한 문제가 뭐였나? 도구가 너무 많고, 서비스가 너무 많고, 개발자가 모든 걸 알 수 없을 때—누군가가 카탈로그를 큐레이션하고, golden path를 정의하고, 권한을 설정한다. Docker MCP Catalog는 정확히 같은 문제를 에이전트를 위해 푼다. 소비자만 인간에서 에이전트로 바뀌었을 뿐, 아키텍처는 동일하다.
OCI 아티팩트로 패키징한다는 게 이 발표에서 가장 실용적인 부분이다. 컨테이너 이미지 배포 인프라를 그대로 쓴다는 뜻이다. 새 인프라를 안 지어도 된다. push, pull, version, sign, access control—다 알던 방식이다. 그리고 Profiles는 겉으로는 워크플로 구성 도구지만, 실질적으로는 권한 경계다. SRE 프로파일은 인시던트 대응 도구만 노출하고, CI 자동화 프로파일은 배포·모니터링 도구만 포함한다. 에이전트가 어떤 컨텍스트에서 무엇을 할 수 있는지를 카탈로그가 정의한다.
AI 코딩 에이전트 선택 기준: 실증 데이터가 말하는 것
이 파이프라인 위에서 실제로 코드를 짜는 에이전트를 고를 때, Reddit에서 화제가 된 Claude→Codex 전환 경험이 몇 가지 실용적인 기준점을 제공한다. 3개월간 Claude Max x20 구독을 쓰다가 GPT-5.5 + Codex로 옮긴 이 사례에서 핵심 불만은 두 가지였다: 40%만 구현해 놓고 완료됐다고 환각하는 과신과, 감독 워크플로를 별도로 설계해야 할 만큼 쌓이는 검증 부담.
Codex로 옮긴 뒤 체감한 변화는 lint/test 피드백 루프의 정합성과 리팩터링의 완결성이었다. 단, 이 데이터는 그대로 믿기엔 맥락이 필요하다. 댓글에서 지적됐듯, 전환 직후 Codex도 성능 저하로 Altman이 직접 사과한 사건이 있었고, 모델 품질은 주 단위로 바뀐다. "오늘은 Anthropic, 내일은 OpenAI, 다음 주에는 다른 도전자"라는 표현이 과장이 아닌 현실이다.
이걸 팀 도입 결정에 어떻게 써야 하나. 특정 모델보다 하네스가 먼저다—이미 이전 글에서 다뤘고, 이 사례도 같은 결론을 가리킨다. Claude 4.7에서 문제가 커졌을 때 그가 구축한 것들—인접 파일 회귀 확인 에이전트, senior reviewer 에이전트, lint/test 파이프라인—은 모델을 바꿔도 그대로 작동했다. 마이그레이션이 CLAUDE.md → AGENTS.md 이름 변경 수준으로 끝난 건 하네스가 모델에서 독립적으로 설계됐기 때문이다.
내일 당장 팀에 적용할 수 있는 것들
세 소스가 교차하는 지점에서 실행 가능한 기준을 뽑아보면 이렇다.
CI 자동화 측면: release-readiness-triage-mcp 도입의 전제는 flakiness 데이터가 먼저 쌓여 있어야 한다는 것이다. flakiness history 없이 cross_reference_flakiness를 돌리면 신호 없는 노이즈만 나온다. 먼저 flakiness 데이터 수집 파이프라인을 만들고, MCP는 그다음이다.
MCP 거버넌스 측면: Docker MCP Catalog를 당장 쓰지 않더라도, "우리 팀에서 에이전트가 접근 가능한 MCP 서버 목록"을 지금 정의해둘 수 있다. 목록이 없으면 개발자마다 JSON 설정 파일이 제각각이 되고, 감사가 불가능해진다. 나쁜 MCP 서버 하나가 카탈로그에 들어오면 그 카탈로그를 쓰는 모든 에이전트가 영향을 받는다는 것도—npm 패키지 공급망 공격과 구조적으로 같다.
에이전트 선택 측면: 모델 비교 실험은 팀 단위로, 실제 레포에서, 2주 이상 돌려야 의미 있다. 한 개발자의 개인 워크플로 경험은 참고 데이터지, 팀 도입 근거가 아니다.
카탈로그가 거버넌스 표면이 되는 순간
MCP 카탈로그가 단순한 편의 기능을 넘어 진짜 거버넌스 레이어가 되는 시점은 팀이 그것을 "승인된 MCP 서버의 단일 진실 공급원"으로 대우하기 시작하는 순간이다. 그게 되면 보안 팀은 개별 MCP 설정 파일 수백 개를 감사하는 대신 카탈로그 아티팩트 하나를 리뷰하면 된다. 배포 파이프라인에 올라탄 에이전트가 무엇을 할 수 있는지는 카탈로그가 정의한다.
컨테이너 이미지 레지스트리가 배포 인프라의 중심이 된 것과 같은 경로가 에이전트 툴링에서 반복되고 있다. 플랫폼 팀이 이걸 "에이전트 전용 별도 인프라"로 보기 시작하면 이미 늦다. 지금 있는 컨테이너 레지스트리, 패키지 관리 거버넌스, IDP 설계 경험—그 위에 에이전트 레이어를 얹는 게 맞는 방향이다.
AI 에이전트를 배포 파이프라인에 얹으려면 세 층이 동시에 작동해야 한다: 릴리스 판단을 맡길 만한 트리아지 로직, 에이전트가 접근하는 도구를 통제하는 카탈로그 거버넌스, 그리고 모델 교체에 흔들리지 않는 하네스 설계. 이 중 하나라도 빠지면 속도가 아니라 위험이 빨라진다.