게임 프로젝트 매니저가 AI를 활용하여 더 빠르고 스마트하게 일하는 방법

간단 요약: 이 글은 시스템에 대한 실제 사례를 다룬 PMNote 아티클의 영어 각색본이며, 모델 설명이나 도구 목록이 아닙니다.

TL;DR / 핵심 답변

AI가 게임 프로젝트 매니저를 더 빠르게 만들고 싶다면 세 가지부터 시작하세요. 요청 사항을 명확하게 지정하고 미흡한 초안을 정확하게 수정할 수 있는 '듀얼 카드 시스템(dual-card system)'을 사용하면, Hao 본인의 경험상 같은 작업을 위해 오갔던 58차례의 왕복 작업이 12회로 줄어들었습니다. 회의록 작성, 주간 보고서, 프로세스 문서, 요구사항 정렬(requirement alignment), 위험 요소 식별 등 다섯 가지 고빈도 워크플로우를 작동시키세요. 그런 다음 AI에게 프로젝트 지식 기반(project knowledge base), 규칙, 그리고 예시를 제공하여 게임에 대한 이해, 형식, 표준을 기억하게 하세요. AI를 검색창이나 맹목적으로 신뢰할 대상이 아니라, 온보딩해야 하는 동료로 대하세요.

해결하고자 하는 평범한 오후의 풍경

오후 3시입니다. 두 번의 회의가 끝났습니다. 녹음 파일은 여전히 휴대폰에 있고, 메모는 작성되지 않았습니다. 내일 아침 주간 보고서는 아직 제목만 있을 뿐입니다. 디자인 팀과의 여러 요구사항 정렬 회의가 저녁 시간으로 잡혀 있습니다.

이것이 많은 게임 PM들에게 평범한 하루입니다. 이 글은 모델 내부 작동 방식(model internals)을 설명하거나 도구를 나열하지 않습니다. Hao가 실제로 운영해 본 시스템만을 다룹니다.

첫째, 어디서 막히는지 파악하세요

Hao가 관찰한 PM들 사이에서 AI 사용은 보통 세 단계로 나뉩니다.

1단계: '단순 질문(just asking)'입니다. AI는 검색 엔진처럼 사용됩니다. 특정 용어를 찾아보거나 문장을 다듬는 식이죠. 실제로 중요한 작업—메모, 주간 보고서, 문서 작성—은 건드리지 않기 때문에 절약되는 시간은 제한적입니다.

2단계: '줄다리기(tug-of-war)'입니다. AI에게 실제 작업을 주기 시작하지만 패턴은 익숙합니다. 첫 번째 답변이 틀리고, 설명을 해도 여전히 틀리며, 5~6차례의 왕복 작업이 오가고 반 시간이 지나면, 차라리 직접 작성하는 것이 더 빠르다고 결론 내립니다. 많은 사람들이 여기서 멈추고 "AI는 작동하지 않는다"라고 결정합니다.

3단계: '시스템' 구축하기. AI가 이미 프로젝트 배경을 파악하고, 사용자의 형식에 맞춰 작성하며, 첫 시도나 단 한 번의 수정만으로 활용 가능한 단계입니다. 이 단계에 이르러서야 회의록 같은 작업들이 진정으로 압축됩니다.

대부분의 경우 모델 자체가 부족한 부분이 아닙니다. 부족한 부분은 사용자님과 AI 사이의 작동하는 방법론(working method)입니다. Hao 역시 힘겨루기 단계(tug-of-war stage)를 거쳤습니다. 이후 정착하게 된 방법론이 바로 '듀얼 카드 시스템'입니다.

듀얼 카드 시스템: 작업 할당을 위한 한 장의 카드, 초안 수정을 위한 한 장의 카드

두 개의 카드가 있습니다. 하나는 요청 사항을 정의하고, 다른 하나는 결과물을 수정합니다.

3C 카드는 세 가지 부분(Context, Components, Criteria)으로 요청 사항을 정의합니다. 약한 회의록 프롬프트는 “이 녹취록을 정리하는 것을 도와줘” 정도입니다. 3C 버전은 다음과 같습니다: 컨텍스트 — 이 회의는 디자인, 엔지니어링, 아트 팀이 참석한 주간 회의입니다; 컴포넌트 — 저는 결정 사항, 담당자가 명시된 실행 항목(action items), 그리고 위험 요소가 필요합니다; 기준 — 모든 실행 항목에는 마감일이 있어야 하며, 위험 요소는 높음(high), 중간(medium), 낮음(low)으로 등급화되어야 합니다.

