korean-writing-refiner

Korean Writing Refiner

한국어 문장을 자연스럽고 명확하게 다듬어, 독자가 바로 이해할 수 있는 최종 문안으로 만든다.

트리거 기준

핵심 기준은 요청 문구가 아니라 산출물이다. 어시스턴트가 외부 표면에 노출될 한국어 최종 문안을 직접 생성하거나 수정하면 이 스킬을 적용한다.

반드시 적용한다:

• 한국어 문장을 직접 수정하거나 다듬는 요청
• GitHub 이슈, PR, 댓글, 커밋 메시지의 제목이나 본문 작성
• README, 공지, UI 문구, 에러 메시지처럼 바로 게시되거나 노출되는 한국어 문안 작성

자동 적용하지 않는다:

• 문제점만 지적해 달라는 요청
• 수정 없는 피드백이나 평가 요청
• GitHub PR 리뷰, 이슈 분석, 대응 전략 정리
• 문체 가이드, 작성 규칙, 대응 원칙처럼 기준만 정리하는 요청
• 코드 작성, 디버깅, 리팩터링, 테스트 작성처럼 문안 작성이 본체가 아닌 작업
• 분석, 리뷰, 전략 정리, 코드 구현처럼 문안 작성이 본체가 아닌 작업

혼합 요청에서는 게시되는 제목, 본문, 댓글, 커밋 메시지 같은 최종 문안에만 적용한다.

기본 원칙

사용자가 수정 범위나 톤을 지정하면 그 지시를 먼저 따른다. 별도 지시가 없으면 다음 순서를 지킨다.

1. 의미 보존을 최우선으로 한다. 수정이 원문 의미를 바꿀 수 있으면 다른 개선은 보류한다.
2. 문서 유형에 맞는 톤과 종결어미를 정한다.
3. 문장 구조 문제를 먼저 정리한 뒤 표현 수준을 다듬는다.
4. 수정본이 원문보다 명확한 이익을 주지 않으면 원문을 유지한다.

문서 유형별 톤

• README, 기술 문서, PR 본문, 이슈 본문은 중립적인 합니다체를 기본으로 한다.
• GitHub 댓글과 내부 메모는 간결한 설명을 우선한다. 설명형이면 합니다체를 쓰고, 짧은 확인이나 제안은 간결한 구어체를 허용한다.
• 커밋 메시지는 짧고 분명하게 쓴다. 무종결형을 우선하고, 저장소 안에서 같은 형식을 유지한다.
• UI 문구, 버튼, 메뉴, 상태값은 짧고 바로 이해되는 표현을 쓴다. 무종결형을 기본으로 하고 한 화면 안에서 톤을 일관되게 유지한다.
• 사용자 안내 문구, 도움말, 길이가 있는 에러 메시지는 별도 톤 가이드가 없으면 합니다체를 기본으로 한다.
• 에러 메시지는 문제 상황, 가능한 원인, 다음 행동이 드러나도록 쓴다.

상위 판단 기준

문장의 모든 요소는 명제, 논증 구조, 인식 상태 중 하나에 기여해야 한다.

• 명제 기여: 제거하면 문장의 참/거짓이나 의미 범위가 달라진다.
• 논증 구조 기여: 제거하면 독자가 전환, 대조, 인과, 예외 관계를 파악하기 어렵다.
• 인식 상태 기여: 제거하면 화자의 확신, 출처, 불확실성이 정확히 전달되지 않는다.

세 기능 중 하나라도 기여하면 유지한다. 어느 것에도 기여하지 않는 구나 절은 제거한다.

수정 원칙

번역투와 명사 중심 표현을 줄인다

• 행위 명사 중심 표현은 동사 중심으로 바꾼다. 예: 검토가 필요하다보다 검토해야 한다.
• -의 연쇄, -에 대한, -를 위한, -에 있어서 같은 표현은 문맥에 맞게 끊어 쓰거나 동사형으로 바꾼다.
• 강한 증거, 깊은 이해처럼 영어 직역이 두드러지는 추상명사 수식은 더 자연스러운 표현으로 바꾼다.
• ~것이 아니라 ~것이다 같은 부정 대조 명사절은 필요하면 두 평서문으로 나누거나 긍정문으로 다시 쓴다.
• 현장에서 정착된 관용 표현이나 전문 용어는 무리하게 바꾸지 않는다.

주체와 인과 관계를 명확히 한다

• 주어와 술어가 멀리 떨어져 오독될 수 있으면 문장을 나눈다.
• 문장 첫머리 관형절의 주어가 상위 절 주어로 잘못 읽힐 수 있으면 상위 주어를 명시한다.
• 한 문장에 독립적인 행위가 둘 이상 들어 있으면 시간, 목적, 원인 관계가 드러나도록 분리한다.

외래어와 약어를 정리한다

• 정착된 외래어와 실무 전문 용어는 그대로 둔다.
• 낯선 외래어나 생소한 영어 표현은 처음 등장할 때만 괄호나 짧은 병기로 풀어 쓴다.
• 영어 명사를 한국어 동사처럼 쓰지 않는다.
• LLM 모델처럼 약어 풀이가 중복되는 표현은 피한다.