텍스트와 음성

6.1 텍스트 분석과 정보 보호

세부 학습 목표

• 엔터티·주제·요약·감정·어조·안전·민감 정보의 목적을 구별한다.
• PII 범위·가림·문자 인덱스와 누락/과도한 가림을 검사한다.
• 도메인 요약·추출·JSON을 원문 조건·필수 필드·근거로 평가한다.

개요

• 목적 구분: 개체 인식·감정 분석·요약·필드 추출.
• 정보 보호: 개인정보 탐지 → 가림 → 누락·과도한 제거 검사.
• 출력 검증: 형식과 원문 근거·누락·잘못된 추정을 각각 확인.

작업에 맞는 결과를 정의하기

• 고객 의견에서 회사 이름을 찾고, 불만 비율을 계산하고, 상담 요약을 만드는 일은 같은 입력을 사용해도 출력이 다릅니다.

  NER(개체명 인식)는 사람·장소·조직 등 엔터티와 범주를 찾습니다. 감정 분석은 긍정·중립·부정 같은 의견 성향을 다룹니다. 요약은 중요한 내용을 압축하고, 필드 추출은 업무에서 쓸 이름과 값으로 내용을 정리합니다.

• 전용 Language 기능과 LLM 기반 추출을 입력·언어·필요한 출력·정확도·운영 조건으로 비교합니다.

  부정 감정이 탐지됐다고 유해 콘텐츠나 개인정보가 있다는 의미는 아닙니다. 분류의 목적과 라벨을 혼동하지 않습니다.

• 2026년 10월 공식 문서 확인 기준으로 NER와 PII 탐지는 Azure Language의 핵심 기능입니다.

  반면 감정 분석·의견 마이닝(opinion mining)·요약 기능은 2029년 3월 31일 지원 종료 예정이며, 신규 구현에는 Microsoft Foundry 모델 기반 대안을 검토합니다. 텍스트 처리의 목적과 품질 검증 원리는 유지하되, 서비스 선택에서는 이 지원 일정도 구분합니다.

개인정보를 가리는 과정

• PII 탐지는 민감 정보를 식별·분류하고 설정에 따라 가린 결과를 제공하는 기능입니다.

  일반 NER와 겹치는 이름도 있지만 목적과 처리 범위가 다릅니다. 서비스가 찾은 범위와 실제 개인정보를 대조해 누락과 과도한 가림을 확인합니다.

아래 코드는 외부 탐지기가 가림 위치를 반환했다고 가정한 로컬 처리 예제입니다. 탐지 기능 자체를 구현하거나 실제 Azure PII 응답 형식을 재현한 것은 아닙니다.

text = "고객 김민수의 연락처는 010-1234-5678입니다."
name_start = text.index("김민수")
phone_start = text.index("010-1234-5678")
spans = [(name_start, len("김민수")), (phone_start, len("010-1234-5678"))]
 
masked = text
for start, length in sorted(spans, reverse=True):
    if start < 0 or length < 0 or start + length > len(text):
        raise ValueError("가림 위치 오류")
    masked = masked[:start] + "[가림]" + masked[start + length:]
assert "김민수" not in masked
assert "010-1234-5678" not in masked
print(masked)

• 뒤쪽 위치부터 바꾸면 앞선 치환 때문에 다음 위치가 밀리는 일을 줄일 수 있습니다.

  운영에서는 겹치는 범위와 Unicode 인덱스 계약도 확인합니다. 서비스의 offset이 어떤 문자열 인덱스 단위인지 확인하지 않고 Python 문자 수나 다른 언어의 문자열 길이에 그대로 적용하면 가림 위치가 틀릴 수 있습니다.

도메인 출력의 품질

• 계약서를 요약할 때는 기간·해지 조건·예외 조항처럼 빠뜨리면 안 되는 항목을 정합니다.

  원문에 없는 날짜를 그럴듯하게 채워 넣지 않도록 누락 표현을 정의하고, 전문 용어와 기준 예시를 평가셋에 담습니다. “전문가처럼 답하라”는 역할 지침만으로 정확성이 검증되지는 않습니다.

• JSON 파싱과 스키마 검증을 통과해도 의미가 틀릴 수 있으므로 4.1의 구조화 출력 검사와 연결합니다.

  개인정보를 가린 결과를 다른 모델·로그·분석 시스템에 보낼 때는 가림 누락이 다음 단계에 그대로 전파되지 않는지도 확인합니다.

