코드와트 프로젝트 (1) 팀 빌딩 & 서비스 기획

포스팅 시리즈 소개

---

나는 크래프톤정글 부트캠프 1기 수료생이다. 크래프톤정글은 스택 쌓기 위주의 부트캠프라기 보다는 전산학 지식을 쌓으면서 엔지니어로서 기초를 닦는데 방점을 두는 부트캠프다. 5개월 간의 여정 중 마지막 대미를 장식하는 “나만의 무기 갖기” 커리큘럼은 지금까지 배웠던 것을 결과물로 보여주는 과정이다. 나는 5명의 팀원 중 한 명으로서 "코드와트(NA-MAAN-MOO/Codewarts: 모같코 온라인 가상공간 플랫폼, 코드와트 (github.com))"라는 웹 메타버스 프로젝트를 진행했으며, 공동 작업 에디터 기능 구현을 도맡았다.

어떻게 해서든 제한된 시간 동안 원하는 아웃풋을 내기 위해 무수히 많은 삽질을 했고, 지금에 와서 하는 말이지만 안되는 걸 되게 하려고 엄청 애썼던 것 같다. 아쉬운 점이 없다면 거짓말이겠지만 결과물도 만족스러웠고 좋은 평가도 받았고 애정이 많이 가는 프로젝트다.

아쉬웠던 점 중 하나가 구현하면서 블로그에 포스팅을 남기지 못했다는 점이다. 사실 그럴 시간에 코드 한 줄 더 짜야된다는 압박감이 들어서 노트 앱에만 기록하고 포스팅으로 다듬을 여력은 없었다. 그 당시에는 무슨 경주마도 아니고 오로지 앞만 보고 달렸던 기억밖에 없다. 아무튼 그래서 지금이나마 코드와트 구현기 시리즈를 작성하며 어려웠던 점, 아쉬웠던 점, 좋았던 점 등을 해부해보려고 한다.

본 포스팅은 팀을 결성하고 코드와트라는 서비스가 어떻게 탄생하게 되었는지 기획 비화를 설명하고 다음 편에서는 본격적인 개발 이야기를 할 예정이다.

팀 결성

---

내가 같은 팀이 될 동료들에게 바랐던 점은 아래와 같다.

1. 소통이 잘 되고
2. 참여도가 높고
3. 프로젝트에 몰입하는 시간대가 서로 비슷했으면 좋겠다(=서로 비슷한 시간에 강의실에 있었으면 좋겠다)

지금 돌이켜보면 되게 이상적인 조건이었나 생각이 드는데, 또 운이 좋게도 그런 멤버로 팀이 구성되었다! 크래프톤정글이나 SW정글을 겪어본 사람들은 알겠지만 이 시기에 긴장감이 상당히 감돈다. 서로 물밑작업도 많이 오고 갈 뿐더러, 결성 과정에서 서로 마음 상하는 일도 생길 수 있고 누군가에게는 굉장히 스트레스 받는 기간이다. 나도 나름대로 내적갈등이 있었다.

돌이켜보면 팀을 결성하는 이 시기에 중요한 걸 배웠다. 어떻게 사람의 마음을 얻을 것인가에 관한 문제다. 능력이 뛰어난 개발자가 되는 것과 같이 일하는 동료의 마음을 얻는 개발자가 되는 것 둘 다 너무나 중요하다. 여하튼 당시에는 '어벤져스 못지 않은 이상적인 팀을 구성해야 한다’는 것이 이 시기 나의 뇌를 지배하는 단기 목표였다.

결론적으로 나름 수월하게 팀 결성이 되었다. 너무 이상적인 조건이었다고 자평했지만 운이 좋게도 실제로 저런 팀원들을 만났다. 일사천리로 팀이 되었고 팀 결성이 확정되었다. 그리고 모든 과정을 다 겪고 난 지금 자평하자면, 갈등이 아예 없었던 것은 아니나 프로젝트 결과 측면으로나 프로세스 측면으로나 만족스러웠던 한 달이었다. 그리고 나 역시 그렇게 되게끔 그간의 경험을 통해 얻은 지식과 노하우를 총동원 했다.

