GitHub CI 검사 수정 트리거

GitHub CI 검사 수정 트리거 기능은 pull request의 CI 검사가 실패할 때 자동으로 「수정」에이전트를 할당합니다. 에이전트는 실패 로그를 분석하고 문제를 수정하려고 시도합니다(예: 실패한 테스트, lint 오류, 타입 불일치).

작동 원리

전체 흐름

1. PR 생성 → 에이전트가 PR을 생성 또는 업데이트
2. CI 검사 실행 → GitHub Actions, CircleCI 또는 기타 CI가 테스트 실행
3. 검사 실패 → (lint, 테스트, 보안 검사 등)
4. 트리거 발동 → AACWorkflow가 실패 감지
5. 수정 에이전트 할당 → 수정 에이전트 자동 할당
6. 에이전트 분석 → 실패 로그 및 오류 메시지 읽기
7. 수정 구현 → PR 브랜치에 변경사항 커밋
8. CI 재실행 → 새 커밋에서 검사 재실행
9. 성공 또는 에스컬레이션 → 검사 통과 시 PR 병합 가능; 실패 시 수동 개입

승인 정책

어떤 CI 실패가 자동 수정을 트리거할지 제어합니다:

• 모든 실패 — 모든 실패한 검사가 수정 트리거
• 특정 검사 — 특정 검사만 (예: 「테스트」는 되지만 「보안」은 안 됨)
• 신뢰할 수 있는 검사만 — 수정 가능하다고 알려진 검사만 (예: lint, 포맷)

설정

CI 수정 트리거 활성화

설정 → GitHub → CI 검사 정책 으로 이동합니다.

1. CI 검사 실패 자동 수정 토글 → ON

2. 자동 수정 가능한 검사 선택:

   • ✓ Lint 오류 (eslint --fix, gofmt 등으로 수정 가능)
   • ✓ 타입 불일치 (보통 TypeScript 추론으로 수정 가능)
   • ✓ 포맷 (Prettier, 포매터로 자동 수정)
   • ✗ 보안 검사 (검토 필요)
   • ✗ 사용자 정의 워크플로우 (보통 수동 개입 필요)

3. 수정 에이전트 선택 (또는 비워두면 기본 「code-fixer」사용)

4. 최대 재시도 횟수 설정 (기본값: 2)

5. 저장 클릭

수정 에이전트 할당

기본적으로 AACWorkflow는 자동 프로비저닝된 「code-fixer」에이전트를 사용합니다. 특정 에이전트를 사용하려면:

1. 설정 → GitHub → CI 검사 정책 으로 이동
2. 수정 에이전트 드롭다운 → 에이전트 선택 (예: 「Frontend Fixer」, 「Backend Fixer」)
3. 저장

선택한 에이전트는:

• 저장소에 쓰기 권한 필요 (GitHub 토큰 통해)
• CI 검사의 오류 유형 수정 방법 알아야 함
• 사용 가능해야 함 (다른 작업으로 과부하 아님)

수정 에이전트 작동 방식

단계 1: 실패 감지

PR의 CI 검사가 실패하면 AACWorkflow는 GitHub에서 실패 로그를 읽습니다 (GitHub API 통해):

{
  "check_run": "tests",
  "conclusion": "failure",
  "title": "Run tests",
  "output": {
    "title": "2 test failures",
    "summary": "packages/views/components/button.test.tsx:42 - expect....",
    "annotations": [
      {
        "path": "packages/views/components/button.test.tsx",
        "start_line": 42,
        "message": "Timeout: test 'renders with onClick handler' did not complete"
      }
    ]
  }
}

단계 2: 분석 및 계획

수정 에이전트는:

1. PR 브랜치를 로컬에서 클론
2. 실패 로그 및 오류 주석 읽기
3. 실패 분류:
   • 수정 가능: 구문 오류, lint 위반, 누락된 타입, 테스트 타임아웃
   • 에스컬레이션: 권한 거부, 인프라 장애, 테스트 로직 문제
4. 수정 계획 (예: 「async 테스트에 await 추가」, 「사용하지 않는 변수 제거」)

단계 3: 수정 구현

수정 에이전트는 PR 브랜치에 변경사항을 커밋합니다:

git checkout feature/aac-42-oauth
# 문제 수정 (구문, 타입, lint, 테스트)
git add .
git commit -m "fix: resolve CI check failures

- packages/views/components/button.test.tsx:42 - add await for async test
- server/cmd/server/main.go:18 - gofmt formatting
"
git push

GitHub는 자동으로 새 CI 실행을 트리거합니다 (브랜치가 업데이트됨).

단계 4: 재시도 또는 에스컬레이션

수정 커밋 후:

• CI 통과 ✅ → PR 이제 병합 가능 (여전히 인간의 검토 필요)
• CI 다시 실패 ❌ → max_retry_attempts 초과하지 않으면 재시도 로직 시작:
  • 새 실패 분석
  • 새 수정 계획
  • 다시 커밋
• 최대 재시도 초과 → 수동 개입으로 에스컬레이션:
  • 댓글 게시: 「I've attempted 2 fixes but CI still fails. See details below.」
  • PR 브랜치를 최선의 상태로 유지
  • 수동 검토자에게 할당

예시

예시 1: Lint 오류 (자동 수정 가능)

CI 실패: ESLint가 apps/web/app/page.tsx:15의 미사용 변수 보고

수정 조치:

