[Apple Developer Academy] 2번째 프로젝트 회고

2022.05.10 ~ 2022.06.20 

6주간 진행했던 애플 디벨로퍼 아카데미에서의 두번째 프로젝트가 끝났다.느낀것도, 배운점도 많았던 프로젝트이기에 회고를 작성해보려고 한다. 아래에서는 '두번째 프로젝트'라는 말 대신 애플 디벨로퍼 아카데미에서 사용하는 단어인 MC2 라고 칭하겠다. (Mini Challenge의 약자) 시작!!

 

---

 

 

🔵 차곡차곡

이번에 우리팀이 만든 '차곡차곡'앱은 "운전하는 도중에 기록을 편하게 하자" 라는 챌린지를 갖고 시작했다. 운전하면서 발견한 예쁜 드라이브 코스 (갑자기 발견한 꽃길 등)와 예상치 못한 장소를 발견했을 때, 자동차 핸들의 간단한 조작으로 위치를 차곡차곡 저장하는 앱이다. 

🚙 Github - https://github.com/DeveloperAcademy-POSTECH/chagokchagok

GitHub - DeveloperAcademy-POSTECH/chagokchagok: "차곡차곡" 쌓여가는 나만의 드라이브 기록 🚙

우리팀의 깃허브 링크이다. 사실 다듬어지지 않은, 그리고 완성되지 않은 앱이라 깃허브를 누가 본다는게 굉장히 민망하지만, 차차 개선시켜나갈 의향이 있어서 적어둔다. (나는 추후 있을 개인프로젝트 시간에 해당 앱을 개선시켜볼 생각이 있다.)

도대체 왜 이런앱이 나오게 되었고, 팀프로젝트를 진행하면서 어떤 과정이 있었길래 앱을 완성시키지 못했을까? 그리고 MC2 팀플에 대해서는 아쉬움만 남을까? 생각을 하다가, 차근차근 회고를 해보았다.

---

 

🔵 기획단계

우리는 '캠핑'이라는 대주제로 부터 시작했다. 우리의 생각의 흐름은 다음과 같다.

우리 팀은 캠핑으로 시작했지만, 캠핑을 솔루션 컨셉 아이디어로 가져가지 않은 이유가 있다. 바로 6명 중 캠핑을 평소에 즐기는 사람이 단 한 명밖에 없었기 때문이다. 6명 모두가 공감하지 못하는 주제는, 6명의 의견을 하나로 좁히는데 문제가 있고, 즐거운 프로젝트가 될 수 없다고 판단했다. 그래서 캠핑을 '왜'가는지에 집중했고, 그로부터 '해방감과 공간' 이라는 주제로 좁혀나갔다. 그렇게 결정된 우리의 솔루션 컨셉은 '운전 중에 느꼈던 순간과 위치를 기록하도록 도와주자'가 되었다.

 

💬  기획단계는 끝없는 미팅의 연속!!

살면서 이렇게 회의를 길게해본적이 있었던가. 진짜 끝나지 않는 미팅의 연속이었다. 나뿐만 아니라 애플 디벨로퍼 아카데미 멘티들 모두가 가장 힘든 시기가 아닐까 싶다. 6명 모두가 동의하는 의견을 도출해내는 방법도 찾아야하고, 혹시 맘에 들지 않아도 본인 스스로 해당 아이디어와 내 생각 사이에서 타협점을 찾아야하기 때문이다.

우리 팀은 여섯명이 동의하는 관심분야를 선택하기 위해서 길게 회의를 진행했다. 적어도 아이디어를 선정하는 부분에 대해서는 만장일치가 되어야 넘어가겠다는 마인드였다.

이 과정에서 우리팀이 가장 좋았고, 잘했다고 생각되는 부분은 '투표하지 않은 사람의 의견을 들어보기'였다. 의견을 결정할 때 항상 '투표나 다수결'로 먼저 의사를 확인하게 된다. 이때 1:5가 나오더라도, 한명의 의견까지 분명하게 듣고 넘어갔다. 사실상 다수결이 아니었던 ,, 그냥 의견을 듣기위한 실명 투표 였을수도?

