📊 TeamScope — Jira·GitLab 데이터를 점수화해 팀 관리를 정량적으로 관리하는 리더 대시보드 설계기

📅 글 개요

팀 리더에게 가장 어려운 일 중 하나는, 팀 상태를 항상 정확하게 읽는 것입니다.

누가 바쁜지, 누가 일정 리스크를 안고 있는지, 누가 코드 품질에 크게 기여하고 있는지, 누가 도움이 필요한지. 이런 정보는 보통 회의, 감각, 기억, 메신저 대화에 흩어져 있습니다.

문제는 이렇게 흩어진 신호만으로 팀을 운영하면, 병목을 발견하는 시점이 늦어지고 대응도 늘 뒤따라간다는 점입니다.

그래서 저는 팀 운영을 감이 아니라 데이터 기반 관리 체계로 바꾸고 싶었습니다.

• Jira API로는 개인별 티켓 진행 상황, 일정, Gantt, 워크로그, 공수 데이터를 수집하고
• GitLab API로는 MR, 리뷰 코멘트, 피드백 반영률, 리드타임, CI 통과율 같은 코드 품질 지표를 모으고
• Plasma DB에서 이를 정규화한 뒤
• 리더가 한 화면에서 바로 해석할 수 있는 점수와 대시보드로 변환했습니다

핵심 메시지

이 글의 목적은 "예쁜 대시보드"를 소개하는 것이 아니라,
팀 리더가 Jira + GitLab + Plasma DB 기반으로 팀 운영을 정량화하는 방법을 설명하는 것입니다.

💡 이 글에서 다룰 내용

• 왜 팀 관리에 정량화 체계가 필요한가
• Jira API, GitLab API, Plasma DB를 연결한 데이터 파이프라인 설계
• Jira 수행 점수와 GitLab 코드 품질 점수 산식
• 리더가 병목과 지원 포인트를 빠르게 찾게 만드는 화면 구성
• 점수를 감시가 아닌 코칭 도구로 사용하기 위한 설계 원칙

🧩 왜 팀 관리에 정량화 체계가 필요했는가

팀 운영에서 진짜 어려운 지점은 "일이 많다"가 아니라 상태를 명확히 설명하기 어렵다는 데 있습니다.

• 어떤 팀원은 티켓 처리량은 높지만 리뷰 참여가 낮을 수 있습니다.
• 어떤 팀원은 MR 품질은 좋지만 일정 준수율이 불안정할 수 있습니다.
• 어떤 팀원은 공수 예측이 자주 빗나가지만, 사실은 과도한 업무를 떠안고 있을 수도 있습니다.

이런 상황을 단순히 "잘하고 있다 / 아쉽다" 수준으로 보면 리더의 대응도 모호해집니다.

그래서 필요한 것은 활동 로그를 많이 모으는 것이 아니라, 업무 수행력 + 협업 기여도 + 코드 품질 + 일정 안정성을 같은 관점에서 읽을 수 있게 만드는 일입니다.

정량화가 필요한 이유

리더는 "누가 잘하고 있는가?"보다
"어디에 병목이 있고, 누구에게 어떤 지원이 필요한가?" 를 더 빨리 알아야 합니다.

저는 이 문제를 풀기 위해 다음 기준을 세웠습니다.

1. 리더가 팀 전체 상태를 10초 안에 파악할 수 있어야 한다.
2. 팀 전체에서 개인 단위 코칭 포인트로 자연스럽게 drill-down 되어야 한다.
3. 일정/공수/Jira 지표와 MR/리뷰/GitLab 지표가 분리되지 않고 함께 해석되어야 한다.
4. 점수는 줄세우기가 아니라, 병목 조기 발견과 지원 우선순위 결정을 돕는 보조 지표여야 한다.

🏗️ 이 대시보드를 설계한 방법

리더가 보고 싶은 것은 단순 로그가 아니라 "지금 이 팀이 안정적으로 일하고 있는가?" 에 대한 압축된 답입니다.

