NDC Replay

개발자를 위한 제작진행개론
이승재
넥슨코리아
스튜디오 공용 게임서버엔진을 개발하고 있습니다. <마비노기 듀얼>, <마비노기 2: 아레나>, <데스크탑 히어로즈>, <카바티나 스토리> 개발에 참여했습니다.
우리는 모두 우리가 만드는 게임이 성공하기를 바랍니다. 일정을 지키는 것보다는 성공하는 것이 더 중요하지요. 이 발표에서는 그럼에도 불구하고 일정대로 출시하려 노력해야 하는 이유, 그리고 그 방법에 대해 개요 수준에서 다룹니다 - 계획을 세우고, 실행하고, 도저히 해낼 수 없다면 어떻게든 하라, 그리고 그것을 개발 기간 내내 계속하라.<br style='line-height:240%'/>이 발표가 밤새거나 휴일출근하지 않고 일정대로 출시하는 데 조금이나마 도움이 되기를 바랍니다.
[새 창에서 슬라이드 보기]
안녕하세요. “일정대로 출시하기 왜 & 어떻게 개발자를 위한 제작 진행개론” 발표 시작하겠습니다.

저는 이승재고요. 저는 프로그래머고 2007년부터 게임을 만들어오고 있습니다. 지금 이제 11년째 접어들었네요. (깊은 한숨) 어떤 게임을 출시를 했지만 반응이 안 좋아서 서비스가 종료가 됐고요. 어떤 게임은 출시를 못하고 중단되는 것도 겪어봤고요. 다행히도 가장 최근에 참여한 <마비노기 듀얼>은 출시를 했고요. 지금도 서비스를 하고 있습니다. 오픈 2주년까지 얼마 안 남았네요. 여러 개의 프로젝트를 겪었는데 <카바티나 스토리>랑 <데스크탑 히어로즈>는 그 두 개는 본부가 달랐지만은 크게 봐서는 <메이플 스토리>를 만드셨던 분들의 문화를 계승한 곳이었고요. <마비노기 2>부터는 데브캣 스튜디오에서 일을 하고 있습니다. 이 두 조직의 개발 문화가 굉장히 달라요. 그런 아주 이질적인 개발 문화를 가진 두 곳에서 일을 5년씩 해보니까 그 차이가 눈에 많이 들어오더라고요. 저기서는 일을 이렇게 했었고 여기서는 이렇게 일을 하는데 어느 한 쪽이 절대적으로 옳은 것 같지는 않고요. 근데 이런 부분은 저쪽에서 잘하는 거를 떼와가지고 개선하면 좋을 것 같고 이런 생각이 들었어요.

오늘 말씀드릴 내용은 일종의 개론에 해당하는 얘기에요. 여기서 개발자라고 하면 프로그래머만을 의미하는 건 아니고요. 프로젝트에 참여하는 모든 사람을 대상으로 하는 얘깁니다. 어떤 분들한테는 이게 너무 당연한 얘기실 거예요. 아니 뭐 이런 걸 발표씩이나 하나? 당연히 이렇게 일하는 거 아니야? 이런 생각이 드실 수 있는데 저도 발표 신청을 하기 전에 좀 망설였어요. 이게 당연한 얘기한다고 욕하지 않을까? 비웃지 않을까? 근데 이런 어떤 일하는 방식 같은 게 각 조직의 개발 문화 형태로만 존재하지 무슨 발표 자료로 존재하거나 책으로 존재하거나 이런 거를 저는 보지를 못했단 말이죠. 그래서 이거를 발표의 형태로 정리를 해서 공유를 하면 이 주제에 대해서 함께 이야기를 해볼 수 있는 실마리가 되는, 일단 시작할 수 있는, 이야기를 시작할 수 있는 그런 의미가 있을 것 같아서 발표를 준비해봤습니다.

이 발표에서 다룰 범위는 신규 게임 프로젝트에요. 라이브는 다를 수 있고요. 게임이 아닌 거는 또 다를 수 있는데 공통점도 있을 수 있겠죠. 그런데 제가 경험한 시간의 거의 대부분은 신규 게임 프로젝트고 그래서 그 틀 안에서만 얘기를 해보도록 하겠습니다.

사실 이 발표는 저희 스튜디오 대상으로 내부 대상으로 한 번 했던 거예요. 당시의 제목은 지금 제목보다 좀 더 도발적인 제목이었어요. “밤새지 않고 휴일출근하지 않고 일정대로 출시하기” 일정대로 출시하기는 지금 세션 제목으로 남아있죠. 일정. 일정이라고 하는 단어는 여러 가지 감정이 생기는, 업계에서 오래 일하다 보면 일정이란 단어에 여러 가지 감정이 드는데 일정을 왜 들고 나와서 얘기를 할까? 프로그래머가. 일정이 뭐가 중요하길래.

사실 일정 지키는 거 중요하지 않습니다. 성공하는 데에 비하면요. 일정과 성공을 비교하면 당연히 성공 쪽이 훨씬 더 말도 안 되게 중요하죠. 게임 산업이 굉장히 도박적인데 성공할 확률이 되게 낮고 그런데 일단 대박이 나면 그 회수할 수 있는 이익이 너무너무 거대해요. 개발비 두 배, 세 배 이 정도 더 쓴 거는 문제도 아니죠. 앞으로 한 10년, 20년 이렇게 라이브를 하면서 그동안 계속 사업을 만들어내는 거예요. 새로운 사업을 만들어 내는 거예요. 계속 서비스하는 온라인 게임 내지는 모바일 게임을 만든다는 거는. 그런데 반대로 일정을 잘 지켰어요. 그래서 정확하게 계획한 대로 진행을 해서 프로덕션을 해서 안정적으로 출시를 했는데 실패를 하면 그건 그냥 실패를 한 거죠. 일정을 잘 지키는 거보다 성공하는 게 훨씬 중요해요. 훨씬 중요한데 그럼에도 불구하고, 그럼에도 불구하고 저는 일정을 지키자라고 얘기를 합니다. 그 얘기를 하려고 해요.

