한국GPT협회 표준교재

807. 회의 녹음에서 회의록까지 — STT 자동화

녹음 파일 하나를 넣으면 결정·이견·액션이 구조화된 회의록 HTML이 나오는 6단계 파이프라인을 만든다

회의 녹음을 회의록으로 바꾸는 6단계 파이프라인

Learning Objectives

녹음 → 전사 → 정제 → 회의록 → 템플릿 → 완성으로 이어지는 6단계 구조와 각 단계의 주체(코드 / LLM)를 구분한다.
전사 품질을 좌우하는 녹음 조건과, 화자분리가 전사보다 어려운 이유를 안다.
회의록을 문서가 아니라 JSON 데이터로 먼저 만드는 이유와 그 이점을 설명한다.
데이터(JSON)와 디자인(HTML 템플릿)을 분리했다가 합쳐 단일 HTML 회의록으로 완성한다.

이해

회의록 자동화가 어려운 이유

학습 안내읽기. 이 장은 "받아쓰기 서비스에 파일을 올리는 법"이 아니라, 회사 안에서 반복 실행할 수 있는 파이프라인을 만드는 법을 다룹니다.

회의 녹음을 텍스트로 바꾸는 기술 자체는 이미 해결된 문제입니다. 그런데도 회의록 자동화가 사내에 자리 잡지 못하는 이유는, 기술 앞뒤에 걸린 세 가지 관문 때문입니다.

관문 1녹음해도 되는가

기술보다 먼저 걸리는 문제입니다. 참석자 동의를 어떻게 받을지, 녹음 파일을 어디에 얼마나 보관할지, 외부 서비스에 올리면 고객사명·단가·인사 정보가 사외로 전송되는데 사내 정책상 가능한지. 이 답이 없으면 나머지는 시작조차 못 합니다.

관문 2이걸 언제 듣고 있나

녹음을 확보해도 다시 듣는 데 회의만큼 시간이 듭니다. 전사문으로 받아도 1시간 회의는 1만 5천 자가 넘어, 읽는 것 역시 만만치 않습니다. 정작 필요한 건 전문(全文)이 아니라 무엇이 정해졌고 누가 무엇을 하는가 몇 줄입니다.

관문 3이걸 어떻게 정리하나

회의록 작성 표준이 사내에 있습니까? 사람마다 양식도 상세도도 달라, 어떤 회의록은 줄거리만 있고 어떤 것은 받아쓰기에 가깝습니다. 기준이 없으면 AI에게 시킬 것도 정할 수 없고, 쌓인 회의록을 비교하거나 이어 볼 수도 없습니다.

단계마다 실패하는 방식이 다르다

어느 단계에서 망가졌는지 구분하지 못하면, 엉뚱한 곳을 고치며 시간을 씁니다.

단계	전형적인 실패	대응
녹음	멀리 앉은 사람 목소리가 안 잡힘, 여러 명이 동시에 말함, 안건 경계가 안 보임	마이크 위치·발언 규칙·안건 전환 선언
전사	화자를 뭉뚱그림(둘을 한 사람으로), 사내 약어 오인식, 숫자·단위 오류	화자분리 도구 선택 + 다음 단계 후보정
회의록	줄거리만 요약하고 결정을 못 집음, 부서별 관점을 뭉갬, 하지 않은 말을 지어냄	출력 구조를 못 박는 프롬프트 + 근거 인용 요구

가장 흔한 오해. "회의록이 부실한 건 STT 정확도 탓"이라고 생각하기 쉽지만, 실제로는 회의록 프롬프트와 출력 구조가 결과의 대부분을 좌우합니다. 전사가 90% 정확해도 프롬프트가 "요약해줘" 한 마디면 쓸 수 없는 회의록이 나옵니다.

이해

폴더가 곧 설계도 — 01에서 06까지

파이프라인을 한 덩어리 스크립트로 만들면, 마지막 단계에서 실패했을 때 처음부터 다시 돌려야 합니다. 전사에 몇 분씩 걸리는 작업에서 이건 치명적입니다. 그래서 각 단계의 산출물을 번호 폴더에 파일로 남깁니다. 폴더 번호가 곧 실행 순서이자 재시작 지점입니다.

파이프라인 폴더 구조

회의록-자동화/
│
├─ 01-input/                    ① 회의 녹음 오디오
├─ 02-STT-processing/           ② 화자분리 STT 코드
├─ 03-transcript/               ③ 화자가 식별된 스크립트
├─ 04-text-to-minutes/          ④ 회의록 프롬프트와 구조 정의
├─ 05-minutes-template/         ⑤ 회의록 뷰어 템플릿과 주입기
└─ 06-result-minutes/           ⑥ 최종 회의록 — JSON과 HTML

01 → 02

녹음 · 전사

코드 — 음성을 텍스트와 화자로

03 → 04

정제 · 회의록

LLM — 판단이 필요한 두 단계

05 → 06

템플릿 · 완성

코드 — 데이터를 디자인에 주입

읽는 순서. 폴더 번호를 따라가면 파이프라인이 무슨 일을 하는지 코드를 안 봐도 보입니다. 폴더 이름이 문서 역할을 하도록 짓는 것이 바이브코딩에서 특히 중요합니다 — AI에게 "이 폴더 구조를 지켜서 작업해줘"라고만 하면 되기 때문입니다.

폴더 이름만 정해 주고 안에 무엇을 넣을지는 AI가 제안하게 합니다. 스크립트 파일명까지 지정하면 지시가 길어지기만 하고, 어차피 만드는 사람마다 달라집니다. 고정할 것은 폴더 여섯 개와 각 폴더의 역할입니다.

① 파이프라인 구성 프롬프트