그래서 데이터 수집부터 시각화까지의 구조를 아래처럼 나눴습니다.

계층	역할	리더가 얻는 가치
Jira API 수집 계층	티켓, 일정, Gantt, 워크로그, 공수 데이터 수집	"일이 계획대로 진행되고 있는가?"를 판단
GitLab API 수집 계층	MR, 코멘트, 리뷰 참여, 리드타임, CI 데이터 수집	"코드와 협업이 건강하게 돌아가고 있는가?"를 판단
Plasma DB 통합 계층	개발자/프로젝트/기간 기준 정규화 및 재집계	서로 다른 원천 데이터를 같은 기준으로 비교 가능
Scoring Engine	복잡한 로그를 점수, 등급, 추세로 변환	리더가 빠르게 해석 가능한 형태로 요약
Dashboard UI	필터링, drill-down, 화면별 비교/탐색	병목 발견, 코칭 포인트 식별, 인력 운영 의사결정 지원

핵심은 각 시스템의 역할을 명확히 나눈 것입니다.

• Jira는 "일을 얼마나 계획대로 수행했는가"
• GitLab은 "코드를 얼마나 건강하게 만들고 협업했는가"
• Plasma DB는 둘을 개인/프로젝트/기간 단위로 이어붙이는 허브
• Scoring Engine은 리더가 빠르게 읽을 수 있도록 복잡도를 줄이는 해석 계층
• Dashboard는 최종적으로 리더의 의사결정을 빠르게 돕는 인터페이스

설계 포인트 한 줄 요약

대시보드는 화면부터 만든 것이 아니라,
데이터 수집 계층 → 통합 저장 계층 → 점수화 계층 → 해석 UI 계층 순서로 설계했습니다.

이 구조를 잡아두면 데이터 소스가 늘어나더라도 전체 체계가 흔들리지 않습니다.

결국 대시보드는 UI가 아니라, 운영 모델을 시각화한 결과물이 됩니다.

🔌 Jira API로 수집한 데이터와 리더십 활용 방식

Jira 쪽에서는 "업무 수행 관점" 의 데이터를 수집했습니다.

여기서 중요한 것은 단순히 이슈 개수를 세는 것이 아니라, 일정을 계획대로 끌고 가고 있는지, 공수 예측이 현실적인지, 업무 기록이 투명하게 남는지까지 함께 보는 것입니다.

Jira API 기준으로는 아래 데이터를 핵심 지표로 삼았습니다.

지표	의미	리더십 활용 포인트
개인별 티켓 수	맡은 업무량	특정 인원에게 업무가 쏠리는지 확인
티켓 완료율	할당 대비 완료 비율	일정 소화력과 실행력 확인
Gantt 기준 일정 준수율	기준선 대비 완료 상태	일정 지연 위험 조기 감지
계획 공수 vs 실제 공수	예측 정확도	과소/과대 추정, 구조적 병목 파악
워크로그 성실도	기록 빈도와 일관성	작업 투명성과 협업 신뢰도 확인

이 데이터는 리더에게 아래 질문에 답할 수 있게 해줍니다.

• 누가 지금 과부하 상태인가?
• 일정이 밀리는 원인이 실행력 부족인지, 할당 자체가 무리였는지?
• 특정 업무가 계속 공수 예측을 벗어나는 구조적 이유가 있는지?
• 기록이 비어 있어 실제 진행 상태를 리더가 오해하고 있지는 않은지?

Jira 데이터가 주는 리더십 인사이트

"누가 바쁜가?"보다
"왜 일정이 흔들리는가?" 를 설명할 수 있어야 관리가 쉬워집니다.

예를 들어 일정 준수율과 공수 정확도가 동시에 낮다면, 그건 단순한 개인 문제보다 업무 쪼개기 방식이나 우선순위 배분 구조를 다시 봐야 한다는 신호일 수 있습니다.

