Localize：현지화 및 번역 검수은(는) 무엇을 하나요?

0. 한 줄 요약

현지화는 A 언어를 B 언어로 바꾸는 것이 아니라, 먼저 A를 뜻으로 환원한 다음 B로 다시 쓰는 것입니다. 이 스킬의 가치는 '자연스럽지만 틀린' 문장을 찾아내고, 그 판단을 재사용 가능한 용어집, 스타일 시트, 확인 대기 목록으로 축적하는 데 있습니다.

문서 내 '실측' 사례는 모두 실제 프로젝트에서 가져온 것으로, 이미 비식별화되었습니다: 프로젝트와 제품은 익명 처리되었습니다. 인용문, 투표 수, 통계 수치는 원본 기록입니다. '예시'로 표시된 단어 예는 원래 단어가 아닌 대체된 것입니다.

1. 철칙 (모든 진입점에 적용)

사용자의 원본 파일과 번역 파일을 수정하지 않습니다. 모든 산출물은 작업 디렉터리에 기록합니다(§3 참조). 검수는 발견 목록을 출력하며, 사용자가 확인한 후에만 수정이 적용됩니다.
원래 의미를 읽을 수 없는 부분은 추측하지 않습니다. 확인 대기 목록에 기록합니다. 번역 진입점에서 여러 곳에 영향을 미치는 의문 사항은 먼저 사용자에게 문의한 후 작업하고, 한 곳에만 영향을 미치는 경우 완성본 옆에 '추정'이라고 표시합니다.
모델은 '출처가 있다'라고 주장할 수 없습니다. '이 단어가 목표 시장에서 이렇게 사용된다'는 판단은 언어 쌍 패키지/로케일 패키지에 근거가 있거나, WebSearch를 사용하여 목표 언어의 유사 자료에서 실제 사용 예를 찾거나, '미검증'이라고 표시해야 합니다.
생성과 검수는 컨텍스트를 분리합니다. 검수는 독립된 서브 에이전트가 수행합니다. 번역 생성 컨텍스트는 자신의 번역을 검수할 수 없습니다.
사실 계층은 스크립트에 맡깁니다. 숫자, 날짜, 통화, URL, 단위, 문자 규범은 먼저 scripts/를 실행하고, 모델은 스크립트가 찾지 못한 의미론적 문제만 처리합니다. 모델의 기호/단위 계층 오탐율은 매우 높으므로, 감으로 로케일 오류를 판단하게 하지 마십시오.
각 발견에는 심각도가 있으며, '오류'와 '선호도'를 구분합니다. §6 참조.
구간별로 검수하고, 전체를 한 번에 처리하지 않습니다. 각 구간은 약 1500자의 원문 문자입니다. 텍스트가 길수록 모델이 찾는 오류가 줄어듭니다.
수정은 표현을 바꿀 수 있지만, 지시하는 대상을 바꿀 수 없습니다. 문장 구조, 단어, 정보 순서를 바꾸는 것은 허용되지만(브랜드 카피는 재작성도 가능), 원문이 지시하는 대상을 바꾸는 것은 허용되지 않습니다——용도, 대상, 수량, 주체. 원문의 사실에 문제가 있는 경우(존재하지 않는 제품, 계산할 수 없는 숫자, 모순), 확인 대기 목록에 기록하여 저자에게 판단을 맡기고, 저자를 대신하여 수정하지 않습니다. 대상을 바꾸면 추가적인 모순이 발생할 수 있습니다.
번역 열에는 바로 사용 가능한 문자열만 넣습니다. 확인 대기 자리 표시자, 옵션 비교(A案/B案), 내부 포인터('아래 참조...'), 너비 주석, 처리 설명은 모두 별도 열 또는 별도 목록으로 이동합니다. 번역 단위가 아닌 것은 번역 테이블에 행을 만들지 마십시오——예를 들어 '이 라벨은 코드로 구성되어 i18n 키가 없음', '이 숫자는 의심스러움'과 같은 것은 전체를 확인 대기 목록으로 이동하고, 번역 열에 설명을 넣는 행을 만들지 마십시오. 인도 전에 scripts/deliverable_check.py를 실행하십시오. char_lint.py로 이중 언어 테이블을 검사할 때는 반드시 --tgt-col 옵션을 사용해야 합니다. 그렇지 않으면 원문 열의 문자가 번역문 오류로 보고됩니다.
본 프로젝트의 시작 파일과 코어 규칙이 충돌할 때는 먼저 기록한 다음, 충돌 방향에 따라 누구를 따를지 결정합니다. 시작 시 작성된 규정 준수 테이블, 스타일 시트, 용어집은 그 당시의 판단이고, 코어 규칙은 프로젝트를 넘나드는 판단이며, 둘은 충돌할 수 있습니다(전형적인 예: 규정 준수 테이블이 전체 구간을 부드럽게 하도록 요구하는 반면, diagnostics.md §10은 기능 설명을 긍정적으로 유지하도록 요구함). 먼저 충돌 방향을 구분한 다음 누구를 따를지 결정하십시오:
- 시작 파일이 코어보다 더 엄격한 경우(금지어, 반드시 작성해야 하는 면책 조항, 더 보수적인 표현 강도) → 시작 파일을 따릅니다, 판단을 기다립니다. 규정 준수에는 일반적으로 이유가 있으며, 느슨한 쪽의 오류 비용이 더 높습니다.
- 시작 파일의 사실이 만료되었거나 코어보다 더 느슨한 경우(사양이 변경되었거나, 제한이 완화되었거나, 코어가 요구하는 처리가 누락된 경우) → 코어를 따릅니다, 그리고 시작 파일을 업데이트합니다. 두 경우 모두: ① 확인 대기 목록에 기록하고, 원문 문제가 아닌 내부 규칙 충돌임을 명시합니다. ② 보고서에 어떤 규칙을 따랐는지, 그 이유를 기록합니다. 조용히 하나를 선택하는 것은 허용되지 않습니다——독립적인 검수 라운드에서는 귀하의 선택을 볼 수 없으며, 이를 위반으로 다시 보고할 것입니다.

