[Apple Developer Academy] 3번째 프로젝트 회고 (후기...?)

2022.06.27 ~ 2022.08.05

6주간 진행했던, 애플 디벨로퍼 아카데미에서의 공식적인 3번째 프로젝트가 끝났다. 이번 팀프로젝트에서는 정말 잘하는 팀원들을 만나서 비교적 개발은 수월하게 끝냈지만, 그 개발과정에서 정말 배운점이 많다. 프로젝트를 진행했던 과정에 대해서 다시 되짚어보고, 아쉬웠던점 그리고 잘했던점에 대해서 회고해보자.

 

🟣 Mini Challenge 3 팀원들과의 첫만남

미니 챌린지 3 (세번째 프로젝트, 이제부터 MC3라고 부르겠다) 팀원들에 대한 기대가 컸다. MC2때 개발자 한명으로 너무 고군분투 했었기 때문에, 멘토들과도 많은 이야기를 나눴었고, 앞으로 팀을 짤 때는 개발자 한명만 둔 팀이 없도록,, 멘토들에게 신신당부하면서 MC3 명단을 기다렸다. 

MC3의 팀원들의 첫인상은 강렬했다. 일단,,, 우리팀은 5명이었고 5명다 개발자였다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이런,, 중간이없어 중간이...(이런 부분은 애플 아카데미에서 조금은 개선되어야 하지 않을까?)
그리고,,, MC3의 팀원들은 나 빼고 전부다 친한사이였다. 5명중 4명이 모두 서로 반말을 하는 사이였고, 나만,, 나만,, 존댓말로 안녕하세요,, 쭈뼛,,, 하면서 팀원들을 마주했다.

💬 반말합시다, 대신 예의를 지킬 수 있는 team 규칙을 설정하자

나빼고 모두가 친한 사이였기 때문에, 팀원들도 눈치를 보면서 존댓말을 해야하는 상황이었다. 원래 팀프로젝트 내에서는, 존댓말로 항상 진행했었고 나도 그게 좋았었지만, 이번 팀프로젝트에서는 우리 팀만의 분위기로 만들어가야겠다고 생각했다.

나를 포함해서 모두 말을 놓기로 결정하고,, 애플 디벨로퍼 아카데미에서 처음 팀이 정해지면 항상 하는 '팀 규칙'을 정하고 아이스브레이킹 시간을 가졌다. 우리팀은 모두 반말을 하는 상황이기 때문에, 가장 중요한 룰이 이거였다.

"아니 근데, ~ " 금지 🚫

반말로 기획회의부터 진행해야 했기 때문에, '아니근데, 아니~'로 시작하는 말을 하지 않기로 했다. 존댓말이 아니면 서로 더 기분이 많이 나빠질 수 있기 때문에!! 지금 생각해보면, 이런 소소하고 구체적인 팀 규칙 때문에 말로 인해 기분 나빠지는 일도 없었고, 서로 피드백을 자유롭게 반말로 주고받을 수 있었다.

💬 매일 아침 테트리스하기

팀원 한 분이 매일 아침 머리를 깨우는 시간을 가지면 어떨지 제안했다. 팀원 모두가 간단한 게임을 좋아하는 성향이었고, 간단하게 웹 페이지에서 팀끼리 모여서 테트리스 할 수 있는 게임툴을 사용해서 매일 아침 9시 15분에 테트리스를 진행했다. 오전에 오면, 다들 피곤하기도 했고, 피곤하다보니 말이 없어지면서 '언제,, 회의를 시작하지..?'하는 애매함이 있었는데, 이러한 재미난 팀 규칙 때문에 팀프로젝트는 아침부터 에너제틱하고 정말 재미나게 흘러갔다.  (또 재밌었던건, 팀원들 점점 테트리스 실력이 올라가서 뒤로 갈 수록 게임이 안끝나고, 한판이 굉장히 길어질 때가 많았다. ㅋㅋㅋㅋㅋ)

그리고 게임 결과에 따라서 역할을 나눴다. 

이렇게 역할을 나눴고, 개발 단계에서 스프린트의 도입으로 팀별로 공유하거나, 발표할 상황이 굉장히 많았는데 이런 사소한 것들도 모두 게임으로 정해졌다.ㅎㅎ

글을 보고 팀원들한테 연라이왔다 ㅋㅋㅋㅋㅋ 맞다.. 우리팀 왤케 테트리스 잘해? 나만 매일 5등을 했었고, 운이 좋으면 4등을 했었다. 원래 서기가 나라서 4등하면 서기 서포트 없이 나 혼자 모두 기록했다 ^___^ 차라리 5등이 나을수도..?

 

🟣 기획 단계

우선 기획단계에서의 회고를 진행하기 전에, 어떻게 이 주제에 도달하게 되었는지 기억하고 싶어서 짧게 후기를 작성해 보겠다.

