들어가며
오늘은 <Lib's Rarry> 프로젝트(이하 LR) 재개 일주일을 앞두며 지금까지의 개발 과정에 대해서 이야기해보려고 한다. LR은 2024 넥슨 대학생 게임잼에서 시작된 게임으로 4가지 기술을 활용해 적을 처치하는 덱빌딩 로그라이크 게임이다.
당시 LR이 더 발전될 여지가 많이 보이기도 했고, 마침 주제에 적합하지 않은 게임 기획에 더해 발표를 제대로 하지 못한 것이 아쉬웠기에 프로젝트를 이어가기로 결정했다.
그렇게 현재 휴식 기간을 포함해서 약 5개월 정도 개발을 이어가고 있는데, 학기말 휴식으로 인해 여유가 생긴 지금이 글을 쓸 적기라고 생각해 이렇게 글을 남긴다.
글의 목적은 개발 과정의 기록이기에 이번 글에서는 어떻게 개발이 진행돼왔는지를 중점적으로 다루려고 한다. 기획에 대한 내용은 다음 편 '『Lib's Rarry』 - 어떻게 차별성 있는 재미를 이끌어냈는가? (feat. 프로토타입)'에서 자세히 다루도록 하겠다.
글은 기억나는 이벤트들을 시간 순으로 정렬해 소개할 예정이다. 그럼 목차부터 살펴보자.
목차
- 게임 볼륨 논의 및 일정 계획 (7월)
- 게임의 컨셉과 재미 요소 정의 (7월)
- 세계관 레퍼런스 조사 및 스토리 정리 (7월)
- 아트 작업 전달 문서 작성 (7월 ~ 8월)
- Figma UI 프로토타입 (7월 ~ 8월)
- 프로그래밍 파트와의 커뮤니케이션 (7월 ~ 8월)
- 팀 작업 전달 방식의 전환 (8월)
- 팀 인원 관리 (8월 ~ 9월)
- 데이터 테이블 관리 및 밸런싱 삽질 (8월 ~ 9월)
- 기초 기획 마무리, 그리고 이어지는 의문 (10월)
- 프로토타이핑과 함께하는 기획 개선 (10월 ~ 11월)
- 팀 단위 테스트, 그리고 결과 (11월)
음.. 적다 보니 복잡해진 것 같은데, 새로 분류하는 것보다 시간 순으로 간략하게 소개하는 편이 더 잘 이해될 것 같아 부득이하게나마 이렇게 정리한다. 그럼 같이 한번 살펴보도록 하자.
그동안의 개발 과정
(24.07 ~ 24.11)
게임 볼륨 논의 및 일정 계획 (7월)
7월 중순, 2024 넥슨 게임잼이 끝나고 LR 프로젝트를 시작하면서 가장 먼저 한 건 게임의 볼륨을 결정하는 것이었다. 당시에는 단순하게 아트의 변경 없이 기술의 시너지만 조금 더 추가하려고 했다.
그러나, 이에 대해 이야기를 해보니 다들 의욕이 있었고, 특히 아트 분이 새로 캐릭터와 UI를 디자인해보고 싶다고 하셔서 컨텐츠 추가가 아닌 리메이크의 형태로 프로젝트를 시작하게 됐다.
다음으로 결정한 건 이 프로젝트의 목적이었는데, 간단하게 내가 생각하는 게임의 방향성을 말씀드린 뒤, '이 프로젝트로 다른 공모전에 참가할 것인가?'에 대한 이야기를 많이 했다.
여러 공모전이나 게임잼이 후보로 나왔고, 평소의 나였다면 이에 대해 긍정적으로 고려했을텐데 바로 직전에 주제 맞추기에 대한 실패 경험을 해서 그런지 참가를 망설였다.
이런 점을 눈치채고 배려를 해주신 건지 다행히 우리만의 페이스로 게임을 개발하자고 의견을 정리할 수 있었고, 그렇게 9월까지 베타 버전을 개발하는 걸 목표로 프로젝트를 시작했다.
게임의 컨셉과 재미 요소 정의 (7월)
다음으로 진행한 건 방향성에 대한 명확한 정의였다. 당시 게임잼을 마치고 약 1~2주간 휴식을 하게 됐는데, 이때 우리 게임의 포지션과 방향성에 대해 고민을 해보며 이를 정리해 봤다.
물론, 이건 방향성을 공유하거나 작업자를 설득하는 과정에서 사용하기 위한 문서가 아니다. 내 스스로 방향을 잃지 않고 잘 기획하고 있는지 참고하기 위해 작성한 문서였다. (심심하신 분들은 읽어봐도 좋을 것 같다고 풀어놓긴 했지만..)
이렇게 정리를 했던 건 지난 <Lost in Hope> 프로젝트에서의 실패 때문이다. 당시 핵심 컨셉과 목표 경험이 명확하지 않다면 의도가 뒤섞이게 되고, 그럼 꼭 필요하지 않은 메커닉들이 많아지면서 게임의 재미가 흐려진다는 걸 깨달았다. 이에 이번에는 최소한의 메커닉으로 최대한의 재미를 구현해보고자 위처럼 컨셉과 재미 요소를 정의해 봤다.
이는 후술할 기획 개선 과정에서 새로 만들어졌기에 지금은 참조되지 않지만, 당시 기초 기획을 마무리할 때까지는 플레이어 경험 흐름을 머릿속에 인지하는데 많은 도움을 받았다.
세계관 레퍼런스 조사 및 스토리 정리 (7월)
원래 같았으면 이렇게 컨셉이 정리된 이후 바로 시스템 기획과 정리에 들어갔을 텐데, 당시에는 바로 작업해야 될 아트 분들이 계셔서 아트 쪽부터 기획을 시작했다.
이때 가장 먼저 했던 건 레퍼런스 조사였는데, 콜로소 시네마틱 강의를 들으며 알게 된 'PureRef'라는 프로그램으로 레퍼런스를 정리하고 메모하여 아트 분들께 전달드렸다.
기존의 나는 아트 레퍼런스를 드릴 때 따로 요청하지 않으면 간략하게만 드리는 편이었다. 내가 내 스스로 원하는 기획을 할 때 즐겁듯이, 아티스트 분들도 자기 취향에 맞는 작업을 하는 게 즐거울 거라고 생각했기 때문이다.
그런데, 이번 아티스트 분은 레퍼런스를 비롯해 세계관 설정까지 그림에 반영하는 걸 좋아하시는 분이라 이전보다 더 상세하게 레퍼런스와 세계관 문서를 작성하고, 스토리까지 상세하게 정리해서 한 번에 넘겨드렸다. 사실 스토리는 상세하게 할 생각이 없었는데 작업자 분과 이야기하다 보니 어느새 작성하고 있는 나를 볼 수 있었다.. 😂😂
그래도, 정말 유의미했던 경험이었다. 원래는 기획을 할 때 구현에 치중돼서 '이 작품이 감성적으로 어떤 느낌을 전달할 것인가?' 보다는 '이 시스템이 의도대로 온전하게 동작할 것인가?'에 초점을 맞춰 기획하기 일쑤였는데, 이 경험을 통해 아티스트 분들은 게임을 어떻게 보고 있는지, 유저는 무엇을 느낄지 고민할 수 있었고, 이 과정에서 생각의 범위가 확장된 것 같다.
아트 작업 전달 문서 작성 (7월 ~ 8월)
레퍼런스 시트를 작성한 이후에는 캐릭터와 배경 모델링에 대한 작업 전달 문서를 작성했다.
원래는 9월 말까지 작업이 완료되려면 늦어도 8월 초에는 작업 전달을 해야 된다고 생각해서, 조급해진 상태로 문서 없이 말과 글로 커뮤니케이션을 했다.
이러다 보니 부정확한 요청에 피드백이 너무 잦아졌고, 불쑥불쑥 들어오는 피드백 요청에 계속 1~2시간가량 소모하니 다른 작업에 집중이 되지 않았다.
이 때문에 레퍼런스 시트를 작성한 것이었고, 여기에 확실한 기준을 더하기 위해 PPT로 작업 전달 문서를 따로 작성했다.
몬스터 작업 요청 문서의 경우, 우선 통일감을 줄 공통된 디자인 컨셉에 더해 어떤 방식으로 몬스터를 구분하기를 바라는지 전달했다. 각 몬스터에 대해서는 내가 생각하는 설정과 컨셉, 그리고 인게임에서 사용하는 기술, 마지막으로 그 기술들을 통해 플레이어로 하여금 어떤 경험을 만들 것인지 정리해 전달했다.
추가로, 외형에 대한 반복적인 피드백을 줄이고자 내가 생각하는 원형을 간단하게나마 그려 첨부했다. 이렇게 문서를 작성했고, 이후에는 문서가 의도대로 잘 기능할까 걱정했는데 다행히 아티스트분이 기대 이상으로 작업해 주셔서 문제없이 작업을 진행할 수 있었다. (근데 소통 오류로 채색 작업이 남은 상태에서 입대하셔서 어떻게 해야 되나 고민이다 😥😥)
다음은 배경 작업 요청 문서다. 이 문서에는 움직이지 않을 사람 오브젝트를 포함해 레벨에 배치될 소품과 레벨의 구조에 대해 정리했다. 이때 레벨을 컨셉별로 구분을 해서 각 공간의 목표와 핵심 특징이 무엇인지 정의했고, 공간에 배치될 각 소품들의 목표 유저 반응은 무엇인지 정의하여 최대한 내 생각이 공유되도록 정리해 봤다.
이 과정에서 내가 생각하는 공간을 전달하기 위해 프로토타입을 만들면 좋겠다는 생각을 했는데, 이를 위해 'Figma'를 활용하여 레벨과 UI 프로토타입을 구성해 함께 첨부했다. 이에 대해서는 다음 항목에서 같이 살펴보도록 하자.
Figma UI 프로토타입 (7월 ~ 8월)
앞서 언급한 것처럼 UI 프로토타입은 내가 생각하는 화면 구성, 그리고 게임 진행에 따라 이 화면이 어떻게 바뀔 것인지 전달할만한 것이 필요해 작성하게 됐다.
기본적으로는 이전 <Lost in Hope> 프로젝트에서 진행했던 것처럼 작업했고, 이에 더해 레벨의 평면도와 측면도, 그리고 카메라의 방향을 추가로 표기하여 내 생각이 보다 잘 전달될 수 있도록 작성했다.
그리고, 'Figma'의 기능을 확인해 보니 preview라고 해서 구성한 UI를 미리 시뮬레이션할 수 있는 기능이 있길래 아래와 같이 구성을 해서 전달했다.
프로그래밍 파트와의 커뮤니케이션 (7월 ~ 8월)
프로젝트 시작 당시, 아트 파트의 작업 전달을 위해 프로그래밍 파트 작업 전달에는 소홀해졌다. 따라서, 문서를 작성하기보다는 어떤 기능이 필요한지 말씀드리고 이에 대한 시각 자료를 간단하게 첨부해 전달하는 방식으로 소통했었다.
다만, 이는 곧 한계를 맞이했는데 플머분들의 한계라기보다는 내 스스로 작업 관리가 안 돼서 이 때문에 문서로 정리하기로 했다. 이렇게 만든 게 아래의 임시 작업 요청 문서다.
이건 아트 작업 전달 이전에 만든 건데, 당시에 플머분들에게 제대로 작업 전달을 드리지 못해서 '디자인 필요 없어! 전달만 빠르게!'라고 외치며 급하게 데이터 테이블, 더미 json 파일과 함께 만들어 전달했다. (순서상 아트 사이에 들어가면 흐름이 끊길 것 같아서 7월 ~ 8월로 묶고 여기에 정리한다.)
팀 작업 전달 방식의 전환 (8월)
이렇게 팀원 분들에 대한 기본적인 작업 전달이 이뤄진 후에는 작업 전달 방식을 바꿔보고자 했다.
기존에는 플밍 파트의 경우 회의 기록을 통해서 작업 진행을 확인했고, 아트 파트의 경우 아래처럼 따로 필요 리소스 시트를 만들어 Figma UI 프로토타입과 함께 볼 수 있도록 해서 작업 진행을 확인할 수 있게 구성했다.
다만, 여러 파일을 왔다 갔다 하면서 참조해야 하기에 쉽게 눈에 들어오지 않았고, 그렇게 큰 효과를 보이지도 않았다. 이에 대해 고민하던 중 아래와 같은 생각을 하게 됐다.
퀘스트처럼 작업 단위를 구분해서 드릴 수는 없나?
마침 이전에 <뚜두 농장> 프로젝트 마무리 전에 잠시 노션을 활용했던 적이 있는데, 이처럼 작업 별로 티켓(페이지)을 만들어놓고, 해당 티켓에 관련된 자료를 같이 첨부하는 방식으로 작업을 전달하고자 했다.
이런 생각을 바탕으로 아래와 같이 작업 전달을 위한 노션 시트를 구성해 봤다.
당시에는 9월 말까지 진행한다고 생각해서 이렇게 쭉 나열하도록 구성했는데, 개발 기간이 늘어나서 조금 많아졌다. 그런데, 이번에 다시 재개하고 나서는 word랑 같이 사용하는 방식으로 진행할 것 같다.
아무튼 이렇게 구성한 노션 시트에 들어갈 작업들에는 아트 파트의 경우 PPT 작업 전달 문서에 정리해 놨기에 그냥 첨부만 했다.
그리고, 프로그래밍 파트의 경우 필요 작업 설명, 자가 확인을 위한 테스트 목록, 필요하다면 기획 의도와 프로토타입을 첨부해 정리하는 방식으로 구성했다.
여기서 유의미했던 건 3가지 인 것 같다.
첫 번째는 문서에 대한 욕심을 버렸다는 것이다. 원래는 나중에 '포폴로 쓸 수 있지 않을까?'라는 생각에 무분별하게 PPT나 word로 작성했었는데, 이번에는 그냥 전달에 초점을 맞춰서 작업별로 노션에 정리하다 보니 보다 간단하고 직관적으로 전달할 수 있게 된 것 같다.
자가 판단뿐만 아니라 언제 한 번 날 잡고 플머분들한테 기획 쪽 작업 방식에 대한 피드백을 요청드렸는데 지금 방식이 좋다고 말씀하시기도 해서 이대로 진행하기로 결정했다.
두 번째는 시각적인 자료를 많이 사용했다는 것이다. 내가 짧은 인디 게임 개발 경험을 돌아보며 '작업자들은 기획서를 잘 읽는가?'라는 질문을 던졌을 때 안타깝지만 아니라는 결론을 내릴 수 있었다. 이건 작업자들이 잘못한 게 아니라 그냥 사람은 복잡해 보이는 걸 회피하는 성향이 있고, 이에 글보다는 그림을 선호하게 되는 것이다.
근데 그렇다고 그림으로 모든 게 전달이 가능하냐? 이건 또 아니다. 그림은 직관적으로 전달이 되나, 그 직관이 내 직관과 같을 거라고 보장할 수 없다. 그래서, 이 당시에 이런 고민 때문에 그림의 형태지만 비교적 정확하게 정보를 전달할 수 있는 시각적 자료에 꽂혔었다.
그래서 다음과 같이 Figma UI 프로토타입을 비롯해, 이전보다 기능별로 세분화하여 단순하게 만든 플로우차트, 로직의 흐름을 그리는 시퀀스 다이어그램, 내가 생각하는 기능 프로토타입을 적극 활용하여 전달력을 약간이나마 높여봤다.
이때 중요한 건 아래 흐름대로 무조건 만들어달라고 하는 것이 아닌 생각 전달을 위한 방식일 뿐이라고 인지드리는 것이다. 내가 아무리 구조화를 할 수 있다고 해도 구현과 유지 보수는 프로그래머의 영역이기에 작업 방식을 존중할 필요가 있다. 그래서, 구현 완료 시 이후 기획을 위해 간략하게나마 설명 부탁드리는 방식으로 진행하고 있다.
마지막은 프로토타이핑이다. 나는 코드를 읽고 수정할 수 있으며, ChatGPT를 어느 정도 다룬다. 그리고, 프로토타입은 유지 보수 상관없이 내가 원하는 기능을 시각적으로 보여주기만 하면 된다.
나는 이러한 2가지 특성에 기인해 ChatGPT를 이용해 프로토타입을 보여주면 더 효과적으로 전달할 수 있을 거라고 생각했다. 그래서 실제로 몇 가지 프로토타입을 만들어 전달드렸는데 확실히 훨씬 효과적인 것 같다. 원래 글과 도표로 정리하면 30분 정도 걸릴 내용이 프로토타이핑은 15분이면 끝나서 효과적이었다.
팀 인원 관리 (8월 ~ 9월)
다음은 팀 인원 관리다. 우리 팀은 전원이 대학생으로 구성되어있다 보니 졸업 작품 준비, 시험 기간 등의 개인 사정으로 인해 프로젝트에 집중하기 어려웠다.
심지어 8월 말에는 배경 아티스트 분이 졸업 작품으로 11월 말까지 휴식, 9월 말에는 캐릭터 아티스트 분이 입대하셨고, 10월 초에는 프로그래머 한 분이 졸업 작품으로 인해 12월 중순까지 휴식하게 됐다.
그래도, 8월 초에 나랑 군생활을 보낸 병찬님이 UI 및 이펙터로 합류하기도 했고, 다른 프로그래머분이 열심히 노력해 주셔서 이렇게 지속될 수 있었다. 휴식 기간이라고 하더라도 일주일에 한 시간 정도 있는 회의에는 꼭 참석하기로 하기도 했고 말이다.
사실 인원 관리라고 할 건 없지만, 가장 골치 아픈 이슈 중 하나라 이렇게 적어봤다. 현재는 지금 집중이 어렵다면 12월 중순까지 졸업 작품을 비롯해 웬만한 일들은 다 처리해 두자고 해서 다들 휴식 중에 있다.
12월 중순부터 프로젝트에 집중해서 개발하기로 했는데, 부디 잘 되기를 바란다. (아트랑 사운드는 또 언제 어떻게 구해..)
데이터 테이블 관리 및 밸런싱 삽질 (8월 ~ 9월)
사실 이건 몇 달 전에 '게임 효과의 밸런싱 기준을 찾아보자.'라는 글에서 다뤘었다. 그래서, 간단하게 요약하면 데이터 테이블을 만들었고, 이를 json으로 변환해서 프로그래머 분들이 로드해 게임 내에 적용할 수 있도록 구성했다고 정리할 수 있을 것 같다.
아래는 데이터 테이블 이미지랑 밸런싱에 대한 회의록인데.. 밸런싱의 경우, 지금 대부분 바뀌기도 했고 굳이 쓰지 않아도 될 내용을 놀지는 않았다고 저렇게 적어놓은 거라 불필요했던 것 같다. 그냥 새로운 경험을 했다는 것에 의의를 두고 넘어가자.. 😉😉
이후, 9월 말은 시험 기간이라 2주가량 팀 휴식을 했다.
게임 효과의 밸런싱 기준을 찾아보자. (feat. Python을 활용한 삽질 기록)
들어가며 최근의 나는 라는 프로젝트에서 활동하고 있다. 는 2024 넥슨 대학생 게임잼에서 시작된 게임인데, 당시 주제 적합성, 발표 등 개인적인 부족함에 팀원들에게 미안한 마음을
memoria-aeon.tistory.com
기초 기획 마무리, 그리고 이어지는 의문 (10월)
10월에는 기초 기획을 마무리 짓고, 이를 word나 통합된 문서로 정리할 예정이었다. 이에 10월 중순까지 노션에 기초 기획과 이를 위한 더미 데이터를 정리했고, 이후 정해진 수순대로 통합 문서를 작성하는 일만 남았다. 그런데 통합 문서를 작성하려는 찰나 문득 이런 생각이 들었다.
우리 게임이 플레이할 만한 가치가 있을까?
어떻게 완성을 해서 출시를 한다고 해도 이 게임이 플레이될 것 같지는 않았다. 내 스스로 '괜찮은 기획'이라고 생각했지만, 이는 어디까지나 '괜찮은' 정도에 불과할 뿐이었다.
기획자라면 꼭 해야 되는 질문이고, 가장 중점적으로 다뤄야 하는 질문인데 다시 한번 이를 놓칠 뻔했다. 그래서 이번에는 제대로 해보자는 생각을 했고, 이에 회의를 통해 기획을 개선하고 싶다고 말씀드렸다. 다행히 다들 긍정적으로 반응해 주셨고, 이에 개선을 시작했다.
기초 기획 마무리, 그리고 이어지는 의문 (10월)
항목을 열기에 앞서 여기서부터는 다음 편, '『Lib's Rarry』 - 어떻게 차별성 있는 재미를 이끌어냈는가? (feat. 프로토타입)'에서 자세하게 정리할 예정이기에 이번 글에서는 비교적 간단히 넘어감을 양해 부탁드립니다 😊
개선으로 시작하고 처음에는 페이퍼 프로토타입으로 만들어 재미를 테스트하고자 했다. 이에 차근차근 준비를 하고 있는데 문득 저번 <Lost in Hope> 프로젝트의 페이퍼 프로토타입 플레이 경험이 생각났다. 그리고, 이를 되돌아보면서 다음과 같은 의문이 들었다.
과거의 나는 좋은 완성도로 실제에 가까운 경험을 추구했지만, 이와 함께 자유로운 아이디제이션은 불가능하게 만들었던 건 아닐까?
빠르게 아이디제이션을 하며 개선해 나가야 할 단계에서 완성도 있는 프로토타입을 만들고 온전히 플레이하기를 바랐으니 얻을 수 있는 경험도 한정된다는 생각을 했다. 그래서, 이번에는 별다른 준비를 하지 않았다.
그런데 웬걸, 당시에 병찬님이랑 만나서 테스트를 진행했는데 이전보다 훨씬 더 좋은 결과를 얻을 수 있었다. 우선 자유롭게 사고할 수 있었던 게 컸고, 다양한 변화본을 플레이하는 과정에서 창의적인 아이디어들이 여럿 나와 플레이하고 개선하는 과정 자체가 재미있었다.
이렇게 어느 정도 갈피가 잡히고 나서는 내 스스로 정리하면서 개선해 나갔는데, 곧 팀원들에게도 플레이해보게 해야 될 것 같아 퀄리티를 높여봤다. 개인적으로 이번 테스트가 프로젝트의 존속을 결정짓는 테스트라고 생각했기에 가능하면 설득력을 높이고 싶었다.
그래서, 이를 구성하고 다시 한번 병찬님한테 원격으로 테스트를 요청드렸다. 원격으로 테스트할 때 원래는 파이썬으로 카메라에 체력 바 넣어서 화면 공유로 플레이하려고 했는데 실제로 해보니 카메라 화질도 좋지 않았고 무엇보다 불편했다.
이에 고민하던 중, 병찬님이 Figma에서 해보는 건 어떻겠냐고 제안을 했다. 어차피 자료도 컴퓨터에 있기에 옮기는 것도 간단해서 한번 Figma로 옮겨봤다. 그리고, 결과는..
아무튼 이렇게 서너 판 정도 하니 어디를 어떻게 고쳐야 될지 감이 왔고, 다시 한번 개선에 개선을 거듭해 아래와 같이 프로토타입을 준비할 수 있었다.
팀 단위 테스트, 그리고 결과 (11월)
테스트를 진행하기 전, 나는 매우 긴장한 상태였다. 내가 아무리 열심히 구성했다고는 하지만 열심히 했다는 것이 무조건 잘했다는 것이 될 수는 없으니 말이다. 팀의 사기가 달려있는 만큼 부담감이 느껴졌다.
그래도, 길게 준비했던 지난 시간들을 기억하면서 한 번 잘 진행해 봤다. 처음부터 모든 것을 소개하기에는 부족한 말솜씨에 괜히 팀원들 머리만 복잡해할 것 같아 최소한의 규칙만 설명했고, 나머지는 진행하면서 말씀드렸다.
그리고, 결과는...
다들 생각보다 재미있게 플레이해 주시기도 했고, 무엇보다 의도한 플레이가 나옴과 함께 그 플레이에서 재미를 느끼는 팀원들을 보는 게 너무 행복했다. '이래서 기획자 하는구나.'라는 걸 다시 한번 느꼈다.
사실 그 이전 버전까지 테스트하면서 우여곡절도 많았고, 뭔가 아직 '괜찮다'는 틀을 깨지 못한 것 같아서 불안했는데 이번 팀 단위 테스트에서 깔끔하게 재미있는 결과가 나오니 너무 행복했다.
당시 테스트를 마치고, 팀원 분들께 구현이 가능할지 여쭤봤는데 이때 이런 답변을 받았다.
구현은 고려하지 않으셔도 돼요. 어떻게든 만들 수 있어요.
개발자 입장에서 가장 무서운 건 개발을 다 해놔도 재미가 없어서 사람들이 안 하는 거에요. 그럴 때면 회의감이 진짜 심하게 들어요.
그러니까, 구현은 어떻게든 해볼테니 상원님이 제일 재미있게 할 수 있도록 만들어보세요!
이때, 내가 지금까지 핀트를 너무 잘못 잡고 있었다는 생각이 들었다. 반성해야지.
... 그러나 이전의 내 행동을 돌아보면 이렇게 말을 해도 나는 계속 구현 쪽으로 이끌리는 경향이 있다. 그러니 내가 재미에 집중할 수 있는 장치가 필요하다. 사고 패턴이라고 해야 될까? 지금 당장 어떻게 방법이 떠오르지는 않는데 의도적으로라도 재미에 집중할 수 있는 방법을 찾아봐야겠다.
아무튼 이렇게 그동안의 개발 과정 리뷰는 끝이다!
마치며
모두 긴 글 읽느라 고생 많았다. 글을 쓰다보니 성장하고 있음이 느껴졌다. 개발자가 아닌 기획자로서 말이다. 지난 5개월이 무의미하지는 않았던 것 같아서 감사할 뿐이다.
우리는 마지막 회의 이후, 12월 중순까지 휴식하면서 프로젝트에 지장이 갈만한 활동을 정리하는 시간을 갖기로 했다. 다음 주인 12월 14일 토요일부터 다시 집중 시작이다!
그럼 다시 한번 나아가보자..!
'프로젝트 > Lib's Rarry' 카테고리의 다른 글
| 『Lib's Rarry』 - 프로젝트 중간 정리 (내부 공유용) (0) | 2025.03.10 |
|---|