왜냐하면 성공할 가능성을 높이기 위해서에요. 몇 가지 이유를 생각해 볼 수 있어요. 프로젝트가 몇 년 뒤의 시장을 예측을 해서 킥오프를 하잖아요. 킥오프 한 시점이랑 출시가 멀어지면 멀어질수록 예측이 틀리고 성공할 가능성이 더 낮아지겠죠? 네, 트렌드가 빠르게 변하기 때문에 미래를 예측하는 게 되게 힘들고요. 프로젝트가 연기하고 연기를 하고 연기를 하고 이제 팀이 경영진을 상대로 보유를 하고 있는 신뢰가 전부 다 떨어지면 프로젝트가 취소가 되죠. 일단 출시는 하고 봐야 성공을 할지 말지를 얘기를 할 수 있는 거고요. 마지막으로는 적당한 제약 조건이 있을 때 사람들이 더 창의적이 된다고 하네요. 이 경우는 일정이고 개인적으로 저도 여러 번 겪어봤던 것 같아요.

또 특히 출시가 아주 가까워지면 변경이 불가능한 외부 스케줄이 잡히는데 예를 들어 마케팅 슬롯을 언제로 잡았다. 그러면 뭐, 애플느님께서 피처드를 이때 해주신다더라 그럼 무슨 수를 써서라도 그때 맞춰야 되죠. 슈퍼 갑 애플님에게 맞춰야 돼요.

원래 제목이 밤새지 않고 휴일 출근하지 않고 일정대로 출시하기 였고 일정대로 출시하는 부분에 대해서 얘기를 했어요. 근데 밤새거나 휴일 출근하면 안 되는 이유는 뭘까요? 밤새고 휴일 출근하는 거 좋아하십니까? 되게 싫은데 하하하하 삶의 질을 유지하기 위해서 밤새거나 휴일 출근하면 안 된다 당연한 얘긴데 물론 그렇기도 하지만은 저는 이렇게 얘기하고 싶어요. 밤새고 휴일 출근하는 게 더 느리기 때문이에요. 오늘 새벽 한 시에 퇴근하면 내일 과연 몇 시간이나 제정신으로 일을 할 수 있을까요? 제가 20대까지는 어떻게 됐던 것 같거든요? 어떻게든 됐던 것 같아요. 맨날 출시 전에 새벽 1시 2시까지 일하고 택시 타고 퇴근하고 런칭 전 몇 달을 그렇게 보냈던 것 같은데 제가 지금은 36살인데 절대 절대로 옛날처럼 되지 않습니다. 최근에 여기 살아있는 사례를 겪었는데요. 지난 일요일날 발표 준비를 하다가, 제가 이번 NDC에 발표를 3개 합니다. 이게 3번째 마지막 발표에요. 이거 하고 나면 저는 해방돼요. 발표 준비를 하다가 2시에 잤는데 그 다음날 월요일날 하루 종일 제정신이 아니다가 저녁을 먹고 나서부터 이제 좀 정신이 들더라고요. 휴식을 충분히 취하지 못하면 느려지는 것도 느려지는 건데 시야가 좁아져요. 최선의 판단을 하지 못하게 됩니다. 이게 저는 정말 정말 치명적인 문제라고 보고 이것도 옛날에 겪었던 적 있어요. 30대가 된 다음에 겪은 거죠. 이거는. 출시하면 다 끝나나요? 아니죠. 바로 라이브 들어가야 됩니다. 라이브 초기는 되게 중요한 시기에요. 모바일 게임은 더 그렇고. 한 번 떠난 유저는 돌아오지 않는다. 모바일 게임에서는. 그렇게 많이들 얘기하죠. 출시하고 나서도 라이브 페이스를 유지하려면 힘을 남겨둔 채로 라이브를 시작해야 됩니다. 그리고 오랫동안 건강하게 개발하기 위해섭니다. 무리하다 건강을 해치고 내가 이러려고 게임 개발자 했나 자괴감 들고 괴로운 건 싫죠.

밤새거나 휴일 출근하면 안 되는 또 다른 이유, 시간이 많이 남아있는 것처럼 착각하게 만들어요. 밤새면 되겠지 휴일 출근하면 되겠지 이런 생각이요. 대학교 다닐 때 미루고 미루다가 밤새서 과제하던 습관, 그다음에 사회 초년생 때 새벽까지 일해서 어떻게든 결과를 만들어내던 그 기억이 남아서 밤을 새고 주말 출근을 하면 뭔가 더 많이 해낼 수 있을 것 같은 그런 기분이 있잖아요. 그런데 그거 다 착각이에요. 절대로, 절대로 그렇지 않습니다. 물론 20대 땐 예외일 수 있어요. 그런데 밤 새면 어떻게 되겠지. 주말 출근하면 어떻게 되겠지. 이런 생각 때문에 일을 미루게 되고 딴짓을 하게 되고 그러다 보면 계획을 빨리 수정해서 최상의 결과를 얻을 수 있는 그런 기회를 놓치게 만듭니다. 우리한테 주어진 시간은 달력에 새겨진 업무일 * 8시간 딱 그만큼이에요. 더는 없어요.

