기술 용어, 대소문자 표기 및 번역 레이블을 교정하는 방법
기술 문서를 검토할 때는 기억이나 단일 대소문자 규칙에 의존하기보다 명시적인 용어 표를 기준으로 각 용어를 대조해야 합니다. 승인된 형태, 독자에게 노출되어야 하는 철자와 대소문자 표기, 허용되는 변형, 리터럴 코드나 API 식별자, 아직 결정 대기 중인 번역을 기록하세요. 그런 다음 본문 문장, 인터페이스 레이블, 식별자를 각각 별도의 항목으로 나누어 교정합니다. 이 방식은 고유 명칭과 코드의 정확성을 그대로 유지하면서 일관되지 않은 용어를 효과적으로 잡아냅니다.
하나의 대소문자 표기 규칙으로 모든 용어를 해결할 수 없는 이유는 무엇일까요?
스타일 가이드는 유용한 기본 지침을 제공하지만, 특정 제품이나 도메인에는 별도의 처리가 필요한 고유 명칭이 이미 정립되어 있을 수 있습니다. Google 개발자 가이드는 제목, 목록, 표에 표준 미국식 영어 대소문자 및 문장형 대소문자(sentence case)를 권장하는 동시에 공식 제품명과 코드 형태는 그대로 유지하도록 규정합니다. Microsoft 가이드 역시 문장형 대소문자 표기를 선호하지만, 자사 브랜드, 제품, 서비스와 같은 고유명사에는 대문자 표기를 명시적으로 지정합니다. 두 가이드의 공통된 기본 규칙은 출발점일 뿐이며, 특정 기술 용어가 일반명사임을 입증하는 근거는 아닙니다. [Google의 대소문자 표기 지침](https://developers.google.com/style/capitalization) [Microsoft의 대소문자 표기 지침](https://learn.microsoft.com/en-us/style-guide/capitalization)
단어 목록(word list)은 일반적인 대소문자 표기 지침 페이지와는 다른 질문에 답을 제시할 수 있습니다. 즉, 특정 편집 가이드가 개별 용어에 대해 선호하는 철자나 용법이 무엇인지 알려줍니다. 예를 들어 Google의 단어 목록은 직접 다루지 않는 항목에 대해 선호하는 사전을 안내하며, 스타일 지침과 권위 있는 공식 문서의 기술적 정의 확인을 명확히 구분합니다. 이러한 분리는 매우 유용합니다. 편집상의 일관성과 기술적 정확성을 확보하려면 각 질문에 부합하는 적절한 출처의 근거가 필요하기 때문입니다. [Google의 단어 목록](https://developers.google.com/style/word-list)
교정용 용어 표에는 어떤 내용이 들어가야 할까요?
일관성 없게 변경되거나 오역될 우려가 있는 용어마다 행을 하나씩 만드세요. 다음의 가상 예시는 필드 구성과 판단 로직을 보여주기 위한 것으로, '동기화 토큰(Sync token)' 및 해당 번역은 설명을 위한 예시일 뿐 실제 제품이나 승인된 용어를 나타내는 것은 아닙니다.
표의 역할은 내린 결정과 그 적용 범위를 보존하는 데 있습니다. 허용된 소문자 형태가 부지불식간에 또 다른 제품명이 되어서는 안 되며, 식별자가 본문 흐름에 맞춘다는 이유로 '수정'되어서도 안 되고, 미해결된 번역은 여전히 미결정 상태임이 명확히 드러나야 합니다. 공식 출처와 내부 용어집이 충돌할 경우, 형태들을 설명 없이 뒤섞어 놓지 말고 충돌 사실과 최종 결정의 출처를 함께 기록하세요.
표시되는 철자와 대소문자는 어떻게 결정해야 할까요?
먼저 해당 용어가 무엇을 가리키는지 확인하세요. 일반 개념인지, 브랜드 또는 제품명인지, UI 레이블인지, 아니면 리터럴 식별자인지 파악합니다. 관련 제품 문서나 용어집에서 공식 형태를 확인하세요. 그런 다음 대상 출판물의 스타일 규칙을 일반 본문, 제목, 레이블에 적용하되, 고유 명칭과 식별자에 대해 문서화된 예외 사항은 유지합니다. Google은 불필요한 대문자 표기를 지양하고 대소문자만으로 의미를 구분하지 말 것을 경고하며, Microsoft 역시 문장형 표기 접근 방식에서 문장의 시작과 고유명사를 제외하고는 소문자를 사용할 것을 권장합니다. [Google 대소문자 표기 지침](https://developers.google.com/style/capitalization) [Microsoft 대소문자 표기 지침](https://learn.microsoft.com/en-us/style-guide/capitalization)
다음으로 대상 조직의 단어 목록 및 사전을 참조하여 형태를 비교 대조하세요. 다른 편집자가 해당 결정을 추적할 수 있도록 출처와 버전 또는 확인 날짜를 기록해 둡니다. 보기 좋아 보이는 대문자 표기, 단순 검색 결과, 혹은 영어 용어와 유사해 보이는 번역문만을 근거로 공식 지위가 있다고 속단해서는 안 됩니다. 출처 간 내용이 상충하거나 형태가 명확하지 않다면, 추측을 기정사실화하지 말고 해당 행을 미결정 상태로 표시하여 판단을 요청하세요.
번역과 인터페이스 레이블은 어떻게 검토해야 할까요?
번역은 기계적인 대소문자 변환이 아니라 의미와 맥락을 결정하는 작업으로 접근해야 합니다. 레이블은 UI 인터페이스의 제약, 기존에 확립된 현지화 제품 용어, 또는 대상 언어의 문법 구조에 따라 달라질 수 있습니다. 후보 단어를 승인된 현지화 자료 및 실제 독자가 접하게 될 맥락과 비교해 보세요. 권위 있는 공식 현지화 용어가 없다면 번역을 미해결 상태로 표시하고 적절한 용어 결정을 요청해야 하며, 공식적인 표현인 것처럼 임의로 지어내서는 안 됩니다.
용어 결정이 내려진 후에는 레이블이 실제 위치한 자리에서 교정을 진행하세요. 대소문자 표기가 대상 언어의 규칙과 해당 제품 또는 사내 스타일에 맞는지 확인합니다. 향후 편집 시 임시 번역을 승인된 번역으로 오인하지 않도록 용어 기록에 원래 레이블을 출처, 상태와 함께 남겨두세요. 레이블이 사용 설명서 등 본문에서 함께 언급되는 경우, 본문의 명칭이 화면의 실제 문구와 일치하는지도 확인해야 합니다.
코드와 API 식별자는 어떻게 보호하나요?
대소문자를 변경하기 전에 리터럴 문자열을 일반 편집 텍스트와 분리하세요. 관련 API 레퍼런스, 스키마, 코드, 또는 인터페이스와 식별자를 글자 단위로 대조해야 합니다. 원본에 정의된 언더스코어, 대소문자, 공백, 구두점은 그대로 유지하세요. 스타일 통일 작업은 리터럴 값이 아니라 이를 둘러싼 주변 설명문에서 이루어져야 합니다. Google의 스타일 가이드에서도 공식 명칭이나 이를 사용하는 코드를 언급할 때는 전체 대문자 또는 카멜 표기법(camel-case) 형태를 명시적으로 허용하고 있습니다. [Google 대소문자 표기 지침](https://developers.google.com/style/capitalization)
실무적인 검토 방법은 용어 표에 보호해야 할 식별자를 표시한 뒤 문서 전체에서 등장하는 모든 항목을 해당 기준과 대조하는 것입니다. 본문 문장에서 코드 형태의 용어를 일반명사처럼 사용하는 경우, 독자 친화적인 단어로 풀어 설명하면서 리터럴 식별자는 코드 서식을 적용해 그대로 유지할지 여부를 결정하세요. 공식 정의 자체가 불명확하다면 그 불확실성을 기록해 두어야 합니다. 스타일 가이드가 API의 동작이나 표준 필드명을 임의로 규정할 수는 없기 때문입니다.
신뢰할 수 있는 교정 절차는 무엇일까요?
이 절차는 자동 번역이나 만능 대소문자 규칙이 아닌 교정 보조 도구입니다. 이 방식의 가치는 어떤 형태가 선택되었는지, 그 출처가 어디인지, 어디에 적용되는지, 여전히 결정이 필요한 사항은 무엇인지 등 각 편집 결정을 투명하게 검토할 수 있게 해준다는 점에 있습니다. 짧은 문서라면 간단한 표로도 충분하며, 용어 분량이 방대하다면 팀에서 기존에 사용 중인 용어집 워크플로 내에서 동일한 필드를 유지하여 관리하세요.