YAPP 26기 안드로이드 파트 개발자 활동 후기: 탈퇴와 미수료 그 사이 어딘가

부제: 당신의 사이드 프로젝트가 실패하는 이유

*해당 포스트는 개발 동아리에 참여한 개인적인 후기를 담은 글이며 모두의 경험과 다를 수 있습니다


1. 동아리 지원 과정 및 활동 정보
2. 프로젝트 진행 과정
3. 탈퇴를 결심하다

26기 회원증(?)이었던 것

1. 동아리 지원 과정 및 활동 정보

회사에서 사용하는 기술 말고 새로운 기술과 아키텍처를 적용해보고 싶어서 동아리에 지원했다.
yapp은 PM 이라는 직군이 별도로 존재하는 동아리라고 알고 있다. (다른 곳은 대부분 개발자나 디자이너가 PM을 같이 함)
PM 직군이 별도로 존재하면 프로젝트가 더 체계적으로 진행되고 출시 확률이 더 높아지지 않을까? 나 이번에 꼭 출시하고 운영까지 하고 싶어 진짜 진짜로.
출시를 목표로 하는 나 + PM이 있으니 일정이나 팀 관리를 더 전문적으로 할 것이라는 기대 = 지원

yapp은 여러 개발동아리와 마찬가지로 자소서+면접 두 단계로 이루어진 리쿠르팅 과정을 가지고 있다.

<자소서>

자소서 질문은 다른 동아리와 비슷하다.
- 지원 동기
- 다른 프로젝트를 하며 어려웠던 점
- 어떤 기술을 사용했고 왜 사용했는지
- 포트폴리오 (선택), github, 기술 블로그 (선택)
크게 까다로운 질문들은 아니었고 개발 동아리에 지원한 사람이라면 당연히 고민해본적 있는 질문들이었다.

<기술 면접>

면접은 지원자의 일정에 맞는 날을 골라서 설문조사를 제출하는 형식이었다.
근데 선착순으로 사람들이 선택하다보니 마지막에 내가 가능한 일정이 남아있지 않아서 결국 나는 다른 날에 추가로 면접을 1:N으로 진행했다.

질문 수준은 평이한 정도였던거같다.
- 안드로이드 라이프사이클
- 코루틴과 thread pool
- compose 생명주기
- MVI 아키텍처

<컬쳐핏 면접>

컬쳐핏 면접 즉 인성 면접의 경우 팀프로젝트 활동 경험을 많이 물어보는 것 같다.
이 사람이 팀원으로서 함께 하고 싶은 사람인지 아닌지 여쭤보는 듯
- 어떤 팀원이 함께 했으면 좋겠는지
- 동료와 프로젝트를 할 때 어려운 점
- 본인은 리더형인지 팔로워형인지
- 동료가 선택한 아키텍처와 본인이 선택한 아키텍처가 충돌하는 경우 어떻게 조율할 것인지

직장인의 경우
- 일이 바쁠텐데 프로젝트까지 감당 가능할지
- 취업 준비생이나 대학생과 같은 팀을 했을 때 어떻게 리드를 할지
- 본인보다 못하는 동료와 매칭이 되면 어떻게 할지

당연히 떨어졌다고 생각했는데 추가합격을 해서 "내가 왜 붙은...?" 라고 생각했다.

<활동 정보>

수료 조건: 출석 점수 70점 + android/ios 둘 중 하나의 플랫폼 서비스에서 런칭 (지각 -10, 결석 -20)
활동 기간: 약 4개월
세션: 매주 토요일 13:00~17:00 (중간고사 기간 1번 쉼)

수료 조건이 생각보다 까다롭다.
출석 점수 차감 기준이 높아서 2번 이상 결석을 못하고 하나의 플랫폼에서 반드시 서비스 런칭을 해야한다.
듣기로 yapp이 수료 인원이 많이 없다고 들었는데 높은 수료 조건도 한 몫 하는듯
다행히 우리 팀은 수료를 할 수 있었다. (물론 난 탈퇴하긴 함)

yapp의 경우 팀원부터 매칭되고 프로젝트를 진행한다.
PM: 저는 A 프로젝트 PM인데요 우리 이런걸 할거에요
개발자: 나 A 프로젝트에 가고 싶음 나는 이런걸 저런걸 잘함
PM: 너 내 동료가 돼라
다른 동아리는 이런식으로 대부분 프로젝트 아이디어가 먼저 있고 이에 관심있는 개발자가 지원 후 매칭되는데 여기는 팀원부터 매칭되고 프로젝트 기획을 시작한다.
아마 4개월 동안 프로젝트를 하기 때문에 팀원 간의 성향을 맞추고 소통이 잘 되도록 하기 위함인 것 같다.
결론부터 말하면 이 방식은 최악이었다. (이후에 자세하게..)

