GitHub PR 화면이 바뀌었다: 검색창보다 먼저 정리할 네 가지 필터

Pull request가 많은 저장소에서는 목록 화면 자체가 작은 운영 도구입니다. 누가 리뷰해야 하는지, 어떤 PR이 막혀 있는지, 이번 주에 끝내야 할 변경이 무엇인지 한 화면에서 골라내야 합니다. GitHub는 2026년 9월 21일(한국 시간 22일) 저장소의 새 Pull requests 페이지를 모든 사용자에게 제공하기 시작했습니다. 변경 안내에 따르면 새 화면에는 필터 입력 보조, 고급 검색의 AND·OR, 접을 수 있는 사이드바, compact 표시, 상태 검사 수와 unread 업데이트 같은 맥락 정보가 들어갑니다.

기능 목록만 보면 UI 개편입니다. 실제로는 리뷰 큐를 만드는 방법이 바뀐 셈입니다. 검색창에 무엇이든 길게 넣기보다, 먼저 리뷰 목적을 정하고 그 목적에 맞는 필터를 조합하는 편이 덜 흔들립니다.

목적을 정하고 PR 필터를 조합한 뒤 목록 신호를 보고 상세 화면에서 검토하는 네 단계 흐름도

그림 1. PR 목록을 리뷰 목적, 검색 조건, 목록 신호, 상세 검토의 순서로 다루는 실무 흐름. 출처: github.blog/changelog/2026-09-21-refreshed-repository-pull-requests-page-generally-available.

새 화면에서 달라진 것

GitHub의 공식 변경 안내는 새 저장소 PR 페이지의 초점을 “찾고 행동하기 쉽게 만드는 것”으로 설명합니다. 필터 입력 보조는 올바른 qualifier를 찾는 데 도움을 주고, 고급 검색은 AND와 OR, 중첩 검색을 지원합니다. 사이드바는 Authored by me, Involves me 같은 자주 쓰는 범주를 빠르게 여닫게 합니다.

목록을 좁히는 기능만 늘어난 것은 아닙니다. compact presentation mode는 한 화면에 더 많은 PR을 보여 주고, status check count·stack indicator·unread update 같은 정보는 목록을 열기 전에 우선순위를 판단할 단서를 줍니다. 여러 PR을 골라 닫거나 라벨과 milestone을 바꾸는 bulk action도 공식 안내에 포함돼 있습니다.

필터 사이드바와 검색 보조, 상태 검사 수와 unread 표시가 있는 저장소 PR 목록의 구성도

그림 2. 새 PR 목록에서 사이드바, 검색 보조, compact 목록과 상태 맥락을 각각 어떤 용도로 볼지 정리한 그림. 출처: github.blog/changelog/2026-09-21-refreshed-repository-pull-requests-page-generally-available.

검색창보다 먼저 목적을 정하자

가장 먼저 할 일은 검색창에 긴 문장을 넣는 것이 아니라, 이번 리뷰의 목적을 한 문장으로 고정하는 것입니다. 예를 들어 “오늘 내가 리뷰해야 할 변경”, “실패한 검사 때문에 멈춘 PR”, “이번 릴리스 milestone에 들어간 미완료 변경”은 서로 다른 큐입니다.

GitHub 문서의 검색 qualifier는 이 목적을 구체적인 조건으로 나누는 데 쓸 수 있습니다. is:pr처럼 대상을 고르고, is:open으로 현재 열려 있는 항목만 남기고, author:, assignee:, reviewer:, label:, milestone:, status: 같은 조건을 덧붙입니다. 조건을 많이 넣는다고 항상 좋은 것은 아닙니다. 결과가 0개가 되면 무엇이 잘못됐는지 찾기 어려워지므로, 넓은 조건에서 시작해 한 단계씩 좁히는 편이 안전합니다.

is pr와 is open에서 시작해 reviewer, label, status 조건을 한 단계씩 더하는 PR 필터 사다리

그림 3. 결과가 0개가 되면 마지막 조건부터 되돌리는 단계적 필터링 방법. 출처: docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests.

네 가지 기본 큐

첫 번째는 내 리뷰 큐입니다. is:pr is:open review-requested:@me처럼 현재 열려 있고 내 검토가 필요한 항목부터 확인합니다. 팀 설정이나 권한에 따라 실제 qualifier가 다를 수 있으므로, 새 화면의 입력 보조가 제안하는 값을 읽어 확인해야 합니다.