밤새지 않고 휴일 출근하지 않고 일정대로 출시하는 것이 중요하다는 얘기를 지금까지 했고요. 출시하는 게 중요하다고 말씀드렸고 어떻게 하면 되는지 구체적으로 알아보겠습니다.

남은 일을 남은 기간 동안 해낼 수 있는 계획을 세우고 실행한다. 도저히 해낼 수 없다면 어떻게든 한다. 이것을 출시할 때까지 계속 반복한다. 이게 다예요. 이게 다인데 이제 하나씩 하나씩 디테일을 뜯어볼게요.

남은 일, 남은 일을 Listing을 해서 목록을 갖고 있어야 돼요. 갖고 있어야 되고 이후로도 계속 업데이트해야 되고 어떤 일들이 남아있는지 추적을 하는 이게 가장 기본이에요. 이게 안 되면 아무것도 계획을 할 수가 없어요. 이게 남은 일이 남은 시간 동안 다 못할 것 같아도 물리적으로 이걸 해내는 게 말이 안 될 것 같아도 어쨌든 리스트는 다 갖고 있어야 돼요. 우리가 해야 될 수도 있는 모든 리스트를 다 갖고 있어야 돼요. 남은 기간 동안 해낼 수 있는 계획을 세우고 실행한다. 이게 각 일이 아까 Listing 했던 그 일이 각각 얼마나 걸릴지 예측을 하고 일들 관계, 선후 관계를 확인하고 기간이 너무 길다 싶으면 적당 주기로 중간 목표를 세우고요. 어느 일을 누가 해야 되는지 파악을 하고 배정하고 그런 걸 합니다. 이 부분이 좀 어려운데요. 도저히 해낼 수 없을 수도 있어요. 계획을. 계획을 기간 내에 실행하는 게 도저히 불가능, 할 수가 없을 수가 있는데 이거를 계획하는 단계에서 알게 될 수도 있고 실행하는 단계에서 알게 될 수도 있어요. 여기서 어떻게든 한다. 어떻게든 하는 게 포인트에요. 여러 가지 방법이 있는데 비슷한 효과를 가지는 다른 방법으로 바꾸거나 담당을 다른 사람으로 바꾸거나 팀 외부 인력을 어떻게 동원을 하거나 아니면 그 일을 아예 빼버릴 수도 있죠. 뺄 시간이 없다면. 혹은 아까 전 절대로 하면 안 된다고 말씀을 드렸지만 금단의 방법을 쓸 수도 있습니다. 철야를 하고 휴일 출근을 하는 거죠. 정말 정말 최후의 수단으로 사채를 쓰는 기분으로 부작용을 이해를 하고 있는 상태에서 제한되게 사용한다면 할 수도, 절대 불가능한 일은 아니라고 생각해요. 8개월 연속 이런 건 절대 말도 안 되는 거고요. 자, 남은 일을 파악하고 계획을 세워서 실행하고 도저히 해낼 수 없다면 어떻게든 하는 거를 출시할 때까지 계속 계속 반복합니다. 왜 왜 계속 반복을 해야 될까요? 계획이 반드시 틀어지기 때문입니다. 계획은 반드시 틀어지게 되어 있어요.

아, 이거 해야 되는 줄 몰랐는데 하는 일이 생깁니다. 맨 처음 계획할 때는 자꾸 빼먹게 돼요. 이거 진짜 어쩔 수 없어요. 그리고 2주로 예상했던 일이 2주면 될 거야 생각했던 일이 3주 걸리는 일이 비일비재하게 생기죠? 그리고 집어넣으면 진짜 끝내줄 것 같은 아이디어가 개발 중간에 떠올라요. 그러기도 하고. 완벽한 계획을 세워놨는데 계속 어긋나게 되죠? 유혹이 생겨요. 어차피 계획대로 안 굴러갈 거 계획 안 세우면 안 되나? 어차피 깨지게 되는 어차피 어긋나게 되는 계획을 굳이 세워야 되나? 그런 유혹이 드는데 안 됩니다. 절대로 안 돼요. 프로덕션 계획을 지속적으로 업데이트하고 모든 팀원에게 공유를 해야 됩니다. 이거에 대해서도 좀 길게 얘기를 해볼게요.

이제 계획에 실패하면 실패를 계획하게 되는 거란 얘기가 있는데 개발을 하다 보면 만나게 되는 질문들이 있어요. 이런 거에 대답을 하지 못하거나 이상하게 대답을 하게 되면, 이상하게 결론을 내리게 되면 프로젝트가 산으로 가기 시작하는데 그거에 제대로 대답을 하려면 프로덕션 계획 큰 그림 이런 게 있어야 돼요. 하나씩 설명을 할게요.

이 일에 시간을 얼마나 써야 할까? 사진 보시겠습니다. 차바퀴가 7개죠. 오른쪽 뒷바퀴가 4개라서 하나 둘 셋 넷 다섯 여섯 일곱, 일곱 개에요. 바퀴 7개로 달리고 있는 자동차에요. 제정신 아니죠? 근데 과연 그럴까요? 급히 차를 써야 된다면 어떨까요? 제한 속도가 10km 이하로만 달릴 거라면 저래도 되지 않을까? 바퀴 갈아 끼울 돈이 없는데. 자 이제 공공도로를 달리는 자동차라는 맥락에서 내지는 공산품이라고 하는 그런 맥락에서 저 차를 보면 확실히 제정신이 아니에요. 그런데 우리가 일을 할 때 만나는 문제들에는 저런 식으로 마감을 하고 넘어가도 되는 경우가 있어요. 최종 프로덕트에 안 들어갈 거라면. 물론 이 차를 몰고 도로에 나가면 안 되죠. 어떤 문제에 대해서 어느 정도 퀄리티의 답을 찾아야 하는가? 그리고 우리가 마주치는 공학적인 문제들에는 해결책이 다양하게 있기 마련이고 비용도 천차만별이에요. 그중에서 적절한 답을 찾으려면 프로덕션 계획을 포함한 그 프로덕트의 큰 그림을 볼 수 있어야 돼요.

