HiMe는 스마트워치와 스마트폰에서 수집되는 심박수, 혈중 산소, 수면, 운동 등의 데이터를 사용자의 하드웨어 안에서 실시간으로 분석하는 개인 건강 에이전트 플랫폼이다. 기존 웨어러블 분석의 획일성과 개인정보 문제를 해결하기 위해 데이터베이스를 핵심 구성요소로 삼고, 실시간 감지와 장기적인 사용자 모델링을 결합했다. 평가 결과, 강력한 로컬 오픈소스 모델은 일부 호스팅형 최신 모델과 경쟁할 수 있었지만, 여러 차례의 대화를 안정적으로 이어 가는 능력과 웨어러블 데이터에서 주관적 건강 상태를 해석하는 능력은 여전히 과제로 남았다.
1. 연구 배경과 HiMe의 등장
스마트워치와 스마트폰은 이제 병원 밖에서도 일상적인 건강 상태를 지속적으로 측정한다. 심박수, 혈중 산소, 심박변이도, 수면, 운동 기록 등이 기기에 축적되면서 개인별로 수개월 또는 수년에 걸친 장기 건강 기록이 만들어진다.
하지만 기존의 웨어러블 분석 방식은 주로 미리 정해진 통계나 고정된 지표에 의존한다. 이러한 방식은 시간에 따라 변화하는 신호의 흐름이나 사용자의 개인적 선호를 충분히 반영하지 못한다. 반대로 원시 데이터를 모두 대규모 언어 모델(LLM)에 직접 입력하려 하면, 데이터 양이 너무 많아 모델의 문맥 길이를 쉽게 초과한다.
LLM 에이전트는 이 문제에 대한 대안이 될 수 있다. 에이전트는 모든 데이터를 한꺼번에 읽는 대신, 도구를 이용해 필요한 데이터를 검색하고, 무엇을 분석할지 스스로 결정한 뒤, 결과를 자연어로 설명할 수 있다.
"에이전트는 건강 데이터에 도구를 통해 접근하고, 무엇을 분석할 가치가 있는지 결정하며, 발견한 내용을 자연어로 설명할 수 있다."
기존 연구는 크게 두 방향으로 진행되어 왔다. 임상용 다중 에이전트 시스템은 의사나 의료진을 주요 사용자로 삼으며, 환자의 지속적인 웨어러블 데이터보다는 진료 기록과 같은 사건 중심의 데이터를 다룬다. 개인 코칭 시스템은 운동 조언이나 일기 작성에 초점을 맞추지만, 실시간으로 계속 들어오는 생리학적 데이터 스트림을 장기적으로 관리하지는 않는다. 또한 일반적인 자체 호스팅 개인 비서는 대화나 예약 작업에는 적합하지만, 높은 빈도로 유입되는 생체 신호와 수개월에 걸친 개인 모델을 처리하도록 설계되지는 않았다.
이러한 공백을 메우기 위해 연구진은 HiMe(Health Intelligence Management Engine)를 제안했다. HiMe는 다양한 웨어러블 기기에서 들어오는 데이터를 사용자의 장비 안에서 처리하면서, 지속적인 건강 모니터링과 개인화된 인사이트 생성을 지원하는 오픈소스 플랫폼이다.
HiMe의 설계는 다음 세 가지 원칙에 기반한다.
-
데이터베이스를 핵심 구성요소로 취급한다.
웨어러블 신호뿐 아니라 사용자 프로필, 개인 선호, 에이전트의 기억, 보고서, 작업 일정 등을 하나의 데이터베이스 안에서 함께 관리한다. -
효과성과 효율성을 동시에 최적화한다.
무조건 가장 큰 모델을 사용하는 대신, 품질·비용·응답 속도 사이에서 적절한 균형을 찾는다. 값싼 통계적 필터는 항상 실행하고, 복잡한 LLM 분석은 의미 있는 변화가 감지될 때만 호출한다. -
실시간 처리와 장기 사용자 모델링을 결합한다.
순간적으로 발생한 이상 징후와 수개월 동안 이어지는 생활 패턴을 모두 파악할 수 있도록 한다.
연구진은 개인의 건강 데이터를 단순한 일회성 질문에 답하기 위한 자료가 아니라, 시간이 지나면서 사용자가 더 건강한 상태로 변화하도록 돕는 장기적인 자산으로 본다.
2. HiMe의 전체 구조와 데이터 흐름

