개요
올해 4월부터 진행했던 IT 연합 동아리 YAPP 20기의 활동이 8월 부로 마무리되었습니다. 올해는 수많은 교내 활동, 대외 활동, 인턴십 등으로 굉장히 알찬(?) 한 해를 보내고 있습니다만, 그 시작을 열어준 YAPP 20기의 활동 후기를 적어보겠습니다.
IT 연합 동아리? 왜?
IT 연합 동아리에 지원하게 된 이유는, SW 마에스트로 활동 이후 대학 내의 조별 과제가 아닌 대학 밖의 사람들과 열정 넘치는 프로젝트를 진행하는 것에 굉장히 큰 즐거움을 느꼈기 때문입니다. 또한 취업을 위한 메인 기술 스택을 Android
로 드디어 정한 시기이고, SW 마에스트로 또한 Flutter
를 사용했기 때문에 당장 Android
실력을 늘리는 데에 집중하고 있었습니다. 마음 같아선 SW 마에스트로에 재지원하여 한 번 더 하고 싶었으나 그럴 수 없으므로 열정 넘치는 프로젝트를 할 수 있는 다른 방법을 찾아보던 도중 IT 연합 동아리라는 것을 발견하였습니다.
YAPP을 선택한 이유
IT 연합 동아리를 찾아본 결과 굉장히 많은 수의 동아리들이 존재했습니다. 이 중에서 하나를 골라 지원할 생각이었는데, 인지도가 높은 동아리를 들어가는 것이 동아리의 분위기나 팀원들의 실력이 좋을 것이라고 생각해 인지도를 기준으로 다음과 같은 동아리들을 추려냈습니다.
- SOPT
- YAPP
- Mash-Up
- Nexters
먼저 첫번째로 SOPT의 경우, 따로 IT 연합 동아리를 찾아보기 전에도 몇 번 들어봤을 정도로 인지도가 훌륭했습니다. 다만, SOPT는 창업 동아리로써 소개되는 느낌이 강했습니다. 이미 프로젝트의 기획과 비즈니스 모델에 대한 구상은 SW 마에스트로에서 충분히 경험했고, 지금은 당장 기술력 향상에만 집중하고 싶어 제외했습니다. 그 외의 3곳은 사실 어딜 들어가도 상관없겠다고 생각했습니다. 다만, YAPP의 경우 타 동아리들과 다르게 개발자, 다자이너 뿐만 아닌 PM 직군 또한 모집하는 것이 눈에 띄었습니다. 이번 활동은 최대한 기획적인 부분에서 손을 떼고 요구 사항대로 성공적으로 개발하는 것에 집중하고 싶었기 때문에 이러한 점이 눈이 갔습니다. 또한 YAPP의 모집 기간이 그 당시 가장 빨랐기에, 별 고민없이 YAPP을 지원하게 되었습니다. 사실 YAPP 서류 심사 기간에 Mash-Up 모집을 하길래 혹시 떨어질까봐 Mash-Up도 서류를 넣어놨습니다ㅎ
첫 안드로이드 면접
그동안 진행했던 프로젝트를 잘 정리해놓아서인지 다행히 서류는 합격할 수 있었습니다. 문제는 면접이었습니다. 그 당시 면접 경험은 SW 마에스트로 면접이 전부였습니다만, 그때의 면접은 대놓고 기술 면접의 느낌은 아니었기에 사실상 기술 면접은 이번이 처음이었습니다. 심지어 안드로이드를 잡은지 얼마 안됐을 때라 걱정을 많이 하며 Android Developer 사이트에서 개념 공부를 계속 했었습니다.
면접은 온라인으로 진행되었고, 다대일 면접으로 무려 3명의 면접관이 있었습니다. 놀라운 것은 그 분 중 한 명이 동아리 회장님이었다는 것이었습니다. 마침 동아리 회장님이 안드로이드 현업자 분이시라니! 더욱 더 붙고 싶은 마음이 커져갔으나 역시 회장님이라 그런지 질문도 굉장히 열심히 해주셔서 눈물이 날 뻔 했습니다…
면접에 들어갈 때 포트폴리오에서 눈에 띌만한 안드로이드 프로젝트는 MVVM
아키텍쳐에 Compose
를 활용한 프로젝트였는데, 비교적 최신 기술인 Compose가 눈에 띄었는지 Compose 질문을 많이 해주셨습니다. 알고보니 동아리 회장님이 Compose를 굉장히 좋아하시는 분이셨습니다…
면접 때 받은 질문들은 다음과 같습니다.
- 자기소개
- 자신의 장단점 소개
- MVVM 아키텍쳐에 대한 설명
- 액티비티 생명주기에 대한 설명
- LiveData 와 Flow 의 차이점 설명
- 평소 Test Code 작성 방법과 아키텍쳐와의 연관성
- Compose 에서 remember 키워드를 사용하는 이유
- Compose 에서 Navigation 을 통해 Fragment 들을 전환하는 방법
- Compose 가 아닐 때 전환하는 방법
- LanchedEffect 와 context.coroutineScope (컴포넌트가 리컴포즈 되었을 때) 의 동작 차이
- StateFlow 설명
- LiveData 를 액티비티 컴포넌트가 아닌 곳에서 사용했을 때 메모리 관점에서의 장단점
- git flow 설명
- git rebase 와 merge 의 차이점
그 당시 안드로이드를 막 시작한 저에게는 정말 답변하기 힘든 질문들이었습니다. 결국 몇몇 질문들을 제외하면 답을 못하거나 제 뇌피셜을 당당하게 말했습니다. 그렇게 30분 동안의 쉴 새 없는 면접이 끝나고 탈락을 직감한 뒤 Mash-Up의 면접 준비를 시작했습니다…
합격…?
근데 합격했습니다. 제 뇌피셜이 어느정도는 맞았던걸까요…?
면접 경쟁률이 1:4 정도였던 것으로 아는데, 지금도 왜 합격했는지 의문이지만 아마 제가 받은 질문들이 어려운 편에 속했던 게 아닐까 하고 추측하고 있습니다.
어쨋든 드디어 제 YAPP 20기 활동이 시작되었습니다!
디자인을 내가 안해도 된다고?
그동안 프론트엔드(모바일) 개발자라는 명목 하에, 당연하단 듯이 모든 디자인을 도맡아 했습니다. 디자인 툴을 사용할 정도로 예술적인 영감이 뛰어나지 않았기에, 무작정 화면을 만들어 본다음 폰트 크기를 조절하거나, 위치를 바꿔보거나, 여백을 2px씩 수정해보는 작업을 수없이 반복하여 힘겹게 무에서 유를 창조해나갔습니다.
그런데 이게 웬걸? 기획이 어느정도 잡힌 뒤 일주일 정도가 지나자 제 감각으로는 도저히 구상해낼 수 없는 예쁜 디자인이 만들어져 있었습니다. 심지어 Figma를 통해 폰트 사이즈, 여백, 색상값, 아이콘 등등 모두 세세하게 제공되고 있었습니다. 정말 행복했습니다. 드디어 남이 그려놓은걸 따라 그리기만 하면 예쁜 화면이 뚝딱 만들어지고, 오로지 코드에만 집중할 수 있었습니다.
그 뒤로 시간이 더 지나자 디자인과 더불어 앱에 사용할 여러 일러스트들이 추가되며 구경하는 재미도 쏠쏠하고 직접 본인의 손으로 앱의 형태로 구현하니 더욱 뿌듯했습니다.
현업자와 협업을!
YAPP에 들어가기 전에도 현업자와 같이 협업할 수 있다는 것을 알고는 있었습니다. 하지만 알고보니 협업 수준이 아닌 사실상 1대1 멘토링을 받는 수준이었습니다. 그리고 이것이 학생 입장인 제가 생각하는 IT 연합 동아리의 최대 장점입니다.
하나의 프로젝트에 직군 별로 2명이 투입되고, 무조건 학생 1명과 현업자 1명의 조합으로 배치됩니다. 따라서 학생 입장에서는 하나의 repository에서 현업자 분과 함께 고군분투하며 열심히 지지고 볶아져 굉장히 많은 것을 배울 수 있습니다. 특히 안드로이드를 제쳐두고 Git에서부터 굉장히 많은 것을 배울 수 있었는데 제가 배운 것들은 다음과 같습니다.
- 이슈 관리하기
- 마일스톤 관리하기
- 커밋 메세지 바르게 작성하기
- 기능 별로 브랜치 따기
- PR 메세지를 이슈와 엮어 작성하기
- 하나의 PR 단위에 어느 정도의 커밋(기능)을 포함시킬지 판단하기
- pre-commit 으로 lint 적용하기
- Android CI 적용하기
- merge conflict 해결하기
- rebase 하기
- . . .
- 코드 리뷰하기
그동안 PR 한 번 없이 add, commit, push
만을 반복하던 저에게 Github은 그저 코드 저장소였지만, 마침내 Github은 협업 플랫폼임을 깨달을 수 있었습니다. 개발 기술은 구글링과 공식 문서를 통해 얼마든지 배울 수 있지만, 이런 디테일한 협업 지식은 실제로 현업자와 협업을 해보지 않고서는 얻을 수 없음을 느꼈습니다. 제가 배운 것은 단순히 Youtube에서 설명해주는 git flow
가 아닌, 현업에서 몇 년 간 종사 하신 분이 여러 회사 별 convention의 영향을 받고 개인의 고민과 취향을 첨가한 생생한 협업 방식이었습니다. 초반에는 무작정 그 분의 이슈 작성법과 커밋 메세지를 따라했습니다만, 뒤로 갈수록 저 만의 스타일을 찾아갔던 것 같습니다.
근데 사실 가장 중요한 것은 따로 있습니다. 바로 코드 리뷰입니다.
말로만 듣던 코드 리뷰
학생 입장에서 정말 멀게 느껴지는 단어, 바로 코드 리뷰입니다. 일단 취업을 해야 코드 리뷰를 받던 말던 하기 때문에 현업에서 코드 품질을 위해 하는 행위 정도로만 알고 있고 별 관심은 없었습니다. 그런데 YAPP에서 이 코드 리뷰를 직접 겪어볼 수 있었습니다.
당시 PR 기능 조차도 어색했던 저였습니다만, PR이 거절되고 제가 작성한 코드에 코멘트까지 달리니 여간 당황하지 않을 수 없었습니다. 코멘트를 들여다보다 직감적으로 이것이 바로 그 코드 리뷰라는 것을 깨달았고, 열심히 고치고 다시 push를 했습니다. 첫 리뷰 때는 request review 버튼을 눌러야 리뷰어에게 알림이 간다는 것을 몰라 하루를 그저 답변이 달리기를 무작정 기다린 적도 있습니다.
처음에는 그동안 입맛대로 작성하던 코드가 실제 현업에서도 이렇게 쓰이는건지 의문이었던 저에게 굉장히 명쾌한 해답을 주었기 때문에 굉장히 속이 시원하고 즐겁고 흥분(?)됐습니다. 그런데 그런 감정은 얼마 가지 못하고…
현업자분과 함께 약 50번이 넘는 티키타카를 하고 나면 지치기 마련이었습니다. 어느 순간 한 번의 PR 마다 굉장히 신중해졌고, 스트레스도 많이 받았습니다. 물론 이러한 신중함과 스트레스가 실력 향상의 원동력이 되었습니다. 리뷰 또한 하나하나가 굉장히 납득적이어서 반박할 건덕지도 없었습니다만, 가끔씩 모호한 점에 대해서는 끝까지 물고 늘어졌습니다. 결과적으로는 안드로이드 기술 능력 향상에 정말 많은 도움이 되었습니다. 또한 돈을 받는 것도 아닌 현업자분이 이렇게 열심히 코드 리뷰를 해주시는 점에 대해 당시에 정말 감사했습니다.
여담이지만 알고보니 저의 코드를 하나하나 리뷰해주신 같은 팀 안드로이드 현업자 분은 여러 플랫폼에서 리뷰어로 활동하고 계시는 코드 리뷰계의 고인물이셨습니다… 그래서인지 다른 팀에 속한 분임에도 저희 레포지토리에 찾아와 부끄럽게도 제가 코드 리뷰로 혼났던 흔적들을 보며 배워가시는 분들도 계셨습니다. 이렇게 훌륭한 분께 맞으며 배울 기회가 있어 정말 행운이었습니다.
YAPP에서 얻을 수 있는 것
제가 작성했던 코드에 대한 리뷰 외에도, 직접 현업자 분이 작성한 코드를 보면서 많은 것을 배울 수 있습니다. 코드 리뷰는 제가 시도하려 했던 방식에 조금의 개선을 이뤄주는 방식이라면, 현업자 분이 직접 작성한 코드는 굉장히 체계적이고 세련되게 작성되었습니다. 그렇기 때문에 현업자 분이 처음부터 작성한 코드를 해석하려면 구글 검색창을 옆 모니터에 켜두고 코드를 굉장히 오랫동안 째려보아야 했습니다. 마침내 코드를 완전히 해석한 뒤에는 큰 깨달음을 얻곤 했습니다. “와… 이렇게 짜는구나…“
또 팀 별로 슬랙 채널이 개설되는데, 학부 조별과제 카톡 단톡방과는 역시나 다른 느낌이었습니다. 안드로이드 현업자와 백엔드 현업자와의 소통, 디자이너와 안드로이드 개발자의 소통, PM으로부터 개발자로의 요구 사항 전달, QA 리스트 수행 등등… 처음에는 두려워서 대화에 최대한 끼지 않으려고 했습니다만, 막상 급해지니 디자이너와 개발자 분들을 열심히 태그하며 이것저것 요청을 하는 저를 발견할 수 있었습니다.
제가 이번 YAPP 활동에서 얻은 것은 다음과 같습니다.
- Git을 이용한 고도화 된 개발 협업 경험
- 지속적인 코드 리뷰를 통한 Android 기술 교정
- 디자이너와의 의견 조율 및 Figma 협업 경험
- 모든 직군이 완성된 하나의 팀에서의 커뮤니케이션 스킬
어쩌면 인턴십 한 번 해보는 것과 똑같다고 생각할 수도 있겠습니다만, 학생 분들 뿐만 아니라 현업자 분들도 비즈니스 마인드가 아닌 학습과 네트워킹을 위해 오신 열정적인 분들이기 때문에 훨씬 자유롭고 거리낌 없이 배울 수 있었습니다. 또한 동아리 내의 여러 스터디를 통해 교류하거나, 가끔씩 있는 회식을 통해 쉽게 친해지기도 해서 인맥적인 부분에서도 굉장히 만족스러운 활동이었습니다.
마치며
2021년이 SW 마에스트로를 통해 프로젝트를 탄탄히 기획하고 비즈니스 모델을 구상하여 SW를 개발하고 프레젠테이션 하는 방법을 배웠다면, 올해는 정말 제대로 팀원과 협업하며 구체적인 디자인과 아키텍쳐를 통해 견고한 SW를 개발하는 방법을 배운 것 같습니다. 아직도 올해의 개발 활동 일정이 많이 남았습니다만, 그 기반에는 모두 YAPP에서의 값진 경험이 녹아있는 것 같습니다.
- Post link: https://blog.yjyoon.dev/review/2022/09/16/yapp-review/
- Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 3.0 unless stating additionally.