Apple Developer Academy에 들어온 뒤 CBL(Challenge Based Learning)을 계속 경험하고 있다. 처음에는 CBL을 하나의 프로세스처럼 이해했다. 질문을 정하고, 그 질문을 탐구하기 위한 활동을 정하고, 리서치를 하고, 결과물로 이어가는 방식이라고 생각했다.

물론 그 이해가 완전히 틀렸다고 생각하지는 않는다. CBL에는 분명 구조가 있고, Guiding Question(GQ)과 Guiding Activity(GA)처럼 팀이 탐구를 이어가기 위한 언어가 있다. 다만 사이드 프로젝트 팀을 운영하면서 느낀 것은, 좋은 CBL이 단순히 그 순서를 잘 따르는 것만은 아니라는 점이었다.

내가 지금 이해하고 있는 CBL은 절차라기보다 팀이 모르는 것을 알아가는 방식에 더 가깝다.

이번 글에서는 사이드 프로젝트 팀에서 CBL을 더 오래 붙잡아보며, 결과물을 먼저 정하지 않았을 때 오히려 제품 방향이 어떻게 더 선명해졌는지 정리해보려고 한다. 그리고 이 과정이 항상 깔끔하거나 빠르기만 했던 것은 아니라는 점도 같이 남기고 싶다.

메인 챌린지에서 느낀 아쉬움

아카데미의 메인 챌린지를 통해 CBL을 처음 경험했다. 그 과정에서 CBL이 어떤 방식으로 작동하는지, 문제를 어떻게 바라보고 질문을 어떻게 만들 수 있는지 배울 수 있었다.

하지만 개인적으로는 CBL을 충분히 오래 붙잡기 어렵다고 느낀 순간도 있었다. 챌린지 기간이 짧기도 했고, 때로는 결과물이나 기술 조건, 주제의 제약이 먼저 존재했다. 그래서 CBL을 경험하기는 했지만, 정말 우리가 아는 것과 모르는 것을 끝까지 따라가며 탐구했다는 감각은 조금 부족했다.

이것이 아카데미의 메인 챌린지가 좋지 않았다는 뜻은 아니다. 오히려 그 과정이 있었기 때문에 CBL이라는 언어를 배울 수 있었다. 다만 나는 그 언어를 조금 더 오래 써보고 싶었다. 정해진 시간 안에 결과물을 만들어야 하는 상황이 아니라, 팀이 정말로 어떤 질문을 붙잡고 어디까지 탐구할 수 있는지 보고 싶었다.

그래서 사이드 프로젝트 팀을 만들 때는 다른 실험을 해보고 싶었다. 처음부터 결과물을 목표로 두지 않는 팀을 만들어보고 싶었다. 결과물은 우리가 지나가는 마일스톤일 뿐이고, 진짜 목표는 좋은 탐구와 좋은 협업을 배우는 것이라고 생각했다.

결과물을 늦게 정하자 질문이 더 오래 남았다

처음 우리 팀은 할 일 관리를 돕는 IoT 기기를 떠올렸다. 만약 바로 만들기 시작했다면 꽤 자연스럽게 기능을 더하는 방향으로 갔을 가능성이 크다.

할 일을 잊지 않게 알림을 주고, 할 일을 기록하고, 사용자가 놓친 일을 다시 보여주는 식의 제품을 상상했을 것이다. 이런 방향이 틀렸다는 뜻은 아니다. 다만 그때 바로 만들기 시작했다면, 우리가 정말 해결해야 하는 문제가 무엇인지는 충분히 보지 못했을 수도 있다.

그래서 우리는 질문을 조금 더 오래 붙잡았다.

사람들은 왜 할 일 관리를 어려워할까. 할 일을 못하는 것과 할 일 관리를 못한다고 느끼는 것은 같은 문제일까. 습관은 의지의 영역일까, 자동화의 영역일까. 할 일 관리를 잘하는 사람과 못하는 사람의 차이는 무엇일까.

이 질문들을 정리하면서 CBL의 의미가 조금 다르게 보이기 시작했다. CBL을 잘한다는 것은 GQ와 GA를 형식에 맞게 채우는 일이 아니었다. 지금 우리가 아는 것이 무엇인지, 모르는 것이 무엇인지, 알아야 하는 것이 무엇인지를 계속 구분하는 일이었다.

우리 팀은 회의할 때 포스트잇을 많이 썼다. 각자가 떠올린 생각을 바로 말로 밀어붙이기보다, 일단 포스트잇으로 꺼내놓고 서로의 맥락을 확인했다. 발산과 수렴의 과정에서도 각자의 생각을 포스트잇으로 놓고, 공통점과 차이점을 보고, 다시 연결되는 지점을 찾았다.

