차곡 BE 기획안 v1.0

§1 적립

A. 이렇게 동작합니다 결정

방문·걸음·하늘 색이 트랙별로 쌓이고, 무엇이든 바뀌면 뒤에서 도는 처리기가 그 여파를 결산·수집 현황·배지에 반영합니다. 방문은 "어떤 종류(지역/역/음식점)의 무엇을 언제" 형태로 저장합니다. 같은 날 같은 지역을 여러 번 지나가도, 데이터베이스가 같은 날 같은 지역은 한 건만 남기도록 막아주어 자연스럽게 하루 1회로 정리됩니다.

B. 확인이 필요한 부분입니다

• 지하철·산처럼 네트워크가 끊긴 곳에서 감지된 기록을, 기기가 저장해 두었다가 연결이 되면 서버로 보내는 흐름입니다. 서버는 늦게 도착한 기록도 그 일이 실제로 일어난 날짜로 받습니다.
• 하루가 몇 시에 끝나는지를 기기와 서버가 같은 기준(자정)으로 맞출 수 있는지 확인이 필요합니다.
• 자동으로 모인 기록과 사용자가 직접 입력한 기록을 화면에서 구분해 보여줄지 확인이 필요합니다. 서버는 둘을 구분해 저장하며, 조작이 가능한 직접 입력분은 순위 경쟁에서 빼는 것을 원칙으로 합니다.

C. 아직 정하지 않은 부분입니다

• 하루 단위 기록을 계속 그대로 둘지, 오래된 것은 주·월 단위로 묶어 정리할지 정해야 합니다.

§2 온보딩 / 과거 데이터 가져오기

A. 이렇게 동작합니다 결정

설치 직후 사진첩을 훑어, 각 사진에 담긴 (촬영 좌표, 촬영 시각)만 500~1,000장씩 나눠 서버로 보냅니다(여러 묶음을 동시에 보낼 수 있습니다). 서버는 좌표를 행정구역으로 바꿔 "누가 어느 지역에 어느 날" 형태로만 저장하고 좌표는 버립니다. 같은 날 같은 지역은 한 건만 남으므로, 다시 가져오거나 같은 묶음을 중복해 보내도 기록이 어긋나지 않습니다. 그래서 응답을 못 받은 묶음은 그냥 다시 보내면 됩니다. 모든 묶음이 끝나면 그 기간의 과거 결산을 만들어 줍니다.

B. 확인이 필요한 부분입니다

• 사진 수천 장을 훑을 때 앱이 멈추지 않게 하는 처리, 사용자가 사진 일부만 허용한 경우의 대응, 훑는 동안 보여줄 대기 화면입니다.
• 이 대량 전송 통로도 좌표를 로그에 남기지 않는지 반드시 검증 대상에 넣습니다.
• 권한을 요청하기 전에 이유를 설명하는 안내 화면과, 가져온 결과가 빈약할 때 보여줄 화면입니다.

C. 아직 정하지 않은 부분입니다

• 과거 기록으로 결산을 만들 때 하루 단위까지 다 만들지, 월·해 단위만 만들지 정해야 합니다.
• 건강 데이터를 몇 년 치까지 읽어올지 정해야 합니다.

§3 지역 도장깨기 (발 디딘 지역을 자동으로 채워가는 기능)

A. 이렇게 동작합니다 결정

좌표를 행정구역으로 바꾸는 일은 서버가 합니다. 전국 행정구역 경계는 공공데이터포털의 통계청 자료(무료이며 상업적 이용이 허용됨)를 쓰고, 행정안전부 코드를 표준으로 삼으며, 반기마다 갱신하되 기준 날짜를 판본으로 붙입니다. 저장은 가장 작은 단위인 행정동으로 하며, 시·군·구는 여기서 자동으로 얻어집니다(행정동을 알면 상위 구는 알 수 있지만, 반대로는 알 수 없기 때문입니다). 행정구역이 개편되면 "옛 지역이 어느 새 지역으로 이어지는지" 적은 대응표를 두고, 과거 기록은 그대로 보존한 채 화면에 보여줄 때 최신 지역으로 바꿔 셉니다. 지하철역 정보는 국가철도공단 표준 자료를 단일 출처로 씁니다.

