오디오 이벤트 감지 받아쓰기: 단어 너머의 의미 있는 소리들

이 글은 다른 엔지니어링 노트보다 의도적으로 더 조심스러워요. "의미 있는 소리"는 출시된 기능이 아니에요. 초기 연구 방향이에요. 소리 이해 음성 입력이 받아쓰기의 차분한 흐름을 유지하면서도 유용한 비언어 신호를 잡을 수 있을까?

비언어 오디오라는 빈자리

보통 음성 입력 시스템은 단어가 아닌 모든 것을 버려요. 깨끗한 전사에는 합리적인 선택이지만, 정보가 새요. 회의에서 웃음은 합의나 긴장을 표시할 수 있어요. 일기에서는 긴 침묵이 의미를 가질 수 있어요. 접근성 워크플로에서는 초인종, 타이머, 우는 아이가 유용한 컨텍스트일 수 있어요.

1시간짜리 회의가 끝난 뒤의 받아쓰기 전사가 어떻게 생겼는지 떠올려보세요. 단어는 다 있지만 리듬은 평탄해져요. 누군가 반대 의견을 내기 전의 긴 침묵, 모진 피드백을 부드럽게 만들어주던 작은 웃음, 어려운 질문 뒤의 침묵의 순간 — 그런 것들이 사라지죠. 전사를 다시 읽는 사람은 기억으로 그 자리를 채워요. 참석하지 못한 동료에게는 단서조차 없어요. 오디오 이벤트 감지 받아쓰기는 사용자에게 따로 내레이션하라고 요구하지 않으면서, 기록 안에 그 텍스처를 조금 되돌리는 한 가지 방법이에요.

리스크는 분명해요. 모든 소리가 텍스트가 되어서는 안 되거든요. 대부분의 배경음은 무관해요. 어떤 건 사적이고, 어떤 건 모호해요. 오디오 이벤트 감지 받아쓰기는 선택적이고, 로컬 퍼스트이며, 소리가 글의 출력을 바꾸는 경우에 대해 보수적일 때에만 의미가 있어요.

AED vs 오디오 캡셔닝

오디오 이벤트 감지(AED)는 간결한 질문에 답해요. 무슨 이벤트가, 대략 언제 일어났나? 오디오 캡셔닝은 소리 장면을 자연어 문장으로 묘사해요. 받아쓰기에는 AED만으로도 충분한 경우가 많아요. "laughter(웃음)"이나 "doorbell(초인종)" 같은 태그는 마커가 될 수 있지만, 전체 캡션은 너무 장황할 수 있어요.

우리가 AED를 먼저 택하는 이유

AED 태그는 조용히 실패해요. 모델이 어떤 소리를 "applause(박수)"로 라벨링했는데 사실 아니었다면, 사용자는 대괄호로 둘러싸인 마커 하나만 보게 되고, 쉽게 지울 수 있어요. 잘못된 오디오 캡션은 되돌리기가 더 어려워요. 주변 문단의 모양을 바꾸고, 독자를 편향시키고, 요약에 남아요. 한 문장씩 신뢰를 쌓아가는 받아쓰기 제품에서, 작은 오답 태그의 비용은 자신만만하게 틀린 문장의 비용보다 훨씬 적어요. 우리의 초기 방향은 자동 산문이 아니라 작은 구조화된 마커예요. 마커는 검토하기도, 지우기도, 무시하기도 더 쉬워요.

받아쓰기에는 어떤 의미가 될까

회의에서는 비언어 오디오가 선택적 마커를 만들 수 있어요. 농담 뒤의 "[laughter]", 결정 전의 "[long pause]", 화자가 끊겼을 때의 "[doorbell]" 같은 것들이죠. 일기에서는 사용자가 따로 내레이션하지 않아도 감정적 텍스처를 보존하는 데 도움이 될 수 있어요. 접근성 워크플로에서는 환경음을 짧은 메모나 리마인더로 바꿀 수 있어요.

구체적인 스케치를 그려볼게요. 사용자가 회의 마커를 켰다고 가정한 회의 노트가 있다고 해봐요. 전사는 평범한 산문처럼 읽히고, 드물게 작은 태그가 끼어들어요. "이번 주에 마이그레이션을 출시하기로 합의했어요. [laughter] 그다음 롤백 플랜을 훑어봤어요. [long pause] 누군가 인덱스 변경을 미루는 게 좋겠냐고 물었어요." 독자는 무대 지시문 같은 긴 문단 없이도 무슨 일이 있었는지 더 풍부하게 느낄 수 있어요.

저널링 스케치는 더 좁아요. 사용자가 하루를 마무리하며 짧은 노트를 받아써요. 들리는 긴 침묵이 "[reflection]" 태그로 떠오를 수 있고, 사용자는 그걸 보관하거나 편집하거나 검토 단계에서 지울 수 있어요. 한 번도 살펴보지 않은 상태로 일기 본문에 자동으로 들어가는 건 없어요.

