[MC1] 아주 그냥 정신없던 첫 프로젝트

[ Zoom으로 시작하며 ]

첫 시작은 Zoom으로 진행되었다.

코로나가 한창일 시기였어서 예정과는 다르게 원격으로 프로젝트를 시작하게 된 것이다.

 

회사를 다니면서 리모트 근무도 해봤고, 타 기업과의 회의를 줌으로도 진행해봤고... 다 해봤다.

다 해봤지만 다시 해도 힘든 것은 처음 보는 사람들과 오프라인이 아닌 온라인으로 만남을 가지는 것이다.

 

가장 큰 문제는 친해지기도 전부터 보이스가 겹칠까봐 서로 눈치보며 말하지 못했던 환경이었다. 이게 친한 사람들끼리는 그냥 겹쳐도 대충 눈치로 순서를 정하면 되는데, 서로에 대한 에의가 극에 달한 상황에서 눈치를 보려니 하루 4시간 진행하는 회의가 얼마나 힘들던지...

초반엔 얼른 코로나가 잠잠해져 오프라인으로 모든 환경이 바꼈으면 좋겠다라는 생각 밖에 없었다.

 

근데 막상 시간이 좀 지나니 또 줌 미팅 후 내 시간 활용, 서울에 살던 나의 생활 반경의 유지... 이런 장점들이 다시 보이긴 했다 :0 ㅋ

 

 

[ 프로젝트를 시작하며 ]

최소한의 아이스 브레이킹을 끝낸 후 첫 프로젝트가 시작됐다. 우리는 각자의 관심사를 기반으로 주제를 선정해야 했고, 그 주제 내에서 어떤 Challange를 해결할 것인지 정해야 했다.

 

이 기획을 진행하는 모든 과정에는 어느정도 틀이 있었다. 따라서 그 틀을 따라가며 우리가 진짜 해결하고자 하는 문제는 무엇이고 어떻게 해결할 수 있는지를 차근차근 고민하게 된다. 

 

사실 이때까지만 해도 기획 단계는 얼른 끝내고 개발할 시간이 많겠지? 프로젝트 진행하는 과정 중에 Swift(개발) 기초를 많이 배우겠지? 하는 막연한 기대감이 있었다.

 

내 개인 회고록 발췌

 

그건 정말 크나큰 착각이었다 ㅎ

대략 5주 정도 진행했던 프로젝트는 2주 반 기획 / 1주 반 디자인 / 1주 반 개발 정도의 비율로 운영이 됐다. 그래서 iOS 개발자로의 전향을 원했던 나는 이 부분에서 상당히 걱정을 많이 했다.

 

처음엔 그 사실을 모르고 일단 기획에 정말 열심히 참여하였고, 같이 팀을 이루던 분들이 서로 스무스하게 의견을 수렴하여 '지체장애인을 도울 수 있는 챌린지'를 주제로 선정하였다.

 

[ 기획을 진행하며 ]

다른 팀에 비하면 상당히 스무스하게 기획이 진행됐다고 생각하지만... 돌아보면 쉽지만은 않았던 것 같다.

우리는 '장애인'에 초점을 맞추고 주제를 좁혀나가고자 했다. 이게 어느정도 다들 관심사에 들어왔다고 생각했는데, 프로젝트를 진행하며 보니 좀 더 비즈니스 모델이 있는 아이템을 선정하길 바라는 사람도 있었고, 장애인과 관련하여 별 관심은 없지만 그냥 팀이 원하니까 진행해보자라는 생각을 가진 사람도 있었다.

 

사실은 내가 후자에 속하는 것 같다. 딱히 관심은 없었지만 첫 프로젝트만큼은 서로의 니즈를 어느 정도 버리고 가는 것도 팀 플레이의 일환이라고 생각했기에 주어진 주제를 최대한 받아들이고 디벨롭시키려고 노력했다. 어차피 첫 프로젝트인 만큼 대단한 결과물이 나오지 않아도 될 것 같다는 생각도 한 몫 한것 같다.

 

일단 열심히만 해보자

 

