[특강] 교수님 우리 프로젝트 망했어요

특강 강사 : 염동현 교수님

관련 자료는 게임스쿨 카페에 업로드 될 예정.

성공적인 프로젝트를 위한 조언 #1

프로젝트 망한 팀들의 속사정 : 초보 개발팀이 가장 흔하게 겪는 패턴

- 게임 컨셉이 모호하다

- 대충 리소스 위주의 스펙을 짠다.

- D-Day가 잡혔으니 일단 일정부터 짠다.

- 다짜고짜 만들기 시작한다.

- 퀄리티도 안 나오고 일정이 밀린다.

- 하나씩 리소스를 줄인다.

- 결국 게임이 완성되지 않는다.

 

 

일이 잘 안 풀리기 시작하면 희생양을 찾게 된다. (하지만 나는 절대 아니다.)

- 교수님의 피드백을 듣고와서 뭐뭐가 문제라는데 라며 팀 내에서 터뜨린다.

- 다른 사람들에게 팀 내의 문제를 흘린다. (SNS 포함, 절대 올리지 말 것.)

다른 파트의 핑계를 댄다. (기획이 안 나와서, 원화가 안 나와서 등...)

 

팀 내의 문제는 팀 내에서 해결해야한다. 외부에 이야기 해 봤자 해결되지 않음. 소문만 퍼지게 된다.

 

 

내가 맡은 일만 잘 끝내면 된다고 생각한다. (누군가 잘 합쳐주겠지)

지금 하는 작업은 내 스타일이 아니라서 따로 포폴작업을 한다. (특히 그래픽 아티스트)

팀원들은 모르지 않는다. 대놓고 CCRC에서 다른 것들을 작업하는 사람들도 있다. 팀원들은 전부 알고 있다.

성공적인 프로젝트를 위한 조언 #2

팀의 규칙 정하기

팀도 작은 사회이기 때문에 팀을 위한 규칙이 있어야 한다.

팀장이나 PD가 일방적으로 모여서 정할 것이 아닌, 반드시 다 같이 모여서 규칙을 정해야 한다.

 

[ 예시 ]

- 작업할 때는 아재개그 하지 않기.

- 매주 월요일 저녁에는 디스코드에 모이기.

- 팀의 초반에 셋팅을 해야한다. 후반에는 추가하기 어려운 경향.

- 우리 게임이 잘 되었을 때 수익을 어떻게 나눌 것인지. (은근히 많이 싸움)

   10명의 팀원. 공평하게 나눠 받으면 깔끔하겠지만, 불만을 가진 사람이 생길 수 밖에 없다.

   처음 시작하고 두 명이 중간에 나가게 되었을 때. 두 명이 새로 들어오게 되면 어떻게 나눌 것인가?

   > 내 돈 안 줄거면, 내가 작업한거 다 지워! (만약 작업물 파기를 원하는 인물이 프로그래머라면??)

      나중에 엄청 큰 싸움이 일어나게 된다.

 

팀을 이끌어가는 리더 그룹 정하기

리더 그룹을 정하고, 그 역할의 책임과 권한을 정한다.

- 팀장

- PD

- PM

- AD

- 파트장

팀을 처음 셋팅했을 때 정해야 하는 부분.

 

역할 : 팀장은 무슨 일을 하는 사람인가

권한 : PD는 무엇을 결정할 수 있는가?

학생이 책임질 일은 별로 없다.

 

팀장은 구체적으로 무슨 일을, 어떤 권한에서 하는 사람인지. PD는 어떤 결정을 할 수 있는 사람인지.

역할과 권한에 대해 명확하게 모든  팀원이 합의를 해야 함.

이를 명확하게 하지 않으면 충돌이 일어나게 된다.

 

PD는 주로 게임의 중요한 방향을 선택하는 사람이라고 정한다면.

어떤 결정을 했는데, "네가 뭔데 그런걸 결정해" 라고 하게 된다면.

충돌이 나는 상황을 피할 수 없다.

 

 

우리 PD가 역할을 잘 못해요.

 

 