두 번째 기술 부채의 계획적인 운용인데요. 상위 결정권자는 신이 아니에요. 모든 구현 디테일을 다 알 수가 없어요. 그래서 모든 주제에 대해서 최선의 의사 결정을 최상의 의사 결정자가 모든 의사 결정을 다 할 수가 없죠. 특히나 결과, 눈에 보이는 결과에 차이가 없는 엔지니어링 이슈들은 프로그래머가 직접 판단을 해서 결정을 해야 돼요. 기술 부채가 대표적인 예고요. 기술 부채가 뭔지 좀 설명드릴게요. 

기술 부채란 거는 어떤 좁은 목표를 편법으로 빠르게 달성하는 거예요. 몇 가지 용도로 쓰이는데 눈에 보이는 걸 만들어서 비전을 공유를 하든가 아니면 중요한 마일스톤을 빨리 달성하든가 불확실성을 줄이기 위해서 사용을 하든가 그렇게 하는데 뭐 예를 들면 이렇게 하면 재밌지 않을까? 이런 아이디어가 떠오르면 그걸 바로 프로덕션 계획에 넣고 차곡차곡 만드는 게 아니라 그게 재밌는지를 검증하기 위한 최소한의 방법으로 빠르게 프로토타이핑을 해보는 거, 이것도 기술 부채고요. 그리고 이 기술을 안 써봤는데 과연 괜찮을까? 이것도 도입을 한다고 바로 결정을 하는 게 아니라 빠르게 써보고 괜찮을지, 안 괜찮을지, 어떤 장점이 있고, 어떤 단점이 있는지 어떻게 활용을 해야 될지 그걸 타이핑해보는 것도 기술 부채로 설명할 수 있고요. 그다음에 스테이지를 100개를 만들어야 되는데 이거 얼마나 걸릴지 모르겠다 하면 몇 개만 만들어보는 거예요. 그게 얼마나 걸릴지 판단해보는 거 그런 것도 기술 부채의 예라고 볼 수 있습니다. 투자자한테 보여줘서 우리 투자를 빨리 받아야 돼. 이것도 기술 부채를 내 가지고 시간을 아끼는 거죠. 

그림으로 보여드릴게요. 기술 부채의 살아있는 예입니다. 에스프레소가 먹고 싶은데 불이 없어요. 이딴  건 문제도 아닌. 이 사진에서 달성하고자 하는 좁은 목표는 당장 커피를 마시는 거예요. 당장 커피를 마시고 싶어서 미칠 것 같으면 이렇게도 할 수도 있죠. 이렇게 할 수도 있어요. 커피는 중요하니까요. 근데 일단 커피를 마시고 정신을 차렸으면 가스버너를 사 오든 뭘 하든 제대로 된 해결책으로 바꿔야 됩니다. 커피를 매일 이렇게 끓이면, 진지하게 얘기를 해볼게요. 진지하게 화력이 딸려서 시간이 오래 걸리고요. 신발이 녹을 수도 있죠? 전기 요금도 많이 나올 거예요. 불이 날 것 같기도 해요. 이런 게 기술 부채입니다.

이게 기술 부채라는 게 은행에서 대출 내는 거 비슷해요. 단시간에 목표를 달성할 수 있는데 갚지 않으면 이자를 계속 내야 됩니다. 그런 면이 은행에서 빌리는 부채랑 비슷해서 기술 부채라고 부르고요. 이 계속 내야 되는 이자는 개발자의 작업 시간이에요. 이자를 낸다는 거는 작업 속도가 느려지고 예상치 못한 추가 작업이 계속 발생하는 거예요. 우리가 은행에서 대출을 낼 때 언제 대출을 내야 되고 언제 갚아야 됩니까? 빌리는 건 돈 쓸 때가 있는데 돈이 모자랄 때죠? 너무 당연하죠. 갚는 건 돈의 여유가 있을 때죠? 기술 부채는 돈 대신에 시간을 빌려서 쓰는 거예요. 프로덕션 계획이 없으면은 지금 우리가 우리한테 시간이 충분한 상태인지 부족한 상태인지 판단을 할 수가 없어요. 언제나 3개월 뒤가 출시다. 라고 주장을 하고 있는 상태에서는 대출을 갚을래야 갚을 수가 없어요. 모두가 오늘만 사는 인생이 되고 똥 코드에 파묻혀서 점점 느려져요. 똑같은 걸 만드는데도 훨씬 느려져요. 그런데 지나고 나서 생각해보면 후회가 되죠. 이 빚을 진작 갚았으면 시간을 훨씬 아꼈을 텐데 혹은 기술 부채 운용을 잘못하면 개발자들이 반대쪽 극단에 빠지게 돼요. 절대로 부채를 내지 않는 경우가 있어요. 부채를 꼭 내서 빠르게 결과를 봐야 되는 시점인데 그걸 거부해요. 왜냐하면 갚을 시간이 있을 거라고 신뢰를 못하기 때문에. 자, 기술 부채에 대해서 말씀드렸어요. 이제.  프로덕션 계획이 있어야지 기술 부채를 활용할 수 있다. 그렇고요.

