제5장. Phase 2 — API 인터페이스

홍익인간(弘益人間)

"널리 인간을 이롭게 하라" — 단군신화 건국 이념, 한국 헌법 전문에 명시된 가치

잘 설계된 API는 개발자가 기반 구현에 관계없이 감정 인식을 자신의 응용에 손쉽게 통합하도록 합니다. 표준화된 인터페이스는 벤더 고착을 막고 개발 비용을 절감하며 사용자 신뢰를 증진시킵니다. 본 장은 RESTful 엔드포인트의 인증, 요청·응답 형식, 모달리티별 호출 방식, 오류 처리, 호출 제한율을 한국 클라우드 보안 인증(CSAP)·KISA-PIMS 환경과 정합화하여 다룹니다.

5.1 API 설계 원칙

5.1.1 핵심 원칙

표 5-1. WIA Phase 2 API 5대 설계 원칙
원칙구현 방식
RESTful표준 HTTP 메서드, 자원 기반 URL
JSON모든 요청·응답이 JSON 형식
버전 관리URL 경로에 API 버전 표기(/v1/)
인증API 키 또는 OAuth 2.0
호출 제한율응답 헤더로 명확한 제한 제공

5대 원칙은 IETF·W3C·OWASP의 모범 사례를 반영하며, 한국 환경에서는 CSAP(클라우드 보안 인증)·ISMS-P 인증 시 추가 보안 요건이 적용됩니다. 특히 모든 요청은 TLS 1.2 이상으로 암호화되어야 하며, TLS 1.3을 권장합니다. 카카오엔터프라이즈·네이버클라우드·NHN클라우드 같은 한국 클라우드 사업자에 배치된 시스템은 CSAP 보안 요건을 자동으로 일부 충족합니다.

RESTful 설계는 자원(resource)을 URL로 표현하고 HTTP 메서드(GET, POST, PUT, DELETE)로 동작을 표현하는 원칙입니다. WIA Phase 2 API는 분석 작업이 자원(resource)이라기보다 동사적 호출이므로 POST 메서드를 주로 사용하며, 결과 조회·취소 같은 자원적 작업에 한해 GET·DELETE를 사용합니다. 이러한 혼합 패턴은 OpenAPI 3.0 사양에서 흔히 사용되며, FastAPI·Spring Boot·Express 같은 주요 웹 프레임워크에서 자연스럽게 구현됩니다.

버전 관리는 URL 경로에 /v1/·/v2/ 같은 메이저 버전을 명시하는 방식을 채택합니다. 마이너 변경은 후방 호환성을 유지하므로 URL 변경 없이 적용되며, 메이저 변경은 새로운 URL로 발행되어 기존 호출자에게 영향을 주지 않습니다. v1과 v2가 병행 운영되는 기간은 최소 12개월이며, 이는 사용자가 마이그레이션할 충분한 시간을 보장하기 위함입니다.

5.1.2 기본 URL

그림 5-1. 환경별 기본 URL — 운영·스테이징
운영:    https://api.wiastandards.com/emotion-ai/v1
스테이징: https://api-staging.wiastandards.com/emotion-ai/v1

한국 사용자에게는 별도의 한국 리전 엔드포인트(api-kr.wiastandards.com)가 제공되며, 데이터 거주(data residency) 요구사항이 있는 의료·금융·공공 응용에서는 이 엔드포인트 사용이 권장됩니다. 한국 리전 엔드포인트 사용 시 응답 헤더의 X-WIA-Region 값이 "KR"로 표기되며, 사용자는 이 헤더를 감사 로그에 기록하여 데이터 처리 위치를 입증할 수 있습니다.

한국 리전 엔드포인트는 KISA-PIMS 인증의 데이터 거주 요건을 자동으로 충족하므로, 한국 공공기관·의료기관·금융기관에서 별도 절차 없이 사용 가능합니다. 미국·EU·아시아 다른 권역의 엔드포인트와 비교하면 한국 리전은 추가 호출 비용이 발생하지 않으며, 글로벌 라우팅 비용을 절감하기 위해 한국 사용자가 가장 가까운 리전을 선택하는 것이 권장됩니다. 전세계 5개 리전(KR·US·EU·SG·BR)이 운영되며, 각 리전 간 평균 지연시간은 표준 모니터링 페이지(status.wiastandards.com)에서 실시간으로 확인할 수 있습니다.

5.2 인증