코드와트 팀은 분위기도 좋고 수월하게 프로젝트를 잘 진행하는 팀이었다. 실제로 이는 나만의 생각이 아니라 같이 부트캠프를 진행한 다른 동료들로부터 종종 들은 의견이기도 하다.

모각코 메타버스 기획 비화

---

"메타버스상에서 서로 알고리즘 문제를 풀며 각자의 에디터 창에 들어가 코드 리뷰를 한다"는 아이디어가 갑자기 튀어나왔다. 이 아이디어를 떠올리게 된 과정은 전형적인 유레카 케이스(?)였다.

사실 모각코 메타버스 아이디어를 내기 전에 여러 공 들인 아이디어가 폐기되었다. (안티 소셜 SNS, 랜덤 모닝콜, 벌금 기반 챌린지 앱 등) 팀을 결성하고 난 다음의 단기 목표는 프로젝트 아이디어를 확정짓는 것이었다. 그래야 빠르게 개발에 착수할 수 있기 때문이었다. 우린 각자 n개의 아이디어를 내고 프레젠테이션을 진행하고 익명 투표로 결정했다. 그렇게 내부 회의로 아이디어가 결정 되면 figma로 열심히 공들여 와이어프레임을 만들고 코치님들 앞에서 프레젠테이션 했다.

그리고 무참하게 다 까였다.

"좀 더 기술적으로 챌린져블하고 신선했으면 좋겠다"는 피드백을 정글 내부의 모든 팀이 지속적으로 받았다. 머리를 맞대고 아이디어를 말 그대로 쥐어 짜냈다. "우리 계속 이렇게 주제 결정이 안 되면 어떡하지"하는 걱정과 서로 좋은 아이디어 있냐고 묻기를 반복했다.

빈백에 누워 있던 팀원이랑 얘기를 나누다가 메타버스 키워드가 나왔다.

“메타버스나 만들어 봐? ㅋㅋㅋ”

하면서 웃었는데 사실 그 당시만 해도 '메타버스를 우리가 어떻게…???'하는 생각이었기 때문에 진지함은 없었다. 그런데 사실 우리가 요구 받은 것은 우리의 한계를 넘을 수 있는 주제여야 했기 때문에 이상하게도 점점 메타버스가 끌리기 시작했다.

(실제 우리가 진행했던 디스코드 모각코)

그러다가 그 친구와 내가 매일 아침 모각코를 한다는 사실이 떠올랐다. 그날 아침도 모각코 멤버들과 디스코드에 모여서 알고리즘 문제를 풀고 있었다. 내가 한참 삽질을 하고 있었는데, 화면 공유를 통해 지켜보던 A라는 동료가 "그거 그렇게 하는거 아니야"라면서 고친 코드를 채팅으로 보내 주었다. 나는 그 코드를 복사해서 내 에디터에 붙여넣기 했고, "서로의 화면에 들어가서 코드를 직접 고쳐 주고 리뷰할 수 있다면 편할텐데."라는 생각을 했었다.

그날 아침에 있었던 이 일화가 메타버스 키워드와 결합되었다. "모각코를 메타버스에서 하자! 그리고 실시간으로 서로의 에디터를 보면서 코드를 공유하고 편집할 수 있게 하자. 디스코드처럼 목소리로 얘기하자."는 아이디어를 제시했고, 반응이 괜찮았다. 왜냐하면 우리 모두 "근데 그런 걸 어떻게 만들어??? 우리가 만들 수 있어??"라는 의문이 들었기 때문에 이 정도면 코치님들이 통과시켜주겠다는 느낌이 들었기 때문이다.

급하게 와이어프레임을 짜서 프레젠테이션을 진행했고 주제를 그대로 가도 될 것 같다는 피드백을 받았다. 되게 얼떨떨하면서 기분이 좋았다. 어떻게 개발할 지는 1도 감이 안 왔지만 일단 개발할 수 있다는 생각에 안도했다. 그렇게 우리 팀은 가장 빨리 주제가 정해진 팀이 되었다. 중간 발표 때도 주제 확정에 관한 불안을 감출 수 없었는데 장병규 의장님의 컨펌(?)을 받는 날이었기 때문이다. 다행히 긍정적인 피드백을 받았다.

