6.1.1 목적

Phase 3는 연속적 감정 분석을 위한 실시간 스트리밍 프로토콜을 정의합니다. 다음과 같은 응용에 필수입니다.

• 화상 회의·통화 중 감정 모니터링
• 운전자 졸음 탐지
• 게임·VR 몰입 경험
• 정신건강 상담 세션 모니터링
• 고객 서비스 감성 추적
• 학습자 참여도 실시간 추적

실시간 처리는 비실시간 처리(Phase 2 REST API)와 본질적으로 다른 트레이드오프를 가집니다. 비실시간 처리에서는 한 번의 요청·응답 주기가 분리되어 있어 재시도·로깅·감사가 단순한 반면, 실시간 처리에서는 연속적 데이터 흐름의 안정성·지연시간·재연결 전략이 핵심 품질 지표가 됩니다. 한국 통신 환경에서는 5G 셀 핸드오버·신호 음영·차량 이동성에서 발생하는 일시적 단절을 우아하게 처리하는 능력이 특히 중요합니다. 한국 도심 환경에서는 5G 핸드오버가 평균 1~3분에 한 번 발생하며, 핸드오버 시점의 일시적 지연이 50~150 ms 정도이므로 안전 임계 응용은 이러한 지연을 자연스럽게 흡수하는 버퍼링 전략이 필요합니다.

실시간 응용의 또 다른 중요한 차원은 데이터 보안입니다. 비실시간 처리에서는 한 번의 요청 본문에 동의·메타데이터·페이로드가 함께 포함되지만, 실시간 처리에서는 연결 시작 시 한 번만 인증·동의를 처리하고 이후 수많은 프레임이 같은 연결을 통해 흐릅니다. 이러한 패턴은 효율적이지만, 동의가 도중에 철회된 경우 즉시 처리를 중단할 수 있는 메커니즘이 필요합니다. WIA 표준은 클라이언트가 언제든 "stop" 메시지를 보내 처리를 중단할 수 있도록 정의하며, 서버는 즉시 처리를 멈추고 이미 받은 프레임도 폐기합니다.

비실시간 처리는 한 번의 호출에 대한 결과가 명확하므로 사용자에게 결과를 직관적으로 표시할 수 있지만, 실시간 처리는 연속적 결과를 어떻게 사용자에게 전달할 것인가라는 UI 디자인의 도전을 동반합니다. 표시 방식은 실시간 게이지·이모지 변화·색상 그라데이션·소리 알림 등 다양하며, 응용의 사용 사례에 맞춰 설계해야 합니다. 사용자 연구를 통해 표시 방식의 효과를 검증하는 것이 권장되며, 한국 사용자는 일반적으로 색상 변화보다 명시적 텍스트 라벨을 선호한다는 결과가 NIA 「감정 AI 사용자 인식 조사」(2024)에서 보고된 바 있습니다. 또한 한국 사용자는 시각·청각 표시가 동시에 제공될 때 더 직관적으로 받아들이는 경향이 있어, 표시 채널 다중화가 권장됩니다.

6.1.2 프로토콜 옵션

WebSocket은 IETF RFC 6455에서 정의된 양방향 통신 프로토콜로 WIA Phase 3의 1차 권장 프로토콜입니다. gRPC는 마이크로서비스 환경에서 서버 간 통신에 적합하며, Protocol Buffers를 사용하여 직렬화 비용을 절감합니다. MQTT는 자동차·IoT 기기에서 저대역폭 환경에 적합하며, Server-Sent Events는 단방향 스트리밍이 충분한 단순한 응용에 사용됩니다.

프로토콜 선택의 의사결정 기준은 (1) 양방향성 필요 여부, (2) 대역폭 제약, (3) 서버 인프라, (4) 클라이언트 환경(브라우저·모바일·임베디드)의 네 가지입니다. 일반적인 웹·모바일 응용은 WebSocket이 사실상 단일 답이며, 서버 간 마이크로서비스 통신은 gRPC가 우수합니다. 차량용 인캐빈 모니터링은 차량 내 ECU와 클라우드 사이의 통신이 핵심이므로 MQTT의 저대역폭·연결 지속성 강점이 중요합니다.

