---
name: korean-writing
description: >
  사용자를 대신해 한국어 사내 커뮤니케이션 글을 쓰거나 남이 쓴 초안을 다듬을 때
  로드한다. 메신저·메일·결재 요청·보고 멘트에 맞는 존댓말과 완충 표현을 고르고,
  요청·거절·사과처럼 관계가 걸린 말을 바로 보낼 수 있는 문장으로 만든다. 이미 써진
  긴 글의 AI 티만 빼 달라는 요청은 korean-humanize 가, PR 본문·커밋 메시지·이슈처럼
개발 산출물에 나가는 산문은 engineering-writing 이 맡는다.
---

# 한국어 사내 글쓰기

한국 회사에서 실제로 오가는 말투로 쓴다. 문법적으로 맞는 문장이 아니라, 받는
사람이 기분 상하지 않고 읽어서 바로 행동할 수 있는 문장이 목표다. 구두로
말할 원고(보고 멘트, 회의 발언)도 같은 지침으로 만든다.

## 반드시 지킬 것

- **사용자가 주지 않은 사실을 만들지 않는다.** 금액, 날짜, 결재선, 담당자
  이름은 받은 것만 쓴다. 없으면 `[금액]`처럼 자리표시자로 남기고 무엇이 더
  필요한지 초안 아래 한 줄로 알린다.
- **초안을 다듬을 때 사실관계와 요청 범위를 바꾸지 않는다.** 문체만 고친다.
  원문이 "검토 부탁"이면 "승인 부탁"으로 올리지 않는다.

## 기본 문체는 합니다체

메신저든 메일이든 **합니다체가 기본값**이다. 짧은 메신저 한 줄이라고 해서
말을 낮추지 않는다.

| 어디에 | 누구에게 | 문체 |
|---|---|---|
| 사내 메신저 (채널·DM) | 동료, 타팀 | 합니다체 |
| 사내 메신저 | 상급자, 임원 | 합니다체 |
| 메일 | 사내 | 합니다체, 인사 한 줄 |
| 메일 | 대외·고객사 | 합니다체, 격식 한 단계 위 |
| 결재·기안 문서 | 결재선 | 합니다체 |
| 구두 보고·회의 발언 | 상급자, 참석자 | 합니다체, 한 문장 40자 이내 |
| 회의록, 기술 문서 | 팀 내부 | 개조식 — 문서 관례 우선 |

**사용자가 기존 메시지나 조직 문서를 보여줬으면 그 톤이 이 표를 이긴다.**
팀이 이미 해요체로 대화하고 있으면 거기 맞춘다. 영어 이름을 쓰는지, 직급을
붙이는지, 이모지를 쓰는지도 거기서 가져온다. 근거 없이 해요체를 기본으로
고르지는 않는다.

### 해요체는 완화용으로만

`~같아요`, `~해요` 같은 해요체 어미는 **공감하거나 반대 의견을 부드럽게 만드는
한두 문장**에만 섞는다. 합니다체 기조 안에서 그 대목만 힘을 빼는 장치다.

> 맞습니다, 말씀하신 대로 어려운 점이 있을 것 같아요.

> 좋은 의견이신데, 추가적으로 이런 부분도 참고해 보면 좋을 것 같아요.

문단 전체가 두 문체 사이를 오락가락하면 안 된다. 기조는 하나로 유지한다.

## 존댓말

- **사물에는 존칭을 붙이지 않는다.** "금액이 100만 원이십니다" → "금액은
  100만 원입니다". "회의가 있으십니다" → "회의가 있으세요"(주체는 사람).
- **이중 경어를 피한다.** "말씀이 계셨습니다" → "말씀하셨습니다".
- **압존법은 쓰지 않는다.** 임원 앞에서도 팀장은 팀장님이다.
- 윗사람에게 "수고하세요"는 쓰지 않는다. "고생 많으셨습니다", "감사합니다"로.

## 완충 표현은 어디에 쓰는가

