name: korean-report-style description: Korean-language conventions for technical reports, progress updates, meeting agendas, software handoffs, architecture documents, runbooks, API references, model evaluations, and consortium deliverables — content selection, prose register, framing of shortfalls and risks, terminology accuracy, and structural integrity after edits. Use this whenever writing or revising any Korean document intended for colleagues, partners, clients, or evaluators — 진행현황, 중간보고, 기술보고, 연구노트, 코드베이스 인수인계, 운영 문서, 협의 아젠다, 회의록, 제안서 — and also when the user asks to soften, reframe, tighten, or "말투를 바꿔달라" on Korean text. Apply it even for internal-only documents; the register rules are not about audience politeness but about the document reading as a report rather than as speech. metadata: version: "1.0.1"

한국어 보고 문서 문체

기술·사업 문서의 한국어 서술 규약. 시각 디자인 규약(색·타이포·도해)과 제작 절차는 korean-report-doc 스킬이 담당하며, 이 스킬의 범위는 정보 선택·문장·framing에 한정한다.

표현을 다듬기 전에 §1.6에 따라 문서 목적과 독자에게 필요한 정보를 선정한다.

원칙 하나로 요약하면 이렇다. 문서는 말이 아니라 기록이다. 말할 때 자연스러운 표현이 문서에서는 대개 어긋난다.

예시는 가상 사례 「A사 — 인라인 계측 체계 확립과 수율 개선」에서 가져왔다. 도메인은 예시일 뿐이고 규칙 자체는 분야를 가리지 않는다.

1. 문체

1.1 제목은 명사구

서술형 제목은 논평처럼 읽히고 문서 개정 시 낡는다. 제목은 주제를 지시하고, 주장은 본문이 한다.

한정이 필요하면 줄표를 쓴다 — 오버레이 — 핵심이자 약점, 상한 2.5 nm와 고객 규격의 여유.

~하는 방법·~하는 과정·~하는 이유·~할 때·~할 것·~하기처럼 관형절이나 동작 명사화로 종결되는 제목도 간결한 명사구로 교정한다. 이미 명사구인 처리 방법·저장 과정·운영 시·확인 사항은 유지한다.

예외: 도해(SVG) 안의 제목은 그림이 말하는 주장이므로 문장이어도 된다.

1.2 구어체 환언 금지

기술적 사실을 일상어로 바꾸면 그 사실이 곁말처럼 읽힌다.

1.3 의인화·물리 은유 금지

주어가 사람이나 사물이 아니면 동사도 그것의 것이 아니어야 한다. 분야 표준 비유라도 서술 문체와 충돌한다.

판정법 — 주어를 사람이나 물건으로 바꿔 본다. 그 자리에서 자연스러우면 전용된 비유다.

• 로트가 흐른다 → "물이 흐른다"의 전용 → 물리 은유
• 문서가 다룬다 → "사람이 사안을 다룬다"의 전용 → 약한 의인화
• 다이가 죽는다 → "사람이 죽는다"의 전용 → 의인화

단, 용어는 원형을 유지한다. 킬러 디펙트 · 뉴슨스 · 드리프트 · 빈닝은 비유가 아니라 이름이며, 번역하면 정밀도가 떨어진다. 판정법을 적용하기 전에 그 말이 개념의 이름인지 서술인지를 먼저 가른다.

코드베이스 인수인계에서는 graph가 살아 있다·prompt와 condition이 싸운다처럼 영문 식별자와 한국어 은유가 결합하는 경우가 많다. bare verb를 전역 규칙으로 만들지 않고 주어와 술어가 결합된 표현만 선택적으로 검토한다. 상세 기준과 사례는 references/software-handoff.md를 참조한다.

그래서 다음 한 줄이 두 규칙의 경계를 보여준다 — 이름은 남기고 서술만 수정한다.

<!-- style-teaching -->

1.4 어미는 문어체

도해 라벨과 표 셀에도 동일하게 적용한다.

검증된 활용형만 치환하고, 돼·됐을 단독으로 전역 치환하지 않는다. 인용문·코드 블록· inline code·교육용 표는 제외한다. 남의 말을 옮긴 자리까지 문어체로 바꾸면 인용이 아니게 된다.