세 번째는 질러야 할 때 지르기 위해서에요. 우리가 게임을 만드는 이상 놀라운 것, 새로운 거를 만들어야 된다. 그래야 살아남을 수 있다. 라고 저는 생각하고 있고요. 그런데 그런 거는 계획하기가 어려워요. 왜냐하면 그런 걸 계획할 수 있다면 놀라운 것도 아니고 새로운 것도 아니겠죠? 일단 동작하는 걸 눈으로 봐야 그다음 아이디어가 떠오르기도 하고 비용을 미리 예측하기도 힘들어요. 해본 게 아니니까.

그런 게임들이 있죠? 어디서 본 것 같고 딱히 새로운 느낌 안 드는 그런 게임들. 출시는 했는데 거의 주목받지 못하고 조용히 사라지는 그런 게임들이 있죠. 저는 주목을 받았지만 출시를 못한 게임도 겪어봤고요. 출시를 했지만 주목을 못 받고 사라진 게임 양쪽 다 참여해봤어요. 출시를 못해도 마찬가진데 출시한 게임이 조용히 사라질 때도 인생에 환멸이 나고 자괴감이 들어요. 나는 뭐 하러 이렇게 열심히 개발했나? 반대로 계획 없이 지르기만 하면 출시를 못하는 건 아니고 멀어집니다. 출시가. 계속 멀어지면 영원히 개발할 순 없겠죠. 인생은 짧고 아이디어는 많습니다. 모든 아이디어를 다 구현할 순 없고 이걸 함으로써 못하게 되는 건 뭔지 출시는 얼마나 늦어지는 건지를 생각해야 됩니다. 이걸 지를 수 있는 상황인지 판단을 하려면 그리고 진짜로 지르면서도 일정에 맞추려면 프로덕션 계획이 튼튼해야 됩니다. 

네 번째 우리 이대로 가면 출시할 수 있나? 이런 의문이 들기 시작하면 사람들이 빠지기 시작합니다. 하나둘씩 빠지기 시작하면 남은 사람들도 점점 더 그런 생각이 들겠죠. 우리 진짜 출시할 수 있나? 망하는 프로젝트에 나만 남아서 뒤처지는 거 아닌가? 그러면 출시랑 점점 더 멀어질 거고요. 계속 가속이 될 겁니다. 혹은 아무 생각 없을 수도 있겠죠. 제가 그랬던 적이 있어요. 정말 아무 생각 없었어요. 아무 생각이 없었던 건 아니고 무슨 생각이었냐면 내가 있는 자리에서 내가 할 수 있는 일을 하면 출시할 수 있을 거야. 라고 생각했어요. 그런데 아니더라고요. 출시를 못했어요. 프로덕션 계획을 지속적으로 업데이트하고 공유를 해서 이대로 가면 출시를 할 수 있을 거다. 라는 믿음을 모두에게 줘야 됩니다. 이걸 완전히 다른 방법으로 해결하는 경우가 있어요. 우리가 최고니까 대단한 사람들이 모였으니까 출시할 수 있을 거고 성공을 할 거야. 이걸 계속 팀에 주입하는 거예요. 계획을 주입하는 게 아니라 환상을 주입해요. 이런 멘탈 좋죠. 좋은데 진짜 문제로부터 눈을 가려요. 그게. 문제의 원인을 외면하게 만들어요. 우리는 지금까지 계획대로 잘 해왔나? 계획대로 안 됐으면 원인은 뭐지? 어떻게 하면 더 잘할 수 있지? 이런 의문을 팀이 스스로 던져야 돼요. 치열하게 스스로 물어야 돼요. 그래야지 현재 상태를 개선할 수 있고 문제를 해결할 수 있습니다.

조언을 몇 개 가져와봤어요. 이거는 지금 거의 매니지먼트에 대한 얘기 위주로 하고 있는데 매니저만을 대상으로 하는 얘기는 아니고요. 프로젝트에 참여하는 모든 분들께 많든지 적든지 도움이 될만한 이야기입니다.

첫 번째에요. 약속을 소중히 여기자. 지킬 수 있는 것만 약속하고 약속한 것은 최선을 다하자. 그리고 지키지 못할 것 같으면 가능한 한 빨리 알리자. 실무자가 약속한 걸 가지고 매니저는 단기 계획을 세웁니다. 장기 계획은 이런 식으로 만들어지지 않아요. 보통. 단기 계획은 이렇게 세우는데 약속을 어기면 틀어져요. 어기지 않는 게 당연히 좋겠죠.	계획이 망가지면 안 좋으니까. 그런데 약속이 깨졌을 때 계획을 업데이트하는 것도 매니저의 역할이에요. 그러라고 월급을 더 받는 거니까 쫄지 말고 알리시면 됩니다.

입장을 바꿔서 매니저 입장에서 약속을 중요하게 여겨야 됩니다. 프로덕션 계획을 지속적으로 업데이트하고 공유를 해야 된다고 얘기했죠? 그리고 중요 마일스톤은 지키려고 애써야 되고 계획을 바꾸면 그 이유를 팀에 밝혀야 됩니다. 계획이라고 하는 거는 팀의 약속을 모아서 만들어낸 것인데 거꾸로 매니저가 팀에게 약속하는 것이기도 해요. 두 개의 의미를 다 가지고 있어요. 약속이 깨어졌는데 아무런 설명도 없는 일이 몇 번이 반복이 되면 팀의 누구도 그 계획을 진지하게 믿지 않게 됩니다. 점점 더 계획을 실현하기가 어려워지죠.