프로젝트에서 리더를 해 본 사람은 별로 없고, 잘 하지도 못한다.

 

잘해서 리더를 하는 게 아니라는 얘기.

하고 싶어서, 때로는 떠밀려서 하게 된다.

 

 

PD라는 것은 단기간에 뭔갈 배워서 할 수 있는 게 아니다.

팀에서 리더를 뽑았으면 어째됐든 리딩을 잘 할 수 있도록 모든 팀원들이 도와주어야 한다.

 

쉽게 말하면, 위와 같은 말을 하면 안 된다.

팀원들이 나서서 PD를 도와주어야 한다.

PD로 지정된 학생은 PD의 자질을 타고났거나, 잘 하는 사람이 아니다.

 

결국에는 남의 팀 일이 아니라, 우리 팀 일이다.

 

 

우리는 당신을 AD로 인정하지 않기로 했어요.

 

 

이후 다른 팀원은 겁이 나서 선뜻 하려고 하지 않는다.

"나도 일을 제대로 못하면 똑같이 비난을 받고, 똑같은 상황에 처하게 되겠구나."

 

누가 또 떠밀려서 AD 자리에 올라가게 되면, 악순환은 시작된다.

 

처음에 리더를 선택했다면, 그 리더가 잘 할 수 있도록 도와주어야 한다.

리더를 바꾸게 된다고 하더라도, 팀원들에 의해 끌어내려지는 게 아니라 스스로 내려왔을 때 맡게 되는 형태여야 한다.

 

팀원들의 불신을 받아서 내려오게 되면, 또 다른 누군가는 그 자리를 맡고싶지 않게 된다.

"나도 비난받아 내려오게 되면 어떡하지?"

멘탈이 나가게 된다. 사람들이 무서워지고, 정신과에 가게 됨.

 

가장 최악의 시나리오는 팀원들에 의해 끌어내려지는 것.

성공적인 프로젝트를 위한 조언#3

게임 컨셉을 명확히 하기

게임 컨셉이 명확하다는 것은 어떤 의미일까?

팀원 모두가 "우리가 어떤 게임을 만들 것이다"라는 것을 구체적이고 명확하게 인지하고 있다는 것을 말한다.

 

팀원이 우리 게임의 컨셉을 명확히 이해하고 있다는 것을 확인하려면?

각자 우리가 만드는 게임에 대해서 설명 해 보라고 하면 된다.

 

내가 뭘 만드는지도 모르는 채로 게임을 만들면 안 된다.

자기가 뭘 만드는지도 모르고 있다면 프로젝트가 잘 될 수가 없다.

 

자기가 만드는 게임이 뭔지 설명을 하지 못한다면, 크게 네 가지 중에 하나이다.

1. 컨셉을 잘못 잡았거나

2. 설명을 제대로 안했거나

3. 우리 게임에 애정이 없거나

4. 이해를 못할 정도로 역량이 부족하거나

 

1, 2는 PD의 문제이고 3, 4는 팀원 개인이 애정이 없거나 능력이 부족 한 것이다.

대부분은 1, 2의 문제가 많다. 3, 4는 초반에 드러나지 않는다.

 

졸작팀이 찾아와서 "교수님, 저희는 스타일리쉬한 액션 게임을 만들겠습니다."

이에 대해서 설명을 좀 해 보라고 물어보면, "화려한 그래픽과...", 옆의 친구에게 물으면, "저는 좀 생각하는 방향이 다릅니다."

만드려고 하는 사람들의 머리속에 다 다른 그림이 그려져 있는 경우가 많다.

 

매콤한 음식을 먹고 싶다!

- 마라탕

- 닭발

- 떡볶이

서로 같지 않다.

성공적인 프로젝트를 위한 조언 #4

게임 스펙 정하기

프로젝트를 시작하면서 제일 먼저 해야 하는 일이 게임의 컨셉을 잡는 일이라면, 두 번째로 해야 할 일은 스펙을 정하는 일이다.

