Apple Developer Academy - MC1 회고

목차

1. 회고를 Solution으로 정한 이유
2. ADA 이전의 일하는 방식과 ADA에서의 방식
3. Challenge를 진행하면서 중점을 두었던 부분
4. 실패에서 배우기 - 레베카 세션
5. 어려움을 느낄 때 도와준 조이
6. 아카데미 라이프에서 해답을 찾기

1. 회고를 Solution으로 정한 이유

MC1의 Guiding Question은 아카데미 라이프였다. 그에 대한 우리 팀의 Solution 은 회고였다. 아카데미 라이프를 9개월간 성공적으로 이끌어나가려면 무엇이 필요할지 고민을 해보았을 때, 그 순간에 집중하는 것과 시간이 지나서도 경험들을 발판 삼아 성장의 밑거름으로 삼는 것이 중요하다고 결론지었기 때문이다.

포항까지 내려온 러너들은 더 나은 자신이 되기 위해 ADA에 왔을 거라고 생각했다. 어떻게 러너들의 성장을 도울 수 있을지를 고민하다가 점점 주제가 커지고 말았다. 고민이 깊어지다가 아이작에게 물어봤는데, 단 1명이라도 그 솔루션을 쓴다면 해보라고 하셨다. 조언 덕분에 좁은 타겟과 명확한 문제의식을 지니고, 우리 팀 6명은 회고를 하는 것이 성장을 위해 필요하니 회고로 주제를 하자고 결론을 내렸다.

그렇게 Mini Challenge1 의 파트 1은 회고를 쉽게 해주는 온라인 설문 Form을 솔루션으로 만들었고, 파트 2는 개발적인 요소가 들어가야하기도 하고, 이번 MC1을 진행하면서 느낀 생각들을 카드 형식으로 표현하는 솔루션을 개발했다. 결과물을 알리기 보단 우리가 걸어온 시간들이 너무 소중해서 이번 회고를 남기려고 한다.

2. 이전의 일하는 방식과 ADA의 방식

MC1 은 15일 동안 솔루션 2개를 만들어내는 챌린지였다. 그전에 어떤 개발 작업을 하면 기능 명세에 따른 구현에 집중했었다. 반면에 ADA에서는 생각의 발산과 수렴을 통해서 팀만의 문제 상황을 정의하는 것에서 부터 시작했다. 생각해보면 문제 상황을 사장님이나 CTO가 고민해서 들고 오면 하부 수행 조직이 그것을 해결하는데 초점이 맞춰지는 모습이 일반적인데, 문제 상황부터 정의하려니까 정말 골치가 아팠다. 조금만 고민해보면 문제 정의부터 시작하는 것이 좋다는 것을 알 수 있다. 왜냐하면 문제해결에 대한 명확한 목표 없이 기능만 만들어서 붙인 앱은 아무도 안쓰는 앱이 되기 쉽기 때문이다. 반면에 명확한 문제의식과 타겟 유저 설정은 코드가 지저분하고 디자인이 별로여도 오래도록 살아남는 앱이 될 수도 있다.

“무엇이 문제일까? 우리는 어떤 점이 가장 어렵나? 우리는 이번 Challenge에서 어떤 문제점을 해결하고 싶은가?” 등의 질문이 계속 되었다. 말을 많이 하고 질문도 많이하고 고민도 많이해야해서 개발을 어떤 방식으로 배우는지보다는 생각하는 방법과 팀원들의 의견을 어떻게 한 점으로 모으는지에 대한 연습이 주를 이뤘다. 이 방식이 해보지 않았던 방식이여서 어려웠다. “생각을 조리있게 정리해서 말하기”는 내가 해본적이 없는 일이였다. 별명이 생각난 것을 바로 바로 말한다고 해서 “척수반사” 였는데, 의견을 스스로 설득하고 설득당하려니 몹시 어색했다.

