Claude에게 SI 프로젝트 WBS를 통째로 맡겨봤다

백지 상태의 WBS 화면 앞에서 PM이 가장 많이 하는 일은 타이핑이 아니라 회상이다. "비슷한 프로젝트에서 뭐가 있었더라." 그 회상을 기계가 대신해 준다면 어떻게 될까. 우리는 궁금한 걸 실험으로 바꿔 보기로 했다. Claude를 wbsgantt에 MCP로 연결하고, 6개월짜리 SI 프로젝트의 WBS를 통째로 맡긴 뒤 그 과정을 그대로 기록했다.

미리 밝혀 둔다. 이 글은 광고가 아니라 실험 리포트다. Claude가 잘한 것만큼 못한 것도, 사람이 반드시 손대야 했던 지점도 그대로 적는다.

실험 설계

대상 프로젝트는 이렇게 정했다. 종업원 800명 규모 중견 제조사가 노후 그룹웨어와 부서별 엑셀 관리를 통합 ERP(회계·인사·생산·구매)로 이관한다. 레거시 데이터 15년치, 회계연도 시작 전 오픈이 제약이고, 기간은 6개월이다. SI·엔지니어링 PM이라면 익숙한 형태다.

규칙은 하나였다. WBS의 생성은 Claude가 도구로 하고, 판단은 사람이 한다. Claude는 wbsgantt의 MCP 도구 — import_wbs_project, create_wbs_node, add_wbs_dependency, set_wbs_dictionary 같은 것들 — 만 쓸 수 있다. 대화창에서 프롬프트를 주면 Claude가 실제 도구를 호출해 실제 프로젝트를 만든다. 화면에 뜨는 노드, 계산되는 일정은 전부 진짜다.

라운드 1 — 초안: 40개 노드가 한 번에

첫 프롬프트는 짧았다. 위 RFP 요약을 주고 "PMBOK 표준에 맞는 WBS를 만들어 새 프로젝트로 import 해라. 100% Rule과 8/80 Rule을 지켜라"가 전부였다.

Claude는 import_wbs_project를 한 번 호출해 노드 40개, 종속성 14개를 만들었다. 트리는 11개 Phase로 나뉘었다 — 프로젝트 관리, 요구사항 정의, 시스템 설계, 회계·인사·생산·구매 모듈 개발, 데이터 마이그레이션, 통합 테스트, 사용자 교육, 오픈·안정화. 마지막에 "시스템 오픈" 마일스톤까지.

여기서 첫 번째로 인상적이었던 건 회상의 품질이었다. 초보 PM이 자주 빠뜨리는 가지들 — 레거시 데이터 마이그레이션, 모듈별 단위 테스트, 사용자 교육, 오픈 후 안정화 지원 — 이 처음부터 들어 있었다. 백지의 공포(1편에서 다룬, 빠뜨림의 상당수가 여기서 온다)를 기계가 상당 부분 걷어낸 셈이다.

하지만 곧 두 번째가 보였다. Claude가 만든 일정을 보니 6개월짜리 프로젝트가 2개월 만에 끝나는 것으로 계산돼 있었다. 원인은 명확했다. 종속성을 Phase와 Phase 사이에만 걸어 놓아서, 한 Phase 안의 활동들이 전부 같은 날 병렬로 시작하는 구조였던 것이다. "현행 업무 분석"과 "요구사항 정의서 작성"과 "요구사항 검토·확정"이 셋 다 8월 10일에 동시 시작한다. 현실의 요구사항 정의는 그렇게 흐르지 않는다.

그리고 도메인 지식이 요구되는 지점에서 두 개의 구멍이 있었다. 권한·보안 설계가 없었다. 800명이 쓰는 ERP에서 역할·권한 설계는 별도 산출물이 필요한 일인데 통째로 빠졌다. **병행 운영(parallel run)**도 없었다. 레거시와 신규를 일정 기간 나란히 돌려보고 넘어가는 컷오버 전략은 이런 이관 프로젝트의 핵심인데, 오픈이 곧장 안정화로 이어져 있었다.

한 가지 더. 8/80 Rule(하나의 Work Package는 대략 8~80시간)로 보면 "생산 기능 개발"이 25일(약 200시간)로 상한을 크게 넘었다. 흥미롭게도 import는 이걸 경고 없이 통과시켰다. wbsgantt가 생성 시점에 강제하는 것은 사이클 차단과 부모마다 가중치 합 100%(100% Rule) 같은 구조적 불변식이지, 작업의 적정 크기 같은 판단의 영역이 아니다. 이 경계는 뒤에서 다시 이야기한다.

라운드 2 — 정련: 사람이 개입하는 지점

이제 PM 차례다. 대화로 지적하고, Claude가 도구로 고쳤다. 다섯 번의 호출이 오갔다.

• 누락된 권한·보안 설계를 시스템 설계 아래에 추가(create_wbs_node). 서버가 코드 1.3.5를 자동으로 붙였다.
• **병행 운영(Parallel Run)**을 오픈·안정화 아래에 추가. 코드 1.11.3.
• 8/80을 넘긴 생산 기능 개발 25일을 셋으로 쪼갰다 — "BOM·표준원가"(10일), "작업지시·실적"(10일), "재고·수불"(8일). update로 원래 노드를 줄이고 create로 둘을 더했다.

정련하면서 관찰한 것: 새 노드를 추가할 때마다 wbsgantt가 코드(1.3.5 같은 것)와 가중치를 자동으로 다시 배분했다. WBS 코드는 표시용 캐시일 뿐 노드의 정체성은 UUID라는 원칙, 형제 가중치는 자동 균등 배분된다는 규칙이 그대로 작동했다. PM은 "무엇을 추가할지"만 판단하면 번호와 비중은 시스템이 맞춘다.

