meeting-minutes

name	meeting-minutes
version	1.3.0
category	productivity
description	회의·통화·논의 녹음의 전사본을 회의록으로 정리하고 업무 관점에서 분석한다 — 핵심 논의, 결정사항, 액션아이템(담당·기한), 리스크·후속을 드러내고 위키에 남겨 연속성을 만든다. Use when: 회의 녹음 분석, '이 녹음 회의록 만들어줘', 화자분리 전사본이 도착했을 때, 통화/미팅 정리. NOT for: 짧은 음성 메모 받아쓰기, 단순 전사만 필요할 때, 일반 대화.
metadata	{"deneb":{"emoji":"📝","tags":["meeting","minutes","회의록","회의","녹음","전사","분석","업무"],"triggers":["회의록","회의 녹음","녹취","전사본","회의 정리"],"related_skills":["email-analysis"]}}
user-invocable	true

회의록 작성 · 분석

화자분리·타임스탬프가 붙은 녹음 전사본을 업무 관점의 회의록으로 정리한다. 이건 절차서가 아니라 작성 자세다. 받아쓴 말을 정해진 칸에 옮겨 담는 게 아니라, 그 회의가 무엇을 결정했고 무엇이 남았는지를 추론으로 풀어낸다.

When to Use

• 회의·통화·미팅 녹음의 전사본이 도착해 정리가 필요할 때
• 사용자가 녹음을 공유하며 "회의록 만들어줘"라고 할 때
• 진행 중인 프로젝트·거래 관련 논의를 기록으로 남길 때

쓰지 않는 경우: 한두 마디 음성 메모, 받아쓰기 자체만 필요한 경우, 일반 대화. 회의가 아니라 짧은 메모면 격식 차리지 말고 핵심만 한두 줄로 정리한다.

작성 자세

쓰기 전에 먼저 훑어 점수를 매겨라. 전사본을 처음부터 끝까지 한 번 훑어 중요한 사실 — 결정·약속·숫자·이견·미결 — 을 빠짐없이 목록으로 건지고, 각각이 얼마나 중요한지 가늠한 뒤에 글을 시작하라. 곧장 요약부터 쓰면(특히 긴 녹음에서) 중요한 발언이 통째로 누락된다. 그리고 이 회의록을 누가 읽고(임원), 무엇을 위해(결정·후속조치) 읽는지를 먼저 정하면 무엇을 앞세울지가 분명해진다.

회의는 고립된 한 시간이 아니다. 이 회의가 무엇을 정하려고 모였는지를 먼저 잡아라 — 직전에 어떤 합의가 있었고, 무엇이 걸려 있었고, 누가 무엇을 들고 왔나. 관련 프로젝트·거래의 과거를 끌어오면 이번 논의의 의미가 분명해진다.

그다음 결정과 행동을 본다. 회의록의 값어치는 매끄러운 요약이 아니라 "그래서 무엇이 정해졌고, 누가 언제까지 무엇을 하나"에 있다. 합의된 것과 미뤄진 것을 가르고, 책임이 붙지 않은 결정은 그렇다고 표시한다.

액션아이템은 신성하다. 발화에서 약속("우리가 X를 Y까지 한다")을 빠짐없이 건져 담당과 기한을 붙인다. 담당이 모호하면 추측하지 말고 "확인 필요"로 둔다. 기한이 있으면 회의록 위키 페이지의 due(YYYY-MM-DD)에 가장 임박한 것을 넣어 모닝레터의 "임박 마감"이 자동으로 챙기게 한다.

받아쓴 사실에 충실하라. 화자 라벨(화자1·화자2 또는 감지된 이름)과 타임스탬프는 전사된 그대로 쓰고, 없는 신원이나 발언을 지어내지 마라. 다툼의 소지가 있는 결정은 근거 발췌를 [mm:ss 화자N] …로 인용해 둔다. 모르는 것은 모른다고 둔다.

무엇을 앞세우고 어떻게 묶을지는 그 회의가 정한다. 15분 스탠드업과 90분 프로젝트 리뷰는 같은 틀일 수 없다. 고정된 섹션에 끼워 맞추지 말고, 그 회의에서 중요한 것이 먼저 오게 하라. 짧으면 짧게, 복잡하면 깊게 — 분량도 사안이 정한다.