사실 알고리즘 문제 풀이 + 동료들과 모여서 코딩하기 = 부트캠프 생활 그 자체였기 때문에, 애쓰지 않아도 우리가 만들고자 하는 서비스에 공감할 수 있었다. 어떤 기능이 있었으면 좋겠는지, 어떤 기능은 꼭 필요한지, 어떤 기능이 있으면 진짜 재밌을 것 같은지 아이디어가 무궁무진했다. 그러다보니 프로젝트를 진행하며 기획 측면에서 혼란이 왔던 적은 없었다. (그리고 그런 일을 방지하기 위해 초반에 빡센 내부 회의와 합의를 통해 기능 명세서를 작성했다.)

코드와트 기획

---

모각코 메타버스 아이디어가 정해지고 본격적인 기획 단계에서 우리는 뭘 했냐면, 다음과 같은 것들을 했다.

1. 기능 명세서 작성
2. UI 와이어프레임 만들기
3. 서비스명 정하기
4. 기술 스택 정하기
5. 디자인 컨셉 정하기

기획명세서 작성하기

여기서 내가 꼭 필요하다고 주장한 것은 기능 명세서 작성이다. 그 이유는 초반에 아이디어 회의를 하면서 똑같은 "모각코 메타버스"라는 주제를 두고도 세부적인 구현 희망사항이 각기 다 다르다는 걸 확인했다. "메타버스, 공동 작업 에디터, 오디오 커뮤니케이션"이라는 세 가지 핵심 기능에는 모두가 동의했지만 구체적으로 어떤 모습으로 구현되었으면 좋겠는지는 각자 생각이 달랐다.

예를 들어, 누군가는 마치 카카오톡처럼 여러 모각코 방을 만들어서 참여할 수 있길 바랐고, 누군가는 최대 정원이 25명인 (그 이유는 우리 반 인원이 25명이었기 때문) 하나의 방만 운영하길 바랐다. 또 다른 사용자의 에디터를 확인하는 기능도 물리적으로 맵 상에서 유저의 근처에 가까이 가야지만 확인할 수 있게 할 건지, 아니면 사용자 이름을 단순 클릭만 해도 볼 수 있게 할 건지 의견이 달랐다. 그리고 각자 자신의 경험에 기초하여 그렇게 주장하는 마땅한 이유도 가지고 있었다.

최대한 지금 합의 하에 정할 걸 정하고 가지 않으면 개발하면서 서로 혼선이 있겠다는 생각이 들었고, 그 점은 충분히 자원을 낭비할 만한 요소가 될 것 같았다. 가장 필요하고 효과적인 것에 우리가 가진 모든 것을 쏟아 부어야 했기 때문에 그럴 순 없었다. 게다가 지금 이렇게 쏟아져 나오는 플랜 B, C 아이디어를 그냥 폐기하고 기억에서 지워버리는 것도 아쉬웠기 때문에 기록해두는 편이 좋을 것 같았다.

해서 최대한 기능에 관한 의견을 많이 수집하고 각자가 어떤 구현 아이디어를 가지고 있는지 공유했다. 그리고 기능에 관한 한 가지치기 전략으로 갔다. 기능 명세서에 우리가 바라는 최대한 많은 기능을 작성하고 그것의 대안이 될 플랜B, C 아이디어도 같이 적었다. 그리고 주장하고 설득하고 납득시키는 과정을 통해, 그 아이디어 중에서 우리가 “실제로” 개발할 기능만 구체적으로 정해나갔다. 기능 명세서를 처음 작성해보았지만 레퍼런스를 참고하며 형식을 갖췄다.

팀을 결성하면서 소통이 잘 이뤄지는 팀원이랑 함께 팀을 하고 싶다고 바랐었는데, 무엇보다도 이런 과정이 자연스럽고 건강하게 이루어지길 원했기 때문이었다. 하루 종일 기능 명세서 토론을 했고 드디어 모두의 머리속에서 공통적인 코드와트 그림이 그려졌던 것 같다.