컨셉을 잡고 나면 스펙을 정할 수 있다.

 

캐릭터가 있습니다.

- 캐릭터는 점프를 할 수 있어야 합니다.

- 좌우로 이동할 수 있어야 합니다.

- 발로 적을 밟으면 죽습니다.

- 이단 점프가 가능합니다.

 

보통 D-day가 정해진 상황에서는 게임의 스펙을 정하는 게 반드시 필요하다.

구체적으로 무엇을 만들지 정량화(수치화)해야 일정에 맞추어 작업을 할 수 있다.

 

 

스펙에 맞춰서 일정을 잡아서 진행해야 한다.

하다보면 어느 순간 되겠지 : 하면 되긴 되는데...

 

 

구체적으로 파트별로 무슨 작업을 해야 하는지를 정량화해서 문서화하는 것을 "사양서"라고 한다.

사양(스펙)서를 통해 전체적으로 개발해야 할 내용 파악이 가능해야 한다.

 

스펙이 정해지고 나면 사양서의 내용 중에 R&D(리서치 & 디벨롭) 해야 하는 항목이 있는지 찾아야 한다.

이 작업을 할 수 있는지, 없는지의 분석을 하는 시간.

 

 

게임 컨셉이... 대규모 전쟁 씬을 만드는 것이 목표라면. 10만명의 병사가 싸우고 있다면?

이것이 구현 가능한가? R&D를 해야 한다.

- 어떤 플랫폼을 기반으로 하지?

- 동시에 몇 명까지 가능하지?

 

학생의 경우 경험과 노하우가 부족하므로 사양서의 내용만으로는 R&D 할 것을 찾지 못하는 경우도 있다.

"할 수 있을 것 같아" 라는 막연한 느낌이 들어도 무조건 R&D를 해야 한다.

 

졸작팀 : 체인 액션 게임을 만드는 팀의 경우...

- 체인을 어떻게 만들어야 해?

- 학생 수준에서 할 수 있는 것이 아님에도 할 수 있다고 우길 때

- 그럼 해 봐야 하는가, 말아야 하는가?

- 결국 만들지 못했다. 못 만들면 포기하면 되는데, 대신할 수 있는 다른 것을 찾아보면 되는데

- 개발 기간이 한참 지났는데 체인을 못 만들 것 같다고 하면 그 때 부터 아수라장이 시작된다.

- 체인 대신 검으로 바꾸고, 밋밋한 게임이 되고...

 

 

눈치 못 채게 되는 대표적인 예 : 인공지능

좀비가 100마리가 있을 때, 어떻게 인공지능으로 움직이는가.

게임 후반에 가서 좀비들이 나만 일렬로 졸졸 따라다니면 다른 것들을 다 잘 만들어도 게임이 엉망이 되게 된다.

 

R&D는 게임 개발 일정 중에 가장 먼저 해결해야 한다.

이걸 못 해내면 게임 자체가 구현이 불가능하기 때문이다. 프로토타입에서 검증해내야 한다.

 

만화풍의 쉐이더를 하고 싶다, 하지만 할 줄 아는 사람이 없다면.

언젠가 될거야로 밀고나가서는 안 된다.

성공적인 프로젝트를 위한 조언 #6

무조건 열심히 한다고 잘 되는 건 아니다.

 

R&D까지 잘 하고 나면 게임 자체가 흔들리게 되는 일은 급감한다.

하지만, 목표를 달성하기 위해서는 방향과 속도가 중요하다.

아주 빠른 속도로 진행했지만, 방향이 다르다면. 아무리 빨라도 방향이 잘못되면 소용이 없다.

 

졸작팀의 예시...

파트별로 에이스들을 모아서 팀을 만들어도 방향을 잘못 잡으면 망한다.

학기작이나 입소문을 거치면서 누가 잘 한다는 소문이 나게 된다. 그 어벤저스들로 팀이 구성되게 되어도.

서로 방향을 가리키고 싶어하기 때문. 내가 맞다고 생각하는 방향으로 냅다 달리게 된다.

 

