위치 기반 서비스 개발, 지도를 띄우는 건 가장 쉬운 부분입니다 — 발주 전에 정해야 할 6가지

위치 기반 서비스 개발을 준비하면서 같은 기획서로 세 군데에서 견적을 받았는데 금액이 두 배 가까이 벌어졌다면, 그 차이는 대개 업체의 양심 문제가 아닙니다.

기획은 이미 끝났습니다. 화면 설계도 나왔습니다. 지도 위에 주변 항목이 핀으로 표시되고, 사용자가 그중 하나를 선택하면 상대방에게 알림이 가고, 수락하면 연결됩니다. 설명할 것은 다 설명했다고 생각하셨을 겁니다.

그런데 회신이 제각각입니다. 어떤 업체는 한 달에 지도를 몇 번이나 불러올 것 같으냐고 묻습니다. 어떤 업체는 앱이 꺼져 있을 때도 위치를 받아야 하느냐고 묻습니다. 어떤 업체는 아무것도 묻지 않고 금액만 보내옵니다. 그리고 대개 아무것도 묻지 않은 쪽이 가장 저렴합니다.

이 글은 그 금액 차이가 어디에서 생기는지에 대한 설명입니다. 결론부터 말씀드리면, 지도를 화면에 띄우는 일은 이 프로젝트에서 가장 쉬운 부분입니다. 문서가 공개되어 있고, 예제가 있고, 숙련된 개발자라면 오래 걸리지 않습니다. 프로젝트를 흔드는 것은 그다음에 오는 여섯 가지 결정이며, 여섯 가지 모두 개발 단계가 아니라 발주 단계에서 정해야 하는 항목입니다.

디비컨설팅은 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭, 교보생명, 가천대학교 등과 100건 이상의 웹·앱·플랫폼 프로젝트를 수행했습니다. 한국인 PM이 발주사와 한국어로 요구사항을 정의하고, 검증된 글로벌 개발팀이 구현하는 구조입니다.

그중에는 지도와 위치, 실시간 알림이 들어간 서비스가 여러 건 있었습니다. 지도 데이터를 다루는 구조에 대해서는 직방 프로젝트에서 정리한 부동산 플랫폼 API 설계 전략에 따로 적어 두었습니다. 반복해서 확인한 사실이 하나 있습니다. 지도가 뜨지 않아서 멈춘 프로젝트는 없었습니다.

멈추는 자리는 거의 항상 같았습니다. 호출량을 아무도 계산해 두지 않았거나, 권한을 거부한 사용자에게 보여 줄 화면이 기획서에 없었거나, 알림이 얼마나 정확해야 하는지를 정하지 않은 채 개발이 시작된 경우였습니다. 아래 여섯 가지는 그 자리들의 목록입니다.

지도를 띄우는 비용과 지도를 쓰는 비용은 다릅니다

지도를 띄우는 비용은 거의 0에 수렴합니다. 그런데 지도를 쓰는 비용은 사용자 수가 아니라 호출 수에 비례합니다.

이것이 위치 기반 서비스 견적에서 가장 자주 빠지는 전제입니다. 사용자 한 명이 앱을 한 번 열면 지도 로드가 발생하고, 주소를 검색하면 검색 호출이 발생하고, 목록을 새로고침하면 좌표 조회가 다시 발생하고, 경로를 표시하면 길찾기 호출이 또 발생합니다. 화면을 어떻게 설계했느냐에 따라 사용자 수가 같아도 호출 수는 크게 달라집니다. 과금 구조를 결정하는 것은 개발이 아니라 기획입니다.

대부분의 견적서에는 ‘지도 연동’ 또는 ‘위치 기능 개발’이 한 줄로 들어갑니다. 그 한 줄이 가리키는 작업은 지도를 화면에 올리고 마커를 찍는 일입니다. 아래 여섯 가지는 그 한 줄 안에 들어 있지 않습니다.

