에이전트가 PR을 올리는 순간 맥락이 끊긴다 — Nx가 채운 CI 자동화 틈

PR은 올라갔는데, 빨간 CI는 다시 사람 몫입니다

AI 에이전트가 기능을 구현하고 로컬 테스트를 거쳐 PR까지 만들었습니다. 그런데 원격 CI에서만 실패가 발생하면 흐름이 끊겨요. 사람이 알림을 확인하고 로그를 복사한 뒤, 실패한 맥락을 다시 설명해야 에이전트가 다음 수정을 시작합니다.

Nx가 메우려는 틈은 코드 생성이 아니라 PR 이후의 정보 단절입니다. 로컬 에이전트가 Nx Cloud의 파이프라인 상태와 실패 작업 출력, Self-Healing CI의 수정 제안을 다시 받아보게 만드는 방식이에요. nx +1

다만 명령 하나로 모든 실패가 자동 해결되는 기능은 아닙니다. 로컬 Nx 실행, Nx Cloud와 VCS 연결, CI의 fix-ci 단계, 에이전트의 MCP·스킬 구성을 차례로 준비해야 합니다. 수정 제안이 만들어지는 조건과 그 제안이 자동 적용되는 조건도 따로 봐야 하고요. nx +1

에이전트가 돌려받는 것은 실패 이후의 맥락입니다

Nx MCP는 현재 브랜치의 CI 상태를 조회하는 ci_information, 개별 작업 출력을 가져오는 ci_task_output, Self-Healing 제안을 적용하거나 거절하는 update_self_healing_fix를 제공합니다. 사람이 CI 화면과 에디터 사이에서 전달하던 정보를 에이전트가 직접 조회할 수 있게 되는 셈입니다. nx

여기서 이름 하나를 바로잡아야 합니다. 초기 공식 글에는 ci-monitor라고 적혀 있지만, 현재 공개 저장소의 스킬 경로와 메타데이터에서 확인되는 이름은 monitor-ci입니다. 예전 이름을 그대로 설치 경로나 스킬 이름으로 찾으면 현재 구성과 맞지 않을 수 있어요. nx +1

Self-Healing CI는 실패 로그와 Nx 프로젝트 그래프를 이용해 원인을 분석하고 수정안을 만든 뒤, 원래 실패한 작업을 다시 실행해 수정 여부를 검증합니다. 이는 특정 실패 작업에 대한 검증입니다. 전체 코드의 업무적 정확성이나 PR 병합 가능성까지 보장하는 결과는 아닙니다. nx

먼저 새 체크아웃에서 Nx가 실행되는지 확인하세요

이 절차는 nx.json이 있고 package.json에 Nx가 포함된 기존 워크스페이스를 대상으로 합니다. Nx가 없는 저장소에서 초기화부터 실행하면 의존성과 설정 파일이 바뀌므로 별도 도입 작업으로 다뤄야 합니다. nx +1

1. 저장소가 지정한 Node.js와 패키지 매니저를 준비합니다.
   package.json, 잠금 파일, 버전 관리 파일과 기존 CI 설정을 확인하세요. 정확한 Node.js 버전과 설치 명령은 해당 저장소의 설정을 따릅니다.
2. 잠금 파일에 맞는 프로젝트 의존성 설치 명령을 실행합니다.
   설치가 끝나면 워크스페이스 루트에서 npx nx --version 또는 저장소가 평소 사용하는 Nx 작업을 실행하세요. 로컬 Nx가 정상적으로 시작되는 것이 첫 성공 기준입니다.
3. Nx가 없다면 연결 작업을 중단합니다.
   nx.json도 없고 package.json에도 Nx가 없다면 configure-ai-agents부터 실행하지 마세요. npx nx@latest init은 Nx 의존성과 설정을 추가하므로 팀이 검토할 별도 변경입니다. nx +1

Nx Cloud와 CI를 먼저 연결합니다

에이전트를 구성하기 전에 원격 CI가 상태와 수정 제안을 남길 경로부터 만들어야 합니다. Nx Cloud 계정, 지원 VCS 연동, 워크스페이스와 CI 설정을 바꿀 권한이 필요합니다. nx

1. Self-Healing CI 설정 문서를 열고 워크스페이스를 연결합니다.
   워크스페이스 루트에서 npx nx@latest connect를 실행한 뒤 브라우저 인증을 완료하세요. nx
