"미.만.추"의 두 판 사이의 차이

2020년 12월 20일 (일) 03:49 판

프로젝트 개요

기술개발 과제

국문 : 미팅으로 만나 사이..

영문 : Shall We Meet..

과제 팀명

미.만.추..

지도교수

김성환 교수님

개발기간

2020년 9월 ~ 2020년 12월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 2015920043 장근석 (팀장)

서울시립대학교 컴퓨터과학부 2015920015 김환석

서울시립대학교 컴퓨터과학부 2015920018 박민승

서론

개발 과제의 개요

개발 과제 요약

◇ 소셜 미팅 어 플 개발
◇ 기존 소개팅 어플 참고해서 미팅 상대를 구하는데 편리한 서비스 제공
◇ 사용자의 정보를 바탕으로 적절한 상대를 추천
◇ Spring을 사용해 서버 구축과 Android와 IOS를 사용해 제공

개발 과제의 배경

◇ 수 많은 소개팅 어플은 존재하는 반면 미팅 어플의 부재
◇ 미팅 중개자의 역할
◇ 일대일 소개팅에 대한 부담감
◇ 가격에 대한 부담감
◇ 수익 창출

개발 과제의 목표 및 내용

◇ 실질적인 앱Android, IOS) 출시
◇ 다양한 유저를 고려한 사용성이 높은 앱 개발
◇ 보안성과 앱 안전성 그리고 투명성이 높은 앱 개발
◇ 소셜 데이팅 어플 시장과는 차별화된 앱 개발

개발과제의 기대효과

기술적 기대효과

◇ 클라이언트 네이티브 언어를 사용해 각 운영체제에 맞는 호환성 
◇ 자바 스프링 부트 프레임워크를 사용함으로써 젠킨스과 같은 다양한 툴 호환성
◇ 양방향 기능 로직을 통한 일 방향적인 단순한 로직 보완 
◇ 필터 기능 도입으로 인해 원하는 방을 찾는 시간 감소

경제적, 사회적 기대 및 파급효과

◇ 코로나로 인해 생긴 우울증을 미팅으로 극복 효과 기대
◇ 쉽게 접근 가능한 미팅 어플로 인해 경제적으로 어려운 술집을 운영하는 소상공인 경제 회복 
◇ 저렴한 미팅 매칭 비용을 통한 타 어플의 비용을 끌어내리는 효과 기대 
◇ 언택트 시대로 인한 온라인 미팅 기능 도입으로 인한 온라인 미팅 시장 개척

기술개발 일정 및 추진체계

개발 일정

9월 : 개발 기획 및 설계 10월 : 프로토타입 개발 및 완성 11월 : 전체적인 기능 구현 12월 : 배포를 위한 테스트

구성원 및 추진체계

장근석

팀장, DB, Android,
프로젝트 총괄
Database 설계
Database 생성
Database 조작
Android UI 구현
Android 로직 구현

김환석

팀원, Server, IOS
기술 부분 총괄
AWS EC2 구축
AWS RDS 구축
AWS S3 구축
ngnix 구축
IOS UI 구현
IOS 로직 구현

박민승

팀원, Server, DB 
대외 부분 총괄
API 서버 구현
API 명세 작성
Database 설계
Database 생성
Database 조작

설계

설계사양

제품의 요구사항

타 소셜 미팅 어플 벤치마킹 사용자 정보 변경 미팅 방 개설 미팅 신청 가능한 방 리스트 제공 미팅 신청 기능 제공 사용자의 편리함 극대화할 수 있는 UI제작

요구사항 만족을 위한 기능 정의 및 기능별 정량목표

◇ 사용자와 친숙한 어플을 만들기 위한 UI 개발
◇ 사용자가 간편하게 사용할 수 있는 추천 기능 개발 
◇ 사용자가 빠르게 사용할 수 있도록 Client와 Server간 통신 속도 극대화(0.5~1초 사이)
◇ 리스트 제공 시 간편함을 위한 즐겨찾기 기능 개발
◇ 매칭 로직 구현 시 일 방향적인 신청을 방지하기 위한 양방향 결제 기능 로직 구현

