지난 발표 피드백 및 기술 검증
지난 발표에서 제기된 연결 시간 제한 이슈와 네트워크 프레임워크 선택 이유에 대한 검증 결과입니다. 우리는 Multipeer Connectivity를 유지하기로 결정했습니다.
Q. 연결 시간 10분 제한 이슈?
✓ 해결됨: Multipeer Connectivity 자체에는 시간 제한이 없습니다. 실제로 팀원이 50분 이상 데이터 전송을 테스트하여 연결이 유지됨을 확인했습니다.
Q. Network.framework 비교?
Network.framework는 저수준 제어로 고성능을 낼 수 있지만, 현재 우리 앱(정지 화면 촬영)에는 Multipeer가 충분한 성능을 제공합니다.
- 프로토타입이 이미 완성됨 (빠른 개발 속도)
- 추후 한계 발생 시 마이그레이션 고려
기술 스택 비교 분석
차트는 각 프레임워크의 상대적 강점을 나타냅니다.
프로젝트 진행 과정
인터미션 기간 동안 진행된 프로토타입 병합 과정과 1차 주요 기능 개발 현황입니다. 팀원 간의 이해도 동기화를 위해 짝 프로그래밍을 적극 활용했습니다.
프로토타입 병합
Completed
기존에 각자 개발한 코드를 재활용하되, 짝 프로그래밍을 통해 코드 이해도를 맞추었습니다.
- 대현님의 코드를 베이스로 통합 진행
핵심 기능 개발 (1차 목표)
In Progress단일 뷰에서 다음 기능들이 완벽하게 동작하는 것을 목표로 함:
고도화 예정
UI/UX 폴리싱 및 성능 최적화, 반응형 레이아웃 적용
아키텍처 및 디자인 패턴
네트워크 상태 변화 등 복잡한 상태 관리를 위해 MVI (Model-View-Intent) 패턴을 도입했습니다. 아래 다이어그램의 각 요소를 클릭하여 상세 내용을 확인하세요.
MVI 패턴 도입 배경
네트워크 끊김 등 예측 불가능한 상황에서 단방향 구조가 주는 신뢰성이 필요했습니다.
Clean Architecture 적용 여부?
서버나 복잡한 데이터 레이어가 없어 엄격한 계층 분리는 생략했습니다. 의존성 방향은 고려하되, 실용적인 구조를 택했습니다.
👈 다이어그램의 원을 클릭해보세요.
주요 과제: 반응형 UI (Responsive Design)
다양한 기기(iPad Pro, iPad Mini, Mac 등)의 화면 크기에 대응하여 촬영 화면을 왜곡 없이 보여주는 것이 가장 큰 과제입니다. 현재 시간이 많이 소요되고 있어 논의가 필요한 부분입니다.
문제점
- 기기마다 화면 비율(Aspect Ratio)이 다름
- 카메라 프리뷰 레이어의 프레임 계산 복잡도
- 다양한 크기에 대응하는 뷰 코드 작성 시간 소요
대응 전략
오토 레이아웃 제약조건을 동적으로 수정하거나, SwiftUI의 GeometryReader 등을 활용하여 적응형 레이아웃을 연구 중입니다.
화면 비율 시뮬레이션
슬라이더를 움직여 다양한 화면 크기에서의 레이아웃 변화 필요성을 확인하세요.