한국 사물인터넷 환경에서 가장 널리 사용되는 MQTT 브로커는 EMQX·Mosquitto·HiveMQ이며, 각 브로커는 WIA Phase 3 메시지 형식과 호환됩니다. 주요 한국 통신사의 IoT 플랫폼, 차량용·헬스케어용 IoT 응용에서 자연스럽게 결합됩니다. WIA Phase 3는 MQTT QoS 1(at-least-once delivery) 또는 QoS 2(exactly-once delivery)를 권장하며, 메시지 손실이 안전에 영향을 주는 응용에서는 QoS 2가 의무입니다.

6.2.1 연결

엔드포인트: wss://stream.wiastandards.com/emotion-ai/v1/stream

연결 요청:
GET /emotion-ai/v1/stream HTTP/1.1
Host: stream.wiastandards.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
X-WIA-API-Key: your_api_key

연결 응답:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

WebSocket 핸드셰이크는 표준 HTTP 1.1 업그레이드 메커니즘을 사용하므로 기존 HTTP 인프라(로드 밸런서·방화벽·프록시)와 호환됩니다. 한국 사용자는 한국 리전 엔드포인트(stream-kr.wiastandards.com)를 사용하여 평균 50~80 ms의 지연 절감을 얻을 수 있습니다. 엔드포인트의 SSL 인증서는 한국 인증기관(예: 한국정보인증)의 인증서가 함께 신뢰 체인에 포함되어 있어, 한국 환경에서의 인증서 검증 문제가 발생하지 않습니다. 별도 루트 CA 신뢰 설정이 필요하지 않습니다.

일부 기업 방화벽은 비표준 포트의 WebSocket을 차단하므로, WIA 표준은 443 포트(HTTPS와 동일)를 통해 wss:// 연결을 제공합니다. 이는 대부분의 기업 환경에서 추가 방화벽 설정 없이도 작동함을 의미합니다. 한국 공공기관·금융기관 환경에서는 행정안전부 「전자정부 통신 보안 가이드」가 정한 포트·프로토콜만 허용되는 경우가 있으므로, 도입 전 IT 부서와 사전 협의가 필요합니다.

WebSocket 연결은 평상시 길게 유지되므로 ping/pong 메시지로 연결 상태를 주기적으로 확인하는 것이 권장됩니다. 표준은 30초마다 ping을 보내고 30초 이내에 pong이 오지 않으면 연결을 끊는 기본 동작을 정의합니다. 일부 NAT·방화벽은 idle 연결을 60초 후 자동 종료하므로, 30초 ping 간격은 이러한 환경에서도 안정성을 유지합니다.

6.2.2 메시지 유형

6.2.3 설정 메시지

{
    "type": "config",
    "stream_id": "stream_abc123",
    "modalities": ["facial", "voice"],

    "facial": {
        "frame_rate": 30,
        "resolution": "720p",
        "encoding": "jpeg",
        "return_action_units": true
    },

    "voice": {
        "sample_rate": 16000,
        "encoding": "LINEAR16",
        "language": "ko-KR"
    },

    "output": {
        "rate": "per_frame",
        "include_dimensions": true,
        "include_raw_scores": false
    }
}

6.2.4 프레임 메시지 (바이너리)

바이너리 프레임 형식:
┌─────────────────────────────────────────────┐
│ 헤더 (16바이트)                              │
│   - Magic: 0x57494145 ("WIAE")              │
│   - Version: 1                              │
│   - Modality: 1=facial, 2=voice, 3=both     │
│   - Timestamp: 8바이트 (epoch 이후 ms)      │
│   - Length: 4바이트                         │
├─────────────────────────────────────────────┤
│ 페이로드 (가변 길이)                        │
│   - JPEG 이미지 데이터 또는 PCM 오디오      │
└─────────────────────────────────────────────┘

