CI가 항상 깨져 있나요? 당신의 AI Agent는 어떻게 해야 할지 전혀 모릅니다.

어떤 실제 코드베이스에서든 CI(지속적 통합)에는 항상 무언가 실패하는 부분이 있습니다. 어려운 점은 실패를 찾는 것이 아니라, 어떤 실패가 릴리스(release)를 막고 있는지 아는 것입니다. 여기 그 질문에 자동으로 답해주는 MCP 서버가 있습니다. 모든 엔지니어가 알고 있는 상황이 있습니다: CI를 엽니다. 무언가 실패하고 있습니다. 당신은 배포를 해야 합니다. 이것이 실제 회귀(regression)인가요? 이미 알려진 불안정한 테스트(flaky test)인가요? 아니면 재시도하면 통과할 인프라의 일시적인 문제(infra blip)인가요? 로그를 열고, 에러를 grep으로 찾고, 지난주 실행 기록과 교차 참조하고, PR(Pull Request)에서 어떤 파일이 변경되었는지 확인하면 20분 후에 답을 얻게 됩니다. 당신의 AI Agent는 이 중 그 어떤 것도 할 수 없습니다. Agent는 당신과 똑같은 가공되지 않은 로그(raw logs)를 봅니다. Agent는 당신의 불안정성 기록(flakiness history)을 모릅니다. 어떤 테스트가 코드 변경의 영향을 받는지도 모릅니다. 그저 추측할 뿐입니다. release-readiness-triage-mcp가 이를 해결합니다.

🚦 🧠 실제로 중요한 세 가지 신호

CI 실패를 분류(triaging)하려면 세 가지 요소를 동시에 상관 분석해야 합니다:

1. 에러 시그니처 중복 제거 (Error signature deduplication)
   만약 40개의 테스트가 ECONNREFUSED 127.0.0.1:5432로 실패했다면, 그것은 40개의 문제가 아니라 하나의 문제(데이터베이스가 시작되지 않음)입니다. 정규화된 에러 시그니처(normalized error signature)로 그룹화하면 실패의 실제 형태를 알 수 있습니다.

2. 불안정성 기록 (Flakiness history)
   어떤 테스트는 상태가 좋을 때도 70%의 확률로 실패합니다. 만약 어떤 테스트가 당신의 기록상 0.73의 불안정 확률(flaky probability)을 가지고 있다면, 오늘 그 테스트가 실패했다는 사실은 코드에 대해 아무것도 알려주지 않습니다.

3. 코드 변경 상관관계 (Code-change correlation)
   Button.test.tsx가 실패하고 있는데 diff(차이점)에 Button.tsx가 포함되어 있다면, 그것은 의심스럽습니다. 만약 AuthFlow.test.tsx가 실패하고 있는데 인증(auth) 관련 변경 사항이 없다면, 그것은 노이즈(noise)입니다.

이 세 가지 신호가 한곳에 없다면, "이것을 안전하게 릴리스해도 되는가?"라는 질문에 답할 수 없습니다. 그저 브라우저 탭만 늘어날 뿐입니다.

🛠️ 4가지 도구
aggregate_suite_failures
첫 번째 단계: 정규화(normalize), 중복 제거(deduplicate), 분류(categorize).

CI 실행 요약 (CI Run Summary)
총 테스트 수: 847
통과: 842
실패: 5
실패율: 0.59%
오류 그룹: 3
실패 그룹 (빈도별):
[NETWORK] 2x — connect ECONNREFUSED 127.0.0.1:Xms • API Suite > health check • API Suite > readiness probe
[ASSERTION] 2x — expect(received).toBe(expected) • Search Suite > debounce timing • Search Suite > sort order
[ASSERTION] 1x — Expected null, got <button>Submit</button> • Button Suite > renders button correctly

supports_custom_infra_patterns — "GCP quota exceeded" 또는 "No space left on device"와 같은 클라우드 특정 문자열을 전달하여, 이를 알 수 없는 실패(unknown failures) 대신 인프라 노이즈(infrastructure noise)로 분류할 수 있게 합니다.

