[DND] 사이드 프로젝트 <메이트립> 회고

DND 11기 1팀에서 진행한 사이드 프로젝트 메이트립에 대한 회고입니다.
Dec 11, 2024
[DND] 사이드 프로젝트 <메이트립> 회고
 

1. 사이드 프로젝트 목표 세팅

사이드 프로젝트 시작 전: 목표 세우기

DND에 지원하면서 이번 사이드 프로젝트를 통해 어떤 것을 얻고 싶은지 깊이 고민했다. 사실 합격할 거라 기대하지 않았는데, 막상 붙고 나니 놀랍기도 하고 설레었다. 특히, 전체 팀 중 안드로이드 개발자가 단 두 명뿐이라는 점이 신기했다. 다른 팀원들은 대부분 웹 개발자나 iOS 개발자라, 다양한 배경을 가진 사람들과 협업할 기회가 될 것 같아 기대가 컸다.

☝️ 역량을 키워서 성장하고 싶다

  • 커뮤니케이션 역량 : 백엔드 개발자, 서버 개발자, 디자이너와 협업하면서 소통 능력을 키우고 싶었다. 특히, 서로 다른 분야의 직군과 효과적으로 의견을 나누고 조율하는 법을 배우고 싶었다.
  • 기술적 성장 : Kotlin 기반 개발에 익숙하지만, 필요하다면 Java와 XML을 사용해보겠다는 다짐도 했다. 익숙하지 않은 환경에서 새로운 기술을 익히며 역량을 확장하고 싶었다.

✌️ 환경을 바꾸고 싶다 : 새로운 동력 찾기

  • 협업의 힘 : 혼자 진행하는 프로젝트는 꾸준히 이어가기 어려울 때가 많았다. 팀원들과 함께라면 더 즐겁고 책임감 있게 작업할 수 있을 거라고 기대했다.
  • 네트워킹 경험 : 관련 직군 종사자들과의 네트워킹은 항상 큰 동기부여가 되었다. 같은 관심사를 가진 사람들과 함께 목표를 이루어나가는 경험이 새로운 자극이 되기를 바랐다.
 

2. 가이드 기반 프로젝트 진행

사이드 프로젝트는 8주라는 제한된 기간 안에 결과물을 완성해야 했기 때문에, 현실적으로 구현 가능한 아이디어를 선정하는 것이 중요했다. 이 기간 동안 프로젝트의 기획, 개발, 테스트, 배포까지 모든 단계를 완료해야 했기 때문에 아이디어의 복잡성과 범위를 적절히 조정해야 했다. 실현 가능성을 중심으로 팀원들과 함께 아이디어를 브레인스토밍하며, 짧은 시간 안에 의미 있는 성과를 낼 수 있는 주제를 신중히 선택했다.
 
 

1️⃣ 1주차

1주차에는 간단한 자기소개로 시작해, 디스코드 음성 채팅을 활용해 첫 주 회의를 진행했다. 회의에서는 팀의 방향성과 아이디어를 정립하기 위해 진행하고 싶은 분야와 서비스 주제, 구현할 주요 기능을 선정했다.
이 과정에서 가장 중요한 단계였던 문제 정의를 심도 있게 논의했다. 어떤 서비스를 만들든, 그 서비스가 구체적인 문제를 해결할 수 있어야만 사용자에게 진정한 가치를 제공할 수 있기 때문이다.
최종적으로 우리가 선택한 주제는 다음과 같았다.
  • 분야: 여행
  • 서비스: 여행 동행 찾기
  • 핵심 기능: 기존 경쟁 서비스의 기능에 더해, 추천 알고리즘을 통해 차별화된 경험 제공
이 과정을 통해 다시 한 번 느낀 것은, 문제 정의의 중요성이었다. 이전에 진행했던 프로젝트 중에서도 문제 정의가 명확했던 경우가 가장 재미있고 몰입감 있게 느껴졌던 기억이 떠올랐다. 특히, 내가 직접 필요로 하고, 당장이라도 사용하고 싶다고 느낀 서비스일수록 동기부여가 더 강하게 작용했다. 이번 프로젝트 역시, 실제로 여행을 준비하거나 계획할 때 유용할 것 같은 서비스를 만들고 있다는 생각에 더욱 흥미가 생겼다.
 

2️⃣ 2주차

