🚗들어가면서...

23년 11월 쯤 우연히 front-end를 배우기 시작했다.
Korea It Academy 라는 학원에서 수업을 마치고 1~7월까지 MOBI라는 단체에서 다양한 front-end stack들을 배우고 경험하며 어느덧 마지막 최종 프로젝트를 진행하게되었다.

총 기간 5월 15일 ~ 7월 15일까지 일정을 잡고 MOBI에서 섭외한 BE & Designer 팀과 처음으로 프로젝트를 진행하며 느꼇던 다양한 경험들을 글로 남겨보려한다.

결과적으로 프로젝트의 완성이라는 목적에는 실패했지만 그 간의 배운점을
notion에 기록된 내용들을 돌아보며 살펴보자.

👌미리보기

간단하게 프로젝트에 대한정보만 살펴보자.

총기간 : 5월15~ 7월15일 (현재도 진행중~)
인원 : FE : 4명 BE : 3명 : Desgin : 1명
프론트 사용스택 : NextJs, TypeScript TailwindCss
협업 툴 : github, jira, notion, discord

NewTips에 대해서

• NewTips는 현재 네일아트 예약과정에서 판매자, 소비자가 모두 불편함을 느낄 수 있다는 문제점을 인식.

• 가게 사장님 : 고객들과 채팅을 통해 예약에관한 대화를 해야만 한다.

• 소비자 : 원하는 디자인, 시술내용, 시간등을 예약하기까지 다양한곳에서 검색, 채팅을 통해 가게와 일정조율.

• 이런 문제점을 바탕으로 우리 팀은 문제해결을 위한 가설을 세우고 이를 바탕으로 MVP를 설정, 검증하는 과정까지를 목표로 진행.

• notion에 작성한 가설 & MVP

다음과 같은 방식으로 5월 19일의 첫 회의를 시작으로 프로젝트를 시작했다.

😰계획한 대로 했다면...

우선 결과부터 살펴보면, 프로젝트는 처음 MVP를 설정하고, 일정을 계획하고 HappyCase를 생각하며 신나게 출발했지만.... 완성된 결과물은 실패하고 말았다.

지난 프로젝트를 돌아보며 느꼇던것, 그 간의 계속된 issue들을 겪으며 정말 적고싶은 것들이 많이 생각이난다.

그 중 가장 중요하게 배웠던 내용들에 대해 3가지 키워드와 함께 살펴보자.

• 1. 서비스 !== 코드
• 2. 모래성
• 3. 기억상실

💥서비스 !== 코드

짧은 기간이지만 그동안 여러 작은 프로젝트들을 경험하면서 서비스를 만드는 것은 코드다! 라는 생각으로 코딩을 해왔던것 같다.

단순히 만들고싶은 것들을 코드로 작성해서 화면에 그려지는 것 자체에 굉장한 재미를 느꼇고 이런방식이면 어떤 서비스든 만들 수 있겟는데? 라는 생각을 하곤했엇다.

이번 프로젝트에 임할때도 어서 코드를 치고싶은 생각에 들떠서 시작을 했는데 지금까지 몰랐던것이 있었다.

서비스는 그냥 만들어지는게 아니다

그 동안 일상에서 사용해왔던 다양한 서비스들이 어느순간 뚝딱 만들어졌다고 생각해왔던것 같다.

예약서비스를 예시로 생각해보면 다음과 같은 기능들이 필요할 것이다.

• 사용자가 처음 보게될 main페이지
• 예약하기 위한 예약페이지
• 사용자 정보를 관리할 마이페이지
• 그 외, 다양한 기능들과 부가적인 ui들(모달, toast메세지 등등)

"단순히 예약서비스를 만들어야 하니 위와같은 기능을 만들어서 사용자들에게 제공하자.!"

이것이 서비스에대한 나의 이해였던것 같다.

회고를 작성하는 시점의 나는 서비스를 다르게 정의하고 싶다.