견적 금액이 벌어지는 이유도 여기에 있습니다. 여섯 가지를 미리 물어본 업체는 그 비용을 반영했고, 묻지 않은 업체는 반영하지 않았을 뿐입니다. 묻지 않은 견적이 싸 보이는 것은 그 항목들이 사라졌기 때문이 아니라, 개발이 시작된 뒤에 변경 요청이라는 이름으로 다시 청구되기 때문입니다. 그리고 이 여섯 가지가 개발 도중에 바뀌면 그것은 수정이 아니라 재설계입니다.

위치 기반 서비스 개발, 발주 전에 정해야 할 6가지

1. 지도 API 선택과 과금 구조

국내 사용자를 대상으로 하는 서비스라면 지도 제공사는 사실상 네이버와 카카오 중에서 고르게 됩니다. 두 곳 모두 과금 기준은 호출량입니다.

다만 무료로 쓸 수 있는 범위, 상업적 이용 조건, 호출 종류별 요금 체계는 제공사마다 다르고 정책도 바뀝니다. 그래서 이 글에는 금액을 적지 않습니다. 계약 전에 각 제공사의 최신 정책 문서를 직접 확인하시는 편이 정확합니다.

발주사가 준비해야 할 것은 금액이 아니라 숫자입니다. 우리 서비스가 한 달에 몇 번 호출하는지를 모르면 어떤 견적도 비교할 수 없습니다. 같은 기능에 A사와 B사가 다른 금액을 적어 냈을 때, 그 차이가 단가 차이인지 호출량 가정의 차이인지 구분할 방법이 없기 때문입니다.

발주 전에 정할 것: 예상 월 호출량을 지도 로드, 장소 검색, 길찾기, 주소-좌표 변환 네 가지로 나누어 각각 추정하고 요구사항 정의서와 견적 요청서에 명시하십시오. 추정치가 정확하지 않아도 괜찮습니다. 숫자가 아예 없는 것보다 낫습니다.

2. 위치 권한과 백그라운드 수집

iOS와 안드로이드 모두 위치 권한은 ‘앱을 사용하는 동안만 허용’과 ‘항상 허용’이 서로 다른 단계입니다. 사용자는 후자를 훨씬 덜 허용합니다.

중요한 것은 기획이 어느 쪽을 전제하고 있느냐입니다. 사용자가 앱을 켜 두지 않은 상태에서도 위치를 받아야 서비스가 성립한다면, 권한 동의율이 곧 서비스의 성립 여부가 됩니다. 기능은 완성되었는데 동의율이 낮아 서비스가 돌아가지 않는 상황은 개발로 해결되지 않습니다.

백그라운드 위치를 사용하면 앱 스토어 심사에서 그 사용 사유를 소명해야 합니다. 이것은 난이도의 문제라기보다 일정의 문제입니다. 심사에서 한 번 막히면 출시일이 밀립니다. 발주 단계에서 막을 수 있는 리젝 사유는 앱스토어 심사 거절이 반복되는 이유에 따로 정리해 두었습니다.

발주 전에 정할 것: 백그라운드 위치가 정말 필요한지 다시 검토하시고, 권한을 거부한 사용자에게 무엇을 보여 줄지 정해 견적 요청서에 적으십시오. 수동 주소 입력으로 대체할지, 기능을 일부만 열지, 이용이 어렵다고 안내할지를 정하셔야 합니다. 이 화면은 기획서에서 가장 자주 누락되는 화면입니다.

3. 측위 정확도 전제

GPS는 하늘이 열린 실외에서 가장 정확하고, 실내와 지하, 고층 건물 사이에서는 오차가 커집니다. 와이파이와 기지국 정보로 보정하더라도 이 전제 자체는 달라지지 않습니다.

문제는 서비스 로직이 그 오차를 견디도록 설계되어 있느냐입니다. 일정 반경 안의 사용자에게 노출하는 기능은 오차에 관대합니다. 반면 매장 안에 들어왔을 때 자동으로 처리되는 기능은 오차에 민감합니다. 같은 ‘위치 기능’이라도 요구하는 정확도가 다릅니다.

허용 오차를 먼저 정하지 않으면 QA 단계에서 ‘되는데 가끔 안 됩니다’라는 보고가 반복됩니다. 이것은 버그 리포트가 아니라 기준이 없다는 신호이고, 기준이 없으면 수정도 끝나지 않습니다.