이번 MC3프로젝트의 주제는 '사회의 커뮤니티를 위한 앱 개발하기'였다. '커뮤니티'는 아무거나 괜찮았다. 단, 특징이 명확하고 타겟이 명확한 앱을 개발하라는 이야기였다. 예를들어, 'BTS를 좋아하는 외국인 팬덤을 위한 앱' 혹은 '매일 아침 러닝을 뛰는 러닝족을 위한 앱'이 있을 것이다.

✏️ 팀원 모두가 공감하는 주제 찾기

팀원들 모두가 공감하기 위해서, 떠오르는 주제들을 적으면서 브레인스토밍을 진행했다. 커뮤니티를 위주로 찾아야 하기 때문에 '문제가 뭔지'에 대해서 고민할 수 있는 주제들로 나열해나갔다.

교육, 육아, 임산부, 개발자 커뮤니티, 카메라, 연애, 부모님, 여행 등 다양한 대주제가 나왔다. 최대한 이야기를 나누면서 어떤 주제에 관심이 많고, 어떤 커뮤니티에 어떤 문제점이 있는지 파악하려고 애썼다. 브레인 스토밍하고, 하루종일 대화하면서 느낀 점은, 우리 모두는 '연애'와 '부모님'과 관련된 커뮤니티, 키워드에 관심이 많다는 것을 깨달았다.

✏️ 문제 및 커뮤니티 설정

부모님을 대주제로 정하고, 우리가 최대한 공감할 수 있는 문제점을 찾아나섰다. 20대 성인 5명이 모였던 만큼, 아래와 같은 공감대가 형성되었다.

이런식으로 우리가 부모님과 관련되어 걱정됐던 것들, 우려했던 것들 등 문제를 정의하기 위해서 브레인스토밍을 진행했다. 이중에서 가장 우리가 지금 현재 공감갔던 것은 아래 주제와 같다.

하지만, 우리의 이번 MC3 주제는 바로 '커뮤니티'를 찾는 게 우선이었다. 우리는 '부모님'이라는 대주제 키워드로 먼저 접근했고, 그래서 우리는 그래서 부모님과 관련된 문제를 느끼는 '커뮤니티'가 어딘데? 하는 문제를 마주쳤다.

그래서 부모님과 관계에 있어서 가장 소홀해지고, 가장 문제점이 많다고 느끼는 커뮤니티를 찾아나섰다. 부모님과 연락이 힘들었던 학생을 찾다가, 애플 아카데미 내부에 '유학생'이 많았던 점을 고려해서 '유학생'들에게 무엇이 힘들었는지 물었다.

더불어 여러가지 유학생 커뮤니티에 들어가서 부모님과 연락할때의 힘든점, 그리고 연락할때 주로 어떤 문제점이 있는지에 대한 이야기를 많이 나눠보았다. (카카오톡, 그리고 네이버 카페를 이용했다. 캡쳐 내용은 블러처리!!)

그들의 대답들 중 공통점은 하나같이 '시차가 달라서 부모님과 전화하는 것 조차 힘들다'였다. 그래서 우리는 '부모님과 관계가 가장 소홀해지는' '해외 유학생'을 타겟으로 '유학생을 위한 부모님 전화 주기 알리미 CallMe Baby' 라는 앱을 개발하기로 결정했다.

두둥..!

🔖 기획 단계에서 아쉬웠던 점

🙌🏻 지쳐서 모든 질문에 Yes라고 대답했다.

사실 이번 팀 프로젝트는, 크게 자기주장이 강한 사람이 없었어서 수월하게 흘러갔다. 하지만, 거기서 왔던 단점은 너무 'yes'로만 가지 않았나 하는 아쉬움이 남았다. 나는 정말 사실대로 이야기하면 MC3를 시작하기 전에 조금은 지쳐있었다. 6개월 내내 팀프로젝트를 진행했고, 기획 회의에서 너무 많은 힘을 뺐었기 때문에 이번 프로젝트에서는 조금은 가벼운 마음으로 진행해보자 하는 마음이었다. 이런 마음이 내가 프로젝트를 진행하는데 많이 방해가 되었던 것 같다. 내가 생각했던 방향과 다르게 진행되어도, '일단 가보자'하는 마음으로 Yes라고 대답했고 기획에 욕심을 내지 않았다. 이런 마음으로 팀프로젝트를 진행했는데, 과연 옳은 마인드일까?

회사를 가게되면 모든 프로젝트는 '팀'단위로 운영된다. 결코 혼자하는 일이 없을 것이다. 하지만 고작 6개월 팀프로젝트를 진행했다고 지쳤던 내 모습은 굉장히 실망스러웠다. 이렇게 지친 내모습이 모든 의견에 yes 라고 대답하게 되었고, 그만큼 내가 이 프로젝트에 대한 애정도 점점 식어갔다. 마지막에 프로젝트를 되돌아 봤을 때, 이런 내 모습을 많이 반성했다. 내가 진정 내 프로덕트에 자부심을 갖고, 진심을 다해서 문제를 해결해 나가려면 이런 마인드를 가지면 안된다는 것을 깨달았다. 단순히 내 마음이 지친다고 이 모습을 팀프로젝트까지 너무 끌고간것이 아니었을까. 다음 프로젝트에서는 '마인드 컨트롤'하는 방식에 대해서 조금 더 연구하고, 나의 이런 안좋은 마인드가 팀프로젝트에 영향을 주지 않게 하기 위해 노력해야겠다고 많이 느꼈다.

 

