테오의 스프린트 15기 회고 1 - Mind Palace

시작은 언제나 ‘Why’

일단 왜 테오의 스프린트에 참여하게 되었는지, 그 이유부터 이야기를 시작해보자.
 
우리나라의 IT 스타트업에 근무하면 필히 익숙해지는 단어가 몇가지가 있다. 바로 애자일, 린, 스프린트. ‘함께 자라기(김창준 저)’는 대부분의 스타트업 프로덕트 팀의 필독서이며 내가 거쳐온 회사 역시 마찬가지였다. 하지만 애자일 방법론이라는 것이 현실 세계의 스타트업에서 적용 가능한가? 실효성이 있는가? 생각해보면 ‘네!!!!’라고 개운하게 대답하기 어려운 것도 사실이다.
애자일 소프트웨어 개발 선언에 따르면 애자일 방법론은 다음과 같은 가치에 우선순위를 둔다.
 

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

 
왜 실현이 어려운가? 나는 매일 매일이 생존의 갈림길인 성장 단계의 스타트업 비즈니스는 필연적으로 다양한 계약과 이해관계에 얽혀있기 때문이라고 생각한다. 또한 워터폴 방식의 의사 결정으로부터 자유롭기도 힘든 것이, 창업자 혹은 C레벨과 단순 실무자 입장에서 느끼는 책임감의 무게가 다를 수 밖에 없기 때문. 이러한 현실적 제한 때문에 ‘공정과 도구보다 개인간의 상호작용을 우선시’ 하는 것은 한없이 불가능에 가깝다고 느꼈다.
 
그렇다면 애자일 방법론은 현실을 모르는 사람들이 만들어낸 허무맹랑한 이야기인가? 나는 그렇지 않다고 생각한다. 꽤 많은 성공사례를 가지고 있는 방법론이다. 충분한 실효성이 예상되나, 애자일이 애자일답기 위한 필요 조건을 통상적인 비즈니스 환경에서 만족시키기가 어려울 뿐이다.
 
사실 테오의 스프린트를 알게 된 지는 꽤 되었다. 이전 직장에서 현 직장으로의 이직을 준비하던 도중 테오의 프론트엔드 카톡방을 알게 되었다. 조용히 스며들어서 정보를 얻기도 하고. 내가 대답해드릴 수 있는 질문이 올라오면 가끔은 답변을 하기도 하고. 꾸준히 올라오는 스프린트 후기를 보며 9기 무렵부터 한 번 참여해보고 싶다는 생각을 했지만 늘 타이밍이 안맞았다. 그러다가 15기에 와서야 드디어 일정을 뺄 수 있는 주간에 스프린트가 열린 것. 그 소식을 접했고, ‘곰곰’이라는 이름으로 신청했다. 포지션은 프론트엔드 개발자.

팀이 꾸려지고 첫날 진행했던 팀캔버스의 Personal Goal 항목에 적었던 내용이다. 이것만 봐도 알 수 있듯이, 나는 ‘스프린트’라는 방법론을 실제 협업을 통해 체험해보고 싶은 마음이 그 무엇보다 컸다.

이 회고에서는 상세한 스프린트 과정에 대해 소개하지는 않을 예정이다. 하고싶은 이야기가 너무 많아 글이 길어질 것 같아서. 테오의 스프린트가 어떤 방식으로 진행되는지는 테오의 후기글에 정말 잘 소개되어있으니 참고 부탁!
참고: 테오의 스프린트 15기 후기

 

미안금지조 (구 13조)

우리 조는 오원의 아이디어, ‘기억 궁전’을 통해 만나게 되었다. 기억의 궁전이란 기억을 시각화하여 저장할 수 있는 일종의 기억술으로, 오원의 아이디어는 이 ‘기억의 궁전’이라는 컨셉에서 출발한, 사용자의 기억을 시각화하여 저장할 수 있는 서비스였다.

그렇게 팀원들과 만나, MC 담😎의 인도 하에 서로에 대하여 알아가는 팀캔버스 시간을 가졌다. 이 과정을 통해 느낀 것은 ‘이 사람들 성격 정말 좋은데..?’ 하는 것. 개인 기록에 포커스가 맞추어진 아이디어를 통해 만나게 되어 그럴까? 묘하게 결이 비슷하다는 느낌을 받았다. 그래서인지 생각보다 빠르게 편해졌고, 2일차에 다시 모여 서비스에 대한 지도를 그릴 때에도 자유롭게 의견을 주고 받을 수 있었다.

 

지도 그리기 (중요!)

나에게는 가장 인상 깊은 시간이었다.
스프린트는 크게 다음과 같은 단계로 이루어진다.

서로 알아가기 → 아이디어 이야기하기 → 풀어놓은 아이디어를 기반으로 의사 결정하기 → 개발하기 → 피드백&회고

지도 그리기는 이 중 아이디어를 이야기하고 풀어놓는 단계에 해당하는 과정이었다.
이 때, 테오가 강조한 포인트가 몇가지 있었다.

1. 적극적으로 리액션하고, 이야기하는 도중에 생각이 많이 발전되기 때문에 그 내용이 휘발되지 않도록 다른 사람들이 주변에 기록하며 들을 것.
2. 이 단계에서 절대 선택하거나 결정하려 하지 말 것. 지도를 그리는 날은 결정하는 날이 아니라는 사실을 기억할 것.

이런 가이드 덕분일까? 첫번째 질문, ‘내가 생각하는 우리 서비스의 궁극적인 목적은 무엇일까요?’에서 부터 다채로운 의견이 쏟아져 나오기 시작했다. 다른 사람의 의견을 들으면서도 서로 공감하면서 ‘그거 진짜 좋은 것 같아요’, ‘저도 그 생각했는데! 거기다가 이런걸 더하면~’ 하는 식으로 대화가 자연스럽게 이어졌다.

