테오의 스프린트 18기 참가 후기

December 26, 2024

들어가며

좋은 사람들과 함께 잘 만들어진 협업 프로세스를 배우고 경험한다.라는 슬로건으로 운영중인 테오의 스프린트에 드디어 참여했다. 후기 글들과 스프린트 결과물을 보면서 꼭 한번 참여해 보고 싶었는데 항상 시간이 안 맞아서 참여하지 못해서 항상 아쉬웠다. 컨퍼런스 발표를 마치고 숨을 돌리고 있던 와중에 모집 글이 올라와서 다행히 이번엔 참여할 수 있겠다 싶어서 부리나케 지원 폼을 작성했다.

테오의 스프린트란

구글 스프린트는 짧은 시간 내에 아이디어 검증을 하기 위한 그럴싸한 MVP를 효율적으로 만들어내는 방법론입니다. **[6일간 좋은 사람들과 잘 만들어진 협업 프로세스를 함께 경험한다]**라는 슬로건 아래 스프린트를 직접 경험해 본 9명의 퍼실리테이터가 모여, 스프린트에서의 경험을 잘 이어가기 위해 1개월간 열심히 준비했습니다. 다양한 생각과 경험이 모여 더욱 풍성한 스프린트가 되길 기대합니다.

https://teo-sprint.oopy.io/

테오의 스프린트는 위에서 소개한 내용처럼 아이디어 검증을 위한 협업 프로세스를 타이트하게 경험할 수 있는 스프린트이다.

스프린트에서 어떤 걸 경험하고 배웠는지 날짜별로 정리해 봤다.

Day1. 팀 캔버스 작성하기

우리는 아이디어를 중심으로 팀을 구성했다. 나도 아이디어를 냈는데 놀랄 만큼 아무런 관심도 받지 못했다. 하지만 그런 아이디어들이 꽤 여럿있었고 다른 좋은 아이디어들이 많아서 딱히 신경쓰진 않았다. 😅

아이디어: 즉석 대화 소재 생성기

내가 선택한 아이디어는 즉석 대화 소재 생성기이다. 낯선 사람과 대화할 때 할 말이 없으면 대화 소재를 추천해주는 서비스인 것이다. 정말 나같은 사람에게 필요하겠다 싶어서 냅다 선택했다. 하지만 나같은 사람들이 많아서 우리 팀의 아이디어는 반응이 뜨거웠고 많은 사람들이 모였다.

팀 빌딩

우리는 1조가 되었고 서로에 대해 알아가는 시간을 가졌다. 다양한 사람들이 모였는데 우리는 공통적으로 모두 MBTI I였고 아이디어에 대해 많이 공감하는 사람들이었다.

그리고 나서 우리는 여러가지 이야기를 나눴다.

팀의 성공을 어떻게 정의할 것인가?

공통적인 의견으로는 서비스의 완성, 그리고 사용자가 있을 것이었다. 생각이 잘 맞아서 좋았다.

우리 서비스는 어떤 가치를 줄 것인가?

우리는 좋은 대화 소재를 추천하고 누구나 빠르게사용할 수 있게 하고 싶었다.

그 외에 우리는 가진 능력과 기술스택, 약점과 리스크, 꼭 지켜줬으면 하는 규칙에 대한 얘기를 나누면서 팀 캔버스를 완성했다. 이런 내용들도 미리 얘기를 하니까 협업하면서 생길 수 있는 이슈에 대해 미리 생각해볼 수 있었고 서로 어떤 부분을 걱정하는지 알 수 있었다.

숙제로 비슷한 앱의 레퍼런스를 찾아 왔었는데 우리 아이디어를 실현한 앱들이 꽤 보여서 놀랐다. 이 앱들에서 찾은 아쉬운 점들을 개선해서 우리 서비스에 넣으면 좋지 않을까 하는 생각을 했다.

Day2. 지도 그리기

Day2는 생각의 주파수를 맞추는 날이었다. 그라운드 룰이 있었는데 아래와 같았고 굉장히 인상깊었다.

결정하지 않기
- 새로운 가능성을 차단하지 않는다.
- A vs B 가 아니라 A + B = C가 되도록
기록하기
리액션하기

이 룰들을 가지고 또 여러가지 이야기를 나눴다.

서비스의 목적

우리는 서비스의 목적을 대화의 어려움 해소, 즐거운 대화라고 생각했고 말을 잘 못하는 I들을 타겟이라고 생각했다. 한 팀원분은 서비스 타겟이 우리 팀이라고 적었는데 맞는 말이었다. 😅

Pain/Wow Point

기존 사람들이 목적을 달성하기 위해 어떤 행동을 하고 있는지를 생각해 봤을 때 이런 것들이 있었다.

그냥 침묵하기
관심사를 명찰이나 옷에 붙이기
어떻게든 머리 짜내기

