GitHub Code Quality 지적, 누가 무시했는지 찾는 법

저장소 코드 화면 대신 조직의 Audit log를 연다

Code Quality 지적이 사라졌는데 수정 커밋이 보이지 않는다면, 조직 감사 로그에서 수동 처리 기록을 찾을 수 있다. GitHub는 10월 13일부터 지적 해제와 다시 열기 이벤트를 제공한다. Code Quality를 켠 저장소는 이를 위해 추가 설정을 할 필요가 없다.

조직의 Settings → Logs → Audit log에서 아래와 같이 검색한다. my-org/my-repo는 실제 조직·저장소 이름으로 바꾸는 예시다.

action:repo.code_quality_findings_dismissed repo:my-org/my-repo

다시 열린 기록은 이벤트 이름을 바꿔 찾는다.

action:repo.code_quality_findings_reopened repo:my-org/my-repo

처리자를 알고 있다면 actor:사용자명을 덧붙여 범위를 좁힌다. 이때는 실명이 아니라 GitHub 사용자명을 써야 한다. 감사 로그는 일반 문장을 찾는 검색창이 아니므로 ‘품질 경고 무시’라고 입력하는 대신 이벤트와 저장소 필터를 사용한다.

한 줄에 여러 지적이 묶일 수 있다

이벤트는 요청한 사람과 시각, 저장소와 규칙, 영향을 받은 지적의 식별자와 개수를 담는다. 한 번에 여러 지적을 처리할 수 있어 로그 한 줄을 지적 하나로 세면 안 된다.

예를 들어 팀의 처리량을 확인한다면 로그의 행 수만 더하기보다 이벤트에 기록된 지적 ID와 개수를 확인해야 한다. 같은 지적을 다시 열었다가 해제한 기록도 각각의 상태 변경이다. 이를 모두 코드 수정 건수로 바꾸어 읽을 수는 없다.

무시는 필요한 판단일 수 있지만, 수정 커밋은 아니다

GitHub의 backlog 처리 안내는 관련 없거나 조치할 수 없는 지적에 Dismiss를 사용할 수 있다고 설명한다. 더 이상 유지하지 않는 레거시 코드, 팀 규칙에서 인정한 예외, 오탐이 그 예다. 해제 이력이 있다는 사실만으로 잘못된 처리를 했다고 볼 수는 없다.

코드를 고치는 경로는 별도로 존재한다. 저장소의 ‘Security and quality → Code quality → Standard findings’에서 규칙과 지적 내용을 읽고, Copilot에 수정을 맡겼다면 생성된 초안 PR을 검토한 뒤 CI 검사를 거쳐 병합한다. 이 화면의 처리에는 저장소 쓰기 권한이 필요하다.

따라서 확인할 대상도 두 가지다. 불필요한 지적을 제외한 결정은 해제 이벤트로, 실제 변경은 PR의 코드 차이와 병합 결과로 확인한다. 감사 로그는 누가 상태를 바꿨는지 답하지만, 그 결정의 적절성까지 대신 판단하지는 않는다.

권한·기간·제품 이름을 확인한다

일반 조직 감사 로그는 조직 소유자가 볼 수 있다. 보관 범위는 최근 180일이고 기본 화면에는 최근 3개월만 표시되므로, 더 오래된 기록은 created 필터로 기간을 지정해야 한다.

이번 Code Quality 이벤트는 GitHub Team과 GitHub Enterprise Cloud에서 제공되며 Enterprise Server는 대상이 아니다. Enterprise Cloud에서는 감사 로그 API로도 가져올 수 있다. 저장소에서 지적을 처리할 수 있다는 사실과 조직 감사 로그를 열 수 있다는 사실은 같은 권한을 뜻하지 않는다.

보안 취약점을 다루는 code scanning 경고를 찾는 경우에는 이름도 달라진다. 보안 스캔의 수동 해제 이벤트는 code_scanning.alert_closed_by_user, 수동 재개는 code_scanning.alert_reopened_by_user다. Code Quality 지적과 혼용하면 필요한 기록을 놓칠 수 있다.

사라진 지적을 찾는 첫 단계는 올바른 이벤트를 조회하는 것이다. 처리자만 확인하고 끝내지 말고, 대상 ID와 개수까지 맞춘 뒤 코드 수정 여부를 판단해야 한다.