회의 녹음을 회의록으로 바꾸는 자동화 파이프라인을 이 폴더에 만들어 줘. # 폴더 구조 — 이대로 만들 것 01-input/ 회의 녹음 오디오 02-STT-processing/ 화자분리 STT 코드 03-transcript/ 화자가 식별된 스크립트 04-text-to-minutes/ 회의록 작성 프롬프트와 회의록 구조 정의 05-minutes-template/ 회의록 뷰어 템플릿과 주입기 06-result-minutes/ 최종 회의록 (JSON + HTML) # 규칙 - 단계마다 산출물을 파일로 남기고, 다음 단계는 그 파일을 읽어서 시작할 것. → 특정 단계만 다시 실행할 수 있어야 한다. - 각 폴더에 어떤 스크립트가 필요한지 네가 정해서 제안해 줘. 파일 이름도 네가 정하고, 정한 이름과 역할을 README에 표로 남길 것. - 경로·타임코드·텍스트 정규화 같은 공용 함수는 한 곳에 모을 것. - 회의록 프롬프트는 코드에 박지 말고 04 폴더의 파일로 분리할 것. - 04는 자동 실행하지 말 것 — 프롬프트를 눈으로 보고 고쳐 가며 쓸 거야. # 지금 만들 것 폴더 구조와 각 스크립트의 뼈대(무엇을 읽고 무엇을 쓰는지 주석으로 명시). 실제 처리 로직은 아직 넣지 마 — 구조와 인터페이스만 잡아 줘.

04를 일부러 자동화하지 않는다. LLM 호출을 스크립트 안에 묶어 버리면 프롬프트가 코드 속에 숨습니다. 회의록의 품질은 그 프롬프트가 결정하는데, 숨어 있으면 고칠 생각을 하지 않게 됩니다. 04에는 프롬프트와 회의록 구조 정의만 두고, 실행은 대화로 합니다.

실습

1단계 · 녹음 — 여기서 절반이 정해진다

학습 안내직접 실행. 회의를 녹음해 01-input/에 넣는 것이 시작입니다. 전사기가 아무리 좋아도 안 들리는 목소리를 살려내지는 못합니다.

직접 녹음한 회의가 아직 없다면 아래 두 파일로 먼저 돌려 보십시오. 이 교재의 6단계를 끝까지 통과한 녹음이며, 뒤에 나오는 산출물이 모두 이 두 회의에서 나온 것입니다. 받아서 01-input/에 넣으면 2단계로 넘어갈 수 있습니다.

실습 녹음 ① — 부품 불량 대응 회의 (8분 30초) 실습 녹음 ② — 신사업 기획 회의 (8분 20초)

녹음 전에 반드시. 회의를 녹음하려면 참석자에게 고지하고 동의를 받는 것이 먼저입니다. 회의 시작 시 "회의록 작성을 위해 녹음합니다"를 밝히고, 녹음 파일의 보관 기간과 접근 범위도 정해 두십시오. 외부 서비스로 전사할 경우 파일이 사외로 전송된다는 점을 참석자가 알아야 합니다.

회의실에서 지킬 세 가지

장비를 바꾸는 것보다 진행 방식을 조금 바꾸는 것이 효과가 큽니다. 아래 셋은 비용이 들지 않으면서 결과를 가장 크게 바꿉니다.

하나말이 겹치지 않게

한 번에 한 사람만 말합니다. 끼어들 때는 짧게 끊고 상대가 마친 뒤 다시 말합니다. 겹친 구간은 화자분리가 뒤섞이고 내용도 함께 유실됩니다 — 사람 귀에는 들려도 기계는 두 사람을 한 덩어리로 봅니다.

둘안건이 바뀔 때 소리 내어

"다음 주제는 ○○○입니다"라고 말하고 넘어갑니다. 회의록 쓸 사람이 뒤에서 듣고 있다고 생각하면 나오는 습관입니다. 이 한마디가 긴 회의를 안건 단위로 자르는 기준이 되어, 회의록의 아젠다 구분이 정확해집니다.

셋이름과 소속을 한 바퀴

첫머리에 참석자가 각자 이름과 소속을 한 번씩 말하고 시작합니다. 전사보다 화자분리가 훨씬 어렵기 때문입니다 — 목소리만으로는 이름을 알 수 없어 기계는 SPEAKER_00 같은 번호만 내놓습니다. 이 한 바퀴가 그 번호를 실명에 붙일 유일한 단서입니다.

'이름 한 바퀴'가 왜 그렇게 중요한가. 회의록에서 "누가 무엇을 언제까지"의 '누가'가 비면 액션 아이템이 실행되지 않습니다. 그런데 화자 이름은 음성 어디에도 적혀 있지 않습니다. 회의 시작 30초를 쓰면 이후 매핑 작업이 추측에서 확인으로 바뀝니다.

실습

2단계 · 화자분리 STT

음원을 텍스트로 바꾸는 단계입니다. 회의록에서는 누가 말했는지가 내용만큼 중요하므로, 단순 받아쓰기가 아니라 화자분리(diarization)가 함께 되어야 합니다. 길은 두 갈래입니다.

선택 1회의록 SaaS 서비스

클로바노트 같은 서비스에 파일을 올리면 전사와 화자분리가 모두 높은 수준으로 나옵니다. 설치도 코드도 필요 없습니다. 다만 무료 사용량에 한도가 있고, 파일이 외부로 전송되며, 파이프라인 중간에 끼워 넣기가 어렵습니다.

선택 2직접 코딩

Whisper·WhisperX·pyannote를 조합해 내 PC에서 돌립니다. 파일이 사내를 벗어나지 않고, 분량 제한도 과금도 없으며, 파이프라인에 그대로 붙습니다. 대신 첫 설치가 까다롭습니다.

	SaaS 서비스	직접 코딩
