배경과 목표
어떤 문제에서 시작했나요?
걷기나 자전거, 버스로 다니는 일은 누구나 매일 하지만, 그 이동이 얼마만큼의 탄소감축에 해당하는지는 따로 재지 않으면 본인도 알기 어렵습니다. 참여를 권하는 쪽에서도 누가 얼마나 움직였는지를 숫자로 모을 방법이 마땅치 않습니다. 이번 프로젝트는 그 이동을 앱이 스스로 기록해 거리와 탄소감축량으로 보여 주고, 쌓인 기록을 포인트로 돌려주는 것을 전제로 시작했습니다. 고객사는 친환경 이동을 알리는 활동을 하는 곳이며, 공개 동의 근거가 없어 이름은 밝히지 않습니다. 남아 있는 자료에는 고객사가 이전에 참여 기록을 어떤 방식으로 모아 왔는지가 적혀 있지 않습니다. 그래서 이 글은 확인된 합의 범위와 실제로 만든 것부터 설명합니다.
목표: 합의된 구축 범위는 기능 정의와 디자인 설계, 앱 화면 설계, 백엔드 개발, 그리고 관리자 페이지와 오너 페이지 개발이었습니다. 앱은 안드로이드와 iOS 양쪽으로 내고, 이동 기록부터 포인트 적립과 상품 구매, 배송까지 한 앱 안에서 끝나게 하는 것이 목표였습니다. 완료 기준은 두 스토어 등록과 함께 개발완료보고서·사용설명서를 전달하고, 계약 기간 동안 모니터링과 유지보수를 이어 가는 것으로 문서에 적혀 있습니다. 가입자 수나 누적 감축량 같은 운영 목표 수치는 자료에 없어 여기에 적지 않았습니다.
네오렉트의 역할
어디까지 수행했나요?
네오렉트는 기획, 디자인, 퍼블리싱, 개발, 유지관리를 맡았고 참여율은 100%로 기록돼 있습니다. 앱과 웹 프론트, 백엔드, 관리자·오너 페이지가 모두 범위 안이었습니다. 2022년 12월부터 참여했고, 가지고 있는 자료에는 종료 시점이 '현재'로만 적혀 있어 끝난 날짜는 비워 두었습니다. 투입 인원과 팀 구성은 자료로 확인되지 않아 적지 않았습니다. 이 글에 적은 내용은 참여 범위와 기능 목록이 기록된 문서, 그리고 실제 앱 화면에서 확인한 것까지입니다. 운영 중 실제로 모인 감축량이나 이용자 규모는 근거가 없어 다루지 않았습니다.
주요 기능
무엇을 만들었나요?
- 이동을 시작하기 전에 걷기·자전거·버스 중 하나를 고르면, 선택한 방법에 맞춰 이동이 기록됩니다.
- 시작을 누르면 지도 위에 동선이 그려지고 이동 거리와 소요 시간, 탄소감축량이 함께 올라갑니다.
- 이동을 끝내면 거리·탄소감축량·이동시간을 정리한 여정 기록이 뜨고, 그 자리에서 포인트가 적립됩니다.
- 탄소포인트 적립·사용 내역을 월별로 볼 수 있고, 적립일로부터 1년인 유효기간과 소멸 예정 포인트를 따로 확인합니다.
- 주간·월간 기록을 그래프로 보고 다른 사용자와 순위를 견주어 볼 수 있습니다.
- 모은 포인트나 결제로 상품을 사고, 장바구니와 간편 결제 카드 등록·관리, 주문·배송 내역 조회가 앱 안에서 이어집니다.
- 구글·카카오·네이버·애플 계정으로 로그인하고, 프로필 사진과 닉네임(무작위 생성 가능)을 직접 관리합니다. 촬영한 사진에 위치를 붙여 올리는 길거리 정화 참여와 고객사가 여는 챌린지·게시판도 앱에서 다룹니다.
- 관리자 웹에서는 회원·기록·상품·배송·공지·챌린지·신고·포인트 여덟 개 영역을 운영하며, 기록 관리 영역이 부정 적립 여부를 들여다보는 자리입니다.
해결 과정
제약을 어떻게 풀었나요?
제약 1
이동 기록이 곧 포인트 적립의 근거여서, 기록을 그대로 믿고 포인트를 주면 부정 적립을 걸러낼 자리가 없습니다.
의사결정: 적립 기능만 만들지 않고, 관리자 쪽에 기록을 다시 들여다보는 자리를 따로 두기로 했습니다.
구현: 관리자 웹의 여덟 개 관리 영역 가운데 기록 관리 영역을 부정 사용·기록 모니터링 용도로, 신고 영역을 사용자가 올린 사진의 위치 기반 확인 용도로 나누어 두었습니다. 두 영역 모두 문서에 그 목적대로 적혀 있습니다.
제약 2
안드로이드와 iOS, 기기와 환경이 제각각이라 한 환경에서만 확인하면 출시 후에 문제가 드러납니다.
의사결정: 완성본을 여러 디바이스와 환경에서 돌려 보고, 거기서 나온 버그를 모아 한 번에 수정하는 절차를 두었습니다.
구현: 테스트에서 모인 수정 사항을 반영한 버전을 고객사에 다시 보여 주고 피드백을 받아 적용했습니다. 결과적으로 구글 플레이와 앱스토어 양쪽에 등록됐습니다.
제약 3
2022년 12월부터 기능을 계속 더해 온 서비스라, 새 작업을 바로 운영에 넣으면 쓰고 있는 사용자가 영향을 받습니다.
의사결정: 운영에 바로 올리지 않고 개발 버전을 먼저 배포해 확인하는 순서를 고정했습니다.
구현: 개발 버전을 사전 배포해 테스트와 모니터링을 거친 뒤에 운영 버전에 반영하는 방식으로 작업했습니다.
결과
무엇이 달라졌나요?
- 구축·납품 범위
- 앱(안드로이드·iOS) · 관리자 웹 · 오너 페이지 · 백엔드
- 근거: 참여 범위가 기록된 프로젝트 문서의 작업범위 항목
- 스토어 출시
- 구글 플레이 · 앱스토어 2개 마켓 등록
- 근거: 같은 문서에 양쪽 스토어 등록 주소가 적혀 있음
- 관리자 웹 관리 영역
- 8개 (회원·기록·상품·배송·공지·챌린지·신고·포인트)
- 근거: 같은 문서의 관리자 웹 기능 목록을 세어 확인
화면
실제 화면과 구조
사용 기술
발행 2026.11.03
비슷한 프로젝트를 준비 중이신가요?
배경과 제약 조건을 알려주시면 이 사례의 경험을 바탕으로 진행 방식과 예상 범위를 제안드립니다.