🔖 기획 단계에서 내가 잘한 점

🙌🏻 팀에서 서기 역할을 담당했다. (내가 도움이 될 수 있는 부분을 최대한 찾고, 실행했다.)

https://silver-saturnalia-c1b.notion.site/0c90b0717a4b4c50a9c8b345bf02224a

모테 - 모닝테트리스

팀 프로젝트를 하면서 어떤 역할로 내가 도움이 될 수 있을지 살폈다. 그중에 내가 가장 잘 할 수 있는 것은 바로 '기록'이었다. 팀원들 모두가 이야기하는 내용을 적어서 최대한 의견충돌을 줄여주고, 원활한 회의가 될 수 있도록 돕는 역할을 하겠다고 했다. 

팀 notion 회의록 내부

이렇게 기록하니까, 팀원들끼리 의견 충돌이나 문제를 재설정하는 시기가 있을 때 회의록을 돌아보며 차근차근 진행할 수 있었다. 또 회의록에 어떤 일을 했는지 history를 남겼기 때문에 문제가 생겼을때 바로바로 그날의 회의록으로 들어가 회상하면서 팀원 사이에서 생긴 문제를 적절히 해결할 수 있었다. (예를들어, 문제를 재정의해야할 때나, 커뮤니티를 설정해야할 때 회의록을 많이 뒤져보면서 우리 팀원들이 어떤 문제에 가장 관심이 많고, 이야기가 많이 오갔는지에 대한 내용들을 체크할 수 있었다.)

 

🟣 디자인 단계

지난번 MC2 프로젝트 회고를 보면 이번 MC3프로젝트에서는 디자인을 주도적으로 진행해보는 것에 도전해보고 싶었다. 하지만, 생각처럼 그게 잘 되지 않았다. (내가 적극적으로 그렇게 하지 못했다... )

개발자5명이서 모였지만 우리 중 한명이 HIG요소에 대해서 잘 알고, 디자인을 잘하는 팀원이 있었다. 그 팀원 주도하에 디자인이 진행되었다. 이번 단계에서는 최대한 HIG 요소를 활용한 앱을 만드는 것이었다. 내가 주도적으로 디자인을 하진 않았지만 이번 프로젝트를 통해서도 배운게 많았다.

🔖 (느낀점 및 배운점) 이게 왜 필요한 기능인지 생각해보자 (Why, why!!!)

우리는 '전화 주기 알리미'앱이다. 전화주기를 파악하는데 '달력'이 굳이 필요할까?

맨 처음 디자인 (design by. AVO)

맨 처음 디자인은 이렇다. 팀원 모두 달력을 넣는 것을 동의했기에 초안으로 이런 깔끔한 디자인이 완성되었다(Thanks AVO🥑). 하지만, 멘토들의 피드백은 달랐다. 우리가 가장 중요하게 생각하는 것이 무엇인가? '몇월 며칠'에 전화를 했는지가 중요한가? 혹은, '몇번을 꾸준히'전화했는지가 중요한가?

사실 우리는, 후자가 더 중요했다. 몇번을 꾸준히, 혹은 3일마다, 5일마다, 주기가 중요했을뿐 달력에 적혀있는 '날짜'는 전혀 중요치않았다. 그니까 즉, 내가 엄마한테 4월 3일에 전화했는지는 중요하지 않다는 것이다. 며칠전에 전화했지? 가 중요하지...

그렇다면 달력을 사용하지 않아도 되지 않을까? 

앱 '무다' 예시

감정 기록 다이어리 앱 무다를 보면, 달력이긴 하지만, 감정기록이 더 중요하기 때문에 감정으로만 기록이 저장된다. 즉, 내가 4월 3일에 슬펐나? 보다, 내가 언제 주로 슬펐지? 에 대한 것에 더 초점이 맞춰질 수 있다. 우리도 이런 것처럼, 달력보다는 '주기'가 더 중요했기 때문에 개발공수가 많이 드는 달력은 굳이 필요하지 않다는 피드백이 많았다.

이번 디자인을 보고나서도 느낀점이 참 많았다. '기록? -> 무조건 달력이지!' 하는게 아니라, 왜, 꼭, 이게 필요한것인가? 우리의 목적은 무엇인가? 우리가 유저에게 어떤 정보를 잘 전달하고싶은가?에 대해서 고민해봐야한다는 점이다. 또 다른 좋은 예시로 '깃허브 커밋창'을 확인할 수 있었다. 내가 12월 1일에 몇커밋을 했는지가 중요한게 아니라, 얼마나 꾸준히 잔디를 채워나갔는지가 더 중요하지 않은가? 그렇듯, 우리도 굳이 '달력'이라는 기능을 가져갈 이유가 없었다. 

