우유랩스 문서 규칙

골격 — 모든 문서가 같다

제목(버전 포함) → 작성 YYYY.MM.DD · 목적 · 근거 출처 한 줄 → 요약 한 문단 →

번호 절 → 닫는 행동·결정 블록.

요약과 닫는 블록은 스키마에서 필수입니다. 조직의 성숙한 문서가 전부 그렇게 열고 닫습니다 —

확인해 주시면 좋을 지점 · 합의 필요 항목 · 다음 액션 · 발송 전 체크.

버전은 제목에 담습니다. 런웨이와 자금 계획 v0.3 처럼. 별도 메타 행을 만들지 않습니다.

문체 — 기계가 막는 것

  • ·본문에 줄표(—)를 쓰지 않습니다. 쉼표와 마침표로 나눕니다. 절 제목의 — 부연 은 예외입니다.
  • ·화살표(→)를 접속사로 쓰지 않습니다. 도식·코드·표에서는 됩니다.
  • ·~가 아니라 ~입니다 는 문서당 두 번까지입니다.
  • ·제목에 이모지를 붙이지 않습니다.
  • ·킥커에 01 · 02 같은 순번을 쓰지 않습니다. 출처와 맥락을 씁니다 —

SNAPSHOT INTERVIEW SHEET · 2026.08.31–09.04 처럼.

  • ·킥커에 The problem 같은 영문 분류 라벨을 쓰지 않습니다.
  • ·진행자 관용구를 쓰지 않습니다: 핵심은 이겁니다 · 한 문장으로 하면 · 솔직히.
  • ·덱의 제목은 서술문으로 씁니다. 병목의 위치 가 아니라 막히는 자리는 같고 채널만 다릅니다.

구조 — 스키마가 막는 것

글꼴·크기·색·정렬을 고르는 칸이 없습니다. 판면은 서버가 가집니다.

통계 타일을 격자로 까는 변형이 없습니다. 지표는 넷까지이고 헤어라인으로 나뉩니다.

슬라이드는 장면을 하나만 가집니다 — 유리판이 둘이 될 수 없습니다.

한국어에서 AI 가 쓴 티가 나는 것

번역투와 과설명이 대부분입니다. 아래는 기계가 잡습니다.

  • ·"~할 수 있습니다" 남발. 가능을 말할 때만 씁니다. `검수는 5영업일 이내에 완료할 수

있습니다 가 아니라 5영업일 이내에 완료합니다`.

  • ·"~하는 것을 목표로 합니다" · "~하고자 합니다". 하겠다고 씁니다.
  • ·"다양한" · "효율적인" · "최적화" · "혁신적인" · "체계적인" 같은 빈 형용사.

무엇이 어떻게 다른지를 적습니다.

  • ·"~에 대한" 겹치기. 개발에 대한 계약 이 아니라 개발 계약.
  • ·"진행하다" 로 모든 동사 대체. 검토를 진행합니다 가 아니라 검토합니다.
  • ·"부분" · "측면" · "관련하여" 로 문장 늘리기. 일정 측면에서는 이 아니라 일정은.
  • ·"보다 나은" · "보다 빠른". 비교 대상이 없으면 도 빼고 그냥 씁니다.
  • ·첫 문장을 요약으로 시작하기. 본 문서는 ~에 대해 다룹니다 는 지웁니다. 제목이

이미 그 말을 했습니다.

  • ·마지막 문단의 다짐. 앞으로도 최선을 다하겠습니다 같은 맺음말은 쓰지 않습니다.

대신 상대가 할 일을 적습니다.

  • ·이모지와 과한 감탄. 대외 문서에는 없습니다.

문장을 줄이는 법

한 문장에 주어 하나, 동사 하나. 수식을 두 개 이상 달지 않습니다.

숫자가 있으면 형용사를 지웁니다 — 상당한 개선 이 아니라 23% 단축.

문체 전반

합쇼체로 씁니다. 특정한 읽는 사람에게 씁니다. 틀렸던 것은 틀렸다고 적습니다

("v0.1 의 추정치는 틀렸습니다").

한 문장은 소리 내어 한 번에 말할 수 있는 길이로 하고, 길이를 섞습니다.

계약서와 NDA

조항을 지어내지 않습니다. 법무 검토를 거친 정본 문안을 받아 넣고, 당사자·기간·금액·

범위 같은 변수만 채웁니다. 그럴듯한 조항은 도움이 아니라 사고입니다.

에이전트는 get_design_rules 로 이 글을 그대로 받습니다.