한 문서에서 평서체와 합니다체를 섞지 않는다. 둘은 독자와의 거리가 다르므로 혼용하면 문서가 초안처럼 읽힌다. 문서 본문은 평서체로 쓰고, 송부 메일·요청문은 합니다체로 분리한다.

✗ 검사 레시피가 확정됐습니다. 로트가 들어오면 빈닝이 돌아간다.

✓ 검사 레시피를 확정하였다. 로트가 투입되면 빈닝이 수행된다.

한 문서 안에 두 체가 필요하면 문서와 커버레터를 분리한다.

README · 문서 카탈로그 · 저장소 문서는 평서체다. 대외 안내로 보이지만 읽는 사람이 결정을 내리기 위해 참조하는 문서이며, 같은 저장소의 다른 문서와 어체가 달라지면 안 된다. 안내 문서가 규약과 다른 어체를 쓰면 규약을 스스로 부정하는 것이 된다.

1.5 번역투 제거

1.6 독자에게 필요한 정보의 선택

정보를 구체화하기 전에 포함할 필요를 판단한다. 문서 목적과 독자의 이해·판단·행동에 필요한 내용을 선정한다. 사실이거나 구체적이라는 이유만으로 포함하지 않는다.

• 관련성 — 작성 과정, 수행하지 않은 검사, 예상 가능한 예외를 일괄 추가하지 않는다.

검증 보고에서 미실시 검사는 보고 대상이지만, 검사 절차서에 같은 목록이 필요한 것은 아니다.

• 주장의 범위 — 조건·한계를 생략하면 실제 주장의 의미·범위·사용 조건을 잘못 이해하는

경우에 명시한다. 남길 주장의 불확실성을 보존하는 것과 모든 미확인 사항을 수록하는 것은 다르다.

• 필요한 구체성 — 남길 내용에서 필요한 관계·행동·조건만 구체화한다. 공통 전제는 한 번

제시한다. 불필요한 문구를 구체적인 결함 목록이나 부록으로 대체하지 않고 삭제한다.

제목·요청에서 이미 전달한 전제, 주장하지 않은 내용의 부정, 작성 범위의 반복도 중복이다. 문서의 성격·용도·구성을 설명하는 문장은 독자의 이해에 필요한 경우에만 포함한다.

1.7 과장·위협 표현 금지

소요와 위험은 사실로 적고, 압박으로 적지 않는다.

1.8 어휘 선택 — 정밀도 기준

쉬운 말이 기준이 아니라 정밀도가 기준이다. 한자어와 영문은 격식을 위해서가 아니라 의미역을 좁히기 위해 쓴다. 정밀도가 향상되지 않으면 쓰지 않는다.

광의 고유어를 협의 한자어로

고유어 동사는 의미역이 넓어 계약·규격 문서에서 해석이 분기한다.

판정법 — 그 동사에 목적어를 바꿔 끼워 본다. 서로 다른 종류의 목적어가 모두 자연스러우면 의미역이 넓은 것이므로 협의어로 대체한다.

• 넘긴다 → 데이터를 / 업무를 / 권한을 넘긴다 → 전부 성립 → 전달 · 이관 · 위임으로 분리 <!-- style-exempt -->
• 늘다 → 정밀도가 / 비용이 / 기간이 늘다 → 전부 성립 → 향상 · 증가 · 연장으로 분리
• 갈린다 → 해석이 / 승패가 / 길이 갈린다 → 전부 성립 → 분기 · 결정 · 분리로 분리 <!-- style-exempt -->

아래 표는 자주 나타나는 예시이며 목록이 아니다. 표에 없는 동사도 판정법으로 검사한다.

교정안도 이 표를 통과해야 한다. 다른 절에서 제시한 「쓴다」 쪽 문장에 광의 고유어가 남아 있으면 규칙이 자기모순이 된다.

이관과 전달을 함께 「넘긴다」로 적으면 책임 범위가 무너진다.

업무분장 문서에서 「이관」과 「추가 수행」의 구분이 쟁점이 되는 일이 실제로 있다.

표기 층위

enum 값과 필드명은 번역하지 않는다. SUCCESS를 「성공」으로 적으면 코드와 문서가 어긋난다. 규격·API에 등장하는 말은 한글 음차보다 영문 표기를 쓴다. 원어와 1:1로 대응해야 검색·대조가 된다.

