
코칭 세션과 현장 실사를 기록으로 남기는 일은 이제 녹음 버튼 하나로 끝납니다. 문제는 그다음입니다. 같은 음원을 두 엔진에 넣었더니 처리 시간이 17배 차이 났고, 빠른 쪽은 회의록의 핵심 단어 하나를 0회 잡았습니다. 어느 쪽이 좋은 엔진이냐는 질문은 답이 없습니다. 답이 있는 질문은 “이 녹취에는 어느 쪽이냐”입니다.
- 속도 — 2시간 24분짜리 현장 녹취를 맥오에스 내장 SpeechAnalyzer는 54초에, 착석 녹취 앱 Alt(알트)는 15분 10초에 처리했습니다. 실시간 대비 각각 160배와 9.5배입니다.
- 대가 — 그 17배의 대가는 명확했습니다. 회의록 핵심 항목인 “장기재고”를 느린 쪽은 7회 잡았고 빠른 쪽은 0회 잡았습니다. 화자 분리도 느린 쪽에만 있습니다(7명).
- 결론 — 두 엔진은 우열이 아니라 용도가 갈리는 두 레인입니다. 회의록을 정본으로 만들 녹취는 느린 쪽, 현장에서 30분 뒤 초안이 필요한 녹취는 빠른 쪽. 아래 6장면 판단표에 상황별로 정리했습니다.
Part 1 · Why왜 같은 음원으로 두 번 돌려봤나
코칭·컨설팅을 하면 녹취가 쌓입니다. 1:1 세션, 현장 실사, 워크숍, 경영진 보고. 그런데 어떤 엔진으로 풀 것인가는 대개 처음 써본 것으로 굳습니다. 저도 그랬습니다. 맥오에스 내장 SpeechAnalyzer 파이프라인을 정본으로 쓰면서, 그 선택을 뒷받침하는 비교를 한 번도 해본 적이 없었습니다.
그래서 가장 조건이 나쁜 녹취 하나를 골랐습니다. 제조 현장을 걸어 다니며 진행한 워크스루 실사입니다. 마이크에서 화자가 멀고(원거리 수음), 여러 명이 겹쳐 말하고, 설비 소음이 깔리고, 이동 중이라 음량이 계속 흔들립니다. 조건이 좋은 음원은 어떤 엔진이든 잘 풉니다. 갈리는 지점은 나쁜 조건입니다.
| 항목 | 값 | 확인 |
|---|---|---|
| 길이 | 8,660초 = 02:24:20 | O 실측 |
| 포맷 | 44.1kHz · 모노 · 63kbps | O 실측 |
| 성격 | 제조 현장 워크스루 — 이동 중 · 다자 화자 · 설비 소음 | O 관측 |
| 음량 | 피크 0.108 — 정규화 이득 6.48배가 필요한 저음량 | O 실측 |
※ 음원은 고객사 실사 녹취라 회사·지역·제품을 특정할 수 있는 정보는 전부 제거했습니다. 본문의 전사 인용도 엔진 오인식을 비교하는 데 필요한 최소 발췌입니다.
Part 2 · What두 엔진은 무엇이 다른가
비교 대상은 둘입니다.
하나는 SpeechAnalyzer — 애플이 맥오에스에 넣은 음성인식 프레임워크입니다. 운영체제 기본이라 별도 설치가 없고, 오디오가 기기 밖으로 나가지 않습니다. 저는 이것을 오디오 변환 → 저음량 보정 → 전사로 이어지는 명령 한 줄짜리 파이프라인으로 감싸서 씁니다.
다른 하나는 Alt(알트) — 회의 녹취에 특화된 국내 데스크톱 앱입니다. 공개 음성인식 모델의 양자화판을 기기에서 돌리고, 여기에 화자 분리 모듈을 얹었습니다. 즉 둘 다 기기 안에서 처리되지만, 뒤에 붙은 것이 다릅니다.
| SpeechAnalyzer 맥오에스 내장 | Alt 착석 녹취 앱 | |
|---|---|---|
| 실행 위치 | 기기 내부 · 운영체제 프레임워크 | 기기 내부 · 앱 내장 엔진 |
| 화자 분리 | ❌ 없음 | ✅ 있음 |
| 설치 | 불필요(운영체제 기본) | 앱 설치 |
| 파일 투입 | 명령 한 줄 · 일괄 처리 가능 | 앱 화면에서 업로드 |
| 기록 보관 | 내 폴더에만 남음 | 앱 노트로 저장 · 계정 동기화 대상 |
Alt는 결과를 앱의 노트로 저장하고, 그 노트는 계정 동기화 대상입니다. 처리 자체는 기기 안에서 일어나지만 결과물의 보관 위치는 다릅니다. 고객사와 비밀유지 약정이 걸린 녹취라면 이 차이가 기능 차이보다 먼저 걸립니다. 자세한 판단은 6장면 판단표 ⑥번을 보십시오.
Part 3 · Numbers54초 대 15분 10초, 그리고 그 대가
같은 파일을 두 엔진에 넣고 벽시계로 쟀습니다. 격차는 예상보다 컸습니다.
| 지표 | SpeechAnalyzer | Alt | 판정 |
|---|---|---|---|
| 처리 시간 | 54초 | 15분 10초 | SpeechAnalyzer가 17배 빠름 |
| 실시간 대비 배속 | 160배 | 9.5배 | — |
| 구간 수 | 666 | 1,462 | Alt가 더 잘게 끊음 |
| 글자수(공백 제외) | 18,014 | 20,733 | Alt가 15% 많음 |
| 현장 용어 출현 | 64회 | 103회 | Alt가 1.6배 |
| 화자 분리 | ❌ | ✅ 7명 | Alt 단독 |
여기서 눈여겨볼 것은 마지막 두 줄입니다. 속도에서 진 쪽이 내용에서 이겼습니다. 그리고 그 차이는 평균값이 아니라 특정 단어에서 몰려서 나타났습니다.
Part 4 · Evidence같은 40초, 두 개의 기록
수치보다 실물이 빠릅니다. 녹음 시작 55초 지점, 실사를 주재하던 임원이 담당자에게 묻고 담당자가 답하는 대목입니다. 실제 발화는 “전사적자원관리도 잘 맞고 물건이 제자리에 있으면 뭐가 문제냐”였습니다.
| 엔진 | 같은 구간 전사 결과 |
|---|---|
| SpeechAnalyzer 맥오에스 내장 |
관리가 안 된다라고 나 생각을 했는데 VR도 잘 맞고 제 자리에 살 있으면 뭐가 문제죠? |
| Alt 착석 녹취 앱 |
화자1 · 나는 지금 가장 ERP하고 잘 안 맞고 물건이 제자리에 없으니까 관리가 안된다라고 생각을 했는데 화자1 · ERP 잘 맞고 제자리에 딱 있으면 뭐가 문제죠? 화자2 · 잘 안 맞는다는 지적이 나오는 때가 특히 성수기 때 |
두 가지가 갈립니다. 첫째, 핵심 용어입니다. Alt는 “ERP”를 정확히 잡았고 SpeechAnalyzer는 “VR도”로 흘렸습니다. 회의록을 쓸 때 이 한 글자 차이가 문장 전체의 뜻을 바꿉니다.
둘째, 화자입니다. 이 구간은 임원이 묻고 담당자가 답하는 구조인데, SpeechAnalyzer 출력은 두 사람 발언이 한 줄에 이어 붙어 있습니다. 질문과 답변이 섞이면 회의록 작성자가 기억으로 화자를 복원해야 하고, 그 복원은 자주 틀립니다.
Part 5 · Practice필자는 Alt를 실제로 어떻게 쓰는가
벤치마크는 하루짜리 실험이지만, 판단은 그 앞의 두 달에서 나왔습니다. 제가 Alt를 쓰기 시작한 것은 2026년 6월 5일이고, 이 글을 쓰는 시점까지의 사용 기록은 아래와 같습니다.
| 항목 | 값 |
|---|---|
| 사용 기간 | 2026-06-05 ~ 2026-07-26 (약 7주) |
| 녹취 세션 | 36건 |
| 총 녹음 길이 | 88.4시간 (5,301분) |
| 세션 평균 길이 | 147분 — 대부분이 반나절짜리 워크숍·실사입니다 |
| 전사 구간 누계 | 50,453개 |
| 자동 요약 생성 | 36건 중 33건 |
| 화자 분리 적용 | 2026-07-20 노트부터 — 그 이전 기록에는 없습니다 |
실제 흐름 — 녹음 버튼부터 회의록까지
앱 안에서도 검색은 됩니다. 그런데 회의록·보고서·산출물은 프로젝트 폴더에 있고, 근거가 되는 전사는 앱 안에 있으면 둘이 영영 만나지 않습니다. 인용하려면 매번 앱을 열어 찾아 복사해야 하는데, 그 마찰이 결국 “기억으로 쓰기”로 이어집니다. 전사를 산출물 옆에 두는 것 — 이게 제가 도구를 고를 때 성능 다음으로 보는 기준입니다.
덧붙이면, 화자 분리는 제가 쓰기 시작한 뒤에 들어온 기능입니다(2026년 7월 20일 기록부터). 그 전 두 달치 녹취에는 화자 라벨이 없어서 회의록을 쓸 때마다 “이건 누가 한 말이지”를 기억으로 메웠습니다. 지금 제가 화자 분리를 이렇게 강조하는 것은, 없이 두 달을 써봤기 때문입니다.
Part 6 · Cases코칭·컨설팅 6장면 판단표
여기까지가 실측입니다. 이제 실무입니다. 아래는 제가 실제로 마주치는 여섯 장면과, 각 장면에서 어느 레인을 고르는지입니다. 판단 기준은 하나로 요약됩니다 — “이 기록에서 누가 말했는지가 중요한가”.
| 장면 | 무엇이 걸려 있나 | 선택 | 이유 |
|---|---|---|---|
| ① 현장 워크스루 실사 이동 · 다자 · 소음 |
당일 저녁 1차 정리본이 필요하고, 며칠 뒤 정본 회의록도 필요하다 | 둘 다 순차 사용 |
현장에서 나오자마자 SpeechAnalyzer로 54초 초안을 뽑아 기억이 살아 있을 때 메모를 붙이고, 정본은 Alt로 다시 돌려 화자와 용어를 채웁니다 |
| ② 1:1 코칭 세션 착석 · 2인 |
코치의 질문과 코치이의 답을 구분해야 다음 세션 설계가 된다 | Alt | 2인 대화는 화자가 섞이면 기록의 가치가 절반이 됩니다. 45분 세션이면 처리도 5분 안쪽이라 속도가 문제되지 않습니다 |
| ③ 워크숍 퍼실리테이션 다자 · 조별 |
어느 조에서 어떤 의견이 나왔는지가 산출물의 근거다 | Alt | 조별 발언 귀속이 핵심입니다. 다만 종일 워크숍이면 처리가 1시간 가까이 걸리니 세션별로 끊어 올리는 편이 낫습니다 |
| ④ 경영진 보고 회의 결정 · 액션 |
“누가 무엇을 지시했나”가 그대로 실행 항목이 된다 | Alt | 결정·액션 항목은 발언자와 묶여야 효력이 있습니다. 화자 없는 전사는 “누군가 그렇게 말했다”로 남습니다 |
| ⑤ 강의·특강 녹취 단일 화자 · 장시간 |
내 발화를 교안·글감으로 회수하는 것이 목적이다 | SpeechAnalyzer | 화자가 한 명이면 분리할 것이 없습니다. 2시간 강의가 1분 안에 텍스트가 되고, 여러 회차를 한꺼번에 돌리기도 쉽습니다 |
| ⑥ 비밀유지 등급 높은 녹취 고객사 내부 정보 |
결과물이 어디에 저장되는지가 기능보다 먼저다 | SpeechAnalyzer | 결과가 내 폴더 밖으로 나가지 않습니다. 화자 분리를 포기하는 대신 보관 경로를 통제합니다 — 약정 위반은 되돌릴 수 없습니다 |
Part 7 · Limits이 비교가 말할 수 없는 것
수치를 그대로 옮기기 전에 알아야 할 한계가 있습니다. 저는 이 비교로 “어느 엔진이 더 정확한가”를 판정하지 않았습니다. 그럴 자격을 갖추지 못했기 때문입니다.
| 한계 | 무슨 뜻인가 |
|---|---|
| 정답지가 없다 | 사람이 직접 듣고 받아쓴 기준 전사가 없어 단어오류율(WER)·문자오류율(CER)을 계산하지 않았습니다. 대신 현장 용어가 몇 번 잡혔는가를 대리 지표로 썼습니다 |
| 대리 지표의 한계 | 따라서 “64회 대 103회”는 방향은 말해도 정확도 비율은 아닙니다. 10% 안쪽 차이라면 우열로 읽지 마십시오 |
| 표본 한 건 | 조건이 가장 나쁜 녹취 하나입니다. 조용한 회의실의 짧은 녹취에서는 순서가 달라질 수 있습니다 |
| 시간 측정 범위 | Alt 쪽 15분 10초는 업로드·변환·화자분리를 모두 포함한 Alt 전체 소요입니다. 순수 전사 시간만 떼어내지는 않았습니다 |
이번에 같은 파일로 다시 재면서, 제 작업 메모에 적어둔 수치 하나가 재현되지 않는 것을 발견했습니다. “저음량 보정을 안 하면 구간이 26% 사라진다”고 적어둔 것인데, 다시 재보니 그렇지 않았습니다(보정 후 값은 그대로 재현됐고 보정 전 값만 달랐습니다). 보정 자체는 여전히 유효하지만, 그 숫자는 인용을 멈췄습니다. 측정치는 기록해둔 순간부터 낡기 시작합니다.
Part 8 · Action오늘 적용하는 법
정리하면 할 일은 셋입니다.
덧붙이면, 저는 이번에 후보 엔진을 하나 더 시험했다가 채택하지 않았습니다. 기본 설정으로 2시간 24분을 통째로 넣었더니 같은 문장을 끝없이 되풀이하는 상태에 빠졌기 때문입니다. 흥미로운 것은 그것이 모델의 한계가 아니라 설정 하나 때문이었다는 점인데, 그 이야기는 이 글의 범위를 넘습니다. 다만 교훈 하나는 옮겨둘 만합니다.
글자수를 보지 마십시오. 되풀이에 빠진 전사는 오히려 글자수가 폭증합니다(실제로 정상 결과의 4.7배가 나왔습니다). 대신 서로 다른 문장이 전체의 몇 퍼센트인가를 보십시오. 정상 전사는 90%를 넘고, 무너진 전사는 한 자릿수로 떨어집니다. 긴 녹취를 자동으로 돌리신다면 이 비율 하나만 로그에 찍어도 사고를 막습니다.
- 음원 1건 · 8,660초(02:24:20) · 제조 현장 워크스루 실사 · 2026-07-21 녹음. 고객사 식별 정보는 전량 제거.
- 맥오에스 내장 SpeechAnalyzer는 운영체제 프레임워크 기반 자체 파이프라인(오디오 변환 → 피크 정규화 → 전사)으로 실행. Alt는 앱 내 파일 업로드 기능으로 동일 파일 투입(언어 한국어 · 화자 인식 켬).
- 처리 시간은 벽시계 기준. Alt 쪽은 노트 생성 시각과 전사 기록 시각의 차이로 측정 — 업로드·변환·화자분리 포함.
- “현장 용어”는 해당 실사의 정리본에서 추출한 25개 용어의 출현 횟수 합계. 사람이 재구성한 문서 기반이므로 정답이 아니라 대리 지표입니다.
- 단어오류율·문자오류율은 산출하지 않았습니다(기준 전사 부재). 본문 Part 7의 한계를 함께 읽어주십시오.
- M-1 Agentic PM 시리즈 진입 가이드 — 전체를 한 장으로
- Z-1 실록(Sillok) — 5세기 Audit-Grade 거버넌스를 LLM 운영에 빌려온 한국형 LLMOS 하네스
- Z-2 실록(Sillok) 2026 상반기 결산 — RAG·고객사·지능화 루프·오픈소스
- Z-3 하네스×RAG 기업 컨설팅 — 네 현장·환각 방지·TOP10 자가진단·진화 루프
- Z-4 하네스 엔지니어링 백서 — Weng 하네스론×실록 구조 매핑·자기개선 루프·정직한 결산
- Z-5 에이전트 스킬 수명주기 백서 — Dynamic Agent Skills 8단×실록 매핑(7 온전+1 갭)·분기 12문항 레퍼런스·PO/PM/PL 컨설팅 직역
- K-1 Agentic 시대, PM의 온톨로지맵 — Obsidian을 통해 나만의 RAG를 만드는 법
- K-2 Karpathy의 LLM과 Obsidian 지식 결합
- K-3 Karpathy의 autoresearch: PM에서의 적용 사례
- K-5 Karpathy LLM OS 시각으로 본 AX PM/PL 역량 — Claude Code 소스 교차 분석
- K-6 30시간 RAG 실측 — Karpathy llm-wiki vs obsidian-vault 양강 비교
- K-7 구글 OKF·Obsidian Vault·llm-wiki — 무엇을 어떻게 시작할까
- K-8 Obsidian × LLM 4만 노트 — 개인 RAG 최종 아키텍처 5층
- K-9 PM 온톨로지맵 템플릿 배포판 — 30분에 채우는 5칸
- P-0 7인의 사고 체계 종합 프레임워크
- P-1 Karpathy: 제약 설계 + 닫힌 루프
- P-2 Sutskever: 압축이 곧 지능이다
- P-3 Hassabis: 제1원리 분해
- P-4 LeCun: 세계 모델 + 예측
- P-5 Hinton: 거버넌스 + 자기부정
- P-6 Ng: AI 전환 플레이북
- P-7 Fei-Fei Li: 인간중심 설계
- P-8 Builders 종합: Boris·Cat·Truell·Masad·Murati·Brockman
- P-9 Operators 종합: Altman·Amodei·Nadella·Pichai·Zuckerberg·Suleyman
- P-10 Hardware 양강: Jensen Huang · Lisa Su
- P-11 DeepSeek 량원펑 — 연속 학습의 공백과 하네스
- X-1 AI/AX 2030 전략: McKinsey, BCG, Accenture, Deloitte, Gartner 교차 분석
- X-2 빅테크 리더십 격변과 AX 전략
- X-3 2026년 GitHub에서 주목할 프로젝트와 AI 전환 신호
- X-4 AI 에이전트 2026 상반기 대해부 — 지금 무슨 일이, 리더는 무엇을
- W-1 Agentic 월간 관전포인트 2026-05 — 가우스+빅테크 듀얼 모델 시대
- W-2 Agentic 2026 상반기 총결산 — 다섯 축 6개월
- E-1 AI 네이티브 기업 전환 — CHO·PMO 재정의
- E-2 한국 기업 AX 2030 (Capstone)
- E-3 NH농협은행 SAFe 애자일 3년 — 페이스메이킹의 기록
- E-4 하나은행 × BCG 애자일 전환 — 두 개의 리듬으로
- E-5 네이버랩스 AKI — 하이브리드 애자일 PMO로 7개 제품을 한 박자로
- S-1 Agentic PM의 시대가 열리다 — LG전자 SW PM 워크숍을 마치며
- S-2 삼성전자 PMC: AI와 함께하는 PM 교육 혁신
- S-3 SKT Agent 도출을 위한 AI 퍼실리테이션 기법
- S-4 리스크는 그릇이었다 — LG전자 SW공학연구소 GenAI RISK 워크숍
- S-5 코드 한 줄 없이 손익관리팀이 만든 에이전트 — 신한EZ손해보험
- S-6 “어디까지 입력해도 되나요?” — 삼성 구매 현장의 Agentic 각성
- S-7 지금 Agentic으로 전환해야 하는 이유 — 삼성·LG·KT·Clean&Science 300여 분의 증명
- S-8 ‘바이브 프로젝트 매니징’을 스스로 이름 붙였습니다 — 현대모비스 편
- S-9 “대충 시키면 다 해줄 줄 알았는데” — SK쉴더스 보안 PM들의 이틀
- S-10 휴맥스 전사 ALM 정착 — 표준 4개를 codeBeamer 하나에
- S-11 AI로 신약 프로젝트 관리 — KDRA 바이오 PM 3일 워크숍
- S-12 AI 바이오·제약 회사는 무엇부터 자동화해야 하는가 — 26주 실측
- S-13 에이전트를 어디까지 붙일 것인가 — 되돌릴 수 없는 일 먼저 NEW
- S-14 같은 기준, 다른 답 — 22개 업무 유형의 사람 확정 지점 NEW
- S-15 가장 무거운 일은 전문 업무가 아니었다 — 에이전트 10종 NEW
- G-1 삼성전자 GAUSS PM Agent: 효과적 설계로 주니어 PM 지원하기
- G-2 주니어 PM 위한 AI 하네스 구축 가이드
- G-4 삼성 DX 엔지니어를 위한 Codex 온보딩 — 하네스 & 개인 RAG
- G-5 나의 Agent 비서, 블록 12개로 조립한다 — 재사용 블록과 77%의 법칙
- G-6 내 업무를 맡길 AI 에이전트 — 6블록 설계와 PROFILE BIND
- CC-6 사내 지식을 RAG로 — 망분리·토큰0 6단계
- CC-4 내 노트 4만 개 검색 — LLM 직접 읽기 vs 전용 CLI, 하이브리드 5.5배
- CC-5 Obsidian 노트를 앱 없이 검색 — 오픈소스 byeori(벼리)
- A-5 Fable 5와 보낸 첫 하루 — 모델 × 하네스 × RAG 실측 회고
- A-8 좋은 엔진은 없다, 맞는 엔진이 있다 — Codex/Sol vs Claude/Fable 5대 실전 비교
- CC-3 Opus xhigh 솔로 vs ultracode 멀티에이전트 — 작업유형별 A/B 실측
- A-6 맥은 이미 AI 워크스테이션 — 사진·노트·인박스 0원 정리
- A-7 Mac@Work 2026 — 맥 20년차의 도구 모음과 Agentic 카테고리
- G-3 대기업 직장인을 위한 AI Agent & Skill 추천 가이드 2026
- G-7 녹취 엔진 두 레인 — SpeechAnalyzer와 Alt, 코칭·컨설팅 6장면 판단표