Inithouse의 Voice Tables로 전달되는 음성 입력의 약 82%가 첫 번째 통과 시 정확한 테이블 스키마(Table schema)로 해결됩니다. 나머지 18%는 후속 확인 절차가 필요합니다. 이 비율을 달성하기 위해 수개월 동안 파이프라인 튜닝(Pipeline tuning)을 거쳤으며, 이 수치들이 우리의 아키텍처(Architecture) 결정 대부분을 형성했습니다.

Voice Tables는 여러 제품 포트폴리오를 병렬로 출시하고 있는 스튜디오인 Inithouse에서 구축한 에이전틱 AI(Agentic AI) 워크스페이스입니다. 사용자가 필요한 내용을 말로 설명하면, Voice Tables가 사용자를 위해 테이블, 문서 및 데이터를 구축합니다. "이름, 이메일, 프로젝트, 마지막 연락 날짜 컬럼이 포함된 프리랜서 클라이언트용 CRM이 필요해"라고 말하면 약 60초 안에 구조화된 워크스페이스를 얻을 수 있습니다.

이 포스트에서는 음성-구조화(Speech-to-structure) 파이프라인과 실제 운영 환경에서의 지연 시간(Latency) 및 파싱(Parsing) 데이터가 어떤 모습인지 살펴봅니다.

파이프라인: 음성에서 구조화된 데이터로

시스템은 세 가지 단계로 구성되며, 각 단계는 고유한 지연 시간 프로필(Latency profile)을 가집니다:

1단계: 음성-텍스트 변환 (Speech-to-text, Whisper). 오디오가 OpenAI의 Whisper 모델로 전달됩니다. 일반적인 발화(515초 분량의 음성)의 경우, 전사(Transcription)에는 400900ms가 소요됩니다. 입력이 길어지면 선형적으로 증가합니다. 우리는 침묵으로 구분된 세그먼트(Segments)를 배치 처리(Batch process)하므로, 30초 분량의 장황한 설명은 2~3개의 청크(Chunks)로 나뉘어 병렬로 처리됩니다.

2단계: 의도 파싱 (Intent parsing, LLM). 전사된 텍스트는 LLM으로 전달되어 구조화된 의도를 추출합니다: 어떤 종류의 워크스페이스인지, 어떤 컬럼이 필요한지, 데이터 타입은 무엇인지, 제약 조건은 무엇인지 등을 파악합니다. 82%의 정확도 수치가 바로 여기서 나옵니다. LLM은 컬럼 타입(텍text, number, date, email, URL)을 결정하고 엔티티(Entities) 간의 관계를 추론합니다.

파싱(Parsing)은 복잡도에 따라 800~1400ms가 소요됩니다. "날짜, 금액, 카테고리가 포함된 지출 추적기"와 같은 간단한 요청은 1초 미만 내에 파싱됩니다. 반면 "작업, 담당자, 마감일, 의존성, 그리고 상태별로 그룹화된 칸반(Kanban) 뷰가 포함된 프로젝트 관리 보드"와 같은 요청은 LLM이 암시된 뷰 설정(View configuration)을 해결해야 하므로 전체 1400ms가 소요됩니다.

3단계: 스키마 생성 및 작업 공간 구축(Schema generation and workspace build). 파싱된 의도(intent)는 테이블 스키마, 기본 뷰(default view), 그리고 선택적으로 문서 템플릿으로 컴파일됩니다. 이 단계는 결정론적이며 빠릅니다: 100~200ms가 소요됩니다.

전체 종단 간(end-to-end) 처리 시간은 음성 입력이 일반적으로 자체적인 음성 지속 시간 외에 1.3~2.5초의 처리 시간을 통해 사용 가능한 작업 공간을 생성한다는 것을 의미합니다. 사용자 입장에서는 원하는 바를 설명하고 그것이 나타나는 것을 보는 느낌과 같습니다.

의도 파싱이 실패하는 경우(Where intent parsing breaks down)

그 18%의 실패율은 우리가 추적하는 세 가지 패턴으로 분류됩니다:

모호한 열 유형(Ambiguous column types) (실패 사례의 8%).

