OpenAI Realtime API를 사용하여 음성 우선 및 화면 인식 제품 가이드를 구축한 방법

대부분의 인앱 온보딩 (in-app onboarding) 도구들은 사용자에게 무엇을 해야 할지 알려줍니다. 툴팁을 띄우거나, 체크리스트를 대기열에 넣거나, AI가 한 단락을 타이핑하면 사용자가 이를 클릭으로 번역해야 하는 채팅창을 엽니다. 우리는 그 반대를 원했습니다. 사용자가 소리 내어 말할 수 있고, 음성으로 답변하며, 위치를 설명하는 대신 커서를 정확한 버튼으로 이동시키는 가이드 말입니다.

이 글은 해당 가이드 뒤에 숨겨진 아키텍처 결정 사항, 우리가 직면했던 트레이드오프 (tradeoffs), 그리고 오늘날 실시간 음성 기능을 구축하려는 누구에게나 해주고 싶은 조언을 정리한 것입니다.

왜 STT → LLM → TTS가 아닌 음성 대 음성(voice-to-voice)인가

전통적인 음성 파이프라인은 세 단계로 이루어집니다: 음성-텍스트 변환 (speech-to-text, STT), 그 다음 채팅 완성 (chat completion), 마지막으로 텍스트-음성 변환 (text-to-speech, TTS)입니다. 각 단계는 지연 시간 (latency)을 추가하며, 그 경계가 드러납니다. 어시스턴트가 직렬적으로

데스크톱 버전에서는 Apple의 ScreenCaptureKit을 기반으로 작동하며, 임베드 가능한 웹 버전에서는 범위가 지정된 DOM 스냅샷(scoped DOM snapshot)을 사용합니다. 어떤 방식이든, 가이드는 질문이 들어온 시점의 컨텍스트를 확인하고, 답변하며, 그 후에는 잊어버립니다. 이를 통해 개인정보 보호(privacy) 측면의 정직함을 유지하고, 토큰 비용을 세션 유지 시간(time-open)이 아닌 실제 사용량에 비례하도록 관리할 수 있습니다.

커서 가리키기: 사용자가 실제로 체감하는 부분

온보딩(onboarding)의 느낌을 바꾸는 기능은 바로 커서의 움직임입니다. 모델이 대상 요소를 식별하면, 가이드는 사용자의 커서를 해당 요소로 애니메이션화하여 이동시키고 강조 표시합니다. 기술적 지식이 없거나 막막해하는 사용자에게는 버튼에 대해 생성된 문장을 읽는 것보다, 버튼을 직접 보여주는 것이 훨씬 더 빠릅니다.

어려운 점은 애니메이션이 아니라, 레이아웃과 뷰포트(viewport)가 변하더라도 "베벨 도구(the bevel tool)"나 "게시 버튼(the publish button)"을 화면상의 안정적인 대상으로 찾아내는 것입니다. 우리는 픽셀 좌표 대신 시맨틱 셀렉터(semantic selectors; 역할(roles), ARIA 레이블, 가시적 텍스트)에 의존합니다. 좌표는 레이아웃이 바뀌는 순간 깨지기 때문입니다. 이는 브라우저 자동화(browser automation)를 수행하는 사람이라면 누구나 배우게 되는 교훈과 같습니다. 무엇을 찾고 있는지(what)를 설명해야지, 그것이 우연히 어디에 있었는지(where)를 설명해서는 안 됩니다.

자체 콘텐츠를 통한 학습

일반적인 모델은 일반적인 도움을 제공합니다. 가이드가 귀하의 제품 말투로 답변하고, 귀하의 버튼을 가리키며, 귀하의 용어를 사용하게 하려면, 귀하의 자료를 기반으로 근거를 마련(grounded)해야 합니다. 개발자들에게 흐름(flow)을 직접 스크립트로 작성하라고 요구하는 대신, 우리는 이미 보유하고 있는 콘텐츠(문서, 도움말 기사, 기능 설명 등)를 통해 가이드를 학습시킬 수 있도록 합니다. 모델은 질문 시점에 해당 코퍼스(corpus)를 대상으로 정보를 검색(retrieve)합니다.

이는 일반적인 온보딩 도구의 워크플로우를 뒤집는 것입니다. Appcues나 Userpilot 같은 도구들은 각 흐름을 사전에 *구축(build)*할 것을 요구합니다. 반면, 검색 기반(retrieval-grounded) 음성 가이드는 한 번만 학습시키면 사용자가 예상하지 못한 질문을 포함하여 개방형 질문에 대응할 수 있습니다.

단 하나의 스크립트 태그로 배포하기

채택을 위해서는 임베드(embed) 방식이 매우 간단해야 합니다. 전체 가이드는 단 하나의 <script> 태그로 배포됩니다. 빌더(builder)가 이를 삽입하고 자신의 콘텐츠를 연결하기만 하면, 사용자는 바로 질문을 시작할 수 있습니다. 작동하는 가이드를 만들기 위해 별도의 SDK 절차나 흐름별 작성(per-flow authoring)이 필요하지 않습니다.

훔칠 만한 가치가 있는 교훈들

• 지연 시간(latency)이 경험을 결정한다면 음성 대 음성(voice-to-voice) 방식을 사용하세요. 대화형 제품의 경우, 단일 Realtime 스트림을 사용하는 것이 중간 텍스트 제어권을 잃는 것보다 더 가치 있습니다.
• 의도(intent)에 따라 캡처를 제어하세요. "요청할 때만 화면을 본다"는 방식은 지속적인 캡처보다 개인정보 보호와 비용 측면에서 더 유리하며, 사용자의 신뢰도 더 높습니다.
• 대상(target)을 의미론적(semantically)으로 해결하세요. 커서 포인팅(cursor-pointing)은 픽셀 좌표에 의존하면 실패하며, 역할(roles), 레이블(labels), 그리고 가시적인 텍스트에 의존해야 생존할 수 있습니다.
• 기존 콘텐츠로부터 학습시키세요. 개방형 도움말(open-ended help)을 위해서는 스크립트를 짜는 것보다 그라운딩(grounding)이 더 효과적입니다.
• 인원수가 아닌 사용량에 따라 가격을 책정하세요. 음성 상호작용은 분(minutes) 단위로 깔끔하게 매핑됩니다. 월간 활성 사용자(MAU)당 비용을 부과하는 것은 가이드가 유발하지 않은 성장까지 처벌하는 격이 됩니다.

직접 체험해 보세요

저희는 이를 Skilly로 구축했습니다. 제품에 임베드할 수 있는 음성 우선(voice-first) 가이드이자, Blender나 Figma 같은 데스크톱 앱 사용법을 안내해 주는 macOS 튜터입니다. 커서 포인팅 동작을 실제로 확인하거나 가이드를 직접 만든 앱에 적용해 보고 싶다면, **tryskilly.app**에서 확인하실 수 있습니다. 시작은 무료입니다.

공개 빌딩(Building in public) 중입니다 — 피드백과 날카로운 질문을 환영합니다.