팀이 터지기 바로 직전에 들은 교수님의 피드백... "너희가 만든 건 게임이 아니고 테크데모 같아."

각자 자신의 방향으로만 집중했기 때문.

이걸 바로잡아주는 것은 PD, PD가 없으면 팀장, 그 마저도 없으면 AD.

 

처음부터 방향을 잘 잡기는 어렵다.

중간중간 우리가 맞는 방향으로 가고 있는지 확인해야 한다.

흔들리고, 돌아가더라도 골에 가깝게 가면 된다.

 

 

맞는 방향이란 무엇인가?

- 게임 컨셉에 맞는 작업을 하고 있는가?

- 누군가 게임 컨셉에 맞지 않는 작업을 제안하거나 하고 있다면?

과감하게 쳐내야 한다.

 

1인칭 슈팅 게임을 만들기로 했는데...

원화가 - "제가 졸작할 때 꼭 하고싶었던 캐릭터가 있습니다."

교복입은 미소녀, 검은 긴 생머리의 큰 장검을 휘두르는 캐릭터를 만든다면?

시나리오를 맡은 기획자 - "우리 게임은 FPS인데, 생뚱맞은 캐릭터와 스토리를 가지고 와서 했으면 좋겠다고 하면..."

 

 

"팀원들에게 어려운 얘기하기가 힘들어요..."

 

개인으로서가 아니라, 역할을 받았으면 해야 한다. 그걸 못 하면 감투를 쓰면 안 된다.

네 말도 맞는 것 같아, 네 입장은 그렇구나... < 절대 안됨.

- 팀장, PD, AD 등...

 

 

게임 컨셉의 이름으로 널! 용서하지 않겠다!!

명확하게 팀이 나아가야 할 방향을 지정 해 주고, 그에 맞지 않으면 과감하게 쳐 내야 한다.

 

 

방향은 맞는 것 같은데, 속도가 나지 않을 때.

- 팀 역량이 부족하던가

- 열정이 사라졌던가.

 

성공적인 프로젝트를 위한 조언 #7

팀 역량 파악하기

처음 게임 컨셉을 잡고 이어서 스펙을 정하는 과정에서 팀의 역량이 반영되어야 한다.

숙련된 작업자들이 있으면 스펙이 커지고, 미숙한 작업자가 많다면 스펙이 줄어든다.

 

그렇다면 어떻게 팀의 역량을 파악할 수 있을까?

1. 어느정도 할 수 있는지 직접 물어본다. (오류가 많음)

2. 포폴을 가져오라고 한다. (싸우자가 될 수 있음)

3. 주변의 소문을 확인한다. (보통 많이 쓰곤 하는 방법)

4. 간단한 테스트를 한다. (이건 진짜...)

 

나열하긴 했지만, 실제로 역량을 파악할 수 있는 좋은 방법이 많지 않다.

 

 

프로토타입 제작을 통해 팀의 역량을 파악해야 한다.

게임 제작에 반드시 필요한 기능을 구현 (프로그래밍, 기획, 그래픽)

반드시 모든 파트가 참여해야 한다.

 

이펙트 일이 없다고 이펙터가 참여하지 않으면 이펙터의 역량을 파악하기 힘들다. 일단 뭐라도 시켜봐야한다.

프로토타이핑 결과에 따라 우리 팀이 어디까지 제작이 가능할지 가늠을 할 수 있다. 그리고 스펙을 조정한다.

초반에 이러한 과정을 거쳐야 후반에 탈이 나지 않는다.

 

 

프로토타이핑을 하지 않으면 우리 팀의 역량 파악이 불가능하다.

프로토타입 제작 이후 팀 역량에 맞게 기획을 조절한다.

 

- 더 키우던가

- 뭐였더라

- 줄이던가

(여기 구간 너무 빠르게 지나가서 놓침. 피피티 다시 보고 추가해야 함)

 

 

팀 역량이 부족할 때 할 수 있는 일

1. 팀원의 역량을 키운다.

2. 일정을 늘린다.