2. Nx Cloud에서 VCS 연결을 확인합니다.
   공식 문서가 지원 대상으로 안내하는 GitHub, GitLab, Azure DevOps 또는 Bitbucket 저장소를 연결하고, Workspace Settings에서 Self-Healing CI를 활성화합니다. nx
3. 올바른 CI job 끝에 npx nx fix-ci를 추가합니다.
   Nx 작업을 시작하는 main 또는 orchestrator job에 배치하고, 앞선 단계가 실패해도 실행되게 설정하세요. GitHub Actions에서는 if: always(), 다른 CI에서는 이에 해당하는 조건이 필요합니다. BYOC 구성이라면 main job뿐 아니라 각 agent job에도 같은 처리가 필요합니다. nx

에이전트 구성은 설치와 동작을 나눠 확인하세요

Nx Cloud 연결이 끝났다면 이제 코딩 클라이언트에 Nx MCP와 monitor-ci 스킬을 구성합니다. 공식 설정 명령은 기존 Nx 워크스페이스를 확인한 뒤 클라이언트별 규칙, MCP와 스킬 파일을 만듭니다. nx

1. 사용할 클라이언트를 지정해 구성을 생성합니다.
   npx nx configure-ai-agents를 실행해 대화형으로 선택하거나, 자동화된 환경에서는 npx nx configure-ai-agents --agents <claude|codex|copilot|cursor|gemini|opencode> --no-interactive 형식을 사용하세요. nx
2. 생성된 변경 사항을 검토합니다.
   규칙 파일과 MCP·스킬 설정이 예상한 클라이언트 위치에 추가됐는지 diff를 확인하세요. 저장소에 바로 커밋하기 전에 조직 규칙이나 기존 설정과 충돌하지 않는지도 봅니다.
3. 설치 상태를 검사합니다.
   npx nx configure-ai-agents --check=all을 실행하세요. rules, MCP, skills 검사가 통과하면 구성 파일 설치는 성공한 것입니다. 이 검사는 원격 CI 조회까지 성공했다는 뜻은 아닙니다. nx
4. VCS 인증과 권한을 확인합니다.
   에이전트에게 PR 생성까지 맡길 경우 커밋·푸시·PR 생성에 필요한 인증과 권한이 있어야 합니다. 이 권한이 없다면 사람이 PR을 만든 뒤 모니터링만 요청하세요.
5. 기본 브랜치가 아닌 PR 브랜치에서 첫 입력을 보냅니다.
   PR 생성 권한이 있다면 공식 예시인 Commit the work, create a PR and monitor CI.를 입력할 수 있습니다. 처음에는 자동 적용을 전제로 하지 말고, 에이전트가 Nx Cloud의 파이프라인 상태를 가져오는지부터 확인하세요. nx

제안 생성과 자동 적용은 서로 다른 문입니다

Self-Healing 제안이 없다고 해서 곧바로 AI 신뢰도가 낮았다고 해석하면 안 됩니다. 제안이 만들어지는 단계와 만들어진 제안이 자동 적용되는 단계에는 서로 다른 조건이 걸립니다. nx

제안이 생성되지 않으면 PR에서 CI가 실행됐는지, Self-Healing이 활성화됐는지, 기본·보호 브랜치에서 실행한 것은 아닌지, 실패 작업이 eligible task나 제외 패턴에 걸렸는지 확인하세요. 반대로 제안은 보이지만 자동 적용되지 않았다면 그때 auto-apply 패턴과 신뢰도, 재실행 검증 결과를 따로 살펴봐야 합니다. nx

monitor-ci는 성공, 수정할 내용 없음, 환경 문제, 시간 초과처럼 결과를 구분해 처리하도록 공개돼 있습니다. 따라서 첫 PR의 CI가 처음부터 통과했다면 수정 제안이 없어도 정상이에요. 에이전트가 해당 실행 상태를 조회했다면 모니터링 연결이라는 첫 목표는 달성한 것입니다. github

🔗

더 깊이 파고 싶다면

End to End Autonomous AI Agent Workflows with Nx

PR 이후 사람이 다시 호출되는 문제와 에이전트가 CI를 모니터링하는 전체 흐름을 설명한 출발점입니다.

AI-Powered Self-Healing CI

VCS 연결, fix-ci 배치, 제안 생성 범위와 자동 적용 조건을 구분해 확인할 수 있습니다.

Integrate Nx with your Coding Assistant

지원 클라이언트, 비대화형 구성과 --check=all 검사 절차를 확인할 수 있습니다.