이 과정은 단순히 회의를 보기 좋게 정리하기 위한 것이 아니었다. 우리가 무엇을 알고 있는지, 무엇을 모르고 있는지, 무엇을 더 알아야 하는지를 눈앞에 꺼내놓는 방식에 가까웠다. 말로만 회의하면 모두가 비슷하게 이해한 것처럼 느껴질 수 있다. 하지만 포스트잇으로 꺼내놓으면 서로가 같은 단어를 다르게 이해하고 있었다는 것이 보이기도 한다.

GA는 정해진 활동이 아니라 질문에 맞는 활동이었다

GQ가 우리가 붙잡아야 하는 질문이라면, GA는 그 질문을 알아가기 위한 활동이다. 처음에는 GA를 리서치, 인터뷰, 관찰 같은 정해진 방법 중 하나를 고르는 것으로 생각하기 쉽다.

하지만 실제로 팀에서 탐구를 해보니, GA는 정해진 방법을 따르는 것이 아니라 질문에 가장 잘 답할 수 있는 방법을 찾는 과정에 가까웠다.

한 번은 “습관은 자동화의 영역인가, 의지의 영역인가”라는 질문을 탐구해야 했다. 이 질문은 단순히 검색 몇 번으로 끝낼 수 있는 질문처럼 느껴지지 않았다. 습관이라는 말은 너무 익숙하지만, 실제로 사람들이 어떤 순간에 행동을 자동으로 하고, 어떤 순간에 의지를 써야 한다고 느끼는지는 더 구체적으로 봐야 했다.

이 질문에 답하기 위해 우리 팀은 AI를 활용한 인터뷰를 실험했다. AI에게 답을 대신 맡긴 것이 아니라, 인터뷰를 어떻게 기획하고 준비하고 실행하고 정리할 수 있을지 실험해본 것이다. AI를 통해 질문을 구조화하고, 인터뷰 흐름을 점검하고, 정리 과정에서 놓친 관점을 다시 확인했다.

중요했던 것은 AI를 썼다는 사실 자체가 아니었다. 우리가 가진 질문에 답하기 위해 기존 방식만 반복하지 않고, 그 질문에 맞는 탐구 방법을 찾으려 했다는 점이었다.

만약 GA를 “정해진 활동 목록 중 하나를 고르는 것”으로만 생각했다면, 우리는 그냥 인터넷 리서치를 하거나 일반적인 인터뷰를 했을지도 모른다. 하지만 그때 우리에게 필요했던 것은 습관과 의지, 자동화에 대한 사람들의 실제 감각을 더 잘 이해하는 일이었다. 그러면 활동도 그 질문에 맞게 설계되어야 했다.

이 경험을 하면서 좋은 CBL은 절차를 정확히 밟는 것보다, 팀이 모르는 것을 알아가기 위한 가장 적절한 활동을 설계하는 일에 가깝다고 느꼈다.

제품 방향이 바뀐 이유

질문을 오래 붙잡자 문제 정의가 바뀌었다.

처음에는 문제를 “사람들이 할 일을 잊는다”에 가깝게 이해했다. 그런데 리서치와 논의를 계속하면서, 할 일 관리를 잘하는 사람과 못하는 사람의 차이가 단순히 기억력이나 의지의 차이는 아닐 수 있다는 생각이 들었다.

대부분의 사람은 결국 마감이 오면 일을 한다. 할 일 관리를 잘한다고 느끼는 사람도 놓치는 일이 있고, 할 일 관리를 못한다고 느끼는 사람도 결국 중요한 일은 어떻게든 해낸다. 차이는 단순히 할 일을 했는지 못 했는지에만 있지 않았다.

중요한 차이는 할 일을 처리하는 과정에서 스스로 체계가 있다고 느끼는지, 다음 행동으로 넘어갈 때 뇌에 얼마나 큰 부하가 걸리는지, 그 행동이 습관처럼 자연스럽게 이어지는지에 있었다.

할 일 관리를 잘하는 사람은 모드 전환이 비교적 가볍다. 무엇을 해야 하는지 알고, 다음 행동으로 넘어가는 데 드는 생각의 비용이 낮다. 반대로 할 일 관리를 어렵게 느끼는 사람은 해야 할 일을 알고 있어도, 그것을 시작 가능한 단위로 나누고 실행 모드로 전환하는 데 큰 부하를 느낄 수 있다.

그러자 우리가 만들어야 할 것도 달라졌다.

