도철

모두가 동의해야 프로세스를 바꿀 수 있을까요?

2026-10-02T05:48:15Z

개발을 하다 보면 새로운 프로세스가 필요한 순간이 있습니다. 요청이 누락되지 않도록 접수 방식을 정하거나 코드 리뷰 기준을 맞추거나 배포 전 확인 절차를 마련하는 일입니다. 반복되는 문제를 줄이고 함께 일하기 위해 제안하지만 모두가 같은 필요를 느끼는 것은 아닙니다. 누군가는 "이제 정리가 되겠다"고 생각하고 누군가는 "해야 할 일이 하나 더 생겼다"고

작업이 지연될 때 개발 PM이 살펴야 할 것 - 진행 상황과 함께 이어질 작업의 일정까지 확인하는 과정

2026-09-28T08:00:36Z

"조금만 더 보면 될 것 같습니다." 오후 세 시, 개발자가 말합니다. 두 시에 시작하기로 한 플레이 테스트는 접속 오류로 아직 시작하지 못했습니다. 다행히 유력한 원인을 찾았다고 합니다. 곧 해결될 수도 있습니다. 여기까지 기다렸는데 테스트를 내일로 옮기기는 아쉽습니다. 그런데 QA의 이야기는 다릅니다. "지금 시작해도 오늘 예정된 범위를 전부 보기는

게임을 좋아하면 게임 개발 PM도 잘할 수 있을까요?

2026-09-16T09:52:59Z

게임을 좋아하는 마음은 게임 개발 PM의 일을 이해하는 데 도움이 됩니다. 다만 그 자체로 일을 잘하게 해주는 것은 아닙니다. 중요한 것은 그 관심을 개발 과정과 동료의 일을 이해하는 데 어떻게 연결하느냐라고 생각합니다. 게임을 많이 해본 경험은 분명 쓸모가 있습니다. 개발팀이 이번 전투는 타격감이 부족하다 또는 이 보상 구조로는 반복 플레이를 이어가기

개발 완료인데 작업 일정은 끝나지 않았습니다. - 완료를 세분화하여 관리한 이유

2026-08-19T13:33:25Z

"개발 완료됐습니다." 그런데 막상 빌드를 확인하면 수정할 부분이 발생하는 경우가 있습니다. 예를들어 기본 동작에 이슈가 있거나 구현 결과가 기획 의도와 다른 경우도 있습니다. 일정표에는 개발 완료라고 적혀 있지만 실제로는 개발 일정이 더 필요한 상황입니다. 왜 이런 일이 생길까요? 같은 완료를 다르게 이해하기 때문입니다 프로젝트에서 개발 완료라는

정식 스크럼을 변형해서 장기 태스크 관리해보기

2026-08-17T12:51:02Z

게임 개발에는 스크럼을 적용하기 어렵다고 생각하는 사람도 있을 수 있습니다. 직군마다 작업을 시작하고 마치는 시점이 다르고 모든 참여자가 하나의 기능에만 전담으로 투입되기도 어렵습니다. 아트 리소스 제작이나 기술 R&D처럼 짧은 기간 안에 완료된 결과물을 내기 어려운 작업도 있습니다. 출시나 업데이트 일정이 정해져 있다면 스프린트의 결과에 따라 범위와 우선

개발 PM은 언제 프로젝트에 투입되어야 좋을까요 - 문제가 생긴 뒤보다 일하는 방식을 함께 고민할 수 있을 때

2026-08-08T13:15:27Z

"필요성은 이해하지만, 지금 바꾸기는 어렵습니다." PM으로 프로젝트에 합류한 뒤 이런 이야기를 들은 적이 있습니다. 당시 프로젝트는 일하는 방식이 이미 상당 부분 자리 잡은 상태였습니다. 저는 현재 방식의 장단점과 개선했을 때 기대할 수 있는 효과를 정리해 제안했지만 개발이 한창 진행되는 상황에서 익숙한 방식을 바꾸기는 어렵다는 답을 듣기도 했습니다.

같은 프로젝트인데 서로 다른 계획을 떠올리면 위험하다 - 디렉터와 PM간 방향과 실행 조건을 계속 동기화하는 과정이 필요한 이유

2026-08-06T12:55:31Z

디렉터에게 요청받은 내용을 PM이 담당 부서에 작업요청하거나 공유합니다. 그럼 이어서 작업자는 묻습니다. 이 작업은 왜 지금 해야 하나요?기존 작업보다 우선순위가 높은가요?일정 안에 모두 하기 어렵다면 무엇부터 해야 하나요? PM이 프로젝트의 방향과 판단의 배경을 충분히 이해하지 못했다면 다시 확인해보겠습니다라고 답할 수밖에 없습니다. 물론 확인이

PM에게 필요한 긍정적인 태도란 무엇인가

2026-08-08T14:15:02Z