중간에 진행을 도와주러 들어왔던 모승, 꾺이 끝나는 시간을 걱정해주었던 것이 생각난다. 이야기가 풍부해지는것은 좋지만, 이러면 다음날 많이 피곤할 수 있다고.😌 다음날 아침에도 출근을 해야하는 입장에서 종료 시간이 늦어지는게 부담스럽지 않았다면 거짓말일 것이다. 하지만, 이야기를 풀어놓고 생각의 주파수를 맞추는 것이 너무나 재미있어서 중간에 그만두고 싶지는 않았다.

정말 신기한 것은, 절대 논쟁하거나 무언가를 결정하려 하지 않았는데도 네번째 질문에 대해 이야기를 나눌 때에는 모두의 의견이 거의 맞추어졌다는 사실이다. 자유롭게 이야기하며 서로의 의견에 공감하게 되고, 그 중에서도 원하는 바가 자연스럽게 정리되어 핵심 가치가 추려진다는 것은 정말 새로운 경험이었다.
논쟁과 토론까지 가지 않아도 팀원들이 같은 방향을 바라볼 수 있다니!
 
그 후의 워드 클라우드 → 질문 만들어 답하기 → 기능 정의 → 스토리보드 작성하기의 과정은 일사천리였다.
중간중간 방향을 잃고 헤메고 있을 때에는 테오, 모승, 꾺, 수달이 들어와 어떤 식으로 생각을 발전시키면 되는지 가이드를 전달해주었고, 덕분에 지도 그리기의 날은 꽤 그럴듯한 스토리보드를 끝으로 마무리를 할 수 있었다. 이 때 모든 작업이 끝난 시각이 새벽 3시쯤이었던가? 출근을 위해 누우면서도 다음 날의 스프린트가 기대되는 마음에 설렘을 안고 잠들었던 기억이 난다.

 

스케치, 결정하기, 그리고 떠오르는 해☀️

다음 날은 실제 개발을 진행할 수 있도록 스케치를 하고, 기능의 상세 요건을 결정하는 날이었다.

전날 스토리 보드를 작성하며 각각의 페이지에 대한 기능 요건을 설정 했음에도 불구하고, 모두가 그려온 스케치는 조금씩 다른 모습이었다. 그 스케치에 대해 이야기를 나누고 어떤 식으로 기능을 설정하면 좋을지 BDD, SDD 기반으로 명세를 정리하는 작업을 진행했다.
이 때 필요한 것이 ‘결정권자’였다.
 

UX 결정권자는 만장일치로 우리의 갓자이너 허니비.
기술, 개발 면에서의 결정권자를 담당하는 PL은 백 - 오원, 프- 곰곰(나).
그렇게 결정권자를 정하고, 모두 함께 기능의 상세 명세를 BDD, SDD 기반으로 설계하다보니 시간이 훅 지나갔다. 누울 때 쯤에는 이미 해가 떠오르고 있었다..
 
이 쯤에서 사실대로 고백하자면.. 나는 스프린트라는 방법론에 흥미가 있어 테오의 스프린트에 참여했을 뿐, 그렇게까지 열심히 할 생각이 없었다. (이것은 팀원들에게도 이미 양심 고백한 내용😌) 왜냐하면 회사 일이 워낙 바쁜 시즌이었고, 비장한 책임감을 가지고 프로젝트에 임하면 있던 재미도 사라질 것 같았기 때문이다. 그래서 딱 투자할 수 있는 만큼의 에너지만 투자하고 즐겁게 스프린트를 마무리하는 것이 나의 또 다른 목표였다.
 
하지만 덜컥 프론트 PL을 맡아버렸고, 기왕 맡기로 한 이상 적당히 슬렁슬렁 마무리하고 싶지는 않았다.
나는 이 프로젝트에서 팀원들이 하고 싶은 것을 제약 없이 마음껏 시도해볼 수 있었으면 했다. 그래서 내가 선택한 PL으로서의 스탠스는 개인적인 개발은 일부 포기하고 팀원들이 마음대로 뛰어놀 수 있도록 판을 깔아주는 것.
 
대부분의 취준생 혹은 신입 개발자들에게 익숙한 방식인 git flow를 이용하여 브랜치 전략을 짜고, vercel을 활용해 프론트엔드 레포지토리의 CI/CD를 구성했다. 그리고 PR마다 preview build를 통해 dev 브랜치에 병합되었을때의 예상도를 확인할 수 있게 만들었다. 상세한 코드 컨벤션을 논의하고 결정하는 것은 시간 낭비일 수 있겠다는 생각에, eslint, prettier, husky를 이용하여 최소한의 포맷팅과 컨벤션 룰을 정하고 공통 설정을 진행하였다. 그리고 빠른 속도를 위하여 프론트엔드 작업 컨벤션을 지정한 뒤 배포하였다. 이 과정에서 코드 리뷰의 진행 여부를 결정하는 등.. 다양한 의사 결정의 과정이 있었는데, 내 절대적인 기준은 ‘빠르게 스프린트 작업을 수행할 수 있도록 하는 데에 도움이 되는가?’ 였다.
 
그렇게 기본적인 세팅을 진행하며 주말을 맞이했다.
이 주말 동안 시연 가능한, ‘그럴 듯한’ 데모를 개발해내야 했기 때문에 속도와 전략이 중요했다.
 

다음은.. 회고 2편에 계속.
2편 보러 가기 : https://guuumi.tistory.com/135