DateP 프로젝트: 2025년 3월 19일 - Firebase Functions 배포 완료 및 Home Screen 로딩 스피너 추가

 

제목: DateP 프로젝트: 2025년 3월 19일

- Firebase Functions 배포 완료 및 Home Screen 로딩 스피너 추가

 

DateP Project: 오늘 한 일

1. Firebase Functions 배포 완료 및 테스트
   • 수정 및 추가:
     • free, basic, premium 플랜에 대한 Firebase Functions 배포 완료.
     • 각 플랜별 테스트 성공적으로 마무리:
       • free
       • basic
       • premium
   • 성과:
     • basic과 premium은 속도 차이가 거의 없음(빠른 응답 확인).
     • free 플랜은 Perplexity API 사용으로 인해 속도가 상대적으로 느림(10~15초 소요).
   • 문제:
     • free 플랜의 속도 차이가 눈에 띔. 목표는 5초 내 응답.
2. Home Screen UI 개선: Search Button에 로딩 스피너 추가
   • 수정 및 추가:
     • index.tsx의 Home Screen에서 "추천받기" 버튼(fetchPlacesAndShowModal) 옆에 로딩 스피너 추가.
     • loading 상태일 때 Gluestack UI의 Spinner가 버튼 내부에 표시되도록 구현.
     • 코드 예시:
       <Button

         onPress={fetchPlacesAndShowModal}

         disabled={loading}

         style={[styles.button, { height: 55 }]}

       >

         <View style={{ flexDirection: "row", alignItems: "center" }}>

           <ButtonText style={styles.buttonText}>

             {loading ? translations[language].searching : translations[language].fetchButton}

           </ButtonText>

           {loading && (

             <Spinner size="small" color="#007AFF" style={{ marginLeft: 8 }} />

           )}

         </View>

       </Button>
   • 효과:
     • API 요청 중 사용자에게 로딩 상태를 시각적으로 피드백.
     • 특히 free 플랜의 느린 응답 시간 동안 체감 대기 시간 감소.

해결해야 할 문제

1. Perplexity API 속도 문제 (Free Plan):
   • 현재: 10~15초 소요.
   • 목표: 5초 이내 응답.
   • 방안:
     • 프롬프트 간소화: 불필요한 필드(rating, price) 제거 고려.
     • 캐싱 도입: 동일 요청에 대해 Firebase Firestore나 Memory Cache 활용.
     • 대체 API 검토: OpenAI GPT(1~3초) 또는 xAI Grok 사용 가능성 탐색.
2. Home Screen 최적화:
   • basic과 premium은 속도가 빠르나, free 플랜의 느린 속도와 UI 간극을 줄일 필요 있음.
   • 방안: 로딩 스피너 외에 진행률 표시(Progress Bar) 추가.
3.  Google Places API의 Random Modifier 문제
   • 문제:
     • 현재 textQuery를 장소 + randomModifier로 설정해 중복 결과를 피하려 함.
     • 그러나 "좋은", "인기 있는", "숨겨진", "특별한", "분위기 좋은" 등의 수식어에 따라 반환 결과 개수가 1개에서 20개까지 편차가 큼.
     • 목표: 최소 10개 이상의 장소 반환.
   • 분석:
     • Google Places API는 textQuery의 구체성에 따라 결과 수가 크게 달라질 수 있음.
     • Random Modifier가 너무 구체적이거나 모호하면 검색 범위가 좁아지거나 넓어져 편차 발생.
   • 해결 방안:
     1. Random Modifier 최적화
        • 실험을 통해 최소 10개 이상의 결과를 일관되게 반환하는 수식어 세트 도출.
          • 예: "추천", "인기", "탐방" 같은 중립적이면서 범용적인 단어 사용.
          • 너무 구체적인 단어("숨겨진", "특별한")는 결과 수가 적을 가능성 높음.
        • 언어별로 수식어 풀(Pool)을 만들고, 결과가 10개 미만일 경우 다른 수식어로 재시도하는 로직 추가.
          • 예: 장소 + "인기" → 결과 5개 → 장소 + "추천"으로 재시도.
     2. API 요청 보강
        • textQuery 외에 type(예: restaurant, cafe)이나 radius를 활용해 결과 범위를 확장.
        • 예: textQuery: "카페 + 추천", type: "cafe", radius: 5000.
     3. 결과 필터링 및 보정
        • API 호출 후 결과가 10개 미만이면, Random Modifier를 변경하거나 기본 키워드(장소만)로 재요청 후 중복 제거.
        • 예: "카페 + 분위기 좋은" → 3개 반환 → "카페"로 재요청 → 총 10개 이상 확보.
     4. 실험 설계
        • 각 Random Modifier별 반환 결과 수를 기록하며 테스트.
          • "좋은" → 평균 8개
          • "인기 있는" → 평균 12개
          • "추천" → 평균 15개
        • 최소 10개를 보장하는 상위 수식어 3~5개 선정 후 로테이션 적용.

앞으로의 방향성

• 앱 아이콘 및 Splash Screen:
  • 앱 아이콘 디자인 완료 후 설정.
  • Splash Screen으로 초기 로딩 UX 개선.
• In-App Purchase 구현:
  • react-native-iap로 결제 시스템 추가 예정.
• EAS 빌드:
  • 현재 API 문제 해결 후 개발용 EAS 빌드 진행.
  • 최종 배포 전 테스트 빌드 계획.
• 기타:
  • AI 생성 콘텐츠 신고 기능 (Android 전용) 추가 검토.

요약

• 오늘 작업: Firebase Functions 배포 완료(free, basic, premium), Home Screen에 로딩 스피너 추가.
• 문제: free 플랜의 Perplexity API 속도 저하.
• 다음 단계: API 속도 최적화, 인앱 결제 구현, EAS 빌드 및 배포 준비