1. 감지: unused variable 'tempUser'
2. 실행: eslint --fix apps/web/app/page.tsx
3. 커밋: fix: remove unused variable
4. 푸시
5. CI 재실행 및 통과 ✅

결과: PR이 초록색; 인간이 코드 검토.

예시 2: 테스트 타임아웃 (보통 수정 가능)

CI 실패: packages/core/agents/agents.test.ts:120에서 테스트 타임아웃

수정 조치:

1. 오류 읽기: 「Test 'should handle concurrent requests' did not complete」
2. 파일 열기, async 작업에서 await 누락 확인
3. async 호출 전에 await 추가
4. 커밋: fix: add missing await in concurrent test
5. 푸시
6. CI 재실행; 테스트 500ms 내 완료 ✅

결과: PR이 초록색.

예시 3: 타입 오류 (수정 가능성 변함)

CI 실패: TypeScript가 packages/core/api/client.ts:45의 타입 오류 보고

수정 조치:

1. 읽기: Type 'undefined' is not assignable to type 'string'
2. 문맥 검사; 올바른 값 추론 불가
3. 시도: 타입 가드 추가 (예: ?? '')
4. 커밋 및 푸시
5. CI 재실행; 타입 검사 통과 ✅

결과: PR이 초록색 (하지만 인간이 타입 가드 정확성 검토해야 함).

예시 4: 보안 검사 (에스컬레이션)

CI 실패: Snyk가 package.json의 취약한 의존성 감지

수정 조치:

1. Snyk 출력 읽기: 「lodash < 4.17.21 is vulnerable」
2. 업그레이드 안전성 확인: npm update lodash
3. 테스트: npm test — 모두 통과 ✅
4. 그러나: 보안 검사가 require_approval: true를 가짐
5. 댓글: 「Found vulnerable dependency; attempting upgrade.」
6. 인간 승인 대기 후 수정 푸시

결과: 수동 개입으로 에스컬레이션; 수정이 OK 대기.

승인 및 보안

신뢰 수준

검사 유형별 신뢰 수준 구성:

최대 재시도 횟수

에스컬레이션 전 수정 에이전트의 재시도 횟수 설정:

• 1 — 1회 시도; 실패 시 에스컬레이션
• 2 (기본값) — 2회 시도; 2차 실패 후 에스컬레이션
• 3 — 3회 시도; 대부분의 문제가 3차 시도까지 수정됨

API 및 자동화

수정 수동 트리거

자동 수정 비활성화 시 수동으로 트리거 가능:

POST /api/workspaces/{ws}/github/pr/{pr_number}/trigger-fix

Body:

{
  "check_run_id": 12345,
  "agent_id": "550e8400-e29b-41d4-a716-446655440000"
}

특정 PR에 대해 수정 비활성화

특정 PR에 대해 자동 수정을 비활성화하려면 (예: 수동 조사):

PATCH /api/workspaces/{ws}/github/pr/{pr_number}

Body:

{
  "auto_fix_ci_enabled": false
}

재활성화:

{
  "auto_fix_ci_enabled": true
}

수정 시도 조회

GET /api/workspaces/{ws}/github/pr/{pr_number}/fix-history

반환:

{
  "pr_number": 123,
  "fix_attempts": [
    {
      "attempt": 1,
      "triggered_at": "2025-06-22T15:30:00Z",
      "check_run": "tests",
      "failure_summary": "2 tests failed (timeouts)",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "abc123def456",
      "result": "success"
    },
    {
      "attempt": 2,
      "triggered_at": "2025-06-22T15:35:00Z",
      "check_run": "lint",
      "failure_summary": "3 ESLint violations",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "def456abc123",
      "result": "escalated"
    }
  ]
}

모범 사례

1. 높은 신뢰 검사부터 시작 — lint와 포맷이 자동 수정에 가장 안전
2. 처음 몇 가지 자동 수정 검토 — 완전히 신뢰하기 전에 수정 판단 확인
3. 전용 수정 에이전트 사용 — 오류 분석 및 수정 교육받은 에이전트
4. 에스컬레이션 모니터 — 자주 에스컬레이션되면 CI 오류 메시지가 불명확할 수 있음; 로그 개선
5. 합리적인 재시도 한계 설정 — 2-3회 보통 수정 가능한 문제 포함

문제 해결

「수정이 잘못된 수정을 하고 있음」

1. 수정 에이전트의 지침 확인 (설정 → 에이전트)
2. 과거 수정 시도 검토하여 패턴 파악
3. CI 검사 로그에 더 구체적인 문맥 추가 (더 좋은 오류 메시지 도움)
4. 다른 수정 에이전트 사용 또는 승인 게이트 추가 고려

「수정이 계속 에스컬레이션되고 수정하지 않음」

1. 검사 실패가 수정 불가능할 수 있음 (예: 보안, 인프라)
2. 수정 에이전트가 문맥 부족; 지침과 능력 확인
3. 너무 낮으면 max_retry_attempts 증가
4. 에이전트 시스템 프롬프트에 예시 추가하여 의사결정 가이드

「수동 수정 필요하지만 자동 수정 먼저 실행됨」

1. GitHub의 PR로 이동
2. auto_fix_ci_enabled: false 설정 (API 또는 설정 통해)
3. 조사 및 기본 문제 수동 수정
4. 문제 명확하면 자동 수정 재활성화

관련 기능

• GitHub 통합 — GitHub 통합 참조
• GitHub PR 생성 — GitHub PR 생성 흐름 참조
• 승인 정책 — 승인 정책 참조