- 본문 문장 안에서 줄표를 쓰지 않는다.
- 삽입구는 괄호로 바꾼다:
관계형 스키마 — 외래 키, JOIN — 를→관계형 스키마(외래 키, JOIN)를 - 문장 연결은 두 문장으로 나눈다:
~와 비슷하다 — 지역 변수가 ~→~와 비슷하다. 지역 변수가 ~ - 용어 해설 목록은 콜론으로 바꾼다:
**용어** — 설명이다.→**용어**: 설명이다.
- 삽입구는 괄호로 바꾼다:
- 장·절 제목과 목차에서도 쓰지 않는다. "제목 — 부제"는 "제목: 부제"로 바꾼다.
- 제목에 이미 콜론이 있으면(예:
output: 'export') 콜론이 겹치지 않게 문구를 다듬는다.
- 제목에 이미 콜론이 있으면(예:
- 실제 설정 파일이나 출력을 인용한 문자열(예: go-quality 서브에이전트의
PASS — ...)과 코드 블록 안 내용은 원문 그대로 둔다.
- 무너지는 대상과 결과가 바로 이어서 구체적으로 설명될 때만 쓴다(예: "이 전제가 무너진다. 요청을 보내는 사람이 여럿이고 ~").
- 그 외에는 실제로 무엇이 어떻게 잘못되는지로 바꿔 쓴다: "편집 리듬이 무너진다" → "파일 하나를 고칠 때마다 전체 테스트를 기다리게 된다", "이 그림은 무너진다" → "요금·관리 부담이 생겨 성립하지 않는다".
- 보안 문맥에서는 "뚫린다"처럼 실제 사건을 가리키는 동사를 쓴다.
- 쓰지 않는다. 두 조건이 어떤 관계인지를 독자가 짐작하게 두지 말고, 실제 관계가 드러나는 말로 바꾼다.
- 인과: "적게 쓰는 런타임이 무료와 맞물린다" → "자원을 적게 쓰는 앱일수록 무료 인프라를 쓰기에 유리하다"
- 근거: "이유는 ~과 맞물린다" → "이유는 ~에 있다"
- 결합 효과: "A와 B가 맞물려 ~" → "A에 B가 더해져 ~"
- 사용 관계: "인덱스가 쿼리와 어떻게 맞물리는지" → "인덱스를 쿼리가 어떻게 사용하는지"
- 부합: "서버리스와 맞물린다" → 무엇이 왜 들어맞는지 직접 쓴다("인스턴스가 사라져도 잃을 상태가 없다")
- 기계 부품이 실제로 맞물리는 물리적 묘사만 남긴다.
- 원칙적으로 쓰지 않는다. 무엇이 어떻게 나뉘는지가 드러나는 동사로 바꾼다.
- 단순 분류는 "나뉜다": "삭제 정책은 두 가지로 나뉜다", "용도에 따라 포트가 나뉜다(6543/5432)".
- 역할이나 자리를 나눠 맡기는 정적인 배정은 "구분한다": "둘을 브랜치로 구분한다", "개발 배포와 운영 배포를 구분한다".
- 조건이 모드·경로를 결정하는 분기는 "정한다"로 바꾸고, 가능하면 대응 규칙까지 쓴다: "DATABASE_URL이 모드를 가른다" → "DATABASE_URL이 모드를 정한다", "
DATABASE_URL의 유무로 두 모드를 가른 뒤" → "DATABASE_URL이 있으면 PostgreSQL 모드, 없으면 SQLite 로컬 모드로 정한 뒤". - 기준에 따라 답이 달라지는 서술은 "~에 달렸다"로 바꾸거나 기준별 결론을 직접 쓴다: "무엇이 좋은지는 '검증자가 몇 명인가'로 갈린다" → "검증자가 발급자 하나뿐이면 HS256으로 충분하지만, 검증자가 따로 있으면 JWKS가 낫다".
- 성패·여부·요령을 판가름한다는 용법은 실제로 무엇이 달라지는지로 바꾼다: "이 배수가 무료 티어의 성립 여부를 가르지는 않는다" → "이 배수는 여유분의 차이이지 성립과 불성립의 차이가 아니다", "운영의 요령이 여기서 갈린다" → "운영의 공은 한도 감시가 아니라 방치 방지에 들여야 한다".
- 남겨 두는 용법: 물리적으로 가르는 동작, "의견이 갈린다" 같은 굳은 관용구, 그리고 갈래 비유가 문맥에 세워져 있는 분기 서술("두 갈래" 비유 위의 "가장 크게 갈리는 것은 배우는 양이다", "개발과 운영이 갈리지 않고").
- 소프트웨어(런타임, 서버, 함수, 요청, 작업 등)를 묘사하는 용법으로 쓰지 않는다. 어느 기준에서 크고 작은지가 드러나게 바꾼다.
- 메모리: "가벼운 서버" → "수십 MB 메모리로 도는 서버", "무거운 런타임" → "기본 점유가 큰 런타임"
- 크기: "배포 아티팩트가 무겁다" → "배포 아티팩트가 크다", "요청이 무거워진다" → "요청이 몇 KB씩 커진다"
- 시간: "무거운 배치/작업" → "오래 걸리는 배치/작업"
- 절차: "실습 준비가 가볍다" → "실습 준비가 간단하다"
- 부담·약점 같은 추상 명사에 얹는 용법도 실제 변화로 바꾼다: "부담이 가벼워진다" → "부담이 줄어든다", "약점이 무거워진다" → "약점이 심각해진다".
- 물리적 무게와 굳은 관용구("말의 무게")는 그대로 둔다.
- 기술적 실체를 가리키는 굳은 표현(조립 지점, 발생 지점)과 본래 의미(프랜차이즈 지점)만 허용한다.
- 추상적 용법은 문맥에 맞게 바꾼다: 부분, 곳, 대목, 장면, "어느 지점에서" → "어디서".
- 좌표축처럼 기준 두 개를 직교시켜 조합하는 진짜 2차원 구도(예: 2장의 "오류 발견 난이도"와 "오류 비용"을 조합한 검토 강도 매트릭스)와 도표·그래프의 축에만 쓴다.
- 기준·원인·항목·구성 요소를 뭉뚱그려 가리키는 용법은 실체에 맞는 말로 바꾼다.
- 판단 기준: "비교의 축이 드러난다" → "비교의 기준이 드러난다", "같은 축으로 나뉜다" → "배포와 같은 기준으로 나뉜다"
- 원인: "지연 시간의 다른 축인" → "지연 시간의 또 다른 원인인"
- 열거한 항목: "이 네 축에서 모두" → "이 네 가지 모두에서"
- 구성 요소: "남은 축은 Supabase다" → "남은 조각은 Supabase다", "두 축 위에서 체계를 세운다" → "두 기둥 위에 체계를 세운다"
- 주제: "이 책의 큰 축이어서" → "이 책의 큰 줄기여서"
- 실제 층 구조나 중복·충돌을 가리킬 때만 쓴다: 물리적 겹침(중괄호 두 겹, 카드 앞뒷면을 겹쳐 두기), CSS 박스 모델의 네 겹 상자, 캐시 위에 캐시를 얹는 층, 핸들러를 겹겹이 감싸는 데코레이터, "겹치다/겹치지 않는다"(slug·경로·잠금·배열 겹침 연산자).
- 지식·의미·비용·용어처럼 층이 아닌 추상 명사에 얹는 용법은 개수나 실제 관계로 바꾼다.
- 개수: "여러 겹의 지식이 필요하다" → "네 가지 지식이 한꺼번에 필요하다", "용어가 네 겹으로 쌓여 있어" → "용어 네 개가 한꺼번에 등장해"
- 추가: "한 겹의 의미가 더해진다" → "의미가 하나 더해진다"
- 합산: "비용도 겹친다", "~까지 겹치면" → "비용도 더해진다", "~까지 더해지면"
- 중복 작성: "어두운 버전을 겹쳐 써야" → "어두운 버전을 한 벌씩 더 써야"
- 물리적 손잡이(문, 도구)를 가리킬 때만 쓴다.
- 설정·제어 수단을 가리키는 비유로 쓰지 않는다. 무엇을 어떻게 조작하는지가 드러나게 바꾼다.
- "환경 변수라는 손잡이" → "환경 변수로 동작 바꾸기", "가장 큰 손잡이가 남아 있다" → "동작을 가장 크게 바꾸는 환경 변수가 남아 있다"
- "캐시 버전이라는 수동 손잡이" → "손으로 올리는 캐시 버전", "그 손잡이를 한 번 당긴 흔적" → "그 버전을 한 번 올린 흔적"
- "
htmx.min.js가 그 답의 손잡이다" → "htmx.min.js에 그 답이 들어 있다"
- 굳은 용어("사실상 표준(de facto standard)")이거나 정확성에 꼭 필요한 한정("브라우저가 직접 실행하는 언어는 사실상 자바스크립트뿐이다")일 때만 쓴다.
- 그 외에는 삭제하거나 풀어쓴다: "사실상 0" → "0에 가깝다", "사실상 필수다" → "필수가 된다".
- 비유를 맺을 때만 쓴다(예: 스프레드시트·신호등·그물·자물쇠 비유 뒤의 "~인 셈이다").
- 일반 서술의 결론에는 직설 종결을 쓴다: "확장된 셈이다" → "확장됐다", "관문이 되는 셈이다" → "관문이 된다".
- 대체 표현이 "~인 것이다"로 쏠리지 않게 한다. 이것도 남발하면 같은 문제가 생긴다.