[SUPP] 페어와의 협업 맛을 돋우는 애피타이저 - 2

우아한 테크코스 2기 과정 중 크루들과 제작한 서비스인 SUPP에 대한 글입니다.

프로젝트 로고

나를 비롯하여 또링, 스티치, 알트 그리고 코즈까지 5명이 모여 SUPP 개발 팀이 꾸려지고 대략적인 서비스 컨셉이 나왔다. 이번 글에서는 기획과 개발 과정에 대해 알아보자. 

 

기획의 순간

지금까지의 코어 아이디어는 "크롬 익스텐션을 이용해서 우테코 교육 사이트의 돔을 조작해서 페어인 크루의 정보를 보여주자"이다. 그렇다면 우리는 어떤 정보를 보여줄 것이며 어떻게 정보를 얻을 것인가. 이에 대해서는 팀원 모두 고민과 아이디어가 많았다. 3월 7일, 팀원들과의 회의에서 이 내용은 구체화되었다. 우리는 우테코를 시작하고 근 한 달간 수행해왔던 페어 프로그래밍의 속성을 분석하고, 어떤 질문들이 필요한지 추려냈다. 페어를 하며 불편했던 점과 페어 간에 나누면 좋을 이야기를 뽑아냈다. 그렇게 질문을 추려내니 대여섯 가지의 질문이 모였다. 가장 기초적인 페어의 노트북 OS 정보부터 시작해서 git 커밋 메시지를 어떻게 쓰는지까지. 그 이후는 일사천리였다. 이런 질문에 대한 사용자의 대답을 입력받는 웹 페이지를 만들면 되니까. 

 

당시의 회의록, 서비스 예비 이름 중 supp을 찾을 수 있다.

 

하지만 우리는 만족하지 못했다. 지금의 기획만으로는 만드는 사람과 사용하는 사람 모두 즐겁지 않을 것 같았기 때문이었다. 흥미로운 요소를 추가하고 싶었다. 현재 기획의 핵심인 질문에 대한 대답이라는 컨셉에서 우리는 당시 한창 유행했던 MBTI와 같은 성향 검사를 떠올렸다. 그리고는 "개발자 성향 테스트를 전면에 내세우면 어떨까?" 라는 아이디어를 도출했다. 팀원들과 함께 여러 개발자 성향과 질문을 생각해봤지만 유의미한 질문과 재미있는 성향을 만들지 못했다. 이만 성향 테스트를 포기하려던 찰나, 구글 검색이 빛을 발했다. 외국에서 이미 만들어놓은 개발자 성향 테스트가 있었다. 우리는 해당 테스트를 이용하기로 결정하고 기획을 가다듬었다. 

 

---

 

개발의 순간

즐거움, 학습, 협업 등등 이번 프로젝트를 진행하는 여러가지 이유가 있을 테지만 그중 레벨 2를 대비해보자는 이유도 있었다(우테코 2기 레벨 2에서는 Spring Boot를 공부한다). 우리 팀은 이동욱 님께서 쓰신 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 책을 바탕으로 스터디를 진행했다. 그리고 스터디에서 배운 내용을 SUPP을 구현하는 데에 녹여내면 좋겠다고 생각했다. 당시 우테코 레벨 1을 진행하며 자바와 객체지향의 늪에서 허우적거리는 모두였지만 열심히 준비하고 공부해서 이동욱 님 책을 기틀 삼아 SUPP 개발을 준비했다. 간단한 게시판을 구현하는 이동욱 님의 책 보다 쉬운 규모의 프로젝트라고 생각했지만 현실은 달랐다. 당시 우리 팀원들은 스프링 부트에 대한 지식이 적었음과 더불어 프론트에 대해서는 더 문외한이었다. 또한 배포라는 미지의 영역도 두려웠다.

하지만 우리는 이에 굴하지 않았다. 이동욱님의 책에는 나와있지 않던 github으로 OAuth 로그인을 구현했고 익숙하지 않던 자바스크립트를 이용하여 프론트에 기능을 추가했다. 물론 이 과정에서 클린코드를 짜야한다는 마음과 실제 코드와의 괴리감, 스프링으로 테스트를 짜는 법을 습득하지 못하여 테스트 없이 진행한 점 등 아직도 마음에 걸리는 부분들이 발생했다. 하지만 당시에 이런 부분은 추후에 리팩토링하기로 하고 기능 구현을 진행했다. 

프로젝트 기획대로 사용자의 정보를 받을 수 있는 설문 조사 기능과 그 정보를 보여줄 수 있는 구글 익스텐션을 이용한 돔 조작 기능을 하는 애플리케이션 각각이 필요했기에 두 개의 레포지토리를 파고 개발을 진행했다. 익스텐션은 알트가 중심을 잡아 수월하게 진행되었다. 설문 조사 프론트는 머스테치를 이용해 구현했다. api가 네 개뿐인 서버지만 처음 스프링으로 프로젝트를 진행한 우리로는 어려워하며, 즐거워하며 개발했던 기억이 있다. 

 

당시 프로토타입으로 만들었던 익스텐션 적용화면 가운데 모달창에 돔 조작을 하여 자기소개, OS 정보를 띄우고 프로필 클릭시 카카오톡 처럼 상세 정보를 볼 수 있도록 구성했다.

 

우리의 협업은 어땠는가. 개발 팀이 꾸려졌으면 개발 규칙이 필요하다. 우리는 이슈 기반으로 프로젝트를 진행했다. 그리고 이슈 관리를 깃헙 프로젝트에서 진행했다. 당시 깃헙 프로젝트를 처음 사용해보고 이슈를 만들었던지라 지금 보기에는 서툰 부분이 보인다. 하지만 첫 시도임에도 불구하고 이슈 기반 개발이 잘 진행되었다는 점이 뿌듯하다. 브랜칭 전략은 develop 브랜치를 중심으로 feature 브랜치를 따서 진행했다. 최종적으로는 master 브랜치에 배포될 내용을 머지했다. 깃플로우를 간소화한 전략이었다. 이때 진행했던 협업의 방법들이 추후 다른 프로젝트를 더 잘 진행할 수 있게 하는 밑바탕이 되었다.

 

---

 

이번 글에서는 SUPP의 본격적인 기획과 개발 과정을 회의록과 기억을 되살려가며 적어보았다. 기억은 날아가기 마련이지만 회의록을 잘 정리해둔 덕에 이렇게 글을 남기기가 수월하다. 기록의 중요성 👍
다음 글은 실제 SUPP의 배포와 공개 그리고 그 이후의 이야기들에 대해 적을까 싶다.