MC1의 출제의도는 내 생각엔 “각자의 생각을 조리있게 설득하고 설득 당하기”이지 않나 싶다. 협업을 위해서는 의견의 양방통행이 제일 중요하니까 그렇게 정했을 것 같다. 그런점에선 최연소인 러너가 의견을 전달하는 모습이 멋졌다. 자신의 생각을 조리있게 전달하는 능력을 배우고 싶었다.

3. Challenge를 진행하면서 중점을 두었던 부분

챌린지를 진행하면서 염두에 두었던 부분이 시작과 끝이 다르다. 시작할 때는 포트폴리오로 이것을 쓸 수 있을지에 대한 고민이 많았다. 결론적으로 포트폴리오에 쓰겠다는 마음은 말도 안되는 소리였다. 왜냐하면 우리는 우리의 원피스를 찾아나섰기 때문이다.

사실 지금 이미 잘하는 것을 더 잘하는 것은 한계가 있다. 더 파고 들어가려하다 보면 고립이 될 수도 있고, 모든 지식을 배우려고 하는 것도 무의미할지도 모른다. 여행 배낭 속에 모든 것을 집어넣을 수는 없다. 도라에몽 주머니는 만화에나 있는 거라고 생각했다.

또 다른 성장하는 방법은 ‘안해본 것을 하는 것’이다. 그래서 우리는 이번 챌린지에서 안해본 것들을 주로 하자라는 목표를 잡았다. 물론 마감이 정해진 챌린지기에 솔루션의 제출에서 자유로울 수는 없었지만 최대한 우리는 안해본 것을 하자고 목표를 잡았다. 여기에도 물론 아이작의 입김이 작용했다. 작년 기수를 보면 결국에는 테크는 더 테크하고, 디자인은 더 디자인하고, 기획은 더 기획을 한다는 것이였다.

자기의 전문분야를 깊이 파는 것은 어느 정도 장려하는 부분이기는하나 ADA에서는 다양한 사람들이 섞이고 융합할 수 있는 환경이 제공되는데 너무 자기가 하던것만 하는 것도 아쉽다고 생각이 든다고 하셨다. 그 조언을 듣고 우리는 우리가 안해본 것들을 하자고 결론을 지었다. 예를 들면 디자인은 테크를 해보고, 도메인도 테크를 해보고, 테크는 기획과 디자인을 해보자는 것이였다. 물론 잘되기가 어려웠다. 각자 잘하는 것을 해서 모으기도 촉박한 시간인데, 안해본것을 해서 모으자니… 아주 낭만이 있는 시도였다.

낭만 … 그것 참 낭만적인 단어다.

호기롭게 낭만있는 작업방식을 선택했으나, Xcode를 처음 다뤄본 팀원이 3명이나 되었다. 다른 두분은 SwiftUI를 처음 접하셨다. 또 이런 작업 방식이 처음이기도 하고 무엇을 어떻게 해야할지를 갈피를 못잡고 지나간 시간들이 꽤 돼서 어떻게 해야할지 고민이였다. 그러나 이렇게 난관이 하나 둘씩 추가될 때마다 신기하게 재미가 생겼다. 이 분들이 개발이 무엇인지 정도는 알고, 어떻게 하면 되겠구나를 알려주고 싶다는 생각이 들었다. 사실 개발은 깊이 들어가면 어렵지만 처음 시작할 때 모르고 막 구현할 수 있기 때문에 즐거운 경험일 수도 있다. 나도 처음 전화기의 숫자 패드를 구현한 때 너무 즐거웠던 기억이 있다. 그 재미를 느끼게 돕고 싶었다. 그래서 정한 방식은 “기능도 코드도 디자인도 최소로하고 우리가 최대한 성장할 수 있도록 서로를 돕자”가 되었다.

스토리라인을 심도있게 정하고 그것을 잘 보여줄 수 있는 형태를 잡았다. 이것만 설정되고 나니까 사실 개발은 별로 할게 없었다. 솔루션의 구현 목표를 높게 잡지 않고 솔루션을 도달하는 과정에서의 팀원들의 성장이 목표였으니까 가능한 일이였다. 그래서 일단 작업 단위를 목록으로 나열하도록 고민을 같이하고, 그 작업단위를 어떤 기간에 맞춰서 할지 정한 후, 거기에 맞춰 작업을 분배했다. 그 과정에서 어려움을 겪는 분이 있으면 도와드리는 쪽으로 가닥을 잡았다. 문제를 대신 해결해주는 것이 아닌 적당한 방향으로 제시만 해주는 선이여서 나도 그렇게 어렵지는 않았다.

