시리즈 글 목록
- [프로젝트/Lost In Hope] - 프로젝트 종료를 맞이하며, 회고록 (1)
- 현재 글 : [프로젝트/Lost In Hope] - 프로젝트 종료를 맞이하며, 회고록 (2)
- [프로젝트/Lost In Hope] - 프로젝트 종료를 맞이하며, 회고록 (3)
- [프로젝트/Lost In Hope] - 프로젝트 종료를 맞이하며, 회고록 (4) [完]
시리즈 들어가며 다시 보기
들어가며
23년 09월 03일, 약 1년 가까이 진행했던 <Lost In Hope> 프로젝트가 종료됐습니다.
<Lost In Hope>가 종료된 이유부터 말씀드리면, 더 이상 프로젝트가 팀원들에게 의미를 주지 못했기 때문이라고 생각 들어요. 간단하게 말하면 '내가 가진 생각과 게임 프로젝트에만 집중하느라 팀원들을 신경 쓰지 못했다.'가 맞을 것 같네요.
그렇다고 나쁘게 끝난 건 아니고, 그냥 지지부진한 진행도, 현생 이슈로 이탈하는 팀원들, 멘탈 나간 제 자신으로 인해 자연스레 종료하게 됐습니다.
그래서, 오늘은 이 <Lost In Hope> 프로젝트의 회고록을 작성해보려고 하는데요.
<Lost In Hope> 프로젝트를 진행하면서 '무엇이 좋았고 (Liked), 어떤 게 아쉬웠으며 (Lacked), 배운 점은 무엇인지 (Learned), 그리고 앞으로 하고자 하는 것은 무엇인지(Longed for)'를 정리하는 4L 회고 방식으로 그동안 진행했던 '<Lost In Hope> 개발 일지'의 종장을 적어보려고 합니다.
그럼 목차부터 살펴봅시다.
목차
- 무엇이 좋았는가? (Liked)
- 분석과 탐구 : 게임 디자인 이슈를 대하는 자세
- 논리와 설득 : 비전을 전달하는 자세
- 회고와 기록 : 성찰하고 성장하는 자세
- 시도와 실패 : 프로젝트 매니징을 다루는 자세
- 비전과 테마 : 나의 영혼을 대하는 자세
- 결론 - 무엇이 아쉬웠는가? (Lacked)
- 방향성 유지의 오류
- 규모 조절의 오류
- 관계 구축의 오류
- 완벽 지향의 오류
- 결론 - 무엇을 배웠는가? (Learned)
- 프로젝트로 팀원에게 의미를 부여하는 방법
- 타겟 유저라는 함정을 피하는 방법
- 체계를 다루는 방법
- 비전을 설정하는 방법
- 자유를 얻는 방법
- 결론 - 무엇을 바라는가? (Longed for)
- 내가 정의하고, 나를 정의하던 틀 해체하기
- 내가 집착하던 이상과 의미 놓아보기
- 나의 게임 디자인적 주관, 나아가 삶의 주관 찾기
이상입니다! 목차를 예쁘게 정리하고 싶어서 끝을 맞추다 보니 너무 거창해졌네요.
사실 자기 계발이나 게임 디자인에 관심이 있으면, 한 번쯤 들어봤을, 너무나 당연한 사실들을 다루는 내용이라 큰 기대는 하지 마시고 그냥 쉬엄쉬엄 보시면 좋을 것 같아요.
추가로, 모든 회고를 정리한 뒤에는 지금 무엇을 하고 있는지, 어떻게 진행하고 있고, 어떤 결과를 얻었는지 간단하게 소개하고 마무리 지으려고 해요.
서론이 길었는데 기대컨은 이쯤 하고, 같이 제 실패 원인을 낱낱이 살펴보도록 합시다!
무엇이 아쉬웠는가? (Lacked)
방향성 유지의 오류
방향성 유지의 오류는 '명확함'의 부재로 인해 발생한 오류예요.
먼저 <Lost In Hope> 프로젝트 제안 당시의 제 개인적인 목표는 다음의 2가지였어요.
- 팀원의 의견을 수용할 수 있는 유연함.
- 방향성을 유지할 수 있는 확고함.
전 당시에 커뮤니케이션이 제 약점이라고 생각했기에, 팀 프로젝트를 진행하며 방향성을 기준으로 팀원들과 문제없이 소통할 수 있기를 바랐어요. 의도는 좋았네요.
하지만, 저는 이 목표에 잘못된 인식을 갖고 있었어요. 바로 '의견을 수용할 수 있는 유연함'과 '방향성을 유지할 수 있는 확고함'이 대립하는 것이며, 이것들을 모두 이루려면 이 사이에서 균형을 잘 잡아야 된다고 생각한 거예요.
이 때문에 프로젝트 개발을 하면서 방향성이 길을 잡지 못하고 갈팡질팡한 것 같아요.
지금 생각해 보면 방향성 설정과 변경의 가이드를 정의해서 팀원들 합의 하에 글로 명시해 놨으면 어땠을까 싶네요.
당시에는 방향성을 명확하게 공유하지 않고 '이거는 이래서 안 돼.', '저거는 저래서 안 돼.'라고 생각하며 거부감을 보이기도 하고, 또 그러면서도 팀원들 기분이 상하지 않았을까 걱정하기도 했거든요.
만약 명확한 기준을 명시했다면, 팀도 확인하면서 본인들의 의견을 제안했을 거고, 서로 피드백을 하면서도 불편함이 없었을 텐데 말이에요.
이전에 방향성 공유를 위해 방향성 나무 같은 거 만들지 않았냐고요? 만들었죠. 근데 만들면 뭐해요. 복잡해서 읽히지가 않는걸요.
이게 참 어려운 것 같아요. 방향성을 단순하게 정리하면 모호함이 생기고, 상세하게 정리하면 읽히지가 않잖아요. 그래서 게임 디자이너의 능력이라는 게 방향성을 어떻게 정리하느냐로 갈리는 것 같기도 해요.
어떤 디자이너들은 딱 한 문장으로도 명확하게 그림이 그려지도록 표현하니까 말이에요. 효과적이며 좋은 표현을 할 수 있도록 많이 찾아보고, 작성해 보며 노력해야 될 것 같아요.
아무튼 이게 첫 번째 아쉬웠던 점이에요. 명확함의 부재로 인한 방향성 유지의 오류, 많이 아쉽네요.
규모 조절의 오류
규모 조절의 오류는 '과감함'의 부재로 인해 생긴 오류예요.
이건 위에서 언급한 방향성 유지의 오류와도 연관이 있는데요.
저는 <Lost In Hope> 프로젝트를 진행하면서 시스템을 디자인할 때마다 방향성에 신경을 많이 썼어요. 현재 방향성은 어떤 걸 목표로 하고 있고, 시스템은 어떤 경험을 불어 일으켜야 하는지에 초점을 맞췄죠.
그런데, 저는 방향성에 맞게 시스템을 더할 생각만 하고, 시스템을 뺄 생각은 하지 못했어요.
프로젝트를 진행할 때 방향성이 계속 흔들리면서 조금씩 바뀌었거든요. 이 때문에 이전에는 필수라고 생각했던 시스템이 나중에는 효과에 비해 자원만 많이 먹는 시스템이 되기도 했어요.
근데, 저는 이런 상황에 전체적으로 시스템을 살펴보며 줄일 생각을 하지 못하고, 어떤 시스템이 게임을 복잡하게 만드는지 찾아가며 이를 간단하게 바꿀 새로운 시스템들을 더하기만 했어요.
본질적인 시스템의 의도를 돌아보며 이를 압축할 생각은 하지 못했던 거죠. 아마, 개발 도중 본질적인 시스템을 수정하면 안 된다는 고정관념에 갇혀 있었던 것 같아요.
본질적인 시스템을 수정하면 안 되는 이유는 게임의 방향성이 달라지기 때문인데, 저희 프로젝트는 이미 방향성이 바뀌었는걸요. 그럼 본질적인 시스템 또한 이에 맞춰 바꾸거나, 최소한 주의 깊게 검토라도 했어야 됐는데 어떤 생각을 재해석하지 않고 그저 진리인 양 받아들이는 제 버릇 때문에 시스템을 뺄 생각을 하지 못했어요.
이 때문에 지금은 뭐든 그대로 받아들이기보다는 제 언어로 재해석하자고 생각하고 있으며, 저의 모든 사고 흐름을 가장 근본적인 원리에서부터 재정립하고 있어요. 저를 최적화하는 느낌이라고 할까요?
아무튼 이게 두 번째 아쉬웠던 점이에요. 과감함의 부재로 인한 규모 조절의 오류, 다시 실패를 반복하지 않기 위해 고정관념을 버리고, 근본 원리를 생각할 수 있게 노력하고 있어요.
관계 구축의 오류
관계 구축의 오류는 '관심'의 부재로 인해 발생한 오류예요.
지금에 와서 <Lost In Hope> 프로젝트를 돌아보면 다음 2가지 관점의 관계 구축에 아쉬움이 남아요.
- 팀원과 팀원 사이의 관계 구축
- 프로젝트와 팀원 사이의 관계 구축
팀원과 팀원 사이의 관계부터 말하자면, 저는 팀워크를 효율로 접근하려 했던 게 잘못됐던 것 같아요. 이전 항목과 마찬가지로 당시의 저는 커뮤니케이션이 약점이라고 생각했는데, 이 때문인지 팀원들 사이에서 서로 알아가려는 노력을 하기보다는 효율적인 커뮤니케이션을 하겠다고 접근에서부터 이상하게 한 것 같아요.
예를 들면, '모든 회의에 모든 직군이 참여해서 모든 이슈를 말하게 되면 분명 어떤 부분은 붕 뜨게 되기에 파트 별로 나눠서 진행하겠다.' 같은 내용이 커뮤니케이션 스킬을 키우기 위한 접근 방법이었는데, 분명 맞긴 하죠. 맞긴 하는데.. 커뮤니케이션을 위한다기에는 뭔가 이상하죠?
네, 저의 동료에 대한 관심은 사람을 향해 있던 게 아니라 효율을 향해 있었습니다. 아마 사람들 사이에서 일 외의 이야기를 하는 게 어색해서 이런 식의 접근을 한 것 같은데 바보 같죠? ㅋㅋㅋ. 바보 맞습니다.
<Lost In Hope> 프로젝트가 종료되기 직전에 참여했던 넥슨 게임잼에서 느낀 건데, 제가 어색했던 이유는 그냥 계속 의식하면서 잘 보이려고 하니까 이상했던 거였어요 ㅋㅋㅋ.
제가 관심을 가져야 할 부분은 효율이 아니라 팀원이었는데, 팀원들끼리 서로 알아가고 공감할만한 기회를 많이 제공하지 못한 게 너무 아쉽기도 하고 미안하네요.
만일, 다시 한번 팀을 운영한다면, 꼭 일로만 무언가를 하는 게 아니라 정기적으로 모여서 게임을 플레이하거나 이곳저곳 다니면서 같은 경험을 공유하고 인간적으로 알아가는 시간을 가져보고 싶네요.
항상 개발 과정에서 즐거울 수 있는 게임을 개발하자고 해놓고, 회사 같이 게임을 개발하기만 했으니.. 그냥 말이 안 나옵니다.
이번에 제 자신을 돌아보고 정립하는 과정에서 '다른 사람들은 어떨까?'라는 생각을 하며 타인의 삶을 알아가고 싶다는 관심이 생기기 시작했는데, 이에 비하면 이전의 삶은 너무 자기중심적이었던 것 같습니다. 사람에 대한 관심이 얼마나 중요한 지 25년 만에야 깨달았으니.. 이걸 다행이라고 해야 될까요.
언젠가 다시 한번 팀을 만든다면 '회사 같다.'가 아닌 '즐겁다.'를 말할 수 있는 팀이 될 수 있게 노력해야겠습니다.
다음은 프로젝트와 팀원 사이의 관계예요. 이 부분의 결론부터 말하면 저는 팀원에게 의미를 부여하지 못했다는 거예요.
이유는 단순해요. '팀원들이 무엇을 하고 싶은가?'가 아닌, '팀원들은 무엇을 할 수 있는가?'에 집중했고, 각자 그들이 가지고 있는 능력의 일부분만을 요구하며 팀원들이 성장할 수 있는 기회를 제공하지 못했어요.
이것 또한 왜곡된 고정관념 때문인데, '팀원들이 프로젝트에 즐겁게 참여하기 위해서는 할 일이 적어야 된다.'라고 생각했기 때문이에요. 믿기지가 않죠? 저도 직접 적으면서 이상한데, 당시에는 일을 최대한 줄여주자고 생각했어요. 왜 그랬는지 모르겠네요.. (아마 팀원들이 하기 싫어하는 일이라는 걸 무의식적으로 인식하고 있었기 때문이 아닐까요..?)
아무튼 팀원들은 자신들이 딱히 바라지 않는, 그리고 이미 할 수 있는 일만을 반복해서 요구하니 날이 갈수록 의욕이 떨어지는 것도 이상하지 않다고 생각해요.
비유를 하자면, 제가 가진 틀(방향성)에 팀원들이 가진 조각(능력)을 끼워 맞추기 위해서 잘라냈다고 하는 게 맞을 것 같네요.
팀 프로젝트란 내가 가진 틀에 상대를 끼워 맞추는 것이 아닌, 상대와 내가 가진 조각을 모아 만들어진 형상대로 틀을 맞추고, 빈틈은 각자가 매워갈 수 있게 제시하는 거라는 걸 너무 늦게 깨달았어요.
완벽 지향의 오류
마지막인 완벽 지향의 오류는 '여유'의 부재로 발생한 오류예요.
저는 당시에 회의를 하거나 작업을 할 때마다 효율적인 커뮤니케이션과 완벽함을 위한다며 필요 이상으로 과하게 무언가를 준비했는데요. 지금에 와서는 '이것 또한 하나의 주요 패인이 아닌가?'라는 생각이 들어요.
제가 효율적인 커뮤니케이션을 추구하며 행하고자 했던 완벽함은 효율적인 커뮤니케이션이 아닌 불통을 낳았어요. 제가 생각했던 완벽함은 팀원들에게 참여할 수 있는 여지를 남기지 않았고, 결국 반박하거나 의견을 낼 염두조차 내지 못하게 만들었죠.
.. 완벽함이란 뭘까요? 정답이 없는 세계에서 완벽함이란 그저 환상에 불과한 것이 아닐까요? 그리고, 그런 완벽함을 쫒으며 말하는 이는 이상만을 쫒는 돈키호테처럼 주변에 민폐를 뿌리고 다니는 이상한 사람이 아닐까요?
하지만 그럼에도 저는 완벽함에 대한 추구를 내려놓고 싶지는 않습니다. 그럼 저는 어떻게 해야 될까요?
아마 완벽함에 이르는 방법을 바꿔야겠죠.
지금까지의 저는 홀로 작업을 진행해도 큰 문제가 없었지만, 팀 프로젝트를 하며 여러 사람과 협업을 하기 위해서는 속도를 맞추고 각자가 그리는 완벽함을 맞출 필요가 있어요. 저만의 완벽함으로는 한계가 있다는 걸 확인했으니까요.
설령, 자신의 완벽함에 한계가 없다고 하더라도 마찬가지예요. 본인이 완벽하다면 팀원은 왜 필요한가요?
결국, 지금보다 더 위대한 일을 하기 위해서는 한 사람이라도 더 함께할 사람을 모아야 해요. 그러기 위해서는 자신만의 완벽함을 내려놓고, 모두가 공감하는 완벽함을 추구할 필요가 있고요.
만약, 그것도 싫다면 자신만의 완벽함을 모두가 공감할 수 있는 무언가로 만들어야겠죠.아직은 어려운 이야기지만 말이에요.
팀원이 협력할 수 있는 여지를 남기지 않는 것, 이것이 마지막으로 아쉬운 점인 완벽 지향의 오류예요. 지금은 제 완벽함, 그러니까 이상에 대해 다시 정의하고 있어요. 이게 전편에 말한 빛이랑 같은 말인데, 전편에서 말한 대로 조만간 이에 대해 정리하는 글을 작성해 볼게요.
결론
<Lost In Hope> 프로젝트에서 아쉬웠던 점을 하나의 키워드로 정리하면 아래와 같아요.
독선 (獨善)
이를 풀이하면 '신념이 되지 못한 고집을 행한 것' 정도가 될 것 같네요. 그리고, 제 고집이 신념이 되지 못했던 이유는 그곳에 저만 있고, 함께할 이들이 없었기 때문이겠죠. 이제는 인지했으니까 달라질 겁니다.
아래에 아쉬웠던 점을 요약하고 마무리 지을게요.
무엇이 아쉬웠는가?
- 방향성은 정리했어도, 방향성 수정에 대한 기준은 정리하지 않았다.
- 고정관념에 빠져 시스템을 과감하게 검토하지 않았다.
- 관계를 관심이 아닌 효율로 다루려고 했다.
- 나만의 완벽함을 추구했다.
다음 글로 들어가기 전에
이제 4L 중, 두 번째인 Lacked(무엇이 아쉬웠는가?)가 끝났네요.
다음 편에서는 Learned (무엇을 배웠는가?)로 찾아올게요.
저는 지금까지 그래왔듯이, 앞으로도 계속 나아갈 겁니다!
선곡 하나하고 사라질게용!
항상 응원해 주셔서 감사합니다 😊
'프로젝트 > Lost in Hope' 카테고리의 다른 글
| 프로젝트 종료를 맞이하며, <Lost In Hope> 회고록 (4) [完] (0) | 2023.10.28 |
|---|---|
| 프로젝트 종료를 맞이하며, <Lost In Hope> 회고록 (3) (0) | 2023.10.25 |
| 프로젝트 종료를 맞이하며, <Lost In Hope> 회고록 (1) (1) | 2023.10.23 |
| Lost In Hope - 06월 개발 일지 (0) | 2023.07.29 |
| Lost In Hope - 05월 개발 일지 (2) | 2023.07.02 |
