WBS Studio

프로젝트 설명 한 줄, 또는 기획서 파일(PDF·Word·텍스트)을 넣으면 AI가 작업분해구조(WBS)로 분해해 주는 프로젝트 관리 도구다. PMBOK 원칙에 맞춰 계층을 만들고, 일정·의존성·크리티컬 패스까지 계산한다.

만들어진 WBS는 트리·간트·마인드맵·테이블·칸반·캘린더·워크로드 7개 뷰에서 편집하며, 모든 뷰가 같은 데이터를 다룬다.

프로젝트 초기의 WBS는 빈 화면에서 시작한다. 머릿속 계획을 계층으로 옮기는 그 첫 단계가 가장 오래 걸리고, 대개 미뤄진다.

보고 싶은 형태가 사람마다 다르다. 일정은 간트, 구조는 트리나 마인드맵, 진행은 칸반, 부하는 워크로드로 보고 싶다. 기존 도구는 한 형태를 고정하거나, 여러 형태를 지원해도 뷰마다 데이터를 따로 들고 있어 한쪽을 고치면 다른 쪽이 어긋난다.

AI에 맡기면 다른 문제가 생긴다. 분해 자체는 AI가 잘하지만, 날짜 계산처럼 정확해야 하는 부분에서 그럴듯하게 틀린다. 그리고 AI 호출은 이 서비스의 유일한 변동 비용인데, 가입을 공개하는 순간 상한 없는 비용 경로가 된다.

• 입력 문턱을 낮췄다. 자연어 한 줄 또는 기획서 업로드에서 시작한다. 빈 화면이 아니라 초안을 고치는 방식으로 바꿨다.
• 뷰는 늘리되 모델은 하나로. 7개 뷰가 같은 데이터 모델을 직접 편집한다. 어느 뷰에서 고쳐도 나머지에 즉시 반영돼 뷰 간 불일치가 구조적으로 생기지 않는다.
• AI와 결정론의 경계를 그었다. AI는 무엇을 할지(작업 분해·소요일)를 정하고, 날짜·롤업·크리티컬 패스는 코드가 계산한다.
• 입력 복잡도로 모델을 고른다. 휴리스틱 스코어러가 1ms·무비용으로 입력을 SIMPLE·MEDIUM·COMPLEX로 나눠 저렴한 모델부터 쓰고, 결과가 JSON 스키마 검증에 실패하면 상위 티어로 단계적 에스컬레이션한다.

• AI 자동 분해 — 자연어 또는 기획서(PDF·DOCX·TXT·MD·CSV) → WBS 트리
• 7개 뷰 — 트리, 간트(DHTMLX), 마인드맵(xyflow), 테이블, 칸반, 캘린더, 워크로드
• CPM 분석 — FS·SS·FF·SF 의존성과 lag를 지원하는 크리티컬 패스 자동 식별
• 자동 롤업 — 자식 진행률로 부모 진행률을 자동 산출
• 사용자 정의 단계 — 칸반 열 이름·색·순서를 자유롭게 바꾸되, 고정 분류 4개(준비→설계→실행→검수) 중 하나에 속하게 한다
• 팀 협업 — 작업별 댓글과 이미지 첨부. 첨부는 버킷을 공개하지 않고 백엔드가 팀 권한으로 프록시 서빙
• 휴지통 — 삭제한 작업을 30일 보관 후 복원
• 내보내기 — CSV(엑셀 호환 BOM 인코딩)·XLSX
• 주간 품질 리포트 — 스냅샷 비교로 주간 변화와 인사이트 도출
• 소셜 로그인 — 구글·카카오
• AI 비용 대시보드 — 생성 이력과 티어별 비용

  Next.js 프런트엔드 ── Cloudflare Workers ── wbs.azclab.com
    트리 · 간트 · 마인드맵 · 테이블 · 칸반 · 캘린더 · 워크로드
    AI 패널 (라우팅 티어·비용 실시간 표시)
                     │  /api/v1
  FastAPI 백엔드 ── Cloudflare Containers (30분 무풍 시 수면)
    ├─ LLM 라우터 ── scorer(1ms) → SIMPLE / MEDIUM / COMPLEX
    │                 └ 스키마 검증 실패 → 상위 티어 에스컬레이션
    ├─ WBS 생성 파이프라인 (JSON Schema 검증)
    ├─ scheduler        소요일 → 날짜
    ├─ cpm              크리티컬 패스
    ├─ automation       진행률 롤업
    ├─ ai_quota         사용량 상한
    └─ document_parser · exporter · reporting · node_trash
                     │
  Neon serverless Postgres          R2 (댓글 첨부, 백엔드 프록시 서빙)