2. 입력 계약

작업 시작 전에 아래 표를 수집합니다. 누락된 항목은 '누락 시' 열에 따라 처리하고 보고서 머리글에 표시합니다.

입력	필수	누락 시
원문(파일 경로 또는 붙여넣기)	review/translate 필수	원문 없음 → §5.3 다운그레이드 절차 진행
번역문	review 필수	—
소스 로케일 / 대상 로케일	필수	텍스트에서 자동 판단, 보고서에 '자동 판단' 표시
자료 유형(`references/material-types.md` 참조)	필수	한 번 질문; 응답 없으면 텍스트 특징에 따라 판단하고 표시
장면 한 줄: 누가, 어떤 상황에서, 이 자료를 읽고, 어떤 결정을 내리는가	필수	한 번 질문; 응답 없으면 자료 유형에 따라 기본값을 사용하고 보고서 머리글에 '장면 미확인' 표시
기존 용어집 / 스타일 시트	선택 사항	`templates/`에서 새로 생성
레이아웃 제약(글자 수 제한, 상자 너비, 소프트웨어 문자열 여부)	선택 사항	G7 레이아웃 검사 미수행, 보고서에 명시
대상 언어 유사 자료 샘플(translate 진입점 강력 권장)	선택 사항	보고서에 '장면 재구성에 샘플 참조 없음' 표시
번역 출처(인간 번역 / 기계 번역 / AI / 이전 버전)	review 권장	'알 수 없음' 표시
대상 언어 텍스트 작성자/출처(대상 언어 모국어 사용자 / 비모국어 사용자 / 알 수 없음)	원문 없을 시 필수 질문	알 수 없음 → 다운그레이드 및 표시
투입 등급(§8 참조)	선택 사항	기본값 '전체 등급'

3. 작업 디렉터리 및 산출물

기본적으로 원문 파일이 있는 디렉터리에 <원문 파일명 확장자 제외>.l10n/을 생성합니다. 사용자가 지정하면 해당 디렉터리를 사용합니다.

⚠ 최종 보고서 저장 책임은 주 대화에 있으며, 서브 에이전트는 텍스트로 반환합니다. 실측: 일부 실행 환경은 파일 이름으로 서브 에이전트의 findings.md/report/summary 유형 파일 작성을 차단하며, 동일한 스킬이 다른 세션에서 동일한 이름의 파일을 작성하는 것은 통과될 수 있습니다——차단은 세션 간에 변할 수 있으며, 양쪽 모두 가정할 수 없습니다. → 서브 에이전트는 내용을 생성하고 텍스트로 반환하며, 주 대화가 직접 저장하고 확인합니다(ls -lT + 항목 수). 저장 실패 시 서브 에이전트는 이름을 바꾸거나 Bash를 사용하여 우회해서는 안 됩니다——이는 다른 도구를 사용하여 방금 내려진 차단을 무력화하는 것입니다. 중간 산출물(list-a.md scripts-report.md open-questions.md 등)은 실측에서 제한되지 않으므로 직접 작성할 수 있습니다.

귀인 규율: '환경이 차단했다'고 단언하기 전에 먼저 격리 실험을 수행합니다(이름/디렉터리/크기 변경 각 한 번씩). 동일한 실행에서 반례가 있는 경우(다른 파일이 작성된 경우) 환경 탓으로 돌릴 수 없습니다. 실측: 주 대화가 '차단하지 않았는데 네가 쓰지 않은 것'이라고 단언하고, 서브 에이전트가 세 번의 프로브로 주 대화가 틀렸음을 증명했습니다. 실험을 수행한 쪽이 맞습니다.

파일	내용
`00-brief.md`	장면 한 줄, 자료 유형, 언어 쌍 및 로케일, 이번 지름길, 등급, 공백 등 전략 스위치, 입력 누락 항목
`glossary.md`	용어집(템플릿 `templates/glossary.md`), 거부 사유 및 상태 포함
`style-sheet.md`	스타일 시트(템플릿 `templates/style-sheet.md`), 로케일 패키지 기본값에서 시작
`open-questions.md`	확인 대기 목록(템플릿 `templates/open-questions.md`)
`scripts-report.md`	R1 각 스크립트의 출력
`findings.md`	검수 발견 목록(템플릿 `templates/findings-report.md`). 저장 책임은 주 대화에 있으며, 서브 에이전트에 있지 않습니다. 아래 참조
`draft.<locale>.md`	translate 진입점의 번역 완성본('추정' 표시 포함)
`decisions.md`	전체 문서 통일 사항에 대한 결정 기록(용어, 기호, 어체, 주요 결정)

4. 작업 시작 전 네 가지 + 규칙 패키지 로드

순서대로 수행하고 00-brief.md에 기록합니다:

장면 한 줄(§2), 그리고 즉시 '낙제할 수 있는' 판단 기준 세트로 확장합니다.

실측 교훈: 장면 한 줄만으로는 충분하지 않습니다. 한 상업 제안서의 장면은 매우 구체적으로 정의되었지만(독자 신원, 읽는 시간, 읽은 후 내릴 결정을 명시), 그대로 용어 결정 에이전트의 프롬프트에 작성했음에도 불구하고, 몇 가지 핵심 용어가 모두 모국어 사용자에 의해 거부되었습니다. 사후에 계산해 보니 용어집 60개 항목 중 단 9개만이 '누가 읽는가'를 근거로 언급했습니다. 장면은 좌우명이 되었고, '통과 여부'에 대한 어떤 판단 기준에도 들어가지 않았습니다.

따라서 장면은 반드시 아래 표로 변환되어 00-brief.md에 기록되어야 하며, 이후의 모든 결정은 이 표를 기준으로 검증되어야 합니다:

결정 유형	장면으로 어떻게 검증할 것인가('낙제'라고 답할 수 있어야 함)
단어 선택	검색 시 장면을 한정어로 분해하여 단어와 함께 검색(자료 유형 + 독자 신원). 한정 후 사용 예를 찾을 수 없음 = 미검증, 넓은 검색 방법으로 속여서는 안 됨. `diagnostics.md` §7 첫 번째 관문 참조
숫자・단위・통화	'이 독자가 이 시간 내에 훑어보고, 즉시 양감을 느낄 수 있는가?'——실제로 실패한 사례: 장면에는 '수십 분 안에 읽음'이라고 명시되어 있지만, 엔화 환산을 하지 않기로 결정했고, 세 명의 모국어 사용자 모두 '매번 계산해야 하므로 읽기를 포기하는 원인'이라고 말함
어역	'이 단어가 이 독자의 일상 문서(실사 보고서/사양서/사내 결재)에 나타나는가? 어색한가?' 어색하면 동일 어역의 동의어로 교체, 하지만 의미를 함께 낮추지 마십시오. `diagnostics.md` §10b 참조
구조・순서	'그가 이 시간 내에 그 결정을 내리기 위해 필요한 정보 순서는 무엇인가?' 원문 순서와 다른 경우, 확인 대기 목록에 기록
번역하지 않고 유지	'이 독자가 원래 형태(영어 소제목, 외화, 사양명)를 보았을 때, 전문성을 느끼는가 이질감을 느끼는가?' 실측: 원래 형태로 유지된 영어 소제목이 '해외 템플릿을 그대로 사용하는 인상'이라고 판단됨

판단 기준은 실패할 수 있어야 비로소 판단 기준입니다. '낙제가 무엇인지'에 답할 수 없는 기준은 시험을 치르지 않은 것과 같습니다.

이번 작업의 '저렴한 대응' 지름길을 기록합니다. 각 언어 쌍에는 겉보기에 합법적인 지름길이 있습니다: 언어 쌍 사이에는 '겉보기에 일대일 매핑이 가능한' 얕은 층(어형/자형/어순)이 존재하며, 진정한 차이는 더 깊은 층(의미 항목/지역 어휘/통사론)에 있습니다. 매핑 테이블이 사용하기 쉬울수록 더 위험합니다. 언어 쌍 패키지의 첫 번째 절에서 복사하거나 (언어 쌍 패키지가 없는 경우) 모델이 먼저 가설을 작성하게 합니다.
규칙 패키지 로드:

패키지	경로	패키지 없을 시
언어 쌍 패키지(방향 관련)	`references/pairs/<src>-<tgt>.md` (예: `zh-ja.md`)	모델이 지름길 가설을 자체 작성; G3/G6 신뢰도 다운그레이드; 보고서 머리글에 '언어 쌍 패키지 없음' 표시
대상 로케일 패키지	`references/locales/<locale>.md` (예: `ja-JP.md`)	스타일 시트를 빈 템플릿에서 시작; G5 신뢰도 다운그레이드; 보고서에 '로케일 패키지 없음' 표시
자료 유형 규칙	`references/material-types.md`	—

기존 패키지: pairs = zh-ja(완전), ja-zh, en-ja, ja-en, zh-en, en-zh(시드); locales = ja-JP(완전), zh-CN, zh-TW, en-US, en-GB(시드). 시드 패키지는 출처가 있는 내용만 포함하며, 부족한 부분은 명시적으로 기록합니다. 4. 용어집, 스타일 시트, 확인 대기 목록을 생성합니다. 용어집은 작업하면서 계속 추가하며, 용어를 결정할 때마다 하나의 항목을 기록합니다. 스타일 시트는 로케일 패키지 기본값을 복사한 후 프로젝트에 맞게 수정합니다. 확인 대기 목록은 첫 문장부터 기록을 시작합니다.

5. 세 가지 진입점

5.1 review: 기존 번역문 검수(원문 + 번역문 있음)

가장 실수하기 쉬운 형태이며, 유혹은 '번역문만 읽고 문제를 찾는 것'입니다. 실증 결론: 단일 언어 단독 한 번이 가장 나쁨; 반드시 이중 언어 대조 검토가 필요함; 번역문에서 시작; 두 번의 순서는 자유.

R0 입력 수집(대상 언어 텍스트 작성자/출처 포함) → 00-brief.md 작성 → 규칙 패키지 로드 → 세 가지 항목 생성
R1 스크립트 실행(§7): fact_check / char_lint / length_estimate / term_coverage / **distribution_check** → scripts-report.md
    **`distribution_check`는 단일 언어 검토 전에 실행해야 함**: 전체 문서의 분포를 보고하며, 단일 언어 검토는 항목별로 보기 때문에,
    분포 데이터를 먼저 확보해야 단일 언어 검토가 어디를 봐야 할지 알 수 있습니다.
R2 구간 분할: 원문과 번역문을 단락별로 정렬, 각 구간 ≤ 약 1500자 원문 문자, 번호 S01, S02…
R3 단일 언어 검토(독립 서브 에이전트, 번역문 + 로케일 패키지 + 장면만 제공):
    '모국어 사용자가 쓴 것처럼 읽히지 않는' 위치, 네 가지 트리거 적중, 어체 단절 표시
    → **원본 그대로 `review/list-a.md`에 기록**(요약이 아님, 원본)
    → **주 대화가 파일 존재, 행 수 ≥ 후보 항목 수를 확인**, 확인 실패 시 R3 재실행, 요약만 가지고 진행하지 않음
R4 이중 언어 검토(독립 서브 에이전트, 구간별로 원문 + 번역문 + 언어 쌍 패키지 + 용어집에서 적중된 항목 제공):
    대조를 통해서만 발견할 수 있는 다섯 가지 유형의 오류 + 모델 특유의 실패(문장 누락/내용 추가/과도한 윤문) + 정보 입자 수
    → list-B 출력
