quest_PoC

확장 로드맵 — 실전 적용을 위해 더 필요한 것

이 문서는 코드로 구현하지 않은 항목들을 다룹니다. 인프라·데이터·계정이 없는 상태에서 흉내만 낸 코드를 넣으면 “검증된 것처럼 보이지만 실제로는 검증되지 않은” 결과물이 되기 때문에, 대신 이 PoC로 실제로 확인한 것과 실전에 가려면 무엇이 더 필요한지를 정리합니다. (APPLICATION_POINTS.md의 “PoC의 산출물은 판단이다”와 같은 원칙입니다.)

1. 실무 프로세스 및 파이프라인 확장성

실시간 컨퍼런스콜 처리 (Streaming STT)

이 PoC에서 확인한 것: Whisper small 모델이 103초 오디오를 29초에 처리합니다(실시간의 약 3.5배 속도). 즉 배치(사후) 처리로도 이미 충분히 빠릅니다.

실시간으로 바꾸려면 필요한 것:

• Whisper 자체는 스트리밍 모델이 아닙니다 — 오디오를 청크(예: 5~10초)로 잘라 순차적으로 넣는 방식(faster-whisper의 VAD 기반 청크 처리, 또는 whisper-streaming 같은 래퍼)으로 흉내 내야 합니다.
• 청크 경계에서 문장이 잘리면 인식률이 떨어집니다 — 겹치는 구간(overlap)을 두고 뒤 청크에서 다시 인식해 합치는 로직이 필요합니다.
• “실시간 팝업 알림”은 이 PoC의 리스크 판정 로직(정규식 임계값 또는 Claude 호출)을 청크마다 반복 실행하는 것으로 확장 가능합니다 — 로직 자체는 이미 사후 처리와 동일하게 재사용할 수 있습니다.

판단: 기술적으로 불가능하지 않지만, 이 조직의 실적발표는 분기당 1회(APPLICATION_POINTS.md 참고)라 “실시간”의 긴급성이 크지 않습니다. 배치 처리로 몇 분 안에 브리핑이 나오는 지금 방식 대비 실시간 전환의 한계효용은 낮다고 판단합니다.

화자 분리(Diarization) 및 발표/Q&A 구별

이 PoC에서 확인한 것: notebooks/earnings_call_briefing_poc.ipynb 11번 섹션에서, 실제 화자 분리 없이 “질문”이라는 전환 문구로 발표 구간과 질의응답 구간을 나누는 저비용 프록시를 구현했습니다. 이걸로 “이 리스크가 발표 중 나온 것인지 Q&A 중 나온 것인지”는 구분되지만, 발화자가 누구인지(경영진 vs 애널리스트)는 구분하지 못합니다.

진짜 화자 분리를 하려면 필요한 것:

• pyannote.audio 같은 화자 분리 모델 — 다만 일부 모델이 AGPL 라이선스이거나 HuggingFace 게이트(토큰 발급) 조건이 있어, 도입 전 라이선스 확인이 먼저입니다(사진 검색기 예시와 같은 원칙).
• 화자 분리 결과와 Whisper 세그먼트를 시간축으로 정렬(alignment)하는 추가 로직.
• “이 화자가 경영진인지 애널리스트인지”는 화자 분리만으로는 알 수 없고, 목소리 등록(enrollment) 또는 “먼저 말하는 사람=경영진” 같은 휴리스틱이 추가로 필요합니다.

분석 가치: “경영진이 스스로 인정한 리스크”와 “애널리스트가 지적한 리스크”는 신뢰도가 다릅니다 — 전자는 이미 회사가 알고 대응 중인 이슈, 후자는 시장이 새로 제기한 이슈일 가능성이 높습니다. 브리핑에 이 구분이 있으면 “이미 알려진 리스크”와 “새로 제기된 리스크”를 다르게 우선순위화할 수 있어 실무 가치가 있다고 판단합니다.

2. 금융/재무 도메인 특화 및 신뢰성

도메인 특화 어휘/파인튜닝 ROI

이 PoC에서 확인한 것: initial_prompt로 회계 용어 사전을 주입했더니 일부 용어(“손익”, “총계”)는 고쳐졌지만 전부는 아니었습니다(“질의응답”→”지류응답”, “매출채권”→”매출책권”은 그대로— VALIDATION_RESULTS.md 4번 섹션 참고).

파인튜닝 ROI 판단:

• Whisper 파인튜닝에는 (a) 라벨링된 회계/재무 도메인 음성-텍스트 쌍 데이터, (b) GPU, (c) 파인튜닝 파이프라인 구축이 필요합니다 — 이 PoC 환경(로컬 CPU)에서는 실행 자체가 불가능합니다.
• 비용 대비 효과: 이번에 남은 오인식은 전부 리스크 판단에 쓰이는 숫자에는 영향이 없는 서술어 수준이었습니다. 파인튜닝은 “브리핑 문장이 매끄러운가”에는 도움이 되지만, “리스크를 놓치거나 잘못 판단하는가”에는 이미 영향이 없다는 뜻이라 우선순위가 낮습니다.
• 더 저렴한 대안: initial_prompt를 문장 형태로 더 구체화하거나(단어 나열이 아니라 실제 대화 예문), STT 이후 LLM 보정 단계를 추가하는 쪽이 파인튜닝보다 비용 대비 효과가 높을 것으로 판단합니다.

정확도 가드레일 및 Human-in-the-loop UI