HiMe는 에이전트 서버, 스마트폰 앱, 웨어러블 앱으로 구성된다. 사용자가 데이터베이스를 직접 조회하는 것이 아니라, 하나의 에이전트가 사용자와 데이터 저장소 사이에서 중간 역할을 한다.
웨어러블 기기는 심박수, 혈중 산소, 심박변이도, 수면, 운동 등의 신호를 실시간으로 측정한다. 측정값은 기기에서 일정한 묶음으로 임시 저장된 뒤 스마트폰을 거쳐 에이전트 서버로 전달된다. 서버의 데이터 어댑터는 기기마다 다른 데이터 형식을 통일하고, 같은 측정값이 중복 저장되지 않도록 정리한다.
정리된 데이터는 사용자별 통합 데이터베이스에 저장된다. 이 데이터베이스에는 다음과 같은 정보가 함께 들어간다.
- 웨어러블에서 수집한 생체 신호
- 사용자의 프로필과 목표
- 에이전트가 축적한 기억
- 생성된 건강 보고서
- 예약된 작업
- 실시간 모니터링 규칙
- 에이전트가 필요에 따라 만든 사용자 정의 테이블
사용자는 데이터베이스를 직접 조작하지 않는다. 대신 에이전트가 데이터를 읽고, 여러 단계에 걸쳐 분석하며, 결과를 보고서나 기억, 새로운 작업으로 저장한다. 공개 웨어러블 데이터셋을 동일한 어댑터를 통해 재생할 수도 있기 때문에, HiMe는 실제 서비스 플랫폼이면서 동시에 건강 에이전트 평가 환경으로도 활용될 수 있다.
HiMe의 에이전트 서버는 하나의 실행 루프에서 세 가지 종류의 사건을 처리한다.
- 사용자가 보낸 메시지
- 실시간 모니터링 규칙이 발생시킨 알림
- 미리 예약된 작업
이 사건이 발생하면 상호작용 에이전트가 깨어나고, 필요에 따라 분석 에이전트·관리 에이전트·계획 에이전트 같은 전문 하위 에이전트를 호출한다. 에이전트는 데이터베이스에서 필요한 정보를 읽고 결과를 다시 데이터베이스에 기록한 뒤, 사용자가 요청을 보낸 채널로 답변을 돌려준다.
특히 모든 보고서의 수치는 실제 데이터베이스 질의나 코드 실행 결과와 대조된다. 따라서 에이전트가 근거 없이 숫자를 만들어 내는지 확인할 수 있고, 사용자는 보고서에 포함된 근거 보기 기능을 통해 결과가 어떤 데이터에서 나왔는지 확인할 수 있다.
3. 네 개의 계층으로 구성된 설계

