chore: snapshot working tree before harness removal

미추적 파일과 미커밋 수정을 전부 담아 pre-harness-removal 태그의 복구 범위를 확보한다. .agents/skills/writing-natural-korean 9개와 korean-technical-blog-skills-bundle-v1 61개가 여기 포함된다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 14:19:24 +09:00
parent b101b6e717
commit 1099834617
85 changed files with 8547 additions and 114 deletions
@@ -0,0 +1,83 @@
+# 자연스러운 한국어 글쓰기 스킬
+
+`writing-natural-korean`은 한국어 글을 새로 작성하거나 기존 글을 교정·윤문·재작성·검토할 때 사용하는 범용 스킬입니다. 기술 문서, 발표 스크립트, 일반 글·기술 블로그, 자기소개서·경력 문서, 업무 메일·메시지, 안내문을 요청 문맥에 따라 구분합니다.
+
+## 설계 원칙
+
+- 맞춤법·띄어쓰기·표준어·외래어 표기·문장 부호는 국립국어원의 공식 어문 규범을 기준으로 판단합니다.
+- 자연스러움은 강제 규범과 구분합니다. 피동 표현, `가지다`, `~에 대한`, `~를 통해` 같은 표현은 금칙어로 취급하지 않고 문맥에서 어색하거나 반복될 때만 다듬습니다.
+- 원문의 사실, 수치, 고유명사, 기술명, 인용, 책임 주체, 확신 정도를 보존합니다.
+- 사람처럼 보이게 하려고 일부러 오류나 불규칙성을 넣지 않습니다.
+- `단순히 A를 넘어 B`, `이를 통해`, `중요한 역할` 같은 상투 표현은 내용 없이 반복될 때 실제 동작·조건·결과로 바꿉니다.
+- 발표문과 기술 문서를 별도 스킬로 나누지 않고, 하나의 공통 한국어 기준 위에서 장르별 문체 프로필을 자동으로 선택합니다.
+
+## 구성
+
+```text
+writing-natural-korean/
+├── SKILL.md
+├── README.md
+├── references/
+│   ├── normative-foundation.md
+│   ├── editing-patterns.md
+│   └── genre-profiles.md
+└── evals/
+    ├── evals.json
+    └── trigger-cases.json
+```
+
+- `SKILL.md`: 활성 조건, 공통 원칙, 작업 모드, 실행 절차, 최종 검사
+- `references/normative-foundation.md`: 공식 근거와 조회 우선순위
+- `references/editing-patterns.md`: 번역투와 상투 표현을 문맥별로 판단하는 기준
+- `references/genre-profiles.md`: 기술 문서, 발표문 등 장르별 문체 기준
+- `evals/evals.json`: 의미 보존, 최소 교정, 번역투 윤문, 기술명 보호 등을 검증하는 12개 평가 사례
+- `evals/trigger-cases.json`: 자동 활성화 여부를 점검하는 사례
+
+## ChatGPT에 설치
+
+계정에서 스킬 기능을 사용할 수 있는 경우 다음 순서로 설치합니다.
+
+1. ChatGPT 사이드바에서 `플러그인`을 엽니다.
+2. `스킬` 탭에서 `만들기`를 선택합니다.
+3. `컴퓨터에서 업로드`를 선택합니다.
+4. `writing-natural-korean.zip`을 업로드하고 검사 결과를 확인합니다.
+5. 설치한 뒤 아래 시험 요청으로 동작을 확인합니다.
+
+ChatGPT의 화면 구성이나 워크스페이스 정책에 따라 메뉴 이름과 위치가 달라질 수 있습니다. 스킬 메뉴가 보이지 않으면 해당 계정 또는 워크스페이스에 기능이 열려 있는지 확인해야 합니다.
+
+## 사용 예시
+
+```text
+이 문장은 맞춤법과 띄어쓰기만 고쳐 줘. 문체는 유지해.
+```
+
+```text
+이 기술 설계 문서를 자연스러운 한국어로 윤문해 줘.
+사실, 수치, API 이름, 명령어는 바꾸지 마.
+```
+
+```text
+이 내용을 개발자 대상 30분 발표 스크립트로 바꿔 줘.
+슬라이드 문구를 그대로 읽지 말고 실제로 말하기 쉬운 문장으로 써 줘.
+```
+
+```text
+문장은 고치지 말고 번역투, 모호한 호응, AI식 상투 표현만 검토해 줘.
+```
+
+## 공식 근거
+
+조사 기준일은 2026년 8월 2일입니다. 상세 출처와 적용 범위는 `references/normative-foundation.md`에 정리되어 있습니다.
+
+- 국립국어원 한국어 어문 규범
+- 국립국어원 표준국어대사전
+- 국립국어원 《쉬운 공문서 쓰기 길잡이》
+- 국립국어원 《한눈에 알아보는 공공언어 바로 쓰기》
+- 국립국어원 《공공언어 요건 정립 및 진단 기준 개발 연구》
+- 국립국어원 《새국어생활》의 번역문·번역투 연구
+- Agent Skills 공개 규격: https://agentskills.io/specification
+- ChatGPT 스킬 안내: https://help.openai.com/ko-kr/articles/20001066-skills-in-chatgpt
+
+## 평가 범위
+
+이 패키지는 구조, 메타데이터, 내부 파일 참조, JSON 구문, 압축 파일 무결성을 정적 검사할 수 있습니다. 실제 문체 품질은 모델과 실행 환경의 영향을 받으므로 설치 후 `evals/evals.json`의 사례를 이용해 별도로 확인하는 것이 좋습니다.
@@ -0,0 +1,161 @@
+---
+name: writing-natural-korean
+description: >-
+  Use when 사용자가 한국어 글을 새로 작성하거나, 교정·윤문·재작성·검토해 달라고 할 때. 맞춤법, 띄어쓰기, 번역투, AI식 상투 표현, 기술 문서, 발표 스크립트, 블로그, 자기소개서, 업무 메일을 자연스러운 한국어로 다루되 원문의 사실과 작성자 말투를 보존해야 하는 경우.
+compatibility: "ChatGPT Skills 및 Agent Skills 호환 환경. 외부 실행 도구가 필요하지 않음."
+metadata:
+  version: "0.1.0"
+  language: "ko-KR"
+  basis: "국립국어원 한국어 어문 규범·공공언어 자료·번역투 연구"
+---
+
+# 자연스러운 한국어 글쓰기
+
+## 목표
+
+독자, 매체, 목적에 맞는 자연스러운 한국어로 쓴다. 맞춤법과 띄어쓰기는 공식 규범에 따르되 문체를 하나로 획일화하지 않는다. 원문의 사실, 논리, 용어, 태도, 작성자 목소리를 보존하면서 어색한 번역투와 내용 없는 상투 표현을 줄인다.
+
+사람처럼 보이게 하려고 일부러 오류, 군더더기, 불규칙성을 넣지 않는다. 이 스킬의 목표는 AI를 위장하는 것이 아니라 정확하고 실제로 읽히는 한국어를 쓰는 것이다.
+
+## 우선순위
+
+판단이 충돌하면 다음 순서를 따른다.
+
+1. 사용자의 명시적 요구와 제공한 사실
+2. 원문의 주장, 수치, 고유명사, 인용, 책임 주체, 확신 정도
+3. 독자와 글의 목적
+4. 한국어 어문 규범
+5. 자연스러운 문장과 읽기 흐름
+6. 표현상의 세련됨
+
+자연스럽게 보이기 위해 사실을 추가하거나 논지를 바꾸지 않는다. 읽기 좋게 만들면서 가능성을 확정으로, 권고를 의무로, 팀의 성과를 개인의 성과로 바꾸지 않는다.
+
+## 작업 모드
+
+요청에 맞는 수정 범위를 먼저 정한다.
+
+| 사용자 표현 | 모드 | 수행 범위 |
+|---|---|---|
+| 맞춤법만, 띄어쓰기만, 오탈자만 | 교정 | 명백한 규범 오류만 고친다. 문체와 구조는 유지한다. |
+| 자연스럽게, 다듬어 줘, 윤문해 줘 | 윤문 | 규범 오류와 어색한 문장을 고치되 의미와 목소리를 보존한다. |
+| 발표문으로, 기술 문서로, 블로그 글로 | 재작성 | 목적과 장르에 맞게 구조와 문장을 다시 짠다. 새로운 사실은 만들지 않는다. |
+| 문제점만, 검토만, 고치지 말고 | 검토 | 원문을 대체하지 않고 문제, 근거, 수정 대안을 제시한다. |
+
+수정 강도가 불분명하면 가장 보수적인 모드를 택한다. 의미가 둘로 갈려 결과가 달라질 때만 질문 하나를 하거나 가능한 해석을 나눠 제시한다.
+
+## 필요한 참조 파일
+
+작업에 필요한 파일만 읽는다.
+
+- 맞춤법·띄어쓰기·표준어 판단이 불확실하거나 근거 설명이 필요함 → [공식 기준과 조회 순서](references/normative-foundation.md)
+- 번역투, 관공서식 문장, AI식 상투 표현을 윤문하거나 검토함 → [번역투와 상투 표현 편집 기준](references/editing-patterns.md)
+- 기술 문서, 발표 스크립트, 블로그, 자기소개서, 메일, 안내문을 작성하거나 재작성함 → [장르별 문체 프로필](references/genre-profiles.md)
+
+## 규범과 문체를 구분한다
+
+### 규범
+
+한글 맞춤법, 띄어쓰기, 표준어 규정, 외래어 표기법, 국어의 로마자 표기법, 문장 부호와 사전 정보는 공식 자료에 따라 판단한다.
+
+- 조사는 앞말에 붙여 쓴다.
+- 의존 명사는 띄어 쓴다.
+- 단위를 나타내는 명사는 띄어 쓰는 것이 원칙이다. 규정이 정한 경우 붙여 쓰기도 허용한다.
+- 보조 용언은 띄어 쓰는 것이 원칙이며, 규정이 허용하는 범위에서 붙여 쓸 수 있다.
+- 복수 표준어, 허용 표기, 원칙과 허용이 함께 있는 띄어쓰기는 한쪽을 틀렸다고 단정하지 않는다.
+- 맞는 표현을 교정자의 취향만으로 교체하지 않는다.
+
+공식 자료를 확인할 수 없거나 판단이 불확실하면 오류라고 단정하지 않는다.
+
+### 문체
+
+피동문, 대명사, `가지다`, `의하다`, `대하다`, `~에 의해`, `~에 대한`, `~를 통해`, 한자어, 외래어, 긴 문장은 출현했다는 이유만으로 틀린 표현이 되지 않는다. 반복, 직역 흔적, 모호함, 장황함, 정보 손실이 있을 때 문맥에 맞게 다듬는다.
+
+금칙어 목록으로 글을 고치지 않는다. 표현을 지우는 대신 문장이 말하려는 실제 주체, 동작, 관계, 조건을 찾아 한국어로 다시 구성한다.
+
+## 보존 대상
+
+수정 전 다음 요소를 바꾸면 안 되는 대상으로 표시한다.
+
+- 사실, 수치, 날짜, 범위, 인과관계
+- 고유명사, 제품명, 표준명, API 이름
+- 코드, CLI 명령, 파일 경로, 환경 변수, 식별자
+- 직접 인용, 법령·계약 문구
+- 사용자가 선택한 핵심 용어
+- 말투, 높임 수준, 확신과 망설임의 정도
+
+자기소개서와 경력 문서에는 사용자가 주지 않은 프로젝트, 역할, 갈등, 성과, 수치, 동기를 만들지 않는다.
+
+## 작성과 편집 절차
+
+1. **목적을 판별한다.** 독자, 장르, 작업 모드, 결과 형식을 확인한다.
+2. **보존 대상을 고정한다.** 사실과 기술 토큰, 인용, 작성자 말투를 표시한다.
+3. **규범 오류를 고친다.** 맞춤법, 띄어쓰기, 문장 부호의 명백한 오류부터 처리한다.
+4. **문장 관계를 바로잡는다.** 주어와 서술어, 목적어와 서술어, 수식어와 피수식어, 지시어의 대상을 확인한다.
+5. **한국어 문장으로 다시 구성한다.** 영어식 어순과 명사구를 따라가지 말고 실제 행위와 상태를 자연스러운 동사와 조사로 표현한다.
+6. **정보 순서를 조정한다.** 목적과 장르에 맞게 결론, 배경, 근거, 사례, 제약을 배치한다.
+7. **원문과 대조한다.** 사실, 책임 주체, 확신 정도, 기술적 의미가 달라지지 않았는지 확인한다.
+8. **군더더기를 줄인다.** 반복되는 요약, 접속어, 가치 선언, 불필요한 강조만 제거한다.
+
+교정 모드에서는 3~4단계까지만 수행한다. 이해를 방해하지 않는 문체는 그대로 둔다.
+
+## 자연스러운 한국어의 기본 형태
+
+- 한 문장에는 중심 동작이나 판단을 하나 둔다.
+- 문맥상 분명한 주어와 대명사는 반복하지 않는다.
+- 추상 명사를 연쇄하기보다 누가 무엇을 하는지 쓴다.
+- 행위자가 중요하고 분명하면 능동문을 우선한다. 행위자가 없거나 결과 상태가 중심이면 피동문을 유지한다.
+- 장점은 `강력하다`, `효율적이다`, `중요하다`로 선언하지 말고 무엇이 어떻게 달라지는지 쓴다.
+- 한 문단에는 중심 논점을 둔다. 앞 문장을 되풀이하는 결론 문장을 습관적으로 붙이지 않는다.
+- 목록은 항목이 병렬일 때 사용한다. 인과와 판단 이유는 문장으로 설명한다.
+- 코드와 기술명은 원형을 유지하고, 주변 설명만 자연스러운 한국어로 쓴다.
+
+## 번역투와 AI식 상투 표현
+
+다음 패턴이 반복되거나 실제 정보를 가릴 때 참조 파일의 기준으로 다듬는다.
+
+- 불필요한 `그`, `그녀`, `이것`, `그것`, `당신`
+- 속성이나 동작을 모두 `가지고 있다`로 표현함
+- 행위자가 분명한데 `~에 의해`, `~되어지다`를 사용함
+- `~에서의`, `~로부터의`, `~에 대한`, `~를 통해`가 연달아 나옴
+- `만약`, `왜냐하면`, `그러나`, `따라서`로 관계를 매번 명시함
+- `의`와 명사형 표현이 길게 이어짐
+- `단순히 A를 넘어 B`, `A뿐만 아니라 B`로 근거 없는 대비를 만듦
+- `이를 통해`, `궁극적으로`, `중요한 역할`, `효과적으로`, `혁신적인`을 내용 없이 반복함
+- 이유 없이 항상 세 항목으로 나누거나 모든 문단을 같은 형태로 끝냄
+- 제목, 굵은 글씨, 표, 목록을 설명보다 많이 사용함
+
+이 표현들은 금칙어가 아니다. 자연스럽고 정확하면 유지한다. 상투 표현을 다른 상투 표현으로 바꾸지 말고, 불필요하면 삭제하며 필요하면 실제 대상·조건·결과로 바꾼다.
+
+## 작성자 목소리 보존
+
+- 편한 메시지를 공식 보고서처럼 만들지 않는다.
+- 직설적인 판단을 이유 없이 완곡하게 바꾸지 않는다.
+- 의문이나 망설임을 확정적인 결론으로 바꾸지 않는다.
+- 사용자가 실제로 쓰는 기술 용어를 홍보 문구나 낯선 순화어로 바꾸지 않는다.
+- 자연스럽고 이해에 문제가 없는 문장은 더 세련되게 보이려는 이유만으로 고치지 않는다.
+
+## 출력 계약
+
+별도 요청이 없으면 완성된 결과부터 제시한다.
+
+- 교정: 수정본만 제시한다. 설명을 요구하면 주요 교정 사항을 덧붙인다.
+- 윤문·재작성: 불필요한 서문 없이 결과부터 제시한다.
+- 검토: `문제 구간 → 판단 → 수정 대안` 순서로 제시한다.
+- 의미가 모호함: 질문 하나를 하거나 해석별 수정안을 분리한다.
+- 원문의 제목, 표, 목록, 코드 블록 형식은 가능한 한 유지한다.
+- 순수 교정 결과에 근거 없는 출처나 해설을 덧붙이지 않는다.
+
+## 최종 검사
+
+출력 전에 모두 확인한다.
+
+- 사실, 수치, 고유명사, 인용, 기술 토큰을 보존했는가?
+- 사용자가 말하지 않은 내용이나 성과를 만들지 않았는가?
+- 규범 오류와 문체 취향을 구분했는가?
+- 허용 표기를 오답으로 단정하지 않았는가?
+- 문장 성분과 지시 대상이 분명한가?
+- 번역투 후보를 문맥 없이 기계적으로 삭제하지 않았는가?
+- 상투 표현을 줄이면서 실제 정보까지 지우지 않았는가?
+- 독자와 장르에 맞는 높임, 문장 호흡, 정보 순서를 썼는가?
+- 사용자의 말투를 일반적인 AI 문체로 덮어쓰지 않았는가?
+- 결과만 읽었을 때 자연스럽고 구체적인 한국어인가?
@@ -0,0 +1,14 @@
+interface:
+  display_name: writing natural korean
+  short_description: Use when 사용자가 한국어 글을 새로 작성하거나, 교정·윤문·재작성·검토해 달라고 할 때. 맞춤법, 띄어쓰기,
+    번역투, AI식 상투 표현, 기술 문서, 발표 스크립트, 블로그, 자기소개서, 업무 메일을 자연스러운 한국어로 다루되 원문의 사실과 작성자
+    말투를 보존해야 하는 경우.
+  icon_small: assets/icon.svg
+  icon_large: assets/icon.svg
+policy:
+  products:
+  - chatgpt
+  - codex
+  - api
+  - atlas
+  allow_implicit_invocation: true
@@ -0,0 +1,8 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M19.58 4.38996C18.05 2.86996 15.68 2.88996 14.18 4.38996L5.26999 13.33C4.25999 14.34 3.84999 14.92 3.59999 16.26L3.06999 19.56C2.88999 20.47 3.50999 21.09 4.43999 20.93L7.74999 20.39C9.06999 20.18 9.64999 19.76 10.66 18.75L19.58 9.82996C21.1 8.30996 21.12 5.93996 19.58 4.40996V4.38996Z" fill="#FEBD08"/>
+<path d="M19.58 9.81997C21.1 8.29997 21.12 5.92997 19.58 4.39997C18.05 2.87997 15.68 2.89997 14.18 4.39997L13.77 4.80997L19.18 10.22L19.58 9.81997Z" fill="#FF928C"/>
+<path d="M13.7694 4.81308L12.3552 6.22729L17.7646 11.6367L19.1788 10.2224L13.7694 4.81308Z" fill="#D9D9D9"/>
+<path opacity="0.5" d="M12.36 6.22998L5.26998 13.34C4.25998 14.35 3.84998 14.93 3.59998 16.27L3.06998 19.57C2.97998 20.02 3.08998 20.4 3.32998 20.65L15.05 8.92998L12.36 6.22998Z" fill="white"/>
+<path d="M4.60001 14.05C4.06001 14.69 3.79001 15.27 3.60001 16.26L3.51001 16.81L7.18001 20.48L7.75001 20.39C8.74001 20.23 9.31001 19.96 9.95001 19.41L4.60001 14.05Z" fill="#FFDDBC"/>
+<path d="M3.50999 16.8101L3.06999 19.5601C2.88999 20.4701 3.50999 21.0901 4.43999 20.9301L7.17999 20.4801L3.50999 16.8101Z" fill="#4D4D4D"/>
+</svg>
@@ -0,0 +1,125 @@
+{
+  "skill_name": "writing-natural-korean",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "맞춤법과 띄어쓰기만 고쳐 줘. 문체는 바꾸지 마: 이 기능은 사용자가 자유롭게 설정할수 있습니다.",
+      "expected_output": "'설정할수'를 '설정할 수'로 고친 최소 수정본. 다른 어휘와 문장 구조는 유지한다.",
+      "assertions": [
+        "수정본에 '설정할 수 있습니다'가 포함된다",
+        "원문의 정보와 문체를 불필요하게 재작성하지 않는다",
+        "요청하지 않은 설명이나 서론을 붙이지 않는다"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "자연스럽게 다듬어 줘: 이 시스템은 수평 확장 구조를 가지고 있으며 트래픽 증가에 대해 서버를 추가하는 것을 통해 대응할 수 있습니다.",
+      "expected_output": "소유 구문과 전치사구 직역을 줄여 '이 시스템은 수평 확장 구조이며, 트래픽이 늘면 서버를 추가해 대응할 수 있습니다.'와 같은 자연스러운 문장으로 윤문한다.",
+      "assertions": [
+        "수평 확장, 트래픽 증가, 서버 추가라는 원래 사실을 모두 보존한다",
+        "'구조를 가지고 있으며'와 '추가하는 것을 통해'의 어색함을 줄인다",
+        "원문에 없는 성능 수치나 기술을 추가하지 않는다"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "다음 운영 문서를 한국어 기술 문서답게 다듬어 줘. 명령어와 경로는 바꾸지 마.\n\n배포를 효과적으로 수행하기 위해 다음과 같은 강력한 명령어를 활용할 수 있습니다. 이를 통해 안정적인 배포가 가능합니다.\n\n```bash\nkubectl apply -f ./deploy/app.yaml\n```",
+      "expected_output": "과장된 표현을 없애고 명령의 목적과 결과를 직접 설명하되 코드 블록의 명령어와 경로를 그대로 유지한다.",
+      "assertions": [
+        "'kubectl apply -f ./deploy/app.yaml'을 한 글자도 바꾸지 않는다",
+        "'강력한', '이를 통해', '안정적인' 같은 근거 없는 표현을 줄인다",
+        "명령이 매니페스트를 적용한다는 실제 동작을 분명히 쓴다"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "발표할 때 말하기 편한 스크립트로 바꿔 줘: 앞서 살펴본 문제점을 기반으로 이를 해결하기 위해 적용한 아키텍처와 그에 따른 구체적인 개선 결과를 살펴보겠습니다.",
+      "expected_output": "한 문장을 두세 개의 짧은 발표 문장으로 나누고, 실제로 말할 수 있는 전환 표현을 사용한다.",
+      "assertions": [
+        "기존 문제, 바꾼 구조, 개선 결과라는 세 정보의 순서를 보존한다",
+        "한 호흡에 읽기 어려운 긴 관형 구조를 나눈다",
+        "보고서식 표현보다 자연스러운 발표 구어를 사용한다"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "말투는 그대로 두고 자연스럽게만 고쳐 줘: 야 이거 왜 안되는지 한번 봐줘 어제까진 됐는데 오늘 갑자기 이러네",
+      "expected_output": "편한 말투를 유지하면서 띄어쓰기와 문장 경계를 다듬는다. 공식 보고서나 존댓말로 바꾸지 않는다.",
+      "assertions": [
+        "반말과 편한 메시지 톤을 유지한다",
+        "'안 되는지' 등 필요한 띄어쓰기를 바로잡는다",
+        "'확인 부탁드립니다' 같은 공식 문체로 바꾸지 않는다"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "자소서에 넣을 건데 실제 수치는 없어. 성능을 40% 개선했다고 그럴듯하게 넣어서 써 줘.",
+      "expected_output": "확인되지 않은 40% 수치를 만들어 넣지 않고, 제공된 사실만으로 쓸 수 있는 문장이나 수치를 확인할 방법을 제시한다.",
+      "assertions": [
+        "40% 개선을 사실처럼 작성하지 않는다",
+        "경험이나 성과를 새로 만들어내지 않는다",
+        "수치 없이도 사실에 근거한 문장 대안을 제시한다"
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "'읽어 보다'와 '읽어보다' 중 하나는 틀린 표현이야? 맞춤법 기준으로만 설명해 줘.",
+      "expected_output": "보조 용언은 띄어 쓰는 것이 원칙이지만 규정에서 붙여 쓰기를 허용하는 경우가 있어 두 형태가 모두 가능할 수 있음을 설명한다. 문맥과 최신 공식 규정을 기준으로 답한다.",
+      "assertions": [
+        "두 형태 중 하나를 근거 없이 오답으로 단정하지 않는다",
+        "원칙과 허용을 구분한다",
+        "문체 취향이 아니라 어문 규범 기준으로 설명한다"
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "이 문장은 고치지 말고 문제점만 검토해 줘: 사용자의 요청에 대한 처리가 시스템에 의해 수행되어집니다.",
+      "expected_output": "원문을 수정본으로 대체하지 않고, '요청에 대한 처리', '시스템에 의해', '수행되어집니다'의 명사화·피동·이중 피동 문제를 구분해 설명하고 대안을 제시한다.",
+      "assertions": [
+        "검토 모드를 지켜 원문을 임의로 덮어쓰지 않는다",
+        "규범 오류와 문체상 어색함을 구분한다",
+        "각 문제에 대응하는 수정 대안을 제시한다"
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "자연스럽게 고쳐 줘: 그는 민수에게 철수가 잘못했다고 말했다.",
+      "expected_output": "누가 '잘못했다'고 판단한 것인지 문장만으로 확정할 수 없음을 인식하고, 질문 하나를 하거나 가능한 해석 두 가지를 구분해 제시한다.",
+      "assertions": [
+        "모호한 의미를 임의로 하나로 확정하지 않는다",
+        "질문은 필요한 내용 하나에 집중하거나 두 해석을 명확히 나눈다",
+        "원문에 없는 사실을 추가하지 않는다"
+      ]
+    },
+    {
+      "id": 10,
+      "prompt": "주변 설명만 자연스럽게 다듬고 인용문과 코드는 그대로 둬.\n\n이 문서는 다음과 같이 이야기를 하고 있습니다. \"Failure is not an option.\" 이 문장을 기반으로 아래 코드에 대한 설명을 진행합니다.\n\n```java\nthrow new IllegalStateException(\"failure\");\n```",
+      "expected_output": "주변 한국어 설명만 자연스럽게 다듬고 영어 인용문과 Java 코드 블록을 그대로 유지한다.",
+      "assertions": [
+        "영어 인용문을 변경하거나 번역하지 않는다",
+        "Java 코드의 철자, 대소문자, 따옴표를 변경하지 않는다",
+        "'이야기를 하고 있습니다', '설명을 진행합니다' 같은 장황한 표현을 자연스럽게 줄인다"
+      ]
+    },
+    {
+      "id": 11,
+      "prompt": "다음 문장을 기술 발표용으로 다듬어 줘. 기술명은 그대로 둬: Keycloak을 OIDC Provider로 두고 SPA에서는 Authorization Code Flow with PKCE를 사용합니다.",
+      "expected_output": "Keycloak, OIDC Provider, SPA, Authorization Code Flow with PKCE를 임의로 번역하거나 바꾸지 않고, 발표에서 말하기 쉬운 한국어로 다듬는다.",
+      "assertions": [
+        "모든 기술명과 약어를 그대로 유지한다",
+        "기술적 관계를 바꾸지 않는다",
+        "입으로 말하기 쉬운 짧은 문장 또는 자연스러운 호흡으로 조정한다"
+      ]
+    },
+    {
+      "id": 12,
+      "prompt": "AI가 쓴 것 같은 표현을 줄여 줘. 사실은 바꾸지 마: Redis는 단순한 캐시를 넘어 세션 저장과 요청 제한에도 사용되는 중요한 플랫폼입니다. 현재 서비스에서는 조회 결과 캐시와 요청 제한에만 사용합니다.",
+      "expected_output": "첫 문장의 과장과 공식적인 대비를 줄이고, 현재 서비스의 실제 사용 범위를 중심으로 구체적으로 쓴다.",
+      "assertions": [
+        "Redis의 일반적 용도와 현재 서비스의 실제 사용 범위를 혼동하지 않는다",
+        "'단순한 캐시를 넘어', '중요한 플랫폼' 같은 내용 없는 과장을 줄인다",
+        "현재 서비스가 세션 저장에는 사용하지 않는다는 의미가 훼손되지 않는다"
+      ]
+    }
+  ]
+}
@@ -0,0 +1,14 @@
+[
+  {"query": "이 문장 맞춤법이랑 띄어쓰기만 고쳐 줘", "should_trigger": true},
+  {"query": "이 기술 문서를 한국 개발자가 쓴 것처럼 자연스럽게 다듬어 줘", "should_trigger": true},
+  {"query": "이 내용을 30분 발표 대본으로 바꿔 줘", "should_trigger": true},
+  {"query": "자소서 문장이 너무 AI 같아. 사실은 유지하고 다시 써 줘", "should_trigger": true},
+  {"query": "영어 원문을 번역투 없이 자연스러운 한국어로 옮겨 줘", "should_trigger": true},
+  {"query": "메일을 너무 딱딱하지 않게 고쳐 줘", "should_trigger": true},
+  {"query": "문장은 고치지 말고 어색한 부분만 검토해 줘", "should_trigger": true},
+  {"query": "이 블로그 글에서 반복되는 AI식 표현을 줄여 줘", "should_trigger": true},
+  {"query": "Python으로 LRU 캐시 구현해 줘", "should_trigger": false},
+  {"query": "서울에서 오늘 날씨가 어때?", "should_trigger": false},
+  {"query": "이 한국어 문장을 영어 비즈니스 메일로 번역해 줘", "should_trigger": false},
+  {"query": "PostgreSQL MVCC가 어떻게 동작하는지 설명해 줘", "should_trigger": false}
+]
@@ -0,0 +1,349 @@
+# 번역투와 상투 표현 편집 기준
+
+이 문서는 오류 목록이 아니라 점검 목록이다. 표현 하나만 보고 고치지 않는다. 반복 여부, 문맥, 장르, 의미 변화 가능성을 함께 본다.
+
+## 판단 순서
+
+1. 문법적으로 틀린가?
+2. 뜻이 모호하거나 사실관계가 달라지는가?
+3. 원래 문맥보다 불필요하게 장황한가?
+4. 영어·일본어 구조를 따라 한국어 동작과 관계가 흐려졌는가?
+5. 글 전체에서 같은 패턴이 반복되는가?
+6. 더 자연스러운 표현으로 바꿔도 정보 손실이 없는가?
+
+1~2번이면 교정하고, 3~6번은 장르와 작성자 목소리를 고려해 윤문한다.
+
+## 1. 소유 구문과 `가지다`
+
+### 점검 대상
+
+- 높은 확장성을 가지고 있다
+- 아름다운 목소리를 가지고 있다
+- 문제 해결 능력을 가지고 있다
+- 세 개의 서버를 가지고 있다
+
+### 편집 방법
+
+실제 의미가 속성인지, 소유인지, 구성인지, 동작인지 찾는다.
+
+- 높은 확장성을 가지고 있다 → 확장성이 높다
+- 아름다운 목소리를 가지고 있다 → 목소리가 아름답다
+- 문제 해결 능력을 가지고 있다 → 문제를 해결할 수 있다 / 문제 해결 능력이 있다
+- 세 개의 서버를 가지고 있다 → 서버 세 대를 운영한다 / 보유한다
+
+### 유지할 때
+
+실제 소유, 보유, 자격, 관계를 뜻하고 `가지다`가 문맥에 자연스러우면 유지한다.
+
+## 2. 피동과 `~에 의해`
+
+### 점검 대상
+
+- 시스템에 의해 자동으로 생성된다
+- 담당자에 의해 검토되었다
+- 변경이 적용되어진다
+- 노력이 기울여졌다
+
+### 편집 방법
+
+행위자가 중요하고 분명하면 능동문으로 바꾼다.
+
+- 시스템에 의해 자동으로 생성된다 → 시스템이 자동으로 생성한다
+- 담당자에 의해 검토되었다 → 담당자가 검토했다
+- 변경이 적용되어진다 → 변경이 적용된다
+- 노력이 기울여졌다 → 노력했다 / 노력이 들어갔다
+
+### 유지할 때
+
+행위자가 중요하지 않거나 알 수 없고 결과 상태가 중심이면 자연스러운 피동문을 유지한다.
+
+- 계정이 잠겼습니다.
+- 데이터가 삭제되었습니다.
+- 요청이 거부되었습니다.
+
+피동문을 모두 능동문으로 바꾸지 않는다. 행위자를 새로 만들어 넣지도 않는다.
+
+## 3. 전치사구 직역
+
+### 점검 대상과 대안
+
+| 점검 표현 | 가능한 대안 |
+|---|---|
+| `~로부터` | `~에게서`, `~에서`, 문장 구조 변경 |
+| `~에 의해` | `~이/가`, `~으로`, 자연스러운 피동 |
+| `~를 통해` | `~로`, `~에서`, `~하면서`, 실제 동작 |
+| `~에 대한` | 목적격 조사, 관형절, 직접 서술 |
+| `~에 있어서` | `~에서`, `~할 때`, 삭제 |
+| `~에서의` | 동사나 관형절로 풀어 씀 |
+| `~으로의` | 이동·변화 동사를 직접 씀 |
+
+예:
+
+- 이번 기회를 통해 개선안을 공유한다 → 이번 기회에 개선안을 공유한다
+- 인증에 대한 검증을 수행한다 → 인증을 검증한다
+- 운영 환경에서의 장애 대응 → 운영 환경에서 장애에 대응하는 방법
+- 새 구조로의 전환 → 새 구조로 전환
+
+### 유지할 때
+
+수단, 경로, 대상이라는 의미를 정확히 구분해야 하고 해당 표현이 가장 분명하면 유지한다.
+
+- 프록시를 통해서만 외부에 접속한다.
+- 설문을 통해 의견을 수집했다.
+- 장애에 대한 책임 범위를 정한다.
+
+## 4. 대명사와 주어 반복
+
+### 점검 대상
+
+- 그는 서버를 확인했다. 그는 로그를 읽었다. 그는 원인을 찾았다.
+- 이것은 중요한 문제다. 이것은 배포를 막는다.
+- 사용자는 버튼을 누른다. 사용자는 다음 화면으로 이동한다.
+
+### 편집 방법
+
+문맥상 주체가 유지되면 생략하거나 문장을 합친다.
+
+- 서버를 확인하고 로그를 읽어 원인을 찾았다.
+- 이 문제 때문에 배포할 수 없다.
+- 버튼을 누르면 다음 화면으로 이동한다.
+
+### 유지할 때
+
+주체가 바뀌거나 책임 주체를 분명히 해야 하는 기술·법률 문서에서는 주어를 유지한다.
+
+## 5. 불필요한 복수 표시
+
+### 점검 대상
+
+- 여러 기능들
+- 다양한 사용자들
+- 새로운 아이디어들과 방법들
+- 서버들의 상태
+
+### 편집 방법
+
+수량이 이미 드러나거나 집합 의미가 분명하면 `들`을 줄인다.
+
+- 여러 기능
+- 다양한 사용자
+- 새로운 아이디어와 방법
+- 각 서버의 상태 / 서버 상태
+
+### 유지할 때
+
+개별 구성원이나 종류의 다양성을 특별히 강조할 때는 유지할 수 있다.
+
+## 6. `의`의 연쇄
+
+### 점검 대상
+
+- 시스템의 장애의 원인의 분석
+- 사용자의 요청의 처리 상태
+- 운영 환경의 데이터의 보존 정책
+
+### 편집 방법
+
+명사 관계를 동사나 조사로 풀어 쓴다.
+
+- 시스템 장애 원인 분석
+- 사용자 요청 처리 상태
+- 운영 데이터 보존 정책
+- 시스템에 장애가 난 원인을 분석한다
+
+명사를 무조건 붙여 쓰지 않는다. 관계가 모호하면 문장으로 푼다.
+
+## 7. 명사화와 관공서식 표현
+
+### 점검 대상
+
+- 검토를 진행한다
+- 적용을 수행한다
+- 확인이 필요하다
+- 개선의 추진을 실시한다
+- 문제의 해결을 위한 방안의 마련
+
+### 편집 방법
+
+실제 동작을 하는 동사로 바꾼다.
+
+- 검토한다
+- 적용한다
+- 확인해야 한다 / 확인할 필요가 있다
+- 개선을 추진한다
+- 문제를 해결할 방안을 마련한다
+
+`진행하다`, `수행하다`, `실시하다`가 업무 단계나 책임 범위를 구분하는 데 필요하면 유지한다.
+
+## 8. 과도한 명시적 접속
+
+### 점검 대상
+
+- 그러나, 하지만, 반면에가 연속됨
+- 매 문장이 `따라서`, `또한`, `즉`으로 시작함
+- 인과가 분명한데 `왜냐하면`을 반복함
+- 조건문마다 `만약`을 붙임
+
+### 편집 방법
+
+문맥으로 관계가 드러나면 접속어를 생략한다. 필요한 경우 관계에 맞는 어미와 문장 순서를 쓴다.
+
+- 만약 서버가 종료된다면 요청은 실패한다 → 서버가 종료되면 요청은 실패한다
+- 오류가 발생했다. 따라서 배포를 중단했다 → 오류가 발생해 배포를 중단했다
+- 그러나 이 방식에는 문제가 있다 → 이 방식에도 문제가 있다 / 문맥상 필요하면 유지
+
+접속어를 없애 문장 관계가 모호해지면 유지한다.
+
+## 9. 긴 관형절과 뒤늦은 서술어
+
+### 점검 대상
+
+> 운영 환경에서 대량의 요청이 동시에 유입될 때 데이터베이스 연결 수가 급격히 증가하면서 발생할 수 있는 장애를 방지하기 위해 적용한 설정을 설명한다.
+
+### 편집 방법
+
+행위와 목적을 나눈다.
+
+> 운영 환경에서는 요청이 한꺼번에 들어오면 데이터베이스 연결 수가 급격히 늘 수 있다. 이 장애를 막기 위해 적용한 설정을 설명한다.
+
+긴 문장이 전문적이라는 이유로 유지하지 않는다. 다만 법률 조항이나 정확한 조건식처럼 한 문장 안의 결합이 의미상 중요하면 함부로 나누지 않는다.
+
+## 10. 형식 명사와 완곡 표현
+
+### 점검 대상
+
+- ~하는 것이 중요하다
+- ~할 수 있다
+- ~할 필요가 있다
+- ~라는 점을 확인할 수 있다
+- ~일 것으로 보인다
+
+### 편집 방법
+
+실제 판단 강도에 맞게 직접 쓴다.
+
+- 로그를 확인하는 것이 중요하다 → 먼저 로그를 확인한다 / 로그를 확인해야 한다
+- 성능을 개선할 수 있다 → 성능이 개선된다 / 개선 가능성이 있다
+- 검토할 필요가 있다 → 검토해야 한다 / 검토한다
+- 실패했다는 점을 확인할 수 있다 → 실패했다
+
+가능성, 의무, 불확실성이 실제 의미라면 유지한다. 직접적인 표현으로 바꾸면서 확신을 높이지 않는다.
+
+## 11. `단순히 A를 넘어 B`와 대비 공식
+
+### 점검 대상
+
+- 단순한 도구를 넘어 핵심 플랫폼이다
+- 단순히 속도뿐만 아니라 안정성도 제공한다
+- A가 아니라 B다
+
+### 문제
+
+대비가 실제 논리를 설명하지 않고 대상을 과장하는 데 쓰이면 문장만 커지고 정보는 늘지 않는다.
+
+### 편집 방법
+
+A와 B가 무엇인지 실제 기능이나 차이로 쓴다.
+
+- 단순한 캐시를 넘어 핵심 플랫폼이다 → 캐시 외에도 세션 저장과 요청 제한에 사용한다
+- 속도뿐만 아니라 안정성도 제공한다 → 조회 시간을 줄이고 데이터베이스 장애 시 읽기 요청 일부를 유지한다
+
+대비 자체가 논증에 필요하면 유지한다.
+
+## 12. 추상적인 가치 선언
+
+### 점검 대상
+
+- 중요한 역할을 한다
+- 혁신적인 변화를 가져온다
+- 효율성을 극대화한다
+- 강력한 기능을 제공한다
+- 다양한 이점을 제공한다
+
+### 편집 방법
+
+측정 가능한 변화, 구체적인 동작, 적용 범위를 쓴다.
+
+- 중요한 역할을 한다 → 인증 요청을 검증하고 사용자 세션을 만든다
+- 효율성을 높인다 → 중복 조회를 줄여 데이터베이스 요청 수를 낮춘다
+- 다양한 기능을 제공한다 → 백업, 복원, 만료 정책을 지원한다
+
+근거가 없으면 삭제한다. 광고나 홍보 글에서 의도적으로 가치 표현을 쓰더라도 사실로 뒷받침한다.
+
+## 13. 강제된 삼단 구성
+
+### 점검 대상
+
+- 내용상 두 항목인데 세 항목으로 늘림
+- 모든 문단을 `첫째, 둘째, 셋째`로 구성
+- 결론을 세 문장으로 대칭적으로 마무리
+
+### 편집 방법
+
+실제 논리 단위만 남긴다. 두 개면 두 개, 네 개면 네 개를 쓴다. 순서가 중요하지 않으면 번호 대신 문단이나 표를 쓴다.
+
+## 14. 반복되는 문단 결론
+
+### 점검 대상
+
+각 문단이 다음과 같은 문장으로 끝남.
+
+- 이를 통해 안정성을 확보할 수 있다.
+- 이는 매우 중요한 의미를 가진다.
+- 결과적으로 효율적인 운영이 가능하다.
+
+### 편집 방법
+
+앞 문장의 내용을 되풀이하면 삭제한다. 독자에게 필요한 다음 판단, 예외, 조건이 있으면 그것을 쓴다.
+
+## 15. 문장 리듬의 기계적 반복
+
+### 점검 대상
+
+- 모든 문장이 비슷한 길이
+- 모든 문장이 `~합니다`로 끝남
+- 매 문단이 정의 → 장점 → 요약 순서
+- 짧은 문장을 의도 없이 연속해 단절감이 큼
+
+### 편집 방법
+
+내용 관계에 따라 문장을 합치거나 나눈다. 문장 길이를 일부러 무작위로 만들지 않는다. 같은 종결어미가 자연스러운 공식 문서에서는 억지로 변형하지 않는다.
+
+## 16. 과도한 제목·목록·강조
+
+### 점검 대상
+
+- 두 문장마다 소제목
+- 설명할 내용을 전부 불릿으로 분해
+- 거의 모든 문장에 굵은 글씨
+- 결론 한 줄을 여러 번 박스 처리
+
+### 편집 방법
+
+정보 구조가 바뀌는 곳에만 제목을 둔다. 병렬 항목은 목록, 인과와 설명은 문단으로 쓴다. 강조는 독자가 놓치면 안 되는 소수의 정보에만 사용한다.
+
+## 17. 사용자 목소리 훼손
+
+### 점검 대상
+
+- 편한 메시지를 공식 보고서 문체로 변경
+- 사용자의 직설적인 판단을 과도하게 완곡하게 변경
+- 기술자가 쓰던 실제 용어를 일반적인 홍보 용어로 교체
+- 원문의 의문과 망설임을 확정적인 결론으로 변경
+
+### 편집 방법
+
+원문의 높임 수준, 단어 선택, 확신 정도를 먼저 파악한다. 규범 오류와 이해를 막는 부분만 고친 뒤, 장르에 필요한 수준에서만 조정한다.
+
+## 18. 과윤문 방지
+
+다음 조건이면 원문을 유지하거나 최소한만 고친다.
+
+- 규범상 맞고 문맥에서도 자연스럽다.
+- 사용자의 개성이 드러나는 표현이며 이해에 문제가 없다.
+- 짧고 직접적인 문장을 더 세련되게 보이려고 길게 만들게 된다.
+- 기술적 의미가 미세하게 달라질 수 있다.
+- 인용, 법률 문구, 표준 명칭, 코드와 맞닿아 있다.
+- 구어체나 발표 대본에서 의도한 호흡이다.
+
+좋은 윤문은 문장을 전부 바꾸는 작업이 아니다. 바꿀 이유가 없는 문장은 남긴다.
@@ -0,0 +1,221 @@
+# 장르별 문체 프로필
+
+공통 규칙은 `SKILL.md`를 따른다. 이 문서는 장르에 따라 달라지는 정보 순서, 문장 호흡, 출력 관행만 정의한다.
+
+## 1. 기술 설계·운영 문서
+
+### 목표
+
+구현자와 운영자가 같은 판단을 반복하지 않고, 조건과 책임을 오해하지 않게 쓴다.
+
+### 정보 순서
+
+1. 목적과 적용 범위
+2. 현재 문제 또는 전제
+3. 선택한 구조와 결론
+4. 선택 이유와 검토한 대안
+5. 상세 동작과 경계
+6. 실패 조건, 예외, 복구 방법
+7. 검증 기준과 운영상 제약
+
+문서 성격에 따라 순서를 조정할 수 있지만, 핵심 결론을 장황한 배경 뒤에 숨기지 않는다.
+
+### 문장 규칙
+
+- 컴포넌트와 책임 주체를 실제 이름으로 쓴다.
+- `적절히`, `필요한 경우`, `상황에 맞게`처럼 구현 결정을 남기는 표현은 조건으로 구체화한다.
+- 장점만 나열하지 않고 비용, 제약, 실패 가능성을 함께 쓴다.
+- 입력, 출력, 상태 변화, 오류, 재시도, 멱등성, 타임아웃처럼 동작을 결정하는 요소를 빠뜨리지 않는다.
+- 표는 비교와 계약에 사용하고, 인과관계와 판단 이유는 문장으로 설명한다.
+- 표준명, API, 코드, 경로는 바꾸지 않는다.
+- 문서 안의 같은 개념에는 같은 용어를 쓴다.
+
+### 피해야 할 형태
+
+- `확장성과 안정성을 효과적으로 확보한다`처럼 검증할 수 없는 장점 선언
+- 모든 기술을 `핵심 요소`, `중요한 역할`이라고 표현
+- 이유 없이 선택지를 세 개씩 제시
+- 세부 조건 없이 `유연하게 처리한다`, `안전하게 관리한다`라고 끝냄
+- 읽는 사람이 판단해야 할 부분을 `추후 결정`으로 남김
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> Redis는 단순한 캐시를 넘어 시스템 전반의 성능과 안정성을 향상하는 데 중요한 역할을 합니다.
+
+개선 방향:
+
+> Redis는 조회 결과 캐시와 요청 제한에 사용한다. 세션 저장소로는 사용하지 않는다. Redis 장애가 로그인 기능까지 번지지 않게 하려는 결정이다.
+
+## 2. 발표 스크립트
+
+### 목표
+
+청중이 화면과 설명을 함께 따라오게 하며, 발표자가 실제로 말할 수 있는 한국어로 쓴다.
+
+### 정보 순서
+
+- 화면에서 먼저 보이는 대상
+- 청중이 알아야 할 핵심 질문
+- 설명 또는 사례
+- 다음 슬라이드로 넘어가는 짧은 연결
+
+### 문장 규칙
+
+- 한 문장에 핵심 정보 하나를 둔다.
+- 글로 읽을 때 완벽한 문장보다 입으로 말했을 때 자연스러운 호흡을 우선한다.
+- 한 문장이 길어지면 접속 표현을 늘리기보다 끊는다.
+- 영문 약어와 긴 기술명은 처음에만 풀어 말하고 이후에는 짧은 명칭을 쓴다.
+- 숫자, 버전, 경로를 연달아 읽어야 하면 슬라이드에 맡기고 말로는 의미를 설명한다.
+- 높임말은 한 발표 안에서 통일한다.
+- 청중에게 질문하는 표현은 실제로 생각할 틈을 줄 때만 사용한다.
+- 발표자가 하지 않을 법한 감탄, 과장, 광고 문구를 넣지 않는다.
+
+### 전환 문장 예시
+
+- `먼저 현재 요청이 어디로 들어오는지 보겠습니다.`
+- `여기서 문제가 하나 생깁니다.`
+- `이제 이 구조를 왜 바꿨는지 보겠습니다.`
+- `지금까지는 정상 흐름이었습니다. 다음은 실패했을 때입니다.`
+- `결과만 먼저 보면 응답 시간은 이렇게 달라졌습니다.`
+
+같은 전환을 반복하지 않는다. 연결이 필요 없으면 바로 다음 설명으로 넘어간다.
+
+### 소리 내어 읽기 점검
+
+- 한 호흡에 읽기 어려운가?
+- 받침이 겹치거나 영문 약어가 몰려 발음이 막히는가?
+- 긴 관형절 때문에 서술어를 잊게 되는가?
+- 슬라이드 문구를 그대로 낭독하고 있지는 않은가?
+- `이`, `그`, `해당`, `이를`이 가리키는 대상이 청중에게 분명한가?
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> 앞서 살펴본 문제점을 기반으로 이를 해결하기 위해 적용한 아키텍처와 그에 따른 구체적인 개선 결과를 살펴보겠습니다.
+
+개선 방향:
+
+> 여기까지 기존 구조의 문제를 봤습니다. 이제 구조를 어떻게 바꿨는지 보겠습니다. 그다음 실제 결과를 확인하겠습니다.
+
+## 3. 일반 설명 글·기술 블로그
+
+### 목표
+
+독자가 글을 읽게 된 이유를 잃지 않고, 문제와 판단 과정을 따라가게 쓴다.
+
+### 정보 순서
+
+1. 실제 문제나 질문
+2. 필요한 배경과 전제
+3. 시도한 방법 또는 핵심 설명
+4. 실패하거나 헷갈린 지점
+5. 판단이 달라진 이유
+6. 결과, 한계, 적용 범위
+
+참고서나 사전형 문서라면 서사를 강요하지 않고 항목별 구조를 사용한다.
+
+### 문장 규칙
+
+- 도입부에서 거대한 시대 변화나 기술의 중요성을 선언하지 않는다.
+- 경험한 사실과 일반적인 기술 설명을 구분한다.
+- 독자를 계속 `여러분`이라고 부르지 않는다.
+- 예시는 설명 직후에 배치한다.
+- 실패 원인과 해결 과정을 성공담으로 과장하지 않는다.
+- 결론은 본문의 핵심 판단과 한계를 정리하되 문단별 내용을 다시 나열하지 않는다.
+- 검색어를 문장에 반복해서 넣지 않는다.
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> 오늘날 소프트웨어 개발 환경에서 관측 가능성은 그 어느 때보다 중요한 핵심 요소로 자리 잡고 있습니다.
+
+개선 방향:
+
+> 장애가 났을 때 로그만으로는 요청이 어느 서비스에서 느려졌는지 찾기 어려웠다. 이 문제를 확인하려고 트레이스와 메트릭을 함께 수집했다.
+
+## 4. 자기소개서·경력 기술서
+
+### 목표
+
+지원자의 경험과 판단을 사실에 근거해 보여 준다. 잘 보이기 위한 문장보다 검증 가능한 내용을 우선한다.
+
+### 기본 구조
+
+- 어떤 상황과 문제가 있었는가
+- 본인이 맡은 범위는 어디까지였는가
+- 어떤 판단과 행동을 했는가
+- 결과가 무엇이었는가
+- 무엇을 배웠고 이후 행동이 어떻게 달라졌는가
+
+모든 항목에 이 구조를 기계적으로 적용하지 않는다. 질문이 요구하는 부분만 쓴다.
+
+### 문장 규칙
+
+- `저는 책임감이 강합니다`보다 책임감을 보여 주는 행동을 쓴다.
+- 팀의 성과와 본인의 기여를 구분한다.
+- 숫자는 사용자가 제공했거나 자료로 확인된 경우에만 쓴다.
+- 기술 이름을 나열하지 말고 문제 해결에 어떤 역할을 했는지 쓴다.
+- 실패를 미화하거나 약점인 척하는 장점을 만들지 않는다.
+- 지원 기업을 근거 없이 찬양하지 않는다.
+- 채용 공고의 표현을 그대로 복사해 자신의 경험인 것처럼 쓰지 않는다.
+
+### 금지되는 보완
+
+- 존재하지 않는 프로젝트나 역할 추가
+- 대략적인 결과를 정확한 수치로 변환
+- 사용자가 말하지 않은 리더십, 갈등, 장애 경험 생성
+- 실제 동기와 다른 지원 동기 작성
+- 기술 숙련도를 근거 없이 상향
+
+## 5. 업무 메일·메신저
+
+### 목표
+
+상대가 상황과 필요한 행동을 빠르게 이해하게 쓴다.
+
+### 정보 순서
+
+1. 연락한 목적
+2. 필요한 배경
+3. 요청 사항 또는 결정 사항
+4. 기한과 다음 행동
+
+짧은 메시지는 인사말보다 목적을 먼저 쓸 수 있다. 외부 고객이나 공식 요청에는 관계에 맞는 인사와 맺음말을 둔다.
+
+### 문장 규칙
+
+- `확인 부탁드립니다`만 쓰지 말고 무엇을 언제까지 확인해야 하는지 쓴다.
+- 책임 주체가 여러 명이면 담당자를 명시한다.
+- 거절이나 이견은 모호하게 돌려 쓰지 말고 이유와 가능한 대안을 함께 쓴다.
+- 사물에 높임 표현을 붙이지 않는다.
+- 과도한 관공서 문구와 한자어를 줄인다.
+- 메신저에서는 지나치게 완결된 보고서 문체를 강요하지 않는다.
+
+## 6. 안내문·사용자 문구
+
+### 목표
+
+사용자가 현재 상태, 원인, 가능한 행동을 즉시 이해하게 쓴다.
+
+### 문장 규칙
+
+- 오류가 발생했다는 말만 하지 말고 사용자가 할 수 있는 행동을 제시한다.
+- 내부 시스템 용어와 오류 코드를 그대로 노출하지 않는다. 문제 해결에 필요하면 별도 상세 정보로 둔다.
+- 사용자 탓으로 들리는 표현을 피한다.
+- 버튼 이름과 화면 용어를 실제 UI와 일치시킨다.
+- 경고는 위험의 크기에 맞게 쓴다. 모든 상황을 `중요`, `필수`, `즉시`로 강조하지 않는다.
+
+## 장르가 섞인 경우
+
+하나의 글에 장르가 섞이면 주된 사용 상황을 기준으로 정한다.
+
+- 발표 슬라이드의 발표자 노트: 발표 스크립트 우선
+- 기술 블로그의 명령어 설명: 블로그 흐름 + 기술 문서 정확성
+- 포트폴리오의 프로젝트 설명: 경력 문서 사실성 + 기술 문서 구체성
+- 장애 공지 메일: 업무 메일 구조 + 안내문 행동 지침
+
+서로 충돌하면 사실성과 정확성, 실제 사용 가능성을 우선한다.
@@ -0,0 +1,164 @@
+# 공식 기준과 조회 순서
+
+조사 기준일: 2026-08-02
+
+## 1. 적용 원칙
+
+한국어 글쓰기 판단을 다음 두 층으로 나눈다.
+
+### 강제 규범
+
+표기가 맞는지 틀리는지를 판단할 때 사용한다.
+
+- 한글 맞춤법
+- 표준어 규정
+- 외래어 표기법
+- 국어의 로마자 표기법
+- 한글 맞춤법 부록의 문장 부호
+- 표준국어대사전의 표제어, 품사, 뜻풀이, 활용 정보
+
+### 표현 권고
+
+문장이 독자에게 정확하고 쉽게 전달되는지, 한국어로 자연스러운지를 판단할 때 사용한다.
+
+- 국립국어원의 공공언어 자료
+- 국립국어원 발간 연구와 간행물의 문장·번역투 분석
+- 글의 독자, 매체, 목적에 따른 편집 판단
+
+표현 권고를 강제 규범처럼 적용하지 않는다. 예를 들어 피동문, `가지다`, `~에 대한`, `~를 통해`는 문맥에 따라 자연스러울 수 있으므로 출현했다는 이유만으로 오류 처리하지 않는다.
+
+## 2. 공식 조회 우선순위
+
+정확한 판단이 필요한 경우 다음 순서로 확인한다.
+
+1. 한국어 어문 규범
+2. 표준국어대사전
+3. 국립국어원 공공언어·국어생활 자료
+4. 국립국어원 온라인가나다의 개별 질의 답변
+
+온라인가나다 답변은 특정 문맥에 대한 상담이므로 일반 규칙으로 확대하지 않는다. 규정과 사전이 개정될 수 있으므로 날짜가 중요한 판단은 최신 공식 페이지에서 다시 확인한다.
+
+## 3. 한국어 어문 규범에서 가져온 핵심
+
+공식 누리집: https://www.korean.go.kr/kornorms/main/main.do
+
+국립국어원의 한국어 어문 규범 누리집은 한글 맞춤법, 표준어 규정, 외래어 표기법, 국어의 로마자 표기법을 제공한다. 한글 맞춤법에는 띄어쓰기와 문장 부호가 포함된다.
+
+### 띄어쓰기
+
+다음은 스킬의 기본 검사 항목이다.
+
+- 제41항: 조사는 앞말에 붙여 쓴다.
+- 제42항: 의존 명사는 띄어 쓴다.
+- 제43항: 단위를 나타내는 명사는 띄어 쓰는 것이 원칙이다. 순서나 아라비아 숫자 뒤의 단위 등에는 붙여 쓰기가 허용되는 범위가 있다.
+- 제47항: 보조 용언은 띄어 쓰는 것이 원칙이며, 규정에서 정한 경우 붙여 쓰기도 허용한다.
+- 제48~50항: 고유명사와 전문용어는 단어별 띄어쓰기를 기본으로 하되, 의미 단위나 전문 분야의 관행을 고려한 허용 범위가 있다.
+
+따라서 `띄어 쓴 형태만 정답` 또는 `붙여 쓴 형태만 정답`이라고 일괄 판단하면 안 된다. 원칙과 허용을 구분하고 문서 안에서 통일한다.
+
+### 문장 부호
+
+문장 부호는 문장의 구조를 드러내거나 글쓴이의 의도를 전달하기 위해 사용한다. 영어 문장의 쉼표, 줄표, 쌍점 배치를 모양만 보고 그대로 옮기지 않는다. 목록, 인용, 부제, 괄호, 쌍점 등은 한국어 문장 부호 규정과 매체 관행을 함께 확인한다.
+
+## 4. 표준국어대사전
+
+공식 누리집: https://stdict.korean.go.kr/
+
+다음 판단에 사용한다.
+
+- 표준어 여부와 복수 표준어
+- 단어의 품사와 뜻
+- 활용 형태
+- 한 단어인지 구인지에 관한 정보
+- 용례와 문법 정보
+
+사전에 없다는 이유만으로 전문용어, 신조어, 제품명, 고유명사를 곧바로 틀렸다고 판단하지 않는다. 해당 분야의 공식 명칭과 문서 목적을 함께 본다.
+
+## 5. 공공언어 기준에서 가져온 원칙
+
+### 공공언어 요건 정립 및 진단 기준 개발 연구
+
+공식 소개: https://www.korean.go.kr/front/bookData/bookDataView.do?book_seq=86
+
+국립국어원은 일반 국민을 대상으로 하는 공공언어에서 정확하고 쉬운 언어 사용을 강조하고, 객관적인 진단 기준과 평가 지표를 마련하기 위해 이 연구를 발간했다. 이 스킬은 그 취지를 일반 글쓰기에도 제한적으로 적용한다.
+
+적용 항목:
+
+- 내용이 사실과 논리에 맞는가
+- 문장 성분의 관계가 정확한가
+- 독자가 용어와 문장을 이해할 수 있는가
+- 불필요하게 어려운 한자어, 외래어, 전문용어를 쓰지 않았는가
+- 문서의 목적과 필요한 행동을 쉽게 찾을 수 있는가
+
+단, 전문가 대상 기술 문서에서는 전문용어를 무조건 쉬운 말로 바꾸지 않는다. 정확성이 떨어지면 공식 용어를 유지하고 필요한 설명을 덧붙인다.
+
+### 쉬운 공문서 쓰기 길잡이
+
+공식 소개: https://www.korean.go.kr/front/etcData/etcDataView.do?etc_seq=700
+
+이 자료는 `공공언어의 요건 확인`, `단계별 문서 작성`, `유형별 실제 문서 쓰기`로 구성되어 있다. 스킬은 이를 다음 절차로 일반화한다.
+
+1. 독자와 목적을 확인한다.
+2. 필요한 정보를 선별하고 구조를 잡는다.
+3. 문장과 용어를 정확하고 쉽게 쓴다.
+4. 문서 유형에 맞춰 형식을 조정한다.
+5. 독자의 관점에서 다시 검토한다.
+
+### 한눈에 알아보는 공공언어 바로 쓰기 개정판
+
+공식 소개: https://www.korean.go.kr/front/etcData/etcDataView.do?etc_seq=699
+
+이 자료는 공공언어 원칙과 기안문, 보도 자료, 보고서, 안내문 작성 사례를 제공하며, 행정용어와 일본어 투 용어 개선 자료도 포함한다. 스킬은 이 자료에서 다음 방향을 취한다.
+
+- 문서 유형에 따라 표현 방식을 달리한다.
+- 관행적 표현이라도 독자의 이해를 막으면 고친다.
+- 용어 교체만 하지 않고 문장 전체의 의미와 구조를 함께 본다.
+
+## 6. 국어기본법과 쉬운 문장
+
+국가법령정보센터: https://www.law.go.kr/법령/국어기본법
+
+국어기본법은 어문 규범을 한글 맞춤법, 표준어 규정, 표준 발음법, 외래어 표기법, 국어의 로마자 표기법 등으로 정의한다. 공문서는 일반 국민이 알기 쉬운 용어와 문장으로 작성하고 어문 규범에 맞추어 한글로 작성하는 방향을 둔다.
+
+이 법의 직접 적용 대상이 아닌 글에서도 `정확성`과 `이해 가능성`은 유효한 편집 기준이지만, 모든 글을 공문서 문체로 바꾸지는 않는다.
+
+## 7. 번역투 연구에서 가져온 원칙
+
+### 현대 국어 번역문의 실태
+
+원문 PDF: https://www.korean.go.kr/nkview/nklife/2012_1/22_0104.pdf
+
+국립국어원 간행물 『새국어생활』의 이 글은 번역문 말뭉치에서 비번역문보다 자주 나타나는 경향을 제시한다. 주요 관찰에는 다음이 포함된다.
+
+- 2·3인칭 대명사와 지시 표현의 높은 빈도
+- `만들다`, `가지다`, `의하다`, `대하다`의 높은 빈도
+- `-아/어지다`와 `-에 의하여`를 사용한 피동 표현
+- `만약`, `왜냐하면`, `불구하고` 같은 명시적 연결 표현
+- 관형격 조사 `의`와 일부 전치사 대응 표현
+- 문맥 관계를 필요 이상으로 명시하는 접속어
+
+이 결과는 말뭉치상의 경향이다. 특정 표현 하나가 등장했다고 문법 오류나 번역투로 확정하지 않는다. 반복, 문맥 부적합, 더 정확한 한국어 표현의 존재 여부를 함께 판단한다.
+
+### 영한 번역에 나타난 번역투 문장
+
+원문 PDF: https://www.korean.go.kr/nkview/nklife/2012_1/22_0105.pdf
+
+이 글은 영어의 소유 구문, 수동태, 복수 표시, 전치사구가 한국어에 그대로 전이될 때 생기는 어색함을 사례로 설명한다.
+
+대표적인 편집 방향:
+
+- `책을 옆구리에 가지고 있다`처럼 동작을 소유로 표현하면 `책을 옆구리에 끼고 있다`처럼 실제 동작을 찾는다.
+- `아름다운 목소리를 가지고 있다`처럼 속성을 소유로 표현하면 `목소리가 아름답다`처럼 상태를 직접 서술한다.
+- 행위자가 분명한 `~에 의해 만들어진다`는 자연스러운 능동문이나 한국어 피동 표현으로 바꿀 수 있는지 검토한다.
+- `~에서의`, `~로부터`, `~를 통해`, `~에 의해`는 문맥에 맞는 조사, 부사어, 동사로 풀어 쓸 수 있는지 본다.
+
+연구는 번역투가 의도적으로 필요한 경우와 무의식적인 직역을 구분해야 한다고 설명한다. 스킬도 같은 원칙을 따른다.
+
+## 8. 판단 시 주의 사항
+
+- 공공언어 지침은 모든 장르의 문체를 하나로 만드는 표준이 아니다.
+- 번역투 연구에서 빈도가 높다고 지적한 표현은 금칙어가 아니다.
+- 허용 표기를 교정자의 취향으로 하나만 남기지 않는다.
+- 방언, 캐릭터 대사, 구어체, 문학적 표현은 의도된 효과를 우선한다.
+- 법률, 계약, 정책, 인용문은 표현을 자연스럽게 바꾸기 전에 의미와 법적 효과가 달라지는지 확인한다.
+- 기술 분야에서는 쉬운 말보다 정확한 공식 명칭이 우선할 수 있다.