품질	전사·화자분리 모두 바로 쓸 수준	모델·설정에 따라 다름. 조율하면 대등
보안	파일이 외부 서버로 전송됨	사내 PC 밖으로 나가지 않음
비용	무료 사용량 한도, 초과 시 유료	전기·GPU 시간. 분량 제한 없음
자동화	사람이 올리고 받아와야 함	파이프라인에 그대로 연결
고르는 기준	가끔 쓰는 회의 · 빠르게 시작	기밀 회의 · 반복 처리 · 자동화가 목적

직접 만들 때 — 세 모델이 각자 다른 일을 한다

직접 코딩을 고르면 도구가 세 개 필요합니다. 하나가 전부를 하지 못하기 때문입니다.

Whisper

음성 → 텍스트. 문장 단위 시각이 함께 나오지만 오차가 커서 화자 매칭에는 쓰기 어렵다

WhisperX

문장 → 단어 단위 시각으로 정밀 정렬. 화자 구간과 맞추려면 이 정밀도가 필요하다

pyannote

"언제 누가 말했는가"만 낸다. 내용은 모른다 — 시간축 위의 화자 구간만 계산한다

합치면

단어마다 시각이 있고, 시각마다 화자가 있으니 → 단어마다 화자가 붙는다

② 전사 프롬프트

02-STT-processing 에 화자분리 전사 스크립트를 만들어 줘. 01-input 의 회의 녹음을 전사해서 03-transcript 에 저장한다. # 요구사항 - 출력은 여러 형태로: JSON(구간별 화자·시작·종료·텍스트·단어), SRT/VTT(자막), 읽기용 마크다운(화자 라벨 + 발언). JSON을 정본으로 두고 나머지를 파생시킬 것. - 화자는 SPEAKER_00 처럼 익명 번호로 두고, 실명 매핑은 다음 단계에서 한다. - 긴 파일은 구간을 나눠 처리하고, 합칠 때 타임코드를 원본 기준으로 되돌릴 것. - 구간 경계에서 같은 화자가 이어지면 하나로 병합할 것. - 진행 상황(몇 번째 구간, 예상 남은 시간)을 콘솔에 표시. - 이미 전사한 파일은 건너뛸 것 — 실수로 다시 실행해도 시간을 버리지 않게. # 환경 - 사내망 밖으로 파일이 나가지 않는 로컬 방식으로. - GPU가 있으면 쓰고 없으면 CPU로 떨어지게. 설치가 까다로우니 requirements.txt에 버전을 고정하고, 막히면 원인과 해결책을 알려 줘.

위 프롬프트로 실제 만들어진 스크립트입니다. 먼저 직접 만들어 보고, 막히거나 결과를 비교하고 싶을 때 열어 보십시오. Whisper·WhisperX·pyannote를 묶어 JSON·SRT·VTT·마크다운을 한 번에 내놓고, 이미 전사한 파일은 건너뜁니다.

화자분리 전사 스크립트 — diarize_transcribe.py 버전 고정 목록 — requirements.txt

설치가 첫 관문입니다. Whisper·WhisperX·pyannote는 서로 요구하는 버전이 달라 아무 생각 없이 설치하면 GPU를 잃거나 서로 깨집니다. 오류가 나면 메시지 전문을 그대로 붙여넣어 해결을 맡기십시오. 이 단계에서 시간을 좀 쓰더라도, 한 번 맞춰 두면 이후로는 계속 돌아갑니다.

전사에 걸리는 시간을 미리 재 두십시오. 장비에 따라 회의 길이의 몇 배가 걸리기도 합니다. 처음 한 번은 짧은 회의로 시간을 재고, 그 배율로 긴 회의를 가늠하십시오. 오래 걸리는 작업일수록 "실패한 단계만 다시 돌리는" 설계의 값어치가 커집니다.

실습

3단계 · 스크립트 다듬기 — 코드가 만든 것을 LLM이 손본다

2단계 산출물은 기계가 들리는 대로 적은 원본입니다. 그대로는 회의록 재료로 부족합니다. 여기서부터 LLM이 일합니다 — 문맥을 읽어야 고칠 수 있는 것들이기 때문입니다. 손볼 것은 세 가지입니다.

화자 매핑

SPEAKER_00 → 김 부장 (생산팀). 회의 앞부분의 자기소개, 서로를 부르는 호칭("김 부장님 의견은"), 발언 맥락을 단서로 확정한다. 이것이 되어야 액션 아이템에 담당자를 적을 수 있다

용어 교정

사내 약어·장비명·제품 코드의 오인식을 바로잡는다. 실제로 납품 지연이 납품 지원으로, 불량률이 분량률로 적히는 일이 흔하다 — 회의 전체 주제를 알아야 고칠 수 있다

숫자 확인

금액·수량·비율·일자는 오인식이 잦고 영향이 크다. 확정하지 말고 목록으로 뽑아 사람이 눈으로 확인하게 한다. "20억"이 "2억"이 되면 회의록 전체가 틀어진다

③ 정규화 프롬프트

03-transcript 의 전사문에 화자 실명과 사내 용어를 반영해 줘. # 화자 실명 매핑 - 회의 앞부분의 자기소개, 상대를 부르는 호칭("김 부장님"), 발언 맥락을 단서로 SPEAKER_00 → 실명(부서) 매핑을 추정해 줘. - 추정은 추정이라고 표시하고 근거를 함께 적어 줘. 사람이 확정한다. - 확정된 매핑은 별도 파일로 저장해 다음 회의에도 쓸 것. - 화자별 발언 횟수·발언량·발언 시간 비중을 함께 계산해 줘. # 용어 교정 - 사내 약어·장비명·제품 코드의 오인식을 문맥으로 찾아 고쳐 줘. - 고친 내역을 원문 / 교정문 / 근거 표로 남겨 줘. 임의 수정은 금지. - 사전에 없지만 반복해서 이상하게 나오는 표현을 사전 추가 후보로 제안해 줘. 확정된 것은 용어 사전 파일에 쌓는다. # 숫자 점검 - 금액·수량·비율·일자가 나온 발언을 목록으로 뽑아 줘. 고치지 말고, 회의록에 옮기기 전에 사람이 확인할 목록으로만.

