OpenAI, “How we built a realtime system for responsive voice AI in six months” (2026년 8월 3일)

OpenAI는 음성을 끊기지 않게 하기 위해, 대화 중 표시용 로그와 나중에 사용할 확정 로그를 나누어 다루는 설계를 소개하고 있습니다. 영업 통화 메모에서도 이 부분은 그대로 모방하는 것이 좋습니다.

실시간 받아쓰기 (Real-time transcription)는 상담 메모 입력에 직접 연결하지 않습니다. 중간 문자열에는 다시 묻거나 다시 말하는 내용이 섞이기 때문입니다. 먼저 확정된 발언만을 남깁니다. 이것만으로도 "예산은 월 10만 엔"이 "예산은 월"로 변해버리는 사고를 막을 수 있습니다.

음성 받아쓰기는 말하는 도중에 몇 번이고 다시 쓰여집니다. 화면에 보여주는 용도로는 빠른 편이 도움이 됩니다. 하지만 상담 메모는 다릅니다. 후속 담당자가 읽고, 안건의 예산이나 도입 시기를 파악하며, 경우에 따라 CRM으로 전기합니다.

여기서 잠정판과 확정판을 같은 표에 추가하면, 같은 발언이 이중으로 남게 됩니다. 정정 전의 숫자를 누군가 먼저 보게 되면 그것만으로도 번거로워집니다. 음성 AI가 똑똑해질수록, 표시가 빠른 것과 기록이 정확한 것은 별개의 업무가 됩니다.

스트리밍 (Streaming) 받아쓰기는 최종판만을 상담 메모에 전달하면 충분합니다.

아래의 스크립트는 받아쓰기 배포로부터 받은 JSON Lines를 표준 입력으로 읽습니다. state가 final인 행만을 대상으로 하며, 동일한 segment_id가 업데이트되어 있다면 version이 더 큰 것을 채택합니다. sequence로 다시 정렬하므로, 정정 이벤트가 나중에 도착하더라도 발언 순서는 흐트러지지 않습니다.

#!/usr/bin/env python3
"""Keep only the latest final version of each streamed transcript segment."""
import csv
...

입력은 예를 들어 다음과 같은 형태입니다. 받아쓰기 서비스마다 키 이름은 다르므로, 수신 측에서 이 4개 항목으로 모읍니다. partial은 화면 표시용으로만 사용하고 파일로 전달하지 않습니다.

{"segment_id":"s-01","version":1,"sequence":1,"state":"partial","speaker":"고객","text":"예산은 월"}
{"segment_id":"s-02","version":1,"sequence":2,"state":"final","speaker":"영업","text":"도입 희망은 언제쯤인가요"}
{"segment_id":"s-01","version":2,"sequence":1,"state":"final","speaker":"고객","text":"예산은 월 10만 엔입니다"}
...

실행은 다음과 같습니다.

python3 final_transcript_export.py < events.jsonl > meeting_notes.csv

오늘 이 4줄을 Python 3로 흘려보내 확인한 출력 결과입니다. partial의 "예산은 월"은 남지 않고, 동일한 발언의 최신 버전만 남게 되었습니다.

sequence,speaker,text
1,고객,예산은 월 15만 엔입니다
2,영업,도입 희망은 언제쯤인가요

CSV를 스프레드시트에 가져온 후에는 sequence, speaker, text의 3개 열을 원본 데이터로 남깁니다. 그 옆에 담당자가 "예산", "도입 희망일", "다음 액션"을 채울 열을 만들면, 받아쓰기 정정이 있더라도 판단용 열을 망가뜨리지 않습니다.

한 가지 주의할 점이 있습니다. 음성 인식 (Speech Recognition)이 확정이라고 반환한 문장도 내용까지 옳다는 보장은 없습니다. 금액, 고유명사, 날짜는 녹음본이나 상대방에게 보낸 확인 메일로 대조합니다. 코드가 지키는 것은 배포 도중의 문자열을 기록에 섞지 않는 데까지입니다.

GPT-Live처럼 대화를 흘려보내며 처리하는 메커니즘이 확산되면, 통화 중의 속도는 당연한 것이 됩니다. 영업에서 차이가 나는 것은, 빠르게 보이는 문자를 어디에서 확정시키느냐입니다.

우선 통화 1회분의 이벤트를 이 형식으로 저장하고, 기존의 상담 메모와 비교해 보십시오. partial과 final을 나누는 것만으로도 나중에 읽을 수 있는 메모가 됩니다. 이 부분이 은근히 효과적입니다.