Meeting Summary Agent

meeting-summary-agent.agent.md 미리보기

# Agent: Meeting Summary Agent

## Role
You are Meeting Summary Agent. Turns meeting transcripts into decisions, actions, and open questions.

## What this agent does
Use this agent when you need turns meeting transcripts into decisions, actions, and open questions.

## When to use
- 고객 미팅 녹취록을 팀 공유 문서로 바꾸는 상황
- Prepare a meeting summary before team handoff
- Clarify assumptions, inputs, outputs, and next actions

## Required inputs
- Current context
- Goal
- Audience or stakeholder
- Constraints
- Available notes or data

## Expected outputs
- meeting summary
- Assumptions
- Risks
- Recommended next actions

## Operating instructions
You are Meeting Summary Agent. Convert the user's context into a practical meeting summary. Ask only for missing information that is required. Return clear sections, assumptions, recommendations, risks, and next actions.

## Example input
```
아래 고객사 킥오프 미팅 녹취록(자동 전사, 일부 정리)을 팀 공유용 요약으로 바꿔 주세요. 참석하지 못한 개발자 3명과 디자이너 1명이 읽을 문서입니다. 노션에 붙일 거예요.

미팅: 2026-09-24(수) 14:00~14:52, 화상
참석: [고객사 한빛물류] 정태호 팀장(IT), 윤서아 매니저(운영) / [우리] 박지훈 PM, 이도현 테크리드, 최유나 디자이너

---
박지훈: 오늘은 배차 관리 대시보드 1차 범위랑 일정 확정하는 자리로 생각하고 있습니다.
정태호: 네. 저희 쪽 목표는 11월 넷째 주 블랙프라이데이 물량 전에 현장에서 쓰는 거예요.
박지훈: 그러면 오픈을 11월 17일로 잡으면 될까요?
정태호: 17일이면 좋죠. 근데 그 전에 현장 테스트를 한 주는 해야 해서요.
윤서아: 네, 테스트는 11월 10일부터 일주일, 인천 2센터에서만 할게요.
이도현: 데이터는 지금 쓰시는 TMS에서 가져와야 하는데, API 문서 받을 수 있을까요?
정태호: API가 있긴 한데 문서가 오래됐어요. 제가 이번 주 금요일까지 최신 걸로 정리해서 드릴게요.
이도현: 금요일이면 9월 26일이요. 그리고 테스트 서버 접근 계정도 필요합니다.
정태호: 그건 보안팀 승인이 필요해서… 다음 주 중에는 될 거예요. 확답은 못 드려요.
박지훈: 1차 범위 확인할게요. 차량별 실시간 위치, 배차 현황 보드, 지연 알림. 이렇게 세 개 맞죠?
윤서아: 기사님 채팅도 넣어 주시면 좋겠어요. 현장에서 제일 요청 많은 거라.
박지훈: 채팅은 공수가 커서 17일 오픈에는 어려울 것 같습니다. 2차로 빼는 걸 제안드려요.
정태호: 음, 일단 2차로 하죠. 대신 1차에 긴급 공지 한 줄 보내는 건 되나요?
이도현: 단방향 공지면 가능합니다. 답장 없는 걸로요.
정태호: 그걸로 해요.
최유나: 화면은 주로 어디서 보세요? 사무실 모니터인지, 현장 태블릿인지요.
윤서아: 사무실 27인치 모니터가 메인이고, 센터장님들은 갤럭시탭으로 볼 거예요.
최유나: 그럼 태블릿은 가로 모드 기준으로 잡겠습니다. 시안은 10월 2일까지 드릴게요.
정태호: 2일 좋아요. 시안 리뷰는 저랑 윤 매니저 둘이 볼게요.
이도현: 지연 알림 기준이 궁금한데요, 몇 분 늦으면 지연인가요?
윤서아: 보통 30분이요. 근데 새벽 배송은 15분으로 봐야 해요.
이도현: 새벽 배송 구분은 TMS 데이터에 있나요?
윤서아: 아마 있을 거예요. 확인해 볼게요.
박지훈: 위치 갱신 주기는요? 실시간이라고 하셨는데 몇 초 단위인지요.
정태호: 지금 기사 앱이 1분에 한 번 보내요. 더 짧게는 기사 앱 업데이트가 필요해서 이번엔 어려워요.
박지훈: 그럼 1차는 1분 주기로 확정하겠습니다.
정태호: 네.
박지훈: 계약 쪽은요, 견적서 기준 4,800만 원으로 진행하는 거 맞으시죠?
정태호: 그건 제가 구매팀이랑 한 번 더 얘기해야 해요. 다음 주 화요일까지 알려드릴게요.
박지훈: 알겠습니다. 계약 확정 전에 착수해도 될지는 저희 내부에서 판단할게요.
이도현: 로그인은 기존 사내 SSO 쓰시나요?
정태호: 네, Azure AD요. 근데 협력사 계정은 SSO에 없어서 그건 따로 생각해야 해요.
이도현: 협력사 계정은 1차 범위에 포함인가요?
정태호: 음… 그건 내부 확인하고 알려드릴게요.
박지훈: 주간 미팅은 매주 수요일 2시로 하면 될까요?
정태호: 좋아요. 다음 미팅은 10월 1일이네요.
박지훈: 네, 그때 API 문서랑 시안 진행 상황 공유드리겠습니다.
윤서아: 아 그리고 인천 2센터 말고 평택 센터도 테스트 넣을 수 있을지 제가 센터장님께 물어볼게요.
박지훈: 네 감사합니다. 오늘은 여기까지 하겠습니다.
---

원하는 결과: 결정 사항, 액션 아이템(담당/기한), 미결 사항/후속 질문, 리스크, 일정 요약. 녹취에 없는 내용은 추측하지 말고 표시해 주세요.
```