5.2.1 API 키 인증

그림 5-2. API 키 인증 — curl 예시
헤더: X-WIA-API-Key: your_api_key_here

예시 요청:
curl -X POST https://api.wiastandards.com/emotion-ai/v1/analyze/face \
  -H "X-WIA-API-Key: EXAMPLE_API_KEY_REPLACE_ME" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "https://example.com/face.jpg"}'

API 키는 HTTPS 채널을 통해서만 전송되며, 헤더에 포함시키는 것이 표준입니다. 쿼리 문자열에 API 키를 넣는 일은 금지되며, 이는 키가 서버 로그·브라우저 히스토리·중간 프록시에 노출될 위험 때문입니다. 키 회전(rotation)은 분기 단위로 자동 수행되며, 사용자는 키 회전 시점 30일 전 알림을 받습니다. 한국 환경에서는 KISA-PIMS 인증 시 키 관리 절차의 문서화가 의무이며, WIA는 키 관리 표준 절차서를 한국어로 제공합니다.

API 키는 사용자별로 발급되며, 한 사용자가 여러 키를 동시에 보유할 수 있습니다. 일반적으로 운영 환경 키 1개와 개발·시험 환경 키 1개를 분리하여 사용하는 패턴이 권장되며, 운영 키는 더 엄격한 접근 통제(IP 화이트리스트, 호출 시간대 제한)를 적용합니다. 키 누출 시 즉시 폐기 절차가 가능하며, 폐기 후 새 키 발급은 즉시 이루어집니다. 키 누출 사고 발생 시 24시간 이내에 KISA에 신고할 의무가 「개인정보 보호법 시행령」 제40조에 명시되어 있습니다.

5.2.2 OAuth 2.0 (선택)

그림 5-3. OAuth 2.0 인증 — 토큰 엔드포인트와 스코프
헤더: Authorization: Bearer <access_token>

토큰 엔드포인트: POST /oauth/token
스코프:
  - emotion:read    - 감정 분석 결과 읽기
  - emotion:analyze - 분석 콘텐츠 제출
  - emotion:stream  - 실시간 스트리밍 접근

OAuth 2.0(IETF RFC 6749)은 다중 사용자 환경 또는 위임 인증이 필요한 경우 권장됩니다. WIA는 OAuth 2.0 표준 구현 외에 OpenID Connect(OIDC)도 부속서에서 정의하며, OIDC를 통해 사용자 신원 정보를 함께 처리할 수 있습니다. 한국 시장에서는 카카오·네이버 로그인과의 연동이 가능하도록 OIDC 호환성을 확보한 사례가 다수 보고됩니다.

OAuth 2.0의 표준 흐름 가운데 WIA는 (1) Authorization Code Grant(웹 응용용), (2) Client Credentials Grant(서버 간 통신용), (3) Refresh Token Grant(액세스 토큰 갱신용)의 세 가지를 지원합니다. Resource Owner Password Credentials와 Implicit Grant는 OAuth 2.1 표준에서 권장되지 않으므로 WIA에서도 지원하지 않습니다. 액세스 토큰의 기본 만료 시간은 1시간이며, 리프레시 토큰은 30일입니다.

5.3 표정 감정 분석 API

5.3.1 얼굴 이미지 분석

그림 5-4. 얼굴 이미지 분석 API — 요청·응답 예시
POST /v1/analyze/face

요청 본문:
{
    "image_url": "https://example.com/face.jpg",
    // 또는
    "image_base64": "data:image/jpeg;base64,/9j/4AAQ...",

    "options": {
        "return_action_units": true,
        "return_dimensions": true,
        "return_landmarks": false,
        "min_face_size": 50,
        "max_faces": 5
    }
}

응답 (200 OK):
{
    "request_id": "req_abc123",
    "processing_time_ms": 145,
    "faces": [
        {
            "face_id": 0,
            "bbox": { "x": 120, "y": 80, "width": 200, "height": 250 },
            "emotions": {
                "primary": { "label": "happiness", "confidence": 0.87 },
                "all": [
                    { "label": "happiness", "confidence": 0.87 },
                    { "label": "neutral", "confidence": 0.08 },
                    { "label": "surprise", "confidence": 0.05 }
                ]
            },
            "dimensions": {
                "valence": 0.72,
                "arousal": 0.45
            },
            "action_units": [
                { "au": "AU6", "intensity": 0.8 },
                { "au": "AU12", "intensity": 0.9 }
            ]
        }
    ]
}