R5 병합 및 중복 제거, §6에 따라 심각도 결정, §6의 세 가지 옵션 형식으로 제안 작성
    **병합 후 반드시 한 줄을 보고해야 함: list-A에 N개 항목 중 M개가 최종 목록에 포함됨.**
    단일 언어 검토의 발견이 한꺼번에 필터링되는 것은 프로세스 실패이며, '중요하지 않다'는 의미가 아님——§5.5 참조.
R6 회의론자 재검토(독립 서브 에이전트, **반드시 Read/grep 권한 부여**): critical/major 항목을 하나씩 검토,
    기본적으로 불확실하면 다운그레이드; 제안대로 한 번 수정하고, 수정 후 명확히 좋아지지 않으면 neutral로 다운그레이드;
    실측 경험: 약 절반의 critical/major가 다운그레이드되며, 일부 항목의 논거가 grep에 의해 직접 반박됨
    **회의론자는 다운그레이드만 담당하며, 누락된 발견을 찾지 않음.** 회의론자가 검토하지 않은 minor 항목이 처리되지 않아도 된다는 의미는 아님, §5.5 참조.
R7 findings.md 작성; glossary.md / open-questions.md / decisions.md 업데이트
R8 사용자에게 제공: 먼저 전체 문서 통일 사항을 나열하여 사용자가 결정하게 한 후, 항목별 목록을 제공하여 사용자가 선택하게 함; 선택 후에만 적용

R3/R4/R6의 서브 에이전트 프롬프트 템플릿은 references/subagent-prompts.md에 있으며, 반드시 자체 포함되어야 합니다(파일 경로, 장면, 지름길을 모두 포함하고, 상속된 컨텍스트에 의존하지 않음). 이 스킬의 절대 경로는 ${CLAUDE_SKILL_DIR}입니다. 배포 전에 템플릿의 {{skill_dir}}를 모두 이 경로로 대체해야 합니다. 그렇지 않으면 서브 에이전트가 언어 쌍 패키지/로케일 패키지를 읽을 수 없습니다. (위에 리터럴 ${CLAUDE_SKILL_DIR}이 표시되고, 예를 들어 Codex와 같은 다른 도구에서 경로로 대체되지 않은 경우, 이 SKILL.md 파일이 있는 디렉터리의 절대 경로를 사용하십시오. 이 파일 내의 다른 ${CLAUDE_SKILL_DIR}도 동일합니다.)

5.5 단일 언어 검토의 발견은 병합 시 증발해서는 안 됨

이는 이론적인 우려가 아니라 실제로 겪은 함정입니다. 한 SaaS 랜딩 페이지 프로젝트에서, 모국어 사용자의 피드백 10개 중 8개가 이미 단일 언어 검토에서 보고되었고, 그중 6개는 회의론자 재검토에 전혀 들어가지 않았습니다——병합 시 이중 언어 검토의 발견(누락 번역/지시 대상/용어)에서 후보를 선택했기 때문에, 단일 언어 검토의 가독성 관련 발견이 한꺼번에 필터링되었습니다. 단일 언어 검토가 존재하는 유일한 이유는 '번역처럼 읽히는' 것을 잡아내기 위한 것이며, 그 산출물은 재검토에 들어가기 전에 손실되었습니다.

원인은 구조적인 세 가지가 겹쳐서 발생했습니다: ① 단일 언어 검토의 발견은 거의 모두 minor입니다(그것이 minor의 정의입니다); ② 회의론자는 설계상 critical/major만 검토하며, minor는 결코 재검토에 들어가지 않습니다; ③ 심각도 테이블은 개별 항목 기준으로 결정되며, 개별 항목은 '이해에 영향을 미치지 않지만', 동일한 문장에 여러 개가 쌓이면 '이 문장은 번역처럼 읽힌다'가 되지만, 어느 단계에서도 이를 합산하지 않습니다.

네 가지 고정 조치(프로세스 순서대로):

A. list-A는 반드시 저장되어야 하며, 주 대화가 확인해야 합니다. 요약은 원본을 대체할 수 없습니다——§9.1의 교차 확인은 항목별로 list-A를 비교하는 것이며, 요약만 있으면 연결이 끊어져 나중에 '이 항목을 이전에 보고했는지' 확인할 수 없습니다. '반드시 저장'이라는 규칙만으로는 충분하지 않습니다: 실측에서 저장되지 않은 이유는 서브 에이전트가 다시 쓸 때 API 400으로 중단되었기 때문이며, 규칙이 네트워크 오류를 막을 수 없습니다. 따라서 이는 주 대화 자체의 작업입니다——R3 종료 후 주 대화가 직접 wc -l로 파일이 존재하고 행 수가 일치하는지 확인한 후에만 R5로 진행할 수 있습니다.(에이전트가 완료했다고 말했지만, 주 대화가 직접 확인해야 합니다.)
B. 밀도 업그레이드. 동일한 문자열이 단일 언어 검토에서 ≥3회 보고된 경우, 개별 항목이 아무리 가벼워도 전체 문자열을 T5 재작성 후보로 올립니다. 이유: 세 가지 독립적인 문제가 한 문장에 압축되어 있으면, 개별적으로 수정해도 바뀌지 않으며, 재작성이 더 빠릅니다.
C. 단일 언어 검토의 '재작성이 더 빠름', '읽을 수 없음'은 강력한 신호입니다. 단일 언어 검토가 특정 구간에 대해 '個別修正より書き直しが早い' 또는 '완전히 읽을 수 없음'이라고 말하면, 직접 T5로 보내며, 심각도 필터링을 거치지 않습니다. 이는 모국어 시각에서 유일하게 제공할 수 있는 강력한 판단이며, minor로 처리되어서는 안 됩니다.
D. 병합 시 생존율을 보고합니다. R5 출력에는 반드시 'list-A N개 항목 → 최종 목록 M개 항목'이라는 행이 포함되어야 합니다. M/N이 현저히 낮으면, 다시 확인하여 이중 언어 검토의 발견만 선택했는지 확인합니다.

