내가 소속한 동아리인 GDSC에서 새해기념 연합 해커톤에 참여하게 되었다.
작년에 참여한 새싹톤의 경우에는 기획부터 서비스 1차 구현,2차구현 등 기간이 한달 이상으로 넉넉하기도 했고 같은 GDSC 사람들이여서 짧은 기간내에 무언가 하나를 뽑아내야하는"해커톤" 이라기 보다 "단기 프로젝트" 느낌이 강했다.
물론 실력있는분들에게 멘토링을 받고 다른 실력있는 기획,디자인,안드,백엔드분들과 정해진 기간동안 하나의 서비스를 만들어 냇다라는것 자체만으로 충분히 의미가 있다고 생각한다.
새싹톤의 경우, 한달이상의 시간이 있었고, 최종결과이후 약간의 나태해짐과 바로 JMT개발 등으로 인해 제대로된 회고를 남기지 못했는데 이번에는 여운을 길게 가져가보고자 회고를 작성해보려 한다.
본격적인 시작에 앞서
사실, 본격적으로 시작하기 전날에 해커톤이 처음이라 오는 긴장감+ 같은 팀원(특히나 같은 iOS와 무엇을 해본적이 없었기 때문에..)에게 민폐만 끼치면 어떡하지 + 내가 제대로 아는게 맞나.. 등의 걱정으로 인하여 전날 저녁에 부랴부랴 준비를 해가게 되었다.
물론.... 해커톤에 준비할게 뭐가 있나... 라는생각이 들었지만, 이전에 내가 했던 프로젝트를 한번씩 보면서 내가 이전에 어떤식으로 view를 구성했는지를 쭉 살펴보고 관련되거나 비슷한 디자인이 나오게 될 경우 바로 view를 뜯어다 붙이기 위해 전체를 훑었다.
이후, 자기전까지 시간이 약간남아 내가 생각했을때 웬만하면 사용될것 같은 디자인 구조인 Compositional layout을 작성해서 프로젝트를 하나 생성해 두었다.
이전 새싹톤과, 다른 해커톤을 참여해본적 있는 분들의 경험을 종합해 보았을 때 이런식으로 비슷한 view를 컴포넌트화 하는게 확실히 중요한것을 알게 되었기에 해 둔 작업이다
해커톤 당일
시작부터 멍청했다.
어찌어찌 다시 대강당을 찾아 자리에 착석하게 되었다.
자리에서 어색한 인사 후 본격적인 활동을 위해 본관으로 이동했다.
기획
해커톤의 주제는 솔루션 챌린지에서 한번씩 본 SDGS, 사랑, 다짐 이였고, 이를 녹이기 위해 서로 생각을 정리하는 시간을 가지게 되었고 서로의 생각을 노션에 작성하기로 했다.
팀원분들 전부, 해커톤은 처음이였지만 다들 GDSC 소속인 만큼 솔루션 챌린지를 진행중이거나 경험해본적이 있어서 아이디어 구상에는 많은 방법들이 나오게 되었다.
다양한 의견들이 있었던 와중에, 팀원중 한분이 이전에 하셧던 프로젝트에서 1:1 혹은 다대다 인원을 매칭하는 알고리즘을 작성해본적이 있고 이를 활용하여 서비스를 만들면 좋을것같다고 의견을 주셧고 우리는 모두 수긍했다.
이를 확장시키기 위해 "새해 다짐을 하기를 원하는 사람들을 위하여 1:1로 비슷한 목표를 가진 사람들을 위한 서비스 + 단체로 하기를 원하는 사람들을 위한 서비스" 를 기획했다.
주제 확정
우리의 서비스가 차별화된 점은 1:1 매칭이 가능하다는 점과 목표를 달성했을 경우 주어지는 뱃지를 통한 Benefit이 있다는 점이였다.
이렇게 주제가 확정되고 세부적인 기능들과 관련된 카테고리들에 대해서 정해야 했다.
각자 본인이 생각하기에 알맞은 방법과, flow를 그리기 시작했는데 전체적인 flow에서 의견이 맞지 않았다.
그 의견들을 다 작성하기에는...시간이 상당히 걸리기에 요약하자면
클라이언트 입장에서는 서비스측면에서 사용자에게 이런 감동을 안겨줄 수 있다~ 라는 입장이였고
백엔드 입장에서는 logic적인 측면에서 기능을 추가하고 만드는 입장에서 말하느라 생기는 작은 오해였다.
이런 사소한 갈등이 있고 난 후, 같은 iOS를 하시는분이 피그마를 켜서 빠르게 작업을 해주셧다(감동)
나도 빠른 flow완성을위해 이전에 피그마에서 했던 디자인들을 최대한 레퍼런스로 활용했고 서로의 레퍼런스를 보며 나름 빠르게 작업이 진행되었다
(물론 같은 ios팀원님이 손이 굉장히 빠르셔서 가능했던일.... 다시생각해도 감사합니다)
여기까지 마쳣을때 딱 7시였고 팀원과 함께 저녁을 먹으러 가게 되었다.
개발시작
저녁을 먹으면서 iOS분과 어떤것으로 개발스택을 채택할것인지에 이야기를 나누었는데,,,,
팀원분은 코드베이스로 쭉 코딩을 해오셧고 SwiftUI도 현재 공부중이셔서 이번에 아얘 SwiftUI로 해커톤에 참여하려 했다고말한다.
나는 SwiftUI를 경험해보기만 했지 짧은 시간내에 SwiftUI로 만들기는 실력이 턱없이 부족했다. 물론, 겨우겨우 만들려면 만들수는 있겠지만 경험이나 만들어 내는 속도가 너무 느릴것이라 생각되어 합의하에 UIkit으로 만들기로 하였고, 페이지는 나눠서 나는 스토리보드, 같은팀원분은 코드베이스로 만들기로 하였다.
1. 첫번째 이슈
스토리보드로 작업해본적이 거의 없다는 팀원분을 위해 탭바 분기를 위해 Storyboard Referance 를 나누게 되었고 기본 분기만 한 상태로 작업 환경을 구성해 Merge를 합쳣습니다.
이후 페이지를 구성하면서, 저는 팀 매칭이 된 이후 부분을 만들기 위해 메인페이지에서 팀매칭 이후 부분으로 바로 넘어갈 수 있는 버튼을 눌러 화면상의 Stack을 쌓으려 했는데... 화면에 PUSH가 되지 않는 이슈가 생겻습니다.
let storyboard = UIStoryboard(name: "Group", bundle: nil)
guard let groupAuthVC = storyboard.instantiateViewController(withIdentifier: "SelectGoalViewController") as? SelectGoalViewController else {
print("SelectGoalViewController를 찾을 수 없습니다.")
return
}
self.navigationController?.pushViewController(groupAuthVC, animated: true)
print(1)
코드를 아무리 뜯어보고, 아무리 segueWay가 끊어진걸 확인해봐도 멀쩡했다. 로그의 1 도 잘 찍혀나오는데.....
오랜만의 UIKit이여서 상당히 많이 당황스러웟고 정신이 너무 없었다.(마음이 급해서 실제로 이 push 문제를 해결하는데 한시간을 쏟았다)
심지어 같은 iOS분도 코드로 작업을 했는데 화면 Push가 안된다고 하셔서 더 정신이 없었다.
마음이 급해져 화면을 우선 segue로 연결한 후 해당 문제는 다음으로 넘기고 간단한 View와 Button만 있는 부분을 우선 작업하며 머릿속으로 무엇이 잘못되었나를 곰곰히 생각했다.
그리고 돌아와 다시 스토리보드를 살펴보니, 맨 처음 Tabbar로 분기처리 한 후 navigationController으로 VC가 시작해야하는데 Group부터 스토리보드 시작점을 잡아 생긴 문제였다.
옛날옛적 처음 개발을 시작할 때 겪었던 이슈였는데 정말 오랜만에 초기 세팅을 잡다보니 생긴 문제였다. 정신을 차리자
2. 두번째 이슈
인증된 사진을 등록하기 위한 view를 그리다가 생긴 문제였다. view를 그리기 위해 이전에 JMT에서 사용한 코드를 그대로 가져다 쓰려고 했다.
그러나 이전에 사용한 컬렉션뷰 코드를 전부 끌어다가 가져왔음에도.. 화면에 stackView가 50만 그려지는등 원하는대로 UI가 그려지지 않았다. 이 문제는 방금 발생한 첫번째 이슈같은 간단한 문제가 아닌 분명 부모뷰의 크기를 가져오는데서 생기는 문제라고 생각을 했다.
코드를 하나씩 뜯어보며 크기를 조절하는 방법을 택했고, Lookin 라이브러리를 사용하면서 현재 View가 부모뷰의 크기를 잘 따라가는지 하나씩 살펴보았다. 노가다 반복작업을 진행해보니 회색선 안에 카메라와 숫자 label을 stack뷰로 묶었고, 해당 뷰를 스크롤 뷰 위에 올린 상태의 뷰를 containerView로 감싼 후, 사진이 늘어날때마다 containerView가 늘어나게 코드를 수정했는데 containerView가 상위view의 높이를 참조하고 있어서 생긴 문제였다.
해당 문제를 해결하는데에도 약 두시간 정도가 소요되었다.
3. 세번째 이슈
페이지를 계속 그려나가고 일정 페이지가 그려지는 대로(생각보다 기능이 들어간 부분이 많아서 사실상 한 페이지가 그려질때마다) Merge를 하였고, 디테일한 디자인을 그려나가니 시간이 3시쯤 되었다. 이때까지 페이지를 약 45%정도 그렸고 이쯤되니 백엔드와 연결될 부분이 명확하게 있어야 했다. 하지만 백엔드 분들에게 해당 부분의 서버부분이 준비가 되었는지 물었을때는 API 명세서도 제대로 설계가 되지 못했다. 지연되는 이유에 대해서 물었더니 서버 배포할 도메인을 찾는 와중에 오류가 많이나서 그랬다고 하셧다. 일단 페이지 UI를 먼저 그린 후 서버값을 불러오려 했지만 완성까지 시간이 빠듯할것 같아 일단 화면중에 보이는 간단한 CRUD만 빠르게 배포를 요청드렸다.
이후, 클라이언트는 서버 배포가 되지않을 최악의 경우를 고려해서 일단 Label을 보여 주는 목업 디자인으로 완성을 하는쪽으로 가닥을 잡았다.
이후... 시뮬레이터와 실기기 빌드 속도가 정말 속터지게 느리길래 iOS DeviceSupport 의 파일들을 삭제했더니
모든 스토리보드가 까매졋다거나 (물론 이 문제는 맥북을 완전 종료 후 켜면 해결된다)
껏다 켜니까 주최측에서 제공한 와이파이를 맥북이 찾지를 못해서 남은 5시간을 핫스팟으로 연결해서 사용한다거나
Rebase를 강제로 해버려서 이전 기록들과 함께 합쳐진다거나 ( 심지어 rebase 문제라고 추측할 뿐 정확한 답은 아니다)
스토리보드 특성상 merge를 하고나서 빨간색으로 파일이 사라져 있는 문제등 크고작은 사소한 문제가 있었지만....
어쨋든 약 20시간동안 정말로 몰입을 해서 하나의 서비스를 만들게 되었다는 점에서 굉장히 만족스러웟다
느낀점
1. 소통은 비용을 줄여준다.
iOS를 맨 처음 시작할 때, 기획을 너무 간략하게만 잡아 MVP만을 목적으로 공부를 시작하다가 보기좋게 프로젝트가 엎어졌던적이 있었다. 그때 느꼇던 점은 "기획회의는 최대한 자세히 할 수록 좋다" 라는 점이였다.
이 느낀점을 바탕으로, 다른 프로젝트나 혼자서 토이프로젝트를 진행할 때 세부적인 부분을 다 정했으면 도저히 구현이 불가능하다고 생각하거나 기타 심각한 오류가 있지 않는이상 큰 틀의 기획은 변경하지 않는것을 우선으로 하는 가설을 세우고 그에 맞춰 개발해왔다.그리고 이번 해커톤을 진행하면서, 해당하는 가설이 나름 증명된것같아 다행이다.
다른팀과 비교했을 때, 빠른팀은 기획이 1시간여 만에 끝난팀도 있고 대부분 2시간 이내로 걸린것 같았다. 하지만 우리팀은 약 4시간정도에 걸쳐 기획회의를 하고(피그마로 직접 그려가며 플로우를 추가하는것까지하면 5시간) 이후 개발을 시작했다.
개발시작이 다른팀에 비해 많이 늦어진 감이 있지만, 한번 방향이 정해지고 나니 이후 같은 기획에 대해 의문을 품는 경우가 없었고 전체적인 flow에 의문이 가는 부분도 없었다. 물론, 우리가 놓친것일수도 있지만 적어도 우리가 필수로 생각하는 기술인 1:1 매칭과 다대다 매칭 부분을 완성하고 백엔드도 이에맞춰 테이블 설계 및 DB작업을 할 수 있어서 ~~작업 이후에 ~~ 작업으로 하면 되나요? 라고 되묻는 부분도 없었기에 개발 시간을 단축할 수 있었다고 생각한다.
그리고 소통이 비용을 줄이는데 가장 큰 몫을 하는것은 역시나 모든 내용을 문서화 하는것이 제일 중요한것 같다.
2. 기획의 절감 : 얼만큼 투자해야 하는가?
주제가 주어진것에 맞추어야 하는만큼, 우리는 얼만큼의 서비스의 볼륨을 가져갈지에 대해 생각이 필요했다.
당장 매칭서비스가 있으려면 이에따라 매칭된 인원끼리 채팅을 할 수 있어야 할텐데, 채팅을 짧은시간내에 구현하기에는 어려워 보였고 이는 과감히 카카오톡 오픈채팅을 딥링크로 연결하는것으로 생략했다. 또한, '사용자가 정말로 원하는 기능은 무엇이고 이 앱을 사용해야 하는 이유는 무엇인가?' 라고 물었을때 우리의 서비스는 1:1 매칭이 가장 주력 메뉴였다. 이로인해, 모든 기획은 1:1 기능을 우선으로 생각하며 가지치기가 되었고 결국에는 우리팀이 생각했을때 가장 최고의 기능들만 남게 되었다.
당연한 이야기이지만, 우리가 생각했을때 놓친부분과 잘못 생각한 부분이 분명히 있겠지만 기획에서 꼼꼼히 가져가려는 우리의 팀원들을 보며 많은것을 배웟다.
3. 협업은 아름답다
"사진 등록하는부분 컴포넌트화 해주세요" 이번 해커톤에서 가장 충격적인 말 이였다.
'컴포넌트화.....? 단위단위로 끊어달라는건가.....? 아니면 하나하나 다 만들어달라는건가....? 엥 컴포넌트는 피그마에서나 쓰는거 아니였어....?'
같은 iOS분의 말을듣고 2초간 많은 생각이 들었다. 같은 iOS와 작업을 해본적이 없어 코드 컨벤션이나 다른 작업 스타일을 맞춰본적이 없었기 때문에 컴포넌트화가 무엇인지 되질문했고 함수로 만들어서 다른데서 사용할수 있게 만들어달라 라는 말을 뜻한다고 말씀해 주셧다.
생각해보면, 이전에는 하나 기능이나 view를 만들고 나면, 아무생각없이 같은 코드를 반복해서 작성했고 코드의 간결성과 재활용성은 전혀 신경쓰지 않았다. 결론적으로 이 코드는 내가 다시 재활용해서 사용하기는 했지만, 코드 스타일과 아키텍쳐 등 왜 구조나 좋은 코드에 대해서 항상 고민하고 코드리뷰와 SwiftLint 를 사용하는지에 대한 당위성을 알게 되었다.
또한, 기능단위 커밋만 해서 커밋로그도 당당하게 풀어썻던 나는 stylr,feat 등 커밋도 자세하게 나누시는것이 습관화되어있으신것을 보고 협업과 코드리뷰등을 하면서 나를 반성할 필요가 있음을 분명히 느꼇다.
4.나는 할 수 있는 사람이였다.
거창한 내용은 아니지만 시작할때 장난으로 "아 벌써 졸린데ㅋㅋ" 라고 장난스레 말했고 새벽 4시 넘어가면 꾸벅꾸벅 졸아버릴 줄 알았다.
하지만 모든 시간이 끝날때까지 정말 풀로 집중을 했고 밤을새서 약간 피곤한것 이외에는 졸리지도 않았다. 살면서 손에 꼽을정도로 없는 경험이였는데 정말 나는 몰입할 수 있는사람인것을 알게 되었고 이렇게 해본적이 있으니 앞으로도 할 수 있을것이라는 자그마한 용기를 얻게 되었다.
앞으로 생각해볼점
써보지 않은 기술에 대한 두려움을 없애자. SwiftUI를 사용하면서, 코드베이스로 짜보면서 아주아주 깊게 파보아야 겟다.
해커톤은 내가 부족한 점을 빠르게 알기위한 좋은수단이다. 그러나 깊은 공부를 하기에는 좋은 수단은 아니다.
내가 알고있는 지식을 빠르게 사용할 수 있도록, "어떻게든 되게 할 수 있도록" 태도를 길러봐야겟다.
'기타' 카테고리의 다른 글
| [ios/swift] Firebase 기본 사용법 (0) | 2022.08.10 |
|---|