cross_reference_flakiness — 플래키(flakiness) 데이터베이스를 사용하여 각 실패에 점수를 매깁니다:
플래키 교차 참조 (Flakiness Cross-Reference)
[KNOWN FLAKY] Auth Suite > login with expired token
플래키 확률: 73%
[MILDLY FLAKY] Search Suite > debounce timing
플래키 확률: 22%
[NO HISTORY] Button Suite > renders button correctly
플래키 데이터베이스에서 발견되지 않음

correlate_code_changes — 변경된 파일과 실패한 테스트를 매칭합니다. 단독으로 작동하거나 ast-impact-mapper-mcp에서 사전 계산된 영향받는 테스트 목록과 함께 작동합니다:
코드 변경 상관관계 (Code Change Correlation)
변경된 파일: 2
사전 식별된 영향받는 테스트: 1
[CORRELATED] Button Suite > renders button correctly → 영향받는 테스트 목록을 통해 매칭됨
[NOT CORRELATED] Search Suite > debounce timing
[NOT CORRELATED] Auth Suite > login with expired token

generate_release_recommendation — 마지막 단계입니다. 모든 것을 하나의 판결로 결합합니다:

🔴 출시 권고: NO_GO (신뢰도 75%)

코드 변경과 직접적으로 상관관계가 있는 확인된 회귀(regression) 1건이 존재합니다. 출시하지 마십시오.

카테고리	개수
전체 실패 (Total failures)	5
🔴 실제 회귀 (Real regressions)	1
🟡 알려진 불안정한 테스트 (Known flaky)	2
⚪ 인프라 일시 오류 (Infra blips)	2
❓ 알 수 없음 (Unknown)	0

🔴 차단 요소 (Blockers) (출시 전 반드시 수정 필요)

Button Suite > renders button correctly

• 이 테스트는 이번 커밋의 코드 변경 사항에 직접적인 영향을 받습니다.
• Expected null, got <button>Submit</button>

✅ 무시해도 안전함

• Auth Suite > login with expired token
  — 역사적으로 불안정함 (flaky): 과거 실패율 73%
• API Suite > health check
  — 에러 패턴이 인프라 문제(네트워크)와 일치함
• Search Suite > debounce timing
  — 약간 불안정함 (flaky): 과거 실패율 22%
• Storage Suite > upload avatar
  — 에러 패턴이 인프라 문제(네트워크)와 일치함

Pass format: "markdown"이며, 출력 결과는 GitHub PR 코멘트나 Slack 메시지에 바로 붙여넣을 수 있는 상태로 제공됩니다.

🔗 이것은 메타 오케스트레이터 (meta-orchestrator)입니다
이 MCP는 생태계 내의 다른 도구들 위에 위치하도록 설계되었습니다:

• flakiness-knowledge-graph-mcp: 실행 이력을 바탕으로 불안정성(flakiness) 데이터베이스를 구축합니다. — 이 출력값을 cross_reference_flakiness에 전달합니다.
• ast-impact-mapper-mcp: TypeScript AST를 통해 코드 변경에 영향을 받는 테스트가 무엇인지 계산합니다. — 이 출력값을 correlate_code_changes에 전달합니다.
• playwright-trace-decoder-mcp: 개별 실패의 근본 원인(root-cause)을 파악하기 위해 트레이스(trace) 파일을 디코딩합니다. — NO_GO 판정을 받은 후 차단 요소를 이해하기 위해 사용합니다.

에이전트가 이 체인을 오케스트레이션합니다. 각 MCP는 도구 접근 없이는 수행할 수 없는 한 가지 작업만을 처리합니다.

⚡ 설정

{
  "mcpServers" : {
    "release-readiness-triage" : {
      "command" : "npx" ,
      "args" : [
        "-y" ,
        "release-readiness-triage-mcp"
      ]
    }
  }
}

그다음 이렇게 물어보기만 하면 됩니다: "여기 CI의 실패 내역, 우리의 불안정성(flakiness) 이력, 그리고 이번 PR에서 변경된 파일들이 있습니다. 출시해도 안전할까요?"

단 하나의 답변. 로그를 읽을 필요가 없습니다.

📦 링크
npm: npmjs.com/package/release-readiness-triage-mcp
GitHub: github.com/vola-trebla/release-readiness-triage-mcp
npx release-readiness-triage-mcp