회의론자에게 minor도 검토하도록 하지 않는 이유: 그 역할이 희석됩니다. 회의론자의 임무는 다운그레이드(과도한 심각도 부여 방지)이며, 만능이 아닙니다. 누락된 발견은 위의 네 가지 조치를 통해 저장 및 병합 단계에서 해결해야 하며, 재검토 단계에서 보완할 수 있다고 기대해서는 안 됩니다.

5.6 그룹 수준의 발견은 한 구성원을 수정하여 '해결'할 수 없음

실제로 겪었고, 오히려 부정적인 점수를 받았습니다. 한 실제 프로젝트에서 네 개의 옵션 각각에 설명 라벨이 있었고, 단일 언어 검토는 **'네 개의 옵션 설명 축이 정렬되지 않음'**이라고 보고했습니다——네 개는 각각 용도, 권장도, 품질, 사양에 대해 설명하고 있었습니다. 이는 이 네 개를 하나의 그룹으로 본 발견이었습니다. 당시 처리 방법은 가장 눈에 띄는 한 가지만 다시 작성하는 것이었습니다. 결과: 축은 여전히 정렬되지 않았고(다른 세 개는 수정되지 않음), 수정된 항목은 이후 세 명의 블라인드 테스트에서 세 버전 중 최악으로 만장일치 판정을 받았으며, 수정 전 원본보다도 나빴습니다. 한 구성원을 수정하는 것은 그룹 문제를 해결하지 못할 뿐만 아니라, 새로운 개별 문제를 추가했습니다.

판단 기준: 발견의 표현에 '정렬되지 않음', '통일되지 않음', '평행하지 않음', '스타일 불일치', '이들 사이에'가 나타나면—— 주어가 복수라면, 이는 그룹 수준 발견입니다.

두 가지 합법적인 처리 방법, 세 번째는 없음:

전체 그룹을 함께 수정하고, 수정 후 전체 그룹을 함께 검증(레이아웃, 너비, 축, 어체 모두 그룹 기준으로 확인).
전체 그룹을 그대로 두고, 이 발견을 확인 대기 목록에 기록하고, '전체 그룹 재작성 필요, 이번 라운드에서는 수행하지 않음'이라고 명시.

허용되지 않음: 그룹에서 가장 눈에 띄는 하나를 수정하고 문제가 해결된 것으로 간주하는 것. 그룹 수준 발견의 올바른 산출물은 전체 그룹의 대체 방안이며, 하나의 항목이 아닙니다.

5.6a 전체 그룹 재작성 후, 스타일 시트로 다시 확인해야 함——그룹 수준 수정은 이미 이 구성원들을 규제하는 제약 조건을 위반해서는 안 됨

§5.6은 '전체 그룹 수정'이라고 하지만, 절반만 말했습니다. 실측: §5.6에 따라 해당 라벨 그룹을 전체 재작성하여 축이 통일되고 너비도 수렴되었지만(3.00×→1.43×), 모국어 사용자 블라인드 테스트에서 '지명된 하나만 수정한 경우'에 패배했습니다——두 명이 거부한 이유는 「体言止めで短く揃えるのが日本のUI標準」이며, 이 규칙은 이미 해당 프로젝트 자체의 스타일 시트에 명시되어 있었습니다. 축은 고쳐졌지만, 어체 규칙을 위반했습니다. 근본 원인은 규칙에 있는 것이 아니라, 프롬프트가 기억에 의존하여 제약 조건을 재진술하고 스타일 시트 원문을 복사하지 않았기 때문입니다.

고정 조치: 이미 확정된 문자열을 수정하기 전에 먼저 '이 문자열은 이미 어떤 결정에 의해 규제되고 있는가'를 묻고, 해당 항목의 원문을 프롬프트에 복사해야 합니다——기억에 의존하여 재진술하는 것은 허용되지 않습니다. 최소한 다음 네 가지 유형을 복사해야 합니다:

복사할 항목	출처
적중된 용어 항목	`glossary.md`
적용되는 스타일 시트 행(어체, 끝맺음, 구두점, 공백, 너비 하드 제약)	`style-sheet.md` ← 가장 놓치기 쉬운 유형
해당 병렬 그룹의 기정된 작성 축	`style-sheet.md`의 '병렬 그룹의 작성 축' 행
장면 한 줄과 이번 지름길	`00-brief.md`

T3에는 원래 이 요구 사항이 있습니다(§5.2 '각 구간에 glossary 적중 항목 + style-sheet + 장면 + 지름길 포함'). 함정에 빠진 것은 프로세스 외부의 임시 재작성 작업——모국어 피드백 수정, 통합 버전 생성, 누락 번역 보충. 이러한 작업은 T3 번호를 거치지 않으므로 '손쉽게 수정'하는 것으로 간주되어 페이로드 없이 처리되기 쉽습니다. T3와 마찬가지로 전체 페이로드를 포함해야 합니다.

병렬 그룹의 축이 '지시 대상'과 충돌할 때, 지시 대상이 우선합니다——축을 깨더라도 의미를 수정하지 마십시오. 실측: 원문 네 칸 중 세 칸은 A + B, 한 칸은 A / B(또는)였으며, 스타일 시트는 이 그룹의 연결자를 모두 「＋」로 통일했습니다. 생성 측에서 축을 따라 해당 칸의 '또는'을 '그리고'로 작성했습니다——레이아웃 통일을 위해 원문의 의미를 변경한 것인데, 이는 철칙 8에서 금지하는 것입니다. 축은 표현 층이고, 지시 대상은 사실 층입니다. 충돌하면 이 칸의 축을 깨고(「／」 사용), 보고서에 깬 이유를 기록합니다. 레이아웃 일관성은 지시 대상보다 우선할 수 없습니다——이 규칙도 검수 측의 검사 항목에 포함되어야 합니다. 자연스럽게 읽히지만 원문과 대조해야만 알 수 있기 때문입니다.