그리고 우리가 찾았던 비슷한 서비스들엔 어떤 아쉬운 부분들이 있었을까 생각해봤는데 아무도 그런 앱이 있다는 것을 알지 못했고 찾아보려는 생각조차 못했었다는 것이 공통된 의견이었다. 그래서 일단 이런 부분들이 기회가 될 수 있겠다는 생각이 들었다. 그리고 우리 앱을 사용해서 대화를 쉽게 할 수 있다는 것을 깨달으면 그게 WOW point가 되지 않을까 하는 생각이 들었다.

워드 클라우드 만들기

우리가 얘기할 때 나왔던 단어들을 가지고 워드 클라우드를 만들었다. 빈도수가 높았던 단어일수록 크게 작성했다. 불편, 부담, 다양한 주제, 침묵 등이 눈에 띈다.

어떻게 하면~ 질문 만들기

이 활동이 상당히 인상적이었다. 우리가 갖고 있는 고민 포인트들을 구체화할 수 있었고 해소하는 방법에 대해 생각해 볼 수 있었다.

어떻게 하면 이 앱을 꺼낼 때 부담스럽지 않을 수 있을까?

이 앱을 어떻게 자연스럽게 꺼낼 수 있을지에 대한 고민에서부터 나온 질문이다. 낯선 사람과 앉아 있는데 갑자기 이 앱을 꺼내면서 대화를 시작하면 상대방도 당황하지 않을까 하는 생각이 들었다. 그래서 “빌드업을 하면 괜찮을 거 같다.”, “상대방이 이 앱을 인지하고 거부감을 줄일 수 있는 시간이 필요하다. ex) 앱에 게임을 같이 제공”는 의견들이 나왔다.

어떻게 하면 다양한 주제의 토픽을 효과적으로 분류할 수 있을까?

우리 주제들을 어떻게 분류해야 사용자가 쉽게 사용할 수 있을지에 대한 고민도 했다.

다른 서비스와 차별화된 주제

어떻게 하면 우리 서비스의 주제들을 차별화할 수 있을지에 대한 고민도 했다.

이런 질문들을 통해서 핵심적인 고민거리에 대한 서로의 생각을 들어볼 수 있었다.

기능 및 페이지 정리

다음으로는 필요한 기능들을 쭉 나열하고 페이지별로 나누고 정리하는 시간을 가졌다.

화면 스케치

숙제로는 각자가 생각하는 화면을 스케치했다.

Day3. 스케치

Day3에서는 각자의 스케치를 화면 별로 정리하고 좋았던 요소에 투표를 하는 시간을 가졌다. 여기서 좋았던 요소에 투표를 하는 게 인상적이었다. 이것도 A + B = C가 되도록 하는 장치였다.

서로의 스케치를 보면서 스케치도 각자가 생각하는 게 달라서 정말 신기했다. 다양한 스케치들이 나왔다.

요소에 투표했던 예시를 들어보면 아래 처럼 토픽 추천받아 대화 시작해보기 버튼에 많이 투표를 했다. 밸런스 게임을 통해서 어느정도 어색함이 사라지면 바로 대화를 시작할 수 있게 하는 장치여서 좋다고 생각했다.

이렇게 투표를 하고 UX/UI 최고 권위자를 뽑았다. 우리 팀은 디자이너가 있기 때문에 자연스레 디자이너가 최고 권위자가 되었다.

또 PL(Project Leader)를 뽑았는데 내가 맡았다. 아무래도 회사에서 하는 역할이랑 비슷한 거 같기도 하고 데모 퀄리티를 꼭 지켜보고 싶었다. 잘 해낼 수 있을 거라는 근거 없는 자신감도 뿜뿜했다.

우선순위 결정

그럴싸함 챙기는 법을 읽었는데 대부분 하고 있던 생각이랑 비슷했다. 하지만 미구현 기능에 대해 '준비중입니다' 알림 띄우기 항목이 인상적이었다.

다음으로는 임팩트와 Effort(걸리는 시간)을 기준으로 기능들의 우선순위를 나눴다.

Day4. 결정하기

드디어 결정하는 시간이 왔다. 이제까지의 활동에는 결정하는 시간이 없어서 몸이 근질거렸다.

BDD로 태스크 분배

사용자의 행위를 중심으로 태스크를 나눴다. BDD를 처음 해봐서 이게 맞나 걱정이 됐지만 그래도 얼추 잘 해낸 거 같다.

태스크를 분배하고 컨벤션, 기술스택, 배포에 대한 결정을 했는데 프론트엔드 팀원들은 대부분 스택이 비슷했기 때문에 정하는데 크게 어려움은 없었다.

Day5~6. 개발

주말에 드디어 개발을 했다. 개발을 이틀만 하니까 시간이 많이 부족하긴 했는데 초반부에서 생각을 맞추는 활동들을 하다 보니까 확실히 많은 시간이 들고 꼭 필요한 시간들이라는 생각이 들었다. 이렇게 하는 게 맞다는 생각이 들었다. 이렇게 많은 시간을 투자했는데도 아직도 생각이 다른 부분들이 남아 있을 수 있기 때문이다.