나의 잔디,, 나름 꾸준히 채워 나갔다. 뿌듯!

이 커밋창을 바라보는 개발자, 즉 유저의 심리는 모두 나와 같지 않을까? 바로 "뿌듯함" 이다. 그리고 구멍이 뻥 뚫려있는 모습이 가슴이 아프기도 하다. 우리는 이러한 감정을 유학생들에게 주고 싶었다. 유학생활을 하다보면 며칠이 지났는지 까먹고 지낸다는 점이다. 그래서 부모님께 전화를 한달, 그 이상을 안할때가 있다고 한다. 우리는 이렇게 부모님에게 전화를 하지 않은 날에 깃허브 커밋창 잔디의 구멍처럼 송송 뚫려있는 UI를 제공해서 약간의 '죄책감'을 느끼게 하고 싶었다. ㅎㅎㅎㅎ (^___^)

그렇게 우리의 의견이 반영된 디자인은 다음과 같았다.

팬더 그림 by 워니 / design by AVO🥑

우리는 그래서 과감하게 유저에게 '몇회' 전화를 했는지, '얼마나 자주 전화를 했는지'보여주고자 왼쪽 같은 뷰를 만들었다. 그리고 주기를 가장 잘 볼 수 있도록 깃허브 커밋창처럼 구현해보기로 했다. 더불어서 메인 화면에서도 마지막전화가 언제였는지, D day 기법으로 보여주면서 명확하게 며칠 전에 전화했는지 보여주고자 했다. 이렇게 디자인을 바꾸면서 '모든 디자인에는 why를 생각하자'라는 깨달음을 얻었다.

🟣 개발 과정, 처음 시도한 것들이 많았다.

이번 개발 과정에서는 말로만 들어봤던 스프린트와, 플래닝 포커의 도입이 가장 핵심이었다. 그리고 또 여러개의 조건이 붙었다. UIKit으로 개발할 것, HIG 요소를 최대한 활용해서 개발할 것, 써드파티를 사용하지 말것! 등등의 조건이 있었다. 우리는 이 모든 것을 지키려고 노력했다. 그리고 이 중에, 내가 느낀점이 많았던 점들에 대해서 회고해보자.

💬 스프린트의 도입

이번 프로젝트에서는 스프린트를 도입했다. 6주라는 짧은 기간이기 때문에 2차 스프린트까지 진행했다. 짧은 기간동안 회의를 통해 진행하고, 그 이후 더 개선점을 반영하여 2차 스프린트로 진행하는 일정이었다. 총 1주일씩 주어졌다. 그래서 개발기간은 총 2주... 스프린트를 진행하면서 아쉬웠던점에 대해서 생각해봤다.

🔖 스프린트 회고, 리뷰에서 '개인회고'를 진행하지 않았던 점

 

스프린트를 진행할때 가장 중요한 것은 회고 및 회의, 리뷰라고 생각한다. 하지만 처음 시도해본 스프린트였기 때문에, 개발하기 급급했고 1차때 끝내지 못했던 것에 대해서 바로바로 쳐내고 싶어서 제대로된 회의 및 리뷰를 진행하지 못했던 점이 아쉬웠다. 진행하긴 했는데, 본인에게 솔직하지 못한 탓이었을까? 팀 내부에 대한 회고만 진행됐고, 내 스스로 어디가 문제였는지 '개인회고'를 하고 진행하는 시간이 부재했다.

1차 스프린트가 끝났을때 개인회고를 제대로 공유 했더라면, 내가 어떤 부분에서 시간을 많이 썼고 내가 어떤 부분에서 힘들었는지 팀원들과 조금은 공유가 되지 않았을까? 하는 아쉬움이 있다. 뒤에서도 나오겠지만, 내가 이번 프로젝트에서는 시간관리를 단단히 실패했기 때문이다. 처음 다뤄보는 UIKit이기도 했고, 내가 처음 다루다보니 어떻게 시간설정을 해야하는지 전혀 감이 안잡혔기 때문이다. 

결국, 마지막 2차 스프린트때는 우리팀에서 개발을 가장 잘해서 CTO 역할을 맡았던 우디가 주도적으로 모든 코드를 수정하고, 모든 문제를 쳐내기 바빴다. 이 모든 것이 팀원들 서로서로 본인의 실력이 어땠는지, 본인이 진행하면서 어떤 점이 어려웠는지 제대로 공유가 되지 않아서 그랫던 것이라고 생각된다.

개인회고는 진행하지 않았지만, 스프린트에 대한 전체적인 회고는 간단하게라도 진행하고 넘어갔다. 

https://silver-saturnalia-c1b.notion.site/1-e7ae05a644ba439ebed738bfd180f202

1차 스프린트 리뷰

https://silver-saturnalia-c1b.notion.site/1-65741f606b82417f9618629707399f04

1차 스프린트 회고

 

🔖 1차 스프린트로 하기로 했던 내용을, 2차까지 끌고가게 되었다. 결국, 2차때 새롭게 추가하기로 했던 기능들에 대해서는 전혀 개발하지 못했다.

