2025. 6. 21. 21:57ㆍExperience Story/Apple Developer Academy @ POSTECH
🍎 Apple Developer Academy @ POSTECH 4기 : Challenge 3 회고 (2025.05.08 - 06.13)
[Apple Developer Academy @ POSTECH] #4 - 그래서 나는 무엇을 배웠지?
🍎 Apple Developer Academy @ POSTECH 4기 : Challenge 2 회고 (2025.04.07 - 04.25) [Apple Developer Academy @ POSTECH] #3 - 처음 경험해본 새로운 세계, CBL (Challenge Based Learning)🍎 Apple Developer Academy @ POSTECH 4기 : Challenge 1 회
mini-min-dev.tistory.com
아카데미가 시작된 지 어느덧 세 달.
Cohort 2025에 준비되어 있는 여섯개의 챌린지 중에서 벌써 절반의 챌린지가 끝났다니.. 이 빠른 시간이 잘 믿기지가 않습니다.
이번 세번째 챌린지는 어떻게 보면 실질적으로 기획부터 디자인, 개발까지
아카데미에서 하나의 앱 서비스를 만드는데 있어 여러 명이 협업해보는 첫 프로젝트였습니다.
그러다보니, 앞선 두 번의 챌린지보다는 확실히 내용의 깊이도 있었고 / 그만큼 배울 수 있는 점도 많았고 / 또 그만큼 어려움도 많이 겪어본 한 달이었죠.
지난 Challenge 2가 끝나고 쓴 회고 글에서, 저는 Challenge 3에 보완해야 할 점들을 적었습니다.
- 많이 경험하고, 도전하고, 마주치더라도 "구체적으로 어떤 것?"에 대한 목표를 세우고 다음 챌린지에 들어가기
- 나의 장점은 다른 팀원에게, 다른 팀원의 장점은 나에게 / 이렇게 서로 좋은 영향을 주고받는 진정한 협업과 성장의 의미를 더 느껴보기
과연 이번 Challenge 3에서는 이 아쉬웠던 점들이 잘 보완되었을지. 그리고 이 과정에서 배운 점은 또 무엇일지. 알아보도록 할게요.
그리고 결론부터 말하자면 이번 챌린지는 과정부터 결과까지 꽤 많이 만족스러웠던 챌린지였습니다!
사람 공부 Part 1. 단단한 하나의 팀 만들기
프로젝트가 끝났을 때, 팀원 여러 명이 "백퍼센트 만족"하는 하나의 솔루션을 함께 만드는 것은 (거의) 불가능에 가깝다고 생각합니다.
각자가 프로젝트에서 이루고 싶은 목표도 다를뿐더러,
제각각의 전문분야와 실력을 갖고 있는 사람들이 모두가 전적으로 동의하는 아이디어는 이 세상에 그리 많지 않기 때문이죠.
대부분은 본인이 처음 세운 목표에 부합하지 않다는 이유로 / 평소에 관심을 가져본적이 없거나 생소한 주제라는 이유로 / 너무 구현하기 어렵거나 쉽다는 이유 등으로 / 팀원 간의 의견 충돌 상황을 불가피하게 맞닥뜨리게 됩니다.
물론 정말 합이 잘 맞는 팀원을 만나 이 모든 것을 부합할 수 있는 하나의 아이디어를 찾게 될 수도 있습니다만. 그 아이디어를 떠올리기까지 소요되는 시간도 항상 우리들의 편은 아니죠.
그래서 보통은 (시간과 같은 현실적인 제약에 쫓겨) 어느정도 일정 수준에서 타협하게 되는 지점이 생깁니다.
이번 챌린지도 마찬가지였습니다.
관심있는 큰 도메인을 기준으로 팀이 구성되었지만
파고 들어가보면 세부적으로는 <외국인 유학생> <한국어 학습> <한국 친구 사귀기>라는 여전히 큰 카테고리 아래, 생각하는 프로덕트는 제각각이었고,
여섯 명의 팀원이 각자 이번 챌린지에서 원하는 목표와 공부해보고 싶은 분야, 깊이까지 모두 제각각이었으니까요.
게다가 이번 팀은 어쩌다보니 디자인 없이 테크와 도메인 분야의 러너들만 모이게 되었죠. 맨땅에 헤딩인 셈이었습니다.
그래서 초반에는 어려운 점이 많았습니다.
정확하게 말하면, 어렵다기보다는 정답이 없는 문제에 대해 삽질을 하고 있다는 느낌이랄까요. (애초에 위 글의 문맥처럼 정답이 없긴 합니다.)
우리가 처음 떠올린 사용자는 "생각보다 많은 불편함을 느끼고 있는 것 같지 않았고"
이런 사용자에게 우리는 어떠한 서비스를 만들어서 갖다 주더라도 "그리 큰 효용감을 만들어낼 수 없을 것 같다"는 불확실함 때문이었습니다.
무엇보다도 이런 과정에서 어찌저찌 만들어진 앱은 우리 팀원 모두가 그리 많은 애정을 쏟지 않을 것 같았죠. 시간만 빠르게 흘러갔던 첫주였습니다.
하지만 이번 저의 Challenge 3 팀은 오히려 "타협"의 과정 속에서 갈수록 단단해져 갔던 것 같습니다.
세 가지 지점이 유독 기억에 남습니다.
- 팀 분위기, 회의 방식 바꿔보기
: Miro나 Notion과 같은 온라인 툴로 진행하는 회의는 집중력이나 효율성 측면에서 그리 좋지 못했습니다.
오히려 화이트보드와 포스트잇을 사용하는 클래식한 방식이 / 때로는 카페나 편의점, 바깥 산책을 나가면서 갑갑한 분위기를 환기해 더 자유롭게 대화할 수 있는 팀 분위기를 만들었던 것이 오히려 모든 팀원들의 만족도를 높일 수 있었던 계기였던 것 같습니다.
👉🏻 많은 회의 시간, 작업 시간을 가져가는 것이 꼭 좋은 결과로만 이어지는 것은 아니라는 것을 다시 한번 느끼게 되었습니다! - 다른 사람이 아닌, 우리 팀원 여섯 명만이라도 확실히 납득할 수 있도록 이야기하고 넘어가기
: 본격적인 구현에 들어가기에 앞서 모두의 납득을 위한 시간을 세션 하루종일 쏟은 적이 있었습니다.
이유는 단 하나.
다른 누군가가 "이런 점은 보완이 필요해보여요" "이런 점은 고려를 안하신건가요?" "이렇게 할 수 있지 않을까요?"라고 했을 때, 흔들리지 않고 여섯 명 누구라도 큰 기둥을 굳건하게 유지할 수 있는 팀을 만들기 위해서였습니다.
애초에 부족한 시간에 만들어진 앱이 완벽할 수 없다는 것을 인정하고,
단, 그 안에서 우리가 할 수 있는 최선을 쏟으며 / 그 과정 속에서 우리 팀의 큰 방향이 흔들리지 않기 위해 / 미리 들을 수 있는 지적, 우리의 약점으로 보이는 지점들을 우리 팀원끼리라도 미리 납득하고 넘어갔던 것입니다. (어떻게 보면 입 맞추기라고 볼 수 있겠네요 ^_^)
👉🏻 프로덕트를 다 만들고 흔들릴 바에야, 조금 시간이 걸리더라도 모두의 이해를 위한 시간은 협업에서 꼭 필요한 것 같습니다. - 미팅과 피드백을 통해 우리 솔루션 컨셉에 확신갖기
: 이번 챌린지에서는 멘토나 애플 팀과의 피드백 시간을 잘 활용했던 것 같습니다.
여기서는 팀에서 고려하지 못했던 점을 멘토의 피드백을 통해 보완, 반영할 수 있었다는 것을 넘어서서,
(너무나 당연하게도 단편적인 것만 듣고 피드백을 전달할 수밖에 없는 상황에서) 멘토에게 우리 팀이 고려했던 지점이 무엇이라고 설명을 하거나, 또는 우리의 의도를 누구할 것 없이 미팅 시간에 전달하기 위해 노력하며, 우리가 만들고 있는 이 프로덕트에 대한 확신이 생길 수 있었다는 것을 말하고 싶습니다.
위의 내용과 이어지는 부분인 것 같기도 한데요.
우리가 했던 그 타협의 과정이 멘토나 애플 팀분들에게 "납득이 되어지는구나!" -> "우리 맞는 방향으로 가는 것 같아!"의 흐름으로 확장되었던 것 같습니다. 이 과정을 거치며 팀원들도 솔루션 컨셉에 대한 애정이 생겨갔던 것 같구요.
👉🏻 피드백은 때론 아프기도 합니다. 하지만 그 아픔을 이겨내는 과정에서 더 단단한 팀을 만들어나갈 수도 있는 것 같습니다.
앱을 만드는 과정 속에서, 결국 이 서비스를 사용하게 될 사용자를 이해하는 것이 가장 중요하다고 생각할 수 있습니다.
하지만 이번 Challenge 3를 끝낸 저의 생각은 조금 다릅니다. 이 서비스를 만드는 우리의 팀원들, Maker들을 이해하는 것이 더 중요한 것 같거든요.
서로가 의지할 수 있는 팀원이 되었을 때, 우리가 만드는 프로덕트에 대해 비로소 납득이 되었을 때.
어쩔 수 없이 (다른 목표와 배경지식 속에서) 이루어질 수밖에 없는 팀 안에서의 타협도, 타협이 아닌 동의와 애정이 될 수 있었습니다.
사람 공부 Part 2. 원하는 것 찾기
"생각보다 사람들은 세상을 살아가는데 있어 많은 불편함을 겪지 않는다."
이번 챌린지에서 사용자를 인터뷰해보면서 수없이 많이 (거의 매일마다) 들었던 생각입니다.
하지만 과연 그럴까요?
사실 따지고 들어가보면 사람들에게 엄연히 불편함 점은 존재합니다.
그렇지만 그것이 불편한지 모르고 살아가거나, 다른 방식으로 우회해서 사용하거나, 그냥 불편함과 함께 더불어 살아가고 있을 뿐이었죠.
그래서 사용자에게 "너 평소에 불편한 점이 뭐야?" "평소에 원하는 것이 있었어?"라고 물어보면 대답은 항상 동일했습니다.
"음... 딱히 없는 것 같아."
사람을 이해하는 것은 참 어려운 일이었습니다.
많은 인터뷰와 거기서 나름대로 뽑아본 인사이트들, 그리고 그 인사이트로부터 정의한 문제까지 일련의 과정을 거쳐 서비스를 만들었고
그 서비스를 가지고 사용자에게 재방문해봤습니다.
반응은 나쁘지 않았지 않았다고 하지만, 냉정하게 바라봤을 때 "있으면 좋지만 없어도 크게 문제없는 수준"의 프로덕트라고 생각이 들더군요.
정말 사용자는 평소에 큰 불편함이 없던 것일까요?
우리가 도출한 문제가 과연 진짜 우리의 퍼소나가 평소에 많은 어려움을 겪고 있던 문제였던 것일까요?
우리의 서비스로 인해 삶의 질이 한 단계 개선되는 경험을 주려면 어떤 것이 더 필요했던 것일까요? (시간? 더 많은 인터뷰? 다른 기획 방법?)
"원하는 것, Needs를 발견하기까지의 과정"은 앞으로 더 많은 배움이 필요할 것 같습니다.
사람 공부 Part 3. 이유가 있는 기획. 이유가 있는 디자인. 이유가 있는 기술.
사실 처음 이번 챌린지를 시작할 때는 기술적인 배움의 목표를 많이 세우고 들어갔습니다.
하지만 막상 팀의 사정과 주어진 기간, 그리고 이번 챌린지 주제에 맞게 배울 수 있는 점을 다시 정리하다보니
아키텍처, 메모리 관리, 확장성 고민과 같은 기술적인 역량을 높이는 것보다 평소에 경험하지 못했던 기획과 디자인, 특히 UX 측면에서 배울 수 있는 점이 더 많을 것이라 생각되어 목표를 수정하게 되었죠.
정말 집착에 가까울 정도로 "이유"를 찾기 위한 GQ (Guiding Quesion)를 많이 던졌던 이번 챌린지였습니다.
- 사용자는 우리 앱을 언제 설치하고 언제 접속하는거지?
- 사용자가 우리 앱에 처음 접속했을 때, 우리의 코어 기능인 해당 액션을 유도하기 위한 최적의 방법은 무엇일까?
- 우리 앱에 로그인이 꼭 필요할까? 탭바가 필요할까? 해당 버튼이 필요한 걸까? 이런 컴포넌트말고 다른 요소를 쓸 수는 없을까?
- 이렇게 긴 문구를 쓰면 사용자가 앱을 사용할 때 과연 읽을까? 이렇게 짧으면 무슨 내용인지 이해하기 어렵지 않을까? [UX Writing]
- 사용자가 스와이프, 롱프레스 제스처와 같은 동작을 취하도록 유도하려면 어떻게 해야하지?
그리고 이렇게 많은 질문들이 있었기에 "Simple"하지만 "Core"했던 앱이 만들어질 수 있었던 것 같습니다.
이번 챌린지에서 만든 앱은 화면 하나하나, 컴포넌트 하나하나, 하다못해 색상까지 모두 "그냥"이 없이 "이유"를 가지고 유저 플로우를 기획했고 / 디자인 요소로 반영되었습니다.
이렇게 고민한 시간만큼 이 앱을 사용하게되는 사용자도 우리의 의도에 맞게 행동할 것이고요.
개발도 마찬가지인 것 같습니다.
요즘 블로그에 업로드하는 개발 글도 항상 공부의 이유를 포함해서 내용을 작성하고 있는데요.
결국은 좋은 Developer란 코딩 기술을 엄청 복잡하고 화려하게 잘 짜는 사람이 아니라,
열 줄의 코드를 쓰더라도 명확한 이유를 갖는 사람. 그리고 그 코드를 통해 의도하는 Buisness Value를 명확하게 전달할 수 있는 사람이라고 생각하게 되는 요즘입니다.
그래서 무슨 기획을 하더라도, 무슨 디자인을 하더라도, 무슨 기술을 쓰더라도 / 그 이유와 가치에 대해 한번 더 고민해야겠다고 느꼈습니다.
다음 챌린지는 이 배움에서 비롯되어, 기술적인 이유를 찾는 목표를 설정해보고자 합니다!
참 배운 것 많았고 행복했던 챌린지 쓰리였습니다!
다시 또다시 매번 느끼지만, 혼자서는 이런 배움을 경험해보지 못했을 거고. 중간마다 마주쳤던 어려움들을 아마도 스스로는 쉽게 이겨내지 못했을 것이라는 것.
좋은 팀 문화와 프로덕트는 좋은 사람들과 함께 만들어나갈 때 더 ✨빛✨을 낸다는 것 또 배워갑니다!
이번 챌린지의 무엇보다 가장 큰 얻음은 사람이었던 것 같아요.
너무나도 멋진 내 C3 팀원들, 에코 콘 엘리안 유니아 글로니에게 고마움을 샤라웃하며 이번 회고도 마무리👍🏻 C4 때 돌아오겠습니다앗~!