테오의 구글 스프린트 회고🔥

holymoly.jun·2022년 1월 30일

회고록

목록 보기

2/2

1/19 ~ 1/25, 단 5일 만에 새로운 서비스 기획부터 배포까지 해보는 테오의 구글 스프린트에 참여했다.

ifkakao에서 테오의 디자이너와 웹프론트 협업 이야기에 대한 세션을 듣고, 조금 더 많은 대화를 나누고 싶어서 테오가 운영하는 오픈 카톡 방에 들어갔다. 그곳에서 만난 주/시니어 개발자 6명과 함께 자발적 해커톤 진행했다.

해커톤은 5일 만에 새로운 프로덕트를 만들 수 있다는 구글의 디자인 스프린트 방식을 사용했다. 아래는 구글 스프린트를 하기 위해 필요한 사전 지식인 애자일, 스프린트에 대한 정의와 우리 팀이 구글 스프린트를 진행했던 방식에 대해 공유하는 글이다.

애자일과 스프린트

기존의 폭포수 프로세스

기존의 회사에서는 흔히, 폭포수 프로세스(워터풀 프로세스)의 방식을 사용했다. 회사에서 제품을 릴리즈할 때, 개발 방식이 마치 폭포수처럼 아래로 향하는 것에서 유래됐다. 이 폭포수 프로세스의 흐름은 요구사항 분석 -> 설계 -> 구현 -> 시험 -> 통합 -> 유지보수 로 이루어져 있다.

새로운 일의 방식, 애자일

그러나, 여러 IT 서비스(WEB, APP)들이 생겨나면서 고객의 요구사항에 보다 민첩(agile)하게 반응해야 했다. 그래서, 목적 중심으로 움직이는 회사들은 수직적 구조에서 수평적인 구조로 바꾸고, 해당 업무에 대한 결정권을 실무자에게 위임했다.

스크럼과 스프린트

애자일 프로세스를 실천할 수 있는 방식(프레임워크, 템플릿)에는 여러 가지가 존재한다. 그중에 가장 대표적인 것이 스크럼이다. 애자일을 잘 실천할 수 있도록 일의 방식을 템플릿화 해놓은 것이다. 예를 들어 이런 것이 있다.

매일 15분씩 미팅하기 (데일리 스크럼 미팅)

개발 주기마다 적용할 기능이나 개선에 대한 목록 (프로덕트 백로그)

항상 팀을 우선으로 생각하라. (목적 중심, 팀 중심)

위의 이미지에서 보다시피, 애자일 프로세스(스크럼)를 진행하기 위해 계획, 개발, 리뷰 작업 등 최소 단위의 cycle이 필요한데 그것이, 스프린트이다. 스프린트의 주기는 모두 제각각이며, 구글의 스프린트 주기는 5일이다.

5일 구글 스프린트

상대적으로 스프린트의 주기가 굉장히 짧은 구글 스프린트를 경험해 보고 싶었다. 그래서 ifkakao 세션을 듣고 인연이 닿았던 테오가 함께 구글 스프린트를 해볼 인원을 구한다는 소식을 듣고 바로 지원했다.

기간 : 1/19 ~ 1/25 (아이스브레이킹 2일 + 스프린트 5일)
시간 : 매일 23시 ~ 01시
워크스페이스 : Gather Town, Fig Jam
구성원 : 프론트엔드 개발자 6명 (테오는 어드바이져 역할)

1. Map (feat. 아이스브레이킹)

TL;DR

워크스페이스 : Fig Jam 팀 캔버스 템플렛
방식 : 아이스브레이킹
1. 피그잼 타이머 기능을 활용해 시간 제한 두기
2. 시간 내에 템플릿에 있는 질문 작성하기
3. 작성한 질문 모두 돌아가면서 발표하기
방식 : 맵 그리기
1. 만들고 싶은 것에 대해서 이미지 및 스케치 그림을 최대한 활용해서 나열하기
2. 결정된 아이템에 대해 HMW로 구체화하기

1-1. 아이스 브레이킹

목표를 세우고, 스프린트에 대한 백로그를 정하는 시간이다. 그러나, 우리 팀은 오늘 Gather Town에서 처음 봤기 때문에 아이스브레이킹 시간이 필요했다.

그래서 우리는 팀 캔버스를 작성하는 시간을 가졌고, 테오가 미리 준비한 아이스브레이킹 피그잼 템플릿을 활용했다. 해당 템플릿과 운영하는 방식이 아이스브레킹하는데 매우 유용했다.

1-2. Map

하고 싶은 것 나열하기

