WearOS

웨어러블 앱 개발을 발주하려는 담당자가 처음 마주치는 것은 기술 검토가 아니라 서로 다른 견적서 몇 장입니다. 사내에서는 이미 “갤럭시 워치에서 심박수와 걸음 수를 수집해 앱으로 보여주자”는 수준까지 합의가 끝났고, 남은 일은 어느 업체에 맡길지 정하는 것뿐입니다. 그런데 받아 본 견적은 금액 차이가 크고 항목 구성도 제각각이어서, 무엇이 포함되고 무엇이 빠졌는지 비교할 기준이 없습니다.

이 글은 워치 앱을 직접 만드는 방법을 설명하지 않습니다. 웨어러블 프로젝트에서 비용과 일정이 어긋나는 지점이 어디인지, 후보 업체에게 무엇을 물어야 그 지점이 계약 전에 드러나는지를 정리했습니다. Wear OS, 센서 수집, 배터리, 백엔드 같은 기술 항목은 전부 발주사가 업체에게 던질 질문 형태로 바꿔 두었습니다. 일반적인 개발 외주 업체 고르는 법과 겹치지만, 웨어러블은 디바이스라는 변수가 하나 더 끼어듭니다.

디비컨설팅은 한국인 PM이 요구사항과 일정을 책임지고 검증된 글로벌 개발팀이 구현하는 구조로 100건 이상의 프로젝트를 수행했습니다. 50개 이상의 글로벌 파트너사 네트워크에서 인력을 확보하며, 고객 만족도는 98%입니다. 프로젝트가 확정되면 2~4주 안에 전담팀을 구성하고, 국내 채용 대비 40~60% 수준의 비용으로 같은 범위를 수행합니다. 다만 중요한 것은 이 숫자가 아니라 아래 질문에 업체가 어떻게 답하는지입니다.

웨어러블 앱 견적이 실제보다 싸게 나오는 이유

웨어러블 견적은 일반 모바일 앱 견적보다 틀어질 확률이 높습니다. 발주사도 업체도 워치에서 보이는 화면을 기준으로 범위를 상상하는데, 실제 개발 범위는 그 화면 뒤에 대부분 숨어 있기 때문입니다. 아래 세 가지는 계약 후 추가 비용으로 되돌아오는 대표적인 누락 항목이며, 견적은 총액이 아니라 출시 이후의 앱 유지보수 비용까지 포함해 보셔야 합니다.

워치 앱만 계산하고 폰 앱·백엔드·관리자 화면이 빠집니다

워치 앱은 전체 시스템의 입구일 뿐입니다. 센서 데이터는 워치에서 발생하지만 저장과 조회, 분석은 폰 앱과 서버에서 일어나고, 운영자가 수집 현황을 확인할 관리자 화면도 거의 항상 필요합니다. 데이터를 받는 API와 사용자 인증, 데이터베이스 설계는 워치 화면 개수와 무관하게 별도로 만들어야 합니다. 견적서에 “워치 앱 화면 N개”만 적혀 있다면 그 금액은 실제 범위의 절반도 담지 못한 숫자입니다.

디바이스 실기기 테스트가 빠집니다

에뮬레이터로는 센서값의 실제 분포, 배터리 소모량, 블루투스 연결이 끊겼다 붙는 상황을 확인할 수 없습니다. 워치는 모델마다 화면 크기(480×480px 수준)와 연산 능력, Wear OS 버전이 다르고, 같은 코드가 어떤 모델에서는 멀쩡하고 어떤 모델에서는 수집이 끊깁니다. 실기기를 확보해 모델별로 돌려 보는 공수가 견적에 없다면, 그 비용은 사라진 것이 아니라 출시 직전의 추가 비용이나 출시 후의 품질 문제로 이동한 것뿐입니다.

배터리 최적화를 기능이 아니라 ‘품질’로 분류해 누락합니다

배터리 최적화는 화면을 하나 더 만드는 일이 아니라 수집 주기와 전송 방식을 다시 설계하는 일입니다. 기능 목록에 없으니 견적서에서도 빠지고, 테스트 단계에서 배터리가 반나절도 못 간다는 보고가 올라온 뒤에야 범위 협의가 시작됩니다. 하루 종일 착용 가능한 수준을 설계 목표로 잡으려면 GPS 수집 주기 조정, 센서 배치(batching), 정지 상태에서 수집 빈도를 낮추는 적응형 로직, Wi-Fi 연결 시에만 대량 전송하는 방식이 처음부터 설계에 들어가야 합니다.

웨어러블 앱 개발 업체에게 반드시 물어야 할 5가지

