---
title: "📡 260623 — 달록 웨어러블 데이터 전략 (어댑터 매트릭스 + 레퍼런스 분석 + v1 스코프)"
category: "design"
parent: "Claude Code 작업보고"
document_type: "설계"
source_status: "generated"
knowledge_group: "02_specs"
priority: "High"
purpose: "달록이 어떤 웨어러블/헬스 소스에서 어느 깊이의 데이터를 가져올 수 있는지 비교(HC·삼성SDK·가민·애플·자체워치앱), 레퍼런스 앱(스트라바·NRC·런데이) 분석, 그리고 v1 데이터 스코프 확정. 어댑터 우선순위·승인게이트 의사결정 근거."
read_when: ["웨어러블 어댑터","데이터 소스 비교","러닝 다이내믹스","앱화 v1 스코프","경쟁 레퍼런스"]
updated: "2026-06-23"
work_timestamp: "20260623_111901"
context: "달록본레포CC (D:\\dallog\\dallog_git) — 달록 앱화·웨어러블 설계 묶음."
source_of_truth: "https://dallog-tools.hansbridge.co.kr/knowledge/"
---
> 2026-06-23 설계. 앱화 전체는 `260622_설계_앱화-커리큘럼-아키텍처`, 흡수 스키마는 `260622_설계_웨어러블-정규화흡수층-스키마` 참조. 본 문서는 "어디서 어느 깊이까지 데이터를 가져오는가"의 전략 결론.

## 0. 결론 요약
- **러닝 다이내믹스(충격-자세: 지면접촉·수직진폭·강성·좌우비대칭) 수집은 v1에서 포기.** 삼성(HC·SDK)은 원래 불가, 가민·애플만 제공.
- **애플 HealthKit 드롭**(iOS 앱 계획 없음). **삼성 Data SDK 보류**(HC로 먼저, 부족하면 추가).
- **v1 = 폰 GPS 자체 트래킹 + Health Connect 흡수**로 기본+시계열+랩 확보 → **런데이·NRC 경쟁 라인**. 차별화는 AI코치·근력·체성분·KB.
- 깊은 데이터는 나중에 **비파괴 추가**(가민 어댑터/필드 ADD COLUMN/raw_payload 승격). 미리 공간 안 만듦.

## 1. 데이터 획득 비교표 (5개 소스)

| 데이터 | ① HC(삼성경유) | ② 삼성 Data SDK | ③ 가민 Health API | ④ 애플 HealthKit | ⑤ 달록 자체 워치앱(Wear OS) |
|---|---|---|---|---|---|
| 기본(거리·시간·페이스·평균심박) | ✅ | ✅ | ✅ | ✅ | ✅ |
| 시계열(심박·페이스·케이던스·파워) | △ HR·페이스○/케이던스·파워 불확실 | ✅ segment 포함 | ✅ | ✅ | ✅ |
| 구간 랩 | △ | ✅ | ✅ | ✅ | ✅ |
| 러닝 다이내믹스(충격-자세) | ❌ | ❌(앱내부만) | ✅ 완전 | ✅(watchOS9+/S6+) | △ 기기 하드웨어 의존 |
| 기타 | 걸음·수면·SpO2·체성분·VO2max·HRV·GPS·고도 | +스트레스·혈압·혈당·체온 등 광범위 | 최다(BodyBattery·훈련효과·호흡·100+종목) | 광범위(심전도 등) | 워치 센서 범위 |

**접근/구조**: ①②⑤=기기측(Capacitor 앱 필요) / ③=클라우드(웹 가능) / ④=iOS기기. 승인게이트: ①헬스데이터선언 ②삼성파트너십 ③가민파트너(까다로울 수) ④애플$99/년 ⑤없음.

## 2. ★핵심 발견 — 잠금 추세 속 가민이 예외

| | 외부(클라우드) 연결 | 러닝 다이내믹스 |
|---|---|---|
| 애플 HealthKit | ❌ 클라우드 없음 / 기기내 읽기 ✅ | ✅(기기내) |
| 삼성 Data SDK | ❌ 클라우드 / 기기내 읽기 △(파트너십) | ❌ |
| **가민 Health API** | ✅ **클라우드 푸시** | ✅ **완전** |

→ 폰·헬스플랫폼만으론 러닝 다이내믹스 불가. 그걸 측정하는 워치가 그 데이터를 (가민API/애플/달록워치앱센서)로 줘야만 가능. **가민이 유일한 개방형 클라우드 소스.**

## 3. 레퍼런스 앱 분석 (스트라바·NRC·런데이)