만약 2/4 로 표가 나뉘었다면, 다수가 선택한 아이디어에 대해서 나머지 두명에게 '왜 이 의견에 투표하지 않았는가?'를 물었다. 투표하지 않은 이유에 대해서 논리적으로 설명해 나가고, 다수의 의견이 반영된 아이디어에 문제점이 있다면 정확하게 해결하고 넘어갈 수 있었다. 우리팀 모두가 힘들지만 끝없이 대화하고 경청하려고 노력해준 것에 대해서 너무너무 감사하다!

 

💬 기획단계에서의 회고 

애플 디벨로퍼 아카데미의 정책상, 프로젝트르 진행하는 세부사항은 공개하지 못하게 되어있다. 애플 디벨로퍼 아카데미의 교육 방식은 전적으로 CBL 방식인데, 이 방식대로 진행했기 때문에 러프하게, 큼지막하게 작성하면서 회고해보자.

우리 팀은 모든 회의와 관련된 내용을 노션에다가 정리했다. 정리광인 내가 주도적으로 회의록을 작성하고 싶었으나, 팀원들도 회의록을 작성하는 연습을 하고싶다는 의견을 적극적으로 받아들여 다같이 회의록을 작성했다.

https://nifty-manx-a51.notion.site/Mini-Challenge-2-52a1fe9608c44d28a5d1d4cad6300d50

Mini Challenge 2

 

우리 팀은 회의를 그닥 길게한 팀은 아니었다. (다른 팀들에 비해!) 모두가 효율을 추구했기 때문이다. 하지만 이게 나중에 큰 문제로 떠올랐다. 효율만을 추구하여 알맹이를 제대로 챙기지 못했다는 생각이 들었다. 당연하게도, '소통의 오류'가 발생했고 이는 개발단계를 들어갔을 때도 서로 다른 것을 만들고 있거나, 같은 view를 만들고 있는 등 큰 문제가 되었다.

왜 이런 문제가 생겼을까? 내가 브릿지(쉬는)기간에 혼자 곰곰히 생각하여 찾아낸 문제는 다음과 같다.

• 팀원 내부에서 정한 앱의 기능, UX 디자인 사항, 개발 방식 등에 대해서 구체적으로 문서화하지 않았다. 물론 팀노션으로 모든 내용을 관리하긴 했는데, 회의록을 작성하고 자료를 공유하는 것에 익숙하지 않았기에 제대로된 공유가 이루어지지 않았다.
• 시간이 짧다고 좋은 회의는 아닌데, 충분한 의견을 나누지 않고 회의를 마무리했다. 예를들어 "이건 개발단계로 넘어가서 그때봐서 정하죠!" 하고 넘어간 내용이 너무 많았다. 하지만 우리가 이렇게 결정한데에는 이유도 있긴 했다. (Tech position이 1명이었던 팀) 이유가 있었지만, 이렇게 하게됨으로써, 어떤걸 정하고 넘어갔는지, 정하지 않고 넘어갔는지에 대해서 문서화되어있지 않았기 때문에 개발자들 사이에서도 소통의 오류가 발생했다.
• 제대로된 회의 norms가 없었다. 회의 규칙, 그리고 팀 규칙에 대해서 충분한 시간을 가졌음에도 불구하고, 우리팀은 "이거 그냥 추상적인것만 적어놓고 넘어가죠" 하고 넘어갔었다. 하지만 '의견 충돌 시 어떻게 해결해야하는지', '본인의 의견은 어떤 방식으로 설득해야하는지'등에 대한 구체적인 norm이 있었다면, 조금 더 논리적이고 알맹이가 가득 찬 회의가 진행되지 않았을까.

물론 이렇게 어렵고 힘든점도 많았지만 우리팀이 계속해서 가져가야할 좋은 점도 많았다. 