엔터티·감정·요약의 목적 구분

• 엔터티 인식은 개체를 분류하고, 감정 분석은 표현된 태도를 추정하며, 요약은 내용을 압축합니다.

  기능별 출력과 오류 기준을 구분합니다. 2026년 10월 기준 Azure Language의 기존 감정 분석·요약 등 일부 기능은 2029년 3월 31일 지원 종료 예정이므로 신규 구현은 Foundry 모델 기반 대안을 검토합니다. NER·PII 등 지속 지원 핵심 기능과 구분합니다.

• 상황: 민원 문서에서 담당 회사와 불만 원인을 구분해 수집합니다.

• 적용: 회사명은 엔터티/구조화 추출, 불만 원인은 내용 분류 또는 요약으로 분리합니다.

  두 결과를 원문 문장과 대조합니다.

• Azure Language 서비스 선택 

• 요약 기능 지원 종료 공지 

PII 탐지·가림과 NER 구분

• 일반 NER는 인명·조직명 등 여러 종류의 개체를 찾고, PII 탐지는 개인 식별 가능 정보의 탐지·분류·가림에 초점을 맞춥니다.

  Azure Language PII 기능은 텍스트·대화·문서 유형별로 처리 방식이 다릅니다. 탐지가 모든 민감 정보를 100% 가린다는 보장은 없으므로 누락 검사가 필요합니다.

• 상황: 고객 메일 100건에서 이름만 제거했지만 전화번호가 남아 있습니다.

• 적용: 필요한 PII 범주를 먼저 정의한 뒤 가림 결과에서 빠진 전화번호 등과 과잉 가림을 별도로 검토합니다.

• Azure Language 개인정보 탐지 

구조화 JSON 출력 검증

• 유효한 JSON을 출력하는 것과 지정한 JSON Schema를 따르는 것, 그리고 원문의 사실에 맞는 값을 추출하는 것은 서로 다른 검증 단계입니다.

  Azure OpenAI의 Structured Outputs는 지원되는 API·모델에서 스키마 준수를 강화하지만 금액·날짜 등 추출값의 정답성까지 보장하지는 않습니다.

• 상황: 청구서 금액이 JSON 숫자로 나왔지만 원문의 총액과 다릅니다.

• 적용: JSON 파싱 → 스키마 적합성 → 원문 근거와 금액 검산 순서로 확인합니다.

  구조화 출력의 스키마 통과는 내용 정확성과 별개입니다.

• Azure OpenAI 구조화 출력 

확인 문제

목적 A: 본문에 언급된 의료기관·지역·날짜를 분류해 색인
목적 B: 공개용 발췌문에서 연락처 등 개인정보를 탐지해 가림
조건: 목적 A의 모든 개체를 무조건 삭제하지 않음

입력: 이름·전화번호를 포함한 후기 원문
개인정보 검출·가림은 승인된 내부 환경에서 수행 가능
요구: 외부 분석 API에 원문 개인정보를 보내지 않음

원문: "검사 A는 음성이며 검사 B는 추가 확인 필요"
기존 요약: "A 양성, B 확인 필요"
용어집 적용 요약: "A 음성, B 정상"
필수 조건: 검사명·부정 표현·미확정 상태 보존
평가 방식: 전문 용어 포함 여부만 검사

참고 자료

• What is named entity recognition (NER) in Azure Language? 
• What is PII detection in Azure Language? 
• Analyze text with Azure Language in Foundry Tools 
• What are sentiment analysis and opinion mining? 
• What is Azure Language? 
• Summarization overview and retirement notice 

자료 확인: 2026-10-22 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

6.2 번역·음성 인식·합성

세부 학습 목표

• 텍스트 번역·STT·TTS·음성 번역의 입력과 출력을 구별한다.
• 실시간·단일 발화·연속·배치 처리와 오디오 형식·언어를 선택한다.
• SSML·목소리의 지원을 확인하고 숫자·용어·원음의 단계별 오류를 대조한다.

개요

• 번역: 의미를 다른 언어로 변환.
• 음성 인식(STT): 음성을 문자로 변환.
• 음성 합성(TTS): 문자를 음성으로 변환.
• 방식 선택: 실시간 여부·입력 길이·처리량·언어 조건 비교.

입력과 출력을 따라 서비스 고르기