데이터 계층
HiMe는 에이전트가 보유한 정보를 하나의 통합 데이터베이스에 저장한다. 웨어러블 신호, 사용자 프로필, 장기 기억이 서로 분리된 저장소에 흩어지는 대신 함께 분석될 수 있다.
예를 들어 사용자가 건강 점검 보고서를 요청하면 에이전트는 다음과 같이 작업한다.
- 데이터베이스에서 사용자의 기존 기준선과 개인 목표를 읽는다.
- 필요한 분석 기술과 관련된 정보를 확인한다.
- 웨어러블 신호 테이블을 여러 단계에 걸쳐 질의한다.
- 분석 결과를 자연어 보고서로 작성한다.
- 보고서를 데이터베이스에 저장한다.
- 필요하면 다음 날 아침에 실행할 후속 작업을 추가한다.
각 에이전트에는 고유한 테이블 접근 권한이 부여되기 때문에, 모든 작업을 안전하게 제한할 수 있다. HiMe는 특정 건강 분석 흐름을 코드로 하나하나 고정하지 않는다. 기본적인 도구와 데이터베이스 구조만 제공하고, 에이전트가 상황에 맞게 필요한 테이블과 작업을 활용하도록 설계되어 있다.
이러한 구조 덕분에 새로운 기능을 추가할 때마다 별도의 에이전트를 만들 필요가 없다. 필요한 기능을 새로운 테이블이나 데이터 구조로 확장할 수 있다.
도구 계층
데이터베이스가 중심이 되기 때문에 도구 계층은 비교적 단순하다. 기본적으로 에이전트가 수행하는 일은 통합 데이터베이스를 읽고 쓰는 것이다. 여기에 코드 실행 도구가 추가되며, 답변 작성, 파일 수정, 대시보드 생성 등은 같은 추상화 위에서 확장될 수 있다.
코드 실행 도구는 Jupyter 노트북처럼 이전 호출에서 만들어진 상태를 유지한다. 따라서 에이전트는 매번 처음부터 코드를 다시 작성하지 않고, 앞선 분석 결과를 이어서 활용할 수 있다.
또한 외부로 전송되는 모든 메시지는 사실 검증기를 거친다. 검증기는 에이전트가 사용한 도구 기록을 확인하고, 답변에 포함된 수치가 실제 질의 결과와 일치하는지 검사한다. 검증 과정의 증거는 해시 형태로 보관되어, 나중에 결과를 추적할 수 있다.
에이전트 계층
사용자와 직접 대화하는 상호작용 에이전트가 중심에 있다. 이 에이전트는 필요할 때 다음과 같은 전문 하위 에이전트를 호출한다.
- 분석 에이전트: 웨어러블 데이터를 분석하고 건강 질문에 답한다.
- 관리 에이전트: 기억, 사용자 프로필, 반복 작업을 관리한다.
- 계획 에이전트: 사용자의 목표에 맞는 건강 계획과 모니터링 일정을 만든다.
프롬프트는 시스템 지시, 역할, 성격, 책임, 경험 등의 모듈로 나누어 조합된다. 이 방식은 여러 에이전트가 공통 구조를 재사용하게 하며, 프롬프트 앞부분을 안정적으로 유지해 모델의 KV 캐시를 효율적으로 활용하도록 돕는다.
HiMe는 15개 LLM API 제공자를 지원하지만, 개인정보 보호를 위해 연구진은 vLLM을 이용한 로컬 오픈소스 모델 실행을 권장한다.
상호작용 계층
사용자는 HiMe의 내장 채팅뿐 아니라 WeChat, Telegram과 같은 메시징 플랫폼을 통해 에이전트에 접근할 수 있다. 게이트웨이 레지스트리는 사용자가 메시지를 보낸 채널을 기억해 같은 채널로 답변을 돌려준다.
대화가 쌓이면 에이전트는 사용자 기억과 프로필을 업데이트하고, 사용자의 상태에 맞춰 능동적인 작업을 설정한다. 작업은 특정 시각에 실행되는 일정 기반 작업일 수도 있고, 특정 건강 사건이 발생했을 때 실행되는 이벤트 기반 작업일 수도 있다. 결과 알림은 스마트폰과 웨어러블로 전달된다.
HiMe에는 사용자의 상태를 시각적으로 보여 주는 픽셀 아트 고양이 디지털 트윈도 포함되어 있다. 고양이의 움직임과 표정은 실시간 건강 상태를 간단하고 친숙한 방식으로 표현한다. 🐈
4. 실시간 감지와 장기 모델링을 결합하는 방식
HiMe의 중요한 특징은 모든 측정값마다 비싼 LLM을 호출하지 않는다는 점이다. 웨어러블 데이터는 매우 자주 들어오기 때문에, 각 심박수 측정마다 복잡한 분석을 실행하면 비용과 지연 시간이 크게 증가한다.
대신 HiMe는 다음과 같은 두 단계 구조를 사용한다.
- 저비용 통계 트리거가 전체 스트림을 지속적으로 감시한다.
- 의미 있는 변화가 감지되면 고비용 LLM 분석을 호출한다.
예를 들어 심박수가 개인 기준선보다 비정상적으로 높거나 낮아지거나, 혈중 산소가 일정 수준 아래로 떨어지거나, 심박변이도가 급격히 낮아지는 경우 통계 트리거가 작동할 수 있다. 그때만 분석 에이전트가 깨어나 주변 시간대의 데이터와 과거 기록을 함께 살펴본다.
이 구조는 순간적인 이상 징후와 장기간에 걸친 추세를 동시에 다룬다. 값싼 구성요소는 데이터를 높은 해상도로 계속 감시하고, LLM은 중요한 사건이 발생했을 때만 개입해 해석과 설명을 수행한다.
연구진은 이러한 설계가 다음과 같은 장점을 준다고 설명한다.
"연속적인 생리학적 스트림을 개인화되고 감사 가능한 인사이트로 바꾸면서도, 데이터가 사용자의 하드웨어 밖으로 나가지 않게 한다."
또한 사용자의 장기 모델은 불투명한 벡터 데이터베이스가 아니라, 에이전트가 직접 수정할 수 있는 Markdown 기반의 사용자 모델로 관리된다. 사용자는 서버 패널에서 기억, 프로필, 작업, 보고서, 프롬프트와 도구를 직접 확인하고 수정할 수 있다.
5. 실제 사용자 경험과 시연 과정

