Jira는 20명 기준 연 1,956달러다. GitHub는 960달러. 절반 가격인데도 대부분 팀은 GitHub에 코드만 올리고 일정은 따로 관리한다. 코드 옆에서 이슈와 일정을 같이 보는 것만으로 생산성이 갑절이 된다면, 그게 지금 당장 해볼 만한 일 아닐까.

이슈 하나가 작업 하나가 되는 구조

GitHub에서 프로젝트 관리의 출발점은 이슈다. 2025년 4월, 오랫동안 베타에 머물던 Sub-Issues 기능이 정식 출시되었다. 핵심은 계층이다. 부모 이슈 하나에 최대 50개의 하위 이슈를 붙일 수 있고, 8단계까지 중첩이 가능하다. 별도 레포지토리의 이슈도 크로스 레퍼런스로 연결된다. 부모 이슈에는 하위 이슈의 진행률이 자동으로 계산되어 표시된다.

기존에는 마크다운 체크리스트로 비슷한 흐름을 흉내 냈지만, Sub-Issues는 각 하위 항목이 독립된 이슈로 존재하면서도 계층 정보를 가진다는 점이 다르다. 담당자를 따로 배정할 수 있고, 라벨과 마일스톤도 독립적으로 붙일 수 있다. 기능 하나를 개발할 때 프론트엔드 작업과 백엔드 작업을 별도 이슈로 쪼개고 하나의 Epic 이슈 아래 묶으면, 누가 무엇을 하고 있는지 실시간으로 보인다.

마일스톤을 붙이면 진행률 바가 따라온다. 마감일이 지났는데 완료율이 30%라면 주황색 경고가 뜬다. 실무 패턴은 단순하다. 마일스톤으로 시간축을 잡고, Epic 이슈로 범위를 정하고, 라벨로 작업 종류를 구분한다. 이슈 본문에 "왜 이 작업을 하는가"를 적는 습관만 있으면 3개월 뒤 온보딩한 사람도 이슈 검색만으로 모든 의사결정 맥락을 복원할 수 있다.

Projects 보드 — 코드와 계획이 같은 그래프 위에

2022년 대대적으로 개편된 GitHub Projects는 단순 칸반을 넘어섰다. 테이블 뷰, 로드맵 뷰, 타임라인 뷰를 모두 제공하면서도 근본이 다르다. 이슈와 PR이 같은 데이터 그래프 위에 존재한다는 점이다. 별도 통합 설정 없이도 PR 설명에 "Closes #123"이라고 적으면 머지 시점에 이슈가 자동으로 닫히고, Projects 보드의 카드도 Done으로 이동한다.

기본 제공 워크플로를 켜두면 새 이슈가 생성되는 즉시 프로젝트에 자동 추가된다. 닫힌 이슈는 사람 손을 거치지 않고 완료 열로 이동한다. Jira에서 보드를 수동으로 갱신하던 팀이 GitHub Projects로 옮기면 이 한 가지 차이만으로도 회의 시간이 줄어든다.

Iteration 필드를 활용하면 스프린트 단위로 작업을 그룹화할 수 있다. 지난 스프린트의 완료된 작업량을 기준으로 다음 계획을 세우는 것이 합리적인데, GitHub는 이 데이터를 자동으로 누적해준다. 2025년 강화된 Insights 기능은 병목 구간이 어디인지, 누가 과부하 상태인지, 평균 리드타임이 얼마인지를 차트로 보여준다.

코드 리뷰와 작업 관리가 같은 화면에서 이뤄진다는 것의 의미는 작지 않다. 컨텍스트 스위칭이 사라진다. PR을 보다가 관련 이슈를 클릭하고, 이슈에서 다시 마일스톤 진행률을 확인하는 흐름이 탭 하나에서 끝난다.

자동화가 없애주는 것들

GitHub Actions와 GraphQL API를 조합하면 반복되는 관리 노동을 코드로 바꿀 수 있다. 대표적인 패턴 세 가지를 보자.