`혹시`, `가능하시다면`, `~할 것 같습니다` 같은 완충 표현은 군더더기가 아니라
**상대에게 부담을 주는 말을 부드럽게 만드는 장치**다. 발화 유형에 따라 쓴다.

| 무슨 말인가 | 완충 |
|---|---|
| 요청, 거절, 반대 의견, 지적 | **필요하다** — 상대에게 부담이 가는 말이다 |
| 제안, 협의 | 가볍게 — "~하시면 좋을 것 같습니다" |
| 보고, 공지, 사실 전달 | **불필요하다** — 단정형으로 쓴다 |
| 내가 결정권자로서 내리는 지시 | 최소한만 — 완충이 과하면 지시가 흐려진다 |

**완충은 한 겹만 쓴다.** "바쁘신데 죄송하지만 혹시 가능하시다면 확인 부탁드려도
될까요?"는 겹쳐서 오히려 읽는 사람을 불편하게 한다. 하나만 고른다.

### 요청 어미 사다리

부담의 크기에 맞춰 올린다. 작은 부탁에 가장 정중한 형태를 쓰면 과하다.

- 동료·수평: "~ 부탁드립니다", "확인해 보겠습니다"
- 타팀·상급자: "~ 부탁드리겠습니다", "혹시 ~해 주실 수 있으실까요?"
- 부담이 큰 요청·대외: "혹시 가능하시다면 ~ 부탁드려도 될까요?"
- 의견을 구할 때: "어떻게 생각하시는지 여쭤봐도 될까요?"
- 제안할 때: "~하시면 좋을 것 같습니다", "~해 볼 수 있을까요?"

## 두괄식

**결론을 먼저, 근거는 그다음.** 메신저·메일·보고 전부 같다.

> 결제 실패율은 어제 0.4%로 내려왔습니다. 커넥션 풀을 두 배로 늘린 것이
> 직접적인 원인이었습니다. 이번 주 안에 자동 확장으로 바꾸겠습니다.

결론 → 근거 → 다음 계획. 조사 과정을 시간순으로 나열하지 않는다.

## 사내 메신저

- 한 메시지에 한 용건. 3~5줄 안에 끝내고, 넘치면 스레드로 잇는다.
- **엔터로 나눠 보내지 않는다.** 한 번에 한 메시지로 보낸다.
- 질문은 답하기 쉽게 만든다 — 예/아니오나 선택지로. 열린 질문은 답이 늦다.
- **언제까지 필요한지 반드시 적는다.** 기한 없는 요청은 우선순위가 없다.
- 답이 없을 때 어떻게 할지 미리 적으면 회신이 빨라진다 — "금요일까지 의견
  없으면 A안으로 진행하겠습니다".
- 멘션은 지금 행동해야 할 사람에게만. `@here`·`@channel`은 지연이 실제
  피해로 이어질 때만 쓴다.
- 이모지는 의미를 보탤 때만 한두 개. 모든 줄에 붙이지 않는다.

**고치기 전**

> 안녕하세요! 바쁘신데 죄송합니다 ㅠㅠ 다름이 아니라 저번에 말씀드렸던 로그
> 수집 관련 건에 대해서 혹시 확인이 가능하실지 여쭤보고자 연락드렸습니다.
> 확인 부탁드리면 감사하겠습니다!

**고친 뒤**

> 로그 수집 설정 변경 PR 리뷰 부탁드립니다. (링크)
> 스테이징에서 하루 돌렸고 유실은 없었습니다.
> 목요일 배포에 넣으려면 수요일 오전까지 리뷰가 필요합니다.

서론 세 줄이 사라지고 완충은 "부탁드립니다" 한 겹만 남았다. 기한이 생겨서
받는 사람이 바로 판단할 수 있다.

## 거절·반대 의견

**인정 → 근거 → 대안** 세 단으로 쓴다. 어느 하나도 빼지 않는다.

1. **인정** — 상대 안의 *어떤 점이* 맞는지 구체적으로. "좋은 의견이신데"만
   붙이고 반대하면 형식적으로 읽혀서 안 하느니만 못하다.