• LLM에게 날짜를 시키지 않는다. 모델은 날짜 산술에서 형제 작업 간 연속성·주말·부모 구간 정합을 자주 깨뜨린다. 필드가 늘어난 만큼 토큰과 스키마 검증 실패율만 오른다. 그래서 AI는 소요일(days)만 내고, 시작·종료일은 결정론 스케줄러가 형제 순서로 계산한다.
• 소프트 삭제 대신 스냅샷 휴지통을 택했다. 프로젝트는 deleted_at 소프트 삭제를 쓰지만 작업(노드)은 다르게 했다. 노드를 읽는 쿼리가 수십 곳이라 전부에 필터를 넣어야 하고, 하나라도 빠지면 지운 작업이 되살아나 보인다. 대신 지우기 직전 하위 트리를 스냅샷으로 떠서 30일 보관한다.
• AI 사용량에 상한을 걸었다. 비용 추적은 기록만 하고 막지 않는다. 로그인만 하면 누구나 AI를 부를 수 있으므로, 공개 가입 전에 사용자별 상한을 별도 서비스로 뒀다.
• 단계는 자유롭게, 분류는 고정으로. 사용자가 칸반 단계를 마음대로 만들어도 반드시 고정 분류 4개 중 하나에 속하게 했다(Linear 모델). AI 생성과 일정 배치는 사용자 단계 이름이 아니라 분류만 보고 동작하므로, 사용자 정의가 자동화를 깨지 않는다.
• 측정하고 나서 최적화 여부를 정했다. 500노드(실사용의 약 10배) 벤치마크에서 모든 상호작용이 200ms 미만, 노드 선택은 50ms 미만이었다. 가상화 도입을 유보했다 — 초기 로드 2.5초는 렌더가 아니라 원격 DB 페이로드 문제였다. 컨테이너 콜드스타트도 실측 1.2초로 우려 기준(5초)에 크게 못 미쳐 keep-alive 같은 완화책을 넣지 않았다.

wbs.azclab.com에서 운영 중이며, 자연어·기획서 입력부터 편집 가능한 WBS와 크리티컬 패스까지 한 흐름으로 이어진다.

• 모바일 Lighthouse 성능 64 → 100. 첫 화면 표시(FCP·LCP)가 6.1초에서 1.1초로 줄었다. 원인 셋을 찾아 고쳤다 — 로그인 폼이 opacity:0으로 프리렌더돼 JS 로드 전까지 화면이 비어 있었고, 세션 확인이 JS를 다 받은 뒤에야 시작됐으며, 인증 로더가 테두리뿐인 스피너라 첫 페인트 후보가 되지 못했다. 세 가지 모두 점수만의 문제가 아니라 실사용 체감 지연이었다.
• 7개 뷰가 같은 데이터를 대상으로 동작해 전환해도 어긋나지 않는다.
• 모델 라우팅의 비용 절감은 입력 분포를 SIMPLE 70%·MEDIUM 25%·COMPLEX 5%로 가정할 때 50~85%로 추정된다(설계 추정치, 실측 아님).
• 백엔드 테스트 28개, E2E 스펙 16개.

AI 제품에서 가장 중요한 결정은 AI에게 무엇을 시키지 않을지였다. 분해는 잘하지만 날짜 산술은 그럴듯하게 틀린다 — 그 경계를 코드로 고정하면서 모델이 내야 할 필드 자체가 줄었고, 그만큼 토큰과 스키마 검증이 실패할 여지도 함께 줄었다. 성능도 같은 태도로 다뤘다. 가상화·keep-alive 같은 흔한 처방을 먼저 넣지 않고 측정부터 했고, 둘 다 필요 없다는 결론이 나왔다. 대신 측정이 가리킨 진짜 병목 — 프리렌더된 투명 화면 — 을 고쳐 Lighthouse 64를 100으로 올렸다.