백엔드·관리자 구축 제안 · 동작 데모 포함

오름 완등 인증 서비스
백엔드·관리자 구축 제안서

앱이 흔들리지 않으려면 서버 규격이 먼저 정해져야 한다고 봅니다

신영진 | 풀스택 개발 · 시스템 운영

인증 검수를 먼저 만들어 봤습니다

완등 인증은 이 서비스의 핵심이자, 이용자가 늘수록 운영 부담이 커지는 지점입니다

1자동 판정 먼저사진의 위치·촬영 시각을 오름 좌표·신청 시각과 대조해 조건을 만족하면 통과 후보로 분류합니다

2걸린 것만 확인관리자는 보류 건만 보면 됩니다. 신청이 늘어도 처리 시간이 비례해 늘지 않습니다

3자동 승인은 안 합니다최종 확인은 관리자가 하도록 남겨둡니다. 판정 기준이 잘못 잡혔을 때 잘못된 승인이 쌓이면 되돌리기 어렵습니다

위치정보가 없는 사진이 생각보다 많습니다 — 메신저로 주고받은 사진이나 일부 기기는 위치정보가 제거됩니다. 전부 반려하면 정상 이용자도 막힙니다. 앱에서 촬영 시 위치를 함께 기록해 전송하는 방식을 앱 개발사와 협의하시길 권하며, 그 전까지는 보류로 분류해 관리자가 판단하도록 설계했습니다.

오름 관리와 API 규격

운영 중 바뀔 값은 코드가 아니라 화면에서 고칠 수 있어야 합니다

오름 관리

인증 반경을 오름마다 조정할 수 있게 둡니다. 정상부 넓이가 달라 일괄 기준은 맞지 않습니다. 폐쇄된 오름은 삭제가 아니라 숨김 처리해 기존 인증 기록을 보존합니다

API 규격 초안

앱이 호출할 API를 미리 정리했습니다. 앱과 서버가 동시에 개발되는 구조라 규격이 늦어지면 양쪽 모두 대기하게 됩니다

기술 구성과 선택 이유

개발 인력이 없으시다고 하여 쉬운 표현으로 정리했습니다

1서버 · DBJava(Spring Boot) + MySQL. 검증된 조합이라 이후 다른 개발자가 이어받기 쉽고, 카페24 호스팅 환경에서도 안정적으로 운영됩니다

2관리자 웹별도 설치 없이 브라우저로 접속합니다. 검수 작업이 반복되므로 목록에서 바로 처리되는 구조로 만듭니다

3사진 저장인증 사진은 계속 쌓입니다. 서버 디스크에 그대로 두면 용량이 차므로 별도 저장소를 쓰고 원본과 축소본을 나눠 보관합니다. 목록 화면이 느려지지 않습니다

4소셜 로그인카카오·네이버·애플 토큰을 서버가 검증한 뒤 자체 토큰을 발급합니다. 앱은 자체 토큰만 쓰면 되므로 나중에 로그인 수단이 늘어도 앱 수정이 최소화됩니다

카페24 호스팅에 대해 — 초기 운영에는 충분합니다. 다만 사진 업로드가 몰리면 부담이 커지므로 사진 저장은 분리해 두는 것을 권장드립니다. 이렇게 해두면 이용자가 늘어 서버를 옮기더라도 구조를 다시 짜지 않아도 됩니다.

OCR 판독 결과를 운영 흐름으로 연결한 경험

OCR 자체보다 판독 결과를 어떻게 판단하고 처리할지가 자동 검수의 핵심입니다

1실제 이미지 OCR 연계악사손해보험 운영 업무에서 카카오톡 채널로 접수된 서류 이미지를 OCR 시스템과 연계했습니다. 고객이 보낸 이미지를 판독하고, 그 결과를 업무 시스템의 다음 처리 단계로 넘기는 흐름을 운영했습니다