그래도 주제가 나에겐 나름 신선한 부분이 있었기에 주변에 실제로 지체장애를 앓고 있는 장애인을 만나 인터뷰도 진행하고, 그들이 정말 힘들어하는 것이 무엇인지, 왜 필요한지에 대한 근거를 열심히 조사했다. 우리는 전부 지체장애인이 어떤 고통을 겪고 있고, 어떤 허들을 가지고 있으며, 어떤게 필요한지 전혀 알지 못했던 사람들이기 때문에... 직접 그들의 니즈를 찾는 것은 어려우면서도 흥미로웠다.

 

그렇게 기획 단계가 마무리 되며 우리는 많은 지체장애인들이 휠체어를 타고 있고 휠체어를 이용한 러닝(휠체어를 미는 것)을 통해 건강을 유지하는데, 이때 그들에게 힘이 되줄 수 있으면 좋겠다는 결론이 나왔다.

 

그래서 이를 도와줄 '휠체어 이용자를 응원하는 앱'을 기획했다. 앱의 컨셉은 나이키 런 앱과 흡사하다. 그들에게 러닝 코치가 되어 보이스로 그들을 독려하고 얼마나 러닝 시간이 남았는지 등을 전달해 주는 것이다. 나중에는 라디오처럼 휠체어 이용자들의 보이스를 자유롭게 녹음하여 서로 들어볼 수 있는 개인방송 같은 기능도 도입하면 좋을 것 같다는 결론을 냈다.

 

기획을 진행하며 생각나는 일들

• 우리가 사용하는 키워드들에 대한 정의가 명확한가?
  • 나는 지체장애인에 청각장애인도 포함되는 것인줄 몰랐다.. 나름 키워드에 대한 정의를 확실하게 내렸다고 생각했었는데, 그 사실을 뒤늦게 알고나서 너무 안일하지 않았나라는 생각이 들었다.

 

• 이게 진짜 필요한 솔루션인게 맞나?
  • 기획을 진행하는 과정에는 뭐든 도움이 되겠지라는 마인드로 솔루션을 짜곤한다. 하지만 이는 결국 쓸모없이 용량만 차지하고 쓰지 않는 앱이 될 확률이 높다.
  • 결국 중요한 것은 유저의 니즈다. 유저 테스팅을 통해 이 솔루션의 니즈를 입증하는 것. 이게 가장 중요하다.

 

• 솔루션을 생각하지마라!
  • 사실 이게 진짜 어려운 일이다. 어떤 문제를 해결하겠다고 마음 먹은 순간, 그 문제를 해결할 솔루션에 대해서 생각하게 되니까...
  • 하지만 아카데미는 이 부분에 대해서 굉장히 엄격했다고 생각한다. 솔루션은 문제 정의와 문제의 환경을 파악하는 과정이 전부 이루어진뒤 고민해도 늦지 않다는 의견이다. 매우 동의하는 바이지만, 현실적으로 지키기가 제일 어려웠던 부분이었다.
  • 지키기 어려운 이유 중에 하나는 시간이었다. 당장 2주 안에 기획을 끝내야하는데 시장조사, 자료조사, 유저 페르소나 등의 다양한 근거를 뒷받침시키기가 어려웠던 것이다. 그래서 자연스럽게 "이런 솔루션 괜찮지 않아? 이거 될 거 같은데? 이걸 기반으로 조사해보자"와 같은 결론에 도달하게 되는 것이다.

 

• 모든걸 같이 하는게 맞는가?
  • 이 부분은 사실 디자인 / 개발도 마찬가지이다.
  • 애플 아카데미는 모든걸 같이한다. 기획, 디자인, 개발. 이러다 보면 무슨 문제가 생기는가 하면...
    • 도메인, 특히 기획 업무를 하던 사람이 팀에 있으면 그 사람의 의견에 영향을 많이 받게된다. 결국 개발을 하고 싶어서 왔던 도메인 직군의 지원자들은 개발보다 도메인에 힘을 많이 쏟게 되고 개발을 하는 시기에 피로도가 굉장히 높아진다.
    • 특별히 기획 직군을 담당하던 지원자가 없다면, 모두가 기획자가 되어 참여하는데 6-8명의 사람들이 이루는 팀에 모두가 기획자라는 것은 엄청난 의견 충돌이 발생한다는 것을 뜻한다. 이는 결국 누군가 자신의 의견을 포기하게 되고 포기하지 않는다면 매일매일이 엄청난 에너지 소비로 이루어져 점점 뒤의 일들을 소홀히 하게 된다.
    • 물론 장점도 있다. 기획 / 디자인 / 개발 전부 참여해보고 싶은 지원자들도 있었고 나도 전부 관심은 있었으니까. 하지만 이게 1번으로 끝나지 않는다는 것에 문제가 있다. 처음엔 할만했지만 Mini 2, Mini 3까지 내내 이런 상황이 반복됨에 따라 피로도가 극에 달한 것 같다.
    • 결론은 장단점이 있지만, 개발자로 완전 전향을 원했던 나에겐 그리 만족스럽지 못한 방식이었다는 것이다.

 