HiMe의 사용 과정은 초기 설정부터 일상적인 건강 관리까지 이어진다. 먼저 설정 마법사가 LLM 백엔드, 시간대, 메시징 연동, 에이전트 서버를 구성한다. 이후 스마트폰에서 건강 데이터 접근 권한을 승인하고, 서버 연결과 동의 절차를 진행하며, 간단한 건강 목표 설문에 응답한다.
계획 에이전트는 사용자의 설문 답변과 이미 수집된 건강 데이터를 바탕으로 다음을 생성한다.
- 개인화된 모니터링 작업
- 정기적인 건강 분석 일정
- 초기 건강 계획
- 수면·활동·회복 등을 위한 보고서 생성 작업
일상적인 사용 중에는 디지털 트윈 고양이가 건강 상태를 요약해 보여 준다. 사용자는 필요할 때 채팅으로 즉시 분석을 요청할 수 있으며, 스마트폰 알림, 메시징 앱, 웨어러블 화면을 통해서도 에이전트와 상호작용할 수 있다.
에이전트가 생성한 보고서는 데이터베이스 질의에 기반한 근거를 함께 제공한다. 사용자는 고급 관리 탭에서 수집된 데이터, 에이전트 상태, 보고서, 예약 작업, 개인화 페이지를 확인할 수 있다. 에이전트 서버 패널에서는 모델, 실행 과정, 프롬프트, 기억, 기술, 도구, 생성 콘텐츠까지 자세히 통제할 수 있다.
따라서 HiMe는 에이전트가 자율적으로 건강 관리를 수행하도록 하면서도, 사용자가 그 작동 과정을 완전히 숨겨진 상태로 두지 않는다.
"사용자는 자율적인 건강 지원의 혜택을 받으면서도, 에이전트의 작동 방식에 대한 완전한 가시성과 통제권을 유지할 수 있다."
6. 평가 방법과 실험 구성
HiMe는 완성된 벤치마크라기보다 시연 시스템이지만, 데이터베이스의 최종 상태를 기준으로 에이전트의 결과를 평가할 수 있도록 설계되었다.
연구진은 공개 웨어러블 데이터셋에 포함된 기록을 재생하면서 에이전트가 실제로 작동하도록 했다. 이후 에이전트가 만든 최종 데이터베이스 상태를, 동일한 데이터로 독립적으로 계산한 정답 상태와 비교했다.
평가에는 다음 다섯 개의 데이터셋이 사용되었다.
- LifeSnaps
- PMData
- MMASH
- CovIdentify
- GLOBEM
각 데이터셋에서 무작위로 선정한 참가자들의 기록을 사용했으며, 데이터셋마다 별도의 데이터 어댑터를 거쳤다. 모두 22개의 LLM 백본을 비교했고, 이 중 19개는 로컬 모델이었다. 모델 규모는 1.5B부터 35B 매개변수까지 다양했으며, GPT-5-mini, DeepSeek-V4-flash, Gemini-3.5-flash 같은 호스팅 API 모델도 비교 대상으로 포함했다.
평가 항목은 역할별로 나누었다.
- 라우팅: 상호작용 에이전트가 필요한 하위 에이전트만 정확히 호출하는가
- 분석: 자연어 질문에 대해 독립적인 기준 질의와 일치하는 수치를 제시하는가
- 기억 관리: 사용자의 프로필과 능동 작업을 요청대로 수정하는가
- 계획 생성: 사용자의 건강 목표를 모두 반영한 일정과 보고서를 만드는가
- 환각: 실제 질의나 코드 실행 근거 없이 수치를 말하는 비율이 얼마나 되는가
각 역할은 독립적인 평가 기준을 가지므로, 실패가 발생했을 때 어느 역할이 문제를 일으켰는지 확인할 수 있다.
7. 역할별 에이전트 성능
평가 결과는 강력한 로컬 모델이 일부 호스팅형 모델과 비슷하거나 더 나은 성능을 낼 수 있음을 보여 주었다.
대표적으로 Qwen3.6-27B와 Qwen3.5-35B-A3B는 분석 점수에서 각각 0.91을 기록했다. 이는 DeepSeek-V4-flash의 0.85와 GPT-5-mini의 0.76보다 높았다. 다만 Gemini-3.5-flash는 0.94로 가장 높은 분석 점수를 보였다.
"강력한 로컬 백본은 분석 점수 0.91에 도달해 호스팅형 모델과 경쟁했으며, 환각도 발생시키지 않았다."
하지만 모델 크기가 커진다고 성능이 항상 선형적으로 좋아지는 것은 아니었다. 예를 들어 Qwen3-30B-A3B는 전체 매개변수는 30B이지만 실제 활성화되는 매개변수가 약 3B인 혼합 전문가 모델이다. 이 모델은 더 작은 Qwen3-8B보다 분석과 기억 관리에서 낮은 점수를 기록했다.
또한 역할별로 난이도 차이가 컸다. 라우팅은 강력한 모델에서 거의 포화되어 있었지만, 분석 능력은 모델에 따라 0.00부터 0.94까지 크게 달라졌다. 특히 1.5B급 소형 모델은 대부분의 역할에서 실패했고, 근거 없는 수치를 말하는 환각률도 0.47로 가장 높았다.
부록의 전체 평가에서는 Qwen3.5-9B가 비교적 저렴하면서도 분석 점수 0.87, 기억과 계획 점수 1.00을 기록해 실용적인 로컬 구성으로 소개되었다. 그러나 개별 작업에서 좋은 성능을 보이는 것과 여러 차례의 대화를 안정적으로 수행하는 것은 별개의 문제였다.
8. 여러 단계의 대화에서는 성능이 급격히 낮아짐
개별 역할의 성능만 보면 모델이 충분히 유능해 보일 수 있다. 그러나 실제 사용자는 한 번의 질문만 하지 않고, 여러 대화를 이어 가며 계획을 세우고, 이전 내용을 기억하고, 새로운 단위를 적용하거나 과거 기록을 다시 확인한다.
연구진은 이를 반영해 다음 다섯 단계로 구성된 복합 대화 평가를 수행했다.
- 수면과 활동을 포함한 주간 점검 계획을 만든다.
- 방금 설정한 계획을 기억한다.
- 가장 활동적인 날의 평균 심박수를 계산한다.
- 사용자의 지속적인 선호를 기억에 저장한다.
- 이전 선호를 반영하면서 단위를 바꾸고 역대 최고 심박수를 답한다.
개별 대화 단계의 평균 성능은 높았지만, 모든 단계를 완벽하게 통과하는 비율은 낮았다. 한 단계에서 발생한 작은 오류가 다음 단계로 누적되기 때문이다.
가장 높은 엄격 통과율은 Gemma-4-26B-A4B의 0.44와 Gemini-3.5-flash의 0.37에 불과했다. 많은 모델은 모든 단계를 성공적으로 이어 가는 비율이 0이었다.
"여러 역할을 한 세션 안에서 안정적으로 연결하는 능력은 온디바이스 에이전트 연구의 아직 해결되지 않은 핵심 과제다."
이는 단순히 질문에 정확히 답하는 능력과, 장기적인 개인 비서로서 맥락·기억·도구 사용을 일관되게 유지하는 능력이 다르다는 것을 보여 준다.
9. 역할 분리가 실제로 도움이 되는가
HiMe는 하나의 거대한 에이전트가 모든 일을 수행하도록 하지 않고, 라우팅·분석·기억·계획 등으로 역할을 나눈다. 연구진은 이러한 분해가 단순한 소프트웨어 구조상의 선택인지, 실제 성능에도 도움이 되는지 확인하기 위해 단일 에이전트 구조와 비교했다.
대부분의 모델에서 역할을 나눈 구조는 성능이 유지되거나 오히려 향상되었다. 특히 다음과 같은 개선이 관찰되었다.
- Qwen3-8B: 약 +0.65
- Qwen3-32B: 약 +0.23
13개 로컬 모델 중 대부분은 역할 분리로 큰 손해를 보지 않았다. 다만 Qwen3.6-27B와 Gemma-4-E4B는 단일 구조보다 성능이 낮아지는 예외를 보였다. 가장 작은 모델들은 두 구조 모두에서 제대로 작동하지 않았다.
역할 분리는 각 에이전트가 맡은 책임을 좁히고, 도구 호출을 단순화하며, 오류 원인을 역할별로 추적할 수 있게 한다. 실제 운영 환경에서는 하나의 긴 문맥 안에서 모든 역할을 수행하는 단일 에이전트보다, 책임이 분리된 구조가 더 유리할 가능성이 높다고 연구진은 설명한다.
10. 웨어러블 데이터를 건강 보고서로 해석하는 능력
수치를 검색하고 계산하는 것과, 그 수치가 사용자의 피로도·회복 상태·스트레스와 어떤 관계가 있는지 해석하는 것은 다른 문제다.
연구진은 에이전트에게 참가자의 여러 생체 신호 기록을 제공하고, 웨어러블 데이터만으로 개인화된 건강 보고서를 작성하게 했다. 그 결과를 참가자가 별도로 작성한 자기보고 내용과 비교해 피로, 준비 상태, 스트레스에 대한 해석을 평가했다.
이 과제에서 가장 높은 점수를 받은 모델도 46%에 그쳤다. 흥미롭게도 단일 질문의 분석 점수에서 0.94를 기록한 Gemini-3.5-flash는 데이터에서 주관적 상태를 해석하는 보고서 평가에서는 14.6%에 머물렀다. 분석 점수 0.85였던 nemotron-3-nano도 보고서 평가에서는 18.7%를 기록했다.
즉, 숫자를 정확히 찾아내는 능력이 곧 건강 상태를 올바르게 이해하고 설명하는 능력을 의미하지 않는다.
"주관적 상태를 서술하는 능력은 숫자를 검색하는 능력과 별개의 역량이다."
이 결과는 개인 건강 에이전트가 단순한 질의응답 시스템을 넘어 사용자의 실제 상태와 맥락을 해석하려면, 추가적인 연구와 평가 기준이 필요하다는 점을 보여 준다.