notion image
2주차에는 사용자 경험(UX)을 조사하는 데 집중했다. 이를 필드 리서치(Field Research)라고 하는데, 실제 사용자의 요구사항과 문제를 심층적으로 이해하기 위해 설문조사와 비대면 인터뷰를 진행했다. 설문조사를 통해 사용자들이 현재 겪고 있는 불편함과 니즈를 정량적으로 파악했으며, 인터뷰에서는 사용자들의 구체적인 경험과 감정을 더 깊이 탐구했다.
특히, 우리가 기획 중인 서비스와 비슷한 기존 서비스를 사용한 경험이 있는 사람들을 대상으로 조사하여, 경쟁 서비스의 장단점과 차별화 가능성에 대한 인사이트도 얻을 수 있었다. 이 과정에서 수집된 데이터는 서비스 기획과 핵심 기능 설계의 기반이 되었고, 사용자 중심의 서비스를 만들기 위한 중요한 첫걸음이었다.
 
notion image
2주차에는 페르소나(Persona)사용자 여정 지도(Journey Map)를 정의했다. 하지만 아쉽게도 다른 일정 때문에 2주차 회의에는 참석하지 못했다. 대신, 회의가 끝난 후 팀원들이 Figma에 작업한 내용을 살펴보며 여러 의견을 댓글로 남겼다. 비록 실시간 논의에는 참여하지 못했지만, 의견을 공유하고 피드백을 주고받는 과정을 통해 팀의 방향성에 기여할 수 있었다.
 
 
notion image
이 작업을 기반으로 정보 구조 설계(Information Architecture, IA)를 진행했다. 처음엔 단순히 콘텐츠를 나누는 작업처럼 보였지만, 실제로는 사용자 경험을 좌우하는 핵심 작업임을 깨달았다. 특히, 정보 구조가 사용자가 원하는 정보를 얼마나 빠르고 쉽게 찾을 수 있는지를 결정짓는 중요한 요소라는 것을 배웠다. 웹과 앱 기획에서 정보 구조는 단순한 설계 단계를 넘어, 사용자 친화적인 서비스 구현의 출발점임을 실감했다.
 
 

3️⃣ 4️⃣ 3-4주차 프로젝트 세팅

3주차부터 팀의 가이드라인이 변경되면서 역할이 명확히 나뉘었다. 개발자는 프로젝트 세팅기초 설계를, 디자이너는 Lo-fi/Hi-fi 디자인 작업을 맡아 진행했다. 이 작업은 2주 동안(3-4주차) 진행되어야 했는데, 막상 작업을 하다 보니 2주라는 기간이 다소 여유롭게 느껴졌다. 팀 리더가 "4주차까지는 디자이너가 바쁘고, 이후에는 개발자가 바빠질 것"이라고 했는데, 실제로 이 예측이 그대로 맞아떨어졌다.
 
💬 프로젝트 세팅: 기본 협업 환경 구축
이 기간 동안 개발팀은 프로젝트 세팅과 협업 환경 구성을 중점적으로 진행했다. 요구사항 구체화, 이슈 관리 도구 설정, 아키텍처 설계, 컨벤션 문서 작성 등 중요한 작업들이 이루어졌다.
 
  1. 요구사항 구체화
      • 개발팀이 협력하여 기능과 요구사항을 명확히 정의했다.
      • 이 과정에서 우아한테크코스 프리코스의 기능 요구사항 예시를 참고했는데, 이전에 프리코스를 진행한 경험 덕분에 빠르게 감을 잡을 수 있었다.
      • 단순히 요구사항을 나열하는 데서 그치지 않고, 놓친 부분이 없는지 반복적으로 검토하며 세부 사항을 다듬었다.
  1. 이슈 관리 도구 설정
      • Jira를 사용해 이슈를 관리하고, GitHub Issues를 통해 Pull Request를 연결했다.
      • 디자이너와 개발자가 서로의 진행 상황을 실시간으로 확인할 수 있어 협업 효율이 높아졌다.
 
💬 프로젝트 아키텍처 설계
아키텍처 설계는 개발팀 내에서 세부적으로 논의해 결정했다.
  • MVI(Model-View-Intent) 패턴
  • Clean Architecture
  • Multi-Module Architecture
이전에는 단일 모듈과 MVVM 패턴만 경험해 보았기에 새로운 아키텍처를 적용하는 것이 흥미로웠다. 다만, Clean Architecture의 적용은 다소 어려워 최종적으로 구현하지는 못했다. 리팩토링 단계에서 다시 도전할 계획이다.
 
💬 컨벤션 문서 작성
컨벤션 문서 작성은 팀 작업의 일관성 유지를 위해 가장 중요한 단계였다.
  • Git 브랜치 전략 : Git Flow 전략을 채택했다. 이전에 Github Flow만 사용해 봤기 때문에 새로운 브랜치 전략을 경험해 보고 싶었다.
  • Git 커밋 컨벤션 : 팀의 Git repository wiki에 커밋 컨벤션을 명시했다. 이를 통일하니 커밋 히스토리가 일정하고 보기 좋았다.
  • 코딩 컨벤션 : Kotlin 코딩 컨벤션을 적용하기로 했으나, Ktlint 플러그인을 활용하지 않아 완벽히 지키지 못한 부분이 아쉬웠다. 다음에는 플러그인을 통해 자동화된 수정 기능을 사용해 볼 계획이다.
 

