고윤태의 개발 블로그

누구나 접근하기 쉽지만 얻어 가는 것이 있는 글을 쓰기 위해 노력 중입니다.

기타

펫밀리 회고록

고윤태 2024. 4. 18. 10:45

1. 프로젝트 개요


1-1. 이 멤버가 모이게 된 스토리

💡 우리 모두의 이야기를 한데 모으기 전에, 잠깐! 이 모임에 합류하게 된 계기부터 소개해볼까요?

팀원

해당 프로젝트의 팀원은

  • 고윤태 🦮 [프론트엔드]
  • 신영석 🐩 [백엔드]
  • 서연주 🐈 [디자이너]
  • 공윤혜 🐈‍⬛ [PM]

 

총 4명으로 구성이 되어 있었습니다. 합류 이야기는 저의 이야기만 공유드리겠습니다.


안녕하세요 프론트엔드 개발자 고윤태입니다.

저는 평소 토이 프로젝트를 진행하는 것을 매우 좋아했습니다. 이에는 몇 가지 이유가 있습니다.

  1. 새로운 기술 스택의 사용
  2. 다양한 패턴으로의 코드 구현
  3. 기획 단계부터 참여하는 제품 개발
  4. 새로운 분야에 대한 지식 습득

 

토이 프로젝트를 통해 이런 기회를 얻고, 큰 만족감을 느꼈습니다. 운이 좋게도, 하나의 프로젝트 팀을 구성할 수 있었는데, 이는 상당히 큰 규모의 팀이었습니다.

팀의 구성은 다음과 같았습니다.

  • PM 2명
  • 디자이너 2명
  • 프론트엔드 개발자 3명
  • 백엔드 개발자 3명
  • 데이터 수집가 1명

 

이 규모는 작은 스타트업을 넘어서는 것이었습니다. 하지만 프로젝트를 진행하다 보니, 프로젝트 주제로 사업을 시작하려는 계획이 있었고, 저에게 이직을 제안받았습니다. 조건이 맞지 않아 팀을 떠나게 되었지만, PM, 디자이너, 프론트엔드, 백엔드 개발자로 구성된 스쿼드 형태의 팀에서 토이 프로젝트를 진행했던 경험이 너무 좋았습니다.

그래서 결국, 저 스스로 직접 팀을 모으게 되었습니다.


1-2. 펫밀리 소개 🐈‍⬛

🥕당근 앱을 사용해 보신 적 있으신가요? 중고거래를 해본 사람이라면 당근을 모를 수 없을 텐데요. 저희는 한 단계 나아가 반려인을 위한 중고거래 커뮤니티 서비스를 기획해 보았습니다. 저희가 이 서비스를 기획하게 된 배경과 어떤 마음으로 이 서비스를 만들 게 되었는지 소개해 드릴게요!

반려인을 위한 중고거래 서비스는 왜 필요할까?

반려동물 1,500만 시대에 접어들며 주변에서 반려동물을 키우는 사람들이 많아지고 있는 걸 체감하고 있는데요. 반려인들의 증가로 반려동물을 위한 사료나 장난감 등의 용품을 구매하는 사람들도 늘어나고 중고거래 비율도 늘어나고 있었어요. 주변 지인들도 강아지 용품이나 사료 등을 구매한 후 처리하지 못해 동네에 나눔을 하는 식으로 당근 앱을 사용하고 있다는 걸 알고 ‘반려인을 위한 중고거래 플랫폼’으로 범위와 타깃을 좁혀 마이크로세그멘테이션 해보기로 했어요. (그리고 무엇보다 저희 팀원들이 모두 동물을 사랑하는 동물애호가라 즐겁게 프로젝트에 참여할 수 있을 거 같았어요!😊)

“마이크로세그멘테이션” : 마이크로세그멘테이션이란 아주 작은 계층만 타깃으로 하는 것을 말한다. 특정 타깃 소비자의 수요에 집중해 고객이 '나에게 더 적합한 제품'이라고 느낄 수 있도록 만드는 경우

Pet+Family = 펫밀리!

