회의 처리 흐름
갱신: 2026-08-17
회의 한 건은 시작과 중지·재개를 거쳐 종료된다. 종료 뒤에는 오디오 조립, 화자 분리, 화자 확인, 분석이 차례로 이어진다. 각 상태에는 진입 조건과 실패했을 때 돌아갈 지점이 필요하다. 단계를 실행하는 프로세스와 통신 규약은 시스템 아키텍처에 있다.
회의 상태와 종료 후 상태
NOT_STARTED, IN_PROGRESS, PAUSED, ENDED는 현재 회의록에 저장하는 상태다. 종료 뒤 처리에 필요한 화자 분리 중, 화자 확인 대기, 요약 생성 중, 검토 대기, 확정은 아직 저장 컬럼이 없다. 앞부분은 구현된 상태이고 뒷부분은 처리 흐름을 완성하기 위해 추가해야 할 상태다.
확정은 편집 금지를 뜻하지 않는다. 참여자가 내용을 고치면 다시 검토 대기로 돌아가 변경 내용을 확인할 수 있어야 한다. 반대로 종료된 회의를 다시 IN_PROGRESS로 되돌리는 전이는 허용하지 않는다. 녹음을 재개할 때는 같은 회의 아래에 새 run을 연다.
회의 중에는 run이 시간을 나눈다
전사 세션과 회의는 1:1 관계가 아니다. 사용자가 중지했다가 재개하거나 realtime task가 바뀌면 새 run이 열린다. Soniox 연결만 다시 맺을 때는 run을 유지하고 그 안에 새 stt_stream을 만든다. S3 오디오도 run과 segment 단위로 나뉜다.
| 규칙 | 적용 방식 |
|---|---|
| 회의 전체 좌표 | soniox.start_ms + stt_stream.offset_ms + run.offset_ms |
run 안에서 잃은 구간 | 무음을 넣어 뒤쪽 좌표를 보존 |
run 사이의 중지 시간 | 오디오에 넣지 않음 |
| 실제 시각 | run.started_at + (합본 위치 - run.offset_ms) |
| 동시성 | 한 회의에는 열린 run을 하나만 허용 |
중지 시간을 오디오에 넣지 않으므로 한 시간 쉬었다가 재개해도 모델 입력에 한 시간의 무음이 생기지 않는다. run.offset_ms는 앞선 run의 재생 길이 합으로 계산한다. 벽시계 경과 시간을 사용하면 중지 시간이 그대로 오디오 좌표에 섞인다.
요약의 근거 칩도 같은 좌표 체계를 사용해야 한다. 세션 안의 위치를 그대로 저장하면 서로 다른 run에서 같은 숫자가 나오고, 화면에서 엉뚱한 전사 문장을 가리킬 수 있다.
연결이 끊겼을 때 새 run을 여는 조건
| 끊긴 원인 | 예상 오디오 유실 | 이어 가는 방법 |
|---|---|---|
| 진행자가 중지하거나 종료 | 0 | 남은 버퍼의 finalize를 기다린 뒤 run을 닫음 |
| 배포 또는 scale-in | 0 목표 | SIGTERM에서 버퍼를 마지막 세그먼트로 올리고 새 task에서 새 run을 엶 |
| realtime 태스크 비정상 종료 | 최대 30초 | 메모리 버퍼는 복구하지 못하고 새 run에서 재개 |
| RDS 장애 전환 | 60~120초 쓰기 지연 전제 | 재시도 버퍼로 흡수하도록 설계했으나 검증하지 않음 |
Soniox WebSocket 재연결은 run을 나누지 않는다. 같은 realtime 세션 안에서 새 stt_stream과 오프셋을 만들어 전사 좌표만 이어 붙인다. 새 run은 사용자 중지·재개나 실행 태스크 교체처럼 회의 수집 경계가 실제로 끊겼을 때 연다.
종료 요청 뒤에는 세 실행 주체가 이어받는다
API는 열린 run이 모두 닫힌 것을 확인한 뒤 세그먼트 키 목록을 조립 큐에 넣는다. 조립 함수는 키 순서대로 오디오를 합쳐 S3에 저장하고 합본 키와 길이를 보낸다. API가 이 합본을 pyannote에 제출해 화자 구간을 받은 뒤, 전사 세그먼트와 가장 오래 겹친 화자를 연결한다.
기계 화자 SPEAKER_01을 실제 참여자 이름으로 바꾸는 일은 사용자가 맡는다. 이 확인이 끝나면 API가 확정 화자를 포함한 전사를 AI 분석 큐에 넣는다. AI가 만든 요약 문장에 화자 이름을 복사해 저장하지 않고, 근거 세그먼트와 화면에서 결합해 표시한다. 사용자가 화자 이름을 고쳐도 요약 본문을 다시 쓸 필요가 없게 하기 위해서다.
조립 함수는 S3와 SQS만 사용한다. 데이터베이스를 읽거나 pyannote를 호출하지 않는다. 외부 화자 분리 요청과 webhook 수용, 전사 매핑은 업무 상태를 소유한 API가 맡는다.
실패했을 때 끝나는 지점
| 상황 | 처리 상태 |
|---|---|
| 화자 분리 실패 | 화자 없이 분석을 계속하고 화면에 실패 상태 표시 |
| 사용자가 화자 확인 화면을 열지 않음 | 자동 진행 여부 미확인 |
| 작업이 두 번 실패 | watchdog 1회 재발행 뒤의 종착 정책 미확인 |
| 분석이 10분 넘게 끝나지 않음 | watchdog이 1분마다 확인해 한 번 재발행 |
| 늦게 도착한 화자 결과와 사용자 수정이 충돌 | 우선순위 미확인 |
화자 확인 대기는 장애 지연이 아니라 사용자의 입력을 기다리는 상태다. 처리 시간 경보에서 제외해야 한다. 반면 조립, 화자 분리, 분석은 시스템이 끝내야 하므로 제한 시간을 넘기면 운영 경보와 재처리가 필요하다.