DeepL 용어집(Glossary): 무엇을 수정하고, 무엇을 수정하지 않으며, 어떻게 테스트할 것인가?

간단한 답변

예: DeepL은 선택된 소스 및 타겟 언어에 대해 용어집 기능을 제공하며, 이를 번역기, 앱, 통합 기능 및 API 인터페이스 전반에서 사용할 수 있습니다. 하지만 “용어집”이 “모든 출력물에서 이 정확한 문자열을 저 정확한 문자열로 대체한다”는 의미는 아닙니다. DeepL에 따르면 용어집 항목은 단순 검색 및 교체(literal search-and-replace) 방식으로 적용되기보다는 타겟 언어의 문법에 맞춰 조정됩니다. 반면, 한 사용자의 실제 보고서는 용어집이 단일 단어 항목에 대해 예상치 못한 방식으로 작동하는 것을 설명합니다. 따라서 유용한 답변은 조건부입니다. 즉, 도메인 전문 용어를 안내하기 위해 용어집을 사용하고, 팀에서 실제로 사용하는 언어 쌍(language pair), 인터페이스(surface), 콘텐츠 및 릴리스 버전을 테스트해야 합니다. 이 기능을 법률적, 재무적, 의료적 또는 브랜드 안전성이 보장되는 번역의 보증으로 취급해서는 안 됩니다.

이 가이드는 공급업체의 점수에 의존하지 않고 실행할 수 있는 릴리스 테스트를 제공합니다: 작은 전문 용어 고정값(terminology fixture), 위험 가중치 검토 루브릭, 그리고 버전별 결정 기록입니다. 이 문서는 로컬라이제이션 리드, 제품 팀 및 워크플로우를 평가하는 구매자를 위한 것입니다. 특정 서비스가 아래의 테스트를 통과했다는 주장은 아닙니다. 본 기사를 위해 실제 DeepL 번역 실행은 수행되지 않았습니다.

검색 뒤에 숨겨진 결정 사항

용어집이 “일관성을 보장한다”고 묻는 구매자는 보통 다른 운영상의 질문, 즉 선호하는 용어가 문맥에 따라 변동되는 것을 발견하지 않고 번역된 페이지, 계약서, 제품 화면 또는 도움말 콘텐츠를 게시할 수 있는지 여부를 알고 싶어 합니다.

이 질문 속에는 적어도 네 가지의 구별되는 결정 사항이 숨겨져 있습니다:

1. 제품이 언어 쌍에 대한 선호 용어를 저장할 수 있는가?
2. 해당 기능이 우리가 사용하는 특정 번역 인터페이스(translation surface) 및 플랜에서 적용되는가?
3. 출력물이 우리의 문장, 파일, 로케일 및 모델 구성에서 선호 용어를 사용하고 있는가?
4. 그 출력이 언어적, 사실적, 시각적 및 법률적 검토를 거친 후 의도된 사용에 적합한가?

첫 번째 질문에 긍정적으로 답했다고 해서 나머지 세 가지 질문까지 해결되는 것은 아닙니다. DeepL의 도움말 페이지는 용어집(glossary)을 용어 및 짧은 구문 선호도(term and short-phrase preferences)로 설명하며, 지원하는 언어와 표면(surfaces) 목록을 제시하고, 항목이 목표 언어의 문법에 적응한다고 언급합니다. 이는 유용한 기능 설명일 뿐, 특정 문서에 대한 품질 보증은 아닙니다. 또한 통합 의존성도 명시합니다: 타사 플러그인이 지원 구현을 해야 할 수 있으며, 제공업체 측에서 시간이 걸릴 수도 있습니다. DeepL 용어집 도움말 페이지

공개 검색 결과의 격차는 실질적입니다. 문서에서는 선호도를 추가하는 방법을 설명하지만, 사용자들은 여전히 용어집이 정확한 출력을 강제할지 묻습니다. Stack Overflow 질문 하나는 사용자가 영어에서 독일어로 된 단일 항목이 문자 그대로 매핑(literal mapping)처럼 작동할 것으로 예상했지만, 대신 문법적으로 변경된 형태를 본 사례를 설명합니다. 이는 측정된 결함률이나 기능이 광범위하게 신뢰할 수 없다는 증거가 아닌, 단일 사용자 보고서입니다. 하지만 이 보고서는 중요한 테스트 지점을 식별합니다: 원하는 표제어(lemma)와 정확히 보호되는 문자열(protected string)을 구별하고, 두 가지가 동등하다고 가정하기보다는 문맥을 테스트해야 한다는 것입니다. 보고된 API 용어집 질문