4️⃣ 기술 스택 결정

팀원과의 논의를 통해 프로젝트에서 사용할 기술 스택도 최종적으로 결정했다.
  • 언어 : Kotlin
  • UI : Jetpack Compose
  • 비동기 처리 : Coroutine
  • 의존성 주입 : Hilt
  • 네트워크 통신 : Retrofit
  • 이미지 처리 : Coil
  • 로그인 : 카카오 API
  • 최소 Android 버전 : API 26
  • Gradle 버전 : 8.6
  • API 테스트 : Postman
이외에도 안드로이드 스튜디오 버전을 통일해 개발 환경의 일관성을 유지했다.
 
 
 

5️⃣ 5주차 중간 회고

notion image
Now in android repo를 참고하면서 개발 진행
  • 디자인 시스템 : 처음으로 디자인 시스템을 맡아 개발을 시작했다. 결과적으로, 이 모듈을 통해 중복되는 코드의 수를 줄이고, 유지 보수성을 높이는 데 큰 도움이 되었다. 이전 프로젝트에서 중복된 코드로 인해 발생한 문제를 피하고, 앞으로의 개발에서의 효율성을 높이는 기회를 제공했다.
  • 홈 모듈 : 내가 개발을 맡아 진행했는데 이번 홈 모듈 개발을 통해 앞으로 중복될 가능성이 높은 코드를 사전에 방지하고, 전체 프로젝트의 구조를 정리하는 데 기여할 수 있었다.
  • 로그인 및 온보딩, 마이페이지 모듈 : 팀원 분이 맡아 개발을 진행했다.
 
회고와 배움의 기회
중간 회고를 진행하려고 했으나, 기록을 남기지 못해 아쉬움이 남았다. 사진만 남아 있어 나중에 이를 바탕으로 추억할 수 있겠지만, 기록의 중요성을 새삼 깨닫게 된 계기였다. 다음 프로젝트에서는 매일 TIL을 작성하고, 회고 때 기록을 남길 수 있도록 할 계획이다.
 
 

6️⃣ 6주차 프로토타입 데모

이때까지 개발한 부분만 시뮬레이터 돌려서 제출했다.
 
 

7️⃣ 7주차 우선 순위 조정

개발은 언제나 계획대로만 진행되지 않는다. 이번 주에도 예상보다 기능 개발이 지연됐다. 여러 이유가 있었지만, 내가 맡은 홈 모듈 개발에서 발생한 문제들이 가장 큰 원인이었다.
  • 네트워크 통신 문제
    • 데이터가 제대로 전달되지 않는 문제가 발생했다. 스택오버플로우에 질문하고, 안드로이드 개발자 오픈채팅방에서 조언을 구하며, 팀원들에게 도움을 요청한 끝에 원인을 찾을 수 있었다.
    • 문제는 뷰모델 인스턴스 생성 방식에 있었다. 상위 모듈에서 생성한 인스턴스를 하위 모듈로 전달했어야 했지만, 각 모듈에서 따로 인스턴스를 생성하다 보니 사용자 입력값이 제대로 전달되지 않았다.
    • 상위에서 하위로 값이 잘 흐른다고 착각하고 있었던 점도 해결이 지연된 이유 중 하나였다.
  • 타입 불일치 문제
    • 또 다른 문제는 날짜 형식 때문이었다. 서버에서 원하는 형식으로 변환하는 함수를 잘못 작성한 줄 알았지만, 사실은 타입 자체가 문제였다. 처음에는 서버가 String 타입으로 데이터를 받길래 String으로 처리했지만, 로그를 찍어보니 날짜 형식이 서버에서 원하는 것과 달랐다.
    • 이를 Java의 LocalDateTime으로 바꿔 처리해봤지만 여전히 해결되지 않았다. 결국 문제는 문자열로 감싸는 형식에 있었다.
    • 올바른 형식으로 문자열을 감싼 뒤에야 데이터가 제대로 전달되었다. 이 과정에서도 팀원들과 슬랙으로 활발히 소통하며 문제를 해결했다.
결국, 개발 일정이 늦어지면서 최종 발표까지 어려움이 예상되었다. 이에 따라 FCM(알림) 기능은 우선순위를 낮추고 발표 이후로 미루기로 결정했다.
 

8️⃣ 8주차 최종 발표