번뜩이는 생각이들이나 창의력은 우리가 모여서 대화할 때 뿐만 아니라 서로를 도우면서도 나타났다. 나는 기획적인 단어들을 아주 처음 듣고, 디자인적으로 피그마를 보기만해봤지 한번도 만들어 본적은 없다. 서로 나눌 수 있는 것은 나누고 돕기로 하니까 마음의 문도 더 열리는 느낌이였다.

4. 실패에서 배우기

레베카라는 팀 빌딩 전문가가 우리에게 강연을 들었다. 대단하신 분인 것같았는데, 픽사, 디즈니, 블리자드 이런 곳에서 팀 빌딩을 전문적으로 하셨다고 한다. 한 곳에서 오래 일하기 보단 그 직장에서 친하게 지낸 사람들이 직장을 옮기면 항상 레베카를 섭외해가려고 했다고 한다. 하여튼 그 레베카가 우리의 아이스 브레이킹과 마인드 셋에 대한 시간을 갖도록 도와줬다.

간단한 자기 소개와 아이스 브레이킹을 마친 후에 1,2,3 게임을 했다. 우리나라의 탕수육 게임이랑 비슷하다. 대신 점점 난이도를 높인다. 1에서 박수를 치고, 2,3 을 하다가 나중에는 1에서 박수, 2에서 점프, 3을 외치는 식이다. 이 과정에서 특이한 점은 실수를 하면 게임에서 지는게 아니라, 환호성을 지르는 것이였다. 패배의 쓴맛이 아닌 실수의 기쁨을 느끼는 것이 포인트였다.

보통의 과정에서 무언가에 실패하면 부끄러워하고 그 상황에서 벗어나서 다시하기 싫었었는데, 실패에서 환호를 하다보니 신기한 감정이 들었다. 다시 도전 해보고 싶은 느낌이 들었다. 무슨 일이든지 처음하다보면 잘 안될 수 있는데, 거기서 낙담하기 보단 새롭게 무언가를 배울 수 있다는 기회로 받아들이는 자세를 배웠다. 또 간단한 스토리라인을 짜는 방법에 대해서 배웠는데, Story Spine 기법을 배웠다. 픽사에서 쓰는 창작기법이라고 하는데 이야기가 일정한 플롯을 가져간다고 하는 것이였다. 어떤 플롯을 받고 거기 안에서 이야기를 생각해내니 조금 더 시작하기가 수월했던 것 같다. 0에서 1만들기는 어렵지만 0.5에서 1을 만들기는 수월한 기분이 들었다.

5. 어려움을 느낄 때 도와준 조이

5.1. 팀빌딩

팀원들과 일적인 부분에서 어렵다는 느낌을 받았을 때 어떤식으로 해결책을 찾아야하는지를 대화를 통해서 알려주셨다. 다 듣고 보면 정말 그렇다는 느낌을 받은게 많았다. 의견을 주고 받을 때 먼저 열심히 들어야한다는 것을 알려주셨는데, 그래야 그 사람의 의도를 생각할 수 있다는 것이다. 그리고 그것을 다른 나머지 팀원들에게 설득할 수 있어야 납득이 된다고 하셨다. 사실 그룹으로 챌린지를 진행하다보면 “저 사람은 왜 나랑 다르게 행동하지?”에 대한 의문이 들 수 밖에 없다. 그런 상황에서 왜 그런 생각을 해서 행동을 했는지 대화를 통해 알고 그것을 남들에게 전달해서 이해를 이끌어내는 과정 자체가 팀빌딩에 중요하다고 하셨다. 그 자체가 팀빌딩이기도 한 것 같다.

5.2. 리더쉽

