Dev on 42Class

Meetnote 개발 회고 — 로컬 회의록 자동화 Obsidian 플러그인

Sun, 05 Apr 2026 00:00:00 +0000

왜 만들었나

회의가 끝나고 나면 항상 같은 고민이 반복됐다. “누가 뭐라고 했더라?” 회의록을 작성하자니 회의에 집중이 안 되고, 녹음만 해두면 다시 듣기가 귀찮다. 기존 SaaS 서비스들은 비용도 문제지만, 회의 내용이 외부 서버로 나가는 것 자체가 부담스러웠다.

그리고 결정적인 이유가 하나 더 있었다. 지금 모든 업무 문서를 Obsidian에서 마크다운으로 관리하고 있는데, 이건 AX(AI Transformation) 관점에서 매우 중요한 선택이었다. 마크다운은 AI 에이전트에게 전달하기 가장 좋은 포맷이다. 회의록도 마크다운으로 생성되면 별도 서비스에서 옮기는 번거로움 없이, 다른 업무 문서들과 함께 한 곳에서 관리할 수 있다. 에이전트가 과거 회의 맥락을 참조하고, 액션 아이템을 추적하고, 관련 문서를 연결하는 것까지 자연스럽게 이어진다.

그래서 만들었다. 완전히 로컬에서 동작하는 회의록 자동화 도구. 비용 0원, 오프라인 가능, GPU 가속. 그리고 결과물은 Obsidian Vault 안의 마크다운 파일.

무엇을 만들었나

Meetnote는 Obsidian 플러그인 + Python 백엔드로 구성된 로컬 회의록 자동화 도구다.

핵심 기능:

실시간 음성 인식 — Whisper large-v3-turbo, 5초 단위 스트리밍
화자 분리 — pyannote 3.1, GPU 자동 감지
화자 식별 — 임베딩 DB 기반, 회의할수록 정확도 향상
AI 요약 — Claude CLI / Ollama, 액션 아이템 자동 생성
이메일 발송 — 참석자별 회의록 HTML 메일
암호화 — AES 암호화, 자동 삭제, 감사 로그

Apple Silicon 기준 60분 회의를 약 5분 만에 처리한다.

기술 스택

영역	기술
Plugin	TypeScript, Obsidian API, Web Audio API
Backend	Python, FastAPI, WebSocket
STT	mlx-whisper (Apple Silicon), faster-whisper (CPU)
화자 분리	pyannote.audio 3.1
화자 임베딩	wespeaker-voxceleb-resnet34-LM
AI 요약	Claude CLI, Ollama
배포	Docker, GitHub Actions, GHCR

아키텍처

┌─────────────┐ WebSocket (PCM 16kHz) ┌──────────────┐
│ Obsidian │ ──────────────────────────────▶│ FastAPI │
│ Plugin │◀────────────── JSON ──────────│ Backend │
│ (TS) │ │ (Python) │
└─────────────┘ └──────┬───────┘
 │
 ┌─────────────────┼─────────────────┐
 │ │ │
 ┌─────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐
 │ Whisper │ │ pyannote │ │ Speaker │
 │ STT │ │ Diarizer │ │ Embedding │
 └───────────┘ └─────────────┘ └─────────────┘

Plugin이 Web Audio API로 마이크 음성을 캡처해서 5초 단위로 WebSocket을 통해 바이너리 전송한다. 백엔드는 Whisper로 실시간 전사하고, 녹음 종료 후 pyannote로 화자 분리를 수행한다. 전사 결과와 화자 분리 결과를 시간 기반으로 병합해서 “누가 무슨 말을 했는지” 최종 결과를 만든다.

개발 과정에서 마주친 문제들

1. MLX vs faster-whisper — 플랫폼별 분기

Apple Silicon에서는 MLX가 압도적으로 빠르지만, Linux/CUDA 환경에서는 faster-whisper가 낫다. 처음에는 하나로 통일하려 했지만, 성능 차이가 너무 커서 런타임에 플랫폼을 감지하고 분기하는 방식을 택했다.

2. 화자 분리와 전사 결과 병합