세 번째, 예측은 어렵습니다. 하지만 해야 됩니다. 예측을 하지 않으면 약속을 할 수 없어요. 약속을 하지 않으면 계획을 세울 수가 없죠. 자기 작업이 얼마나 걸릴지 예측을 할 수 있어야 됩니다. 예측도 자꾸 해버릇하면 더 정확해지고요. 자기가 예측한 걸 맞추기 위해서 좀 더 의욕을 내는 그런 효과도 있어요. 어떤 일은 근본적으로 예측하기가 어렵습니다. 안 해본 거, 완전히 새로운 거 만드는 거, 새로운 도구를 사용해보는 일 같은 게 그렇고요. 프로그래머의 경우에는 현재 코드 상태에 따라서 똑같은 일을 완수를 하는데 걸리는 시간이 몇 배씩 차이가 나기도 해요. 반면에 좀 해본 종류의 일, 최근에 건드렸던 코드면 좀 더 정밀하게 예측을 할 수가 있겠죠. 그런 걸 반영을 해서 예측치를 범위로 잡는 게 좋습니다. 며칠에서 며칠 사이로 걸릴 겁니다. 뭐 이렇게요. 그리고 중요한 점, 예측을 받은 사람은 그 예측이 나중에 틀린 걸로 드러났을 때 예측한 사람을 비난하면 절대 안 됩니다. 비난을 하면 마음은 편하겠죠. 네가 잘못한 거야. 네가 예측을 잘못한 거야. 너 때문에 나의 완벽한 계획이 망가진 거야. 그런데 그 사람을 비난하면 다음부터 예측을 더 잘하게 될까요? 아니에요. 예측을 부풀리게 될 거예요. 아니면 예측을 거부하든지.

네 번째 조언은 불확실성을 길들이자는 겁니다. 안 해본 거, 실패할 가능성이 높은 거를 계획에서 일찍 배치하면 예상보다 오래 걸렸을 때나 아니면 이게 잘못됐을 때 바로잡을 시간이 주어집니다. 우리한테. 그리고 불확실성을 줄이기 위한 작업 자체에 시간을 투자해야 돼요. 이 도구를 써도 될까? 이렇게 하는 게 정말 괜찮을까? 모든 작업을 하는 게 내가 만든, 내가 작업한 모든 결과가 최종 제품의 일부로 들어가야만 한다는 그런 건 그렇게 생각하면 안 돼요. 중요한 의사 결정을 하기 위한 수단으로써 시간을 쓰는 거를 아까워하면 안 됩니다. 안 그러면 호미로 막을 일을 나중에 가래로 막게 돼요. 이거 제가 되게 좋아하는 건데요. 미뤄도 문제없는 일은 미루다 보면 안 해도 되는 경우가 있어요. 이게 정말 신나요. 제가 제일 좋아하는 겁니다. 그다음으로 좋아하는 건 코드 지우는 거고 코드 지우는 거보다 좋아합니다. 일을 해야 될 거라고 계획을 했는데 일 안 해도 되게 되는 거. 그런데 어떤 일을 미뤄도 되는지 판단을 하려면 프로덕션 계획이 있어야 돼요. 이걸 미뤘을 때 막판에 일이 몰려서 밤을 새야 되는 거 아닐까? 이런 가능성 때문에 버리게 될 일을 미리 해야 되면 되게 아깝죠. 계획을 보고서 판단을 내려야 됩니다. 그리고 마지막으로 마감 직전 일정을 짜는데 여유를 더해야 됩니다. 우리가 모른다는 것조차도 모르는 일들, 어떤 일일지 얼마나 걸릴지 지금은 전혀 알 수 없는 것들을 대비해야 돼요. 이거를 프로젝트 시작 시점에는 몇 달 정도로 길게 잡을 건데 출시가 점점 가까워 오면 남은 버퍼가 줄어들고 줄어들어서 출시 직전에는 남은 여유고 뭐고 아무것도 없고 그냥 카오스 상태가 돼요. 일정 여유 잡아두는 걸 아까워하면 안 됩니다. 전혀 여유 없이 빡빡하게 계획을 잡아놓으면 막판이 되면 출시를 연기해야 될지 아니면 뭘 잘라야 될지 고민을 하게 될 거예요.

다섯 번째 조언, 리드 타임을 이해하자. 이게 생산 내지는 공장 쪽에서 쓰는 개념이라서 우리한테 좀 낯선데 이거를 염두에 두고 일하지 않는 경우가 많은 것 같아요. 읽겠습니다. “리드 타임은 상품의 주문 일시와 인도 일시 사이에 경과된 시간을 말한다.” 이제 이거를 우리의 업무에 맞게 표현을 다시 해보면 작업 요청이 나한테 들어오고 나서 내가 그걸 다해서 결과를 전달하기까지 걸리는 시간인 거예요.

이런 예를 좀 보실게요. 작업 두 개가 저한테 들어왔어요. 내가 두 개를 해야 돼요. A는 4일 드는 거고 B는 1일 들어가는 거예요. 그러면 뭘 먼저 해도 각각 걸리는 시간은 같을 걸로 예상이 되는 상황이에요. 이거 A 먼저 해야 될까요? B를 먼저 해야 될까요? 이 리드 타임만 놓고 계산을 하면 A 먼저 하고 B를 나중에 하면 A는 나한테 요청되고 나서 내가 작업 다 해서 돌려드리기까지 4일이 걸리고 B는 나한테 들어와서 작업 다하고 돌려드리기까지 5일이 걸려요. 그러면 평균은 4.5일이죠? 그런데 B를 먼저, 그러니까 빨리 끝나는 거 먼저 하고 늦게 끝나는 걸 나중에 하면 오래 걸리는 걸 나중에 하면 B가 요청 들어와서 1일 만에 결과가 가고 A는 그때 시작해서 5일이 지난, 4일이 지난 다음에 5일째에 들어가게 되죠. 그러면 평균인 3일이네요. 조건이 같다면 빨리 끝날 일부터 하는 게 유리한데 실제로는 각 작업 뒤에 어떤 작업이 기다리고 있는지에 따라서 달라집니다. 