저는 이 지점을 리더가 빠르게 발견할 수 있도록 Gantt와 공수 상태를 한 화면에 묶었습니다.

💬 GitLab API로 수집한 데이터와 코드 품질 평가 방식

Jira가 "일의 진행"을 보여준다면, GitLab은 "협업과 코드 품질"을 보여줍니다.

실제 팀 운영에서는 티켓이 많이 끝났다고 해서 항상 건강한 상태는 아닙니다.

리뷰에 잘 참여하지 않거나, 피드백을 반영하지 않거나, 머지 리드타임이 과도하게 길다면 생산성이 높아 보여도 팀 전체 효율은 오히려 떨어질 수 있습니다.

GitLab API 기준으로는 아래 항목을 핵심적으로 반영했습니다.

지표	의미	리더십 활용 포인트
MR 생성성	기간 내 머지된 MR 수	산출물 속도 확인
리뷰 참여도	타인 MR에 남긴 코멘트 수	팀 기여도와 협업 밀도 확인
피드백 반영률	받은 코멘트 중 해결 비율	수용성과 개선 속도 확인
MR 리드타임	생성부터 머지까지 걸린 시간	병목, 대기, 커뮤니케이션 지연 확인
CI/CD 통과율	파이프라인 성공 비율	안정성, 배포 건강도 판단

여기서 중요한 것은 MR 수 자체보다 지표 간의 관계를 함께 보는 것입니다.

• MR 생성성은 높은데 피드백 반영률이 낮다면, 속도는 나지만 품질 리스크가 있다는 뜻일 수 있습니다.
• 리뷰 참여도는 낮은데 자신의 MR만 빠르게 머지된다면, 팀 협업의 균형이 깨질 수 있습니다.
• CI 통과율이 반복적으로 낮다면 개인 이슈가 아니라 테스트/배포 파이프라인 자체를 재정비해야 할 수도 있습니다.

GitLab 데이터가 주는 리더십 인사이트

"누가 많이 만들었는가?"보다
"팀의 코드 협업 구조가 건강한가?" 를 읽는 데 더 큰 의미가 있습니다.

즉 GitLab 데이터는 사람을 평가하기보다, 팀의 코드 협업 구조가 건강한지를 읽게 해주는 신호로 보는 것이 맞습니다.

🗃️ Plasma DB를 중심으로 데이터를 체계화한 이유

Jira와 GitLab의 원천 데이터는 구조도 다르고 시간축도 다릅니다.

그대로 붙여서는 비교가 되지 않습니다.

• Jira는 이슈, 상태 전이, 예정일, 워크로그처럼 "업무 관리" 중심 구조
• GitLab은 MR, 커밋, 코멘트, 파이프라인처럼 "코드 변경" 중심 구조

그래서 중간에 Plasma DB 같은 통합 저장 계층이 반드시 필요합니다.

이 계층은 단순 저장소가 아니라, 리더가 해석 가능한 단위로 데이터를 재정렬하는 허브입니다.

제가 잡은 기본 기준은 아래와 같습니다.

1. 개발자 기준 정규화 Jira 사용자명, GitLab 사용자명, 내부 멤버 정보를 하나의 팀원 엔티티로 매핑합니다.
2. 프로젝트 기준 정규화 여러 Jira/GitLab 프로젝트를 같은 팀의 운영 단위로 묶어 필터링할 수 있게 합니다.
3. 기간 기준 재집계 월별, 분기별, 연도별, 커스텀 범위로 같은 데이터셋을 재해석할 수 있게 만듭니다.
4. 점수 계산용 집계 레이어 원천 이벤트 로그를 그대로 보여주는 대신, 점수 산식에 필요한 형태로 미리 집계합니다.

이렇게 되면 리더는 필터만 바꿔도 아래와 같은 질문에 바로 답할 수 있습니다.