• 한국어 발화를 영어 자막으로 표시하는 작업에는 음성 인식과 번역이 연결됩니다.

  한국어 STT가 성공했다고 영어 자막이 이미 만들어진 것은 아닙니다. 반대로 영어 목소리를 선택한 TTS는 입력 문장을 그 언어의 의미로 자동 번역하는 기능과 구분해야 합니다.

• Translator와 LLM 번역은 용어 일관성·언어 조합·형식·비용·지연 요구로 비교합니다.

  실제 업무 용어와 숫자·제품 코드를 담은 표본으로 확인해야 모델이 해당 언어로 대답한다는 사실 이상의 품질을 판단할 수 있습니다.

전사 처리 방식

• 실시간 전사는 대화·자막처럼 중간 결과와 빠른 반응이 필요한 작업에 사용합니다.

  빠른 동기 전사는 준비된 파일을 짧은 지연으로 처리하는 요구와 비교하고, 배치는 대량 녹음 파일을 비동기로 처리하는 데 적합한 후보입니다. 현재 API의 입력 제한·지원 기능·언어와 처리 방식을 확인합니다.

다음은 WAV 파일의 한 발화를 인식하는 Azure Speech SDK 예제입니다. azure-cognitiveservices-speech 패키지, Speech 리소스의 환경 변수와 적절한 오디오 파일이 필요합니다. 실제 서비스 호출에는 비용이 발생할 수 있습니다.

• 입력 준비: “오늘 회의는 오후 세 시에 시작합니다”를 한 번 녹음합니다.

  WAV 내보내기를 지원하는 녹음·편집 도구에서 PCM·16비트·모노·16kHz로 저장하고 파일 이름을 sample.wav로 지정합니다. 이 파일은 학습자가 준비합니다. 확장자만 .wav로 바꾸면 실제 오디오 형식이 변환되지는 않습니다.

• 실행 위치: Python 파일과 sample.wav를 같은 폴더에 두고 그 폴더에서 실행합니다.

• 연결 설정: SPEECH_KEY와 SPEECH_REGION을 해당 Speech 리소스의 값으로 설정합니다.

python -m pip install azure-cognitiveservices-speech
$env:SPEECH_KEY = "<Speech 리소스 키>"
$env:SPEECH_REGION = "<Speech 리소스 지역>"

import os
import azure.cognitiveservices.speech as speechsdk
 
config = speechsdk.SpeechConfig(
    subscription=os.environ["SPEECH_KEY"],
    region=os.environ["SPEECH_REGION"],
)
config.speech_recognition_language = "ko-KR"
audio = speechsdk.audio.AudioConfig(filename="sample.wav")
recognizer = speechsdk.SpeechRecognizer(
    speech_config=config, audio_config=audio
)
result = recognizer.recognize_once_async().get()
if result.reason == speechsdk.ResultReason.RecognizedSpeech:
    print(result.text)
elif result.reason == speechsdk.ResultReason.NoMatch:
    print("인식 가능한 발화가 없음")
else:
    print("인식 취소 또는 오류: 상세 결과 확인 필요")

• 확인할 결과: 녹음한 문장의 의미와 “오후 세 시”가 전사에 보존되는지 확인합니다.

  구두점·띄어쓰기나 세 시와 3시 같은 표기는 달라질 수 있습니다. 원음과 전사를 대조하고 숫자·날짜·고유명사가 달라졌다면 별도 오류로 기록합니다. 성공 여부는 실제 녹음과 서비스 응답을 함께 보고 판단합니다.

• recognize_once_async()는 한 번의 발화를 다루는 호출입니다.

  긴 회의 파일 전체를 이 한 호출로 처리한다고 가정하지 않습니다. 연속 인식이나 배치 처리 요구를 별도로 구성하고 오디오 형식·샘플레이트·언어·실제 오류 세부 정보를 확인합니다. 키는 환경 변수나 안전한 저장소로 관리하고 코드·로그에 넣지 않습니다.

TTS와 발음 제어

• TTS에는 읽을 문장과 지원되는 목소리를 지정합니다.

  SSML을 지원하는 음성에서는 문장 구조·쉼·발음 같은 제어를 적용할 수 있습니다. 음성 종류별로 지원 태그가 다를 수 있으므로 특정 태그를 모든 목소리에 적용하지 않습니다.

• 합성 결과가 자연스러워도 원래 전사가 틀렸거나 번역이 금액을 바꿨다면 업무 답은 틀립니다.

  원음·전사·번역·합성 입력을 단계별로 남겨 어느 지점에서 오류가 생겼는지 대조합니다. 숫자·단위·고유 명사와 전문 용어는 대표 검증 사례에 포함합니다.