개념설계안

◇ Client

네이티브한 언어인 SWIFT, KOTLIN으로 어플을 만들면서 각자의 운영체제에 알맞게 호환성이 높다. 미팅으로 만나 사이의 전반적인 기능들을 예쁜 UI를 통해 보여주는 역할을 하며 HTTP 통신을 통해 API서버와 데이터를 주고 받는다.

◇ Server 자바를 기반으로 한 스프링부트 프레임워크를 사용함으로서 객체지향적인 서버를 구현하였다. JPA와 Data Rest 등 스프링에서 기본으로 제공해주는 모듈을 사용함으로서 개발의 드는 시간을 절감할 수 있었다. 또한 MySQL과는 JDBC와 연결됨으로서 쉽게 연결할 수 있었다. DB의 데이터를 불러와 함수를 처리한 후 클라이언트와 HTTP 통신을 하는 역할을 한다.

◇ DBMS 해당 어플의 전반적인 사용자의 데이터, 게시물의 정보, 결제 정보 등 데이터베이스를 관리하는 역할을 한다. 가장 대중적인 MySQL을 사용함으로서 쉽게 데이터베이스를 관리하고 조작을 했다.

◇ Push Server

매칭이 성사되면 성사된 사용자들의 스마트폰에 알람을 주는 기능을 구현하는데 FCM(Firebase Coud Message)을 사용하였다. FCM은 Google이 제공해주는 푸시알림 API이며 안드로이드와 IOS 또한 쉽게 개발을 할 수 있는 환경을 제공해준다.

이론적 계산 및 시뮬레이션

내용

상세설계 내용

◇ Server Side

● JPA

JPA는 여러 ORM 전문가가 참여한 EJB 3.0 스펙 작업에서 기존 EJB ORM이던 Entity Bean을 JPA라고 바꾸고 JavaSE, JavaEE를 위한 영속성(persistence) 관리와 ORM을 위한 표준 기술이다. ORM(Object Relational Mapping)이란 RDB 테이블을 객체지향적으로 사용하기 위한 기술이다. RDB 테이블은 객체지향적 특징(상속, 다형성, 레퍼런스, 오브젝트 등)이 없고 자바와 같은 언어로 접근하기 쉽지 않다. 때문에 ORM을 사용해 오브젝트와 RDB 사이에 존재하는 개념과 접근을 객체지향적으로 다루기 위한 기술이다.

● REST API

REST는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 프로젝트를 개발하면서 RESTful한 API를 만들어 클라이언트와 데이터를 주고 받았는데, JSON형식으로 데이터를 주고받았기 때문에 데이터 변환에 큰 문제 없이 주고 받을 수 있었다. 또한 알맞은 기능에 따라 GET, POST, PATCH, DELETE를 선택해 사용하며 설계 기능 상 문제 없이 로직을 구현 할 수 있었다.

● AWS S3

S3는 단독 스토리지로도 사용할 수 있으며 EC2, EBS, Glacier와 같은 다른 AWS 서비스와도 함께 사용할 수 있어 클라우드 어플리케이션, 컨텐츠 배포, 백업 및 아카이빙, 재해 복구 및 빅데이터 분석을 포함한 다양한 사례에 알맞다.

● JENKINS

젠킨스는 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 툴이다. CI(Continuous Integration) 툴 이라고 표현한다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유영역에 있는 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해준다.

● SSL

사용자와 서버의 통신을 암호화하여 해커가 중간에 통신 데이터를 가로채더라도 알 수 없게 하는 통신 방법이며 쇼핑몰을 운영하거나 개인정보를 취급하는 웹사이트는 SSL 적용이 의무화 되어 있다. 미팅으로 만난 사이 어플 또한 사용자의 개인정보(이미지)를 취급하기 때문에 웹사이트에 SSL을 적용해주었고 KEY는 무료로 제공해주는 사이트인 letsencrypt에서 받았다.

◇ Client Side