B. 확인이 필요한 부분입니다

• 지도를 어떻게 그릴지입니다. 현재 시안은 실제 지도 없이 점·칸으로 지역을 표현하는 방식입니다. 실제 지도(카카오·네이버 등)를 v1에서 완전히 쓰지 않는 것으로 확정할지 확인이 필요합니다.
• 위치를 계속 수집하는 백그라운드 기능의 라이브러리 선택과, 배터리 소모를 줄이는 정확도 조정입니다.
• "발을 디뎠다"와 "차·지하철로 지나갔을 뿐이다"를 무엇으로 구분할지입니다. 이 판단은 연속된 위치 흐름을 가진 기기만 할 수 있어(그 흐름은 서버로 오지 않으므로) 기기가 1차로 판정해야 합니다.
• 지역을 사용자에게 어느 단위로 보여줄지입니다. 수집 현황은 시연 사이트처럼 "서울 36%"처럼 큰 지역 안의 진행률을 함께 보여주는 계층형을 보여줄 수 있습니다. 여기에 더해 "동네" 순위의 단위와 지역 정복 배지의 기준도 정해야 합니다. 저장은 이미 행정동이라 어느 쪽으로 정해도 데이터는 지원됩니다.
• 지도의 기본 확대 단계입니다(점·칸 방식에서는 "단위를 바꿔 보여주는 화면"의 문제가 됩니다).

§4 활동 적립 (걸음 · 거리 · 고도)

A. 이렇게 동작합니다 결정

건강 데이터는 하루 단위 합계값만 받습니다. 받을 때 "없으면 새로 넣고 있으면 덮어쓰는" 방식이라, 처음 보내든 나중에 워치 동기화로 값이 바뀌어 다시 보내든 같은 통로로 처리됩니다. 실제로 값이 달라진 날짜만 다시 계산합니다. 뒤늦은 보정은 7일까지만 받아주며, 이미 확정된 순위는 그 시점의 값을 따로 저장해 두었기 때문에 나중 보정으로 뒤집히지 않습니다.

B. 확인이 필요한 부분입니다

• 건강 데이터를 다시 읽어 갱신하는 주기, 권한을 거부당했을 때의 화면, iOS·안드로이드의 서로 다른 건강 API를 공통으로 다루는 방식입니다.
• 환산 문구와 환산 대상 선정, 다음 목표까지 남은 양의 노출, 월간 목표를 사용자가 직접 정하게 할지입니다.

C. 아직 정하지 않은 부분입니다

• 환산 목록(에베레스트·서울→부산 등)을 앱 업데이트 없이 추가할 수 있도록 서버에서 관리하는 방식을 정해야 합니다.

§5 미식 도감 / 확인 카드

A. 이렇게 동작합니다 결정

음식점에 머문 것을 감지하는 일은 기기가 합니다. 머무름이 끝나는 즉시 서버가 근처 음식점 후보 n개를 붙인 확인 카드를 만들어 두므로, 외부 장소 검색 호출이 식사 시간대에 자연스럽게 나뉘고, 밤에 사용자가 카드를 열면 기다림 없이 후보가 떠 있습니다. 사용자가 답하지 않은 카드는 7일간 두었다가 지웁니다. 확인받지 않은 방문을 임의로 맞다고 처리하지는 않습니다. 사진은 사용자가 사진첩에서 골라 붙이며, 파일은 기기에만 두고 서버에는 "사진이 붙어 있다"는 표시만 둡니다.

B. 확인이 필요한 부분입니다

• 카드를 넘기는 방식과 탭했을 때 곧바로 반응하는 처리, 사진첩에서 사진을 고르는 화면입니다.
• 카드를 어떤 형태의 화면으로 띄울지(전체 화면·아래에서 올라오는 창 등), 그리고 확인하지 않은 항목을 결산에 흐리게라도 넣을지입니다.
• 밀린 확인을 한꺼번에 "모두 맞다"로 처리하는 대신 "모두 넘기기"만 두는 건 어떤지 제안합니다. 사용자가 보지 않은 방문을 맞다고 처리하면 틀린 가게가 수집 현황·단골 배지·친구와 겹치는 장소 집계까지 오염시키기 때문입니다.
• 음식점 확인을 저녁 하루 마감 때 한꺼번에 묻는 대신, 음식점을 떠난 것으로 추측되는 시각에서 5분쯤 뒤에 그때그때 묻는 건 어떤지 제안합니다. (근거는 아침·점심·저녁에 간 곳을 밤에 몰아서 다 고르는 게 귀찮을 수도 있겠다는 개인적인 생각입니다.)