요청은 image_url(외부 URL)과 image_base64(인라인 base64) 두 형식 중 하나를 사용합니다. 인라인 base64는 외부 URL이 가용하지 않은 환경에서 유용하지만 요청 본문이 커지므로 1 MB 이하 이미지에 한해 권장됩니다. 외부 URL 사용 시에는 표준 서버가 해당 URL에 접근할 수 있는 경로가 보장되어야 하며, 일반적으로 공개 CDN URL이 사용됩니다.

options.max_faces는 한 이미지에서 분석할 얼굴의 최대 개수를 제한합니다. 그룹 사진 분석 시 1~10 사이의 값이 적절하며, 개별 얼굴이 너무 작아 옵트인 동의를 분리해 받기 어려운 환경에서는 max_faces=1로 제한하여 의도하지 않은 분석을 방지합니다.

응답의 faces 배열은 이미지에 포함된 모든 얼굴의 분석 결과를 담습니다. 각 얼굴은 face_id로 식별되며, 그룹 사진 분석 시 face_id는 0부터 순차적으로 할당됩니다. 각 얼굴의 bbox는 이미지 내의 픽셀 좌표(x, y, width, height)로 표시되며, 후속 시스템이 결과를 시각적으로 표시할 때 활용할 수 있습니다.

options.return_action_units가 true로 설정되면 응답에 action_units 배열이 포함되며, 각 AU의 강도가 0~1 범위로 출력됩니다. AU 정보는 결과의 설명 가능성을 높이는 데 유용하지만 응답 크기가 약 2배로 늘어나므로, 사용자 인터페이스에 표시하지 않는 응용에서는 false로 설정하여 대역폭을 절감할 수 있습니다.

5.3.2 비디오 프레임 분석

그림 5-5. 비디오 프레임 분석 API — 요청·응답 예시
POST /v1/analyze/face/video

요청 본문:
{
    "video_url": "https://example.com/video.mp4",
    // 또는
    "frames_base64": ["data:image/jpeg;base64,...", ...],

    "options": {
        "sample_rate": 5,
        "start_time_ms": 0,
        "end_time_ms": 10000,
        "track_faces": true
    }
}

응답 (200 OK):
{
    "request_id": "req_video123",
    "duration_ms": 10000,
    "frame_count": 60,
    "analyzed_frames": 12,
    "timeline": [
        {
            "timestamp_ms": 0,
            "faces": [{ ... }]
        },
        {
            "timestamp_ms": 833,
            "faces": [{ ... }]
        }
    ],
    "summary": {
        "dominant_emotion": "happiness",
        "average_valence": 0.65,
        "average_arousal": 0.42,
        "emotion_transitions": 3
    }
}

5.4 음성 감정 분석 API

5.4.1 오디오 분석

그림 5-6. 오디오 분석 API — 요청·응답 예시
POST /v1/analyze/voice

요청 본문:
{
    "audio_url": "https://example.com/audio.wav",
    "options": {
        "language": "ko-KR",
        "return_transcript": true,
        "return_prosody": true,
        "segment_by": "utterance"
    }
}

응답 (200 OK):
{
    "request_id": "req_voice456",
    "duration_ms": 5500,
    "language_detected": "ko-KR",
    "transcript": "정말 기뻐요!",
    "emotions": {
        "primary": { "label": "happiness", "confidence": 0.85 }
    },
    "dimensions": {
        "valence": 0.78,
        "arousal": 0.65
    },
    "prosody": {
        "pitch_mean_hz": 220.5,
        "pitch_range_hz": 95.3,
        "intensity_db": 65.2,
        "speech_rate_wpm": 130,
        "pause_ratio": 0.18
    }
}

한국어 음성 입력 시 language 옵션은 "ko-KR"로 설정합니다. 음성 인식 정확도는 화자의 발화 명료도·배경 잡음·녹음 장비에 따라 달라지며, 16 kHz 이상 PCM 무손실 형식이 권장됩니다. 주요 한국 콜봇·주요 한국 플랫폼 음성 서비스 콜의 통화 환경에서는 8 kHz G.711 PCMA 형식이 일반적이며, 이 경우 정확도가 약 5~8 %p 낮아질 수 있습니다.