11. 실시간 트리거 방식의 효과
항상 작동하는 건강 에이전트는 지속적인 데이터 감시와 비용 절감을 동시에 달성해야 한다. HiMe는 모든 데이터에 대해 일정한 간격으로 LLM 분석을 실행하는 폴링 방식 대신, 에이전트가 작성한 통계적 트리거를 사용한다.
실험에서는 심박수 급등·급락, 지속적인 빈맥, 혈중 산소 저하, 낮은 심박변이도와 같은 이상 사건을 데이터에 삽입했다. 이후 다음 두 방식을 비교했다.
- 폴링 방식: 5분마다 동일한 다단계 분석을 실행
- 트리거 방식: 통계 조건이 충족될 때만 분석 실행
트리거 방식은 평균적으로 폴링 방식보다 더 많은 이상 사건을 찾아냈다. 특히 작은 모델에서는 정상적인 신호가 너무 많이 섞이면 고정된 일정에 따라 실행되는 분석이 중요한 사건을 놓치기 쉬웠기 때문에, 트리거 방식의 이점이 더 컸다.
큰 모델에서는 탐지율이 약간 낮아지는 대가가 있었지만, 토큰 사용량을 10분의 1 수준으로 줄이는 효과를 얻었다. 따라서 트리거 방식은 실시간 감시의 탐지 능력을 크게 훼손하지 않으면서, LLM 호출 비용을 줄이는 현실적인 방법으로 평가되었다.
12. 두 달간의 실제 사용자 연구