C. 아직 정하지 않은 부분입니다

• 어느 장소 검색 서비스를 쓸지, 그 서비스의 하루 호출 한도와 비용·상업적 이용 조건입니다.
• 감지한 좌표와 실제 가게를 얼마나 가까울 때 같은 곳으로 볼지, 후보 n개를 어떤 기준으로 고를지입니다.
• 메뉴 종류를 어떻게 분류할지, 수집 현황의 "전체 개수"를 무엇으로 셀지, 카페·술집 등을 어떻게 걸러낼지, 가게 정보를 서버에 얼마나 저장해 둘지입니다.

§6 하늘 아카이브

A. 이렇게 동작합니다 결정

사진첩에서 고르는 것이 아니라 앱 안의 카메라로만 찍습니다(그날 실제로 찍은 하늘임을 보장하기 위해서입니다). 찍은 사진에서 대표 색을 뽑아 서버에는 그 색만 보냅니다. 사진 원본은 물론 축소본도 서버에 두지 않습니다. 며칠 연속 찍었는지와 보호 아이템 처리는 하루가 끝나는 시각 기준을 따릅니다.

B. 확인이 필요한 부분입니다

• 흐린 날의 회색이나 밤하늘의 어두운 색이 뭉개지지 않게 색을 뽑는 방식과, 1년치 365칸을 빠르게 그리는 성능입니다.
• 자정을 갓 넘겨 찍은 사진을 전날 칸으로 인정해 줄지, 그렇다면 몇 시까지 인정할지입니다. - 00시?
• 어둡거나 흐린 하늘도 기록으로 인정된다는 안내, 어둡거나 흐린 하늘과 연속 기록이 끊겼을때 어떻게 구분해 보여줄건지 입니다.

C. 아직 정하지 않은 부분입니다

• 하늘 촬영 알림을 몇 시에 보낼지 정하는 방식입니다(그날 날씨와 연동할지 포함).

§7 하루 마감 / 결산 확인

A. 이렇게 동작합니다 결정

임시 결산이 미리 만들어져 있으므로 진입하면 곧바로 보이고, 음식점 확인 카드를 처리하면 그 내용이 반영되어 확정됩니다. 확인을 건너뛰어도 임시 결산은 그대로 열립니다. 처리하지 않은 확인은 7일에 닫힙니다.

B. 확인이 필요한 부분입니다

• 알림을 눌렀을 때 앱이 꺼져 있어도 곧바로 해당 화면을 여는 처리, 확인에서 결산으로 넘어가는 연출, 여러 날이 밀렸을 때의 화면 전환입니다.
• 확인 창의 형태, 밀린 날짜를 다루는 화면, 기본 마감 시각(밤 9시 반)이 적절한지와 사용자가 바꿀 수 있게 할지, 공유 버튼을 얼마나 자주 띄울지입니다.

C. 아직 정하지 않은 부분입니다

• "나중에 확인" 시 사용자가 지정한 시각에 다시 알림을 보내는 처리입니다.

§8 결산

A. 이렇게 동작합니다 결정

미리 계산해 저장해 둡니다. 확정된 과거 결산은 바뀌지 않습니다(사용자가 직접 삭제를 요청한 경우만 예외입니다). 다시 계산해야 할 일이 생기면 앞서 말한 하나의 신호로 일원화해 처리합니다.

B. 확인이 필요한 부분입니다

• 확정된 과거 결산은 다시 안 바뀌므로 캐시 정책을 분리하는 것, 서버가 새 종류의 결산 카드를 추가해도 앱이 깨지지 않게 하는 것, 해 단위 결산을 별도 화면으로 두는 것입니다.
• 하루·주·월·해 결산을 오가는 방식, 기록이 없는 날의 화면, 과거 결산을 찾아보는 방식, 아직 못 채운 트랙을 흐리게 보여줄지, 친구 결산을 어디서 보게 할지입니다.