● MVP 패턴 MVP 패턴이란 Model, View, Presenter의 첫 글자를 따서 이름이 지어졌다. MVP의 핵심 설계는 MVC와는 다르게 UI(View)와 비즈니스 로직(Model)을 분리하고, 서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써 서로의 영향(의존성)을 최소화하는 것에 있다. MVC 와는 다르게 코드가 매우 깔끔 해지며 MVP를 이용해서 이와 같이 Model과 View 간의 결합도를 낮추면, 새로운 기능 추가 및 변경을 해야 할 때 관련된 해당 부분만 코드 수정하면 되기 때문에 확장성이 좋아짐과 동시에 유닛 테스트 시 테스트 코드를 작성하기 편리해지기 때문에 더 쉽게 안전한 코딩이 가능해진다. 그리고 UI, Data 각각 파트를 나누기 때문에 해야 할 일이 명확해지고 그 결과로 쉽고 빠르게 코딩이 가능하다.

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

구글플레이스토어, 앱스토어에서 직접 구동 가능

포스터

향후계획

가. 어려웠던 내용들

● Server

◇ 푸시 알림 기능
한 번도 사용해보지 않았기 때문에 푸시 알림이 어떻게 동작하는지 이해하는데 어려웠다. 처음에는 클라이언트가 계속 API서버에 데이터베이스가 바뀔 때까지 push를 하는 방향인 줄 알았지만 알고 보니 각 기기마다 토큰이 배포되고 API서버에서 푸시 알림을 주어야 하는 부분의 데이터베이스가 변경될 때 미리 받아놓은 토큰에 푸시알림을 주는 방향이라는 것을 알 수 있었다. 이 기회에 FCM(Google FireBase Clous Message)에 대해서 알 수 있었고 사용해볼 수 있었다. 

◇ 양방향 결제 로직 구현
양방향 결제 로직을 구현하는데 많은 시나리오를 가져야만 했다. 결제가 안되었을 때 어떻게 진행해야 했고 결제가 안되었을 때 어떻게 진행 해야할지를 잘 설계해야 했었다. 처음에는 대표님과 의사소통이 불충분해 양바향 결제 로직을 구현하는데 있어서 많은 시행착오가 있었지만 점점 많은 소통을 하게 되니 하나하나 이해해가며 로직을 구현할 수 있었다.

◇ AWS S3 사용과 이미지 통신
사용자에게 프로필 사진과 미팅을 만들 때 3장의 사진을 저장할 저장소가 있어야 했고 그 사진들을 어떻게 클라이언트로부터 받아올지에 대한 어려움이 많았었다. 처음에는 클라이언트에서 서버에 사진을 업로드해서 그 경로만 주고 받으면 되는 줄 알았지만 그렇게 되면 클라이언트에 처리 해야할 작업량이 늘어나고 그렇게 된다면 처리 속도가 많이 느려질 것이란 것을 클라이언트와 소통을 하며 깨달을 수 있었다. 그래서 이미지를 서버에 전달한 방법을 찾아야만 했다. 하지만 한 번도 이미지를 갖고 HTTP통신을 해보지 않았기 때문에 처음에는 우왕좌왕했지만 스프링부트에 대해 아시는 분에게 물어보고 커뮤니티에도 물어보며  HTTP통신에서 Multipart 형식으로 데이터를 보내면 이미지를 전송할 수 있는 방법을 찾을 수 있었다.

● Android

◇ 안드로이드 버전 관리

다양한 제조사 빠른 업데이트로 인해 안드로이드는 파편화가 빈번하다는 단점이 있다. 이를 해결하기 위해 개발자의 버전관리는 필수적이다. 이번 개발에서는 gallery에서 사진을 가져와 서버에 전달하는 과정에서 버전관리에 대한 어려움을 겪었다. Android 7 이전에서는 바로 절대 경로를 통해 접근할 수 있었다. 하지만 7부터는 절대경로가 아닌 content uri를 리턴함으로 mediastore.images.imagecolumns.data를 통해 잘대경로를 얻을 수 있었다. 하지만 android 10부터 보안이 깅화됨에따라 위 함수가 deprecated됨으로써 임시파일을 만들어 복사한뒤 임시파일을 전달하는 방법을 사용하였다.