• 이번 달 팀 전체 상태는 어떤가?
• 특정 프로젝트만 보면 누가 병목인가?
• 한 명의 개발자를 월별로 보면 어떤 지표가 꾸준히 흔들리는가?

Plasma DB의 역할

데이터를 저장하는 것이 목적이 아니라,
리더가 해석할 수 있는 단위로 다시 묶는 것이 핵심입니다.

즉 Plasma DB는 "데이터를 모아두는 곳"이 아니라, 리더가 생각하는 단위로 데이터를 재구성하는 운영용 해석 계층입니다.

📐 점수화 모델 설계

점수화는 이 대시보드의 핵심이지만, 가장 조심해서 설계해야 하는 부분이기도 합니다.

점수가 잘못 설계되면 팀원을 단순 줄세우기 하는 시스템처럼 보이기 쉽기 때문입니다.

제가 둔 원칙은 명확합니다.

점수는 평가를 위한 평가가 아니라, 병목 조기 발견과 코칭 대화의 시작점이어야 한다.

점수 구조는 크게 두 축입니다.

• Jira 점수: 일을 계획대로 수행하고 있는가
• GitLab 점수: 코드를 건강하게 만들고 협업하고 있는가

1. Jira 업무 수행 점수

항목	배점	해석 포인트
티켓 완료율	25점	맡은 업무를 실제로 소화하고 있는가
일정 준수율	25점	계획 대비 일정 안정성이 있는가
공수 정확도	25점	예측이 현실적인가
작업일지 성실도	25점	진행 상태가 투명하게 공유되는가

2. GitLab 코드 품질 점수

항목	배점	해석 포인트
MR 생산성	20점	산출물이 꾸준한가
코드 리뷰 참여도	25점	타인을 돕고 팀 품질에 기여하는가
피드백 반영률	20점	피드백을 수용하고 개선하는가
MR 리드타임	20점	변경 흐름이 지체되지 않는가
CI 통과율	15점	안정적으로 변경을 마무리하는가

3. 종합 점수

종합 점수 = (Jira 점수 x 50%) + (GitLab 점수 x 50%)

여기서 중요한 것은 가중치를 고정하지 않았다는 점입니다.

팀 상황에 따라 Jira 50 / GitLab 50이 최선이 아닐 수 있습니다.

• 신규 프로젝트 초기: 일정 준수보다 실행 속도를 더 볼 수 있음
• 품질 안정화 단계: GitLab 리뷰/CI 비중을 더 높일 수 있음
• 운영 안정화 팀: 공수 정확도와 리드타임을 더 중요하게 볼 수 있음

점수화 철학

점수는 사람을 줄세우기 위한 결과표가 아니라,
병목을 발견하고 코칭 우선순위를 잡기 위한 운영 보조 지표여야 합니다.

그래서 가중치를 설정 화면에서 직접 조정할 수 있도록 설계했습니다.

리더마다, 조직마다, 시기마다 중요도가 달라지기 때문입니다.

📊 대시보드 화면으로 어떻게 관리가 쉬워졌는가

점수 모델이 있어도, 리더가 읽기 어렵다면 의미가 없습니다.

그래서 화면은 "팀 전체를 본 뒤, 필요한 개인을 깊게 보는 구조" 에 맞춰 설계했습니다.

메인 팀 대시보드

메인 화면에서는 아래 질문에 먼저 답합니다.

• 이번 기간의 팀 평균 점수는 어떤가?
• Jira와 GitLab 중 어느 축이 상대적으로 약한가?
• 특정 팀원 혹은 프로젝트를 선택했을 때 추세가 어떻게 달라지는가?

메인 대시보드의 역할

리더가 회의 전에 10초 안에
"지금 팀 상태가 어떤가?" 를 읽게 만드는 화면입니다.

필터와 KPI 카드, 팀 점수 추세, 레이더 차트를 한 자리에 모아둔 이유는 리더가 회의 전에 팀 상태를 빠르게 읽도록 돕기 위해서입니다.

