GitHub Projects 고급 검색 GA: 운영 보드는 감사 로그가 아니다
“지난 분기에 이 변경이 언제 production에 들어갔고, 누가 승인했으며, 첫 배포가 왜 실패했는가?” 이 질문에 GitHub Projects 보드 하나로 답하려 했다면 데이터 모델을 다시 봐야 한다. GitHub는 7월 16일 Projects 고급 검색을 GA로 전환해 AND, OR, reviews:로 훨씬 정교한 운영 뷰를 만들게 했다. 동시에 90일이 지난 deployment status는 자동 삭제되며 REST와 GraphQL API에서도 보이지 않는다고 알렸다. 보드는 더 강해졌지만, 장기 감사 원장으로 승격된 것은 아니다.
무엇이 바뀌었나: 질문은 자유로워지고 기록의 수명은 짧아졌다
GitHub Projects의 필터 바는 이제 서로 다른 필드 사이에서도 논리식 AND와 OR를 직접 받을 수 있다. 예전처럼 질문마다 별도 view를 만들지 않고도 “이번 iteration의 높은 우선순위 버그이거나 review가 막힌 PR” 같은 임시 질의를 표현할 수 있다. 저장된 view는 반복 업무에, 즉석 논리식은 조사와 회의 질문에 쓰는 구분이 가능해졌다.
새 reviews: 필터는 PR의 review state를 보드 질의에 끌어온다. 이 값은 review 요청 대상과 각 reviewer가 마지막으로 제출한 review를 추적하는 Reviewers 필드에 기반한다. 따라서 “개발 완료”와 “승인 완료”를 같은 status 열로 뭉개지 않고 review 병목을 별도로 볼 수 있다.
그러나 같은 변경 로그에는 더 중요한 보존 계약이 붙었다. deployment status는 90일이 지나면 자동 삭제되고 REST·GraphQL API에서 사라진다. deployment의 현재 상태는 영향을 받지 않지만, 과거에 queued → in_progress → failure → success로 움직인 개별 상태 전이는 장기 조회 대상으로 가정할 수 없다.
왜 중요한가: 현재 상태, 작업 흐름, 감사 증거는 서로 다른 데이터다
Projects는 “지금 무엇을 해야 하는가”에 최적화된 작업 투영이다. issue, PR, review, custom field를 조합해 팀의 현재 병목을 보여준다. deployment status는 특정 deployment가 시간에 따라 어떤 상태를 거쳤는지 알려 주는 이벤트에 가깝다. 두 데이터를 한 화면에서 연결할 수 있어도 수명과 책임은 같지 않다.
90일 뒤에도 남는 deployment current state만으로는 재시도 횟수, 첫 실패 원인, 승인 이후 실제 배포까지 걸린 시간 같은 운영 질문을 복원할 수 없다. API 소비자가 “페이지네이션 끝까지 읽었으니 전체 이력”이라고 해석하면, 삭제된 과거를 정상적인 빈 결과로 오인할 수 있다.
규제 감사가 아니어도 incident review, 고객 문의, rollback 판단, DORA 계열 내부 지표에는 과거 시점의 증거가 필요할 수 있다. GitHub의 보존 정책이 나쁘다는 뜻이 아니라, 제품의 목적과 팀의 증거 보존 기간이 다를 수 있다는 뜻이다.
실무 설계: Projects는 control view, 외부 저장소는 evidence ledger
Projects에는 사람이 의사결정할 필드만 둔다. 예를 들어 Environment, Release, Risk, Review state, Deployment state, Incident link를 구조화하고, 고급 검색으로 “production 대상이면서 review가 미완료인 PR”이나 “실패했거나 rollback 대기인 배포 관련 작업”을 찾는다.
배포가 발생할 때는 GitHub Actions나 배포 플랫폼에서 append-only에 가까운 별도 레코드를 남긴다. 최소 필드는 repository, commit SHA, environment, deployment ID, status, actor/approver, workflow run URL, artifact digest, createdAt이다. 민감한 log 전체를 복사하기보다 검증 가능한 식별자와 필요한 증거만 보존하고 접근 제어·TTL을 별도로 정한다.
Projects item에는 원장 전체를 복제하지 말고 release ID나 evidence URL만 연결한다. 보드는 현재 흐름을 빠르게 질의하고, 원장은 과거 사실을 재구성한다. 이 경계를 두면 보드 필드를 지워도 감사 증거가 사라지지 않고, 원장 스키마가 복잡해져도 일상 보드가 무거워지지 않는다.
검색식을 운영 규칙으로 바꾸는 방법
첫 단계는 질문을 자연어에서 검증 가능한 view로 바꾸는 것이다. 예를 들어 environment:production AND (reviews:changes_requested OR status:blocked)처럼 production 위험만 모으거나, iteration:@current AND (priority:P0 OR priority:P1)처럼 당장 다룰 범위를 좁힌다. 실제 qualifier와 review state 값은 조직의 필드 구성과 GitHub UI 제안값으로 확인해야 한다.
두 번째는 saved view 수를 줄이는 것이 목적이 아니라 책임을 분명히 하는 것이다. Daily triage, release gate, incident follow-up처럼 반복되는 질문만 저장하고, 일회성 분석은 고급 검색으로 처리한다. view 이름에는 owner와 행동을 넣어 “누가 보고 무엇을 해야 하는지”를 드러낸다.
세 번째는 API 자동화에 결손 탐지를 넣는 것이다. deployment status를 정기 수집한다면 마지막 성공 시각, 수집 지연, deployment별 status count, 90일 경계보다 짧은 동기화 주기를 감시한다. 0건을 곧바로 “실패 없음”으로 해석하지 말고, source retention으로 이미 사라진 것인지 구분한다.
커뮤니티 신호: 개발 완료와 배포 완료를 어떻게 연결할 것인가
개발자 커뮤니티에는 Projects로 특정 배포에 묶인 작업을 보고 싶지만 완료된 항목을 어떻게 숨기고 다시 불러올지 모르겠다는 질문이 반복된다. 답변은 milestone, 별도 열, release 단위 같은 여러 모델로 갈린다. 이 글은 그 논의를 기능 사실의 근거로 쓰지 않고, “Done이 merge인가, QA 통과인가, production 검증인가”라는 모델링 혼란의 신호로만 사용한다.
고급 검색은 이 혼란을 자동으로 해결하지 않는다. 잘 정의된 field와 상태 전이가 있어야 검색식도 의미가 있다. 반대로 모든 것을 하나의 Status 필드에 넣으면 AND와 OR가 있어도 정확한 질문을 만들 수 없다.
팀이 먼저 합의할 것은 도구가 아니라 완료 정의다. 코드 완료, review 승인, 배포 성공, production 검증을 별도 사건으로 취급하고 연결해야 보드와 원장의 역할이 명확해진다.
오늘 적용할 체크리스트
1. GitHub Projects에서 저장된 view가 답하는 반복 질문과 owner를 문서화한다.
2. PR item에 Reviewers와 reviews:를 시험해 review 병목을 별도 표시한다.
3. AND·OR로 release gate용 질의를 만들고 결과 표본을 사람이 검증한다.
4. “Done”을 merge, deploy, production validation 중 무엇으로 정의하는지 분리한다.
5. deployment status를 90일 넘게 써야 하는 보고서·감사·incident 절차를 찾는다.
6. 필요한 경우 status event를 90일 이전에 외부 evidence ledger로 수집한다.
7. commit SHA, environment, deployment ID, actor, workflow URL, artifact digest를 보존한다.
8. 원장 접근 권한, 암호화, 보존 기간, 삭제 정책을 명시한다.
9. API의 빈 결과를 “사건 없음”과 “보존 만료”로 구분한다.
10. 분기별 복구 훈련에서 오래된 배포 한 건을 실제로 재구성해 본다.
리스크와 반론
외부 원장은 비용과 개인정보·보안 책임을 늘린다. 모든 팀이 필요한 것은 아니다. 90일 이내 운영 분석만 필요하고 배포 플랫폼이 더 긴 이력을 제공한다면 GitHub status를 별도로 복제하지 않아도 된다. 먼저 질문과 법적·계약적 보존 요구를 확인해야 한다.
Projects 고급 검색은 GA지만, 모든 조직 필드가 자동으로 좋은 운영 모델이 되는 것은 아니다. 복잡한 논리식은 현황을 잘 보여 주는 동시에 잘못된 qualifier나 빈 field를 숨길 수 있다. 중요한 gate는 UI view 하나에만 의존하지 말고 CI 규칙과 환경 보호 정책으로 강제한다.
마지막으로 deployment status와 workflow log, audit log, artifact provenance는 서로 대체재가 아니다. 무엇을 증명해야 하는지에 따라 보존 대상이 달라진다. “전부 저장” 대신 최소 증거와 복구 가능성을 설계하는 편이 안전하다.
운영 질문을 표현하는 예시 질의
# Example intent — confirm exact field names in your Project
(environment:production AND reviews:changes_requested)
OR (environment:production AND status:blocked)
# Evidence collector must run inside the source-retention window
repository + commit_sha + environment + deployment_id
+ status + actor + workflow_url + artifact_digest + created_atField names and accepted review values depend on the Project configuration; validate the expression against a known sample before using it as a gate.
Projects와 배포 증거 분리 체크포인트
✓GitHub Projects에서 저장된 view가 답하는 반복 질문과 owner를 문서화한다.
✓PR item에 Reviewers와 reviews:를 시험해 review 병목을 별도 표시한다.
✓AND·OR로 release gate용 질의를 만들고 결과 표본을 사람이 검증한다.
✓“Done”을 merge, deploy, production validation 중 무엇으로 정의하는지 분리한다.
✓deployment status를 90일 넘게 써야 하는 보고서·감사·incident 절차를 찾는다.
✓필요한 경우 status event를 90일 이전에 외부 evidence ledger로 수집한다.
✓commit SHA, environment, deployment ID, actor, workflow URL, artifact digest를 보존한다.
✓원장 접근 권한, 암호화, 보존 기간, 삭제 정책을 명시한다.
✓API의 빈 결과를 “사건 없음”과 “보존 만료”로 구분한다.
✓분기별 복구 훈련에서 오래된 배포 한 건을 실제로 재구성해 본다.
정리
GitHub Projects의 AND, OR, reviews:는 팀의 현재 상태를 더 정확히 질문하게 해 준다. 그러나 90일이 지난 deployment status가 API에서 사라지는 순간, 그 보드는 장기 감사 원장이 될 수 없다. Projects는 control view로, 필요한 배포 증거는 별도 evidence ledger로 설계하고 둘을 release ID와 commit SHA로 연결하라.