단, 분야에 정착한 개념어는 한글 음차를 유지한다. 드리프트 · 뉴슨스 · 빈닝은 규격상의 이름이 아니므로 영문으로 되돌리면 읽기 비용만 증가한다. 판정 기준은 코드·API 문서에 같은 철자로 존재하는가이다.

조직이 영문 표기 정책을 쓰면 그 정책이 우선한다. 영어에서 온 낱말을 전부 영문으로 표기하는 조직은 저장소나 문서 폴더에 .krstyle.toml 을 배치하고 다음을 지정한다. 검사기는 문서 위치에서 위로 올라가며 처음 만나는 설정을 읽고, references/loanwords.md 의 음차를 표기 갈래로 보고한다.

[lint]
loanwords = "english"   # 기본값은 "keep"

정밀도 없는 격식체는 제거

한 문장에 영문과 한자어를 겹쳐 쌓지 않는다. 밀도가 아니라 탁도가 상승한다.

✗ 검사 endpoint의 payload를 canonical ID로 정합 후 전달 요망

✓ 검사 endpoint의 payload를 표준 ID 기준으로 정합한 뒤 전달한다

조직 내부에서 굳어진 용어는 그대로 두되, 외부 문서에서는 처음 등장할 때 한 번 풀어 쓴다.

2. 프레이밍

2.1 결함 서사를 역량 서사로

개선 결과를 보고할 때 같은 사실이라도 주어가 '결함'이면 사고 보고서처럼 읽힌다. 주어를 '측정 역량'으로 옮기면 사실을 삭제하지 않으면서 성격이 바뀐다. 결함 분석·검증 보고에서는 결함과 미확인 사항 자체가 보고 대상이므로 그대로 명시한다.

✗ 2.2 계측이 드러낸 결함 넷

✓ 2.2 구조적 개선 — 인라인 계측 체계 확립과 수율 향상

2.2 결과 우선 구조

성과 항목은 확인된 결과로 시작하고 배경은 후행 배치한다. 배경이 선행하면 문제 서술이 되고, 결과가 선행하면 성과 서술이 된다.

#### ① 검사–빈닝 기준 연결 — 검출률과 계측 시간을 동시에 개선
📊 결과 · 유효 검출률 4/7 → 5/7 · 웨이퍼당 계측 ~900 → ~590초
 
(그 다음에 배경과 원인)

2.3 위험과 대응

§1.6에 따라 필요한 위험을 선정하고, 확정된 대응이 있으면 함께 기재한다. 대응이 없어도 사용 조건이나 의사결정에 영향을 주는 위험은 명시한다. 대응이 정해진 것처럼 서술하거나, 항목을 채우기 위해 위험과 대응을 추가하지 않는다.

2.4 상대의 요청을 기점으로

협의 문서가 우리 이야기로 시작하면 통보가 된다. 상대의 요청·질문을 먼저 두고 그에 대한 응답으로 구성한다. 고객사에 보내는 품질 보고라면 고객이 제기한 항목이 먼저 오고 우리 분석이 뒤에 온다. 단, 요청자를 명시하는 것이 부담이 되는 경우에는 「아젠다」처럼 중립 표제로 두고 내용만 남긴다.

2.5 협의안과 산정 근거

"정해 주십시오"는 상대에게 판단 근거 없이 결정을 위임하는 것이다. 우리 판단과 그 산정 근거를 먼저 제시하고 조정을 요청한다.

✗ 계측 대상 로트와 회차를 확정해 주십시오.

✓ 계측 가능 범위(안) — 대상 로트·회차와 각각의 산정 근거. 여건에 따라 조정 요청.

3. 정확성

3.1 상태 표기

추정을 실측처럼 쓰지 않는다. 측정·구현 상태가 주장의 해석에 영향을 주면 해당 상태를 주장이 있는 자리에 명시한다(범례에만 배치하지 않는다). 문장에 상태가 분명하면 별도 표기를 반복하지 않는다. 상태를 채우려고 문서 목적과 무관한 미측정 항목을 추가하지 않는다.

가운데 단계의 이름은 분야에 따라 정한다 — 계측 문서라면 레시피 보유, 소프트웨어라면 구현됨이 읽힌다. 세 단계라는 구조는 바꾸지 않는다.

3.2 사업 문서와의 용어 정합

같은 말이 사업 문서와 다른 시점을 지시하면 오해가 발생한다. 공정 기준 문서·고객 합의서의 용례를 먼저 확인하고 문서 전체에서 일관되게 쓴다.