바이너리 프레임은 JSON 텍스트 메시지보다 약 3배 적은 대역폭을 사용하며, 실시간 응용의 처리량을 크게 높입니다. 30 fps 표정 분석에서 한 시간 스트리밍 시 JSON 메시지로 약 700 MB가 필요하지만, 바이너리 프레임으로는 230 MB로 압축됩니다. 모바일 환경의 데이터 요금 비용·배터리 소모·응답성을 모두 고려하면 바이너리 프레임이 사실상 단일 답입니다. 표준 SDK는 바이너리 프레임의 직렬화·역직렬화를 자동 처리하므로 사용자는 일반 이미지 객체나 PCM 버퍼를 그대로 전달할 수 있습니다.

바이너리 헤더 16바이트는 다음과 같이 구성됩니다. Magic 4바이트(0x57494145, "WIAE")는 프레임 검증을 위한 시그니처입니다. 잘못된 시그니처를 가진 프레임은 즉시 거부되며, 이는 우연한 패킷 손상이나 의도적 공격을 빠르게 식별하기 위한 안전 장치입니다. Version 1바이트는 프레임 형식 버전을 표시하며, 향후 형식 변경 시 이전 버전과의 호환을 위해 사용됩니다. Modality 1바이트는 페이로드의 종류를 표시하며, 1은 표정(JPEG), 2는 음성(PCM), 3은 둘 다를 의미합니다.

Timestamp 8바이트는 epoch 이후 밀리초 단위 정수이며, 프레임 캡처 시점을 정확히 표시합니다. 이는 후속 분석에서 프레임 순서·간격·동기화를 추적하는 데 사용되며, 멀티모달 융합 시 표정과 음성의 시간 동기화에 핵심 정보가 됩니다. Length 4바이트는 페이로드 길이(바이트)이며, 메시지 경계 식별에 사용됩니다.

페이로드는 표정 모달리티의 경우 JPEG 이미지(권장 품질 75~85), 음성 모달리티의 경우 16비트 PCM(샘플률 16 kHz 또는 44.1 kHz), 멀티모달의 경우 두 페이로드를 연속 배치한 형태입니다. JPEG 압축은 대역폭과 정확도의 트레이드오프이며, 품질 75는 일반 응용에 충분하지만 미세표정 탐지 같은 정밀 분석에서는 품질 90 이상이 권장됩니다. WebP 형식도 부속서에서 정의되어 있어 30~40 % 추가 대역폭 절감이 가능하지만, 일부 임베디드 환경에서는 디코더가 지원되지 않을 수 있어 호환성 검토가 필요합니다.

6.2.5 결과 메시지

{
    "type": "result",
    "stream_id": "stream_abc123",
    "frame_number": 1542,
    "timestamp": "2026-05-01T10:30:15.123Z",
    "latency_ms": 42,

    "emotions": {
        "primary": { "label": "happiness", "confidence": 0.85 },
        "change_detected": false
    },

    "dimensions": {
        "valence": 0.72,
        "arousal": 0.48
    },

    "action_units": [
        { "au": "AU6", "intensity": 0.78 },
        { "au": "AU12", "intensity": 0.82 }
    ],

    "face": {
        "detected": true,
        "tracking_id": "face_001",
        "bbox": { "x": 120, "y": 80, "width": 200, "height": 250 }
    }
}

6.3.1 프레임률 요구사항

6.3.2 지연시간 목표

한국 5G SA(독립모드) 환경에서의 실측 지연시간은 평균 65~80 ms로, 위 목표를 충실히 달성합니다. 5G NSA 환경에서는 평균 90~120 ms이며, LTE 환경에서는 150~200 ms가 일반적입니다. WiFi 환경에서는 사무실의 안정된 네트워크에서 30~50 ms, 가정 환경에서 40~60 ms가 측정됩니다. 차량 환경의 경우 셀 핸드오버 시점에 일시적으로 200 ms 이상이 측정될 수 있으므로, 안전 임계 응용에서는 차량 내 엣지 처리(현대모비스 인캐빈 모니터링 사례)를 결합하는 것이 권장됩니다.

지연시간 측정은 단순 평균값만으로는 충분하지 않으며, 95퍼센타일·99퍼센타일 같은 분포 지표를 함께 보아야 합니다. 평균 80 ms이지만 95퍼센타일이 200 ms인 환경은 평균 100 ms이지만 95퍼센타일이 130 ms인 환경보다 안전 임계 응용에 부적합합니다. WIA 표준의 적합성 시험은 평균뿐 아니라 95퍼센타일·99퍼센타일을 모두 측정하여 보고하도록 의무화합니다.