긴 녹음(예: 60분+)은 통째로 옮기지 말고 큐레이션한다. 전체 요지와 챕터(시간대별 주제)를 먼저 주고, 특정 구간을 더 펼치고 싶은지 물어라. (요약은 항상 이 자세로.)

전달 직전, 처음 훑어 추린 핵심 사실이 회의록에 다 들어갔는지 한 번 대조하라 — 특히 약속·기한·이견·미결. 매끄러운 요약일수록 결정적 발언 하나가 빠지기 쉽다. 빠진 게 있으면 채우고 내보낸다.

연속성 — 회의를 시리즈로 잇기

한 번 쓰고 마는 회의록은 절반이다. 다음 세 가지로 회의를 사람·시간·거래에 엮어 연속성을 만든다.

화자 신원 매핑 (화자N → 실명)

ASR은 화자1·화자2처럼 익명 라벨만 준다. 위키 인물·핫워드(거래처·연락처)와 발화 단서(서로 부르는 호칭, 직책, 안건 담당)로 누가 누구인지 추론하라.

• 근거가 분명하면 라벨을 실명으로 바꿔 쓴다(예: 화자2 → 김민준 부장).
• 애매하면 지어내지 말고 잠정 표기 화자2(=김부장?)로 두고, 응답 끝에서 한 번만 확인을 청한다 — yes/no가 아니라 정정까지 받게: "화자2가 김민준 부장 맞나요? 아니면 누구인지 알려주세요. 확인해주시면 다음 회의부터 자동 적용합니다."
• 사용자가 같은 세션에서 확인해주면, 그 매핑을 회의 시리즈/프로젝트 위키 페이지의 참석자 매핑 섹션에 라벨 → 인물(위키 경로)로 저장한다. 다음 회의는 그 매핑을 먼저 읽어 같은 사람에게 같은 이름을 붙인다.
• 매핑은 고정이 아니라 언제든 정정 가능한 기록이다. 사용자가 "화자2는 박과장이야", "지난 매핑 틀렸어 — 김부장이 아니라 김차장" 처럼 바로잡으면(그 자리에서든 나중 회의 에서든), 그 즉시 위키의 참석자 매핑을 덮어쓰고(이전 값은 버린다), 지금 다루는 회의록의 라벨도 함께 바로잡는다. 정정은 추가 확인 없이 사용자 말을 따른다.
• 잘못 합쳐졌거나(두 사람을 한 라벨로) 잘못 갈렸으면, 사용자 지시대로 매핑을 쪼개거나 합친다. 사용자가 "그 사람 빼"라고 하면 해당 항목을 지운다.
• 단, 화자 인덱스는 녹음마다 바뀐다 — 인덱스를 고정키로 믿지 말고, 매번 목소리·역할· 발화 내용으로 사람을 다시 식별하라. 저장된 매핑은 힌트지 절대 규칙이 아니다.

지난 회의 대비 (시리즈 타임라인)

회의록을 쓰기 전에, 같은 프로젝트·토픽의 직전 회의록을 위키에서 찾아 읽어라 (같은 related 프로젝트, 같은 토픽, 제목 패턴으로 검색).

• 있으면 회의록을 "지난 회의 대비 진행"으로 연다 — 지난번 결정·액션아이템이 이번에 어떻게 됐나(완료/진행/막힘/뒤집힘), 새로 생긴 것, 여전히 열린 것.
• 지난 액션아이템과 이번 발화를 대조해 상태를 갱신한다. 닫힌 항목은 닫혔다고 표시하고, 미결은 이번 회의록으로 이월한다.
• 회의록끼리 related로 서로 연결해(이전 ↔ 이번) 시리즈가 한 줄로 읽히게 한다. 첫 회의면 그냥 시작점으로 연다.

결정 → 거래·프로젝트 갱신

회의에서 단가·수량·금액·납기·일정 같은 업무 사실이 정해지면, 회의록만 남기지 말고 관련 거래·프로젝트 위키를 그 자리에서 갱신하라(email-analysis의 거래 처리와 동일).

