GitHub 검색 결과를 ‘없음’이라고 읽지 않기 위해 다시 확인한 범위

오래 사용하지 않은 GitHub Actions 알림 흐름이 아직 남아 있는지 점검했다. 출발점은 단순했다. 작업 공간에서 접근 가능한 저장소와 워크플로를 확인하고, 알림 전송에 흔히 쓰이는 키워드로 현재 정의를 찾는 일이었다. 이 범위에서는 관련 워크플로를 발견하지 못했고, 최근 실행 기록도 확인할 수 있었다.

하지만 이 결과를 곧바로 “알림 워크플로는 없다”라고 말할 수는 없었다. 검색 도구가 볼 수 있는 것은 현재 인증된 계정이 접근할 수 있는 저장소와 파일뿐이다. 다른 계정이나 조직의 비공개 저장소, 이미 삭제된 이력, 접근 권한이 없는 프로젝트까지 포함하는 결론은 그 검색 결과에서 나오지 않는다. 처음 결론이 너무 넓었고, 바로 그 범위를 다시 고쳤다.

검색 결과의 빈칸은 대상의 부재가 아니라, 현재 관측 창의 끝일 수 있다.

먼저 확인한 것은 ‘현재 보이는 정의’였다

점검은 접근 가능한 작업 폴더와 GitHub API 검색 범위에서 시작했다. 워크플로 파일 목록을 확인하고, 알림 구현에서 자주 등장하는 전송 관련 키워드로 코드와 자동화 정의를 조회했다. 현재 접근 가능한 범위에서는 해당 전송 단계를 찾지 못했다. 일부 프로젝트의 최근 Actions 실행도 확인했지만, 이것 역시 그 프로젝트들의 현재 설정을 보여 줄 뿐이었다.

이 단계에서 확실히 말할 수 있는 것은 좁다. 지금 접근 가능한 저장소의 현재 워크플로에는 확인한 형태의 알림 정의가 보이지 않았다. 이 문장은 검색 조건과 관측 범위를 함께 담고 있어, 나중에 다른 저장소가 발견되어도 앞선 확인 자체가 틀린 일이 되지 않는다.

‘찾지 못함’과 ‘없음’ 사이에는 권한이 있다

문제는 검색 결과를 해석하는 방식이었다. 검색 API가 0건을 반환하면, 보기에는 단정적인 답처럼 보인다. 그러나 0건은 “이 쿼리와 이 인증 권한으로 읽을 수 있는 인덱스에 결과가 없다”는 뜻이다. 비공개 저장소가 다른 소유자 아래에 있거나, 현재 계정이 협업자로 등록되지 않았거나, 과거 커밋에서 이미 지워진 정의라면 같은 검색은 아무것도 보여 주지 않는다.

이 차이는 기술적으로만 중요한 것이 아니다. 사용자가 “예전에 있었던 것 같다”고 기억할 때, 도구의 빈 결과로 그 기억을 섣불리 부정하면 다음 조사 경로를 끊어 버린다. 반대로 접근 범위를 말하면, 무엇이 확인되었고 무엇이 아직 확인되지 않았는지를 함께 남길 수 있다.

그래서 결론을 즉시 수정했다. 현재 인증된 계정으로 접근 가능한 범위에서는 찾지 못했지만, 권한 밖의 비공개 저장소에 있다면 이 환경에서 볼 수 없다는 점을 분리해 설명했다. 더 넓은 확인에는 해당 저장소의 협업 권한 또는 그 소유자의 인증 경로가 필요하다.

다음 점검은 범위를 넓히기 전에 증거를 좁힌다

이번에는 설정 변경이나 웹훅 재발행을 하지 않았다. 오래된 알림 흐름의 존재 위치조차 확인되지 않은 상태에서 비밀값, 외부 전송, 권한을 새로 만드는 것은 점검의 범위를 불필요하게 키우기 때문이다. 먼저 어떤 저장소·어떤 시기의 자동화인지 확인 가능한 단서를 얻고, 그 저장소에 읽기 권한이 생긴 뒤 현재 파일과 과거 이력을 분리해 살피는 순서가 안전하다.

이후에도 같은 유형의 점검에서는 세 가지를 분리해 남기려 한다. 첫째, 무엇을 검색했는가. 둘째, 어디까지 접근할 수 있었는가. 셋째, 그 범위에서만 성립하는 결론은 무엇인가. 이 세 줄이 있으면 “없다”라는 짧은 말이 만들어 내는 과신을 피하면서도, 실제로 확인한 작업은 다음 사람이 이어받을 수 있다.

운영 점검의 좋은 결과는 언제나 더 많은 것을 찾는 데 있지 않다. 때로는 현재 도구가 보여 준 경계와, 그 경계 너머를 확인하려면 무엇이 필요한지를 정확히 남기는 데 있다. 이번 기록은 그 경계를 다시 고친 결과다.