노드 수는 40개에서 44개가 됐다.

라운드 3 — 일정: 종속성만 말했더니 일정이 나왔다

라운드 1에서 본 "2개월 압축"을 고칠 차례. 나는 일정을 직접 짜지 않았다. 대신 인과만 말했다. 세 개의 종속성을 add_wbs_dependency로 추가했다.

• 현행 업무 분석 → 요구사항 정의서 작성 (FS)
• 요구사항 정의서 작성 → 요구사항 검토·확정 (FS)
• 마이그레이션 실행·검증 → 통합 테스트 수행 (FS)

앞의 둘은 요구사항 Phase 내부의 순서를, 마지막은 라운드 1에서 끊겨 있던 연결 — 이관된 데이터가 통합 테스트로 흘러들어야 한다 — 을 이었다.

효과는 즉각적이었다. CPM이 다시 돌면서 프로젝트 종료일이 10월 2일에서 11월 2일로, 한 달 밀렸다. 종속성 세 개만으로. 요구사항 정의 Phase는 이제 8월 10일21일 → 8월 24일9월 4일 → 9월 7일~9일로 계단식으로 재배치됐다(이전엔 셋 다 8월 10일 동시 시작).

크리티컬 패스는 간트에서 붉게 표시된다. 흥미로운 지점 하나 — 이 크리티컬 패스 계산은 프론트엔드 화면에서 이뤄지고, MCP 도구(get_wbs_tree)의 응답에는 크리티컬 플래그가 들어 있지 않다. 즉 Claude는 "이 작업이 크리티컬인가"를 스스로 알지 못한 채 종속성만 진술했고, 크리티컬 패스라는 결론은 도구를 감싼 시스템이 계산했다. 이 역할 분담이 이 실험의 축소판이다.

라운드 4 — Dictionary: 초안은 기계, 서명은 사람

마지막으로 몇 개 Work Package의 정의서(WBS Dictionary)를 채우게 했다. "마이그레이션 실행·검증" 노드에 set_wbs_dictionary로 정의, 산출물(이관 실행 로그·정합성 검증 리포트·롤백 절차서), 완료 기준("원천 대비 이관 건수 100% 일치, 회계 잔액 합계 오차 0원"), 가정, 제약("주말 배치 창 48시간 내 완료")을 넣었다.

여기서 6편에서 그은 선이 그대로 재현된다. 정의서 초안을 기계가 쓰는 것은 회상이고, 기계가 잘한다. 그러나 "이관 건수 100% 일치"라는 완료 기준을 계약의 합격선으로 서명하는 것은 사람의 일이다. 초안은 판단의 출발점을 당겨줄 뿐, 판단 자체를 대신하지 않는다.

평가 — 잘한 것, 못한 것, 사람의 몫

최종 프로젝트는 노드 44개(요약 12·Work Package 31·마일스톤 1), 계획 기간 92일(8월 3일~11월 2일), 크리티컬 패스 12노드, 종속성 17건, 모든 부모의 가중치 합 100%로 정리됐다. 이제 정직하게 평가해 본다.

경계가 선명하게 드러났다. wbsgantt가 기계적으로 강제하는 것은 구조적 불변식이다 — 사이클은 생성 시점에 막히고, 부모마다 가중치 합은 100%로 맞춰진다. 반면 8/80의 적정성, 종속성의 실제 인과, 범위의 계약적 경계는 강제되지 않는다. 그것들은 판단이고, 판단은 서명하는 사람의 몫으로 남는다.

정량적으로도 남는 게 있었다. 40개 노드짜리 초안을 백지에서 손으로 세우는 데 드는 시간을, 도구 호출 한 번이 걷어냈다. 사람이 한 일은 초안을 세우는 것이 아니라 초안을 검증하고 도메인 구멍을 메우는 것이었다. 이건 6편에서 말한 "산출물 제작 시간을 판단 시간으로 되돌린다"의 실물이다.

직접 해보기

같은 걸 직접 해보고 싶다면 순서는 이렇다.

1. wbsgantt에서 API 토큰 발급 — 계정 화면의 "API 토큰" 섹션에서 발급한다(권한: WBS 읽기·쓰기). 토큰은 발급 직후 한 번만 표시되니 복사해 둔다.
2. LLM 클라이언트에 커넥터 등록
   • claude.ai / Claude Desktop: 커넥터 추가 → URL https://api.wbsgantt.com/mcp/ + 발급한 토큰.
   • Claude Code: claude mcp add --transport http wbsgantt https://api.wbsgantt.com/mcp/ --header "Authorization: Bearer <토큰>"
   • ChatGPT: 커스텀 커넥터에 같은 URL·토큰.
3. 프롬프트 템플릿 — 아래처럼 프로젝트 맥락과 규칙을 주고 시작하면 된다.

"다음은 [프로젝트 성격·기간·제약]이다. PMBOK 표준에 맞는 WBS를 만들어 wbsgantt에 새 프로젝트로 import 해라. 시작일은 [YYYY-MM-DD]. 100% Rule과 8/80 Rule을 지키고, [이 도메인에서 흔히 빠뜨리는 것]을 특히 신경 써라. 초안을 만든 뒤 내가 검토할 테니, 누락이나 8/80 위반이 의심되는 지점을 스스로 지적해라."

마지막 문장이 중요하다. 초안은 기계에게, 검토의 시작점까지도 기계에게 시키되, 계약이 되는 판단은 당신이 쥔다. 그 분업이 지켜질 때 도구는 PM을 대체하는 것이 아니라, PM을 백지 앞에서 풀어준다.