CER 카드는 세 가지 부분(Context, Error, Request)으로 약한 초안을 수정합니다. 결과물이 충분하지 않다고 해서 “다시 써줘”라고 말해서는 안 됩니다. 문제점을 구체적으로 지적해야 합니다: 컨텍스트 — 방금 작성한 회의록입니다; 에러 — 실행 항목에 담당자가 없고, 회의에서 제기된 아트 관련 위험 요소 두 가지가 누락되었습니다; 요청 — 이 두 가지 공백을 채우고 나머지는 그대로 둬 주세요.

같은 종류의 작업임에도 불구하고, 정보 구조의 이러한 변화(모델 자체가 아닌) 덕분에 왕복 횟수가 5~8라운드에서 단 한두 번으로 줄어들었습니다.

이것을 잘못 적용할 수도 있는 쉬운 방법도 있습니다. Hao는 한때 모호한 개요서로 AI에게 도구 제작을 요청했습니다. 그 결과, 승인(Acceptance), 디버깅(debugging), 그리고 반복적인 수정 작업에 대부분의 시간이 소요되었고, 절약했던 실행 시간은 온전히 되돌려 받았습니다. 요청이 거칠수록 후반 단계에서 비용이 더 많이 듭니다.

다섯 가지 고빈도 워크플로우 (Five high-frequency workflows), 하나씩 다루기

다음 다섯 가지는 Hao가 검증했으며, 시간 절약 효과가 가장 명확했던 분야들입니다:

이 중 두 가지는 더 자세히 다룰 가치가 있습니다.

주간 보고서의 경우, 속도는 부수적인 효과입니다. 중요한 부분은 하나의 사실 집합에서 여러 버전으로 만드는 것입니다. 생산자(producer)를 위한 버전은 마일스톤과 위험 요소에 초점을 맞춥니다. 관리자(manager)를 위한 버전은 자원 및 일정에 중점을 둡니다. 팀을 위한 버전은 실행 항목(action items)에 초점을 맞춥니다. 이전에는 단 하나의 버전을 작성하는 것조차 부담스러웠습니다. 이제는 동일한 출처의 초안을 세 가지 독자별 버전으로 바꿀 수 있습니다.

위험 요소 포착의 경우, 변화는 화재 진압에서 순찰(patrol)로 넘어가는 것입니다. 팀이 이미 빠진 함정들을 모으고, 점검 규칙을 추가하며, AI가 프로젝트 문서와 회의록을 정기적으로 스캔하여 신호를 조기에 발견하도록 합니다. 항상 맞지는 않을 것입니다. 놓치는 것(miss)의 비용은 여전히 오경보(false alarm)의 비용보다 훨씬 높습니다.

만약 이 역할이 처음이라면, 먼저 회의록 작성부터 시작하세요. 이는 자주 발생하며, 잘못된 초안을 다시 만드는 것은 저렴합니다. 이미 프로젝트를 진행하고 있다면, 위험 요소 포착에 우선순위를 두세요. AI가 판단력을 가장 명확하게 증폭시킬 수 있는 영역입니다.

사용할수록 AI를 더 유용하게 만드는 방법

흔한 좌절감 중 하나는 모든 채팅이 '0'에서 시작한다는 것입니다. 프로젝트 내용을 재설명하고, 창을 닫으면 맥락(context)이 사라집니다. 원본 기사의 답변은 세 가지 요소를 함께 사용하는 것입니다:

• 프로젝트 배경, 용어집(glossary), 과거 결정 사항 등이 담긴 **지식 기반(knowledge base)**을 마련하여 필요할 때 AI가 참조하도록 할 수 있습니다. 한 번 정의하고 지속적으로 유지되는 출력 표준을 정하는 **규칙(Rules)**도 중요합니다. 예를 들어, “주간 보고서는 항상 진행 상황보다 위험 요소를 먼저 다룬다”와 같은 규칙입니다. 또한, 이미 처리했던 위험 사례나 작성했던 문서들로 구성된 **예시 라이브러리(example library)**를 활용하면, AI의 제안이 일반적인 웹 콘텐츠가 아닌 사용자의 실제 이력에 기반하게 됩니다.

