오빠 톤 많아? w 테오의 스프린트 14기

설탕·2023년 5월 1일
2
post-thumbnail

✏️ 이 글은 테오의 스프린트 14기에 참여하여 오빠 톤 많아? 퍼스널 컬러 자가진단 서비스를 기획 및 개발한 과정을 담고 있습니다.

전부터 관심 있게 봤던 테오의 스프린트가 14기를 모집한다는 소식을 듣고 호다닥 참여 신청했다.

테오의 스프린트 취지: 5일간 좋은 사람들과 함께 잘 만들어진 협업 프로세스를 함께 경험한다.

시작하기 전, 아이디어를 준비해 가는 숙제가 있었다.

만들고 싶은 아이디어 글로 적어오기
🎈 Point: 스프린트는 "함께" 만들어 가는 것입니다. 아이디어를 너무 자세히 적지 마세요!

테오의 스프린트

DAY 1: 아이디어 선정, 팀 빌딩

아이디어 발표

각자 준비해온 아이디어를 발표했다. 아이디어 준비 및 발표가 모든 사람에게 필수는 아니었지만 @soojjung님의 도움을 받아 준비해온 아이디어가 있어서 발표했다. 참신하고 좋은 아이디어가 많았다.

내 아이디어: 퍼스널 컬러 팔레트

테오가 리스너의 반응을 강조했는데, 다들 반응을 잘해주셔서 발표할 맛이 났다. 이때 나온 반응도 기획의 방향성에 기여한 듯하다.

아이디어 선정 및 팀 구성

투표해서 득표수가 많은 아이디어들을 선정하고, 하고 싶은 아이디어에 지원하는 방식으로 팀을 구성했다. 내 아이디어보다 더 좋은 아이디어가 있으면 거기 참여하려고 했는데, 내 아이디어에 투표해주시고 지원해주신 분들이 있어서 내 아이디어로 계속 가게 됐다.

10조에 내 퍼스널 컬러 아이디어로 나까지 총 7명 팀이 구성되었다.
(하지만 첫째 날 이후로 2명이 탈주해서 5명이서 하게 됐다)
모두 프론트엔드 개발자였는데, 다행히 내 아이디어가 백엔드 없이 구현할 수 있는 서비스라서 팀원 추가 영입을 하지 않고도 원활하게 진행할 수 있었다.

팀 빌딩

팀 캔버스 주제

닉네임과 간단 소개, 스프린트에서 다같이 해냈으면 하는 목표, 개인의 목표, 우리 서비스의 궁극적인 목표, 우리 서비스에서 제일 중요한 가치, 나의 강점과 기술스택, 나의 약점과 리스크, 팀이 나를 위해 해줬으면 하는 것, 팀 룰

각 주제에 대해 팀원 각자의 생각을 쓰고 돌아가며 말하기를 통해 공유하며 팀 빌딩 시간을 가졌다.
밤늦은 시간에 처음 만난 사람들과 꽤나 많은 주제로 이야기 나누는 것이 쉽지는 않았지만, 테오가 강조한 대로 리스너들이 모든 텐션을 끌어올려서 반응해준 덕에 의지와 자신감을 갖고 말할 수 있었다.

첫째 날을 마치며 숙제: 레퍼런스 찾아오기

아이디어 구상할 때 생각한 유저 플로우에 따라 레퍼런스를 찾았다.
(아래 노란색 영역이 내가 찾은 레퍼런스)

DAY 2: 지도 그리기

둘째 날은 아이디어 발산의 날이다.
각자의 생각들을 펼쳐보면서 함께 생각의 주파수를 맞추어보는 시간이었다.

서비스의 목적, 대상, 핵심 가치 논의

스탬프로 도배된 쪽지들 ㅋㅋㅋ
스탬프 = 스피커의 의견을 잘 듣고 있다는 리스너의 반응

워드 클라우드

서비스의 목적, 대상, 가치에 대한 논의를 바탕으로 하나의 팀 생각으로 추상화했다.

어떻게 하면 ~할 수 있을까 질문 만들어 답하기

워드 클라우드의 키워드를 바탕으로 구체적인 방법을 찾는 과정이다.
어떻게 하면 ~할 수 있을까 질문을 만들고, 레퍼런스를 보여주면서 해결책을 이야기하며 아이디어를 확장해갔다.

지도 그리기

키워드별로 줌인하면
공유하기

쉽다 UI/UX

서비스에 넣고 싶은 요소 찾기

논의를 토대로 서비스에 넣고 싶은 기능/장치/요소들을 써보았다.

화면과 유저 스토리를 통해 지도 완성하기

앞에서 작성한 요소들을 같은 화면을 기준으로 그룹화하고 유저 스토리에 따라 순서를 배치하며 유저 플로우를 점검했다.

이렇게 둘째 날 지도 그리기를 마무리하며 숙제!

DAY 3: 스케치, 결정, 설계

