
저는 이번에 청년톡톡 팀프로젝트의 안드로이드 개발자로 활동했던 이건희입니다.
한 달 반 정도 활동했고 개발자분들의 이탈로 인해 팀 프로젝트가 종료되었습니다
짧은 기간이었지만 팀프로젝트를 진행하면서 느낀 점을 회고해보려 합니다
팀 프로젝트에 참여하다
저는 대부분의 사이드 프로젝트를 혼자 작업했습니다
디자인, 기획, DB 등등...
혼자 작업을 하다 보니 편한 점도 있지만
항상 결과물에 대해 조금의 아쉬움이 있었습니다.
- 조금만 더 UI가 아름다웠으면 좋겠는데
- 다른 개발자라면 어떻게 작업했을까?
- 누군가와 같이했다면 더 빠르게 각자의 역할에 집중할 수 있지 않았을까?
점점 팀 프로젝트에 대한 갈망이 커져가던 중
같이 스터디를 하시는 분이 인프런 팀프로젝트 모집 게시판을 통해서
팀프로젝트를 모집했다는 말을 듣고 인프런 팀프로젝트 모집 게시판을 찾아봤습니다.
탐색하던 도중 제가 생각하기에 아이디어도 괜찮고
협업도 잘 될 것 같은 팀프로젝트를 찾아서 합류하게 되었습니다
팀 규모는 서버 2, 디자인 2, 안드로이드 1, iOS 1 이었습니다.

- 매주 회의
- 갖춰진 업무 프로세스
- 청년 정책을 모아서 제공하는 앱이라는 점에서 매력을 느꼈습니다.
협업 능력을 통해서 디자이너분들이나 다른 개발자분들과 성과도 만들어가고
청년톡톡을 더 좋은 앱으로 만들 수 있다는 기대감으로 시작했습니다.
테스트코드가 없어? 만들면 되잖아
팀에 합류했지만 팀원이 대거 변경되는 과도기인 만큼 시간이 붕 뜨게 되었습니다.
어떻게 하면 빠르고 효율적으로 코드를 파악할 수 있을까 고민하던 중
제품 코드와 테스트코드를 번갈아가며 확인해야겠다는 생각이 들어서
테스트 코드를 확인했지만 없었습니다.
길이 없으면 만들면 된다는 마인드로
기존 코드를 파악하고 리팩터링의 토대를 마련하기 위해
테스트코드를 작성하기 시작했습니다 API 통신 단위 테스트부터 작업하였고
작업 결과 서버 측에서 변경되어야 할 정보 3개를 서버 측에 수정을 요청하였고
기존 안드로이드 코드에서 잘못되었던 점 2가지를 확인하고 수정하였습니다.
테스트코드를 작업하면서도 회의와 여러 가지 논의들이 오갔고
코드를 읽는 비용에 버금가게 소통과 회의에 많은 에너지를 쓰게 되었습니다.
그렇기 때문에 문서를 남기고 이해하기 쉽게 전달하는 것의 중요성을 깨달았습니다.
계속되는 지연과 불길한 예감
API 통신 단위 테스트작업이 종료되고 새로운 분들이 팀에 적응할 때쯤
인수인계를 받고 코드 적응 중이시던
신규 iOS 개발자분이 참여가 어렵다는 연락을 받게 되었습니다.
급하게 새로 한 분을 모집하고 커피챗같은 면접을 진행했지만
합류하고 이틀 만에 또 참여가 어렵다는 연락이 왔습니다.
Android, iOS 모두 배포가 넉 달간 밀려있었고 API 개선
디자인 개선이라는 큰 고비를 넘기고 있었습니다.
이전 작업자께서 모두 작업을 해주셔서 검토 후에
안드로이드는 배포가 나갔지만 iOS는 배포가 나가지 못했습니다.
합류하기로 한 iOS 개발자분들도 이탈하고
기존 iOS 개발자분도 더 이상 프로젝트에 시간을 할애할 수 없었고
배포가 나가지 못해서 검토해야 하는 코드는 산처럼 쌓여갔기 때문에
과감하게 iOS는 포기하고 Android에만 집중해서 작업하기로 결정했습니다.
새로운 iOS 개발자분이 오더라도 기존의 코드를 살려서 가는 것보다
새로 구축하는 게 낫다고 생각되어서 계속 프로젝트가 진행되었다면
추후에 iOS는 다시 개발했을 것 같네요