개발할 때는 PL로서 아래 항목들을 챙기려고 노력했다.

스케쥴 투명하게 관리
- 작업 가능한 시간, 불가능한 시간 공유
- 온라인이면 zep에 항상 들어 와 있기
  - 소통하기 편하고
  - 궁금한 거 봐주고
- 자리 비울 때 디스코드에 올리기
작업 상황 투명하게 관리
- 노션에 todo로 관리
  - 실패(?)
  - 모두가 해당 항목에 동의했고 멤버들을 초대하려고 메일을 남겨달라고 했지만 전부가 남기진 않았음. 그래서 활용하지 못했음.
  - 하지만 노션 없이도 빠트린 내용없이 잘 완수했음. -> 우리 팀엔 필요없는 거 같음!
도와주기
- 모르는 거 봐주기
서로의 작업물 연결하기
- 밸런스 게임 2명, 토픽 추천 2명 이렇게 맡았기 때문에 서로의 작업물을 연결하는 작업을 해야했다.
적절히 위임하기
- 챙기려고 했으나 신경써야 할 게 너무 많아서 밸런스 게임 주제, 대화 소재 등 데이터 부분을 백엔드에 챙겨달라고 위임.
- README → 써 본 경험 있는 팀원에게 위임. 대신 그 팀원의 개발 태스크를 도와줌.
먼저 배포하기
- 배포하면 문제가 생기는 경우가 많아서 미리 미리 배포해보기
  - 실제로 배포했는데 api가 안 불러와져서 보니까 vercel에 환경변수 등록하는걸 빼먹었었음
덜어내기
- 카드 UI, interaction가 굉장히 어려웠다. 이 부분을 조금 덜어냈어야 했는데 그거라도 없으면 너무 심심할 거 같아서 미련을 좀 가지고 시간을 투자했다. 역시나 빠르게 덜어내는 게 더 나았을 것이라는 생각을 했다.

Day7. 데모

개발을 무사히 마치고 데모날이 왔다. 그리고 이렇게 메시지를 남겼다. 기능을 마무리하고 서비스에 크게 지장이 없는 선에서 챙길 수 있는 디테일을 계속 챙겨 나가다 보니 직전까지 정신이 없었다.

페어 데모

데모는 아래의 방식으로 진행했는데 데모를 하는 방식도 인상깊었다. 데모를 위한 데모가 아니라 정말 유저의 찐 반응을 볼 수 있도록 설계된 거 같아서 마음에 들었다.

사람 사는 거 다 똑같구나

테오의 스프린트에서는 모두가 매끄러운 경험을 할 줄 알았는데 데모 때 보니까 사람 사는 거 다 똑같구나 하는 생각이 들었다. 디자이너가 도중에 이탈한 팀도 있고 배포했는데 문제가 생겨서 데모를 못한 팀도 있었다. 참 안쓰러우면서도 내가 정말 운이 좋아서 좋은 사람들을 만난 거였구나 하는 감사한 마음이 들었다.

회사에서 이 경험을 공유했을 때 한 분이 “물론 운이 좋았다고 하실 거 같지만 그것 외에 데모를 성공적으로 마칠 수 있었던 비결이 뭐라고 생각하시나요?”라는 질문을 하셨다. 그 분이 원하는 대답을 하고 싶었지만 아무리 생각해봐도 이건 “운이 좋았다.” 라고밖에 설명할 길이 없었다. 좋은 사람들이 모여서 맡은 바 역할을 다 한 게 성공의 요인이었다는 게 내 결론이다.

팀 회고

데모 후에 팀 회고를 하면서 스프린트를 마쳤다.

모두 소통도 잘 되고 책임감 있게 서로의 역할을 다 했던 부분들이 좋았다고 작성했고 완성할 수 있어 좋았다고 했다. 의견을 나눌 때도 서로 잘 들어주고 존중하면서 진행했던 부분이 좋았다.

아쉬웠던 부분은

데이터 부분이 조금 아쉬웠는데 대화 소재는 아이디에이션을 하고 투표를 해서 높은 투표 수를 받은 소재들을 위주로 쓰고 싶었는데 마음이 급해서 아이디에이션까지밖에 하지 못했다.
밸런스 게임도 선택지 별로 질문을 다 다르게 하고 싶었는데 시간상 질문을 통일해야 했다. 하지만 질문을 통일하다 보니까 질문과 답변 사이 관계가 어색한 부분이 있었다.
데모 때 카드가 스와이프 되는 걸 몰랐다는 피드백을 받았는데 이 부분이 많이 아쉬웠다. 시간 관계상 디자인을 바꿨는데 우리 팀원들이야 스와이프 되게 만들었다는 걸 알지만 모르는 사람이 봤을 때 스와이프 된다는 걸 충분히 인지하지 못 할 수 있었기 때문이다.