재확인 작업: 전체 그룹 수정 후, 새 그룹을 스타일 시트에 대해 항목별로 확인하고, 새 그룹이 이전 그룹에 없던 문제(너비, 어체, 구두점, 인접 그룹과의 일관성)를 도입하지 않았는지 확인합니다. length_estimate.py --siblings는 너비만 확인할 수 있으며, 어체는 사람이 확인해야 합니다.

부산물: 그룹 내 이산도는 기계 검사 가능합니다. 병렬 그룹(key에 하나의 토큰만 변경됨, 예: plan_lite_/standard_/pro_/max_description, 예시)의 표시 너비 극차는 length_estimate.py --siblings가 나열합니다. 한 실제 프로젝트에서 6개의 병렬 그룹 중 5개의 극차가 ≤1.67배였고, 수정된 그룹만 3.00배였습니다. 스크립트는 나열만 하고 판단하지 않습니다——임계값을 몇 배로 설정할지에 대한 프로젝트 간 근거가 없으므로, 임의로 설정하지 마십시오.

5.2 translate: 처음부터 번역(원문만 있음)

T0 입력 수집(가능하면 대상 언어 유사 자료 샘플 요청) → 00-brief.md → 규칙 패키지 로드
T1 전체 문서 사전 분석, 작업하지 않음: 전체 문서 읽기 → 용어 후보 추출 → 확인 대기 목록 작성
    여러 곳에 영향을 미치는 의문 → 먼저 사용자에게 문의; 한 곳에만 영향을 미침 → '추정' 표시 후 계속
T2 용어 결정(세 가지 관문: 기존 단어? 충돌? 레이아웃에 들어맞는가?) → glossary.md
    **'확정성 눈금', '상태 배지'와 같은 자체 체계를 가진 단어는 반드시 목표 시장의 유사 자료에서 기존 표현을 찾아야 합니다.**
    실측: 프로세스는 확정성 업그레이드를 방지하기 위해 4단계 눈금을 설계했으며, 가장 강력한 단계는 `検証済み`로 결정했습니다——**설계는 옳았지만, 단어 선택이 잘못되었습니다.**
    세 명의 모국어 사용자가 일관되게 투자 자료 트랙션 배지의 정식 표현은 `実績`이며, `検証済み`는 제3자 검증을 연상시킨다고 지적했습니다.
    **일관된 눈금 체계가 목표 시장에서 사용 중인 눈금 체계와 같지 않습니다.**
    **용어의 출처는 '그 자료가 누구에게 보여졌는가'와 함께 기록되어야 합니다——단어가 목표 언어에 존재함 ≠ 대상 독자가 읽고 즉시 이해함.**
    실측 **네 번의 동일 유형**: 네 개의 단어가 모두 '검증됨'으로 간주되었으며, 근거는 각각 다른 회사의 제품 페이지, 일반 사전, 자체 설계 눈금, 제조업체 기술 블로그였습니다——
    결과는 하나는 다른 회사 제품이 할 수 있지만 자료의 제품은 할 수 없는 일; 하나는 일본어에서 다른 분야에서만 사용됨;
    하나는 대상 독자의 자료에서 과장된 표현; 하나는 기술 독자는 자주 사용하지만 비즈니스 독자는 거의 사용하지 않음.
    **공통 근본 원인**: 출처의 독자와 자료의 독자가 동일한 그룹이 아닙니다.
    → 출처 열은 반드시 `출처(독자 프로필)` 형식으로 작성되어야 합니다: '某제조업체 기술 블로그(독자=エンジニア)'와
    '투자자 대상 사업 계획서(독자=投資担当)'는 **다른 것이며, 서로 대체될 수 없습니다**.
    검증 시 **동일한 유형의 독자**를 대상으로 한 자료를 우선적으로 찾으십시오.
    **항목 선택은 '이 단어가 어려워 보인다'는 이유만으로 할 수 없으며, 먼저 빈도수를 확인해야 합니다**:
    `term_coverage.py cover`는 원문의 고빈도 실사 중 용어집에 포함되지 않은 것을 나열합니다. **고빈도 + 병렬 위치에 반복적으로 나타나는 단어는 반드시 항목이 있어야 하며**,
    전혀 어려워 보이지 않더라도 마찬가지입니다. 포함하지 않기로 결정한 경우에도 테이블에 '통일 불필요, 이유는...'라는 행을 작성하여 다음 사람이 알 수 있도록 해야 합니다.
    실측 누락: `팀`(9회)과 `회사`(10회) 모두 '어려워 보이지 않는다'는 이유로 테이블에 포함되지 않아 번역문에 각각 두 가지 번역이 나타났으며,
    **테이블에 포함된 단어의 일관성은 100%였습니다.** 항목이 없음 → 기계적 일관성 목록이 적용되지 않음 → 인도 전 grep 검사가 탐지하지 못함 →
    이중 언어 검토에서 '테이블대로 사용했는가'를 확인할 테이블이 없음. **한 층이 누락되면 네 층이 모두 비게 됩니다.**
    스타일 시트는 로케일 패키지 기본값에서 시작 → style-sheet.md
    **마무리 전에 결정 파일 간의 일관성을 반드시 확인해야 합니다**: glossary / style-sheet / decisions에서 동일한 단어의 표기가 일치해야 합니다.
    실측에서 겪음——glossary는 `一括エクスポート`로 결정했지만,
    style-sheet의 동일한 병렬 그룹은 `まとめて書き出し`로 작성되었으며(단어 예는 예시), 생성 측은 둘 중 하나를 선택해야 했고,
    어떤 것을 선택해도 검수 측에서 오류로 보고될 수밖에 없었습니다. **두 개의 결정 파일이 충돌하면 하류에서는 해결 방법이 없습니다.**
    기계 검사: glossary의 '대상 언어 단어' 열을 하나씩 grep하여 다른 두 파일에서 다른 형태가 나타나면 중지하고 통일합니다.