[ 디자인을 진행하며 ]

디자인은 아무래도 기획보다 더 전문가의 영역인 것처럼 느껴진다. 그럼에도 불구하고 처음 프로젝트여서 그런지 우리는 모두가 디자인에 본격적으로 참여하였다.

 

다같이 Miro라는 디자인 협업툴을 이용하여 각자 생각하는 Lo-Fi 디자인을 제출하였고, 각자의 디자인을 하나하나 보며 논의 끝에 괜찮은 부분만 종합하여 디자인을 완성시켰다. 물론 디자인 지원자가 팀 내에 한 명 있었고, 아무래도 디자인을 해보지 않은 사람들에 비해 월등히 높은 퀄리티의 결과물을 보여주었기에 결국 그 지원자의 디자인이 상당부분 반영되었다.

 

이때 느꼈던 것 같다. 디자인의 Lo-Fi를 논의 할 때 다같이 이야기 나누면서 어떤 기능이 MVP로서 필수적으로 들어가야하고, 어떤 컨셉이 앱 안에 녹여져 있으면 좋겠다. 정도의 의견을 나눌 수 는 있겠지만, 결국 최종적인 디자인을 고민해야하는 것은 디자인으로 지원한 지원자의 몫이라는 것을...

 

디자인이란 무엇인가

 

물론 타 팀은 정말 완벽하게 1/N로 나누어 디자인 역할을 분담했는지는 모르겠다. 하지만 나는 아무리 감각이 있어도 디자인 공부를 했고, 프로젝트를 진행해본 사람의 퀄리티를 따라 잡기엔 너무 짧다고 생각했다. 그래서 Mini 2를 진행할 때는 무조건 디자이너 역할을 하고 싶어하는 지원자와 같이 팀을 이뤘으면 좋겠다라는 생각을 했다.

 

돌아보면 이 당시까지만 해도 제대로 된 UI/UX를 고려하지 못했던 것 같다. 그저 디자인적으로 우수해 보이면 되지 않나라는 생각을 했던 것 같고, 실제 유저가 이 앱을 사용했을 때 어떤 점이 불편하고 버튼을 누를때 무슨 순서로 누르는지, 어떤 화면이 나오길 기대하는지 등 기본적인 것에 대한 고민이 부족했다.

 

디자인을 진행하며 생각나는 일들

• 아무리 열심히 해도 프로젝트 기간 내에 디자인 전공자를 따라잡기는 힘들다.
  • 모든 업무를 다같이 하길 추천하는 아카데미지만, 정말 최소한 나누어야 할 분배 업무는 있는 것이다.

 

• 나는 나름 디자인에 감각이 있다고 생각했는데?
  • 진짜 초등학생 수준이더라.

 

• 앱 서비스에 중요한 것은 기능?
  • 중요한 것은 유저를 위한 UI / UX
  • 그 다음이 기능이라고 생각이 들 정도로 디자인이 앱을 사용하는 유저에게 큰 영향을 미친다는 것을 깨달았다.

 

[ 개발을 진행하며 ]

제일 아쉬운 부분이기도 하다.



개발도 모두가 함께 진행했다. 우리팀의 경우 정말 잘하는 친구들이 많았다. iOS를 꽤 오랬동안 공부하고 다양한 프로젝트를 진행했던 팀원, 42서울 출신에 앱 출시까지 진행했던 팀원, 안드로이드 개발자로 짧게나마 일하고 왔던 팀원 등... 다들 기본기가 워낙 탄탄한 친구들이라 생각보다 빠르게 앱 개발이 진행되었다. (돌아보면 이때 팀원들과 진행했던 개발이 Mini3 때 진행했던 플젝보다 더 어려운 개발이었는데... 대단한 친구들...)

 

