2시간의 컴플라이언스 서류 작업을 3분으로 단축하는 AI 구축 — 전체 아키텍처 분석

금융 어드바이저(Financial advisors)들에게는 숨기고 싶은 비밀이 있습니다. 그들은 업무 시간의 거의 절반을 누구에게도 조언하지 않는 데 소비한다는 점입니다.

그 원인은 무엇일까요? 바로 컴플라이언스(Compliance, 규제 준수) 문서화 작업입니다. 모든 고객 미팅이 끝난 후, 어드바이저들은 무엇을 논의했는지, 무엇을 권고했는지, 그 권고 사항들이 적절했는지, 그리고 FINRA 및 SEC 규정을 준수했는지를 그들의 CRM이 수용할 수 있는 형식으로 모두 기록해야 합니다.

45분간의 미팅은 통상적으로 2시간 분량의 서류 작업을 만들어냅니다.

저는 이 작업을 약 3분 만에 수행하는 오픈 소스(open-source) 도구를 구축했습니다. 모든 아키텍처(architectural) 결정, 모든 트레이드오프(trade-off), 그리고 중요한 모든 코드 라인을 통해 정확히 어떻게 구현했는지 설명하겠습니다.

문제는 생각보다 더 구체적입니다

자문 회사들과 대화를 시작했을 때, 저는 "미팅 시간이 너무 길다"거나 "더 나은 CRM 소프트웨어가 필요하다"라는 답변을 예상했습니다. 하지만 모든 컴플라이언스 담당자(compliance officer)는 똑같은 말을 했습니다.

"우리는 노트에 적힌 내용이 걱정되는 것이 아닙니다. 노트에 적히지 않은 내용이 걱정되는 것입니다."

진정한 고통은 문서화 속도가 아니라 컴플라이언스 격차(compliance gap)에 있습니다. 만약 고객이 "이 돈을 잃을 여유가 없습니다"라고 말했는데 어드바이저가 공격적인 성장 펀드를 권고한다면, 이는 FINRA 2111 적합성 위반(suitability violation)에 해당합니다. 하지만 기록자(보통 몇 시간 뒤 기억에 의존해 작성하는 어드바이저)가 그 인용구를 잊어버린다면? 위험 신호에 대한 기록이 남지 않게 됩니다.

이 점이 제 시스템 설계 전체를 바꾸어 놓았습니다. 이것은 단순히 형식을 맞추는 전사(transcription) 도구가 아닙니다. 불일치를 감지하여 듣는 컴플라이언스 엔진(compliance engine)입니다.

아키텍처 (Architecture)

4단계 파이프라인(pipeline):

오디오(Audio) → 전사(Transcription) → 구조화된 추출(Structured Extraction) → 컴플라이언스 체크(Compliance Check) → CRM 노트(CRM Note)
         (Whisper)          (OpenRouter를 통한 Claude)         (Rule engine)         (Formatter)

스택(Stack): Python/FastAPI + React 프론트엔드(frontend) + Whisper (로컬) + OpenRouter를 통한 Claude

두 가지 핵심 설계 선택:

1. Whisper는 로컬에서 실행됩니다. 자문 회의에는 개인정보(PII)와 법적 특권 정보가 포함되어 있습니다. 오디오를 제3자 API로 전송하는 것은 대부분의 기업에 있어 선택 사항이 아니라, 규제상 허용되지 않는 사항입니다.

2. 컴플라이언스 엔진은 LLM이 아닙니다. 확률론적 시스템(probabilistic system)이 결정론적(deterministic)인 컴플라이언스 판단을 내리게 해서는 안 됩니다. 컴플라이언스 체크는 구조화된 데이터(structured data)를 바탕으로 하드코딩된 규칙을 사용합니다. LLM의 역할은 추출(extraction) 단계에서 끝납니다.

추출 프롬프트 (The Extraction Prompt)

LLM은 가공되지 않은 전사 텍스트(raw transcript text)를 전달받아 구조화된 JSON을 반환합니다. 핵심 필드는 risk_signals입니다:

"risk_signals": [
    {
      "signal": "발화 내용",
...

대부분의 회의록 작성 도구는 주제와 실행 항목(action items)을 추출합니다. 이 시스템은 컴플라이언스 리스크를 나타내는 문구를 구체적으로 찾아냅니다 — "이 돈을 잃을 여유가 없습니다" (위험 허용도), "제 아내는 이 계좌에 대해 모릅니다" (문서화 문제), "그냥 당신이 최선이라고 생각하는 곳에 넣어주세요" (재량권 관련 우려).

온도(Temperature)는 0.1로 설정되었습니다. 컴플라이언스 관련 데이터를 추출할 때는 창의적인 해석을 원하지 않기 때문입니다.

컴플라이언스 엔진 (The Compliance Engine)

프로젝트에서 가장 단순한 코드입니다. 그것이 핵심입니다.

적합성 체크(suitability check)는 리스크 신호(risk signals)를 상품 추천 내용과 교차 참조합니다:

risk_averse_keywords = ["can't afford to lose", "conservative", "safe",
                        "no risk", "preserve capital", "nervous"]
aggressive_products = ["growth fund", "equity", "crypto", "leveraged",
...

이것이 키워드 매칭인가요? 네. 정교한가요? 사실 그렇지 않습니다. 컴플라이언스 담당자들에게 정확히 필요한 것인가요? 전적으로 그렇습니다.

출력은 신호등 시스템(traffic-light system)인 GREEN / YELLOW / RED로 나타납니다. 이는 컴플라이언스 부서가 이미 사고하는 방식과 직접적으로 매핑됩니다.

Reg BI 체크는 가장 흔한 조사 결과(examination finding)를 포착합니다:

has_alternatives = len(products) > len(recommended)
if not has_alternatives:
    status = "YELLOW"
...

화려하지는 않습니다. 하지만 수억 원대의 과태료를 방지합니다.

왜 오픈 소스인가?

코드가 경쟁 우위는 아닙니다. 유능한 개발자라면 누구든 Whisper → LLM → 규칙 엔진 (rule engine)을 체인(chain)으로 연결할 수 있습니다.

진정한 가치는 다음 사항에 있습니다:

1. 어떤 문제를 해결해야 하는지 아는 것. 기능들은 명세서(spec)가 아니라, 컴플라이언스 담당자들과의 수십 차례 대화를 통해 도출되었습니다.
2. 프로덕션 강화 (Production hardening). SOC 2, 온프레미스 (on-prem) 배포, CRM 통합, SSO, 감사 로깅 (audit logging).
3. 지속적인 지원. 컴플라이언스 규칙은 변합니다. FINRA는 규정을 업데이트합니다.

그것이 제가 하는 일입니다. 저는 혼돈을 자동화합니다 — 엔지니어링 기술 위에 도메인 전문 지식(domain expertise)이 요구되는, 지저분하고 수동적이며 규제된 워크플로우를 말이죠.

전체 코드베이스: github.com/archit-akg13/advisor-meeting-notetaker

저는 Archit Mittal입니다. 금융 서비스를 위한 AI 자동화를 구축합니다. 만약 귀하의 팀이 본업보다 서류 작업에 더 많은 시간을 소비하고 있다면, 제가 해결해 드릴 수 있습니다 → architmittal.com

매일 업데이트되는 AI 자동화 팁을 확인하려면 Twitter @automate_archit를 팔로우하세요.