T3 구간별 생성(각 구간에 동일한 glossary의 적중 항목 + style-sheet + 장면 + 지름길 포함):
    ① 의도 추출: 이 문장이 실제로 말하고자 하는 바(문자 그대로를 벗어나)
    ② 장면 재구성: 목표 시장의 사람이 이 장면에서 어떻게 쓸 것인가(샘플이 있으면 샘플의 문장 구조/어체 대조)
    ③ 감 다듬기: 어체, 길이, 전체 문서 일관성
    항상 자문: 내가 이 단어를 선택한 이유가 원문도 이 형태이기 때문인가(번역), 아니면 이러한 유형의 자료가 이렇게 쓰이기 때문인가(현지화)?
    → draft.<locale>.md
T4 (원문, draft)에 대해 §5.1의 R1–R7 실행(독립 컨텍스트)
T5 findings에 따라 draft 수정; 일관성 스캔 실행(용어집의 각 단어가 전체 문서에서 실제로 사용된 방식);
    **`distribution_check`를 한 번 더 실행**——항목별 수정은 전체 문서 분포를 변경할 수 있으므로, 수정 후 반드시 분포를 다시 확인해야 함
T6 인도: draft + glossary + style-sheet + open-questions + decisions(+ 길이 보고서)

5.2b adapt: 저자 승인 후 구조/장르 재구성(MVP)

translate는 이미 문장 구조 변경 및 표현 재배열을 허용합니다. adapt의 차이점은 사전 승인 + 감사 가능한 구조/장르 재구성입니다. 사용자가 '번역/현지화'만 말하면 여전히 translate를 사용하고, '일본 시장에 맞게 재작성/일본 회사 스타일로 변경/제안서 재구성'을 말하고 명시적으로 승인했을 때만 adapt를 사용합니다.

시작 전에 반드시 필요: 대상 독자와 일치하는 유사 자료 샘플, 저자 승인 테이블, 성공 기준. 이 중 하나라도 누락되면 adapt를 중단하거나 translate로 되돌립니다. 모델이 자체 판단할 수 없습니다.

재구성 가능: 제목 및 정보 계층, 단락/단계 순서, 표현 단위 병합/분할, 목표 시장의 표시 계층, 승인된 업계/장르 표현, 표현 형식(산문 ↔ 표/번호 단계, AUTH-08)——이 항목은 별도로 나열됩니다. 산문을 표로 변경하면 한 문장이 여러 칸으로 분할될 수 있으며, 조건과 부정이 분할 과정에서 가장 쉽게 누락되기 때문입니다. 절대 변경 불가: 숫자, 날짜, 주체, 대상, 수량, 시간, 기능, 가격, 무료/유료 조건, 효과 강도, 법적 의미, 부정 및 제한.

프로세스: A0 입력/승인 → A1 목표 시장 관행 → A2 사실 원장 → A3 최대 두 개의 구조 방안 및 저자 승인 대기 → A4 구간별 재구성 → A5 독립 사실/지시 대상 및 자연도 검수 → A6 저자 승인. 저자가 구조 방안을 승인하지 않으면 생성 불가; 저자가 승인하지 않으면 완료라고 할 수 없음.

산출물: authorization.md, market-conventions.md, fact-ledger.md, structure-options.md, adapt-map.md, decisions.md, open-questions.md, 완성 원고; adapt-map은 하나의 소스 단위가 여러 대상 단위에 대응되거나, 여러 소스 단위가 하나의 대상 단위로 병합되는 것을 지원합니다. N≠M이 누락 번역을 의미하지는 않으며, 반드시 매핑 및 사실 원장 대조를 통해 확인해야 합니다.

운영형 자료에는 task-test.md도 필요: 핵심 작업 성공률이 translate보다 낮을 수 없음; 더 자연스럽지만 사용자가 작업을 실패하기 쉬우면 adapt는 실패로 간주합니다.

두 가지 기계 검사 관문(통과하지 않으면 진행 불가):

# A3→A4: 실제 저자 승인 이벤트가 없으면 생성 불가
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py gate \
    --authorization <승인 테이블> --structure <구조 방안> --conventions <시장 관행> [--map <adapt-map>]
# A4→A5: 다대다 매핑 및 사실 입자 하나씩 적용
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py map \
    --source <원문> --ledger <사실 원장> --map <adapt-map> --draft <대상 원고> \
    --authorization <승인 테이블> --glossary <용어집>

원문과 대상 원고 모두 단위 앵커( / )를 포함해야 하며, 그렇지 않으면 단위 수준 검증이 불가능합니다. gate 종료 코드 2 = 생성 불가. 차단하는 항목: AUTH-07 잠금 해제, '승인됨' 표시되었지만 저자 확인 이벤트 없음, 승인 방안이 A / B / 승인 거부와 같은 자리 표시자, 독자 일치하는 검증된 샘플 없음, map이 승인되지 않은 AUTH를 참조. '모델이 테이블에 스스로 승인됨을 기재'하는 것이 바로 이 관문이 차단하려는 것입니다. map 종료 코드 1 = 차단 있음. 차단하는 항목: 원장 해시가 원문과 일치하지 않음(생성 후 원장 수정), 소스/대상 단위가 매핑되지 않았거나 출처 없음, 원장 입자가 적용 테이블에 행이 없음(매핑 격차), 적용 테이블이 원장의 소스 값을 수정, 선언된 대상 구현 문자열이 해당 대상 단위에 존재하지 않음(병합 시 입자 손실), 주체의 대상 구현이 용어집의 정해진 번역과 일치하지 않음(수혜자 변경), 숫자/날짜/URL이 한쪽에만 존재함(사실 손실 또는 사실 추가).