이 세 가지 요소가 갖춰지면, 글쓰기가 마치 오랜 동료가 작성한 것처럼 보이기 시작합니다. 변화는 점진적입니다. Hao의 경험상, 보통 2~3주 정도 지나야 그 변화를 체감할 수 있습니다.

그 다음: 자체 개선 루프(self-improving loop), 아직 테스트 중

작년 하반기부터 원문 기사 작성 시점까지, Hao는 AI를 사용하여 여러 소규모 도구를 만들었지만 충분히 논의되지 않은 함정에 빠졌습니다. 바로 '수요 고갈'입니다. 도구는 완성되었고, 해결해야 할 문제(pain)가 사라지면서 다음에 AI에게 무엇을 요청해야 할지 명확하지 않아 사용하지 않는 크레딧이 방치되는 것입니다.

Hao의 관점에서 볼 때 병목 현상은 인간 측면에 있습니다. AI의 실행 대역폭은 확장될 수 있지만, 사람이 새로운 필요를 감지하는 능력이나 업무를 받아들일 수 있는 시간은 같은 방식으로 확장되지 않습니다. 2025년 BCG가 실시한 소프트웨어 개발자 설문조사에 따르면 응답자의 85% 이상이 여전히 작업 지원(task-assist) 및 위임(delegation) 단계에 머물러 있었으며, 반(半) 자율 협업 또는 더 깊은 단계에 도달한 비율은 10% 미만이었습니다. 같은 해 McKinsey의 글로벌 설문조사에서는 응답자의 88%가 조직이 최소 한 가지 비즈니스 기능에서 정기적으로 AI를 사용한다고 답했지만, 대부분의 조직은 여전히 실험(experiment) 또는 파일럿 단계에 머물러 있었습니다. 두 설문조사는 서로 다른 인구 집단과 정의를 사용합니다. 원문 기사에서는 이 점을 단지 상기시켜주는 차원에서 다루고 있습니다. 즉, 도구를 사용할 수 있다는 것이 워크플로우 자체를 재설계했다는 것과는 다르다는 것입니다.

하오(Hao)가 현재 시도하는 작업 방식은 '자가 진화 플라이휠(self-evolving flywheel)'입니다. 주기적으로 AI가 업무 기록을 읽고, 가능한 개선점을 찾아 제안하며, 사람이 이를 선택하고 확인하는 과정이 반복됩니다. 감지하고(Sense), 진단하며(diagnose), 행동하고(act), 피드백을 제공하는 것입니다. 각 순환 고리(loop)는 AI에게 작업에 대해 조금씩 더 많은 것을 가르칩니다. 본문은 이 플라이휠 역시 아직 실험 단계임을 명확히 밝힙니다. 트리거와 필터가 여전히 조정되고 있는 중입니다. 하지만 방향성은 더욱 분명해졌습니다. 향후 몇 년 동안, PM들 사이의 격차는 '누구의 AI 시스템이 스스로 개선되는가'라는 새로운 질문이 될 수 있습니다.

시작 체크리스트

• 아직 '질문만 하는(just asking)' 단계에 머물러 있는 경우: 내일 회의 하나를 골라 녹취하고, 이를 AI에게 제공한 뒤 3C 카드를 사용하여 작업을 할당해 보세요. 이것을 단 한 번이라도 해보면 첫 번째 단계를 벗어날 수 있습니다.
• 줄다리기(tug-of-war)에 빠져 있는 경우: 처음부터 새로운 채팅을 시작하지 마세요. CER 카드(CER card)를 사용해 수정하세요. 구체적인 문제점을 명시하고 변경 범위를 제한해야 합니다. 만약 한두 번의 시도에도 여전히 사용할 수 있는 결과물이 나오지 않는다면, 돌아가서 3C 카드를 고치세요.
• 효율성을 시스템으로 전환할 준비가 된 경우: 프로젝트 배경에 대한 내용이 단 한 페이지일지라도 지식 기반(knowledge base)을 만드세요. 이것이 나중에 복리 효과를 내는 기반이 됩니다.
• 이미 프로젝트를 진행하고 있는 경우: 위험 사례 라이브러리(risk-example library)를 구축하세요. 그래야 AI가 당신이 자리를 비웠을 때도 문제를 감지할 수 있습니다.

