1) 이 글을 쓰는 이유
대부분의 프로젝트 관리 툴은 “기능”은 많은데 실제 사용 플로우가 단절되어 있는 경우가 많다.
특히 WBS, 일정, 진척률, 리스크, 주간보고, 권한이 분리되면 운영자 입장에서 한 화면 안에서 업무를 끝내기 어렵다.
그래서 난 WBS Console을 만들었다.
이 글은 기능 소개가 아니라, 왜 이렇게 만들었는지와 어떻게 만들었는지를 정리한 기록이다.
2) 핵심 목표
이 서비스의 1차 목표는 단순했다.
- 프로젝트 운영이 필요한 사람들도 바로 쓸 수 있는 단일 콘솔을 만든다
- 복잡한 기능을 덩어리로 분리하지 않고 하나의 흐름으로 묶는다
- 공개 데모는 운영 데이터와 분리해 누가 와도 안전하게 체험하게 한다
즉,
PM/PL/PMO가 “일정표를 보는 화면”만이 아니라
“업무가 진행되는 화면”을 갖도록 만든다.
3) 서비스 주소
- 운영 서비스: https://bca.ac.kr/wbs/
- 공개 데모: https://bca.ac.kr/wbsdemo/
- 매뉴얼: 로그인 후
Settings → 사용 매뉴얼
(데모 테스트 시나리오와 운영 가이드를 함께 제공)
4) 구현한 주요 기능
4-1) 프로젝트와 WBS를 중심으로 한 작업 흐름
- 프로젝트 생성/선택/조회
- WBS 계층 편집
- 작업 추가, 수정, 삭제, 이동(내어쓰기/들여쓰기), 순서 정렬
- 진척률과 상태 변경이 즉시 화면에 반영
WBS의 핵심은 “편집” 자체보다 변경이 전파되는 일관성이다.
내가 만든 구조는 상세 영역/리스트/요약 지표가 같은 기준일 기준으로 같은 결과를 내도록 맞췄다.
4-2) Gantt + 기준일 기반 검토
- 월간/주간/일간 단위에서 바 차트(타임라인) 형태로 작업 분포 확인
- 기준일(Date) 기준으로 실제 상태를 함께 검토
- WBS와 Gantt 간 동기화를 우선순위로 설계
운영에서는 “어떤 작업이 언제 어떻게 바뀌었는지”가 더 중요해서,
Gantt는 단순 시각화가 아니라 검토 판단의 근거 화면으로 사용되게 만들었다.
4-3) Issue / Risk 연동
- 작업 단위에 Issue/Risk를 연결
- 상태 변경, 진행 추적, 활동 히스토리 흐름
- 담당자·기한·원인/조치 이력 정리
문서형 관리에서 자주 터지는 문제는 “누가 무엇을 맡았는지 연결이 끊긴다”는 점이다.
그래서 WBS 항목과 Issue/Risk를 묶어서 운영 문맥을 유지하도록 설계했다.
4-4) 주간보고/보고서 작성
- 보고서 템플릿 기반 입력
- 기간, 실적, 계획, 의사결정 요청 섹션 구성
- 작성 상태를 프로젝트 진척 기준과 맞춰 점검
보고서는 작업의 결과물이 아니라 회의 결과물이다.
이 플랫폼에서 보고서 화면은 “추가 입력 폼”이 아니라 현재 상태를 한 번에 문서화하는 용도로 둔다.
4-5) 사용자/권한/설정
- 사용자, 역할(Role), 그룹, 권한(Permission) 관리
- 화면 단위 접근 제어
- 보안/감사 로그 조회
운영용 툴은 화면 기능 자체보다 접근 제어가 먼저다.
그래서 화면 메뉴 접근부터 기능 호출까지 가능한 범위를 권한 기반으로 제한했고,
관리 기능은 별도 구획으로 나눴다.
5) 바이브 코딩만으로 진행한 개발 방식
이 프로젝트는 문서-요구-개발을 순차적으로 밀어붙인 방식이 아니라,
아래 순서로 움직였다.
- 가장 먼저 동작이 필요한 핵심 화면을 잡는다
- 바로 구현해서 확인한다
- 흐름에서 부딪히는 지점만 즉시 고친다
- 다음 화면으로 넘어간다
- 매주/매일 결과물을 사용자가 보는 흐름 기준으로 점검한다
즉, 전형적인 “요구사항을 먼저 끝내고 코드를 쓰는 방식”이 아니라
실제 체감 동선 기준으로 계속 밀어붙인 방식이야.
바이브 코딩이 왜 먹혔나?
- 초기 기획 확정이 느린 상태에서도 기능 실체를 먼저 보여줄 수 있었다
- 데모용 제한 정책(운영 분리) 같은 정책 항목도 화면에서 즉시 검증했다
- 매뉴얼(Testing Guide)을 화면 안에 두고, 수정 이슈를 실제 체험 경로에서 붙잡았다
결과적으로 “문서에서 맞는지”보다 “현실에서 맞는지”로 합의점을 빠르게 잡을 수 있었다.
6) 사용자 안내와 학습 동선
서비스를 만든 뒤에 가장 중요했던 건 “사용자 입장”이었다.
그걸 위해 매뉴얼을 별도 파일이 아니라 화면 메뉴로 통합했다.
Settings → 사용 매뉴얼에서 바로 확인 가능- 데모 환경에서 어떤 기능이 가능한지/안 되는지 명시
- 테스트 시나리오 형태로 초보자도 기능을 따라가며 검증 가능
단순한 문서가 아니라 제품의 일부분으로 메뉴얼을 설계한 것이다.
7) 보안/운영 관점에서의 분리
공개 데모는 운영 데이터와 분리해 두었고,
데모 모드에서 제한되는 기능(운영 데이터 접근/일부 대량 작업/내보내기 일부 제한)을 걸어두었다.
이 덕분에
외부 체험자도 기능을 이해할 수 있지만 운영 환경엔 영향이 가지 않는다.
8) 화면 캡처



9) 정리
WBS Console은 “새 기능을 많이 넣는 툴”이 아니라,
프로젝트 운영자가 실제로 하루를 보내는 동작 흐름을 한 화면에서 끝내게 만든 툴이다.
그리고 이 제품은 전 과정을 바이브 코딩으로 만들었다는 점이 핵심이다.
기능이 완벽해 보이기 전에 먼저 돌아가게 만들고,
돌아가는 화면을 기준으로 다시 정교하게 다듬는 방식으로 완성도를 끌어올렸다는 점을 이번 빌드에서 확인했다.
참고:
운영 도메인 기준으로 공개된 페이지는 언제든 아래 URL에서 확인 가능하다.
'Ai™' 카테고리의 다른 글
| [AI] Google Opal 함 보자구 (1) | 2025.10.29 |
|---|
WRITTEN BY
- bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #AI, #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고 May The Force be With You