3. 할 수 있는 인원을 추가한다.

4. 스펙을 줄인다. (가장 현실적)

5. 도움을 요청한다

 

- 1, 2, 3 : 이상적이다.

- 4, 5 : 현실적이다.

 

성공적인 프로젝트를 위한 조언 #8

열정 되살리기

열정은 소모되는 자원이다.

사람마다 그릇도 다르고, 차 있는 양도 다르고, 소모되거나 회복되는 양도 다르다.

 

일단 냅다 달려버린 후 하얗게 불태워버리면 안 된다.

학기작, 특히 졸작에서 중간 결과를 볼 때 까지 미친듯이 달리다가 나가떨어지는 경우가 많다.

 

열정이 식었(다 썼을) 때, 다시 일어서게 하는 첫 번째 힘은 희망이다.

어제보다 오늘이 더 나아졌음을 보여줘야 한다.

 

빌드를 만들어라.

우리 게임이 돌아가는 모습을 보여줘야 한다.

계속 나아지는 모습을 보여줘야 한다.

주기적으로 빌드를 해라. (최소 주 1회)

 

예전에는 졸작을 시연하는 과정이 없었기 때문에 영상만 보고 팀원들이 불타오르는 경우도 많았다. 자신들끼리 뽕에 취하는.

 

 

프로그래머가 빌런이라서 작업을 하지 않을 때.

기획, 아트가 모두 쌓여있지만 합쳐서 보여줄 수 있는 게 없다면.

"우리는 안 되나보다" 다 같이 다운텐션을 보이게 됨.

 

갑자기 플머가 개과천선되어서 만들어내기 시작하면

"오! 내가 만든 건물이 여기(엔진)에서 이렇게 보이네." 수정하고, 추가하고.

팀원 전체가 신나게 된다.

 

 

칭찬해라.

다시 일어서게 하는 두 번째 힘은 칭찬이다.

무엇이 됐든 팀 외부에서 칭찬받을 일을 만들어야 한다. 외부에 게임을 알려라.

별 것 아닌 칭찬이라도, 계속해서 외부에서 들어오게 되면 힘이 되게 된다.

팀원들이 위축되는 이유는 혼나기 때문이다.

성공적인 프로젝트를 위한 조언 #9

내 업무의 끝은 어디까지인가?

잘 안되는 팀의 사례 중 하나는 자기 일만 하는 것이다.

각 파트별로 해야 하는 직무가 있다. 직무별 업무를 완료하면 자신이 일이 끝났다고 생각하는데, 잘못된 인식이다.

게임은 협업이 중요하기 때문에 업무도 다른 파트와의 연계를 고려한다. 나의 일이 잘 전달되도록 하는 것이 중요하다.

 

[ 예시 ]

원화가가 캐릭터를 그렸다. 이대로 끝인가? 아니다.

- 기획자에게 가서 기획 의도대로 캐릭터가 그려졌는지 확인해야 한다.

- 그 이후, 다음 작업자인 모델러에게 가서 원화를 보여주고 설명해야 한다.

 

나와 연결되어있는 작업자들과 커뮤니케이션을 활발히 해야 한다.

커뮤니케이션이 끝나야 일이 끝난 것.

 

커뮤니케이션은 기획자에게 중요한 역량이라고 생각할 수 있지만, 모든 파트에게 필요한 역량이다.

시키는 일만 잘 하면 된다고 생각하면 안 된다.

최종적으로는 빌드를 확인하여 내 작업물이 반영되어 제대로 구현되었는지 확인까지 해야 업무가 끝난 것이다.

 

졸작 했던 팀 중에...

기획자기 두 명 있는데, CC이다. 기획서를 써서 카페에 올리고 기획의 일이 끝났다며 에버랜드에 놀러갔다.

남은 사람들은 기획서를 보면서 작업을 해야 하는데... 물어 볼 사람이 없다. 결국 둘은 팀에서 방출이 되게 된다.

 

잘 돌아가는 팀은, 수시로 서로 왔다갔다 하면서 확인을 한다.