2차 스프린트가 있다는 기대감 때문이었을까? 1차때, 우리는 모든 기능을 "2차때하자~" 마인드로 모두 넘겨버렸다. 왜 이렇게 되었을까?
우리 모두 UIKit이 처음이었기 때문에, 1차 스프린트때 어디까지 진행이 가능할지에 대해서 전혀 감이 안오는 상황이었다. 그래서인지 모두가 시간관리에 실패했던 것 같고, 그래서 더 '2차도 있는데, 뭘 급하게해!'하는 마인드가 마음속에 생겨버린것 같다.

사실, 처음 의도한 스프린트는, 1차 때 개발한 기능을 토대로 추가하거나, 삭제하거나, 개선하기 위한 기간을 2차로 잡았었지만, 우리는 모든 기능을 2차로 미뤘기 때문에, 1차와 2차스프린트에서 진행한 기획 내용은 동일했다. 즉, 1차스프린트로 하기로 했던 모든 것들이 그냥 기간만 길게 늘여 진행했다는 것이다. 우리가 이렇게 되지 않았으려면 어떻게 했어야할까?

우선, 1차때 개발 가능한 기능을 최소로 줄여서 각자 최소 task 만 담당했어야한다고 생각한다. 그리고 UIKit을 잘 못하는 사람들이 많았기 때문에 MC1때 진행했던 것처럼 'pair programming'을 진행했으면 어떘을까? 더 많은 지식을 공유할 수 있었을 것이고, 두명이서 개발하면서 더 많이 배우고, 오히려 개발속도가 빨랐을 것이라고 감히 예상해본다. 지금까지 페어 코딩을 하면서 느꼈던점은, '코딩'에 아주 익숙한사람들이 페어 코딩을 하면 시간이 더 오래걸릴 수도 있다는 단점을 갖고 있기는 하지만, 처음 코딩을 배우는 사람들에게는 이처럼 서로에게 좋은 선생님이 되어주고, 좋은 조언자가 되어줄 수 있는 방법이라고 느꼈다. 그래서 이렇게 팀원들끼리 모여서 개발을 하고, 페어코딩을 하는 시간을 갖지 않았던 점에 대해서 아쉬움이 남는다.

또, 기획단계에서 정확한 기능명세를 하고 넘어가야한다고 생각했다. 기획 회의에서 진행했던 점에 모호한점이 많았어서, 내가 1차 스프린트때 담당한 뷰는 아예 개발에 적용되지도 못하고 코드가 삭제되기도 했다. 이런 점들이 계속되다 보니까 1차때 개발해야하는 것들이 점점 2차로 밀리고, 추가기능 / 개선은 하지도 못한채 개발하기 급급했던 것 같다. 필요없는 뷰가 갑자기 발견됐다는 것은, 개발자 한명의 인력을 잘 못 사용했다는 의미도 있기 때문에, 개발 조직 내부에서는 정말 critical 하다고 생각된다. 다음 프로젝트에서는 이런일이 발생하지 않도록 꼭 기능명세를 먼저 작성하고, '이 기능이 왜 필요하지? why!' 에 대해서 질문하는 사람이 되어야 겠다고 생각했다.

💬 플래닝 포커

멘토들이 팀원들끼리 시간 분배를 할때 새로운 방식으로 '플래닝 포커'방식을 제안해주셨다. 내가 해당 task를 개발하는데 "8시간 걸릴것 같다"라고 배팅하고, 동시에 다른 팀원들이 생각했을때 내가 그 task를 구현하는데 얼마나걸릴지 배팅해준다. 두개의 시간을 고려해서 나에게 시간을 배정하는 방식이다.

🔖 스스로 시간관리에 실패한점 (플래닝 포커,,, 어떻게 잘 사용할 수 있을까?)

우리팀은 플래닝포커가 제대로 진행되지 않았다. 처음 플래닝포커를 하라고 제시해주셨을때, 우리 모두의 반응은 다음과 같았다.

아니 UIKit이 뭔지도 모르고, 어떻게 개발하는지도 모르는데 내가 이걸 어떻게 몇시간 걸린다고 이야기함?

이런 반응... 그래서,, 우리는 결국 플래닝 포커를 진행하지 않은 채로 1차 스프린트를 진행했다. (불길...)
역시나, 모두가 제대로된 뷰를 1차스프린트 마지막까지 구현해오지 못했고, 결국 우리는 이 모든 task를 2차 스프린트로 끌고가게 되었다. 

그렇다면, 이렇게 모두가 처음인 상황에서는 어떻게 시간분배를 할 수 있을까? 아직 명확한 해답은 찾지 못했지만, 지금의 나라면 이렇게 할 것 같다. 우선, 시간 설정을 하기전에 '리서치의 시간을 갖자'고 제안할 것이다. 담당하게될 task에 대해서 겉핥기식으로 먼저 검색을 해본 이후, 내가 이 코드들을 이해하고, 구현하는데 얼마나 시간을 쏟을 것인가에 대해서 생각해볼 수 있을 것 같다. 다음 프로젝트에선 처음보는 task를 담당하게 될때, 이렇게 먼저 검색을 한번 해보고, 가늠하는 것이 좋을 것 같다. 

