2024년 7월 13일 강원과학고 학생 24명과 AWS 오피스 투어·멘토링 프로그램의 일부로 Working Backwards 워크숍을 진행했습니다. 만족도는 5점 만점에 4.6점이었지만, 이 사례에서 더 중요했던 결과는 학생들이 기술 이름으로 시작한 아이디어를 자신이 직접 본 문제의 언어로 다시 썼다는 점입니다.
인터넷에서 찾은 문제보다 직접 본 장면을 먼저 꺼냈다
학생 프로젝트는 “환경 문제를 AI로 해결한다”, “교통을 더 편리하게 만든다”처럼 큰 주제로 시작하기 쉽습니다. 의미 있는 주제지만, 실제 사용 장면이 없으면 팀이 무엇을 관찰하고 무엇을 검증해야 할지 정하기 어렵습니다.
첫 활동에서는 기술을 잠시 빼고 각자가 최근에 직접 본 불편을 적었습니다. 교실, 기숙사, 통학, 동아리 활동처럼 구체적인 공간과 시간을 붙였습니다. 같은 “시간 낭비”도 누가, 언제, 어떤 선택을 못했는지에 따라 전혀 다른 문제가 됐습니다.
팀은 관찰과 해석도 분리했습니다.
관찰: 점심시간마다 학생들이 메뉴를 확인하려고 여러 채널을 다시 찾는다.
해석: 정보가 없다.
가설: 필요한 순간에 한 화면으로 제공하면 선택 시간이 줄어든다.관찰을 그대로 남기면 첫 해결책이 틀렸을 때도 문제 정의로 돌아갈 수 있습니다.
“좋은 아이디어” 대신 반박할 수 있는 질문을 줬다
학생이 아이디어를 발표했을 때 바로 칭찬하면 첫 해결책이 정답처럼 굳어질 수 있습니다. 피드백은 아이디어 평가보다 가설을 검증하는 질문으로 바꿨습니다.
- 그 장면을 실제로 몇 번 보았는가
- 불편을 겪는 사람은 지금 어떻게 해결하는가
- 이 기능이 없어도 문제를 줄일 더 단순한 방법이 있는가
- 데모에서 고객의 어떤 행동이 달라져야 성공인가
질문의 목적은 아이디어를 어렵게 만드는 것이 아니었습니다. 팀이 자신들의 관찰과 해결책 사이의 연결을 직접 설명하게 하는 것이었습니다. 대답할 수 없는 질문은 실패가 아니라 다음 조사 항목이 됐습니다.
24명에게 같은 속도와 같은 결과를 요구하지 않았다
기술 경험과 발표 자신감이 다른 학생들이 같은 시간표로 움직이면, 빠른 팀은 기능을 과하게 늘리고 느린 팀은 문제 문장을 완성하기 전에 구현으로 넘어가기 쉽습니다.
그래서 팀마다 같은 결과물보다 같은 전환 조건을 사용했습니다.
- 한 고객을 구체적으로 말할 수 있는가
- 직접 본 장면과 추측을 구분했는가
- 해결책 없이도 문제를 설명할 수 있는가
- 데모가 한 가설을 확인하도록 줄어들었는가
조건을 충족한 팀은 prototype으로 넘어갔고, 그렇지 않은 팀은 인터뷰 질문이나 관찰 범위를 더 다듬었습니다. 모두가 같은 분량을 만들지 않아도, 어떤 판단을 거쳐 다음 단계로 갔는지는 비교할 수 있었습니다.
오피스 투어를 진로 소개에서 프로젝트 질문으로 연결했다
오피스 투어와 현업 멘토링은 기술 직무를 소개하는 데서 끝날 수도 있습니다. 이번에는 멘토에게 들은 역할과 협업 방식을 팀의 프로젝트 질문으로 다시 가져오게 했습니다.
예를 들어 “실무에서는 요구사항이 바뀐다”는 설명은 FAQ의 질문이 됐고, “운영자는 장애 때 여러 정보를 함께 본다”는 이야기는 사용자 장면과 필요한 data source를 다시 생각하게 했습니다. 직무 정보가 프로젝트 밖의 별도 세션이 아니라 문제 정의와 architecture 가정에 들어갔습니다.
워크숍 뒤에는 작은 관찰 하나를 남겼다
하루 안에 완성된 제품을 만들 수는 없습니다. 대신 각 팀이 다음 주에 할 수 있는 한 번의 검증을 정했습니다. 친구 세 명에게 같은 장면을 물어보기, 종이 prototype으로 선택 시간을 재보기, 필요한 데이터가 실제로 존재하는지 확인하기처럼 작은 행동이었습니다.
만족도 4.6은 세션 경험을 보여 주지만 프로젝트의 지속성을 보장하지는 않습니다. 더 오래 남는 것은 학생이 “AI로 무엇을 만들겠다”에서 멈추지 않고, 어떤 관찰을 했고 다음에 무엇을 확인할 것인지 자기 언어로 설명할 수 있게 된 것입니다.
댓글