회의 녹음에서 근거를 확인할 수 있는 실행 항목까지: Scribe 전사 워크플로

유용한 회의 처리 과정에서는 서로 구분되는 결과물 세 가지가 필요합니다. 녹음 파일, 발언 내용을 보존한 전사문, 그리고 관련 발언과 시간에 연결된 실행 항목 제안입니다. 매끄러운 요약이 전사문을 대신할 수는 없습니다. 생성된 JSON 파일에 들어 있는 항목도 프로젝트 시스템에서 승인된 작업과는 다릅니다.

이 튜토리얼에서는 Ofox를 사용해 43.92초 분량의 합성 녹음을 elevenlabs/scribe_v2로 전사한 다음, 타임스탬프가 포함된 응답을 openai/gpt-6-luna에 전달합니다. 녹음에는 담당자가 지정된 작업, 담당자가 없는 작업, 미정인 출시일, 승인되지 않은 예산이 의도적으로 포함되어 있습니다. 텍스트 모델은 메시지를 보내거나 외부 작업을 생성하지 않고 실행 항목 제안과 미해결 질문을 반환했습니다. 원본 파일과 원시 응답을 다운로드할 수 있습니다.

회의 내용은 이 튜토리얼을 위해 작성한 가상의 대본이며, 합성 음성으로 읽었습니다. 대본에 등장하는 이름은 실제 참석자나 검증된 화자 신원을 나타내지 않습니다. 이 예제는 감사 가능한 처리 과정을 보여 주기 위한 것으로, 소음이 있는 실제 회의에서의 성능이나 안정적인 자동 화자 분리를 입증하지 않습니다.

검토 가능한 결과물 정의하기

오디오를 업로드하기 전에 검토자가 어떤 결과물을 받아야 하는지 정하세요. 이 워크플로의 최소 구성은 원본 녹음, 원시 ASR 응답, 수정된 전사문(있는 경우), 인용문과 시간 범위가 포함된 실행 항목 제안, 미해결 질문, 검토 결과입니다. 나중에 수정하더라도 모델이 실제로 반환한 내용이 사라지지 않도록 결과물을 서로 분리해 보관하세요.

실행 항목 기록에는 그럴듯한 문장만으로는 부족합니다. 작업 자체와 담당자, 마감일, 승인 상태를 구분해야 합니다. 녹음으로 뒷받침되지 않는 필드에는 null을 사용하거나 “확인 필요” 상태를 명확히 표시하세요. 추측으로 표의 모든 칸을 채우면 문서가 더 완성되는 것이 아니라 오히려 쓸모없어집니다.

작업 키트에는 meeting-script.txt, 회의 오디오, meeting-transcript.json, extract_actions.py, 추출 요청과 원시 응답이 들어 있습니다. 다른 사람의 비공개 회의를 업로드하지 않고도 이 파일들로 처리 과정을 확인할 수 있습니다.

가상 회의 합성 음성

1. 사용 권한이 있는 입력을 확보하고 타임라인 보존하기

선택한 클라우드 서비스로 처리할 권한이 있는 녹음만 사용하세요. 직장 회의라면 조직의 녹음, 보존, 접근 규정을 따르세요. 전사문이 모델의 작업 이해에 도움이 될 수 있다는 이유만으로 비밀번호, 비공개 액세스 토큰, 무관한 개인정보를 포함하지 마세요.

원본 파일은 보관하고, 필요하다면 지원되는 형식의 오디오 사본을 만드세요. 여기서 테스트한 Ofox 경로는 WAV 또는 MP3를 지원합니다. 영상에서 오디오 트랙을 추출했다면 어떤 트랙을 선택했는지, 앞부분의 시간을 잘라냈는지 기록하세요. 이후의 모든 인용은 올바른 타임라인을 기준으로 해야 합니다.

이 예제에서는 원본 대본으로 43.92초 분량의 MP3 파일 하나를 생성했습니다. 파일에는 다음과 같이 서로 다른 유형의 발언이 의도적으로 포함되어 있습니다.

• Leo가 2026년 10월 15일까지 API 예제를 확인하겠다고 합니다.
• 일본어 내레이션 녹음 담당자는 지정되지 않았습니다.
• 화자는 프로덕션 출시를 승인할 수 없다고 말합니다.
• 출시일은 미정이므로 초대장을 아직 보내면 안 됩니다.
• 30달러의 테스트 예산을 논의했지만 승인하지는 않았습니다.

이러한 차이가 테스트의 핵심입니다. “보내지 말라”는 말을 놓친 채 “초대장을 보내라”는 내용만 추출하는 시스템은 그럴듯해 보이지만 해로운 작업 목록을 만들 수 있습니다. 예산 논의를 승인으로 취급하는 시스템은 요약을 넘어 사실을 만들어낸 것입니다.