2이번 과업과 맞닿는 구조외부 채널에서 이미지가 들어오고, OCR 결과를 받아 업무 처리로 연결한다는 점에서 완등 인증 자동 검수와 구조가 같습니다. 사진·텍스트·위치 정보를 종합해 다음 단계를 결정하는 설계로 구현합니다

3통과·보류·반려 분리사진이 흐리거나 기울어지고 텍스트가 일부만 읽히는 상황을 전제로 합니다. 완전 일치만 보지 않고 유사도 기준을 두어 통과 후보·보류·반려로 나누고, 애매한 건은 관리자에게 판정 근거와 함께 넘깁니다

4운영하며 기준 조정판정 기준은 코드에 고정하지 않고 관리 화면에서 조정할 수 있게 둡니다. 초기에는 보류 비중을 높게 두고, 실제 데이터가 쌓이면 자동 통과 범위를 넓혀 운영 부담을 줄입니다

검증 원칙 — 금융권 AML 시스템에서 규칙으로 데이터를 검사하고 예외를 차단하는 구조를 다뤘습니다. OCR 결과도 그대로 믿지 않고 검증·이력·관리자 확인 단계를 두는 원칙으로 설계하겠습니다.

미정 항목에 대한 의견

각각 견적과 일정에 영향이 있어 항목별로 말씀드립니다

항목	1차	의견
소셜 로그인 3종	포함	애플 로그인은 iOS 앱 심사에서 사실상 필수입니다. 카카오·네이버와 함께 넣는 것을 권장드립니다
사진 자동 판정(OCR·위치)	포함	없으면 관리자가 전량 수검사합니다. 이용자가 늘수록 운영이 감당 안 되므로 1차에 넣는 편이 결과적으로 저렴합니다
푸시 알림	축소	인증 승인·반려 알림만 먼저 넣고, 마케팅성 발송은 뒤로. 발송 대상 관리 화면까지 만들면 범위가 커집니다
랭킹·뱃지	후순위	완등 데이터가 쌓여야 의미가 생깁니다. 인증 기록 구조만 제대로 잡아두면 나중에 집계 화면만 추가하면 됩니다
커뮤니티·후기	2차	신고·비공개 처리 등 운영 부담이 큰 기능입니다. 기준을 먼저 정하지 않고 열면 관리가 어려워집니다
통계·대시보드	최소	일자별 인증 건수와 오름별 순위 정도만. 상세 분석은 데이터가 쌓인 뒤에

각 항목의 개별 견적은 요청하신 대로 지원서에 별도로 기재드렸습니다. 다만 자동 판정은 빼지 마시길 권합니다. 이 기능 하나가 오픈 후 운영 인건비를 좌우합니다.

성공적인 마무리의 기준

앱 개발사와 나뉘어 진행되는 구조라, 무엇이 되면 끝인지를 먼저 맞추고 싶습니다

1앱이 막힘없이 붙는 것앱 개발사가 API 문서만 보고 연동을 끝낼 수 있는 것. 문서가 부실하면 서로 확인하느라 일정이 늘어납니다

2인증 한 건이 끝까지 도는 것실제 오름에서 사진을 찍어 올리고 자동 판정 후 관리자 승인까지 현장 시나리오로 1건 완주해 보는 것

3관리자가 혼자 운영하는 것오름 등록·수정, 인증 검수, 반려 사유 입력을 개발자 도움 없이 하는 것

4기록이 남는 것승인·반려 이력과 처리자가 남아, 이용자 문의가 왔을 때 왜 반려됐는지 답할 수 있는 것

확인이 필요한 부분 — ① 앱 개발사 확정 여부와 착수 시점 ② 오름 데이터(368개 좌표·고도·탐방정보) 보유 형태 ③ 인증 사진 보관 기간과 개인정보 처리 방침 ④ 예상 이용자 규모 ⑤ 자동 판정에서 위치정보 없는 사진을 어떻게 처리하실지

규격을 먼저 확정하고
시작하겠습니다

앱과 서버가 동시에 개발되는 구조에서는 서버 규격이 일정을 좌우합니다.
데모는 직접 눌러보실 수 있습니다.