yowu-write-meeting

name

yowu-write-meeting

description

회의록에 적히는 문장을 팀원이 한 번에 읽히도록 풀어 쓰거나 감사(audit)할 때 사용한다. 줄글 벽·과잉 기록·모호한 상태 표기('논의함'으로 끝나 결과를 알 수 없는 문장)·보고서 말투를 걷어내되, 시스템명·도메인 용어는 그대로 둔다. 문장 품질만 다룬다 — 섹션 구성·양식 같은 회의록 구조는 팀 포맷의 몫이고, 녹취록 변환·발화자 귀속·원문 대조 같은 사실 충실도는 별도 기능의 몫이다. 위키 최종본은 yowu-write-wiki, 기술 문서·PR은 yowu-write-tech, 에세이·회고는 yowu-write-essay를 쓴다. 트리거 - "회의록 다듬어", "회의록 읽기 쉽게 정리", "회의록 문장 정리", "미팅노트 다듬기", "회의 결정사항 문장 정리", "write meeting", "회의록 감사/검토".

yowu-write-meeting: 회의록 문장 풀어쓰기

회의에 없던 사람이 회의록을 안 읽는 이유는 내용이 어려워서가 아니다. 한 줄 한 줄 따라 읽는 노력이 너무 커서다. 오간 말을 그대로 옮긴 줄글, "논의함"으로 끝나 결과를 알 수 없는 항목, 보고서 말투로 부푼 문장 앞에서 독자는 읽기를 포기하고 사람에게 물어본다. 그 순간 회의록은 실패한다. 이 스킬은 그 노력을 깎는다 — 문장에서.

목표: 회의에 없던 팀원이 회의록의 각 줄을 한 번에 읽고 "무슨 결과인지, 내가 뭘 해야 하는지"를 아는 것. 논의의 깊이는 유지하고, 문장을 따라 읽는 부하만 낮춘다. 구조·양식이 아니라 그 안에 적히는 문장만 다룬다.

우선순위가 충돌하면: 명료 > 간결 > 스타일. 그리고 이 셋 모두에 앞서는 절대 규칙 하나 — 없는 내용을 지어내 채우지 않는다. 재료(녹취·메모)에 있는 것만 쓴다. 재료가 말하지 않은 결정·기한·담당자를 발명하지 않는다.

스킬 분기와 범위 경계

• 회의록에 적히는 문장을 팀이 한 번에 읽게 → yowu-write-meeting (이 스킬)
• 회의록을 검색으로 유입될 위키·컨플루언스 최종본으로 다듬을 때 → yowu-write-wiki
• 설계 문서·PR 설명·장애 보고서 같은 기술 문장 → yowu-write-tech
• 에세이·블로그·개인 회고 → yowu-write-essay
• 매체가 불분명한 요청 → 대상 매체를 먼저 확인한다
• 이 스킬은 문장 품질만 다룬다. 회의록에 어떤 섹션을 둘지, 무엇을 앞세울지, 표·불릿 중 무엇을 쓸지 같은 구조·양식은 팀 포맷의 몫이라 규정하지 않는다. 녹취록을 회의록으로 변환하는 절차, 발화자 오귀속 검증, 원문과 1:1 대조하는 사실 충실도 점검도 별도 기능의 몫이다. 문장이 매끄럽다고 발화자 귀속·수치·합의 수준이 맞는 것은 아니다 — 문장 품질을 구조나 사실 충실도와 같은 것으로 착각하지 않는다.

용어 보존 규칙

• 도메인 언어와 기술 용어는 원형 유지. 팀이 쓰는 시스템명, 서비스 코드명, 도메인 용어를 회의록에서 다른 말로 바꾸지 않는다. 회의록은 그 용어로 검색되고 인용된다.
• 코드 식별자·설정 키·API 경로는 백틱으로 감싸고 변형하지 않는다.
• 푸는 것은 용어가 아니라 용어를 둘러싼 문장이다.

회의록 문장이 지켜야 할 것 (장르 규칙)

회의록 문장에는 다른 글에 없는 두 가지가 걸린다. 둘 다 문장을 어떻게 쓰느냐의 문제이지, 문서를 어떻게 배치하느냐가 아니다.

1. 결과를 말하는 문장으로 — 한 항목을 쓸 때 토픽만 말하고 끝내지 않는다. "~에 대해 논의함"은 독자에게 정보가 0이다. 그 논의가 어디로 갔는지 — 합의인지, 미정인지, 후속인지 — 를 문장에 담는다. 회의록 문장에서 지렛대가 가장 크다. 단, 재료가 말한 그 결과만 쓴다 — 재료가 합의를 말하지 않았으면 "합의"로 격상하지 않는다.
2. 중계가 아니라 요지 — 오간 말을 그대로 옮기지 않는다. 발언을 요지로 압축하고, 이견·쟁점·결정·액션만 남긴다. 단순 동의·잡담·곁가지는 버린다. 같은 내용을 여러 번 반복해 쓰지 않는다 — 한 번이면 된다. (한 항목의 표현을 요지로 줄이는 것은 문장 일이다. 어떤 항목·섹션을 문서에 둘지 배치하는 것은 팀 포맷의 몫이다.)