MC3에서 내가 했던 대답인 "얼마 걸릴지 모르겠는데요?"라는 대답은, 팀원 모두에게 민폐를 끼치는 대답인것 같다. 다음 스프린트로 여정을 떠나기 위해서는 팀원 전체의 박자가 맞아야하는데, 내가 그때까지 해내지 못하는 상황이 발생하면, 팀 전체가 stop 되는 상황이 발생할 수도 있기에, 이런 부분에 대해서는 절대 무책임한 대답은 하지 않겠다고 다짐했다. 

💬  처음 사용해보는 UIKit

🔖 제대로 하지 못했던 코드리뷰 (팀원의 코드를 잘 이해하지 못했다)

이번 프로젝트에서는 '코드리뷰 문화'를 제대로 가져가고 싶었다. 팀원들 중 남의 코드를 잘 이해하는 AVO나 우디가 주도적으로 코드리뷰를 진행해주었지만, 나는 다른사람의 코드를 리뷰하는 능력이 아직은 부족했다. 우선, UIKit을 처음 봤기 때문에 어떤 것이 좋은 코드인지, 어떻게 제안해야하는지 전혀 방법을 몰랐다. 그래서 이번 시간은 남의 코드를 잘 보고, 팀원과 코드를 한발자국씩 맞춰가는 시간으로 삼았다.

하지만, 개발에 속도가 붙어나가면서 pr이 늘어나게 되니까 점점 팀원의 코드를 이해하지 못하는 일이 발생했다. 특히 우리팀은, 새로운 디자인 패턴을 많이 사용했는데, 이부분을 CTO 역할을 담당했던 우디가 잘 설명을 해줬는데도 잘 이해가 가지 않았다. 모든것을 이해하고 넘어가려고 하니, 과부하가 오던 상태였고, 내 코딩에도 잘 집중하지 못하는 일이 발생하고 말았다.

이렇게 처음 프로젝트를 진행할때는 어떠한 자세를 갖고 개발하고, 이해하는게 좋을까? 이 부분은 아직도 의문점으로 남아있다. 회사에 들어가게 되면 더 크고 많은 코드를 만지게 될텐데, 회사 사람들은 본인이 속해있는 팀의 코드를 전부 이해하고 있을까?

우선 내가 가장 부족하다고 생각된 점은, '남의 코드를 이해하는 능력'이었다. 특히 우리팀의 CTO, 갓우디🌳의 코드를 보고 이해할 수가 없었다. (내가 많이 부족해서 이해를 할 수가 없었다는 뜻이다... 처음보는 단어가 많아서.... 우디 오해하지마... ) 도대체가 무슨말이야... ....... . .... 흑,,,  그래서 나는 핸드폰 깃허브 어플로 우디의 코드를 기차로 이동하면서도 보고, 침대에 누워서도 그냥 책읽듯 읽었던것 같다. 이렇게 해도 모든것을 이해할 수는 없었지만(모든것을 구글로 뒤져보면서 따라가기가 벅찼다는뜻이야 우디... 오해하지마...), 그래도 우리 팀원의 코딩 스타일이 어떤지, 그리고 내가 어떻게 코드를 분리해서 작성해야할지에 대한 감이 조금은 잡혔던 것 같다.

아니 이거보고도 팀원들한테 연락이 왔따 ㅋㅋㅋㅋㅋㅋ 내가 글을 이중적인 의미를 담을 수 있게 써놨더라고..? 내가 이해하지 못한게 일일히 하나하나 다 찾아보지 못했고, 내가 부족해서였는데, 우디의 코드 스타일이 더러워서 많이 읽어도 이해하지ㅏ못햇다!! 라는 식으로 이해를 해버리게 글을 써버린것이다..그래서 위에 오해하지말라고 변명을 써놨다 ㅋㅋㅋ ^___^ 우디짱

 

💬 Dynamic Type을 적용해보았다. 

이전에 MC1, MC2프로젝트를 진행할때는 모든 뷰를 Dynamic Device에 맞출 생각도 하지 못했었고, 글씨도 그냥 '고정값'으로 사용했었다. 근데 이번에는 달랐다. 모든 디바이스에서 깨지지 않는 UI를 가져가기 위해서 AutoLayout을 잘 사용해보는 것이 목표였고, 더불어서 모든 글꼴 타입에는 Dynamic type을 적용해보기로 했다.

Accessibility를 중요시 생각하는 애플이기에, 핸드폰 글꼴이 커지면 앱의 글꼴까지 함께 커지는 것 이런 사소한 것들도 모두 고려한 앱이 '잘 된 앱'이라고 할 수 있을 것 같다고 생각됐다. 글꼴을 아주 크게 늘리면 뷰가깨지는 현상이 있는지에 대해서 계속해서 테스트해보면서 'iOS'에 대해서 조금은 더 잘 이해할 수 있었다.