Whisper와 pyannote는 독립적으로 동작한다. 둘의 타임스탬프가 정확히 일치하지 않기 때문에, 시간 구간의 최대 겹침(temporal overlap)을 기준으로 화자를 배정했다. 같은 화자의 연속 발언은 5초 이내 간격이면 하나로 합친다.

3. 환각(Hallucination) 필터링

Whisper는 가끔 무음 구간에서 환각을 일으킨다. no_speech_prob과 compression_ratio를 기준으로 품질 필터를 넣어 해결했다. LLM 기반 전사 보정도 추가했는데, 고유명사나 전문 용어의 정확도가 체감될 정도로 올라갔다.

4. 동시 녹음 세션 처리

Transcriber와 Diarizer는 GPU 메모리를 많이 쓰기 때문에 싱글톤으로 관리한다. 하지만 여러 사용자가 동시에 녹음할 수 있어야 하므로, WebSocket 세션별로 격리하되 공유 리소스는 Lock으로 보호하는 구조로 만들었다.

5. Docker 빌드 최적화

처음 Docker 빌드는 46분이 걸렸다. PyTorch + pyannote 의존성이 무거웠기 때문이다. base 이미지와 app 이미지를 분리하고, GitHub Actions에서 base 이미지를 캐싱하는 방식으로 빌드 시간을 3분까지 줄였다. 이후 추가 최적화로 1분대까지 단축했다.

누적 학습 — 화자 임베딩 DB

가장 만족스러운 기능이다. 회의에서 새로운 화자가 감지되면 임베딩 벡터를 자동 저장한다. 다음 회의에서 코사인 유사도(임계값 0.70)로 기존 화자와 매칭한다. 회의를 할수록 화자 인식 정확도가 올라가는 구조다.

타임라인

집중적으로 작업한 건 약 일주일. 115개 커밋, 혼자서 기획부터 배포까지.

Phase 0 — MVP: 실시간 전사, 화자 분리, 요약, 암호화, RAG 검색
Phase 1 — 안정화: 버그 수정, 환각 필터, 품질 최적화
Phase 2 — UX: 사이드 패널, 화자 관리 UI, 이메일, 원클릭 설치
Phase 3 — 배포: Docker, GHA 캐싱, 온보딩 모달, 보안 강화

돌아보며

일주일이라는 짧은 기간이었지만, “내가 직접 쓸 도구"를 만드는 과정이라 몰입도가 높았다. 특히 화자 임베딩 DB의 누적 학습은 쓸수록 똑똑해지는 느낌이 있어서 뿌듯하다.

아쉬운 점은 Windows 네이티브 지원이 아직 Docker(WSL2) 의존이라는 것. 그리고 CPU 환경에서는 60분 회의 처리에 40분이 걸려서 실용성이 떨어진다.

다음 목표는 웹 기반 대시보드와 팀 단위 화자 DB 공유 기능이다.

Meetnote — 로컬 회의록 자동화

Obsidian plugin for local meeting transcription, speaker diarization, and AI summarization

GitHub에서 보기 →

Spring DATA JPA in MySQL에서 Pessimistic Lock(비관적 락) 처리

Wed, 03 Feb 2021 00:00:00 +0000

WMS운영 중 비정상적인 락 처리 현상이 있어 확인한 결과 공유드립니다. Spring DATA JPA in MySQL에서 Pessimistic Lock(비관적 락) 처리

락 어논테이션으로 처리 : @Lock(LockModeType.PESSIMISTIC_WRITE)
쓰기,읽기 모두 lock를 거는 방식이지만 실제로는 읽기에 대핸 lock이 걸리지 않음
읽기도 lock을 걸려면, 해당 row에 접근하는 select 쿼리에 모두 for update구문을 걸어줘야 함(@Lock(LockModeType.PESSIMISTIC_WRITE))
해당 락은 row level lock이지만 mysql innoDB의 락 처리 방식은 인덱싱 되지 않은 조건으로 선별 된 row에 대해선 row level로 락은 잡지 못함
mysql innoDB는 인덱싱 범위에 대해서 락을 잡는 방식으로 인덱싱 되지 않은 조건으로 선별 된 select결과는 row가 아닌 테이블이 락이 걸리는 현상이 발생됨
락을 걸어야 하는 데이터 셋의 검색조건은 인덱싱된 컬럼을 기준으로 잡아야 함
JPA에서 lock scope범위에 따라 릴레이션 된 모델들도 함께 락이 잡히게 됨
대상 테이블만 락의 범위로 잡으려면 scope를 지정해줘야 함
락 범위 어논테이션으로 처리 : @QueryHints(value = {@QueryHint(name = “javax.persistence.lock.scope”, value = “NORMAL”)})

