유니페스는 어떻게 협업했을까?(2)

우리팀이 성공적인 런칭을 마치고, 현재는 휴식기 및 앞으로 어떤것을 더 진행해볼지 고려하고 있는 상황이다. 우리가 어떻게 협업을 했는지 작성하기 딱 좋은 시기인거같아 정리 겸 기록해보려한다.

팀 구성

팀구성을 마치고보니 PM 1명, ios 1명, 안드로이드 2명, 웹 프론트 1명, 백엔드 4명, 디자이너 1명으로, 총 10명의 팀원이 모집되었다.

모이고 보니, 생각보다 개발을 더 잘하는사람들이 모이게 되었다. 다들 개발에 어느정도 자신이 있고 고학년들에 열정까지 있으니 초기단계가 일사천리로 진행되었다. 이게 정말 다행이였던것이, 프로젝트는 다행히 처음 목표했던바와 같이 진행되었만, 의외로 시간이 많이 촉박했었다. 지금 생각해보니 이정도의 실력있는 팀원들이 아니였으면 살짝 위험했을수도 있겠다 싶다. 3월 중순에 개발이 시작되었는데, 5월 중순이 대학축제 기간이니... 까딱 잘못하다간 반년을 미루게될뻔했다..

Jira, Sprint 그리고 KPT 회고

내 과거 인턴경험을 살려, Jira와 애자일 방법론에 따른 개발을 팀원에게 소개시켜주고 대화를 나눈적이 있다. 프로젝트 초반의 경우 모두 환영하고 도입하고자 했지만, 결과적으로는 절반정도만 도입하게되었다.

당시 도입하고자 했을때는 고려하지 못한부분이 있었다. 바로 우리의 시간이 매우 촉박한데 더불어, Jira를 통해 관리하는것이 그런 우리의 시간을 유연하게 만들어주지 못하고 오히려 시간만 잡아 먹을수도 있다는 점이다.

 

개발을 할때도 사실 첫 환경구축에 가장 많은 시간이 들어가곤한다. 어떤 디자인패턴을 쓸거야? 어떤 아키텍쳐를, 어떤 라이브러리를, 어떤 구조로 작성해서 재사용성이 좋게 만들거야? 어떻게 분리를 잘 해둬서 나중에 관심사 분리가 잘되게 할거야? 등등.. 사실 이런 프로젝트 관리도 크게 다르지 않다고 느꼈다.

인턴당시 나는 크게 3가지 일을 하였다. 시니어 개발자분과 함께 앱 개발, 외국계 개발자분과의 소통에서 번역, 그리고 Jira를 관리하였다.

 

자연히 Jira로 프로젝트 관리하는데에는 자신이 있었다. 그래서 이걸 바탕으로 PM과 논의하고, PM도 지라사용법을 좀 공부하고 빠삭해진 PM이 프로젝트를 관리하며 전체적으로 틀을 짜고 이슈를 작성하고, 개발자들과 함께 보며 시간을 관리하고.. 이런식으로 진행을 하고자 했다. 하지만 촉박한 일정과 함께, 근본적으로 과연 이것이 필요할까? 라는 의문이 들게되었다. 

 

이렇게 생각하게된 주된 계기는, 우리의 역할이 비교적 명확하다는 점이였다. 페이지는 5~6페이지정도 되고, 그 안에서 우리가 해야할점도 명확히 보였다. PM님의 훌륭한 기획과 개발에 익숙한 팀원들덕에, 개발에 들어가기전 우리가 고려해야할것들에 대해 이미 인지가 들어간 상태고, 추가적으로 변경될만한 내용이 없었다. 실제로 개발을 진행하며 크게 바꾸게된것은 없다싶이 했다. 시간의 배분도 자연스럽게 어느정도 이루어질수 있었다. 물론 그속에도 고려할 상황도 많았지만, 계획을 위한 계획, 계획의 오버 엔지니어링이 되어 시간을 뺐기는것은 금물이였다.

 

물론 우리같은 경우는 특수한경우라고 생각한다. 규모가 크지 않았고, 잘 짜여진 기막힌 기획이 있었고, 시간이 얼마나 소요될지 판단할수 있는 노련한 개발자도 한분 있었다. 일반적인 경우 오랜 개발에 걸쳐 흐지부지 되는경우가 많았지만, 우리팀은 이런 점을 고려해, Jira를 사용하지 않게되었다. 사실 개발에 그 무엇보다 중요한것은, 서비스 그 자체를 기간내에 완성하는것이니까. Jira를 사용하는것이 내 이번 회고에 더 다양한 리소스를 제공해주며, 협업에 대해 무언가 더 할말을 작성하기 좋았을것이다. 그럼에도 Jira를 사용하지 않은것은, 내가 가장 중요하게 여기는 덕목인, Done is better than Perfect에 위배된다고 생각하기에 해당 부분은 빼자고 제안했다. 

 