네트워크 전송 지연시간을 줄이기 위한 기법으로는 (1) 클라이언트와 서버를 동일 리전에 배치, (2) HTTP/2 또는 HTTP/3를 사용하여 다중화 연결 활용, (3) WebSocket의 permessage-deflate 압축 비활성화(작은 메시지에는 오히려 지연 증가), (4) TCP_NODELAY 활성화로 Nagle 알고리즘 우회의 네 가지가 있습니다. 표준 SDK는 이러한 최적화를 기본으로 적용합니다.

6.3.3 출력 속도 모드

"per_frame":
  - 모든 입력 프레임에 대한 결과
  - 최대 대역폭, 최소 지연시간
  - 게임·VR에 적합

"per_second":
  - 1초마다 집계 결과
  - 낮은 대역폭
  - 분석·모니터링에 적합

"on_change":
  - 감정 변화 시에만 결과
  - 최소 대역폭
  - 이벤트 기반 응용에 적합

"threshold":
  - 신뢰도가 임계값을 초과할 때 결과
  - 민감도 설정 가능
  - 경보 시스템에 적합

6.4.1 감정 이벤트

{
    "type": "event",
    "event_type": "emotion_change",
    "stream_id": "stream_abc123",
    "timestamp": "2026-05-01T10:30:15.123Z",

    "previous_emotion": {
        "label": "neutral",
        "confidence": 0.75
    },

    "current_emotion": {
        "label": "happiness",
        "confidence": 0.82
    },

    "transition_duration_ms": 450,
    "trigger": "gradual"
}

6.4.2 이벤트 유형

이벤트 기반 스트리밍은 per_frame 모드의 데이터 양을 크게 줄이면서도 의미 있는 변화 시점만 사용자에게 전달합니다. 콜센터·운전자 모니터링·헬스케어 환경에서 특히 유용하며, micro_expression 이벤트는 임상 진단·법의학 분석에서만 사용 사례가 명확합니다.

이벤트의 임계값은 사용 사례별로 조정 가능합니다. 운전자 모니터링에서는 졸음 신호의 임계값을 매우 낮게 설정하여 작은 신호도 놓치지 않도록 하고, 헬스케어에서는 우울 신호의 누적이 일정 수준에 도달했을 때만 트리거하여 거짓 양성을 줄입니다. 임계값 조정은 config 메시지의 events.thresholds 객체로 설정하며, 권고 기본값은 표준 부속서 H에서 사용 사례별로 제공됩니다.

이벤트 기반 스트리밍의 또 다른 장점은 클라이언트 측 처리 부담이 작다는 점입니다. per_frame 모드는 모든 프레임의 결과를 받아 처리해야 하지만, 이벤트 기반 모드는 의미 있는 변화 시점에만 처리가 필요하므로 모바일·임베디드 환경에서 자원을 절감할 수 있습니다. 차량 인캐빈 모니터링에서 차량의 ECU 자원을 효율적으로 사용하기 위해 이벤트 기반 모드가 권장됩니다.

한 응용에서 per_frame과 이벤트 기반을 혼합 사용하는 패턴도 가능합니다. 예를 들어 평상시에는 per_second 모드로 낮은 부하를 유지하다가, high_arousal 이벤트가 발생하면 일시적으로 per_frame 모드로 전환하여 정밀한 분석을 수행하고, 이벤트가 종료되면 다시 per_second로 돌아가는 적응형 패턴이 있습니다. 표준 SDK는 이러한 모드 전환을 자동으로 처리하는 어댑티브 모드를 기본 구현으로 제공합니다. 어댑티브 모드는 평균 대역폭 비용을 60~80 % 절감하면서도 의미 있는 변화 시점에서는 정밀한 분석을 보장하므로, 모바일·차량 환경에서 특히 권장됩니다.

6.5.1 전송 보안

• TLS 1.3. 모든 연결에 의무
• 인증서 고정(Certificate Pinning). 모바일 앱에 권장
• WSS만 허용. 비암호화 WebSocket 금지
• 한국 환경. 「전자서명법」 인정 인증서 사용 권장

