대부분 정확한 현실가능성을 파악하지 않은 뇌피셜이며 세부 구현이나 현실성에 대해서는 피드백을 해주시면 괜찮을 것 같습니다, 빨간색 글씨로 제약사항이나 주석을 달아주시면 제가 반영해서 기획을 새롭게 해보겠습니다.
개인적으로는 량이 너무 방대한 것 같아서 우선순위 따라서 하되, 다음우선순위는 다음 우선순위 구현시에 그때그때 논의하는게 좋을 것 같습니다 (DB 관련 제외)
사용자 주요타겟 - MZ 세대
주요 목표 - 사용자가 원하는 공간을 연결하는 것
핵심 기능 - 1. 일반공간 노출 2. 추천공간 노출 3. 길찾기 4. 공간리뷰
1. 일반공간 노출_빅데이터가 아닌 정보노출 & 핵심정보 노출 & 물리적으로 현실적인 공간 정보 & 쉬운 정보의 검색
- 일반적인 상황에서 어플리케이션으로 주변을 걸어다닐 경우 건물의 정보를 노출시켜줌 - 가장 기본적인 기능
- 기본적인 UI 구성이 핵심적
- MapGo 기능명세에 목표 UI자체는 상세 기술되어 있음.
- 어떤 정보를 노출시킬 것인가(2~3장 동시 노출) - "핵심 정보" 노출이 주요한 목표
- (잠정적 후보군)
-
- 핵심사진 5장(필수), url연동시켜서 사진 선택시 해당 url연결
-
- 아래 사진 1)과 같이 핵심 태그들을 기반으로 공간의 특성들을 배열하기
-
- SNS(SNS없는 상황, SNS기능 개발 X 상황 고려 필요)
-
- 기타 줄글 포함한 자료(글을 읽기에 불편하지 않다면 적절할 수 있다고 생각함 다만 어떠한 줄글이 핵심적일 수 있는지 판단할 수 있을지는 의문, 논의필요)
- 얼마나 정보를 노출시킬 것인가 — 목표는 정보의 전달력이 중심, 일단 만들어보고 정보전달이 어느 정도 화면크기로 나갈때 적절한지 논의가 필요, 일단 2장으로 개발 중
- AR로 보여준다는 것은 어떤 것인가? —> UI 형태에 따라 논의가 필요, 사람들이 기대하는 AR이 아니기 때문에 AR을 내세우는만큼 사용자의 기대에 충족시킬 수 있는가가 주요 문제, 일단 UI개발을 시도해보고 구현 가능한 바운더리 내에서 생각해보는 것이 좋을 듯
- 유사성 낮은 알고리즘 이미지 유사성 낮게 이미지 긁어오기
- 어떤 정보가 핵심적인가?
- 후보군
-
- 인스타좋아요-보안&개인정보&메일문의중
-
- 구글 이미지-알아보는중(현실적인 희망&상업용활용가능한 이미지 거르기 가능)
-
- 네이버API-초기 발표에서 대부분 네이버에서 문제점을 찾은거라서 네이버를 쓰면 똑같은 문제를 발생시킬것이라 생각함, 하지만 1,2가 활용불가능하다면 어쩔 수 없을 듯
- 몇개의 공간 정보를 동시에 보여줄 것이며, 그 몇개는 어떻게 고를 것인가?
- 잠정적으로 3개의 공간정보를 동시에 보여주며, 겹쳐서 놓되, 손으로 슬라이드 시 다음 공간의 정보를 보여주는 형태
- 해당 공간의 정보임을 알 수 있는 연결이 필요(신지홍 씨가 말씀해주신 링크(?)가 좋을 듯함)
- 공간을 고르는 방법 - 1. 가장 가까운 위치 3개, 2. 화면에 담기는 건물중에서 가까운 3개(실시간 데이터 로드 시 굉장히 오래 걸릴 듯함) —> 다만 어느 정도 멀면 보여주지 않거나, 특정 공간안에 있으면 일반노출 기능은 자동으로 off되는 기능이 필요할 듯 함
- 정보를 로드하는 방식(실시간 검색시간vs서버 용량)
- 1.1 실시간 데이터로드 : 주소정보 획득 —> 네이버 주소 검색 —> 해당 건물의 핵심정보 API통해 획득(ex/상호명) —> 상호명 인스타 검색 —> 좋아요 수대로 정렬 및 5개 대표사진 선택, 가장 좋은 방식이긴 하나 개인정보 때문에.. 일단 불가능하다는 쪽으로 생각중
- 1.2 실시간 데이터로드(1.1인스타 검색→구글 검색) —> 대표성 띄는 선택을 기준으로 사진선택, 동시에 3개 공간에 대해서 상호작용하기에 시간이 너무 오래 걸릴 것 같은 문제점이 존재
-
- 서버에 데이터 저장 : 서버에 "주소-주요 정보" 저장 —> 휴대폰으로 주소정보 in 시 주요정보 out 시키는 방식, DB구축이 너무 힘들듯하고 양도 많을 듯함, 해커톤의 경우 지역의 제한이 필요함, 또한 현실구현은 하지않겠지만 정보의 refresh를 위한 방안을 고민해봐야할 듯함
- 공간의 태그 활용한 공간 카테고리화_즉석카테고리(부차적)
- 가능하다면, 공간마다 태그가 있을 시 태그 활용해서 사용자로 하여금 선택적인 정보를 보도록 도와야함
- 다만, 기능 구현에 어려운 점이 있는 부분이 실시간 데이터로드를 할 시 태그 정보가 없는 경우도 있을거고 매번 확인해야해서 검색시간이 기하급수적일 수 있을 것이라 생각
- 서버에 태그 정보를 남기는 것이면 고려해볼만한 사항인 듯
- 태그가 있다면 ML과도 상호작용할 수 있을 듯 함
2. 추천 공간 노출(ML)_빅데이터가 아닌 정보의 노출 & 사용자가 좋아할만한 공간을 추천
ML부분에 시트에 기술된 부분 1차 고려 후 수정
-
어떤 공간을 추천할 것인가?
- 사용자가 좋아할만한 공간을 추천하는 것이 목표_그런 점에서 ML학습의 목적 및 타겟은 그 사람이 공간추천을 받았을 때 만족하는 것인지가 타겟값, 하지만 만족하는 지에 대해서 일일이 라벨링이 현실적으로 불가능하기 때문에, 대안이 필요. 타겟값 = 만족 을 연결시키는 것이 중요
- 타겟값을 만족에 염두해두고 ML 개발하는 것이 불가능할 시 그냥 다양한 공간을 유사도에 기반으로 "이러한 공간이 니가 가고 싶어하는 공간과 유사하다~"라는 정도로 보여주는 것이 좋을 것 같음 —> 현실적으로 어려움이 존재, 타겟 값을 설정하는 것은 추후 과제로 남겨야하는 부분으로 보임
-
언제 공간을 추천할 것인가?
- 상시 공간을 추천하면 불편할 듯 함
- 일반공간만 노출 & 일반공간,추천공간 동시노출 & 추천공간만 노출 구현 필요
- 카테고리별로 입력데이터가 구분되어야할 것 같음(이 부분은 충분한 설명 및 논의가 필요할 듯함 구현적으로는 상당한 량일 것 같아서 고려 자체를 안하는 것도 좋아보임)
- ex/ 음식점을 간 사용자가 존재함—> 음식점을 간 정보가 축적되어 다음에 추천공간으로 음식점 추천이 가능 —> 다음에 전시장을 가보고 싶음 —> 전시장 관련 입력데이터가 없기때문에 음식점 추천만 제시 —> 추천 정보가 오히려 방해가 됨
- 이런 점 때문에 다양한 경우에는 다양한 입력값이 필요한데 현실적으로 불가능함 & 애초에 희귀한 입력값은 현실에도 그러한 공간이 희박해서 사실상 우리의 방향과 반대인 빅데이터가 적절한 어플이되는 것이기에 우리 어플의 타겟으로 잡지 말아야하나 고민이 됨.
-
ML 종류의 선택
- 그냥 유사도 알고리즘(KNN etc..) - 사용자 정보가 전무할 경우 사용할 것으로 예상 → 그냥 유사한 공간을 추천해주는 것이기 때문에 데이터가 많아서 추천해주는 것은 아님, 그런점에서 어느 정도 목표와 부합함. 다만 어떤 공간이 추천될지는 솔직히 아직은 랜덤이기 때문에 사용자 만족을 염두해 두고 사용하는 것은 아닌 것으로 판단됨. 공간이 (인풋값 유형에 따라)유사한거지 만족은 아님
- 개인 정보 추천 알고리즘 - input으로 개인정보 또한 받음(딥러닝 추천알고리즘 파악필요), 나온 의견 중 "한 사용자가 여러 곳을 갈 경우 그러한 공간을 좋아한다"의견이 나오긴 했으나, 어떤 사용자가 어디를 갔을지 정리하는 것이 어려울 수 있고, 특정 물리적인 공간을 제약시에 해당 공간을 벗어나는 공간에 대해서 학습시 문제가 될 수 있고, 공간을 좋아해서 리뷰를 한건지는 불확실 할 수 있음.