2. Scribe로 전사하고 원래 응답 보관하기

OFOX_API_KEY를 설정하고 requests, FFmpeg, ffprobe를 설치한 다음, 키트 디렉터리에서 제공된 클라이언트를 실행하세요.

python3 audio_api.py transcribe \
  --input meeting.mp3 \
  --output my-meeting-transcript.json

클라이언트는 elevenlabs/scribe_v2와 verbose_json을 사용해 /v1/audio/transcriptions로 multipart form data를 업로드합니다. 현재 노출된 경로는 Ofox Scribe 모델 페이지에서 확인하세요. 이 예제에서는 기본 제공업체 API의 모든 매개변수가 게이트웨이에서도 허용된다고 가정하지 않습니다.

응답은 편집하기 전에 저장하세요. 샘플 JSON에는 전체 텍스트와 단어 단위 시작·종료 시간이 포함되어 있습니다. 또한 음성으로 말한 날짜를 “October 15th, 2026”으로 정규화합니다. 이런 표기 정규화는 유용하지만, 모델이 현재 날짜를 알고 있다거나 상대적인 마감일을 언제나 안전하게 해석할 수 있다는 근거는 아닙니다.

녹음 파일은 43.92초 지점에서 끝나며, 응답에 포함된 마지막 단어의 종료 시각은 43.74초입니다. 길이와 사용량 필드는 서로 구분해 보관하세요. 마지막 발화 단어의 타임스탬프는 파일 길이를 대신하지 않으며, 전사 요청의 청구 금액을 확정해 주지도 않습니다.

API 요청이 실패하면 오류 메시지를 전사문처럼 추출 모델에 전달하지 말고, 오류 본문과 요청 ID를 보관하세요. 타이밍 정보 없이 텍스트만 반환된 경우 요약 초안은 만들 수 있지만, 정렬 정보가 확보되기 전까지는 시간에 연결된 근거를 검증했다고 주장할 수 없습니다.

3. 판단에 영향을 주는 부분을 중심으로 전사문 검토하기

먼저 이름, 날짜, 숫자, 부정 표현, 권한 관련 발언을 검토하세요. 이 합성 예제에서는 비교할 원본 대본을 사용할 수 있습니다. 실제 회의에서는 녹음이 기본 근거입니다. 슬라이드, 안건, 이전 회의록은 용어를 이해하는 데 도움을 줄 수 있지만, 참석자가 말한 내용을 조용히 덮어써서는 안 됩니다.

수정 사항은 편집 로그에 남기세요. 각 행에는 원래 ASR 문구, 수정 문구, 시간 범위, 수정 이유, 검토자를 기록할 수 있습니다. 오디오가 불분명하면 확실하지 않다고 표시하세요. 가까이에 있던 사람이 말했거나 평소 그 사람이 해당 업무를 맡는다는 이유만으로 담당자 이름을 만들어내지 마세요.

이 응답에는 검증된 화자 라벨이 없습니다. 의도적으로 구성한 대본에서는 “Leo speaking”이라고 말하지만, 이는 오디오 파일에 담긴 텍스트일 뿐 특정 직원이 발화했다는 음향적 증거가 아닙니다. 다음 모델이 이 관례만으로 화자 신원을 추론하지 않도록 추출 프롬프트에서 명시적으로 경고합니다.

여러 사람이 서로 끼어들거나 의견이 다를 때는 깔끔한 실행 항목 목록을 만들기 위해 추가 검토가 필요할 수 있습니다. 짧고 한 사람의 목소리만 담긴 이 튜토리얼 녹음은 발화 겹침, 배경 소음, 동시 발화, 억양을 테스트하지 않습니다. 팀 녹음에 자동화 워크플로를 적용하기 전에 이러한 조건은 별도로 평가하세요.

4. 근거에 연결된 제안을 텍스트 모델에 요청하기

추출 단계에는 전사 텍스트와 실제 단어 배열이 모두 입력됩니다. 모델에는 제공된 자료만 사용하고, 알 수 없는 필드는 명시적으로 반환하며, 부정 표현을 보존하고, 확약과 제안을 구분하라고 지시합니다. 메시지를 보내거나 프로젝트 시스템을 수정해서는 안 됩니다.

전체 요청은 actions-request.json에 있습니다. 핵심 지침은 다음과 같습니다.

Use only the supplied ASR words and text.
Return actions, decisions, and open_questions.
Each action needs task, owner, due_date, status=proposed,
an exact supporting quote, and start/end seconds copied
from the word timestamps. Use null for unknown fields.
Separate commitments, proposals, and negations.
Do not infer acoustic speaker identity from a spoken name.
Do not invent approvals, send messages, or create tasks.