‘펫밀리’라는 저희 서비스 이름은 프론트 개발자인 윤태 님이 아이디어를 내서 만장일치로 채택되었는데요! 강아지를 뜻하는 펫과 반려동물을 사랑하는 동네 반려인들 모두 가족이라는 의미를 담아 직관적이면서도 따뜻한 펫밀리라고 지었어요!

타겟 중심 서비스 엣지 더하기

단순히 반려용품 중고거래 플랫폼이면 차별성이 없다고 느껴져 어떻게 하면 서비스의 엣지를 살릴 수 있을까 고민했어요.

펫밀리를 사용하게 될 사용자는 누구일까요? 결국 같은 동네에서 반려동물을 키우는 반려인들일 거예요. 반려인들이 단순 중고거래 용도로 이 서비스를 사용하기보단 좀 더 연결고리를 강화하고 싶었고, 동네 기반의 산책 모임을 개설할 수 있는 서비스를 제공하면 가치를 전달할 수 있겠다 싶었어요. 컨셉을 설정하고 아이디어를 더하면서 서비스 가닥을 잡고 주요 기능과 저희가 전달하고 싶은 서비스만의 가치를 잡아나갔어요!

주요 기능

  • 반려동물용품 중고거래 반려인들은 펫밀리를 통해 사용하지 않는 반려동물 용품을 판매하거나 필요한 용품을 저렴하게 구매할 수 있어요. 또한, 위치기반 지역 앱으로 지역 주민과 관심 물품에 대해 채팅으로 약속을 만들고 거래할 수 있어요.
  • 동네 친구와 함께하는 산책모임 펫밀리는 사용자들이 주변 동네 친구들과 함께 산책하는 모임을 만들고 참여할 수 있는 기능을 제공해요. 펫밀리를 통해 새로운 동네 친구들을 만나고 반려동물의 사회성도 키워줄 수 있어요.

펫밀리의 가치

  • 지역 커뮤니티 형성: 동네 주민들 간에 소통과 교류를 촉진하는 역할을 해주어요. 동네 주민들이 자신의 필요에 맞는 물건을 찾거나 판매함으로써 지역 사회가 더욱 활성화되고, 같은 지역에 있는 반려견과 함께 산책할 수 있어 친구들을 찾을 수 있는 기회도 제공하여 소통과 연결을 강화해 줘요!
  • 유대감과 반려동물 사회성 증가: 같은 지역에 있는 반려견과 함께 산책하면서 다른 반려견 주인들과의 사회적 상호작용을 할 수 있고, 사용자들 간의 소통과 교류를 증가로 유대감을 형성하는 데 도움이 돼요!

 

2. 우리의 협업


2-1. Storybook 사용기

storybook이란?

 

 

새로운 도구나 기술에 대해 알아볼 때, 그 시작은 항상 자기소개에서부터입니다. 스토리북 홈페이지 메인에서 제공하는 자기소개를 살펴볼까요?

Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient

 

"UI 컴포넌트 개발을 위한 오픈소스 도구로서 React, Vue, Angular에 대한 개발을 독립적으로 지원합니다. 이를 통해 UI를 체계적이고 효율적으로 만들 수 있습니다."

단순히 이 설명만으로는 스토리북이 어떻게 작업을 효율적으로 만들어주는지 와닿지 않을 수 있습니다. 그렇다면 자세한 소개를 확인해 볼까요?

Storybook is a user interface development environment and playground for UI components. The tool enables developers to create components independently and showcase components interactively in an isolated development environment.

 

스토리북은 UI 개발 환경이자 UI 컴포넌트의 놀이터입니다. 이 도구는 개발자가 컴포넌트를 독립적으로 생성하고, 격리된 개발 환경에서 컴포넌트를 상호작용하며 선보일 수 있게 해 줍니다.

storybook 세팅

스토리북을 처음 설정할 때 많은 고민이 있었습니다. 설치 과정 자체는 간단하지만, 협업을 목적으로 선택한 만큼 디자이너와 PM도 확인할 수 있어야 했습니다. 에뮬레이터 설치와 실행의 러닝커브가 부담스러웠고, 에뮬레이터 사용에 대한 어색함도 예상되었습니다.