개발자는 기간내에 서비스를, 내부 기준에 맞춰 만들어낼수있는것이 가장 중요하다고 생각한다. 그렇기에 무슨 툴을, 무슨 라이브러리를 사용하건, 그것이 약이될지 독이될지 비판적으로 접근하는것이 매우 중요하다고 생각한다.

 

그렇다면 Jira를 통한 애자일 방법론을 도입하지 못했는데 왜 절반쯤의 성공이라고 했을까? 그것은 바로 일정부분 내가 원했던 방식의 방법론이 도입되었기 때문이다. 여기서부터는 우리팀이 협업을 한 과정이다. 보통 Jira를 통해 애자일 방법론으로 개발했다면, 스프린트를 시작하기 전 우리가 구현할 스토리들을 미리 최대한 작성해둘것이다. 그리고 이번 스프린트에서 어떤것을 진행할지 결정하고 백로그에 넣어둔 뒤 스프린트를 진행하고, 스프린트를 마무리하며 회고를 하는 방향으로 진행했을것이다.

 

우리팀은 스프린트 기간을 1주일로 정해, 그 주의 회고와 앞으로 할 일에 대해 논의하였다. 예를들어, 내가 홈화면을, 다른 안드로이드 개발자가 맵 화면을 구현한다고 할시, 이번주까지 여기서부터 여기까지의 구현을 하리라 정하고, 다른 개발자들과 논의해 그 범위가 적절할지, 우려되는 사항이나 함께 말할부분이 없는지 함께 논의한다. 이런 논의를 거쳐 정리해, 이번 스프린트 기간의 구현 내용이 결정되고, 마찬가지로 회고를 통해 구현이 적절했는지에 대해 함께 논의한다. 이를통해 우리는 애자일 방법론으로 개발을 진행할수있었고, 확실한 업무 효율을 불러올수 있었다.

 

회고의 경우, 어떤회고방식을 사용할지 고민했었다. 그러던중 이전 팀프로젝트 팀원의 기술블로그를 참고하여, KPT 회고방식을 도입하였다. KPT회고방식을 Keep,Problem,Try의 약자로, 무엇을 계속할지, 무슨문제가 있었는지, 어떤것을 더 해볼지에 관해 논의하는 회고방식이였다. 먼저 전반적인 스프린트의 평가를 매우 심플하면서도 효과적인 이 회고 방식을 통해 우리팀은 각 파트별 진행사항에 대해 더욱 깊이 이해하고 각자의 개발을 진행할수 있었다.

 

Github

깃허브는 정말 이번기회에 새롭게 보게된거같다. 깃허브를 사용한지 오래되었음에도, 이번기회에 어마어마하게 많은걸 배울기회가 있었다.

 

https://github.com/Project-Unifest/unifest-android

GitHub - Project-Unifest/unifest-android: 대학 축제의 지도를 펼치다. Uni-Fest

 

이번 프로젝트에 깃허브와 관련해 고려한 것들은 다음과 같다.

1. 깃 브랜치 전략 수립

2. CI/CD

3. Renovate bot으로 의존성 관리

4. PR리뷰

 

하나하나 살펴보자

깃 브랜치 전략 수립

브랜치 전략에 관해
https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

이 글을 읽어보면 좋을것같다. 우리팀 또한 git-flow를 이용하여 개발을 진행했다.

