(KO) PostgreSQL KO 번역 현황 — 문서별 단계 보드

목차

• 이 문서가 있는 이유
• 단계 모델은 다른 곳에 있다
• PostgreSQL KO 미러는 어떻게 만들어졌나
• 현재 단계: 전부 P2
• 집계
• 남은 후속 작업

이 문서가 있는 이유

knowledge/code-analysis/postgres/ 의 모든 EN 문서는 knowledge/ko/code-analysis/postgres/ 에 KO 미러를 가진다. 이 미러는 번역이 아니라 병렬 구성으로 작성됐다는 점이 핵심이다 (knowledge/CLAUDE.md §“Bilingual layout”). 이 보드는 각 미러가 얼마나 성숙했는지, 남은 품질 게이트가 무엇인지를 기록한다. 그래서 나중에 읽는 사람이 특정 KO 미러가 바로 공개해도 되는 수준인지, 아니면 다듬기·검수가 더 필요한지를 판단할 수 있다.

단계 모델은 다른 곳에 있다

5단계 성숙도 모델과 그 규칙은 한 곳에서만 정의한다 — cubrid-translation-status.md 와 플레이북 knowledge/methodology/korean-translation.md 이다. 여기서 다시 정의하지 않는다. 요약하면 다음과 같다.

• P0 — 직역 KO 미러.
• P1 — S1 기계 클린업 게이트 (kb-ai-tell-check 에서 S1 findings 0).
• P2 — 구조 재작성 (병렬 구성, S1-clean, 훑어보기 쉬운 한국어).
• P3 — 자연스러운 한국어 prose (전용 다듬기 패스).
• P4 — 원어민/opus 검수 통과.

문서별 단계 마커 규약(각 KO 미러 frontmatter 의 tags: 에 들어가는 p<n> 태그가 단일 출처이고, 다른 문서가 KO 미러를 가리킬 때 쓰는 [KO_p<n>](path) 링크 마커)도 그 문서에 정의돼 있다. 모델을 바꾸려면 cubrid 문서를 고친다. 이 문서가 아니다.

PostgreSQL KO 미러는 어떻게 만들어졌나

PostgreSQL 트리는 cubrid 의 P0→P1 경로(직역 미러를 만든 뒤 번역체를 여러 라운드로 기계 클린업)를 거치지 않았다. 대신 각 KO 미러를 처음부터 한국어 병렬 구성으로 작성했다.

• 모델: sonnet, 단일 패스, 리뷰어 루프 없음 (knowledge/CLAUDE.md rule 9 — KO 작성은 EN writer-reviewer 루프와 분리된다).
• 문체: §“한국어 작성 스타일” 규칙 — 영어 기술 용어는 첫 등장에서 짧은 한국어 풀이를 괄호로 달고 그대로 쓴다, 한 문장에 한 가지 생각, 설명형 어미 (~다는 점이다, ~란 ~을 의미한다, 이는 … 때문이다).
• 문서별 게이트: KO 파일에 kb-ai-tell-check 를 돌려 A-계열 findings 를 S1 = 0 까지 정리했다.
• EN 과 공유하는 구조: 같은 섹션 순서, 같은 영어 코드 발췌, 같은 Mermaid 골격 (같은 노드 ID), 같은 position-hint 표, 같은 교차참조 문서 이름, 같은 updated: 날짜.

이 미러들은 S1-clean 병렬 구성이라 P0/P1(직역 후 클린업) 단계는 구성상 이미 지난 셈이다. 다만 별도의 prose 다듬기 batch(P3)나 원어민 검수(P4)는 아직 거치지 않았다. 그래서 P2 에 위치한다.

현재 단계: 전부 P2

2026-06-06 기준 knowledge/ko/code-analysis/postgres/ 의 모든 KO 미러는 P2 다. 이것이 프로젝트 전체의 균일한 상태다. 아직 문서별 차이가 없으므로, 이 보드는 139개의 동일한 행 대신 집계를 기록한다. (cubrid 는 전용 다듬기 batch 이후 103개 미러가 균일하게 P3 라는 점과 대비된다.)

PostgreSQL 만의 P1 하위 게이트 주석: cubrid 의 “four-phase rewriter” 내부 하위 단계(Hangul-anchored → boundary → boundary-relaxed → cross-line)는 이미 있던 직역 미러를 클린업하던 작업이라 여기에는 적용되지 않는다. PostgreSQL 미러는 애초에 직역이 아니었으므로 기계적으로 번역체를 걷어낼 대상이 없었다. 문서당 한 번의 kb-ai-tell-check 패스가 S1 게이트를 덮는다.

집계

그룹별 KO 미러 수 (전부 P2):

그룹	KO 미러
overview + coverage + translation-status	16
storage-engine 모듈	20
txn-recovery 모듈	14
query-processing 모듈	20
server-architecture 모듈	9
monitoring-stats 모듈	2
system-catalog 모듈	6
ddl-schema 모듈	10
replication-ha 모듈	9
client-protocol 모듈	3
extensibility 모듈	6
base-infra 모듈	7
i18n-text 모듈	3
utilities 모듈	8
evolution 문서	7
합계	약 140

(정확한 합계는 EN 트리와 1:1 로 맞춰진다. 정밀한 수가 필요하면 ls knowledge/ko/code-analysis/postgres/*.md 로 다시 센다. EN = KO = meta 정합은 배치마다 유지된다.)

남은 후속 작업

1. 문서별 p2 frontmatter 태그 찍기. cubrid SSOT 규약은 단계 태그를 각 KO 미러의 tags: 배열에 둔다. PostgreSQL 미러는 아직 이 태그가 없다. 기계적 패스로 각각 p2 를 달면, 이 보드가 손으로 주장하는 균일 상태가 아니라 파생 상태가 된다.
2. P3 승격. 방법론에 따른 전용 자연 prose 다듬기 batch(sonnet)를 돌리면 트리가 P3 로 올라간다 — cubrid 와 같은 수준이 된다.
3. P4 승격. 문서별 원어민/opus 검수 통과. 사람 또는 opus 의 판단이 필요한 유일한 단계다.
4. [KO_p2](path) 링크 마커. EN 문서가 자기 KO 미러를 가리킬 때, cubrid SSOT 의 마커 규약을 현재 단계 값으로 맞춰 쓴다.