이거는 그다음 조언에서 좀 더 설명을 할게요. 전체를 보고 낭비를 없애자. 사람들 사이에서 생기는 낭비가 생각보다 많습니다. 내가 하는 일을 기다리는 사람은 누구지? 내가 일을 이렇게 쪼개서 하면 다른 사람이 덜 기다릴까? 뭘 조금 더하면 다른 사람이 시간을 아낄 수 있을까? 이런 생각을 해야 돼요. 내 일만 보고 있지 말고 전체 프로덕션에서 내 일이 다른 일들이랑 어떤 관계에 있는지를 의식하면서 일을 해야 돼요. 모르겠으면 매니저한테 물어보면 되고요. 일을 완전히 끝낸 뒤에 납품을 하는 게 아니라 후속 작업할 사람이 작업을 시작할 수 있을 정도가 되면 일단 거기서 끊고 한 번 넘겨드린 다음에 작업을 마저 마친다든지 여러 가지를 할 수 있어요. 다른 사람이 작업을 할 때 시간을 좀 덜 쓸 수 있도록 배려를 합시다. 이런 작은 개선이 쌓여서 퇴근을 일찍 하고 출시가 미뤄지지 않고 더 놀라운 걸 만들 수 있는 기반이 되게 됩니다.

일곱 번째 조언, 이건 거의 의사 결정자분들을 위한 건데요. 모든 작업이 우선순위 S일 수는 없어요. 우선순위는 상대적인 거고 모든 작업이 우선순위 S라는 얘기는 모든 작업이 우선순위 D라는 얘기랑 똑같아요. 우선순위 S는 진짜 이걸 안 하면 출시를 못해. 패치를 못해. 이런 것만 우선순위 S여야 돼요. 근데 정말 정말 그럴까요? 정말 모든 작업이 다 중요할까요? 그 작업들이 출시를 미루는 거보다 더 중요할까요? 그때그때 다르겠죠. 무엇이 더 중요한 것인지 판단을 하고 뭐를 잘라내야 될지를 판단하는 거는 의사결정자의 책임입니다. 책임자가 그 책임으로부터 도망치면 안 돼요. 도망치면 안 됩니다.

여덟 번째 조언, 지속적으로 개선하자는 거예요. 아까 잠깐 말씀드린 거랑 연결되는 부분이 있는데 이렇게 하는 게 최선인가? 우리가 제 일을 잘 하고 있나? 낭비를 하지는 않았나? 더 잘하는 방법은 없나? 이런 거를 스스로에게 지속적으로 물어야 됩니다. 그런데 이거를 매일매일 염두에 두면서 일을 하기는 되게 힘들고 적당한 주기로 적당한 사람 수를 모아서 회고를 하고 그 회고한 내용들을 모아서 또 검토를 하고 그래서 그중에서 실행할 수 있는 걸 실행하고 그렇게 하기를 권장을 드려요.

아홉 번째 조언, 계획에 집착하지는 말자는 거예요. 이거는 계획을 세울 때의 얘기는 아니고 실행할 때의 얘기인데 계획을 실행하려고 할 때 계획에 집착하지 말자는 얘기고 상황이 계속 바뀝니다. 계획을 세울 때의 상황이랑 진행을 하면서 상황이 다르죠. 그리고 몰랐던 새로운 사실을 알게 돼요. 애초에 완벽한 계획을 짠다는 거는 불가능한 겁니다. 그래서 계획의 디테일에 집착할 필요가 전혀 없고요. 그 계획의 디테일 자체가 아니라 이 계획을 변경했을 때 그게 전체 프로덕션에 어떻게 파급되는지를 보고서 판단을 해야 돼요. 좀 더 큰 그림을 보고서 이게 계획인지 여러 가지 레이어로 이루어질 텐데 작은 그림에서의 디테일에서 이걸 변경했을 때 더 큰 그림에서 어떤 계획이 변경되어야 되는지 그 계획을 변경하는 것 자체가 전체 그림에 문제가 없는지 이런 거를 고려해서 판단을 해야 됩니다.

마지막 조언이에요. 실무랑 병행하기 힘드실 겁니다. 본인 업무에서 이 비중이 높다면은. 업무에서 제작 진행 비중이 높은 사람들이 있어요. 주로 파트장님들인데 동시에 여러 일들이 진행되고 있는데 그걸 끊임없이 추적을 해야 되고 빠진 걸 찾아야 돼요. 빠진 걸 찾아낸다라고 하는 거는 앞선 작업이 끝났는데 후속 작업이 시작이 안 되고 있는 경우라거나 아니면 서로를 기다리고 있는 경우나 해야 되는데 그거를 잊어버린 경우 이런 것들이 생겨요. 그리고 그런 거를 찾아내서 일이 돌아가도록 만들어 줘야 되고요. 그리고 이런 것과 관련해서 필요할 때 바로 판단을 해서 답해줄 수 있도록 언제든 대기 중인 상태로 있어야 되게 되는데 그러다 보면은 자투리 시간이 많이 생겨요. 이게 아깝다. 이 시간 동안 코딩을 하고 싶다. 이런 생각이 들 텐데 활용하기 쉽지 않습니다. 하나의 업무에 집중을 해서 결과를 내야 되는 일은 제작 진행 하는 거랑 동시에 하기가 되게 어렵고요. 밤에 하든지 아니면 하루 두 시간 정도 방해금지 시간을 만들던지 아니면 이상한 모자를 쓰고 내가 이 모자를 쓰고 있을 때는 나한테 방해를 하지 마세요. 이렇게 공지를 하든지 어떤 수단을 동원하더라도 일정하게 시간을 내기는 되게 힘들 거예요. 실무에 집중을 하고 있다 보면 어떤 일이 생기냐 하면 제작 진행에서 빵꾸가 날 겁니다. 둘 다 잡을 수는 없어요.