2. **근거** — 왜 어려운지 사실로. 감정이나 관례가 아니라 확인된 것으로.
3. **대안** — 대신 무엇을 할 수 있는지, 또는 조건이 어떻게 바뀌면 가능한지.
   대안 없는 거절은 상대에게 숙제를 떠넘기는 것이다.

**반대 의견**

> 캐시 계층을 먼저 넣자는 방향에는 저도 동의합니다. 다만 지금 병목은 캐시
> 미스가 아니라 커넥션 풀이라서, 캐시를 넣어도 p99는 그대로일 것 같습니다.
> 풀 사이즈를 먼저 조정해 보고 그다음에 캐시를 보면 어떨까요?

**일정 거절**

> 이번 주 안에는 어려울 것 같습니다. 지금 결제 장애 대응이 우선이라서요.
> 다음 주 화요일까지면 가능한데, 일정 조정이 어려우시면 다른 방법을 같이
> 찾아보겠습니다.

거절에서는 "어렵습니다"보다 "어려울 것 같습니다"가 자연스럽다. 여기가 완충이
제 역할을 하는 자리다.

## 감사와 사과

**빨리, 한 번, 구체적으로.** 미루면 어색해지고, 반복하면 내용이 사라진다.

- **감사** — 무엇 덕분에 무엇이 됐는지 적는다. 그래야 빈말로 안 읽힌다.
  > 어제 로그 확인해 주신 덕분에 원인을 하루 만에 찾았습니다. 감사드립니다.
- **사과** — 사과 한 번 → 무슨 일이었는지 → 지금 조치 → 재발 방지. 이 순서다.
  > 혼선 드려 죄송합니다. 배포 시간을 잘못 공지했습니다. 정정 공지는 방금
  > 올렸고, 다음부터는 공지 전에 배포 채널과 시간을 대조하도록 하겠습니다.
- 사과에 변명을 섞지 않는다. 원인 설명은 필요하지만 "~때문에 어쩔 수 없었다"로
  끝나면 사과가 아니게 된다.
- 사과를 두 번 이상 반복하지 않는다. 한 번 하고 대응으로 넘어간다.

## 결재·승인 요청

### 상신 알림 (메신저)

네 가지를 한 문단에 담는다 — **무엇을 올렸는지, 왜 필요한지, 얼마·언제까지,
언제 승인이 필요한지**.

> 데이터독 연간 계약 갱신 건 결재 올렸습니다. (링크)
> 금액은 작년과 같은 1,200만 원이고, 8월 20일에 만료되어 그 전에 갱신되어야
> 알림이 끊기지 않습니다.
> 8월 14일까지 승인 부탁드리겠습니다.

### 기안문 본문

```markdown
제목: [무엇에 대한 무슨 결재인지 — 한 줄]

## 요청 사항
[승인받으려는 것 한 문장. 금액·기간·범위를 숫자로.]

## 배경
[왜 지금 필요한지. 안 하면 무엇이 문제인지.]

## 세부 내역
- 금액: [산출 근거까지]
- 기간: [시작 ~ 종료]
- 범위: [포함되는 것과 빠지는 것]

## 검토한 대안
[다른 선택지와 이것을 고른 이유. 없으면 생략합니다.]

## 리스크
[예상되는 문제와 대응 방안]

## 처리 기한
[언제까지 승인되어야 하고, 늦으면 무엇이 어긋나는지]
```

- 결재선과 참조자는 조직마다 다르다. 사용자가 알려준 경우에만 적는다.
- 금액에는 근거를 붙인다. 숫자만 있으면 결재자가 되묻는다.
- **기안문에는 완충을 쓰지 않는다.** "필요하다고 판단됩니다" → "필요합니다".
  요청하는 문서다.

### 리마인드와 반려 대응

- 재촉이 아니라 **기한 근거**로 다시 알린다.
  > 어제 올린 계약 갱신 건 다시 안내드립니다. 14일까지 승인되지 않으면 20일에
  > 알림이 끊깁니다. 오늘 중 확인 가능하실까요?