아래 다섯 가지는 웨어러블을 실제로 해 본 팀과 모바일 앱 경험을 웨어러블로 확장해 보려는 팀을 가르는 질문입니다. 각 항목 끝에 그대로 물어보실 문장을 적어 두었고, 답변만큼 중요한 것은 그 답이 견적서에 항목으로 들어가는지입니다.

1. 디바이스 테스트 체계

Wear OS는 버전과 제조사별 커스터마이징에 따라 백그라운드 동작과 센서 권한 처리가 달라집니다. 에뮬레이터만으로 개발한 팀은 이 차이를 출시 후 사용자 문의로 처음 알게 됩니다. 실기기를 몇 종 보유하고 있는지, 어떤 모델과 OS 버전 조합으로 테스트하는지, 발주사가 쓰는 워치 모델이 그 목록에 있는지를 확인하셔야 합니다.

물어볼 질문: “실기기 몇 종으로 테스트하십니까? 모델과 Wear OS 버전 조합을 알려 주시고, 에뮬레이터만 쓰는 범위가 있다면 구분해 주십시오.”

2. 백그라운드 센서 수집 책임

웨어러블 서비스의 가치는 대부분 앱을 켜지 않아도 계속 쌓이는 데이터에서 나옵니다. 그런데 Wear OS는 앱이 백그라운드로 전환되면 배터리 절약을 위한 시스템 정책에 따라 센서 접근을 제한합니다. 이는 코드 품질 문제가 아니라 플랫폼의 기본 동작이며, Foreground Service로 실행 상태를 알리고 WorkManager로 전송을 스케줄링하며 Wake Lock을 제한적으로 쓰는 조합을 설계해 본 팀만 안정적으로 통과합니다.

물어볼 질문: “백그라운드에서 센서 수집이 끊기지 않도록 Foreground Service, WorkManager, Wake Lock을 어떻게 조합하셨습니까? 직접 구현한 사례로 설명해 주십시오.”

3. 배터리 최적화를 견적에 넣었는가

앞에서 설명한 누락이 실제로 일어났는지 확인하는 질문입니다. GPS 수집 주기를 어떤 기준으로 정할지, 센서 데이터를 건건이 보낼지 배치로 모을지, 정지 상태에서 수집 빈도를 낮출지, 대량 전송을 Wi-Fi 연결 시로 한정할지가 각각 설계 결정이고 각각 공수입니다. 견적서에 이런 항목이 한 줄도 없다면 배터리 요구사항은 아직 아무도 책임지지 않는 상태입니다.

물어볼 질문: “배터리 최적화가 견적서에 별도 항목으로 들어가 있습니까? 수집 주기, 센서 배치, 적응형 수집 빈도, 전송 조건 중 무엇을 범위에 넣으셨는지 표시해 주십시오.”

4. 워치–폰–클라우드 3단 연동을 누가 책임지나

데이터는 워치에서 끝나지 않고 폰을 거쳐 서버로 갑니다. 워치가 직접 통신하는 것보다 블루투스로 연결된 폰을 경유해 업로드하는 편이 배터리 측면에서 유리하고, 그 통신은 Wearable Data Layer API로 구현합니다. 워치 단독 상황을 위한 LTE 직접 업로드 폴백도 필요합니다. 워치 앱 업체와 백엔드 업체가 다르면, 데이터가 누락됐을 때 워치가 못 보낸 것인지 폰이 못 받은 것인지 서버가 못 저장한 것인지를 아무도 끝까지 추적하지 않고 책임이 사라집니다. 출시 이후의 서버 운영 유지보수 주체까지 같은 질문에 넣어 확인하시는 편이 안전합니다.

물어볼 질문: “워치 앱, 폰 앱, 서버 세 구간 중 귀사 계약 범위는 어디까지입니까? 데이터 유실이 발생했을 때 원인 구간을 찾고 수정하는 책임은 누구에게 있습니까?”

5. 스토어 심사와 SDK 등록

심박수처럼 건강 데이터를 수집하는 앱은 구글 플레이와 갤럭시 스토어에서 별도 심사를 거칩니다. 갤럭시 워치 특화 센서에 접근하려고 Samsung Health Sensor SDK를 쓴다면 개발자 등록과 심사 과정이 또 따로 필요합니다. 여기서 리젝이 나오면 일정이 통째로 밀리는데, 많은 계약서는 개발 완료까지만 범위로 잡고 심사 대응을 비워 둡니다. 같은 이유로 헬스케어 앱 개발은 기능 개발보다 승인 절차에서 일정이 틀어지는 경우가 많습니다.

물어볼 질문: “스토어 심사 리젝 대응과 재제출이 계약 범위에 포함됩니까? Samsung Health SDK 개발자 등록과 심사는 누가 진행합니까?”

