Project Portfolio

Dhlab Planner

사내 일정관리 툴 접근이 제한된 환경에서, 내부 이슈와 스프린트를 운영하기 위해 직접 설계하고 도입한 일정관리 시스템입니다.

프로젝트 소개

Project Snapshot

사내 일정관리 시스템을 직접 설계하고,
자동 동기화 구조까지 구축했습니다.

사내 일정관리 툴 접근이 제한된 환경에서, 시스템 부재로 반복되던 협업 비용을 줄이기 위해 내부 이슈/스프린트 관리 도구를 구축했습니다. GitHub Enterprise Webhook 기반 상태 동기화와 프로젝트 단위 권한 모델을 함께 적용해 운영 가능한 구조를 만들었습니다.

FRONTEND

Next.jsTypeScriptTailwind CSSshadcn/uiRelay Client

BACKEND

Next.js API RouteSupabase

OPS/INTEGRATION

GitHub Enterprise WebhookGoogle SheetsSlack BotJenkins

사내 데이터 보호를 위해 이미지 블러 처리

프로젝트 도입

4건

팀 내 6개 프로젝트 중 4개 프로젝트에 도입

위클리 준비시간 단축

1.5시간

PM 보고자료 준비 시간을 매주 1시간 이상 절감

동료 피드백

29건+

운영 중 수집된 개선 피드백 기반으로 지속 고도화

내부 일정관리 시스템 설계 배경

일정관리 시스템을 사용할 수 없었던 배경

인턴·프리랜서는 사내 Jira 접근 권한이 없어 공식 일정관리 시스템을 팀 전원이 함께 사용할 수 없었습니다.

사내에 Jira가 이미 있다는 이유로, 외부 일정관리 툴 도입 예산이 승인되지 않았습니다.

결국 스프레드시트와 구두 커뮤니케이션으로 일정을 관리하게 됐고, 데이터 신뢰도가 낮아졌습니다.

기술적 제약 조건

인턴·프리랜서가 접근하는 GHES 환경에서는 GitHub Actions가 비활성화되어 있어, 웹훅 기반 커스텀 서버 방식으로 자동화를 구현해야 했습니다.

별도 예산을 승인받을 수 없어, 모든 구성 요소를 무료로 사용 가능한 솔루션 범위 안에서 해결해야 했습니다.

일정관리 시스템 부재로 발생한 문제

데이터 신뢰도 저하

진행상황을 수동으로 반영하다 보니 코드 기준 실제 상태와 일정표 상태가 자주 어긋났고, 계획 판단의 기준 데이터가 흔들렸습니다.
개발자 보고 부담 증가

자동 집계가 없어서 개발자가 매주 "5줄 요약"을 별도로 작성해야 했고, 구현 시간 외에 반복 보고 업무가 고정적으로 발생했습니다.
PM 운영 비용 누적

수집된 내용을 다시 정리해 회의용 자료로 가공해야 했기 때문에, 주간 회의 준비가 분석보다 편집 작업 중심으로 소모되었습니다.

해결 방향과 설계 고민

작게 시작하고 점진적으로 개선

단순하고 직관적인 사용성

자동 동기화 중심 운영

완성형 도구를 한 번에 구현하기보다, 제약이 많은 환경에서 실제로 굴러가는 구조를 먼저 만들고 운영 데이터를 바탕으로 확장하는 전략을 선택했습니다.

Feature Overview

주요 기능 소개

일정 관리 시스템의 주요 화면과 기능을 소개합니다.

Feature Pages

칸반 보드

백로그 상태 관리 · 필터링

Webhook 자동 동기화

GitHub 연동 · 상태 자동 전환

멤버 관리

역할 기반 접근 제어

스프린트 대시보드 · 종료 및 백로그 이월

현황 파악 · 이월 처리

칸반 보드

상태 관리

백로그를 Not Started · In Progress · Develop Release · Complete 컬럼으로 구분합니다. 드래그 앤 드롭으로 상태를 쉽게 변경할 수 있습니다.

백로그 추가

PM이 스프린트와 유저스토리를 등록해두면, 작업자들이 유저스토리 하위에 백로그를 직접 추가하고 담당자와 우선순위를 지정해 작업을 진행합니다.

필터링

그룹, 우선순위, 담당자, 보고자, 상태, 유저스토리 등 다양한 조건으로 필터링해 원하는 백로그만 모아볼 수 있습니다.

Webhook 기반 자동 동기화 및 알림 구조

How I Built It

GitHub Enterprise 웹훅 이벤트를 Next.js API 라우터에서 수신한 뒤, 이벤트를 바탕으로 백로그 상태를 갱신합니다.

백로그 상태가 변할 때마다 Supabase Function에서 Slack으로 알림을 발송해 팀원들이 상태 변화를 즉시 인지할 수 있도록 했습니다.

매일 오전 9시에 전날 변경된 백로그 상태를 데일리 리포트로 취합해 Slack으로 전송, 데일리 스크럼 시 활용했습니다.

State Mapping

브랜치 이름의 티켓명 기준으로 백로그를 매핑합니다.

PROJECT_ID-001 push → In Progress
develop merge → Develop Release
main merge → Production Release

Webhook 자동 동기화 다이어그램

Architecture

멤버 관리

멤버 할당

페이지 진입 시 왼쪽에 미소속 멤버, 오른쪽에 그룹별 소속 멤버가 표시되며 언제든지 추가·제거할 수 있습니다.

팀 내에서 멤버를 몇 주 단위로 프로젝트에 투입·이동시키는 일이 잦았기 때문에, 인원 변동을 빠르게 반영할 수 있도록 별도 페이지로 구성했습니다.