신기한 점은 개발파트 팀원 매칭을 직접 해준다는 것이다.
같이 안드로이드를 개발할 동료가 정해진 상태로 활동에 참여하게 된다.
근데 이런 시스템은 장단점이 존재하는 듯

나머지는 크게 특이사항 없다.
다른 개발 동아리와 비슷하게 흘러간다.
기획 세션 -> UT -> 개발 세션 / 해커톤 -> 최종 성과 보고회

2. 프로젝트 진행 과정 (2025/5/10~2025/8/30)

우리 팀은 다음과 같은 tool을 사용했다.
- github: 프로젝트 코드 형상 관리
- jira: 개발 이슈 및 스프린트 관리
- figma: 디자인
- notion: 문서 및 정책 관리
- discord: 파트 간 소통 및 협업

프로젝트 초반에 안드로이드 파트는 github issue로 태스크를 관리했다.
그런데 서버, iOS 파트와의 작업 진행 상황 공유가 전혀 안되고 있었고 개발 속도가 나지 않아서 초반에는 프로젝트가 거의 진행이 되지 않았다.
우리 프로젝트의 규모나 작업량이 적은 편이 아니었기 때문에 이렇게 하다간 출시를 못하겠다고 판단했다.

그래서 우리 팀의 개발 이슈를 공유할 수 있도록 jira를 생성하고 스프린트를 도입했다.
기능 별로 스프린트를 1~2주 정도 정해서 해당 스프린트에 iOS/Android/Server 별로 작업 티켓을 나누고 담당자에게 이를 할당했다.
그리고 돌아가면서 해당 기능의 완성을 책임질 스프린트 마스터를 정했다.
사실 스프린트 마스터도 그냥 전부 내가 할까 생각하다가 책임을 나누지 않으면 누군가는 참여도가 너무 낮을 것 같아 한명씩은 스프린트 마스터를 할 수 있도록 정했다.
사이드 프로젝트를 여러번 경험하며 느낀 결과 참여도가 적은 팀원에게 역할을 부여 할수록 기여도를 끌어올릴 수 있었기 때문이다.
이 방식은 상당히 효과적이었다고 생각한다.

사실 회사에서만큼 스프린트를 체계적으로 관리하지는 못했다.
사이드 프로젝트인만큼 자유도가 있어야 한다고 생각했고 다른 팀원들이 개발 리더가 되었을 때 어떻게 해당 역할을 수행할지 보고 싶기도 했다.
그런데 이 방식은 좀 별로였는듯
그냥 다들 마감일 전에 일정만 관리하는 방식으로 역할을 수행했다.
아무래도 경험치가 부족하거나 개발 일정이 촉박했기 때문이라고 생각된다.
사실 스프린트 마스터는 기능 정책 담당 및 디자인 협의, 기능 명세서 작성 등등 할일이 꽤나 많은데 이런 부분이 제대로 수행되지 못한건 아쉽다.

안드로이드 프로젝트에서는 새로운 기술을 사용하지는 않았다.
기존 목표이던 워치 개발, 크루 기능이 MVP 2로 넘어가게 되었고 같은 파트원의 러닝 커브를 고려해서
MVI(orbit) + Multi Module + Clean Architecture를 사용했다.
사실 이건 굉장히 typical한 기술이기도 하고 익숙해서 아키텍처 관련해서 새롭게 배운 점은 적었던게 아쉽다.
그래도 지도 sdk를 사용하면서 naver map compose를 사용해본 게 그나마 제일 새로웠다.

개발 세션 준비하면서 만든 아키텍처 장표

원래 목표인 baseline profile 적용을 못한 점도 아쉽다.
성능 개선과 cuj 시나리오 발굴에도 관심이 있는데 일정 문제로 적용을 못했다.
(안드로이드 2주 내부 테스트는 진짜 적폐 그 자체다.)

3. 탈퇴를 결심한 계기

결론부터 말하자면 안드로이드는 출시를 하지 못했다.
심지어 개발도 마무리하고 2주 테스트도 끝나서 프로덕션 신청만 하면 되는 상황이지만 더 이상 진행하지 않을 것이다. (완성도가 떨어지고 이슈 너무 많음)
프로젝트를 진행하면서 중간부터는 개발이 마무리되면 수료 여부와 상관없이 동아리를 탈퇴하겠다고 결심했기 때문이다.
실제로도 개발 완료 후 2주 테스트 시작과 동시에 yapp 활동을 더 이상 하지 않았다.

1) yapp 세션 실효성에 관한 의문

yapp 세션 구성이 과연 사이드 프로젝트를 진행하는 데 효율적인가?

