환자가 직접 짠 당뇨 AI — GlycemicGPT가 BYOAI 셀프호스트로 보여준 헬스케어의 새 답

핵심 요약 (TL;DR)

Type 1 당뇨인 Joshua Engelbrecht가 endocrinologist 공백 몇 개월을 못 견뎌 Dexcom G7·t:slim X2 BLE 직접 연결 + BYOAI(Claude·OpenAI·Ollama 로컬 자유 선택) 풀스택 GlycemicGPT를 GPL-3.0으로 출시했습니다. GitHub 96★, v0.7.2, 115 릴리스. #WeAreNotWaiting 계보에 합류한 환자 주도 헬스케어 AI의 가장 단단한 최신 사례입니다.

"내 CGM 데이터를 아무도 안 본다"

Joshua Engelbrecht의 Show HN 본문에 박힌 한 문장이 무겁습니다. "endocrinologist 사이 공백이 몇 달이었다. 누구도 내 CGM을 보지 않았다. 나는 glucose 그래프를 노려보며 내가 뭘 잘못하고 있는지 알아내려 했다." Type 1 당뇨인 본인이 의료 시스템의 공백을 직접 메우기로 한 시점이었던 거죠.

만든 건 단순한 추적 앱이 아닙니다. Dexcom G7 CGM + Tandem t:slim X2 인슐린 펌프 BLE 직접 연결(공식 SDK 경로인지 리버스인지는 원문에 명시 없음 — "BLE 직접 연결"로만 표현), AI 일일 브리프, 임상 당뇨 지식 RAG 챗봇, 보호자 에스컬레이션이 들어간 예측 알림, 10년 데이터 보관, Wear OS 동반 앱. 스택은 Next.js 15·React 19·FastAPI Python 3.12·PostgreSQL 16·Redis 7·Kotlin Jetpack Compose. 1인 풀스택 치고 코드량과 속도가 가파릅니다(96★, 115 릴리스, v0.7.2). Joshua 본인이 "Claude Code로 짰다"고 명시한 적은 없지만, 이 규모를 혼자 끌고 가는 게 LLM 없이는 어려운 시대라는 건 우리 모두 알죠.

BYOAI — 헬스케어 도메인의 진짜 자유

GlycemicGPT의 진짜 도장 자국은 BYOAI(Bring Your Own AI) 설계입니다. Claude, OpenAI, Ollama 로컬 추론, 기타 OpenAI 호환 엔드포인트를 사용자가 자유롭게 선택합니다. 의료 데이터를 외부 SaaS API로 무조건 보내야 한다면 "쓸 만한 AI 헬스 도구"는 처음부터 불가능합니다. 그래서 Joshua는 모델 선택권을 사용자에게 주고, 본인은 로컬 추론도 권장하는 방향으로 설계를 잡았습니다.

이건 단순한 기술 선택이 아니라 AI 헬스케어의 거버넌스 모델입니다. 어제까지 헬스케어 AI 스타트업의 약점은 "환자 데이터 처리에 대한 책임 분배가 모호"였죠. GlycemicGPT는 그 책임을 사용자에게 명시적으로 넘기는 대신, 모델 선택권으로 그 비용을 보상합니다. FDA 미승인·"펌프를 제어하지 않음"·"모니터링/분석 전용"이라는 디스클레이머가 README에 길게 박혀 있는 것도 같은 맥락인 거예요.

한국의 돌봄 개발자가 읽어야 할 5가지 신호

• 신호 1: 의료기기 BLE는 더 이상 닫힌 우주가 아닙니다. Dexcom G7·t:slim X2 같은 1티어 디바이스가 BLE로 직접 붙는다면, 한국에서도 부모의 혈압계·혈당계·웨어러블 데이터가 셀프호스트로 모일 수 있는 가능성이 열린 거죠.
• 신호 2: BYOAI는 SaaS 락인을 풀어주는 패턴입니다. 모델 사용권을 사용자에게 분리하면, 도구 자체는 오픈소스로 살아남고 비용은 사용자의 청구서로 흐릅니다. 이게 헬스케어처럼 데이터 민감도가 높은 도메인의 정답에 가깝습니다.
• 신호 3: GPL-3.0으로 푸는 게 안전 장치입니다. 환자 본인의 도구를 카피해 상용 SaaS로 닫는 시도를 GPL이 막아줍니다. 헬스케어 셀프호스트의 거버넌스 모델로 다시 의미가 생긴 라이선스인 거예요.
• 신호 4: "FDA 미승인 + 펌프 제어 안 함" 같은 디스클레이머가 자유를 줍니다. 책임을 명시하면 기능을 펼칠 수 있습니다. 의료 도구가 무서운 이유는 책임이 모호해서지, 기능 자체가 위험해서가 아니거든요.
• 신호 5: #WeAreNotWaiting의 한국 버전이 비어 있습니다. 환자 본인이 짠 도구가 환자 본인의 데이터로 검증되는 흐름. 한국에서는 아직 한 자리가 비어 있습니다.

환자가 자기 도구를 짤 수 있게 된다는 것

제품 사이트와 DEV.to 본인 포스트를 같이 읽으면 더 분명해집니다. Joshua는 자기 도구를 "daily use"라고 적었습니다. 직접 만든 도구를 매일 자기 몸에 쓰는 사람만이 만들 수 있는 디테일이 README의 알림 우선순위, 예측 윈도, caregiver 에스컬레이션 분기 곳곳에 박혀 있습니다.

FAQ

Q. 한국에서 비슷한 시도를 해도 의료기기법상 문제가 없을까요?
A. "모니터링/분석 전용·치료기기 제어 없음" 범주는 일반적으로 의료기기 인증 대상이 아닙니다. 다만 광고/홍보에서 "치료" 표현을 쓰는 순간 의료기기 광고법으로 끌려갈 수 있으니, 디스클레이머는 한국어 버전에서도 동일한 무게로 박아두는 게 안전합니다.

Q. BYOAI가 정말 SaaS 모델보다 안전한가요?
A. "안전"의 정의에 따라 다릅니다. 데이터가 외부 API로 안 나가는 시나리오(Ollama 로컬)는 분명히 더 안전합니다. 다만 모델 선택권이 사용자에게 있다는 건 "사용자가 그 선택의 책임도 진다"는 뜻이라, UI에서 그 트레이드오프를 충분히 설명해야 합니다.

Q. 1인 풀스택을 따라하려면 어떤 스택부터?
A. GlycemicGPT처럼 Next.js + FastAPI + PostgreSQL + Redis가 클래식한 조합입니다. BLE 같은 디바이스 직결이 빠지면 백엔드 + 모바일은 훨씬 가벼워집니다. 가장 큰 변수는 모델이 아니라 도메인 지식 RAG의 정확도예요. 헬스케어라면 임상 가이드라인 데이터셋 수집부터가 진짜 작업입니다.

환자가 자기 도구를 짤 수 있는 시대 — GlycemicGPT는 헬스케어 바이브코딩의 첫 단단한 증거입니다.