notion image
최종 발표는 오프라인으로 진행되었지만, 개인적인 사정으로 참여하지 못해 아쉬움이 컸다. 다음에는 팀원들과 꼭 오프라인에서 직접 만나보자는 이야기를 나누며, DND 활동을 공식적으로 마무리했다.
1주차 첫날, 각자의 목표를 공유하며 시작했던 기억이 떠올랐다. 당시 팀원들 중에는 배포와 운영 경험을 쌓고 싶다고 말한 이들도 있었다. 이를 떠올리며, 앞으로도 프로젝트를 이어갈지 논의한 끝에 만장일치로 개발을 계속 진행하고, 운영을 목표로 삼자는 결론을 내렸다.
 
 
 

3. 배포를 앞두고 사이드 프로젝트에 대해 회고하기 : KPT

🔥 KEEP

  • 새로운 기술 적용 : Hilt, Multi-Module, Git-Flow 브랜치 전략, MVI 패턴, Paging3, Cursor 기반 페이징 기법, UiState 등을 학습하고 프로젝트에 적용했다. 또한, Postman을 활용해 API 테스트를 수행하며 실무적인 경험을 쌓았다.
  • 슬랙 연동으로 작업 효율 향상 : 백엔드 개발자분의 도움으로 깃허브 이슈 변동 사항을 슬랙에 알림으로 받아볼 수 있었다. 작업 진행 상황을 실시간으로 파악할 수 있어 협업이 한층 원활해졌다.
  • 열정적인 팀원들과의 협업 : 책임감과 열정이 가득한 팀원들과 함께할 수 있어 정말 즐거운 시간이었다. 🥰
 

😭 PROBLEM

  • 일정 관리 : 3주차부터 전체 일정이 지연되었다. 회고 중에도 일정 관리에 대한 아쉬움이 나왔다.
  • 커밋 단위와 이슈 번호 활용 : Git 커밋 단위가 너무 작다고 느꼈다. 앞으로는 이슈 번호를 커밋 메시지에 포함해 작업 내역을 명확히 관리하고 싶다.
  • 깃허브와 Jira 연동 부족 : Jira로 이슈를 관리했지만, 깃허브 이슈와 연동하지 않아 작업 흐름을 더 효율적으로 관리하지 못한 점이 아쉬웠다.
  • 테스트 미비 : 테스트를 작성하지 못했다. 배포 이후 시간을 내어 꼭 테스트를 추가하고 싶다.
  • iOS 배포 : iOS 앱 배포를 위해 Flutter 리포지토리를 만들어놨지만 혼자 진행하려니 막막하다. Swift나 SwiftUI로 새롭게 시도할지 고민 중이다. 코틀린 멀티플랫폼으로 개발했으면 더 수월했을 텐데, 이 부분이 특히 아쉽다.
  • 클린 아키텍처 리팩토링 : 프로젝트를 클린 아키텍처로 리팩토링하면 구조적 개선뿐만 아니라 큰 공부가 될 것 같다.
  • 비공개 테스트 환경 : 팀 계정을 새로 생성해 비공개 테스트를 다시 해야 하지만, 테스터 모집이 쉽지 않다. 처음부터 테스터를 모았으면 좋았을 텐데, 앞으로는 이 부분도 철저히 준비해야겠다.
 

👊 TRY

  • 테스트 작성 : 반드시 테스트 코드를 작성해 품질을 보장하고 싶다.
  • iOS 앱 배포 : iOS 앱 배포를 위해 Flutter 프로젝트를 이어가거나, Swift/SwiftUI로 새롭게 시도해보고 싶다. 아니면 React Native도 좋을 것 같은데 고민해봐야할 것 같다.
  • 알림 기능 추가 : 프로젝트에 알림 기능을 구현해 사용자 경험을 더욱 풍부하게 만들고 싶다.
  • 더 나은 팀원으로 성장 : 이번에는 도움을 받는 팀원이었지만, 다음에는 도움을 줄 수 있는 팀원이 되고 싶다!
 
 

4. DND 후기 🐥

 
 

5. 프로젝트 구경가기! 🚀

재밌는 동행의 시작, 메이트립! 메이트립은 여행 동행에 관심이 있는 사람들을 위한 서비스입니다.
동행에 관심은 있지만 상대방이 신뢰할 만한 사람인지, 나와 잘 맞는 사람인지 모르겠다구요? 🤷‍♀️🤷‍♂️
메이트립에서는 상대방의 인증 수단과 기본 정보, 성격, 여행 성향, 여행 스타일 등 동행에 필요한 필수 정보들을 확인할 수 있어서 상대방에 대한 신뢰도는 물론! 나와 비슷한 성향을 가진 동행자를 더욱 편리하게 찾을 수 있습니다.
또한, 동행이 끝났다면 상대방과의 동행 후기를 작성해서 동행자와 추억을 간직할 수 있고 다음 동행자에게 도움을 줄 수 있습니다. 메이트립에서 재미있는 동행을 경험해 보세요!
Share article

code-with-me