"미.만.추"의 두 판 사이의 차이
(→설계) |
|||
(같은 사용자의 중간 판 10개는 보이지 않습니다) | |||
70번째 줄: | 70번째 줄: | ||
*기술 로드맵 | *기술 로드맵 | ||
얼굴인식 시스템, 사진분석 시스템, 위치정보 시스템등을 2021년 상반기, 하반기 그리고 2022년까지 기술 개발 계획에 있음 | 얼굴인식 시스템, 사진분석 시스템, 위치정보 시스템등을 2021년 상반기, 하반기 그리고 2022년까지 기술 개발 계획에 있음 | ||
− | + | [[파일:Mmc5.JPG]] | |
====시장상황에 대한 분석==== | ====시장상황에 대한 분석==== | ||
170번째 줄: | 170번째 줄: | ||
팀장, DB, Android, | 팀장, DB, Android, | ||
프로젝트 총괄 | 프로젝트 총괄 | ||
− | + | Database 설계 | |
− | + | Database 생성 | |
− | + | Database 조작 | |
− | + | Android UI 구현 | |
− | + | Android 로직 구현 | |
180번째 줄: | 180번째 줄: | ||
팀원, Server, IOS | 팀원, Server, IOS | ||
기술 부분 총괄 | 기술 부분 총괄 | ||
− | + | AWS EC2 구축 | |
− | + | AWS RDS 구축 | |
− | + | AWS S3 구축 | |
− | + | ngnix 구축 | |
− | + | IOS UI 구현 | |
− | + | IOS 로직 구현 | |
191번째 줄: | 191번째 줄: | ||
팀원, Server, DB | 팀원, Server, DB | ||
대외 부분 총괄 | 대외 부분 총괄 | ||
− | + | API 서버 구현 | |
− | + | API 명세 작성 | |
− | + | Database 설계 | |
− | + | Database 생성 | |
− | + | Database 조작 | |
==설계== | ==설계== | ||
===설계사양=== | ===설계사양=== | ||
+ | [[파일:Mmc4.JPG]] | ||
====제품의 요구사항==== | ====제품의 요구사항==== | ||
− | + | [[파일:Mmc3.JPG]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
요구사항 만족을 위한 기능 정의 및 기능별 정량목표 | 요구사항 만족을 위한 기능 정의 및 기능별 정량목표 | ||
238번째 줄: | 233번째 줄: | ||
● JPA | ● JPA | ||
− | + | JPA는 여러 ORM 전문가가 참여한 EJB 3.0 스펙 작업에서 기존 EJB ORM이던 Entity Bean을 JPA라고 바꾸고 JavaSE, JavaEE를 위한 영속성(persistence) 관리와 ORM을 위한 표준 기술이다. | |
− | + | ORM(Object Relational Mapping)이란 RDB 테이블을 객체지향적으로 사용하기 위한 기술이다. RDB 테이블은 객체지향적 특징(상속, 다형성, 레퍼런스, 오브젝트 등)이 없고 자바와 같은 언어로 접근하기 쉽지 않다. 때문에 ORM을 사용해 오브젝트와 RDB 사이에 존재하는 개념과 접근을 객체지향적으로 다루기 위한 기술이다. | |
272번째 줄: | 267번째 줄: | ||
===완료 작품의 소개=== | ===완료 작품의 소개=== | ||
====프로토타입 사진 혹은 작동 장면==== | ====프로토타입 사진 혹은 작동 장면==== | ||
− | + | [[파일:Mmc2.JPG]] | |
+ | 구글플레이스토어, 앱스토어에서 직접 구동 가능 | ||
====포스터==== | ====포스터==== | ||
− | + | [[파일:poster.jpg]] | |
===관련사업비 내역서=== | ===관련사업비 내역서=== | ||
− | + | 구글 개발자 계정 : 27,000원 | |
+ | 앱 스토어 개발자 계정 : 110.000원 | ||
+ | 도서 구입비 : 75,000원 | ||
− | + | [[파일:mmc.jpg]] | |
− | |||
===향후계획=== | ===향후계획=== | ||
− | 내용 | + | 가. 어려웠던 내용들 |
+ | |||
+ | ● 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패턴 적용예정 | ||
===특허 출원 내용=== | ===특허 출원 내용=== | ||
내용 | 내용 |
2020년 12월 20일 (일) 03:56 기준 최신판
프로젝트 개요
기술개발 과제
국문 : 미팅으로 만나 사이..
영문 : Shall We Meet..
과제 팀명
미.만.추..
지도교수
김성환 교수님
개발기간
2020년 9월 ~ 2020년 12월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 2015920043 장근석 (팀장)
서울시립대학교 컴퓨터과학부 2015920015 김환석
서울시립대학교 컴퓨터과학부 2015920018 박민승
서론
개발 과제의 개요
개발 과제 요약
◇ 소셜 미팅 어 플 개발 ◇ 기존 소개팅 어플 참고해서 미팅 상대를 구하는데 편리한 서비스 제공 ◇ 사용자의 정보를 바탕으로 적절한 상대를 추천 ◇ Spring을 사용해 서버 구축과 Android와 IOS를 사용해 제공
개발 과제의 배경
◇ 수 많은 소개팅 어플은 존재하는 반면 미팅 어플의 부재 ◇ 미팅 중개자의 역할 ◇ 일대일 소개팅에 대한 부담감 ◇ 가격에 대한 부담감 ◇ 수익 창출
개발 과제의 목표 및 내용
◇ 실질적인 앱Android, IOS) 출시 ◇ 다양한 유저를 고려한 사용성이 높은 앱 개발 ◇ 보안성과 앱 안전성 그리고 투명성이 높은 앱 개발 ◇ 소셜 데이팅 어플 시장과는 차별화된 앱 개발
관련 기술의 현황
관련 기술의 현황 및 분석(State of art)
- 전 세계적인 기술현황
◇ AI를 통한 얼굴인식 기술, 현재는 국내 앱의 경우에는 사람이 직접 검수하는 편이 아직은 지배적 ◇ 축적도니 사진과 정보를 분석해 유저들의 매칭 시스템 개선 딥러닝을 통한 사진과 정보를 분석해 유저들의 매칭 시스템을 개선한다. CNN을 사용해 사진에 나와있는 장소, 분위기, 사람의 성격등을 분석할 수 있도록 구현을 하며 사진에 대한 정보는 미팅에 대한 후기를 적어놓을 수 있는 커뮤니티를 만들어 사진과 후기를 저장하며 데이터를 수집한다.
◇ 위치정보(GPS) 시스템을 이용한 지리 기반 매칭 스마트폰에서 제공해주는 위치정보 시스템을 사용해 지도 API와 비교하며 사용자에게 미리 받은 정보를 이용해 KM를 정해 지리 기반 매칭 기능 구현
◇ AWS rekognition
AWS에서 말하는 Rekognition은 바로 수백만개의 딥러닝 이미지를 가지고 인식하여 시각 분석 데이터를 만드는 서비스입니다.
Rekognition은 이미 보유 중인 이미지를 가지고 분석 자료를 만드는 서비스입니다. 특히 수백만개의 이미지를 처리하기 떄문에 이미지 기반 빅데이터 처리를 위한 서비스로 볼 수 있으며, Amazon에서 제공하는 딥러닝 서비스 중에서는 가장 강력한 기능을 제공하는 서비스 중 하나입니다.
대표적으로 제공하는 이미지 분석기술은 다음 두가지가 있습니다. 1) 사람 얼굴 인식 2) 수많은 컨텐츠 중 부적절한 컨텐츠 검출
그 외에도 Rekognition에서 제공하는 이미지 분석 기술은 다양하니 참고하시면 되겠습니다.
Rekognition에서는 딥러닝 서비스를 위한 SDK를 제공하고 있으며, 대부분의 리전에서 사용이 가능합니다. 현재(2019년 10월)는 총 12개 리전에서 Rekognition을 이용할 수 있으며, 서울 리전 역시 포함되어 있습니다.
- 특허조사 및 특허 전략 분석
- 기술 로드맵
얼굴인식 시스템, 사진분석 시스템, 위치정보 시스템등을 2021년 상반기, 하반기 그리고 2022년까지 기술 개발 계획에 있음
시장상황에 대한 분석
- 경쟁제품 조사 비교
Tinder
상대의 사진과 400자 미만의 간단한 소개를 읽고 마음에 들면 오른쪽으로 스와이프해 좋아요를, 그렇지 않으면 왼쪽으로 스와이프해 거절을 하는 직관적인 방식.위로 올리면 Super Like를 보내 상대방이 다음 번 앱을 열었을 때 자신이 확실하게 노출될 수 있게 할 수 있는 부가 기능도 존재.
차별화
재미있는 스와이핑 매칭 -> 호감을 표시할 수 있는 방법이 쉽다.
단점
한국에서는 잘 통하지 않음 (지인 방지 기능 X, 거리 기능 기반의 매칭 시스템) 입력 조건이 매우 간단 (본인의 사진이 아니어도 통과)
아만다
어플에 인증된 우수회원만 활동할 수 있는 프리미엄 데이팅 앱가입 시 매력을 입증 할 수 있는 여러가지 요소를 입력해 인증을 받아 아만다의 추천을 통해 이성을 만남. 아만다는 ‘2016 올해를 빛낸 꿀잼앱’에 이름을 올렸다. [출처: https://www.ebn.co.kr/news/view/864845]
차별화
가입 심사를 통과하기 어려움 -> 직원들이 하나에서 열까지 다 검사함 + 유저들에게 검사를 받아야한다. 비슷한 점수의 사람들과 만날 수 있는 매칭 시스템
단점
가입 심사를 통과하기 어려움 비용이 만만치 않다.
스카이피플
최초의 학교와 직장 인증을 통한 스펙 기준의 데이팅 앱‘서울대생'이 만든 인증을 통한 안전한 소개팅 이라는 홍보문구로 알 수 있든 조건이 있는 만남을 추구한다.
차별화
아무나 가입되지 않는 데이팅 서비스를 제공 100% 학교 직장 인증을 통한 신뢰성 제공
정오의 데이트
12시 땡 되면 이성 2명을 소개해주고, 저녁 8~9시 정도되면 또 2명을 소개해주는 방식. 가능한 사용자가 설정한 지역쪽에 사는 이성을 소개소개기능 외 이상형 토너먼트, 3문답 퀴즈, 혼자 고민상담, 간단한 게임들이 있음.
차별화
비교적 타 플랫폼보다 가입 심사에 통과하기 쉽다. 외국인 카테고리가 있어, 외국인 친구를 사귀기 쉽다.
단점
모든 기능을 사용하기 위해서는 비용을 지불해야 한다.
글램
하루에 두명까지 무료로 주변 이성 추천마음에 들 경우 ‘좋아요’와 메시지를 보낼 수 있으며, 하루에 무료 횟수 제한이 있다. 차별화 이성 간에만 볼 수 있는 커뮤니티가 있음. 골드, 플래티넘과 같은 등급을 매겨 등급간 매칭해줌.
골드스푼
오로지 돈과 스펙으로만 등급을 매겨 등급에 따라 이성 간을 매칭해주는 시스템
차별화
일정 재산, 직업을 조건으로 하는 가입 심사 평판이 좋지 않은 소개팅 어플이 난무하는 가운데 능력 있는 남성들과 진지한 연애를 원하는 여성들을 위해 탄생
남자는 능력 & 여자는 외모 조건 내건 골드스푼
남자는 의료인·법조인·회계사·5급 이상 공무원 등의 전문직이거나 연 소득 7000만 원 이상·수입차량 보유·강남 3구 거주 등의 자격 필요
여성은 기존 골드스푼 회원의 프로필 사진 평가에서 3점 이상을 받거나, 골드스푼 인증팀의 심사를 통과한 사람만이 가입 가능
- 마케팅 전략 제시
S : 쉬운 접근성, 양방향 기능 도입 W : 사용자의 검증, 짧은 개발 기간 O : 찾기 힘든 N:N 미팅 어플, 시간별 미팅 기능 T : 시장을 선점하고 있는 거대 어플 들, 악 이용 발생 가능성
개발과제의 기대효과
기술적 기대효과
◇ 클라이언트 네이티브 언어를 사용해 각 운영체제에 맞는 호환성 ◇ 자바 스프링 부트 프레임워크를 사용함으로써 젠킨스과 같은 다양한 툴 호환성 ◇ 양방향 기능 로직을 통한 일 방향적인 단순한 로직 보완 ◇ 필터 기능 도입으로 인해 원하는 방을 찾는 시간 감소
경제적, 사회적 기대 및 파급효과
◇ 코로나로 인해 생긴 우울증을 미팅으로 극복 효과 기대 ◇ 쉽게 접근 가능한 미팅 어플로 인해 경제적으로 어려운 술집을 운영하는 소상공인 경제 회복 ◇ 저렴한 미팅 매칭 비용을 통한 타 어플의 비용을 끌어내리는 효과 기대 ◇ 언택트 시대로 인한 온라인 미팅 기능 도입으로 인한 온라인 미팅 시장 개척
기술개발 일정 및 추진체계
개발 일정
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 개발 ◇ 사용자가 간편하게 사용할 수 있는 추천 기능 개발 ◇ 사용자가 빠르게 사용할 수 있도록 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 각각 파트를 나누기 때문에 해야 할 일이 명확해지고 그 결과로 쉽고 빠르게 코딩이 가능하다.
결과 및 평가
완료 작품의 소개
프로토타입 사진 혹은 작동 장면
포스터
관련사업비 내역서
구글 개발자 계정 : 27,000원 앱 스토어 개발자 계정 : 110.000원 도서 구입비 : 75,000원
향후계획
가. 어려웠던 내용들
● 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패턴 적용예정
특허 출원 내용
내용