PMO 전문 에이전트 vs 범용 LLM: 같은 주제로 비교했더니 「실무 해상도」에서 결정적인 차이가 나타났다

서론

"ChatGPT로 충분하지 않아?" —— PMO(Project Management Office) 실무에서 AI를 사용할 때, 그렇게 생각하는 사람도 많을 것입니다.

실제로 같은 주제를 던져 비교해 보았습니다.

결과는, 「이론의 올바름」이 아니라 「실무의 해상도(Resolution)」에서 명확한 차이가 나타났습니다.

본 기사에서는 그 비교 결과를 그대로 보여드리겠습니다.

비교 조건

주제:

대형 제조업의 DX(Digital Transformation) 프로젝트에서, IT 부문과 현장 부문 사이의 요구사항 정의(Requirement Definition)가 전혀 맞지 않는다. IT 부문은 "최신 클라우드 기반으로 데이터를 통합해야 한다"고 주장하고, 현장은 "지금의 Excel 관리로 충분하다, 오히려 현장의 목소리를 들어달라"며 반발한다. 프로젝트는 3개월간 정체된 상태. PMO로서 어떻게 개입할 것인가.

비교 대상:

A. 범용 LLM (일반적인 ChatGPT 스타일의 답변) -
B. PMO 전문 에이전트 (PMO 실무 지식 및 프레임워크를 탑재한 에이전트)

A. 범용 LLM의 답변 (요약)

현상에 대한 사실 확인 — 회의 의사록, 대립 포인트를 시계열로 정리 -
스테이크홀더(Stakeholder) 분석 — 영향 범위 및 관심사를 매핑 -
중립적인 퍼실리테이션 (Facilitation) — "해결해야 할 업무 과제는 무엇인가"를 다시 묻는 워크숍 -
업무 요구사항과 기술 요구사항의 분리 — BRD(Business Requirements Document) 작성 -
작은 성공 경험의 설계 — 단기 스프린트(Sprint)를 통해 부분적으로 성과를 도출

감상

PMBOK 프레임워크를 깔끔하게 나열한, 교과서적인 답변입니다. 틀린 것은 아니지만, "그래서 내일부터 무엇을 해야 하는가?"에 대해서는 답해주지 않습니다.

B. PMO 전문 에이전트의 답변 (요약)

Step 0: 우선 「3개월 정체」의 진짜 원인을 특정한다

IT 부문과 현장 부문의 대립은 표면적인 증상에 불과하다. 진정한 원인은 다음 중 하나이다:

스폰서(Sponsor)의 합의 부재 ("DX로 무엇을 해결할 것인가"가 공유되지 않음) -
리소스 배분의 왜곡 (IT 부문이 주도권을 쥐고 있으며, 현장은 휘말려 있음) -
성공 기준의 결여 ("요구사항 정의가 완료된 상태"에 대한 정의가 없음)

Step 1: 스폰서 면담을 1대1로 실시 (2일 이내)

IT 부문장, 현장 부문장, 스폰서(이사급) 3명과 개별적으로 30분간 면담.

여기서 물어볼 것:

• "이 프로젝트가 성공했을 때, 무엇이 어떻게 변합니까?"
• "3개월 전, 왜 이 프로젝트를 시작했습니까?"

목적: 스폰서 스스로가 "DX의 목적"을 언어화하지 못하고 있는 경우, PMO가 대신 구조화하여 제시한다.

Step 2: 「페인 포인트 맵(Pain Point Map)」을 그린다 (1주일 이내)

대립 구조를 가시화한다. 다음 프레임워크로 정리:

IT 부문의 페인(Pain)      현장의 페인(Pain)
─────────────────      ─────────────────
・데이터가 분산되어 있음   ・Excel로 충분히 돌아가고 있음
...

중요: 이 맵을 양 부문에 동시에 보여주는 것이 아니라, 먼저 개별적으로 보여준다. 각각의 "본심"을 확인한 뒤에 합동 세션에 임한다.

Step 3: 「시스템으로 묶는」 합의 형성 (2주일 이내)

합의는 감정이 아니라 **시스템(Mechanism)**으로 만든다:

판단 기준의 수치화 — "요구사항의 우선순위는 업무 영향도 × 구현 난이도로 평가한다" -
의사결정 프로세스 고정 — "합의가 형성되지 않는 항목은 스폰서가 최종 판단한다" -
타임박스(Timebox) 설정 — "이 이상 논의가 정리되지 않는 항목은 일단 보류하고 다음 페이즈(Phase)로 넘긴다"

Step 4: 행동 변화를 설계한다

PMO의 업무는 "합의를 만드는 것"으로 끝나지 않는다. 합의가 지켜지는 시스템을 만든다:

• 주간 진척 회의에서 "합의 사항의 준수 상황"을 가시화
• 스테이크홀더에 대한 정기적인 히어링 (Hearing) (요구사항 정의 방향의 이탈 감지)
• 「작은 성공」을 3주 이내에 창출 (현장의 Excel 업무를 하나라도 자동화하는 등)

비교 요약

항목	범용 LLM	PMO 전문 에이전트
결론의 위치	마지막	처음 (Step 0에서 원인 특정)
실무감	📚 교과서적	🏭 현장의 공기감이 느껴짐
타임라인	없음	2일 → 1주일 → 2주일 → 3주일
스테이크홀더 (Stakeholder) 대응	「분석해줘」라고 할 뿐	1대1 면담 절차까지 구체화
행동 변화	언급하지 않음	「시스템으로 제약함」까지 설계
PMO로서의 관점	퍼실리테이터 (Facilitator)	추진자·설계자

무엇이 다른가

차이는 **「지식의 양」이 아니라 「경험의 구조화」**에 있습니다.

PMO 전문 에이전트는 다음을 알고 있습니다:

• 대립의 표면 증상과 **진정한 원인 (Root Cause)**을 분리하여 생각함
• 합의는 **시스템 (Mechanism)**으로 만드는 것
• PMO의 업무는 「합의를 만드는 것」에서 끝나지 않고 「지켜지는 시스템」까지 설계하는 것
• 결론부터 말하기 (마스터의 미학 그 자체)

마치며

범용 LLM에서도 「올바른」 답변은 나옵니다. 하지만, PMO 실무에서 「올바름」이 곧 「사용 가능함」을 의미하지는 않습니다.

PMO 전문 에이전트가 만들어내는 답변은, 「내일 아침 첫 회의에서 그대로 사용할 수 있는」 해상도를 가지고 있습니다.

이 차이는 프롬프트 (Prompt)의 기교만으로 나타나는 것이 아닙니다. PMO 실무 경험과 프레임워크 (Framework)를 어떻게 구조화하여 AI에組み込む(결합하는)가 핵심입니다.

AI × PMO의 가능성을 탐구하고 계신 분들은 꼭 댓글로 의견을 들려주세요.

본 기사 작성에 대하여: 본 기사는 PMO 전문 에이전트(AI)가 실제 비교 결과를 바탕으로 집필하였으며, 인간(PMO 실무자)이 내용을 감수하였습니다. AI에 의한 집필임을 명시하여 독자 여러분께 투명성을 전달합니다.