이 가이드가 확장하는 원본 페이지는 운영 환경에서의 DeepL 현장 보고서입니다. 이 기사는 일반적인 제품 리뷰를 반복하지 않으며, 더 광범위한 현장 보고서만으로는 스스로 해결할 수 없는 구매 결정 하나, 즉 용어집 기반 워크플로우가 명명된 전문 용어 및 출시 요구 사항을 충족하는지 확인하는 방법을 분리하여 다룹니다.

용어집이 합리적으로 할 수 있는 것들

용어집은 완전한 번역 정책(translation policy)이 아니라, 전문 용어 제어(terminology control)입니다. 이는 특정 원문 표현들이 선호되는 목표 언어 등가물(preferred target-language equivalents)을 가지고 있음을 시스템에 알려줄 뿐입니다. 시스템은 여전히 해당 용어들이 문장, 문법, 스타일 및 문맥에 어떻게 적합한지 결정해야 할 수 있습니다.

DeepL은 해당 항목들이 굴절어(inflection)를 사용하는 언어의 문법 규칙에 맞춰 조정되었다고 명확하게 밝힙니다. 그 동작 방식이 검색 및 대체(search-and-replace)가 아니며, 사용자가 나열된 경우에 복수형이나 굴절된 형태를 입력할 필요가 없다고 합니다. 이 진술은 수용 기준을 변경하기 때문에 중요합니다. 만약 귀하의 요구 사항이 “문법적으로 적절한 형태론(morphology)을 사용하여 동일한 개념을 사용”하는 것이라면, 이 기능은 테스트에 유용한 제어 장치일 수 있습니다. 그러나 만약 요구 사항이 “출력 바이트가 대소문자까지 정확히 이 문자열을 포함해야 한다”라면, 문법 인식 용어집만으로는 충분한 불변성(invariant)이 아닙니다.

용어집은 또한 원문 텍스트가 명확한지, 특정 용어가 법적으로 정확한지, 목표 구문이 국가에 적절한지, 또는 문서가 레이아웃과 숫자적 의미를 보존했는지 여부를 결정할 수 없습니다. 아래 프로토콜은 용어 검사(terminology check)가 품질의 좁은 단면만을 다루기 때문에, 언어학적 검토(linguistic review), 시각적 검사(visual inspection), 기능적 확인(functional checks), 그리고 시장별 제어(market-specific controls)를 의도적으로 분리합니다.

네 가지 레벨의 제어 모델 (The four-level control model)

포괄적인 보증을 한 기능에 맡기기보다는 네 개의 별도 레이어(layer)를 사용하십시오.

이러한 분리는 관료적인 장식이 아닙니다. 이는 실패를 진단 가능하게 만듭니다. 용어집 항목이 없으면 설정을 수정하십시오. 출력에 허용할 수 없는 형태가 포함되어 있으면 규칙을 강화하거나 재분류하십시오. 용어가 정확하지만 문장이 법적 의미를 변경한다면, 언어학적 또는 주제별 검토(subject-matter review)로 에스컬레이션하십시오. 지난달에는 테스트를 통과했지만 플러그인이 변경되었다면, 새로운 구성에 대해 고정 테스트(fixture)를 다시 실행하십시오.

용어 분류부터 시작하기 (Start by classifying the term)

중요하게 들리는 모든 단어를 하나의 구별되지 않은 목록에 넣지 마십시오. 각 항목에 대해 위험도에 맞는 정책을 선택해야 합니다.

선호 용어 (Preferred terminology)

특정 대상 언어 표현이 선호되지만 일반 문법에 의해 표면 형태가 변경될 수 있는 도메인 용어에 사용합니다. 개념(concept), 선호 어간(preferred lemma), 금지된 대안(forbidden alternatives), 사용 참고 사항(usage note), 언어 변형(language variant) 및 예문(example sentence)을 기록해야 합니다. 용어집이 해당 용어를 안내하는 데 도움을 줄 수 있지만, 검토자가 형태론적 변화가 올바른지 여부를 결정합니다.

보호 문자열 (Protected strings)

