포스트

[GitHub 100일 챌린지] Day 72 - Issues 효율적 관리

[GitHub 100일 챌린지] Day 72 - Issues 효율적 관리

100일 챌린지 Day 72 - 많은 Issues를 효율적으로 관리하고 검색하는 방법을 마스터합니다.

⏱️ 예상 학습 시간: 35-45분 📚 난이도: ⭐⭐⭐ (중급)

배울 내용

  1. Issue 검색 쿼리 작성법
  2. 필터 저장 및 재사용
  3. 대량 작업 처리하기

시작하기 전에

이 내용은 다음 개념을 알고 있다면 더 쉽게 이해할 수 있습니다:

  • ✅ Issue 생성 및 기본 사용법 (Day 71)
  • ✅ 라벨과 마일스톤 개념 (Day 71)
  • ✅ Repository 기본 관리 (Day 12-13)

Day 71을 먼저 학습하신 후 진행하시면 좋습니다!


1. Issue 검색

기본 검색 문법

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 상태로 검색
is:open          → 열린 Issue
is:closed        → 닫힌 Issue
is:merged        → 머지된 PR

# 라벨로 검색
label:bug        → bug 라벨
label:"good first issue"  → 공백 포함 시 따옴표

# 담당자로 검색
assignee:@me     → 나에게 할당된 것
assignee:username → 특정 사용자
no:assignee      → 할당 안 된 것

# 작성자로 검색
author:username  → 특정 사용자가 작성

고급 검색

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 날짜 검색
created:>2024-01-01       → 2024년 이후 생성
updated:<2024-06-01       → 6월 전 업데이트
closed:2024-01-01..2024-12-31  → 기간 내 닫힘

# 댓글 수
comments:>10     → 댓글 10개 이상
comments:0       → 댓글 없음

# 반응 수
reactions:>5     → 반응 5개 이상
reactions:>=10   → 반응 10개 이상

# 마일스톤
milestone:"v2.0"  → v2.0 마일스톤
no:milestone     → 마일스톤 없음

# 프로젝트
project:board/1  → 특정 프로젝트

검색 조합

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# AND 조건 (공백으로 구분)
is:open label:bug assignee:@me
→ 나에게 할당된 열린 버그

# OR 조건
label:bug label:enhancement
→ 버그 또는 개선사항

# NOT 조건 (- 사용)
is:open -label:bug
→ 버그가 아닌 열린 Issue

# 복합 예시
is:open label:bug -assignee:@me created:>2024-01-01 comments:>5
→ 2024년 이후 생성되고, 댓글 5개 이상, 내가 할당받지 않은 버그

2. 검색 필터 저장하기

💡 초보자 팁 검색 쿼리가 복잡해 보이나요? 처음엔 간단한 것부터 시작하세요! is:open만 입력해도 충분합니다. 필요할 때마다 조건을 하나씩 추가하면 됩니다. 아래 예시를 복사해서 사용하셔도 좋습니다!

자주 사용하는 필터

1
2
3
4
5
6
7
8
9
10
11
12
13
14
내 작업:
is:open assignee:@me

긴급 버그:
is:open label:bug label:priority:high

초보자용 작업:
is:open label:"good first issue" no:assignee

리뷰 대기:
is:open label:needs-review

오래된 Issue:
is:open updated:<2024-01-01

북마크 활용

  1. 검색 쿼리 입력
  2. URL을 브라우저 북마크에 저장
  3. 원클릭으로 필터링된 뷰 접근

예시 URL:

1
https://github.com/user/repo/issues?q=is:open+label:bug+assignee:@me

3. 대량 작업 처리

선택 및 일괄 작업

1
2
3
4
5
6
7
8
Issue 목록에서:
1. 체크박스로 여러 Issue 선택
2. 상단 메뉴에서 작업 선택:
   - 라벨 추가/제거
   - 담당자 할당
   - 마일스톤 설정
   - 프로젝트 추가
   - 닫기/열기

실전 예시

시나리오: Sprint 종료 시 완료된 Issue 정리

1
2
3
4
5
6
1. 검색: is:open label:sprint-1
2. 완료된 Issue들 선택
3. 일괄 작업:
   - 라벨 "completed" 추가
   - 라벨 "sprint-1" 제거
   - 일괄 닫기

4. Issue 자동 닫기

커밋 메시지로 닫기

1
2
3
4
5
6
7
8
# 키워드 사용
git commit -m "fix: Login button bug

Closes #123
Fixes #456
Resolves #789"

# Push 시 자동으로 해당 Issue들 닫힘

지원하는 키워드

1
2
3
- close, closes, closed
- fix, fixes, fixed
- resolve, resolves, resolved

PR 설명에서 닫기

1
2
3
4
5
6
7
8
9
10
## 변경 사항
로그인 버튼 라우팅 수정

## 관련 Issue
Closes #123
Closes #124

## 테스트
- [x] 로그인 테스트 통과
- [x] 회원가입 테스트 통과

5. Issue 우선순위 관리

우선순위 라벨 시스템

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
priority:critical (🔴 빨강)
- 서비스 장애
- 보안 취약점
- 긴급 수정 필요

priority:high (🟠 주황)
- 주요 기능 버그
- 중요한 개선
- 다음 릴리스 포함

priority:medium (🟡 노랑)
- 일반 버그
- 기능 개선
- 계획된 작업

priority:low (🟢 초록)
- 사소한 버그
- Nice-to-have
- 나중에 처리