발주 전에 정할 것: 서비스가 견딜 수 있는 오차 범위를 미터 단위로 합의하고, 오차가 그보다 클 때 어떻게 동작할지를 함께 정하십시오. 수동 주소 입력이나 지도에서 직접 위치를 지정하는 대체 동작이 같이 설계되어야 합니다.

4. 지오펜싱·실시간 알림의 트레이드오프

특정 구역에 들어왔을 때 알림을 보내는 기능, 즉 지오펜싱은 앱이 사용자의 위치를 계속 지켜보고 있다는 뜻입니다.

확인 주기를 촘촘하게 하면 알림은 정확하고 빨라지지만 배터리 소모가 늘어납니다. 느슨하게 하면 배터리는 아끼지만 알림이 늦거나 누락될 수 있습니다. 이 둘은 함께 좋아지지 않습니다. 배터리를 많이 쓰는 앱은 사용자가 지우거나 권한을 회수하기 때문에, 이것은 기술 선택이 아니라 서비스 선택입니다.

알림이 조금 늦어도 되는 서비스와 반드시 즉시 도달해야 하는 서비스는 구현 난이도가 몇 배 차이 납니다. 전자는 비교적 표준적인 방식으로 처리할 수 있고, 후자는 별도의 설계와 실기기 검증이 따로 필요합니다. 네이티브와 크로스플랫폼 중 무엇으로 만들지도 이 지점에서 함께 검토해야 합니다.

발주 전에 정할 것: 알림이 늦어도 되는가, 놓쳐도 되는가. 이 두 질문의 답을 견적 요청서에 적으십시오. 두 질문에 모두 ‘안 된다’고 답하실수록 비용과 기간이 올라갑니다. 그 사실을 알고 선택하시는 것과 모르고 선택하시는 것은 다릅니다.

5. 위치정보 관련 신고 절차

개인의 위치정보를 이용해 서비스를 제공하는 경우, 「위치정보의 보호 및 이용 등에 관한 법률」 제9조에 따라 위치기반서비스사업 신고 대상이 될 수 있습니다. 소관 기관은 방송미디어통신위원회(옛 방송통신위원회)이며, 신청은 전자민원센터를 통해 진행합니다.

구분도 확인하셔야 합니다. 위치정보를 직접 수집하거나 제공하는 위치정보사업은 위치기반서비스사업과 별도로 구분되며, 사업 유형에 따라 적용되는 절차가 달라집니다. 우리 서비스가 어느 쪽에 해당하는지는 기능 구조에 따라 달라집니다. 신고 자체에 수수료는 없으나, 등록면허세가 사후에 부과됩니다.

여기서 분명히 말씀드립니다. 위 내용은 법률 자문이 아닙니다. 정확한 해당 여부와 구체적인 절차, 제출 서류는 법무 검토 또는 소관 기관 확인이 필요합니다.

발주사 입장에서 중요한 것은 이 항목을 ‘법적 리스크’가 아니라 ‘일정 항목’으로 다루는 일입니다. 개발이 끝났는데 행정 절차가 남아 출시가 미뤄지는 상황은 피할 수 있습니다. 절차가 있다는 사실을 미리 알고 일정에 넣어 두면 됩니다.

발주 전에 정할 것: 우리 서비스가 신고 대상인지 법무 검토를 받으시고, 그 절차에 걸리는 기간을 출시 일정에 반영하십시오.

6. 위치 데이터를 저장할 것인가

현재 위치를 받아 쓰고 버리는 서비스와, 사용자의 이동 경로를 쌓아 두는 서비스는 화면상 비슷해 보여도 완전히 다른 서비스입니다.

경로를 저장하는 순간 보관 기간, 파기 절차, 접근 권한, 조회 기록 관리가 모두 설계 대상이 됩니다. 저장하지 않는 서비스에는 아예 존재하지 않는 작업들입니다. 그래서 ‘일단 쌓아 두고 나중에 분석하자’는 결정은 겉보기와 달리 가장 비싼 기본값이 되기 쉽습니다. 외부 개발팀이 어디까지 접근하는지를 문서로 통제하는 방법은 외주 개발 보안에서 실제로 통제해야 하는 것에 정리해 두었습니다.

