← 대표 작업03 / CASE STUDY

사내 운영 · 공개 UI 데모

Meeting Assistant

약 32명 규모 회사의 교육부·개발부에서 사용하는 회의 어시스턴트. 기획부터 개발·배포·운영·유지보수까지 담당하며 RTX 4090 서버에서 운영합니다.

역할단독 담당 · 기획 / 개발 / 배포 / 운영 / 유지보수

기간2026.06–

주요 도구Python · faster-whisper · pyannote · Claude API · Docker · Google SSO

UI 데모 ↗

통계에 기록된 회의 건수: 32
기록된 회의 길이 합계: 833 min
현재 운영 환경: RTX 4090

01 / WORKFLOW

사용 맥락과 구현 범위

CLI 도구를 사내 직원이 브라우저에서 사용하는 웹 UI와 Docker 서비스로 확장했습니다. 녹음 이후 전사, 발언자 구분, 회의록 작성, Notion 저장과 메일 전달까지 연결한 프로젝트입니다.

기획부터 음성 처리 파이프라인과 웹 UI 개발, 로그인·권한 구성, 배포, 운영·유지보수까지 단독으로 담당했습니다. 교육부·개발부 사용자의 요청을 받아 오류 대응 화면, 녹음 파일 백업, 안드로이드 웹앱을 추가했습니다.

02 / USAGE · 2026.08–09

월별 이용 기록

약 32명 규모 회사의 교육부·개발부에서 사용합니다. 아래는 2026.09.15에 공유된 운영 화면의 월별 집계입니다. 개인별 이름과 이용 내역은 제외했습니다.

기간	기록 건수	회의 길이 합계
2026.08	10	363분
2026.09 · 9/15 제공 시점	22	470분

합계 32건·833분. 분 단위 값은 기록된 회의 길이이며 모델 처리 시간이나 업무 절감 시간이 아닙니다.
9월은 월중 집계입니다. 회사 인원은 활성 사용자 수가 아니며, 이 통계만으로 성공률·반복 사용률·월간 성장률을 계산하지 않습니다.

03 / USER REQUESTS

사용자 요청으로 바꾼 기능

오류가 나면 운영 담당자인 제가 바로 상태를 파악하고 처리할 수 있도록 로그·완료·실패 기록과 재시도를 UI에 모았습니다. 녹음 보관과 쉬운 모바일 사용 요청도 각각 백업 기능과 안드로이드 웹앱에 반영했습니다.

요청·운영 필요	반영한 변경
오류 위치를 확인하고 바로 대응	로그와 완료·실패 기록 조회, UI에서 재처리
녹음 파일을 따로 보관	녹음 파일 백업 기능
고령 사용자도 쉽게 모바일 녹음	안드로이드 웹앱과 간단한 녹음 흐름

운영 담당자가 제공한 요청 요약과 구현 내용입니다. 사용자 발언의 직접 인용이나 만족도 평가로 제시하지 않습니다.

04 / SYSTEM

시스템 구조

RTX 4090에서 faster-whisper와 pyannote를 실행합니다. 전사·화자 분리 구간은 한 번에 하나씩 처리하고, 대기 중인 작업은 queued 상태로 표시합니다. 전사 텍스트는 외부 Claude API로 보내 구조화한 회의록을 생성합니다.

음성 처리 전체를 하나의 HTTP 응답으로 기다리지 않고 작업 ID를 먼저 반환합니다. 화면은 짧은 상태 조회를 반복하므로, 긴 추론 작업의 수명을 프록시 요청 제한과 분리할 수 있습니다.

01음성
faster-whisper
02화자 분리
pyannote · RTX 4090
03회의록
Claude · structured JSON
04저장·전달
Notion · SMTP

05 / CHANGE · 2026.09

업로드 응답이 끊겼을 때

서버에는 작업이 생성됐는데 시작 응답이 HTML 오류로 돌아오면, 화면에서 JSON 해석 오류가 나고 사용자는 업로드 실패로 받아들일 수 있습니다. 이 경우 새로 업로드하기 전에 본인의 진행 중 작업을 찾아 연결하도록 변경했습니다.