• 우선 팀원들에게 '설득하는 방법'에 대해서 배웠다. 우리 팀원들의 가장 큰 장점은 '논리적으로 본인의 의견을 정확하게 전달하는 것'이었다. "사람에 대한 반대가 아니라, 의견에 대한 반대"임을 정확하게 인지하고 있었다. 모두가 하나의 의견에 대해서 반대되는 의견을 이야기할 때 '반대하는 이유 + 이것을 보완할 방법'에 대해서 함께 이야기를 나눴다. 이런 점은 '아니 근데,,'라고 말을 시작하는 내 안좋은 습관을 바꿀 수 있게 된, 그리고 바꾸려고 노력하게 된 계기였다.
• 우리 페이스대로, 조급해하지 않는 것에 대해서 배웠다. 내 성격 중 가장 큰 단점이 바로 조급해한다는 것이다. (뒤에서 언급하겠지만) 우리팀은 개발 담당자가 부족해서 조급한 마음이 들었다. 그럴때마다 팀원들이 '급할 필요없다, 우리페이스대로, 우리가 딱 할 수 있는 만큼만'을 강조해주었다. 이런 말들이 나를 조금 컨트롤할 수 있도록 도와주었다. 실제로 이런 것을 회의를 하면서 많이 반영했다. 개발이 되지 않을 것 같은 것, 우리의 기술스택에 비해 너무 고급 기술을 필요로하는 것, 시간내로 끝내지 못할 것 같은것은 모두 쳐냈고, scope을 우리의 역량에 맞춰서 잘 조절해 나가려고 노력했다.

 

🔵 디자인 단계

차곡차곡의 최종 디자인은 아래와 같다.

 

iPhone App UI

CarPlay UI

우리가 UX 디자인을 하면서 가장 중요하게 생각한 부분은 다음과 같다.

• 무슨 앱인지 한눈에 알아보게끔 만들 것
• 유저의 터치 한번으로 모든 메뉴에 접근이 가능할 것

이 조건을 충족하기 위해서 우리는 과감하게 tabbar를 삭제했고, 위처럼 간단한 UI가 탄생했다. 사실 가장 보통의 사람들이 생각하는 tabbar가 달린 UI도 처음에는 생각했었지만, 앱이 가진 기능이 '드라이브'기능과 '모아놓은 코스나 핀 보기' 두가지의 기능 밖에 없기 때문에 tabbar가 적절하지 않다고 판단했다. HIG에서 Tabbar의 가장 이상적인 수는 3~5개라고 했는데, 우리는 두개밖에 되지 않았기 때문에 tabbar가 필요없다고 결론내렸다. 

내가 생각했을 때는, UX 측면에서 좋은 결과물이라고 생각된다. 우선 우리 앱에서는 유저입장에서 '어 이게 버튼인가? 이거누르면되나?'하는 애매모호함은 없었다. 그리고 앱에 진입하면 '아 드라이브하고, 기록한 리스트를 보는앱이구나!'가 한눈에 들어오고 리스트 내부에서도 '내핀, 내코스, 즐겨찾기'에 대한 필터링을 추가적으로 하지 않고 메인 화면에서 바로바로 진입할 수 있다는 것이 depth가 하나 줄어들어서 더 좋은 사용자 경험을 제공한다고 생각한다.

물론 아쉬운 점도 존재한다. 바로 "UX 라이팅" 이다. 우리는 이 앱에 대해서 가장 잘 알고 있는 사람들로써, '수정 여부' , '내 코스와 내 핀이 어떤 식으로 구별이되는지'에 대해서 매우 잘 알고 있다. 우리가 알고있다고 유저도 당연히 알거라고 생각했던 것이 큰 실수였다. 유저테스트를 진행하는데 '내핀과 내코스'를 구별하지 못하는 일이 발생하고, 왜 수정이필요하죠?라는 질문이 들어오기도 했다. 제대로된 앱 설명이 이루어지지 않았고, 애매모호한 UX라이팅이 원인이라고 생각했다.