우선순위 기반 워크플로우

1
2
3
4
5
매일 아침:
1. priority:critical 확인 → 즉시 처리
2. priority:high 확인 → 오늘 처리
3. priority:medium 확인 → 이번 주 처리
4. priority:low 확인 → 여유 시 처리

6. Issue 트리아지 (Triage)

트리아지란?

정의: 새로 생성된 Issue를 검토하고 분류하는 과정

트리아지 체크리스트

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
새 Issue #123 검토:

1. ✅ 유효성 확인
   - 실제 버그인가?
   - 재현 가능한가?
   - 중복이 아닌가?

2. ✅ 분류
   - 라벨: bug, enhancement, question
   - 우선순위: priority:high
   - 카테고리: backend

3. ✅ 담당자 할당
   - @backend-team

4. ✅ 마일스톤 설정
   - v2.1 Release

5. ✅ 추가 정보 요청
   - 환경 정보 필요
   - 스크린샷 요청

트리아지 자동화

GitHub Actions 예시:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
name: Issue Triage
on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - name: Add triage label
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.addLabels({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              labels: ['needs-triage']
            })

7. Issue 알림 관리

알림 설정

1
2
3
4
5
6
Settings → Notifications

옵션:
- Watching: 모든 활동 알림
- Participating: 내가 참여한 것만
- Ignoring: 알림 없음

맞춤 알림

1
2
3
4
5
6
특정 Issue만 Watch:
- Issue 페이지 → 우측 "Subscribe"
- 해당 Issue의 모든 활동 알림 받기

알림 해제:
- Issue 페이지 → "Unsubscribe"

이메일 필터링

1
2
3
4
Gmail 필터 예시:
from:notifications@github.com
subject:[user/repo]
→ 라벨: GitHub/MyRepo

직접 해보기 (25분)

실습을 통해 Issue 관리 능력을 향상시켜봅시다!

🔍 실습 1: 검색 쿼리 연습 (10분)

1
2
3
4
5
- [ ] 1. 본인 Repository의 Issues 페이지 이동
- [ ] 2. 검색창에 `is:open` 입력 → 열린 Issue 확인
- [ ] 3. `is:closed` 입력 → 닫힌 Issue 확인
- [ ] 4. `assignee:@me` 추가 → 내가 담당한 Issue만 표시
- [ ] 5. `label:bug` 추가 → 버그 라벨 Issue만 표시

📌 실습 2: 필터 북마크 만들기 (5분)

1
2
3
4
- [ ] 1. 유용한 검색 쿼리 작성 (예: is:open assignee:@me)
- [ ] 2. 검색 후 URL 복사
- [ ] 3. 브라우저 북마크에 "내 작업" 이름으로 저장
- [ ] 4. 북마크 클릭하여 바로 접근되는지 확인

⚡ 실습 3: 대량 작업 수행 (10분)

1
2
3
4
5
- [ ] 1. 여러 개의 테스트 Issue 생성 (5개 정도)
- [ ] 2. Issue 목록에서 체크박스로 3개 선택
- [ ] 3. 상단 메뉴에서 "Label" 클릭
- [ ] 4. 공통 라벨 추가 (예: "test")
- [ ] 5. 다시 선택하여 일괄 닫기 실행

실습 완료 후: 이제 Issue 관리가 훨씬 효율적으로 느껴지실 겁니다!


😰 어려우시다면

이 내용이 어렵게 느껴진다면:

  1. 검색 쿼리가 복잡하다면
    • 처음엔 is:open, is:closed만 사용하세요
    • 익숙해지면 조건을 하나씩 추가해보세요
    • GitHub 검색창에 치트시트가 표시됩니다
  2. 대량 작업이 두렵다면
    • 먼저 테스트 Issue로 연습하세요
    • 중요한 Issue는 하나씩 처리하세요
    • 실수해도 되돌릴 수 있으니 걱정하지 마세요
  3. 복습이 필요하다면
    • Day 71: Issue 기본 다시 보기
    • GitHub 공식 문서의 검색 가이드 참고
  4. 실전 활용이 막막하다면
    • 작은 프로젝트로 시작하세요
    • 매일 아침 “내 작업” 필터로 하루 시작
    • 팀원과 함께 연습하면 더 빨리 배웁니다

꼭 기억하세요: 검색 쿼리는 외울 필요 없습니다! 북마크하거나 메모해두고 필요할 때 사용하세요.


정리

완료 체크:

  • Issue 검색 쿼리를 작성할 수 있다
  • 자주 사용하는 필터를 저장했다
  • 대량 작업을 수행할 수 있다
  • 우선순위 시스템을 이해했다
  • 트리아지 프로세스를 안다
  • 직접 실습을 완료했다

핵심 요약:

  • 검색: 강력한 쿼리 언어로 빠른 필터링
  • 저장: 자주 쓰는 필터 북마크
  • 대량 작업: 효율적인 일괄 처리
  • 자동화: 커밋으로 Issue 자동 닫기
  • 트리아지: 체계적인 Issue 분류

실전 팁:

  • ✅ 매일 아침 내 Issue 검토 (assignee:@me)
  • ✅ 주간 회의 전 마일스톤 진행률 확인
  • ✅ 긴급 버그는 즉시 priority:critical 라벨
  • ✅ 중복 Issue는 duplicate 라벨 후 원본 링크

다음: Day 73 - Issues 고급


이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.