네이버 부스트캠프 9기: 챌린지부터 멤버십·AI 리팩터링·최종 배포까지 회고 본문
네이버 부스트캠프를 멤버십을 수료하며 쌓여버린 기술부채와 모자란 부분 메우느라 공부하고, 같이 진행 중이던 프로젝트도 슬슬 마무리하고, 거기에 졸업 준비까지 겹치니 정신없이 바쁘게 보냈었다.
덕분에 “개발 블로그 꼭 써야지!” 라고 부스트캠프를 끝내놓고 했던 목표는 욕심이 생겨 부스트캠프에서 진행했던 프로젝트를 최종 배포까지 하고싶은 맘에 계속 미루고 말았다.
그런데 벌써 부스트캠프 10기 모집 소식이라니, 시간이 정말 순식간에 흘렀던 것 같다.....ㅠㅠ
프로젝트를 최종 배포하고싶다는 일념 하에 정말 열심히 했었는데, 마침내 배포 버튼을 누르는 순간 긴 여정을 완주했다는 생각에 너무 기쁘고 뿌듯했다.
처음으로 네이버 부스트캠프를 알게 된 것은 iOS 개발을 같이하는 학교 후배(대효준)의 소개로 같이 도전해보는게 어떤지가 시작이었다.
이때 당시에 난 iOS 개발에 흥미를 가지고 학교 프로젝트에서 모바일 앱을 만들고 있었는데, 개발하면서도 스스로 어떤 게 정답인지 모르는 상태로 개발을 하다 보니, 막막할 때가 많았었다.
부스트 캠프에 대해서 찾아보니, 스스로가 학습의 주체가 되어 몰입하고 최고의 동료와 함께 소통하고 협업하며 문제 해결력을 갖춘 개발자로 성장할 수 있는 커뮤니티라는 모습에서 함께 성장하고 싶은 마음에 참여하고 싶단 마음에 생겨 참여하게 되었다.
지원하기 위해 포트폴리오 + 자기소개서를 나름대로 열심히 작성을 하며 내가 왜 개발자를 선택했는지?, 왜 iOS개발에 관심을 가졌는지에 대해서 깊게 고민할 수 있는 좋은 기회였다.
학교 내에서 컴퓨터 공학과 전문 상담을 해주시는 분께 자소서 첨삭을 2차례 받으며 작성하며 내가 부족한 스펙또한 볼 수 있었다. (더 열심히 살걸)
부스트캠프에서 요구하는 문제 해결력 테스트는 CS지식을 묻는 질문들과 코딩테스트는 자료구조 를 선정하고, 구현을 하고 이렇게 구현을 한 이유에 대해서 물어봤다.
난 구현하는 것에는 자신이 있었기에 문제없이 잘 풀어나갔지만 외부 IDE다 보니, 자동완성이나 디버깅하는 환경에서 조금 버벅여서 시간이 부족했다.
운이 좋게도 1,2차 문제 해결력 테스트와 맴버쉽으로 가는 테스트를 무난하게 쳤지만 베이직, 챌린지, 맴버쉽 모두 합격했다. 베이직 과정은 대부분 캠퍼들은 듣고왔지만 학교와 병행하는 이슈로 인해 난 참여하지 못했다.
(사실 베이직을 열심히 하는 것 또한 챌린지 합격 여부에 영향이 끼칠까봐 조금 불안했었다.)
네이버 부스트캠프 챌린지에 합격한 후, 8주동안 진행했던 첼린지 과정은 생각했던 것 보다 정말 힘들었다.
미션에 대해서는 내부 규정으로 블로그에 자세히 설명할 수는 없지만
매일 매일 새로운 요구사항들이 주어졌고 하루안에 풀 수 없는 도전적인 미션을 내주었다. (왜 챌린지를 챌린지라 부르는가를 메일 체감했다)
미션을 하며 항상 학습 시간이 턱없이 부족했다. 부끄럽지만 시간 안에 미션을 완수한 기억이 한번 도 없다.
정답이 없도록 일부러 문제를 모호하게 내주시고 문제를 끝까지 해결하고싶다보니 매번 새벽 2~3시까지 시간을 사용하여 해결하였다.
미션을 하면서 느꼇던 첫번째 점은 CS지식 고도화이다.
대학시절에서 공부했던 내용들이 나오면서 정확하게 기억은 못하고 어렴풋이 기억하고 있었던 나를 볼 수 있었다.
여기서 깨달은 사실은 내가 알고 있었다고 생각했던 CS 지식들은 실제로 알고있는 척에 불과했었던 것 같다. 조금 더 전문성 있는 내가 되기 위해서 기초부터 다시 다져야 한다는 걸 절실하게 느꼈다.
우리의 iOS 마스터 셨던, JK님의 말씀이 인상 깊어 아직까지도 기억난다.
“개구리를 해부하지 말고, 직접 만들어라.”
개구리를 더 잘 이해하려면 개구리 해부보다는 개구리와 똑같다고 부를 수 있을 개구리를 직접 만들어보라 하셨다.
정말 개구리와 똑같구나 싶을 정도로 만들려면 그만큼 개구리를 깊이 있게 이해하고 분석하고 설계를 해야했다.
미션을 수행하며 두번째는 크게 느낀 점은 시야의 확장이다.
짝(페어) 프로그래밍을 통해서는 "왜 이 방법이 타당한 가"를 설명하지 못한 적도 있었다.
짝이 구현은 했지만 더 좋은 방법이 있을 것 같은데도 근거를 구체적으로 제시하지 못해 설득력이 떨어졌던 적이 많았고
반대로 내가 구현을 할때도 짝에게 설득력있게 설명하지 못한 적도 많았다.
(나도 답답하고 짝도 많이 답답했을 거 같다. )
같은 요구사항을 받더라도 해석 단계부터 구현하는 방식까지 캠퍼분들 마다 접근하는 방법이 모두 달랐다. 피어세션이라는 캠퍼분들의 미션을 어떻게 해결했는지 설명하는 과정에서 "정해진 정답은 없다"라는 것을 경험할 수 있었다.
매주마다 조 편성이 바뀌어 동료들과 익숙해질 즈음 다시 바뀌어 아쉽기도 했지만 그만큼 다양한 관점을 빠르게 얻을 수 있었다.
피어 세션에서 동료들은 “이 구현은 이런 문제가 생길 수 있다”고 조목조목 지적했고, 나는 근거가 부족해 대화에 끼어들지 못했다.
이유를 곱씹다 보니, 결국 기술을 정확하게 이해하지 못하면 깊이 있는 토론에 참여할 수 없다는 사실을 깨달았다. 이후 나는 관련 기술의 탄생 배경부터 거슬러 올라가 학습했고, 정리한 내용을 다시 동료들에게 설명하면서 “정리를 잘한다”는 피드백도 얻었다. 로우레벨부터 개념을 다시 쌓아 올리며 스스로 크게 성장했다고 느꼈다.
아무튼 이렇게 첼린지 과정에서 많은걸 느꼇고 이후 멤버쉽 과정에서 4명의 iOS 캠퍼분들과 함께 알쏭달쏭 프로젝트를 시작했다.
프로젝트에서 가장 중요하게 느끼는 것은 이 프로젝트에 대한 애정이다. 모두가 만족할만한 주제를 선정하는 것이 끝까지 프로젝트를 완주할 수 있다는 확신이 있었다.
그래서 첫 회의는 어떤 주제를 할지에 대한 내용이였는데, 팀원들마다 원하는 게 달랐다. 한 분은 기술적으로 심도있게 파기를 원했었고, 한분은 작곡을 할 줄 아셔서, 음악쪽에 대한 도메인 지식이 뛰어나셨던 분인지라 음악에 대한 주제를 원했었다, 난 다른 팀과는 차별화된 기존의 앱에서 없고, 모바일 기기만의 특징을 잘 살릴 수있는 앱을 원했었다.
그러다 번뜩 브레인 스토밍 중 그림으로 릴레이 하는 갈틱폰 처럼, 노래를 릴레이 하면 재밌지 않을까? 라는 아이디어가 튀어나왔다.
* 첫 사람이 노래 A를 8초동안 흥얼거린다.
* 둘째 사람은 그 소리를 듣고 "음... 이건 노래 A?" 하고 자기 나름대로 흥얼거린다.
* 셋째 사람도 마찬가지로 둘째 사람의 녹음을 듣고 "노래 A?" 하고 흥얼거린다.
* 마지막 사람은 맨 끝에 도달한 녹음을 듣고 "원곡이 뭘까?" 를 맞힌다.
생각만 해도 재밌고, 독창적이고 나름대로 기술적인 고민, 음악 도메인에 대한 애정, 독창성 전부 들어맞는 주제를 찾게된 것 같다.
그렇게 열심히 초기 1~2주 정도는 협업 방식, 그라운드 룰 용어 정리, 기획, 피처리스트, 프로젝트 설계, 모듈 명세서, 기술 스택, 엔지니어링 위키, 칸반보드, POC 등등 프로젝트에 필요한 작업들을 진행했는데,
프로젝트에서 한가지의 난제는 여러 기기에서 동일한 데이터를 실시간으로 동기화하는 방법을 찾는 일이었다. 우리는 iOS 개발자 네 명뿐인 팀이라 전담 백엔드 인력이 없었고, 모두가 애초에 “iOS 역량 강화”를 목표로 모였기에 백엔드까지 손대야 한다는 부담에 살짝 주저하는 분위기였다. 하지만 나는 “어떤 기술을 깊이 이해하려면 그 주변 영역까지도 두루 알아야 한다”는 신념이 있었기에, 과감히 백엔드 역할을 맡기로 했다.
그렇게 나는 프로젝트 규모, 학습에 필요한 시간적인 여유와 실현 가능성을 고려해 Firebase ServerLess를 선택했고 서버 아키텍처 설계 & iOS Firebase 통신 모듈에 대한 설계를 맡았다.
Firebase에서의 데이터 변경이 일어 날 때마다 값을 방출하고 뷰에 반영하기 위해 데이터 흐름을 Combine을 통해 제어를 했었는데, 내가 원하는 대로 흐름이 동작하지 않았다. (Firebase 모듈이 제멋대로 같은 값을 두번 보낸다던가, 느리게 반응한다던가, 캐싱을 하고있어 변경이 되지않고있는 .. 아주 말썽이였다.) Firebase SDK는 내가 건들일 수 없으니, 좀 더 많은 Combine에 Operator에 대한 이해가 필요해보였다.
마지막 6주차에 돌입했을 때는 QA와 최종발표 준비를 했었다. QA를 할 때마다 UX적으로 고쳐야 할 부분, 기능이 동작하지 않는 경우 버그가 많아서 발표 날까지도 최대한 버그를 수정을 했다.
최종 발표에서 우리가 어떤 문제를 정의했고 해결했는지, 데모, 트러블 슈팅 순으로 발표를 잘 마무리 할 수 있었다. 나름 좋은 성과가 있었다.
CS 리펙토링, AI 리펙토링
GitHub - boostcampwm-2024/refactor-ios11-alsongDalsong: 알쏭달쏭 노래를 맞춰보세요!
알쏭달쏭 노래를 맞춰보세요! Contribute to boostcampwm-2024/refactor-ios11-alsongDalsong development by creating an account on GitHub.
github.com
CS 리펙토링과 AI 리펙토링에서는 다른 팀원들의 프로젝트를 리펙토링 해보고 싶은 캠퍼분들이 선택적으로 참여할 수 있었는데,
새로운 팀원 세명, 그리고 나를 포함한 기존 팀원 두명, 총 5명의 팀원들과 함께 프로젝트를 개선하고, 새로운 AI 기능을 추가하는 작업을 할 수 있었다.
CS 리펙토링에서는 기존 프로젝트의 문제 파악 및 수치화를 하는 작업을 진행하였다.
특히 새로운 팀원들에게 프로젝트의 구조를 설명하는 과정에서 어떤 의도로 코드를 작성했는지 에 대해 명확하게 설명할 수 있어서 많이 성장했다고 느꼇다.
두번 째는 Instrument를 사용하여 메모리의 누수와, Hang이 걸리는 작업들을 개선하는 작업들을 할 수 있었다. 이때 CS 동아리를 통해서 운영체제의 자원관리와 파일시스템에 대해서 많이 배울 수 있었고, 그 결과 이미지 로딩 시간 개선, 캐시메모리 개선, 메모리 누수 개선을 할 수 있었다.
AI 리펙토링에서는 사실 어떤 기능 도입을 할 때 사용자에게 좋은 경험을 줄 수 있을까? 에 대한 고민을 많이 했는거 같다. 특히나 우리 프로젝트에서는 유의미한 경험을 도출해 내기가 어려웠다. 그래도 우리 게임에서 부족한 게임 설명을 개선하고자 튜토리얼 과정을 만들기로 결정하였고, AI가 직접 허밍을 하고, AI가 노래를 맞추는 기능을 추가하였다 (성능이 많이 모자라다 ㅎㅎ)
AI 리펙토링에서는 그래도 자신감은 얻었다. AI를 어떻게 활용할 수 있는지, 프로젝트에 어떻게 적용할 수 있는지, CreateML을 다루는 법 등등 짧은 기간동안 좋은 경험을 할 수 있었다 !
최종 배포
GitHub - alsongDalsong/iOS-alsongDalsong: 알쏭달쏭 노래를 맞춰보세요!
알쏭달쏭 노래를 맞춰보세요! Contribute to alsongDalsong/iOS-alsongDalsong development by creating an account on GitHub.
github.com
최종 배포에서는 배포를 위한 완성도를 높이기 위한 작업을 했다.
캐릭터, UI & UX 개편, Localization , 배경음악과 효과음, 햅틱, 버그 픽스 등등 추가가 되었다.
특히 어려웠던 점은 기존 Audio를 관리해주는 싱글톤 패턴에서 상태관리를 하고있었는데, 당시에는 음악 재생이 단순히 녹음과 노래만 재생을 하고, 현재 어떤 노래가 재생되고있는지 Publisher로 방출하고 있었는데, BGM이 추가되다보니 굉장히 상태가 꼬이게 되는 문제가 많아 골머리를 앓았다..
반드시 다시 리펙토링을 반드시 해야할 것 같다.
마지막 결론
* CS 지식을 정확하게 무조건 정확하게 알고 설명 할 정도로 잘 알고 있어야 할거같다. -> 기술 블로글 작성해서 전문성 쌓아보자
* 프로젝트는 팀원들도 모두 무조건 재밌고 열정을 가질 수 있는 주제로 하는 것이 팀원들과도 열정이 식지 않고 끝까지 완주할 수 있는 원동력이 되는 것 같다. (더 애정을 갖게되는거 같다.)
* 설계 할때는 좀 더 신중히
* 주장을 할 때도 내 스스로 납득되지 않으면 절대 남을 납득 시킬 수 없다.
* 프로젝트 최종으로 완성해서 너무 기쁘다
* 글쓰기 미루지말자
값진 경험을 해주게 해주신 부스트캠프 운영진분들, 멘토님, 9기 캠퍼분들 너무 감사합니다.
완성도 있는 프로젝트를 위해 정말 애쓰고 고생 해 주신 우리 팀원분들 최고 십니다