예 — 합의서상 「양산」은 인증 통과 이후를 지시하는데 문서에서 파일럿 라인 작업을

「양산」이라 부르면 충돌한다. 파일럿 구간은 「양산 준비」 또는 「양산 검증」으로 적는다.

3.3 논란 가능 내용의 근거 확인

기한·의무·책임이 걸린 서술은 어느 문서 몇 조에 있는지 확인하고 인용한다. 확인되지 않거나 분쟁 소지가 있으면 문서에서 제외한다.

3.4 기준이 바뀌면 명시적으로 고지

이전에 공유한 수치와 산출 기준이 달라졌다면, 수치가 개선되었더라도 기준 변경 사실을 별도로 명시한다. 후속 비교에서 혼선을 방지한다.

예 — 수율을 양산 조건 기준으로 재산출하였다면, 이전 공유분과 조건이 다르다는 사실을

수치 옆에 명시한다. 수치만 갱신하면 개선폭이 과장되어 전달된다.

4. 편집 후 정합성

항목을 삭제하면 문서 전체가 어긋난다. 삭제·삽입 후 반드시 아래를 확인한다.

• [ ] 번호 재정렬 — 리스크 S1~Sn · T1~Tn, 그림, 표, 절 번호가 연속하는가
• [ ] 참조 갱신 — 본문의 「§5.1 S3」, 「그림 8」, 「§4.1」이 실재하는 대상을 가리키는가
• [ ] 요약문 정합 — "S1과 S4가 나머지를 지배한다" 같은 문장이 삭제된 항목을 참조하지 않는가
• [ ] 중복 제거 — 같은 내용이 도해 라벨과 캡션, 두 절에 동시에 있지 않은가
• [ ] 열 정합 — 표의 한 열을 비웠다면 그 열의 존재 이유가 남아 있는가
• [ ] 미사용 정의 — 삭제로 쓰이지 않게 된 도해·표 정의가 남아 있지 않은가

5. 표기 세부

• 작성자 — 팀명보다 개인명. A사 · 홍길동
• 파일명 — YYMMDD_사업명_문서종류. 한글 파일명은 인코딩 문제가 없는 환경에서만
• 마감 — 문서 끝에 EOD. 인사말·회사명·로고를 붙이지 않는다

6. 적용 절차

1. 정보를 선정한 뒤 초안을 쓴다. §1.6에 따라 포함할 내용을 정하고 내용 위주로 작성한다.

문체 교정을 하며 쓰면 논지가 흐려진다.

1. 검사기를 돌린다. 손으로 훑지 않는다 — 사람도 모델도 자기 문장은 못 본다.

``bash python <스킬경로>/assets/lint.py 초안.md # 걸린 곳을 줄·열로 낸다 python <스킬경로>/assets/lint.py 초안.md --fix # 어미만 자동으로 고친다 python <스킬경로>/assets/lint.py 산출물.html # HTML typesetting 후에도 한 번 더 python <스킬경로>/assets/lint.py 초안.md --heuristic # software 표현 검토 python <스킬경로>/assets/lint.py 초안.md --format github # CI annotation python <스킬경로>/assets/lint.py 초안.md --format sarif # SARIF 2.1.0 ``

출력이 여덟 갈래로 구분된다.

--json은 기존 형식을 유지하면서 summary.total·by_tier·by_file·by_rule을 함께 출력한다. 일반 Markdown 표도 검사한다. 규칙을 설명하는 표는 알려진 교육용 헤더를 쓰거나 바로 앞에 <!-- style-teaching -->을 둔다.

영문 인용 바로 뒤 괄호 안의 번역은 원문을 따른 표현이므로 검사하지 않는다. 작업 경위(HTTP 503 반환 · rate limit · 도구 실패)를 서술한 문장은 --heuristic 이 보고한다.

필요한 정보를 삭제하여 검사기를 피하지 않는다. 관련성이 없는 내용의 삭제는 §1.6을 따른다. 인용이 꼭 필요한 자리는 백틱·「」로 감싸거나 줄 끝에 <!-- style-exempt --> 를 단다.

