Project Management Framework · Applied

이슈 308건이
하나의 로드맵이 되기까지

「프로젝트 관리 체계 정의서」의 개념(프로젝트 · 마일스톤 · 스프린트 · 부모/하위 이슈 · 배포)을 MAESTRO-BS 조직의 실제 운영 보드 — 2026 Development Roadmap — 에 그대로 대입한 사례 문서다. 모든 수치·이슈 번호·필드 구성은 2026-08-03 기준 실데이터이며, 08절에서 이전 판(2026-07-02) 대비 한 달의 변화를 추적한다.

Org Project #3 Issues 308 ▲95 Repos 7 Milestones 10 Sprint 1–4 (4 진행 중) Status 11단계 Fields 21
01

개요 · 대상 프로젝트

2026 Development Roadmap은 건설부문 IT 시스템의 연간 개발 계획을 담는 조직 레벨 GitHub Projects 보드다. 리포지토리 7개를 가로질러 이슈 308건을 하나의 보드에서 계획·추적한다 — 정의서의 "Org Project = 최상위 컨테이너" 개념 그대로다. 한 달 전 213건에서 95건이 늘었고, 증가분의 대부분(+94)은 BisFramework에서 나왔다.

연간 프로젝트 트랙 (7개)

보드 README에 선언된 프로젝트 축. 각 트랙은 Project 단일 선택 필드로 이슈에 태깅된다.

코드프로젝트기간
BIS건설 경영정보시스템M2 ~ M10
ETL데이터플랫폼M1 ~ M9
KPIKPI 관리시스템M3
AIXAI 기반 자동화M6 ~ M12
CST부서 컨설팅 (22개 부서)M2 ~ M12
DSB대시보드 v1→v2→v3→최종M1 ~ M12
SYS시스템 개발M1
분기 테마. 1Q 기반을 깔고 표준을 만든다 → 2Q 보이게 만들고 관리하기 시작한다 → 3Q 자동화와 AI를 얹는다 → 4Q 운영 안정화와 확장. 현재는 3Q — 실제로 AI 트랙(투자심의 AI 분석·파싱 자동화)이 개발 물량의 중심에 있다.
gantt2026 연간 프로젝트 트랙로드맵 개요
%%{init: {"gantt": {"useMaxWidth": false, "useWidth": 1120, "barHeight": 30, "barGap": 10, "topPadding": 70, "leftPadding": 120, "fontSize": 14, "sectionFontSize": 13}}}%%
gantt
  title 2026 연간 트랙 (README 선언 기준)
  dateFormat YYYY-MM-DD
  axisFormat %m월
  tickInterval 1month
  section SYS
  시스템 개발 (M1)              :2026-01-01, 2026-01-31
  section ETL
  데이터플랫폼 (M1~M9)          :2026-01-01, 2026-09-30
  section DSB
  대시보드 v1→최종 (M1~M12)     :2026-01-01, 2026-12-31
  section BIS
  건설 경영정보시스템 (M2~M10)  :2026-02-01, 2026-10-31
  section CST
  부서 컨설팅 (M2~M12)          :2026-02-01, 2026-12-31
  section KPI
  KPI 관리시스템 (M3)           :2026-03-01, 2026-03-31
  section AIX
  AI 자동화 (M6~M12)            :2026-06-01, 2026-12-31
          
02

계층 구조 대응

정의서의 개념 계층이 이 보드에서 어떤 실체로 존재하는지 1:1로 대응시킨 표. 개념은 같고, 인스턴스만 실제 데이터다.