HiMe가 실제 사용자의 건강 관리에 도움이 되는지 확인하기 위해, 연구진은 기술 배경이 없는 참가자 9명을 대상으로 두 달간의 현장 연구를 진행했다. 참가자들은 자신의 기기에서 HiMe를 사용한 뒤, 사용성·능동성·개인화·정확성 등을 5점 척도로 평가했다.
전체 평가는 4.00점에서 4.67점 사이로 긍정적이었다. 가장 높은 점수는 다음과 같았다.
- 사용성: 4.67점
- 능동적 지원 경험: 4.56점
참가자들은 특히 수면과 회복에 관한 능동적인 보고서가 평소 지나치기 쉬웠던 건강 데이터를 다시 확인하게 해 주었다고 평가했다. HiMe의 가장 큰 장점으로는 기존 도구보다 능동성과 개인화가 향상되었다는 점이 꼽혔다.
반면 개인화된 계획의 적합성은 4.00점으로 가장 낮았다. 일부 참가자는 생활 패턴이 바뀌었을 때 예약된 건강 계획이 변화에 충분히 빠르게 적응하지 못한다고 느꼈다. 정확성이나 응답 속도가 크게 개선되었다는 평가는 상대적으로 적었다.
보고된 오류는 드물고 대부분 사소했지만, 연구 참가자 수가 적고 자발적으로 참여한 사람들로 구성되었다는 한계가 있다. 따라서 이 결과는 긍정적인 가능성을 보여 주지만, 더 크고 다양한 사용자 집단을 대상으로 한 장기 연구가 필요하다.
13. 부록 실험과 구현 세부사항
부록에서는 본문 실험을 확장하고 평가 절차를 구체적으로 설명한다.
전체 역할 평가
22개 모델에 대한 전체 평가에서는 최신 로컬 모델들이 호스팅 API 모델과의 격차를 상당히 줄인 것으로 나타났다. 그러나 단일 작업에서 높은 점수를 받은 모델이 장기 대화에서도 안정적인 것은 아니었다. 예를 들어 nemotron-3-nano는 분석 점수 0.85를 기록했지만, 여러 단계가 이어지는 복합 대화 점수는 0.02로 크게 떨어졌다.
역할 분해 실험
역할 분해 실험에서는 13개 로컬 모델을 단일 에이전트와 다중 역할 에이전트로 비교했다. 대부분의 모델은 역할을 나누어도 성능이 유지되었고, 몇몇 모델에서는 큰 폭의 향상이 나타났다. 반면 일부 강력한 모델에서는 역할 분리로 인해 성능이 떨어지는 예외도 확인되었다.
트리거 탐지 프로토콜
트리거 실험에서는 같은 에이전트를 폴링 방식과 트리거 방식으로 각각 실행했다. 에이전트는 사용자의 자연어 요구를 바탕으로 신호, 임계값, 관찰 시간, 재실행 제한 시간을 포함한 감지 규칙을 직접 만들었다. 이상 사건은 심박수 급등·저하, 지속적인 심박수 상승, 혈중 산소 86% 저하, 낮은 심박변이도 등을 포함했다.
분석이 이상 사건을 실제로 발견했는지는 고정된 LLM 평가자가 판정했으며, 근거 없이 문제를 제기한 경우는 잘못된 경보로 처리했다.
온디바이스 지연 시간
로컬 모델은 NVIDIA H200에서 vLLM과 bfloat16으로 실행해 지연 시간을 측정했다. 32B 모델은 초당 약 53토큰, 1.5B 모델은 약 536토큰을 생성했다. 혼합 전문가 모델은 전체 매개변수 수보다 실제 활성화되는 매개변수 수에 따라 속도가 결정되었으며, 30B급 혼합 전문가 모델이 dense 4B 모델과 비슷한 속도로 작동하기도 했다.
사용자 설문
참가자들은 HiMe를 처음에는 주로 수면 관리 도구로 사용했으며, 이후 운동과 스트레스 관리로 활용 범위를 넓혔다. HiMe를 사용하기 전에는 여러 앱에 건강 정보가 분산되어 있는 경우가 많았다. 참가자들은 기존 방식보다 능동성과 개인화가 좋아졌다고 평가했지만, 정확성·속도·사용성에서의 개선은 상대적으로 덜 강조했다.