두 번째는 검사 실패 큐입니다. 상태 검사와 unread 업데이트를 함께 보면 “누군가 고쳤지만 아직 다시 보지 않은 PR”과 “아직 빌드가 깨진 PR”을 구분하기 쉽습니다. 실패 상태를 곧바로 코드 결함으로 단정하지 말고, 최신 커밋과 실패한 검사 이름을 PR 안에서 다시 확인합니다.

세 번째는 릴리스 큐입니다. milestone이나 label을 기준으로 좁힌 뒤, 오래 열린 PR과 최근 업데이트 PR을 나눠 봅니다. compact 모드는 목록 비교에는 유용하지만, 제목만 보고 승인하면 안 됩니다. status count와 unread 표시를 우선순위 신호로 쓰고 최종 판단은 상세 화면에서 합니다.

네 번째는 정리 큐입니다. 닫혔거나 오래된 PR을 한꺼번에 처리하는 작업입니다. bulk action은 편하지만, 여러 PR을 선택하기 전에 각 항목의 milestone·연결 issue·작성자 배지를 확인해야 합니다. 새 화면이 빠르게 만들었다는 이유만으로 닫기와 라벨 변경을 자동화하면 안 됩니다.

AND와 OR를 섞을 때의 주의점

AND는 조건을 모두 만족하는 항목을 남기고, OR는 여러 후보군을 한 결과로 묶습니다. 예를 들어 특정 label이 붙은 PR 가운데 내가 리뷰어이거나 담당자인 항목을 찾는 식으로 쓸 수 있습니다. 다만 검색식이 길어질수록 결과를 설명하기 어려워집니다.

팀에서 반복할 검색은 짧은 목적 이름과 함께 기록하는 편이 좋습니다. “내 리뷰”, “릴리스 대기”, “검사 실패”처럼 큐 이름을 먼저 정하고 실제 검색식은 설명에 남깁니다. 검색 결과가 바뀌었을 때 어떤 조건이 결과를 바꿨는지도 추적할 수 있습니다.

내 리뷰, 검사 실패, 릴리스 대기, 정리라는 네 가지 PR 큐와 목록 신호 및 상세 결정의 관계

그림 4. 큐 이름을 먼저 정하고 AND로 좁히거나 OR로 후보군을 묶되 최종 결정은 상세 화면에서 하는 원칙. 출처: docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/filtering-and-searching-issues-and-pull-requests.

새 화면을 도입할 때의 점검 순서

  1. 오늘 처리할 큐 하나를 고르고, 조건을 두세 개로 시작합니다.
  2. 목록에서 상태 검사 수, unread 표시, milestone과 연결 issue를 확인합니다.
  3. 필요한 경우 사이드바를 접어 비교 범위를 넓히고 compact 모드로 목록을 훑습니다.
  4. 실제 변경 판단은 PR 상세 화면에서 합니다. 목록의 숫자는 우선순위 신호이지 승인 근거가 아닙니다.
  5. bulk action을 하기 전 선택한 항목의 목적과 범위를 다시 읽습니다.

이 순서는 새 UI에만 해당하지 않습니다. PR 목록을 검색 결과가 아니라 작업 큐로 다루는 방법입니다. 필터가 잘 만들어져도 리뷰어 지정, CI 정책, milestone 운영이 엉켜 있으면 화면은 문제를 가릴 뿐입니다. 저장소마다 qualifier와 권한이 다르므로 작은 범위에서 결과를 확인한 뒤 팀의 기본 검색을 정하는 편이 낫습니다.

이 글의 검증 범위

이 글은 GitHub의 공식 변경 안내와 GitHub Docs의 검색·PR 필터 문서를 2026년 9월 22일에 대조해 정리했습니다. 새 PR 페이지의 기능 설명은 GitHub가 공개한 범위에 한정했습니다. 이 글은 GitHub의 공식 변경 안내와 검색 문서를 읽고 정리한 사용 흐름이며, 특정 저장소의 실제 PR 처리 시간이나 생산성 향상을 측정한 실험은 아닙니다. 특정 팀이 새 화면을 사용해 리뷰 시간을 줄였는지, bulk action이 오류 없이 처리되는지는 별도로 측정하지 않았습니다.

즉, 이번 업데이트를 생산성 향상으로 단정할 수는 없습니다. 확인할 수 있는 것은 목록을 찾고 좁히고 비교하는 도구가 늘었다는 점입니다. 실제 효과는 팀이 어떤 큐를 만들고, 그 큐를 얼마나 일관되게 사용하는지에 달려 있습니다.

참고 자료

AI 활용 투명성: 이 글은 공식 문서의 기능 설명을 바탕으로 구조화하고 문장을 다듬었다. 새 화면의 생산성 효과나 특정 저장소의 처리 시간은 독립적으로 측정하지 않았다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기