7개월간의 대장정이 드디어 끝났다. (21년 말 ~ 22년 8월 초)
회고를 하며 부족했던 점이 뭔지 파악해 보려 한다.

회고

에브리타임(대학생 전용 커뮤니티 서비스 - 시간표 및 강의평가 기능 제공)에서 수원대학교의 시간표 & 강의평가 서비스를 최신 데이터로 업데이트해주지 않아 직접 만들었다.
처음에는 시간표 앱만 만들어서 배포하였는데 생각보다 반응이 뜨거웠고 강의평가 기능도 추가하면 좋을 것 같았다.

그래서 교내 IT 동아리 FLAG에서 팀원을 모집했다.
초기 멤버는 iOS - 1, WEB - 3, Backend - 2, Android - 1으로 구성되었다.

다들 초보였기 때문에 공부를 하며 개발을 해야하는 상황이었다. (7개월이나 걸린 이유) 심지어 디자이너도 없어서 와이어프레임과 디자인 전부 내가 맡아서 했다. (초기 와이어프레임 보러가기)
(이때는 디자인이 깔쌈하다 생각했다 ... ㅎㅎㅎ)

협업 경험은 한이음 활동을 한번 해본게 전부라 트렐로, 슬랙 ... 이런 협업 프로그램들을 정말 하나도 몰랐고 구글 문서, 카카오톡으로 회의 및 진행 상황을 공유했다. (첫 회의록)

그러던 중 교내 알고리즘 대회 1등을 하게 되었고 수상자들 중에 안드로이드를 공부하시는 분이 있다는 걸 알게되었다. 주변에 안드로이드를 개발하는 사람이 없던 나는 친해지고 싶어서 많은 어필(?)을 하였고 그 분과 대화를 하던 도중 실력이 좋으신 분이라는 것을 알게되었다. 같이 협업하면 좋을 것 같아 제안을 했고 고맙게도 수락해주셨다!

새로 오신 안드로이드 파트 분이 트렐로와 잔디를 써보는게 어떠냐고 해서 바로 도입했다. 트렐로로 전체 진행상황을 파악할 수 있었고 잔디로 토픽(슬랙으로 치면 채널)으로 대화 주제를 나누는 부분도 너무 유용했다.

이렇게 프로젝트가 잘 진행되었으면 좋았겠지만 그러진 않았다.

1. 백엔드 팀원 이탈

벡엔드 팀원들(A, B)끼리의 마찰이 있었다.
A는 실력이 B에 비해 모자랐다. A도 나름 공부를 한다고 하였지만 B와의 실력 차가 좁혀지지 않았다. 추가로 A는 연락이 잘 안되는 문제가 있었고 이 때문에 B와의 갈등이 좀 있었다. 나는 이 사실을 B가 직접 해당 문제를 개인 메세지로 알려준 다음에야 알게 되었다.

우선 이 문제를 해결하기 위해 백엔드 팀원을 추가 모집(B의 의견)했고 A에게는 어떤 내용을 공부했는지 B에게 공유해달라고 부탁했다. A가 노력한다는 사실을 알면 B와의 갈등이 어느정도 해소될 거라 생각했다. 하지만 A는 공부한 내용을 B에게 공유를 잘 하지 않았고 결국 갈등은 더 심해졌다. 또한 A가 공부한 내용을 봤을 때 열심히 했다는 느낌을 받지 못했다. (B도 마찬가지 였을 것이다.) 결국 A를 내보내기로 결정했다.

어떤 점이 문제였을까?

팀장 자격 미달
각 팀원들이 잘 하고 있는지, 문제는 없는지 파악했어야 했는데 그러지 않았다. 다들 알아서 잘하겠지라는 생각이었는데 이게 너무나도 잘못된 생각이었다. A와 B가 갈등이 있다는 사실을 B가 말해줘서야 알다니 ... 너무 소극적인 태도로 프로젝트에 임했던 것 같다.
-> 적극적으로 팀원들과 소통하여 문제를 미리 파악했다면 A가 나가지 않거나 갈등을 해소할 수 있었을 텐데 ... 지금 생각해보니 너무 아쉽다. 다음에는 팀원들이 협업을 어떻게 진행하고 있는지 개발이나 소통하는 부분에서 어려운 점은 없는지 등을 미리 파악하자!

다들 열심히 한다고 말했으니, 진짜 열심히 하겠지
프로젝트 인원을 모집할 때 카카오톡으로 간단한 자기소개 및 각오만 받은 게 조금 문제였던 것 같다. 지원자가 책임감이 있는지 무언가를 열심히 해 본 경험이 있는지 실력이 어느 정도인지 연락은 잘 되는지 시간 투자를 확실하게 할 수 있는지 등을 파악했어야 했는데 너무 건성으로 뽑았다.
-> 팀원을 구할 때는 기준을 깐깐하게 잡자!

2. 팀원들의 참여도