실제 선택지는 네이티브냐 크로스플랫폼이냐가 아닙니다

물론 크로스플랫폼 앱 개발 판단 기준은 폰 앱 쪽에서 의미가 있고, Wear OS 쪽은 Kotlin 기반 네이티브가 사실상 기본값입니다. 하지만 프로젝트의 성패를 가르는 변수는 그보다 앞에 있습니다. 요구사항을 누가 정의하고, 디바이스 테스트를 누가 책임지며, 발주사 담당자가 몇 시간을 써야 하는가입니다. 이 기준으로 보면 선택지는 세 가지입니다.

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
디바이스 테스트 책임	개발사	발주사 본인	한국 PM
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

국내 개발사는 책임 구조가 가장 단순합니다. 한국어로 소통하고 요구사항 정리와 실기기 테스트를 개발사가 맡습니다. 문제는 단가입니다. 워치·폰·백엔드·관리자 화면이 모두 붙는 프로젝트는 투입 인월이 커지므로 단가 차이가 총액에서 그대로 증폭됩니다.

해외 직접 발주는 단가만 보면 가장 매력적입니다. 그러나 요구사항 정의, 일정 관리, 중간 검수, 디바이스 테스트 확인, 영어 커뮤니케이션이 전부 발주사 담당자에게 넘어옵니다. 웨어러블은 화면이 나왔는지로 검수가 끝나지 않고 센서가 백그라운드에서 끊기지 않는지, 배터리가 버티는지까지 확인해야 하므로 담당자 투입 시간이 특히 많이 듭니다. 그 시간을 비용으로 환산하면 기대만큼 싸지 않은 경우가 많습니다.

세 번째 구조는 단가는 해외 발주 쪽에 두고 책임은 국내 개발사 쪽에 두는 방식입니다. 발주사는 한국인 PM하고만 한국어로 이야기하고, 요구사항 문서화와 일정 관리, 디바이스 테스트 확인은 PM이 맡습니다. 대신 개발 인력의 상주가 필수인 사업에는 맞지 않습니다. 디비컨설팅이 IT 아웃소싱과 앱 개발 외주를 수행하는 구조가 여기에 해당합니다.

디비컨설팅이 이 과정을 통제하는 방식

위의 다섯 가지 질문은 저희에게도 똑같이 적용됩니다. 저희가 그 질문에 어떤 절차로 답하는지를 단계별로 적었고, 단계마다 발주사가 검토하고 승인하는 산출물이 있습니다.

• ① 상담 및 요구 분석 — 한국인 PM이 한국어로 요구사항을 문서화합니다. 수집할 센서 종류, 수집 주기, 백그라운드 동작 조건, 관리자 화면 지표까지 이 단계에서 확정합니다.
• ② 개발팀 구성 — 확정된 범위에 맞춰 2~4주 안에 전담팀을 구성합니다. Wear OS 네이티브, 폰 앱, 서버 역할을 나눠 배치합니다.
• ③ 프로젝트 개발 — 애자일 방식으로 짧은 주기마다 동작하는 결과물을 공유하고 진행 상황을 투명하게 공개합니다. 범위 변경은 문서에 반영한 뒤 진행합니다.
• ④ 테스트 및 배포 — 기능 QA와 함께 워치 모델별 실기기 확인, 백그라운드 수집 지속성, 배터리 소모를 점검한 뒤 스토어에 배포합니다.
• ⑤ 운영 및 유지보수 — 출시 후 OS 업데이트와 스토어 정책 변경에 대응하고, 계약 종료 시 소스코드와 함께 API 명세·DB 스키마·배포 절차 문서까지 인계합니다.

웨어러블은 실기기 테스트와 스토어 심사가 뒤에 붙기 때문에 같은 기능량의 일반 앱보다 뒤 구간이 깁니다. 일반적인 앱 개발 기간 산정에 이 두 구간을 추가로 잡아 두시는 편이 현실적입니다.

실제 구축 사례

웨어러블과 직접 관련된 구축 사례는 다음과 같습니다.

• Wear OS 센서 데이터 수집 플랫폼 — 심박수·위치 등 웨어러블 센서 데이터를 실시간으로 수집·동기화하고 갤럭시 위치 앱과 연동했습니다. 클라우드 서버 연동으로 데이터 저장과 모니터링 환경을 구축했으며, 다양한 IoT 디바이스로 확장 가능한 구조로 설계했습니다. 산업 분야는 헬스케어와 사물인터넷(IoT)입니다.
• FitDynamics — 사용자 맞춤 운동 퀘스트, 경험치·레벨 시스템, 운동 데이터 리포트 그래프를 갖춘 헬스케어 프로토타입 앱입니다. 웨어러블 연동 가능성을 고려한 확장 구조로 만들었습니다.
• 그 외 구축 범위 — 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트, 하나투어 하나오픈챗, LS일렉트릭 테크스퀘어, 가천대학교 학사관리 시스템을 수행했습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