이러한 이유로, 앱의 컴포넌트를 웹에서 볼 수 있게 하고 웹을 배포하기로 결정했습니다. 초기 설정에 도움이 된 자료는 다음과 같습니다:

이 정보가 비슷한 상황에 있는 분들에게 도움이 되길 바랍니다.

storybook으로 얻은 이점

스토리북을 사용하면서 얻은 이점은 디자인 시스템 내 컴포넌트의 조화와 사용성 확인을 넘어섭니다. 프로젝트의 개발 효율성과 품질이 크게 향상되었으며, 개발자와 디자이너 간의 원활한 커뮤니케이션을 가능하게 했습니다. 프로젝트의 일관성과 재사용성이 개선되었습니다.

스토리북 사용으로 얻은 주요 이점은 다음과 같습니다:

  1. 컴포넌트 기반 개발의 가시성 향상: 개발자들은 스토리북을 통해 개별 컴포넌트를 독립적으로 확인하고, 다양한 상태와 변형에서의 동작을 미리 볼 수 있습니다. 이는 컴포넌트의 재사용성을 높이고, 오류 발생 가능성을 줄이는 데 도움을 줍니다.
  2. 디자인-개발 간의 간극 줄임: 디자이너와 개발자 간의 소통이 용이해지며, 디자인 시스템의 컴포넌트를 실제 코드로 빠르게 변환할 수 있습니다. 스토리북을 통해 제공되는 문서와 인터페이스는 양쪽 모두에게 명확한 가이드라인을 제공합니다.
  3. 프로젝트 문서화의 자동화와 개선: 스토리북은 컴포넌트의 기능과 사용 방법을 문서화하는 데 이상적인 플랫폼을 제공합니다. 이는 새로운 팀원이 프로젝트에 빠르게 적응하고 기존의 컴포넌트를 재활용하는 데 큰 도움이 됩니다.
  4. 테스팅 및 디버깅의 용이성: 스토리북을 사용하면 개발자가 컴포넌트를 분리하여 테스트할 수 있어, 복잡한 애플리케이션 내에서 버그를 식별하고 수정하기가 더 쉬워집니다. 이는 품질 관리 과정을 간소화하고, 최종 제품의 안정성을 높입니다.
  5. 개발 과정의 효율성 증대: 컴포넌트의 시각적 검증이 용이해지며, 디자인 변경 사항을 신속하게 반영할 수 있습니다. 이는 프로젝트의 속도를 높이고, 시장 출시 시간을 단축하는 데 기여합니다.

종합적으로, 디자인과 개발의 통합을 촉진하고, 고품질의 사용자 인터페이스를 보다 효율적으로 생성하는 데 중요한 역할을 해준 협업 도구였습니다.


2-2. 배포 히스토리

저희 팀은 기능 개발이 완료될 때마다 QA를 위해 해당 기능을 배포하고, 팀 전체에 새로운 기능의 배포 사실을 알리는 방식으로 진행해 왔습니다. 이 과정에서 개발자는 Git Commit History를 통해 개발 상황을 파악할 수 있었지만, PM과 디자이너는 작은 수정 사항을 놓치는 경우가 종종 발생했습니다. 심지어 저 역시도 "이번 배포에 어떤 변경 사항이 있나요?"라는 PM의 질문에 과거 배포의 범위를 기억하지 못해 정확한 답변을 하는 데 어려움을 겪었습니다.

개발자에게는 Git의 태그(tag)를 통한 버전 관리가 해결책일 수 있지만, PM이나 디자이너에게는 이 방법이 직관적이지 않았습니다. 이러한 문제를 해결하기 위해, 저희는 배포 히스토리를 작성하여 팀원과 공유하기 시작했습니다.

 

