3주차 그룹 멘토링 일지 - Team-HGD/SniffMEET GitHub Wiki

✔️ 결론 및 To Do

멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.

문제 해결 과정도 Wiki에 추가
MVP 중에 기능 좀 더 쳐내기

✔️ 멘토링 아젠다

멘토링 24시간 전에 준비하여 멘토에게 공유합니다.

논의 사항 및 질문

멘토의 조언이 필요한 부분을 질문으로 정리합니다.

Local Network를 통한 메이트 맺기 과정 추상화

현재는 Local Network를 통해 메이트 맺기를 진행하고 있습니다.

확장성을 고려하여 remote network로도 동작할 수 있게끔 추상화를 적용하여 설계를 하고 싶었습니다.

하지만 둘의 진행과정이 상이한 부분이 있어서 설계에 조금 어려움이 있었는데요.
- Local Network를 통한 과정
  1. 주변 탐색하기
  2. Peer 찾아서 연결 진행하기
  3. 데이터 송수신
- Remote Network를 통한 과정
  1. 이미 Peer를 알고 있는 상태에서 해당 Peer에 대한 정보 요청하기
  2. 데이터 송수신
고려해야할 사항이나 구조 설계 팁이 있을까요?

/// 코어 레이어
protocol DataTransfer {}

final class LocalDataTransferImpl: DataTransfer {}

final class RemoteDataTransferImpl:DataTransfer  {}

/// 서비스 레이어
protocol 데이터를보내는Usecase {}

final class 데이터를보내는UsecaseImpl: 데이터를보내는Usecase {

  let remoteDataTransfer: DataTransfer
  let localDataTransfer: DataTransfer

  func execute() {
    if {
      remoteDataTransfer....
    } else {
      localDataTransfer
    }
  }
}

final class SomeViewController {
 let useCase: 데이터를보내는Usecase
}

이용가능한 Peer 관리

MultiPeerConnectivity(이하 MPC)와 NearByInteraction(이하 NBI)를 이용하여 메이트를 찾는 플로우는 다음과 같습니다.
1. MPC를 통해 주변 peer와 session 연결
2. MPC session을 이용하여 NBI 간 토큰 교환 및 세션 연결
3. 제일 거리 값이 가까운 peer에 대해서만 MPC로 데이터 공유
MPC로 주변 peer에 연결할 때, 원하는 상대인지 확인하거나 선택할 수 없고 MPC는 최대 7명까지 연결 유지할 수 있습니다.

만약 유저에 7명 이상이 주변에서 ‘메이트 맺기’ 기능을 사용한다고 가정하고 그 중 유저가 원하는 상대를 제외한 7개의 연결을 유지되는 상황이 발생합니다.

시스템에서 임의로 연결을 끊어줘야한다고 생각합니다.

생각한 문제해결방식은 다음과 같습니다.
1. 연결에 제한시간을 두는 방식입니다. (TTL)
2. 7명 이상 연결을 유지하고 있을 때 새로운 피어가 발견된다면 제일 먼저 생성된 연결을 끊고 새롭게 연결을 유지하는 것입니다.
위 문제 해결방식이 적합한지 궁금합니다. 또 핵심 기능에서 발생할 문제라고 생각하여 우선적으로 생각하고 있는데 이런 상황을 가정하면서 까지 문제해결을 하는게 맞는지 궁금합니다.

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

MVP 선정

기존 프로젝트의 크기가 6주 프로젝트 기간에 적합하지 않다고 판단했습니다. 따라서 MVP를 정하고 개발을 시작하였습니다.

MVP에 포함되는 기능은 다음과 같습니다.
- 익명 로그인을 이용한 반려동물 정보 등록
- Local Network를 통한 메이트 맺기 기능
- 메이트에 산책 요청 및 응답
완성된 GUI 보시면 확인이 빠를거 같아 첨부합니다.
- MVP
https://www.figma.com/design/hqvx1sLktjajEBcT0lGhyd/SniffMeet?node-id=3-2&node-type=canvas&t=wEQRwXbKBDYRE0ZV-0
서버 프로바이더 변경 및 패턴 결정

서버를 Firebase를 활용해서 구축하려고 결정했었습니다. API 요청 제한 개수가 작다는 점과 새로운 걸 시도하고 싶다는 의견을 합쳐 SupaBase를 이용하기로 변경하였습니다.

패턴은 VIPER 패턴을 선택했습니다. VIPER 패턴이 가지는 장점인 확실한 모듈간의 역할 분리를 통해 각 SOLID SRP에 대해 좀 더 깊은 이해를 할 수 있고, 이로 인해 하나의 컴포넌트에 많은 기능이 집중되는 경험을 하지 않아도 되기 때문입니다. 또한 모듈간의 역할 분리를 더 심화시키는 차원에서 Router에서 모듈 생성 책임을 따로 Builder로 분리해서 사용하도록 정했습니다. 그래서 정확한 패턴은 VIPER + Builder 입니다.

기존에 비슷한 아키텍처만 사용하다가, 새로운 아키텍처를 적용함으로써 아키텍처 그 자체에 대한 학습도 진행할 수 있다고 생각합니다.
개발 진척 사항

현재 핵심 기능 개발과 뷰 작업을 진행하고 있습니다.
1. 뷰 작업
  
  개발이 완료된 뷰에 대해서는 관련 PR을 첨부합니다.
2. 핵심 기능 - MPC, NBI
  
  현재 MPC는 PoC를 마친 상태이고 구조 설계 및 구현을 맞췄습니다.. NBI는 PoC 진행 중에 있습니다.
  - 초기 구상이었던 에어드랍 방식에서 변경
    
    초기 기획은 에어드랍 처럼 두 기기가 일정 거리에 도달하면 데이터가 송수신될 수 있는 상태를 만들려고 했습니다. 하지만 기본적으로는 MPC로 세션이 연결되었을때, NBI에서 생성된 각 기기의 discoveryToken을 MPC를 이용해 서로의 기기에게 전달하고, NBI는 그 기기간의 거리와 위치를 파악하는 기능을 하게됩니다.
    
    에어드랍처럼 동작하려면 앱을 진입한 시점부터 advertising, browsing, 기기 초대, 연결 과정이 계속해서 이루어져야 합니다. 시스템 자원이 낭비될 수 있다는 점에서 특정 이벤트(버튼) 시점부터 기기 간 연결을 유지할 수 있도록 진행하는 것으로 결정했습니다.
3. Network 작업
  
  Moya 처럼 네트워크 모듈을 만들고 있습니다.
  
  SupaBase를 설정하는 중 입니다.