- 반려되면 변명하지 않는다. **무엇을 어떻게 고쳐서 다시 올릴지**만 쓴다.
- 조건부로 진행해야 하면 조건을 명시한다 — "선승인 후 계약서는 다음 주에
  첨부하는 방식으로 진행해도 될까요?"

## 메일

```
제목: [무엇에 대한 메일인지 — 요청이면 기한까지]

안녕하세요, ○○님. [소속] [이름]입니다.

[본론 한 문장 — 두괄식]

[세부 내용. 항목이 셋 이상이면 목록으로.]

[요청 사항과 기한 한 줄]

감사합니다.
[이름 / 소속]
```

- 제목에 요청과 기한을 넣으면 회신이 빨라진다 — `[요청] 9/12까지 계약서 검토
  부탁드립니다`.
- 인사는 한 줄이면 충분하다. "항상 많은 도움 주셔서 감사합니다"는 실제로 도움을
  받았을 때만 쓴다. 매번 붙이면 상투어로 읽힌다.
- 회신에서는 앞 메일 내용을 다시 요약하지 않는다. 달라진 것부터 쓴다.
  > 피드백 주신 부분을 반영해 수정했습니다. 다시 한번 확인 부탁드리겠습니다.
- 참조(CC)에 넣은 사람에게 무엇을 기대하는지 본문에 한 줄로 밝힌다.

## 구두 보고·회의 발언 원고

발음과 억양은 이 스킬이 다루지 않는다. 대신 **말하기 쉬운 문장**을 만든다.

- 한 문장 40자 안쪽. 한 호흡에 읽히지 않으면 끊는다.
- **첫마디를 정해 둔다.** "어…", "그…" 같은 채우는 말은 첫 문장이 준비되지
  않아서 나온다. 결론 한 문장을 미리 확정하면 사라진다.
- 어미를 단정형으로 쓴다. 확인한 것은 "~입니다". 모르는 것은 얼버무리지 말고
  "확인해서 오늘 중 말씀드리겠습니다"로 기한을 준다.
- 보고 기본형은 **결론 → 근거 → 다음 계획** 세 문장이다. 질문은 그 뒤에
  받는다.
- 의견을 낼 때는 단정과 여지를 함께 둔다.
  > 이 방향이 맞다고 봅니다. 다만 트래픽이 두 배가 되는 경우는 따로 검토해
  > 봐야 할 것 같습니다.

## 문장 다듬기

| 흔한 표현 | 대신 |
|---|---|
| ~하도록 하겠습니다 (일반 실행) | ~하겠습니다 |
| ~에 대해 확인 부탁드립니다 | ~ 확인 부탁드립니다 |
| ~를 통해 진행하겠습니다 | ~로 하겠습니다 |
| 확인이 필요한 부분이 있습니다 | 확인할 것이 있습니다 |
| 배포가 완료되어졌습니다 | 배포했습니다 |
| 이슈가 발생한 상황입니다 | 장애가 났습니다 |
| 관련하여 공유드립니다 | (빼고 바로 내용) |

사과와 재발 방지 약속에서는 "다음부터는 ~하도록 하겠습니다"가 자연스럽다.
완충이 필요한 자리라서 예외다.

### 모호한 말을 숫자로

| 모호 | 대신 |
|---|---|
| 대충 정리하면 | 간략히 정리하면 |
| 어느 정도 됐습니다 | 70%쯤 됐습니다 / 수치는 확인해서 말씀드리겠습니다 |
| 조금 늦을 것 같습니다 | 30분 정도 늦습니다 |
| 빠른 시일 내에 | 오늘 중 / 이번 주 안에 |
| 확인해 보겠습니다 (기한 없이) | 오늘 중 확인해서 공유드리겠습니다 |

- 명사를 늘어놓지 말고 동사로 푼다. "결제 실패 건수 증가 확인" →
  "결제 실패가 늘었습니다".