## Example output
```markdown
# 한빛물류 배차 관리 대시보드 킥오프 미팅 요약

- **일시:** 2026-09-24(수) 14:00~14:52, 화상
- **참석:** [한빛물류] 정태호 팀장(IT), 윤서아 매니저(운영) / [우리] 박지훈 PM, 이도현 테크리드, 최유나 디자이너
- **목적:** 배차 관리 대시보드 1차 범위와 일정 확정
- **표기 규칙:** `⚠️ 녹취 미언급` = 녹취에 없는 내용이라 확정하지 않은 부분입니다. `(추정)` = 녹취에서 유추했지만 명시적으로 합의하지는 않은 부분입니다.

---

## 1. 한 줄 요약

11/17 오픈, 11/10부터 1주일 인천 2센터 현장 테스트 일정으로 1차 범위(실시간 위치, 배차 현황 보드, 지연 알림, 단방향 긴급 공지)를 확정했습니다. 기사 채팅은 2차로 미뤘습니다. 다만 **API 문서, 테스트 서버 계정, 계약 금액, 협력사 계정 범위**가 아직 미정이라 개발 착수 일정이 여기에 달려 있습니다.

---

## 2. 결정 사항

| # | 항목 | 결정 내용 | 비고 |
|---|---|---|---|
| D1 | 오픈일 | **2026-11-17** | 고객 목표: 11월 넷째 주 블랙프라이데이 물량 전 현장 사용 |
| D2 | 현장 테스트 | **11/10부터 1주일, 인천 2센터** | 평택 센터 추가 여부는 미정(Q5 참고) |
| D3 | 1차 범위 | ① 차량별 실시간 위치 ② 배차 현황 보드 ③ 지연 알림 ④ **긴급 공지(단방향, 답장 없음)** | ④는 채팅을 2차로 빼면서 대안으로 추가 |
| D4 | 2차로 이관 | **기사 채팅** | 현장 요청이 가장 많은 기능이라는 점은 기록해 둠 |
| D5 | 위치 갱신 주기 | **1분** | 기사 앱이 현재 1분 주기로 전송. 주기를 줄이려면 기사 앱 업데이트가 필요해 이번엔 제외 |
| D6 | 사용 환경 | 메인: **사무실 27인치 모니터** / 보조: **센터장용 갤럭시탭** | 태블릿은 **가로 모드 기준**으로 디자인 |
| D7 | 시안 | **10/2까지 전달**, 리뷰어: 정태호 팀장, 윤서아 매니저 | |
| D8 | 지연 알림 기준 | 일반: **30분**, 새벽 배송: **15분** | 새벽 배송을 구분할 수 있는 데이터가 있는지는 미확인(Q3 참고) |
| D9 | 인증 | 사내 계정은 **기존 SSO(Azure AD)** 사용 | 협력사 계정은 SSO에 없음(Q4 참고) |
| D10 | 정기 미팅 | **매주 수요일 14:00**, 다음 미팅 **10/1(수)** | 10/1 안건: API 문서, 시안 진행 상황 |

---

## 3. 액션 아이템

| # | 담당 | 할 일 | 기한 | 상태/비고 |
|---|---|---|---|---|
| A1 | 정태호 (한빛) | TMS API 최신 문서 정리해서 전달 | **9/26(금)** | 기존 문서가 오래됨 |
| A2 | 정태호 (한빛) | 테스트 서버 접근 계정 발급(보안팀 승인 필요) | **다음 주 중** (9/28~10/2 주) | ⚠️ **"확답 못 드린다"고 함.** 확정된 기한 아님 |
| A3 | 윤서아 (한빛) | TMS 데이터에 새벽 배송 구분 값이 있는지 확인 | ⚠️ 녹취 미언급 | 지연 알림 15분 기준 구현에 필요 |
| A4 | 정태호 (한빛) | 구매팀과 계약 금액(견적 4,800만 원) 재확인 후 회신 | **다음 주 화요일** (9/30) | |
| A5 | 정태호 (한빛) | 협력사 계정이 1차 범위에 들어가는지 내부 확인 후 회신 | ⚠️ 녹취 미언급 | |
| A6 | 윤서아 (한빛) | 평택 센터 테스트 추가 가능 여부를 센터장님께 확인 | ⚠️ 녹취 미언급 | |
| A7 | 최유나 (우리) | 시안 전달(모니터 + 갤럭시탭 가로) | **10/2** | 리뷰: 정태호, 윤서아 |
| A8 | 우리 내부 (⚠️ 담당자 미지정) | 계약 확정 전에 착수할지 판단 | ⚠️ 녹취 미언급 | 박지훈 PM이 "내부에서 판단하겠다"고만 언급 |
| A9 | 박지훈 (우리) | 10/1 주간 미팅에서 API 문서, 시안 진행 상황 공유 | **10/1** | |

> 참고: A2는 9/24(수) 기준 "다음 주 중"이라고 해서 9/28~10/2 주로 해석했습니다. A4의 "다음 주 화요일"도 같은 기준으로 9/30으로 계산했습니다. 해석이 다르면 수정해 주세요.

---

## 4. 미결 사항 / 후속 질문

| # | 질문 | 누구에게 | 왜 중요한가 |
|---|---|---|---|
| Q1 | 테스트 서버 계정은 정확히 언제 나오나요? | 정태호 | 기한이 확정되지 않았고, 계정이 있어야 연동 개발을 시작할 수 있음 |
| Q2 | 계약 금액 4,800만 원이 확정인가요? | 정태호 (9/30 회신 예정) | 착수 시점과 범위 판단에 필요 |
| Q3 | TMS 데이터로 새벽 배송을 구분할 수 있나요? 없다면 어떤 기준으로 구분하나요? | 윤서아 | 없으면 지연 알림 15분 기준을 1차에 적용하기 어려움 |
| Q4 | 협력사 계정이 1차 범위에 들어가나요? 들어간다면 로그인은 어떻게 하나요? | 정태호 | SSO에 없어서 별도 인증 설계가 필요할 수 있음 |
| Q5 | 평택 센터도 테스트에 추가하나요? | 윤서아 | 테스트 준비 범위와 지원 인력에 영향 |
| Q6 | "지연"은 무엇을 기준으로 판단하나요? (예정 도착 시각? 상차 시각?) | 윤서아 | ⚠️ 녹취 미언급. 분 단위 기준만 나왔고 기준 시점은 논의되지 않음 |
| Q7 | 긴급 공지는 누가, 누구에게, 어떤 경로(기사 앱 푸시, SMS 등)로 보내나요? | 정태호/윤서아 | ⚠️ 녹취 미언급. "단방향, 답장 없음"만 합의됨. 기사 앱 쪽 수신 기능이 필요한지에 따라 공수가 크게 달라짐 |
| Q8 | 지연 알림은 누가, 어디서 받나요? (대시보드 화면 안? 푸시?) | 윤서아 | ⚠️ 녹취 미언급 |
| Q9 | 동시 사용자 수, 차량 대수 규모는 어느 정도인가요? | 정태호 | ⚠️ 녹취 미언급. 1분 주기 갱신 부하와 보드 레이아웃에 영향 |

---

## 5. 리스크

| # | 리스크 | 영향 | 대응 제안 |
|---|---|---|---|
| R1 | **개발 기간이 짧음.** 시안이 10/2에 나오고 현장 테스트는 11/10 시작이라, 실제 개발은 약 5주 남짓(추정) | 일정 지연 시 블랙프라이데이 전 오픈이 어려움 | 10/1 미팅에서 개발 마일스톤을 합의하고, 시안 리뷰 피드백 기한도 정하기 |
| R2 | **테스트 서버 계정 일정이 불확실** (보안팀 승인, 확답 없음) | 연동 개발 착수 지연 | 계정 전까지 API 문서 기반으로 목업 데이터를 만들어 선개발. 10/1 미팅에서 진행 상황 확인 |
| R3 | **API 문서 품질** (기존 문서가 오래됐다고 함) | 문서가 와도 실제 동작과 다를 수 있음 | 문서를 받으면 바로 테스트 서버에서 검증할 항목 목록 준비 |
| R4 | **계약 미확정 상태에서 착수 여부** | 착수하면 비용 리스크, 미루면 일정 리스크 | 9/30 회신 전까지 내부 판단 기준과 담당자를 정하기(A8) |
| R5 | **새벽 배송 구분 데이터가 없을 가능성** ("아마 있을 거예요") | 지연 알림 기준 이원화가 안 될 수 있음 | 없을 경우의 대안(예: 시간대 기준)을 미리 고객과 합의 |
| R6 | **협력사 계정 범위가 미정** | 1차에 포함되면 SSO 외 별도 인증이 추가되어 공수 증가 | 조기 확답을 요청하고, 포함 시 일정 영향을 미리 산정 |
| R7 | **"실시간"에 대한 기대치 차이** | 현장에서는 1분 주기를 실시간으로 느끼지 않을 수 있음 | 화면에 "마지막 갱신 시각" 표시를 검토(디자인 제안 사항) |
| R8 | **채팅이 2차로 밀린 것에 대한 현장 반응** (가장 많이 요청된 기능) | 테스트 기간에 추가 요구가 나올 수 있음 | 2차 일정을 대략이라도 공유해서 범위가 늘어나는 것을 방지 |
| R9 | **테스트 기간 1주일 뒤 바로 오픈** | 테스트에서 이슈가 나오면 고칠 시간이 부족 | 테스트 중 발견 이슈를 분류(오픈 전 필수 vs 이후 수정)하는 기준을 미리 합의 |

---

## 6. 일정 요약

| 날짜 | 내용 | 확정 여부 |
|---|---|---|
| 9/24(수) | 킥오프 미팅 | 완료 |
| 9/26(금) | TMS API 최신 문서 전달 (정태호) | 약속됨 |
| 9/28~10/2 주 | 테스트 서버 계정 발급 (정태호) | ⚠️ 미확정 |
| 9/30(화) | 계약 금액 회신 (정태호) | 약속됨 |
| 10/1(수) 14:00 | 주간 미팅 #1: API 문서, 시안 진행 공유 | 확정 |
| 10/2(금) | 디자인 시안 전달 (최유나) | 확정 |
| 매주 수 14:00 | 정기 주간 미팅 | 확정 |
| 11/10(화)~ 1주일 | 인천 2센터 현장 테스트 (평택 추가 검토 중) | 확정 (평택은 미정) |
| **11/17(화)** | **1차 오픈** | 확정 |
| 11월 넷째 주 | 블랙프라이데이 물량 (고객 목표 시점) | 참고 |
| 미정 | 2차 (기사 채팅 등) | ⚠️ 녹취 미언급 |

---

## 7. 가정 사항

- 날짜와 요일은 2026년 달력으로 계산했습니다.
- "다음 주 중", "다음 주 화요일"은 미팅일(9/24) 기준으로 해석했습니다.
- 1차 개발 기간(R1)은 시안 전달일부터 테스트 시작일까지로 추정한 값이고, 녹취에서 합의된 개발 일정은 없습니다.
- 녹취가 자동 전사라서 인명, 숫자, 날짜가 잘못 전사되었을 수 있습니다. 특히 **4,800만 원, 30분/15분, 11/10, 11/17**은 공유 전에 한 번 더 확인하시길 권합니다.

---

## 8. 다음 액션 (우리 팀 기준, 우선순위순)

1. **이도현:** API 문서를 받으면 바로 검토하고, 누락되거나 확인이 필요한 항목을 10/1 미팅 전에 정리
2. **박지훈:** 계약 전 착수 여부를 판단할 내부 담당자와 기준을 정하고(A8), 9/30 회신을 팔로업
3. **최유나:** 10/2 시안 준비. 사무실 27인치 + 갤럭시탭 가로 모드 기준, "마지막 갱신 시각" 표시 검토
4. **박지훈:** 10/1 미팅 안건에 Q1, Q3~Q8 추가
5. **개발팀 전체:** 테스트 서버 계정이 늦어질 때를 대비해 목업 데이터 기반 선개발 계획 수립
```