아래는 당시 작성한 공동으로 작성한 기능 명세서이다. 굵은 글씨는 실제로 구현한 사항이고 파란 글씨는 우리가 여력이 된다면 추가 할 수도 있는 기능, 특정 기능의 대안이 될 기능 등이었다. 자연스럽게 구현의 우선순위가 정해지며 추후 개발 단계에서 나나 팀원들이나 "나 뭐해야 돼?"하는 혼란이 줄었고 개발에 집중할 수 있었다.

실제로 다른 팀들이 개발 단계에서 A 기능을 추가하느냐 마느냐, A 기능은 구현이 불가한데 어떤 기능으로 대체할 것이냐 열띠게 토론하는 것을 많이 봐왔는데 우리는 초반 이 시기에 그런 토론을 몰빵해서 진행한 셈이었다.

(기획 단계에서 작성했던 기능 명세서)

UI 와이어프레임 만들기

팀원 중 figma에 능숙한 친구가 있었다. 그래서 figma는 상당 부분 그 친구가 많은 걸 도맡아 했다. 우리는 개발 외에 손이 많이 가는 작업(PPT 만들기, 와이어프레임 짜기, 포스터 만들기)은 무조건 figma 같은 협업 툴을 이용해 다 달라붙어 공동작업했다. 그래서 한 사람이 혼자서 하는 것보다 빨리 끝났고 지속적으로 피드백을 주고 받을 수 있었다.

서비스명 정하기 & 컨셉 정하기

코득코득

초반 기획 아이디어 정할때와 마찬가지로 각자 떠오르는데로 브레인스토밍을 하고 익명 투표로 진행했다. 사실 코드와트가 되기 전에 코득코득이라는 이름으로 불렀다. 지금의 코드와트는 호그와트에 영감을 받은 마법학교 컨셉인데 처음에는 "코득코득"이라는 이름의 정글 속 강의실이 컨셉이었다.

(초창기 와이어프레임)

코득코득에서 지금의 "코드와트"로 이름이 바뀌게 된 계기가 있다. 이때 사실 한 차례 팀 내 갈등이 있었다.

때는 우리가 본격적인 개발에 들어서기 전, 스택에 익숙해지기 위해 개인적으로 학습을 진행하고 있을 때였다. 코드와트는 Phaser라는 라이브러리를 이용해 메타버스 맵을 구현했다. 두 명의 팀원이 메타버스 구현을 맡았고 본격적으로 서비스에 올릴 맵을 만들고 그 위를 돌아다닐 캐릭터가 필요했다. 그리고 이때도 서로 바라는 바가 달랐다.

• 팀원A - 핑크와 파스텔톤의 파니룸 스타일, 싸이월드 미니룸 느낌
• 팀원B - 게임빌 프로야구같은 캐주얼한 느낌
• 팀원C - 우린 고를 수 있는 선택권이 없다, 있는 에셋 따라가야 한다
• 나 - 일랜시아, 어둠의 전설, 디아블로1처럼 좀 다크한 세기말 감성

(팀원 A의 원픽 파니룸 스타일)

팀원 B가 파니룸에 난색을 표했다. 남성인 본인이 피씨방에서 이걸 하고 있으면 옆에서 쳐다볼 것 같다고 말했다. 듣고 보니 그렇겠다 싶어서 A 친구의 아이디어는 채택할 수 없었다. 나는 추억의 넥슨 1세대 RPG 향수가 있어서 일랜시아 느낌을 원했는데 슬프게도 다들 일랜시아가 뭔지 몰랐다… 하여튼 그 와중에 우리는 다음과 같은 사항에는 모두 동의했다.

1. 강의실은 아이소메트릭 뷰
2. 로그인 페이지는 사이드뷰(횡 스크롤)
3. 캐릭터는 웬만하면 3등신 이상
4. 성별에 상관 없이 즐길 수 있는 컨셉

아이소메트릭을 선택한 이유는 간단하다. 우리는 탑다운 뷰를 피하려고 했다. 너무 게더타운이 생각나기 때문이었다. 그리고 특유의 초록색 & 갈색의 조화도 피하고자 했다. (아래와 같은) 마찬가지의 이유로 게더타운처럼 2등신 캐릭터는 피하고자 했다. 한편 로그인 페이지는 유저가 많은 활동을 할 필요가 없어서 구태여 아이소메트릭을 고집할 필요가 없었기 때문에 횡스크롤이면 충분했다.

