개발 시작 전 회의

신한 금융 SW 아카데미에서 5명이 팀을 이뤄 '오목 게임'을 만드는 미니 프로젝트를 진행하기로 하였다. 말 그대로 미니 프로젝트인 만큼 로컬 서버에서만 돌리기로 하였고, 그동안 배운 과목인 JAVA와 JSP만을 이용하여 코드를 작성하기로 하였다.

첫 번째 회의

전체 규칙을 작성하였다. 기간이 2주로 짧은 만큼 Agile모델을 채택하기로 하였고, 코딩 컨벤션과 Commit 컨벤션을 정하였다.

그 후 우리가 생각하는 필수 기능을 정했고, 프로젝트 진행 방식에 대해 상의하였다. 처음에는'기능'별로 역할을 나누어 풀스택으로 구현하기로 결정하였다. 하지만, 메인페이지의 로그인 버튼은 메인페이지 담당자가 구현을 해야 하는지, 로그인 담당자가 구현해야 하는지에 대한 의견 충돌에 부딪혔고 현업에서 하는 대로 '프론트 및 백'으로 역할 분담을 하기로 하였다.

이후 사다리 타기를 통하여 분야를 나누고, 두 번째 회의 전까지 와프를 짜 오기로 하였다.

두 번째 회의

다음은 내 와프의 일부이다. 피그마 사용이 익숙치 않은 팀원이 있어 직접 손으로 그려오기로 하였다. 솔직히 직접 그리기 전까지는 와프를 짜는건 디자이너가 해야 할 일이라 생각하였고, 심지어 디자인쪽을 힘들어하는 나에게는 너무 막막하였지만, 어떻게 해야 가장 효율적인 개발이 나올 수 있을지를 생각하며 와이어 프레임을 작성하니 재미있었고, 더 열심히 하고싶다는 욕구가 생겨 디자인도 시도를 해 보려고 한다. 강사님이 "개발에 소용 없는 경험은 없어요"라고 하셨는데, 확실히 와프 짜는 작업에 참여해보니 어떤 식으로 백엔드 로직을 작성해야 하는지도 눈에 보이고 좋았다. (로그인을 하지 않으면 다른 기능에 권한을 주지 않는 식으로 말이다)

 

각자 짜 온 와프를 기반으로 전체 로직을 결정하였다.

• 게임 화면에서만 실시간 채팅 (1:1)
• 자동 매칭 (유저가 방을 만들 필요가 없이 랜덤 매칭됨)
• 사용자 방 생성 → 생성하면 코드를 게임측에서 제공, 상대방이 코드 입력하면 방 입장

초반에는 마이페이지 및 로그인 구현하지 않기, 사용자 방 생성 기능 없애기, 관전 모드 등의 의견이 많이 나왔지만, 최대한 배운것을 활용하고 유저의 니즈를 고려하여 위와 같이 결정하였다.

이제 디자인에 대한 컨셉을 잡아야 해서 일요일까지 디자인 컨셉을 직접 그려 오기로 하였다. 이 기회에 피그마도 손에 익혀 나중에 디자이너와도 소통할 수 있도록 해야겠다.

세 번째 회의

피그마도 어렵고, 디자인도 너무 어려웠다. 각자 일요일까지 하기로 했지만, 팀원 중 하나가 정말 장난이 아닌 디자인을 뽑아와서 만장일치로 그 디자인을 사용하기로 하였다.

퍼블리싱 작업은 경력이 있으신 분이 해주기로 하셔서 최종적으로 역할 분담을 한 후 개발 진행 방식을 결정하였다.

각자가 맡은 기능을 중심으로 풀스택으로 프레임을 먼저 개발하기로 하였고, 이후에 소켓을 개발하기로 하였다.

작업 티켓을 나누었고, 이 티켓 번호로 pr 메세지의 제목을 작성하기로 하였다.(줄이 그어진 것은 이미 개발이 완료 된 것이다)

이후 팀원 중 한 명이 깃허브의 Projects 설정을 해 주었고, 여기다가 각자 할 일들을 공유하기로 하였다.

main 브랜치에 merge 할 때 올리는 pr message, projects 등 깃허브에 되게 다양하고 편리한 기능들이 많아서 신기했다. 또한, 작업 티켓을 나누는 방식은 처음 해 보는데, 개개인이 할 일을 커밋 메세지의 제목에 붙이는 것 보다 노션에 정리해 둔 작업 티켓과 번호를 기반으로 커밋 메세지를 올리니 더 깔끔하고 기능별 구분이 잘 되어 앞으로 종종 애용할 것 같다.