심사위원 1

• MBTI, 나이 등 입력 정보가 AI 추천 결과에 미치는 영향력을 정량화한 기준이 있다면 설명해 주세요.

• KoBERT 파인튜닝 시 하이퍼파라미터 최적화 방법과 7,900개 라벨링 데이터의 품질 검증 절차는?

• Naver 지도/Kakao Mobility와 연계 시 개인정보 처리(예: 이동 경로 수집)에 대한 법적 대응전략을 검토하셨나요? ⇒ 질문의 의도가 궁금

  • 현재 저희가 사용하는 Kakao api는 단순한 장소 데이터 수집을 위하여 사용하고 있고, 따라서 법적 내용 부분은 해당되지 않는 걸로 알고 있습니다.
  • 간략히

• 기존 서울시 관광 앱(예: Visit Seoul)과 비교해 본 시스템의 차별화 포인트는 무엇인가요?

  서비스 개발에 앞서 차별점을 명확히 하기 위해 실제로 Visit Seoul 앱을 사용해본 결과, 이 앱의 핵심 기능은 크게 두 가지였습니다.

  첫째, 사용자의 현위치 기반으로 음식점, 쇼핑몰, 관광지 등의 정보를 지도상 마커로 제공하거나 직접 검색할 수 있는 기능이며,

  둘째, 테마별 관광 코스를 추천하는 기능입니다.

  그러나 이러한 기능은 기존의 많은 관광 앱에서도 흔히 제공되고 있어, 특별한 차별점은 찾기 어려웠습니다.

  이에 저희는 차별화를 위해 다음과 같은 요소를 도입했습니다.

  우선, 서울 내 주요 120개 장소에 대해 실시간 혼잡도 정보 및 알림 기능을 제공하여, 사용자들이 보다 쾌적한 관광 일정을 계획할 수 있도록 했습니다.

  또한, 관광 코스 추천 시 사용자의 개인 성향과 요청 사항을 반영한 맞춤형 추천 시스템을 적용하여, 보다 개인화된 경험을 제공한 것이 가장 큰 차별점입니다.

심사위원 2

① 기획 대비 구현의 정합성

1. 수행계획서에서 제시한 기술 스택(Kafka, Spark, LangChain, Elasticsearch 등)은 모두 실제로 구현에 반영되었나요?
   1. 수행계획서에 적힌 내용은
   2. 이번 프로젝트에서는 Spark를 직접 사용하지는 않았습니다. 대신, Streamsets를 활용해 데이터 수집 및 전처리 파이프라인을 구성했고, 목적에 따라 데이터를 분기 처리함으로써 Spark 없이도 실시간성과 확장성을 확보할 수 있었습니다.
2. 혼잡도 예측, 사용자 추천 기능 등 AI 기반 기능은 실제 어떤 수준으로 구현되었으며, 테스트 결과는 어떻게 확인하였나요?
   1. 혼잡도 예측은 서울시 공공 api를 통해 받고있습니다.

② 기능 구현 및 완성도

1. 실시간 데이터 수집·시각화 기능은 어떤 방식으로 동작하며, 5분 단위 수집이라는 주기는 실제 사용자 이용에 적절한가요?

   • 저희 시스템은 서울시에서 제공하는 도시 데이터를 활용하며, 백엔드에서 수집된 데이터를 SSE(Server-Sent Events) 방식으로 프론트엔드에 전달하여 실시간에 가까운 시각화를 구현하고 있습니다.

   • 데이터 수집 주기는 5분 단위인데, 이는 서울시 오픈 API에서 제공하는 가장 짧은 업데이트 주기를 따르고 있습니다.

     그보다 더 짧은 간격으로 데이터를 요청하더라도 실질적인 데이터 변화는 없기 때문에 의미가 없으며, 오히려 시스템 부하만 증가시킬 수 있습니다.

     또한 관광지 혼잡도는 짧은 시간 내 급변하지 않기 때문에, 사용자 입장에서도 5분 단위 갱신이면 충분히 실시간에 가까운 체감 경험을 제공할 수 있다고 판단했습니다.

2. 감정 분석 모델의 F1-score가 0.86로 제시되었는데, 이를 평가하기 위한 테스트셋 구성 방식과 기준은 무엇인가요?

   1. 전체 7,900개 라벨링 데이터 중 20%를 무작위로 분할하여 테스트셋으로 구성하였습니다. 필요시 추가 설명{ 라벨 분포(긍정/중립/부정)가 실제 리뷰 데이터와 유사하도록 stratified sampling을 적용하였습니다.}

3. LangChain 기반 LLM 추천 기능의 출력 결과가 실제 사용자 요구를 얼마나 반영했는지 검증한 사례가 있나요?

   1. 처음에는 사용자 요구사항을 정확히 반영하지 않는 문제가 발생했었습니다. 조건에 요청사항 반드시 반영이라는 프롬프트를 추가했더니 “하루에 카페 4번”과 같은 일반적이지 않은 사용자의 요청사항들도 반드시 반영하는것을 확인할수있었습니다.

③ 시스템 통합 및 사용자 인터페이스

1. 사용자 대시보드와 관리자 대시보드가 분리 구현되었는데, 각 역할에 따라 제공되는 정보의 차별화 전략은 무엇인가요?

   a: 사용자 대시보드는 개인 맞춤형 서비스 제공을 위해 선택한 특정 지역 중심의 관광정보를 제공하고, 관리자 대시보드는 효율적인 운영관리를 위해 전체 관광특구의 통합 현황과 분석 데이터를 제공합니다. 또한 사용자 대시보드에서는 직관적인 카드 기반 UI를 제공하여 관광 편의 위주로, 관리자 대시보드에서는 데이터 중심의 모니터링 기능을 제공하여 각각의 목적에 맞을 수 있도록 제작했습니다.

   사용자 대시보드는 개인 맞춤형 서비스 제공을 위해 선택한 지역의 관광 정보를 제공하고, 관리자 대시보드에서는 원활한 운영 관리 및 통합관제를 위해 전체 관광특구의 통합현황 및 통합 데이터 분석 결과를 제공하고 있습니다.

2. 시스템 모니터링(Grafana, Zipkin 등)은 어떤 메트릭을 기준으로 운영되었으며, 실제 장애 대응이 가능한 수준인가요?

   1. 그라파나에서는 노드의 비정상적인 리소스 사용을 감지할 수 있으며, 로그스태시로 중앙화된 로그를 집킨에서 트레이싱하여 어떤 서비스에서 에러가 발생했는지 확인하여 장애를 대응할 수 있었습니다.
   2. 최근에 발생했던 ES 용량 문제가 있었습니다. 사이트에서 DB정보를 가져올 수 없었고, ELK에서 에러에 대해서 체크를 했고, TraceID를 뽑아 Zipkin에서 확인을 하여 어디 부분에서 발생했는지 확인을 하였습니다. 실제 백엔드 서버에서 ES에 연결하는 과정에서 뜬 것을 확인했고, PVC 용량을 늘리는 것으로 에러를 해결하였습니다.