반대로 처음부터 저장하지 않기로 정하면 설계가 단순해집니다. 나중에 정말 필요해졌을 때 추가하는 편이 수월한 경우도 많습니다.

발주 전에 정할 것: 경로 저장이 정말 필요한지, 필요하다면 무엇에 쓸 것이고 보관 기간은 얼마이며 누가 조회할 수 있는지를 정해 견적 요청서에 적으십시오.

세 가지 발주 방식은 여기에서 갈립니다

한국 기업이 실제로 마주하는 선택지는 ‘국내냐 해외냐’가 아닙니다. 위의 여섯 가지를 누가 정의하고 누가 책임지는가로 갈립니다.

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
호출량·과금 설계 책임	개발사	발주사 본인	한국 PM
국내 지도 API 정책 파악	높음	낮음	높음
권한·스토어 심사 대응	가능	어려움	가능
실환경 테스트 주관	개발사	발주사 본인	한국 PM
발주사 담당자 투입 시간	보통	매우 많음	적음
커뮤니케이션 언어	한국어	영어	한국어
개발 단가	높음	낮음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

이 표에서 가장 오해하기 쉬운 줄은 ‘개발 단가’입니다. 해외에 직접 발주하든 한국인 PM을 거치든 개발 단가 자체는 낮습니다. 차이는 그 낮은 단가를 쓰기 위해 발주사가 무엇을 떠안느냐에 있습니다.

해외에 직접 발주한다는 것은 호출량 설계, 지도 API 정책 해석, 스토어 심사 소명, 신고 대상 여부 판단을 발주사가 직접 하겠다는 뜻입니다. 사내에 모바일 개발 리드가 있고 요구사항을 영어 문서로 작성할 수 있는 회사라면 합리적인 선택입니다. 실제로 그런 회사에는 그 방식을 권합니다.

그런 인력이 없는 회사가 같은 선택을 하면, 아낀 단가는 재작업과 일정 지연으로 돌아옵니다. 개발팀을 운영할 사람이 없는 상태에서 개발팀만 싸게 구하는 것은 비용 절감이 아니라 비용 이연입니다. 같은 구조가 왜 견적을 넘기는 비용으로 되돌아오는지는 IT 외주개발 비용이 견적보다 더 나오는 구조에 정리되어 있습니다.

디비컨설팅이 이 결정들을 정리하는 방식

IT 아웃소싱 프로젝트는 다음 5단계로 진행됩니다. 위의 여섯 가지가 각 단계 어디에서 정해지는지 함께 적었습니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 앞의 여섯 가지 중 네 가지, 즉 예상 호출량, 백그라운드 위치 필요 여부, 허용 오차 범위, 경로 저장 여부를 이 단계에서 확정합니다. 신고 대상 여부는 법무 검토가 필요한 항목이므로 이 단계에서 일정 항목으로 등록합니다. 여기서 정리된 문서가 이후 견적과 검수의 기준이 됩니다.
2. 개발팀 구성 — 프로젝트 성격에 맞는 전담팀을 2~4주 안에 구성합니다. 위치 서비스는 모바일 권한 처리와 지도 API 연동 경험을 기준으로 인력을 배치합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 한국인 PM하고만 한국어로 소통합니다. 개발팀과 직접 영어로 회의하실 필요가 없습니다.
4. 테스트 및 배포 — QA를 거친 뒤 릴리스합니다. 위치 서비스는 사무실 책상 위의 테스트만으로 검증되지 않습니다. 실제 기기로, 실제 환경에서, 이동하면서 확인하는 테스트가 별도로 필요합니다. 실내와 지하, 이동 중 알림 도달처럼 재현이 어려운 조건은 이 단계에서 걸러내며, 해당 일정을 처음부터 계획에 포함합니다.
5. 운영 및 유지보수 — 문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차가 포함됩니다. 소스코드는 발주사에 귀속됩니다.

이 구조로 만든 것들

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• 직방 — 호갱노노, 부동산 데이터 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처 글펍, 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 와디즈 — 글로벌 플랫폼

