Baby-on-top
Baby-on-top has 6 repositories available. Follow their code on GitHub.
github.com
나만무 프로젝트가 마무리되고 벌써 1주일이 지났다. (현재 글을 쓰는 시점은 약 3주…)
이력서를 쓰다 보니 나만무 경험을 녹아내야 하는 상황들이 많은데, 후기를 작성하면서 경험을 정리해보면 좋을 것 같다.
👊 리더 해볼까?
이전까지 랜덤으로 팀이 발표되었다. 나만무에서는 코치님들이 일부 개입하시긴 하지만 팀 구성이 자유롭다. 리더는 함께 하고 싶은 팀원을 우선순위로 작성하고, 팀원도 역시 원하는 팀장을 우선순위로 선정하는 방식이다.
리더를 지원해볼까 하는 생각은 나만무가 시작하기 전부터였다.
사실 나는 전공자이고 오랫동안 IT 동아리 활동을 하면서 개발 실력은 부족하지만, 익숙했다. 그래서 나에게 어떤 자극과 고난(…?)을 주고 싶다는 생각이 들었다. 지금까지 프로젝트를 하면서 리더보다는 팔로워로서 경험한 적이 많기 때문에 리더는 나의 새로운 도전이었고, 리더의 시선으로 보는 프로젝트를 어떠할지 궁금했다.
그렇게 리더를 지원했다!
📌 팀 프로젝트
내가 생각한 리더의 역할은 다음과 같다.
“팀에서 팀원들이 잘할 수 있는 것을 할 기회를 주는 것, 그리고 같이 프로젝트 하는 사람들이 프로젝트를 통해 얻어가는 것이 있는 것”
그것은 꼭 개발 실력이 아니어도 된다. 단지, 프로젝트 하는 시간이 낭비되지 않았으면 하는 마음이었다.
이런 마음가짐을 가지고, 팀 프로젝트를 시작했지만 쉽지 않았다.🥲
그래도 팀 매칭이 완료되고, 프로젝트가 시작되었다.
💭 기획 발표
정글에서 나만무는 1주 - 기획 선별, 2주 - MVP 개발, 2주 - 폴리싱(완성도 올리기)으로 이루어져 있다.
그만큼 개발 시간을 충분히 확보하려면 첫 주에 기획이 어느 정도 선별되는 것이 중요한데, 우리 팀은 운이 좋게 기획이 빠르게 확정되었다.
우리 팀의 아이디어는 협업을 위한 화이트보드 개발로, 주요 기능은 실시간 협업 기능과 자유로운 위젯 배치이다.
기획 단계에서 고려해야 하는 부분은 어느 정도 난도가 있고(기술적 챌린지를 보여줄 수 있는), 재미있는 그런 아이디어를 찾아야 했다. 또 최종 발표에서 시연을 고려했을 때, 지루하지 않을 그런 프로젝트를 생각해야 했다.
기획이 확정되고 나서부터는 대략적인 와이어 프레임을 그리고, 구현해야 하는 기능들을 정리하기 시작했다.
일단 우리 팀은 대략적인 아이디어는 모두 같은 생각이었지만, 그것을 구체화할 때 어떤 제품이 나올지 생각하는 것이 모두 달랐다. 그래서 일단 와이어 프레임을 그리고, 그려진 와이어 프레임을 보면서 기능 목록들을 정리했다. 이 기능 목록들을 다음에 백엔드에서 구현해야 하는 API 리스트와도 연결되었다.
⚒️ 개발
우리 팀은 백엔드 3명, 프론트엔드 2명으로 구분하고 대략적인 기술 스택을 결정한 후에 본격적인 개발을 시작했다.
- Frontend: react, javascript
- Backend: spring, java
일단 이번 프로젝트가 첫 프로젝트이거나 처음 React를 사용하거나, Spring을 쓰는 팀원들이 대부분이었다. 내 생각은 1~2주차는 백엔드에서는 CRUD나 로그인 기능을, 프론트엔드에서는 해당 기능들을 연결할 수 있도록 환경을 구축하면서 도구들에 적응하는 시간을 갖고 이후에 핵심 기능을 구현하면 될 것이라고 생각했다.
하지만…
로그인은 핵심 기능이 아니다.
MVP 개발이 시작되고, 첫 주 차에 받았던 피드백은 "로그인은 당장 중요한 것이 아니다"였다.
맞다.
우리 팀이 보여줘야 할 것은 1) 실시간으로 협업하고, 2) 위젯을 자유롭게 배치하는 모습을 보여줘야 했다. 그래서 첫 주차의 피드백까지 우리가 보여줘야 했던 것은 우리가 목표로라는 주요 기능을 구현하기 위해서 이런 기술들이 필요하고, 이런 것을 이렇게 적용해보니 MVP로 가져갈 수 있을 것 같다. 혹은 이런 부분은 쉽지 않을 것 같다 그런 것을 검증해야 했다.
이 밖에도 개발 과정에서 코치님의 요구사항과 우리 팀이 이해한 것이 달라 발생한 소통 오류가 있었는데, 그 과정에서 일주일이라는 시간이 허비되었다. 결국 폴리싱 기간에도 기능 구현에 집중할 수밖에 없었다. 소통 오류가 발생한 것도 아쉽지만, 인력을 적절히 분배하여 일부 팀원들은 원래 생각했던 기능을 구현하는 데 집중했으면 어땠을까 싶기도 하다.
🛞 팀을 이끌기 위해
일단 한 달 동안 정말 거의 모든 것을 함께 할 팀원들이기 때문에, 팀 분위기가 좋았으면 했다. 마지막에는 모두 바빠서 여유가 없었지만, 가능한 저녁은 함께 먹고 강의실에 있는 시간을 최대한으로 가져갔다. 그 외에도 주말에는 저녁에 카공하거나 회식 있을 때는 제대로 놀기도 하면서 팀원들과 스트레스도 푸는 시간을 가졌다.
1. 스크럼
리더로서 팀원들에게 바라는 점이 있다면, 각자가 무엇을 하고 있는지 알고 싶었다!
다만 매일매일 스크럼을 가져가는 것은 쉽지 않았기 때문에, 팀 슬랙에 Geekbot을 연동하여 팀원들의 작업 진행 내용과 오늘 할 일을 등을 파악했다. (feat. 매일 랜덤 질문도 던졌다~)
초반에는 이 부분이 낯설기도 했지만 거듭하다 보니, 그날 할 일이 명확해지고 목표를 다질 수 있어 유익했다.
2. 작업 보드 관리
우리 팀은 초반에는 프론트와 백엔드를 구분하여 작업했다. (후반에는 프론트 인력이 부족해서 백엔드에서 프론트 작업을 함께 진행했다)그러다 보니 누가 어디까지 작업이 완료되었고, 어떤 작업을 하면 좋을지 파악하는 것이 필요했다. 그래서 이 부분은 작업 보드를 생성하여 진행 상태(`To-do`, `In progress`, `Complete`)와 작업 구분(`FE`, `BE`, `ALL`), 작업자, 스프린트, 타임라인(일정)을 명시했다. 사실 작업 보드가 잘 유지되려면 작업 단위가 작아야 하며, 작업 내용이 명확해야 하고, 무엇보다 꾸준한 업데이트가 중요했다. 그래서 이 부분의 중요성을 팀원들에게 설득하는 것이 필요했다.
처음에는 팀을 이끌어가기 위해 어떤 장치를 마련하는 것을 찾아봤다.
같이 스터디하거나, 스크럼을 하고, 작업 보드를 마련하고, 주기적으로 회고를 쓰고 등등이다. 하지만 우리에게 주어진 5주라는 시간 동안 이것을 다 가져가기는 쉽지 않았다. 정글 과정의 최대 장점이 합숙하여 몰입하는 것을 최대한 살려서 강의실에 있는 동안 함께 앉아 무엇인가를 하는 것이 가장 속도가 빠른 방법이었다.
📝 마무리
사실 만족스러웠던 것보다 아쉬운 것이 기억에 많이 남는다.(좋았던 것은 분명하다!)
가장 큰 부분은 기술적 챌린지이다.
우리 팀은 시연에서 유의미한 결과를 보여주기 위해 마지막까지 기능 개발에 집중하고, 눈에 띄는 버그들을 수정하는데에 집중하다보니 구현한 기능에 깊이있는 고민을 충분히 하지 못했다. 어떻게 보면 지금이 그런 것을 다듬을 수 있는 폴리싱 단계가 아닐까 싶기도 하다🧼
그 외에도 팀장으로서 활동하다보니 개발에 집중하기 어려웠다. 일단 매주 주간 발표가 있으며, 초반에는 기획 발표에 후반에는 포스터, 최종 발표, 발표 영상등을 만들어야 하다보니 개발에 집중할 시간이 많이 없었다. 아쉬움이 남는 기능들을 보고 넘어가야한다는게 아쉬웠다.
이밖에도 지금 지나고보니 이때는 이렇게 팀을 이끌어갔다면 어땠을까 하는 아쉬움도 있다.
하지만 아쉬움은 뒤로하고, 앞으로가 중요하다.
수료하고 집에 온 시점에 이 글을 작성하고 보니, 그때가 그립기도 하다. 정말 힘들기도 했지만 돌이켜보면 그게 전부였던 재미있는 시간이었다.
마지막으로 한달동안 함께한 우리 팀원들과 멘토님 모두 감사합니다!😊
다음글에서는 우리 프로젝트의 기술적인 부분에 대해 정리해보겠다.
+) 다른 팀의 멘토님이 작성하신 글이 유익해서 첨부합니다!