계층 (개념)이 로드맵의 실제비고
최상위 · Org ProjectOrg Project #3 「2026 Development Roadmap」리포 7개 가로지름
대형 목표 · EpicProject 필드 (BIS·ETL·KPI·AIX·CST·DSB·SYS·SPRO)연간 트랙 축
릴리스 목표 · Milestone리포별 Milestone — 권한관리구축, 투자심의평가, 사업수지파싱 …도메인 기능 단위, 마감일 보유
반복 주기 · SprintSprint Iteration 필드 — Sprint 1~4, 각 14일2026-06-19 시작 · Sprint 4 진행 중
작업 단위 · Issue이슈 308건 (BisFramework 242 · hany-kpi 35 · 기타 31)
부모 이슈#354 사업수지 파싱 고도화 트랙 · #347 가이드라인 서버 전환 트랙네이티브 Sub-issues 진행률 표시
하위 이슈#354 아래 14건 · #347 아래 6건 (담당·상태 개별 보유)한 달 사이 본격 확산
리포지토리 분포. BisFramework 242 · hany-kpi 35 · ai-transform-system 12 · BIS-Docs 8 · HANY 6 · SPRO 4 · HANY-docs 1 — 조직 프로젝트 하나가 여러 리포의 이슈를 통합 추적하는 전형적인 구조. 7월 증가분 +95건 중 +94건이 BisFramework에 집중됐다.
03

구성 요소 · 실제 현황

마일스톤 (Milestone) — 진행률 실측

BisFramework 리포의 활성 마일스톤 10개 중 대표 5개. GitHub이 자동 계산하는 "닫힌 이슈 / 전체" 진행률이 그대로 릴리스 준비도 지표가 된다. 7월 말 마감일 일괄 재계획이 있었다 — 6개 마일스톤이 2026-08-07로 정렬됐다.