C. 아직 정하지 않은 부분입니다

• 결산을 만드는 정기 작업의 실행 방식과, 사용자마다 다른 시간대를 반영하는 방법입니다.
• 데이터가 큰 해 단위 결산을 미리 계산해 두는 방식입니다.
• 새 결산 카드를 앱 업데이트 없이 추가할 수 있는 구조입니다.
• 확정된 결산을 언제까지 바꾸지 않을지의 세부 규칙, 기록이 없는 기간의 기준, 하루 단위 결산의 보관 기간입니다.
• 결산이 다 만들어진 뒤 알림을 보내는 시점입니다.

§9 도감 (수집 현황)

A. 이렇게 동작합니다 결정

누적 개수는 기록이 하나 늘 때마다 조금씩 더해 두는 방식으로 셉니다(화면에 들어올 때마다 전체를 다시 세지 않습니다). 세는 기준은 우리 내부 식별자입니다.

B. 확인이 필요한 부분입니다

• 결산과 같은 화면 부품을 다시 쓰는 것과, 결산과는 다른 저장·캐시 정책입니다.
• 트랙마다 개수가 다른 비대칭 배치(나중에 트랙이 늘 것을 감안), 그리고 수집 현황을 친구에게 보여줄지입니다(보여주기로 하면 음식 사진을 서버에 올릴지 다시 논의해야 합니다).

C. 아직 정하지 않은 부분입니다

• "국밥 12/40"의 40처럼, 수집 현황의 전체 개수를 무엇을 기준으로 셀지입니다.

§10 배지

A. 이렇게 동작합니다 결정

단골·첫 등록 같은 배지 판정은 우리 내부 식별자를 기준으로 합니다. 배지를 언제 주고 언제 회수할지는 "기록을 며칠까지 고칠 수 있는가"에 달려 있습니다. 사용자가 위치 기록을 전부 삭제하면 위치로 얻은 배지도 함께 회수합니다.

B. 확인이 필요한 부분입니다

• 배지를 얻는 순간의 연출, 배지 아이콘을 이미지로 받을지 코드로 그릴지입니다.
• 단골 배지에 가게 이름을 넣는 것과, 프로필에 진열하는 배지 개수를 제한할지입니다.
• 가게 상호를 배지에 표시해도 되는지는 법적 확인이 필요합니다.

C. 아직 정하지 않은 부분입니다

• 배지 종류를 앱 업데이트 없이 추가하는 방식입니다.
• 배지를 실시간으로 줄지, 결산을 만들 때 함께 줄지입니다.
• "앱에서 이 가게를 가장 먼저 등록한 사람" 배지처럼 전 세계에 한 명만 주는 판정에서, 같은 밤 두 사람이 같은 가게를 확인하는 경우의 처리입니다.

§11 공유 카드

A. 이렇게 동작합니다 결정

밖으로 공유되는 이미지에는 모아서 요약한 값만 담고, 언제 어디에 갔다는 낱낱의 방문 기록이나 걸음 수 원본은 담지 않습니다. 하늘 색 모자이크나 환산 문구는 위치가 드러나지 않아 안전하고, 개별 가게 이름·다녀온 동네 목록·순위는 사는 곳이 드러날 수 있어 주의가 필요합니다.

B. 확인이 필요한 부분입니다

• 공유 이미지를 그리는 방식, 해상도 고정, 글꼴이 늦게 뜨는 문제입니다.
• 어떤 카드에 어떤 항목을 담을지, 공유 전에 사용자가 항목을 고르거나 가릴 수 있게 할지, 금액과 정확한 위치를 자동으로 가리는 것입니다.

C. 아직 정하지 않은 부분입니다

• v1에서 공유 이미지를 기기에서 그려도 충분한지, 어떤 결산이 얼마나 공유됐는지 기록하는 방식입니다.

§12 친구 / 겹치는 장소 / 순위

A. 이렇게 동작합니다 결정