일단 UT가 2번이나 잡혀있다. 게다가 2차 UT 2주 뒤는 데모데이다.
즉 개발이 완료되는 시점은 그보다 1주일 전이니
사실상 2차 UT를 통해 인사이트를 얻었다 해도 유의미한 결과물로 이어지기는 어려운 일정이다.
사이드 프로젝트에서 UT를 2번이나 할 이유는 없다고 생각한다.
차라리 개발 세션이나 팀 세션이 더 있어야 할듯
UT는 어디까지나 usability test 이므로 사용성 테스트는 디자인 세션 이후에 목업으로 한번만 진행해도 충분하다고 생각한다
그리고 갑자기 2차 UT 도중 F-lab 멘토와의 멘토링 시간이 있다
이건 진짜 신청한 사람들만 진행하는게 맞다고 본다
필요없는 발표 자료 만들기를 너무 많이하게 되고 이런 외부 업체와의 멘토링이 세션에 굳이 필수로 넣어야하는 활동이라고 느껴지지 않음
근데 뭐 아마 어떠한 이유가 있을거라고 생각됨 후원사이기도 하고

개발 세션도 초반~중반에 진행해서 사실상 어느정도 아키텍처나 기술 스택이 확정된 이후에 진행한다.
즉 OB 들의 피드백을 받아도 그걸 적용해서 아키텍처를 갈아엎을 수가 없다.
개발 세션이 단순한 기술 스택 자랑 시간도 아니고 동아리 원들 모아놓고 발표를 시킬거면
세션을 일찍 잡고 기술 스택에 대한 피드백을 확실하게 줘서 개발에 도움을 줄건지,
다른 팀에게 프로젝트 소개만 하고 말건지 (그럼 장표 만들게 하지 말아야 함)
노선은 확실하게 하고 운영을 해야한다.

yapp에서의 해커톤은 다른 동아리처럼 밤을 새서 진행하는 개발 세션이 아니라
11:00~20:00 약 9시간 정도만 진행하게 된다

해커톤 로드맵 발표

그마저도 중간에 모두가 참여해야하는 이벤트가 있고 장소 내부 취식이 어려워서 밖에서 밥을 먹다보니 실제로 개발할 시간은 부족했다
그리고 해커톤 종료 전 1시간 동안은 오늘 해커톤 동안 뭘 했고 얼마나 했는지 각 팀마다 장표를 만들어서 발표를 해야한다
누군가에게는 좋을 수도 있지만 솔직히 해커톤 세션을 이렇게 운영하는 건 비효율적이라는 감상을 지울 수가 없다

결국 yapp 정기 세션은 실효성에 의문을 갖게 하는 세션 구성, 여러 발표들, 장표 만들기
그리고 일정하지 않고 상당히 특이한 대관 장소(불광동)가 있었다는 감상만 남음

2) 서비스 기획 자체에 대한 의문

우리는 러닝 서비스를 만들었다. 러닝 초보에게 음성 피드백을 제공하는 기능을 킬러 기능으로 생각했다.
그러나 yapp 활동이 종료된 이 시점까지도 "왜 굳이 우리 앱을 사용해야 하는가?" 에 대한 질문은 해소되지 않았다고 생각한다.
러닝 서비스? 이미 시장에 너무 많다
초보를 위한 음성 피드백? 런데이라는 앱이 잘 되어 있고 심지어 삼성에서 개발한 갤럭시 워치 8에는 러닝 코치라는 앱이 기본으로 탑재되어 있다
즉 우리 서비스 기획의 경쟁력이 부족했다.
이는 서비스를 출시하고자 하는 동기부여를 생산하기 어려웠고, 팀원 간의 서비스 이해도가 각자 다른 큰 문제를 발생시켰다.

yapp은 4개월동안 세션을 진행하지만 사실 yapp 동아리 단위의 세션은 10번이 채 되지 않고 나머지는 팀 세션이다
즉 알아서 오프라인/온라인 중 장소를 정해서 진행하면 된다
그런데 우리 팀에게 이 방식은 오히려 팀 세션이 잘 진행되지 않은 이유가 됐다
모여서 회의를 진행하는 것 vs 온라인으로 진행하는 것
-> 당연히 우리는 단기간에 필요한 결정사항과 협의사항이 전자가 유리하다
그럼에도 불구하고 대부분 온라인으로 진행했기에 초반 회의에서 유의미한 기획 결과물을 제대로 추출하지 못했다
즉 초반 세션에서 우리 서비스의 방향성을 제대로 잡지 못했고 모두가 생각하는 서비스가 달라지게 되었다.
이것이 우리의 프로젝트가 실패한 첫번째 원인이다..

3) 결국 문제는 내부에: 팀원 간 내부 문제