음성 분석 응답의 prosody 객체는 운율 분석 결과를 담습니다. pitch_mean_hz는 한국어 화자의 경우 일반적으로 남성 100~150 Hz, 여성 180~250 Hz, 어린이 250~350 Hz 범위입니다. pitch_range_hz는 감정의 강도를 시사하는 지표로, 평정한 화자는 50 Hz 이하, 흥분된 화자는 150 Hz 이상의 범위를 보입니다. speech_rate_wpm(분당 단어 수)은 한국어의 경우 정상 범위가 120~160이며, 분노·흥분 시 180 이상, 우울·피로 시 100 이하로 측정됩니다. pause_ratio(휴지 비율)은 발화 시간 대비 무음 구간의 비율이며, 우울 화자에서 평균보다 높게 측정됩니다.

segments 배열은 화자의 발화를 의미 단위(utterance)로 분할한 결과를 담습니다. 한 발화의 끝은 (1) 0.7초 이상의 무음, (2) 종결 어미 검출, (3) 의문문 억양 패턴 종료의 세 가지 조건 중 하나로 결정됩니다. 한국어 종결 어미는 "-요"·"-입니다"·"-습니다"·"-네요"·"-군요" 등이며, 각 종결 어미의 억양 패턴이 달라 발화 분할의 정확도에 영향을 줍니다.

5.4.2 실시간 음성 분석

그림 5-7. 실시간 음성 분석 — WebSocket 메시지 흐름
POST /v1/analyze/voice/stream
요청: WebSocket 업그레이드 (제6장 참조)

초기 메시지:
{
    "type": "config",
    "sample_rate": 16000,
    "encoding": "LINEAR16",
    "language": "ko-KR"
}

오디오 청크: 바이너리 PCM 데이터

응답 메시지:
{ "type": "partial", "timestamp_ms": 1500, "emotion": { "label": "neutral", "confidence": 0.7 } }
{ "type": "final", "segment": { "start_ms": 0, "end_ms": 3000, "text": "안녕하세요", "emotion": { "label": "happiness", "confidence": 0.82 } } }

실시간 음성 분석은 콜센터·차량용 음성 인터페이스·라이브 방송 환경에 적합하며, 평균 지연시간은 한국 5G SA 환경에서 200 ms 이하로 측정됩니다. 5G NSA 환경에서는 평균 350 ms이며, LTE 환경에서는 평균 600 ms입니다. 응용의 지연시간 요구사항에 따라 적절한 네트워크 환경을 선택해야 합니다.

"partial" 메시지는 발화 중간에 점진적으로 출력되는 임시 결과이며, "final" 메시지는 발화가 끝난 뒤의 확정 결과입니다. 두 메시지는 서로 보완 관계에 있어, partial은 사용자에게 즉각적 피드백을 제공하는 데 사용되고 final은 분석 결과의 영구 저장에 사용됩니다. 응용에 따라 partial만 사용하거나 final만 사용하거나 둘 다 사용할 수 있으며, partial 메시지의 빈도는 config 메시지의 partial_interval_ms 매개변수로 조정할 수 있습니다(기본값 500 ms).

WebSocket 연결의 안정성은 실시간 응용의 핵심 품질 지표이며, 한국 통신 환경에서는 5G 셀 핸드오버·신호 음영·이동성 변화로 인해 일시적 연결 손실이 발생할 수 있습니다. 표준 SDK는 자동 재연결 기능을 제공하며, 연결 손실 시 마지막 final 메시지의 timestamp_ms를 시작점으로 다시 연결을 시도합니다. 재연결 전략은 제6장 §6.6.3에서 상세히 다룹니다.

5.5 텍스트 감성 분석 API

5.5.1 텍스트 분석

그림 5-8. 텍스트 감성 분석 API — 요청·응답 예시
POST /v1/analyze/text

요청 본문:
{
    "text": "이 제품 정말 좋아요! 최고의 구매!",
    "language": "ko",
    "options": {
        "return_aspects": true,
        "return_entities": true,
        "detect_sarcasm": true
    }
}

응답 (200 OK):
{
    "request_id": "req_text789",
    "text_length": 18,
    "language": "ko",
    "sentiment": {
        "polarity": 0.92,
        "subjectivity": 0.85,
        "label": "very_positive"
    },
    "emotions": {
        "primary": { "label": "happiness", "confidence": 0.91 }
    },
    "dimensions": {
        "valence": 0.88,
        "arousal": 0.65
    },
    "aspects": [
        { "aspect": "제품", "sentiment": 0.95 }
    ],
    "sarcasm": { "detected": false, "confidence": 0.02 }
}

