mckinsey-pptx는 컨설팅 덱 작성을 Claude Code 에이전트 작업으로 바꾼다

생성형 AI가 업무 문서를 바꾸고 있다고 말할 때, 많은 사람은 아직도 텍스트 초안이나 요약 자동화를 먼저 떠올린다. 하지만 실무에서 더 많은 시간을 잡아먹는 산출물은 보고서 본문보다도 발표 덱이다. 특히 경영진 보고, 사업 리뷰, 전략 제안처럼 “스토리라인 + 숫자 시각화 + 정돈된 레이아웃”이 동시에 필요한 작업은 단순 복붙 자동화로 해결되지 않는다.

seulee26/mckinsey-pptx가 흥미로운 이유는 바로 이 지점을 겨냥하기 때문이다. 이 저장소는 자신을 “McKinsey-style PPTX generator”라고 소개하지만, 실제 구조를 뜯어보면 단순 슬라이드 템플릿 모음이 아니다. Claude Code 플러그인, mckinsey-slide-agent 서브에이전트, /mckinsey-deck 커맨드, 그리고 python-pptx 기반 생성 엔진을 결합해, 사용자가 한국어 한 줄로 말한 브리프를 실제 .pptx 파일 생성 작업으로 연결하는 작은 에이전트 시스템에 가깝다.

내가 보기엔 이 프로젝트의 핵심은 “AI가 PPT를 예쁘게 그려준다”보다 “프레젠테이션 제작을 템플릿 선택 + 스토리 설계 + 파일 생성이라는 에이전트 워크플로우로 쪼갠다”는 데 있다. 특히 최근 README가 개발자 문서라기보다 비개발자 온보딩 문서에 가까운 형태로 정리되면서, 이 저장소는 단순 Python 라이브러리에서 한 걸음 더 나아가 실제 사용자-facing 생산성 에이전트처럼 보이기 시작했다.

무엇을 해결하려는가

이 프로젝트가 푸는 문제는 단순한 “PPT 자동 생성”이 아니다. 더 정확히는, 짧은 브리프만 있는 상태에서 어떤 슬라이드 타입을 골라야 하고, 어떤 숫자는 차트로, 어떤 메시지는 executive summary로, 어떤 비교는 매트릭스로 풀어야 하는지를 사람이 매번 직접 판단해야 하는 부담을 줄이려 한다. 컨설팅 스타일 덱이 어려운 이유는 디자인 도구를 다루는 기술보다도, 상황에 맞는 구조를 빠르게 고르는 판단 비용이 크기 때문이다.

README는 이를 매우 사용자 친화적으로 포장한다. 예를 들어 “Q4 사업 리뷰 데크 만들어줘”라고 입력하면 40개 템플릿 중 적절한 것을 골라 6~8장짜리 .pptx를 만든다고 설명한다. 또 엑셀, 워드, PDF, 메모, 로고 이미지를 한 프로젝트 폴더 아래 두고 Claude Code를 그 폴더에서 실행하라고 안내하는데, 이는 이 저장소가 단순한 템플릿 패키지가 아니라 실제 업무 자료를 읽고 덱으로 재조합하는 로컬 문서 파이프라인을 지향한다는 뜻이다.

특히 이 프로젝트는 보고서 작성보다 프레젠테이션 “형식 선택”을 중간 추론 단계로 올려놓는다. 예를 들어 성장률이 단일 시계열이면 column_simple_growth, 실제값과 전망치를 나눠 보여줘야 하면 column_historic_forecast, 2x2 포트폴리오 분석이면 growth_share, 프로젝트 일정이면 gantt_timeline을 쓰라는 식이다. 즉 문제의식은 “문장을 슬라이드로 바꾸자”가 아니라 “브리프를 받아 적절한 시각 표현 문법을 선택하자”에 가깝다.

핵심 아이디어 / 구조 / 동작 방식

