Voice Tables에서 말로 한 문장을 말한 시점부터 데이터가 채워진 워크스페이스가 생성될 때까지의 중앙값(median time)은 58초입니다. 우리는 이 초들이 실제로 어디에 쓰이는지 파악하기 위해 4주 동안 847개의 음성 세션(voice sessions)을 측정했습니다.

Voice Tables는 목소리로 제어하는 에이전트형 AI 워크스페이스(agentic AI workspace)입니다. 필요한 것(CRM, 트래커, 인벤토리 등)을 설명하면, 시스템이 사용자를 위해 테이블, 문서 및 데이터를 구축합니다. Inithouse에서 우리는 하나의 가설을 테스트하기 위해 이를 출시했습니다: '음성-to-구조화된-데이터(voice-to-structured-data)' 방식이 수동 설정보다 한 자릿수(an order of magnitude) 더 빠를 수 있다는 것입니다. 데이터는 그것이 가능하다는 것을 보여주었지만, 세부 내역은 우리를 놀라게 했습니다.

58초는 어디로 가는가

우리는 파이프라인(pipeline) 전체를 계측(instrumented)했습니다. 모든 음성 세션은 다섯 가지 체크포인트에서 타임스탬프를 기록합니다: 오디오 캡처 종료, 전사(transcription) 완료, 스키마(schema) 생성, 데이터 채우기, 워크스페이스 렌더링.

스키마 생성(Schema generation)이 가장 큰 비중을 차지합니다. LLM(대규모 언어 모델)은 단 하나의 음성 설명으로부터 컬럼(column) 유형, 관계, 그리고 기본값을 추론해야 합니다. 이는 전사(transcription)보다 더 어려운 문제입니다. Whisper는 일반적인 입력 길이(1030단어)에 대해 5초 미만으로 완료되지만, 후속 추론(downstream reasoning)에는 그보다 45배의 시간이 필요합니다.

어떤 유형의 프롬프트가 작동하는가

모든 음성 입력이 사용 가능한 워크스페이스를 생성하는 것은 아닙니다. 847개의 세션 중 714개(84%)가 사용자가 유지한 워크스페이스를 생성했습니다. 나머지 133개는 예측 가능한 범주에 속했습니다.

구체적인 명사가 승리합니다. "배관 고객을 위한 CRM이 필요해"는 작동합니다. "내 물건들을 정리할 무언가가 필요해"는 작동하지 않습니다. 이름이 지정된 도메인 객체(client, invoice, property, recipe)를 포함하는 프롬프트의 성공률은 91%였습니다. 그러한 객체가 없는 프롬프트의 경우 62%로 떨어졌습니다.

구체성이 길이보다 더 중요합니다. 우리는 프롬프트가 길수록 더 나은 결과를 낼 것이라고 예상했습니다. 하지만 그렇지 않았습니다. 명확한 명사가 포함된 다섯 단어의 프롬프트("track my freelance invoices")는 89%의 성공률을 기록했습니다. 반면, 추상적인 상태를 유지한 스무 단어의 프롬프트("I want a system where I can manage everything related to my work and personal life")는 58%의 성공률을 기록했습니다.

프롬프트 내의 숫자는 스키마 (schema) 품질을 향상시킵니다. 사용자가 "five columns"(5개의 열) 또는 "three categories"(3개의 카테료리) 또는 "ten items"(10개의 항목)라고 말했을 때, 생성된 스키마가 기대치와 일치하는 경우는 94%였습니다. 수치적 힌트가 없었을 때 스키마 정확도는 76%로 떨어졌습니다. 우리는 수치적 구체성이 이 정도로 큰 비중을 차지할 것이라고 예상하지 못했지만, LLM은 숫자를 강력한 구조적 제약 조건 (structural constraints)으로 취급합니다.

진짜 병목 현상은 전사 (transcription)가 아닙니다

이 측정을 실행하기 전, 우리 팀은 전사 (transcription) 과정이 병목 현상이 될 것이라고 가정했습니다. Whisper는 오디오에 대해 추론 (inference)을 수행하며, 억양, 배경 소음, 마이크 품질 등을 처리해야 합니다. 스키마 생성은 LLM에 대한 "단순한" 텍스트 프롬프트일 뿐이라고 생각했습니다.

데이터는 그 가정을 뒤집었습니다. 전사는 빠르고 신뢰할 수 있습니다 (명확한 실내 오디오의 경우 오류율 3% 미만). 스키마 생성은 모호함 (ambiguity)이 존재하는 지점입니다. "my projects"(내 프로젝트)와 같은 문구는 칸반 보드 (Kanban board), 청구 추적기 (billing tracker), 또는 연구 노트 (research notebook)를 의미할 수 있습니다. LLM은 그중 하나의 해석을 선택하며, 때로는 틀린 선택을 하기도 합니다.

우리는 두 가지 완화 (mitigations) 방법을 시도했습니다:

우리는 두 가지 완화(mitigations) 방법을 시도했습니다:

1. 명확화 프롬프트 (Clarification prompts). LLM의 신뢰도 점수(confidence score)가 0.7 미만으로 떨어지면, Voice Tables는 스키마를 생성하기 전에 후속 질문을 합니다. 이로 인해 영향을 받은 세션에 약 6초가 추가되었고(전체 중 약 22 %), 후속 질문을 받은 코호트의 유지율(keep-rate)은 84%에서 89%로 상승했습니다.

2. 템플릿 매칭 (Template matching). 가장 흔한 사용 사례 10가지(CRM, 재고 관리, 예산 추적기, 프로젝트 보드, 이벤트 플래너 등)에 대해 스키마 템플릿을 미리 구축했습니다. 음성 입력이 코사인 유사도(cosine similarity)가 0.85를 초과하는 알려진 카테고리와 일치할 경우, 개방형 생성 대신 해당 템플릿이 작동합니다. 템플릿 매칭 세션은 중앙값(median)으로 34초가 소요되어 전체 평균보다 41% 더 빨랐습니다.

음성 우선 도구에 대한 시사점 (What this means for voice-first tools)

음성을 데이터로 변환하는 파이프라인은 현실입니다. Voice Tables는 말한 문장부터 작동하는 워크스페이스까지 1분 이내로 갈 수 있음을 증명합니다. 하지만 '1분 이내'라는 것이 균일한 경험을 의미하지는 않습니다. 분포 범위는 (템플릿 매칭, 구체적 프롬프트의 경우) 28초에서 (모호한 프롬프트와 명확화 루프가 결합된 경우) 94초까지 다양합니다.

Inithouse에서는 여러 제품 포트폴리오를 병렬로 출시하고 있습니다. 사진 애니메이션을 위한 Ziva Fotka, 대화 카드를 위한 Here We Ask, 자기 발견을 위한 Origin Of You 등 포트폴리오 전반에 걸쳐 동일한 패턴이 나타납니다. 즉, 1차적인 기술적 난제(음성 인식, 이미지 처리, 성격 모델링)가 병목 지점인 경우는 드뭅니다. 병목 지점은 원시 입력(raw input)을 구조화된 출력으로 변환하는 해석 계층(interpretive layer)입니다.

특히 음성 우선 도구의 경우: 전사(transcription)가 아닌 스키마 생성에 투자해야 합니다. Whisper(또는 동등한 기술)는 소비자 수준에서 이미 해결된 문제입니다. 말로 된 의도(spoken intent)를 구조화된 데이터로 매핑하는 것이 그렇지 않습니다.

Inithouse([https://inithouse.com])에서 구축되었으며, 여러 제품을 병렬로 출시하는 연구소입니다. Voice Tables는 voicetables.com에서 라이브 중입니다.