이 PoC에서 확인한 것: segment_confidence(avg_logprob/no_speech_prob)를 리스크마다 남기고, 10번 섹션에서 근거 구간 오디오를 실제로 잘라 재생하는 기능까지 구현했습니다. 이 기능을 만드는 과정에서 실제로 근거 세그먼트가 잘못 잡혀 있던 버그를 발견해 고쳤습니다 — “1차 스크리닝 + 사람이 타임스탬프로 검증”하는 workflow가 실제로 오류를 잡아낸 사례입니다.

실전 UI로 만들려면 필요한 것: 노트북 셀 대신 웹 UI(예: Streamlit)에서 리스크 목록 클릭 → 해당 오디오 재생 + 원문 하이라이트를 보여주는 화면. 코드 로직(세그먼트 찾기, 클립 자르기)은 이미 있으므로 UI 레이어만 얹으면 됩니다 — 공수는 크지 않을 것으로 판단합니다(로직 재사용 가능, 프론트엔드 작업만 추가).

3. 멀티모달 융합 및 십자 검증

음성-재무제표 수치 대조

이 PoC에서 확인한 것: 12번 섹션에서 실제로 구현하고 검증했습니다. 음성에서 뽑은 수치(매출성장률 20%, 부채비율 233%, 유동비율 88.9%)를 정확한 재무제표와 대조하면 불일치가 없고, 일부러 틀리게 만든 재무제표(매출성장률 8%로 변경)와 대조하면 그 불일치를 정확히 잡아냅니다.

실전 적용 시 필요한 것: 지금은 재무제표를 코드 안의 딕셔너리로 하드코딩했습니다. 실전에서는 실제 IR 자료(PPT/Excel)를 파싱해 같은 형태의 딕셔너리를 자동 생성하는 단계가 필요합니다 — 원본 AI-project_MVP가 이미 Excel 파싱을 다루고 있으니, 그 파서를 재사용하면 큰 추가 공수 없이 연결 가능할 것으로 판단합니다.

음성 톤/감정 분석 (Acoustic Feature Analysis)

이 PoC에서 확인한 것: 없음 — 이번 파이프라인은 텍스트 전사 이후 단계만 다뤘습니다.

실전 적용 시 필요한 것:

• 피치, 멈춤(pause), 말 속도 등 음향 특징을 뽑는 별도 라이브러리(librosa, opensmile 등)와, 감정/불확실성을 분류하는 모델(예: wav2vec2 기반 감정 분류기).
• 더 중요한 문제: “경영진의 목소리 톤이 불확실하다”는 것을 리스크 지표로 쓰려면, 그 판정이 실제로 무엇을 재는지 검증할 방법이 필요합니다(예시 2의 “값이 계산된다고 의도한 것을 재고 있다는 뜻은 아니다”와 같은 문제). 발표자의 평소 말투, 긴장, 통역·자료 확인을 위한 정상적인 멈춤과 “회피성 멈춤”을 구분할 기준이 없으면, 이 지표는 오히려 잘못된 확신을 줄 위험이 있습니다.
• 판단: 이 PoC 범위를 크게 벗어나는 별도 연구 주제로, 지금 단계에서는 도입하지 않는 것이 맞다고 판단합니다. 도입한다면 “말투가 리스크와 실제로 상관관계가 있는지”를 과거 사례로 먼저 검증(라벨링된 데이터로 상관관계 확인)한 뒤에 판단해야 합니다.

4. 비즈니스 타겟 및 서비스 상품화

타겟 고객군

세 후보를 놓고 비교하면:

타겟	이 PoC가 바로 맞는 정도	이유
인하우스 기업 재무/기획팀	높음	PROBLEM_DEFINITION.md의 대상 사용자와 정확히 일치, 내부 초안 용도라 되돌릴 수 있음(APPLICATION_POINTS.md 참고)
증권사/자산운용사 애널리스트	중간	여러 회사의 컨퍼런스콜을 동시에 처리해야 하는 발생량 문제 해결에는 유리하지만, 리스크 판정 임계값(부채비율 200% 등)이 기업/산업마다 달라야 함(이미 인자화되어 있어 확장 가능 — APPLICATION_POINTS.md 4번 항목)
IR 컨설팅 대행사	낮음	여러 고객사 데이터를 다뤄야 해서 “음성을 외부로 전송하지 않는다”는 조건이 고객사마다 다른 계약을 요구할 수 있음

판단: 지금 만든 PoC의 가정(분기 1회, 내부용, 로컬 실행)과 가장 가까운 인하우스 재무/기획팀이 1차 타겟으로 적합합니다. 애널리스트 대상으로 확장하려면 “여러 기업의 임계값을 관리하는” 설정 레이어가 추가로 필요합니다.

기존 엔터프라이즈 시스템 연동

판단: Slack/Teams 알림이나 ERP/CRM/BI 연동은 이 PoC 코드에 가짜로 구현하지 않았습니다 — 실제 워크스페이스·계정이 없는 상태에서 만드는 연동 코드는 검증할 방법이 없어 오히려 “됐다고 착각하게 만드는” 위험이 있습니다(PROBLEM_DEFINITION.md와 같은 원칙).

실전에서는 risks.json(이미 notebooks/runs/<RUN_ID>/에 저장되고 있음)을 표준 산출물로 두고, 이걸 Slack Webhook/Teams Incoming Webhook/BI 대시보드가 읽어가는 방식이 연동 비용이 가장 낮을 것으로 판단합니다 — 이미 구조화된 JSON으로 저장하고 있으니, “무엇을 연동할지”보다 “각 채널의 API 인증을 누가 관리할지”가 실제 병목이 될 것입니다.