이 두 관문이 증명할 수 있는 것과 증명할 수 없는 것을 함께 설명해야 합니다: 스크립트는 '선언된 문자열이 지정된 단위에 문자 그대로 나타나는지'만 검증하며, 이 문자열이 의미론적으로 해당 입자를 실제로 표현하는지는 판단하지 않습니다——부정을 삭제하고 적용 테이블도 실제로 존재하는 관련 없는 문자열로 변경하면 기계 검사를 통과할 수 있습니다. 또 다른 허점은 대상 측 적용이 단위 수준으로만 제한된다는 점입니다: 각 대상 단위에 출처가 있음을 보장하지만, 단위 내부의 모든 문장에 출처가 있음을 보장하지는 않습니다, 따라서 이미 매핑된 단위에 지어낸 문장을 삽입하면 스크립트는 볼 수 없습니다(숫자/날짜/URL 계층만 일부를 포착할 수 있음). → 대책: adapt-map에는 반드시 수동으로 '추가된 텍스트' 테이블을 작성해야 하며, 표 머리글, 각주 기호, 안내 문장, 소제목과 같은 비원문 단언을 항목별로 나열하고 독립적인 검수에 제출해야 합니다. 의미 유지는 템플릿 F의 독립 검수에 맡기고, 장르 적합성은 저자 승인에 맡깁니다. 스크립트 통과 ≠ adapt 통과.

자세한 템플릿 및 프롬프트는 templates/authorization.md, templates/adapt-map.md, references/subagent-prompts.md의 템플릿 E/F를 참조하십시오.

현재 검증 상태: 승인 관문 및 사실 매핑 계약에는 32개의 자동 양성/음성 회귀 테스트(evals/test_adapt_checks.py, 샘플 evals/smoke/adapt/)가 있으며, '2→1 병합 시 모든 조건 유지 → 통과, 부정 하나 삭제 → 실패, 수혜자 변경 → 실패, 승인되지 않음 → 생성 불가'를 포함합니다. 실제 자료(Joplin 도움말 문서 en→ja, Evernote 섹션 15단위 → 9단위)에서 A0–A4를 성공적으로 실행: gate와 map 모두 0 차단, 다섯 번의 적대적 변조가 모두 차단됨('원고와 신고를 동시에 변경'하는 수혜자 교체 포함). A5 독립 검수 완료(함정 라운드 + 클린 라운드 이중 검증); A6 저자 승인, 대상 사용자 작업 테스트, 모국어 통독은 아직 수행되지 않음——이 세 가지가 완료되지 않으면 adapt 통과를 선언할 수 없음. 실측 교훈: 실제 자료 첫 실행 시 보고된 5개의 문제는 모두 관문/템플릿 자체의 결함이었습니다 (방안 이름이 단일 문자로 제한됨, 관행 파일의 두 테이블 형식, 영어 철자 숫자, 관문이 스스로 승인한 '산문→번호 단계' 차단, 구조 변경 없는 행이 승인 참조를 강제받음). 관문이 실제 자료를 처음 접할 때 보고하는 오류는 먼저 관문을 의심하십시오.

5.3 원문 없음(번역문만 있음)

원문이 없으면 누락 번역, 지시 대상 편향, 숫자 불일치와 같은 번역의 실질적 오류를 확인할 수 없습니다; 어감, 내부 일관성, 표기 규범은 확인할 수 있습니다. char_lint / term_coverage / distribution_check(전사율은 적용 불가)와 R3을 실행하고, 판단할 수 없는 항목은 확인 대기 목록에 포함합니다.

하지만 sourceLanguage에 명시된 언어 ≠ 텍스트 작성자가 해당 언어의 모국어 사용자임을 의미하지 않습니다. 원문 없이 작업을 시작할 때 반드시 물어야 합니다: "이 대상 언어 텍스트는 누가 썼습니까?"

대상 언어 모국어 사용자가 작성 → 위의 제한 사항이 적용됨; 가독성 문제를 번역 오류로 작성할 수 없음.
비모국어 사용자가 직접 작성(독립 개발자, 해외 진출 팀의 자체 제작 카피) → 작성자의 모국어가 '숨겨진 원문'이므로, 해당 pairs/<작성자 모국어>-<대상 언어>.md를 로드하고, 이중 언어 검토 방법으로 모국어 간섭을 스캔; 거짓 친구, 작성자 모국어 단어 잔재, 동일 개념 누락 통일을 찾을 수 있음, 하지만 보고서에는 이것이 '모국어 간섭'이며, 원문-번역문 대조 결론이 아님을 명확히 기록해야 함.
작성자 알 수 없음 → 작성자 모국어를 추측하지 않음; 대상 언어 내에서 증명 가능한 문제만 보고하고, '작성자 출처 미확인'이라고 별도 표시.

실측(한 앱, 대상 언어 카피가 비모국어 작성자에 의해 직접 작성됨): 단일 언어 검토는 작성자 모국어 단어 잔재를 몇 군데 발견; 동일한 앱의 다른 문자열에서 동일한 개념이 이미 현지화된 표현으로 작성되었으므로, 이는 내부에서 증명 가능한 모국어 간섭입니다. 이러한 경우는 독립 개발자/해외 진출 팀에서 일반적이며, 특이 사례가 아닙니다.

5.4 다국어 병행 / 지속적 업데이트(간략히)

다국어 병행: 먼저 source of truth 결정; 용어집에 열 추가(개념 | 언어 A | 언어 B...); 모든 버전 간 숫자 및 사실 대조(fact_check.py를 쌍으로 실행); '의도적 차이' 설명 유지. 지속적 업데이트: 용어집 및 스타일 시트는 장기 자산으로, .l10n/ 임시 디렉터리가 아닌 사용자 프로젝트에 보관; 새 콘텐츠는 R1–R4만 실행.

6. 심각도, 발견 형식, 세 가지 옵션

…

[이하 내용 생략]

Localize：현지화 및 번역 검수