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일에 함께 시작한다. 실제 요구사항 정의는 그런 순서로 흐르지 않는다.

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

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

라운드 2. 사람이 고친 것

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

• 누락된 권한·보안 설계를 시스템 설계 아래에 추가했다(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로 종속 관계 3개를 추가했다.

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

앞의 둘은 요구사항 Phase 안의 순서를 이었다. 마지막은 라운드 1에서 끊겨 있던 연결이다. 이관된 데이터가 있어야 통합 테스트를 할 수 있다.

효과는 바로 나타났다. CPM이 다시 계산되면서 프로젝트 종료일이 10월 2일에서 11월 2일로 한 달 밀렸다. 종속 관계 3개를 추가했을 뿐이다. 요구사항 정의 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을 대체하지 않는다. PM을 백지에서 시작하는 부담에서 풀어줄 뿐이다.