첫째, PR 검토 대기 자동 추적. 지정된 리뷰어가 24시간 이상 응답하지 않은 PR을 자동으로 감지해 슬랙 알림을 보내는 워크플로는 30줄 남짓한 YAML로 구현된다. 사람이 매일 아침 열린 PR 목록을 훑어보는 수고가 사라진다.

둘째, 라벨과 담당자 자동 할당. PR의 변경 파일 경로를 보고 프론트엔드면 프론트엔드 팀을, 인프라면 SRE 팀을 자동으로 리뷰어로 지정한다. 이슈 템플릿에서 선택한 옵션에 따라 라벨을 붙이는 것도 Actions 한 줄이면 끝난다.

셋째, AI 에이전트와의 결합. 2026년 Hacker News에는 GitHub 이슈를 읽고 자동으로 해결 코드를 PR로 올리는 AI 에이전트가 등장했다. 아직 실험 단계지만, 이슈를 구조화된 작업 단위로 만들어두면 미래에는 그 이슈 자체가 AI 에이전트의 입력값이 될 수 있다.

실제 사례도 나오고 있다. 한 개발자는 자신의 사이드 프로젝트 전체를 GitHub 이슈로만 관리하며, AI 코딩 에이전트에게 이슈를 할당해 앱을 완성했다. 그가 말하는 생산성의 핵심은 "일과 코드가 같은 곳에 있으면, 중간 관리가 사라진다"는 것이다.

비용 비교가 말해주는 것

20명 규모 팀 기준으로 연간 도구 비용을 비교해보자. Jira Standard는 사용자당 월 8.15달러로 20명이면 연 1,956달러다. GitHub Team은 사용자당 월 4달러, 연 960달러. 반값이다. Notion의 팀 플랜은 사용자당 월 10달러, Linear는 월 8달러. GitHub가 이 그룹에서 가장 저렴하다.

여기에 GitHub를 이미 코드 저장소로 사용 중이라면 추가 비용은 0원이다. 무료 티어에서도 Issues, Milestones, Labels, Projects의 기본 기능은 전부 열려 있다. Sub-Issues와 Insights 같은 고급 기능이 유료 플랜에 포함되는 구조지만, 20명 팀이 써도 월 80달러면 끝이다.

비용보다 더 큰 차이는 "도구를 배우는 비용"이다. Jira는 관리자가 워크플로를 설계하고, 사용자에게 교육하고, 커스터마이즈된 필드를 유지보수해야 한다. GitHub는 개발자가 이미 매일 열어보는 화면에서 시작한다. 별도 온보딩 없이 이슈 탭 하나로 프로젝트 관리가 시작된다는 점이 도입 장벽을 낮춘다.

시작은 작게, 증명은 데이터로

팀 전체를 한 번에 옮기려 들지 않는 것이 핵심이다. 먼저 다음 스프린트 하나만 GitHub Projects로 관리해보자. 2주 동안 이슈를 쪼개고, 마일스톤을 붙이고, 자동화 워크플로를 한두 개 붙여본다.

2주 뒤에 확인할 수 있는 지표는 세 가지다. 첫째, 상태 갱신 회의 시간이 줄었는가. 둘째, PR-to-merge 리드타임이 단축되었는가. 셋째, 팀원들이 작업 맥락을 찾기 위해 서로에게 묻는 DM 횟수가 줄었는가.

이 숫자들이 쌓이면 경영진을 설득할 근거가 된다. 도구를 바꾸는 일은 정치다. 데이터가 있어야 밀어붙일 수 있다. 다행히 GitHub는 무료 티어로도 이 실험을 충분히 돌릴 수 있고, 실패해도 잃는 것은 2주간의 이슈 정리 습관뿐이다.

생산성이 갑절이 되는 비결은 비싼 도구에 있지 않다. 코드를 쓰는 사람이 코드 옆에서 일을 보는 구조에 있다. 이미 GitHub를 열어놓고 있다면, 오늘 올릴 첫 번째 이슈부터 시작하는 거다.