rfc-ko

번역 가이드

RFC를 한국어로 번역할 때 지키는 규칙과 요령입니다. 단어별 번역은 용어집을 따릅니다.

1. 용어

• 용어집을 먼저 확인하세요. 같은 단어를 한 번은 “요청”, 다른 데서는 “리퀘스트”라고 쓰는 게 기술 번역에서 가장 흔한 실수입니다. 번역하다 새 용어가 나오면 바로 glossary.md에 추가합니다.
• 원어는 정해진 곳에서만 병기하세요. 예: 흐름 제어(flow control). 요약과 본문에서 각각 처음 나올 때, 그리고 원문이 그 용어를 따옴표로 정의하는 곳에서 병기하고, 그 밖에는 번역어만 씁니다. 병기가 다른 괄호 안에 들어가도 괜찮습니다. IANA 레지스트리 이름도 번역하고 처음 나올 때 원어를 병기합니다.
• 억지로 번역하지 마세요. 개발자 사이에서 굳어진 말은 그대로 쓰는 편이 읽기 쉽습니다. 헤더, 프레임, 스트림, 페이로드, 캐시처럼요.
• 고유 식별자는 번역하지 마세요. SETTINGS_MAX_CONCURRENT_STREAMS, GET, :authority, 상태 코드 이름, ABNF 규칙 이름, 스트림 상태 이름은 원문 그대로 둡니다.
• 새 용어는 두 사전을 함께 찾아보고, 정보통신기술용어해설 표기를 기본으로 하세요. 정보통신기술용어해설과 TTA 정보통신용어사전을 함께 찾아봅니다. 정보통신기술용어해설 표기를 따르고, TTA 표기가 다르면 용어집 비고에 사전 용어를 함께 적습니다(예: heuristic은 휴리스틱, 비고에 TTA: 발견적). 두 사전 모두 개발자 관용과 다르거나(예: idempotent의 TTA 용어 “등멱원”과 관용 “멱등”) 사전에 없으면 MDN 한국어 문서나 국내 교재의 용어를 참고해 정하고, 굳어진 말은 그대로 씁니다.
• 원어의 뜻이 애매하면 영어사전을 찾아보세요. 예: authoritative는 “권한(authority)에서 나온”이라는 뜻이라 “권한 있는 응답”으로 옮깁니다. 기본은 Merriam-Webster이고, 근거가 된 뜻은 용어집 비고에 짧게 적습니다.
• 같은 원어라도 문맥에 따라 번역어가 다를 수 있습니다. 예: validator는 HTTP 문맥에서 검증자, 프로그램을 가리키면 유효성 검사기. 용어집 비고에 문맥별 번역을 적습니다.

2. 규범 키워드 (RFC 특유)

• MUST, SHOULD, MAY 같은 대문자 키워드는 한국어로 옮기고 괄호 안에 대문자 원어를 남깁니다. 예: 반드시 ~해야 한다(MUST). 키워드별 표현은 glossary.md의 규범 키워드 표를 따릅니다.
• 같은 단계의 키워드(예: SHOULD와 RECOMMENDED)는 강도가 같습니다. 표현만 나눠 씁니다.
• 소문자 “must”는 규범 키워드가 아니므로 일반 서술로 번역하고 괄호를 붙이지 않습니다. RFC 8174가 이 구분을 명시합니다.
• 문서 앞부분의 BCP 14 고정 문구는 glossary.md에 등록된 번역을 그대로 씁니다.

3. 문장

• 긴 문장은 나누세요. 영어의 관계대명사를 한 문장에 몰아넣으면 읽기 힘들어집니다. 두세 문장으로 끊는 게 낫습니다.
• 수동태는 능동으로 바꾸세요. “is sent by the client”는 “클라이언트가 보낸다”로 옮깁니다.
• 주어를 생략하지 마세요. 한국어는 주어를 자주 빼지만, 기술 문서에서는 “누가” 하는지(클라이언트인지 서버인지 중개자인지)가 핵심이라 명시하는 게 안전합니다. 원문에 없는 주어는 문맥상 분명할 때만 보충합니다.
• 문체를 통일하세요. RFC 번역에는 “~한다”체가 잘 어울립니다. 한 문서 안에서 “~합니다”와 섞지 마세요.
• 대명사를 풀어 쓰세요. “it”이나 “this”가 가리키는 대상이 애매하면 “이 프레임”, “해당 스트림”처럼 구체적으로 씁니다.

4. 정확성

• 의미를 바꾸는 의역은 피하세요. 매끄럽게 쓰려다 조건이나 범위가 바뀌면 안 됩니다. “unless”, “only if”, “at most” 같은 조건 표현은 특히 꼼꼼히 보세요.
• 숫자와 단위는 원문과 대조하세요. 옥텟(octet), 비트 오프셋, 기본값, 최댓값을 다시 확인합니다.
• 애매한 곳은 표시해 두세요. 해석이 갈리는 문장에는 역주를 달거나 <!-- TODO: 확인 필요 -->를 남겼다가 나중에 정오표나 메일링 리스트를 찾아봅니다.
• 역주는 원문과 구분하세요. 예: > **역주:** RFC 7540의 우선순위 체계는 이 문서에서 폐기되었다.
• 저작권 고지는 원문을 그대로 두세요. 원문이 따르는 IETF Trust 법적 조항은 번역을 허용하되 원문의 법적 고지를 함께 싣도록 합니다. 원문 Copyright Notice를 인용 블록으로 두고 그 아래에 번역을 두며, 절 끝 역주에 그 근거와 법적 효력은 원문에 있다는 것을 적습니다.
• 정오표를 확인하세요. 번역 전에 https://www.rfc-editor.org/errata/rfcNNNN을 보고, 반영한 것과 반영하지 않은 것을 번역본 머리말에 적습니다. 고친 곳은 원문을 취소선으로 남기고 고친 내용을 함께 두며, 역주는 “정오표 7138(Verified)에 따라 0.7을 고친 값이다.”처럼 한 줄로 씁니다.

5. 구조와 작업 방식

• 섹션 번호와 앵커를 유지하세요. ## 6.5. SETTINGS처럼 원문 번호를 그대로 두면 다른 RFC의 참조를 따라가기 쉽습니다.
• 목차는 링크로 거세요. 번역한 장은 하위 절까지 링크 목록으로 펼치고, 아직 번역하지 않은 장은 제목만 둡니다. 본문에서 번역한 절을 참조하는 곳도 링크로 바꾸고, 깨진 링크가 없는지 확인합니다.
• 그림, 코드, ABNF는 번역하지 마세요. ASCII 다이어그램과 ABNF는 그대로 두고, 필요하면 아래에 설명만 덧붙입니다. 구조체 정의 같은 코드 블록은 코드를 그대로 두고 코드 안의 주석만 옮깁니다.
• 섹션 단위로 커밋하세요. 예: rfc9113: 5장 번역.
• 소리 내어 읽어 보세요. 하루 지나서 원문 없이 번역문만 읽어 보면 어색한 곳이 잘 보입니다.
• AI 초벌 번역을 쓴다면 이 가이드와 용어집을 함께 주고, 결과는 반드시 원문과 한 문장씩 대조하세요. 규범 키워드와 조건 표현이 바뀌는 경우가 잦습니다.