- "진행", "처리", "대응"은 무슨 일인지 감추는 말이다. 배포·정산·회신처럼
  구체적인 동사로 바꾼다.
- 한 문장에 쉼표가 셋 이상이면 끊는다.
- 영어 약어와 사내 용어는 그대로 두되, 받는 사람이 모를 수 있으면 처음
  나올 때 한 번 푼다.

### AI 티 나는 표현

AI가 쓴 메시지는 문법이 맞아도 받는 사람이 바로 알아본다. 아래는 사내 메시지·메일에서
특히 자주 나오는 것이다. 새로 쓸 때도, 초안을 다듬을 때도 이 표를 거른다.

| AI 티 | 대신 |
|---|---|
| "안녕하세요! 좋은 하루 보내고 계신가요?" 같은 인사 확장 | 인사는 한 줄, 느낌표 없이 |
| "궁금한 점 있으시면 언제든 말씀해 주세요", "도움이 되셨기를 바랍니다", "좋은 하루 되세요!" | 뺀다. 마무리는 "감사합니다" 한 줄 |
| "~하시면 됩니다", "~해 주시면 감사하겠습니다"를 문장마다 반복 | 요청 어미는 한 번만 |
| 3~5줄 메시지를 불릿·볼드·이모지로 꾸밈 | 문장으로 쓴다. 항목이 셋 이상일 때만 목록 |
| "단순히 A가 아니라 B입니다", "A를 넘어 B로" | B만 바로 말한다 |
| "~에 대해 확인 부탁드립니다", "~와 관련하여 공유드립니다", "~를 통해 진행" | "~ 확인 부탁드립니다", "~ 공유드립니다", "~로 진행" |
| "-고,", "-지만,", "-면서," 연결어미 뒤 쉼표 | 쉼표를 뺀다. 길면 문장을 나눈다 |
| "다양한", "효율적으로", "원활하게", "적절히" | 무엇을 어떻게 하는지 구체적으로 |
| "매우", "정말", "적극적으로", "신속하게" | 빼거나 수치·기한으로 |
| "결론적으로", "정리하자면", "다음과 같습니다" | 빼고 바로 본문 |
| 확인 안 된 것을 "~것으로 보입니다"로 얼버무림 | "확인 못 했습니다. 오늘 중 확인해서 말씀드리겠습니다" |

요청·거절에 쓰는 완충 한 겹은 예의다. 위 표는 그 완충 위에 얹히는 군더더기를
걷어 내는 것이다. 보고서·발표 원고처럼 긴 글의 AI 티를 빼 달라는 요청은 korean-humanize 를
로드한다 — 전체 패턴 목록은 그 스킬의 `ai-tell-catalog.md` 에 있다.

## 산출물 형식

- **완성된 본문만 코드 블록 없이 그대로 내놓는다.** 사용자가 복사해서 바로
  보낼 수 있어야 한다. 기안문·메일처럼 구조가 있는 문서만 마크다운 블록으로 준다.
- 본문 아래에 바꾼 이유를 두세 줄로만 붙인다. 문장별 해설은 하지 않는다.
- 채널이나 상대가 불분명하면 **가장 그럴듯한 쪽으로 하나를 쓰고**, 다른
  선택지가 있다는 걸 한 줄로 알린다. 초안 없이 되묻지 않는다.
- 길이나 격식 조정 요청("더 짧게", "더 정중하게")에는 새 버전만 다시 준다.

## 하지 않는 것

- 원문에 없는 열의나 사과를 채워 넣지 않는다.
- 완충을 겹쳐 쓰지 않는다. 정중함은 길이가 아니라 상대의 시간을 아끼는
  데서 나온다.
- 보고와 공지에 완충을 넣지 않는다. 사실을 흐리게 만든다.
- 같은 인사말을 문단마다 반복하지 않는다.
- 상대를 압박하는 표현("아직 확인 못 받았습니다", "몇 번째 요청입니다")을
  쓰지 않는다. 기한과 영향만 사실대로 적는다.