일일이 도트를 찍을 시간과 자원은 없었기 때문에 일단 가능성을 열어두고 위와 같은 느낌만 아니라면 자유롭게 에셋을 찾아보자고 결론을 지었다. "강의실"이라는 키워드만 가지고… 그래서 퀄리티 좋고 우리의 컨셉과도 잘 맞는 에셋을 찾아 며칠 간 에셋 파밍을 했다.

문제: 원하는 에셋이 없다

그런데 문제에 봉착했다.

1. 현대적인 느낌의 에셋 자체가 적다
2. 있는 것도 퀄리티가 마음에 들지 않는다
3. 심지어 그에 맞는 캐릭터 에셋은 더 없다
4. 서로 다른 제작자의 에셋을 한 맵에 표현하다보니 크기도 안 맞고 이질감이 있다

기왕이면 같은 도트라도 고퀄리티, 더 귀엽고 더 예뻤으면 좋겠고, 신선한 느낌을 원했는데 그런 것들은 백이면 백 서양 판타지 or 중세시대 마을 컨셉이었다.

맵 제작 담당 팀원 D가 그나마 찾은 모던 컨셉 에셋으로 강의실 맵을 제작했다. 솔직히 내 눈엔 지극히 무난한 싸이월드 기본 미니룸으로밖에 안 보였다. (아래 이미지에서 책상, 컴퓨터, 의자, 사람밖에 없다고 보면 된다.) 싸이월드 미니룸이 인기 있었던 이유는 다양한 컨셉의 미니룸 에셋이 존재했고 사용자가 자신의 캐릭터와 미니룸을 커스터마이징 할 수 있었기 때문이다.

우리는 그 정도의 재미를 줄 수 있을만큼 에셋도 없었고 제작할 여력도 없고, 심지어 캐릭터 옷도 갈아입힐 수 없었다. 캐릭터도 무개성하고 매력이 없었고 종류도 다양하지 않았다. 정말 레벨 1 기본캐 느낌!

(여기서 책상, 컴퓨터, 의자, 사람밖에 없다고 보면 된다)

메타버스 맵은 우리의 핵심 기능 중 하나고, 보는 사람으로 하여금 제일 먼저 임팩트를 전달해주는 역할을 해야 하는데 이대로 서비스가 만들어진다면 적어도 나는 이 서비스에 별 흥미를 못 가질 것 같았다.

팀원 C의 말이 맞았던 것이다. 우리에겐 선택권이 없었다. 에셋 제작할 여력이 안되는 한 기존의 고퀄리티 에셋을 따라가는 것이 베스트겠다는 생각이 들었다.

갈등: 대뜸 판타지

그래서 나는 판타지, 중세의 성 컨셉으로 맵을 꾸미자고 제안했다. 그리고 그에 맞게 폐기된 이름 후보 중 "코드와트"를 사용하자고 했다. 마침 그에 딱 걸맞는 에셋 패키지도 있었다. 게다가 내 생각에 마법학교 컨셉을 잡으면 추후에 생길 세부적인 디자인 요소의 결정도 고민할 필요 없이 쉬워질 것 같았다. (예를 들어, 코드와트 게시판의 메모지를 구현하며 고민할 필요 없이 포스트잇이 아닌 양피지 디자인을 선택할 수 있었다.) 게다가 마법이라는 요소가 들어가면 좀 더 화려한 이펙트를 쓸 수도 있을테고 여러모로 게임적인 요소를 추가해도 잘 어우러지겠다고 생각했다.

팀원 D가 나와 같은 생각을 했다. 반면 팀원 A, C는 현대적인 강의실 컨셉을 유지하자고 하였다. A와 C의 의견은 다음과 같았다.

1. 판타지 컨셉이 기획 의도에 공감하는데 방해가 될 것 같다
2. 발표 때 "말이 안 된다"고 부정적인 피드백을 받을 것 같다
3. 너무 모험인 것 같다