우리는 받아쓰기를 연극적으로 만들 생각이 없어요. 모든 기침이나 키보드 클릭을 쓰겠다는 게 아니에요. 신호가 강한 좁은 이벤트 집합만 감지하고, 그 이벤트들을 텍스트로 둘지, 태그로 둘지, 아무것도 아닌 채로 둘지를 사용자가 정하게 하자는 거예요.

연구 토대

몇 가지 공개된 연구 라인이 이 주제와 관련돼 있어요. CLAP은 대조적 언어-오디오 사전학습을 탐구해요. BEATs는 음향 이해를 위한 오디오 사전학습을 다뤄요. AudioSet은 오디오 이벤트에 대한 대규모 데이터셋이고, AudioCaps는 오디오 캡셔닝의 기준점이에요.

이건 연구 토대지, 제품의 의존성 선언이 아니에요. Loqua의 프로토타입 작업은 맥 받아쓰기에 한정된 질문에 집중하고 있어요. 어떤 소리 단서가 커서 옆에서 유용한가, 어떤 건 보이지 않게 두어야 하는가, 그리고 사용자가 그 경계를 어떻게 제어할 수 있는가.

지금 프로토타이핑 중인 것

좁은 세 가지 동작을 프로토타이핑하고 있어요. 첫째, 회의 마커: 웃음, 침묵, 박수, 끊김에 대한 선택적 태그. 둘째, 저널링 단서: 긴 침묵이나 들리는 한숨에 대한 사용자 승인 태그. 셋째, 접근성 알림: 사용자가 요청할 때 로컬 소리 단서가 리마인더나 메모로 변하는 것.

내부적으로 그리고 있는 사용자 경험은 의도적으로 조용해요. 감지된 이벤트는 받아쓰기 텍스트 옆의 작은 검토 영역에 칩(chip)으로 나타나지, 텍스트 안에 바로 들어가지 않아요. 사용자는 칩을 문서로 끌어다 놓거나, 무시하거나, 도착지에 맞는 태그로 변환할 수 있어요. 기본 동작은 "동의 없이는 절대 삽입하지 않음"이에요. 기본 모드는 해당 워크플로에서 사용자가 켜기 전까지 꺼져 있어요.

프로토타입은 로컬 퍼스트이고 opt-in이에요. 이 방향에서 그 어떤 것도 사적인 배경음을 조용히 주석으로 달아서는 안 돼요. "마커 전용" 모드도 시험 중이에요. 감지된 소리가 산문에 자동으로 들어가지 않고, 삽입 전에 검토 가능한 칩으로 먼저 나타나는 모드예요.

아직 풀지 못한 어려운 문제들

가장 어려운 문제는 "의미"예요. 웃음은 합의일 수도, 불편함일 수도, 비꼼일 수도, 그냥 아무것도 아닐 수도 있어요. 한숨은 피로일 수도, 안도일 수도, 마이크 노이즈일 수도 있어요. 약한 증거에서 감정 해석을 지어내는 모델은 원치 않아요. 두 번째 어려운 문제는 개인정보예요. 환경음은 사용자가 예상하는 것보다 더 많은 걸 드러낼 수 있어요.

세 번째 어려운 문제는 공유 공간이에요. 엄격한 opt-in이 있더라도, 회의실 안의 마이크는 동의한 적 없는 사람들의 소리도 듣게 돼요. 그 방의 웃음을 잡아내는 비언어 오디오 기능은 여전히 사용자가 아닌 사람들에 대한 정보를 기록하는 셈이에요. 풀 수 없는 문제는 아니라고 보지만, 제약 조건을 강하게 좌우해요. 감지기는 사용자 기기에서 로컬로 돌아야 하고, 마커는 명시적인 동작 없이 공유되어서는 안 되며, 환경음 클래스의 기본값은 추론보다는 침묵 쪽으로 기울어야 해요.

그래서 현재 기준은 보수적이에요. 오디오 캡셔닝 받아쓰기는 분명한 사용자 제어, 보이는 마커, 쉬운 삭제를 요구해야 해요. 오디오 이벤트 감지 받아쓰기를 프로토타입에서 출시 단계로 옮기기 위한 기준은 구체적이에요. 신중한 사용자가 정직하다고 묘사할 수 있는 opt-in 흐름, 우리가 명시적으로 테스트하지 않은 환경에서는 기본 꺼짐 동작, 그리고 잘못된 태그를 키 한 번으로 없앨 수 있는 UX. 이 조각들이 충분히 맞아 들어가기 전까지는, 이 작업은 출시 약속이 아니라 연구 프런티어로 남아 있어요.