회의록 문장의 병 (진단이 먼저다)

고치기 전에 병명을 붙인다. 회의록에서 특히 치명적인 순서로:

1. 모호한 상태 (최악) — "긍정적으로 검토하기로 함", "추후 논의"로 끝나 결정인지 미정인지 알 수 없다. → 재료가 말한 딱 그 상태로 확정한다: "미정 — 비용 산정 후 재논의" 또는 "잠정합의 — 도입, 문제 발생 시 전환". 재료가 합의를 말하지 않았으면 "합의"로 격상하지 않는다.
2. 과잉 기록 — 오간 말을 다 옮겨 독자의 부하만 키운다. → 이견·쟁점·결정·액션만. 단순 동의는 결과에만 반영한다. 한 항목이 몇 줄을 넘기면 압축 신호다.
3. 명사화·피동 — "일정에 대한 조율이 진행되었음" → "일정을 조율함". (회의록의 명사형 종결 ~함은 관례이나, 동사를 명사로 굳히는 ~의 진행/수행과는 다르다.)
4. 의미 인플레이션·헤지 — "매우 중요한 안건", "활발히 논의됨", "~일 것으로 보임" → 사실만 쓰고 상태로 확정한다.
5. 빌린 권위 — "제반 사항을 종합적으로 검토", "만전을 기함" 같은 보고서 말투. → 팀원에게 말하듯 쓴다.

추가 신호: 중복(같은 내용을 여러 번), 빈 칸 채우기(정보 없는데 지어낸 내용 — 삭제). 병명이 안 잡히면 소리 내어 읽어 호흡이 막히는 문장을 찾는다.

풀어쓰기 기술 (the moves)

대상은 한국어 회의록이다. 다른 언어에는 언어 보편 규칙(상태 명시, 모호성 제거, 의미 인플레이션, 헤지, 부정 병렬)만 적용하고 조사·피동·번역투 규칙은 한국어에 한정한다.

1. 한 항목 한 요지 — 한 문장(또는 bullet)에 생각이 두 개 겹치면 나눈다.
2. 얼버무린 결론을 분명히 — 결론이 합의인지 미정인지 후속인지를 문장으로 못 박는다. 회의록에서 가장 지렛대가 큰 동작이다. 단, 재료가 상태를 명시하지 않으면 미정/후속이 정답이다 — 없는 합의를 지어내지 않는다.
3. 명사문을 동사문으로 — "~에 대한 검토가 필요함" → "~을 검토해야 함".
4. 능동·주체 명시 — 액션에는 담당자를, 결정에는 주체를("팀 합의"라도) 세운다. 주어 없는 액션은 아무도 안 한다. 단, 재료에 담당자가 없으면 발명하지 말고 "담당자 미정"으로 남긴다.
5. 이중피동·번역투 제거 — "~되어짐", "~에 있어서", "~을 필요로 함" → "~됨", "~에서", "~이 필요함".
6. 필러·곁가지 삭제 — 인사·잡담·주제 무관 발언은 회의록에 남기지 않는다.
7. 쉬운 말 — "활용함" → "씀", "수행함" → "함". 단, 팀이 공유하는 도메인 용어는 그대로 둔다.
8. 개조식 종결 통일 — ~함 / ~하기로 함. 존대체·서사체는 문장을 늘이고 지시 강도를 흐린다. (어떤 종결을 쓸지 팀 관례가 있으면 그것을 따른다.)
9. 호칭·발화자 태그는 문장 안에서 — 본문 속 이름에는 "님"을 붙인다(참석자 메타 목록은 예외, 팀 호칭 관례가 다르면 그것을 따른다). 발화자 태그(이름님:)로 문장을 부풀리지 않는다 — 이견·쟁점을 특정인에게 귀속해야 할 때만 붙이고 단순 요지엔 생략한다(어디까지 태깅할지는 팀 포맷을 따른다). 태그를 다는 것과 그 태그가 맞는 사람인지 검증하는 것은 다르다 — 검증은 범위 밖이다.

부정 병렬 금지 (AI 문체의 1번 신호)

"단순히 X가 아니라 Y입니다" 패턴과 변형("X를 넘어 Y로", "중요한 것은 X가 아니라 Y"). 기각할 프레임을 세웠다 무너뜨려 통찰처럼 보이게 하는 수사이고, 대부분 요점이 없다는 신호다. 기각 절반을 지우고 Y를 구체적 사실로 다시 쓴다. 사실을 기록하는 회의록에서 수사는 잡음이다. 예외: Y가 구체적 사실이고 본문이 그것을 실제로 증명하면 대비 구조를 써도 된다(이 문서 도입부가 그 예다).

블록리스트 (시작점 — 원칙이 목록보다 오래간다)

원칙: 결정·사실을 밝히는 대신 인상만 남기는 표현은 지운다.