여기에는 사정이 있는데 초반에 우리 팀과 다른 팀들의 기획이 코치님들에게 무참하게 다 까일 때, 기술적으로 약하다는 피드백 외에도 “주제가 공감이 가지 않는다”, "말이 되지 않는다"는 피드백을 들은 팀이 많았다. 나는 이런 피드백이 의미하는 바가 '이런 서비스를 만든다고 했을 때 납득이 되는가, 당신이라면 쓸 것 같은가’의 여부라고 생각했다. 즉, 프랑켄슈타인같은 서비스를 만들지 말라는 뜻으로 받아들였다. 예를 들어, 배달 앱을 만드는데 배달기사 아저씨와 영상 통화를 하면서 참참참 게임을 진행하는 서비스 같은?

팀원 A, C가 어떤 생각으로 반대하는지는 이해했지만 나는 그들의 의견에 동의하지 않았다. 강의실에서 코딩하든 호그와트에서 코딩하든 우리가 핵심으로 하는 공감 포인트 "모여서 다같이 코딩을 한다"는 점은 변하지 않기 때문에 그런 피드백에 해당되는 사례가 아니라고 생각했다. 그렇기 때문에 이 사항은 우리가 자의적으로 약간의 모험을 해도 전혀 무리 없는 부분이라고 봤다. 하지만 그래도 A와 C는 불안한 기색이었기 때문에 (주제가 또 까일까봐), 그럼 내가 먼저 코치진에게 의견을 구해보겠다고 했다. 긍정적인 의견을 들어야 안심할 듯 보였다.

결론적으로 코치님이 "말하는 그런 부분이 공감 요소를 해치는 결정적인 역할을 할 것 같지 않다"는 의견을 주셨고 그에 따라 A와 C도 안심하고 우리의 의견을 받아들였다.

맵 제작과 캐릭터 고르기

속전속결로 에셋 구매를 진행하고 맵 제작에 돌입했다. 맵 제작은 메타버스 기능을 맡은 팀원 D가 도맡아 했다. 왜냐하면 이 팀원이 우리들 중 가장 디자인 감각이 뛰어난 친구로 인정받았기 때문이다.

에셋을 받는다고 맵이 자동으로 뚝딱 생성되는 것은 아니다. Tiled라는 프로그램을 사용했는데 클릭의 연속과 노가다의 산물이다. 공동 작업이 불가한 툴이라 그 친구의 노고에 온전히 기댈 수밖에 없었다. 팀을 위해 본인이 희생한 거나 다름 없어서 미안한 마음이 들었다. 예상대로 결과물에는 우리 모두 만족스러웠다. 👍

한편 나는 내가 즐겼던 그 모든 2D 고전 게임들이 모두 이런 노가다로 탄생한건가? 싶어서 아득해졌고 새삼 디자이너 분들이 정말 대단하다고 생각했다.

(내가 제일 좋아하는 초록 공주 캐릭터)

캐릭터를 고르는 과정은 마치 쇼핑을 하듯이 참 즐거웠다. 우리는 여러 제작자의 캐릭터를 짬뽕시켜 집어넣지 말고 한 명의 제작자의 에셋을 쓰기로 했다. 또 열심히 에셋 파밍을 하다가 우리는 보물같은 에셋 제작자를 만났다. (이름하야 Wayward) 퀄리티도 좋고 무료인데다가 굉장히 다양한 컨셉의 캐릭터가 있어서 각자 취향껏 마음에 드는 캐릭터를 골라 모조리 코드와트에 넣어버렸다.

캐릭터를 메타버스 내에 삽입하는 일은 맵 제작 만큼의 노가다는 아니어도 일일이 이미지를 편집해야 해야해서 역시나 번거롭다. 하지만 맵 제작과 달리 우리가 도와줄 수 있는 부분이 있어서 생각보다 금방 끝낼 수 있었다.

(현재 코드와트는 28개의 캐릭터를 선택할 수 있다)

이렇게 해서 코드와트 기획에 관련해서 말할 수 있는 부분은 다 다루어봤다. 캐릭터까지 정해지고 이제 정말 개발 뿐이야 하는 심정으로 개발에 몰입했다. 다음 편부터는 기술 스택을 정하는 것부터 시작해 본격적으로 눈물나는 시행착오 개발기를 작성할 예정이다. 많은 관심 부탁드립니다.