전사 정확도를 확인하는 법

"잘 되는 것 같다"로는 개선할 수 없습니다. 회의 앞부분 5분 정도만 손으로 받아 적어 기준으로 삼으면, 그때부터 정확도를 수치로 확인할 수 있습니다. 다음 장(808)에서 PDF 파서에 쓰는 방식과 같습니다.

④ 정확도 점검 프롬프트

전사 정확도를 점수로 확인하는 스크립트를 만들어 줘. - 내가 회의 앞부분 5분을 손으로 받아 적어 기준 파일로 둘게. 형식은 "화자: 발언" 한 줄씩. 이 파일의 틀을 먼저 제안해 줘. - 같은 구간의 전사 결과와 대조해서: 문자 단위 일치율, 화자가 올바르게 갈렸는지, 가장 많이 틀린 단어 목록을 보여 줘. - 틀린 단어 목록은 용어 사전에 추가할 후보로 정리해 줘. 비교 전에 공백·문장부호 차이는 무시하도록 정규화할 것.

사전이 자산이 됩니다. 회의를 처리할 때마다 "자주 틀리는 단어"를 용어 사전 파일에 넣는 것을 몇 번만 반복하면, 우리 회사 용어에 맞춰진 전사기가 됩니다. 이 파일은 다른 부서에서도 그대로 가져다 쓸 수 있습니다. 화자 매핑 파일도 마찬가지로, 같은 사람이 참석하는 정기 회의에서는 계속 재사용됩니다.

실습

4단계 · 회의록 만들기 — 문서가 아니라 데이터로

여기가 이 파이프라인의 핵심입니다. 그런데 결과물을 완성된 문서가 아니라 JSON 데이터로 받습니다. 낯선 선택이니 이유부터 봅니다.

JSON이 무엇인가

JSON은 이름표를 붙여 값을 적어 두는 형식입니다. 표가 행과 열로 정리하듯, JSON은 항목 이름과 값의 짝으로 정리합니다. 사람도 읽을 수 있고 프로그램도 바로 다룰 수 있습니다.

JSON의 생김새 — 액션 아이템 하나

{
  "no": 1,
  "task": "부품업체와 재협상하여 불량 제품 보상 범위를 최대한 확보한다",
  "owner_department": "구매팀",
  "owner": "송 대리",
  "due": "미정",
  "due_note": "회의에서 기한이 지정되지 않음. 손실 규모를 고려할 때 최우선 처리 필요",
  "priority": "상",
  "deliverable": "협상 결과 및 보상 확보 금액 보고"
}

왼쪽이 항목 이름, 오른쪽이 값입니다. 같은 내용을 문장으로 쓰면 "구매팀 송 대리가 부품업체와 재협상해 보상 범위를 확보하기로 했으며 기한은 미정이다"가 되겠지만, 그 문장에서 담당 부서만 뽑아내려면 사람이 읽어야 합니다. JSON은 owner_department를 그냥 꺼내면 됩니다.

Data First, Document Later

회의록을 데이터로 먼저 만들면 생기는 것들

문서로 바로 만들면 그 문서 하나로 끝입니다. 데이터로 만들면 같은 내용을 여러 형태로 다시 쓸 수 있습니다 — 웹 회의록, 인쇄용 PDF, 액션 아이템만 모은 관리표, 검색 시스템. 또 빠진 항목을 기계가 잡아냅니다: 담당 부서가 비어 있으면 렌더링 전에 경고가 뜹니다. 문장으로 쓰인 회의록에서는 무엇이 빠졌는지 사람이 읽어야 압니다.

정해진 항목▸LLM이 채움▸기계가 검증▸여러 형태로 출력

무엇을 채우게 할 것인가 — 회의록의 뼈대

항목을 미리 정해 두는 것이 곧 회의록의 품질 기준입니다. AI가 알아서 요약하게 두지 않고, 이 칸들을 채우라고 지시합니다.

항목	담는 것	왜 필요한가
`meta`	제목·참석자·녹음 정보·STT 교정 내역	어떤 오인식을 무엇으로 고쳤는지 남아야 신뢰할 수 있다
`summary`	한 줄 요약 + 핵심 3~5개	회의에 없던 사람이 30초 만에 파악
`agendas`	안건별 부서별 의견 · 결론 · 이견	이 회의록의 핵심 — 아래에서 따로 다룬다
`implications`	시사점 — 요약이 아니라 "그래서 무엇을 의미하는가"	회의록을 판단 자료로 만든다
`action_items`	담당 부서·담당자·기한·우선순위·산출물	하나라도 비면 실행되지 않는다
`open_issues`	결론이 안 난 것과 그 이유	다음 회의 안건이 된다

부서별 의견을 왜 따로 남기나. 원가팀은 비용을, 품질팀은 불량률을, 영업팀은 고객 신뢰를 봅니다. 같은 사안을 서로 다르게 보는 지점이 회의록의 가치입니다. 요약하다 보면 이 차이가 가장 먼저 뭉개집니다. 그래서 부서마다 입장 · 요약 · 근거 · 우려 · 인용을 각각 채우게 만듭니다.

⑤ 회의록 생성 프롬프트