결국 이 방법론은 하나의 아이디어로 요약됩니다. AI를 숭배해야 할 신(god)으로 대하는 것이 아니라, 훈련시켜야 할 동료(colleague)로 다루는 것입니다. 일주일 동안 프로젝트, 형식, 그리고 표준을 가르치는 데 시간을 투자하면, 그 이후부터 매일 그 시간이 보상받게 될 것입니다.

FAQ

게임 PM이 AI를 사용해 본 적이 없다면 어디서 시작해야 할까요?
회의록(meeting notes)부터 시작하세요. 회의록은 거의 매일 발생하며, 결과가 좋은지 즉시 확인할 수 있고, 만약 AI가 엉망으로 만들더라도 메모만 다시 정리하면 됩니다. 이 워크플로우가 원활해지면 주간 보고서와 문서로 넘어가세요.

AI 출력을 그대로 외부로 보낼 수 있나요?

아닙니다. 그리고 그렇게 해서는 안 됩니다. AI가 초안과 구조를 담당합니다. 사용자가 사실(facts)과 판단(judgment)을 책임져야 합니다. 노트의 결정 사항, 주간 보고서의 숫자, 위험 등급 모두 인간의 검토가 필요합니다. 유용한 사고방식은 이를 인턴이 작성한 초안으로 취급하는 것입니다. 당신은 승인을 건너뛰는 것이 아니라, 작성을 위한 시간을 절약하고 있는 것입니다.

만약 경력이 없는 상태에서 게임 PM으로 직업을 전환하려는 경우, 먼저 AI 도구를 배워야 할까요?

아닙니다. 순서를 뒤집지 마세요. 먼저 프로젝트 관리(project-management)의 기본 사항—프로세스, 커뮤니케이션, 그리고 위험 감각—을 배우십시오. 이것들이 "1"입니다. AI는 그 다음에 오는 "0"입니다. 근본적인 관리 판단이 없다면, AI는 단지 평범한 결과물을 더 빨리 생산하도록 도울 뿐입니다. 입문 경로에 대해서는 게임 프로젝트 관리에 대한 공개된 종합 가이드를 참고하십시오.

이 방법은 게임 외의 인터넷 산업 PM에게도 적용될까요?

방법 자체는 일반적이지만, 상황(scenes)은 다릅니다. 게임 개발은 디자인, 엔지니어링, 아트, 오디오가 병렬로 진행되는 더 무거운 크로스펑셔널 작업(cross-functional work)을 수반하기 때문에, 정렬 작업—노트, 요구사항(requirements), 프로세스 문서—이 많은 인터넷 제품 환경보다 더 가치 있게 느껴지는 경우가 많습니다. 버전 주기 관리(Version-cadence management)는 게임에 특화된 무거운 영역이며, 원문 기사에서는 이 부분을 나중에 다루기로 했습니다.

저자 및 출처

하오(Hao)는 약 10년 경력의 게임 프로젝트 매니저이며, PMNote(하오의 게임 PM 노트)의 저자입니다.
이 영어 버전은 원본 중국 기사에서 각 사례, 시기, 또는 소스 페이지에 없는 설문조사 수치를 추가하지 않고 각색되었습니다:
지식 기반, 규칙 및 템플릿에 대한 더 자세한 내용은 AI for game PM 주제 아래 https://pmnote.ai 에서 확인할 수 있습니다. 위챗 미니 프로그램 입구를 원한다면, 위챗에서 「Hao的游戏PM笔记」를 검색하십시오.
원문 기사 출처:

• BCG(보스턴 컨설팅 그룹), AI 도입 퍼즐(The AI Adoption Puzzle), 2025년 (소프트웨어 개발자들 사이의 AI 협업 단계 분포) - McKinsey(맥킨지), 2025년 AI 현황(The State of AI in 2025) (조직적 AI 사용 및 확장 단계)