개발자 상세 Drill-down

팀 전체 지표에서 이상 신호가 보이면, 바로 개인 상세 화면으로 내려갑니다.

여기서는 단순 총점이 아니라 어떤 항목이 흔들리는지가 중요합니다.

• 일정은 괜찮은데 리뷰 참여가 낮은지
• 생산성은 높은데 피드백 반영률이 낮은지
• 티켓 완료율은 높지만 공수 정확도가 낮은지

개발자 상세 화면의 역할

총점을 보는 화면이 아니라,
코칭 포인트를 구체화하는 화면이어야 합니다.

이렇게 봐야 리더가 "성과가 낮다"가 아니라 "어떤 지원이 필요한가" 로 대화를 바꿀 수 있습니다.

티켓, MR, 공수 분석, 설정 화면

이 보조 화면들은 "왜 이 점수가 나왔는가?" 를 설명하는 근거 역할을 합니다.

점수 카드만 있으면 리더는 해석하기 어렵지만, 원천 데이터와 분석 화면이 함께 있으면 설명 가능한 관리 체계가 됩니다.

👤 리더가 이 화면으로 할 수 있는 의사결정

이 대시보드의 목적은 리더가 더 많은 숫자를 보는 것이 아닙니다.

더 빨리, 더 정확하게, 더 부드럽게 의사결정하도록 만드는 것입니다.

예를 들면 이런 판단이 가능합니다.

• 과부하 식별: 일정 준수율과 공수 정확도가 동시에 흔들리는 팀원을 찾아 업무 재배치
• 협업 개선: 생산성은 높지만 리뷰 참여도가 낮은 팀원을 발견해 팀 기여 방식 조정
• 품질 리스크 감지: MR 수는 많지만 피드백 반영률과 CI 통과율이 낮은 흐름 조기 발견
• 코칭 포인트 분리: 개인 역량 문제와 구조적 병목을 구분해 대응
• 우선순위 재설정: 특정 프로젝트만 필터링해 실제 리스크가 큰 영역부터 조치

리더가 얻게 되는 변화

"누가 문제인가?"를 찾는 것이 아니라,
"어디를 먼저 조정하면 팀이 더 좋아지는가?" 를 빠르게 판단하게 됩니다.

핵심은 리더가 누군가를 "낮은 점수의 사람"으로 보는 것이 아니라, "현재 어떤 지원과 조정이 필요한 사람" 으로 볼 수 있게 만드는 것입니다.

🎯 결국 이 대시보드가 만든 변화

이 대시보드를 만들고자 했던 이유는 명확했습니다.

리더가 매번 여러 시스템을 오가며 상태를 추측하지 않아도 되게 만들고 싶었습니다.

Jira API와 GitLab API에서 들어오는 원천 데이터를 Plasma DB에서 체계화하고, 그것을 점수화와 시각화로 변환하면 팀 운영은 훨씬 명확해집니다.

그리고 그 명확함은 단순 편의성 이상을 만듭니다.

• 병목을 더 빨리 발견하게 하고
• 지원이 필요한 팀원을 더 정확히 보게 하고
• 프로젝트별 리스크를 더 빨리 설명하게 하고
• 리더의 관리 부담을 훨씬 줄여줍니다

마지막 한 줄 정리

이 대시보드는 성과를 심판하는 시스템이 아니라,
리더가 더 쉽고 간편하게 팀을 관리하도록 돕는 운영 도구입니다.

결국 이 대시보드는 성과를 평가하는 판이 아니라, 리더가 더 쉽고 간편하게 팀을 관리하고, 더 좋은 대화를 시작하게 만드는 운영 도구로 설계되었습니다.

🔗 함께 보면 좋은 글

• 🤖 RAG 기반 AI 코드리뷰 에이전트 — 설계부터 자동화까지
• 🏗️ 프론트엔드 아키텍처 설계 - Turborepo를 활용한 모노레포 구축