잘 되는 팀은 이야기가 활발하게 진행된다.

성공적인 프로젝트를 위한 조언 #10

교수님은 신이 아니다.

수업이나 별도 상담을 통해 교수님들로부터 크리틱을 받는 경우에 다양한 피드백을 받게 된다.

업계 경력도 많고, 게임 개발 경험도 풍부한 전문가인 교수님이 하는 얘기니까 피드백의 무게가 남다른 것은 사실이다.

 

하지만, 게임에 대해서 여러분만큼 많이 고민하고 있지는 않다.

단편적으로 보이는 부분들을 종합하여 자신의 경험에 빗대어 조언을 해 주는 것.

 

 

A교수님은 이렇게 얘기하고,
B교수님은 다르게 얘기하는데
C교수님 생각은 어떠세요?

 

 

교수님의 피드백은 경험 기반이기 때문에 교수자별로 서로 다른 피드백이 나올 수 밖에 없다. 정답이 없는 부분.

이게 맞는 것 같아서, 상황에 맞는 피드백을 해 주는 것일 뿐이다.

다양한 피드백을 받는 것은 좋지만 A, B, C 교수님 중에 누구의 조언이 맞는지를 고민해서는 안 된다.

 

무조건 교수님의 피드백을 수용하려면 머리가 터져버릴 것이다.

피드백을 받으면 우선 피드백의 내용이 우리 게임의 컨셉, 방향성과 맞는 것인지부터 확인해야 한다.

 

"졸작은 교수님이 만들고 싶은 게임을 만드는 것이다" 라는 말이 들리기도 하는데,

절대 아니다.

 

 

아무리 교수님의 피드백이라도, 우리 팀에 맞지 않으면 과감하게 버린다.

다만, 교수님의 피드백을 수용하지 않을 때에는 왜 수용하지 않는지에 대해서 합리적인 근거를 마련하여

피드백을 주셨던 교수님께 전달해야 한다. "그냥 안 했다"가 되면 혼나게 되는 것.

피드백에 대해 무시하면... 교수님도 사람인지라 좋아하지 않는다. "니들이 내 이야기를 안 듣고 얼마나 잘 하나 보자."

'강단이 있네', '하고싶은 게 있나 보네', '한번 지켜보자.' 가 되게 만들자.

성공적인 프로젝트를 위한 조언 #11

게임 개발은 일(비즈니스)이다.

게임 개발은 친목을 다지려고 하는 게 아니다.

친구끼리, 커플끼리 하다가 사적인 관계 때문에 프로젝트를 망치는 경우가 허다하다.

 

팀에서 파벌이 생기고, 싸우기 시작하면...

"룸메랑 매일 봐야하는데, 룸메 편을 들지 않았다가 남은 시간들이 괴로우면 어떡하지..."

더 심한 일들은 분명히 생긴다.

 

아까 전의 에버랜드 기획자들의 경우...

여자 기획자 쪽이 일을 더 많이 해 주고 숨겨주는 경우도...

 

 

비즈니스 관계에서의 팀워크는 서로에 대한 신뢰에서 나온다.

제 때 업무를 완성하는가? 퀄리티에 대해서 믿고 맡길 수 있는가?

 

 

팀을 구성 할 때에는 비즈니스라고 생각하면서 팀원을 구성해야 한다.

- 우리 팀에 맞는 사람인가?

- 우리 팀에 공헌할 수 있는 사람인가?

 

여러가지 예외 케이스도 있으며, 무조건 안 되는 것이 아니다. 잘 안 되었을 때 곤란해질 뿐.

성공적인 프로젝트를 위한 조언 #12

욕심 부리지 않기

   만들고 싶은 게임이 있다면 졸작이 마지막 기회!!!

   "제 인생의 마지막 기회입니다. 졸작이 아니면, 제가 만들고 싶은 게임을 영원히 만들 수 없잖아요!"

 

   만들 실력은 되고?

   고작 이게 네가 만들고 싶은거냐?

 

욕심을 부린 만큼 꿈이 크다

