이 글에서 다루는 내용
- 프로젝트 관리 도구가 있어도 이슈 관리가 자동으로 되지 않는 이유
- 회의록을 PM이 써야 하는지, 담당 기획자가 써야 하는지에 대한 고민
- 실행으로 이어지는 회의록에 필요한 액션 아이템 구조
- AI 회의록 요약을 사용할 때 PM이 마지막으로 판단해야 하는 부분
게임 개발 PM 일을 하다 보면 회의록을 자주 쓰게 됩니다. 그런데 막상 회의에 참여해서 회의록을 작성하다보면 생각보다 애매합니다. 회의 내용을 전부 받아 적자니 너무 길어지고, 간단히 적자니 나중에 “그래서 누가 하기로 했죠?”라는 말이 나옵니다.
특히 게임 개발처럼 기획, 개발, 아트, QA, 사업, 운영이 계속 얽히는 환경에서는 회의록이 단순한 기록물로 끝나면 안 됩니다. 회의록은 회의가 끝난 뒤 실제 작업이 움직이게 만드는 도구에 가까워야 합니다.
저도 처음부터 그렇게 생각했던 것은 아닙니다. 예전에는 회의록을 “회의에서 나온 이야기를 정리하는 문서” 정도로 봤습니다. 그런데 여러 프로젝트를 거치면서 생각이 조금 바뀌었습니다. 중요한 건 회의에서 무슨 말이 오갔는지가 아니라, 회의 이후 무엇이 실행되는가였습니다.
프로젝트 관리 도구가 있어도 일이 자동으로 관리되지는 않는다
최근 참여했던 프로젝트에서는 이미 사용되고 있는 프로젝트 관리 도구가 있었습니다. 이슈를 만들고, 담당자를 지정하고, 상태를 업데이트하고, 일정에 맞춰 진행 상황을 확인할 수 있는 구조 자체는 갖춰져 있었습니다.
문제는 도구가 있다고 해서 모두가 자연스럽게 잘 쓰는 것은 아니라는 점이었습니다.
개발자분들 중에는 작업 상황 업데이트를 어려워하는 경우가 있었고, 일정이 지났는데도 상태가 그대로 남아 있는 경우도 있었습니다. 이슈 관리가 되어야 하는데 실제로는 PM이 계속 확인하고, 물어보고, 다시 알림을 주는 일이 반복됐습니다.
물론 개발자분들이 일을 안 해서 그런 것은 아니었습니다. 오히려 각자 작업은 바쁘게 하고 있었습니다. 다만 개발 중에는 구현, 버그 수정, 리뷰, 긴급 대응이 계속 밀려오다 보니 관리 도구 업데이트는 뒤로 밀리기 쉬웠습니다. 게임 개발 현장에서는 이런 일이 생각보다 자주 생깁니다. 일을 안 하는 것이 아니라, 일이 너무 많아서 일의 상태를 정리하는 일이 밀리는 겁니다. 약간 억울하지만, PM은 그 밀린 상태를 보고 불안해지는 사람이고요.
이때 회의록과 액션 아이템 정리는 꽤 중요한 역할을 했습니다. 회의에서 나온 내용을 그냥 문장으로 남기는 것이 아니라, 누가 무엇을 언제까지 해야 하는지 확인하고, 필요하면 PM이 이슈를 생성해서 추적할 수 있도록 만드는 방식이 필요했습니다.
게임 개발 PM의 역할 자체가 궁금하다면, 이전에 쓴 게임 개발 PM은 무슨 일을 할까? 실무에서 느낀 진짜 역할 글에서 조금 더 넓은 관점으로 정리해두었습니다.
회의록은 PM이 써야 할까, 담당 기획자가 써야 할까?
개발 미팅을 하다 보면 한 번쯤 나오는 논쟁이 있습니다.
“회의록은 PM이 작성해야 하나요, 아니면 담당 기획자가 작성해야 하나요?”
PM 입장에서는 억울할 수 있습니다. 모든 개발 사항을 깊이 이해하고 있는 것은 아니기 때문입니다. 시스템의 세부 스펙, 예외 처리, 밸런스 의도, 구현 방식까지 모두 파악하지 못한 상태에서 회의록을 정리하려면 부담이 큽니다. 잘못 정리하면 오히려 혼선을 만들 수도 있습니다.
반대로 기획자 입장에서도 할 말이 있습니다. PM이 회의에 참여하고 있다면 회의록 정리 정도는 서포트해줄 수 있지 않느냐는 생각이 들 수 있습니다. 담당 기획자는 이미 스펙 작성, 개발 대응, QA 확인, 밸런스 조정까지 하고 있는데 회의록까지 매번 담당하면 부담이 커질 수 있습니다.
둘 다 맞는 말입니다. 그래서 이 문제는 “누가 무조건 써야 한다”로 정리하기보다, 회의록의 목적을 먼저 정리하는 것이 중요했습니다.
회의록의 목적이 세부 스펙을 정확히 문서화하는 것이라면 담당 기획자의 역할이 더 중요합니다. 하지만 회의 이후의 결정사항, 액션 아이템, 담당자, 마감일, 리스크를 빠르게 공유하고 추적하는 것이라면 PM이 정리하는 것이 더 효과적일 수 있습니다.
결국 저희는 PM이 녹음 내용을 텍스트로 변환하는 앱과 AI를 활용해 회의록을 빠르게 정리하고 공유하는 방식으로 정리했습니다. 물론 일부 기획자분들은 본인이 따로 더 상세한 내용을 정리해서 공유하기도 했습니다.
이 방식은 꽤 효과가 있었습니다. 회의록 정리에 들어가는 코스트를 크게 줄일 수 있었고, 놓치는 부분도 줄어들었습니다. 무엇보다 회의가 끝난 뒤 빠르게 공유할 수 있다는 점이 좋았습니다. 회의록은 며칠 뒤에 올라오면 이미 반쯤 의미가 사라집니다. 그때는 다들 다음 불을 끄고 있거든요.
좋은 회의록은 길지 않아도 된다
제가 회의록을 정리할 때 중요하게 생각했던 것 중 하나는 “너무 길게 쓰지 않는 것”이었습니다.
회의 내용은 안건별로 문단을 나누고, 각 안건마다 3~4줄 정도로 간략하게 정리했습니다. 이유는 단순합니다. 회의록이 길면 사람들이 잘 안 읽습니다.
회의에 참석했던 사람도 안 읽고, 참석하지 못했던 사람은 더 안 읽습니다. 긴 회의록은 작성한 사람에게는 성실함의 증거처럼 보이지만, 읽는 사람에게는 또 하나의 업무가 됩니다.
그래서 저는 자잘한 논의 내용은 과감히 제외하고, 결정사항과 중요한 논의 위주로 정리하려고 했습니다.
- 무엇이 결정됐는가?
- 왜 그렇게 결정됐는가?
- 누가 무엇을 해야 하는가?
- 언제까지 해야 하는가?
- 추가 확인이 필요한 것은 무엇인가?
이 정도가 명확하면 회의록은 충분히 역할을 할 수 있습니다. 물론 이게 항상 쉬운 것은 아닙니다. 저는 기획자로 일해본 경험이 있고, 실제 라이브 게임을 깊게 플레이하면서 개발 내용을 어느 정도 이해하고 있었기 때문에 가능한 부분도 있었습니다. 반대로 해당 게임의 구조나 개발 맥락을 충분히 파악하지 못한 PM이라면 모든 내용을 이렇게 정리하기 어려울 수 있습니다.
그래서 더더욱 회의록의 역할을 명확히 나눌 필요가 있습니다. PM이 모든 스펙을 완벽하게 정리할 필요는 없습니다. 대신 회의 이후 일이 움직이도록 결정사항과 액션 아이템을 잡아주는 역할은 할 수 있습니다.
회의록을 구조화하는 방식은 팀마다 다르지만, Atlassian의 meeting notes 가이드처럼 결정사항과 후속 액션을 명확히 남기는 방향은 여러 협업 환경에서 공통적으로 중요하게 다뤄집니다.
액션 아이템에는 담당자와 마감일이 있어야 한다
회의록에서 가장 중요한 부분은 액션 아이템입니다. 그리고 액션 아이템에는 반드시 담당자와 마감일이 있어야 합니다.
“추후 확인 필요”라고만 적혀 있는 항목은 사실상 아무도 하지 않을 가능성이 높습니다. “개발팀 확인 필요”도 비슷합니다. 개발팀의 누가 확인해야 하는지, 언제까지 확인해야 하는지 없으면 회의록 안에서는 그럴듯해 보여도 실제 업무로는 잘 이어지지 않습니다.
좋은 액션 아이템은 조금 건조해도 됩니다.
- A 기능 예외 케이스 처리 방식 확인 — 담당자: ○○ — 마감: 6월 7일
- B 콘텐츠 보상 수량 수정안 재검토 — 담당자: ○○ — 마감: 다음 밸런스 회의 전
- C 버그가 의도된 스펙인지 확인 — 담당자: 기획 ○○ / 개발 ○○ — 마감: 오늘 중
문장이 예쁘지 않아도 괜찮습니다. 중요한 건 실행 가능해야 한다는 점입니다.
담당자나 마감일이 명확하지 않은 부분이 있다면 PM이 다시 확인하고, 필요하면 프로젝트 관리 도구에 이슈를 생성해서 처리할 수 있도록 서포트해야 합니다. 이 부분이 회의록과 프로젝트 관리 도구가 연결되는 지점입니다.
게임 개발 회의록이 어려운 이유는 변동성이 크기 때문이다
게임 개발 회의록이 어려운 이유는 단순히 내용이 많아서가 아닙니다. 변동성이 크기 때문입니다.
특히 PD나 주요 의사결정자가 회의 중에 돌발 이슈를 가져오거나, 현재 진행 중인 개발 사항을 갑자기 바꾸는 경우가 있습니다. 이때 PM 입장에서는 일정과 스펙 관리가 굉장히 어려워집니다.
PD의 한마디는 영향력이 큽니다. 방향성이 바뀌면 기획서가 바뀌고, 개발 일정이 바뀌고, QA 범위가 바뀌고, 때로는 이미 구현한 것을 다시 봐야 할 수도 있습니다. 특히 개발 마감 직전에 스펙이 바뀌면 리스크는 훨씬 커집니다.
이런 상황에서 회의록은 단순히 “PD님이 이렇게 말씀하셨다”를 남기는 문서가 아니어야 합니다. 그 말이 실제 일정과 작업 범위에 어떤 영향을 주는지까지 연결해서 봐야 합니다.
예를 들어 이런 식입니다.
- 변경된 스펙이 기존 일정에 영향을 주는가?
- 추가 개발 범위가 생기는가?
- QA 일정이나 테스트 범위가 바뀌는가?
- 기존에 합의한 우선순위와 충돌하는가?
- 이번 버전에 반드시 들어가야 하는가, 다음 버전으로 넘길 수 있는가?
회의록에 이런 리스크가 남아 있으면 나중에 다시 논의할 근거가 생깁니다. 반대로 이런 맥락 없이 결정사항만 짧게 남기면, 나중에는 “그때 왜 이렇게 하기로 했죠?”라는 질문이 다시 돌아옵니다. 그리고 그때부터 기억력 게임이 시작됩니다. PM에게 별로 유리하지 않은 게임입니다.
AI 회의록은 시간을 줄여주지만, 판단까지 대신해주지는 않는다
저는 클로드를 활용해 회의록 요약을 진행했고, 정리된 내용을 슬랙에 공유했습니다. 녹음 내용을 텍스트로 전환한 뒤 AI로 요약하면 확실히 속도가 빨라집니다.
특히 좋은 점은 초안 작성에 들어가는 부담이 크게 줄어든다는 것입니다. 회의가 끝난 직후 피곤한 상태에서 빈 문서를 열고 처음부터 정리하는 일은 생각보다 에너지를 많이 씁니다. AI를 활용하면 일단 정리된 초안이 나오고, PM은 그것을 검토하면서 중요한 내용만 다듬을 수 있습니다.
하지만 AI가 모든 것을 해결해주지는 않았습니다. 요약은 잘하지만, 맥락 판단은 결국 사람이 해야 했습니다.
AI는 회의 중 많이 언급된 내용을 중요하게 볼 수 있습니다. 하지만 실제 프로젝트에서는 짧게 지나간 한마디가 더 중요할 때도 있습니다. 예를 들어 “이건 다음 빌드에 꼭 들어가야 합니다” 같은 말은 짧게 나왔더라도 일정과 우선순위에 큰 영향을 줍니다. 반대로 길게 논의했지만 결론이 나지 않은 내용은 액션 아이템이 아닐 수도 있습니다.
그래서 AI 회의록은 그대로 복사해서 공유하기보다, PM이 마지막으로 한 번 정리해야 합니다. 녹음이 가능하다고 해서 회의 내용을 주의 깊게 듣지 않으면 마무리 정리는 어렵습니다. 회의 내용을 전혀 모르는데 정리를 한다는건 불가능한 일이겠지요.
- 결정사항이 맞게 정리됐는지
- 담당자와 마감일이 빠지지 않았는지
- 보류된 내용을 결정된 것처럼 쓰지 않았는지
- 리스크가 충분히 드러나는지
- 슬랙에 공유했을 때 사람들이 바로 이해할 수 있는지
AI는 회의록 작성 시간을 줄여주는 도구입니다. 하지만 회의록을 실행 가능한 형태로 바꾸는 일은 여전히 PM의 역할에 가깝습니다.
AI를 게임 기획자와 PM 업무에 어떻게 활용할 수 있는지는 이전 글인 게임 기획자와 PM은 왜 AI를 써야 할까?에서도 다룬 적이 있습니다.
회의록은 빠르게 공유될수록 가치가 크다
회의록은 가능하면 회의가 끝난 직후에 공유하는 것이 좋습니다. 급한 일이 없다면 미팅이 끝나고 바로 작성해서 공유하는 편이 가장 효과적입니다.
이유는 간단합니다. 회의 직후에는 모두가 맥락을 기억하고 있습니다. 누가 어떤 이야기를 했는지, 어떤 분위기에서 결정됐는지, 어떤 부분이 아직 애매한지 기억이 살아 있습니다. 이때 회의록이 공유되면 빠진 부분을 바로 보완할 수 있습니다.
반대로 하루 이틀 지나서 회의록이 올라오면 확인 비용이 늘어납니다. 사람들은 이미 다른 일을 하고 있고, 당시 맥락을 다시 떠올려야 합니다. 회의록을 읽고도 “이거 맞나요?”라는 질문이 다시 생길 수 있습니다.
완벽한 회의록을 늦게 공유하는 것보다, 중요한 결정사항과 액션 아이템을 빠르게 공유하는 쪽이 실무에서는 더 도움이 될 때가 많습니다.
제가 생각하는 개발 PM 회의록의 기본 원칙
지금까지 경험을 바탕으로 정리하면, 게임 개발 PM의 회의록은 다음 원칙을 지키는 것이 좋다고 생각합니다.
1. 모든 말을 적으려 하지 않는다
회의록은 녹취록이 아닙니다. 모든 논의 내용을 다 적으려고 하면 작성자도 힘들고, 읽는 사람도 힘듭니다. 중요한 것은 결정사항과 그 결정에 영향을 준 핵심 맥락입니다.
2. 결정사항과 논의 중인 내용을 구분한다
회의에서 나온 말이라고 해서 모두 결정된 것은 아닙니다. “검토해보자”, “가능할 수도 있다”, “일단 논의해보자”는 결정이 아닙니다. 결정된 내용과 아직 보류된 내용을 구분하지 않으면 나중에 큰 혼선이 생깁니다.
3. 액션 아이템에는 담당자와 마감일을 붙인다
담당자와 마감일이 없는 액션 아이템은 실행력이 약합니다. 애매하다면 PM이 회의 중이나 회의 직후에 다시 확인해야 합니다. “이건 누가 언제까지 보면 될까요?”라는 질문은 생각보다 중요합니다.
4. 리스크를 숨기지 않는다
스펙 변경, 일정 지연, QA 범위 증가, 의사결정 보류 같은 내용은 회의록에 남겨야 합니다. 리스크를 회의록에 남기는 것은 누군가를 탓하기 위한 것이 아니라, 팀이 같은 현실을 보고 움직이게 하기 위한 일입니다.
5. 공유 채널에 맞게 짧고 명확하게 쓴다
슬랙에 공유할 회의록이라면 너무 긴 문서보다 읽기 쉬운 구조가 중요합니다. 안건별로 짧게 나누고, 액션 아이템은 눈에 잘 띄게 정리하는 것이 좋습니다.
마치며: 회의록은 회의를 끝내는 문서가 아니라 일을 시작하게 만드는 문서다
게임 개발 PM에게 회의록은 단순한 기록 업무가 아닙니다. 회의에서 나온 논의를 실제 업무로 바꾸는 과정입니다.
프로젝트 관리 도구가 있어도 사람들이 항상 완벽하게 업데이트하지는 않습니다. 오히려 거의 안되는 경우가 부지기수입니다. 회의에서 좋은 이야기가 나와도 담당자와 마감일이 없으면 실행으로 이어지기 어렵습니다. 중요한 결정이 있었어도 빠르게 공유되지 않으면 각자 다르게 이해할 수 있습니다.
그래서 회의록은 회의를 예쁘게 정리하는 문서가 아니라, 팀이 같은 방향으로 움직이게 만드는 실행 도구에 가까워야 합니다.
AI를 활용하면 회의록 작성 비용은 확실히 줄일 수 있습니다. 하지만 무엇을 결정사항으로 볼지, 어떤 내용을 액션 아이템으로 만들지, 어떤 부분을 리스크로 남길지는 결국 사람이 판단해야 합니다. 그리고 그 판단을 가장 가까이서 할 수 있는 사람이 개발 PM일 때가 많습니다.
회의록을 잘 쓴다는 것은 말을 많이 적는다는 뜻이 아닙니다. 회의가 끝난 뒤 일이 흔들리지 않게 붙잡아주는 것에 가깝습니다. 요약하자면, “그래서 이거 누가 언제까지 하죠?”를 끝까지 놓치지 않는 일입니다.
화려하진 않지만, 실제 프로젝트에서는 이런 작은 정리가 꽤 큰 차이를 만듭니다.