구조를 보면 이 프로젝트는 세 층으로 나뉜다. 첫째는 Claude Code 플러그인 계층이다. .claude-plugin/plugin.json은 플러그인 메타데이터를 제공하고, agents/mckinsey-slide-agent.md는 서브에이전트의 역할과 워크플로우를 정의하며, commands/mckinsey-deck.md는 사용자의 브리프를 그 서브에이전트에게 위임하는 슬래시 커맨드를 만든다. 즉 사용자는 채팅으로 요청하지만, 내부적으로는 plugin → command → subagent delegation 흐름을 탄다.

둘째는 템플릿 의사결정 계층이다. mckinsey_pptx/agent/CATALOG.md는 단순 예제 문서가 아니라 거의 룰북에 가깝다. 각 템플릿마다 언제 써야 하는지, 언제 쓰면 안 되는지, 어떤 인자를 요구하는지, 어떤 인접 템플릿과 구별되는지를 자세히 설명한다. 서브에이전트 문서도 이 카탈로그를 “source of truth”라고 명시하며, 매 슬라이드마다 왜 그 템플릿을 골랐는지 설명하도록 강제한다. 즉 템플릿 선택이 암묵적 감각이 아니라 공개된 결정 규칙으로 드러나 있다.

셋째는 실제 렌더링 계층이다. mckinsey_pptx/builder.py와 slides 모듈은 PresentationBuilder를 중심으로 여러 슬라이드 타입을 라우팅하고, 필요한 경우 payload shape를 보고 타입을 추론하는 add_specs 흐름까지 제공한다. 여기에 examples/demo.py, examples/demo_korean.py 같은 샘플이 붙어 있어 영문/한글 데크 생성 경로를 바로 재현할 수 있다. 즉 이 프로젝트는 완전한 WYSIWYG 에디터가 아니라, 구조화된 spec을 받아 .pptx를 조립하는 생성 엔진을 갖는다.

또 하나 눈에 띄는 것은 운영 가드레일이다. mckinsey-slide-agent.md는 첫 실행 시 import 확인, 실패 시 requirements.txt 설치, 필요하면 PYTHONPATH에 플러그인 루트를 prepend하는 절차를 적어 둔다. 더 나아가 LibreOffice와 Poppler가 있으면 PDF/PNG preview까지 렌더링해 레이아웃을 검증하라고 강제한다. 즉 이 프로젝트는 텍스트를 슬라이드 코드로 바꾸는 것에서 멈추지 않고, overflow·title wrap·Korean width 문제까지 포함한 제작 SOP를 서브에이전트 규칙으로 내장한다.

공개된 근거에서 확인되는 점

저장소 메타데이터를 보면 프로젝트는 아직 매우 초기지만 반응은 빠르다. 재확인 시점 기준 GitHub는 368 stars, 74 forks, 기본 브랜치 main, 11 commits를 보여 준다. 최신 태그는 v0.2.0이며, GitHub UI의 최신 커밋 메시지도 Fix slide layout overflow and polish template rendering (v0.2.0)로 표시된다. 반면 Releases API의 /releases/latest는 404를 반환했기 때문에, 버전 태그는 운영하지만 정식 릴리스 노트 체계는 아직 얇은 상태로 보인다.

플러그인 메타데이터도 비교적 잘 정리되어 있다. plugin.json은 버전 0.2.0, MIT 라이선스, AX Labs 작성자 정보, 그리고 korean, strategy, pptx, consulting 같은 키워드를 명시한다. marketplace.json 역시 axlabs-mckinsey-pptx를 productivity 카테고리로 배치한다. 다만 GitHub 저장소 메타데이터의 license 필드는 Other / NOASSERTION으로 노출되고 있어, API 메타와 실제 LICENSE 파일/README 표기가 완전히 정렬되지는 않는다. 즉 이 저장소는 단순 개인 스크립트보다는 Claude Code 플러그인 유통 경로를 의식한 배포 패키지에 가깝고, 라이선스 해석은 실제 파일 기준으로 보는 편이 안전하다.