-> 스펙이 커진다

-> 팀의 역량이 못 따라간다.

-> 구현을 못한다.

-> 팀 내에 분란이 생긴다.

-> 게임을 갈아엎는다.

 

 

그럼 전 이제 만들고 싶은 게임을 평생 만들 수 없는 건가요?

 

 

회사 가서, 실력도 쌓고, 돈도 모으고, 좋은 동료도 만들고, 여유가 생기면 하면 된다.

불가능 한 것이 아니다.

 

선배의 케이스...

"교수님 저는 꿈이, 저만의 작은 스튜디오를 만드셔서 만들고 싶은 게임들을 잔뜩 만드는거에요."

"하지만 부모님이 반대합니다. 가업을 이으라고... 직원이 50명 정도 되는 빵집..."

"그럼 너는 빵집을 해라. 그리고 모은 돈으로 게임 개발을 해라."

몹시 좋아하면서 학교를 그만 두고 빵집을 하러 갔다.

 

 

하고싶은 게임을 만들기 위해서는

역량도 길러야 하고, 도와줄 수 있는 사람도 필요하고, 돈도 필요하다.

하고 싶은 게임? 사실 졸작 수준에서 불가능하다.

졸작 수준에서 제작 가능한 게임이 "평생 만들고 싶은 게임"이라면... 너무 초라한 것은 아닌가?

 

학교에서는 자신의 욕심을 채우기보다는 프로젝트를 통해서 배우려는 자세가 중요하다.

하고싶은 게임을 만드는 것. 그것은 기본적으로 열심히 하다 보면, 보너스처럼 따라오게 되는 것.

성공적인 프로젝트를 위한 조언 #13

실패를 두려워하지 않기 (제일 하고싶었던 이야기)

실패를 두려워하지 말라는 것은 욕심을 부리라는 이야기가 아니라, 결과에 대해 걱정하지 말라는 이야기.

학교는 실패를 해도 되는 안전한 공간이다. 실패했다고 해서 나락에 떨어지거나 인생이 끝나는 것이 아니다.

학교는 여러분들이 사회에 나가기 전에 거치는 과정. 안 좋은 결과가 나오더라도 배울 점이 있다.

 

"하지만, 졸작 망하면 취업은 어떻게 해요?"

 

신입의 결과물이 좋아봤자...

결과보다는 과정이 더 중요하다. 과정을 잘 보여주는 것이 중요하다. 졸작 망해도 취업 잘만 한다. 다만, 추억이 조금 아쉬울 뿐...

 

정말 프로젝트가 잘 되서 취업한 사람들도 있지만, 프로젝트가 망해서 취업한 사람들도 많다. 프로젝트가 망했는데, 조기취업을 하는 경우.

졸작을 망쳤지만.. 졸작을 망치는 과정 중에서도 했던 역할들을 잘 수행했고, 그것을 잘 보여주었기 때문이다.

졸작이 히트를 쳤음에도 취업을 못 하는 사람들도 있다. 내가 무엇을 기여했는지를 보여주지 못했기 때문이다.

 

졸작과 취업은 생각보다 관계가 없지만, 학생들은 오해를 많이 한다.

하지만, 잘 되면 좋긴 하다. 추억. 해외에 나가고, 상금도 받고. 평생 가지고 갈 수 있는 추억이 되긴 한다.

하지만 그것은 어디까지나 추억이고, 그것 때문에 인생이 뒤바뀌진 않는다.

 

 

과정이란

- 어떤 의도를 가지고 있었는가?

- 어떤 프로세스로 개발 해 왔는가?

- 어떤 문제가 발생했으며, 해결하기 이해 어떤 노력을 기울였는가?

- 프로젝트를 개발하며 무엇을 얻었는가?

 

캐릭터가 말 하는 장면을 만들고 싶다면...

- 캐릭터가 입을 움직이는 것을 만들어야 한다.

- 하지만 일정상 불가능하다면?

- 이러한 상황에서 문제를 어떻게 해결 해 내었는가.

 