한국어 텍스트 분석은 형태소 분석(KoNLPy, Mecab-Ko) 전처리가 필수이며, 신조어·이모티콘·자모 분해(예: "ㅋㅋ", "ㅠㅠ") 처리도 표준 권고에 포함됩니다. KoBERT·KLUE-RoBERTa·KoGPT 같은 한국어 특화 모델이 영문 모델 대비 평균 8~12 %p 높은 정확도를 보고합니다.

aspects 배열은 텍스트가 언급한 주제·대상별 감성 점수를 분리해 제공합니다. 예를 들어 한 리뷰가 "디자인은 좋은데 배터리는 형편없어요"라고 작성된 경우, aspects는 [{"aspect": "디자인", "sentiment": 0.8}, {"aspect": "배터리", "sentiment": -0.7}] 형태로 분해됩니다. 이러한 측면별 분석(aspect-based sentiment analysis, ABSA)은 단일 감성 점수만 제공하는 단순 분석보다 사용자 피드백 분석에 훨씬 유용합니다.

sarcasm 객체는 반어·풍자 탐지 결과를 담습니다. 한국어 반어 표현은 "참 잘했어요"·"훌륭하네요" 같은 긍정 어휘가 부정 의도로 사용되는 패턴이 많아 글자만 보면 긍정으로 분류되지만 의미는 부정인 경우가 잦습니다. 이러한 경우 sarcasm.detected가 true로 설정되며, 후속 시스템은 sentiment.polarity를 그대로 사용하지 않고 반어 보정을 적용해야 합니다. 반어 탐지의 정확도는 일반적으로 65~75 % 수준이므로, 사용자 인터페이스에서는 sarcasm.confidence가 0.7 이상일 때만 보정을 적용하는 것이 권장됩니다.

5.5.2 일괄 텍스트 분석

그림 5-9. 일괄 텍스트 분석 API — 요청·응답 예시
POST /v1/analyze/text/batch

요청 본문:
{
    "texts": [
        { "id": "review_1", "text": "최고의 제품!" },
        { "id": "review_2", "text": "끔찍한 경험." },
        { "id": "review_3", "text": "그냥 보통이에요." }
    ],
    "language": "ko"
}

응답 (200 OK):
{
    "request_id": "req_batch001",
    "results": [
        { "id": "review_1", "sentiment": { "polarity": 0.85, "label": "positive" } },
        { "id": "review_2", "sentiment": { "polarity": -0.78, "label": "negative" } },
        { "id": "review_3", "sentiment": { "polarity": 0.1, "label": "neutral" } }
    ],
    "summary": {
        "average_sentiment": 0.06,
        "positive_count": 1,
        "negative_count": 1,
        "neutral_count": 1
    }
}

일괄 분석은 리뷰·SNS 텍스트 같은 대량 데이터를 효율적으로 처리하기 위한 엔드포인트입니다. 한 요청에 최대 1,000개 텍스트를 포함할 수 있으며, 1,000개 초과 시 여러 요청으로 분할해야 합니다.

5.6 생체신호 분석 API

5.6.1 생체신호 분석

그림 5-10. 생체신호 분석 API — 요청·응답 예시
POST /v1/analyze/biosignal

요청 본문:
{
    "signals": {
        "ecg": { "sample_rate": 256, "data": [0.12, 0.15, ...], "unit": "mV" },
        "eda": { "sample_rate": 4, "data": [2.5, 2.6, ...], "unit": "uS" }
    },
    "duration_ms": 60000,
    "options": { "return_hrv": true, "return_stress": true, "return_engagement": true }
}

응답 (200 OK):
{
    "request_id": "req_bio001",
    "duration_ms": 60000,
    "heart_rate": { "mean_bpm": 72, "min_bpm": 65, "max_bpm": 82 },
    "hrv": { "rmssd_ms": 42.5, "sdnn_ms": 55.3 },
    "eda": { "scl_mean": 3.2, "scr_count": 5 },
    "derived_states": {
        "stress_level": 0.35,
        "relaxation": 0.55,
        "engagement": 0.72
    }
}

5.7 멀티모달 융합 API

5.7.1 멀티모달 분석

그림 5-11. 멀티모달 분석 API — 요청·응답 예시
POST /v1/analyze/multimodal