멤버 유형 · 권한

재직자

모든 권한 보유. 백로그 생성 · 수정 · 삭제 및 멤버 관리 가능.

퇴직자

Soft Delete

로그인 불가. 이전 백로그 담당자 기록 조회를 위해 계정 삭제 없이 Soft Delete 처리.

휴직자

페이지 조회는 가능. 멤버 관리 목록에 표시되지 않아 백로그 할당 대상에서 자동 제외.

외부인

협력 업체 등 외부 사용자. 소속 프로젝트에만 접근 가능하며 백로그 CRUD 권한만 허용.

스프린트 대시보드 · 종료 및 백로그 이월

위클리 활용

매주 진행하는 스프린트 종료 회의에서 대시보드의 트리뷰를 통해 전체 진행 현황을 보면서 일정 관련 논의를 마친 후, 스프린트 종료 프로세스 버튼으로 이번 스프린트에서 완료되지 않은 백로그를 다음에 진행할 스프린트로 일괄 이월 처리했습니다.

종료 프로세스

아키텍처 진화 및 기술적 의사결정

v1 phase 1

선택 이유 최소 리소스로 운영 가능성을 빠르게 검증하기 위해 Apps Script + AppSheet 조합 선택

한계 AppSheet UI 적응 난이도, 보고용 가독성 부족, 멀티 프로젝트 확장 한계

전환 판단 실사용 피드백에서 UI/리포팅 문제가 반복돼 Next.js 기반으로 전환

v2 phase 2

선택 이유 Next.js API Route + React Flow 트리뷰로 사용성과 보고 품질 개선

한계 Google Sheets 기반이라 성능 저하, 프로젝트 추가 시 수작업 복제 필요

전환 판단 확장성 문제 해결을 위해 Supabase 마이그레이션 및 캐싱 구조 도입 판단

v3 phase 3

선택 이유 Supabase + Relay 캐싱으로 네트워크 요청 절감과 구조적 확장성 확보

한계 초기 스키마 설계와 운영 정책 정합성 관리가 더 중요해짐

전환 판단 기능 추가보다 데이터 모델/권한 정책 안정화 중심으로 운영 전략 전환

운영 과정에서 드러난 제약을 근거로 단계적으로 전환하면서, 완성형 설계보다 실제 사용성 검증과 점진적 개선을 우선하는 전략을 채택했습니다.

운영을 통해 얻은 설계 통찰

Key Learning

기술 스택보다 운영 조건을 반영한 데이터 구조와 자동화 연결이 더 중요했습니다.

이번 프로젝트의 성패는 라이브러리 선택보다도, 팀의 실제 업무 흐름과 정책 제약을 시스템 모델에 얼마나 정확히 반영했는지에 달려 있었습니다.

확장성은 코드보다 스키마에서 시작된다

유저스토리 도입, 스프린트 이월, 멤버 다중 할당 같은 요구가 들어오면서 코드 수정보다 관계/정책 모델 변경이 더 큰 영향을 주었습니다. 기능이 늘어날수록 확장 가능한 스키마가 유지보수 비용을 결정한다는 점을 체감했습니다.

자동화는 입력 기능이 아니라 업무 흐름이어야 한다

Git 이벤트 기반 상태 전이, Slack 알림, 데일리 리포트를 연결해 일정 관리를 기록이 아니라 협업 흐름으로 편입했습니다. 업데이트를 강제하는 대신, 팀이 원래 하던 행동에서 자동으로 데이터가 생성되도록 설계했습니다.

작은 시작과 점진적 개선이 현실적이다

AppSheet로 최소 기능을 빠르게 검증한 뒤, 운영 제약이 드러날 때마다 Next.js에서 Supabase/Relay 구조로 단계적으로 진화시켰습니다. 완벽한 설계보다 운영으로 검증되는 제약을 기준으로 구조를 바꾸는 접근이 더 효과적이었습니다.

도구의 목적은 기능보다 팀의 행동 변화다

개발자/PM/관리자가 같은 기준 화면(트리뷰)을 보게 되면서 보고 방식과 커뮤니케이션 습관이 바뀌었습니다. 결과적으로 5줄 요약 보고가 사라지고, 관리자가 직접 진행 상황을 파악할 수 있는 흐름이 만들어졌습니다.

Dhlab Planner

프로젝트 소개

사내 일정관리 시스템을 직접 설계하고, 자동 동기화 구조까지 구축했습니다.

내부 일정관리 시스템 설계 배경

일정관리 시스템을 사용할 수 없었던 배경

기술적 제약 조건

일정관리 시스템 부재로 발생한 문제

해결 방향과 설계 고민

작게 시작하고 점진적으로 개선

단순하고 직관적인 사용성

자동 동기화 중심 운영

주요 기능 소개

칸반 보드

Webhook 기반 자동 동기화 및 알림 구조

Webhook 자동 동기화 다이어그램

멤버 관리

스프린트 대시보드 · 종료 및 백로그 이월

아키텍처 진화 및 기술적 의사결정

운영을 통해 얻은 설계 통찰

기술 스택보다 운영 조건을 반영한 데이터 구조와 자동화 연결이 더 중요했습니다.

확장성은 코드보다 스키마에서 시작된다

자동화는 입력 기능이 아니라 업무 흐름이어야 한다

작은 시작과 점진적 개선이 현실적이다

도구의 목적은 기능보다 팀의 행동 변화다

사내 일정관리 시스템을 직접 설계하고,
자동 동기화 구조까지 구축했습니다.