배포 히스토리를 작성하고 공유하는 과정은 다음과 같은 이점을 제공했습니다.

 

  1. 명확한 변경 사항의 전달: 배포 히스토리를 통해, 이번 배포에 포함된 변경 사항과 확인해야 할 부분이 명확해졌습니다. 이로 인해 PM과 디자이너는 개발 상황을 더 쉽게 이해할 수 있게 되었습니다.
  2. 팀 내 커뮤니케이션 개선: 배포 히스토리는 개발자, PM, 디자이너 간의 커뮤니케이션을 간소화하고 효율화하는 데 기여했습니다. 모든 팀원이 변경 사항을 한눈에 파악할 수 있어, 불필요한 질문과 혼란을 줄일 수 있었습니다.
  3. 시간 절약과 효율성 증가: 수정사항을 찾으려고 시간을 사용하는 대신에, 배포 히스토리를 통해 쉽게 정보를 얻을 수 있게 되어, 팀 전체의 작업 효율성이 향상되었습니다.
  4. 프로젝트 문서화의 강화: 배포 히스토리는 프로젝트의 중요한 문서화 과정 중 하나가 되었습니다. 이를 통해 프로젝트의 진행 상황을 기록하고, 필요한 경우 과거의 결정이나 변경 사항을 쉽게 참조할 수 있게 되었습니다.

배포 히스토리의 도입은 PM과 디자이너뿐만 아니라 개발자에게도 긍정적인 영향을 미쳤습니다. 이는 팀원 모두에게 만족스러운 경험을 제공하며, 프로젝트 관리의 투명성과 효율성을 높이는 데 크게 기여했습니다.

개발자에게는 Git의 태그(tag)를 통한 버전 관리가 해결책일 수 있지만, PM이나 디자이너에게는 이 방법이 직관적이지 않았습니다. 이러한 문제를 해결하기 위해, 저희는 배포 히스토리를 작성하여 팀원과 공유하기 시작했습니다.

배포 히스토리를 작성하고 공유하는 과정은 다음과 같은 이점을 제공했습니다:

  1. 명확한 변경 사항의 전달: 배포 히스토리를 통해, 이번 배포에 포함된 변경 사항과 확인해야 할 부분이 명확해졌습니다. 이로 인해 PM과 디자이너는 개발 상황을 더 쉽게 이해할 수 있게 되었습니다.
  2. 팀 내 커뮤니케이션 개선: 배포 히스토리는 개발자, PM, 디자이너 간의 커뮤니케이션을 간소화하고 효율화하는 데 기여했습니다. 모든 팀원이 변경 사항을 한눈에 파악할 수 있어, 불필요한 질문과 혼란을 줄일 수 있었습니다.
  3. 시간 절약과 효율성 증가: 수정사항을 찾으려고 시간을 사용하는 대신에, 배포 히스토리를 통해 쉽게 정보를 얻을 수 있게 되어, 팀 전체의 작업 효율성이 향상되었습니다.
  4. 프로젝트 문서화의 강화: 배포 히스토리는 프로젝트의 중요한 문서화 과정 중 하나가 되었습니다. 이를 통해 프로젝트의 진행 상황을 기록하고, 필요한 경우 과거의 결정이나 변경 사항을 쉽게 참조할 수 있게 되었습니다.

배포 히스토리의 도입은 PM과 디자이너뿐만 아니라 개발자에게도 긍정적인 영향을 미쳤습니다. 이는 팀원 모두에게 만족스러운 경험을 제공하며, 프로젝트 관리의 투명성과 효율성을 높이는 데 크게 기여했습니다.


2-3. 일정 관리 Jira를 도입해 보자

우리가 생각하는 일정 관리란?

프로젝트를 진행하는 팀에게 가장 중요한 요소 중 하나는 무엇일까요? 저는 바로 일정 관리라고 생각합니다. 팀원들이 스케줄을 공유하며 각자 해야 할 일을 명확히 이해하는 것, 이 모두가 효과적인 일정 관리의 일환입니다. 제 경험에 따르면, 일정 관리가 잘 이루어지는 팀은 목표 달성을 향해 흔들림 없이 전진한다는 것을 느낄 수 있었습니다.

일정 관리 1부 Notion

처음 저희 팀이 선택한 일정 관리 도구는 당시 저희에게 친숙했던 Notion이었습니다.

 