요청 본문:
{
    "modalities": {
        "face": { "image_url": "https://example.com/face.jpg" },
        "voice": { "audio_url": "https://example.com/audio.wav" },
        "text": { "text": "오늘 기분 정말 좋아요!" }
    },
    "fusion": {
        "method": "weighted_average",
        "weights": { "face": 0.5, "voice": 0.3, "text": 0.2 }
    }
}

응답 (200 OK):
{
    "request_id": "req_multi001",
    "fused_result": {
        "emotions": { "primary": { "label": "happiness", "confidence": 0.88 } },
        "dimensions": { "valence": 0.75, "arousal": 0.52 }
    },
    "modality_results": {
        "face": { "emotions": { "primary": { "label": "happiness", "confidence": 0.85 } } },
        "voice": { "emotions": { "primary": { "label": "happiness", "confidence": 0.82 } } },
        "text": { "emotions": { "primary": { "label": "happiness", "confidence": 0.90 } } }
    },
    "fusion_details": {
        "method": "weighted_average",
        "weights_used": { "face": 0.5, "voice": 0.3, "text": 0.2 },
        "agreement_score": 0.92
    }
}

멀티모달 API는 모달리티별 동기화·정렬을 표준 서버가 자동 처리하므로 클라이언트 부담이 적습니다. agreement_score는 모달리티 간 일치도이며, 0.7 이상이면 신뢰할 만한 융합 결과로 간주됩니다. 0.5 미만은 모달리티 간 충돌 신호로, 이 경우 사용자에게 결과의 불확실성을 명시적으로 표시하는 것이 권장됩니다.

fusion.method 필드는 §3.6.1의 4가지 융합 전략 가운데 하나로 설정합니다. weighted_average는 가장 단순하고 견고한 방식으로 산업에서 가장 널리 사용됩니다. max_confidence는 가장 높은 신뢰도의 모달리티 결과를 그대로 사용하는 방식으로, 한 모달리티가 다른 모달리티보다 명확히 우월할 때 적합합니다. voting은 다수결 방식이며 단순하지만 신뢰도 차이를 무시하는 한계가 있습니다. attention은 학습된 가중치를 사용하는 가장 정교한 방식으로 정확도가 높지만 모델 학습이 필요합니다.

fusion.weights 합은 1.0이 되어야 하며, 그렇지 않은 경우 표준 서버가 자동으로 정규화를 수행합니다. 가중치는 동적으로 변경 가능하며, 모달리티 한쪽의 신호 품질이 떨어지는 경우(예: 음성 채널의 잡음 증가, 표정 카메라의 가림) 해당 모달리티의 가중치를 동적으로 낮추는 것이 권장됩니다. 표준 SDK는 이러한 동적 가중치 조정 기능을 기본 구현으로 제공합니다.

5.8 오류 처리

5.8.1 오류 응답 형식

그림 5-12. 오류 응답 형식 — JSON 예시
{
    "error": {
        "code": "INVALID_IMAGE",
        "message": "제공된 이미지를 처리할 수 없습니다",
        "details": {
            "reason": "이미지에서 얼굴을 탐지하지 못했습니다",
            "suggestion": "얼굴이 명확히 보이는 이미지를 사용해 주십시오"
        }
    },
    "request_id": "req_err001"
}

5.8.2 오류 코드

표 5-2. WIA Phase 2 API 오류 코드
HTTP 상태오류 코드설명
400INVALID_REQUEST요청 본문 형식 오류
400INVALID_IMAGE이미지 처리 불가
400NO_FACE_DETECTED이미지에서 얼굴 미탐지
401UNAUTHORIZEDAPI 키 무효 또는 누락
403FORBIDDEN권한 부족
429RATE_LIMITED요청 제한 초과
500INTERNAL_ERROR서버 오류

5.9 호출 제한율

표 5-3. WIA Phase 2 API 호출 제한율 요금제
요금제분당 요청일별 요청
무료10100
개발자6010,000
비즈니스300100,000
엔터프라이즈맞춤맞춤

호출 제한율 초과 시 429 Rate Limited 응답이 반환되며, 응답 헤더 X-RateLimit-Reset에 다음 가용 시각이 ISO 8601 형식으로 포함됩니다. 클라이언트는 지수 백오프(exponential backoff) 재시도 전략을 권장합니다. 한국 시장에서는 카카오엔터프라이즈 주요 한국 플랫폼 콜봇 클라우드·네이버클라우드 CLOVA Sentiment API의 호출 제한율과 비교 가능한 수준으로 설정됩니다.

