[강동7기 전Z전능 AI PM] 코멘토 청년취업사관학교 DAY 12
DAY 12 | 개인 디자인 스프린트 — 토스 프로덕트 디자이너 챌린지 문제로 연습해보기
오늘 수업은 개인 디자인 스프린트였다. 최복원 멘토님의 퍼실리테이팅으로 진행됐고, 주제는 토스 프로덕트 디자이너 챌린지 2026 문제 중 하나를 가져왔다.
“6명이 회의 일정을 잡는 경험을 설계하라”
조건은 이랬다. 회의는 1시간, 어떤 사람은 점심 직후를 피하고 싶어 하고, 어떤 사람은 특정 요일에 외근이 많다. 반드시 참석해야 하는 사람이 있고, 선택적으로 참석 가능한 사람도 있다.
디자이너 채용 과제이긴 하지만 문제 정의와 UX 설계는 PM의 핵심 역량이기도 해서, 실제 지원자처럼 문제 정의부터 프로토타입까지 전 과정을 혼자 밟아보기로 했다.
과제를 다시 읽기
처음 이 과제를 봤을 때 드는 생각은 명확했다. “캘린들리 같은 걸 만들면 되는 거 아닌가?” 근데 이 생각 자체가 함정이었다.
이 과제가 진짜 평가하려는 게 뭔지를 먼저 생각해봤다.
- 문제를 얼마나 좁고 정확하게 정의하는가: “일정 잡기 어렵다”는 누구나 아는 사실이고, 이걸 구성 요소로 쪼갤 수 있는지가 관건
- 제약 조건을 다루는 방식: 필수 참석자, 선택 참석자, 개인별 회피 시간, 요일별 외근이라는 서로 다른 성격의 제약이 섞여 있는데, 이걸 단순 교집합 문제로 풀면 과제 의도를 놓친 것
- 정보 비대칭을 어떻게 UX로 메울 것인가: 현실에서는 동료 6명의 캘린더와 선호를 한 번에 알 수 없다
빠지기 쉬운 함정도 정리해봤다. 기존 캘린더 앱 기능을 거의 그대로 재현하는 것, 모든 정보를 사용자에게 입력하라고 요구하는 것, 완벽한 시간이 없을 때의 예외 처리를 설계하지 않는 것. 이 세 가지를 피하는 게 목표가 됐다.
사용자를 다시 정의하다
처음엔 “회의를 주최하는 실무자” 한 명을 사용자로 놓고 시작했다. 근데 스스로 이런 질문을 던졌다.
“부담을 없애고 싶다면, 주최자 한 명만 봐도 되는가?”
일정 조율이 실패하는 근본 원인을 들여다보면, 정보가 주최자 한 사람에게만 몰려서 그 사람이 병목이 되는 구조였다. 그래서 사용자 정의를 “주최자 1명”에서 “주최자와 참석자 5명의 양면 구조”로 확장했다. 참석자 쪽 설계 원칙은 “최소 입력, 1탭 이내 응답” 으로 못박았다. 이 결정이 이후 모든 설계의 방향을 바꿨다.
Pain Point 분석
주최자와 참석자 양쪽 시점에서 현재 회의 일정 잡는 흐름을 그려봤다. 회의 필요성 인지 → 일정 확인 → 슬랙으로 후보 제안 → 응답 대기 → 취합 → 예외 발생 → 재조율 → 최종 확정까지.
Pain Point를 뽑아서 심각도, 빈도, 해결 가치로 우선순위를 매겨봤다. 가장 심각한 항목들의 공통점이 있었다. “탐색이 어렵다”는 문제가 아니라, “구조가 없어서 매번 사람이 수작업으로 정리해야 한다” 는 문제였다.
5 Whys로 계속 파고든 끝에 도달한 진짜 문제는 이거였다.
참석자의 역할과 제약이 재사용 가능한 데이터로 존재하지 않기 때문에, 매 회의마다 사람이 대화로 정보를 처음부터 다시 수집하고 계산해야 하는 구조
세 가지로 압축했다.
- 정보의 비영속성: 참석자 역할과 반복 제약이 데이터로 남지 않음
- 계산의 부재: 여러 사람의 제약을 조합하는 걸 사람이 대화로 대신 함
- 기준의 암묵성: 필수/선택 판단, 무응답 처리, 완벽하지 않은 시간에 대한 규칙이 없어 모든 예외 판단이 주최자에게 전가됨
여기서 스스로 반론도 제기했다. “정보를 구조화하면 해결된다”는 결론으로 바로 가면 함정이다. When2meet이나 Doodle도 이미 구조화를 시도했는데 문제가 반복되고 있으니, 진짜 관건은 “누가 그 구조화 비용을 지불하는가” 였다. 참석자에게 입력을 맡기는 비용이 슬랙 답장보다 높으면 아무도 안 쓴다.
장기 목표 & 스프린트 질문 & HMW
장기 목표
주최자가 혼자 모든 정보를 취합하고 책임지는 부담에서 벗어난다.
스프린트 질문
- 참석자가 응답하지 않을 때, 주최자는 재촉을 시스템에 온전히 맡길 수 있을까?
- 참석자들은 자신이 피하고 싶은 시간대 같은 선호사항을 입력하려고 할까? 귀찮아서 혹은 눈치 보여서 안 적지 않을까?
- 참석자들은 자신의 선호가 다른 동료에게 공개되는 것을 불편해하지 않을까?
HMW
- 어떻게 최종 결정에 대한 책임을 주최자 한 사람에게만 지우지 않을 수 있을까?
- 어떻게 참석자가 개인의 선호를 말하는 것에 부담을 느끼지 않게 할까?
- 어떻게 참석자가 응답하지 않을 때, 부담 없이 재촉할 수 있을까?
아이디어에서 솔루션으로
매력적이지만 리스크가 큰 아이디어는 과감히 뺐다. 예를 들어 “참석자의 응답 패턴을 주최자에게 참고 정보로 제공”하는 아이디어는 효율적으로 보였지만, 사실상 참석자를 감시하는 느낌을 줄 수 있어 폐기했다.
최종 UX 원칙 다섯 가지:
- 정보는 한 번 등록하면 계속 재사용된다
- 계산은 시스템이, 판단은 사람이 한다
- 참석자의 응답 비용은 슬랙 답장보다 낮아야 한다
- 예외는 예외로 처리하고 전체를 되돌리지 않는다
- 모호함을 화면이 대신 판단해주지 않는다
스스로에게 던진 질문들로 설계를 발전시키다
프로토타입을 만드는 과정은 정답을 그리는 작업이 아니라, 계속 질문을 던지고 그 답으로 설계를 고쳐나가는 작업이었다.
“미참석 사유를 텍스트로 받는 것보다, 사유별로 구조화하고 전달 방식까지 선택하게 하면 어떨까?”
HMW에서 던진 “참석자가 선호를 말하는 것에 부담을 느끼지 않게 하려면”이라는 질문이 여기로 이어졌다. 외근/다른 회의/개인 사정/기타로 사유를 구조화하고, “서면으로 받을게요” 또는 “다른 일정을 잡을게요” 중 당사자가 직접 고르게 했다. 선호를 직접 드러내는 게 아니라 구조화된 선택지 안에서 고르게 하면 심리적 부담이 줄어든다는 가설이었다. 여기서 “주최자와 1:1로 시간을 잡아 전달받는” 옵션도 고민했는데, 이건 주최자가 또 다른 일정 조율을 떠안는 구조라 시스템이 자동으로 캘린더를 맞춰주는 형태로만 성립하도록 조건을 붙였다.
“마감까지 응답이 없으면 어떻게 되는 건데?”
스프린트 질문 중 “재촉을 시스템에 온전히 맡길 수 있을까?”에서 출발한 질문이었다. 이 질문이 필수 참석자와 선택 참석자를 완전히 다르게 다뤄야 한다는 걸 깨닫게 해줬다. 필수 참석자에게는 50% 지점과 마감 2시간 전, 2단계로 리마인드하고, 그래도 응답이 없으면 봇이 계속 재촉하는 대신 주최자에게 “마감 연장” 또는 “직접 연락” 중 선택하게 하는 흐름을 새로 만들었다. 재촉의 부담을 시스템이 대신 지되, 최종 판단은 사람이 하는 구조다.
이런 질문들을 거치면서 프로토타입은 최종적으로 12개 화면으로 정리됐다.
더 풀어보고 싶은 것들
이번 스프린트에서 다 해결하지 못한 문제가 하나 남아있다. 참석자의 개인 선호 정보를 어떻게 다룰 것인가다.
현재 설계에서는 참석자가 피하고 싶은 시간대나 외근 요일 같은 정보를 입력하게 되어 있는데, 이 정보가 다른 동료에게 어느 범위까지 공개되어야 하는지 명확하지 않다. 개인 사정이 담긴 정보인 만큼 공개 범위와 표현 방식에 대한 설계가 더 필요하다. “회피 시간대”라는 워딩도 다시 생각해봐야 할 것 같다. 선호를 드러내는 게 아니라 제약을 신고하는 느낌이 들어서, 참석자 입장에서 부담스럽게 읽힐 수 있다.
돌아보며
이번 스프린트에서 가장 크게 배운 건, 문서로는 완벽해 보이는 설계도 실제로 화면을 만들어보면 반드시 빈틈이 드러난다는 것이다. 프로토타입을 직접 클릭해보고 나서야 “이 숫자는 대체 어디서 나온 거지?”라는 의심이 들었다.
또 하나는, 좋아 보이는 아이디어일수록 더 의심해야 한다는 것이다. “주최자가 혼자 정보를 취합하는 부담에서 벗어나게 하자”는 방향 자체는 맞았지만, 구현 방식에 따라 부담이 사라지는 게 아니라 형태만 바뀌어 다시 주최자에게 돌아올 수 있다는 걸 여러 번 확인했다.
완성된 프로토타입보다, 그 과정에서 스스로 발견하고 고친 구멍들이 이 스프린트의 진짜 결과물이었다.
오늘의 한 줄
“캘린들리 같은 거 만들면 되지”라는 첫 생각이 함정이었다. 문제를 다시 읽고, 사용자를 다시 정의하고, 스스로 반론을 제기하면서 처음 생각과 완전히 다른 방향으로 도달했다.
취업 부트캠프 청년취업사관학교 새싹 aipm dx교육 ai교육 실무프로젝트 실무경험 취업포트폴리오 포트폴리오 전z전능 코멘토 모비니티