번역가와 AI가 실제로 활용할 수 있는 번역 용어집 구축 방법
맥락, 승인된 용어, 담당자, 검토 상태를 포함한 번역 용어집을 만드세요. CSV 템플릿을 내려받아 다섯 가지 잘못된 항목 수정 방법을 살펴보세요.

번역 용어집을 만들려면 통제된 표현이 필요한 개념을 선정하고, 각 개념이 문서에서 무엇을 의미하는지 정의하고, 각 언어와 맥락에 맞는 대상 용어를 승인하고, 이러한 결정을 유지 관리할 담당자를 지정하세요. 그런 다음 번역가나 번역 도구에 넘기기 전에 실제 문단에서 해당 항목을 테스트하세요.
가장 유용한 구분은 결정 사항을 기록하는 마스터 용어집과 도구가 사용할 수 있는 더 작은 내보내기 파일 사이의 차이입니다. 2열 가져오기 파일이 필요할 수는 있지만, 그 두 열을 신뢰할 수 있게 만든 맥락, 근거, 승인 이력을 대체할 수는 없습니다.
빈 용어집 템플릿과 작성 예시 용어집으로 시작하세요. 둘 다 UTF-8 CSV 파일입니다. 예시는 가상의 제품과 설명을 위한 영어-프랑스어 결정을 사용하며, 인증된 용어 목록이나 고객 프로젝트, 또는 BookTranslator용으로 바로 사용할 수 있는 가져오기 프리셋이 아닙니다.
용어집은 사전보다 작게 유지하세요
일관성 없는 선택이나 모호한 선택이 의미를 바꾸거나, 탐색을 혼란스럽게 하거나, 중요한 구분을 약화시키거나, 피할 수 있는 검토 작업을 유발할 때 해당 용어를 포함하세요. 소프트웨어가 추출했다는 이유만으로 모든 명사를 수집하지 마세요.
유용한 선별 과정에서 물어볼 질문:
- 이 개념이 섹션, 파일, 기여자 전반에 걸쳐 반복되는가?
- 원어 단어에 관련된 의미가 두 가지 이상 있는가?
- 조직, 저자, 주제 영역에서 특정 대상 형태를 요구하는가?
- 다른 선택을 하면 경고, 지침, 인터페이스, 논증을 따라가기 더 어려워지는가?
- 이 용어가 새롭거나, 논란이 있거나, 이 프로젝트에서 수정을 초래한 것으로 알려져 있는가?
드물지만 중요한 용어는 빈번한 일반 단어보다 먼저 항목으로 등록할 가치가 있습니다. 현실적인 모호성이 없는 표준 용어는 항목이 전혀 필요하지 않을 수 있습니다.
COTSES의 번역을 위한 용어 관리 입문 가이드는 조직과 관련된 용어 및 명시적인 검증 책임을 권장합니다. 또한 항목 수만으로는 품질을 입증할 수 없다고 경고합니다. 이러한 원칙은 소프트웨어 예시의 연식보다 여기서 더 중요합니다.
후보 추출은 수신함에 불과합니다. 추출된 구문은 그 의미, 적용 시점, 대상 표현을 누가 승인했는지 알 때 유용한 용어가 됩니다.
하나의 의미를 중심으로 하나의 레코드를 만드세요
원문 문자열에 레코드의 단독 소유권을 부여하지 마세요. 영어 단어 “charge”는 전기적 속성이나 청구 금액을 나타낼 수 있습니다. 모든 발생을 하나의 프랑스어 단어에 매핑하는 한 행은 일관성이 아니라 오류를 인코딩하는 것입니다.
각 개념에 안정적인 식별자를 부여한 다음 언어별 결정을 추가하세요. 간단한 스프레드시트에서는 개념 및 원문/대상 로케일 쌍당 한 행을 사용하세요. 두 행이 동일한 원문 철자를 공유하더라도 같은 개념을 나타내지 않을 수 있습니다.
템플릿에는 다음 필드가 포함됩니다:
| 필드 그룹 | 필드 | 방지하는 것 |
|---|---|---|
| 식별 | 항목 ID, 개념 ID, 원어 용어, 원어 로케일, 대상 로케일 | 서로 다른 의미나 언어 변이를 혼동함 |
| 의미 | 정의, 도메인, 품사, 원문 맥락, 맥락 참조 | 잘못된 용도에 그럴듯한 사전적 등가어를 선택함 |
| 대상 결정 | 승인된 대상어, 대상 맥락, 번역 금지 플래그, 거부된 변이형, 사용 규칙 | 대안이나 문법적 변화를 상호 교환 가능한 것으로 취급함 |
| 책임 소재 | 상태, 담당자, 결정 출처, 최종 검토일, 버전, 변경 사항 | 초안이나 오래된 선호가 조용히 정책이 됨 |
맥락 참조를 통해 검토자는 해당 구절을 다시 찾을 수 있어야 합니다. 파일 버전과 섹션, 권위 있는 용어 기록, 또는 다른 지속적인 출처 등이 필요합니다. “인터넷에서”는 충분하지 않습니다. 원저자가 정의한 개념의 경우, 원고 자체의 정의가 관련 증거가 될 수 있습니다.
정의와 원문 맥락을 분리하세요. 정의는 개념이 무엇인지 말하고, 맥락은 그것이 어떻게 사용되는지 보여줍니다. “Select the workspace”와 같은 문장은 사용법을 보여주지만, 워크스페이스가 무엇을 포함하는지 또는 프로젝트와 어떻게 다른지 설명하지는 않습니다.
다섯 가지 흔한 용어집 항목 수정하기
다음 수정 사항은 다운로드 가능한 가상 예시에 속합니다. 이는 편집 결정을 보여주는 것이지, 보편적인 프랑스어 용어 규칙이 아닙니다. 샘플 구절에서 주변 텍스트를 제공합니다.
1. 하나의 강제된 대상어를 가진 다의어
취약한 항목: charge → charge
수정: 별도의 개념을 만드세요:
- 전기적 속성: 원어
charge; 대상어charge électrique; 도메인 “입문 전자공학”; 맥락 “The capacitor stores electric charge.” - 청구 금액: 원어
charge; 대상어frais; 도메인 “청구”; 맥락 “The delivery charge is shown before payment.”
이것은 두 매핑 중 하나가 “charge”의 모든 출현을 대체해야 한다는 의미가 아닙니다. 항목의 도메인과 맥락은 결정의 일부입니다. 선택한 도구가 이들을 구분할 수 없다면, 전역 치환 대신 별도의 프로젝트 내보내기, 더 길고 명확한 구문, 또는 인간 검토를 사용하세요.
2. 품사가 없는 용어
취약한 항목: seal → sceller
수정: 동사와 구성 요소를 구분하세요:
- “봉투를 봉하다”: 동사이며, 이 프로젝트에서 예시 대상어는
sceller입니다. - “고무 실을 교체하다”: 부품을 가리키는 명사이며, 대상어는
joint입니다.
이제 스프레드시트는 고무 부품이 동작이라고 암시하는 대신 두 가지 개념을 설명합니다. 실제 기술 문서라면 도메인 검토자가 해당 부품의 의미와 선호 용어를 검증하도록 하십시오.
3. 프로젝트 선호 없이 둘 다 허용 가능한 번역
취약한 항목: workspace → espace de travail / zone de travail
수정: 가상 애플리케이션의 명명된 컨테이너에 대해 espace de travail을 승인합니다. zone de travail은 이 인터페이스 개념에 대해 거부된 변형으로 기록하며, 일반적으로 나쁜 프랑스어라는 뜻이 아닙니다. 정상적인 문법 변화형은 허용된다는 사용 주석을 추가하십시오.
거부된 변형에는 이유와 적용 범위가 필요합니다. 그렇지 않으면 검토자가 다른 문맥에서 완벽하게 유효한 표현을 “교정”할 수 있습니다.
4. 암시로만 보호된 제품명
취약한 항목: LeafDeck → LeafDeck
수정: do_not_translate=true로 설정하고, 가상 제품명임을 명시하며, 대소문자를 유지하고, 데모 프로젝트의 명명 결정을 인용합니다. 이 규칙이 일반 설명에 나오는 무관한 단어에는 적용되지 않는다고 밝히십시오.
원문과 대상 텍스트가 일치한다는 사실만으로는 유지가 의도된 것인지 아니면 단순히 미완성 작업인지 설명되지 않습니다. 더 넓은 제외 목록은 번역하지 않을 항목 결정 가이드를 참조하십시오.
5. 승인된 것처럼 제시된 초안 결정
취약한 항목: sync → synchroniser / mettre à jour, 소유자나 상태 없음.
수정: 먼저 동작을 정의합니다. 기기 라이브러리를 동기화하는 가상 명령의 경우 동사로 synchroniser를 승인하고 대안은 이 특정 명령에 부적합하다고 기록합니다. 소유자와 날짜가 있는 결정 출처를 지정하십시오.
별도의 제안 명사 레이블은 검토자가 해결할 때까지 draft로 유지하십시오. 작성된 CSV에는 의도적으로 해당 초안 행이 포함되어 있습니다. 깔끔해 보이는 스프레드시트가 모든 행이 승인되었다는 증거는 아닙니다.
장식용 점수가 아닌 항목 품질 게이트를 사용하십시오
항목을 승인하기 전에 여섯 가지 예/아니요 질문을 하십시오:
- 의미: 다른 사람이 이 개념을 인접 개념과 구별할 수 있습니까?
- 근거: 뒷받침하는 출처나 작성자 결정을 찾을 수 있습니까?
- 언어: 대상 형태가 지정된 로케일, 문법, 도메인에 적합합니까?
- 범위: 규칙이 어디에 적용되고 어디에 적용되지 않는지 알고 있습니까?
- 책임: 변경 사항을 해결할 책임자가 있습니까?
- 사용: 대표 문장에서 항목을 확인했습니까?
해결되지 않은 답변이 있으면 항목은 초안으로 남습니다. 이는 편집 승인 기준이지, 검증된 번역 품질의 수치 측정이 아닙니다.
전문성에 따라 업무를 분담하세요. 저자나 주제 전문가는 개념을 확정하고, 대상 언어 검토자는 용례를 확인하며, 용어 담당자는 결정을 기록하고 승인된 버전을 배포합니다. 소규모 프로젝트에서는 한 사람이 여러 역할을 맡을 수 있지만, 질문에는 여전히 답이 필요합니다.
검토자가 항목에 이의를 제기하면 경합하는 선택지와 그 충돌을 드러내는 구절을 기록하세요. 개인 메시지가 문서화되지 않은 예외가 되도록 두지 말고 번역가 질의 워크플로를 따르세요.
승인 후에만 수신 도구용으로 내보내기
마스터 용어집과 엔진 사전은 목적이 다릅니다. 마스터는 사람에게 결정을 설명합니다. 가져오기 파일은 특정 도구의 스키마와 일치 동작을 따라야 합니다.
용어집 가져오기를 지원하는 도구의 경우:
- 필요한 원문/대상 언어 쌍과 프로젝트 도메인을 선택하세요.
draft및deprecated항목을 제외하세요.- 수신 도구가 구분할 수 없는 중복 원문 문자열을 해결하세요.
- 지원되는 필드만 도구의 현재 가져오기 형식에 매핑하세요.
- 대소문자, 굴절, 다중 단어 용어, 보호 텍스트를 어떻게 처리하는지 확인하세요.
- 대표적인 소규모 입력을 테스트하고 반환된 번역을 검사하세요.
예를 들어, Google Cloud Translation의 문서화된 단방향 CSV 형식은 헤더 없이 원문/대상 쌍을 사용하는 반면, 동등 용어 집합 CSV는 언어 헤더를 사용합니다. 용어집 일치는 기본적으로 대소문자를 구분하며, 일부 불용어 항목은 무시됩니다. 이는 Google Cloud 규칙이지 일반 CSV 규칙이나 BookTranslator 기능이 아닙니다. 해당 서비스용 내보내기를 준비하기 전에 현재 Google Cloud 용어집 문서를 확인하세요.
이 글의 풍부하게 주석이 달린 CSV를 아무 가져오기 대화 상자에 업로드하지 마세요. 그것은 작업용 마스터입니다. 반대로, 도구가 두 열만 허용한다고 해서 그 정의와 승인 이력을 버리지 마세요.
지원되는 지시 필드가 있는 AI 시스템을 사용할 때는 관련성이 있고 승인된 하위 집합과 의미를 구분하는 데 필요한 맥락을 제공하세요. 지시는 용어를 요청할 수 있지만, 출력이 그것을 따랐다는 것을 입증하지는 않습니다. 결과를 검사하세요. 시스템이 지원되는 용어집 입력을 제공하지 않으면, 가져오는 방법을 만들어내지 말고 마스터를 검토자 참고 자료로 유지하세요.
다국어 현장 팀이 있는 조직의 경우, 번역 후에도 용어 일관성이 중요합니다. 교육 자료, 정책, 운영 커뮤니케이션은 승인된 표현을 유지하면서 직원들이 선호하는 언어로 전달되어야 할 수 있습니다. iTacit은 다국어 커뮤니케이션이 언어, 국가, 문화 전반에 걸쳐 직장 정보를 어떻게 지원하는지 설명합니다.
현지 결정을 지우지 않고 언어 추가하기
다른 대상 로케일을 추가할 때 개념 ID를 재사용하되, 해당 로케일에 자체 대상, 상태, 담당자, 근거를 부여하세요. 프랑스어에서의 승인이 독일어 대응어를 승인하지는 않습니다. 빈 대상은 “해결되지 않음”을 의미하며, “원문을 자동으로 사용”을 의미하지 않습니다.
같은 원칙이 한 언어 내에서도 적용됩니다. 로케일별 결정이 실질적으로 다를 경우 분리하세요. 아무것도 바꾸지 않는 지역 레이블을 추가하려고 중복 행을 만들지 마세요.
이러한 상태를 단순하게 유지하세요:
- 초안: 후보 또는 분쟁 중인 결정으로, 승인된 내보내기에 포함되지 않습니다.
- 승인됨: 명시된 범위와 버전에 대해 수락되었습니다.
- 사용 중단: 이력과 감지를 위해 유지되지만, 새 작업에는 권장되지 않습니다.
실질적인 변경의 경우 이전 형태, 새 형태, 이유, 적용 버전, 담당자, 영향을 받는 원문 위치를 기록하세요. 관련 내보내기를 다시 만들고 번역가에게 재검토가 필요한 구절을 알리세요. 프로젝트 중간에 용어를 조용히 교체하고 이미 번역된 장이 스스로 업데이트되기를 기대하지 마세요.
제품, 원문 원고, 표준 또는 승인된 용례가 변경되면 항목을 검토하세요. 달력 알림도 도움이 되지만, 변경된 정의가 더 강력한 계기입니다.
확장하기 전에 문단에서 용어집을 검증하세요
용어집은 내부적으로 깔끔해도 문장에서 실패할 수 있습니다. 의도적으로 다음을 포함하는 소규모 문단 세트를 사용하세요:
- 두 가지 의미로 쓰인 모호한 원어 단어;
- 제목과 본문 모두에 나타나는 용어;
- 단수, 복수 또는 기타 문법적 변형;
- 일반 언어 옆에 있는 보호된 이름; 그리고
- 표, 캡션, 지시문 또는 기타 중요한 문서 구조에 있는 용어.
다운로드 가능한 예시는 “delivery charge”와 “electric charge”를 짝지어 보여주며, “seal”을 명사와 동사로 모두 포함합니다. 이러한 사례는 범위를 지정하지 않은 치환이 왜 잘못된 수용 테스트인지 드러냅니다.
각 문단에 대해 원문, 용어집 버전, 대상 출력, 검토자 결정, 필요한 경우 수정 사항을 기록하세요. 실제로 번역 서비스를 테스트했다면 서비스/모델, 날짜, 설정, 원시 출력을 추가하세요. 이 글의 예시는 그러한 서비스 테스트가 실행되었다고 주장하지 않습니다.
전체 문서가 번역된 후에는 용어 일관성 검토로 넘어가세요. 용어집 구축은 정책을 수립하고, 출력 검토는 전달된 텍스트가 부자연스러워지지 않으면서 정책을 따르는지 판단합니다.
단순한 단어 목록이 아니라 결정 기록을 넘겨주세요
최종 인계에는 원문 버전, 승인된 마스터 용어집, 해당되는 경우 수신 도구 내보내기, 미해결 질의 로그, 대표 예시가 포함되어야 합니다. 번역을 수행하는 사람은 어느 파일이 권위 있는지, 충돌에 대해 누구에게 물어야 하는지 알아야 합니다.
지원되는 전체 책이나 긴 문서의 경우, BookTranslator의 파일 번역 워크플로가 이후 검토를 위한 초안을 제공할 수 있습니다. 승인된 용어집을 해당 초안과 함께 보관하세요. 여기의 워크시트는 외부 편집 참고 자료이며, BookTranslator가 사용자 관리 CSV 용어집을 가져오거나 모든 항목을 강제한다는 주장이 아닙니다.
몇 가지 중요한 개념부터 시작하여 결정을 검토 가능하게 만들고, 진정한 모호성이나 검토 결과에서 확장하세요. 목표는 다음 문서에서 미해결 결정을 줄이는 것이지, 가장 큰 용어집을 만드는 것이 아닙니다.