다만 main이 release의 역할을 하고, develop와 supporting 브랜치까지만 존재하고 release나 hotfix는 만들지 않았다. 대신 supporting 브랜치로 fix/[#이슈넘버]를 만드는 식으로 작성해주었다. 프로젝트의 특성, 팀의 경험, 작업의 효율성을 고려해서 간략화 하여 사용한것이다. Git-flow의 전체 복잡한 구조를 사용하는 것보다 단순화된 브랜치 전략이 규모에 더 적합할수 있다. 관리할 브랜치의 수를 줄여주어 복잡성을 낮출수 있고, 또 우리팀이 짧은 개발 주기와 축제기간이 다가오며 계속해서 버그를 수정하며 빠른 배포 주기를 가졌기에, 불필요한 브랜치를 줄이고 주요 브랜치에 집중하였다.

CI/CD 환경 구축

https://velog.io/@mraz3068/Apply-Android-Github-Action-CD

[Android] Github Action 를 이용하여 CD 를 적용 하는 방법

 

(위 게시글은 같은 팀원분의 CD 관련 블로그 포스팅이다)

배포에 들어가기 전까지는, 우리팀은 code style check, run build success를 CI를 이용해 체크해주었다. 이후 배포일이 다가오자, release 버전의 apk파일을 계속해서 만들어주는것이 꽤나 시간을 잡아먹곤 했다. 이런점들을 해결해주기 위해 배포환경 또한 구축하여 별도의 처리 없이도 릴리즈버전을 쉽게 확인해볼수 있게 되었다. 

 

CI의 경우, 유니페스 이후 다른 프로젝트를 진행하면서 직접 환경을 재구축해보면서 한번 더 배울수 있었다:

CI의 경우 구축은 어렵지 않을수 있지만, 많은부분을 gitignore에 포함시켜 작성하였을시에는 해당부분에 대한 처리를 따로 해주어야한다. 예를들어, CI로 코드스타일 체크와 빌드가 잘 되는지를 체크하도록했는데, secrets.properties나 google service.json등을 생성하는 부분이 없을 경우에는 오류가 당연히 발생한다. 

이런 경험을 배워가며, 효율적인 배포환경에 대해 한번 더 생각하게되었다.

 

Renovate bot으로 의존성 관리

https://jhyeok.com/renovate-bot/

https://jhyeok.com/renovate-bot/

레노베이트 봇으로 의존성 관리를 할경우, 프로젝트의 의존성을 업데이트 해줘서 좋았다. 다만, 웹훅으로 깃허브와 디스코드를 연결해 알림봇을 만들었는데, 업데이트가 자꾸 들어와 조금 거슬렸다... 만 그래도 유용했다 ㅎㅎ

PR 리뷰

클린아키텍쳐 대신 구글 권장 아키텍쳐, MVVM 대신 MVI, XML 대신 컴포즈 등등... 새롭게 도입한 여러 부분들에서 헤매지 않을수 있었던건 PR리뷰의 덕이 컸다. 특히 리컴포지션과 관련되어 성능상 여러가지 처리를 해줄부분이 많은데, 이런부분에 대해서 빠르게 적응할수 있었다. 나 또한 PR을 생성하면서, 동료가 보기쉽게 적절히 끊는법에 대해 고민하게 되었다. 특히 한번은 어쩌다보니 Room 과 관련해서 내부저장관련 기능 작성과 리팩토링을 함께 하느라 한 PR에 1000줄가량을 한번에 올린적이 있었는데, PR을 올리면서도 죄송했다. 이런부분을 고려하며 다음 PR부터는 조심하고, 어떻게 짜야하는지 한번더 생각하며 역지사지의 마음으로 PR을 올리고자 했다. 또한 나보다 잘하는 개발자분의 코드를 요목조목, 기능별로 보면서 개안하는 부분도 있었다. 여러모로 어마어마하게 만족스러운 경험, 감사한 경험이였다.

후기

성장을 위해서, 기획부터 운영까지 협업으로 진행해보라는 말의 의미를 진정으로 깨달을수 있었다. 또한 새로운 기술스택과 생소한 개념을 많이 사용하면서 개발을 진행했는데, 이번에 정말 좋은 팀원분들과 함께해서 잘 마무리 지을수 있었던거 같아 너무 행복했다. 특히 함께 개발하신 안드로이드 개발자님께 많이 배웠고, 또 많이 자극받았던것같다. 협업에 있어 서로 하나의 목표를 향해 가다가도, 정말 예상치 못한곳에서 문제가 생기기도 했다. 그렇지만 결국 하나의 팀으로 이 서비스를 만들기 위해 모두가 노력하고있다는 신뢰를 바탕으로 대화해보니, 그런문제는 쉽게 해결되곤 했다. 정말 당황하고... 황당한 상황도 있었다.. 하지만 지나고나니 다 추억이다 ㅎㅎ

 

뭐 당연히 배포후에도 갑작스럽게 작동하지 않는다던지 하는 문제로 순간 멘붕도 오고 했는데, 결국 성공적으로 런칭하고  홍보하지도 않았는데 깃허브에 많은분들이 관심가져주시고 star로 주시고, 마무리까지 잘 지어 학교신문과 우리팀이 인터뷰도 하는등 여러가지로 뿌듯한 경험을 했다. 이 다만 마지막으로 아쉬운점은, 프로덕트를 조금만 일찍 만들었으면 어땠을까 하는점이다. 홍보에 조금더 많은 시간을 투자했으면 좋을텐데, 막상 개발이 완료되니 홍보기간이 조금 부족했던거같아 아쉽다. 좀 더 타이트하게 배포를 시작해 유저유치를 했으면 좋을텐데 아쉽지만, 우리의 프로젝트는 계속될거다.당장 하반기 축제전 웨이팅기능을 추가하기로 하여 개발에 들어갔으니. 앞으로도 유니페스 팀을 지켜봐주시라!