Jira 없이 엔지니어링 지표 관리하기
Jira 없이도 중요한 것을 측정할 수 있습니다. Git, CI, 팀이 이미 사용하는 도구로 엔지니어링 건강성을 추적하는 방법을 소개합니다.
By Ellis Keane · 2026-03-23
최고의 엔지니어링 가시성을 확보한 소규모 팀은 대개 Jira가 추적하게 하는 지표를 쫓는 것을 그만둔 팀입니다.
이게 단순히 반론을 위한 반론처럼 들린다는 걸 압니다. 솔직히 말하면 조금 그럴 수도 있습니다. 하지만 저는 거의 3년 동안 스프린트 보드를 관리하고, 백로그를 정리하고, 그날 아침 누군가가 Jira를 열었을 때 이미 반쯤 끝나 있던 티켓의 예상치를 업데이트하는 일을 충실히 해왔습니다. 2주마다 (Zoom으로 – 2023년의 일입니다) 서로 대화하면서 이미 알고 있던 것을 그대로 말해주는 속도 차트를 들여다봤습니다. Jira 없는 엔지니어링 지표를 찾아나선 게 아닙니다. 속도 차트가 아무것도 알려주지 않는다는 걸 인정했을 때 자연스럽게 그렇게 됐습니다.
팀이 테이블 하나를 둘러앉을 수 있는 규모라면, Jira 없이도 상황을 파악할 수 있습니다. 이미 사용 중인 도구에서 더 나은 시그널이 필요할 뿐입니다.
이것은 "Jira는 나쁘다"는 글이 아닙니다. Jira는 Jira형 추적이 필요한 조직에 훌륭한 도구입니다(특정 규모에서는 진정으로 필요합니다). 하지만 10~40명 규모 스타트업의 엔지니어링 매니저가 속도 차트를 만들기 위해서만 Jira에 비용을 지불하고 있다면, 그것은 점심을 데우기 위해 업소용 오븐을 사는 것과 다를 바 없습니다.
"속도 차트를 만들기 위해서만 Jira에 비용을 지불하는 것은 점심을 데우기 위해 업소용 오븐을 사는 것과 같습니다." – Chris Calo
Jira 지표가 실제로 측정하는 것
직접적으로 말하겠습니다. 대부분의 Jira 지표는 엔지니어링 성과가 아니라 Jira 사용량을 측정합니다. 스토리 포인트는 팀의 스토리 포인트 추정 능력을 측정합니다. 속도는 팀이 스프린트를 비슷한 용량으로 일관되게 채우는지를 측정합니다. 번다운 차트는 목요일 오후에 누군가가 티켓을 보드에서 끌어다 놓았는지를 측정합니다.
이것들이 전혀 쓸모없다는 건 아닙니다. 하지만 이것들은 개발자 생산성 지표로 위장한 프로세스 지표이며, 그 간극이 바로 엔지니어링 매니저가 본질을 놓치는 지점입니다.
저는 이해관계자 미팅 전에 거의 한 시간을 Jira 데이터를 "우리는 순조롭게 진행 중입니다"라는 슬라이드 덱으로 만드는 데 쓴 EM이었습니다. 이해관계자는 고개를 끄덕이고, 지난 화요일의 로그인 버그에 대해 한 가지를 묻고 미팅은 끝납니다. 그 한 시간은 슬라이드 덱을 위한 것이었습니다. 실제 답은 "엔지니어에게 물어보세요"였습니다.
지표가 측정하는 작업보다 유지 관리에 더 많은 시간이 걸린다면, 지표가 문제입니다.
티켓 보드가 아닌 Git에서의 사이클 타임
소규모 제품 팀에게 사이클 타임은 일반적으로 추적할 수 있는 가장 높은 시그널의 지표입니다. 첫 번째 커밋부터 프로덕션 배포까지의 기간을 측정하며, Git 히스토리와 CI 파이프라인에서만 도출할 수 있습니다. 티켓 보드는 필요 없습니다.
구성 요소:
- 브랜치 또는 PR의 첫 번째 커밋 타임스탬프
- PR 병합 타임스탬프
- 배포 타임스탬프 (CI/CD에서 – GitHub Actions, CircleCI, 사용 중인 것)
1과 3의 차이가 사이클 타임입니다. 코딩 시간(1에서 PR 오픈까지), 리뷰 시간(PR 오픈에서 병합까지), 배포 큐(병합에서 프로덕션까지)로 분할하면 작업이 실제로 어디서 막히는지 보여주는 진단 도구가 됩니다.
팀에서 처음 이 작업을 했을 때 숫자는 정말 놀라웠습니다. 리뷰 시간이 병목이라고 생각했습니다(모두가 리뷰 시간이 병목이라고 생각하죠?). 실제로는 코딩에서 PR 단계는 괜찮았고, 리뷰도 괜찮았으며, 스테이징 환경이 불안정하고 아무도 수정을 우선순위에 두지 않아서 병합에서 배포 사이에 평균 2일을 잃고 있었습니다. 속도 차트로는 절대 이것을 발견하지 못했을 것입니다.
측정 방법
GitHub를 사용한다면 CLI로 가져올 수 있습니다:
```bash
지난 30일간 병합된 PR 가져오기
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
배포 타임스탬프의 경우 대부분의 CI 시스템이 API나 웹훅을 통해 이를 노출합니다. PR 병합 SHA를 배포 이벤트에 매핑하면 단계별로 분할된 사이클 타임을 얻을 수 있습니다.
팁: CI가 배포 타임스탬프를 명확하게 노출하지 않는다면, 가장 간단한 접근법은 커밋 SHA와 함께 #deploys 채널에 게시하는 Slack 봇입니다. 타임스탬프, 사람이 읽을 수 있는 로그, 그리고 부수적으로 얼마나 자주 출시하는지 알려주는 채널이 생깁니다.
코드 리뷰 처리량
리뷰 처리량(엔지니어당 주간 리뷰 PR 수와 PR 오픈에서 첫 번째 리뷰까지의 중앙값 시간)은 어떤 스프린트 지표보다 팀 건강성에 대해 더 많은 것을 알려줍니다. 과소평가되어 있습니다.
왜 그럴까요? 리뷰 행동은 선행 지표이기 때문입니다. 리뷰 시간이 늘어나면 보통 엔지니어들이 과부하 상태이거나, 컨텍스트 스위칭이 너무 많거나, (이것이 불편한 부분이지만) 서로의 코드를 피하고 있다는 뜻입니다. 이 중 어느 것이든 2주 후 마감 기한 놓침으로 나타나기 전에 알아야 할 가치가 있습니다.
GitHub는 API를 통해 이 데이터를 제공합니다. 주요 필드는 PR의 createdAt와 첫 번째 리뷰 이벤트의 submittedAt입니다.
제가 주시하는 숫자는 첫 번째 리뷰까지의 중앙값 시간(시간 단위)입니다. 몇 개의 소규모 팀 경험으로 보면 건강한 리뷰 주기는 8시간 미만인 경향이 있습니다. 지속적으로 하루를 넘기면 구조적인 무언가가 바뀐 것입니다. 그게 무엇이든 Jira에서는 보이지 않습니다.
미팅 대 의사결정 비율
이것은 전통적인 엔지니어링 지표가 아니며, KPI가 아니라 대략적인 경험적 지식입니다. 하지만 소규모 팀에서는 놀라울 정도로 시사적임을 발견했습니다.
이번 주 팀이 가진 미팅 수를 세어보세요. 거기서 나온 구체적인 결정의 수를 세어보세요("X를 조사해야 한다"가 아니라 담당자와 다음 단계가 있는 실제 결정). 후자를 전자로 나눕니다.
미팅의 절반 미만이 결정을 낳았다면 그 미팅들이 시간을 정당화하는지 물어볼 가치가 있습니다. 일부 미팅은 위험을 줄이거나 컨텍스트를 공유하기 위해 존재하며, 그것도 타당합니다. 모든 것이 결의로 끝날 필요는 없습니다. 하지만 비공식적으로라도 이를 추적하기 시작하면(저는 문자 그대로 노트에 집계했습니다) 어떤 미팅이 생산적이고 어떤 것이 아무도 의문을 품지 않는 의식인지 감이 생깁니다.
약 한 달간 이것을 추적하자 어떤 생산성 글보다 더 많이 미팅 일정을 잡는 방식이 바뀌었습니다. 월요일 스탠드업이 3주 연속 결정을 전혀 내지 못했다는 것을 볼 수 있을 때, 취소하는 것이 급진적으로 느껴지지 않게 됩니다.
Jira 없이 엔지니어링 지표 구축하기: 경량 대시보드
BI 도구가 필요 없습니다. Notion 페이지, Google 스프레드시트, 또는 4가지 숫자가 담긴 주간 Slack 게시물이면 충분합니다:
- 중앙값 사이클 타임 (Git/CI에서) – 더 빠르게 출시하고 있나요, 느리게 출시하고 있나요?
- 첫 번째 리뷰까지의 중앙값 시간 (GitHub에서) – 팀이 신속하게 리뷰하고 있나요?
- 배포 빈도 (CI 또는 #deploys 채널에서) – 얼마나 자주 출시하고 있나요?
- 미팅 대 의사결정 비율 (수동 집계) – 미팅이 제 역할을 하고 있나요?
네 가지 숫자, 이미 가진 도구에서 도출 가능하며, Jira 보드 유지 관리가 필요 없습니다. 매주 업데이트하세요. 숫자가 2주 연속으로 잘못된 방향으로 움직이면 조사하세요. 안정적이면 그냥 두세요.
목표는 감시 시스템을 구축하는 게 아닙니다(하지 마세요 – 엔지니어들이 싫어할 것이고, 그들이 옳습니다). 엔지니어링 팀의 가시성은 작업 자체에서 나와야지, 사람들에게 작업에 대해 보고하도록 요청하는 것에서 나와서는 안 됩니다.
최고의 엔지니어링 지표는 수집 비용이 낮고, 조작하기 어려우며, 행동으로 이어질 수 있는 것입니다. 스토리 포인트는 세 가지 모두에서 실패합니다.
티켓 보드가 실제로 필요한 경우
이것은 "Jira는 나쁘다"는 글이 아니라고 했고, 진심입니다. 프로젝트 관리 도구 없이 지표를 추적하는 것이 진정으로 무책임해지는 정당한 상황이 있습니다:
- 작업 상태에 대한 감사 추적이 법적으로 요구되는 컴플라이언스 요구가 강한 산업
- 비공식적인 조정으로는 불가능한 교차 팀 의존성이 있는 대규모 엔지니어링 조직
- 팀 전체에 걸친 단일 진실의 출처가 필요한 전담 프로젝트 관리 기능을 가진 조직
그런 상황이라면 Jira(또는 Linear, Shortcut)가 올바른 선택입니다. 제가 주장하는 것은 소규모 팀에게 지표만을 위해 무거운 도구를 유지 관리하는 것은 나쁜 거래라는 것입니다. 팀의 실제 작업이 아니라 도구의 작업 모델에 최적화하게 됩니다.
솔직히 말하면, Jira를 사용하는 팀조차도 보드 데이터를 위의 Git 기반 지표로 보완하면 이점을 얻을 것입니다. Jira는 사람들이 하고 있다고 말하는 것을 알려줍니다. Git은 실제로 하고 있는 것을 알려줍니다. 둘 다 유용하지만, 상태 업데이트 연극에 면역이 있는 것은 하나뿐입니다.
지표 문제가 스타트업에서 계속 제기된다면, 한 달 동안 4가지 숫자 대시보드를 시도해 보세요. Jira 없는 엔지니어링 지표는 안전망 없이 가는 것처럼 들릴 수 있습니다. 하지만 Git 히스토리와 CI 파이프라인에 얼마나 많은 시그널이 있는지 보고 나면, 티켓 보드가 무엇을 더해주고 있었는지 궁금해질 것입니다.
커스텀 스크립트나 Jira 보드 없이 사이클 타임, 지연된 PR, 리뷰 병목을 자동으로 파악하세요.
Q: 프로젝트 관리 도구 없이 의미 있는 엔지니어링 지표를 얻을 수 있나요? A: 네. 사이클 타임(첫 번째 커밋에서 배포까지), 리뷰 처리량, 배포 빈도는 모두 Git 히스토리와 CI 파이프라인에 있습니다. 엔지니어 40명 미만의 팀에서는 티켓 보드가 생성하는 것보다 더 날카롭고 조작하기 어려운 경향이 있으며, 정확성을 유지하기 위해 카드를 보드에서 끌어다 놓을 필요도 없습니다.
Q: Sugarbug는 엔지니어링 지표를 자동으로 보여주나요? A: Sugarbug는 GitHub, Linear, Slack, 캘린더에 연결해 팀 활동의 지식 그래프를 구축합니다. 지연된 PR, 리뷰 병목, 해결되지 않은 결정 등의 패턴을 플래그합니다. GitHub API에 대한 커스텀 스크립트를 작성하고 유지 관리할 필요 없이 여기서 설명한 많은 시그널을 커버합니다.
Q: Jira 지표 사용을 중단하는 데 동의를 얻으려면 어떻게 해야 하나요? A: 반란이 아닌 실험으로 제안하세요. 기존 Jira 대시보드와 함께 Git 기반 지표를 4주 동안 추적하고, 어떤 숫자가 실제 변화를 이끌었는지 비교하세요. Git 지표가 더 실행 가능하다면(경험상 그런 경향이 있습니다), 주장은 스스로 만들어집니다.
Q: 프로세스 지표와 성능 지표의 차이는 무엇인가요? A: 프로세스 지표(스토리 포인트, 속도, 번다운)는 팀이 워크플로를 얼마나 일관되게 따르는지 측정합니다. 성능 지표(사이클 타임, 배포 빈도, 리뷰 처리량)는 팀이 실제로 무엇을 얼마나 빠르게 출시하는지 측정합니다. 소규모 팀은 거의 항상 후자에서 더 많은 시그널을 얻습니다. 성능 지표는 수동 상태 업데이트가 아닌 작업 자체에서 도출되기 때문입니다.