"일상의 문제점을 찾아서 그것을 해결해주자..!"

프로젝트를 시작할 때 MOBI에서 검증하고싶은 가설을 세우고 그것을 바탕으로 MVP를 정하라는 조언을 받았었다.

어쩌면 완전한 서비스를 처음부터 시작해보는 과정이 처음이라
그 당시에는 왜 그래야하는지 이해하지 못했다.

돌아보며 가설과 MVP가 어떤 의미를 갖는지 생각해보면 다음과 같은 이유가 아닌가 생각이든다.

• 1. 문제점을 발견하고 해결해야만 같은 문제점을 느낀 사용자들을 끌어들일 수 있다.
• 2. 가설을 세우고 검증하는 과정에서 서비스에 대한 가능성을 점칠 수 있다.
• 3. MVP를 설정함으로서 불필요한 작업, 시간낭비를 줄일 수 있다.

7월 15일 이후는 서비스를 완성하기 위해 팀원들과 계속 개발을 진행중인데
가설과 MVP를 중점으로 개발을 하면서 이전보다 더 효율적으로 진행되는것 같다.
팀원 모두가 같은 목표를 바라보며 개발을 하는 과정이 더 확실한 목표, 빠른 진행속도를 가져다주고 있다.

코드 치기전에 정말 필요한 개발인지 체크하자.

"우리팀은 프로젝트를 시작하며 Designer분에게 저희 이런 서비스를 만들거 같은데 작업해주세요~" 라고 요청했다.

이렇게 며칠이 지난후 확인한 figma에는 정말 다양한 페이지들이 존재했는데
figma를 바탕으로 모든 페이지를 작업하는 것을 목표로 했엇다.

프로젝트의 마무리 시점에 완성된 페이지들을 보면 MVP에 일치하지 않는 페이지들이 여럿 있는데..

정말 가장중요한 가치인가에 대해 조금만 더 고민해 봤더라면
지금 사용하지않는 페이지, 기능들을 만들시간에 MVP에 적합한것들을 만드는것을 우선으로 했을것이다.

결국 프로젝트의 완성시점에서 돌아보면 모두 완성 해야 할 것들이지만 순서가 달랐더라면 어땟을까 하는 아쉬움으로 남는다.
그저 빠른 시간안에 모든 코드를 완성하겠어..! 라는 생각으로 비효율적으로 진행했다.

🏰모래성

"모래성" 하면 떠오르는 것은... => "쉽게 무너진다".
그것이 이번 우리팀의 설계와 같다는 생각을 한다.

앞에서 언급한것 처럼 우리팀은 서비스를 개발하는 것이 아닌 코드를 치는 방향으로 진행됬었다.

그러다보니 서비스의 설계, 여러가지 case들을 제대로 회의하지 않고 바로 코드를 치는 단계로 들어갔다.

이정도 속도면 충분히 정해진 기간안에 완성해낼 수 있겠어..!

이것의 초반의 생각이었다.

하지만... 잘 설계되지 않은 서비스는 모래성과 같았고 곧 이전 작업들이 필요없어 지는 순간이 왔다.

어느덧 데모데이가 다가올때쯤...

Chan : 어.. 저희 데모데이까지 가설검증하기 위해서 필요한 내용들은 작업을 못하겠는데요...

더 편리한 예약 서비스 라는것을 만들기 위해서 프로젝트를 시작해서 검증을 받아야할 순간이 다가왔는데 정작 그 시점 완성된 것은 예약과정에 대한 flow가 아닌 가상데이터를 그저 화면에 보여주고 있었을 뿐...

설계란?

실제 회사였다면 아마 설계를 직접하진 않겠지만.. 설계는 이런것이 아닐까 생각한다.

• 문제점 파악 : 왜 이서비스를 개발해야 하는지에 대한 파악
• 가설 : 이렇게 한다면 문제점이 해결되지 않을까?
• MVP : 문제점을 해결하기 위해 최우선시 해야할 것
• 검증 : 가설과 MVP를 바탕으로 최소한의 서비스를 만들고 평가받는 과정

