에이전트가 건강 데이터를 다룬다면, 지루한 부분부터 처리하라

솔직히 말하자면: 내가 신뢰할 수 있는 첫 번째 건강 관련 에이전트 워크플로우는 AI 의사가 아니다.

그것은 Apple Watch의 6개월치 수면 데이터를 가져와 타임스탬프를 정리하고, 기록을 고정된 수면 다이어리 스키마에 매핑하며, 오류가 있는 행을 플래그 지정하고, 어떤 데이터도 임상 의사에게 전달되기 전에 인간 검토를 거치는 좁은 파이프라인이다.

듣기에는 재미없게 들릴 것이다.

좋다.

바로 그것이 내가 신뢰할 수 있는 첫 번째 버전인 이유다.

나는 r/openclaw에서 올라온 게시물을 읽다가 이 결론에 도달했다. 거기서 누군가가 자신의 AI 어시스턴트가 Apple Watch의 수면 데이터 몇 달 치를 자신이 다니는 수면 클리닉이 요청한 다이어리로 변환했고, 그 과정에서 데이터 관련 문제들이 매우 심각했다고 말하는 글이었다.

그 문장 안에 제품 전체가 담겨 있다.

'AI 헬스케어' 같은 것이 아니다.

'자율적인 웰니스(autonomous wellness)'도 아니다.

수면 의학을 이해한다고 가장하며 부드러운 UI를 갖춘 GPT-5 래퍼(wrapper)도 아니다.

단지 매우 실용적인 엔지니어링 문제일 뿐이다:

• 지저분한 내보내기 데이터 파싱(parse)
• 시간 경계 정규화(normalize time boundaries)
• 임상 의사 친화적인 형식에 맞추기
• 오류가 있는 행에서 명확하게 실패하기(fail loudly on bad rows)
• 인간의 승인을 요구하기

이것이야말로 실제 사용 사례다.

그리고 n8n, Make, Zapier, OpenClaw 또는 Python으로 자동화를 구축한다면 익숙하게 느껴져야 한다. 어려운 부분은 최종 프롬프트가 아니다. 어려운 부분은 지저분한 중간 과정이다.

어려운 부분은 추론(reasoning)이 아니라 ETL이다

대부분의 건강 에이전트 데모는 가장 중요한 부분을 건너뛴다.

그들은 세련된 요약본을 보여준다. Claude나 GPT-5가 침착하고 명료하게 무언가를 말하는 것을 보여준다. 대시보드를 보여준다.

나는 그것이 어려운 부분이 아니라고 생각한다.

어려운 부분은 ETL이다:

• 추출(extraction)
• 변환(transformation)
• 적재(loading)

수면 데이터의 경우, 이것은 다음과 같은 것들을 다루는 것을 의미한다:

• 자정(midnight)을 넘나드는 타임스탬프
• 시간대 정규화(timezone normalization)
• 낮잠 대 밤샘 수면
• 누락된 시작 또는 종료 시간
• 겹치는 간격(overlapping intervals)
• 기기가 기록하지 못한 공백 기간(gaps from the device not recording)
• 클리닉별 다이어리 형식

이 중 어느 하나라도 잘못되면, 마지막의 모델 요약은 도움이 되지 않는다. 오히려 적극적으로 오해를 불러일으킨다.

그렇기 때문에 나는 지루한 파이프라인이야말로 진정한 제품이라고 생각한다.

실제로 배포할 워크플로우

만약 제가 오늘 이것을 구축해야 한다면, 아키텍처를 매우 좁게 유지할 것입니다.

Apple Health 내보내기
  -> 수면 기록 구문 분석
  -> 스키마 유효성 검사
...

그게 전부입니다.

진단은 없습니다.
치료 제안도 없습니다.
“순환 리듬 장애가 있을 수도 있다” 같은 헛소리도 없습니다.

단지 검토 게이트(review gate)를 거치는 구조화된 변환 파이프라인만 있으면 됩니다.

실제로 배포할 워크플로우

코드나 자동화 빌더에서 어떻게 분해할 수 있는지 보여드리겠습니다.

1단계: 내보내기 데이터를 결정론적으로 구문 분석하기

피할 수 있다면 LLM에게 Apple Health 내보내기를 구문 분석하도록 요청하지 마세요.

먼저 결정론적인 코드를 사용하세요.

from datetime import datetime
import csv

...

이것은 지루한 코드입니다.

그게 요점입니다.

2단계: 일지 경계를 명시적으로 정규화하기

수면 데이터는 인간이 행(row) 단위가 아닌 밤 단위로 생각하기 때문에 까다롭습니다.