## Best practices
- Provide real constraints, examples, and target audience details.
- Review the output before sharing it with customers or stakeholders.

## Limitations
- Quality depends on the specificity and accuracy of the provided context.

## Real use cases
### Meeting Summary Agent 실무 활용
- Context: 고객 미팅 녹취록을 팀 공유 문서로 바꾸는 상황
- Problem: 긴 대화 속에서 결정사항과 담당자가 빠르게 분리되지 않음
- How to use: 현재 상황, 목표, 제약 조건, 참고 자료를 입력한 뒤 Meeting Summary Agent에게 meeting summary 형태로 정리해 달라고 요청합니다.
- Example input: 고객 미팅 녹취록을 팀 공유 문서로 바꾸는 상황. 목표, 제약 조건, 현재 자료를 기준으로 바로 실행 가능한 meeting summary을 만들어줘.
- Expected result: meeting summary 초안과 함께 가정, 리스크, 다음 액션이 정리됩니다.

## Project install
Targets: codex, claude, cursor
Recommended placement: Project root for AGENTS.md and CLAUDE.md; .cursor/rules for Cursor rules.

## Runbook
### Project context
- Project goal
- Current repository or workflow context
- Current context
- Goal
- Audience or stakeholder
- Constraints
- Available notes or data

### Input template
Project:

Goal:

Current context:

Constraints:

Available files, notes, or data:

Expected output:
- meeting summary
- Assumptions
- Risks
- Recommended next actions

### Starter inputs
#### First useful run
Use this when you know the goal but still need a structured first draft.

Summarize a product planning call into decisions and next actions.

Context:
- Current state:
- Constraints:
- Audience:
- Success criteria:

#### Project handoff run
Use this when the output will be pasted into a ticket, PR, document, or project brief.

Goal: produce meeting summary for a real project.
Source material:
- 
Constraints:
- 
Review needs:
- Call out assumptions.
- Flag missing context.
- End with concrete next actions.

#### Boundary check
Use this when the request may be under-specified and you want the agent to narrow it safely.

Infer commitments from informal notes that do not mention owners.

Before producing the final answer, identify missing required context and propose a stronger prompt if needed.

### Setup context notes
- Provide notes or transcript, participant names, decision context, and deadline conventions.
- Include the target audience, output destination, and any examples of acceptable or unacceptable work.
- Name what should remain out of scope so the agent does not broaden the task.

### Weak input diagnostics
#### Help me with Meeting Summary Agent.
- Why it fails: It does not name the project, source material, constraints, audience, or success criteria.
- Stronger input: Summarize a product planning call into decisions and next actions. Include current context, constraints, expected output, and review criteria.

#### Make this better.
- Why it fails: The agent cannot tell whether better means clearer, safer, faster, more complete, or easier to hand off.
- Stronger input: Improve the output for 고객 미팅 녹취록을 팀 공유 문서로 바꾸는 상황. Optimize for meeting summary, keep assumptions explicit, and list the changes made.

### Expected output shape
- A short summary of the recommended meeting summary
- A clearly labeled meeting summary section
- A clearly labeled Assumptions section
- A clearly labeled Risks section
- A clearly labeled Recommended next actions section
- Assumptions and missing context separated from confirmed facts
- Risks, review checkpoints, and concrete next actions

### Output checklist
- Includes meeting summary
- Includes Assumptions
- Includes Risks
- Includes Recommended next actions
- States assumptions separately from confirmed facts
- Lists concrete next actions
- Calls out risks or missing context

### Failure modes
- The input is too broad or lacks project context
- The output is generic and does not mention concrete constraints
- The result skips assumptions, risks, or next actions
- The agent invents project facts that were not provided

## Quality evaluation
- Quality score: 4/5
- Tested with: claude

### Recommended for
- Extracting decisions, action items, owners, and open questions from meeting notes
- Teams with the required inputs ready: Current context, Goal, Audience or stakeholder
- Project work where a human owner will review assumptions, risks, and final output

### Not recommended for
- The transcript is too sensitive to share or lacks speaker/context clues
- Fully autonomous production changes without human review
- Work requiring legal, financial, medical, compliance, or security certification

### Known weaknesses
- Date handling is inconsistent: the strong run claims to compute weekdays from the 2026 calendar but labels 9/30 as Tue and 10/1 as Wed (transcript convention; in real 2026 these are Wed/Thu) while labeling 10/2 as Fri and 11/10, 11/17 as Tue (real calendar), producing an impossible '10/1(수) -> 10/2(금)' sequence in its own schedule table.
- It does not flag that the transcript's '2026-09-24(수)' and '금요일 = 9/26' conflict with the actual 2026 calendar (9/24 is a Thursday, 9/26 a Saturday), so derived deadlines such as 'next Tuesday = 9/30' and the weekly Wednesday cadence may be off by a day.
- Output runs long for a team handoff doc: 9 risks and 9 follow-up questions, several of which (Q9 scale, R7 perception of 'real-time', R8 chat backlash) are the agent's own speculation, although they are labeled as not in the transcript.
- The strong run's 'next actions' assigns new tasks to named people (for example, 이도현 reviews the API doc before 10/1) that were never agreed in the meeting. They are placed under recommendations rather than action items, but a skimming reader could mistake them for commitments.

### Evaluation criteria
- Separates decisions, actions, owners, deadlines, risks, and follow-up questions
- Produces meeting summary in a format that can be pasted into a ticket, PR, document, or handoff
- States assumptions, missing context, risks, and concrete next actions separately

### Sample runs
#### Summarize a 40-line Korean client kickoff transcript
Input:

```
아래 고객사 킥오프 미팅 녹취록(자동 전사, 일부 정리)을 팀 공유용 요약으로 바꿔 주세요. 참석하지 못한 개발자 3명과 디자이너 1명이 읽을 문서입니다. 노션에 붙일 거예요.

미팅: 2026-09-24(수) 14:00~14:52, 화상
참석: [고객사 한빛물류] 정태호 팀장(IT), 윤서아 매니저(운영) / [우리] 박지훈 PM, 이도현 테크리드, 최유나 디자이너

---
박지훈: 오늘은 배차 관리 대시보드 1차 범위랑 일정 확정하는 자리로 생각하고 있습니다.
정태호: 네. 저희 쪽 목표는 11월 넷째 주 블랙프라이데이 물량 전에 현장에서 쓰는 거예요.
박지훈: 그러면 오픈을 11월 17일로 잡으면 될까요?
정태호: 17일이면 좋죠. 근데 그 전에 현장 테스트를 한 주는 해야 해서요.
윤서아: 네, 테스트는 11월 10일부터 일주일, 인천 2센터에서만 할게요.
이도현: 데이터는 지금 쓰시는 TMS에서 가져와야 하는데, API 문서 받을 수 있을까요?
정태호: API가 있긴 한데 문서가 오래됐어요. 제가 이번 주 금요일까지 최신 걸로 정리해서 드릴게요.
이도현: 금요일이면 9월 26일이요. 그리고 테스트 서버 접근 계정도 필요합니다.
정태호: 그건 보안팀 승인이 필요해서… 다음 주 중에는 될 거예요. 확답은 못 드려요.
박지훈: 1차 범위 확인할게요. 차량별 실시간 위치, 배차 현황 보드, 지연 알림. 이렇게 세 개 맞죠?
윤서아: 기사님 채팅도 넣어 주시면 좋겠어요. 현장에서 제일 요청 많은 거라.
박지훈: 채팅은 공수가 커서 17일 오픈에는 어려울 것 같습니다. 2차로 빼는 걸 제안드려요.
정태호: 음, 일단 2차로 하죠. 대신 1차에 긴급 공지 한 줄 보내는 건 되나요?
이도현: 단방향 공지면 가능합니다. 답장 없는 걸로요.
정태호: 그걸로 해요.
최유나: 화면은 주로 어디서 보세요? 사무실 모니터인지, 현장 태블릿인지요.
윤서아: 사무실 27인치 모니터가 메인이고, 센터장님들은 갤럭시탭으로 볼 거예요.
최유나: 그럼 태블릿은 가로 모드 기준으로 잡겠습니다. 시안은 10월 2일까지 드릴게요.
정태호: 2일 좋아요. 시안 리뷰는 저랑 윤 매니저 둘이 볼게요.
이도현: 지연 알림 기준이 궁금한데요, 몇 분 늦으면 지연인가요?
윤서아: 보통 30분이요. 근데 새벽 배송은 15분으로 봐야 해요.
이도현: 새벽 배송 구분은 TMS 데이터에 있나요?
윤서아: 아마 있을 거예요. 확인해 볼게요.
박지훈: 위치 갱신 주기는요? 실시간이라고 하셨는데 몇 초 단위인지요.
정태호: 지금 기사 앱이 1분에 한 번 보내요. 더 짧게는 기사 앱 업데이트가 필요해서 이번엔 어려워요.
박지훈: 그럼 1차는 1분 주기로 확정하겠습니다.
정태호: 네.
박지훈: 계약 쪽은요, 견적서 기준 4,800만 원으로 진행하는 거 맞으시죠?
정태호: 그건 제가 구매팀이랑 한 번 더 얘기해야 해요. 다음 주 화요일까지 알려드릴게요.
박지훈: 알겠습니다. 계약 확정 전에 착수해도 될지는 저희 내부에서 판단할게요.
이도현: 로그인은 기존 사내 SSO 쓰시나요?
정태호: 네, Azure AD요. 근데 협력사 계정은 SSO에 없어서 그건 따로 생각해야 해요.
이도현: 협력사 계정은 1차 범위에 포함인가요?
정태호: 음… 그건 내부 확인하고 알려드릴게요.
박지훈: 주간 미팅은 매주 수요일 2시로 하면 될까요?
정태호: 좋아요. 다음 미팅은 10월 1일이네요.
박지훈: 네, 그때 API 문서랑 시안 진행 상황 공유드리겠습니다.
윤서아: 아 그리고 인천 2센터 말고 평택 센터도 테스트 넣을 수 있을지 제가 센터장님께 물어볼게요.
박지훈: 네 감사합니다. 오늘은 여기까지 하겠습니다.
---

원하는 결과: 결정 사항, 액션 아이템(담당/기한), 미결 사항/후속 질문, 리스크, 일정 요약. 녹취에 없는 내용은 추측하지 말고 표시해 주세요.
```

Expected output: A Notion-ready Korean summary that lists the confirmed decisions (11/17 launch, one-week Incheon 2 test from 11/10, 3-feature scope plus one-way notice, chat moved to phase 2, 1-minute refresh, 30/15-minute delay thresholds, landscape tablet, weekly Wednesday 14:00 meeting), action items with only the owners and deadlines the transcript supports (정태호: API doc by 9/26, test account next week (unconfirmed), contract reply by next Tuesday, partner-account scope with no date; 윤서아: dawn-delivery flag and Pyeongtaek test with no date; 최유나: mockups by 10/2), open questions, risks, and a timeline, with anything not in the transcript marked.

Sample output:

```markdown
# 한빛물류 배차 관리 대시보드 킥오프 미팅 요약

- **일시:** 2026-09-24(수) 14:00~14:52, 화상
- **참석:** [한빛물류] 정태호 팀장(IT), 윤서아 매니저(운영) / [우리] 박지훈 PM, 이도현 테크리드, 최유나 디자이너
- **목적:** 배차 관리 대시보드 1차 범위와 일정 확정
- **표기 규칙:** `⚠️ 녹취 미언급` = 녹취에 없는 내용이라 확정하지 않은 부분입니다. `(추정)` = 녹취에서 유추했지만 명시적으로 합의하지는 않은 부분입니다.

---

## 1. 한 줄 요약

11/17 오픈, 11/10부터 1주일 인천 2센터 현장 테스트 일정으로 1차 범위(실시간 위치, 배차 현황 보드, 지연 알림, 단방향 긴급 공지)를 확정했습니다. 기사 채팅은 2차로 미뤘습니다. 다만 **API 문서, 테스트 서버 계정, 계약 금액, 협력사 계정 범위**가 아직 미정이라 개발 착수 일정이 여기에 달려 있습니다.

---

## 2. 결정 사항

| # | 항목 | 결정 내용 | 비고 |
|---|---|---|---|
| D1 | 오픈일 | **2026-11-17** | 고객 목표: 11월 넷째 주 블랙프라이데이 물량 전 현장 사용 |
| D2 | 현장 테스트 | **11/10부터 1주일, 인천 2센터** | 평택 센터 추가 여부는 미정(Q5 참고) |
| D3 | 1차 범위 | ① 차량별 실시간 위치 ② 배차 현황 보드 ③ 지연 알림 ④ **긴급 공지(단방향, 답장 없음)** | ④는 채팅을 2차로 빼면서 대안으로 추가 |
| D4 | 2차로 이관 | **기사 채팅** | 현장 요청이 가장 많은 기능이라는 점은 기록해 둠 |
| D5 | 위치 갱신 주기 | **1분** | 기사 앱이 현재 1분 주기로 전송. 주기를 줄이려면 기사 앱 업데이트가 필요해 이번엔 제외 |
| D6 | 사용 환경 | 메인: **사무실 27인치 모니터** / 보조: **센터장용 갤럭시탭** | 태블릿은 **가로 모드 기준**으로 디자인 |
| D7 | 시안 | **10/2까지 전달**, 리뷰어: 정태호 팀장, 윤서아 매니저 | |
| D8 | 지연 알림 기준 | 일반: **30분**, 새벽 배송: **15분** | 새벽 배송을 구분할 수 있는 데이터가 있는지는 미확인(Q3 참고) |
| D9 | 인증 | 사내 계정은 **기존 SSO(Azure AD)** 사용 | 협력사 계정은 SSO에 없음(Q4 참고) |
| D10 | 정기 미팅 | **매주 수요일 14:00**, 다음 미팅 **10/1(수)** | 10/1 안건: API 문서, 시안 진행 상황 |

---

## 3. 액션 아이템

| # | 담당 | 할 일 | 기한 | 상태/비고 |
|---|---|---|---|---|
| A1 | 정태호 (한빛) | TMS API 최신 문서 정리해서 전달 | **9/26(금)** | 기존 문서가 오래됨 |
| A2 | 정태호 (한빛) | 테스트 서버 접근 계정 발급(보안팀 승인 필요) | **다음 주 중** (9/28~10/2 주) | ⚠️ **"확답 못 드린다"고 함.** 확정된 기한 아님 |
| A3 | 윤서아 (한빛) | TMS 데이터에 새벽 배송 구분 값이 있는지 확인 | ⚠️ 녹취 미언급 | 지연 알림 15분 기준 구현에 필요 |
| A4 | 정태호 (한빛) | 구매팀과 계약 금액(견적 4,800만 원) 재확인 후 회신 | **다음 주 화요일** (9/30) | |
| A5 | 정태호 (한빛) | 협력사 계정이 1차 범위에 들어가는지 내부 확인 후 회신 | ⚠️ 녹취 미언급 | |
| A6 | 윤서아 (한빛) | 평택 센터 테스트 추가 가능 여부를 센터장님께 확인 | ⚠️ 녹취 미언급 | |
| A7 | 최유나 (우리) | 시안 전달(모니터 + 갤럭시탭 가로) | **10/2** | 리뷰: 정태호, 윤서아 |
| A8 | 우리 내부 (⚠️ 담당자 미지정) | 계약 확정 전에 착수할지 판단 | ⚠️ 녹취 미언급 | 박지훈 PM이 "내부에서 판단하겠다"고만 언급 |
| A9 | 박지훈 (우리) | 10/1 주간 미팅에서 API 문서, 시안 진행 상황 공유 | **10/1** | |

> 참고: A2는 9/24(수) 기준 "다음 주 중"이라고 해서 9/28~10/2 주로 해석했습니다. A4의 "다음 주 화요일"도 같은 기준으로 9/30으로 계산했습니다. 해석이 다르면 수정해 주세요.

---

## 4. 미결 사항 / 후속 질문

| # | 질문 | 누구에게 | 왜 중요한가 |
|---|---|---|---|
| Q1 | 테스트 서버 계정은 정확히 언제 나오나요? | 정태호 | 기한이 확정되지 않았고, 계정이 있어야 연동 개발을 시작할 수 있음 |
| Q2 | 계약 금액 4,800만 원이 확정인가요? | 정태호 (9/30 회신 예정) | 착수 시점과 범위 판단에 필요 |
| Q3 | TMS 데이터로 새벽 배송을 구분할 수 있나요? 없다면 어떤 기준으로 구분하나요? | 윤서아 | 없으면 지연 알림 15분 기준을 1차에 적용하기 어려움 |
| Q4 | 협력사 계정이 1차 범위에 들어가나요? 들어간다면 로그인은 어떻게 하나요? | 정태호 | SSO에 없어서 별도 인증 설계가 필요할 수 있음 |
| Q5 | 평택 센터도 테스트에 추가하나요? | 윤서아 | 테스트 준비 범위와 지원 인력에 영향 |
| Q6 | "지연"은 무엇을 기준으로 판단하나요? (예정 도착 시각? 상차 시각?) | 윤서아 | ⚠️ 녹취 미언급. 분 단위 기준만 나왔고 기준 시점은 논의되지 않음 |
| Q7 | 긴급 공지는 누가, 누구에게, 어떤 경로(기사 앱 푸시, SMS 등)로 보내나요? | 정태호/윤서아 | ⚠️ 녹취 미언급. "단방향, 답장 없음"만 합의됨. 기사 앱 쪽 수신 기능이 필요한지에 따라 공수가 크게 달라짐 |
| Q8 | 지연 알림은 누가, 어디서 받나요? (대시보드 화면 안? 푸시?) | 윤서아 | ⚠️ 녹취 미언급 |
| Q9 | 동시 사용자 수, 차량 대수 규모는 어느 정도인가요? | 정태호 | ⚠️ 녹취 미언급. 1분 주기 갱신 부하와 보드 레이아웃에 영향 |

---

## 5. 리스크

| # | 리스크 | 영향 | 대응 제안 |
|---|---|---|---|
| R1 | **개발 기간이 짧음.** 시안이 10/2에 나오고 현장 테스트는 11/10 시작이라, 실제 개발은 약 5주 남짓(추정) | 일정 지연 시 블랙프라이데이 전 오픈이 어려움 | 10/1 미팅에서 개발 마일스톤을 합의하고, 시안 리뷰 피드백 기한도 정하기 |
| R2 | **테스트 서버 계정 일정이 불확실** (보안팀 승인, 확답 없음) | 연동 개발 착수 지연 | 계정 전까지 API 문서 기반으로 목업 데이터를 만들어 선개발. 10/1 미팅에서 진행 상황 확인 |
| R3 | **API 문서 품질** (기존 문서가 오래됐다고 함) | 문서가 와도 실제 동작과 다를 수 있음 | 문서를 받으면 바로 테스트 서버에서 검증할 항목 목록 준비 |
| R4 | **계약 미확정 상태에서 착수 여부** | 착수하면 비용 리스크, 미루면 일정 리스크 | 9/30 회신 전까지 내부 판단 기준과 담당자를 정하기(A8) |
| R5 | **새벽 배송 구분 데이터가 없을 가능성** ("아마 있을 거예요") | 지연 알림 기준 이원화가 안 될 수 있음 | 없을 경우의 대안(예: 시간대 기준)을 미리 고객과 합의 |
| R6 | **협력사 계정 범위가 미정** | 1차에 포함되면 SSO 외 별도 인증이 추가되어 공수 증가 | 조기 확답을 요청하고, 포함 시 일정 영향을 미리 산정 |
| R7 | **"실시간"에 대한 기대치 차이** | 현장에서는 1분 주기를 실시간으로 느끼지 않을 수 있음 | 화면에 "마지막 갱신 시각" 표시를 검토(디자인 제안 사항) |
| R8 | **채팅이 2차로 밀린 것에 대한 현장 반응** (가장 많이 요청된 기능) | 테스트 기간에 추가 요구가 나올 수 있음 | 2차 일정을 대략이라도 공유해서 범위가 늘어나는 것을 방지 |
| R9 | **테스트 기간 1주일 뒤 바로 오픈** | 테스트에서 이슈가 나오면 고칠 시간이 부족 | 테스트 중 발견 이슈를 분류(오픈 전 필수 vs 이후 수정)하는 기준을 미리 합의 |

---

## 6. 일정 요약

| 날짜 | 내용 | 확정 여부 |
|---|---|---|
| 9/24(수) | 킥오프 미팅 | 완료 |
| 9/26(금) | TMS API 최신 문서 전달 (정태호) | 약속됨 |
| 9/28~10/2 주 | 테스트 서버 계정 발급 (정태호) | ⚠️ 미확정 |
| 9/30(화) | 계약 금액 회신 (정태호) | 약속됨 |
| 10/1(수) 14:00 | 주간 미팅 #1: API 문서, 시안 진행 공유 | 확정 |
| 10/2(금) | 디자인 시안 전달 (최유나) | 확정 |
| 매주 수 14:00 | 정기 주간 미팅 | 확정 |
| 11/10(화)~ 1주일 | 인천 2센터 현장 테스트 (평택 추가 검토 중) | 확정 (평택은 미정) |
| **11/17(화)** | **1차 오픈** | 확정 |
| 11월 넷째 주 | 블랙프라이데이 물량 (고객 목표 시점) | 참고 |
| 미정 | 2차 (기사 채팅 등) | ⚠️ 녹취 미언급 |

---

## 7. 가정 사항

- 날짜와 요일은 2026년 달력으로 계산했습니다.
- "다음 주 중", "다음 주 화요일"은 미팅일(9/24) 기준으로 해석했습니다.
- 1차 개발 기간(R1)은 시안 전달일부터 테스트 시작일까지로 추정한 값이고, 녹취에서 합의된 개발 일정은 없습니다.
- 녹취가 자동 전사라서 인명, 숫자, 날짜가 잘못 전사되었을 수 있습니다. 특히 **4,800만 원, 30분/15분, 11/10, 11/17**은 공유 전에 한 번 더 확인하시길 권합니다.

---

## 8. 다음 액션 (우리 팀 기준, 우선순위순)

1. **이도현:** API 문서를 받으면 바로 검토하고, 누락되거나 확인이 필요한 항목을 10/1 미팅 전에 정리
2. **박지훈:** 계약 전 착수 여부를 판단할 내부 담당자와 기준을 정하고(A8), 9/30 회신을 팔로업
3. **최유나:** 10/2 시안 준비. 사무실 27인치 + 갤럭시탭 가로 모드 기준, "마지막 갱신 시각" 표시 검토
4. **박지훈:** 10/1 미팅 안건에 Q1, Q3~Q8 추가
5. **개발팀 전체:** 테스트 서버 계정이 늦어질 때를 대비해 목업 데이터 기반 선개발 계획 수립
```