design by AVO

by AVO

 

🟣 최종적으로 느낀점

최종적으로 이번 프로젝트는 '아쉬움'이라고 표현할 수 있겠다. 아직 개발 실력이 많이 부족하여 팀원들에게 내가 많은 도움을 주지 못했던 것에 대해서 아쉬웠고, 우리 팀 프로젝트의 코드를 전부 이해하지 못했던 것에 대해서도 아쉬웠다.

이전 MC2 팀에서는 내가 주도적으로 개발을 담당했지만, 이번 프로젝트에서는 정말 잘하는 CTO 갓우디가 존재했기에, 그에게 많이 의지하면서 개발을 진행했던 것 같다. 한편으로는, 우리 팀원 모두가 우디에게 의존해서 개발했기 때문에 그에게 너무 큰 부담을 주진 않았을까?하는 걱정도 된다. 그래서 서로에 대한 개인회고를 꼭 진행해보고 싶었지만, 그렇게 하지 못해서 더 많은 아쉬움이 남는다.

🤒 코로롱 이슈...

또 하나의 아쉬웠던 점은, MC3를 진행할때, 애플 디벨로퍼 아카데미 내부에 코로나가 유행했었다. 그중에, 나도 걸리게 되었고, 우리 팀원들도 룸메가 코로나에 걸리거나, 함께 밥먹은 사람이 코로나에걸리거나 등등 코로나이슈가 굉장히 많이 발생했다. 그래서 안그래도 짧은 6주였는데 참여하지 못한 팀원들이 많이 생겨서 실질적으로 만나서 개발한 시간은 굉장히 적었다. 심지어 나는, 팀프로젝트 마지막 1주일동안 코로나에 걸리게 되어 최종 개발을 하면서 모두가 고생하는 시기에 일주일을 빠지게 되었고, 최종 발표까지 함께하지못했다. .. 아쉬웡 ㅠㅠ

🟣 CSS (Continue, Stop, Start)

💬 Continue

- 공유하는 문화를 가져가려고 하는 점
MC2프로젝트와 동일하게, 이번 팀프로젝트에서도 팀원들과 이슈를 공유하고 싶어했다. 그리고 이를 '회의록을 기록'하는 것으로 실천했다. 이렇게 글로 기록하는 문화는 MC1, MC2, MC3 모든 팀원들에게 좋은 영향을 줬다고 생각한다. 이렇게 내가 가진 장점을 다른 사람에게도 전해주고, 그들도 나로 인해서 좋은 영향을 받을 수 있는, 서로에게 도움이 되는 팀원이 항상 되고 싶다. 이 부분은 지치지 말고 꼭 마지막 프로젝트에서도 가져가자!

💬 Stop

- 지친 마음을 팀프로젝트까지 끌고가는 것
나의 지친 마음을 팀프로젝트를 진행하는 내내 끌고 갔던것이 굉장히 minus 였다. 이런 지친 마음 때문에 더 프로젝트에 몰두하지 못했고, 더 아쉬움이 진하게 남는 프로젝트가 됐던것 같다. 나의 개인적인 감정은 앞으로 팀 프로젝트로 끌고가지 않도록 해야한다. 그래야 나또한 내가 하고자하는 일에 대해서 더 애정도 생기고, 더 열심히 임무를 완수할 수 있다고 생각한다. 절대, 나의 개인적인 감정을 팀 내부로 가져가지 말자! 마인드 컨트롤 하는 방법을 다시 생각해보자.

- 질문하는데 두려워하는 것
이번 프로젝트에서는 이전 프로젝트와는 다르게, 특출나게 개발을 잘하는 누군가가 존재했다. 나는 프로젝트를 진행하면서 그 사람에게 질문하는 것을 두려워했다. 질문하는 것이 왜 두려웠을까? 그가 생각했을때, 너무 당연한 것에 대해서 질문하면 어쩌지..?하는 불안한 마음 때문이 아니었을까?... 이런 마음을 이겨내고, 질문을 많이하는 습관을 길러야한다고 생각한다. 물론, 내가 충분히 납득이 될만큼 찾아보고 왜 안되는지 명확하게 설명할 수 있을때 질문해야하는 것이 맞다고 생각하지만, 그 이후까지 너무 끙끙대고 쩔쩔매고 해결하지 못하고 있는것이 더 바보같다고 생각된다. 이번 프로젝트에서는 내가 그랬다... 충분히 찾아 봤을때, 내 머리로는 이해가 되지 않았는데, '그가 생각했을때 이게 별게 아니면?'하는 마음떄문에 제대로 질문하지못했다. 
사실 조직생활을 하다보면 나보다 잘하는 사람 천지일 것이다. 그 속에서 나는 질문을 해야만 내것으로 만들 수 있고, 성장할 수 있다고 생각된다. 나의 이런 나쁜 마음은 버리고, 잘 정리해서 잘 질문하는 방법에 대해서 더 고민해볼 필요가 있다고 생각된다.