친구와 내가 같이 가본 장소가 얼마나 겹치는지를 보여주는 지표는, 서로를 친구로 등록한 사이일 때만 계산하고, 결과에 좌표는 담지 않으며, 우리 내부 식별자를 기준으로 셉니다. "동네" 순위에서 사용자가 어느 지역에 속하는지는 주로 머무는 지역(사는 동네에 해당)을 행정동 단위로 판정해 정합니다.

B. 확인이 필요한 부분입니다

• 친구 초대 링크를 누르면 앱의 초대 화면으로 바로 여는 처리(앱이 없으면 스토어로 유도), 그리고 순위가 낮은 사용자에게는 등수 대신 자기 성장 지표만 보여주는 화면입니다(순위를 서버 응답에서 아예 빼는 방식으로 처리합니다).
• 프로필과 친구에게 공개하는 범위의 기본값, 닉네임 규칙, 순위 화면으로 들어가는 경로, 친구가 한 명도 없을 때의 화면, 친구 기능을 어디에 둘지입니다.

C. 아직 정하지 않은 부분입니다

이 기능은 백엔드 작업량이 v1에서 가장 크며, 미팅과 무관하게 이어서 결정합니다.

• 순위를 어떻게 집계할지, "기간이 시작된 시점보다 얼마나 늘었는지"를 재기 위해 시작 시점 값을 어떻게 따로 저장할지, 순위를 얼마나 자주 갱신하고 언제 확정할지입니다.
• 전국 범위처럼 사용자가 많아지면 무거워지는 순위를 다루는 방식, 주로 머무는 지역을 무엇으로 판정할지, 이사했을 때 갱신하는 방식입니다.
• 순위 낮은 사용자에게 등수를 감추는 서버 처리, 직접 입력분을 순위에서 빼는 처리, 동점 처리입니다.
• 친구에게 공개할 범위를 서버에서 걸러 보내는 처리, 겹치는 장소를 다시 계산하는 시점, 초대 링크의 발급·만료, 신고·차단, 닉네임 정책입니다.

§13 알림

A. 이렇게 동작합니다 결정

보내는 시점은 원문에서 확정된 것을 유지합니다(하늘 촬영·하루 마감·다시 알림·밀린 확인·결산 생성). 사용자마다 다른 시간대에 맞춰 보냅니다. 알림 문구를 서버에서 관리하는 방식과 세부 예약 방식은 아직 정하지 않았습니다.

B. 확인이 필요한 부분입니다

• 앱 안에 알림함을 둘지, 기기 자체 알림과 서버 발송 알림을 어떻게 나눌지입니다.
• 알림 설정 화면, 알림이 겹칠 때의 우선순위, 알림을 전부 끈 사용자를 어떻게 다룰지입니다.

C. 아직 정하지 않은 부분입니다

• 알림 문구를 앱 업데이트 없이 바꾸는 방식과, 사용자가 지정한 시각에 다시 보내는 처리입니다.

§14 프라이버시 / 데이터 통제

A. 이렇게 동작합니다 결정

좌표는 어떤 서버 기록에도 남기지 않습니다. 계정 삭제는 실제로 지우는 것입니다(다만 이미 확정된 남들의 순위가 소급해 바뀌지 않도록, 지난 순위표에 남은 내 자리는 "탈퇴한 사용자"로만 바꿉니다). 위치 기록 전체 삭제가 무엇을 지우는지도 정해 두었고, 데이터 내보내기는 남이 얽히지 않은 본인 데이터만 대상으로 합니다.

B. 확인이 필요한 부분입니다

• 기기 안에서 원본 좌표를 며칠 두는지, 권한이 거부된 상태를 모든 화면이 알아차리게 하는 것, 데이터 내보내기 화면입니다.
• "위치 기록 전체 삭제" 버튼을 설정 맨 위에 두는 것, 트랙별 수집을 켜고 끄는 토글, 집·직장을 기록에서 빼는 설정 경로입니다.
• 위치정보사업자 신고 대상 여부, 위치·건강 같은 민감정보의 별도 동의 요건, 만 14세 미만 가입 처리, 가게 상호 표시 가능 여부는 법적 확인이 필요합니다.
• 데이터 내보내기 기능이 실제로 어디에 쓰이는지 용도 확인이 필요합니다(원문에 한 줄만 있어 근거가 얇습니다).

C. 아직 정하지 않은 부분입니다

• 없습니다.