나름대로 편하게 잘 사용하고 있었지만 사용하면서 한계에 부딪혔습니다.

열심히 사용하다 보니 경고등이 들어왔답니다. 😅

Notion의 무료 버전 한도를 모두 사용해 버려, 추가적인 일정 관리나 문서화 작업이 불가능해졌습니다. 이 상황에서 프로젝트를 계속 진행하기 어렵다고 판단하여, 백엔드 개발자인 영석과 긴급회의를 시작했습니다.

(제가 돈이 많았더라면 Notion의 Pro Plan을 구매했을 것입니다.)

 

📢 영석과의 대화
  🦮 (윤태) :
우리 notion 요금제 초과라 이제 사용을 할 수가 없어
  🐩 (영석) :
어쩔 수 없이 다른 거 써야지
  🦮 (윤태) :
Jira가 젤 낫겠지?
  🐩 (영석) :
그렇지
  🦮 (윤태) :
보드 하나 파!

 

이러한 심도 있는 대화를 통해 Jira를 사용하기로 긴급 대책 회의를 종료했습니다.

일정 관리 2부 Jira

Jira 도입을 위해 팀원들에게 Jira 사용 경험을 물어본 결과, 사실상 능숙하게 사용할 수 있는 사람은 거의 없었습니다. 그래서 우리는 Jira 사용법에 대한 스터디를 진행했지만, 러닝 커브가 상당히 높다고 느꼈습니다. 결국, 우리에게 친숙한 Notion에서의 일정 관리 UX를 모방하여 Jira를 사용하기로 한 결론을 내렸습니다.

회사에서 정해진 룰대로 사용은 해봤어도 Jira의 초기 세팅을 해본 적은 없었는데요 역시나 시작부터 난관에 봉착했습니다.

바로 템플릿 만들기… notion을 사용할 때는 캘린더 하나를 만들어 캘린더에 보드도 추가하고 사용했지만

Jira를 사용하려고 하니 보이는 무수히 많은 템플릿...

 

 

이것저것 만들어보고 검색도 해보면서 어떤 게 제일 좋을까 고민했지만 notion과 비슷하게 가장 기본인 칸반 템플릿으로 결정!!

하지만 이게 끝이 아니었습니다…

최대한 기존의 Notion에서 사용했던 방법과 동일하게 사용하여 러닝커브 없이 다른 팀원들이 능숙하게 사용하길 기대하며 기존과 동일하게 백엔드, 프론트, 디자인, 기획, QA수정사항 등 여러 가지 업무를 태그들로 나누려고 봤더니 Jira에는 에픽이란 게 존재했습니다.

그래서 에픽도 추가해 주고 이슈 속에 체크박스 같은 것도 사용해 보려고 했더니 이것 또한 추가 작업이 필요해 열심히 검색해서 추가해 주고 나니 드디어 완성된 엉성하지만 나름의 우리의 일정관리 템플릿!!

 

 

시작하기가 조금은 어려웠지만 만든 후 서로 일정에 대해 파악하기 쉬웠고 에픽과 하위 작업 등을 통하여 기존 Notion보다 세밀하게 일정 관리와 업무 분담을 할 수 있었습니다.


2-4. 우리가 오프라인 회의만 진행한 이유

토이 프로젝트 팀을 모집할 때 Hola나 인프런 같은 사이트를 살펴보면, 많은 팀이 온라인 회의와 함께 오프라인 회의를 필수적으로 진행하고 있음을 알 수 있습니다. 제가 팀을 모집할 때, 서울이 아닌 다른 지역에 거주한다는 이유로 필요한 인재를 놓칠 수 있다는 우려가 있었습니다.

일부는 팀원 간의 친밀감을 위해 오프라인 회의의 중요성을 강조하지만, 저를 포함한 팀원 대부분이 이미 서로를 알고 있는 사이였고, 저는 디스코드를 통한 온라인 활동도 활발히 하고 있었습니다. 따라서, 사람 간의 정이 온라인과 오프라인에서 다르다고 느낀 적은 없었습니다.