💬 Start

- 깃허브 내부의 discussion을 사용하면서 기술적으로 조금 더 공유해보자.
지금 내가 공유하는 수준은 단지, 우리팀원들의 의견을 공유하고, 회의록을 통해서 기록하면서 공유하는 수준이었다. 하지만, 이제 깃허브 내부의 discussion을 조금 더 사용해보고, 더 적극적으로 기술적인 것에 대해서 공유해보면 어떨까? 여기서도 '다른사람 다 알거야'라는 마음보다는, 내가 몰랐으면 누군가는 또 모르지 않았을까? 하면서 공유해보면 어떨까 싶다. 이번 팀 프로젝트에서도 모두가 UIKit 이 처음이었던 만큼 (우디제외^^) 내가 몰랐던 것은 그 누구도 몰랐을 수 있다. 내가 notion에 작성하면서 공부한 내용들을 다음 팀프로젝트에서는 조금 더 적극적으로 팀원들과 함께!! 공유해보자! 더 풍성한 지식이 될 것 이라고 믿어 의심치 않는다.

- 팀원들에게 나의 상황을 조금 더 자세하게 공유해보자.
내가 어떤 부분에서 힘들었고, 어떤 부분이 잘 이해가 안되는지 명확하게 팀원들과 공유해보자. 이번 프로젝트에서는 사실 notification을 만들때, 내가 잘 이해하지 못해서 되게 오랜 시간 해당 task를 끌고 갔었다. 그때 팀원들은 이 task가 그렇게 오래가져갈 task는 아니라면서 한 번 피드백을 준 적이 있었다. 그럴때 나는 주눅이 들었지만, 이제는 주눅들지 말고 피드백을 듣기 이전에 내가 힘들었던 것에 대해서 조금 더 공유하면 어떨까 싶다. 앞서 말한 내용은 즉, 나 말고는 다른 팀원들은 이 task에 대해서 조금은 알고 있었다는 것이다. 만약 내가 이 문제에 대해서 자세히 팀원들과 공유했더라면, 더 긴 시간을 허비하진 않지 않았을까!? 
다음부터는 팀원들 사이에 모르는 것이 없게 해보자!

🟣 다음 팀프로젝트에서는 이런 것을 배우고 싶다.

 

- 기술 지식의 함양
특히 UIKit에 대해서 더 깊게 공부해보고 싶다. 이번에 아주 간단하게, collectionview를 다뤄봤는데, 필수 구현 메서드도 있고, custom해서 다양하게 사용될 수 있다는 것까지 알게 되었다. 다음 프로젝트에서는 Colelctionview에 대해서 더 자세히 파보고, 더 깊은 이해를 해보고싶다. 더불어서 UIKit의 동작방식, 메모리 관리법 등 더 깊은 공부와 이해를 위해 많으 ㄴ공부를 해보고 싶다!

- 코드리뷰 문화
더 적극적인 코드리뷰 문화를 가져보고 싶다. 팀으로 일하는 만큼, 남의 코드를 이해하고 질문을 던지는 방법중 가장 간단한 방법이 바로 코드리뷰가 아닌가 싶다. 내가 이번 프로젝트를 진행하면서도, 무서워하지 않고 남의 코드를 읽으면서 이해하지 못했던 부분에 적극적으로 리뷰를 달고, 또 내가 새롭게 알게됐던 내용에 대해서 리뷰를 적극적으로 달면서 팀원들과 소통했으면 어땠을까? 하는 생각을 해봤다. 다음 프로젝트에서는 코드리뷰를 적극적으로 하면서, 팀원의 코드 칭찬도 적극적으로, 질문도 적극적으로, 코드 개선점도 적극적으로 찾아나서보고 싶다.

- 다른사람들도 잘 이해할 수 있는 문서화 방법 찾기
다른 사람들도 잘 이해할 수 있는 다양한 문서를 만들어보고 싶다. 회의록 뿐만 아니라, 회고록, 나의 코드를 제대로 설명하는 PR, 내가 개발하면서 고민했던 것들에 대한 공유 등 다양한 문서화를 하고, 그 문서화를 잘하는 방식에 대해서 더 깊은 고민을 해보고 싶다. 개발자도, 글을 잘써야한다고 생각한다. 그래야만 내 코드를 다른사람에게 설득할 수 있고, 또 설명할 수 있기 때문이다!! 

 

---

마지막으로 우리팀 너무 고생많았다. 그리고 이렇게 친구같은 팀을 만나게 되어 너무 행복했다! 비록 코로나 이슈로 12월에 첫 단체사진을 찍게 되었지만 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ (아래 사진 12월임^^) 앞으로 서울에서도 자주 만났으면 좋겠다. 그리고 꼭, 이 팀원들을 현업에서 다시 만나고싶다.

다들 나 잊지마 ㅠㅠ 고마웠다ㅠㅠㅠㅠㅠㅠㅠㅠ  ❤️🥹