나는 일단 Swift를 아카데미에 들어오기 전에 튜토리얼 정도만 해보고 온 수준이라 무엇을 어떻게, 어디서부터 시작해야할지 감도 안잡혔다. 그래서 이 부분에 대해서 멘토진들이 가이드를 줬으면 어땠을까 생각한다. 물론 Mini1 프로젝트가 끝났을 때 원하는 일정에 맞춰 개발을 끝마친다는 것이 얼마나 힘들 일인지를 느끼게 해주고 싶었다는 말도 어느 정도 동의는 한다만... 어느 정도 개발을 할 줄 아는 인원들이 없었다면 진짜 시작조차 못했을 것 같아서 첫 시작을 이렇게까지 해야하나 싶었다 비전공자로써.

 

결국 우리가 선택한 개발 방식은 페어 프로그래밍이었다. 개발을 잘하는 3명을 중심으로 한 명씩(우리팀은 6명이었다.) 붙어서 각자 개발할 부분을 나눠 맡으며 모르는 것을 질문하고 코드를 리뷰 받는 것이었다.

 

이 부분은 정말 긍정적인 경험이었다. 우리 페어가 맡은 화면과 기능 내에서 어떤 것을 개발해야하고 어떤 것을 찾아보야할지 물어볼 수 있었고, 스스로 공부하면서 모르는 것들은 바로바로 물어볼 수 있어서 좋았다. 또한 나의 파트너도 안드로이드 개발만 했지 iOS는 처음이라 모르는 것을 같이 찾아보고, 찾으면 서로 논의하는 그 시간이 굉장히 값졌다. 여러모로 신세를 많이 졌다.

 

고마워 Woogy!

 

개발 스택으로는 SwiftUI, Core Data를 사용했는데 사실상 Core Data는 제대로 적용하지 못했다. 개발을 하기 앞서 MVC, MVVM의 디자인패턴 개념도 적용을 시킬지 말지에 대해 논의를 많이 했지만, 시간이 부족하고 나 같은 초짜가 있어서 그런 부분까진 신경쓰지 말자고 결론을 냈다. 그리고 같이 개발을 진행하던 친구들도 SwiftUI가 익숙하지 않아 좀 더 쉽게 가고자 했던 부분도 있었다.

 

개발 부분 중 나는 운동 데이터를 기록하고 기록된 데이터를 차트로 볼 수 있는 화면을 만들어야 했다. 사실 뭐 아는게 없는데 이런 부분을 맡았다는 거 자체가 지금 생각해보면 황당하긴하다. 하지만 그 당시에는 진짜 구글링 열심히 해서 코드 복붙으로 어떻게든 화면을 만들고자 했었다. 당연히 데이터의 흐름인 State나 Binding 개념은 아예 없었고, 그저 UI만 구현하는 것으로도 충분히 챌린지였다.

 

다른 사람의 코드를 긁어오는 것은 너무나 쉽고 간단하지만, 결국 그 코드를 변형하여 디자인 된 화면으로 재정의하는 것이 정말 어려웠다. 심지어 그 당시 SwiftUI가 Chart를 지원해주지 않았기 때문에 커스터마이징된 코드 혹은 3rd Party를 사용해야 했다. 그리고 난 이 모든것이 무슨 말인지 몰랐지만 나의 파트너에게 물어봐 대강 어떤 느낌인지만 알고 지나갔다.

 

당시엔 열심히 View의 개념이 뭔지, Struct가 뭐고 Class가 뭔지, Rectangle에 Text는 어떻게 쓰는지 등 정말 기초 중의 기초를 구글링을 통해 배웠다. 그러나 여전히 View의 구조나 Struct / Class 간의 차이, Button에 액션을 주고 Text의 데이터가 어떻게 변동되는 건지 등 정말 기초적인 개념이 너무 부족했다. 마치 답안지를 보고 수학 문제를 푸는 느낌.. 그저 코드를 복붙하고 그걸 어떻게든 변형하여 원하는 뷰를 만드는 수준이었던것 같다.

 