최근 추가된 드라이브에 왜 날짜로 뜨는지도 이해하지 못했다. 차곡차곡은 카플레이와 연결된 상태에서 장소와 위치를 기록하기 때문에 임시로 '최근 추가된 드라이브'에 저장되고, 이후에 사용자가 직접 수정해줘야하는 구조였다. 이런 것을 사용자가 잘 이해하지 못해서, '앱이 어렵다'라는 평이 많았다.

이를 해결하기 위해서는, 온보딩 페이지가 있어야 한다고 생각한다.  사용자 입장에서 왜 카플레이가 사용되어야하는지?에 대해 이해를 잘 못하는 상황이 었고, 핀과 코스를 구별하는 이유도 몰랐기 때문에 이를 더 쉽게 설명할 수 있는 UX라이팅과, 온보딩 페이지가 꼭 필요해보였다.

 

💬  디자인 단계에서의 회고

우리팀은 Tech 1명, Domain 2명, Design 3명으로 구성된 팀이다. 디자이너들은 디자이너로서의 확고한 성장을 원했고, tech 개발자는 확고한 개발역량 함양을 원했다. 각자 다른 목표를 가졌기 때문에 우리팀은 초반부터 (개발팀/디자인팀) 두팀으로 쪼개지게 되었다. 이 과정에서 아래와 같은 문제점들이 발생했다.

• 팀 내부에서 나눠서 회의를 진행했기 때문에 (디자인팀 / 개발팀) 두 팀 사이에서의 소통의 오류가 발생했고, 디자이너들은 개발사항을 잘 알지 못했고, 개발자들은 매번 바뀌는 패딩값, 디자인사항으로 인해서 불만을 토로했다.
• 디자이너 세 명의 생각에 갇혀 빠른 의사결정을 하지 못했다. 개발하는 사람들도 더이상 디자인에 참여하고싶지 않다고 선을 그었던 것이 문제였다. 조금 더 다양한 시각으로 앱을 바라보고, 다양한 시각에서의 해결책을 도출해냈어야 했다. 그렇지 못하고, 디자이너 세명이서 끝없는 토론으로 디자인 사항을 모두 결정했기 때문에 디자인 사항들이 너무 늦어지지 않았나 생각된다.
• 나는 tech 한명이 팀에서, 내가 tech를 리드해야 했기 때문에 많은 부담감으로 인해 디자인에서 빨리 빠져나와 개발을 하길 원했다. 이 과정에서 제대로 정의되지 않은 사항들을 개발하게 되니까, 개발 속도까지 더 더뎌진것 같다.

우리팀에서 잘한점도 있다.

• 디자이너들의 피드백 요청이 있을 때, 두려워하지 않고 적극적으로 피드백에 응했다. '내가 디자인 감각이없어서..'하는 주눅드는 일이 없었고, 모두 다 솔직하게 본인의 의견, 그리고 본인의 시각에서 정확한 의사를 전달했다.

사실 내가 디자인 과정에 많이 참여하지 않아서 이정도만 작성할 수 있을 것 같다. 디자인/개발 선을 긋고 참여하지 않은 점에 대해서도 많은 후회가 남고, 많은 것을 배울 기회를 내가 스스로 막은 것 같으 느낌이 든다.

 

🔵 개발 단계

우리팀은 처음으로 CarPlay라는 신기한 솔루션을 선택했다. 멘토들도 거의 접해보지 못했던 개발 내용이라, 많이 힘들거라고는 예상했다. 더불어,, 인터넷에도 정말 정말 자료가 없다... 그래도 어찌 저찌 다양한 reference를 참고해서 아래와 같은 화면을 만드는데 까지는 성공했다.

물론 가장 간단한 탬플릿을 가져다가 썼기 때문에, 왼쪽 위에있는 버튼하나 있는 UI가 전부이다. ㅎㅎㅎㅎㅎ 이거 만드는데도 3일이 걸렸다.... 어려워 ㅠㅠ 

