Implementation

TL;DRMALMO의 “실시간” 요구는 대부분 서버 → 클라이언트 단방향 이벤트였고, 6주 개발 제약에서 SSE가 더 합리적인 선택이었다.전역 SSE 연결 1개로 “커플 이벤트 + AI 스트리밍”을 모두 받고, 화면/기능은 subscribe 기반 fan-out으로 분리했다.데모데이 전날 서버의 ‘1분 강제 재연결’ 정책이 스트리밍 중간에 끼어들어 chunk 유실이 발생했고, “전송 전 강제 재연결(타임 윈도우 리셋)”로 안정화해 데모데이(400명+)에서 중간 누락 제보 0건으로 운영했다.1) “실시간 채팅 = WebSocket”이 항상 정답은 아니었다실시간 채팅을 구현한다고 하면 많은 팀이 WebSocket부터 떠올린다. 나도 처음엔 그랬다.하지만 MALMO에서 만들려던 기능을 요구사항으로 다시 정리해보..

프로젝트에 주어진 시간은 단 6주.이런 초단기 프로젝트에서 가장 큰 리스크는 예측 불가능한 버그로 인한 개발 지연입니다. 이전 프로젝트에서는 사용자 인증 처리로 인해 QA 단계에서 불필요한 시간을 많이 소요했기에, 우선적으로 인증 처리 부분을 기획전 잡아가고자 했습니다. 어떻게 하면 인증 관련 이슈를 원천 차단하고,비즈니스 로직에만 집중할 수 있는 환경을 만들 수 있을까? 선제적 아키텍처 설계와 자동화저희는 문제가 터진 뒤에 해결하는 대신, 개발 시작 단계에서부터 견고한 인증 아키텍처를 설계했습니다. 핵심 전략은 '자동화'와 '보안'이었습니다. 1. 보안 원칙 수립: 토큰 분리React Native와 WebView를 함께 사용하는 하이브리드 환경이었기에, 보안을 최우선으로 고려했습니다.RefreshTok..

CMC 17기 활동의 목표는 "APP 출시"였습니다. 저희 팀은 React 기술 스택을 활용하여 유지보수성이 높은 앱을 효율적으로 개발하고자 했고, 그 첫 번째 관문은 바로 React Native와 WebView 간의 통신, 즉 '브릿지(Bridge)' 환경을 설정하는 것이었습니다. 🤔 왜 WebView를 선택했을까? React로 만든 웹 프로젝트가 이미 있다면, WebView는 가장 빠르게 앱을 만들 수 있는 매력적인 선택지입니다. WebView는 앱 내부에 웹 브라우저를 띄워 특정 URL의 웹 페이지를 그대로 보여주는 방식입니다. 덕분에 기존 웹 코드를 재사용하여 iOS와 Android 앱을 동시에 대응할 수 있습니다.하지만 여기서 한 가지 중요한 질문이 생깁니다. "앱의 네이티브 기능과 WebVi..