위치 요청을 업로드하면 근처 사용자에게 실시간으로 안내되는 위치 기반 생활 서비스 웹 플랫폼도 구축했습니다.

100건 이상의 프로젝트, 50개 이상의 글로벌 파트너사, 고객 만족도 98%. 다른 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 앱 개발 외주 또는 웹 개발 외주에 위치·지도·실시간 알림이 들어가는데, 사내에 이 영역을 설계해 본 인력이 없는 기업
• 배달, 방문, 매칭, 현장 관리처럼 위치가 부가 기능이 아니라 서비스의 핵심인 기업
• 견적서를 여러 장 받았으나 금액 차이의 근거를 설명해 줄 사람이 필요한 기업
• 개발 이후 운영과 유지보수까지 한국어로 소통할 상대가 필요한 기업

반대로 권하지 않습니다

• 사내에 모바일 개발 리드와 기획 인력이 이미 있는 기업. 권한·과금 설계를 직접 하실 수 있다면 해외 인력을 직접 계약하시는 편이 더 저렴합니다. 저희 구조의 가치가 정확히 그 설계와 관리 업무에 있기 때문입니다.
• 2~3주 안에 결과물이 필요한 경우. 전담팀 구성에만 2~4주가 걸립니다.
• 측위 정확도가 센티미터 단위로 요구되는 산업용 측량이나 정밀 제어. 일반 모바일 측위의 영역이 아니며, 전용 장비와 기술이 필요합니다.
• 가장 낮은 견적이 유일한 기준인 발주. 앞의 여섯 가지를 묻지 않은 견적이 언제나 가장 쌉니다. 그 기준으로 선택하실 예정이라면 저희는 적합한 상대가 아닙니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 되나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 직접 영어로 회의하거나 번역된 문서를 검토하실 필요가 없습니다.

국내 지도 API는 해외 개발팀이 다룰 수 있나요?

네이버와 카카오의 지도 API는 개발 문서가 공개되어 있어 구현 자체는 일반적인 API 연동 작업입니다. 다만 약관과 과금 정책, 상업적 이용 조건처럼 한국어 문서를 읽고 판단해야 하는 영역이 있습니다. 이 부분은 한국인 PM이 맡아 정리하고, 개발팀은 정리된 요구사항에 따라 구현합니다. 제공사 확인이 필요한 경우에도 PM이 한국어로 처리합니다.

기획서가 없는데 견적이 가능한가요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 그리고 일정과 예산 범위만 있으면 개략 견적을 드립니다. 위치 서비스의 경우 앞의 여섯 가지 중 답할 수 있는 항목을 함께 주시면 견적의 정확도가 올라갑니다.

비용은 어떤 기준으로 산정되나요?

등급별 단가에 투입 기간을 곱해 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 항목에서 금액이 발생하는지 확인하실 수 있습니다. 지도 API 사용료처럼 제공사에 직접 지불하는 비용은 개발비와 분리해 안내합니다.

소스코드 소유권은 어떻게 되나요?

발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계하므로, 이후 다른 개발사와 협업하시더라도 이어받을 수 있습니다.

정리

위치 기반 서비스 개발에서 프로젝트의 성패를 가르는 것은 지도를 띄울 수 있느냐가 아닙니다. 호출량, 권한, 정확도, 알림, 신고, 보관 — 이 여섯 가지를 누가 언제 정의하느냐입니다. 발주사가 정하지 않으면 개발사의 가정대로 만들어지고, 아무도 정하지 않으면 개발이 끝난 뒤에 변경 요청이라는 이름으로 비용이 돌아옵니다. 여섯 줄을 견적 요청서에 적어 넣는 데 드는 시간은 길지 않습니다. 그 시간이 견적 비교를 가능하게 만들고, 프로젝트 중반의 재설계를 막습니다. 기획서가 아직 정리되지 않았더라도, 해결하려는 문제와 주요 사용자, 필수 기능 몇 가지만 있으면 개략 견적과 함께 여섯 가지에 대한 검토 의견을 드릴 수 있습니다.