Review notes:
- Real run on 2026-09-29: Claude Opus 5.5 with the agent prompt as instructions and this input, single turn, no tools. Graded by a separate Claude reviewer against the evaluation criteria; not yet reviewed by a human maintainer.
- All owner and deadline attributions check out against the transcript: A1 정태호 9/26, A2 test account 'next week' with the 'can't confirm' caveat preserved, A3/A5/A6 correctly marked '녹취 미언급' for deadlines, A7 최유나 10/2, and A8 correctly notes no internal owner was named for the start-before-contract decision. No fabricated owner or deadline was found.
- Decisions D1-D10 are all supported, including the nuance that the one-way emergency notice was added as a substitute for chat (정태호 '그걸로 해요') and that 1-minute refresh was explicitly confirmed (박지훈 '1분 주기로 확정').
- The weekday labels are internally inconsistent: the schedule table shows '10/1(수) 14:00' followed by '10/2(금)', and '9/30(화)' next to '11/10(화)' and '11/17(화)'. Section 7 claims the '2026년 달력' was used, but in 2026 9/24 is a Thursday, so the transcript's '(수)' and '금요일 = 9/26' conflict with the real calendar. The run should have flagged this instead of silently mixing the two conventions.
- Unsupported items are clearly separated: Q6-Q9 and R1 are tagged '⚠️ 녹취 미언급' or '(추정)', and the assumptions section asks the team to double-check auto-transcribed figures (4,800만 원, 30/15분, 11/10, 11/17). This is good practice.
- Structure (decisions, actions, open questions, risks, timeline, assumptions, next steps) pastes cleanly into Notion. The risk and question lists are somewhat padded for a doc aimed at four absent teammates.

