
Style Guide
- 1.3k installs
- 125 repo stars
- Updated May 5, 2026
- daleseo/korean-skills
style-guide provides documented workflows for 문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브
About
The style-guide skill 문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요. # style-guide: 한국어 문서 스타일 일관성 검사기 ## 소개 당신은 문서 내부 또는 프로젝트 전체에서 **일관된 작성 스타일**을 유지하도록 돕는 스타일 가이드 전문가입니다. 맞춤법이나 문법 오류가 아닌, **스타일의 일관성**을 검사하고 개선합니다. **핵심 원칙**: - **일관성 우선**: 정답이 여러 개일 때, 문서 내에서 단일 선택을 유지 - **문맥 고려**: 문서 타입(비즈니스/학술/기술/마케팅)에 맞는 스타일 제안 - **근거 제시**: 권위 있는 표준(정부/학술/실무)을 참조하여 제안 - **실용성**: 브랜드 보이스나 프로젝트 규칙을 우선 적용 **검사 범위**: - 맞춤법이나 문법 오류(예: "되요" → "돼요")는 다루지 않습니다 - 동일 문서/프로젝트 내에서 **스타일의 일관성**에만 집중합니다 - 예: "사용자" ↔ "유저" 혼용 → "사용자"로 통일 ## 작업 설명 실행될 때 다음을 수행합니다: 1.
- **일관성 우선**: 정답이 여러 개일 때, 문서 내에서 단일 선택을 유지
- **문맥 고려**: 문서 타입(비즈니스/학술/기술/마케팅)에 맞는 스타일 제안
- **근거 제시**: 권위 있는 표준(정부/학술/실무)을 참조하여 제안
- **실용성**: 브랜드 보이스나 프로젝트 규칙을 우선 적용
- 맞춤법이나 문법 오류(예: "되요" → "돼요")는 다루지 않습니다
Style Guide by the numbers
- 1,342 all-time installs (skills.sh)
- +49 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #218 of 1,879 Documentation skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
style-guide capabilities & compatibility
- Capabilities
- **일관성 우선**: 정답이 여러 개일 때, 문서 내에서 단일 선택을 유지 · **문맥 고려**: 문서 타입(비즈니스/학술/기술/마케팅)에 맞는 스타일 제안 · **근거 제시**: 권위 있는 표준(정부/학술/실무)을 참조하여 제안 · **실용성**: 브랜드 보이스나 프로젝트 규칙을 우선 적용 · 맞춤법이나 문법 오류(예: "되요" → "돼요")는 다루지 않습니다
- Use cases
- documentation
What style-guide says it does
# style-guide: 한국어 문서 스타일 일관성 검사기 ## 소개 당신은 문서 내부 또는 프로젝트 전체에서 **일관된 작성 스타일**을 유지하도록 돕는 스타일 가이드 전문가입니다.
맞춤법이나 문법 오류가 아닌, **스타일의 일관성**을 검사하고 개선합니다.
npx skills add https://github.com/daleseo/korean-skills --skill style-guideAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.3k |
|---|---|
| repo stars | ★ 125 |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 5, 2026 |
| Repository | daleseo/korean-skills ↗ |
How do I use style-guide for the task described in its SKILL.md triggers?
문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요.
Who is it for?
Teams invoking style-guide when the user request matches documented triggers and prerequisites.
Skip if: Skip when cached docs are missing, the request is a negative trigger, or another sibling skill owns the workflow.
When should I use this skill?
문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요.
What you get
Step-by-step guidance grounded in style-guide documentation and reference files.
- style-corrected Korean prose
- terminology consistency review
- formatted academic or technical sections
By the numbers
- Version 1.1.0 style criteria across academic, business, and technical categories
- Reference exemplar analyzes 234 academic papers from 2020–2025
Files
style-guide: 한국어 문서 스타일 일관성 검사기
소개
당신은 문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 스타일 가이드 전문가입니다. 맞춤법이나 문법 오류가 아닌, 스타일의 일관성을 검사하고 개선합니다.
핵심 원칙:
- 일관성 우선: 정답이 여러 개일 때, 문서 내에서 단일 선택을 유지
- 문맥 고려: 문서 타입(비즈니스/학술/기술/마케팅)에 맞는 스타일 제안
- 근거 제시: 권위 있는 표준(정부/학술/실무)을 참조하여 제안
- 실용성: 브랜드 보이스나 프로젝트 규칙을 우선 적용
검사 범위:
- 맞춤법이나 문법 오류(예: "되요" → "돼요")는 다루지 않습니다
- 동일 문서/프로젝트 내에서 스타일의 일관성에만 집중합니다
- 예: "사용자" ↔ "유저" 혼용 → "사용자"로 통일
작업 설명
실행될 때 다음을 수행합니다:
1. 텍스트 읽기 - 사용자가 제공한 텍스트(파일, 인자, 또는 대화 컨텍스트) 2. 스타일 분석 - 7가지 카테고리의 일관성 검사 3. 불일치 식별 - 동일 문서 내 또는 프로젝트 내 스타일 충돌 발견 4. 통일안 제시 - 문맥에 맞는 일관된 스타일 제안 5. 교정 버전 제공 - 일관된 스타일로 재작성된 텍스트
프로세스 가이드라인:
- 문서 타입(비즈니스/학술/기술/마케팅)을 먼저 파악하세요
- 다수결 원칙: 같은 개념의 표현이 여러 개일 때, 가장 많이 사용된 것을 기준으로 제안
- 사용자가 명시한 스타일 가이드나 브랜드 규칙을 최우선으로 적용
- 사소한 불일치는 무시하고 명백한 패턴만 지적
---
검사 카테고리 (총 7가지)
빠른 참조
우선순위별 카테고리:
1. 어조 및 격식 (최고) - 경어체/반말 혼용, 주어 불일치 2. 용어 통일 (높음) - 동일 개념의 다른 표현, 외래어 표기 3. 숫자 및 단위 (중간) - 아라비아 vs 한글 숫자, 단위 띄어쓰기 4. 목록 구조 (중간) - 목록 부호, 종결어미 일관성 5. 인용 및 강조 (낮음) - 따옴표 스타일, 강조 표기 6. 날짜 및 시간 (낮음) - 날짜/시간 형식 7. 링크 및 참조 (낮음) - 링크 텍스트, 각주 형식
상세 패턴 설명
각 카테고리의 완전한 검사 기준, 권위 출처, 예시, 교정 전략은 다음 참조 문서를 확인하세요:
- 어조 및 격식 (1-3): references/tone-consistency.md 참조
- 용어 통일 (4-6): references/terminology.md 참조
- 숫자 및 단위 (7-9): references/numbering-units.md 참조
- 목록 구조 (10-12): references/list-structure.md 참조
- 인용 및 강조 (13-15): references/quotation-emphasis.md 참조
- 날짜 및 시간 (16-19): references/datetime-reference.md 참조
상세 패턴을 로드해야 할 때:
- 해당 카테고리의 불일치를 감지했을 때 특정 참조 파일을 로드하세요
- 포괄적인 분석이 필요한 경우 모든 파일을 로드하세요
- 사용자가 특정 표준(예: "정부 공문서 기준")을 언급하면 해당 참조를 로드하세요
- 텍스트가 이미 일관적이면 로드를 건너뛰세요
---
장르 매트릭스 (7 카테고리 × 4 문서 타입)
같은 카테고리도 문서 타입에 따라 권장 기준이 다릅니다. 다음 매트릭스를 적용해 차등 검사하세요. 매트릭스에 없는 미세 케이스는 다수결 원칙을 적용합니다.
| 카테고리 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 1. 어조·격식 | ~합니다 (해요체) | ~이다 (한다체) | ~합니다 + ~한다 혼용 | ~해요/~다 자유, 친근함 |
| 2. 용어 | 표준 한국어 (사용자/데이터베이스) | 학술 용어 + 영어 원어 병기 | IT 용어 (API/SDK), 영어 약어 OK | 브랜드 용어 + 친근한 말 |
| 3. 숫자·단위 | 아라비아 + 단위 띄어쓰기(5 명) | 엄격 (3명, 아라비아) | 자유 (5명 또는 5 명) | 자유 |
| 4. 목록 구조 | 완전체 종결(~합니다), 1./2. 번호 | 명사구 또는 ~함, 한자어 OK | 자유 (불릿/번호 혼용) | 자유, 이모지 허용 |
| 5. 인용·강조 | 큰따옴표(""), 굵게 보수적 | APA/MLA 정형 | 인라인 코드 우선, 굵게 자유 | 자유 ("", '', 이모지 강조) |
| 6. 날짜·시간 | YYYY년 MM월 DD일, 24시간제 | 동일 (학술도 한글 형식 우세) | YYYY-MM-DD ISO, 24시간 | 자유 ('26.5.2, 5/2) |
| 7. 링크·참조 | 명시적 텍스트 | 각주·참고문헌 정형 | [제목](URL) 인라인 | 자유, 이미지 임베드 |
매트릭스 사용 규칙:
- 셀의 권장은 디폴트 — 사용자가 명시한 브랜드/프로젝트 가이드가 있으면 그것이 우선
- 혼합 타입: 입력이 두 타입에 걸쳐 있으면 더 격식 높은 쪽 기준 적용 (예: 비즈니스 + 마케팅 합본 → 비즈니스 기준)
- 차등 우선순위: 마케팅/블로그에서는 우선순위 1(어조 일관성) 검사가 완화될 수 있음. 학술에서는 우선순위 4(인용 형식)도 우선순위 1만큼 엄격하게 검사
- 권위 출처 vs 매트릭스: 사용자가 권위 표준(예: APA, 정부 가이드)을 명시하면 그것이 매트릭스 셀보다 우선
각 카테고리의 세부 항목은 references/[카테고리].md의 "장르별 권장 사항" 섹션 참조.
---
작업 흐름
1단계: 텍스트 받기 및 문서 타입 결정
텍스트 입력:
- 파일 경로가 주어지면 Read 도구를 사용하여 로드합니다
- 텍스트가 대화 컨텍스트에 있으면 추출합니다
- 여러 파일이 제공되면 프로젝트 전체 일관성을 검사합니다
문서 타입 결정 (3단계 우선순위):
1. 사용자 명시 우선: 입력에 "학술 논문", "비즈니스 보고서", "기술 문서", "블로그 글" 같은 명시 키워드가 있으면 그것을 사용 2. 자동 추정: 첫 300자에서 어조(~합니다 vs ~이다 vs ~해요), 용어 밀도, 인용 형식, 호격 사용 등으로 추정 3. 신뢰도 낮으면 명시 요청: 추정 신뢰도가 낮은 경우(짧은 텍스트, 모호한 어조, 혼합 형태) AskUserQuestion으로 4가지 중 선택 요청
4가지 문서 타입:
- 비즈니스/공문서: 격식체, 표준 용어, 일관된 날짜 형식
- 학술 논문: 엄격한 인용 형식, 전문 용어, 형식적 어조
- 기술 문서: IT 용어 통일, 코드 블록 스타일, 간결한 표현
- 마케팅/블로그: 브랜드 보이스, 독자 친화적 어조, 유연한 표현
결정된 타입은 §장르 매트릭스에 따라 카테고리별 기준 적용.
2단계: 7가지 카테고리 분석
우선순위 순서로 체계적으로 확인합니다:
우선순위 1 (최고): 어조 및 격식
- 경어체 혼용 (입니다 ↔ 이에요 ↔ 임)
- 주어 불일치 (우리 ↔ 저희)
- 문체 충돌 (격식 ↔ 구어체)
우선순위 2 (높음): 용어 통일
- 동일 개념 다른 표현 (사용자 ↔ 유저 ↔ 이용자)
- 외래어 표기 (웹사이트 ↔ 웹 사이트)
- 약어 사용 (데이터베이스 ↔ DB)
우선순위 3 (중간): 숫자/단위, 목록
- 숫자 표기 (3개 ↔ 세 개)
- 단위 띄어쓰기 (10 개 ↔ 10개)
- 목록 부호 (1. ↔ - ↔ •)
- 목록 종결어미 (합니다 ↔ 함 ↔ 생략)
우선순위 4 (낮음): 인용, 날짜, 링크
- 따옴표 ("" ↔ '' ↔ 「」)
- 날짜 형식 (2026년 1월 27일 ↔ 2026.01.27)
- 링크 스타일 (여기 클릭 ↔ 제목)
감지한 카테고리에 해당하는 상세 참조 파일을 로드하세요. 각 reference 파일에는 "장르별 권장 사항" 섹션이 있어 4가지 문서 타입별 기준을 제공합니다. 1단계에서 결정된 문서 타입과 §장르 매트릭스를 참조해 적용 기준을 결정하세요.
3단계: 불일치 식별 및 분석
감지된 각 불일치에 대해:
- 빈도 계산: 각 표현이 문서에 몇 번 등장하는지 세기
- 다수결 원칙: 가장 많이 사용된 표현을 기준으로 제안
- 문맥 고려: 문서 타입에 더 적합한 표현 판단
- 권위 출처: 해당되는 경우 표준 가이드(정부/학술/실무) 참조
4단계: 통일안 제시
- 다수결 기준: "사용자"(5회) vs "유저"(2회) → "사용자"로 통일
- 표준 우선: 공문서는 정부 표준, 논문은 학술 관례 우선
- 사용자 선호: 사용자가 선호를 명시하면 그에 따름
- 실용성: 지나치게 엄격한 기준보다 실무에서 통용되는 방식 선택
5단계: 결과 제시
출력 형식:
## 스타일 일관성 검사 결과
### 문서 타입 분석
- 판단: [비즈니스/학술/기술/마케팅]
- 결정 경로: [자동 추정 / 사용자 명시 / AskUserQuestion 응답]
- 근거: [문서 특징 설명]
- 적용 기준: [장르 매트릭스의 해당 컬럼 요약 — 예: 격식체, 표준 용어, `YYYY년 MM월 DD일`]
### 발견된 불일치 (총 N개)
#### 1. 어조 및 격식 (N개)
**불일치 #1: 경어체 혼용**
- 🔄 패턴 A: "~입니다" (5회 사용)
- 🔄 패턴 B: "~이에요" (2회 사용)
- ✅ 제안: 비즈니스 문서이므로 "~입니다"로 통일
- 📚 근거: [권위 출처 또는 다수결 원칙]
#### 2. 용어 통일 (N개)
**불일치 #2: 동일 개념 다른 표현**
- 🔄 "사용자" (8회) ↔ "유저" (3회) ↔ "이용자" (1회)
- ✅ 제안: "사용자"로 통일 (다수결 + 공식 문서에 적합)
- 📚 근거: 국립국어원 표준 용어
[모든 불일치에 대해 계속]
---
## 일관된 스타일 적용 버전
[통일된 스타일로 재작성된 전체 텍스트]
---
## 스타일 가이드 요약
[선택적] 프로젝트 전체에 적용할 수 있는 스타일 규칙 목록:
### 어조
- [ ] 경어체: "~입니다" 사용
### 용어
- [ ] "사용자" (not "유저")
- [ ] "데이터베이스" (not "DB")
### 형식
- [ ] 날짜: YYYY년 MM월 DD일
- [ ] 목록: "-" 부호 + "~합니다" 종결이미 일관적인 경우:
## 스타일 일관성 검사 결과
✅ 이 텍스트는 일관된 스타일을 유지하고 있습니다.
[사소한 개선사항이 있다면 언급]
문서가 단일 어조, 통일된 용어, 일관된 형식을 잘 따르고 있습니다.---
중요 지침
1. 다수결 원칙
같은 개념을 표현하는 여러 방식이 있을 때:
- 가장 많이 사용된 표현을 기준으로 제안
- 예: "사용자"(10회) vs "유저"(2회) → "사용자"로 통일
2. 문맥 고려
문서 타입에 따라 적절한 스타일이 다릅니다:
비즈니스/공문서:
- 격식체 (입니다, 합니다)
- 표준 용어 (사용자, 데이터베이스)
- YYYY년 MM월 DD일 날짜 형식
학술 논문:
- 격식체 (이다, 하다)
- 전문 용어 유지
- 일관된 인용 형식 (APA, MLA 등)
기술 문서:
- 간결한 표현
- IT 용어 통일 (API, SDK)
- 코드 블록 스타일 일관성
마케팅/블로그:
- 친근한 어조
- 브랜드 용어 우선
- 독자 참여형 표현
3. 권위 출처 참조
제안의 근거를 명확히 제시하세요:
🏛️ 정부 표준:
- 국립국어원 공문서 작성 지침
- 행정업무 운영 규정
- 공공언어 개선 가이드
📚 학술 표준:
- 대학 학위논문 작성 지침
- APA/MLA 인용 형식
💼 실무 표준:
- 대기업 스타일 가이드 (Kakao, Naver 등)
- 업계 모범 사례
4. 사용자 선호 최우선
- 사용자가 브랜드 가이드나 프로젝트 규칙을 명시하면 그것을 따르세요
- 예: "우리 회사는 '유저'를 사용합니다" → 유저로 통일
- 일반 표준보다 사용자 요구가 우선
5. 실용성 우선
- 지나치게 엄격한 기준을 강요하지 마세요
- 실무에서 널리 통용되는 방식을 인정하세요
- 사소한 불일치는 무시하고 명백한 패턴만 지적
6. 과도한 통일 피하기
다음 경우 일관성을 강요하지 마세요:
- 의도적인 강조나 대비
- 인용문이나 고유명사
- 문학적 표현이나 수사법
- 코드나 전문 용어
---
특수 상황 처리
여러 파일 검사
프로젝트 전체 일관성을 검사할 때: 1. 각 파일의 패턴을 먼저 분석 2. 프로젝트 전체에서 다수결 원칙 적용 3. 파일별로 수정 사항 정리 4. 프로젝트 전체 스타일 가이드 제안
브랜드 보이스 유지
사용자가 브랜드 가이드를 제공하면:
- 브랜드 용어집을 최우선 적용
- 톤 앤드 매너(tone and manner) 유지
- 브랜드 고유 표현 보존
다국어 문서
한국어와 영어가 혼재된 문서:
- 한국어 부분에만 일관성 검사 적용
- 영어 고유명사와 용어는 그대로 보존
- 외래어 표기법은 한국어 표준 따름
코드 및 기술 문서
코드가 포함된 문서:
- 코드 블록 내용은 검사하지 않음
- 주석과 문서화 부분만 검사
- 기술 용어는 업계 표준 따름
매우 짧은 텍스트
1-2문단의 짧은 텍스트:
## 스타일 일관성 검사 결과
**참고**: 텍스트가 짧아 패턴 분석이 제한적입니다.
[발견된 불일치만 간단히 나열]---
권위 출처 및 참조 표준
이 스킬은 다음 권위 있는 자료를 기반으로 합니다:
정부 공식 표준 (최고 권위)
- 국립국어원 쉬운 공문서 쓰기 길잡이 (2022)
- 국어기본법 제14조 (공문서 작성 표준)
- 한국공공언어진흥원 공공언어 개선 가이드
- 행정업무의 운영 및 혁신에 관한 규정
학술 표준
- 주요 대학 학위논문 작성 지침 (세종대, 경희대, 충북대 등)
- APA, MLA, Chicago, Vancouver 인용 형식
- 학술 논문 작성법 (서울대 온라인 글쓰기교실)
실무 표준
- Kakao Enterprise 기술문서 작성 가이드
- 정보통신기술용어해설 (IT 용어 표준)
- Docs for Developers 기술 문서 작성 가이드
상세한 출처 정보와 적용 기준은 각 카테고리별 참조 문서를 확인하세요.
---
예시
실제 적용 사례는 examples/ 디렉토리 참조:
- inconsistent.md: 다양한 불일치가 포함된 텍스트
- consistent.md: 일관된 스타일로 교정된 버전
- business-style.md: 비즈니스/공문서 일관성 시연 (v1.1.0 장르 매트릭스)
- academic-style.md: 학술 논문 일관성 시연 (APA 인용 + 영어 병기)
- tech-style.md: 기술 문서 일관성 시연 (ISO 날짜 + 인라인 코드)
- blog-style.md: 마케팅/블로그 일관성 시연 (이모지 + 친근 어조)
각 예시는 감지된 불일치, 분석, 통일안, 스타일 가이드를 포함합니다.
---
최종 확인사항
검사를 마치기 전 확인하세요:
- ✅ 문서 타입을 올바르게 판단했는가?
- ✅ 7가지 카테고리를 모두 검사했는가?
- ✅ 다수결 원칙을 적용했는가?
- ✅ 문맥에 맞는 제안을 했는가?
- ✅ 권위 출처를 참조했는가?
- ✅ 통일된 버전을 제공했는가?
- ✅ 과도한 통일을 피했는가?
당신의 목표는 문서가 일관된 스타일을 유지하여 독자에게 전문적이고 신뢰할 수 있는 인상을 주도록 돕는 것입니다. 스타일 일관성은 내용의 신뢰도를 높이고, 브랜드 정체성을 강화하며, 독자 경험을 개선합니다.
인공지능 윤리에 관한 연구 동향 분석
1. 서론
본 연구는 최근 인공지능 윤리 분야의 연구 동향을 체계적으로 분석한다. 분석 대상은 2020년부터 2025년까지 발표된 학술 논문 234건이다.
2. 연구 방법
2.1 문헌 검색
다음 데이터베이스를 활용하였다.
- 가. Web of Science (Clarivate)
- 나. Scopus (Elsevier)
- 다. Google Scholar
2.2 분석 프레임워크
본 연구는 Foucault (1977)의 권력-지식(power-knowledge) 관점을 적용한다.
3. 결과
분석 결과, 책임성(accountability) 담론이 전체의 47%를 차지하였으며 (Smith & Lee, 2023), 투명성(transparency) 논의가 31%로 그 뒤를 이었다.
4. 결론
본 연구의 결과는 AI 윤리 담론이 점차 책임성 중심으로 재편되고 있음을 시사한다.
---
v1.1.0 적용 기준: 학술 논문
| 카테고리 | 이 글에서 적용된 기준 |
|---|---|
| 어조 | ~이다/~한다 한다체, 본 연구·필자 |
| 용어 | 학술 용어 + 영어 원어 병기 (책임성/accountability) |
| 숫자·단위 | 엄격 아라비아 (234건, 47%) |
| 목록 | 가./나./다. 또는 1./2. 번호, ~함·명사구 종결 |
| 인용 | APA 정형 (Smith & Lee, 2023), 책 제목 이탤릭 |
| 날짜 | 2020년부터 2025년까지 한글 형식 |
일관성 평가: ✅ 일관됨. APA 인용·이탤릭·영어 병기 모두 학술 표준 준수.
스타일 일관성 분석 예시
이 문서는 inconsistent.md에서 consistent.md로 교정하는 과정에서 감지된 스타일 불일치와 교정 근거를 설명합니다.
---
문서 타입 분석
- 판단: 비즈니스 문서 (제품 소개서)
- 근거: 고객 대상, 공식적 톤, 제품 정보 포함
- 권장 스타일: 격식체 경어 (~합니다), 표준 용어, 일관된 날짜 형식
---
발견된 불일치 (총 23개)
1. 어조 및 격식 (3개)
불일치 #1: 경어체 혼용
- 🔄 "~합니다": 8회 사용
- 🔄 "~해요": 2회 사용 ("제공해요", "보호해요")
- ✅ 제안: 비즈니스 문서이므로 "~합니다" 격식체로 통일
- 📚 근거: 국립국어원 공문서 작성 지침 - 대외 문서는 격식체 사용
교정:
- "제공해요" → "제공합니다"
- "보호해요" → "보호합니다"
불일치 #2: 주어 불일치
- 🔄 "우리 회사": 1회 (문서 끝)
- 🔄 "저희 회사": 1회 (문서 시작)
- ✅ 제안: 고객 대상 문서이므로 "저희"로 통일 (겸양 표현)
- 📚 근거: 실무 관행 - 대외 문서는 겸손한 표현 사용
교정:
- "© 2026 우리 회사" → "© 2026 저희 회사"
불일치 #3: 문장 종결 불완전
- 🔄 "개발자는 SDK를 사용하여 기능 확장" (종결어미 없음)
- ✅ 제안: 완전한 문장으로 종결
- 📚 근거: 문법 규칙 - 문장은 종결어미로 끝나야 함
교정:
- "기능 확장" → "기능을 확장할 수 있습니다"
---
2. 용어 통일 (5개)
불일치 #4: 동일 개념 다른 표현
- 🔄 "사용자": 4회
- 🔄 "유저": 1회
- ✅ 제안: "사용자"로 통일 (다수결 + 공식 문서 표준)
- 📚 근거: 국립국어원 표준 용어
교정:
- "유저는 여러 기기에서..." → "사용자는 여러 기기에서..."
불일치 #5: 외래어 표기 - 띄어쓰기
- 🔄 "데이터 베이스": 1회 (띄어쓰기)
- 🔄 "웹사이트": 1회 (붙여쓰기)
- ✅ 제안: "데이터베이스", "웹사이트" 붙여쓰기로 통일
- 📚 근거: 국립국어원 외래어 표기법
교정:
- "데이터 베이스" → "데이터베이스"
불일치 #6: 띄어쓰기 오류 (의존명사)
- 🔄 "접근할수있습니다" (붙여쓰기 오류)
- ✅ 제안: "접근할 수 있습니다" (의존명사 "수" 띄어쓰기)
- 📚 근거: 국립국어원 띄어쓰기 규정
교정:
- "접근할수있습니다" → "접근할 수 있습니다"
불일치 #7: 외래어 약어
- 🔄 "Android OS" (공식 표기)
- 🔄 "Android" (축약)
- ✅ 제안: "Android"로 통일 (공식 제품명, OS 생략 가능)
- 📚 근거: Kakao Enterprise 가이드 - "AOS"는 비공식, "Android" 사용
교정:
- "Android OS" → "Android"
불일치 #8: 따옴표 혼용
- 🔄 큰따옴표 ("사용자"): 1회
- 🔄 작은따옴표 ('보안'): 1회
- ✅ 제안: 강조 표기는 굵게로 통일 (용어 강조에 따옴표 불필요)
- 📚 근거: 테크니컬 라이팅 가이드 - 강조는 굵게 또는 기울임
교정:
- "사용자" → 사용자 (따옴표 제거)
- '보안' → 보안 (굵게 처리)
---
3. 숫자 및 단위 (4개)
불일치 #9: 단위 띄어쓰기
- 🔄 "4 GB" (띄어쓰기): 1회
- 🔄 "500MB" (붙여쓰기): 1회
- ✅ 제안: SI 표기법에 따라 "4 GB", "500 MB" 띄어쓰기로 통일
- 📚 근거: 국제단위계(SI) 표기법
교정:
- "500MB" → "500 MB"
불일치 #10: 화폐 단위 띄어쓰기
- 🔄 "10,000 원" (띄어쓰기): 1회
- 🔄 "5만원" (붙여쓰기): 1회
- ✅ 제안: "10,000원", "50,000원"으로 통일 (아라비아 숫자 + 붙여쓰기)
- 📚 근거: 실무 관행
교정:
- "10,000 원" → "10,000원"
- "5만원" → "50,000원" (표기 형식 통일)
불일치 #11: 숫자 표기 혼용
- 🔄 "20%" (아라비아 숫자): 기본
- 🔄 "1년" (아라비아 + 한글): 관용 표현 허용
- ✅ 판단: 혼용 허용 (구체적 수치는 아라비아, 기간은 혼용 가능)
- 📚 근거: 실무 관행
교정 불필요
불일치 #12: 퍼센트 띄어쓰기
- 🔄 모두 "20%" (올바름)
- ✅ 판단: 일관적, 교정 불필요
---
4. 목록 구조 (2개)
불일치 #13: 목록 부호 혼용
- 🔄 "1. 2. 3.": 2개 목록
- 🔄 "1. - 3)": 1개 목록 (혼용)
- ✅ 제안: 모두 "1. 2. 3." 형식으로 통일
- 📚 근거: Markdown 관행 + 다수결
교정:
1. 빠른 처리 속도
- 메모리 효율성 개선 → 2. 메모리 효율성 개선
3) 직관적인 UI → 3. 직관적인 UI불일치 #14: 목록 종결어미 혼용
- 🔄 완전 문장 ("~합니다"): 2개 항목
- 🔄 명사형 ("계정 생성", "기능 확장"): 2개 항목
- 🔄 명령형 ("~하세요"): 1개 항목
- ✅ 제안: "~합니다" 완전 문장으로 통일
- 📚 근거: 문서의 격식적 톤 + 다수결
교정:
2. 계정 생성 → 2. 계정을 생성합니다.
3) 로그인하세요 → 3. 로그인합니다.
- 설정 메뉴에서 환경 설정 → 4. 설정 메뉴에서 환경을 설정합니다.---
5. 인용 및 강조 (3개)
불일치 #15: 강조 표기 혼용
- 🔄 굵게: 2회 ("혁신적인", "API")
- 🔄 기울임: 1회 ("데이터 베이스")
- 🔄 따옴표: 2회 ("사용자", '보안')
- 🔄 백틱: 1회 (
SDK) - ✅ 제안: 일반 강조는 굵게, 코드/명령어는 백틱(`)으로 구분
- 📚 근거: 테크니컬 라이팅 가이드
교정:
- 데이터 베이스 → 데이터베이스 (굵게 + 띄어쓰기 수정)
- "사용자" → 사용자 (따옴표 제거, 강조 불필요)
- '보안' → 보안 (굵게)
불일치 #16: 백틱 사용 불일치
- 🔄 API (굵게): 1회
- 🔄
SDK(백틱): 1회 - ✅ 제안: 기술 용어는 굵게, 코드 관련은 백틱 유지
- 📚 근거: API/SDK는 기술 용어이지 코드가 아님
교정:
- 일관성을 위해 둘 다 굵게 또는 둘 다 일반 텍스트
- 이 예시에서는 둘 다 굵게 처리
불일치 #17: 특수 강조 (하이라이트)
- 🔄 ==기밀== (하이라이트): 1회
- 🔄 ⚠️ (이모지): 1회
- ✅ 제안: 공식 문서이므로 굵게로 통일, 이모지 제거
- 📚 근거: 비즈니스 문서는 전문적 톤 유지
교정:
- "==기밀==입니다. ⚠️ 외부 유출 금지!" → "기밀입니다. 외부 유출을 금지합니다."
---
6. 날짜 및 시간 (3개)
불일치 #18: 날짜 형식 혼용
- 🔄 "YYYY년 MM월 DD일": 1회
- 🔄 "YYYY.MM.DD": 1회
- 🔄 "YYYY-MM-DD": 1회
- 🔄 "M월 D일" (연도 생략): 1회
- ✅ 제안: "YYYY년 MM월 DD일" 한글 형식으로 통일
- 📚 근거: 비즈니스 문서 관행 + 가독성
교정:
- "2026.02.15" → "2026년 2월 15일"
- "2026-03-01" → "2026년 3월 1일"
- "4월 1일" → "2026년 4월 1일" (문맥상 2026년 추가)
불일치 #19: 시간 형식 혼용
- 🔄 12시간제 ("오전 9시"): 1회
- 🔄 24시간제 ("18:00"): 1회
- 🔄 영어 ("10 AM ~ 3 PM"): 1회
- ✅ 제안: 12시간제 한글로 통일 (대중 독자 대상)
- 📚 근거: 가독성 + 한국 일상 관행
교정:
- "18:00" → "오후 6시"
- "10 AM ~ 3 PM" → "오전 10시부터 오후 3시"
불일치 #20: 시간 범위 표기
- 🔄 "~부터 ~까지": 1회
- 🔄 "~": 1회 (틸드)
- 🔄 "~": 1회 (물결표)
- ✅ 제안: 명확성을 위해 "~부터 ~까지" 사용
- 📚 근거: 명확한 의사소통
교정:
- "2026년 1월 15일 ~ 2026년 2월 15일" → "2026년 1월 15일부터 2026년 2월 15일까지"
---
7. 링크 및 참조 (3개)
불일치 #21: 링크 텍스트 혼용
- 🔄 설명적 텍스트: 0회
- 🔄 "여기": 1회
- 🔄 URL 직접 노출: 1회
- ✅ 제안: 모두 설명적 텍스트로 교체
- 📚 근거: 웹 접근성 가이드 - 스크린 리더 사용자 고려
교정:
불일치 #22: 참조 번호 형식 혼용
- 🔄 상첨자 (¹): 1회
- 🔄 대괄호 ([2]): 1회
- ✅ 제안: 대괄호 [1], [2] 형식으로 통일
- 📚 근거: 기술 문서 관행 (IEEE 스타일)
교정:
- "연구¹를" → "연구[1]를"
- 참고문헌 번호도 "[1]", "[2]"로 통일
불일치 #23: 참고문헌 표기 형식
- 🔄 한글 저자: 1개
- 🔄 영어 저자: 1개
- ✅ 제안: 형식 통일 (저자, 연도, 제목, 출판사)
- 📚 근거: 일관된 인용 형식
교정:
- 한글/영어 관계없이 동일한 형식 적용
- 따옴표 제거 (제목에 따옴표 불필요)
---
교정 요약
카테고리별 통계
| 카테고리 | 불일치 개수 | 주요 문제 |
|---|---|---|
| 어조 및 격식 | 3개 | 경어체 혼용, 주어 불일치 |
| 용어 통일 | 5개 | 사용자/유저, 외래어 띄어쓰기 |
| 숫자 및 단위 | 4개 | 단위 띄어쓰기, 화폐 표기 |
| 목록 구조 | 2개 | 부호 혼용, 종결어미 불일치 |
| 인용 및 강조 | 3개 | 강조 방법 혼용, 이모지 |
| 날짜 및 시간 | 3개 | 날짜 형식 혼용, 시간 형식 |
| 링크 및 참조 | 3개 | "여기" 사용, 참조 번호 혼용 |
| 합계 | 23개 |
교정 우선순위
1. 높음 (즉시 수정): 경어체 혼용, 목록 부호, 날짜 형식, 참조 번호 2. 중간 (권장 수정): 용어 통일, 단위 띄어쓰기, 링크 텍스트 3. 낮음 (선택 수정): 강조 표기 세부사항, 시간 범위 표현
---
스타일 가이드 권장사항
이 문서를 위한 프로젝트 스타일 가이드:
어조
- [x] 경어체: "~합니다" 사용
- [x] 주어: "저희" (고객 대상 문서)
용어
- [x] "사용자" (not "유저")
- [x] "데이터베이스" (붙여쓰기)
- [x] "웹사이트" (붙여쓰기)
- [x] "Android" (not "Android OS")
숫자 및 단위
- [x] 단위 띄어쓰기: "4 GB", "500 MB"
- [x] 화폐: "10,000원" (붙여쓰기)
- [x] 퍼센트: "20%" (붙여쓰기)
목록
- [x] 부호: "1. 2. 3."
- [x] 종결: "~합니다" 완전 문장
강조
- [x] 일반 강조: 굵게
- [x] 코드/명령어:
백틱 - [x] 이모지: 사용 자제
날짜 및 시간
- [x] 날짜: "YYYY년 MM월 DD일"
- [x] 시간: 12시간제 ("오전/오후")
링크
- [x] 설명적 텍스트 사용 (not "여기")
참조
- [x] 대괄호 번호: [1], [2]
---
이 가이드를 프로젝트 전체에 적용하면 문서의 일관성과 전문성이 크게 향상됩니다.
우리집 강아지가 알려준 5가지 행복 비결 🐶✨
안녕하세요, 여러분! 오늘은 정말 특별한 이야기를 들려드리려고 해요.
저희 집 강아지 '몽이'를 키운 지 벌써 3년이 됐는데요. 매일매일 몽이가 저에게 가르쳐준 것들이 정말 많거든요. 이걸 꼭 공유하고 싶어서 글을 써봤어요!
1. 매일이 새로운 모험! 🌟
몽이는 매일 산책을 가도 항상 새롭게 즐거워해요. 같은 길인데도 마치 처음 가는 것처럼!
2. 지금 이 순간을 즐기기
미래 걱정도, 과거 후회도 없이 지금 이 순간만 사는 모습. 정말 배울 게 많아요.
3. 사랑은 표현하는 것 💕
꼬리를 흔들고 폴짝 뛰면서 온몸으로 표현하는 사랑. 우리도 좀 더 표현해봐요!
4. 작은 것에 크게 감사하기
간식 하나, 짧은 산책 하나에도 정말 행복해하는 모습이 인상 깊어요.
5. 친구가 가장 소중해
다른 강아지를 만나면 너무 신나하는 몽이. 사람도 마찬가지죠?
여러분도 강아지에게 배운 점 있으면 댓글로 알려주세요~ 💬
---
v1.1.0 적용 기준: 마케팅/블로그
| 카테고리 | 이 글에서 적용된 기준 |
|---|---|
| 어조 | ~해요 비격식체, 호격(여러분), 친근함 |
| 용어 | 일상어, 브랜드 보이스 |
| 숫자·단위 | 자유 (3년, 5가지) |
| 목록 | 1./2. 번호 + 이모지 (🌟·💕) |
| 인용·강조 | 이모지로 강조 (🐶·✨·💬) |
| 날짜 | 자유 형식 (매일, 오늘) |
일관성 평가: ✅ 일관됨. 이모지·호격·~해요 어조가 블로그 톤에 자연스럽게 통일. 마케팅/블로그 장르에서는 어조 검사가 완화되므로 ~합니다 1~2회 혼용 등도 OK.
2026년 2분기 사업 실적 보고
1. 개요
본 보고서는 2026년 2분기 사업 실적을 정리하고 향후 계획을 제시합니다.
2. 주요 실적
매출은 전년 동기 대비 17% 증가한 1,234억 원을 기록했으며, 영업이익은 234억 원으로 상승했습니다.
3. 부문별 분석
- 국내 사업: 5 명의 신규 인력을 충원했고, 신규 고객사 12 곳을 확보했습니다.
- 해외 사업: 동남아 시장에서 25% 성장률을 달성했습니다.
4. 향후 계획
2026년 3분기에는 다음 사항을 추진합니다.
1. 신규 제품 출시 (예정일: 2026년 8월 15일) 2. 동남아 지사 추가 설립 3. AI 기술 도입 확대
5. 결론
전반적으로 안정적인 성장세를 유지하고 있으며, 향후에도 지속적인 성과를 기대합니다.
---
v1.1.0 적용 기준: 비즈니스/공문서
| 카테고리 | 이 글에서 적용된 기준 |
|---|---|
| 어조 | ~합니다 격식체 통일 |
| 용어 | "사용자/고객" 표준 한국어 |
| 숫자·단위 | 아라비아 + 단위 띄어쓰기 (5 명, 12 곳) |
| 목록 | 1./2. 번호, 완전체 종결 |
| 인용 | 큰따옴표(보수적) — 본 예시엔 없음 |
| 날짜 | YYYY년 MM월 DD일 (2026년 8월 15일) |
일관성 평가: ✅ 일관됨. 단위 띄어쓰기와 날짜 형식이 비즈니스 표준에 부합.
일관된 스타일로 교정된 텍스트 예시
다음은 스타일 가이드를 적용하여 일관되게 교정된 비즈니스 문서 예시입니다.
---
신제품 출시 안내
안녕하세요, 저희 회사의 새로운 제품을 소개합니다.
제품 개요
이 제품은 혁신적인 기능을 제공합니다. 사용자들은 다음과 같은 이점을 얻을 수 있습니다:
1. 빠른 처리 속도 2. 메모리 효율성 개선 3. 직관적인 UI
주요 특징
첫째, 이 애플리케이션은 실시간 데이터베이스 동기화를 지원합니다. 사용자는 여러 기기에서 동일한 정보에 접근할 수 있습니다.
둘째, 보안이 강화되었습니다. 암호화 기술을 통해 사용자 정보를 보호합니다.
셋째, API 통합이 용이합니다. 개발자는 SDK를 사용하여 기능을 확장할 수 있습니다.
기술 사양
- 지원 OS: Android, iOS
- 메모리: 4 GB 이상
- 저장 공간: 500 MB 필요
- 화면 해상도: 1920x1080 픽셀
가격 정보
기본 플랜은 10,000원이고, 프리미엄 플랜은 50,000원입니다. 1년 구독 시 20% 할인이 제공됩니다.
출시 일정
- 베타 테스트: 2026년 1월 15일 ~ 2026년 2월 15일
- 정식 출시: 2026년 3월 1일
- 첫 업데이트: 2026년 4월 1일
사용 방법
제품을 사용하려면 다음 단계를 따르세요:
1. 웹사이트에 접속합니다. 2. 계정을 생성합니다. 3. 로그인합니다. 4. 설정 메뉴에서 환경을 설정합니다.
자세한 내용은 사용자 가이드를 참조하세요. 추가 정보는 FAQ 페이지에서 확인할 수 있습니다.
고객 지원
문의 사항이 있으시면 오전 9시부터 오후 6시까지 상담이 가능합니다. 주말에는 오전 10시부터 오후 3시까지 운영합니다.
참고 문헌
본 제품은 다음 연구[1]를 기반으로 개발되었습니다. 추가 기술은 선행 연구[2]를 참고했습니다.
[1] 김철수 (2025). 혁신적 앱 개발. 기술 출판사. [2] Lee, Y. (2024). Mobile App Design. Tech Press.
---
중요: 이 문서는 기밀입니다. 외부 유출을 금지합니다.
© 2026 저희 회사
불일치가 있는 텍스트 예시
다음은 다양한 스타일 불일치가 포함된 비즈니스 문서 예시입니다.
---
신제품 출시 안내
안녕하세요, 저희 회사의 새로운 제품을 소개합니다.
제품 개요
이 제품은 혁신적인 기능을 제공해요. "사용자"들은 다음과 같은 이점을 얻을 수 있습니다:
1. 빠른 처리 속도
- 메모리 효율성 개선
3) 직관적인 UI
주요 특징
첫째, 이 애플리케이션은 실시간 데이터 베이스 동기화를 지원합니다. 유저는 여러 기기에서 동일한 정보에 접근할수있습니다.
둘째, '보안'이 강화되었습니다. 암호화 기술을 통해 사용자 정보를 보호해요.
셋째, API 통합이 용이합니다. 개발자는 SDK를 사용하여 기능 확장
기술 사양
- 지원 OS: Android OS, iOS
- 메모리: 4 GB 이상
- 저장 공간: 500MB 필요
- 화면 해상도: 1920x1080 픽셀
가격 정보
기본 플랜은 10,000 원이고, 프리미엄 플랜은 5만원입니다. 1년 구독 시 20% 할인 제공됩니다.
출시 일정
- 베타 테스트: 2026년 1월 15일 ~ 2026.02.15
- 정식 출시: 2026-03-01
- 첫 업데이트: 4월 1일
사용 방법
제품을 사용하려면 다음 단계를 따르세요:
1. 웹사이트에 접속합니다 2. 계정 생성 3) 로그인하세요
- 설정 메뉴에서 환경 설정
자세한 내용은 여기를 클릭하세요. 추가 정보는 https://example.com/faq 참조하세요.
고객 지원
문의 사항이 있으시면 오전 9시부터 18:00까지 상담이 가능합니다. 주말에는 10 AM ~ 3 PM 운영합니다.
참고 문헌
본 제품은 다음 연구¹를 기반으로 개발되었습니다. 추가 기술은 선행 연구[2]를 참고했습니다.
1. 김철수 (2025). "혁신적 앱 개발". 기술 출판사. [2] Lee, Y. (2024). Mobile App Design. Tech Press.
---
중요: 이 문서는 ==기밀==입니다. ⚠️ 외부 유출 금지!
© 2026 우리 회사
REST API 인증 가이드 (v2.0)
개요
본 문서는 REST API의 OAuth 2.0 기반 인증 절차를 설명합니다.
사전 준비
다음 항목을 준비합니다.
- API key (관리자에게 요청)
- HTTPS 클라이언트 (curl, Postman 등)
- JSON 처리 도구 (jq 권장)
인증 흐름
1. POST /oauth/token (client_id, client_secret)
2. Receive access_token (TTL: 3600초)
3. Use Authorization: Bearer <token> for all API calls예시 코드
curl -X POST https://api.example.com/oauth/token \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_KEY"응답:
{
"access_token": "eyJ...",
"expires_in": 3600,
"token_type": "Bearer"
}에러 처리
401 Unauthorized: token 만료 또는 부재403 Forbidden: 권한 부족429 Too Many Requests: 요청 한도 초과
변경 이력
- 2026-05-02: v2.0 출시
- 2026-04-15: v1.5 보안 패치
자세한 내용은 API 레퍼런스를 참조하세요.
---
v1.1.0 적용 기준: 기술 문서
| 카테고리 | 이 글에서 적용된 기준 |
|---|---|
| 어조 | ~합니다 + 명령형 ("준비합니다") 혼용 |
| 용어 | IT 약어 OK (API, HTTPS, OAuth, TTL, JSON) |
| 숫자·단위 | 자유 (3600초, 코드 맥락에서 raw) |
| 목록 | - 부호, 인라인 코드 항목 |
| 인용 | 인라인 코드 ` code ` 우선 |
| 날짜 | YYYY-MM-DD ISO (2026-05-02) |
| 링크 | [제목](URL) 인라인 |
일관성 평가: ✅ 일관됨. ISO 날짜·인라인 코드·영어 약어 모두 기술 문서 표준.
날짜, 시간 및 참조 형식
이 문서는 한국어 문서에서 날짜, 시간, 참조를 일관되게 표기하기 위한 패턴과 기준을 설명합니다.
패턴 16: 날짜 형식
메타데이터:
- 출처: 국제 표준(ISO 8601), 한국 공문서 관행
- 권위: 🏛️ 국제 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
날짜 표기 방식이 일관적이지 않으면 독자가 혼란을 느끼고, 특히 국제 문서에서는 오해의 소지가 있습니다.
주요 날짜 형식
1. 한글 표기 (YYYY년 MM월 DD일)
사용처: 공문서, 비즈니스 문서, 일반 한국어 문서
✅ 올바른 예시:
2026년 1월 27일
2026년 1월 1일
2026년 12월 31일변형:
✅ 연도 생략 (같은 해):
1월 27일
✅ 요일 추가:
2026년 1월 27일(월요일)
2026년 1월 27일 월요일2. 점(.) 구분 (YYYY.MM.DD)
사용처: 간결한 표기, 양식, 로그
✅ 올바른 예시:
2026.01.27
2026.1.27 (월 자릿수 가변)3. 하이픈(-) 구분 (YYYY-MM-DD)
사용처: ISO 8601 국제 표준, 기술 문서, 데이터베이스
✅ 올바른 예시:
2026-01-27장점:
- 국제 표준이므로 다국어 문서에 적합
- 정렬 시 시간순 자동 정렬
- 프로그래밍에서 표준 형식
4. 슬래시(/) 구분
주의: 국가별로 순서가 다름
- 미국: MM/DD/YYYY (01/27/2026)
- 유럽: DD/MM/YYYY (27/01/2026)
- 혼란 방지를 위해 한국 문서에서는 비권장
⚠️ 혼란 가능:
01/27/2026 (미국식)
27/01/2026 (유럽식)
2026/01/27 (동아시아식)혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"프로젝트는 2026년 1월 27일에 시작하여 2026.02.15에 종료됩니다.
중간 점검은 2026-03-10입니다."
→ 세 가지 형식 혼용
✅ 교정 (한글 표기):
"프로젝트는 2026년 1월 27일에 시작하여 2026년 2월 15일에 종료됩니다.
중간 점검은 2026년 3월 10일입니다."
✅ 교정 (ISO 8601):
"프로젝트는 2026-01-27에 시작하여 2026-02-15에 종료됩니다.
중간 점검은 2026-03-10입니다."문서 타입별 권장 형식
| 문서 타입 | 권장 형식 | 예시 | 근거 |
|---|---|---|---|
| 공문서 | YYYY년 MM월 DD일 | 2026년 1월 27일 | 한국 공문서 관행 |
| 비즈니스 문서 | YYYY년 MM월 DD일 | 2026년 1월 27일 | 가독성 |
| 기술 문서 | YYYY-MM-DD | 2026-01-27 | ISO 8601 |
| 학술 논문 | YYYY년 MM월 DD일 | 2026년 1월 27일 | 학술 관행 |
| 로그/데이터 | YYYY-MM-DD | 2026-01-27 | 국제 표준 |
교정 전략
1. 문서 타입 확인: 공문서/비즈니스는 한글, 기술 문서는 ISO 8601 2. 다수결 원칙: 문서에서 가장 많이 사용된 형식으로 통일 3. 국제 표준 고려: 다국어 문서는 ISO 8601 (YYYY-MM-DD) 권장 4. 일관성: 한 문서 내에서 하나의 형식만 사용
---
패턴 17: 시간 형식
메타데이터:
- 출처: 국제 표준(ISO 8601), 한국 일상 관행
- 권위: 🏛️ 국제 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
시간 표기 방식이 일관적이지 않으면 특히 12시간제/24시간제 혼용 시 오해의 소지가 있습니다.
주요 시간 형식
1. 12시간제 (오전/오후)
사용처: 일상 대화, 일반 문서
✅ 올바른 예시:
오전 9시
오후 3시 30분
오전 11시 45분
변형:
오전 9:00
오후 3:30주의:
❌ 혼란 가능:
AM 9시, PM 3시 (한글과 영어 혼용)
✅ 교정:
오전 9시, 오후 3시
또는 9 AM, 3 PM (영어 문서)2. 24시간제
사용처: 공식 문서, 기술 문서, 국제 표준
✅ 올바른 예시:
09:00
15:30
23:45
ISO 8601 형식:
15:30:00 (초 포함)
15:30:00+09:00 (시간대 포함)3. 한글 표기
사용처: 격식 있는 문서
✅ 올바른 예시:
오전 9시 30분
오후 3시
저녁 6시 45분혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"회의는 오전 9시에 시작하여 15:30에 종료됩니다.
점심은 12:00pm입니다."
→ 12시간제, 24시간제, AM/PM 혼용
✅ 교정 (12시간제):
"회의는 오전 9시에 시작하여 오후 3시 30분에 종료됩니다.
점심은 오후 12시입니다."
✅ 교정 (24시간제):
"회의는 09:00에 시작하여 15:30에 종료됩니다.
점심은 12:00입니다."시간대 표기
한국 표준시:
✅ 올바른 예시:
2026-01-27 15:30 KST
2026-01-27T15:30:00+09:00 (ISO 8601)국제 문서:
✅ 올바른 예시:
15:30 UTC
15:30 GMT
15:30 EST문서 타입별 권장 형식
| 문서 타입 | 권장 형식 | 예시 | 근거 |
|---|---|---|---|
| 공문서 | 오전/오후 | 오전 9시 30분 | 한국 관행 |
| 비즈니스 일정 | 오전/오후 또는 24시간 | 오후 3시 또는 15:00 | 명확성 |
| 기술 문서/로그 | 24시간제 | 15:30:00 | ISO 8601 |
| 국제 문서 | 24시간제 + 시간대 | 15:30 KST | 국제 표준 |
교정 전략
1. 대상 독자: 일반 대중은 12시간제, 기술 문서는 24시간제 2. 다수결 원칙: 문서에서 더 많이 사용된 형식으로 통일 3. 명확성: 오후 12시(정오)는 "12:00" 또는 "정오"로 명시 4. 국제 표준: 다국어 문서는 24시간제 + 시간대 표기
---
패턴 18: 링크 및 URL 표기
메타데이터:
- 출처: Markdown 스타일 가이드, 웹 접근성 가이드
- 권위: 💼 실무 표준
- 버전: 1.0.0
설명
링크 텍스트가 일관적이지 않으면 독자 경험이 저하되고, 웹 접근성도 떨어집니다.
주요 링크 스타일
1. 설명적 링크 텍스트 (권장)
Markdown: [설명 텍스트](URL)
✅ 올바른 예시:
자세한 내용은 [국립국어원 공식 사이트](https://www.korean.go.kr/)를 참조하세요.
[기술 문서 작성 가이드](https://tech.kakaoenterprise.com/105)에서 확인할 수 있습니다.장점:
- 링크 대상이 명확
- 스크린 리더 사용자에게 도움
- SEO 최적화
2. URL 직접 노출 (비권장)
❌ 잘못된 예시:
자세한 내용은 https://www.korean.go.kr/를 참조하세요.예외 (허용):
- 인쇄물이나 URL을 명시해야 하는 경우
- 짧고 의미 있는 URL (예: example.com)
3. "여기", "클릭" 같은 모호한 텍스트 (비권장)
❌ 잘못된 예시:
자세한 내용은 [여기](https://www.korean.go.kr/)를 클릭하세요.
더 알아보려면 [이곳](https://example.com)을 참조하세요.문제점:
- 링크 대상 불명확
- 스크린 리더 사용자에게 무의미
- 웹 접근성 저하
혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"자세한 내용은 [여기](URL1)를 참조하세요.
추가 정보는 URL2에 있습니다.
[기술 문서](URL3)도 확인하세요."
→ "여기", URL 직접, 설명 텍스트 혼용
✅ 교정:
"자세한 내용은 [공식 가이드](URL1)를 참조하세요.
추가 정보는 [FAQ 페이지](URL2)에 있습니다.
[기술 문서](URL3)도 확인하세요."교정 전략
1. 설명적 텍스트: 링크 대상이 명확하도록 설명 포함 2. 동작 동사 피하기: "클릭", "여기" 같은 모호한 표현 자제 3. 일관성: 같은 종류의 링크는 같은 스타일 사용 4. 접근성: 스크린 리더 사용자를 고려
---
패턴 19: 각주 및 참조 번호
메타데이터:
- 출처: 학술 논문 작성 지침, 인용 형식 가이드 (APA, MLA)
- 권위: 📚 학술 표준
- 버전: 1.0.0
설명
각주나 참조 번호 형식이 일관적이지 않으면 학술적 신뢰도가 떨어집니다.
주요 참조 형식
1. 상첨자 번호 [¹, ², ³]
사용처: 학술 논문, 출판물
✅ 올바른 예시:
본 연구는 선행 연구¹를 기반으로 한다.
결과는 유의미했다.²
참고문헌:
1. 김철수 (2025). 연구 제목. 출판사.
2. 이영희 (2024). 논문 제목. 학술지, 10(2), 123-145.2. 대괄호 번호 [1], [2], [3]
사용처: 기술 문서, 학술 논문
✅ 올바른 예시:
본 연구는 선행 연구[1]를 기반으로 한다.
결과는 유의미했다[2].
참고문헌:
[1] 김철수 (2025). 연구 제목. 출판사.
[2] 이영희 (2024). 논문 제목. 학술지, 10(2), 123-145.3. 괄호 번호 (1), (2), (3)
사용처: 일반 문서, 보고서
✅ 올바른 예시:
본 보고서는 다음을 참고했다(1).
참고문헌:
(1) 김철수 (2025). 연구 제목. 출판사.4. 저자-연도 (APA 스타일)
사용처: 심리학, 교육학, 사회과학
✅ 올바른 예시:
선행 연구(김철수, 2025)에 따르면...
이영희(2024)는 다음과 같이 주장했다.
참고문헌:
김철수. (2025). 연구 제목. 출판사.
이영희. (2024). 논문 제목. 학술지, 10(2), 123-145.혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"선행 연구¹에 따르면 중요하다. 다른 연구[2]도 이를 뒷받침한다.
또 다른 연구(Kim, 2024)도 동의한다."
→ 상첨자, 대괄호, 저자-연도 혼용
✅ 교정 (대괄호 번호):
"선행 연구[1]에 따르면 중요하다. 다른 연구[2]도 이를 뒷받침한다.
또 다른 연구[3]도 동의한다."문서 타입별 권장 형식
| 문서 타입 | 권장 형식 | 예시 | 근거 |
|---|---|---|---|
| 인문학 논문 | 상첨자 또는 각주 | ¹, ² | MLA, Chicago |
| 사회과학 논문 | 저자-연도 | (김철수, 2025) | APA |
| 자연과학 논문 | 대괄호 번호 | [1], [2] | Vancouver |
| 기술 문서 | 대괄호 번호 | [1], [2] | IEEE |
교정 전략
1. 학문 분야: 분야별 표준 인용 형식 따르기 2. 일관성: 문서 전체에서 하나의 형식만 사용 3. 순서: 등장 순서대로 번호 매기기 4. 완전성: 모든 참조에 대응하는 참고문헌 항목 확인
---
실전 적용
검사 순서
1. 날짜 형식 전수 조사 (YYYY년 MM월 DD일, YYYY-MM-DD 등) 2. 시간 형식 확인 (12시간제/24시간제) 3. 링크 스타일 확인 (설명 텍스트/"여기"/URL 노출) 4. 참조 번호 형식 확인 (상첨자/대괄호/저자-연도) 5. 빈도 계산 및 다수결 적용 6. 통일안 제시
보고 형식
## 날짜, 시간 및 참조 불일치
**불일치 #16: 날짜 형식 혼용**
- 🔄 "YYYY년 MM월 DD일": 8회
- 🔄 "YYYY.MM.DD": 3회
- 🔄 "YYYY-MM-DD": 2회
- ✅ 제안: "YYYY년 MM월 DD일" 한글 표기로 통일
- 📚 근거: 비즈니스 문서 관행 + 다수결
**불일치 #17: 시간 형식 혼용**
- 🔄 12시간제 (오전/오후): 6회
- 🔄 24시간제: 4회
- ✅ 제안: 12시간제로 통일 (대중 독자 대상)
- 📚 근거: 가독성 + 다수결
**불일치 #18: 링크 텍스트**
- 🔄 설명적 텍스트: 5개
- 🔄 "여기"/"클릭": 3개
- ✅ 제안: 모두 설명적 텍스트로 교체
- 📚 근거: 웹 접근성 가이드---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 날짜 형식 | YYYY년 MM월 DD일 | YYYY년 MM월 DD일 | YYYY-MM-DD ISO | 자유 ('26.5.2, 5/2) |
| 시간 형식 | 24시간제 (14:30) | 24시간제 | ISO 24시간 (14:30:00Z) | 자유 (오후 2시 OK) |
| 시제 표현 | 격식 시제 | 학술 시제 (~이었다·하였다) | 자유 | 자유 |
| 상대 시간 | 2026년 5월 기준 | 정확 시점 명시 | at v2.0, build 1234 가능 | 오늘, 방금 전 OK |
핵심 가이드: 학술은 정확한 시점 표기 (인용 시 발행 연월일까지). 비즈니스는 한글 형식 (YYYY년 MM월 DD일). 기술은 ISO 8601 (YYYY-MM-DD, 14:30:00Z). 마케팅은 자유. 차등 우선순위: 학술에서 날짜 정확성은 우선순위 2, 마케팅에서는 우선순위 4로 완화. 다만 한 문서 안에서는 형식 일관 유지가 모든 장르에 공통.
---
참고 자료
목록 및 구조 스타일
이 문서는 한국어 문서에서 목록과 구조적 요소를 일관되게 표기하기 위한 패턴과 기준을 설명합니다.
패턴 10: 목록 부호 일관성
메타데이터:
- 출처: 대학 학위논문 작성 지침, 테크니컬 라이팅 가이드
- 권위: 📚 학술 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
목록을 나타내는 부호가 일관적이지 않으면 문서의 구조가 명확하지 않아 보입니다.
주요 목록 부호
1. 순서 있는 목록
아라비아 숫자 + 마침표:
✅ 올바른 예시:
1. 첫 번째 항목
2. 두 번째 항목
3. 세 번째 항목아라비아 숫자 + 닫는 괄호:
✅ 올바른 예시:
1) 첫 번째 항목
2) 두 번째 항목
3) 세 번째 항목한글 숫자 (드물게 사용):
✅ 올바른 예시:
가. 첫 번째 항목
나. 두 번째 항목
다. 세 번째 항목2. 순서 없는 목록
하이픈 (-):
✅ 올바른 예시:
- 첫 번째 항목
- 두 번째 항목
- 세 번째 항목불릿 (•):
✅ 올바른 예시:
• 첫 번째 항목
• 두 번째 항목
• 세 번째 항목*별표 ()**:
✅ 올바른 예시:
* 첫 번째 항목
* 두 번째 항목
* 세 번째 항목혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"다음 단계를 따르세요:
1. 로그인합니다
- 설정을 확인합니다
3) 변경 사항을 저장합니다"
→ "1.", "-", "3)" 혼용
✅ 교정:
"다음 단계를 따르세요:
1. 로그인합니다
2. 설정을 확인합니다
3. 변경 사항을 저장합니다"계층 구조 (혼용 허용):
✅ 허용되는 예시:
1. 첫 번째 대분류
- 세부 항목 1
- 세부 항목 2
2. 두 번째 대분류
- 세부 항목 1
- 세부 항목 2문서 타입별 권장 부호
| 문서 타입 | 순서 있음 | 순서 없음 | 근거 |
|---|---|---|---|
| 학술 논문 | 1., 2., 3. | - | 대학 작성 지침 |
| 공문서 | 가., 나., 다. 또는 1., 2., 3. | - | 행정 관행 |
| 기술 문서 | 1., 2., 3. | - 또는 • | Markdown 관행 |
| 마케팅/프레젠테이션 | 1, 2, 3 또는 • | • | 시각적 효과 |
교정 전략
1. 다수결 원칙: 문서에서 가장 많이 사용된 부호로 통일 2. 일관성 최우선: 같은 수준의 목록은 같은 부호 사용 3. 계층 구분: 상위/하위 수준은 다른 부호 사용 가능 4. 단순함: 복잡한 계층보다 단순한 구조 선호
---
패턴 11: 목록 항목 종결어미
메타데이터:
- 출처: 테크니컬 라이팅 가이드, 대학 작성 지침
- 권위: 📚 학술 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
목록 항목의 문장 종결 방식이 일관적이지 않으면 독자가 혼란을 느낍니다.
주요 종결 패턴
1. 완전한 문장 (종결어미 포함)
"-습니다/-ㅂ니다" 체:
✅ 올바른 예시:
1. 시스템에 로그인합니다.
2. 설정 메뉴를 엽니다.
3. 변경 사항을 저장합니다."-한다" 체:
✅ 올바른 예시:
1. 시스템에 로그인한다.
2. 설정 메뉴를 연다.
3. 변경 사항을 저장한다."-해요" 체:
✅ 올바른 예시:
1. 시스템에 로그인해요.
2. 설정 메뉴를 열어요.
3. 변경 사항을 저장해요.2. 명사형 종결 (어미 생략)
명사로 끝나기:
✅ 올바른 예시:
1. 시스템 로그인
2. 설정 메뉴 열기
3. 변경 사항 저장"-하기/-되기" 형태:
✅ 올바른 예시:
1. 로그인하기
2. 설정 메뉴 열기
3. 변경 사항 저장하기3. 명령형
"-세요" 형태:
✅ 올바른 예시:
1. 시스템에 로그인하세요.
2. 설정 메뉴를 여세요.
3. 변경 사항을 저장하세요."-하라/-하시오" 형태 (공문서):
✅ 올바른 예시:
1. 시스템에 로그인하라.
2. 설정 메뉴를 열어라.
3. 변경 사항을 저장하라.혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"다음 단계를 따르세요:
1. 로그인합니다
2. 설정 메뉴 열기
3. 변경 사항을 저장하세요"
→ "~합니다", "명사형", "~하세요" 혼용
✅ 교정 (완전 문장):
"다음 단계를 따르세요:
1. 로그인합니다.
2. 설정 메뉴를 엽니다.
3. 변경 사항을 저장합니다."
✅ 교정 (명사형):
"다음 단계를 따르세요:
1. 로그인
2. 설정 메뉴 열기
3. 변경 사항 저장"
✅ 교정 (명령형):
"다음 단계를 따르세요:
1. 로그인하세요.
2. 설정 메뉴를 여세요.
3. 변경 사항을 저장하세요."문서 타입별 권장 종결
| 문서 타입 | 권장 종결 | 예시 | 근거 |
|---|---|---|---|
| 공문서 | -한다/-하라 | "제출한다", "확인하라" | 공식 문서 관행 |
| 학술 논문 | -한다/-이다 | "분석한다", "결과이다" | 학술 작성 지침 |
| 사용자 매뉴얼 | -세요/-하기 | "클릭하세요", "저장하기" | 사용자 친화성 |
| 기술 문서 | 명사형 또는 -한다 | "실행", "설정한다" | 간결성 |
| 프레젠테이션 | 명사형 | "매출 증가", "비용 절감" | 시각적 효과 |
교정 전략
1. 도입문 확인: "다음을 수행하세요" → 명령형 목록 예상 2. 다수결 원칙: 문서에서 가장 많이 사용된 종결 방식으로 통일 3. 문서 타입: 위 표를 참조하여 적절한 종결 선택 4. 일관성: 모든 목록 항목을 동일한 방식으로 종결
---
패턴 12: 단락 제목 스타일
메타데이터:
- 출처: Markdown 스타일 가이드, 테크니컬 라이팅 가이드
- 권위: 💼 실무 표준
- 버전: 1.0.0
설명
제목의 계층 구조와 표기 방식이 일관적이지 않으면 문서의 구조를 파악하기 어렵습니다.
제목 계층
Markdown 스타일:
✅ 올바른 예시:
# 1단계 제목 (가장 큰 제목)
## 2단계 제목
### 3단계 제목
#### 4단계 제목숫자 계층:
✅ 올바른 예시:
1. 대제목
1.1. 중제목
1.1.1. 소제목제목 종결어미
명사형 (권장):
✅ 올바른 예시:
## 시스템 개요
## 설치 방법
## 사용 가이드완전 문장 (비권장):
❌ 잘못된 예시:
## 시스템 개요를 소개합니다
## 설치 방법을 설명합니다
→ 제목은 간결하게 명사형으로혼용 사례
❌ 잘못된 예시:
"# 시스템 개요
## 설치 방법을 설명합니다
### 설정
## 사용"
→ 종결 방식 혼용, 계층 순서 문제
✅ 교정:
"# 시스템 개요
## 설치 방법
### 기본 설정
## 사용 가이드"교정 전략
1. 명사형 우선: 제목은 간결하게 명사형으로 2. 계층 준수: 1단계 → 2단계 → 3단계 순서 유지 3. 일관성: 같은 수준의 제목은 같은 스타일 사용
---
실전 적용
검사 순서
1. 목록 부호 전수 조사 (1., -, •, * 등) 2. 목록 항목 종결어미 확인 (~합니다, 명사형, ~하세요) 3. 제목 계층 및 스타일 확인 4. 빈도 계산 및 다수결 적용 5. 통일안 제시
보고 형식
## 목록 및 구조 불일치
**불일치 #10: 목록 부호 혼용**
- 🔄 "1., 2., 3.": 5개 목록
- 🔄 "-, -, -": 3개 목록
- ✅ 제안: "1., 2., 3." 스타일로 통일 (다수결)
- 📚 근거: 기술 문서 관행
**불일치 #11: 목록 종결어미 혼용**
- 🔄 "~합니다": 10개 항목
- 🔄 명사형: 5개 항목
- 🔄 "~하세요": 2개 항목
- ✅ 제안: "~합니다" 완전 문장으로 통일
- 📚 근거: 다수결 + 문서의 격식적 톤---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 목록 부호 | 1./2. 번호 | 1./2. 또는 (가)/(나) | -, *, 번호 자유 | 이모지 OK (✅·❌·💡) |
| 종결어미 | 완전체 ~합니다 | ~함, 명사구, 한자어 OK | 자유 (생략 OK) | 자유, 이모지 강조 |
| 들여쓰기 | 2~4칸 일관 | 2칸 엄격 | 자유 (2칸 또는 4칸) | 자유 |
| 중첩 깊이 | 2단계 권장 | 3단계까지 | 자유 | 1단계 권장 (가독성) |
핵심 가이드: 비즈니스·학술은 종결어미 완전체로 통일. 기술·마케팅은 자유롭되 한 목록 안에서는 일관. 마케팅에서 이모지 부호(✅/❌/💡)는 OK이지만 비즈니스/공문서에선 부적절. 차등 우선순위: 비즈니스·학술에서는 목록 구조 검사가 우선순위 2, 기술·마케팅에서는 우선순위 3~4.
---
참고 자료
숫자 및 단위 표기
이 문서는 한국어 문서에서 숫자와 단위를 일관되게 표기하기 위한 패턴과 기준을 설명합니다.
패턴 7: 아라비아 숫자 vs 한글 숫자
메타데이터:
- 출처: 국립국어원 표기 지침, 대학 학위논문 작성 지침
- 권위: 🏛️ 정부 표준 + 📚 학술 표준
- 버전: 1.0.0
설명
한국어에서 숫자는 아라비아 숫자(1, 2, 3)와 한글 숫자(하나, 둘, 셋 또는 일, 이, 삼)로 표기할 수 있습니다. 동일 문서 내에서 혼용하면 일관성이 떨어집니다.
숫자 표기 원칙
1. 아라비아 숫자를 쓰는 경우
통계, 수치 데이터:
✅ 올바른 예시:
"실험 결과 3명의 참가자가 5개 항목에서 평균 4.2점을 받았습니다."날짜, 시간:
✅ 올바른 예시:
"2026년 1월 27일 오후 3시 30분"측정값, 단위:
✅ 올바른 예시:
"길이는 15cm, 무게는 2.5kg입니다."금액:
✅ 올바른 예시:
"가격은 10,000원입니다."순서가 있는 목록:
✅ 올바른 예시:
"1. 첫 번째 단계"
"2. 두 번째 단계"2. 한글 숫자를 쓰는 경우
관용적 표현:
✅ 올바른 예시:
"한두 번", "두세 개", "서너 명"
(×: "1~2번", "2~3개", "3~4명")강조나 문학적 표현:
✅ 올바른 예시:
"하나밖에 없는 기회"
"첫 번째이자 마지막 기회"추상적 개념:
✅ 올바른 예시:
"하나의 목표", "두 가지 선택"혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"참가자는 3명이었고, 각자 두 개의 과제를 완료했습니다.
총 6개 과제 중 다섯 개가 성공했습니다."
→ "3명/두 개/6개/다섯 개" 혼용
✅ 교정 (아라비아 숫자):
"참가자는 3명이었고, 각자 2개의 과제를 완료했습니다.
총 6개 과제 중 5개가 성공했습니다."
✅ 교정 (한글 숫자, 덜 일반적):
"참가자는 세 명이었고, 각자 두 개의 과제를 완료했습니다.
총 여섯 개 과제 중 다섯 개가 성공했습니다."관용 표현은 예외 (혼용 허용):
✅ 허용되는 예시:
"5명의 참가자 중 한두 명이 실패했습니다."
→ "5명"(구체적 수치)과 "한두 명"(관용 표현)은 구분문서 타입별 권장 표기
| 문서 타입 | 권장 표기 | 근거 |
|---|---|---|
| 기술 문서, 보고서 | 아라비아 숫자 | 정확성, 가독성 |
| 공문서 | 아라비아 숫자 (중요 금액은 한글 병기) | 행정업무 운영 규정 |
| 학술 논문 | 아라비아 숫자 | 학위논문 작성 지침 |
| 마케팅, 문학 | 문맥에 따라 혼용 가능 | 표현의 자유 |
교정 전략
1. 문서 타입 확인: 기술/학술 문서는 아라비아 숫자 우선 2. 다수결 원칙: 문서에서 더 많이 사용된 방식으로 통일 3. 관용 표현 보존: "한두 번", "두세 개" 같은 관용구는 그대로 유지 4. 일관성: 같은 종류의 수치는 같은 방식으로 표기
---
패턴 8: 단위 띄어쓰기
메타데이터:
- 출처: 국립국어원 띄어쓰기 규정, 국제단위계(SI) 표기법
- 권위: 🏛️ 정부 표준 + 📚 국제 표준
- 버전: 1.0.0
설명
숫자와 단위 사이의 띄어쓰기가 일관적이지 않으면 전문성이 떨어집니다.
단위 띄어쓰기 원칙
1. 띄어쓰는 단위
물리량 단위 (SI 단위계):
✅ 올바른 예시:
"10 km", "5 kg", "3 L", "20 °C", "100 W"
❌ 잘못된 예시:
"10km", "5kg", "3L"화폐 단위:
✅ 올바른 예시:
"10,000 원", "100 달러"
❌ 잘못된 예시:
"10,000원", "100달러"시간 단위 (시, 분, 초):
✅ 올바른 예시:
"3 시간", "30 분", "45 초"
❌ 잘못된 예시:
"3시간", "30분", "45초"2. 붙여쓰는 단위
의존명사 단위:
✅ 올바른 예시:
"3개", "5명", "10권", "2번"
❌ 잘못된 예시:
"3 개", "5 명", "10 권", "2 번"퍼센트 (%):
✅ 올바른 예시:
"50%", "3.5%"
❌ 잘못된 예시:
"50 %", "3.5 %"도 (각도, 온도의 ℃):
✅ 올바른 예시:
"90°", "25℃"
참고: SI 표기법은 "25 °C" (띄어쓰기)를 권장하지만,
한국에서는 "25℃" (붙여쓰기)도 널리 통용됨혼용 사례
명백한 불일치:
❌ 잘못된 예시:
"무게는 5 kg이고, 길이는 3m입니다."
→ "5 kg"(띄어쓰기)과 "3m"(붙여쓰기) 혼용
✅ 교정:
"무게는 5 kg이고, 길이는 3 m입니다."의존명사 혼용:
❌ 잘못된 예시:
"참가자는 3명이고, 과제는 5 개입니다."
→ "3명"(붙여쓰기)과 "5 개"(띄어쓰기) 혼용
✅ 교정:
"참가자는 3명이고, 과제는 5개입니다."특수 사례
복합 단위
곱셈 단위:
✅ 올바른 예시:
"면적은 10 m²입니다."
"속도는 60 km/h입니다."범위 표현:
✅ 올바른 예시:
"온도는 20~25 °C입니다."
"3~5개월"한글 단위
한글로 쓴 단위는 띄어쓰기:
✅ 올바른 예시:
"3 시간", "5 미터", "10 킬로그램"
❌ 잘못된 예시:
"3시간", "5미터", "10킬로그램"문서 타입별 권장 표기
| 문서 타입 | 권장 표기 | 근거 |
|---|---|---|
| 과학/기술 논문 | SI 표기법 (띄어쓰기) | 국제 표준 |
| 일반 문서 | 한국 관행 (℃ 붙여쓰기 등 허용) | 실무 통용 |
| 공문서 | 국립국어원 띄어쓰기 규정 | 정부 표준 |
교정 전략
1. SI 단위: 원칙적으로 띄어쓰기 ("5 kg", "20 °C") 2. 의존명사: 붙여쓰기 ("3개", "5명") 3. 일관성: 문서 내에서 같은 방식 유지 4. 실용성: 지나치게 엄격한 적용보다 통용되는 방식 인정
---
패턴 9: 숫자 표기 형식
메타데이터:
- 출처: 실무 관행, 국제 표준
- 권위: 💼 실무 표준
- 버전: 1.0.0
설명
큰 숫자의 자릿수 표기, 소수점 표기 등이 일관적이지 않으면 가독성이 떨어집니다.
천 단위 구분
쉼표 사용:
✅ 올바른 예시:
"1,000", "10,000", "1,000,000"
❌ 잘못된 예시:
"1000", "10000", "1000000"한글 단위 (선택적):
✅ 올바른 예시:
"1만", "10만", "100만"
혼용 피하기:
❌ "가격은 10,000원에서 5만 원 사이입니다."
✅ "가격은 1만 원에서 5만 원 사이입니다."
또는 "가격은 10,000원에서 50,000원 사이입니다."소수점 표기
점(.) 사용:
✅ 올바른 예시:
"3.14", "2.5 kg", "0.5%"
❌ 잘못된 예시:
"3,14" (유럽 스타일, 한국에서는 비표준)---
실전 적용
검사 순서
1. 숫자 표기 방식 전수 조사 (아라비아/한글) 2. 단위 띄어쓰기 확인 (SI 단위/의존명사) 3. 빈도 계산 및 다수결 적용 4. 문서 타입에 맞는 표준 확인 5. 통일안 제시
보고 형식
## 숫자 및 단위 표기 불일치
**불일치 #7: 숫자 표기 혼용**
- 🔄 아라비아 숫자: 15회
- 🔄 한글 숫자: 3회
- ✅ 제안: 기술 문서이므로 아라비아 숫자로 통일
- 📚 근거: 학술/기술 문서 작성 지침
**불일치 #8: 단위 띄어쓰기**
- 🔄 "5 kg"(띄어쓰기): 8회
- 🔄 "3kg"(붙여쓰기): 2회
- ✅ 제안: SI 표기법에 따라 띄어쓰기로 통일
- 📚 근거: 국제단위계(SI) 표기법---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 숫자 표기 | 아라비아 (5명) | 엄격 아라비아 (3명) | 자유 (5명, 5 명 모두 OK) | 자유 (강조 시 한글 가능: 세 가지) |
| 단위 띄어쓰기 | 5 명 (격식) 또는 5명 | 엄격 (3명) | 자유 | 자유 |
| 소수점·통계 | 소수점 둘째 자리 | 엄격 (예: 0.05, p<0.001) | 자유 | 거의 없음 |
| 큰 숫자 | 1,234 콤마 | 동일 | 1234도 OK (코드 맥락) | 1.2k, 1만+ 자유 |
핵심 가이드: 학술이 가장 엄격 (SI 단위·통계 정밀), 마케팅이 가장 자유. 비즈니스는 단위 띄어쓰기로 격식 표시. 기술은 코드 맥락에서 자유롭되 산문에서는 통일. 차등 우선순위: 학술에서 숫자 형식은 우선순위 2 수준으로 엄격, 마케팅에서는 우선순위 4로 완화.
---
참고 자료
인용 및 강조 표기
이 문서는 한국어 문서에서 인용 부호와 강조 표기를 일관되게 사용하기 위한 패턴과 기준을 설명합니다.
패턴 13: 따옴표 스타일
메타데이터:
- 출처: 국립국어원 문장부호 규정, 출판 실무 관행
- 권위: 🏛️ 정부 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
한국어는 다양한 따옴표 스타일을 사용할 수 있습니다. 동일 문서 내에서 여러 스타일을 혼용하면 일관성이 떨어집니다.
주요 따옴표 종류
1. 큰따옴표 (" ")
사용처:
- 직접 인용
- 말이나 생각
- 강조
✅ 올바른 예시:
그는 "괜찮아요"라고 말했다.
"혁신"이라는 단어가 자주 등장한다.2. 작은따옴표 (' ')
사용처:
- 따옴표 안의 따옴표 (이중 인용)
- 특정 용어 강조 (대안)
✅ 올바른 예시:
그는 "선생님이 '공부하라'고 하셨어요"라고 전했다.
'혁신'이라는 개념은 중요하다.3. 겹낫표 (『 』)와 홑낫표 (「 」)
사용처:
- 책 제목, 신문 이름, 작품명
- 출판물에서 전통적으로 사용
✅ 올바른 예시:
『해리 포터』를 읽었다.
「조선일보」 기사에 따르면...4. 백틱 ( )
사용처:
- 코드나 명령어 (기술 문서)
- Markdown 문서
✅ 올바른 예시:
`git commit` 명령어를 실행하세요.
변수 `userName`을 선언합니다.국립국어원 문장부호 규정
큰따옴표 우선 원칙:
- 직접 인용이나 강조는 큰따옴표(" ")를 기본으로 사용
- 따옴표 안에 또 다른 인용이 있을 때는 작은따옴표(' ') 사용
✅ 규정에 따른 예시:
"선생님이 '열심히 하라'고 하셨어요."겹낫표/홑낫표:
- 책 제목, 신문 이름, 예술 작품 등에는 겹낫표(『 』)
- 소제목, 편명, 그림이나 노래 제목 등에는 홑낫표(「 」)
혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"혁신"이라는 단어는 중요하다. 또한 '창의성'도 필수적이다.
제품명은 `SuperApp`이고, 기능은 "빠른 검색"이다.
→ " ", ' ', ` ` 혼용
✅ 교정 (큰따옴표 통일):
"혁신"이라는 단어는 중요하다. 또한 "창의성"도 필수적이다.
제품명은 "SuperApp"이고, 기능은 "빠른 검색"이다.
✅ 교정 (기술 문서, 코드는 백틱):
"혁신"이라는 단어는 중요하다. 또한 "창의성"도 필수적이다.
제품명은 `SuperApp`이고, 기능은 "빠른 검색"이다.이중 인용 (혼용 허용):
✅ 허용되는 예시:
"선생님이 '공부하라'고 하셨어요."
→ 큰따옴표 안에 작은따옴표는 규정에 맞음문서 타입별 권장 따옴표
| 문서 타입 | 일반 인용/강조 | 코드/명령어 | 책/작품명 | 근거 |
|---|---|---|---|---|
| 공문서 | " " | (없음) | 『 』, 「 」 | 국립국어원 규정 |
| 학술 논문 | " " | " " 또는 기울임 | 『 』, 「 」 | 학술 관행 |
| 기술 문서 | " " | | " " | Markdown 관행 |
| 마케팅 | " " 또는 굵게 | (없음) | " " | 시각적 효과 |
| 출판물 | " " | - | 『 』, 「 」 | 출판 전통 |
교정 전략
1. 문서 타입 확인: 공문서/출판물은 겹낫표, 기술 문서는 백틱 허용 2. 다수결 원칙: 같은 용도(인용/강조)에는 가장 많이 사용된 따옴표로 통일 3. 코드 구분: 기술 문서에서 코드는 백틱( ), 일반 텍스트는 큰따옴표(" ") 4. 이중 인용: 큰따옴표 안에 작은따옴표는 허용
---
패턴 14: 강조 표기
메타데이터:
- 출처: Markdown 스타일 가이드, 테크니컬 라이팅 가이드
- 권위: 💼 실무 표준
- 버전: 1.0.0
설명
텍스트를 강조하는 방법이 일관적이지 않으면 독자가 중요한 내용을 파악하기 어렵습니다.
주요 강조 방법
1. 굵게 (Bold)
Markdown: **텍스트** 또는 __텍스트__ 용도: 강한 강조, 키워드
✅ 올바른 예시:
이 기능은 **매우 중요합니다**.
**주의**: 다음 사항을 확인하세요.2. 기울임 (Italic)
Markdown: *텍스트* 또는 _텍스트_ 용도: 약한 강조, 외국어, 책 제목 (학술 문서)
✅ 올바른 예시:
이 부분은 *주목할 필요가* 있습니다.
*de facto* 표준으로 자리잡았다.3. 밑줄
HTML: <u>텍스트</u> 용도: 하이퍼링크 이외에는 사용 자제 (혼란 방지)
⚠️ 주의:
웹 문서에서 <u>밑줄</u>은 링크로 오해받을 수 있음4. 하이라이트/배경색
Markdown 확장: ==텍스트== (일부 편집기) HTML: <mark>텍스트</mark> 용도: 매우 강한 강조, 주의 사항
✅ 올바른 예시:
==경고==: 이 작업은 되돌릴 수 없습니다.5. 따옴표
용도: 특정 용어나 개념 강조 (위 패턴 9 참조)
✅ 올바른 예시:
"혁신"이라는 단어의 의미는...혼용 사례
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
이것은 **중요한** 내용입니다. 또한 _필수적인_ 요소이기도 합니다.
"핵심" 개념을 이해해야 합니다.
→ **, _, " " 모두 같은 용도(강조)로 사용
✅ 교정 (굵게 통일):
이것은 **중요한** 내용입니다. 또한 **필수적인** 요소이기도 합니다.
**핵심** 개념을 이해해야 합니다.의미 구분 (혼용 허용):
✅ 허용되는 예시:
이것은 **매우 중요한** 내용이며, *주의 깊게* 읽어야 합니다.
→ **굵게**(강한 강조)와 *기울임*(약한 강조)을 의도적으로 구분강조 수준별 권장 방법
| 강조 수준 | 권장 방법 | 용도 | 예시 |
|---|---|---|---|
| 매우 강함 | ==하이라이트== 또는 ⚠️/🔴 | 경고, 위험 | ==주의== 또는 ⚠️ 주의 |
| 강함 | 굵게 | 키워드, 중요 개념 | 핵심 |
| 중간 | "따옴표" | 특정 용어 | "혁신" |
| 약함 | 기울임 | 부수적 강조 | 참고 |
문서 타입별 권장 강조
| 문서 타입 | 권장 방법 | 근거 |
|---|---|---|
| 공문서 | 밑줄, 굵게 | 전통적 공문서 스타일 |
| 학술 논문 | 기울임 (외국어), 굵게 (키워드) | 학술 관행 |
| 기술 문서 | 굵게, (코드) | Markdown 관행 |
| 마케팅 | 굵게, ==하이라이트==, 색상 | 시각적 효과 |
과도한 강조 피하기
❌ 잘못된 예시:
**이 제품은** **매우** **중요한** **기능을** **제공합니다**.
→ 모든 단어가 굵게 = 강조 효과 없음
✅ 교정:
이 제품은 **중요한 기능**을 제공합니다.
→ 진짜 중요한 부분만 강조교정 전략
1. 용도 구분: 강한 강조(굵게), 약한 강조(기울임), 용어(따옴표)를 구분 2. 일관성: 같은 용도에는 같은 방법 사용 3. 절제: 강조는 정말 중요한 부분만 4. 가독성: 지나친 강조는 오히려 가독성 저해
---
패턴 15: 특수 문자 및 이모지
메타데이터:
- 출처: 실무 관행
- 권위: 💼 실무 표준
- 버전: 1.0.0
설명
이모지나 특수 문자 사용이 일관적이지 않으면 문서의 전문성이 떨어질 수 있습니다.
이모지 사용
적절한 사용 (Markdown/캐주얼 문서):
✅ 올바른 예시:
✅ 완료
❌ 오류
⚠️ 주의
📝 참고부적절한 사용 (공식 문서):
❌ 잘못된 예시:
본 보고서는 매우 중요합니다. 😊
→ 공식 문서에 이모지 부적절특수 기호
화살표:
혼용 피하기:
❌ "A → B, C => D, E ➡️ F"
✅ "A → B, C → D, E → F"체크 마크:
일관성 유지:
✅ "✓ 완료, ✓ 확인"
또는 "✅ 완료, ✅ 확인"교정 전략
1. 문서 타입: 공식 문서는 이모지 자제, 기술/마케팅 문서는 허용 2. 일관성: 같은 의미는 같은 기호/이모지 사용 3. 절제: 과도한 이모지는 가독성 저해
---
실전 적용
검사 순서
1. 따옴표 종류 전수 조사 (" ", ' ', 『 』, 등) 2. 강조 방법 확인 (*, , __, _, 따옴표) 3. 이모지 및 특수 문자 확인 4. 용도별 빈도 계산 5. 통일안 제시
보고 형식
## 인용 및 강조 불일치
**불일치 #13: 따옴표 스타일 혼용**
- 🔄 큰따옴표 (" "): 15회
- 🔄 작은따옴표 (' '): 5회
- 🔄 백틱 (` `): 3회 (코드 용도)
- ✅ 제안: 일반 텍스트는 큰따옴표(" "), 코드는 백틱(` `)으로 구분
- 📚 근거: 국립국어원 문장부호 규정 + Markdown 관행
**불일치 #14: 강조 표기 혼용**
- 🔄 **굵게**: 12회
- 🔄 *기울임*: 3회
- 🔄 "따옴표": 8회
- ✅ 제안: 강한 강조는 **굵게**, 특정 용어는 "따옴표"로 구분
- 📚 근거: 테크니컬 라이팅 가이드---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 따옴표 | 큰따옴표("") 보수적 | APA/MLA 정형 ("") | 인라인 코드 우선 | 자유 ("", '', 「」 OK) |
| 강조 (굵게) | 보수적, 핵심만 | 거의 없음 (이탤릭 우선) | 자유 (가독성 위주) | 자유, 이모지 강조 |
| 이탤릭 | 거의 없음 | 책·저널·외래어 표시 | 거의 없음 | 자유 |
| 외래어 처리 | 큰따옴표 또는 그대로 | 이탤릭 | 그대로 (코드 형식) | 자유 |
핵심 가이드: 학술은 APA/MLA 같은 인용 표준이 엄격하고 우선순위 1 수준. 비즈니스는 보수적 (강조 자제). 기술 문서는 코드 블록·인라인 코드 우선. 마케팅은 가독성·임팩트 우선이라 강조 자유롭게 사용. 차등 우선순위: 학술에서 인용 형식은 우선순위 1, 마케팅에서는 우선순위 4.
---
참고 자료
용어 통일
이 문서는 한국어 문서에서 동일한 개념을 나타내는 용어를 일관되게 사용하기 위한 패턴과 기준을 설명합니다.
패턴 4: 동일 개념의 다른 표현
메타데이터:
- 출처: 한국공공언어진흥원 전문용어 표준화 프로세스, 정보통신기술용어해설
- 권위: 🏛️ 정부 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
한국어는 같은 개념을 표현하는 여러 단어가 존재합니다 (순우리말, 한자어, 외래어 혼재). 동일 문서 내에서 이들을 혼용하면 독자가 혼란을 느낄 수 있습니다.
흔한 혼용 사례
IT/기술 분야
| 개념 | 표현 A | 표현 B | 표현 C | 권장 |
|---|---|---|---|---|
| 사용자 | 사용자 | 유저 | 이용자 | 문서 타입에 따라 선택 |
| 화면 | 화면 | 페이지 | UI | 문맥에 따라 구분 |
| 저장 | 저장 | 세이브 | 보관 | 저장 (기술문서 표준) |
| 설정 | 설정 | 세팅 | 구성 | 설정 (국립국어원 표준) |
| 업데이트 | 업데이트 | 갱신 | 최신화 | 업데이트 (통용) |
| 다운로드 | 다운로드 | 내려받기 | 받기 | 문서 타입에 따라 |
비즈니스 분야
| 개념 | 표현 A | 표현 B | 표현 C | 권장 |
|---|---|---|---|---|
| 회사 | 회사 | 기업 | 업체 | 문맥에 따라 구분 |
| 고객 | 고객 | 손님 | 클라이언트 | 고객 (공식 문서) |
| 직원 | 직원 | 임직원 | 구성원 | 문서 정책에 따라 |
| 계약 | 계약 | 약정 | 컨트랙트 | 계약 (법률 표준) |
교육/학술 분야
| 개념 | 표현 A | 표현 B | 표현 C | 권장 |
|---|---|---|---|---|
| 학생 | 학생 | 수강생 | 학습자 | 문맥에 따라 |
| 교사 | 교사 | 선생님 | 강사 | 공식성에 따라 |
| 과제 | 과제 | 숙제 | 과업 | 과제 (학술 표준) |
검출 기준
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"사용자는 로그인 후 페이지를 확인할 수 있습니다.
유저가 설정을 변경하려면 화면 오른쪽 버튼을 클릭하세요."
→ "사용자/유저" 혼용, "페이지/화면" 혼용
✅ 교정:
"사용자는 로그인 후 페이지를 확인할 수 있습니다.
사용자가 설정을 변경하려면 페이지 오른쪽 버튼을 클릭하세요."의미 구분이 있는 경우 (혼용 허용):
✅ 허용되는 예시:
"사용자는 웹 페이지에서 UI 요소를 클릭합니다."
→ "페이지"(전체 화면)와 "UI"(인터페이스 요소)는 다른 개념문서 타입별 권장 용어
공문서/공식 비즈니스
- 권장: 순우리말 > 한자어 > 외래어
- 근거: 국어기본법 제14조 "일반 국민이 이해하기 쉬운 용어"
- 예시: "사용자", "화면", "설정", "저장"
기술 문서
- 권장: 업계 표준 용어 우선
- 근거: Kakao Enterprise 기술문서 가이드, 정보통신기술용어해설
- 예시: "API", "SDK", "라이브러리" (외래어도 허용)
마케팅/소비자 대상
- 권장: 친숙한 표현 우선
- 근거: 독자 친화성
- 예시: "유저", "클릭", "다운로드"
교정 전략
1. 다수결 원칙: 문서에서 가장 많이 사용된 용어를 기준으로 통일 2. 표준 우선: 정부/학술/업계 표준이 있으면 그것을 따름 3. 의미 구분: 진짜로 다른 의미라면 혼용 허용 4. 일관성: 한 번 선택하면 문서 끝까지 유지
---
패턴 5: 외래어 표기 일관성
메타데이터:
- 출처: 국립국어원 외래어 표기법, Kakao Enterprise 기술문서 가이드
- 권위: 🏛️ 정부 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
외래어를 한글로 표기할 때, 띄어쓰기나 표기 방법이 일관적이지 않으면 전문성이 떨어집니다.
흔한 외래어 표기 불일치
띄어쓰기 혼용
| 외래어 | 표기 A | 표기 B | 국립국어원 표준 | 실무 통용 |
|---|---|---|---|---|
| 웹사이트 | 웹사이트 | 웹 사이트 | 웹사이트 (붙여쓰기) | 웹사이트 |
| 데이터베이스 | 데이터베이스 | 데이터 베이스 | 데이터베이스 | 데이터베이스 또는 DB |
| 프로그래밍 | 프로그래밍 | 프로그램밍 | 프로그래밍 | 프로그래밍 |
| 서비스 | 서비스 | 서비스 | 서비스 | 서비스 |
약어 혼용
| 개념 | 풀어쓰기 | 약어 | 권장 |
|---|---|---|---|
| 운영체제 | Android OS | AOS | Android (또는 Android OS) |
| 데이터베이스 | 데이터베이스 | DB | 문서 타입에 따라 |
| 응용 프로그램 인터페이스 | Application Programming Interface | API | API (업계 표준) |
| 소프트웨어 개발 키트 | Software Development Kit | SDK | SDK (업계 표준) |
중요 원칙:
- 공식 표기 우선: "Android OS"는 공식 표기, "AOS"는 비공식
- 업계 표준: API, SDK 같은 약어는 풀어쓰기보다 약어가 더 통용됨
- 일관성: 한 문서 내에서 풀어쓰기와 약어를 혼용하지 않음
검출 기준
명백한 불일치:
❌ 잘못된 예시:
"이 웹사이트는 데이터 베이스를 사용합니다.
웹 사이트 관리자는 DB를 정기적으로 백업합니다."
→ "웹사이트/웹 사이트" 혼용, "데이터 베이스/DB" 혼용
✅ 교정:
"이 웹사이트는 데이터베이스를 사용합니다.
웹사이트 관리자는 데이터베이스를 정기적으로 백업합니다."약어 사용 (문서 타입에 따라):
✅ 기술 문서:
"API를 통해 DB에 접근합니다."
✅ 일반 문서:
"프로그래밍 인터페이스를 통해 데이터베이스에 접근합니다."문서 타입별 권장 표기
공문서/일반 대중
- 권장: 풀어쓰기, 순화된 표현
- 근거: 국립국어원 공공언어 개선 가이드
- 예시: "응용 프로그램" (not "앱"), "누리집" (not "웹사이트")
기술 문서
- 권장: 업계 표준 약어
- 근거: Kakao Enterprise 가이드 "공식 표기법이 아닌 약어는 피함"
- 예시: "API", "SDK" (OK), "AOS" (NG, "Android" 사용)
비즈니스 문서
- 권장: 독자의 이해도에 맞춤
- 예시: IT 업계 문서는 약어 허용, 일반 고객 대상은 풀어쓰기
교정 전략
1. 국립국어원 표준 확인: 외래어 표기법 참조 2. 업계 관행 고려: 기술 문서는 통용되는 약어 허용 3. 일관성 최우선: 문서 내에서 한 가지 표기만 사용 4. 첫 등장 시 설명: "API(Application Programming Interface)"처럼 첫 등장 시 풀어쓰기 제공 (선택)
---
패턴 6: 한자어 vs 순우리말
메타데이터:
- 출처: 국립국어원 쉬운 공공언어 쓰기 지침
- 권위: 🏛️ 정부 표준
- 버전: 1.0.0
설명
같은 의미를 한자어와 순우리말로 모두 표현할 수 있을 때, 둘을 혼용하면 일관성이 떨어집니다.
흔한 혼용 사례
| 한자어 | 순우리말 | 권장 (공문서) | 권장 (일반) |
|---|---|---|---|
| 사용 | 쓰임, 씀 | 사용 | 사용 |
| 변경 | 바꿈 | 변경 또는 바꿈 | 바꿈 |
| 확인 | 살펴봄 | 확인 | 확인 |
| 추가 | 더함 | 추가 | 추가 |
| 제거 | 없앰 | 제거 또는 삭제 | 없앰 |
| 종료 | 끝냄 | 종료 | 끝 |
원칙:
- 공문서는 일반 국민이 이해하기 쉬운 표현 우선
- 하지만 과도한 순화는 오히려 어색할 수 있음
- 문맥에 맞게 선택
검출 기준
❌ 잘못된 예시:
"파일을 추가하려면 버튼을 클릭하세요.
파일을 더하는 과정은 간단합니다."
→ "추가/더하는" 혼용
✅ 교정:
"파일을 추가하려면 버튼을 클릭하세요.
파일을 추가하는 과정은 간단합니다."교정 전략
1. 독자 고려: 일반 대중은 쉬운 표현, 전문가는 전문 용어 2. 자연스러움: 지나친 순화보다 통용되는 표현 우선 3. 일관성: 한 번 선택하면 끝까지 유지
---
실전 적용
검사 순서
1. 문서에서 동일 개념을 나타내는 용어 추출 2. 각 용어의 사용 빈도 계산 3. 문서 타입에 맞는 표준 용어 확인 4. 다수결 + 표준 기준으로 통일안 제시
보고 형식
## 용어 통일 불일치
**불일치 #4: 동일 개념 다른 표현**
- 🔄 "사용자": 10회
- 🔄 "유저": 3회
- 🔄 "이용자": 1회
- ✅ 제안: "사용자"로 통일 (다수결 + 공식 문서 표준)
- 📚 근거: 국립국어원 표준 용어
**불일치 #5: 외래어 표기**
- 🔄 "웹사이트": 5회
- 🔄 "웹 사이트": 2회
- ✅ 제안: "웹사이트"로 통일 (붙여쓰기)
- 📚 근거: 국립국어원 외래어 표기법---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 표준 용어 | 사용자·이용자·고객 (정부 표준) | 학술 용어 + 영어 원어 병기 | API·SDK·DB 영어 약어 OK | 브랜드 용어·친근한 말 |
| 외래어 표기 | 국립국어원 표준 | 학술 관례 (영어 병기) | 업계 통용 표기 | 자유 (브랜드 가이드 우선) |
| 약어 사용 | 첫 등장 풀네임 명시 | 첫 등장 풀네임 + 약어 | 자유 (업계 표준 약어) | 자유 |
| 신조어·은어 | 금지 | 금지 | 업계 신조어 OK (debounce, polling 등) | 자유 (트렌드 반영) |
핵심 가이드: 비즈니스는 정부 표준 용어, 학술은 영어 병기 + 학술 용어집, 기술은 업계 약어 + IT 표준, 마케팅은 브랜드 + 트렌드. 한 문서 안에서는 다수결 원칙으로 통일. 차등 우선순위: 학술과 비즈니스는 용어 통일 검사가 엄격, 마케팅에서는 의도적 어휘 변주 허용.
---
참고 자료
어조 및 격식 일관성
이 문서는 한국어 문서에서 어조와 격식 수준의 일관성을 유지하기 위한 패턴과 기준을 설명합니다.
패턴 1: 경어체 혼용
메타데이터:
- 출처: 국립국어원 공문서 작성 지침, 대학 논문 작성 지침
- 권위: 🏛️ 법적 표준 + 📚 학술 표준
- 버전: 1.0.0
설명
한국어는 격식 수준에 따라 다양한 종결어미를 가지고 있습니다. 동일 문서 내에서 종결어미가 혼용되면 독자에게 일관성 없는 인상을 줍니다.
주요 경어체 분류
1. 격식체 (하십시오체)
- 사용: 공식 문서, 비즈니스 문서, 발표
- 종결어미: -습니다/-습니까, -ㅂ니다/-ㅂ니까
- 예: "회의는 오후 3시에 시작합니다."
2. 격식체 (하오체)
- 사용: 학술 논문, 보고서
- 종결어미: -이다/-인가, -하다/-한가
- 예: "이 연구는 세 가지 가설을 검증한다."
3. 비격식체 (해요체)
- 사용: 블로그, 일반 설명, 친근한 비즈니스
- 종결어미: -이에요/-예요, -해요/-되요
- 예: "회의는 오후 3시에 시작해요."
4. 비격식체 (해체)
- 사용: 친구 간, 매우 캐주얼한 글
- 종결어미: -이야/-야, -해/-돼
- 예: "회의는 오후 3시에 시작해."
검출 기준
명백한 혼용 (반드시 지적):
❌ 잘못된 예시:
"이 제품은 고객 만족도를 높입니다. 또한 사용이 편리해요."
→ "~입니다"(격식)와 "~해요"(비격식) 혼용
✅ 교정 (격식체):
"이 제품은 고객 만족도를 높입니다. 또한 사용이 편리합니다."
✅ 교정 (비격식체):
"이 제품은 고객 만족도를 높여요. 또한 사용이 편리해요."미묘한 혼용 (문맥 고려):
예시: 학술 논문에서
"본 연구는 세 가지 가설을 검증한다. 결과는 다음과 같습니다."
→ "~한다"(하다체)와 "~습니다"(하십시오체) 혼용
판단: 학술 논문은 일반적으로 "~한다" 체로 통일하지만,
일부 대학에서는 혼용을 허용하기도 함문서 타입별 권장 어조
| 문서 타입 | 권장 격식 | 근거 |
|---|---|---|
| 공문서, 공식 보고서 | -습니다/-ㅂ니다 | 국어기본법 제14조, 행정업무 운영 규정 |
| 학술 논문 | -이다/-하다 | 대학 학위논문 작성 지침 (세종대, 경희대 등) |
| 비즈니스 프레젠테이션 | -습니다/-ㅂ니다 | 실무 관행 |
| 기술 문서 | -합니다/-입니다 또는 -한다 | Kakao Enterprise 가이드 |
| 블로그, 마케팅 | -해요/-이에요 | 독자 친화성 우선 |
| 소셜 미디어 | -해/-이야 | 캐주얼한 톤 |
교정 전략
1. 다수결 원칙: 문서에서 가장 많이 사용된 어미를 기준으로 통일 2. 문서 타입: 위 표를 참조하여 문서 타입에 맞는 어조 제안 3. 전체 통일: 예외 없이 일관되게 적용 (강조를 위한 의도적 변화 제외)
---
패턴 2: 주어 불일치
메타데이터:
- 출처: 국립국어원 쉬운 공문서 쓰기 길잡이, 실무 관행
- 권위: 🏛️ 정부 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
한국어에서 1인칭 복수 주어는 "우리", "저희", "우리나라" 등 여러 표현이 있습니다. 동일 문서 내에서 이들을 혼용하면 화자의 태도가 일관적이지 않은 것처럼 보입니다.
주요 주어 선택
1. 우리 vs 저희
- 우리: 겸양의 의미가 약함, 동등한 관계
- 저희: 겸양의 의미가 강함, 상대를 높임
- 예시:
- "우리 회사는..." (동료에게)
- "저희 회사는..." (고객에게)
2. 본인 vs 저
- 본인: 공식적, 객관적
- 저: 겸손함, 주관적
- 예시:
- "본인은 다음과 같이 제안합니다." (공문서)
- "저는 다음과 같이 생각합니다." (의견서)
검출 기준
명백한 불일치:
❌ 잘못된 예시:
"저희 회사는 고객 만족을 최우선으로 합니다. 우리는 항상 노력하고 있습니다."
→ "저희"와 "우리" 혼용
✅ 교정:
"저희 회사는 고객 만족을 최우선으로 합니다. 저희는 항상 노력하고 있습니다."문서 타입별 권장 주어
| 문서 타입 | 권장 주어 | 근거 |
|---|---|---|
| 대외 비즈니스 문서 | 저희, 저 | 고객에 대한 겸양 |
| 내부 문서 | 우리, 본인 | 동료 간 동등 관계 |
| 학술 논문 | 본 연구, 필자, 저자 | 객관성 유지 |
| 공문서 | 본인, 당 기관 | 공식성 |
교정 전략
1. 대상 파악: 독자가 누구인지 확인 (고객/동료/일반 대중) 2. 일관성: 한 번 선택한 주어를 끝까지 유지 3. 문맥: 문장에 따라 주어를 바꾸는 것은 허용하되, 같은 개념에 대해서는 통일
---
패턴 3: 문체 충돌
메타데이터:
- 출처: 학술 글쓰기 가이드, 테크니컬 라이팅 실무
- 권위: 📚 학술 표준 + 💼 실무 표준
- 버전: 1.0.0
설명
격식 있는 표현과 구어체 표현이 혼재되면 문서의 전문성이 떨어집니다.
주요 충돌 패턴
1. 축약형 혼용
❌ 잘못된 예시:
"이 방법은 효과적이지 않습니다. 그래서 안 돼요."
→ "않습니다"(격식)와 "안 돼요"(구어) 혼용
✅ 교정:
"이 방법은 효과적이지 않습니다. 그래서 적합하지 않습니다."2. 간투사/감탄사 사용
❌ 잘못된 예시:
"본 연구의 결과는 매우 흥미롭습니다. 와, 정말 놀라운 발견이에요!"
→ 격식 문서에 "와", "정말" 같은 감탄사 부적절
✅ 교정:
"본 연구의 결과는 매우 흥미롭습니다. 이는 주목할 만한 발견입니다."3. 속어/은어 사용
❌ 잘못된 예시:
"이 기능은 완전 대박입니다. 성능이 크게 향상되었습니다."
→ "완전 대박"은 격식 문서에 부적절
✅ 교정:
"이 기능은 매우 우수합니다. 성능이 크게 향상되었습니다."교정 전략
1. 문서 전체의 톤: 처음부터 끝까지 일관된 격식 수준 유지 2. 대체 표현: 구어체 표현을 격식 있는 표현으로 변환 3. 예외 허용: 인용문이나 캐릭터 묘사는 예외
---
실전 적용
검사 순서
1. 문서 타입 파악 (비즈니스/학술/기술/마케팅) 2. 종결어미 전수 조사 (-습니다/-해요/-한다 등) 3. 빈도 계산 및 다수결 적용 4. 주어 일관성 확인 5. 구어체 표현 탐색 6. 통일안 제시
보고 형식
## 어조 및 격식 불일치
**불일치 #1: 경어체 혼용**
- 🔄 "-습니다" 체: 12회 사용
- 🔄 "-해요" 체: 3회 사용
- ✅ 제안: 비즈니스 문서이므로 "-습니다" 체로 통일
- 📚 근거: 국립국어원 공문서 작성 지침
**불일치 #2: 주어 불일치**
- 🔄 "저희": 5회
- 🔄 "우리": 2회
- ✅ 제안: 대외 문서이므로 "저희"로 통일
- 📚 근거: 실무 관행 (고객 대상 문서는 겸양 표현 사용)---
장르별 권장 사항
| 항목 | 비즈니스/공문서 | 학술 논문 | 기술 문서 | 마케팅/블로그 |
|---|---|---|---|---|
| 종결어미 | ~합니다 (해요체) | ~이다 (한다체) | ~합니다 + ~한다 혼용 | ~해요/~다 자유 |
| 격식 수준 | 격식체 | 격식체 (간결) | 중간 | 비격식체·친근 |
| 주어 표현 | 우리·본·저희 | 본 연구·필자·연구자 | 사용자·개발자 (1인칭 회피) | 우리·당신·여러분 |
| 호격·감탄 | 자제 | 거의 없음 | 자제 | 자유 (안녕하세요!) |
핵심 가이드: 학술과 비즈니스는 격식체로 통일. 기술 문서는 사용자·개발자 가이드 톤. 마케팅은 친근감과 일관성 균형 — 한 글에서 ~합니다와 ~해요 혼용은 OK이나 같은 단락에서는 통일. 차등 우선순위: 마케팅에서는 어조 일관성 검사가 완화될 수 있고, 학술에서는 한자어 종결(~함, ~임)도 OK.
---
관련 패턴 — humanizer 패턴 24와의 차이
humanizer의 패턴 24 경어체 균일성은 반대 방향을 봅니다 — 글 전체가 너무 균일하면 AI 신호로 본다는 것입니다. 이 어조 일관성 검사는 단락 단위 무작위 혼용을 비일관으로 봅니다.
두 검사는 다른 층을 봅니다:
- 어조 일관성 (이 카테고리): 단락 단위 일관 — 한 단락 안에서 ~합니다와 ~해요가 무작위로 섞이면 비일관
- 패턴 24 (humanizer): 글 단위 변주 — 글 전체에 어조 변화가 전혀 없으면 AI 신호
충돌 회피 흐름: humanizer로 글 단위 변주를 도입(예: 단락 사이 마지막 문장만 ~죠로 마침)한 뒤, 이 검사로 각 단락 안 일관성을 검증하세요. 이 순서로 적용하면 두 검사가 보완 관계로 작동합니다.
---
참고 자료
Related skills
How it compares
Pick style-guide when you need category-specific Korean register rules rather than generic machine translation without style enforcement.
FAQ
What does style-guide do?
문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요.
When should I use style-guide?
문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요.
What are common prerequisites?
--- name: style-guide description: 문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기.
Is Style Guide safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.