지수 백오프의 권장 매개변수는 (1) 초기 지연 100 ms, (2) 지수 배수 2.0, (3) 최대 지연 60초, (4) 최대 재시도 5회, (5) 지터(jitter) ±25 %입니다. 지터는 다수의 클라이언트가 동시에 재시도하는 "썬더링 허드(thundering herd)" 문제를 방지하는 데 필수입니다. 표준의 SDK는 이 지수 백오프 절차를 기본 구현으로 제공하며, 사용자는 매개변수를 사용 사례에 맞게 조정할 수 있습니다.

호출 제한율과 별도로, 동시 연결 수(concurrent connection)·일별 데이터 전송량(daily data transfer)·월별 분석 시간(monthly analysis hours) 같은 부수 한도도 요금제별로 차등 적용됩니다. 엔터프라이즈 요금제는 모든 한도를 협상 가능하며, 한국 대기업 사례에서 분당 1,000~3,000 요청 수준의 한도가 합의된 바 있습니다.

5.10 한국 클라우드 환경 정합 — CSAP·PIMS·5G MEC

한국 시장에서 WIA Phase 2 API를 운영할 때는 다음 세 가지 인프라·인증 요소가 핵심입니다. 첫째, 클라우드 보안 인증(Cloud Security Assurance Program, CSAP)은 한국 공공기관 클라우드 서비스의 보안 요건을 정의하며, IaaS·SaaS·CSAP-Lite 세 등급으로 구분됩니다. WIA 표준 적합성을 받은 SaaS는 CSAP IaaS 인증을 받은 인프라 위에 배치되면 보안 요건의 80 % 이상을 자동으로 충족합니다.

둘째, 정보보호 관리체계 인증(ISMS-P, KISA-PIMS)은 개인정보를 처리하는 시스템의 관리·기술·물리 보안 요건을 점검합니다. WIA Phase 2 API의 인증·접근 통제·감사 로그·키 관리 절차는 ISMS-P의 92개 점검 항목 가운데 약 55개 항목을 자동으로 충족하며, 나머지 항목은 도메인별 추가 절차로 보강됩니다.

셋째, 한국 통신3사(SKT·한 한국 통신사·LGU+)의 5G MEC(Multi-access Edge Computing) 인프라는 실시간 응용의 지연시간을 크게 줄일 수 있는 자원입니다. SKT의 5GX MEC는 평균 10 ms 이하의 엣지 지연시간을 제공하며, 차량용 운전자 모니터링·콜센터 실시간 분석에 적합합니다. WIA Phase 2 API는 표준 REST 호출에 더해 MEC 엣지 노드에서 실행 가능한 경량 SDK를 제공하여 엣지·클라우드 하이브리드 배치를 지원합니다.

표 5-4. 카카오엔터프라이즈·네이버클라우드 API와 WIA Phase 2 비교
항목주요 한국 플랫폼 콜봇 클라우드 STT네이버클라우드 CLOVA SentimentWIA Phase 2
인증API KeyAPI KeyAPI Key 또는 OAuth 2.0
기본 호출 제한분당 200분당 100분당 60(개발자) ~ 300(비즈니스)
한국어 정확도92~94 %87~89 %한국어 모델 88~92 %
데이터 거주KRKRKR/US/EU 선택
감정 라벨 수5종3종(긍·부·중)7+12 한국형

이 비교는 WIA Phase 2가 한국 사업자 API와 동등하거나 우수한 기능을 제공하면서 추가로 표준화·국제 호환성을 갖추는 가치를 보여 줍니다. 한국 사업자가 WIA 적합성을 추가로 확보하면 글로벌 시장 진출 시 별도 표준 도입의 부담을 줄일 수 있습니다.

한국 통신3사의 5G MEC 인프라 활용 시나리오를 구체적으로 살펴보면, SKT의 5GX MEC는 서울·부산·광주·대전 4개 권역에 분산 배치되어 있으며, 각 권역의 응용 노드는 평균 8~12 ms의 엣지 지연시간을 제공합니다. KT의 한 한국 통신사 MEC는 서울·인천·대전·부산·광주 5개 권역에 배치되어 있으며 평균 9~14 ms를 제공합니다. LGU+의 5G MEC는 수도권 중심으로 배치되어 있어 수도권 외 지역에서는 지연시간이 다소 늘어날 수 있습니다.