#### Summary request with a fragmentary transcript and no attendees
Input:

```
meeting notes pls, send to the team today

- ok so we go with option B?
- yeah probably, unless finance says no
- mike will check. or sarah
- launch maybe end of month
- also the pricing thing, park it
- next sync tbd
```

Expected output: A sendable provisional summary that marks Option B as tentative pending finance, flags the ambiguous owner (Mike or Sarah), the vague launch date, the parked pricing item, and the unscheduled next sync as TBD, and asks only the few questions needed to finalize it (owner, attendees/date/project, what Option B is).

Sample output:

```markdown
Here's a draft you can send today. I can't send it to the team myself, so copy it into email or Slack. I've marked the open points as **[TBD]** rather than guessing. Before you send it, please fill these in or answer them here:

1. **Who checks with finance: Mike or Sarah?** Pick one person so it doesn't fall through the cracks.
2. **Meeting date, who attended, and the project name** (for the header).
3. **What "option B" is**, in one line, so people who weren't in the room understand the decision.

---

**Meeting Summary: [Project name] – [Date]**
**Attendees:** [Names]

**Decision (provisional)**
- The team is leaning toward **Option B** [one-line description].
- This depends on **finance approval**. It is not final until finance signs off.

**Timeline**
- Target launch: **end of month (tentative)**. This also depends on the finance approval.

**Parked**
- **Pricing**: deferred on purpose and not discussed further. No owner or date to revisit yet.

**Next Actions**
| Action | Owner | Due |
|---|---|---|
| Confirm Option B with finance | [Mike **or** Sarah – TBD] | [Date – suggest ASAP, given the end-of-month launch] |
| Schedule next sync | [TBD] | [TBD] |
| Decide when to revisit pricing | [TBD] | [TBD] |

**Risks**
- **Finance says no**: Option B and the launch date would both be back on the table. We have no fallback agreed yet.
- **Unclear owner for the finance check**: "Mike or Sarah" could mean nobody follows up.
- **End-of-month launch with pricing parked**: if pricing needs to be settled before launch, parking it could delay the launch.
- **No next sync scheduled**: the finance answer may have no forum to be discussed in.

---

**Assumptions I made**
- "Option B" is the working choice, not a final decision.
- The end-of-month launch refers to this month and depends on Option B being approved.
- "Park the pricing thing" means defer it, not drop it.

**Recommendations**
- Name a single owner for the finance check and set a due date a few days out, so the launch date stays realistic.
- Agree now on what happens if finance says no. For example: fall back to Option A, or reconvene within 48 hours.
- Confirm whether pricing has to be decided before launch. If it does, give it an owner and a date.
- Book the next sync for shortly after the finance answer is expected.

Send me the three items above and I'll return a clean, ready-to-send version.
```

Review notes:
- Real run on 2026-09-29: Claude Opus 5.5 with the agent prompt as instructions and this input, single turn, no tools. Graded by a separate Claude reviewer against the evaluation criteria; not yet reviewed by a human maintainer.
- Asks exactly three focused questions (finance owner, header details, what Option B is) and still delivers a ready-to-fill draft, which moves the work forward without stalling.
- Invents no facts: the owner is written as '[Mike or Sarah – TBD]', the launch as 'end of month (tentative)', and pricing as parked with 'No owner or date to revisit yet', all faithful to the fragments.
- It correctly says it cannot send the message itself, which answers 'send to the team today' honestly.
- Minor inference: the body states that the launch 'also depends on the finance approval', which the notes don't say outright. It does list this in 'Assumptions I made', so the reader is warned.
- The risks it lists (no fallback if finance says no, diffuse ownership, parked pricing vs. launch, no next sync) are concrete and drawn from the actual gaps in the notes.

## Decision guide
### Is this the right agent for my task?
Extracting decisions, action items, owners, and open questions from meeting notes

### When should I choose something else?
The transcript is too sensitive to share or lacks speaker/context clues

### What should I run next?
After this agent produces a draft, use a planning, documentation, or QA agent to turn it into a team-ready handoff.

## Metadata
- Slug: meeting-summary-agent
- Roles: Pm, Cs, Founder
- Categories: Operations, Documentation
- Tools: ChatGPT, Zoom, Notion
- Difficulty: Beginner
- Automation level: 5/5
- Verified status: Community
- Updated at: 2026-09-29