그래도 나름 SwiftUI가 초심자가 뷰를 짜기 쉬운 프레임워크였어서 그런지 어느 정도 만들긴 했다. 그리고 옆에서 나를 도와준 파트너 덕에 불완전하지만 대강 UI라고 불릴만한 화면은 완성시킬 수 있었다. 

 

그렇게 나의 첫 프로젝트 개발이 끝났다.

 

개발을 진행하며 생각나는 일들

• 개발 시간이 부족했다.
  • 나에게 제일 중요한 것은 시간이었다. 프레임워크가 뭔지, SwiftUI와 UIKit이 뭔지, Struct를 왜 선언하고 어떻게 활용하는지 이런 기초 중의 기초도 모르는 나에게 프로젝트를 따라가는 것은 엄청난 스트레스였다.
  • 특히 기초 개념을 하나씩 찾으면서 프로젝트의 디자인을 따라가는 것은 거의 불가능에 가까웠다. 그나마 페어 프로그래밍을 진행했으니 UI에 조금이나마 근접한 화면 개발을 진행할 수 있었다.
  • 차라리 기획을 엄청 짧게하고 혹은 기획을 하는 과정에서 멘토 측에서 최소한의 개념을 숙지할 수 있는 가이드라도 줬다면 프로젝트를 진행하며 더 많은 것들을 흡수할 수 있지 않았을까 싶다.

 

• 잘하는 사람들이 너무 많다.
  • 이미 완성된 인재들도 많았다.
  • 그래서 내가 여기서 9개월 한다고 해서 iOS 개발자로 취업할 수 있을까? 하는 막연한 두려움이 생겼다.

 

• 개념을 공부한다고해서 코드를 짤 수 있는 것은 아니다.
  • 1주 반의 시간동안 나름 열심히 책도 빌려서 보고 유튜브 무료 강의도 챙겨 보면서 Swift 기본 문법을 익혔지만...
  • 결국 이를 적용하는 것은 완전히 딴 세상 이야기였다. 정말 '서비스 개발'을 위한 코딩은 다른 사람의 코드를 많이 보고 내가 스스로 분석해가면서 익혀야하는 것임을 알았다.

 

• 코드 짜는 것만 어려운 것이 아니라 협업툴도 어렵다.
  • Github을 너무 써보고 싶었는데 바로 포기했다.
  • 완전 초짜인 나에게 깃허브는 너무나 어려운 존재였다.
  • 하지만 이게 회사가면 업무의 중심에 있는 툴이라던데... 무조건 공부해야겠다는 생각이 들었다.

 

[ Mini Challange 1을 마치며 ]

여러가지 감정이 교차한 프로젝트였다.

 

아카데미 내에서 다양한 사람들과 같이 프로젝트를 하면서 내가 모르는 것들을 남을 통해 아는 것이 굉장히 도움이 많이 됐고, 내가 팀을 위해 더 열심히 해야겠다는 동기부여로 더 집중도 있게 모르는 것을 얻어 간 시간이었다.

하지만 내 생각보다 너무 풀어놓는 방임주의에 가까운 교육 커리큘럼은 꽤 오랜시간동안 특정 커리큘럼을 쫓아가며 살았던 나에겐 어려운 일이었다. 여러가지 장단점이 있겠지만 최소한 개발에 대해 전혀 모르고 전향을 위해 들어온 도메인, 디자인 지원자들이라면 아카데미보다 더 좋은 선택지도 있을 수 있겠다는 생각을 했다.

 

개발자로서 확실한 전향을 위해서는 내가 더 사람들에게 다가가 모르는 것들을 확인하고 어떤 방향으로 스스로 공부를 해나갈지 계획을 잘 세워야겠다는 생각이 들었다. 또한 프로젝트를 진행하다보면 개인 정비 시간이 생각보다 잘 안나기 때문에 최대한 프로젝트를 진행하며 시간을 효율적으로 활용해야겠다는 생각도 했다.

 

늘어나는 예정, 늘어나는 미완료

 

 

깃허브(Github): https://github.com/DeveloperAcademy-POSTECH/JourneyWay