• 관련 거래 페이지가 있으면 핵심 숫자를 변경 전후 병기로 갱신("단가 150원 → 145원, 6/1 회의 결정"), 가장 임박한 결제기한·납기를 due에 반영. 없으면 새로 만든다 (email-analysis의 templates/deal-page.md).
• 프로젝트 페이지에는 이번 회의의 결정·진행을 타임라인 한 줄로 더하고, 회의록을 related로 건다.
• 무엇을 어디에 갱신했는지 회의록과 사용자 요약에 한 줄로 남겨 출처를 추적 가능하게 한다. 근거 없는 숫자는 절대 쓰지 마라.

쓸 수 있는 것

자세를 뒷받침하는 자원이다. 의무 단계가 아니라, 맥락을 채우고 기록을 남기는 데 필요할 때 쓴다.

• 위키 이력 — 전사본에 나온 프로젝트·회사·인물을 wiki에서 찾는다. 과거 진행 상황이 있어야 이번 결정이 무엇을 바꾸는지 보인다. 관련 페이지는 회의록의 related에 실제 경로로 연결한다.
• 회의록 저장 — 정리한 회의록은 wiki의 회의록 카테고리에 남겨 다음에 이어보게 한다. 가장 임박한 액션 기한은 due 필드(YYYY-MM-DD)에 넣는다. 페이지 골격은 templates/minutes-page.md (틀이 아니라 출발점 — 회의가 단순하면 칸을 비우거나 줄여라).
• 거래·일정 연결 — 금액·납기가 걸린 합의는 email-analysis의 거래 페이지를 갱신하거나 새로 만든다. 후속 회의·마감이 정해졌으면 일정으로 남길 수 있게 명시한다.
• 소관 부서 태그 — 프로젝트·거래 페이지를 만들거나 고칠 때, 담당자를 보고 소관을 판별해 tags에 소관:<팀>을 단다 (소관:1팀·2팀·3팀·남도에코·개인). 매핑은 knowledge/org-기획조정실-2026-06.md 참조. ⚠️ frontmatter 커스텀 필드는 위키가 보존하지 않으니 반드시 tag로. 주간업무보고 팀 분류의 근거가 된다.

저장한 뒤에는 사용자 채널로 간결한 회의록 요약(요지 + 결정 + 액션아이템 상위 몇 개)을 돌려주고, 전문은 위키 + 본인 지메일에 보관했다고 한 줄로 알린다(아래). 그 외엔 캐묻지 마라.

전달 — 자동 보관 + 파일·메일

요약은 채팅으로, 전문은 어디서나 다시 찾을 수 있게 보관한다.

• 영속화는 위키 저장이 기본이자 전부다. (구버전의 "본인 지메일 자동 전송" 스텝은 은퇴 — 에이전트 표면에서 Gmail 발신 도구가 제거되어 gmail(action="send") 류 호출은 불가능하다. 메일 읽기는 mail_archive로만 한다.)
• 파일로 받기(다운로드) — "회의록 파일로 줘"/"다운로드"면 전문 마크다운을 파일로 쓰고(write로 회의록-YYYY-MM-DD-주제.md 생성) 그 경로를 send_file에 넘긴다. 네이티브 클라이언트에 다운로드로 도착한다. "보냈습니다"만 답한다.
• 참석자·외부 공유 — 에이전트 표면에는 메일 발신 도구가 없어 직접 발송은 불가하다. 외부 공유 요청이면 전문 파일(send_file) 또는 본문 텍스트를 제공해 사용자가 직접 보내게 하라. 수신자 이메일을 추측해 안내하지 마라(위키 인물 카드에서 확인한 것만).

주의

지금 응답하는 곳이 곧 사용자의 채널이다 — 채널 상태를 추측하지 마라. 내부 토큰(<thinking>, NO_REPLY)이 새지 않게 하고, 긴 회의록 요약은 분량을 조절한다(전문은 위키). "좋은 질문입니다" 같은 빈 서두 없이 회의록부터 시작한다. 화자 신원·결정·숫자를 지어내지 마라 — 근거 없는 것은 비워 둔다.