관련된 멘탈을 키워주는 교제를 좀 소개를 드리겠습니다.

상상을 해봅시다. 1주일에 한 번씩 신규 컨텐츠가 나와요. 13주 연속으로. 경우에 따라서는 26주, 39주 이런 식으로 연속으로 1주일에 하나씩 계속 나오기도 하고 더 대단한 거는 다 만들어놓고 1주일에 하나씩 푸는 게 아니고 계속 만들면서 컨텐츠를 계속 만들어나가면서 공개를 해요. 물론 한 주에 하나씩 계속 딱딱 만드는 건 아니고 몇 주 전에 선행 생산, 프로덕션을 해놓은 다음에 그거를 파이프라인 해가면서 공개를 하는데 심지어 되게 많은 작업이 외주로 돌아가는 그런 프로젝트에요. 이 미친 거 아닌가? 이런 프로젝트가 세상에 어딨나? 하는 생각이 들 텐데

일본 애니메이션 업계가 진짜로 저런 조건에서 일을 합니다. 그리고 거의 펑크가 나지 않아요. 우리가 사랑하는 수많은 작품들이 저런 시스템 하에서 만들어졌어요. 그럼 되게 궁금합니다.

그쪽 사람들은 대체 일을 어떻게 할까? 어떻게 13주, 26주 이렇게 1주일에 하나씩 컨텐츠 업데이트하는 걸 20분 이상의 러닝 타임을 갖는 영상물을, 컨텐츠를 만들어내고 있는데 그거 도대체 어떻게 하는 건가? 제작 진행을 담당하는 직급이 따로 있더라고요. 이쪽은 일정 지키는 게 되게 중요하니까 어찌 보면 당연한 얘기고 그다음에 이 사람들이 사용하는 매체의 형식, 기술이 우리랑은 다르게 거의 정해져 있으니까 가능한 것일지도 모르겠어요. 어쨌든 그 교재의 이름은

시로바코입니다. 시로바코라는 애니메이션이 있어요. 애니플러스에서 보실 수 있습니다. 애니플러스. 주인공이 오른쪽에 계신 금발 여성분인데 애니메이션 회사에 제작 진행 직군이에요. 이걸 보면 처음부터 제작 진행을 전담으로 해서 입사하는 사람들이 있고 그것만 하는 팀이 있고 이 일을 하는 사람들이 없으면 작품이 제대로 만들어질 수가 없다는 거를 보여줍니다. 제가 이걸 보고 나서는 되게 많이 치유가 됐는데 관련 일을 할 때 제가 에너지가 좀 덜 빠지는 느낌이에요. 안 빠지지는 않고요. 덜 빠지는 느낌입니다.

거의 다 왔습니다. 이 발표를 왜 했는가?

일정대로 출시하는 거 이거 누구의 일일까요? 남은 일을 남은 기간 동안 해낼 수 있는 계획을 세우고 실행하고 도저히 해낼 수 없다면 어떻게든 하고 출시할 때까지 계속 반복하는 게

이게 주로 파트장이나 팀장 급에서 실무랑 병행하는 경우가 많은 것 같아요. 기획 파트에서 맡는 경우도 있고요. 회사에 따라서는 별도 직군으로 나누는 것도 있는 것 같고 해외 회사에는 많은 것 같은데 우리 회사는 아니에요. 왜냐하면 제작 진행 직군이 따로 없거든요. 그런데 제 생각은 이거는 거의 모두의 일에 가까운 것 같아요. 제가 아까 드렸던 조언들 그런 것들 모든 사람이 조금씩 의식을 더 하면서 자기 업무를 예측하고 계획을 세우고 종합해서 큰 계획으로 만들고 그래야 될 것 같습니다.

흔히 듣는 이야기가 있어요. 실무로 시작해서 제작 진행을 일부 맡게 된 분들이 흔히 하시는 얘기, 그런 얘기가 있어요. 아, 오늘도 일 하나도 못했네. 분명히 하루 종일 되게 바빴어요. 그런데 일을 하나도 안 했다. 이런 기분이 들어요. 일정 관리 같은 것만 하고 내가 일을 안 한 것 같다. 이런 생각이 들어요. 이게 반복이 되면 번아웃이 되기 쉽고요. 보람이 안 생겨서. 왜 이런 생각이 들까요? 우리가, 우리의, 우리네 사람들이 업계 처음 들어왔을 때를 돌이켜 보면 대부분 내 시간을 들여서 내 손으로 결과를 내는 종류의 일로 업계에 들어왔어요. 그래서 제작 진행만 하면 아무 일도 안 한 것 같은 기분이 드는 것 같아요. 그래서인 것 같아요. 근데 그게 아니고 제작 진행이 굉장히 중요한 일입니다. 그래서 결심을 했어요.

중요한 일은 멋있는 이름으로 부르자. 제작 진행. Production Management.

그래서 하고 싶은 얘기는 모두 조금씩만 더 제작 진행을 의식하면서 일합시다. 그리고 업무에 제작 진행 비중이 높은 사람은 중요한 일을 하는 거니까 번아웃 되지 말고 힘냅시다. 이런 얘기를 하고 싶었습니다.

감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