◇ Infinity Scrolling

서버에서는 다수의 파일을 가져오는 경우에 지연현싱이 발생함을 알 슈 있었다. 유저가 서버의 모든 데이터를 한번에 요구하는 경우가 전무하고 없고 스크린의 크기가 제한적이므로 1페이지에 10개씩 받아오기로 하였고 onScrollLinstener를 override함으로서 infinity scrolling을 구현하였다.

◇ Fragment transaction

Fragment transaction은 기본적으로 비동기로 작동합니다. 데이터가 변화가 이동하는 fragment 등에 영향을 줄 경우 commit()대신 commitNow()를 사용하여 동기적으로 작업할 것을 권장합니다. fragment를 add시에는 backstack에서 돌아오더라고 생명주기가 재시작되지 않습니다. Replace의 경우애도 onCreateView에서부터 재시작하므로 fragment의 생명주기에도 각별히 주의하여야 합니다.

● IOS

◇ 한글 자료(문서)의 부족

ios 의 한글 참고자료가 부족하여 많이 어려운 감이 있었지만 xcode의 친절한 error 메세지와 풍부한 영문 자료들로 극복 가능할 수 있었다.

◇ 늦은 Apple 개발자 계정 등록

대표님 개인 사정으로 apple 개발자 등록이 늦어져서 진행함에 있어서 힘든 점이 있었습니다. 이는 이후에 개발자 계정이 있다는 가정으로 상상하면서 로직은 구현함으로 추후에 계정이 등록 되었을때 빠른 속도로 마무리 구현 가능하였습니다.

● 클라이언트 공통

◇ 디자이너의 늦은 합류

대표님 개인사정으로 인해 디자이너의 부재의 상황속에서 작업을 진행하였습니다. 결국 저희 팀의 지인들로 연결하여 디자이너를 구하였고 이 과정에서 기존의 UI를 전면 수정할 수 밖에 없는 상황이 생겼습니다.

 나. 차후 구현할 내용

◇ CNN을 사용한 이미지 분석을 하여 추천 기능 활성화
미팅 방을 생성할 때 사용자에게 이미지 3장을 받는다. 그렇기 때문에 이 이미지들과 그 방 사용자의 후기를 데이터베이스와 S3에 저장하여 데이터를 어느 정도 모으면 CNN을 사용해 이미지를 분석한 후 그 이미지와 잘 맞는 분위기 술집 미팅 장소를 추천해주는 기능을 구현할 예정이다. 예를 들어 이미지가 세련된 분위기라면 신사동의 Bar와 같은 세련된 장소를 미리 추천해주는 방식이다. 이에 만약 광고 배너를 만들어 광고주들을 섭외할 수 있다면 더 좋은 효과를 볼 수 있을 것이며 사업성에도 좋을 것이라 생각한다.
  
◇ 스마트폰 GPS 위치 기반 미팅 추천 시스템

지금은 현재 사용자에게 미리 입력받은 선호 지역을 토대로 위치 추천 시스템을 구현해놨는데 추후에 스마트폰의 GPS 위치를 가져와 네이버 지도 API와 연동하여 스마트폰의 위치 기반으로 미팅을 추천해주며 미팅할 장소 주변의 미팅하기 괜찮은 장소를 추천해주는 기능을 구현할 예정입니다.

◇ 클라이언트 MVVM 패턴 적용
view를 observable로 wrpping, liveData와 데이터바인딩을 활용하여 presenter와 view의 의존성을 최소화한 mvvm패턴 적용예정

특허 출원 내용

내용

@@ 281번째 줄: / 281번째 줄: @@
 도서 구입비 : 75,000원
-[[파일:Mmc.png]]
+[[파일:Mmc.PNG|200픽셀|섬네일|왼쪽|설명]]
 ===향후계획===