리더쉽에 대한 조이의 견해도 들었는데, 결국은 방향타를 잡는 사람은 답답함을 느끼는 사람이라는 내용이다. 또 리더의 정의가 어느 방향으로 이끄는 사람이라기 보다는 구성원이 더 좋은 능력을 발휘할 수 있도록 도와주는 조력자라고 말씀하신 부분이 인상 깊었다. 그렇게 남들을 돕기 위해서는 서로간의 신뢰가 쌓여야하는데, 그 신뢰를 쌓는 부분이 사실 제일 어렵다. 힘들고 궂은 일을 솔선수범해서 하는 것이다. 대부분이 하기 싫은 일을 해야 팀원간에 신뢰를 쌓아줄 수가 있다. 이건 생각지도 못한 부분이였다. 대단한 능력이 있고, 커리어가 훌륭해야 신뢰를 쌓을 수 있다고 생각했는데, 한 방 맞은 느낌이 들었다.

5.3. 의견 수렴

그리고 서로 다른 사람들의 의견을 모으는 방법도 알려주셨는데, 사실 이 부분도 정말 어려웠다. 왜냐면 얼마나 창의적이고 열정이 넘치는 사람들인데, 그런 사람들을 한 지점으로 모으는 게 사실은 쉽지 않다. 조금 조심스럽기는 하지만 방법을 하나 알려주셨다.

1. 이야기가 활발히 나올 때는 잠시 기다리기
   1. 왜냐면 먼저 의견을 제시하면 거기에 갇힐 수 있어서 아주 간단한 의견만 내고 다른 사람의 의견을 먼저 들어본다.
2. 조금 차분해지거나 다른길로 세면, 지금 어떤 목표를 가져야하는 시간인지 상기를 시킨다.
3. 의견을 종합해서 괜찮다고 생각하는 의견을 하나로 모은다.
4. 그리고 그 괜찮은 의견을 제시한 사람이 다른 의견을 제시한 사람들을 설득한다.
   1. 이것은 이래서 좋고 저것은 저래서 별로다.
   2. 보통은 반대 의견을 낸 사람들이 스스로를 해명해야하는데, 조이는 우세한 의견을 가진 사람들이 더 적은 의견을 가진 사람들을 설득해야한다고 말해서 놀라웠다.
5. 거기에 이견이 나오지 않을 때까지 위의 행동을 반복한다.

사실 이렇게 나누면 뭔가 되게 딱딱해 보이고 조심스럽다. 그래서 여기에서 가장 중요한 것이 경청하는 자세다. 결국 사람이 하는 일이기 때문에 존중받지 못한다는 느낌을 받으면 그 구성원은 더 이상 이야기를 하지 않을 가능성이 높기 때문이다.

6. 아카데미 라이프에서 해답을 찾기

개발자가 되기 위해 여기에 온 사람들이 많을 걸로 안다. 이렇게 좋은 환경과 열정있는 사람들이 붙어있을 수 있는 기회가 정말 없다. 취업 준비를 해보면 느끼겠지만, 정말 그렇다.

공부를 하면 할수록 잘하는 사람이 너무 많다는 것을 알았는데 그 속에서 어떻게 공부를 준비해야할지에 대한 회의가 조금 찾아왔었다. 어떤 기업에 취업을 위해서 학습해야하는 절대 기준이 있는 것인지, 아니면 내가 부족한 뭔가가 있는 것인지 알기 어려웠다. 그렇게 약간의 회의감 속에서 아카데미 생활을 시작했는데, 다양한 사람을 만나면서 경험해보니 정말 다양한 세계가 있다는 것을 알았다. 다양한 경험과 가지각색의 목표들이 있다는 것을 알았다. 그 안에서 나의 목표와 앞으로의 커리어를 어떻게 쌓아나갈 것인지에 대해서 고민할 수 있는 기회가 주어졌다고 생각한다. 아무 공부나 마구잡이로 하는 것이 아닌, 전체 커리어를 고민해 본 후에 거기에 필요한 개발자 혹은 사람이 되어야겠다고 생각한다면 조금 정리할 것이 줄어들 거라 생각한다.