AI R Voice

긴 음성에는 완료 전의 기록도 필요했습니다

AI R Voice는 Android의 음성 기록을 로컬 처리와 노트로 이어 주는 프로젝트입니다. 휴대전화에서 남긴 파일을 전사하고 정리한 뒤 LAN Receiver와 Obsidian 같은 기록 환경에 연결합니다. 저는 최종 노트뿐 아니라 그 노트가 만들어지는 중간 상태도 다뤘습니다.

7월 31일에는 긴 오디오를 중단 후 재개할 수 있는 처리 흐름을 넣었습니다. 음성 전체를 하나의 긴 요청으로 보고 마지막 결과만 저장하면, 서비스가 종료되었을 때 어느 부분을 다시 처리해야 하는지 알기 어렵습니다. 전사 구간과 요약 작업을 별도로 보존하도록 나눈 이유입니다.

작업이 중단되었을 때 어떤 상태와 산출물을 남길지부터 정했습니다. 긴 파일의 완료 여부와 함께 이어갈 수 있는 단위를 정의해야 다음 처리 범위도 결정할 수 있었습니다.

원본의 동일성을 먼저 확인했습니다

장시간 작업에는 원본 지문과 길이, 크기, 보관된 스냅샷의 위치를 연결했습니다. 재개할 때 같은 파일을 처리하고 있는지 확인하지 않으면 이전 전사 구간과 다른 음성이 섞일 수 있습니다. 작업 이름만 같다는 이유로 중간 결과를 재사용하지 않도록 한 선택입니다.

현재 처리 범위에는 길이 제한도 명시했습니다. 최대 2시간을 넘는 입력은 해당 흐름에서 받아들이지 않습니다. ‘긴 음성 지원’을 길이와 무관한 약속으로 만들지 않고, 작업을 생성할 때 확인하는 조건으로 둡니다. 원본 무결성 정보가 없는 경우도 작업을 시작하지 않도록 했습니다.

전사 결과만 다시 요약하는 작업은 별도로 만들었습니다. 이 경우에는 원본 음성 스냅샷 대신 기존 전사 텍스트의 지문을 사용합니다. 사용자가 요약을 바꾸려는 상황에 원본 음성을 다시 변환하는 일까지 포함할 필요가 없으므로 입력의 종류를 나눴습니다.

한 구간을 두 번 완료한 것으로 만들지 않았습니다

전사는 구간별로 시작·끝 시각과 순서, 처리 종류, 텍스트를 저장합니다. 같은 작업의 같은 구간이 다시 전달되어도 새로운 결과를 계속 추가하지 않도록 식별자를 고정했습니다. 재개 흐름에는 중복을 피하는 조건이 필요하기 때문입니다.

구간 텍스트가 비어 있는 상태와 의미 있는 결과가 있는 상태도 나눴습니다. 처리 호출이 끝났다는 사실만으로 모든 구간이 사용 가능한 전사라고 볼 수는 없습니다. 이후 요약에 사용할 구간을 고를 때도 저장된 상태와 텍스트를 확인합니다.

검수 조건에는 같은 구간을 두 번 저장하고 하나만 남는지 확인하는 경우를 넣었습니다. 그 뒤 작업을 중단 상태로 복구해도 이미 저장된 구간이 유지되는지 살피도록 했습니다. 정상 완료 한 번만 검사하면 중간 산출물을 보존하려고 넣은 장치가 실제로 어떤 역할을 하는지 놓칠 수 있습니다.

중지와 취소는 서로 다른 상태였습니다

실행과 완료 외에도 멈춘 상황에 따라 다른 상태를 둡니다. 일시 중지 요청과 중지, 취소 요청과 취소를 각각 나눴습니다. 중단과 실패도 구분하고, 실패는 복구 가능한 경우와 불가능한 경우로 나눕니다. 모든 정지를 하나의 실패로 표시하면 사용자가 다시 시작할 수 있는지 판단하기 어렵습니다.

일시 중지는 현재 구간을 저장한 뒤 멈추는 흐름으로 표시합니다. 취소는 안전하게 종료하는 과정으로 따로 보입니다. 앱이나 서비스가 종료된 경우에는 마지막 완료 지점부터 시작할 수 있는 중단 상태를 남깁니다. 재개 가능한 상태는 중지·중단·복구 가능한 실패로 제한했습니다.

기기 과열로 멈춘 경우도 별도 문구를 둡니다. 이 상태를 일반 오류와 합치면 사용자는 파일이 잘못됐는지, 잠시 기다려야 하는지 구분하기 어렵습니다. 모바일에서 긴 처리를 구성할 때 진행률 하나보다 멈춘 이유와 가능한 다음 동작이 더 중요한 순간이 있습니다.

전사와 요약의 진행을 따로 읽게 했습니다

장시간 처리 단계는 원본 확인, PCM 변환, 전사, 요약 구간 구성, 구간 요약, 상위 요약, 최종 검증으로 나눴습니다. 전사 구간 수와 요약 노드 수를 각각 보관하고 화면의 상태 문구에 반영했습니다. ‘처리 중’ 하나만 표시하지 않는 구성입니다.

요약은 여러 구간의 내용을 상위 단계로 합치는 흐름을 가집니다. 이미 만든 전사와 현재 요약 노드가 어느 단계까지 준비됐는지 알아야 중단 뒤 이어갈 부분을 정할 수 있습니다. 마지막 노트가 나오기 전에도 진행을 설명할 수 있도록 산출물과 상태를 함께 저장했습니다.

다시 요약할 때는 기존 전사를 유지하고, 새 결과가 완성될 때까지 이전 요약도 남기는 조건을 뒀습니다. 새 작업을 시작했다는 이유만으로 읽을 수 있던 내용을 먼저 지우지 않으려는 선택입니다. 사용자가 기다리는 동안에도 이전 기록으로 돌아갈 수 있어야 했습니다.

기록 앱의 신뢰는 재개 경계에서 드러납니다

AI R Voice의 Receiver와 노트 연결은 최종 결과를 다시 찾는 흐름이고, 장시간 작업 저장은 결과가 나오기 전의 흐름입니다. 저는 두 흐름을 같은 완료 상태로 묶지 않았습니다. 오디오를 보관한 것, 전사한 것, 요약한 것, 노트로 연결한 것을 각각 확인할 수 있어야 합니다.

비슷한 앱을 만들 때는 중간 결과를 얼마나 남길지, 같은 구간을 다시 받아도 중복이 생기지 않는지, 입력이 바뀌면 이전 결과를 재사용하지 않는지부터 정할 수 있습니다. 그 뒤 서비스 종료와 중지·취소를 실제 지원 기기에서 따로 확인해야 합니다. 처리 속도만으로 이 조건을 대신할 수 없습니다.

전사와 요약을 나누고 원본의 동일성을 확인하며 재개 가능한 상태를 좁혔습니다. 개인 기록을 다루는 앱에서는 끝에 나온 문장만큼 중간에 멈췄을 때 무엇이 남는지도 설명할 수 있어야 했습니다.