아래 조건에 해당하면 저희 구조가 잘 맞습니다.

• 헬스케어, 피트니스, 산업 안전처럼 지속적인 신체 데이터 수집이 서비스의 핵심인 경우
• 사내에 Wear OS 개발 경험이 있는 인력이 없어 요구사항 정의부터 함께 할 상대가 필요한 경우
• 워치 앱과 폰 앱, 백엔드를 한 팀에 맡겨 장애 시 책임 구간을 나누고 싶지 않은 경우
• 국내 개발사 수준의 책임 구조를 유지하면서 총비용은 낮추려는 경우

반대로 아래의 경우에는 다른 방식을 권해 드립니다.

• 이미 사내에 Wear OS 팀이 있고 설계와 검수를 직접 하며 인력만 추가로 필요한 경우
• 워치 앱 UI만 2~3주 안에 필요한 초소형 건. 팀 구성 기간을 고려하면 맞지 않습니다
• 요구사항을 끝까지 확정하지 않고 개발하면서 정하려는 경우. 문서화된 범위가 전제입니다

자주 묻는 질문

해외 개발팀이면 의사소통은 어떻게 합니까?

발주사는 한국인 PM하고만 한국어로 소통합니다. 영어로 회의에 들어가시거나 개발자와 직접 메시지를 주고받으실 일은 없습니다. 요구사항 정의, 일정 관리, 중간 검수는 PM의 책임이며 개발팀과의 커뮤니케이션도 PM이 맡습니다.

비용은 어떻게 산정됩니까?

투입 인력의 등급별 단가와 투입 기간을 기준으로 산정합니다. 견적서에는 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 나누어 제시하므로 어느 구간에 얼마가 들어가는지 비교하실 수 있습니다. 웨어러블은 실기기 테스트와 배터리 최적화를 별도 항목으로 표시합니다.

기획서 없이도 견적을 받을 수 있습니까?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 희망 일정과 예산 범위만 정리해 주시면 상담을 시작할 수 있습니다. 이 단계의 견적은 범위 확정 전 개략 금액이므로, 요구 분석을 거친 뒤 항목별 견적으로 다시 드립니다.

실기기 테스트는 어떻게 진행됩니까?

워치 모델별로 실기기에서 확인하는 절차를 테스트 단계에 포함합니다. 에뮬레이터는 화면 레이아웃과 기본 동작 확인까지만 쓰고, 센서값 수집과 배터리 소모, 블루투스 연결 복구, 백그라운드 전환 후 수집 지속 여부는 실기기에서 검증합니다. 발주사가 기준으로 삼는 모델이 있다면 계약 전에 테스트 대상으로 명시합니다.

완성된 소스코드의 소유권은 누구에게 있습니까?

소스코드는 발주사에 귀속됩니다. 계약 종료 시 코드만 넘기는 것이 아니라 API 명세, 데이터베이스 스키마, 배포 절차 문서까지 함께 인계하므로, 이후 다른 개발사에 맡기시거나 사내 인력이 이어받으시더라도 처음부터 다시 분석할 필요가 없습니다. 외주 개발에서 가장 큰 잠금 요인은 코드 자체가 아니라 이 코드를 어떻게 배포하는지 아는 사람이 외부에만 있는 상태입니다. 문서 인계는 그 상태를 없애기 위한 절차이며, 보안 조건과 인계 범위는 계약서에 명시합니다. 관련 내용은 외주 개발 보안·소스코드에 정리해 두었습니다.

정리

웨어러블 앱 개발에서 견적서의 총액은 가장 늦게 봐야 할 숫자입니다. 워치 앱 뒤에 붙는 폰 앱과 백엔드, 관리자 화면이 범위에 들어 있는지, 실기기 테스트와 배터리 최적화가 항목으로 적혀 있는지, 워치에서 서버까지 세 구간의 책임을 한 주체가 지는지, 스토어 심사 리젝 대응이 계약에 포함되는지를 먼저 확인하시면 비교할 수 없던 견적서들이 같은 기준 위에 놓입니다. 그 네 가지를 업체가 모두 책임지면서 단가까지 낮추는 방법은, 한국어로 요구사항과 일정을 책임지는 PM을 두고 개발은 검증된 글로벌 팀이 맡는 구조뿐입니다.