그리고 CarPlay를 앱으로 개발하기 위해선, 애플의 승인이 필요하다. 앱을 기획할때 계속해서 승인요청을 넣었는데,,, 프로젝트가 끝나고 이틀정도 뒤에 승인을 받았다... 호뤠이...👾 근데 좀만 빨리해주지 ^^

승인을 받은게 아까워서라도 카플레이 개발은 조금더 끌고 가볼까한다. 새로운 지식을 배울 수 있음에 감사하다!

 

💬  개발 단계에서의 회고

우리팀의 개발 리드는 대부분 내가 하게 되었다. (한명의 Tech 지원자가 나였기 때문이다) 그래서 내가 세운 목표는 아래 두가지였다.

• Github 활용해서 협업하기
• 개발 역량 함양하기 (UIKit 다뤄보기)

나도 앱개발은 거의 초보 수준이었기 때문에 기획기간에 틈틈히 깃허브와 개발관련한 공부를 하면서 시간을 보냈다. '내가 또 언제 리드개발자를 해보겠어'라는 생각으로 아주 호기롭게 개발을 시작했지만, 문제는 너무 많았다.

우선, github 사용법의 중요성을 팀원들에게 잘 전달해야했다. 내가 30~1시간정도 시간을 내어 깃허브 사용법에 대해서 미니세션(?)을 열어 팀원들에게 설명해주긴 했지만, 그 중요성이 팀원들에게 잘 전달되지 않았던 것 같다. 아마 내가 전달할 때 너무 급하게, 빠르게 전달하려고 하고 핵심을 잘 전달하지 않았기 때문이라고 생각되었다.

그래서 깃허브로 협업하는 과정에서 많은 문제가 생겼다.

https://didu-story.tistory.com/277?category=1022250 

[Github] xcode 프로젝트 - xcuserdata, xshareddata 파일 conflict 해결

더불어 나는 내가 '커밋 규칙과 코드 컨벤션'을 지켜서 올리면, 당연하게 팀원들이 따라서 형식을 맞출줄 알았다. 이것도 나의 큰 실수였다. 무조건 협업을 시작하기 전에 코드 컨벤션, 커밋 규칙, 브랜치규칙, 파일 디렉토리구조를 미리 정하고 시작했어야하는데 그렇게 하지 못한점이 너무 아쉬웠다.

다음에 개발을 진행하게 된다면, 앞으로 어떻게 진행해야 하는지 정리해둔 글이 있는데 여기서 확인해보면 될 것 같다.

https://didu-story.tistory.com/278?category=1022250 

[Github] Github로 협업하는 방법 - repo 생성 시 할 일 (feat. 두번째 프로젝트 회고)

 

이번 프로젝트를 진행하면서 UIKit을 새로 배워보고 싶었다. 하지만 이번에 우리팀에 UIKit을 할 수 있는 코더가 없었기 때문에 UIkit을 사용하지 못하고, 그나마 익숙했던 swiftUI를 이용하게 되었다. 이 또한 조금 아쉬운 점으로 남았다. 물론 SwiftUI가 완벽하지도, 잘하지도 않지만, 새로운 지식을 배워보고싶었던 나의 목표가 없어진 기분이랄까? 

하지만 이때 나는 이런것만 탓하고 앉아있으면 안됐다. 나보다 잘하는사람 밑에서 언제나 따라가면서 배우는 위치에만 있을 수 없지 않나??스스로 SwiftUI에서 어떤 역량을 함양할 수 있는지 찾아보면서 더 공부했어야 했다. 팀을 이끌어야한다는 부담감과, 다양한 깃허브 이슈 등을 해결하는데 급급해서 나의 공부를 많이 놓친것에 대해서 후회한다.

또 깃허브 이슈가 생겼을 때 팀원들과 해당 이슈를 공유하고 함께 해결하려고 노력했어야했다. 너무 나 혼자서만 매달려서 이슈를 해결하려고 하다보니, 사흘을 쌩으로 날려버리고 개발공부는 하나도 하지 못하는 사태가 되었다. 이상태가 되니 나또한 지치게되었던 것 같다.