extract_actions.py를 실행하면 포함된 샘플 추출을 재현할 수 있습니다. 이 스크립트는 /v1/chat/completions를 통해 openai/gpt-6-luna를 사용하고, 타임스탬프가 포함된 전사문을 읽어 원시 결과를 저장합니다. 제공된 스크립트는 기존 actions-response.json을 덮어쓰지 않도록 되어 있습니다. 의도적으로 유료 요청을 다시 보낼 때는 별도의 작업 복사본이나 버전이 지정된 출력 파일을 선택하세요.

이 예제는 지침으로 JSON을 요청한 뒤 검증할 수 있도록 응답을 보관합니다. API 수준에서 구조화된 출력 스키마가 강제되었다고 주장하지 않습니다. 모델 메시지가 유효한 JSON처럼 보여도, 프로덕션 시스템에서는 파싱한 객체를 자체 스키마에 따라 검증하세요.

새 회의에 사용할 때는 입력 파일을 의도적으로 변경하고 프롬프트 버전도 보존하세요. 튜토리얼 전사문을 계속 가리키는 스크립트를 아무 생각 없이 재사용하지 마세요. 형식이 완벽해도 잘못된 녹음을 바탕으로 한 결과는 여전히 잘못된 결과입니다.

5. 실제 결과와 그 불완전한 부분까지 살펴보기

샘플 모델은 확약, 제안, 부정을 포함하는 중첩 actions 객체와 decisions, open_questions를 반환했습니다. 모든 실행 항목의 상태는 proposed입니다. 원시 응답은 한 번 생성된 결과를 보여 주는 근거이지, 이후 호출에서도 동일하게 유지되는 API 스키마로 취급해서는 안 됩니다.

원시 응답에는 별도의 제안으로 “I can review the example”도 들어 있습니다. 이 제안은 API 확인 작업과 겹칠 수 있습니다. 두 인용문이 같은 업무를 가리키는지 검토자가 판단한 뒤 작업을 내보내야 합니다. 인용문 각각이 실제 발언을 근거로 삼더라도, 두 항목을 자동 생성하면 중복 작업이 생길 수 있습니다.

모델은 decisions를 비워 두고 승인되지 않은 예산을 미해결 질문으로 보존했습니다. 승인을 만들어내는 것보다 바람직하지만, 신중하게 구성된 이 예제에서 한 번 나온 결과일 뿐입니다. 실제 논의 전반에서 이런 동작을 신뢰하려면 더 폭넓은 테스트가 필요합니다.

유용한 검토 결과라면 명시적인 API 확인 작업은 유지하고, 데모는 담당자가 지정되지 않은 제안으로 남기며, 미해결 질문 세 가지를 보존하고, 초대장 제한 사항은 실행할 작업이 아니라 제약으로 기록할 수 있습니다. 이런 편집 판단은 actions-response.json과 분리해 저장해 원본 결과도 살펴볼 수 있게 하세요.

6. 인용문, 타임스탬프, 누락된 필드 검증하기

결정론적인 검사부터 시작하세요. JSON을 파싱하고 필수 키를 확인하며, 형식이 잘못된 시간 값을 거부하세요. 인용된 각 시간 범위는 녹음 길이 안에 있어야 하며, 인용된 단어의 시작과 끝에 대응해야 합니다. 숫자가 파일 길이 안에 있다는 사실은 필요한 조건이지만, 해당 구간이 올바른 문장을 가리킨다는 충분한 근거는 아닙니다.

정확한 인용문이 전사문과 일치하는지 확인하세요. 일치를 검사할 때 공백이나 문장부호를 정규화한다면 그 규칙을 기록하세요. “approved”와 “not approved”를 서로 바꿔도 된다고 간주할 수 있는 넓은 퍼지 매칭은 사용하지 마세요. 샘플에서는 예산 인용문에 승인 거부 내용이 포함되어 있습니다. 그 부분을 빼면 의미가 달라집니다.

그런 다음 의미를 검토하세요. 인용문이 정확해도 잘못된 결론을 뒷받침할 수 있습니다. “I cannot approve the production release”는 제한 사항의 근거이지 배포 허가의 근거가 아닙니다. “The release date is still undecided”는 다른 문장의 API 검토 마감일을 가져와 출시일로 삼을 근거가 될 수 없습니다.