오후 11시 42분부터 오전 6시 18분까지의 수면 세그먼트는 하나의 수면 에피소드에 속하지만, 두 개의 달력 날짜에 걸쳐 있습니다.

규칙이 필요합니다.

예를 들어:

def diary_date(record):
    # 예시 규칙: 시작 시간이 오전 6시 이전인 경우를 제외하고는 
    # 수면을 시작된 날짜로 할당한다. 
...

다른 규칙을 선택할 수도 있습니다.

중요한 것은 그 규칙이 명시적이고, 테스트 가능하며, 검토자에게 보여야 한다는 것입니다.

3단계: 모델이 데이터를 보기 전에 유효성 검사하기

대부분의 “에이전트” 데모가 허술해지는 지점이 바로 여기입니다.

행이 중복되거나, 타임스탬프가 누락되었거나, 시간대 변환으로 인해 일지 날짜가 변경되었다면, GPT-5나 Claude 또는 다른 어떤 모델이 멋진 단락을 작성하기 전에 이를 표면화해야 합니다.

def validate_intervals(records):
    records = sorted(records, key=lambda r: r[

```json
{
  "diary_date": "2026-02-14",
  "sleep_start": "2026-02-14T23:42:00-08:00",
...

그다음 모델에게 아주 좁은 범위의 작업을 요청합니다:

제공된 필드만을 사용하여 쉬운 언어로 된 짧은 수면 일기 노트를 작성하세요.
진단을 추론하지 마세요.
의학적 조언을 추가하지 마세요.
...

이것은 훌륭한 LLM (Large Language Model) 작업입니다.

하지만 가공되지 않은 건강 데이터 내보내기(raw health exports)를 자유 형식으로 파싱(Freeform parsing)하는 것은 그렇지 않습니다.

n8n, Make, Zapier 또는 OpenClaw로 이를 구축하는 경우

어떤 스택(stack)을 사용하든 패턴은 동일합니다.

n8n 형태

Webhook / File Trigger
-> Code node: export 파싱
-> IF node: 검증 오류(validation errors)가 있는가?
...

Make 형태

Watch files
-> Parse JSON/XML/CSV
-> 검증 실패를 위한 Router
...

커스텀 Python 형태

python ingest.py --input apple_health_export.xml
python validate.py --input parsed_sleep.json
python normalize.py --input validated_sleep.json
...

스택 자체는 흥미로운 부분이 아닙니다.

경계 설계(boundary design)가 핵심입니다.

멀티 에이전트(multi-agent) 건강 워크플로우가 불안한 이유

저는 에이전트를 좋아합니다. 에이전트로 무언가를 만듭니다.

하지만 사람들은 여전히 멀티 에이전트 설정을 너무 이른 시점에 도입하려 한다고 생각합니다.

만약 당신의 워크플로우가 의료진이 마주하는 서류 작업에 관여한다면, 추가되는 에이전트 하나하나가 상태(state)가 어긋날 수 있는 또 다른 지점이 되고, 재시도(retries)가 배가되며, 출력을 감사(audit)하기 더 어렵게 만듭니다.

이러한 종류의 워크플로우에서 제가 원하는 것은 다음과 같습니다:

• 하나의 파서 (parser)
• 하나의 검증기 (validator)
• 하나의 포맷터 (formatter)
• 하나의 선택적 LLM 요약기 (summarizer)
• 하나의 인간 검토자 (human reviewer)

이것으로 충분합니다.

새벽 2시 7분의 수면 구간이 화요일에 속하는지 수요일에 속하는지를 두고 세 명의 에이전트가 논쟁해야 한다면, 당신의 아키텍처(architecture)는 이미 지나치게 복잡한 것입니다.

비용 함정은 빠르게 나타납니다

이 지점은 사람들이 인정하는 것보다 가격 책정이 더 중요한 부분이기도 합니다.

이와 같은 실제 워크플로우는 단 한 번만 실행되지 않습니다.

다음과 같은 과정을 거칩니다:

• 부분적인 내보내기 데이터로 테스트
• 스키마(schema) 수정 후 재실행
• 검증 실패 후 재시도
• 인간의 피드백 후 재생성
• 포맷 변경 시 다시 재생(replay)

이는 수많은 반복적인 호출(calls)이 발생함을 의미합니다.

워크플로우가 루프를 돌 때마다 토큰당 비용을 지불해야 한다면, 아키텍처는 당신이 신중하게 행동하는 것에 대해 벌을 주기 시작합니다.

이것이 바로 제가 프로덕션 자동화(production automations)에서 정액제 추론(flat-rate inference)이 과소평가되어 있다고 생각하는 이유 중 하나입니다.

Standard Compute의 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)를 사용하면, 백그라운드에서 요청을 라우팅하면서도 동일한 클라이언트 설정을 유지할 수 있으며, 토큰 불안(token anxiety)을 고려한 설계를 피할 수 있습니다.

이는 행동을 변화시킵니다.

팀들은 다음과 같은 작업을 더 기꺼이 수행하게 됩니다:

• 검증 단계(validation passes) 추가
• 결정론적 단계(deterministic steps)와 모델 단계(model steps) 분리
• 안전한 재시도(retry)
• 인간의 검토(human review)를 루프 내에 유지

이는 "재무팀이 지켜보고 있으니 호출을 줄여주세요"라는 말보다 더 나은 엔지니어링 측면의 동기부여가 됩니다.

중요한 아키텍처 규칙

건강 데이터 외에도 제가 사용할 규칙은 다음과 같습니다:

결정론적 전처리(deterministic preprocessing)를 먼저, 모델 요약(model summarization)을 나중에

이는 다음 항목들에 적용됩니다:

• 수면 일기
• 송장(invoices)
• 고객 지원 티켓(support tickets)
• 컴플라이언스 양식(compliance forms)
• CRM 정리
• 상류(upstream)의 잘못된 구조가 하류(downstream)에서 가짜 확신을 만들어내는 모든 워크플로우

더 안전한 패턴은 다음과 같습니다:

1. 파싱 (parse)
2. 검증 (validate)
3. 정규화 (normalize)
4. 구조화 (structure)
5. 요약 (summarize)
6. 검토 (review)

많은 팀이 여전히 그 반대로 하고 있습니다. 지저분한 입력을 모델에 쏟아붓고, 모델이 출력 과정에서 구조를 만들어내기를 기대합니다.

이는 워크플로우가 중요해지는 시점이 오기 전까지만 유효합니다.

이것을 충분히 안전하다고 부르기 위해 제가 요구할 사항들

몇 가지 타협할 수 없는 원칙들입니다.

1. 소스 유래 필드와 모델 생성 텍스트 분리

타임스탬프가 Apple Health에서 왔다면, 이를 소스 유래(source-derived)로 라벨링하십시오.

문장이 GPT-5나 Claude에서 왔다면, 이를 모델 생성(model-generated)으로 라벨링하십시오.

이 둘은 같은 것이 아닙니다.

2. 오류가 있는 행은 명확하게 실패 처리

시작 시간이 누락되었나요? 거부하십시오.

시간 간격이 겹치나요? 플래그(flag)를 표시하십시오.

타임존 정규화(Timezone normalization)로 인해 일기 날짜가 변경되었나요? 이를 표시하십시오.

잘못된 데이터를 조용히 매끄럽게 다듬는 것이 바로 신뢰가 파괴되는 방식입니다.

3. 인간의 검토는 실질적인 게이트(gate)여야 함

단순히 장식용 체크박스가 아닙니다.

데이터가 내보내지기 전에, 인간은 생성된 일기(diary)를 근거가 되는 기록(underlying records)과 대조하여 검토할 수 있어야 합니다.

4. 워크플로우(workflow)는 불확실성을 인정해야 함

웨어러블(wearable) 데이터는 무질서합니다.
클리닉(clinics)마다 원하는 형식이 다릅니다.
어떤 기록은 불완전할 것입니다.

훌륭한 워크플로우는 무언가 불확실할 때 "알 수 없음(unknown)"이라고 말할 수 있어야 합니다.

그것은 결함이 아니라 기능(feature)입니다.

기이한 부분: 범위가 좁을수록 더 똑똑하게 느껴진다

이 카테고리에 대해 생각하면 할수록, 최고의 "헬스 에이전트(health agent)"는 에이전트처럼 느껴지지 않는다는 생각이 듭니다.

그것은 마치 끝부분에 조심스럽게 울타리를 쳐둔 하나의 언어 모델(language model)을 갖춘, 절제된 컨베이어 벨트처럼 느껴집니다.

가짜 친절함(fake bedside manner)도 없습니다.
진단 연극(diagnosis theater)도 없습니다.
요약(summary)이 의학적 판단(medical judgment)과 같다고 가장하지도 않습니다.

그저 지저분한 데이터 문제들을 견뎌내고, 구조화된 결과물(structured artifact)을 생성하여, 인간에게 전달하는 지루한 파이프라인(pipeline)일 뿐입니다.

그것이 사소하게 들릴지도 모릅니다.

하지만 저는 그것이 정확히 적절한 규모라고 생각합니다.

그리고 솔직히 말해서, 이 교훈은 건강 데이터 외부에서도 잘 적용됩니다.

워크플로우가 민감할수록, 자동화(automation)는 더 적게 즉흥적으로 행동해야 합니다.