서브에이전트 문서는 특히 인상적이다. mckinsey-slide-agent.md는 한국어일 때 Apple SD Gothic Neo 테마를 강제하고, 빽빽한 템플릿에서 bullet 길이를 엄격하게 제한하며, chart 계열 슬라이드에는 description과 takeaway_header를 반드시 넣으라고 지시한다. 또한 결과물을 output/ 아래에 저장하고, soffice와 pdftoppm가 있으면 렌더링까지 검증하라고 요구한다. 즉 이 프로젝트의 핵심 자산은 40개 템플릿 자체만이 아니라, 그 템플릿을 깨지지 않게 쓰는 운영 규칙까지 함께 제공한다는 점이다.

README의 톤 변화도 의미 있다. 초기 오픈소스 README가 대체로 개발자 중심이었다면, 현재 문서는 Claude Code 설치, 플러그인 추가, 재시작 필요, /agents 확인, 프로젝트 폴더에 원본 문서를 넣는 법, 한국어 예시 프롬프트까지 단계별로 적는다. 이는 저장소가 단순 코드 공개를 넘어 “비개발자도 한 줄 브리프로 실제 PPT를 뽑아내는 제품 경험”을 전면에 내세우고 있음을 보여 준다.

실무 관점에서의 해석

내가 보기에 mckinsey-pptx의 가장 큰 장점은 PowerPoint 생성을 “에이전트가 판단 가능한 프레젠테이션 문법”으로 바꿨다는 점이다. 많은 슬라이드 생성 도구는 이미지 결과를 보여주거나, 단순한 프롬프트 기반 HTML/캔버스 시안을 만드는 데 그친다. 반면 이 프로젝트는 결과물을 .pptx로 남기고, 어떤 슬라이드를 왜 골랐는지까지 서브에이전트가 설명하게 만든다. 이건 특히 컨설팅, 전략, 운영 리뷰처럼 재편집·검토·사내 공유가 필수인 환경에서 의미가 크다.

또한 이 저장소는 프레젠테이션을 단순한 디자인 문제가 아니라 구조화된 reasoning 문제로 본다. 브리프를 읽고, 데이터 타입을 파악하고, 적절한 슬라이드 문법을 고르고, 렌더 후 오버플로를 다시 확인하는 흐름은 사실상 작은 문서 생산 파이프라인이다. 최근 에이전트 도구들이 코딩뿐 아니라 문서·디자인·리서치 산출물 생성으로 확장되는 흐름과도 잘 맞는다.

특히 이번 버전에서 보이는 신호는 “템플릿 수”보다 “배포 경험” 쪽이 더 중요하다는 점이다. 플러그인 설치 후 Claude Code를 반드시 재시작해야 한다는 주의사항, /agents 확인 절차, output 폴더 관례, KO theme, preview 검증 루틴은 모두 실제 사용자 실패 지점을 줄이기 위한 제품화 흔적이다. 즉 이 프로젝트는 단순한 slide factory보다, 컨설팅 덱 제작 업무를 로컬 에이전트 경험으로 포장한 productivity layer에 더 가깝다.

물론 한계도 있다. 첫째, 현재 배포 타깃이 사실상 Claude Code 플러그인 생태계에 강하게 묶여 있다. 둘째, README의 사용자 친화적 설명에 비해 실제 품질은 템플릿 카탈로그와 입력 구조화 수준에 크게 좌우될 가능성이 높다. 셋째, GitHub Releases 부재에서 보이듯 저장소 운영 성숙도는 아직 초기 단계다. 넷째, “맥킨지 스타일”이라는 강한 미학적 제약은 범용 deck generator라기보다 특정 장르에 최적화된 도구임을 뜻한다.

그럼에도 방향성은 꽤 선명하다. 앞으로 업무용 문서 자동화에서 중요한 것은 모델이 글을 잘 쓰는가보다, 조직이 반복적으로 쓰는 산출물 형식을 얼마나 잘 캡슐화하고, 그 형식 선택을 얼마나 에이전트 절차로 전환할 수 있느냐일 가능성이 크다. mckinsey-pptx는 그 점에서 단순 슬라이드 템플릿 저장소가 아니라, “컨설팅 덱 제작을 위한 로컬 실행형 프레젠테이션 에이전트”라는 정체성이 더 정확해 보인다.