GitHub Projects에 AND·OR 고급 검색 도입…복잡한 업무 보기가 단순해진다

GitHub가 Projects 필터에 AND·OR 복합 검색과 풀 리퀘스트 리뷰 상태 필터를 정식 도입했다.

GitHub Projects에 AND·OR 고급 검색 도입…복잡한 업무 관리가 단순해진다

Date: 2026-07-17 Topic: Developer Tools Primary source: GitHub Changelog

GitHub가 2026년 7월 16일 Projects의 고급 검색 기능을 정식 출시했다. 이제 프로젝트 보기의 필터 입력란에서 AND와 OR를 조합해 여러 조건을 하나의 검색식으로 표현할 수 있다. 특정 질문에 답할 때마다 별도의 보기를 만들어 관리하던 개발팀이라면, 기존 보기를 늘리지 않고도 필요한 작업만 골라볼 수 있게 됐다.

이번 업데이트에는 풀 리퀘스트의 리뷰 상태를 찾는 reviews: 필터도 포함됐다. 이와 함께 GitHub는 배포 상태 정보에 90일 보존 정책을 적용해, 90일이 지난 상태 기록은 REST·GraphQL API에서 더 이상 조회되지 않는다고 안내했다. 다만 각 배포의 현재 상태에는 영향을 주지 않는다.

News Brief

이번 발표의 중심은 GitHub Projects에서 복합 조건 검색을 정식 기능으로 제공한다는 점이다. 프로젝트 보드는 이슈와 풀 리퀘스트를 모아 계획, 진행 상황, 담당 업무를 관리하는 공간이다. 사용자는 이제 필터 입력란에 논리 연산자를 직접 넣어 조건을 결합할 수 있다.

  • AND: 두 조건을 모두 만족하는 항목을 찾는다.
  • OR: 두 조건 가운데 하나 이상을 만족하는 항목을 찾는다.
  • reviews:: 프로젝트에 들어 있는 풀 리퀘스트를 리뷰 상태에 따라 거른다.
  • 배포 상태 기록: 생성 후 90일이 지나면 자동 삭제되고 REST·GraphQL API에서도 제외된다.

고급 검색은 베타나 제한 공개 단계가 아니라 일반 사용자가 쓸 수 있는 정식 제공 상태, 즉 GA(Generally Available)에 들어갔다. 별도 기능 신청 없이 프로젝트 보기의 필터 입력란에서 검색식을 작성하는 방식이다.

Key Details

논리 연산자의 장점은 조건 사이의 관계를 명시할 수 있다는 데 있다. 단순 필터를 차례로 붙이는 방식만으로는 ‘긴급하거나 이번 주 마감이면서 아직 담당자가 없는 작업’처럼 조건의 묶음을 정확하게 표현하기 어렵다. AND와 OR를 함께 사용하면 검색 의도를 하나의 식으로 나타낼 수 있어, 질문마다 새 프로젝트 보기를 만드는 부담을 줄일 수 있다.

reviews: 필터는 풀 리퀘스트 검토 흐름을 프로젝트 관리 화면에 끌어온다. GitHub 설명에 따르면 이 기능은 리뷰를 요청받은 사람과 각 리뷰어가 가장 최근에 제출한 리뷰를 추적하는 Reviewers 필드를 바탕으로 작동한다. 따라서 팀은 코드 화면을 일일이 오가지 않고도 리뷰 대기, 변경 요청, 승인 여부와 관련된 항목을 프로젝트 관점에서 분류할 수 있다.

함께 발표된 90일 보존 정책은 검색 기능과 성격이 다르지만 API 이용자에게 중요하다. 삭제 대상은 오래된 배포의 상태 기록이며, 배포가 현재 어떤 상태인지는 유지된다. 과거 상태 기록을 REST 또는 GraphQL API로 장기간 수집해 감사, 분석, 사내 대시보드에 쓰는 조직이라면 자체 보관 범위가 충분한지 확인할 필요가 있다.

Background

GitHub Projects는 저장소의 이슈와 풀 리퀘스트를 표, 보드, 로드맵 형태로 구성하는 작업 관리 기능이다. 같은 데이터라도 담당자, 마일스톤, 상태, 레이블처럼 무엇을 기준으로 보느냐에 따라 여러 보기가 필요해진다. 팀 규모가 커질수록 역할별 보기가 계속 추가되고, 비슷한 필터를 가진 화면이 중복되기 쉽다.

고급 검색은 이 문제를 데이터 구조를 바꾸지 않고 조회 단계에서 풀려는 기능이다. 기존 항목이나 필드를 옮기는 대신, 사용자가 그때그때 필요한 조건을 검색식으로 표현한다. 정기적으로 공유해야 하는 화면은 저장된 보기로 남기고, 일회성 확인이나 문제 추적은 복합 검색으로 처리하는 식의 구분이 가능해진다.

Core Lens
이번 변화의 핵심은 검색창이 더 똑똑해졌다는 사실보다, 복잡한 개발 업무를 확인하기 위해 프로젝트 보드를 계속 복제할 필요가 줄었다는 데 있다.

What It Means for Developers

개발팀이 바로 체감할 부분은 분류와 점검에 드는 시간이다. 릴리스 직전 미완료 작업, 특정 팀이 맡은 보안 이슈, 리뷰가 멈춘 풀 리퀘스트처럼 여러 조건이 얽힌 목록을 한 화면에서 좁힐 수 있다. 특히 reviews: 필터는 코드 리뷰가 단순한 개발 활동을 넘어 일정 지연을 찾는 프로젝트 관리 신호로 활용될 수 있게 한다.

다만 복잡한 검색식이 늘어나면 팀원마다 조건을 다르게 해석할 가능성도 있다. 반복해서 사용하는 검색은 이름이 명확한 보기로 저장하고, 일회성 조사에만 즉석 검색을 쓰는 운영 원칙이 유용하다. 배포 상태 기록 역시 GitHub가 장기 이력 저장소 역할까지 맡아줄 것이라고 가정하기보다, 필요한 기간과 감사 요건을 먼저 정해야 한다.

What To Watch

  • AND와 OR를 섞은 검색식이 긴 조건에서도 예상한 우선순위로 평가되는지 확인해야 한다.
  • 리뷰 상태 필터가 실제 팀의 승인 규칙과 브랜치 보호 정책을 얼마나 잘 반영하는지 살펴볼 필요가 있다.
  • 90일을 넘는 배포 상태 이력이 필요한 조직은 API 수집 주기와 별도 보관 정책을 점검해야 한다.
  • GitHub가 고급 검색을 향후 자동화, 저장된 보기, 인사이트 기능과 어떻게 연결할지도 관찰할 부분이다.

Sources