인턴, 외주 등으로 인해 프로젝트에 많은 시간을 투자하지 못한 팀원들이 있었다. 인턴과 외주 기간 동안 참여를 못하는 건 괜찮았지만 문제는 해당 활동이 끝난 이후에도 참여를 잘 하지 않았다는 것이다. 심지어 다른 개인 프로젝트는 작업하면서 Suwiki 프로젝트는 건드리지도 않는 팀원이 있었다. 프로젝트 데드라인까지 기간이 꽤 있어서 그냥 내버려두었지만 여기서 또 갈등이 생겼다.

일단 나 조차도 "분명 Suwiki 프로젝트를 먼저 시작했을 텐데 왜 개인 프로젝트를 더 우선시 하는 거지?", "인턴(외주) 끝난 지 일주일이나 지났는데 왜 아무런 작업을 하지 않지?" 등 의문이 많이 생겼고 ... 팀원들 일부 역시 불만이 조금씩 있었다.

어떤 점이 문제였을까?

역시 소통과 나의 소극적인 태도가 문제였던 것 같다. "뭔가 이유가 있겠지" 라고 생각하지 않고 적극적으로 프로젝트에 집중하지 않는 이유를 물어봤으면 더 좋았을 것 같다. 사정이 있겠지만 팀장으로서 프로젝트에 더 집중해달라고 충분히 요청할 수 있었다. 이미 지난 일이지만 많이 아쉽다.
-> 소통, 소통, 소통

3. 일정 관리

데드라인은 8월로 정했지만 세부적인 일정은 정하지 않았다. 마일 스톤과 MOSCOW를 적용했으면 좋았을 것 같다. (이때는 이런게 있는 줄도 몰랐지만 ㅠ) 정해진 일정이 없으니 나를 포함한 팀원들이 늘어지는 게 조금씩 보였다. 이를 해결하기 위해 일주일에 한번씩 회의를 통해 진행상황을 팀원들 전체가 공유하였고 다행히 효과가 있었다.
-> 장기 프로젝트인 경우 일정을 세부적으로 정하자 + 주기적인 진행 상황 보고 필수

---

프로젝트를 하며 생겼던 문제는 이 정도가 끝이다. 소통이 정말 중요함을 느꼈다.

이어서 회고를 해보자.
프로젝트를 진행하던 도중 백엔드 팀원이 디자이너분을 팀원으로 데리고 오셨다. 내가 기존에 했던 디자인을 갈아엎으셨는데 정말 디자인이 깔끔하고 너무 좋았다. (괜히 디자이너가 있는게 아니구나 ... 싶었다.) 그 다음부터는 순조로웠다. 모든 파트가 개발을 완료 했고 몇번의 테스트 기간을 거친 후 Suwiki 배포에 성공했다. 개발을 하며 깨달은 점을 먼저 얘기하고 배포 이후의 이야기를 하겠다.

개발을 하며 깨달은 점

유지보수 하기 쉬운 코드의 중요성

Suwiki를 개발하기 전, 즉 혼자서 개발을 할때는 하드코딩을 했다. 하지만 이번에 같은 안드로이드 팀원분이 MVVM 패턴을 적용해보자고 하셨고 유데미 - 안드로이드 앱개발 부트캠프를 보며 각자 공부를 해왔다. 처음 MVVM을 적용해본거라 미숙한 점이 많았지만 적용해보길 참 잘한 것 같다. 그 이유는 다음과 같다.

1. 코드를 분리시켜 놓으니 버그를 찾기가 한결 수월했다.
   ex) 서버에서 데이터를 받아오는 부분이 이상하네? -> viewModel 부분 확인
   ex) 화면에 보이는 데이터가 조금 이상하네? -> 데이터 바인딩이 잘못되었는지 확인

2. viewModel을 여러 화면에 재활용 -> Suwiki에서는 무한 스크롤 기능을 추가한 CommonRecyclerViewModel을 재활용했다.

유닛테스트 하기에도 편하다는데 아직 유닛테스트 경험은 없다...

디자인패턴 이외에도 styles.xml, color.xml을 적극적으로 활용하니 수정사항이 생겼을 때 반영하기가 너무 수월했다. 개인적으로 안드로이드 팀원분에게 너무 감사하다 ... !!! 나중에 만나면 밥이라도 사드려야지 ㅎㅎ

---

배포 이후의 얘기를 마저 하자면 ...
배포는 성공적으로 되었고 에브리타임에 Suwiki를 홍보하였다. 지금까지 누적 회원 수는 250명 정도 된다. (앱 다운로드 수는 400정도 증가했다.)

이제 마케터를 모집해서 홍보를 더 할 생각이다. 마케터 모집 공고를 올렸는데 정말 감사하게도 5명이나 지원해주셨다. 마케팅 최소 목표는 1000명 이상...! 유저를 확보하는 것이고 충분히 가능하다고 생각한다.

수원대학교의 모든 학생들이 Suwiki를 사용하는 그날까지, 아니 그 이후에도 Suwiki는 계속 서비스될 것이다. 파이팅!!!

Suwiki 사용해보기

[WEB] https://suwiki.kr/

[Android] https://play.google.com/store/apps/details?id=com.kunize.uswtimetable

[iOS] https://apps.apple.com/kr/app/suwiki/id1615744899