번역과 전문 용어 보존

• 전용 번역 서비스와 LLM 기반 번역은 제어 방식 및 활용 조건이 다릅니다.

  계약·의학·기술 문서처럼 용어가 중요한 경우 숫자·단위·고유명사를 독립적으로 검사해야 합니다.

• 상황: 제품 매뉴얼에서 “torque 2.5 N·m”가 한국어 번역 결과에서 25 N·m로 바뀌었습니다.

• 적용: 번역된 수치·단위·고유명사를 원문과 기계적으로 대조합니다.

  2.5 N·m가 25 N·m로 변경되면 품질 오류로 분류합니다.

음성 인식과 스트리밍 전사

• Azure Speech STT는 음성을 텍스트로 변환하며 실시간 전사·빠른 전사·배치 전사 등의 처리 형태를 지원합니다.

  녹음 파일 처리에는 배치 방식이 적합할 수 있고, 대화 자막에는 낮은 지연의 실시간 방식이 필요합니다. 부분 결과와 최종 결과를 구분합니다.

• 상황: 30분 회의 녹음과 전화 상담 실시간 자막을 만들려 합니다.

• 적용: 사전 녹음한 회의는 배치 전사로 처리할 수 있습니다.

  실시간 자막은 스트리밍 STT를 사용하고 부분 결과와 최종 결과의 표시·갱신 로직을 분리합니다.

• Azure Speech STT 방식 비교 

확인 문제

필수: ko→en 지원, 용어집 일치 ≥95%, 비용 ≤5단위
A: 지원 yes / 용어집 98% / 비용 8
B: 지원 yes / 용어집 96% / 비용 4
C: 지원 yes / 용어집 90% / 비용 2
D: 지원 no  / 용어집 미측정 / 비용 3
새 분야 입력 평가: 미실시

오디오의 실제 발화(검토자 확인): "볼트 열 개 가격은?"
STT transcript: "볼트 한 개 가격은?"
모델 입력: 볼트 한 개 가격은?
모델 답변: 볼트 한 개는 500원입니다.
TTS 재생: 볼트 한 개는 500원입니다.

음성 구간 s1 (0–2초): "시작하세요" → 영어 "Start"
음성 구간 s2 (2–4초): "멈추세요" → 영어 "Stop"
번역 응답 도착 순서: s2, s1
자막 앱: 도착 순서로 0–2초, 2–4초에 배치
화면: 0–2초 Stop / 2–4초 Start

참고 자료

• What is Azure text translation in Microsoft Foundry? 
• What is speech to text? 
• What is text to speech? 
• SSML document structure and events 
• Translate text and speech with Microsoft Foundry Tools 
• Speech SDK 오디오 형식 

자료 확인: 2026-10-23 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

6.3 음성 에이전트 구성

세부 학습 목표

• 발화 종료·끼어들기·재생 취소·재연결과 도구 상태를 구별한다.
• 전사 기반 흐름과 원음 멀티모달 추론을 필요한 신호로 비교한다.
• Phrase list·custom speech의 조건과 WER·품번 오류·지연·업무 승인을 평가한다.

개요

• 대화 흐름: 발화 인식 → 모델·도구 처리 → 음성 출력.
• 실시간 제어: 발화 종료·끼어들기·재생 중단·연결 복구.
• 검증: 인식 오류와 업무 답변 오류를 나누고 승인·실행 상태 확인.

음성 대화에서 추가되는 상태

• 텍스트 채팅에서는 입력 전송 시점이 명확하지만 음성에서는 사용자가 잠시 멈춘 것인지 말을 끝낸 것인지 판단해야 합니다.

  출력 중 사용자가 다시 말했을 때 합성을 멈출지, 이미 시작한 외부 작업은 어떻게 처리할지도 정해야 합니다.

• 발화 종료 판단, 음성 활동 탐지, 음향 처리와 대화 상태가 지연·사용성에 영향을 줍니다.

  Voice Live는 음성 인식·생성형 처리·음성 합성을 결합한 실시간 인터페이스를 제공합니다. 앱은 그 위에서 업무 도구·권한·승인과 실패 복구를 설계해야 합니다.