01응답 확인
HTML / 5xx 감지
02작업 조회
본인의 진행 중 작업
03조건 비교
시각 · 부서 · 등록자 · 길이
04다시 연결
기존 작업 ID로 상태 조회

서버와 클라이언트의 시각 차이를 보정하고 여러 조건이 일치하는 경우에만 연결합니다. 조건 기반 재연결이며 중복 실행을 완전히 막는 idempotency 보장은 아닙니다.
2026.09.11 변경 기록과 구현에서 확인한 동작입니다. 실제 재연결 성공률이나 중복 감소율은 아직 집계하지 않았습니다.

06 / FAILURE HANDLING

단계별 실패와 결과 보존

서버 재시작 후 재처리는 남은 녹음으로 새 작업을 시작하는 방식입니다. 이전 추론의 중간 지점에서 자동 재개하는 구조는 아닙니다.

상황	구현한 처리
화자 분리 실패	화자 라벨 없이 전사 결과로 다음 단계 진행
요약 API 실패	전사본과 요약 실패 안내를 저장
Notion 전달 실패	회의록을 로컬에 보존하고 전달 오류를 별도로 기록
처리 중 서버 재시작	작업 기록을 복원해 중단 상태로 표시. 녹음이 남아 있으면 재처리

07 / DATA FLOW

SSO와 데이터 전달 범위

Google SSO로 로그인하며 앱의 목록·상세 화면에서는 본인이 등록한 회의록을 조회합니다. Notion은 별도의 부서별 전달 경로를 사용합니다. 음성의 로컬 처리와 전사 텍스트의 외부 요약 API 전송을 구분해 설명합니다.

공개 데모는 샘플 데이터로만 동작합니다. 사내 녹음, 전사본, 고객 정보와 운영 자격 증명은 공개 페이지에 포함하지 않습니다.

08 / EVIDENCE

확인한 결과와 측정 범위

2026.09.15 기준 구현과 변경 기록에서 작업 재연결, 중단 기록 복원, 부분 결과 보존 경로를 확인했습니다. 현재 RTX 4090 사내 운영 환경과 공개 UI 데모는 별도입니다.

기존 기록의 “56분 파일, 약 28초”는 청크 방식 화자 분리 단계의 단일 사례입니다. 전체 처리 시간이나 반복 벤치마크로 사용하지 않습니다. 사용 기록은 월별 이용 통계에 제시했습니다. 사람이 절약한 시간, 사용자 만족도와 단계별 성공률은 아직 측정하지 않았습니다.

ENGINEERING DECISIONS

설계 판단

요청 수명과 작업 수명 분리

긴 GPU 처리는 서버 작업으로 유지하고 화면은 작업 ID로 진행 상황을 조회합니다. 업로드 시작 응답이 유실된 경우에는 조건에 맞는 기존 작업을 찾아 연결합니다.

완성되지 않아도 남길 수 있는 결과 보존

화자 분리 실패 시 화자 없는 전사로 이어가고, 요약 실패 시 전사본을 보존합니다. 생성된 회의록과 Notion 전달 오류도 각각 기록합니다.

복구 가능성과 성공률 구분

재연결·재처리 경로가 있다는 사실과 실제 복구 성공률은 다릅니다. 완료 상태만 세면 요약·외부 저장 실패가 누락될 수 있어 단계별 결과를 함께 봐야 합니다.

SCOPE & LIMITS

한계와 검증 범위

구현 기록 검토는 장기 운영 성능이나 전체 보안 검증을 대신하지 않습니다. 사내 코드와 회의 데이터는 비공개입니다.
완료 작업 수와 요약·전달 성공 수를 구분해야 합니다. 반복 사용, 수동 수정 시간, 재처리 성공률은 별도 집계가 필요합니다.

UI 데모 ↗

다음 사례MED-RAG ↗

Contact

hyunaeee@gmail.com ↗

대한민국 · 한국어 / 영어