아래 회의 스크립트로 구조화된 회의록을 만들어 줘. # 역할 회의록 작성 전문가. 읽는 사람이 회의에 참석하지 않았어도 무엇이 논의됐고 무엇이 정해졌으며 누가 무엇을 언제까지 하는지 알 수 있게 쓴다. # 작성 원칙 1. 아젠다 중심으로 재구성 — 발언 순서대로 받아쓰지 말고 의제 단위로 재배열. 같은 주제가 회의 중간에 다시 나오면 하나로 통합. 2. 부서별 의견을 각각 남길 것 — 아젠다마다 발언한 모든 부서에 대해 입장(찬성/반대/조건부 찬성/중립/문제제기) · 한 줄 요약 · 근거 · 우려 · 원문 인용. 부서 간 관점 차이를 뭉개지 말 것. 왜 그렇게 말했는지가 남아야 한다. 3. 결론과 이견을 분리 — 실제로 합의된 것만 결론에. 끝까지 안 좁혀진 것은 이견으로, 누가 어떤 입장이었고 왜 안 좁혀졌는지까지. 4. 시사점과 액션아이템 — 시사점은 요약이 아니라 "그래서 무엇을 의미하는가". 액션은 담당 부서 · 담당자 · 기한 · 우선순위 · 산출물을 채운다. # 사실 충실성 - 원문에 없는 금액·날짜·회사명·담당자를 만들지 말 것. - 기한이 회의에서 안 나왔으면 "미정"으로 두고 그 이유를 적을 것. - STT 오인식이 명백하면 문맥으로 교정하되 교정 내역을 따로 기록할 것. - 숫자는 아라비아 숫자로 통일 (이십억 원 → 20억 원). # 출력 JSON 객체 하나만 출력. 코드펜스·설명 문장 없이. 구조는 04-text-to-minutes 의 회의록 구조 정의를 따를 것. # 회의 스크립트 {transcript}

"미정이라고 쓸 것"이 중요합니다. 기한을 비워 두라고 하지 않으면 AI는 그럴듯한 날짜를 채워 넣습니다. 회의록에 없던 기한이 생기면 그것대로 업무가 굴러가 버립니다. 모르는 것은 모른다고 쓰게 하는 지시는 모든 문서 자동화에 공통으로 필요합니다.

LLM이 채워 넣은 결과

실제로 나온 JSON의 일부입니다. 지시한 칸이 그대로 채워졌고, 부서의 관점이 요약 한 줄에 살아 있는 것을 보십시오.

회의록 JSON — 아젠다 1의 부서별 의견 중 하나

{
  "department": "생산팀",
  "speaker": "김 부장",
  "stance": "문제제기",
  "summary": "불량이 사내 문제를 넘어 고객 납품 실패로 번졌고, 보상금과 할인으로
              20억 원 손실이 예상된다.",
  "details": [
    "불량률 증가로 생산 차질이 발생했고, 고객사에 약속한 물량을 납품하지 못하는
     단계까지 진행됐다.",
    "이미 복수의 고객사가 납품 지연 보상금을 요구하고 있다.",
    "고객사 요청으로 지연 물품에 할인을 제안했고, 이 두 가지를 합쳐 약 20억 원의
     손실을 예상한다."
  ],
  "evidence": ["예상 손실 20억 원", "복수 고객사의 납품 지연 보상금 요구"],
  "concerns": ["동일 문제의 재발"],
  "quotes": [{
    "time": "00:00:01",
    "text": "고객사에게 약속한 물량을 납품하지 못하는 상황까지 번지고 있어요.
             벌써 몇몇 고객사에서 납품 지연에 대한 보상금을 요구하고 있고요."
  }]
}

같은 파일 — STT 오인식 교정 기록

"stt_corrections": [
  { "original":  "납품 지원에 대한 보상금",
    "corrected": "납품 지연에 대한 보상금",
    "reason":    "문맥상 납품 지연 보상금. STT 오인식" },
  { "original":  "분량률이 개선되지 않으면",
    "corrected": "불량률이 개선되지 않으면",
    "reason":    "회의 전체 주제가 불량률. STT 오인식" }
]

위 조각들이 들어 있는 회의록 JSON 원본 전체입니다. 두 회의 각각 meta부터 open_issues까지 채워져 있으니, 내 회의록 JSON이 제대로 나왔는지 대조할 기준으로 쓰십시오. 5단계 템플릿에 끌어다 놓으면 바로 화면으로 볼 수도 있습니다.

회의록 JSON ① — 부품 불량 대응 회의 (아젠다 4 · 액션 8) 회의록 JSON ② — 신사업 기획 회의

교정 기록이 남는다는 점을 눈여겨보십시오. AI가 원문을 고쳤다면 무엇을 왜 고쳤는지가 남아야 합니다. 이 기록이 없으면 나중에 "회의에서 정말 그렇게 말했나"를 확인할 방법이 사라집니다. 문서로 바로 만들었다면 이런 항목을 따로 챙길 생각조차 못 했을 것입니다 — 구조를 정해 두면 챙겨야 할 것이 드러납니다.

실습

5단계 · 회의록 템플릿 만들기

4단계에서 나온 JSON은 내용입니다. 이제 그 내용을 담을 그릇을 만듭니다. 여기서 만드는 템플릿은 회의 내용이 비어 있는 빈 뷰어이며, 한 번 만들어 계속 재사용합니다.

Design × Data

디자인은 한 번, 데이터는 회의마다

회의록의 생김새(제목 위치, 표 모양, 색, 인쇄 레이아웃)는 회의가 바뀌어도 그대로입니다. 반면 내용은 회의마다 완전히 다릅니다. 이 둘을 한 파일에 섞어 놓으면 회의마다 디자인을 다시 만드는 꼴이 됩니다. 템플릿 하나 + 회의별 JSON 여러 개가 맞는 구성입니다.

템플릿 안에서 데이터가 놓일 자리

05-minutes-template/ 의 회의록 뷰어 템플릿
  ├─ 스타일 (색·여백·인쇄 레이아웃)         ← 회의가 바뀌어도 그대로
  ├─ 화면 구성 (제목 / 요약 / 아젠다 / 액션) ← 회의가 바뀌어도 그대로
  │
  ├─ 데이터가 들어올 빈 자리 (표식)          ← ★ 여기에 회의 JSON이 들어간다
  │
  └─ 그리기 코드                              ← JSON을 읽어 화면 구성에 값을 채운다
       meta.title      → 문서 제목
       summary         → 상단 요약 상자
       agendas[]       → 아젠다 카드 반복 생성
       action_items[]  → 액션 아이템 표의 행 반복 생성

