CastCanvas Lab: GitHub Projects 로드맵과 이슈 계층 구조 정리

CastCanvas Lab은 FE, BE, COLLAB, SITE, ORCH 다섯 저장소로 나뉘어 있어서 작업 단위가 자연스럽게 분산된다. 레포별 이슈를 그대로 두면 구현 추적은 가능하지만, 전체 일정과 연관 관계를 한 화면에서 보기 어렵다. 이번에는 GitHub Projects를 중심으로 로드맵과 에픽 구조를 다시 세워, 여러 저장소 작업을 한 프로젝트 안에서 운영할 수 있는 형태로 정리했다.

목표

  • 멀티 레포 일정 가시화: FE, BE, COLLAB, SITE, ORCH 이슈를 한 프로젝트에 모아 로드맵 형태로 확인할 수 있게 만들기.
  • 계층 구조 정리: 오케스트레이터 에픽과 구현 레포 이슈를 parent/sub-issue 관계로 연결해 작업 묶음을 명확히 드러내기.
  • 운영 규칙 통일: 상태값, 우선순위, 날짜 필드, 이슈 제목 prefix를 통일해 뷰만 바뀌어도 읽히는 구조 만들기.

핵심 구현 포인트

1) GitHub Project를 로드맵 중심 허브로 구성

단일 레포 기준이 아닌 제품 전체 기준으로 일정을 보려면 프로젝트가 저장소보다 상위 개념이어야 했다. 그래서 CastCanvas Lab Roadmap 프로젝트를 만들고, 각 레포 이슈를 전부 이 프로젝트에 추가했다.

  • Roadmap 뷰에서는 날짜 기반으로 일정선을 확인
  • Table 뷰에서는 Repository, Parent issue, Status, Priority, Start date, Target date 중심으로 관리
  • Board 뷰에서는 상태 흐름을 확인

특히 GitHub Projects는 날짜를 넣는 것만으로는 선이 안 보이고, 뷰에서 Date fields를 Start date, Target date에 연결해야 로드맵 막대가 그려진다는 점을 확인했다.

2) 오케스트레이터 에픽과 하위 이슈를 parent/sub-issue로 연결

프로젝트에 이슈만 모으면 한 화면에 보이긴 하지만, 서로 어떤 관계인지가 약하다. 이를 해결하기 위해 cast-canvas-lab-orchestrator에 상위 에픽 이슈를 만들고, FE/BE/COLLAB/SITE의 개별 구현 이슈를 하위 이슈로 연결했다.

  • [ORCH][EPIC] 디자인 시스템 및 퍼블릭 사이트 기반
  • [ORCH][EPIC] 캔버스 코어 인터랙션
  • [ORCH][EPIC] Inspector 중심 편집 경험
  • [ORCH][EPIC] 백엔드 기초 API 및 사용자 프로필
  • [ORCH][EPIC] 실시간 협업 서버 기반

이 구조를 적용하니 Parent issue, Sub-issues progress 필드가 실제 의미를 가지기 시작했고, 로드맵에서도 작업 묶음을 더 자연스럽게 해석할 수 있게 됐다.

3) 상태값과 제목 규칙을 운영 가능한 형태로 통일

기본 Todo / In Progress / Done만으로는 실제 운영이 부족했다. 그래서 상태값을 다음 다섯 가지로 확장했다.

  • Backlog
  • Todo
  • In Progress
  • Blocked
  • Done

여기에 더해 제목만 보고도 저장소를 식별할 수 있도록 이슈 제목 prefix를 통일했다.

  • ORCH: [ORCH][EPIC], [ORCH][FEAT], [ORCH][BUG]
  • FE: [FE][FEAT], [FE][BUG]
  • BE: [BE][FEAT], [BE][BUG]
  • COLLAB: [COLLAB][FEAT], [COLLAB][BUG]
  • SITE: [SITE][FEAT], [SITE][BUG]

이 규칙은 GitHub Project 카드, 검색 결과, 이슈 리스트, 알림 화면 어디서든 바로 레포를 식별할 수 있게 해준다.

트러블슈팅 / 고민 포인트

프로젝트에 이슈는 모였지만 관계가 안 보이는 문제

  • 원인: 처음에는 레포별 이슈를 프로젝트에만 추가한 상태라, 같은 화면에 보이더라도 어떤 이슈가 어떤 에픽 아래 있는지 명확하지 않았다.
  • 해결: 오케스트레이터 레포에 에픽 이슈를 먼저 만들고, GraphQL 기반 sub-issue 연결을 적용해 parent/sub-issue 관계를 명시적으로 만들었다. 동시에 Parent issue 기준으로 그룹핑하면 프로젝트 뷰에서 계층이 훨씬 읽기 쉬워졌다.

결과

  • 멀티 레포 로드맵 확보: FE, BE, COLLAB, SITE, ORCH 이슈를 하나의 GitHub Project에서 일정 단위로 추적할 수 있게 됨.
  • 에픽 중심 운영 가능: 오케스트레이터 에픽을 기준으로 레포별 작업을 묶어볼 수 있게 되었고, Sub-issues progress도 의미 있는 지표가 됨.
  • 뷰 전환 비용 감소: 상태값, 날짜 필드, 제목 prefix가 정리되어 Roadmap, Table, Board 어느 뷰에서도 해석이 쉬워짐.

다음 개선 아이디어

  • 프로젝트 뷰 표준화: Roadmap, Table, Board 뷰 이름과 기본 컬럼/그룹 설정을 문서로 고정하기.
  • 신규 이슈 발행 규칙 자동화: 에픽 생성, 하위 이슈 연결, 상태값 초기화까지 체크리스트나 스크립트로 반자동화하기.