feat(meet): 회의록 가이드 v2 반영 + 모델 출력 붕괴 복원력 (v2.2.253)
회의록 출력물 개선 (실무 회의록 가이드 v2): - 섹션 우선순위 재정렬(①결정 ②액션 ③오픈이슈 ④리스크 ⑤논의) - 논의사항 주제별 bullet 간결화, 오픈 이슈 섹션 복원 - 액션 아이템 산출물 컬럼 추가(담당·작업·기한·산출물 4요소), 담당자 개인 우선 - Executive Summary 결과 중심, 결정사항은 확정된 것만 모델 출력 붕괴(degeneration) 대응: - callLmSynthesis 재시도 내장(repeat_penalty↑/top_k↓로 반복 억제 강화) + looksDegenerate 감지 - 긴 녹취 조각 실패 시 절반 분할 재귀 재시도(12K→6K→3.5K) - 부분 회의록 fallback(한 조각 실패해도 전체 중단 안 함) 하위호환: 액션 표 파서 신6컬럼/구5컬럼 모두 파싱, 섹션 번호 무관 탐지, 회의일 추출 일시/날짜 둘 다 인식. 테스트 +13건(전체 659 통과). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -64,45 +64,68 @@ ${OUTPUT_FORMAT}`;
|
||||
}
|
||||
|
||||
/** 최종 회의록 출력 형식 — 단일샷(buildMeetPrompt)과 병합 단계(buildMeetReducePrompt)가 공유. */
|
||||
const OUTPUT_FORMAT = `# 출력 형식 (Output Format — 정확히 이 구조를 유지)
|
||||
const OUTPUT_FORMAT = `# 작성 원칙 (회의록 품질 — 출력 전 반드시 내재화)
|
||||
회의록은 *대화 요약 문서*가 아니라 **프로젝트 관리 문서**다. 회의 내용 자체보다 "무엇이 결정됐는가 / 누가 무엇을 해야 하는가 / 무엇이 아직 결정 안 됐는가"를 우선한다.
|
||||
- **정보 우선순위**: ①결정사항 ②액션아이템 ③오픈 이슈 ④리스크 ⑤논의사항 순으로 중요하다. 분량·정성도 이 순서로 배분한다.
|
||||
- **사실 중심**: 추정·해석·평가가 아니라 회의에서 실제 논의·확정된 것만 적는다. (예: "API 연동이 가능할 것으로 판단됨"❌ → "API 연동 가능 여부 검토 필요"✅)
|
||||
- **결정사항 ↔ 논의사항 구분(최우선)**: 명시적으로 합의·확정된 것만 '결정 사항'에 둔다. "검토 필요/정의 필요/활용 검토"처럼 *확정되지 않은 것*은 결정사항이 아니다 — 논의 사항·오픈 이슈로 내린다. 반대로 실제 확정된 것을 결정사항에서 누락하지도 말 것.
|
||||
- **결과 중심**: 발언 순서·토론 과정·"누가 무슨 말을 했는지"를 나열하지 말고 *결과*를 적는다. (예: "PlayCanvas를 논의함"❌ → "PlayCanvas/Babylon.js 비교 검토 진행 예정"✅) 책임 소재나 입장 차이가 핵심일 때만 발언자를 밝힌다.
|
||||
- **담당자는 개인 우선**: "개발팀/QA팀" 같은 조직 단위가 아니라 개인 이름(예: 송병준, 김원일 PD)으로 적는다. 실제로 개인이 안 정해졌으면 "개발팀 (담당자 지정 필요)" 형태로 표기.
|
||||
- **증빙 보존**: 결정되지 않은 사항이라도 중요한 논의·리스크는 빠짐없이 기록한다(향후 이력·분쟁 근거).
|
||||
|
||||
# 출력 형식 (Output Format — 정확히 이 구조를 유지)
|
||||
|
||||
# [회의 제목]
|
||||
|
||||
- **날짜**: [YYYY년 MM월 DD일 | 확인 불가]
|
||||
## 1. 회의 개요
|
||||
- **일시**: [YYYY년 MM월 DD일 | 확인 불가]
|
||||
- **참석자**: [메타데이터 기준 | 없을 경우: 논의 참여 주체]
|
||||
- **주제 요약**: [한 문장 요약]
|
||||
- **회의 목적**: [이 회의가 왜 열렸는지 한 문장. 녹취록에서 드러난 목적만 적고, 불명확하면 "확인 필요"]
|
||||
|
||||
## 🔹 요약 보고
|
||||
핵심 논의 요약 3~5개를 글머리표로 작성.
|
||||
|
||||
## 1. 주요 논의 사항
|
||||
각 안건마다 아래 구조로:
|
||||
### [안건 제목]
|
||||
- **현황**:
|
||||
- **핵심 논의**: 쟁점이 되거나 주체가 중요한 발언은 "OOO: ~" 형태로 발언자를 밝힌다. 주체가 불명확하면 이름을 붙이지 말 것.
|
||||
- **결론**: [결정됨 / 논의 중 / 보류]
|
||||
|
||||
## 2. 리스크 및 이슈
|
||||
## 2. 주요 결과 (Executive Summary)
|
||||
회의 *결과*를 3~5줄 글머리표로 요약한다. 회의 내용을 설명하지 말고(예: "Babylon.js를 검토함"❌) 결과를 적는다(예: "테스트 샘플 3종 선정", "CCOC 1차 작업 6/19까지 진행"✅). **참석하지 않은 이해관계자가 이 항목만 읽어도 결과를 파악할 수 있어야 한다.**
|
||||
|
||||
## 3. 결정 사항
|
||||
**명시적으로 합의·확정된 것만** 적는다 (일정 확정·개발 범위 확정·정책 변경·후속 방향 확정 등). 검토·정의·도입여부가 *필요*한 단계의 것은 여기 넣지 말고 '오픈 이슈'나 '논의 사항'으로 내린다.
|
||||
각 결정 끝에 근거 발언을 인용한다: \`- [결정 내용] — 근거: "발언 원문 일부"\`
|
||||
(이번 회의에서 확정된 결정이 없으면 "이번 회의에서 확정된 결정사항 없음"이라고 명시한다 — 빈칸·생략 금지.)
|
||||
|
||||
## 4. 오픈 이슈
|
||||
|
||||
## 5. 액션 아이템
|
||||
각 행은 반드시 녹취록 근거로 작성한다. 표 셀 안에서는 줄바꿈과 \`|\` 문자를 쓰지 말 것.
|
||||
| 담당 | 작업 내용 | 작업 상세 | 기한 | 상태 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
## 4. 액션 아이템
|
||||
회의 후 수행할 업무를 **담당·작업·기한·산출물 4요소**가 모두 드러나게 정리한다. 각 행은 반드시 녹취록 근거로 작성한다. 담당자는 개인 우선(없으면 "OO팀 (담당자 지정 필요)"). 회의에서 기한·산출물이 안 나왔으면 해당 칸에 "확인 필요"라고 적는다. 표 셀 안에서는 줄바꿈과 \`|\` 문자를 쓰지 말 것.
|
||||
| 담당 | 작업 내용 | 작업 상세 | 산출물 | 기한 | 상태 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
|
||||
- **작업 내용**: 한 줄짜리 작업명. 캘린더 일정 제목으로 그대로 쓰이므로 그 자체로 무슨 일인지 식별되게 작성한다. ("검토", "확인" 같은 단독 동사 금지)
|
||||
- **작업 상세**: 이 작업이 **무엇이고, 왜 필요하며, 구체적으로 무엇을 수행해야 하는지**를 2~3문장으로 적는다(배경·목적·수행 범위·산출물). 녹취록에서 언급된 대상·수치·조건을 그대로 인용하고, **마지막에 근거 발언 원문 일부를 \`근거: "…"\` 형태로 덧붙인다**. 근거가 부족하면 "추가 확인 필요: …" 형태로 무엇을 확인해야 하는지 명시한다. 단순히 작업명을 반복하지 말 것.
|
||||
- **작업 상세**: 이 작업이 **무엇이고, 왜 필요하며, 구체적으로 무엇을 수행해야 하는지**를 2~3문장으로 적는다(배경·목적·수행 범위). 녹취록에서 언급된 대상·수치·조건을 그대로 인용하고, **마지막에 근거 발언 원문 일부를 \`근거: "…"\` 형태로 덧붙인다**. 근거가 부족하면 "추가 확인 필요: …" 형태로 명시. 단순히 작업명을 반복하지 말 것.
|
||||
- **산출물**: 이 작업이 끝나면 나오는 구체적 결과물(예: 테스트 URL 목록, 비교 분석 문서, 일정표). 회의에서 안 나왔으면 "확인 필요".
|
||||
- **상태**: 다음 중 정확히 하나로 분류한다 (캘린더 자동 등록 게이트가 이 값으로 분기하므로 형식 엄수):
|
||||
- \`확정\` — 진행 합의가 명시적이고 기한도 언급됨.
|
||||
- \`진행미정\` — 작업이 언급됐으나 실제로 진행할지 합의가 명확하지 않음.
|
||||
- \`기한미정\` — 하기로 확정됐으나 완료일/D-Day 가 정해지지 않음.
|
||||
- \`조건부: <선행작업>\` — 다른 작업·사건이 끝나야 진행 (선행작업을 짧게 명시. 예: \`조건부: 계약 체결 후\`).
|
||||
- \`반복: <주기>\` — 정기 반복 업무 (예: \`반복: 매주 목요일\`).
|
||||
확신이 없으면 \`확정\`이 아니라 \`진행미정\`/\`기한미정\` 쪽으로 보수적으로 분류한다.
|
||||
실제로 합의·기한이 나왔으면 \`확정\`으로 잡고, 정말 안 나온 것만 보수적으로 \`진행미정\`/\`기한미정\`으로 둔다.
|
||||
|
||||
## 5. 오픈 이슈
|
||||
회의 종료 시점에 **아직 결정되지 않은 미결 사항**을 한곳에 모아 글머리표로 정리한다 (도입 여부·정의 필요·확정 대기 등). 분산시키지 말고 여기서 한눈에 보이게 한다.
|
||||
- 예) Babylon.js 도입 여부 / 최소 지원 사양 정의 / 데이터 입력 구조 확정 / 가우시안 스플래팅 도입 여부
|
||||
|
||||
## 6. 리스크 및 검토 사항
|
||||
프로젝트 진행에 영향을 줄 수 있는 요소를 표로 정리한다(일정 지연·개발 난이도·정책/보안·외부 의존성 등). 식별된 리스크가 없으면 "현재 식별된 리스크 없음"이라고 적는다. 표 셀 안에서는 줄바꿈과 \`|\` 문자를 쓰지 말 것.
|
||||
| 리스크 | 영향 | 대응 방안 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 7. 논의 사항
|
||||
결정되지 않았으나 오간 논의를 **주제별 글머리표**로 간결하게 정리한다. (현황/핵심 논의/추가 검토 같은 하위 구조로 길게 늘이지 말 것.) 발언 나열 금지, 결과·쟁점 중심.
|
||||
**[주제명]**
|
||||
- 핵심 논점 한 줄
|
||||
- 핵심 논점 한 줄
|
||||
|
||||
**[다른 주제명]**
|
||||
- 핵심 논점 한 줄
|
||||
|
||||
# 최종 점검 (출력 전 내부 확인 — 체크 로그는 출력하지 말 것)
|
||||
□ 결정사항에 확정된 것만 있는가(검토 필요 항목이 섞이지 않았나) □ 액션 아이템에 담당(개인)·작업·기한·산출물 4요소가 있는가 □ 오픈 이슈가 한곳에 모였는가 □ 리스크가 영향·대응방안과 함께 정리됐는가 □ 논의사항이 주제별 bullet로 간결한가 □ 요약이 결과 중심인가 □ 결정·액션에 근거 인용이 붙어 있는가
|
||||
|
||||
위 형식을 정확히 따르고, 모든 내용은 한국어로 작성하시오.`;
|
||||
|
||||
@@ -132,6 +155,8 @@ ${segment}
|
||||
\`\`\`
|
||||
|
||||
# 출력 형식 (이 조각에 해당 항목이 없으면 "없음")
|
||||
## 회의 목적
|
||||
(이 조각에서 회의의 목적·배경이 드러나면 한 줄로. 안 드러나면 "없음")
|
||||
## 발언자
|
||||
(이 조각에 등장한 발언자 이름/ID 목록)
|
||||
## 사실(Fact)
|
||||
@@ -143,7 +168,7 @@ ${segment}
|
||||
## 리스크/이슈
|
||||
- 내용 — 근거: "…"
|
||||
## 액션(Action)
|
||||
- [담당] 작업 내용 (기한: …) — 근거: "…"
|
||||
- [담당(개인 우선)] 작업 내용 (기한: … / 산출물: …) — 근거: "…"
|
||||
## 언급된 수치·날짜·금액
|
||||
- 항목: 값 — 근거: "…"`;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user