각자 만들고 싶은 서비스와 레퍼런스 이미지에 대해 준비했다. 이후, 각자 돌아가며 나의 아이디어가 선정될 수 있도록 2분 동안 설득의 시간을 가졌다. 여기서 좋았던 점은 2분 안에 말이 끝나고 할 말이 더 이상 없어도, 시간을 다 채워야 한다.

결정 역시, 시간제한을 두고 피그잼의 스티커 기능을 활용했다. 우리 팀은 설이아빠가 아이디어로 냈던, "한국판 state of js" 가 선정됐다.

결정된 아이템에 대한 지도(map) 그리기

서비스 기획을 구체화 하는데에는 customer journey map, 데이터 관점에서 바라보기, HMW 등등 등등 여러가지 방법론이 있다. 우리는 여러가지 방법으로 map을 그려보았지만, 개인적으로 가장 좋았던 HMW을 소개해본다.
HMW (How Might We?)
어떻게하면 우리가 ~ 을 할 수 있을까? 라는 뜻으로서, 기존의 어떻게하면 ~을 잘 할 수(can) 있을까? 보다는 조금 더 창의적인 아이디어를 도출할 수 있다는 디자인 씽킹법이다.
- 어떻게하면, 경쟁사보다 더 나은 초록색 스트라이프 비누를 만들 수 있을까? (x)
- 어떻게하면, 소비자에게 조금 더 상쾌한 느낌을 주는 비누를 만들 수 있을까? (o)
출처 : HMW 질문법: 어떻게 우리가 ...할 수 있을까?

2. Sketch

Map 단계에 선정된 답변들을 통해 빠르게 스케치를 하는 시간이다. 왼쪽에는 텍스트 형식으로 된 포스트잇이 있고, 해당 텍스트에 대한 스케치를 그려보는 시간이다.

해당 세션 역시 발표와 결정의 시간 모두 제한 시간을 걸어두었고, 투표가 많은 스케치는 추후에 프로토타입 디자인하는데 참고했다.

3. Decide

3-1. PL 선정

사공이 많으면, 배는 산으로 간다. 좋은 서비스를 만들기 위해서는 어느 정도 리더의 독단적인 결정이 필요하다. 우리는 단테를 PL로 선정했다. 단테를 통해 리더는 어떤 자질을 가지고 있어야 하는지에 대해 많을 걸 배울 수 있었다..

단테가 보여준 리더의 자질

팀원들과 평소에 대화할 때는 부드러운 성격이시지만, 결정할 때는 강단 있는 모습을 보여주는 결단력

주말 동안 가장 많은 시간을 투자하는 열정

회의 전, 아젠다를 미리 정해오는 준비성

높은 감성 지능으로 팀원들의 고충을 들어주는 커뮤니케이션 능력

3-2. 목표 리마인드와 계획 수립 (pathfinder)

"우리의 목적은 사용자에게 이 서비스를 느낄 수 있게 하는 진짜 같은 프로토타입을 만드는 것입니다."

우리는 테오와 함께 목표를 리마인드했다. "진짜 같은" 을 위해서는 선택과 집중이 필요했다. 만들고 싶은 기능은 많았지만, 대표 기능 3가지만 뽑기로 했다.

개발자 입문자를 위한 로드맵 기능
한국 웹 프레임워크에 대한 통계 자료
한국 기업/업계에 대한 정보 나열

4. Proto-type

4-1. 프로토타입 제작

피그마를 통해 디자인했다. 대표 기능 3개에 모두 chart가 들어갔기 때문에, chart 라이브러리를 물색했고, 나는 과거에 hands-on 해본 Ant Design Charts를 제안했다.