결국 모든 문제는 팀 내부에 있다.
모르는 건 잘못된 것이 아니다. 당연히 배우려고 이런 동아리 들어오는 것이고 필자도 부족한 점이 많다.
그럼에도 불구하고 뭔가를 알려줬을 때, 잘못된 점을 지적했을 때 다음에도 똑같은 것을 반복하는 건 잘못이다..
프로젝트를 진행하기 위해서 나도 그만큼 결과물을 만들어야 한다는 생각으로 개발 동아리에 들어와야지 누군가가 이것들을 하나하나 다 알려주길 바라는건 당연하지 않다.

개발을 할때는 항상 내가 뭘 지금 하고 있는지, 왜 이걸 해야하는지 알아야 한다.
lint를 맞추기 위해서 아무렇게나 코드를 작성한다거나, 눈 앞에 보이는 디자인만 보고 대충 UI를 짜는 등의 일을 하는 것은 다같이 협업을 할때는 부족한 태도다.
아무도 당신들에게 개발 동아리를 하라고 강요하지 않았음..
스스로 이런 일들을 하려고 들어왔으면 기본적인 태도는 갖추고 있어야한다.

그리고 팀을 이루어서 협업을 한다는 것은 내가 하기 싫어도 해야한다는 뜻도 있다.
yapp은 프로젝트를 보고 팀을 이루는게 아니라, 팀을 먼저 구성하고 프로젝트를 기획한다.
이 과정에서 당연히 내 마음에 들지 않는 아이디어가 채택되고 서비스를 만들게 될 수도 있다.
그래도 어쩌겠어 해야지
아까도 말했지만 아무도 당신들에게 이 동아리를 하라고 강요하지 않았음...

이슈 관리를 위해서 jira를 쓰자고 했으면 티켓을 잘 관리하고 이력을 남겨야하고
누군가 discord에서 멘션을 해서 뭔가를 물어보면 대답을 해야해. 이런 기본적인거 말하게 하지 말라고.
내가 하기 싫어도 해야해 왜? 협업이라는게 그런거임
너를 위해 우리 팀이 서비스를 만드는게 아니라고. 팀의 목표를 위해 당신이 해야하는거라고.
라고 급발진 하면 안되겠지

모르겠다..
이쯤되면 정말 모르겠다.
그래도 나름 많은 프로젝트를 해왔고, 심지어 PM으로서 런칭도 했었는데도 팀 내부 문제는 여전히 어렵다.
결국 내가 개발 파트 리더 아닌 리더가 된 상황에서 제대로 다른 사람들을 이끌지 못했던 것 같아 아쉽다.
yapp을 나오게 된 근본적인 이유는 이런 부분에서 회의감이 많이 들었기 때문이다.
이렇게 유명한 동아리조차 어떠한 사람들은 열심히 하지 않았다.
대단히 특별한 것을 바란것도 아니고 이렇게 기본적인 태도에 문제가 있는 사람들과 함께 해야한다는 점은
이 동아리를 다음에도 참여할 것인가 라는 물음에 부정적인 대답을 내리게 했다.
아 이 동아리는 이런 태도를 가진 사람들이 많구나. 그럼 앞으로도 계속 하기는 어렵지.
이것이 우리 프로젝트가 실패한 두번째 원인이다.

4. 회고

동아리 탈퇴 의사를 운영진께 밝히고 원온원 미팅을 통해 그냥 미수료로 남기로 했다. (무슨 차이인지는 모르겠음)
그래도 하나 배운게 있다.
사이드 프로젝트가 실패할 수 있는 케이스를 하나 더 배웠다.

초반 기획의 방향성이 제대로 잡히지 않아 프로젝트가 헤맸던 경험은 넥스터즈 출석체크 앱을 만들며 배웠다.
그런데 왜 또 나는 같은 실수를 반복했을까? PM이라는 기획 직군이 따로 있어서 너무 안일하게 있었던 것일까?
팀 내부에 문제가 생겼을 때 어떻게 대처하면 좋을지는 여전히 모르겠다.
사실 이전에 PM으로서 이런 일이 있었을 때 어떠한 아이디어를 통해서 위기를 극복했으나 지금은 그러지 못했고 내가 포기해버렸다.

결국 사이드 프로젝트가 실패하는 이유는
명쾌하고 확실한 기획이 부족하기 때문에,
팀원 간 소통이 제대로 되지 않기 때문에,
그리고 조직이 적을수록 한 사람의 영향력이 크게 발휘되기 때문이다. 그게 좋은 쪽이든 안좋은 쪽이든지 간에.

이 경험을 바탕으로 시야를 넓게 보는 연습을 해야겠다.
어떤 태도를 가지고 협업을 해야할지도 다시 고민을 하면서..