템플릿에는 데이터가 들어올 빈 자리가 하나 있고, 그리기 코드가 JSON의 항목 이름을 보고 화면 어디에 무엇을 놓을지 결정합니다. agendas가 4개면 아젠다 카드가 4장 생기고, 5개면 5장 생깁니다 — 디자인을 고치지 않아도 됩니다.

⑥ 템플릿 생성 프롬프트

회의록 JSON을 화면에 보여주는 회의록 뷰어 템플릿을 만들어 줘. # 형식 - 단일 HTML 파일 하나. 외부 라이브러리·폰트·이미지를 쓰지 말 것 (사내망·오프라인에서도 열려야 한다). - 파일 안에 데이터가 들어올 빈 자리를 하나 두고, 그 자리에 JSON이 주입되면 화면을 그리게 할 것. 자리는 나중에 코드가 찾아 바꿀 수 있게 표식을 남겨 줘. - 04-text-to-minutes 의 회의록 구조 정의를 그대로 읽어서 그릴 것. # 화면 구성 - 상단: 회의 제목, 녹음 길이, 참석자 뱃지 - 요약 상자: 한 줄 요약 + 핵심 항목들 - 숫자 카드: 아젠다 / 결론 / 액션아이템 / 미결 개수 - 아젠다: 번호·제목·시간대와 함께, 부서별 의견 카드를 나란히. 입장(찬성/반대 등)은 색이 다른 뱃지로, 근거는 작은 태그로, 인용은 인용 블록으로. 결론과 이견은 시각적으로 구분되게. - 시사점: 분류(리스크/기회/비용/일정/조직)와 영향도 뱃지를 붙인 카드 - 액션 아이템: 표. 담당 부서·담당자·기한·우선순위·산출물. 기한이 "미정"이면 눈에 띄게 표시. - 미결 사항: 왜 결론이 안 났는지와 무엇이 필요한지 # 기능 - 라이트/다크 테마 전환 버튼 - A4 인쇄 시 레이아웃이 깨지지 않게 (인쇄용 스타일 별도) - JSON 내려받기 버튼 - JSON 파일을 드래그앤드롭하면 그 회의록으로 바꿔 보여주기 — 템플릿 하나로 다른 회의록도 열어볼 수 있게 회의 내용은 넣지 마. 빈 뷰어만 만들어 줘.

위 프롬프트로 만들어진 빈 뷰어입니다. 회의 내용은 들어 있지 않습니다 — 열어서 4단계의 회의록 JSON을 끌어다 놓으면 그 회의록이 화면에 그려집니다. 라이트/다크 전환과 A4 인쇄 레이아웃이 들어 있습니다.

회의록 뷰어 템플릿 (빈 뷰어) — meeting_minutes_template.html

드래그앤드롭을 꼭 넣으십시오. 템플릿을 고칠 때마다 렌더링을 다시 돌리지 않고, 템플릿을 열어 JSON을 끌어다 놓으면 바로 확인할 수 있습니다. 디자인을 다듬는 동안 이 기능이 작업 속도를 크게 바꿉니다.

실습

6단계 · 하나로 합쳐 완성하고 배포하기

이제 빈 뷰어(5단계)와 회의 내용(4단계)을 합칩니다. 하는 일은 단순합니다 — 템플릿의 빈 자리에 JSON을 밀어 넣고 새 파일로 저장하는 것뿐입니다. 판단이 없는 기계적인 작업이라 코드가 맡습니다.

주입 — 템플릿 + 데이터 = 완성본

05-minutes-template/ 의 빈 뷰어      재사용 — 원본은 건드리지 않는다
              +
06-result-minutes/ 의 회의록 JSON    이 회의의 내용
              ↓
       빈 자리 표식  →  { ...회의 내용... }
              ↓
06-result-minutes/ 의 완성 HTML      더블클릭하면 열린다

⑦ 주입기 프롬프트

회의록 JSON을 템플릿에 주입해 단독 실행 가능한 HTML을 만드는 주입 스크립트를 05-minutes-template 에 만들어 줘. - 05-minutes-template 의 템플릿을 읽어 데이터 자리 표식을 찾아 06-result-minutes 의 JSON으로 바꾼 뒤, 같은 폴더에 완성본 HTML로 저장. - 템플릿 원본은 절대 수정하지 말 것 — 계속 재사용한다. - 주입 전에 필수 항목을 점검해서 비어 있으면 경고를 띄울 것: 제목 · 참석자 · 아젠다 · 각 아젠다의 결론 · 액션아이템의 담당 부서. - 폴더 안의 JSON을 한 번에 전부 처리하는 옵션도. - 처리 결과를 요약해 줘 — 아젠다 몇 개, 액션 몇 개, 파일 크기.

주입할 때 한 가지 함정. 회의 내용에 </script> 같은 문자열이 들어 있으면 HTML이 그 지점에서 잘려 버립니다. 회의에서 코드 이야기가 나오면 실제로 생길 수 있는 일입니다. 주입 전에 그런 문자를 안전하게 바꾸도록 지시하십시오 — AI에게 "JSON 안의 특수 문자가 HTML을 깨뜨리지 않게 처리해줘"라고 하면 됩니다.

완성된 회의록

더블클릭하면 열리는 단일 HTML입니다. 외부 리소스가 없어 인터넷 없이도, 사내망 안에서도 그대로 열립니다.

완성된 회의록 하단 — 시사점 카드들과 액션 아이템 표 — 하단 — 시사점(리스크·비용·일정·조직)과 액션 아이템 표. **기한 "미정"이 그대로 보인다**