JPA N+1튜닝과정에서 선언한 배치 사이즈와 다르게 쿼리 분할 되어 수행되는 이유

Mon, 01 Feb 2021 00:00:00 +0000

JDBC preparedstatement의 캐싱 방식

먼저 이 현상을 설명하려면 JDBC의 preparedstatement의 캐싱 방식을 알아야 합니다.
preparedstatement는 in절이 들어가는 select 쿼리에 대해 각 경우를 모두 캐싱합니다.

# 데이터가 1개 들어올 때 : where xxx in (?)
# 데이터가 2개 들어올 때 : where xxx in (?,?)
# 데이터가 n개 들어올 때 : where xxx in (?,?, ...)

hibernate의 batch_size에 의한 캐싱 방식

위의 방식으로 캐시되는 경우 데이터가 많아질수록 많은 케이스를 캐싱해야 해서 성능에 문제가 발생합니다.
그래서 하이버네이트는 최적화를 위해 캐싱케이스를 줄이는 방식으로 수행됩니다.
줄이는 방식은 프로젝트에 선언 된 기본배치사이즈 (hibernate.default_batch_fetch_size: 100) 를 기준으로 절반씩 나눠가면서 캐싱합니다.
그리고 자주사용할 것으로 예상되는 1~10 사이는 모두 캐싱 하게됩니다.
in절 항목값을 100으로 잡을 때, 기존 preparedstatement 방식에 의하면 총 100개의 케이스를 캐싱해두게 됩니다.
하이버네이트의 방식으로 하게 되면 14개로 줄어듭니다.
(1,2,3,4,5,6,7,8,9,10,12, 25,50,100)

N+1이슈가 발생한 쿼리가 있고 총 데이터가 83건이면 83번의 동일한 쿼리가 나가는 상황일겁니다.
현상 튜닝을 위해 hibernate.default_batch_fetch_size: 100 으로 설정 후 조회합니다.
예상으로는 쿼리는 한번 나가고 in절 항목이 83개가 들어간 쿼리를 기대합니다.
하지만 실제로는 캐싱된 케이스에 의해 아래와 같이 총 3번의 동일한 쿼리가 나가게 됩니다.

in절 항목이 50으로 캐싱된 쿼리 한 번
in절 항목이 25로 캐싱된 쿼리 한 번
in절 항목이 8으로 캐싱된 쿼리 한 번

83개 항목이 분리 요청 된 실제 예

 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
 )
2020-08-07 17:33:30,948 DEBUG [XNIO-1 task-1] SQL:
 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
 )
2020-08-07 17:33:30,969 DEBUG [XNIO-1 task-1] SQL:
 select
 product0_.id as id1_38_0_,
 product0_.created_by as created_2_38_0_,
 product0_.created_date as created_3_38_0_,
 product0_.last_modified_by as last_mod4_38_0_,
 product0_.last_modified_date as last_mod5_38_0_,
 product0_.code as code6_38_0_,
 product0_.name as name7_38_0_,
 product0_.product_group_code as product_8_38_0_,
 product0_.product_type as product_9_38_0_
 from
 product product0_
 where
 product0_.id in (
 ?, ?, ?, ?, ?, ?, ?, ?
 )

최적화 전략

위와 같이 하이버네이트는 최적화 전략으로 수행됩니다.
3번의 캐싱된 쿼리가 수행되는 것은 정상적인 부분이며 하이버네이트에서 권장하는 기본전략입니다.
참고로, 선언한 (hibernate.default_batch_fetch_size: 100 ) 사이즈 만큼 in절 항목을 발생시키고 싶다면 설정파일에 hibernate.batch_fetch_style: dynamic을 추가하시면 됩니다.
하지만 이 방식은 캐싱되지 않은 케이스로 쿼리가 수행되므로 권장하지 않는 방식이라고 합니다.