14. 연구의 결론과 남은 과제
HiMe는 웨어러블 기기에서 계속 유입되는 건강 데이터를 사용자의 장비 안에서 처리하고, 이를 개인화된 장기 건강 인사이트로 바꾸는 자체 호스팅 플랫폼이다. 이 시스템은 통합 데이터베이스, 품질·비용·속도의 공동 최적화, 실시간 감지와 장기 모델링의 결합이라는 세 가지 원칙을 통해 설계되었다.
실험 결과, 충분히 강력한 로컬 모델은 일부 호스팅형 최신 모델과 경쟁할 수 있었다. 이는 개인정보를 외부 서버로 보내지 않고도 개인 건강 에이전트를 구축할 가능성이 커지고 있음을 의미한다. 또한 저비용 통계 트리거를 사용하면 지속적인 감시와 LLM 호출 비용 절감을 함께 달성할 수 있었다.
그러나 아직 해결해야 할 문제도 분명하다.
- 여러 차례 이어지는 대화에서 기억과 작업을 안정적으로 유지하는 능력
- 웨어러블 수치에서 피로·스트레스·회복 같은 주관적 상태를 해석하는 능력
- 사용자의 변화하는 생활 패턴에 맞춰 건강 계획을 빠르게 조정하는 능력
- 소형 온디바이스 모델의 낮은 정확도와 높은 환각률
- 더 많은 참가자와 장기간의 실제 사용을 통한 검증
연구진은 HiMe가 신뢰할 수 있고 개인화된 건강 에이전트를 연구하고 평가하기 위한 기반이 되기를 기대한다.
"강력한 로컬 모델은 이미 호스팅 API와 경쟁할 수 있지만, 다중 턴 신뢰성과 데이터에서 보고서로 이어지는 해석 능력은 여전히 열려 있는 과제다."