핵심: **이들은 "수집기"가 아니라 대부분 "자체 폰 GPS 트래킹 앱"**.

| | 트래킹 방식 | 주 어댑터 | 러닝 다이내믹스 | 사용자 제공 |
|---|---|---|---|---|
| **스트라바** | 자체GPS + 수집기 | 가민(.FIT)·애플·HC(얕음:시간·거리·칼로리) | △ 가민 연동 시만 | 최상(GAP·세그먼트·심박존·고급분석) |
| **나이키런** | 자체GPS | 자체+애플/구글핏(쓰기) | ❌ | 중(페이스·랩·케이던스·가이드런) |
| **런데이** | 자체GPS | 자체 | ❌ | 중(기본+음성코칭PT) — 달록 코치각도와 최유사 |

→ 스트라바조차 깊은 데이터는 가민 .FIT 파일 의존. NRC/런데이는 폰GPS라 러닝다이내믹스 원천 불가.

## 4. 달록 시사점 / v1 스코프 확정

```
[v1 — 런데이·NRC 경쟁 라인]
 ├─ 폰 GPS 자체 트래킹 (Capacitor) ← 레퍼런스 3개의 공통 방식
 ├─ Health Connect 어댑터 (갤럭시워치 기본+심박+페이스 흡수)
 └─ + 달록 차별화: AI코치·근력·체성분·KB (NRC·런데이엔 없음)

[보류 — 나중에 비파괴 추가]
 ├─ 삼성 Data SDK (HC가 케이던스·랩 부족하면)
 ├─ 가민 어댑터 (러닝 다이내믹스 — 가민 사용자 한정 프리미엄, 시계제작 불필요)
 ├─ 애플 HealthKit (iOS 단계)
 └─ 러닝 다이내믹스 필드 (raw_payload에 이미 원본 보존 → 컬럼 승격)
```

**러닝 다이내믹스 = "가민 사용자 한정 프리미엄"으로 포지셔닝**(전 사용자 소유는 자체 하드웨어 시계 필요라 비현실적). 자체 워치앱조차 갤럭시워치가 Health Services로 그 지표를 내주는지 미검증(안 줄 가능성).

## 5. "나중에 추가 가능?" → YES, 비파괴 (미리 공간 불필요)
정규화 흡수계층이 이미 확장형: 새 소스=data_source코드+어댑터 / 새 필드=ADD COLUMN(nullable) / 시계열·랩=자식테이블 CREATE. **+raw_payload(jsonb)가 어댑터 원본 전체를 이미 보존** → 컬럼 없어도 데이터 손실 없음, 나중에 승격. 추측성 빈 공간 미리 안 만듦(단순함 우선).

## 6. 미해결(실증 필요)
- 가민 파트너 승인 난이도·비용(★) — 정밀조사 대상
- 갤럭시워치가 달록 워치앱(Health Services)에 러닝다이내믹스 주는지 — 실기기 검증 전 단정 불가
- HC가 삼성헬스 케이던스·랩을 실제 주는지 — 사이드로드 실기기 검증

## 7. 달록 자체 워치앱(Wear OS) 개발 백로그 (후속)
달록 워치앱 트랙(폰앱·HC 다음 단계). raw 가속도·자이로 센서는 Wear OS 표준 API로 개방(삼성 독자 계산지표와 달리 접근 가능) → 직접 측정·감지 구현 가능.

- **[근력] 세트 자동감지 + 휴식타이머 — 🟢 실현성 높음(v1 워치앱)**: 가속도로 움직임=세트진행 / 정지=세트종료 감지 → 휴식타이머 자동 시작. 근력 로깅의 최대 불편(세트·휴식·횟수 수동입력) 제거 = 달록 근력축 킬러 UX, NRC·런데이엔 없음.
- **[근력] rep(횟수) 자동 카운팅 — 🟡 가능하나 어려움(v2)**: 운동별 손목움직임 편차 큼(컬·프레스 잘됨/스쿼트·데드·플랭크 어려움). 경량 ML(on-device) 필요. 가민·애플도 함(완벽친 않음). 정확도 실기기 프로토타입 검증 필요.
- **[러닝] 직접 트래킹**: Wear OS Health Services로 심박·GPS·운동 직접 측정. 러닝 다이내믹스(지면접촉·수직진폭 등)는 Health Services 데이터타입엔 있으나 갤럭시워치 하드웨어 노출 여부 미검증(§6).
- 공통: capability 체크(기기별 센서 편차) 필수. 신규 네이티브(Kotlin/Compose for Wear OS) 개발.

---

<!-- ───────────────────────────────────────────── -->