단 한 문장의 말로 10초 이내에 사용 가능한 테이블 스키마(table schema)를 생성할 수 있습니다. 양식(form) 기반의 빌더는 동일한 결과를 얻는 데 약 2분이 소요됩니다. 우리는 Inithouse에서 Voice Tables를 구축하는 동안 이를 반복적으로 측정했으며, CRM, 인벤토리(inventories), 프로젝트 트래커(project trackers), 이벤트 로그(event logs) 등 다양한 사용 사례에서 이 격차가 유지됨을 확인했습니다.

논지는 간단합니다: 자연어 음성은 클릭 방식의 양식 빌더보다 스키마 정보를 더 밀도 있게 인코딩(encode)합니다.

음성 문장이 담고 있는 것

누군가가 "이름, 이메일, 시간당 요율, 프로젝트 상태, 마지막 연락 날짜와 함께 내 프리랜서 고객들을 추적하고 싶어"라고 말할 때, 그들은 다음을 전달하고 있습니다:

• 테이블 이름 (freelance clients)
• 암시적 타입(implicit types)을 가진 5개의 컬럼 (text, text, number, enum, date)
• 제약 조건 (hourly rate는 자유 텍스트가 아닌 숫자임)
• 관계 힌트 (project status는 고정된 값의 집합을 시사함)

양식 빌더는 이 각각의 항목을 별도로 요구합니다. 테이블 이름을 지정하세요. 컬럼을 추가하세요. 타입을 선택하세요. 제약 조건을 설정하세요. 반복하세요. 정보는 이미 문장 안에 있었습니다. 양식은 단지 당신이 그것을 조각조각 다시 입력하게 만들 뿐입니다.

우리가 구축한 파이프라인

Voice Tables는 3단계 파이프라인으로 작동합니다:

브라우저 마이크 → Whisper API (전사/transcription)
  → 함수 호출(function calling) 기능이 있는 LLM (스키마 추출/schema extraction)
    → Supabase (테이블 생성 + 실시간 동기화/real-time sync)

핵심 단계는 함수 호출(function calling) 기능이 있는 LLM입니다. 이 모델은 전사된 텍스트와 출력을 엄격한 JSON 스키마로 제한하는 시스템 프롬프트(system prompt)를 전달받습니다. 이 스키마에는 이름, 타입(text, number, date, boolean, enum), 선택적 제약 조건, 그리고 테이블 간의 관계를 포함한 컬럼 정의가 포함됩니다.

사용자가 "내 부동산 관람 내역을 추적해줘: 고객 이름, 전화번호, 주소, 관람 날짜, 1에서 5까지의 피드백 점수, 그리고 후속 조치를 원하는지 여부"라고 말하면, 모델은 다음과 같이 출력합니다:

{
  "table_name": "Property Viewings",
  "columns": [
...

템플릿을 찾아 헤맬 필요도, 컬럼 유형(column-type) 드롭다운을 클릭할 필요도 없습니다. 스키마는 사용자가 설명한 내용과 일치합니다. 테이블은 몇 초 안에 워크스페이스에 나타납니다.

효과적인 활용 사례

음성-스키마 변환(Voice-to-schema)은 사람들이 대화 중에 이미 유창하게 설명하는 구조화된 데이터(structured data)에 가장 효과적입니다.

연락처 목록 및 CRM. "이름, 회사, 이메일, 전화번호, 거래 단계(deal stage), 예상 종료일(expected close date)이 포함된 고객 목록이 필요해." 사람들은 회의 중에 이런 내용을 항상 설명합니다. 스키마가 이미 그들의 어휘 속에 들어 있습니다.

이벤트 및 활동 로그. "내 운동 세션을 기록해줘: 날짜, 운동 종류, 세트, 횟수, 무게." 명확한 숫자 필드를 가진 짧고 규칙적인 입력 항목들입니다. 음성은 그 어떤 스프레드시트 템플릿보다 이를 더 빠르게 처리합니다.

재고 및 카탈로그. "내 바이닐 컬렉션을 카탈로그화해줘: 아티스트, 앨범, 연도, 상태, 그리고 오리지널 슬리브 보유 여부." 수집가들은 자신의 카테고리를 완벽하게 숙지하고 있습니다.

공통점은 다음과 같습니다: 사용자가 자신의 데이터에 대한 명확한 멘탈 모델(mental model)을 가지고 있다는 점입니다. 음성은 사용자가 UI를 통해 번역하는 대신, 그 모델을 직접 쏟아낼 수 있게 해줍니다.

한계점

우리는 실제적인 한계에 부딪혔습니다. 솔직하게 말씀드리자면 다음과 같습니다:

모호한 유형 판별(Ambiguous type resolution). "우선순위 필드를 추가해줘"라고 했을 때, 이것이 숫자(1-5)인지, 열거형(enum, low/medium/high)인지, 아니면 자유 텍스트인지 어떻게 알까요? LLM(Large Language Model)은 문맥을 바탕으로 추측하며, 약 15%의 확률로 잘못 추측합니다. 폼 빌더(Form builders)는 사용자가 명시적으로 선택할 수 있게 해줍니다.

복잡한 다중 테이블 스키마. "태스크, 하위 태스크, 팀원, 그리고 타임 엔트리(time entries)가 포함된 프로젝트 트래커가 필요해. 각 태스크는 프로젝트에 속해야 하고, 각 태스크는 팀원과 연결된 여러 개의 타임 엔트리를 가져야 해." 이 방식도 작동은 하지만, 중첩(nesting)이 심해질수록 관계 추출(relationship extraction)이 불안정해집니다. 테이블이 두 개일 때는 신뢰할 수 있지만, 상호 참조(cross-reference)가 포함된 테이블이 네 개가 되면 관계 그래프(relationship graph)의 정확도는 대략 70% 수준으로 떨어집니다.

소음이 있는 환경. Whisper는 배경 소음을 잘 처리하지만, 시끄러운 환경에서의 전문 용어는 전사(transcription) 오류를 일으키며, 이는 잘못된 컬럼 이름으로 이어지는 연쇄 반응을 일으킵니다. "client"를 "climb"로 잘못 듣게 되면 터무니없는 스키마가 생성됩니다.

수정 및 반복 작업. 기존 스키마를 음성으로 수정하는 것(