이직을 준비하며 PM 채용 공고를 살펴보면 '긍정적인 태도로 협업할 수 있는 분'이라는 문장을 종종 만나게 됩니다. 처음에는 조금 당연한 조건처럼 보였습니다. 긍정적인 사람을 싫어하는 회사도 있을까? 그런데 PM에게 굳이 긍정적인 태도를 요구하는 이유가 무엇인지 생각해보면 이 문장이 마냥 단순하지만은 않았습니다. 저도 한동안 긍정적인 태도의 의미를 잘못

PM이 자주 하는 말, 확인해보겠습니다

2026-08-01T02:57:08Z

PM으로 일하다 보면 자주 하게 되는 말이 있습니다. 확인해보겠습니다. 이 말은 생각보다 조심스럽습니다. 바로 답하지 못하는 사람처럼 보이거나 PM인데 이것도 모르나?라는 인상을 줄 수도 있기 때문입니다. 하지만 프로젝트에서는 빠른 답보다 확인된 답이 더 중요할 때가 있습니다. 아직 논의 중인 내용을 확정된 것처럼 전달하거나 일부 정보만으로 영향이 없

이번 빌드에 왜 이 작업이 들어갔을까 - 계획한 작업과 실제 빌드 사이, 커밋 로그가 필요한 이유

2026-07-31T06:19:09Z

계획한 배포 범위와 실제 빌드의 내용이 달라진 적이 있었습니다. 포함하기로 합의되지 않은 작업이라면 이번 배포에 들어가도 되는지 다시 판단해야 하고 경우에 따라서는 해당 작업을 제외한 빌드를 다시 만들어야 합니다. 이럴 때 확인하게 되는 것 중 하나가 커밋 로그입니다. 그런데 커밋 메시지가 ‘수정’, ‘오류 처리’, ‘요청 사항 반영’으로만 남아 있다면

프로젝트에는 왜 따로 관리하는 사람이 필요한가 - 프로젝트라는 숲을 바라보는 개발 PM

2026-08-08T14:36:32Z

게임 개발 프로젝트에서는 여러 직군이 함께 일합니다. 각 직군은 자신의 전문 영역에서 중요한 판단을 내리고 맡은 결과물의 완성도를 높이는 데 집중합니다. 그렇게 각자의 역할이 모여 하나의 게임이 만들어집니다. 그렇다면 프로젝트를 따로 관리하는 직군은 왜 필요할까요. 프로젝트는 개별 작업이 잘 진행된다고 해서 자연스럽게 완성되지는 않습니다. 하나의 작업에

일정 관리는 부담스러운데도 필요한 이유

2026-08-08T14:15:30Z

프로젝트에서 일정 이야기가 나오면 분위기가 잠시 달라질 때가 있습니다. 일정 문의가 작업의 진행 상황을 확인하는 질문이 아니라 업무를 시간으로 평가받는 질문처럼 들릴 수 있기 때문입니다. 하지만 일정이 밀렸다는 사실만으로 담당자의 잘잘못을 판단하는 것은 위험합니다. 개발 과정에서 일정이 밀리는 데에는 작업 범위 변경과 선행 작업 지연 그리고 예상하지 못한

개발PM은 킥오프를 통해 작업의 출발선을 맞춘다 - 회의 전 준비부터 액션아이템 확인까지

2026-07-28T10:46:20Z

킥오프 회의는 프로젝트나 특정 작업을 본격적으로 시작하기 전에 관련자들이 모여 목표와 범위 진행 방식 등을 맞추는 자리입니다. 보통은 기획서나 작업 문서가 어느 정도 정리된 시점에 진행하게 됩니다.저는 킥오프가 필요한 이유를 작업을 시작하기 전에 서로 같은 기준을 보고 있는지 확인하는 데 있다고 생각합니다. 문서가 있고 담당자가 정해져 있으면 바로 작업을

프로젝트 작업은 목록을 정리하는 것에서 시작된다

2026-07-28T01:17:09Z

개발 PM 채용 공고를 보면 담당 업무의 첫 줄에 자주 등장하는 문장이 있습니다. 프로젝트 일감 및 일정 관리 짧고 익숙한 문장입니다. 그중 먼저 이야기하고 싶은 것은 일감 정리입니다. 프로젝트에서 일감은 단순히 해야 할 일을 나열한 목록이 아닙니다. 프로젝트가 어떤 목표를 향해 가고 있는지 그리고 그 목표를 위해 어떤 작업이 필요한지 정리한 기준에

11년차 게임 개발 PM 나는 아직도 PM 일을 묻다 - PM으로 일하며 생긴 질문들을 하나씩 기록해보려 합니다

2026-07-27T04:05:50Z

저는 11년차 게임 개발 PM입니다. 처음 PM 일을 시작했을 때는 이 일이 비교적 명확하다고 생각했습니다. 일정을 관리하고 회의록을 정리하고 팀 간 작업을 조율하는 일. 누가 언제까지 무엇을 해야 하는지 확인하고 회의에서 나온 내용을 문서로 남기고 필요한 사람에게 필요한 정보를 전달하는 일. 지금 생각해도 완전히 틀린 부분은 아니었습니다. 일정 관리와