주입까지 끝난 최종 산출물입니다. 내려받아 더블클릭하면 그대로 열립니다 — 외부 리소스가 없어 인터넷 없이도 동작합니다. 위 스크린샷의 실물이며, 내가 만든 회의록과 비교할 완성본으로 쓰십시오.

완성 회의록 ① — 부품 불량 대응 회의 완성 회의록 ② — 신사업 기획 회의

배포

파일 하나이므로 배포가 단순합니다. 상황에 맞게 고르면 됩니다.

방법	적합한 경우	주의
메일 첨부	참석자에게 회의 직후 공유	수정본이 여러 개 돌아다니기 쉽다
사내 공유 폴더	회의록을 날짜별로 쌓아 둘 때	원본 위치를 하나로 정해 둘 것
사내 웹서버	링크로 공유, 검색까지 하고 싶을 때	접근 권한 설정 필요
인쇄 / PDF	결재·보관용	템플릿에 인쇄 레이아웃이 있어야 깨지지 않는다

JSON도 함께 남기십시오. 완성본 HTML 옆에 회의록 JSON을 같이 두면, 나중에 템플릿을 개선했을 때 과거 회의록을 전부 새 디자인으로 다시 만들 수 있습니다. 데이터와 디자인을 분리해 둔 이점이 여기서 나옵니다.

이 파일을 다시 AI에게 주면 — 회의 내용이 그대로 읽힌다

완성된 회의록 HTML을 다시 LLM에 업로드하면, AI가 회의 내용을 정확히 파악합니다. "회의록을 첨부했으니 읽어줘"가 잘 되는 이유가 있습니다.

Why It Reads So Well

파일 안에 구조화된 데이터가 통째로 들어 있기 때문

이 HTML은 화면에 보이는 글자만 담고 있는 것이 아닙니다. 주입 과정에서 4단계의 JSON이 그대로 파일 안에 들어갔습니다. AI가 이 파일을 읽으면 "생산팀 김 부장의 입장이 문제제기이고, 근거가 세 가지이며, 액션 아이템 1번의 담당은 구매팀 송 대리, 기한은 미정"이라는 것을 추측이 아니라 이름표를 보고 알아냅니다. 사람이 쓴 줄글 회의록이었다면 문장을 해석해 뽑아내야 했을 정보입니다.

항목 이름이 있다

action_items · owner_department · due — AI가 무엇이 무엇인지 해석하지 않고 안다. 오독의 여지가 줄어든다

관계가 보존된다

어느 의견이 어느 아젠다에 속하고, 어느 액션이 어느 아젠다에서 나왔는지가 구조로 남아 있다. 줄글에서는 사라지는 정보다

빠진 것도 드러난다

기한이 "미정"이라고 명시되어 있다. AI가 "기한 미정인 액션만 뽑아줘"에 정확히 답할 수 있다

근거가 붙어 있다

각 의견에 원문 인용과 발언 시각이 함께 있어, AI의 답변을 녹음 원본까지 되짚어 확인할 수 있다

이렇게 활용하십시오. 회의록 HTML 여러 개를 한꺼번에 올리고 "이번 분기 회의들에서 기한이 미정인 액션 아이템만 모아 담당 부서별로 정리해줘", "지난 회의의 미결 이슈가 이번 회의에서 결론이 났는지 확인해줘"라고 물어보십시오. 회의록이 낱장 기록에서 의사결정 이력으로 바뀝니다.

완료 기준

회의 녹음 파일 하나를 넣어 6단계를 끝까지 돌려 봤다
01-input ~ 06-result-minutes 각 폴더에 단계별 산출물이 남아 있다
화자 번호에 실명을 붙이고, 그 단계만 다시 실행해 봤다
회의록 JSON을 열어 항목 이름과 값의 구조를 확인했다
회의록 프롬프트만 고쳐 4단계를 다시 돌려, 결과가 바뀌는 것을 확인했다
액션 아이템에 담당·할 일·기한이 모두 있고, 회의에 없던 기한은 "미정"으로 남아 있다
완성된 HTML을 LLM에 다시 올려 회의 내용을 물어봤다

이해

정리 · 6단계에서 AI는 어디서 일했나

여섯 단계를 다 만들어 봤으니 돌아봅니다. "AI로 회의록을 자동화했다"고 말할 때, AI가 실제로 판단한 지점이 어디였는지 짚어 두면 다음 자동화를 설계할 때 그대로 쓰입니다.

단계	주체	성격
01 녹음	사람	회의 진행 방식의 문제. 도구로 해결되지 않는다
02 전사	코드	AI 모델을 쓰지만 프롬프트가 없다. 같은 입력이면 같은 출력 — 결정론적 변환
03 정제	LLM	무엇이 오인식인지, 누가 어느 화자인지 문맥으로 판단
04 회의록	LLM	아젠다 재구성, 부서별 관점 보존, 결론과 이견 분리 — 판단의 핵심
05 템플릿	사람 · 코드	한 번 만들어 계속 재사용. 회의가 바뀌어도 그대로
06 완성	코드	정해진 자리에 값을 넣는 문자열 치환. 판단 없음

Where the AI Actually Works

6단계 중 LLM이 판단하는 곳은 두 곳뿐이다

녹음·전사·렌더링은 프롬프트가 끼어들 자리가 없습니다. 반면 스크립트 정제(3단계)와 회의록 작성(4단계)은 문맥을 읽고 판단해야 하는 일입니다. "AI가 회의록을 써준다"의 실체는 정제된 텍스트를 정해진 구조에 채우는 것 하나이며, 나머지는 전부 배관입니다. 그래서 이 파이프라인의 승부처는 코드가 아니라 프롬프트와 데이터 구조에 있습니다 — 04 폴더에 프롬프트와 스키마만 두고 실행을 대화로 남긴 이유입니다.

