# 실시간 접촉자 확인/알림 플랫폼 - 기획안
> 관리가능한 팬더믹을 위한 마지막 카드.

(추가)[서비스개발진행상황](/3PPJMp-HTEm6FsnfR7MUXQ)문서 에서 실제 개발을 진행하고자함. 싱가포르의 앱이 아래의 모든 내용을 검증해줬고, 오픈소스가 될 예정이니 이것을 기반으로 국내환경에 맞게, 더 가볍고, 개인정보 이슈가 없도록 개발하려고함.

(추가)[싱가포르에서 같은 컨셉의 앱이 출시됨](https://www.tracetogether.gov.sg/) 현재 운영중.. 곧 오픈소스예정. 이 앱의 경우 전화번호를 요구하고 있고, 이것으로 확진자의 정보로 연결하는 것으로 보임. 이점을 빼면 거의 아래내용이 다 구현되어 있다고 보면 됨

**글을 읽기전 주의사항..** "개인정보는 어쩔려고?" 하는 자세로 읽기시작하여 읽는 내내 오독하다가 결국 개인정보떄문에 안돼! 로 흥분하며 결론 맺는 분들 많습니다. 선입관 버리시고 차분히 읽어주시기 바랍니다.

## 간단한 소개
* 대중교통도 뚫린 팬더믹 상황에서 역학조사를 포기하지 않고, 접촉자 정보를 추적할 수 있게함
* 3-4일 걸리는 동선 추적이나 조사없이 확진즉시 접촉자에게 알려줄 수 있음 (N+1차 감염 방지)
* 정확한 정보를 제공하여 방역을 효율적으로 집중하게 할 수 있음.

## 어떻게?
1. 기술:현재 버려지고 있는 가장 정확한/유일한 접촉자 정보(블루투스 신호 정보)를 사용함
1. 참여:사람들의 참여(앱 설치)
1. 정부지원: ~~국가기관의 확진자 확인 공신력 제공~~ 있으면 좋지만 없어도 할수 있음. 무엇보다 기다릴 시간이 없음.

## 가능해?
#### 기술
* 블루투스는 근거리통신 기술로 사람이 들고다니는 스마트폰간의 블루투스 정보는 말그대로 "접촉정보"임. 통신사의 위치정보는 어디까지나 간접적인 정보임.
* 측정할 수 있는 신호 강도와 점유 시간으로 적절한 수준을 찾을 수 있을것으로 예상
* 의심 범위를 수백분의 일로 줄여주기 때문에 아주 소중한 정보임 ( "2호선 이용으로 귀가한 사람들" -> "최소 50m 안에서 10분이상 근접한 사람들" ) .
* 설치된 앱은 블루투스 advertise mode로 켜지는 동시에 주기적으로 신호를 스캔할 수 있음. 이 방식으로 주변의 정보를 수집저장함.
* 블루투스로 본격적으로 기기간 연결하는 것이 아닌, 단지 스캐닝 신호들을 다룸(램덤으로 생성된 advertise용 주소, 디바이스 Class, RSSI 신호강도 등의 정보를 얻을 수 있음)

#### 참여
* 시민들은 확진자 이동정보를 정말 원하고 있는 것 같지만, 참고자료임. "지하철 이동"이라는 이동정보는 사람들에게 아무 의미가 없음. 정말 원하는 것은 **"내가 확진자와 접촉했는가?"** 임.
* 앱을 깔아서 참여하면, 정말 원하는 정보를 얻을 수 있는 확률이 올라감. 참여할 수록 더 올라가고, 정확해짐.
* 자신이 위험한 환경에 노출되어 있다는 사람들은 혹시라도 확진자가 되었을때, 파장을 최소화 하고 싶은 니즈가 있음.

#### 정부지원
* 정확한 확진자 정보는 정부에게만 있으니 반드시 필요하지만, 탑다운 방식은 시간이 오래걸릴수 있음. 초기에는 더 가볍게 접근해야함.
* 정부가 얻게 되는 이익이 가장 분명하다할 수 있음. 정확한 정보로 역학조사 비용을 줄이고, 효율적인 방역이 가능해짐.
* 적어도 수천억원은 절약할 수 있음

## 상세구현
#### 정보수집
* 주기적으로 broadcasting용 id를 생성하여 서버에 고유id와 함께 전송(개인 특정 방지를 위해 생성도 쉽고 안전한 SHA-256 함수로 기기 고유 MAC 주소를 해싱하는 것이 가장 현명하다고 판단)
* 동시에 주기적으로 주변의 브로드케스팅 정보(정확도를 위해 RSSI 포함)를 수집하여 서버에 전송하는 동시에, 랜덤생성된 id를 주변에 브로드캐스팅함 (주변에 내id를 뿌리고, 동시에 뿌려진 id를 수집하며 다니는 것)
* 앱은 백그라운드로 계속 돌아가면서, 서버로 전송함 (실시간일 필요는 없고, 로컬에 수집했다가 wifi일떄 전송해도 됨)
* 저장되는 내용은 a가 b를 발견함, RSSI, a가 b를 발견한 시간, a가 b와 헤어진 시간 등등..
* 단순하지만 엄청난 양의 데이터가 수집될 것임 서버는 일단 단순 저장만 하면됨.
* 다른 방법으로는 모든 사람이 전송하는 방식이 아니라, 기본 아이디만 보내놓고, 확진되었을 때만 관련 정보를 보내는 방법도 있음.단 a->b 일방향으로만 수집되는 단점이 있음
* 또는 데이터베이스에 가입자의 MAC 주소를 저장하고, 클라이언트가 모든 수집된 MAC 주소와 정보를 보내면 서버에서 가입된 유저의 데이터만 수집하는 방식도 괜찮을 듯 함. 다만 이쪽은 개인정보법에 약간 애매함.
* 주기적으로 브로드캐스팅 정보를 서버에 전송하는 것이라면, 무결성을 인증하기 쉬운 블록체인 알고리즘을 일부 사용하는 것도 좋은 방안. (이 경우 노드관리 REST API 서버만 필요하므로 유지비는 가장 적으나 알고리즘 구현이 어려움)

#### 확진자여부 확인
* 정부의 공신력이 중요함, 아무나 자신이 확진자라고 주장하면 안되니까.
* 개인정보가 들어나지 않도록 해야함
* 정부의 지원수준에 따라 몇가지 방법이 있음
* 확진자가 설치한 자가격리앱(정부앱)을 통한 방식, 이용자입장에서는 가장 편함.*[구현예](https://hackmd.io/TNXV54QBTVGJYE8QdYCaEA)*
* 정부가 아무지원을 안해주면, 확진자의 주도로 확인시킬 수 있음
1. 확진자가 앱에서 담당공무원(확진시 매칭됨)의 업무이메일(go.kr로 끝나는)과 확진자번호를 입력함.
2. 서버는 이를 받아서, 담당공무원에게 확인이 가능한 링크를 전달함
3. 공무원은 링크를 열어서 내용을 확인하고 버튼을 누르면 끝
4. 확진자는 공무원이 이러한 일을 하도록 미리 설명해주고, 자신이 원하는 것임을 알려줄수 있음.

#### 필터링 및 알림
* 저장된 데이터에서 검색하여 접촉자후보들을 모두 뽑아냄.
* 적절한 수준에서 선별함. (얼마나 같이 있었는지, 감도가 어느정도인지, 그게 언제인지 그때의 주변상황등에 대한 종합적 판단이 필요함 )
* 최종 접촉자 후보들을 위험 수준별로 분류하여 해당 정보를 접촉자들에게 푸쉬로 알려줌. 기본적으로 시간대 정도알림이 감.
* 접촉자 후보자들은 이정보를 토대로 적절한 조치를 취할 수 있음.
* 이중 검사를 요구받은 사람들은 진료소에 가서 검사를 받으면 됨.

## 이슈
#### 개인정보
푸시알림을 보내야 하기 때문에 식별정보가 필요하고 개인의 동의가 필요함.
이용자가 입력하는 정보는 전혀없음.
접촉자 후보에게 가는 확진자 개인정보는 전혀없음.
개인이 확진자인지 여부를 확인하기 위해서 개인정보가 사용되야 할것 같지만, 확인증을 발급하고 이 진위여부만 확인 하는 방식으로 하면 개인정보를 전혀 사용하지 않게됨. ([구현예](https://hackmd.io/TNXV54QBTVGJYE8QdYCaEA))

#### 접촉정보에 대한 정확성
스캔작업 주기(3-5초)가 있기때문에 이를 고려해야함
마스크를 안했을 경우는 매우 짧은 시간에도 전파가 가능하기 때문에 아주 짧게 곂친다 하더라도 제외시킬수는 없음
감염자가 오염시킨 물건이 매개물이 되는 경우는 시간차가 있기때문에 아예 기록이 없을 수도 있음. (즉 기록에 없다고 감염가능성이 없는 것은 아님, 에어로졸 감염 가능성이 제기됨에 따라 심할 경우 1~3일 내에 방문한 사람마저 떠다니는 확진자의 침방울에 의해 감염될 가능성 또한 있으므로 정확한 판단이 어려워질 것으로 판단됨)

## 실행
#### 1.기술적 검토
* 기본적인 구현가능성은 확인. "nRF" 라는 앱으로 ble 브로드케스팅과 스캔을 테스트 해볼수 있음. 설치하고 advertize 탭을 누른후 추가하면 됨.
* 놓치는 부분이 있는지 프로토타입을 개발하고 테스트해야함
* 베터리 문제의 경우 근처 BLE 디바이스 스캔이 필요한 특성 상 지속적으로 스캔이 되므로, 상당한 베터리 소모가 발생하는 것이 블루투스 스캔 기능이 포함된 앱 개발 중 확인됨. 또한 이 플랫폼의 경우 단순 스캔이 아닌 지속적인 데이터베이스 통신이 필요하므로 추가적인 베터리 소모 또한 필연적으로 이루어짐.
* 블루투스 탐지거리의 경우 테스트 결과 실내에서는 비내력벽 2~3칸, 내력벽 1칸 정도 이내에 있는 장치가 탐지되며, 실외에서는 약 10~17m 내의 디바이스가 탐지됨. [블루투스 RSSI를 이용한 거리계산 공식](https://www.quora.com/How-do-I-calculate-distance-in-meters-km-yards-from-rssi-values-in-dBm-of-BLE-in-android)
* 블루투스 탐지거리가 애매함에 따라 RSSI 수치(dbm)을 이용하여 사용자를 필터링 하는 것이 필요해보이나, RSSI 수치가 상당히 비규칙적이며 폰에 케이스를 끼었는지 아닌지에 따라서도 정확도가 낮으므로 다른 방법을 찾는 것도 필요해보임. (ex. RSSI가 바로 옆에 있음에도 -50~-40 정도가 나오며 들쑥날쑥하는 현상 등)
* 블루투스 스캐닝의 경우 실시간 탐지가 필요한데, 최근 안드로이드의 경우 보안규정에 따라 10분 이상 작동하는 Service를 만드려면 Noticon을 이용한 Foreground 서비스로 구동을 해야함.
* 기술실증 앱 개발은 일단 해당 프로젝트에 참여에 희망하는 개발자들을 모아 한명마다 실증 앱을 개발하도록 하고 구 중 가장 좋은 방식을 채택하거나, 팀을 만들어 하나의 실증앱을 개발하고 그를 토대로 업그레이드 하는 방식 중 하나를 고르는 것이 좋아보임.
* 정부에서 제공하는 인증 API를 이용하는 것이 아닌, 블록체인을 이용한 P2P 인증 방식 또한 유용해보임.

#### 2.개발 추진 방법
현상황에서 분위기를 보면, 대략적으로 3가지 방향이 될것으로 보임.
1. 카카오톡 같은 국민앱이 관련 사내 사외 전문가들을 끌어모아 팀을 만들고 개발함
* 기존 앱에 부가기능(예-카카오톡 실험실)으로 들어가 테스트를 시작할 수 있음.
* 정부의 역할은 정부만 할 수 있는 역할만 하면 됨.
* 확진자 확인 API를 제공해야여 이를 보증해야함 (이를 위해서 개인정보이동이 필요하지 않음. [구현예](https://hackmd.io/TNXV54QBTVGJYE8QdYCaEA) )
* 역학조사관이 신호 세기와 시간에 대한 대략적인 가이드라인을 만들어줘야 함
* 배포에 있어서는 가장 좋음, 설치가 아니라 업데이트만 하면 됨.
1. 블루투스 앱을 전문으로 다루는 작은 회사들이 주체가 됨
* 건강관련 앱이 아닝이상 신규앱으로 출시될 것으로 예상, 앱 배포에 있어서는 느릴수 있으나, 개인정보 다루는데 있어서 더 깔끔할수 있음
* 정부의 역할은 2번과 같음.
1. 정보나 공공기관이 주체가 되어 모든 것을 개발하고 관리하는 모양
* 풀타임 개발자가 없는 상황이라면 외주를 주거나 개발자 참여를 이끌어내야 함.
* 외주는 회의적임. 공격적으로 테스트하고 방법을 찾아야 하는 일인데, 이런 저런 이유로 지연되고, 포기할것이 불보듯 뻔함
* 블루투스 관련해서 경험이 있는 사람이 참여해야하는데...
1. Discord나 Slack을 통해서 여러 개발자가 팀을 결성하고 주체가 되어 개발하는 방식
* Bluetooth 스캐닝과 Database(SQL 등)을 이용한 플랫폼이므로, 여러 분야에서 자신있는 개발자들을 모아 개발할 수 있음.
* RDBMS 경험자, 백엔드 경험자, 안드로이드/IOS 개발자를 필요로 함.
* 시간 절약을 위해 가능한 생산성이 높고 안정성이 입증된 언어로 개발하는 것이 유리함. 백엔드는 Node.js 계열이 유력한 후보
* 각자 자신있는 분야에서 재능기부를 하면서 개발자 본인의 역량 또한 늘릴 수 있고, 하드웨어적 지원(기초/지방자치단체 등에서 사용하는 서버의 공간)을 받을 수 있다면 충분히 괜찮아 보임.
* 취미로 하는 개발자나 본인의 본업무가 있을 개발자가 참여하므로 진행 속도는 낮을 수 있음.
* 일단 참여자의사가 있는 분들은 [여기로.](#%EA%B0%9C%EB%B0%9C%EB%94%94%EC%9E%90%EC%9D%B8%EB%93%B1%EC%97%90-%EC%B0%B8%EC%97%AC%ED%95%98%EA%B3%A0-%EC%8B%B6%EC%9C%BC%EC%8B%A0-%EB%B6%84%EC%9D%80)

결론적으로.. 개발주체는 비정부, api제공은 정부가 하는 것이 가장 무난할 것으로 보임.

#### 3.프로젝트 추진 로드맵
일단 간단한 기술실증(프로토타입)앱을 만들어 정부나 기업에게 제안을 하는 것이 좋아보임.
정부가 먼저 제안하거나 또는 기업이 먼저 제안하거나 해야함
api가 제공된다는 보장이 없으면 기업은 뛰어들수가 없음.
1. 정부가 이를 보장할테니 시도해보면 좋겠다라고 제안하는 모양이 가장 베스트
2. 정부가 이를 원하지 않으면, 서비스 할 기업이 나타나면 API를 제때 제공해 줄 수 있다는 확답이라도 받아야 함
4. 그다음 기업들에게 제안함. 국민앱- 블루투스응용 전문업체순
5. 모두 거절하면, 종료하거나 프로젝트를 오픈소스로 전환/별도 팀을 만들고 업무를 이관하는 방식 등으로 구상을 할 필요가 있음.

이것이 필요하다고 생각하신다면, 누구나 실행하는데 도움을 주실수 있습니다.

* 주변에 카카오톡에 다니는 친구가 있다면, 너네 이것좀 해보라고 알려주면 됩니다.
* 페이스북 이용자면 이 페이지를 공유할 수 있습니다.
* 이 페이지를 수정 보완하실수도 있습니다.
* 개발자 팀을 만들고 각자 재능기부 형식으로 기여하는 것도 상당히 좋아보입니다.

# 방법이 무엇이든 참여하고 싶으신 분은
일단 [오픈채팅방](https://open.kakao.com/o/ggYOQj3b) 에서 부담없이 이야기해주세요.

---------
## 현재까지의 진행 히스토리
* 3.18 서울시 담당자 검토시작 (스마트시티 담당자에서 시작)
* 시민건강국 질병관리과 로 이관
* 3.23 스마트시티 담당자가 과학기술정보통신부에 전달하는 것으로 마무리
(물론, 이후 처리에 대해서는 큰 기대하지 않음. 바쁜 상황에서 충분히 이렇게 될수 있다고 봄. 일단 서울시는 이렇게 마무리. )
* 3.23 블루투스 센싱부분에 대한 프로토타입개발 시작
* [싱가포르에서 비슷한 컨셉의 앱이 대중화됨](https://www.tracetogether.gov.sg/)

# 프로젝트 개발문서 이동한 내용 복사함
## >TraceTogether앱 분석과 달라질점
* [오픈소스](https://bluetrace.io/)가 될 [tracetogether](https://www.tracetogether.gov.sg)이 기반이 될 예정이나 차이가 있을 것. 기본적으로 클라이언트(앱)의 구현은 가져오되, 개인정보나 구현방식은 다를것
* 싱가포르 개발팀이 당장은 오픈소스로 정리해서 공개할 여력이 없어보임. 일단 벤치마킹차원에서 조사.
* 개선점을 분명히 한후 백앤드 부터 설계

### 개인정보이슈
* tracetogeter는 가입할때 부터 폰번호를 입력하고 인증하는 것으로 보임.
* 이 번호는 암호화 되지만, 정부에서는 이를 볼수 있음(이를 통해서 확진자확인을 위한 것으로 보임)
* 설치자는 확진자가 되었을때, 정보제공을 거부할 수 있는지에 대한 [답변](https://tracetogether.zendesk.com/hc/en-sg/articles/360044860414-Can-I-say-no-to-uploading-my-TraceTogether-data-when-contacted-by-the-Ministry-of-Health-)을 보면 기능상으로는 거부할수는 있지만, 법적으로는 역학조사에 참여 해야한다는 것을 명시하고 있음. 결국 거부는 할수 있지만,불법이란 이야기인가? 불분명함
* 일단 설치를 하면, 정부는 핸드폰 번호로 설치여부를 알게 됨
* 접촉자가 누구인지도 정부는 알고 있고, 이를 통해서 접촉자에게 연락을 하게 됨.
* 새로운 앱에서 달라지는 점
* 모든 것은 개인이 결정함.
* 회원가입절차도 없음
* 확진자임을 확인하는 절차를 둘것임. (절차를 진행할지는 개인에게 달려있음.)
* 확진자임을 확인해주는 것이 어떤 정보를 제공하는지에 대해서 명확히 해줄 필요가 있음.
* 접촉자가 이알림을 받고 검사하러 갈지는 개인이 결정함.
### 로그 데이터 저장방식
* 로그를 로컬에 저장하고 있다가 확진시 서버로 제출하는 방식임.
* 정부는 이정보를 가지고 접척자에게 연락하는 것으로 보임
* 새로운 앱에서 달라지는 점
* 확진자는 확진자역할로 업로드
* 일반사용자는 조회
* 조회를 자동으로 할수 있는 옵션을 제공 wifi+베터리 충전시 서버로 전송하게 됨.

### 사용자불만(스토어리뷰)
* opt문제. 즉 가입부터 안되는 이슈(이용자폭증이 문제라함) : 블록체인(P2P)을 이용한 Server-less 방식이 효과적
* 베터리 문제 : 통신 특성 상 해결이 힘듬, DB 발신을 스마트폰이 충전중일 때만 작동하도록 하는 것이 최선일 듯.
* 블루투스이어폰 재생이 끊긴다고함 : BT 계열 스캔 사용 시 발생하는 고질적인 문제로 해결 불가.
* 아이폰에서는 앱을 맨앞에서 실행중이어야 제대로 동작한다는 제한이 있음!! 안드로이드 비해서 평이 안좋음.
<details><summary>자세히</summary>
Unfortunately, on iOS, the TraceTogether app works best in the foreground, so that is what we recommend for better results.

To learn more, please read Apple Developer’s documentation at: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html

When you are in crowded places and not actively using your phone, we recommend that you foreground the TraceTogether app in Power Saver Mode. If you need to use your other apps, just remember to switch back to TraceTogether when you are done.

In Power Saver Mode, TraceTogether dims the screen to minimize and conserve battery usage but stays in the foreground so it can continue searching for other TraceTogether phones. You can activate Power Saver Mode by putting your mobile phone face down, or keeping it upside down if it’s in your pocket. You can also click on the link on the app home screen for these instructions.

</details>

### 개발스텍
* firebase를 주로 사용함. serverless
* firebase auth에 문제가 있는 것으로 보임. 가입이 안되어 욕을 많이 먹음.

### 분석관련정보들
https://www.tech.gov.sg/media/technews/geeky-myth-busting-facts-you-need-to-know-about-tracetogether
https://medium.com/@meshead/tracetogether-a-technical-look-e48360d4a4a9

## 기획 및 정책 이슈
### 네이밍
위 음악표시가 서비스로고이면서 의미임
페르마타(fermata) 또는 코로나(corona) 라고 읽음(이탈리어)
* 페르마타(Fermata) : stop이란 의미
* 코로나(corona) : 영어의 코로나와 같음. 코로나 바이러스의 그 코로나
* 음악적의미: 겹세로줄 위에 위치할 때: D.C., D.S.따위와 같이 쓰여 곡을 마치라는 뜻.(특정 음표 위에 위치할 때: 악곡의 감정을 생각하여 음의 길이를 늘여 연주하라는 뜻)

이래저해 합쳐서,"fermata corona", "코로나 끝내기" 라는 의미

### 개인정보 이슈 제거
* 이용자에게 입력받는 개인정보 없음
* 기기실별id 사용하지 않음 ( 재설치시 새로운 id발급)
* 이동경로 공유하지 않음

### 알림받는 정보
접촉유지시간 및 신호강도/해당 날짜(일자만) 3가지만 알려줌.
이외는 아무것도 알려주지 않음.
이정보에 기초해서 얼마나 위험한지에 정보와 가이드는 제공,
이동경로나 장소에 대한 정보는 없음.

### 필터링 조건
* 클라이언트 필터링 : 클라이언트에 수집되야 하는 조건, 이 필터는 수시로 바뀌고 적용될수 있도록 서버에 저장되고, 클라이언트는 앱 업데이트 없이 갱신할수 있어야함
* 서버 필터링 : 알림 받을 조건을 조절할수 있어야함

### 확진여부 입력
일단 정부지원이 전혀 없는 경우라도 돌아갈수 있게 되야함.
* 정부공식api가 없는 경우: 확진자가 담당공무원을 통해서 확인받게 해줄 수 있음.
1. 확진자가 앱에서 담당공무원(확진시 매칭됨)의 업무이메일(go.kr로 끝나는)과 확진자번호일부를 입력함.
2. 서버는 이를 받아서, 담당공무원에게 확인이 가능한 링크를 전달함
3. 공무원은 링크를 열어서 내용을 확인하고 버튼을 누르면 끝
4. 확진자는 공무원이 이러한 일을 하도록 미리 설명해주고, 자신이 원하는 것임을 알려줄수 있음.

* 정부공식API가 생길 경우: 확진자가 설치한 자가격리앱(정부앱)을 통한 방식, 이용자입장에서는 가장 편함. *[구현예](https://hackmd.io/TNXV54QBTVGJYE8QdYCaEA)*

## 기능개발 요구사항
### DB
* 스케일이 아주 커질수 있으니 클라우드 DB
* 회원정보 DB
* 임시아이디 DB
* 근접정보 DB
* 저장은 매우 자주 대규모로 일어나고 검색도 빨라야함
* 로컬이든 서버든 모든 정보는 21일 이후 자동삭제되야함. 그러니, 아주 장기간 저장도 아니고, 그렇게 빅데이터도 아님
* 조회결과 반응속도가 빠르면 좋지만 꼭 실시간이 아니여도 됨
#### 알림QDB
* 파이어베이스의 Notification 사용
* 또는 Socket.io를 이용하여 앱에서 수신받으면 직접 브로드캐스팅
### 통신 서버
* 앱용-로그 업로드와 데이터 조회를 담당하는 REST API
* 빠른 구축을 위해 Node.js + (Socket.io 또는 Express) 사용
* 근접자 알림용 관리자 페이지
* 백엔드는 Express를 이용하여 구현(ejs 채택), 프론트는 Html5를 이용

### 안드로이드앱
Kotlin 또는 JAVA 사용하며, 라이브러리는 실시간 통신을 채택할 경우 "Socket.io for Android", 비실시간 통신을 채택할 경우 Square사의 "Retrofit"를 사용
#### 네트워크구현부분
* wifi연결시 저장된 log데이터를 전송함-
* 네트워크를

### 아이폰앱
Swift 사용밖에 답이 없는듯 함
사용할 라이브러리는 추가바랍니다.

## 구현기술/사용클라우드
* 어느 회사를 쓸지 결정해야함. 일단 cloud db를 지원하는 aws? nhn? google? toast?
* 무료로 지원해줄 수 있어야함 (마스크앱은 무료로 서비스되고 있음)

## 순서도
추가하겠습니다.