해결되지 않았을 수도 있다. 하지만 그 과정이 어떻게 되었는가. 이것을 회사에서 많이 본다.

노력한 과정들을 보여주어야 한다. 이것을 통해서 뭘 얻었는지.

이것을 보여줄 수 있으면, 프로젝트가 잘 되어도 망해도 충분하다. 오히려 망했을 때 더 잘 나오게 된다.

잘 되면, 내가 잘 나서 잘 된줄 아는 경향이 있다. 오히려 마이너스.

 

과정을 잘 보여주는 포트폴리오

1. 문서 잘 작성하기 - 모든 파트 공통

2. 문제 해결 과정 기록하기

3. 포스트모템 하기

 

행정실에 가면, 선배들이 만들었던 졸작의 완료 보고서가 있다. 열람 해 보면 좋을 것.

성공적인 프로젝트를 위한 조언 #14

포스트모템이란?

프로젝트 완료 후 전 과정을 되돌아보면서 잘된 점과 잘못된 점이 무엇인지 살펴보는 일. 자기 반성의 일환.

다른 사람의 잘못을 지적하는 것은 쉽지 않다. 따라서 스스로 잘못한 일을 용기내어 얘기할 수 있어야 한다.

프로젝트가 망해도 포스트모템을 잘 하면 더 얻는 것이 많아진다.

 

망한 프로젝트는 "우리가 왜 망했지?", "뭐가 잘못됐지?" 알아보는 것이 중요하다.

2학년 때 심하게 말아먹어보라. 괜찮다. 졸작 때 되풀이 하지 않으면 성공할 확률이 높아진다.

 

- 다 같이 모여서 얘기해야 한다.

- 나온 얘기들은 기록으로 남긴다.

- 그래야 다시 같은 실수를 하지 않는다.

굉장히 좋은 포트폴리오가 된다.

 

프로젝트가 망해도 포스트모템을 잘 끝내고 나면 남는 게 생긴다.

졸작도 마찬가지. 망해도 포스트모템을 하면 남는 게 많이 있을 것이다.

Q&A

팀원간 불화 해결 문제와 같은 것도 문서화 해 두면 좋을까? 혹은 작업물만?

모든 것을 적으세요. 다 괜찮습니다. 문제 해결 또한 제출하면 된다.

포폴 만드는 이야기로 가면 양이 너무 많아짐. 면접관 또한 랜덤이기 때문에 "네가 뭘 좋아하는지 몰라서 다 준비했어"가 좋긴 하다.

레벨디자이너여도 레벨디자인만 준비하기 보다는, 시스템, 컨텐츠 등등 다양하게 준비하는 것이 좋다.

당장 필요한 직군으로 채용하더라도, 나중에 전환 될 가능성이 있다.

 

졸작 할 때 욕심을 내지 말라고 하셨던 것. 만들고 싶었던 게임이 있긴 하지만, 분량을 줄이면 가능할 것 같을 때. 시도를 해 봐도 괜찮을지.

시도는 해 봐야죠. 도전하는 것은 좋다고 생각한다. 충돌이 나지 않을 수는 없겠지만, 욕심 부렸다가 스펙과 같은 부분들을 잡고 팀원 역량에 맞춰 줄여가면 된다. 무작정 할 수 있을 것 같다/ 안될 것 같다며 욕심내거나 쳐내지 않는 게 좋을 것.

 

팀의 규칙과 같이 이미 정해진 것을 다시 정해야 할 때 팀원들에게 이야기 하기에 좋은 팁같은 것이 있을지.

모든 일은 솔직한 것이 좋다. 괜히 상대의 기분을 고려해서 빙빙 돌리는 순간 꼬이기 시작한다.

일단 무조건 솔직하면 다 해결 된다. 솔직한 게 짱이다. 이런이런 이유 때문에 다시 팀의 규칙을 정하고 싶다고 솔직하게 이야기 해야 한다.

기분 나쁠 수 있는 점에 대해서는 인정 해 주면 된다. 필요한 일에 대해서는 해야 한다.