프로젝트 붕괴
새로 합류하신 서버개발자분들마저 개인적인 사정으로 이탈되고
디자이너 두 분밖에 남지 않았습니다
알람, 프로필사진 변경 같은 작업사항이 있었지만
모두 서버의 추가 작업이 필요한 작업이고
더 이상의 구인은 의미가 없을 것 같아 현재 작업까지만 마무리하고 프로젝트를 정리하게 되었습니다.
UI수정사항, 사용자 신고기능만 작업하고 마지막 배포를 나가게 되었습니다
이 프로젝트를 적어도 1, 2년은 더할 거라 생각했지만 마지막 배포를 나갈 때 많이 아쉬웠습니다
팀프로젝트에서 이탈하는 이유
결과적으로 팀 프로젝트가 붕괴되고 이런 이야기를 주변 개발자들과 이야기하던 도중
의외로 개발자의 이탈이 많다는 이야기를 들었습니다.
왜 이탈률이 생각보다 높을까 생각해 봤습니다.
- 팀프로젝트는 수익을 만들어내지 않는다(못한다)
- 강제성이 부여되지 않는다
- 지금 하고 있는 일조차 벅차다
- 사내정치, 팀원 갈등
1번과 2번은 어떻게 할 수가 없기에
이탈률을 줄이기 위해 해소 가능한 것부터 생각해 보게 되었습니다.
다음에는 실패할 수 없기에
내가 과연 팀의 일원이 된다면 어떤 점부터 개선할 수 있을까 고민해 봤습니다.
- 프로젝트 관리 도구를 사용하자
프로젝트 관리 도구를 사용한다면
일감을 확실하게 나눌 수 있고 기존의 본업과 경계를 그을 수 있다고 생각합니다.
깃헙 오가니제이션으로 각 포지션의 레포를 분리해 놨지만
당장 어떤 작업들을 진행하는지는 한눈에 보기 힘들었습니다.
안드로이드는 github project를 사용했지만
이것 또한 디자이너분들에게 접근성은 좋지 않았습니다.
클라이언트는 동일한 내용을 배포를 나가야 하지만
당장 iOS에서 해당 작업의 어디까지 진행하고 있는지 파악이 어려웠습니다.
슬랙을 통해서 이슈 공유를 한다고 하지만
그마저도 직접 타이핑을 해야 하는 번거로움이 있었습니다.
Jira와 같은 프로젝트 관리 도구를 사용한다면
비개발자분들도 혹은 다른 포지션 간의 이슈 공유와 협업이 자연스러워지고
소통의 벽은 허물어지리라 생각됩니다. - 문서는 그때그때 만들자
간혹 작업을 하다 보면 문서를 남겨야 할 때가 오게 됩니다.
코드를 작업하다가 만들어진 히스토리, 회의 중 혹은 구두로 이야기를 하던 도중
그때그때 문서를 만들어서 관리하면 추후에 다른 작업자가 보기에도
혹은 미래의 내가 보기에도 소모되는 비용이 적습니다.
몇 줄 안 되는 분량이고 나 혹은 미래의 작업자가 본다면 커밋 메시지에
혹은 다른 개발자, 비개발자분들이 본다면 노션이나 각자 사용하는 문서에 맞게 정리합니다
당장 문서작업이 어렵다면 키워드라도 정리해 놓습니다 혹은 사진도 좋습니다 - 말은 쉽고 간결하게
같은 개발자더라도 포지션이 다르고 사용하는 프로그래밍 언어가 다르다면
개발적인 용어를 쓰더라도 이해가 어려울 수 있습니다
그렇기 때문에 최대한 쉽고 간결하게 정리해서 이야기하는 것이
커뮤니케이션 비용이 적게 들고 더 나은 결과를 도출하기가 쉽습니다.

그렇다면 나는 뭘 해야 할까?
제 자신을 돌아보며 아쉬웠던 점을 찾아보게 되었습니다.
- 업무를 더 잘게 쪼갰어야 했다.
지금도 업무를 최대한 잘게 쪼갠다고 생각했지만
생각보다 뭉텅이로 자르게 되었고 하나의 PR을 더 쪼갤 수 있었는데 하는 아쉬움이 있었습니다. - 프로젝트 관리 도구를 빠르게 도입해야 했다.
아까도 말씀드렸다시피 안드로이드는 github projects를 사용했지만
다른 포지션은 사용하지 않아서 업무 파악이나 공유가 어려운 상황이었습니다.
클라이언트에게 영향이 가는 서버 작업에는 PR 멘션을 부탁드렸지만
서버 개발 또한 중단되어서 받아본 적이 없습니다.
프로젝트 관리 도구를 사용했다면 적어도 디자이너분들과의 협업은 존재했었을 것입니다.
앞으로는 뭘 하지?
같이하던 디자이너분과 새로운 프로젝트를 기획하려고 합니다.
나의 발전이나 내가 키우는 동식물에 대한 기록일기 앱을 만드려 합니다.
당장 지라 프로젝트부터 개설했고 지라를 기준으로 프로젝트를 관리하려 합니다
소통과 피드백을 바탕으로 새로운 프로젝트를 성공적으로 마무리하고 싶습니다.