정확한 문자가 유지되어야 하는 이름, 제품 라벨, 법적 식별자, 코드, 브랜드 철자, 명령어 이름 또는 토큰에 사용합니다. 단순히 “선호 번역”이 아니라 “반드시 정확하게 유지해야 함(must remain exact)”으로 표시하십시오. 별도의 자동화된 정확 문자열 검사를 유지해야 합니다. 위험도가 높은 텍스트의 경우, 모델 지침에만 의존하지 말고, 가능한 경우 제품 파이프라인에서 해당 문자열을 보존하거나 대체한 다음 최종 결과물에서 이를 확인해야 합니다.

예시로는 SKU(재고 관리 단위), 인터페이스와 일치해야 하는 제품 기능 라벨, 등록된 조직 이름, {account_id}와 같은 변수 플레이스홀더, 또는 경고 코드가 있습니다. 보호 문자열은 구두점이나 문법 텍스트 내에 나타날 수 있지만, 문자 시퀀스는 온전하게 유지되어야 합니다. 대문자 사용(capitalization), 공백(spacing), 상표 기호(trademark symbols), 복수 접미사(plural suffixes)가 허용되는지 사전에 결정해야 합니다.

번역 금지 용어 (Do-not-translate terms)

해당 용어는 원본 언어에 그대로 남아 있을 수 있지만, 이는 단순히 번역을 선호하는 것과는 다릅니다. 변경되지 않고 유지되어야 하는지, 대소문자가 달라질 수 있는지, 그리고 현지화된 설명이 동반될 수 있는지를 기록해야 합니다. 최종 출력에서 정확한 원본 문자열을 검증하십시오.

문맥 의존적 대체 용어 (Context-dependent alternatives)

일부 원문 용어는 제품 영역마다 다른 의미를 가집니다. 예를 들어, "Charge"라는 단어는 수수료(fee), 배터리 동작(battery action), 또는 법적 고발(legal accusation)을 의미할 수 있습니다. 단일한 전역 매핑은 해당 용어를 통제하지 않는 것보다 더 심각한 오류를 만들 수 있습니다. 따라서 용어집(glossary)을 도메인별로 분할하거나, 문맥적 주석(contextual note)을 추가하거나, 원문이 모호한 경우 인간의 검토를 요구해야 합니다.

운영 사용 전에 테스트 환경(Fixture) 구축하기

본 가이드의 재사용 가능한 에셋은 경험적 벤치마크가 아닌 작고 합성적인 수용 테스트 환경(acceptance fixture)입니다. 여기에는 네 가지 정책 클래스에 걸쳐 작성된 12개의 수동 테스트 케이스가 포함되어 있습니다: 선호 용어(preferred terms) 3개, 활용 문맥 예시(inflected-context examples) 3개, 보호 문자열(protected strings) 3개, 모호성 또는 형식 지정 사례(ambiguity or formatting cases) 3개입니다. 이 케이스들은 복사하여 각색할 목적으로 만들어졌으며, DeepL이나 다른 번역 서비스에 제출된 적이 없으며, 정확도율(accuracy rate), 성공률(success percentage) 또는 비교 성능은 주장되지 않습니다. 이러한 제외 사항이 중요합니다: 테스트 정의는 유용하지만, 모델의 성능을 측정하는 것은 아닙니다.

중요한 언어 쌍 및 제품 표면(product surface)마다 하나의 환경(fixture)을 만드세요. 원문 문장, 정책 클래스, 예상 불변성(expected invariant), 허용 가능한 변형(acceptable variants), 허용할 수 없는 결과(unacceptable result), 심각도(severity), 검토자 주석(reviewer note)을 포함해야 합니다. 모든 케이스에 대해 하나의 짧은 구문을 사용하지 마십시오. 시스템이 전체 문서, 편집기, API 통합 또는 타사 CAT 도구에서 용어집을 다루는 방식이 다를 수 있으므로, 환경은 배포될 경로와 일치해야 합니다.

이 예시들은 합성적입니다. 실제 조직은 "Atlas," "KYC-7," 예시 금액, 그리고 모든 대상 언어 예상 형태를 승인된 자료로 대체해야 합니다. 환경(fixture)은 번역을 규정하지 않습니다. 특정 프랑스어, 독일어, 이탈리아어 또는 일본어 구문이 올바른지 여부를 테스트하는 것이 아니라 불변성(invariants)을 테스트합니다.

번역 전에 수용 기준 작성하기