단순히 기능이 많은 기기를 만드는 것이 아니라, 할 일을 더 작게 나누고, 인지 부하를 줄이고, 반복 가능한 습관을 만들도록 돕는 도구에 가까워졌다. 결과물을 먼저 정하지 않았기 때문에, 오히려 결과물이 무엇이어야 하는지 더 정확히 보이기 시작했다.

이 지점에서 내가 배운 것은 꽤 단순했다. 결과물을 먼저 잡지 않는다는 것은 아무것도 만들지 않겠다는 뜻이 아니었다. 오히려 무엇을 만들지 더 정확히 알기 위해, 우리가 아직 모르는 것을 오래 바라보겠다는 뜻에 가까웠다.

이 방식이 항상 쉽지는 않았다

물론 이 방식이 항상 좋은 분위기와 빠른 진행을 만든 것은 아니었다.

우리는 사이드 프로젝트 팀이었고, 동시에 아카데미의 메인 챌린지도 병행하고 있었다. 회의를 하다가도 중요한 연락이 오면 바로 회신해야 할 때가 있었고, 체력적으로 지친 상태에서 다시 논의를 이어가야 할 때도 있었다. 모두가 늘 100% 몰입할 수 있는 구조는 아니었다.

또 한 번은 다이슨 디자인 어워드에 나가보자는 이야기가 나왔다. 기존 아이디어로 바로 나가기에는 대회 취지와 맞지 않는 부분이 있었고, 그래서 기존 아이디어를 잠시 홀드하고 다이슨 어워드용 아이디에이션 기간을 가졌다.

그런데 약 2주 동안 아무것도 정하지 못했다. 답답함과 피로가 컸다. 계속 탐구하고 토론하는 것이 항상 좋은 결과로 이어지는 것은 아니라는 것도 그때 느꼈다. 우리가 명확히 그 대회를 위해 모인 팀이 아니었기 때문에, 대회라는 외부 목적에 맞춰 아이디에이션을 하는 일이 생각보다 어려웠다.

결국 우리는 다이슨 어워드에 나가지 않기로 정리하고, 다시 원래 아이디어로 돌아왔다.

이 경험도 중요했다. 질문을 오래 붙잡는 것이 중요하다고 해서, 모든 질문을 끝없이 붙잡아야 한다는 뜻은 아니었다. CBL이 좋은 방식이라고 해서, 모든 상황에서 같은 속도와 같은 리듬으로 작동하는 것도 아니었다.

오히려 이 실패를 겪으면서 CBL을 조금 더 현실적으로 보게 됐다. 좋은 탐구에는 방향이 필요하고, 팀의 에너지와 목적도 중요하다. 질문을 오래 붙잡는 것과 결정을 미루는 것은 다르다. 우리가 지금 무엇을 알아야 하는지 명확할 때의 탐구는 팀을 선명하게 만들지만, 목적이 흐린 상태에서의 탐구는 팀을 지치게 만들 수도 있다.

내가 지금 이해하는 CBL

이 경험들을 통해 CBL에 대한 생각이 바뀌었다.

CBL은 결과물을 늦추는 절차가 아니었다. 아이디어를 일부러 미루는 방식도 아니었다. 오히려 너무 이른 아이디어로 팀이 좁아지지 않도록, 우리가 정말 알아야 하는 것을 더 오래 바라보게 만드는 방식이었다.

그리고 좋은 CBL은 팀이 계속해서 세 가지를 구분하게 만든다.

우리가 지금 아는 것.
아직 모르는 것.
그리고 다음으로 알아야 하는 것.

이 세 가지가 명확해지면 결과물도 선명해진다. 반대로 이 세 가지가 흐려지면, 아무리 빠르게 만들고 있어도 우리가 정말 맞는 것을 만들고 있는지 알기 어렵다.

물론 아직 내가 CBL을 완전히 이해했다고 말할 수는 없다. 지금도 배우는 중이고, 우리 팀의 방식이 모든 팀에 맞는다고 생각하지도 않는다. 메인 챌린지와 사이드 프로젝트는 조건도 다르고, 시간의 압박도 다르다. 큰 조직이나 빠른 의사결정이 필요한 상황에서는 다른 방식이 더 적합할 수도 있다.

다만 지금까지의 경험으로는 한 가지가 조금 분명해졌다.

좋은 CBL은 정답을 빨리 찾는 것이 아니라, 어떤 질문을 더 오래 붙잡아야 하는지 알아가는 일에 가깝다.

결과물을 목표에서 잠시 내려놓았을 때, 결과물이 사라진 것이 아니라 더 정확해졌다.