다른 업무에도 그대로 적용됩니다. 어떤 업무를 자동화하든 판단이 필요한 지점과 기계적인 지점을 먼저 갈라내십시오. 기계적인 곳은 코드로 고정해 두고, 판단이 필요한 곳에만 프롬프트를 붙입니다. 판단이 필요한 곳까지 코드로 굳히면 상황이 바뀌었을 때 대응하지 못하고, 기계적인 곳까지 매번 AI에게 맡기면 결과가 흔들립니다. 806(품질분석 보고서)에서 집계는 코드로, 결론은 매번 LLM으로 나눈 것과 같은 판단입니다.

사례

사례 · 부품 불량 대응 회의

6개 부서가 손실 20억 원 규모의 불량 이슈를 두고 대립하는 8분 29초 회의 녹음을 파이프라인에 통과시킨 결과입니다. 제조 현장에서 흔한 구도입니다.

참석자

08:29

녹음 길이

2.29%

화자분리 오류율

6/6

화자 이름 매핑

단계	산출물	결과
01 녹음	`.wav`	8분 29초 · 6인 회의
02 전사	`.json` · `.md` · 자막	화자분리 오류율 2.29%, 처리 시간은 회의 길이의 약 1.8배
03 정제	실명·용어 반영 스크립트	화자 6명 전원 실명 확정, STT 오인식 4건 교정
04 회의록	회의록 JSON	아젠다 4 · 액션 8 · 시사점 5 · 미결 3
05 템플릿	뷰어 템플릿	한 번 만들어 두 회의에 재사용
06 완성	`.html` 약 50KB	단일 파일 · 오프라인 열람 · 인쇄 지원

교정된 오인식 — 문맥을 알아야 고칠 수 있는 것들

전사 원문	교정	근거
납품 지원에 대한 보상금	납품 지연에 대한 보상금	문맥상 납품 지연 보상금
분량률이 개선되지 않으면	불량률이 개선되지 않으면	회의 전체 주제가 불량률
향후 계약건들의 미칠 영향	향후 계약 건들에 미칠 영향	조사 오인식
이미 일부 고객은, 이부 고객은	이미 일부 고객은	중복 인식

전부 소리는 비슷하지만 뜻이 다른 경우입니다. 사전으로는 잡히지 않고, 회의가 무엇에 관한 것인지 알아야 고칠 수 있습니다 — 3단계를 LLM에 맡기는 이유입니다.

회의록이 남긴 것

06-result-minutes / 자동차 스티어링 부품 불량 관련 이슈 대응 회의.html

결론 (아젠다 4건)

기존 부품업체와의 협상을 우선하고, 업체 교체는 협상 지렛대로만 둔다
부품 입고 검수 절차를 강화한다
사내 재고 기준 상향을 검토한다 — 단, 품질팀은 "검수 강화가 선행되지 않으면 무의미"라는 단서를 달았다
고객사 소통을 지속하며 지연 보상금 협상 여지를 확인한다

끝까지 안 좁혀진 것 (미결 3건)

검수 강화 ↔ 생산 속도 — 두 대책을 동시에 지시하면 현장에서는 납품 일정 압박에 밀려 검수가 형식화될 가능성이 높다. 무엇을 우선할지 명시되지 않았다
계약 이탈 손실 규모 — 20억 원은 계산됐지만 신뢰 상실로 인한 향후 계약 손실은 추정조차 없다
통합 관리 주체 — 협상·검수·공정 개선·고객 대응이 각 부서에 병렬로 배분됐으나 중간 점검 주기와 취합 담당이 정해지지 않았다

액션 아이템 8건 — 기한은 전부 "미정"

회의에서 아무도 날짜를 말하지 않았기 때문입니다. AI가 지어내지 않고 그대로 비워 두었고, 이 표를 보는 순간 회의 운영의 문제가 드러납니다 — 다음 회의에서 기한부터 정해야 한다는 것을.

미결과 시사점을 눈여겨보십시오. 회의록의 가치는 정해진 것보다 정해지지 않은 것을 정확히 남기는 데 있는 경우가 많습니다. "통합 관리 주체가 없다"는 것은 회의에서 아무도 말하지 않았지만, 부서별 배분 내역을 보면 드러나는 판단입니다. 이런 항목이 나오도록 프롬프트에 implications를 넣어 둔 것입니다.

실습

부록 · 더 해보기

MISSION 1한 줄로 도는 파이프라인

"녹음 파일을 주면 6단계를 순서대로 실행하는 실행기를 만들어줘"라고 지시하십시오. 이미 만들어진 산출물은 건너뛰고, --from 3 --to 4처럼 단계를 골라 실행할 수 있게 하는 것이 핵심입니다 — 회의록만 다시 만드는 것이 가장 흔한 경우입니다.

MISSION 2우리 회의 용어 사전 만들기

사내 약어·장비명·제품 코드를 용어 사전 파일에 모으십시오. 회의를 처리할 때마다 가장 많이 틀린 단어를 사전에 추가하는 것을 몇 번 반복하면 정확도가 눈에 띄게 올라갑니다. 부서별로 사전을 나눠 두면 회의 성격에 맞게 골라 쓸 수 있습니다.

MISSION 3액션 아이템 관리표

"06-result-minutes 의 회의록 JSON들에서 액션 아이템만 모아 한 장의 관리표로 만들어줘 — 회의일·담당·할 일·기한·상태"라고 지시하십시오. 데이터로 만들어 둔 덕분에 따로 옮겨 적을 필요가 없습니다.

MISSION 4회의록 배포 자동화

완성된 회의록 HTML을 참석자에게 메일로 보내는 단계를 붙여 보십시오. 505·506(Word·이메일 자동화)에서 다룬 방식을 7단계로 추가하면 됩니다. 발송 전 사람이 승인하는 단계를 넣는 것을 권합니다.