지난 6월 12일, Challenge3의 막이 내렸다. iOS 개발을 통한 팀 협업이 처음이라 마음 한편이 무거웠다. '제발 팀에 민폐가 되지 않게 열심히 하자'는 생각뿐이었다.
항상 이런 식이다. 나를 움직이는 동력은 결핍 기반이다. '정말 잘하고 싶다!'(충족 기반)보다는 '못하면 절대 안 돼!'라는 두려움이 앞선다. 이 부분은 챌린지가 끝난 후 브릿지 회고에서 더 깊이 다뤄보려 한다.
특이했던 팀빌딩
팀빌딩은 독특한 방식으로 진행됐다. 오직 한 사람만을 위한 앱이라는 주제에 맞춰, 각자 주변의 가까운 지인 한 명을 떠올리고 그 사람에게 어떤 도움을 줄 수 있을지 고민한 뒤, App Statement를 A4 용지에 크게 한 줄로 적는 것이었다.
팀을 구성해야 하는 순간이 왔을 때, 다른 분들의 주제를 보니 크게 끌리는 앱이 없어 고민에 빠졌다. 그 사이 여러 팀이 구성을 마치고 강당을 떠났고, 남은 팀들과 사람들 사이에서는 6명을 채우기 위한 자연스러운 어필 타임이 시작됐다.
정말 다행이라고 느낀 점은, 팀들이 남은 사람들을 꺼리는 게 아니라 오히려 자신의 팀으로 영입하고 싶어하는 분위기였다.
마지막까지 고민하다가 결국 한 팀을 선택했다. 그때 내가 고려한 기준은 딱 두 가지였다.
1. 편하게 소통할 수 있는 분위기인가?
단순히 '친한 사람', '착한 사람'을 찾는 게 아니었다. 의견에 대해 얼마나 포용적인지, 자유롭게 말할 수 있는 부드러운 분위기인지를 살폈다.
장단점이 있겠지만, 아직 잘 모르는 분야에서는 분위기가 소프트할수록 내 퍼포먼스가 더 좋아진다고 생각한다. 타인의 눈치를 많이 보는 편이라, 편하게 의견을 개진할 수 있는 환경을 우선시했다.
2. 테크 인원 비율과 내 기여 가능성
애플 아카데미답게 디자인, 도메인, 테크로 구성된 팀에서 테크 인원이 너무 많으면 내가 담당할 부분이 줄어들고, 그만큼 성장 기회도 상대적으로 적어질 거라고 생각했다.
그런데 프로젝트가 끝나고 보니 이 기준을 다시 생각하게 됐다. 담당 부분이 많아진다고 해서 그만큼 선형적으로 성장하는 건 아니었다. 오히려 맡은 일이 적을 때 남은 시간에 프로젝트 전반을 더 깊이 이해할 수 있는 기회가 생긴다는 걸 깨달았다.
지방 미대입시 준비생의 정보 불균형을 해소하자
우리 팀이 처음 선택한 App Statement였다. 나는 당시 적당한 커뮤니티나 플랫폼 정도를 머릿속에 그리며 접근했는데, 멘토분들과 심지어 미대입시를 준비했던 팀원조차도 "이 문제는 정말 우리가 해결할 수 없는 영역"이라고 언급했다.
무엇보다 C3의 주제인 Understanding User와도 맞지 않는다는 의견이 대다수였다. 세상을 바꾸는 거대한 플랫폼이나 아예 문화 자체가 바뀌어야 하는 문제라서, 더욱 만류하는 분위기였다.
결국 뒤늦게 심각성을 느낀 우리는 방향을 바꿨다. 거대한 구조적 문제는 잠시 접어두고, 팀장 체리의 동생이 겪고 있는 개인적인 경험에 집중하기로 했다. 미대입시 준비 과정에서 왜 힘들어하는지 구체적으로 살펴보기 위해 인터뷰 시트를 준비했다.
일단 더 빠른 글 전개를 위해 체리의 동생을 '망고'라고 칭하도록 하겠다!
주제 확정의 어려움
기존 주제도 막막했지만, 정말 큰 문제는 한 분을 제외하고 우리 팀원들이 전부 미대입시에 대한 백그라운드가 없다는 것이었다.
다양한 리서치 방법들이 있었을 텐데, 우리 팀은 현 상황을 빠르게 해결하자는 목적 때문에 전체적으로 넓은 시야를 갖지 못했던 것 같다. 그러다 보니 자연스럽게 인터뷰에만 의존하게 됐다.
문제는 망고가 평일에는 독서실, 주말에는 미술학원에서 시간을 보내다 보니 짧은 시간밖에 주어지지 않았다는 점이다. 그 귀한 인터뷰 시간에 충분히 서면으로도 받을 수 있는 학원 스케줄 정보나 혼자 있을 때 어떤 부분을 하는지 같은 것들을 물어본 게 아쉬움으로 남았다.
결국 인터뷰 시간에는 망고의 객관적 정보들만 듣고, 남은 시간에는 팀끼리 모여서 "망고가 이때 이 말을 한 것은 이런 의도가 아닐까?" 하는 식으로 인사이트 주체자 없이 인사이트를 조합하는 비극적인 상황이 펼쳐지기도 했다.
그 후 빠른 시일 내에 인터뷰를 한 번 더 잡고, 인터뷰 바로 다음날에는 체리가 언니로서 전화를 통해 정보를 보충해주기까지 해서, 덕분에 최우선 과제로 두었던 <정보 불균형>이라는 키워드에서는 벗어날 수 있었다.
망고가 입시미술 준비를 잘하고 있다고 느낄 수 있게 도와주자!
최종적으로 이렇게 추려졌다. 이 문장만 보면 "그래서 어쩌라고?" 하는 생각이 들 수도 있지만, 망고의 상황을 들여다보면 그렇지 않았다.
망고는 미대에 꼭 가야 한다는 압박감 때문에 조급함을 느끼고, 자신이 잘하지 못하고 있다는 생각에 스스로를 자책하는 악순환을 반복하고 있었다.
우리는 현실적으로 앱이 해줄 수 있는 범위에 집중하기로 했다. 미대입시에 붙기 전까지는 불안할 수밖에 없지만, 그 과정에서 스스로를 자책하고 동력을 잃는 패턴에서 벗어날 수 있게 돕자는 것이 우리의 Solution Concept였다.
결과물에 대해
이번 프로젝트를 짧게 요약해보자면, 개발적으로는 큰 성장을 이루지 못했지만 방향성은 잡을 수 있었고, 협업과 나 자신에 대해 다시 한 번 생각해보는 계기가 되었다.
프로젝트를 큰 덩어리로 나누면 기획-디자인-개발인데, 모든 팀원이 기획에 참여하고 6명이 반반으로 나뉘어 디자인과 개발을 맡게 되었다. 나는 개발 파트를 맡았는데, 나도 iOS가 처음이지만 협업 경험이 많지 않은 팀원들을 리드해야 하는 상황에 마주했다.
내가 이번 프로젝트에서 얻어가고자 했던 것은 GPT를 최대한 지양하고, 어떤 부분을 챙겨갈 수 있을지 고민해보자였다. 다행히 우리 챌린지 프로젝트가 스코프를 작게 가져가서, 기존에 C3에서 얻어가고자 했던 부분을 잘 가져갈 수 있을 것 같았다.
하지만 장벽이 있었다.
1. 절대적으로 부족한 개발 시간
개발 시간을 5~7일 정도밖에 주지 않았다. 물론 멘토들은 "완성하지 못해도 된다! Understanding User가 핵심이니까 거기에 초점을 맞춰야 한다"는 마인드였지만, 그 커리큘럼에 더 집중하라고 하셨다.
2. 처음 해보는 리딩에 대한 부담
이 프로젝트를 처음으로 리딩해보려 하니 좀 더 체계를 잘 갖추고 싶었다. 주변에 보이는 것도 많고, 나도 잘 리딩하는 부분에 대해 배우고 싶었다. 그래서 컨벤션이나 깃허브 관리 관련해서 체계를 갖추고자 했는데, 이때 깨달은 것이
어설픈 체계는 오히려 생산성을 떨어뜨린다.
새로운 것을 도입하거나 가르치기 위해서는 나도 더 빠르게 학습했어야 했다. 내가 따라가는 입장이라면 하면서 배우는 박치기 공룡식 학습이 가능했을 텐데, 리딩하는 입장에서 배우면서 적용하려다 보니 팀원들에게 "왜 이렇게 해야 하는지"에 대한 설득력이 떨어졌던 것 같다.
그러다 보니 개발보다는 체계나 더 좋은 코드에 대한 고민에 시간을 쏟았는데, 팀원들 입장에서는 끌어줘야 하는 사람의 개발 진척이 더디다고 느꼈을 상황도 있었다. 항상 "내가 더 잘했으면..."하는 아쉬움이 남았다.
배운 점들
결국 짧은 개발 기한 안에 앞서 말한 여러 요소들에 방해 아닌 방해를 받다 보니 남은 개발 기한이 정말 부족했다.
그렇게 하다 보니 나중에는 일일이 하나하나 코드 리뷰하고 맞춰가는 게 아니라, 어느 순간 허술한 오픈소스처럼 흘러간 게 정말 아쉬웠다. 빠른 개발을 위해 리뷰보다는 빠르게 Approve가 필요한 상황들을 보면서 "정말 좋은 체계란 무엇일까"에 대해 고민해보는 계기가 되었다.
특히 이번 상황처럼 모두가 이런 체계에 익숙하지 않았다면, 그것을 고려해서 커밋/브랜치 컨벤션, GitHub 관리, 코드 리뷰 같은 것들을 적용해야 했는데... 검색을 통해 가장 좋아 보이는 것, 가장 현업 같은 것, 가장 대중적인 것을 가져오려고만 생각했다. 그 틀에 우리를 맞춰야 한다고만 생각했지, 정말 우리가 필요한 협업 방식에는 초점이 가지 않았던 탓에 배보다 배꼽이 큰 상황이 나온 게 계속 아쉬웠다.
아키텍처 패턴에 대한 필요성도 느끼는 계기가 되었다. 당장 기능이 되느냐 안 되느냐의 기로에 서 있는 슈퍼 주니어 친구들끼리 모였다 보니, 그것을 아우르는 패턴을 고민하기에는 사치라고 생각했었다. 그런데 이번에 그 필요성을 절실히 느끼게 되었다.
각자가 본인이 편한 대로 코드를 작성하다 보니 충돌이 났을 때 코드를 살펴보는 데 혼선이 있었고, 심지어 갑작스럽게 생긴 에러의 원인을 찾는 데에도 어려움이 있었다.
이후 멘토링에서도 이런 고민을 나눴고, 협업 관련 책이나 유튜브들을 대거 추천받을 수 있었는데, 브릿지 회고에 같이 얹어서 한번 포스팅을 진행하면 좋을 것 같다!
그와중에 정말 다행인 것은 우리 프로젝트의 방향성이 "작은 프로젝트지만 디테일을 신경 쓰자"였다는 점이다. 편의성 기능, 위젯, 애니메이션 등을 고려하면서도 기본적인 기능이 동작하기까지는 무리가 없었다.
이 덕분에 심리적으로 쫓기지 않으면서 진행할 수 있었고, 발표도 굉장히 성공적으로 할 수 있었다. 하지만 한편으로는 "너무 안전구역 안에서 해결하려 했나?"라는 생각이 들기도 했다.
더 급박하고 약간의 압박감을 받을 수 있었겠지만, 그렇게 좀 더 확실하게 몰두해서 마지막에 완성도를 끌어올리는 해커톤 바이브는 나오지 않았던 것 같다. 어떻게 보면 워라벨을 지키면서 프로젝트를 진행한 셈인데, 이게 과연 챌린지의 본래 취지와 맞았을까 하는 아쉬움이 남는다.
물론 팀워크나 협업 경험 측면에서는 분명 의미가 있었다. 갈등 없이 각자의 역할을 충실히 해내면서 결과물도 완성할 수 있었으니까. 하지만 개발자로서 한계를 뛰어넘는 경험, 정말 치열하게 고민하고 문제를 해결해나가는 그런 강렬한 순간들은 상대적으로 적었던 것 같다.
다음에는 조금 더 도전적인 목표를 설정하고, 안전구역에서 벗어나는 용기도 필요할 것 같다는 생각이 든다.
개인에 대한 회고
사실 아쉬운 점들을 많이 이야기했는데, 그만큼 배울 점이 많다는 이야기일 것이고, 나 스스로는 이번 챌린지를 통해서 개발 외적으로도 많은 것을 배울 수 있었던 것 같다.
미움받을 용기
나는 항상 눈치를 많이 본다. "이 말을 하면 저 사람이 싫어할까?", "저렇게 말하면 또 누가 기분 나빠할까?" 이런 생각에 기획 단계의 뜨거운 토론 자리에서도 첫날, 둘째 날에는 거의 말을 못 꺼냈다. 그저 내가 동의하는 의견에 살짝 얹는 정도였다.
사실 나는 "나 정도면 꽤 괜찮은 팀원이지 않을까?"라는 확신을 가지고 있었다. 팀원과 갈등을 겪은 적도 거의 없었고, 늘 좋은 사람으로 보이려는 마음이 강했다. 그래서 그게 곧 좋은 팀원이라고 믿어왔다.
그런데 이번에는 문득 "내가 정말 객관적으로 좋은 팀원인가?"라는 질문을 스스로 던져봤다. 어쩌면 내 생각이 틀릴 수도 있겠다는 생각이 처음으로 들었다. 나는 그냥 팀이 잘 굴러가게 방해는 안 하지만, 그렇다고 팀을 더 빠르게, 더 나아가게 하는 동력은 아니었을지도 모른다. '최악은 아니지만, 최고도 될 수 없는 팀원'이라는 사실을 이번에 깨달았다.
이후로는 의도적으로 더 많이 말하려고 노력했다. 회의 때 일부러라도 의견을 내다 보니, 그동안 내가 얼마나 편하게만 팀플을 해왔는지 알게 됐다. 말이 적었던 내 모습도 새삼스레 보였다. 팀 분위기가 워낙 좋아서 "지금도 못 하면, 앞으로도 못 하겠다"는 생각이 계속 들었다. 그래서 이전에는 해보지 못했던 것들에 도전하는 마음가짐으로 프로젝트에 임했다.
그렇게 결국 최종 프로젝트에서는 발표를 맡게 됐다. 처음엔 발표에 대한 부담감이 커서 망설였지만, 점심 먹으면서 다시 생각해보니 "지금 아니면 언제 해보겠나?" 싶었다. 100명 가까운 사람들 앞에서 발표할 땐 정말 떨렸지만, 준비한 말을 차분히 떠올리며 발표에만 집중했다. 덕분에 발표를 재미있게, 그리고 무사히 마칠 수 있었다.
팀원뿐만 아니라 별로 커넥션이 없었던 러너들도 와서 "발표 잘했다"고 말해준 것을 듣고, "막 그렇게 피해 다닐 정도는 아니었구나!"하는 깨달음을 얻으며 두려움을 좀 덜 수 있었다. 길게 보면 인생에서 정말 큰 수확이 아닐까 생각이 든다.
App Mango 목업
발표사진
발표날 단체사진