하지만 CarPlay라는 새로운 것에 대해서 배울 수 있었다. CarPlay가 UIKit 기반이라, 조금은 어떻게 돌아가는지 보면서 공부해볼 수는 있었다. 어려운 상황 속에서도 새로운 것에 도전하도록 팀원들도 힘을 북돋아 주었고, 믿어준 팀원들에게 너무 감사하다!

 

🟣 다음 팀프로젝트에서 꼭 해보고 싶은 것

• Daily Scrum
• Github 로 협업하기 (코드리뷰하고 코드 컨벤션, 커밋규칙, 브랜치 규칙 정하기)
• Team Norms 정확하게 정하고 가기
• 디자인에 주도적으로 참여하기

 

🟣 내가 계속해서 가져가고 (Continue), 개선해야할 (Stop) 자세

💬 Continue

- 공유와 기록하는 문화를 만들었다는점
팀원들과 시작하기 전부터, 내가 노션에 모든 것을 공유하고 협업할 때 공유하고 서로 리뷰해주는 문화가 얼마나 중요한지 항상 강조했다. 이러한 부분이 우리 팀의 성장에 조금 더 기여한 것 같다. 기획 단계에서 앞으로 돌아갈 일이 생기면, 회의록을 다시 보고, 우리가 왜 이런 아이디어까지 도출하게 됐는지 명확하게 짚고 넘어 갈 수 있었다.

https://nifty-manx-a51.notion.site/Mini-Challenge-2-52a1fe9608c44d28a5d1d4cad6300d50

Mini Challenge 2

위는 우리 팀의 노션이다. 개발단계로 진입하면서 깃허브를 사용해서 협업했기 때문에 정확하게 적힌 내용이 없을 수 있지만 나름 끝까지 책임지고 문화를 전파하려고 노력했다는 점이 나 스스로도 뿌듯하다.

- 끝까지 문제를 해결하려는 자세
깃허브에서 문제가 생겼을 때도, 힘쓰지 않고 문제를 해결하는 방법이 많았다. repo를 삭제했다가 다시만든다거나, 다양한 쉬운 방법이 있었지만, 이렇게 하게 된다면, 아무런 성장도 하지 못하고 무의미해질 것 이라는 생각이 들었다. 그래서 하루, 이틀이 지나도 포기하지 않고 문제를 해결하려고 끝까지 매달렸던 것 같다. 이렇게 문제를 해결하니까, 어떤 곳에서 문제가 생겼고, 어디서부터 잘못됐는지 원인을 정확하게 파악할 수 있었다. 다음부터는 더이상 이러한 실수를 하지 않을 수 있게 되었고, 더이상 깃허브의 그 어떠한 conflict가 무섭지 않게 되었다!

 

💬 Stop

- 팀원들과 업무공유를 제대로 하지 않은 점
문제를 해결하는데 시간을 많이 쏟은 만큼, 굳이 팀원들에게 공유해야하나?라는 생각을 갖고있었던 것도 사실이다. 하지만 이러한 모든 상황을 팀원들에게 공유하고, 서로 어떤식으로 작업을 진행했는지 공유를 했더라면, 문제 상황에 대해서도 3일이라는 긴 시간을 쏟지 않았을 수도 있다. 팀원들을 조금 더 믿고 의지하면서 개발을 진행했어야 하는데, 그러지 못해서 혼자끙끙 해결하려고 했던 점이 후회스럽다.

- 발산하면서 생각을 정리하지 않고 말한 점
회의하다가 발산하면서 의견을 막 제시했던 점을 고쳐야한다. 또 내가 말이 조금 빠르기 때문에 생각이 정리되지 않은 상태에서 의사전달이 정확하지 않았던 때가 많았다. 팀원들에게 가장 많이 배웠던 점이, 자신의 생각을 논리적으로 정리한 후 '두괄식'으로 말한다는 점이었는데, 이 배운점을 적용시키면서 내 단점을 조금 더 극복하려고 노력하면서 MC3를 진행해야겠다!