• 원음을 직접 이해하는 멀티모달 모델과 STT 텍스트를 사용하는 흐름도 비교할 수 있습니다.

  전사 텍스트에는 억양·배경음 같은 정보가 모두 보존되지는 않습니다. 필요한 신호와 지원 입력, 실제 분석 품질을 검토하고 음향 정보를 근거 없이 과도하게 해석하지 않습니다.

전문 용어 인식 개선

• 품번을 자주 틀리면 먼저 원음과 전사 결과를 비교합니다.

  출력 목소리를 바꾸는 것은 입력 품번 인식을 고치는 것과 다른 변경입니다. Phrase list 같은 가벼운 보정과 custom speech 같은 맞춤화 옵션은 지원 언어·모드·데이터 조건을 확인해 비교합니다.

다음은 단어 단위 오류율 개념을 보여 주는 로컬 편집거리 예제입니다. 실제 Azure 평가 도구의 구현이나 한국어 평가의 유일한 정규화 규칙은 아닙니다.

def word_error_rate(reference, hypothesis):
    ref, hyp = reference.split(), hypothesis.split()
    if not ref:
        raise ValueError("정답 전사가 비어 있음")
    previous = list(range(len(hyp) + 1))
    for i, expected in enumerate(ref, 1):
        current = [i]
        for j, actual in enumerate(hyp, 1):
            current.append(min(
                current[j - 1] + 1, previous[j] + 1,
                previous[j - 1] + (expected != actual),
            ))
        previous = current
    return previous[-1] / len(ref)
 
score = word_error_rate("품번 AB120 주문", "품번 AB12 주문")
assert abs(score - 1 / 3) < 1e-9
print(round(score, 3))

기대 출력은 0.333입니다. 치환·누락·삽입 오류를 정답 단어 수로 나누는 개념이며, 제품 코드를 한 글자 틀린 오류의 업무 영향도는 별도로 평가해야 합니다. 한국어의 띄어쓰기·숫자·단위 정규화와 문자 단위 평가 여부도 기준에 기록합니다.

지연과 변경 작업의 확인

• 완전히 직렬인 흐름에서는 인식·모델·도구·합성의 시간이 누적됩니다.

  스트리밍으로 일부 단계를 겹칠 수 있으므로 실제 첫 음성 응답 시간과 전체 완료 시간, 도구 단계 지연을 따로 측정합니다.

• “예약할게요”라는 합성 문장이 재생됐다고 예약이 실제 완료됐다고 표시하지 않습니다.

  발화·승인 내용과 실제 도구 인수·결과를 연결하고, 불확실한 품번이나 수신자를 확인한 뒤 변경을 실행하도록 구성합니다.

음성 합성·대화형 음성 Agent

• TTS는 텍스트를 음성으로 합성합니다.

  실시간 대화형 음성 에이전트는 사용자 발화를 듣고 답하고 도구를 사용할 수 있어 끼어들기·오디오 스트림·지연 관리가 추가됩니다. Azure Voice Live API는 이러한 음성 대화 구성요소를 통합한 관리형 서비스이며 단순 TTS와 구분해야 합니다.

• 상황: 콜센터 에이전트가 답변하는 중 고객이 “잠깐만”이라고 말합니다.

• 적용: 고객 발화가 시작되면 재생 중인 오디오를 중단하고 대화 상태를 갱신합니다.

  Voice Live처럼 음성 대화를 관리하는 서비스와 단순 TTS 합성을 구분합니다.

• Voice Live 음성 대화 API 

• Speech to Text 

확인 문제

학습용 녹음 40개에 "플랜지" 발화 포함
기존 전사 오류: 12/40
용어 보강 후 같은 40개 오류: 2/40
다른 화자·소음·새 녹음: 평가 없음
운영 환경: 여러 화자와 기계 소음

A 오디오: "괜찮아요" / 검토자 라벨=불만을 억누름
B 오디오: "괜찮아요" / 검토자 라벨=만족
전사 결과 A·B: "괜찮아요"
모델 입력: 전사 문자열만
모델 결과 A·B: 동일
개인별 말투 차이의 평가 자료: 아직 없음

참고 자료

• Voice Live API for real-time voice agents 
• What is custom speech? 
• Develop a speech-capable generative AI application 
• Develop an Azure Speech Voice Live Agent in Microsoft Foundry 

자료 확인: 2026-10-21 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

음성 상담 중 사용자가 주문 번호를 정정했습니다. 이전 인식 결과가 남아 있는 상태에서 주문 조회가 시작됐습니다.