아이언맨 자비스처럼 대화하며 일하는 음성 AI 시스템 기술 조사
#아이언맨 자비스처럼 대화하며 일하는 음성 AI 시스템 기술 조사
사용자가 원하는 시스템: 마블 영화 《아이언맨》의 Jarvis처럼 음성으로 명령하고 대화를 이어가면서 실제 작업을 수행하는 개인 AI 비서.
조사일: 2026-09-16. 해외 공식 기술 문서와 오픈소스 저장소를 우선 확인하고, 국내 한국어 음성 서비스 공식 자료를 보완했다. 이 문서는 웹 조사 결과이며 설치·성능 측정·구현을 수행한 보고서는 아니다. 제품별 기능은 확인된 공식 설명, 권장 구성과 평가 기준은 조사자의 제안으로 구분한다.
#1. 중요 — 자비스형 경험의 핵심
#1.1 목표는 대화와 실행을 동시에 이어가는 것
원하는 경험은 다음과 같이 구체화할 수 있다. 아래 대화는 기능 요구를 설명하기 위해 작성한 예시다.
사용자: “자비스, 내 노트에서 지난달 프로젝트 내용을 찾아서 보고서로 정리해 줘.”
비서: “관련 노트를 찾아 정리하겠습니다.”
사용자: “참, 비용 이야기는 빼고 다음 달 계획을 넣어 줘.”
비서: “비용은 제외하고 다음 달 계획을 넣겠습니다.”
사용자: “그동안 오늘 할 일도 알려 줘.”
비서: 오늘 할 일을 짧게 안내한다. 보고서 작업은 계속된다.
비서: “보고서를 저장했습니다. 핵심 내용은 세 가지입니다.” 화면에는 파일이 표시된다.
이 경험을 만들려면 실시간 대화, 작업 실행, 진행 상태, 수정·취소, 결과물 전달을 연결해야 한다. 말투나 목소리만 유사하게 만드는 것으로는 충분하지 않다.
#1.2 현재 기술로 가능한 범위
OpenAI 공식 문서는 음성 인터페이스와 별도의 실행 백엔드를 분리하는 방식, 한 음성 모델이 대화와 도구 선택을 처리하는 방식, 음성 인식·텍스트 에이전트·음성 합성을 연결하는 방식을 구분한다. 따라서 음성 명령으로 업무를 수행하는 시스템의 기본 구성요소는 이미 제공된다. OpenAI 음성 에이전트 구조
다만 영화 속 비서가 보여주는 모든 상황의 완전한 이해와 무오류 실행까지 보장되지는 않는다. 실용적인 목표는 정해진 업무 범위에서, 대화를 유지하며, 실제 결과를 확인할 수 있는 비서다. 특정 제품 이름보다 이 요구를 충족하는지 평가하는 것이 중요하다.
#1.3 가장 중요한 설계 판단
조사자의 권장 방향은 ‘빠른 음성 대화 담당 + 별도의 작업 실행 담당’이다. 검색·문서 작성·코딩이 오래 걸려도 비서가 계속 듣고 응답할 수 있어야 하기 때문이다. 이 구조는 현재 GPT-Live의 위임 방식과 LiveKit·Pipecat의 비동기 도구 기능에서 직접 확인할 수 있다. GPT-Live, LiveKit Async tools, Pipecat Function Calling
#2. 정확 — 필요한 기술과 확인된 선택지
#2.1 기능을 이루는 기술 지도
| 원하는 경험 | 관련 기술 | 이해할 점 |
|---|---|---|
| “자비스”라고 부르면 시작 | Wake word, 호출어 감지 | 호출어 감지와 명령 이해는 별도 단계 |
| 말이 끝나면 자연스럽게 답변 | VAD, 발화 종료 판단 | 소리가 멈춘 것과 문장이 끝난 것은 다름 |
| 비서가 말할 때 끼어들기 | Barge-in, interruption | 출력 중지와 대화 기록 보정이 필요 |
| 말하고 들으며 대화 유지 | Full duplex, 양방향 음성 | 지원 모델과 오디오 처리 방식에 따라 경험이 달라짐 |
| 파일·웹·앱에서 실제 작업 | Tool calling, API, MCP | 모델이 요청한 도구를 실행할 프로그램이 필요 |
| 오래 걸리는 일과 대화를 병행 | Async tools, 작업 위임 | 함수가 비동기라는 사실만으로 대화가 계속되는 것은 아님 |
| 진행 보고·추가 지시 반영 | 작업 상태, 이벤트, 변경 기록 | 현재 어떤 작업을 수정하는지 명확해야 함 |
| 연결이 끊겨도 이어서 작업 | 영속 저장, 체크포인트, 복구 | 음성 세션과 업무 상태의 수명이 달라야 함 |
| 이전 선호·프로젝트 기억 | 대화 문맥, 작업 상태, 장기 기억 | 세 종류의 정보를 구분해야 함 |
| “이 화면”을 보고 도움 | 화면 캡처, 멀티모달 입력 | 화면 인식과 화면 조작 권한은 별개 |
이 표는 아래 공식 문서들을 종합한 기능 분해다. 특정 제품 하나가 모두 제공한다는 뜻은 아니다.
#2.2 음성 구조의 세 가지 선택
| 구조 | 흐름 | 적합한 목적 | 주요 부담 |
|---|---|---|---|
| 음성 대화와 실행 분리 | 음성 담당 ↔ 별도 실행 에이전트 | 대화 중에도 조사·작성·수정이 계속되는 개인 비서 | 대화와 작업 상태의 동기화 |
| 통합 음성 모델 | 음성 입력 → 모델·도구 → 음성 출력 | 자연스러운 대화와 비교적 짧은 도구 작업 | 장시간 도구 실행 시 대화 유지 방식 확인 |
| 단계별 연결 | STT → 텍스트 에이전트 → TTS | 한국어 인식·음성·모델을 개별 선택하는 시스템 | 각 단계 지연과 중단 처리를 직접 조율 |
STT는 음성을 글로 바꾸고, TTS는 글을 음성으로 바꾸는 기술이다. 단계별 방식은 중간 텍스트를 검사하거나 수정하기 쉽다. 통합 방식은 별도 전사 결과를 반드시 거치지 않고 음성을 처리할 수 있다. 특정 방식이 모든 조건에서 더 빠르거나 정확하다는 보장은 없다. 구조 비교의 근거
#2.3 OpenAI GPT-Live — 대화를 유지하며 작업을 위임
조회한 공식 문서에서 GPT-Live는 듣고 말하는 음성 대화를 담당하고, 별도 백엔드에 추론·도구 작업을 맡기는 구조다. 음성 모델과 백엔드 모델을 독립적으로 선택하며, 음성 출력을 끊어도 백엔드 작업이 자동 취소되지는 않는다. 시작 안내
위임 방식은 두 가지다.
- Responses delegation: 지정한 OpenAI Responses 모델에 백엔드 작업을 맡긴다.
- Client delegation: 개발자가 운영하는 모델·에이전트·서비스를 연결한다.
권한, 확인 절차, 실제 업무 기록, 지속되는 작업 상태는 애플리케이션이 관리한다. 사용자 정의 함수도 애플리케이션에서 실행한다. 그러므로 음성 API 연결만으로 개인 파일과 앱 제어가 모두 생기는 것은 아니다. 위임과 도구 문서
브라우저는 WebRTC, 서버 오디오 통합은 WebSocket 경로를 제공한다. 기본 시작 조건은 마이크, HTTPS 또는 localhost의 웹 페이지, 프로젝트 API 키를 보관하는 서버다. 세션 시작 확인과 실제 응답·작업 결과 확인은 따로 해야 한다. 연결 안내
평가: 사용자의 ‘대화하며 일하기’ 요구에 구조적으로 잘 맞는다. 실제 계정의 사용 가능 여부, 한국어 경험, 비용은 별도로 확인해야 한다.
#2.4 OpenAI Realtime API — 한 세션에서 음성과 도구 사용
Realtime API는 음성을 직접 처리하고 대화 상태와 도구 호출을 함께 다룬다. 공식 시작 안내는 브라우저의 WebRTC 연결과 서버의 WebSocket 연결을 구분하며, Agents SDK의 RealtimeAgent·RealtimeSession으로 음성 턴, 끼어들기, 도구, 작업 인계를 구성한다. Realtime 공식 안내
브라우저에는 서버가 만든 임시 인증값을 전달하는 흐름이 제시된다. 영구 API 키를 프런트엔드에 포함하는 방식으로 구현하지 않아야 한다. 모델·SDK·이벤트 형식은 바뀔 수 있으므로 실제 구현 때 공식 시작 예제를 기준으로 고정할 필요가 있다. 인증과 연결 흐름
평가: 대화와 짧은 작업을 연결하는 시제품에 적합한 후보다. 몇 분씩 걸리는 작업을 추가할 때는 별도 작업 등록·조회 흐름이나 비동기 실행을 함께 검토해야 한다.
#2.5 Gemini Live API — 음성·시각 입력과 도구 연결
Gemini Live API는 연속되는 오디오·이미지·텍스트 입력, 음성 응답, 끼어들기, 전사, 도구 사용을 제공한다. 화면이나 카메라 맥락을 함께 다루는 비서의 후보가 된다. Gemini Live 개요
중요한 제한은 모델별 도구 동작이 같지 않다는 점이다. 조사 시 도구 문서의 표는 Gemini 3.1 Flash Live Preview의 함수 호출을 동기식, 2.5 Flash Live Preview는 동기·비동기 지원으로 구분했다. 비동기 지원 모델에서는 도구 정의의 NON_BLOCKING과 결과 전달 시점 설정을 설명한다. 결과를 즉시 알리거나, 대화가 잠잠해질 때 알리거나, 조용히 문맥에 반영하는 선택이 있다. Live 도구 문서
같은 페이지의 예제에는 다른 모델명도 등장해 표와 예제의 갱신 상태가 완전히 일치한다고 보기 어렵다. 따라서 ‘Gemini Live 전체가 비동기 도구를 지원한다’고 일반화하지 않고, 선택할 모델의 지원표와 실제 동작을 확인해야 한다.
#2.6 LiveKit Agents — 음성 연결과 대화 운영 프레임워크
LiveKit Agents는 음성 인식·모델·음성 합성 파이프라인, 대화 턴 감지, 끼어들기, 도구와 에이전트 흐름을 구성하는 프레임워크다. 완성된 개인 비서라기보다 음성 애플리케이션을 만드는 기반에 해당한다. LiveKit 소개
특히 Async tools는 느린 작업 중에도 대화를 유지하고 중간 진행 상황을 전달하도록 설계되어 있다. 도구는 ctx.update()로 진행 정보를 전달하며, 최종 결과는 따로 반환한다. 문서는 실행 중 사용자 입력, 취소, 중복 호출 처리도 다룬다. 실제 작업에 취소 신호가 전달되도록 연결해야 한다. 비동기 도구
턴 관리에서는 사용자가 끼어들면 음성을 중단하고, 사용자가 실제로 들은 부분에 맞춰 대화 기록을 보정한다. 잘못 감지한 끼어들기 이후 발화를 재개하는 설정도 있다. 일부 적응형 기능은 배포 방식과 제공자 조건을 확인해야 한다. 턴 및 중단 처리
평가: 모델을 교체하면서 음성 경험을 세밀하게 다듬거나 여러 기기로 확장하려는 경우 검토할 가치가 크다. 도입 시 음성 서버·배포·클라이언트 운영 범위도 함께 늘어난다.
#2.7 Pipecat — 비동기 작업과 음성 파이프라인 조합
Pipecat의 공식 함수 호출 문서는 동기 도구와 대화를 막지 않는 비동기 도구를 구분한다. 조회된 버전에서는 cancel_on_interruption=False로 비동기 실행을 설정하고, cancellable_by_llm=True로 필요시 모델이 취소하도록 구성한다. 중간 진행 결과와 최종 결과도 구분해 전달할 수 있다. Pipecat 도구 호출
이 방식은 “검색하는 동안 계속 이야기하기”나 “초안 작성 도중 추가 조건 받기”의 기반이 된다. 다만 라이브러리 내부의 비동기 실행과 서버 재시작 후 복구되는 작업은 다르다. 후자는 별도 영속 작업 관리가 필요하다는 것이 조사자의 판단이다.
문서에는 과거의 일괄 비동기 취소 설정을 도구별 설정으로 바꾸는 내용도 있다. 오래된 예제와 최신 API를 혼합하기보다 설치 버전과 문서 버전을 맞춰야 한다.
#2.8 ‘그만 말해’와 ‘작업 취소’를 구분해야 한다
아래는 자비스형 비서에 적용할 권장 대화 규약이다.
| 사용자 표현 | 권장 해석 |
|---|---|
| “설명은 그만해. 계속 진행해.” | 음성 출력만 중단하고 작업 유지 |
| “보고서 작업 취소해.” | 해당 작업에 취소 요청을 보내고 실제 중단 상태 확인 |
| “비용 부분은 빼 줘.” | 진행 중인 보고서 요구 사항 수정 |
| “잠깐, 아직 저장하지 마.” | 저장 단계 보류; 준비 작업의 지속 여부는 문맥에 따라 판단 |
| “얼마나 됐어?” | 작업 기록에 근거해 진행 상태 응답 |
| “그건 됐고…” | 대상이 모호하면 필요한 부분만 짧게 확인 |
단순히 음성이 들어올 때마다 도구까지 취소하면 사용자가 맞장구를 치는 것만으로 작업이 사라질 수 있다. 반대로 명시적 취소를 음성 출력 중지만으로 처리하면 원하지 않는 작업이 계속된다. GPT-Live와 Pipecat의 문서는 음성 중단과 백엔드·도구 취소가 별도임을 보여준다. GPT-Live, Pipecat
#2.9 작업 상태와 복구
LangGraph는 실행 상태를 체크포인트로 저장하고, 같은 작업 식별자를 사용해 상태를 조회하거나 실행을 이어가는 기능을 제공한다. 사용자 입력이 필요한 지점에서 멈추고 이후 재개하는 흐름도 지원한다. 상태 저장, 중단·재개
여기서 LangGraph의 interrupt는 업무 흐름의 일시정지이며, 오디오 끼어들기와 다른 개념이다. 또한 재개 시 해당 노드가 처음부터 다시 실행될 수 있으므로 외부 행동의 중복을 막는 처리가 필요하다. 체크포인트만으로 이메일 발송·파일 덮어쓰기 등의 중복 실행이 모두 방지되지는 않는다. 재개 동작의 주의점
권장 상태 정보: 작업 ID, 목표, 최신 지시, 진행 단계, 변경 이력, 결과 파일, 오류, 취소 요청 여부. 처음부터 LangGraph를 도입할 필요는 없으며, 간단한 작업은 작은 작업 테이블로 시작하고 복잡해지면 확장할 수 있다.
#2.10 도구 연결: API·MCP·화면 조작
MCP는 AI 애플리케이션이 도구와 데이터 제공 서버에 연결하는 공통 구조를 정의한다. Host·Client·Server를 구분하며, 도구와 자료를 애플리케이션에 제공하는 역할을 한다. MCP 자체가 비서의 기억, 전체 실행 권한, 모든 앱 자동화를 완성해 주는 것은 아니다. MCP 아키텍처
조사자의 권장 연결 순서: 공식 API나 파일 인터페이스 → 필요한 MCP 연결 → 직접 연동이 어려운 부분의 화면 조작. 문서 검색·파일 저장처럼 경로가 분명한 작업은 화면 좌표에 의존하지 않는 연결을 우선 검토한다.
Mac에서 화면을 보는 기능에는 Apple의 ScreenCaptureKit이 후보가 된다. 공식 예제는 화면과 오디오 캡처를 다룬다. 하지만 캡처 API는 화면을 클릭하거나 앱을 조작하는 자동화 계층을 대신하지 않는다. Apple 화면 캡처 예제
#2.11 호출어와 로컬 처리
openWakeWord에는 영어 호출어 모델인 hey jarvis가 포함되어 있다. README는 현재 영어 지원을 명시한다. 따라서 한국어 “자비스야”도 곧바로 같은 수준으로 동작한다고 가정해서는 안 된다. 호출어를 영어로 하더라도 이후 한국어 명령 인식은 별도 음성 모델로 구성할 수 있다. openWakeWord 공식 저장소
whisper.cpp는 로컬 음성 인식 후보로, Apple Silicon의 Metal·Core ML 등 최적화와 마이크 입력 예제를 제공한다. 다만 마이크 예제는 기본적인 연속 전사 예제이며 완성된 양방향 대화 시스템은 아니다. 로컬 전사 이후의 추론, 음성 합성, 작업 실행은 별도 연결해야 한다. whisper.cpp 공식 저장소
권장: 첫 단계는 버튼이나 단축키로 대화를 시작하고, 업무 흐름이 확인된 뒤 호출어를 붙인다. 이는 항상 듣는 상태의 오탐·마이크 관리까지 처음부터 해결해야 하는 부담을 줄이기 위한 제안이다.
#2.12 한국어에 맞는 구성
국내 대안으로 NAVER Cloud의 CLOVA Speech는 gRPC 스트리밍 음성 인식을 제공하고 한국어를 지원한다. 공식 안내의 스트리밍 입력 조건은 16kHz·16bit·mono PCM이다. CLOVA Voice는 텍스트를 음성 파일로 변환하는 API를 제공한다. CLOVA Speech, CLOVA Voice
두 서비스를 연결해도 연속 대화, 작업 위임, 취소 처리가 자동으로 생기지는 않는다. 단계별 STT–에이전트–TTS 구성을 선택할 때의 부품 후보로 보는 것이 정확하다. 한국어 인식 성능의 우열은 본 조사에서 실측하지 않았다.
검증할 표현은 일반 문장보다 실제 업무 표현이 중요하다. 예를 들어 “KERYDOS에 저장해”, “지난번 자비스 기획안”, “비용은 빼고”, “아까 첫 번째 작업만 취소” 같은 고유명사·생략·수정 지시를 시험해야 한다. 이는 사용자 환경에 맞춘 평가 제안이다.
#2.13 집과 공간까지 확장하는 경우
Home Assistant Assist는 자연어로 스마트홈을 제어하고, 자체 하드웨어에서 실행하는 구성을 지원한다. 앱·전용 음성 기기·직접 만든 장치로 접근할 수 있으며 로컬 처리나 LLM 연결을 선택할 수 있다. Home Assistant Assist
평가: 조명·센서·집 안 장치가 목표에 들어오면 좋은 연결 후보다. 웹 조사와 문서 작성 중심의 업무 비서에는 별도의 실행 에이전트가 필요하다. 초기 단계에서 두 범위를 모두 구현하기보다 실제로 가장 자주 사용할 업무부터 시작하는 편이 낫다.
#3. 빈도 — 공식 자료에서 반복되는 기술 방향
#3.1 여러 생태계가 공통으로 다루는 문제
| 반복 주제 | 확인한 공식 자료 | 의미 |
|---|---|---|
| 대화와 오래 걸리는 실행 분리 | GPT-Live, LiveKit, Pipecat | 단순 순차 음성 챗봇을 넘어 작업 중 대화를 유지하려는 방향 |
| 끼어들기와 턴 판단 | LiveKit, Gemini Live, Realtime | 자연스러움은 목소리 품질 외에 발화 타이밍에 좌우됨 |
| 중간 결과와 완료 통지 | LiveKit Async tools, Pipecat | 사용자가 기다리는 동안 실제 상태를 전달 |
| 지속되는 작업 상태 | LangGraph, GPT-Live의 앱 책임 설명 | 음성 연결과 업무 수명을 별도로 관리 |
| 실행 도구의 연결 | MCP, 각 음성 플랫폼 도구 문서 | 음성을 실제 행동으로 바꾸는 외부 계층이 중요 |
이 비교는 공식 문서의 정성적 분석이다. 시장 점유율이나 언급량을 통계적으로 측정한 결과는 아니다.
#3.2 기존 Jarvis OS 조사와의 연결
앞서 조사한 battlesbudz/jarvis-os도 연속 음성과 동시 작업 실행을 개발 목표로 다룬다. 이슈 #280은 대화를 유지하면서 작업을 실행하고 음성 중지·듣기 중지·작업 취소를 구분하려는 방향을 제시한다. 이는 사용자의 목표와 가깝지만, 이슈의 요구 사항을 완성된 기능으로 받아들이면 안 된다. Jarvis OS 음성 개발 이슈
관련 기존 조사: 자비스 OS 개인 AI 비서 프로젝트 상세 조사
해석: 특정 Jarvis 저장소를 반드시 기반으로 해야 하는 것은 아니다. 해당 저장소는 전체 제품 구조의 참고 자료이고, 이번에 확인한 실시간 음성 플랫폼은 원하는 상호작용을 만드는 직접적인 기술 후보다.
#3.3 국내 자료로 보완할 수 있는 영역
국내 공식 자료에서는 한국어 음성 인식·합성 API를 확인했다. 반면 한국어 개인 비서의 연속 대화, 장시간 업무 수행, 복구를 한꺼번에 비교한 독립 벤치마크는 확보하지 못했다. 영어 데모가 자연스럽다는 이유만으로 한국어 업무 환경에서도 같은 결과를 기대하지 않아야 한다.
#4. 추천 — 사용자의 목표에 맞는 구축 방향
#4.1 우선 검토할 세 경로
다음은 조사에 근거한 선택안이며 아직 구현이나 제품 구매를 결정한 것은 아니다.
| 경로 | 구성 | 선택하면 좋은 상황 |
|---|---|---|
| A. 대화 경험 우선 | GPT-Live + 별도 작업 실행 서비스 + 로컬 파일 도구 | 영화처럼 대화를 이어가며 업무를 맡기는 경험이 가장 중요할 때 |
| B. 구성 교체·확장 우선 | LiveKit 또는 Pipecat + 선택한 음성 모델 + 동일한 작업 실행 서비스 | 여러 음성 제공자를 비교하고 모바일 등으로 확장할 때 |
| C. 로컬 데이터 처리 우선 | 로컬 STT + 로컬 추론 + 한국어 TTS + 작업 실행 서비스 | 외부 전송을 최소화하는 것이 최우선일 때 |
A를 첫 검증 후보로 삼되 계정 접근성과 한국어 품질을 확인하는 것이 합리적이다. B에서 LiveKit과 Pipecat을 모두 넣을 필요는 없다. C는 하드웨어·모델 조합에 따라 속도와 한국어 품질 편차가 크므로 완전 로컬이라는 조건만으로 적합성을 판단하기 어렵다.
#4.2 권장 개념 구조
아래는 사용자 요구를 위한 제안 구조이며 특정 제품의 완제품 구성이 아니다.
flowchart TD
U[사용자 음성] --> V[실시간 대화 담당]
V --> O[음성 응답 · 짧은 상태 안내]
V --> R[작업 요청 · 수정 · 취소]
R --> W[작업 실행 담당]
W --> T[노트 검색 · 웹 조사 · 파일 작성]
W --> S[(작업 상태 · 최신 지시 · 결과 경로)]
W --> E[확인된 진행 · 완료 이벤트]
E --> V
T --> F[문서 · 파일 · 화면 결과]
F --> U2[사용자 확인]
M[(선호 · 승인된 장기 기억)] --> W음성은 결론과 선택지를 짧게 전달하고, 긴 보고서·표·출처는 파일이나 화면으로 제공한다. “완료했습니다”는 실제 저장이나 도구 실행 결과를 확인한 뒤 말하도록 구성한다. 이는 대화의 자연스러움과 작업의 신뢰성을 함께 확보하기 위한 제안이다.
#4.3 첫 버전의 범위
현재 작업 환경이 Mac과 Obsidian 볼트라는 점을 고려하면, 다음 세 업무로 시작하는 방안을 제안한다.
- 노트 찾기: “지난번 자비스 계획 찾아서 핵심만 말해 줘.”
- 웹 조사 후 저장: “이 기술 조사해서 Inbox에 마크다운으로 저장해 줘.”
- 작업 도중 변경: “그 보고서에 로컬 실행 방식도 추가해 줘.”
완료 기준은 음성으로 요청한 뒤 파일이 생성되고, 중간 변경이 반영되고, 작업 중에도 다른 질문에 답할 수 있는 것이다. 첫 버전의 기억은 작업 상태와 필요한 사용자 선호 정도로 제한해도 된다. 모든 대화를 자동으로 장기 기억에 넣는 기능은 후속 과제로 둘 수 있다.
#4.4 단계별 검증 순서
| 단계 | 추가할 기능 | 다음 단계로 넘어갈 기준 |
|---|---|---|
| 1 | 마이크 입력과 음성 응답 | 한국어 대화와 끼어들기가 안정적으로 작동 |
| 2 | 노트 검색·파일 생성 | 실제 파일과 출처를 확인할 수 있음 |
| 3 | 백그라운드 작업 | 긴 작업 중 대화가 멈추지 않음 |
| 4 | 수정·취소·재접속 | 변경 지시 반영, 취소 상태 확인, 중복 작업 방지 |
| 5 | 호출어 | 원하는 발화에 반응하고 주변 소리에 과도하게 깨지 않음 |
| 6 | 화면·모바일·집 안 장치 | 실제 필요한 기기부터 개별 추가 |
이는 개발 일정이 아니다. 기기, 제공자, 계정 연결과 품질 요구가 정해지지 않아 소요 기간은 추정하지 않았다.
#4.5 반드시 구분해 측정할 항목
| 항목 | 측정 방법 |
|---|---|
| 첫 응답 지연 | 사용자 발화 종료부터 첫 음성 출력까지 |
| 끼어들기 반응 | 사용자가 말하기 시작한 뒤 비서 출력이 멈추기까지 |
| 작업 완료 시간 | 작업 접수부터 실제 결과물 확보까지 |
| 지시 수정 성공률 | 수정 요청이 최종 결과에 정확히 반영된 비율 |
| 취소 성공 | 작업 상태와 실제 외부 행동이 모두 취소와 일치하는지 |
| 복구 신뢰성 | 재접속·재시작 후 결과와 상태가 이어지고 중복되지 않는지 |
| 한국어 실용성 | 고유명사·숫자·부정·생략 표현의 실제 처리 결과 |
| 비용 | 대화 시간과 작업별 모델·도구 사용량을 별도로 기록 |
평균값뿐 아니라 느린 경우도 기록해야 한다. 빠르게 “네”라고 답했지만 실제 작업은 실패한 경우를 성공으로 세지 않는 것이 중요하다. 본 조사에서는 수치를 직접 측정하지 않았으며 특정 지연 시간이나 성공률을 보장하지 않는다.
#4.6 비용과 운영에서 확인할 점
GPT-Live 공식 문서는 음성 세션을 시간 기준으로 과금하고 백엔드 모델·도구 사용을 별도 계산한다고 설명한다. 따라서 대화 비용과 실제 업무 비용을 분리해 보아야 한다. 정확한 단가는 구축 시 선택한 모델의 공식 요금표로 다시 확인해야 한다. 과금 구조 설명
전체 비용은 음성 처리, 추론, 검색·외부 서비스, 저장·서버, 유지보수로 나눠 기록하는 것을 권한다. 호출어를 로컬로 처리하더라도 활성 음성 세션과 업무 실행까지 무료가 되는 것은 아니다.
권한은 작업의 목적과 연결해야 한다. 음성으로 승인된 작업 범위를 실행 서비스가 확인하고, 외부 문서나 웹페이지의 내용을 새로운 사용자 지시로 받아들이지 않도록 해야 한다. 파일은 허용한 폴더에 저장하고, 실제 효과가 있는 작업은 결과와 실패 이력을 남기는 구성이 적절하다. 이는 개인 파일·계정에 접근하는 비서를 위한 설계 제안이다.
#4.7 결론
사용자가 원하는 자비스형 비서는 현재의 실시간 음성 모델과 작업 실행 기술을 결합해 제한된 업무부터 구축할 수 있다. 가장 잘 맞는 출발점은 대화를 유지하는 음성 계층과 실제 일을 수행하는 실행 계층을 분리하고, 노트 검색·웹 조사·마크다운 저장을 하나의 완결된 흐름으로 검증하는 것이다.
기술 문서에서 기능의 존재는 확인했지만, 사용자 환경에서의 한국어 품질·기기 호환·비용·복구 신뢰성은 아직 검증하지 않았다. 다음 의사결정에서는 화려한 음성 데모보다 “작업 중 추가 지시가 반영된 결과 파일을 받을 수 있는가”를 우선 평가하는 것이 좋다.
#5. 참조 사이트
#실시간 대화와 작업 실행
- OpenAI — Voice agents: 세 가지 음성 구조 비교.
- OpenAI — GPT-Live: 대화와 백엔드 분리, 연결, 과금 구조.
- OpenAI — GPT-Live delegation and tools: 실행 위임과 애플리케이션의 책임.
- OpenAI — Realtime API: 음성 세션·도구·WebRTC.
- Google — Gemini Live API: 음성·시각 입력과 실시간 대화.
- Google — Live API tools: 동기·비동기 도구와 모델별 차이.
- LiveKit Agents: 음성 애플리케이션 프레임워크.
- LiveKit — Async tools: 작업 중 대화, 진행·취소·중복 처리.
- LiveKit — Turns overview: 턴 판단과 끼어들기.
- Pipecat — Function Calling: 비동기 도구와 중간 결과.
#실행 상태·기기·로컬 음성
- LangGraph — Persistence: 체크포인트와 실행 상태.
- LangGraph — Interrupts: 사용자 입력 대기와 재개.
- MCP — Architecture: 도구·데이터 연결 구조.
- Apple — ScreenCaptureKit 예제: Mac 화면과 오디오 캡처.
- openWakeWord: 호출어와 언어 지원 한계.
- whisper.cpp: 로컬 음성 인식과 Apple Silicon 지원.
- Home Assistant — Assist: 음성 스마트홈 제어.
#국내 자료와 이전 조사 연결
- NAVER Cloud — CLOVA Speech: 한국어 스트리밍 음성 인식.
- NAVER Cloud — CLOVA Voice: 한국어 음성 합성 API.
- Jarvis OS — Continuous Voice and Concurrent Task Execution: 개인 비서 프로젝트의 음성·동시 작업 계획.
자료 해석 한계: 공식 문서는 기능과 사용법의 1차 근거지만 제품 간 우열을 입증하는 독립 평가 자료는 아니다. 문서의 수집 시점과 실제 서비스 버전이 다를 수 있으며, 특히 프리뷰 모델·비동기 도구 설정·SDK는 구현 전에 재확인해야 한다.