한국 클라우드 사업자 가운데 NHN클라우드·KT클라우드·네이버클라우드는 모두 CSAP IaaS 인증을 받았으며, 공공 부문 응용에 적합합니다. 카카오엔터프라이즈 주요 한국 플랫폼 콜봇 클라우드는 CSAP-Lite 등급을 받아 비교적 가벼운 보안 요건의 응용에 적합합니다. 의료 등급 응용은 추가로 「의료법」 제17조의2(전자의무기록) 보안 요건과 식약처의 SaMD 가이드라인을 함께 따라야 합니다.

WIA Phase 2 API를 한국 클라우드에 배치할 때의 모범 절차는 (1) CSAP 또는 ISMS-P 인증을 받은 IaaS 선택, (2) WIA SDK를 컨테이너 또는 서버리스 함수로 배치, (3) API 게이트웨이로 인증·호출 제한율 제어, (4) 감사 로그를 별도 보안 저장소에 기록, (5) 분기별 보안 점검과 키 회전의 5단계입니다. 이 절차는 한국 KISA가 운영하는 「클라우드 보안 가이드」(2024)의 권고와 정합합니다.

5.11 장 요약

핵심 내용 일곱 가지.

  1. RESTful 설계. 표준 HTTP 메서드, JSON 형식
  2. 4 모달리티 API. 표정·음성·텍스트·생체신호
  3. 멀티모달 융합. 가중치 설정 가능한 모달리티 결합
  4. 포괄 출력. 감정·차원·AU·메타데이터
  5. 오류 처리. 명확한 코드와 메시지
  6. 호출 제한율. 요금제별 차등
  7. 한국 정합. CSAP·ISMS-P·5G MEC와의 정합 사전 설계

5.12 복습 문제

  1. WIA Phase 2 API의 5대 설계 원칙을 나열하시오.
  2. API 키 인증과 OAuth 2.0 인증의 차이를 한국 사용 사례와 함께 설명하시오.
  3. 표정·음성·텍스트·생체신호 4 모달리티 API의 엔드포인트와 핵심 입력·출력을 정리하시오.
  4. 멀티모달 융합 API의 agreement_score가 0.5 미만일 때 권장되는 처리 방식을 서술하시오.
  5. 한국 5G SA·NSA·LTE 환경에서의 음성 분석 평균 지연시간을 비교하시오.
  6. CSAP·ISMS-P·5G MEC가 WIA Phase 2 API 운영에 어떤 의미를 갖는지 설명하시오.
  7. 호출 제한율 초과 시 클라이언트가 따라야 할 재시도 전략(지수 백오프)을 매개변수와 함께 서술하시오.

5.13 다음 장 미리보기

제6장에서는 Phase 3 — 스트리밍 프로토콜의 WebSocket 메시지 형식, 프레임률·지연시간 요구사항, 보안, 오류 처리, 재연결 전략을 다룹니다. 본 장의 음성 실시간 분석 엔드포인트(/analyze/voice/stream)는 제6장의 WebSocket 프로토콜 위에서 작동합니다.

실습 권고. 본 장의 curl 예시를 실제 환경에서 실행해 보면 표준의 작동 방식을 직접 체감할 수 있습니다. 무료 요금제에 가입하여 분당 10회의 호출 한도 안에서 표정·음성·텍스트·생체신호 4 모달리티를 모두 시험해 보면, 다음 장의 실시간 스트리밍 학습 시 비교 기준이 됩니다. 한국 사용자는 한국 리전 엔드포인트(api-kr)를 사용하면 평균 50~80 ms의 추가 지연 절감을 얻을 수 있습니다.

또한 본 장에서 정의된 API는 후속 제7장의 도메인 통합과 결합되어 헬스케어·교육·마케팅·자동차 응용에서 직접 호출됩니다. 따라서 본 장의 표 5-1·5-2·5-3·5-4를 별도로 표기해 두면 후속 장 학습 시 빠른 참조가 가능합니다. 본권 표준의 진화 이력은 GitHub 공개 저장소에 기록된다.[99]

제5장 미주

  1. WIA Standards 공개 저장소 (emotion-ai 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/emotion-ai — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치이다. 표준의 진화 로드맵·개정 이력·SDK 소스코드는 GitHub 저장소에서 공개적으로 갱신된다.