투자심의평가마감 2026-08-07 · 신규 트랙
5 / 19 issues closed · 26% — 이달 개발 화력 집중처 (In Dev 11건 + In Progress 2건)
권한관리구축 - 기능구현마감 2026-07-07 → 08-07 재설정
7 / 26 issues closed · 27% — 범위가 14→26건으로 확대 (ERP 정합 P1~P6 트랙 편입, #377~#381)
사업수지파싱마감 2026-08-07
10 / 19 issues closed · 53% — 부모이슈 #354 트랙으로 재편, Sprint 4 주력 배정
에너지/정책 모니터링마감 2026-08-07
7 / 10 issues closed · 70% — v2 상용화 잔여분
공내역 자동 분개마감 2026-06-30 경과 (30일+)
1 / 7 issues closed · 14% — 전월에도 경과 상태였고, 재계획 wave에서도 제외됨 (09절 참조)

스프린트 (Sprint) — Iteration 필드 실측

보드의 Sprint Iteration 필드는 14일 주기 4회로 설정돼 있다. 현재(2026-08-03)는 마지막으로 정의된 Sprint 4 진행 중이며, Sprint 5 이후는 아직 정의되지 않았다.

스프린트기간배정 이슈 (최종 실측)
Sprint 12026-06-19 ~ 07-02 (완료)42건
Sprint 22026-07-03 ~ 07-16 (완료)24건
Sprint 32026-07-17 ~ 07-30 (완료)14건
Sprint 42026-07-31 ~ 08-13 (진행 중)8건
배정 감소 추세. 42 → 24 → 14 → 8. 스프린트에 이슈를 싣는 습관이 회차를 거듭할수록 약해지고 있다. 반면 마일스톤·부모이슈 축은 강해졌다 — 팀의 실질 계획 단위가 "기간(스프린트)"에서 "목표(트랙)"로 이동하는 신호로 읽힌다 (09절 개선 후보).

부모 이슈 / 하위 이슈 — 네이티브 Sub-issues 확산

전월에는 권한관리 #214(하위 3건, 전부 완료)가 유일한 실사례였다. 한 달 사이 이 패턴이 대형 트랙의 표준 운영 방식으로 자리 잡았다:

부모 이슈트랙하위 이슈상태
#354사업수지 파싱 고도화 (P0 마감 · 표면화 · R02 · P1 보고서 연계)14건4 완료 · 10 진행
#347투자심의 가이드라인 서버 전환 (HR-3 S1~S7)6건1 완료 · 5 In Dev
#321투자심의 메인 영역 UI v2 프로토타입 정합3건3 In Dev
#214권한관리구축 Phase 1~33건3 완료

배포 버전 (Release) — 상태 필드로 대체

이 보드는 Git 태그 Release 대신 Status 필드 자체에 배포 단계를 인코딩했다. In Dev → In Staging → In Prod 3개 환경이 이슈 상태로 존재하므로, 이슈 하나의 위치만 봐도 "어느 환경까지 나갔는지"가 보인다. 여기에 이달 신설된 QA Review 필드(Defined / TCReady)가 "QA 준비도" 축을 추가했다. 상세는 07절.

04

실무 구조 (실데이터)

정의서 4절의 가상 트리("결제 시스템 개편")를 실제 보드 데이터로 치환한 구조. 이슈 번호·상태·스프린트 배정 모두 실측값이다. 전월 대비 부모이슈 계층이 한 단계 깊어졌다.

Org Project #3: 2026 Development Roadmap   (MAESTRO-BS · 이슈 308건)
│
├── Milestone: 투자심의평가  (BisFramework · 마감 2026-08-07 · 5/19 · 신규)
│   │
│   ├── 부모이슈 #347: 가이드라인 서버 전환 트랙 (HR-3 S1~S7)
│   │   ├── Sub-issue #309: 서버 조회·저장 전환 (S1)          ← In Dev
│   │   ├── Sub-issue #311: draft 활성화 승인 게이트 (S3)     ← In Dev
│   │   ├── Sub-issue #313: 업로드 파일 서버 검증 (S6)        ✓ Done
│   │   └── Sub-issue #314: AI Gateway 서버 프록시 (S7)       ← In Dev
│   │
│   ├── 부모이슈 #321: 메인 영역 UI v2 정합 (#344/#345/#346)  ← In Dev
│   ├── #383: AI 게이트웨이 상시 타임아웃                  ← In Progress · Sprint 4
│   └── #384: 대용량 파일 저장-UI 불일치 (평가 중복)       ← In Progress · Sprint 4
│
├── Milestone: 사업수지파싱  (마감 2026-08-07 · 10/19)
│   └── 부모이슈 #354: 파싱 고도화 트랙 (Sub-issue 14건 · 4 완료)
│       ├── Sub-issue #240: TS 파서 구현 (R01)                ✓ Done
│       ├── Sub-issue #371: 표시값·단위 반영                  ← Ready · Sprint 4
│       ├── Sub-issue #372/#373: 원본 미리보기 재현·열람성    ← Ready · Sprint 4
│       └── Sub-issue #382: pnl-catalog 매칭 연결             ← In Progress · Sprint 4
│
├── Milestone: 권한관리구축 - 기능구현  (마감 2026-08-07 재설정 · 7/26 · 범위 확대)
│   ├── 부모이슈 #214: Phase 1~3 (#213/#216/#218)         ✓ 전부 Done
│   ├── #260: Phase 7 — Menu Tree Management               ← In Dev
│   ├── #377: ERP 정합 P1~P6 트래커 (plan v2.0)            ← Ready
│   └── #378 ~ #381: P1 ~ P5 실행 이슈                     ← Plan / Ready
│
└── Sprint 4  (2026-07-31 ~ 2026-08-13 · 이슈 8건 배정 · 진행 중)
    ├── #371/#372/#373: 사업수지 표시·미리보기 3종         ← Ready · 사업수지파싱 소속
    ├── #383/#384: 투자심의 운영 결함 2종                  ← In Progress · 투자심의평가 소속
    └── #389: 사업 목록→상세 파이프라인 플래시             ← Backlog · 사업수지파싱 소속
두 축의 실증. 이슈 #371은 "사업수지파싱 마일스톤 소속(목표 축)"이면서 동시에 "Sprint 4에서 처리(기간 축)"다. 한 스프린트에 사업수지·투자심의 등 여러 마일스톤의 이슈가 섞여 있다 — 정의서가 말한 "마일스톤과 스프린트는 독립된 두 축"이 이번 달에도 실데이터로 확인된다. 여기에 부모이슈(트랙) → Sub-issue가 세 번째 계층으로 자리 잡아, 「마일스톤 = 도메인 릴리스 / 부모이슈 = 실행 트랙 / 하위이슈 = 작업 단위」의 3단 분해가 표준이 됐다.
05

Projects 필드 설계 · 사용률

보드에 정의된 커스텀 필드(총 21개)와, 이슈 308건 기준 실제 사용률. 정의서의 "권장 필드 설계"와 비교하면 어떤 필드가 살아 있고 어떤 필드가 유령인지 드러난다. 괄호는 전월(213건 기준) 대비 변화.

필드명타입값 (실제 등록값)사용률
StatusSingle selectBacklog / Plan / Ready / In Progress / In Review / In Dev / Ready for Staging / In Staging / Ready for deployment / In Prod / Done — 11단계100% 유지
Assignees네이티브담당자 지정97% (300건) 강세
ProjectSingle selectBIS / ETL / KPI / AIX / CST / DSB / SYS / SPRO — 실사용 BIS 103 · SPRO 3 · SYS 135% (107건) ▲5%p
SprintIterationSprint 1~4 (14일 주기 · Sprint 4 진행 중)29% (88건) ▲4%p
Milestone네이티브투자심의평가, 권한관리구축, 사업수지파싱 등 도메인 10개29% (90건) ▲5%p
Target dateDate목표일 지정20% (62건) 신규 사용
PrioritySingle selectHigh / Midium / Low16% (49건 · 전부 High) ▼5%p
QA ReviewSingle selectDefined / TCReady — 이달 신설15% (Defined 39 · TCReady 7)
Labels네이티브부서 라벨 축 — AX추진팀 26 · 건설최적화팀 24 · AI전환TF 19 · 건축견적팀 12 · 사업최적화팀 11 · QA 10 …35% (108건)
TeamSingle selectSquad 1 / Squad 2 / Squad 30% 유지
QuarterIteration1Q~4Q 주기 설정됨 (전월 미설정 → 90~92일 주기 정의)0% (설정만, 배정 없음)
Parent issue · Sub-issues progress네이티브#354(14건) · #347(6건) · #321(3건) · #214(3건)대형 트랙 표준화 확산
표기 참고. Priority 옵션 "Midium"은 보드에 실제 등록된 표기 그대로다(Medium 오타 — 전월 개선 후보였으나 미교정). 분류 축의 실질은 Project 필드가 아니라 부서 라벨(AX추진팀·건설최적화팀·AI전환TF …)에서 형성되고 있다 — "누가 요청했나"는 라벨이, "어느 시스템인가"는 마일스톤이 답하고, Project 필드는 그 사이에서 절반쯤 잠들어 있다.
06

워크플로우 · 다이어그램

이 보드의 Status는 일반적인 5단계가 아니라 배포 환경까지 포함한 11단계다. 아래 분포와 도식 모두 실측 기준이며, mermaid 블록은 이슈 본문·위키에 그대로 붙일 수 있다.

계획 62건 (20%) 개발 40건 (13%) 스테이징 검증 15건 (5%) 운영·완료 191건 (62%)
Backlog 20 Plan 34 Ready 8 In Progress 3 In Dev 37 In Staging 15 Ready for deployment 1 In Prod 8 Done 182

지금 개발은 어디에 몰려 있나 — 마일스톤 × 상태 교차 실측

개발 구간(In Progress + In Dev) 40건 중 26건이 3대 트랙에 집중돼 있다. "무엇을 만들고 있는 달인가"가 이 표 한 장으로 요약된다.

마일스톤 (보드 배정 기준)계획개발 중완료읽는 법
투자심의평가 (19)1135이달의 주전장 — 서버 전환 + AI 연동 + UI v2
권한관리구축 (24)1185ERP 정합 P1~P6로 재편, 계획·개발 병행
사업수지파싱 (19)4510절반 완료, Sprint 4 주력 배정
BS물가지수 (4)130착수 단계
에너지/정책 모니터링 (10)307수확기 — v2 잔여만 남음
공내역 2종 (9)7+211계획 적체 — 마감 경과 상태 지속
graph계층 구조 (실데이터)위키 문서화
graph TD
  P["Org Project #3 · 2026 Development Roadmap"]
  R1["BisFramework (242)"]
  R2["hany-kpi (35)"]
  R3["ai-transform-system (12)"]
  P --> R1 & R2 & R3
  R1 --> M1["Milestone: 투자심의평가"]
  R1 --> M2["Milestone: 사업수지파싱"]
  R1 --> M3["Milestone: 권한관리구축 - 기능구현"]
  M1 --> PI1["부모이슈 #347 (HR-3 S1~S7)"]
  PI1 --> S1["#309 In Dev"]
  PI1 --> S2["#313 ✓ Done"]
  PI1 --> S3["#314 In Dev"]
  M2 --> PI2["부모이슈 #354 (Sub 14건)"]
  PI2 --> S4["#240 ✓ Done"]
  PI2 --> S5["#371 Ready"]
          
stateDiagram이슈 워크플로우 — 11단계 Status 전체상태 전이 규칙
stateDiagram-v2
  direction LR
  state "Backlog" as BL
  state "Plan" as PL
  state "Ready" as RD
  state "In Progress" as IP
  state "In Review" as IR
  state "In Dev" as ID
  state "Ready for Staging" as RS
  state "In Staging" as IS
  state "Ready for deployment" as RP
  state "In Prod" as PR
  state "Done" as DN
  [*] --> BL
  BL --> PL: 기획 확정
  PL --> RD: 개발 배정
  RD --> IP: 개발 시작
  IP --> IR: PR 생성
  IR --> IP: 변경 요청
  IR --> ID: dev 머지
  ID --> RS: 스테이징 대기
  RS --> IS: 스테이징 배포
  IS --> ID: QA 이슈
  IS --> RP: QA 통과
  RP --> PR: 운영 배포
  PR --> DN: 운영 검증
  DN --> [*]
          
gantt스프린트 · 마일스톤 타임라인 (실측)로드맵
%%{init: {"gantt": {"useMaxWidth": false, "useWidth": 1000, "barHeight": 26, "barGap": 8, "topPadding": 60, "leftPadding": 110, "fontSize": 13, "sectionFontSize": 13}}}%%
gantt
  title 3Q 스프린트 · 마일스톤 마감 (2026)
  dateFormat YYYY-MM-DD
  axisFormat %m/%d
  section 스프린트
  Sprint 1 :done, s1, 2026-06-19, 14d
  Sprint 2 :done, s2, 2026-07-03, 14d
  Sprint 3 :done, s3, 2026-07-17, 14d
  Sprint 4 :active, s4, 2026-07-31, 14d
  section 마일스톤 마감
  공내역 자동 분개 (경과) :milestone, 2026-06-30, 0d
  일괄 재계획 6종 — 권한관리·투자심의·사업수지·에너지·BS물가·공내역발송 :milestone, 2026-08-07, 0d
  분양현황 및 전망 :milestone, 2026-08-31, 0d
          
07

배포 파이프라인 매핑

정의서 8절이 "버전 번호(무엇을)와 환경(어디에)은 별개의 축"이라 했는데, 이 보드는 그 환경 축을 Status 필드에 직접 인코딩한 사례다. 별도의 배포 추적 도구 없이 보드 컬럼만으로 환경 승격 상태가 보인다.

Status의미환경 (정의서 8절 대응)현재 건수전월
In Devdev 브랜치 머지 완료, 통합 확인하위 · dev3712 → 37
Ready for Staging → In Staging스테이징 배포 · QA 검증 중미들 · staging1530 → 15
Ready for deployment → In Prod운영 배포 완료상위 · production99 → 9
Done운영 검증 완료 · 종결182107 → 182
읽는 법 — release train이 실제로 달렸다. 전월 In Staging 30건은 "dev에서는 끝났지만 아직 운영에 나가지 않은 작업 묶음"이었다. 한 달 사이 그 대기열이 15건으로 줄고 Done이 75건 늘었다 — 스테이징 → 운영 승격 배치가 실행되어 대기열이 소화된 것. 대신 In Dev가 12 → 37건으로 쌓였다. 다음 release train의 규모가 이미 형성되고 있다.
flowchart브랜치 · 환경 승격 흐름 (BisFramework 기준)배포 런북
flowchart LR
  A["feature 브랜치"] --> B["PR 리뷰 · In Review"]
  B --> C["dev 머지 · In Dev"]
  C --> D["스테이징 배포 · In Staging"]
  D --> E{"스테이징 QA 통과?"}
  E -->|아니오| C
  E -->|예| F["운영 배포 · In Prod"]
  F --> G["운영 검증 · Done"]
          

QA Review 필드 — 배포 게이트의 새 축 (이달 신설)

QA Review 필드(Defined 39 · TCReady 7)는 "이 이슈의 QA 시나리오가 정의됐는가 → TC까지 준비됐는가"를 표시한다. 사용 46건 중 27건이 In Dev 상태에 몰려 있다 — dev 머지 후 스테이징으로 넘어가기 전에 QA 준비도를 채우는 흐름, 즉 In Dev → In Staging 사이의 게이트로 쓰이기 시작했다는 뜻이다. 환경 축(Status)과 검증 준비 축(QA Review)이 분리된 것은 정의서 관점에서 올바른 진화다.

08

한 달의 변화 (2026-07-02 → 08-03)

같은 보드를 한 달 간격으로 두 번 실측하면, 체계 문서가 말하지 못하는 것 — 팀이 실제로 어떻게 움직이는가 — 이 보인다.

지표07-02 (v1.0)08-03 (v2.0)변화
전체 이슈213308+95 (+45%)
Done107 (50%)182 (59%)+75 종결
In Staging 대기열3015−15 · 운영 승격 배치 실행
In Dev 적재1237+25 · 다음 배치 형성 중
활성 마일스톤10개10개 (투자심의·공내역발송·품의자동화 신규, 마감 6종 08-07 정렬)재편
스프린트 배정S1 43건S1~4 = 42·24·14·8회차마다 감소
부모이슈 트랙#214 1건 (하위 3)#354·#347·#321·#214 (하위 26건)표준 운영 방식화
커스텀 필드QA Review 신설 · Quarter 주기 설정 · Target date 62건 사용필드 진화

전월 개선 후보 6건 — 후속 추적

v1.0(07-02)이 제시한 개선 후보가 한 달 뒤 어떻게 됐는지 항목별 판정. 해소 진전 여전

#전월 개선 후보판정08-03 실측 근거
1유령 필드 (Team · Quarter)진전Quarter는 1Q~4Q 주기가 설정됨 — 단 배정은 여전히 0건. Team(Squad 1~3)은 그대로 0건
2Priority 전부 High여전49건 전부 High — 변별력 없음 지속
3옵션 오타 Midium여전보드 옵션 그대로
4필드 미지정 비율진전Project 70%→65% 미지정 · Milestone 76%→71% 미지정 — 방향은 맞으나 속도 느림
5마감 경과 마일스톤 재계획진전6개 마일스톤 08-07로 일괄 재설정. 단 정작 경과 당사자였던 「공내역 자동 분개」는 06-30 그대로 방치
6선언된 뷰 3종 미구현여전README의 Kanban / Project / Iteration Board "추가 필요" 문구 그대로
추적이 주는 교훈. 한 달 사이 실제로 좋아진 것(부모이슈 트랙, QA Review, 담당자 97%, release train 실행)은 모두 일하는 흐름에 붙어 있는 장치였다. 반면 그대로인 것(Priority, 오타, 뷰 3종)은 따로 시간을 내야 고쳐지는 정리 작업이다 — 개선 후보를 낼 때는 "다음 스프린트의 실제 작업에 얹을 수 있는가"를 기준으로 거는 편이 이행률이 높다.
09

관찰 · 개선 후보 v2

08절의 후속 추적에서 살아남은 항목 + 이번 실측에서 새로 드러난 항목. 체계 자체의 문제가 아니라, 정의된 체계와 실제 사용 사이의 간극이다.

#관찰근거 (실측)개선 후보
1Sprint 5 미정의Sprint 4가 08-13 종료 — 이후 iteration 없음. 배정도 42→8건 감소 추세스프린트 축을 계속 쓸지 결정 — 쓴다면 Sprint 5~ 생성 + 배정 습관 복구, 접는다면 마일스톤·트랙 축으로 공식 일원화
2마감 08-07 몰림활성 마일스톤 6개가 같은 날 마감 — 같은 주에 릴리스 준비도 판정 6건 동시 도래실제 완주 가능한 2~3개를 선별해 마감 분산
3공내역 자동 분개 방치마감 06-30에서 30일+ 경과, 1/7 close, 재계획 wave에서도 제외재계획 또는 명시적 보류(Backlog 강등) 결정
4중복 마일스톤 변형「에너지/정책 모니터링」과 「에너지/정책모니터링」(공백 차이) 병존 — 후자는 0건빈 쪽 삭제로 오배정 예방
5Priority 변별력 없음49건 전부 High + Midium 오타 지속 (2개월째)옵션 교정과 함께 "High = 이번 스프린트 필수"로 정의 재합의, 아니면 필드 제거
6Project 필드 vs 부서 라벨 이원화Project 필드 35% vs 부서 라벨(AX추진팀 등) 축 실질 작동분류 축을 라벨로 공식화하거나, 라벨 → Project 필드 일괄 매핑
7선언된 뷰 3종 미구현README "추가 필요" 문구 2개월째Status·Project·Sprint 필드가 이미 있으므로 뷰만 추가하면 됨 — 5분 작업
핵심 신호. 상태 추적(Status 100% · 담당자 97% · QA Review 신설)은 갈수록 강해지고, 계획 분류(Priority · Project 필드 · Sprint 배정)는 갈수록 약해진다. 팀의 무게중심이 "무엇부터 할까"보다 "지금 어디까지 갔나"에 있다는 뜻 — 다음 정비의 초점은 여전히 필드 추가가 아니라 기존 필드의 용도 결정(쓸 것인가, 접을 것인가)이다.
10

요약 · 현황 스냅샷

핵심이 보드의 실제 (2026-08-03)
계층Org Project #3 › Project 필드(7트랙) › Milestone(10개) › 부모이슈 트랙(#354·#347·#321) › Sub-issue(26건) + Sprint(1~4) 기간 축
두 축 + 한 계층#371 = "사업수지파싱 소속(목표)" + "Sprint 4 처리(기간)" + "#354 트랙의 Sub-issue(실행 단위)" — 3중 좌표가 이슈 하나에 공존
배포환경 축(dev/staging/prod)을 Status 11단계에 인코딩 + QA Review 필드가 In Dev→Staging 게이트로 신설
규모이슈 308건 · 완료 182건(59%) · 개발 중 40건 · 스테이징 대기 15건 · 리포 7개 통합
한 달의 변화+95건 · Done +75 · release train 실행(Staging 30→15) · 부모이슈 트랙 표준화 · 투자심의 신규 트랙 착수
다음 정비Sprint 5 여부 결정 · 마감 08-07 분산 · 공내역 재계획 · 중복 마일스톤 정리 · Priority 용도 결정
데이터 출처 — gh project view/field-list/item-list 3 --owner MAESTRO-BS 및 GraphQL API(iteration 설정 · sub-issues · milestones), 2026-08-03 조회. 이 문서는 「프로젝트 관리 체계 정의서」(원본)의 적용 예시 v2.0이며, 수치는 조회 시점 스냅샷이므로 보드 변경에 따라 달라진다. 이전 판 v1.0은 2026-07-02 데이터 기준.