신뢰도 기반 명확화 (Confidence-gated clarification). 항상 스키마 (Schema)를 생성하고 결과가 좋기를 바라는 대신, 우리는 신뢰도 임계값 (Confidence threshold)을 추가했습니다. 파싱 (Parsing) 신뢰도가 0.7 미만으로 떨어지면, Voice Tables는 무언가를 구축하기 전에 타겟팅된 후속 질문을 던집니다. "연락처를 언급하셨습니다. 이것이 이메일 주소 목록이어야 하나요, 이름이어야 하나요, 아니면 다른 테이블로의 링크여야 하나요?" 이 방식은 모호한 유형 (Ambiguous-type) 실패 사례의 대부분을 잡아내며, 약 3초의 추가 상호작용이 발생합니다. 사용자들은 잘못된 스키마를 받고 다시 구축하는 것보다 이 방식을 선호합니다.

점진적 스키마 정교화 (Progressive schema refinement). 생성 후 스키마를 고정하는 대신, 사용자가 음성으로 수정할 수 있도록 했습니다. 초기 구축 후 "상태(status) 열을 To Do, In Progress, Done이 포함된 드롭다운으로 만들어줘"와 같은 음성 명령이 작동합니다. 이는 파싱 오류 (Parsing errors)의 비용을 줄여주었는데, 첫 번째 시도가 틀리더라도 수동으로 구조를 재조정하는 대신 한 문장만으로 수정할 수 있기 때문입니다.

지연 시간 예산 (The latency budget)

우리는 표준 입력에 대해 음성에서 워크스페이스 (Voice-to-workspace)까지 3초 미만이라는 내부 목표를 설정했습니다. 예산이 사용되는 내역은 다음과 같습니다:

단계	p50	p95
Whisper 전사 (Transcription)	550ms	1100ms
...

단일 엔티티 (Single-entity) 입력의 경우 p95는 3초 미만을 유지합니다. 다중 엔티티 (Multi-entity) 발화는 세그멘테이션 (Segmentation) 단계 때문에 4초를 넘길 수 있지만, 이는 발생 빈도(입력의 약 12%)가 충분히 낮기 때문에 해당 트레이드오프 (Tradeoff)를 수용했습니다.

우리는 Inithouse의 다른 제품에서도 유사한 LLM 지연 시간 (LLM-latency) 제약에 직면했습니다. AI 엔진이 브랜드를 어떻게 설명하는지 모니터링하는 Be Recommended는 5개의 모델을 병렬로 추론 (Inference)하며 자체적인 응답 시간 예산 문제를 해결해야 했습니다. Gottman 및 EFT 프레임워크를 사용하는 AI 갈등 중재 도구인 Verdict Buddy는 각 턴이 누적되는 컨텍스트 (Context)에 추가되는 다회차(Multi-turn) LLM 추론을 처리합니다. 제품마다 트레이드오프는 다르지만 패턴은 반복됩니다: 지연 시간 상한선(Latency ceiling)을 설정하고, 시간이 어디에 소요되는지 측정하며, 가장 비중이 큰 단계에서 시간을 절감하는 것입니다.

다음에 주시하고 있는 것

82%의 1차 통과 정확도(first-pass accuracy)는 도입하기에 충분히 좋은 수준이지만, 확인 단계(clarification step)를 완전히 제거할 수 있을 만큼 충분하지는 않습니다. 우리는 각 사용자의 과거 입력값에서 추출한 퓨샷 예시(few-shot examples)를 활용하여 실험을 진행하고 있습니다. 초기 신호에 따르면, 5개 이상의 워크스페이스(workspace)를 구축한 사용자는 1차 통과 정확도가 90%에 더 가깝게 나타나는데, 이는 모델이 사용자가 선호하는 컬럼 명명 패턴(column naming patterns)과 전형적인 사용 사례(use cases)에 대한 문맥(context)을 파악하고 있기 때문입니다.

워크스페이스를 말로 설명하여 파이프라인(pipeline)이 무엇을 구축하는지 직접 확인해보고 싶다면, Voice Tables는 voicetables.com에서 바로 이용 가능합니다.

병렬적인 제품 실험을 운영하는 스튜디오인 Inithouse에서, 우리는 이러한 수치들을 공개합니다. 왜냐하면 이것이 무엇이 효과적인지 파악하는 가장 빠른 방법이기 때문입니다. 포트폴리오의 더 많은 파이프라인 분석(pipeline breakdowns) 결과도 곧 공개될 예정입니다.