셋째 날은 아이디어 수렴 및 선택과 결정의 날이다.

스케치

스토리보드의 페이지별로 각자 상상한 화면을 스케치하고 발표했다.

그러면서 세부 기능에 대한 논의도 곁들이고 ...
사진에서 얼굴 영역을 선택할 때 직접 크롭하는 기능으로 결정됐는데 나중에 누끼 따는 기능도 찾아봐야겠다.

결정의 시간: UX 결정권을(를) 획득했다!

결정을 위해 UX/UI 최종결정권자와 PL(Project Leader)을 투표로 뽑았다.

UX/UI 결정권자는 내가 됐다! 페이지별로 각자 좋다고 생각하는 스케치에 투표하고, 득표수가 많은 스케치 위주로 최종 UI를 결정했다.

PL도 결정된 김에 굉장히 어그로가 잘 끌린 많은 관심을 받게 한 프로젝트 이름과 팀명도 정하고 ...

BDD와 SDD를 통한 설계

프론트엔드의 개발을 크게 데이터 - 화면 - 행동으로 구분할 수 있습니다. 화면을 보고 사용자는 행동을 하며 행동데이터의 변화를 야기하고 데이터의 변화는 다시 화면으로 그려지는 계속 되는 사이클의 반복이 곧 프론트엔드 프로그래밍입니다. (테오)

  • BDD(Behavior Driven Development: 사용자의 행동을 중심으로 개발을 진행하는 방식
  • SDD(Schema Driven Development): 데이터를 중심으로 추려내고 개발을 진행하는 방식

결정된 화면을 바탕으로 화면에서 일어나는 사용자의 행동데이터의 변화를 정리해보았다.
그리고 임팩트(가치)와 노력(시간비용)을 고려하여 우선순위를 결정한 후 태스크를 분배했다.

나는 사진 업로드 페이지 구현을 맡았다. (테오의 스프린트 끝나고 나서는 모든 페이지를 다 손보긴 했다.)

우선순위 낮음으로 매겨져서 결국 버려진 퍼스널 컬러 설명 모달 ...
퍼스널 컬러 유형 전체보기도 만들까 하다가 우선순위 낮아서 버리고 그냥 배포했는데 다음 버전에 넣을지 말지 아직도 고민이다.

기술 스택 결정

마지막으로 기술 스택과 Git branch 전략을 정했다.
이때는 나와 다른 팀원 한 분이 TypeScript가 아직 생소해서 제한시간 내 빠른 개발을 위해 일단 JavaScript로 정했다.
스타일링은 나는 tailwindCSS가 더 빠르게 개발 가능하다고 생각했지만 한번도 써보지 않은 팀원들이 있었기에 마찬가지로 안전하게 빠른 개발을 위해 styled-components로 정했다.
얼굴 사진 데이터를 전역으로 관리하기 위해 recoil을 도입했고, 메인 화면에 표시할 사용자 수(n명이 진단했어요!)를 저장하기 위해 firebase DB를 도입했다.
yarn, vite, recoil, firebase 모두 나는 처음 써보는 것들이었는데 팀원분들이 사용법을 잘 알려주셔서 어렵지 않게 적용할 수 있었다. 이번 기회로 알게 되어서 다른 프로젝트에도 도입할 수 있었다. 👍

DAY 4~5: 개발

이제 진짜 개발 시작!

서비스 릴리즈가 아니라 아이디어를 검증하는 MVP 단계이기에 기능의 완벽한 구현보다는 협업 경험을 중시하고 그럴싸한 완성도를 먼저 만들어내는 것이 훨씬 더 중요합니다. (테오)

MVP 개발

팀원분들께도 계속 말씀드렸지만, 내가 지금까지 다른 프로젝트들을 통해서 느낀 것이 있다면 계획이 거창하고 원대할수록 완성에 다가가기 어렵다는 것이었다. 완성도를 챙기기 위해 갖가지 욕심은 내려놓고 MVP를 구현해서 서비스가 운영될 수 있는 최소한의 필수 기능을 충족하는 데 중점을 뒀다. 우리 서비스에서 MVP는 사용자가 사이트에 접속 - 테스트 시작 - 얼굴 사진을 선택 - 퍼스널 컬러 테스트 진행 - 테스트 결과 확인 - 공유까지의 플로우가 이루어져야 했다.

기능의 우선순위를 정한 것이 도움이 많이 되었다. 기획에 있었어도 우선순위가 낮은 기능은 정해진 시간 내에 구현이 안 될 것 같으면 아예 빼버렸고, 결과적으로 우선순위가 높은 핵심 기능의 완성에 집중할 수 있었다.

서비스의 완성도

어쨌든 데모 데이에는 데모를 발표해야 했기에 favicon, og meta tag 등을 설정해 서비스의 그럴싸함도 챙겼다. README도 데모 발표 직전에 작성했다.
기능 없는 버튼만 있지 않도록, 우선순위가 낮아서 구현하지 않은 기능은 버튼을 display: none 처리해서 보이지 않게 했다.

디자인

우리 팀에는 디자이너가 없었지만 아무래도 서비스의 완성도를 위해서는 통일된 디자인 목업이 있어야겠다고 생각했다.
그래서 내가 만들었다. 디자인 가이드.
팀원분들이 내가 UI/UX 결정권자라고 존중해주셔서 내가 디자인한 그대로 구현을 해주셨다...!

협업

테오의 가이드대로 페어 프로그래밍을 하기 위해 우리 팀은 따로 짝을 정하지는 않았고, 시간이 맞는 팀원끼리 함께 화면을 공유하면서 개발하기로 했다. 개발 중인 화면을 공유하여 함께 보고 이야기하면서 개발하는 과정이 원활한 협업에도 도움이 되었고 다른 팀원의 코드나 사고 과정, 개발 습관을 배울 수 있는 좋은 기회가 되었다.

GitHub issue와 회의를 통해 팀원들과 진행 상황을 공유하고, 자신이 맡은 태스크를 먼저 완료한 팀원이 다른 팀원을 도와주는 방식으로 진행해서 목표한 MVP를 구현하고 배포할 수 있었다.

DAY 6: 데모 데이

데모

(테오) 우리가 하고자 하는 것은 이틀 안에 완성이 아니라 이틀 동안 우리가 앞으로 만들어갈 서비스의 가치를 검증할 수 있는 데모를 만들고 있다는 것을 잊지 말아주세요.
웹서비스는 완성이라는 것은 없고 언제나 미완성인 상태로 계속 업데이트를 할 수 있는 형태를 취하게 됩니다. (구글도 10년째 업데이트 중입니다.) 그렇기에 우선은 돌아갈 수 있는 데모나 간단한 시제품을 먼저 만들고 검증을 통해서 실제 서비스로 릴리즈하고 또 고도화 하는 과정을 겪게 됩니다.
그렇기에 언제든 배포가 가능하도록 아주 작은 형태로 완성된 형태를 유지하면서 조금씩 업데이트를 하는 형태로 개발을 하는 방식을 이해하는 것은 아주 중요합니다.

우리가 만들고자 하는 것을 자동차라고 목표하고 그걸 만들기 위해서 시간이 걸리는 채로 오래 만드는 방식보다는 우리가 전달하고자 하는 가치가 이동수단이라고 생각을 한다면 우선 그 가치를 전달할 수 있는 단순하고 동작하는 것부터 시작해서 언제든 릴리즈를 할 수 있는 전략이 필요합니다.
우리는 현재 1번의 위치입니다. 오늘 데모를 운영을 할 때 바퀴를 보여주는 것보다는 스케이트 보드를 보여주는 것이 훨씬 더 임팩트가 클 거라고 생각합니다.
대부분의 사용자들은 바퀴만 보고서 자동차를 떠올리지 못합니다.

색깐다 팀 데모 파티 💛

각 팀에서 만든 서비스를 소개하고 서로의 데모를 살펴보면서 피드백을 공유하는 시간을 가졌다.
우리는 스케이트 보드를 보여주는 데 성공했다!
짧은 시간 안에 필수 기능을 모두 구현하여 유저 플로우를 갖춘 것에 감탄하는 피드백이 많아서, MVP 우선순위로 개발하길 잘했다고 생각했다. 더불어 기능적인 피드백도 얻을 수 있었다.

이때 느꼈다... 네이밍 어그로의 중요성

회고

4LS 회고 템플릿(Liked: 좋았던 것 Learnd = 배운 것, 새롭게 알게된 사실 Lacked = 더 잘할 수 있었던 것, 아쉬운 점, 부족했던 점 Longed for = 그래서 앞으로 해봐야겠다 싶은 것)을 이용해서 프로젝트 결과물, 협업과 우리 팀, 스프린트와 나 자신에 대해 팀원들과 함께 회고하며 이야기를 나눴다.

우리 팀은 5명으로 다른 팀에 비해 인원 수가 적었지만 그래서 더 한명 한명의 의견과 역할이 중요했고, 프로젝트에 각자가 더 많이 기여할 수 있었다고 생각한다.

좋은 팀원들 만났다고 칭찬 잔뜩 늘어놓는 우리 좋은 팀원들...!

스프린트를 통해 좋은 협업 프로세스를 경험하게 해준 테오와 우리 색깐다 팀에게 감사를 전합니다.
테오의 스프린트는 끝났지만 우리의 프로젝트는 끝나지 않았다!
다음 포스팅에서 이어집니다.

profile
공부 기록

1개의 댓글

comment-user-thumbnail
2023년 5월 3일

우리는 스케이트 보드를 보여주는 데 성공했다!

이 말이 뭔가 찡하게 오네요!!! 다시 한번 그날의 추억이 기억이 납니다!! 회고 잘 읽었습니다 :)

답글 달기