Antd chart 장점
- css 프레임워크 Antd와 함께 사용 가능
- 다양한 chart 종류 (우리팀이 특히 필요했던, radial tree graph가 있었다.
Antd chart 단점
- 중국어로된 docs
- 아직 Majar version이 1대여서, 안정성 확보가 안됨

(알모) "토이 프로젝트는 원래, 실험적인 걸 하는 겁니다 !"

단점들이 꽤 많았지만, 우리 팀의 알모가 나의 제안에 힘을 실어주었고, 해당 프레임워크를 사용하기로 했다. 그러나, 역시 아직 ts 지원을 하지 않는 chart들이 존재했으며, 완벽하게 중국어에서 영문으로 번역되지 않은 점들이 많아 쓰기 불편했다ㅠㅠ.. ~~(팀원들에게 살짝 죄송..)~~

4-2. 페어코딩

우리 팀은 2명씩 짝을 지어, 3팀으로 나누어 페어 코딩으로 프로토타입 개발을 시작했다. 테오의 제안이었고, 알모가 해당 방식에 대해 노하우가 있어서 해당 제안은 성사됐다.

페어 코딩 진행 방식
- 1:1로 짝을 이룬다. (우리 팀은 시/주니어급 <-> 신입 또는 입문자 이렇게 짝을 이루었다.)
- 역할을 드라이버와 네비게이터로 나뉘며, 10분씩 역할을 바꿔가면서 진행한다.
- 드라이버는 소스코드를 타이핑하고, 네비게이터는 작성되는 소스코드를 실시간으로 리뷰하는 역할이다.
- 네비게이터가 소스코드를 타이핑해 줄 일이 있을 때는, 잠시 interrupt를 하고, 스톱워치를 일시정지한다.
페어코딩 단점
- 프로토타이핑 완성 하는데 시간이 확실히 오래걸리며, 생산성이 저하된다.
- 계속 대화를 하면서 하다보니, 피로도가 쌓일 수 있다.
- 대화/개발 스타일이 맞지 않는 사람과 함께하다 보면, 감정 문제로 이어질 수 있다.
페어코딩 장점
- 코딩하는 동시에, 코드 리뷰가 가능하다. (오히려 생산성 상승..?)
- 네비게이터가 계속 잡아주다 보니, 개발에 대한 집중도 상승한다.
- 팀원과 라포 형성에 매운 큰 도움을 준다.

페어 코딩을 해본 결과, 확실한 단점도 있지만 때에 따라서는 큰 효과를 줄 수 있을 것 같다. 특히, 나와 나의 짝꿍 알모는 페어코딩을 하면서 개발 얘기뿐만 아니라, 개발에 대한 고민, 진로에 대한 걱정과 같은 개인적인 이야기까지 나누게 되었다.

회사에서 항상 페어 코딩을 하기에는 무리가 있지만, 신입 개발자 온보딩 과정에서 주/시니어급 개발자와 페어코딩을 하면 매우 유용할 것 같다.

5. Test & 회고

5-1. Test

원칙은 아무 교류가 없는 3명의 테스터를 초대해서 서비스 시연을 하려고 했지만, 우리는 테오가 테스터 역할 하는 걸로 퉁(?)쳤다 ㅎㅎ.. 테오의 테스팅/QA 방식을 아래와 같다.

서비스를 사용하면서, 느끼는 생각들을 실시간으로 말해주기
좋은 건 좋다고, 나쁜 건 나쁘다고 가감 없이 말해주기

사이트 정체성을 느끼기에는 아직 부족한 거 같아요!
해당 진입점에서는 제가 무엇을 해야 할지 모르겠네요.
오! 이런 기능은 좋네요!
확실히 기술 스택을 중심으로 얘기할 거리가 많은 거 같아요~

5-2. 회고

회고 방식은 4LS 방식을 사용했다. 이것 역시 피그잼 템플릿이 있어서 템플릿을 활용했다. 애자일 프로세스에서 가장 대표적으로 하는 회고 방식이다.

What did we really enjoy about the crit? (좋았던 점은 무엇인가요?)
What new things did we learn? (무엇을 배웠나요?)
What things could we have done better? (무엇을 더 잘 할 수 있었나요?)
What things did we desire to have or to do? (무엇을 더 바라나요?)

팀원을 평가하는 Continue-Stop-Start 방식, 방향성을 읽을 수 있는 KPT 방식도 있으니, 한 번 활용해봐도 좋을 것 같다.

느낀점

스프린트는 개개인의 역량이 T자형으로 모인 인재들이 함께해야 최고의 효율을 낼 수 있다. 프론트 개발자로서, 1인분을 할 수 있는 역량을 기르자.
해커톤을 할 때마다 느끼지만, 세상에 대단한 개발자들이 너무 많고, 그들에게 항상 배우고 성장한다. (해커톤 짱!!)
처음에 지원했던 동기는 우리 회사에서 하는 스프린트를 뭔가 개선해 볼게 없을까 하고 지원했다. 그러나, 구글 스프린트는 해커톤과 같은 프로젝트성 프로덕트에 더 잘 어울린다. 회사에서 진행하는 스프린트에는 여러 가지 환경적 요인으로 인해 해당 방식을 완전히 동일하게 적용하기에는 무리가 있다.
구글 스프린트 주 - 개발주 - 구글 스프린트 주 - 개발주 이런 식으로 격주로는 활용해 볼 수 있을 것 같다.