가장 결정적인 이유는 모든 구성원이 직장인이라는 점이었습니다. 오프라인 회의 장소로 이동하는 시간을 절약하고 싶었고, 온라인 회의는 시간 조정이 더 유연하기 때문입니다. 직장인으로서 예기치 못한 사정이 생겼을 때, 회의 시간을 유연하게 조정할 수 있다는 장점이 있었습니다.

그럼에도 불구하고, 오프라인 회의가 가진 이점은 분명 존재합니다. 서로의 의견이 충돌할 때, 상대방의 표정으로 의사를 파악할 수 있는 것이 큰 장점입니다. 하지만 첫 회의 때 팀원들이 서로의 의견을 잘 개진하는 모습을 보고, 이런 우려는 문제가 되지 않을 것으로 판단했습니다.

결과적으로, 우리는 오프라인 회의만을 진행하기로 결정했고, 이 결정에 모든 팀원이 만족하는 결과를 얻을 수 있었습니다.

 

3.  프로젝트를 마치며


우리 팀은 리더와 팔로워의 구분 없이, 모두가 동등한 팀원으로서 공동체 의식을 바탕으로 프로젝트를 진행했습니다.

비록 주인공 의식이 작용했을 수 있지만, 대부분의 팀원들이 저를 사실상의 리더로 인식했을 가능성이 높습니다. 이는 저 자신이 이 스쿼드의 구성원을 모으는 데 중심 역할을 했기 때문일 겁니다.

가끔은 저도 모르게 리더의 역할을 수행하고 있었던 순간들이 있었습니다.

이전에 프론트엔드 팀의 리더를 맡은 경험이 있었지만, 이번처럼 스쿼드의 리더 역할을 맡는 것은 예상외로 큰 중압감을 느끼게 했습니다.

저를 포함한 4명의 팀원이 각자 다른 역할을 수행하면서, 소통의 중심이 되어야 했고, 저는 제 의견을 잘 전달하면서도 동시에 다른 사람의 의견을 존중하고 수용할 준비가 되어 있어야 했습니다.

개발자로서 만족스럽지 않은 의견이 제시될 때도, 팀적 관점에서 볼 때 긍정적인 측면이 있다면, 그 의견을 받아들여야 했습니다.

 

이런 경험을 통해, 잘한 부분이든 못한 부분이든, 자처한 리더로서 제 모습이 어떠했는지 팀원들에게 직접 물어보고 싶다는 생각이 듭니다.

(아마도 팀원들이 친절하게만 대답해 주실 것 같네요.)

이 프로젝트를 진행하며 저에게 가장 큰 이점을 준 것은, 사람들과 대화하는 것을 좋아하는 제 성격이었습니다.

평소 다양한 분야의 직원들과 대화를 많이 나누는 편인데, 이러한 경험을 통해 얻은 지식이 큰 도움이 되었습니다.

팀원들에게 업무 방식에 대한 레퍼런스를 공유하거나, 유용한 협업 도구, 해당 직군의 일하는 방식에 대해 어느 정도 알고 있었기 때문에, 일정 조율이나 서로의 원하는 방식을 잘 파악할 수 있었습니다.

이번 프로젝트를 통해 가장 크게 얻은 것은, 아마도 팀을 리딩하는 방법일 것입니다.

이 경험을 통해 리더가 아닌 팔로워의 역할을 수행하더라도, 리더의 요구사항을 더 유연하게 받아들일 수 있는 사람이 되었다고 생각합니다.

 

전체 글은 하단 링크에서 확인하실 수 있습니다.

https://nervous-adjustment-25e.notion.site/37b2d7e2faf943019ad479d937c7b120?pvs=4

 

펫밀리의 회고록 | Notion

1. 프로젝트 개요

nervous-adjustment-25e.notion.site

하단 링크는 펫밀리의 협업을 위해 사용했던 노션 워크스페이스 입니다. 참고하셔도 좋을 것 같습니다.

https://glass-metal-4a8.notion.site/c4b9280c319d49cdbf21e10739568655?pvs=4

 

'기타' 카테고리의 다른 글

제가 재밌게 읽었던 글을 소개합니다.  (0) 2023.08.10