종료 코드가 0 이 아니면 아직 완료되지 않은 것이다. 0 은 통과, 1 은 위반, 2 는 입력 오류, 3 은 위반은 없으나 일부 검사를 수행하지 못한 상태다. 형태 갈래에는 kiwipiepy 가 필요하며, 설치되어 있지 않으면 검사기는 3 을 반환하고 결과 본문에 미수행 사실을 기록한다. 의도적으로 생략할 때만 --no-morph 를 지정한다. 검토 갈래를 남겨 둔 채 문서를 내밀 때는 무엇을 왜 남겼는지 사용자에게 말한다.

1. 판정 적용 — 치환표에 없는 표현은 원리로 판정한다.

• §1.3 주어를 사람·물건으로 바꿔 자연스러우면 은유다
• §1.4 문서 전체가 한 어체인지 확인한다
• §1.8 그 동사에 목적어를 바꿔 끼워 의미역이 넓은지 확인한다

1. §2 프레이밍을 절 단위로 검토한다. 제목의 주어가 무엇인지 확인한다.
2. §3 정확성 — 상태 표기, 용어 정합, 근거 확인.
3. §4 체크리스트를 돌린다. 편집을 여러 번 하였다면 매번 돌린다.

번호 재정렬과 참조 갱신은 검사기로 확인한다.

``bash python <스킬경로>/assets/structure.py 초안.md # 절·청구항·그림·표 번호와 참조 python <스킬경로>/assets/parity.py 초안.ko.md 초안.en.md # 국문·영문 두 벌의 수치·구조 대응 ``

structure.py는 한 차례의 편집을 마칠 때마다 돌린다. 다른 문서의 절을 가리키는 참조는 같은 문장 앞에 경로나 링크를 명시하거나 줄 끝에 <!-- structure-exempt --> 를 단다. 문서 이름만으로 지시한 외부 참조는 검사기가 판정하지 못한다. parity.py는 국문과 영문을 함께 관리하는 문서에 쓴다. 두 자리 이상 수치와 출현 횟수, 수준별 제목 수, 표 수, 청구항 번호를 대조하여 하나라도 어긋나면 종료 코드 1을 반환한다.

치환표는 예시이지 목록이 아니다. 검사기가 통과시켜도 통과가 아니다. 검사기는 표에 적힌 형태만 찾는다 — 표에 없는 같은 종류의 표현은 3의 판정으로 검출한다.

검사 범위는 문서 전체다. 본문 산문만 확인하면 아래가 누락된다.

• [ ] 절 제목 — §1.1 명사구 여부. 서술형 제목이 가장 자주 남는다
• [ ] 표의 좌·우변 — 교정안(우변)도 §1.8을 통과해야 한다
• [ ] 도해 라벨 · 캡션 · 표 셀 — §1.4 어미가 여기에서 자주 어긋난다
• [ ] 본문 산문 — 규칙을 서술하는 문장 자신이 규칙을 위반하는 경우가 있다

치환 목록 전체는 references/substitutions.md 참조. 각 규칙의 검사 범위는 prose·heading·table·html·all 중 하나 이상이며, 검출 방식은 literal 또는 regex다. 두 열만 있는 기존 표는 all·literal로 읽는다.

7. 판단이 필요한 지점

기계적으로 적용하면 안 되는 경우가 있다. 다음의 의미나 범위가 문맥으로 판단되지 않을 때 사용자에게 확인한다.

• 정정 고지 — 톤을 부드럽게 하더라도 사실 자체는 남겨야 하는 경우가 있다.

이전 공유 수치의 정정, 기준 변경 고지가 그렇다.

• 한계 서술 — 삭제 후 남는 주장이 검증 범위를 초과하는지 확인한다. 조건이 필요하면 해당

주장에 함께 명시하거나 주장을 확인된 범위로 한정한다. 포함 여부는 §1.6에 따라 판단한다.

• 조직 내부 용어 — 레포·현장에 굳어진 말(골든 웨이퍼, 핫 로트)은 임의로 바꾸지 않는다.
• 쉬운 말과 정밀한 말이 충돌할 때 — 외부 문서라도 의미역이 분기하는 자리에서는

한자어를 유지하고 처음 등장할 때 한 번 풀어 쓴다. 쉽게 바꾸다 계약 의미가 넓어지는 편이 더 위험하다.

• 삭제의 연쇄 — 한 항목을 삭제하면 다른 항목이 중복되거나 무의미해지는 경우가 있다.

발견하면 알리고 함께 정리할지 묻는다.