알 수 없는 값은 인터페이스에서도 그대로 드러나야 합니다. 담당자가 비어 있다고 해서 업로더, 회의 주최자, 처음 언급된 사람을 조용히 담당자로 지정해서는 안 됩니다. 마감일이 없다고 해서 오늘 날짜를 기본값으로 넣어서도 안 됩니다. 후속 도구에서 해당 필드를 요구한다면, 양식을 채우려고 데이터를 만들어내는 대신 검토 대기열에 항목을 남겨 두세요.

7. 추출과 작업 생성을 분리하기

이 튜토리얼은 제안 기록을 만드는 단계에서 멈춥니다. 티켓을 생성하거나 이메일을 보내거나 캘린더 일정을 예약하지 않습니다. 두 API 호출이 모두 HTTP 200을 반환하더라도 전사와 해석이 틀릴 수 있으므로 이 경계는 중요합니다.

프로젝트 도구에 연결하기 전에 누가 실행 항목을 승인할 수 있는지, 승인자가 어떤 근거를 확인하는지 정하세요. 제안된 담당자와 마감일 옆에 인용문과 오디오 시간 범위를 표시하세요. 승인, 수정, 거부 여부를 기록하고, 내보낸 작업을 검토된 버전과 연결하는 감사 기록을 유지하세요.

나중에 작업을 생성할 때는 검토된 회의 버전과 실행 항목 식별자를 바탕으로 멱등성 키나 중복 제거 키를 사용하세요. 요약을 다시 실행해도 티켓이 중복 생성되지 않아야 합니다. 수정된 실행 항목은 변경 사항을 검토한 뒤에만 해당 기록을 업데이트해야 합니다. 이전에 승인한 확약을 조용히 덮어써서는 안 됩니다.

녹음이 끝난 뒤 회의 참석자가 생각을 바꿀 수도 있습니다. 나중에 내려진 사람의 결정은 자체 출처와 함께 작업 기록에 남겨야 합니다. 마치 회의에서 그때 발언했던 것처럼 전사문에 소급해 넣어서는 안 됩니다.

8. 워크플로의 각 단계를 나누어 문제 해결하기

전사 요청이 실패하면 지원되는 입력 형식, 자격 증명, 정확한 오류를 확인하세요. 이 프로젝트에서 이전에 보낸 Scribe 요청은 업스트림 할당량 문제에 부딪혔고, 이후 새 요청이 성공하면서 복구를 확인했습니다. 지갑 상태만으로는 해당 경로의 문제를 진단하기에 충분하지 않았습니다.

전사가 불완전하면 입력 오디오, 선택한 트랙, 업로드 완료 여부를 확인하세요. 텍스트 모델이 잘못된 JSON을 반환하면 원시 응답을 보관하고 추출 또는 검증 절차를 수정하세요. 하위 단계의 JSON 형식만 실패한 경우에는 같은 오디오를 반복해서 업로드하지 마세요.

출력에서 담당자나 날짜를 만들어내면 근거 요건을 강화하고 실제 사례를 검토하세요. 프롬프트를 길게 쓴다고 지침 준수가 보장되지는 않습니다. 담당자가 없는 업무, 잠정적인 날짜, 권한 거부, 서로 모순되는 발언을 포함한 테스트 사례를 유지하고, 검증기와 검토자가 이를 잡아내도록 하세요.

아주 긴 회의에서는 청크 오프셋을 보존하고, 구간마다 반복되거나 대체된 결정을 조정하세요. 이 키트에 포함된 작은 스크립트는 짧은 녹음을 처리하는 투명한 예제이지, 긴 회의를 완전히 오케스트레이션하는 시스템이 아닙니다. 테스트하지 않은 장문 처리 한도나 회의 간 자동 기억 기능을 내세우지 마세요.

9. 요약의 길이보다 유용한 결과를 측정하기

제안된 항목 가운데 수정 없이 승인된 항목, 수정된 항목, 거부된 항목, 중복으로 병합된 항목의 수를 추적하세요. 검토에 든 시간과 검토자가 찾아낸 누락된 확약의 수도 기록하세요. 이런 지표는 생성된 글머리표의 수보다 유용합니다.

비용을 확인할 때는 전사와 텍스트 모델 사용량을 구분하세요. 초당 ASR 수치와 텍스트 토큰 수는 단위가 다릅니다. 아티팩트의 메타데이터는 자체 청구 기록과 요청을 대조하는 데 유용하지만, 이 튜토리얼에서는 대조되지 않은 추정치를 실제 청구 금액으로 제시하지 않습니다.

공개하거나 팀에 배포하려면 검토자가 승인했으며 출처와 연결되고, 미해결 필드가 보존된 작업 목록을 승인 기준으로 삼으세요. 초대장 제한 사항을 누락하거나 예산 승인을 만들어내는 매끄러운 요약은 짧고 읽기 쉬워도 이 기준을 충족하지 못합니다.