• 상태 얼버무림: ~하는 방향으로, ~쪽으로 가닥, 긍정적으로/전향적으로 검토, 추후 협의 → 합의/미정/후속 중 하나로 확정
• 의미 인플레이션: 매우 중요한, 활발히 논의된, 심도 있게, 긴밀히 → 사실만
• 죽은 서두: "금일 회의에서는 ~에 대해 논의하였음" → 서두를 빼고 바로 안건·결과를 쓴다
• 장황 접속: 또한, 아울러, 이를 통해, ~함으로써 → 논리적 역할 없으면 무접속
• 빌린 권위: 제반 사항, 종합적으로, 상기/하기, 만전을 기함 → 평범한 말로
• 형식 tell: 억지 불릿 벽·과도한 볼드·모든 목록 3개 맞추기 → 문장이 아니라 AI 티만 난다. 정보 없는데 지어내 채운 내용 → 삭제

Writing mode (새 회의록 문장을 쓸 때)

초안은 평소대로 쓴다. 완성 후 세 번의 패스로 문장만 훑는다:

1. 상태 패스: 각 항목 문장이 결과(합의/미정/후속)를 말하나, 토픽만 말하고 끝나나? 얼버무린 상태를 재료가 말한 그 결과로 못 박는다 — 없는 합의는 만들지 않는다.
2. 부하 패스: 가장 무거운 문장 2~3개를 쪼갠다. 명사문→동사문, 피동→능동, 필러·곁가지 삭제, 개조식 종결 통일.
3. 정직 패스: 의미 인플레이션·헤지·부정 병렬·빌린 권위를 지운다. 같은 내용 반복을 줄인다. 재료에 없는 내용을 채우지 않았는지 확인한다.

세 패스 모두 문장만 본다. 구조를 바꿔주길 기대한 사용자가 있을 수 있으니, 배치·섹션은 그대로 두고 문장만 손봤음을 결과에 한 줄로 밝힌다.

Audit mode (기존 회의록을 감사할 때)

문제 지점을 원문 그대로 인용해 표시하고, 수정안을 제시한다. 이 감사는 문장 품질만 본다 — 구조(섹션 구성·순서)와 사실 충실도(발화자 귀속·수치·합의 수준)는 각각 팀 포맷과 원문 대조(별도 기능)의 몫이다. 아래는 형식 예시일 뿐이니 항목을 고정하지 말고 실제 발견된 것만 나열한다:

WRITE-MEETING AUDIT:
  상태 모호:   FLAG — "긍정적으로 검토하기로 함" → "미정 — 비용 산정 후 재논의" (재료가 합의를 말하지 않았으면 합의로 올리지 않는다)
  과잉 기록:   FLAG — 발언 5줄 중계 → 쟁점 2개 개조식으로 압축
  명사화:      FLAG — "일정에 대한 조율이 진행되었음" → "일정을 조율함"
  중복:        FLAG — 같은 내용을 두 번 → 한 번으로
  인플레이션:  FLAG — "매우 활발한 논의" → 삭제, 쟁점만
  용어 보존:   OK — `payment-gateway`, TTL 원형 유지 확인
  수정안: [내용과 용어를 보존한 재작성]

과교정 방지 (anti-overfitting)

• 규칙이 회의록을 더 나쁘게 만들면 규칙을 어긴다. 정신이 조문을 이긴다.
• 모든 문장을 짧게, 모든 줄을 불릿로 만들지 않는다. 인과가 흐르는 논의 요약은 짧은 문단이 더 읽힌다.
• 구조·양식·라벨·호칭 관례는 팀 포맷을 따른다. 이 스킬은 그 안의 문장에만 적용한다. 문장을 고치려고 팀의 섹션 구성이나 라벨 양식을 갈아엎지 않는다.
• 구체성과 간결은 싸우지 않는다: 얼버무린 상태를 재료가 말한 결과로 못 박으면 문장이 짧아지면서 정보는 는다 — 두 규칙은 서로 돕는다.
• 사실 검증은 하지 않는다: 사용자가 발화자 귀속·수치·합의 수준의 검증까지 원하면, 문장만 다듬고 사실 검증은 하지 않았음을 명시한다 — 그 검증은 원문 대조(별도 기능)의 몫이다.

상태를 문장에 명료하게 쓰기 (표현 예시)

모호한 상태를 문장에서 있는 그대로 못 박는 표현 예시다. 정해진 분류 체계가 아니라 예시이니, 팀 라벨 관례가 있으면 그것을 우선한다.

상황	문장 표현 예시
합의	합의 — ~로 진행
잠정합의	잠정합의 — ~로 진행 (문제 발생 시 전환)
미정	미정 — {사유 또는 후속 확인 사항}
후속	후속 — {담당자 / 액션}
스코프 제외	스코프 제외 — 이번 스코프에서 빼고 향후 인지 사항으로 기록

최종 테스트: 회의에 없던 팀원이 이 회의록의 각 줄을 한 번에 읽고 "무슨 결과인지, 내가 뭘 해야 하는지"를 답할 수 있는가? 답하려고 다시 사람을 찾아야 하면 문장 부하가 아직 높다.