DevLog - 전략적 개발을 통한 협업 관리

서론

2~3명이서 가볍게 팀을 꾸려 작업할 때와는 다르게, 5명이 한 팀이 되면서부터는 의사소통방식에 대하여 진지하게 고민해 보아야 한다. 
왜냐하면, 사람이 한번에 자기 상태를 아주 가볍게 전파할 수 있는 인원은 3명까지가 한계이기 때문이다. 즉, 팀의 인원이 5명이 넘어가기 시작할 때 부터. 식사, 커피, 회의 직전&직후에 이뤄지는 짧은 담화 등의 상황에서 가벼운 상태 전파가 일어났을 때, 정보를 공유받지 못하는 1명 이상의 사람이 필연적으로 생기게 된다. 

 

본론

게임 개발에 있어, 개발자 (특히 클라이언트 개발자는) 각종 요구사항을 게임에 반영하는 역할을 하기 때문에. "기획-디자인-개발" 사이클의 가장 마지막에 위치한다고 생각되기 쉽지만. 하기에 따라서 얼마든지 각 단계에 영향을 미칠 수 있다.

이 영향에 대하여 이야기하기 전, 커뮤니케이션을 하는 이유에 대하여 먼저 짚어보자면, 회사에서 커뮤니케이션 목적은 정보 전달에 있다고 생각하는데. ^[각주:1]
다시말해 "내가 아는 정보 중에서 상대방이 모르는 것이나 필요로 할 법한 것을 파악해 전달하기 위해서" 우리는 동료와 회의, 보고, 요청메일 등의 방식을 빌어 시간과 자원을 쏟아 이야기를 한다. (물론 전달받기 위해서도 성립한다)

클라이언트 개발자의 장점은 "동작하는 무언가"를 만들어 낼 수 있다는 것이며. 사용하기에 따라 이는 굉장히 강력한 커뮤니케이션 도구가 될 수 있다. 가령 여기 레벨업을 위한 스킬 페이지가 있다고 가정하자. 내가 입사하기 전 팀에서는 새 페이지를 게임에 구현하기 위하여 다음과 같은 과정을 거쳤다.

1. 기획서 작성
2. 디자인 리소스 제작
3. 기능 개발
4. 인게임 적용
5. 테스트 & 검토
6. 회의 및 수정
7. 새 기획서 작성 
8. (1~7) 반복..

1에서 6까지의 과정은 순차적으로 수행되기 때문에, 높은 숫자의 절차는 항상 낮은 숫자의 절차가 끝날 때까지 대기해야 한다는 사실을 알 수 있다. 그리고 완성된 결과물의 수정에는 (그것이 아무리 작은 수정이라 할지라도 1 ~ 6까지의 테스크를 다시 밟아야 하기 때문에) 필연적으로 새로 만드는 것에 준하는 에너지를 필요로 할 것이라는 점을 쉽게 예상할 수 있는데. 

이때 인게임에 적용된 것을 검토해보고, 새 기획이나 수정사항이 나오기 위한 [최소 정보]가 존재하며, 이것을 적절한 타이밍에 제시해주는 것으로 저 사이클을 단축시킬 수 있다

깃 로그를 살펴보면
던전 관련 ui 리소스 등록 시작일 1월 5일 (기획은 더 전에 나왔을테지)
던전 탭 인게임 추가 1 - 19 (프리팹 수정)
실제로 (작동가능한) 던전 페이지가 나온 건
던전 페이지 구현 1 - 24 ~ 25일
즉, 기획 - 구현까지, 약 3주의 시간 소요

적절히 개입하면, 한 사이클을 1주일 안팎으로 압축할 수 있다.

수정내역

• 2022.11.06 앞장만 휘갈겨서 일단 써놓음. 12월 초까지 빌드 프리즈를 목표로 달리는 중이라 글 쓸 짬이 많지가 않다. 그래도 생각나는 것들은 일단 짧게라도 써두려는 중
• 2023.01.27 출시계획이 3월로 거의 확정되면서.. 진짜 눈코뜰새없이 업무가 몰아치는중.. 끝나는대로 이것부터 완성하자
• 2023.04.29 작성 중, 어색한 문장 먼저 다듬는 중 

---

각주

1. 1. 참고 링크, 개인적으로 굉장히 성공적인 커뮤니케이션 사례라고 생각했다. PPSS, "사내 커뮤니케이션의 중요성 by. 르미", https://ppss.kr/archives/207862, 2022년 11월 17일 [본문으로]