위의 네가지 항목에 맞게 일정을 계획하는 과정이 설계가 아닐까 생각한다.

이런 기능은 필요하지 않을까요???
어,,, 이것도 있으면 좋을것 같은데..

설계가 부족하다 보니 프로젝트를 진행하는 과정에 위와같은 대화를 많이 하게되었고
그렇게 하나 둘, 꼭 필요한 기능이아닌 것들을 포함시키면서 엄청난 비효율을 발생시켰다.

위의 내용들을 고민할 시간에 설계한 범위 내에서 error case, 더 효율적인 코드에대해 고민했다면 보다 좋은 서비스를 만들 수 있지않았을까 싶다.

⏱기억상실

프로젝트의 중간 FE 팀의 steak holder역할을 맡게 되었다.

기존 steak holder 였던 팀원분이 가장 잘하셔서 steak holder 역할을 수행해 주셧는데 너무많은 짐을 짊어진 탓에,,,, 힘들어하셧다.

steak holder를 맡을때 쯤 FE팀에는 계속되는 task delay이슈가 있었는데...

이에대한 개선방안을 notion에 작성해서 팀원들과 공유하며 시작했다.

개인적인 작업스타일은 자유로운 분위기의 작업
기한과 task만 정해진다면 자유롭게 기간안에 마무리하는 방식을 선호한다.

이전까지 우리팀도 그런방식으로 진행하지 않았던 터라 이런 방법이라면 더 빠른 진행을 할 수 있지 않을까? 하고 제안했엇다.

하지만 이방법은 성공적이진 않았다...

내가 그렇다고 해서 남들도 그럴것이다.. 라는 생각이 틀렸던것 같다.

다음 plan은?

한번의 제안사항이 성공적이지 못해 다시 원인이 무엇인가 생각해봤다.

불완전한 설계에 따른 계속되는 회의, 수정사항이 생겼다
이를 반영하는 과정에서(PR) 에서 팀원 모두 수정사항에 대해 공유가 안되서 PR이 merge가 안됐다. 어느 순간 PR이 10개가 넘게 쌓이는 상황이 발생했다..

결국 나는 다음과 같은 방식을 제안했다.

Chan : 저희 매일밤 12시에 모여서 PR을 확인하고 모두 merge하고 퇴근하는 걸로 합시다.!

다음과 같은 방식으로 결국 PR이 쌓이는일은 없었고 조금 더 빠르게 작업이 진행됐다.

더 좋은 방법이 있었을탠데.. (문서화)

내 MBTI는 ENTP-A이다.
항상 즉흥적인것을 좋아하고 계획을 짜는것, 그것을 어딘가에 적어두는것과는 거리가 먼 삶이었다.

하지만 프로젝트를 진행하며 느낀점은.... 문서화 너무 필요하다는 것이었다.

우리팀이 겪은 문제점 :
잦은회의 => 그로 인해 계속 변경되는 수정사항을 모두 숙지하지 못함.

회의때는 다양한 의견을 주고받느라 정신없고 결국 문서화를 하지않으면 어떤 내용이 최종 결정사항인지 기억하지 못한다.

팀원모두와 내용을 공유하기 위해. 기억상실을 막기위해서 문서로 꼭 기록해두자.

🎉마감기한 그 이후...

결국 마감기한까지 원하던 목표만큼 완성하진 못했지만. 그 사이 많은 것들을 경험했고 이를 바탕으로 서비스는 계속 개발을 진행중이다.

회고라고 한다면 어떤 서비스인지, 어떤 코드를 작성했는지, 어떻게 개선했는지... 등등 작성하는 것이 일반적인 것같은데.
이번 회고에서는 코드보다 더 중요하다 생각했던 것들만 정리해봤다.

그래도 열심히 개발기간동안 완성한 코드들에 대해서는 2편에 적었다.