6.5.2 인증

API 키 (헤더):
X-WIA-API-Key: EXAMPLE_API_KEY_REPLACE_ME

JWT 토큰 (쿼리 또는 헤더):
wss://stream.wiastandards.com/v1/stream?token=eyJhbG...

토큰 갱신:
{
    "type": "auth_refresh",
    "token": "new_jwt_token"
}

6.5.3 프라이버시 보호

• 종단 간 암호화. 민감 응용에 선택적 적용
• 저장 없음. 프레임은 처리 후 즉시 폐기 — 기본 동작
• 익명화. subject_id는 가명처리되어야 함
• 동의 신호. config에 동의 토큰 포함
• 한국 환경. 「개인정보 보호법」 §15·17·23 동의 절차 준수

6.6.1 오류 메시지

{
    "type": "error",
    "code": "FACE_NOT_DETECTED",
    "message": "프레임 1543에서 얼굴을 탐지하지 못했습니다",
    "frame_number": 1543,
    "recoverable": true
}

6.6.2 오류 코드

6.6.3 재연결 전략

지수 백오프:
  시도 1: 1초 대기
  시도 2: 2초 대기
  시도 3: 4초 대기
  시도 4: 8초 대기
  시도 5: 16초 대기
  최대: 60초

스트림 재개:
{
    "type": "resume",
    "stream_id": "stream_abc123",
    "last_frame_number": 1542
}

재연결 전략은 한국 통신 환경의 5G 핸드오버·신호 음영을 자연스럽게 처리합니다. 표준 SDK는 자동 재연결과 마지막 프레임 번호 추적을 기본 기능으로 제공하므로 사용자가 직접 구현할 필요는 없습니다. 자동 재연결의 기본 정책은 5회 시도이며, 5회 연속 실패 시 사용자에게 오류를 알리고 응용이 자체 복구 절차를 수행하도록 위임합니다. 안전 임계 응용에서는 재연결 시도 중 대체 데이터 경로(예: LTE fallback)를 활용하여 단절 시간을 최소화하는 것이 권장됩니다.

스트림 재개 메시지의 last_frame_number는 클라이언트가 마지막으로 수신한 결과 메시지의 frame_number를 기록한 값입니다. 서버는 이 값 이후의 결과부터 다시 전송하며, 동일 프레임의 중복 분석은 자동으로 건너뜁니다. 이러한 멱등성 보장은 일시적 단절 후에도 데이터의 일관성을 유지하는 데 핵심이며, 한국 통신 환경의 빈번한 일시 단절을 자연스럽게 처리합니다.

지수 백오프의 매개변수는 응용 사례에 따라 조정 가능합니다. 매우 짧은 단절(수 초)이 빈번한 환경에서는 초기 지연을 200 ms로 더 짧게 설정하고, 장기간 단절(수 분)이 가능한 환경에서는 초기 지연을 5초로 더 길게 설정합니다. 지터(±25 %) 추가는 모든 환경에서 권장되며, 다수의 클라이언트가 동시에 재연결을 시도하는 썬더링 허드 문제를 방지합니다.

6.7.1 세션 생애주기

1. 연결 (WebSocket 핸드셰이크)
2. 설정 (config 메시지 전송)
3. 스트림 (프레임 전송, 결과 수신)
4. 일시정지 (선택)
5. 재개 (선택)
6. 종료 (정상 연결 해제)

세션 한도:
  - 최대 지속 시간: 4시간
  - 최대 유휴 시간: 5분
  - 최대 프레임 수: 1,000,000

6.7.2 세션 요약

세션 종료 시 수신:

{
    "type": "session_summary",
    "stream_id": "stream_abc123",
    "duration_ms": 3600000,
    "frames_processed": 108000,

    "emotion_distribution": {
        "happiness": 0.45,
        "neutral": 0.35,
        "sadness": 0.12,
        "other": 0.08
    },

    "average_dimensions": {
        "valence": 0.42,
        "arousal": 0.38
    },

    "events": {
        "emotion_changes": 47,
        "high_arousal_moments": 12
    }
}