모든 픽스처(fixture) 행마다 검토자가 '일관성'이 무엇을 의미하는지 추측할 필요 없이 적용할 수 있는 규칙을 작성해야 합니다. 약한 기준은 “용어는 정확해야 한다”고 말합니다. 유용한 기준은 다음과 같이 말합니다: “승인된 대상 개념이 반드시 나타나야 하며, 문법적 굴절(inflection)은 원어민 검토자가 확인하는 경우에만 허용된다; 법적으로 효력이 발생하는 조항에는 승인되지 않은 동의어가 나타날 수 없다.”

보호되는 문자열(protected strings)의 경우, 정확성을 기계적으로 정의해야 합니다. 플레이스홀더가 바이트 단위로 동일해야 합니까? 제품명 뒤에 복수 접미사가 붙을 수 있습니까? 커리프 아포스트로피와 스트레이트 아포스트로피는 동등합니까? 통화 금액이 숫자 값은 유지하면서 지역별 그룹 구분 기호를 허용할 수 있습니까? 이러한 질문들을 암묵적으로 남겨두면, 두 명의 검토자가 서로 다른 결과를 도출하고 둘 다 용어집을 따랐다고 믿게 될 수 있습니다.

각 기준에는 네 가지 필드를 부여해야 합니다:

1. 예상 불변 요소(Expected invariant): 유지되어야 하는 것.
2. 허용 가능한 변형(Allowed variation): 허용되는 것이 무엇이며 그 이유.
3. 금지된 결과(Forbidden outcome): 실패를 유발하는 것.
4. 처리 방안(Disposition): 누가 편차를 승인할 수 있으며 어떤 증거가 필요한지.

예를 들어, 상표권은 정확한 대문자 사용을 요구할 수 있는 반면, 일반적인 기술 용어는 대소문자나 성별 변화를 허용할 수 있습니다. 금융 용어는 굴절이 허용될 수 있지만 근본적인 개념의 변경은 안 됩니다. 면책 조항(disclaimer)은 용어 검토와 법률 검토가 모두 필요할 수 있습니다. 오류의 결과가 클수록 규칙을 더 엄격하게 설정해야 합니다.

올바른 경계에서 동일한 테스트 실행하기

프로덕션 환경이 문서 플러그인을 사용하는 상황에서 브라우저로 용어집을 테스트하는 것은 프로덕션 경로가 작동한다는 것을 증명하지 못합니다. DeepL의 지원 문서는 여러 플랫폼을 나열하고 있지만, 타사 플러그인은 DeepL에 의해 개발되지 않았으며 지원 구현에 시간이 걸릴 수 있다고 경고합니다. 따라서 전체 경로를 기록해야 합니다: 서비스 표면(service surface), 계획(plan), 소스 및 대상 언어 코드, 노출된 경우 모델 또는 생성 설정, 파일 유형, 용어집 식별자 또는 선택된 용어집 이름, 통합 버전, 그리고 날짜.

그러면 출시될 것과 동일한 경계(boundary)를 사용하여 테스트 환경(fixture)을 재실행합니다. API의 경우, 자격 증명(credentials)을 제거한 요청 매개변수(request parameters)를 캡처해야 합니다. 데스크톱 또는 웹 번역기의 경우, 정확한 용어집 선택 내용과 원본 텍스트를 저장하세요. CAT 도구의 경우, 플러그인 및 커넥터 버전을 기록합니다. 문서 번역의 경우, 단순히 복사된 단락뿐만 아니라 반환된 파일 전체를 검사해야 합니다. 레이아웃(Layout), 헤더(headers), 하이퍼링크(hyperlinks), 각주(footnotes), 숫자 형식 지정(numeric formatting) 및 보호 토큰(protected tokens)은 추출된 텍스트 외부에서 실패할 수 있습니다.

제품 업데이트가 무해하다고 가정해서는 안 됩니다. DeepL 문서는 기능 범위(feature scope)와 통합 소유권(integration ownership)을 설명할 뿐이며, 모든 미래 모델, 플랜 또는 인터페이스에서 출력이 비트 단위로 안정적(bit-for-bit stable)일 것이라고 약속하지 않습니다. 서비스, 커넥터, 용어집, 언어 쌍 또는 플랜 변경은 테스트를 유발하는 구성 변경(test-triggering configuration change)으로 간주해야 합니다.

하드 불변량(hard invariants)을 위한 실용적인 오프라인 검사기