기존 업무용 앱에 번역 연동 범위를 정하는 방법
업무용 앱에 번역 기능을 계획하세요. 견적을 요청하기 전에 콘텐츠, 언어, 검토, 데이터 규칙, 장애 처리, 인수 테스트를 정의하세요.
팀이 다른 언어로 처리해야 하는 완결된 업무 하나에서 시작하세요. 그런 다음 번역이 그 업무에 어떻게 들어가는지 정의하세요. 이렇게 하면 단순히 번역 버튼을 추가해 달라는 요청보다 소프트웨어 공급업체가 견적을 낼 근거가 더 명확해집니다.
범위에는 텍스트, 사람, 데이터, 결과가 포함되어야 합니다. 번역이 실패했을 때 어떻게 되는지도 설명해야 합니다. 기술적인 방식을 고르기 전에 아래 단계에 따라 범위를 준비하세요.
첫 릴리스에서 다룰 업무 흐름 하나를 고르세요
원문이 어디에서 오고 승인된 번역이 어디로 가야 하는지 적으세요. 예를 들어 고객 지원 직원은 들어온 메시지를 읽고 고객의 언어로 답장을 준비해야 할 수 있습니다. 이는 설명을 위한 예시 요건이며, Vavus 설치 사례를 보고하는 것이 아닙니다.
각 단계를 나열하세요: 메시지 열기, 번역 요청, 결과 옆에 원문을 두고 읽기, 답장 편집, 발송 승인. 번역이 자동으로 시작되는지, 직원이 선택한 뒤에만 시작되는지 정하세요.
첫 릴리스는 작게 유지하세요. 애플리케이션의 모든 텍스트 필드보다 화면 하나와 명확한 업무 하나가 테스트하기 더 쉽습니다.
콘텐츠와 언어 요구 사항을 파악하세요
번역이 필요한 필드 목록을 만드세요. 짧은 레이블, 자유 텍스트, 문서, 음성을 구분하세요. 각각 다른 처리와 테스트가 필요할 수 있습니다. 주문 번호나 제품 코드처럼 바뀌면 안 되는 필드도 목록에 적으세요.
지역별 변형을 포함해 원본 언어와 대상 언어를 명시하세요. 일반적인 텍스트 길이와 예상 일일 처리량을 기록하세요. 제안된 서비스가 어떤 언어 조합과 입력 형식을 지원하는지 물어보세요.
짧은 텍스트에서는 맥락이 중요할 수 있습니다. 예를 들어 DeepL의 텍스트 API는 맥락 자체는 번역하지 않으면서 번역에 영향을 줄 수 있는 context 매개변수를 지원합니다. 문서에는 한 요청에 담긴 개별 텍스트 항목끼리는 맥락을 공유하지 않는다고도 나와 있습니다. [1] 범위에는 유용한 맥락을 어디에서 가져올지 적어야 합니다.
용어와 사람의 검토 방식을 정하세요
회사에서 자주 쓰는 용어를 모으세요. 선호하는 번역어, 제품명, 바꾸지 말아야 할 단어를 포함하세요. 이 목록을 관리할 담당자 한 명을 지정하세요.
일부 번역 서비스는 용어집을 지원합니다. Google Cloud Translation은 용어집을 분야별 전문 용어를 일관되게 번역하기 위한 사용자 지정 사전이라고 설명합니다. [2] 사용할 언어 쌍과 선택한 서비스에서 이 기능을 확인하세요. 용어집이 있다고 해서 메시지 전체가 정확하다는 증거는 아닙니다.
어떤 결과물에 자격을 갖춘 언어 검토자가 필요한지 정하세요. 검토자가 원문을 볼 수 있게 하세요. 고객에게 보이는 텍스트를 발송하거나 게시하기 전에 명확한 승인 단계를 두세요.
데이터와 접근 규칙을 정하세요
업무 흐름에서 어떤 정보를 다루는지 설명하세요. 초기 테스트에서는 인위적으로 만든 예시를 사용하세요. 버튼이 작동하는지 확인하려는 목적만으로 실제 고객 기록을 시험 환경에 복사하지 마세요.
텍스트가 어디에서 처리되는지, 애플리케이션이 무엇을 저장하는지, 누가 읽을 수 있는지, 언제 삭제되는지 물어보세요. 이 논의에 로그와 백업도 포함하세요. 제공업체의 현행 약관과 선택한 요금제에서 사용할 수 있는 관리 기능을 확인하세요.
맞춤형 인터페이스를 만든다고 해서 그것만으로 외부 번역 서비스가 비공개가 되거나 오프라인이 되지는 않습니다. 프로젝트에 로컬 처리가 필요하다면 처음부터 그 요건을 밝히고, 전체 데이터 흐름이 요건을 충족하는지 테스트하세요.
지연과 오류에 대비하세요
예상 응답 시간과 서비스를 사용할 수 없을 때 직원이 취해야 할 조치를 적으세요. 애플리케이션은 대기 중, 검토 준비 완료, 실패처럼 명확한 상태를 표시해야 합니다. 원문은 보존하세요.
개발자에게 일시적인 장애와 수정이 필요한 오류를 구분해 달라고 요청하세요. 예를 들어 DeepL 문서는 요청 한도 초과 오류에는 시간을 두고 재시도하도록 안내하지만, 할당량을 모두 쓴 경우에는 다른 대응이 필요합니다. [3] 요청을 반복하더라도 같은 답장을 두 번 보내는 것처럼 업무 작업이 중복되어서는 안 됩니다.
사용량 알림과 지원 담당자를 합의하세요. 프로젝트 비용을 비교할 때는 서비스 요금, 유지보수, 향후 변경도 포함하세요.
개발 전에 인수 테스트를 작성하세요
필요한 언어 쌍마다 대표적인 예시를 고르세요. 긴 메시지, 특수 문자, 비어 있는 필드, 승인된 용어 목록의 단어를 포함하세요. 원본 기록부터 저장되거나 발송된 결과까지 업무 전체를 테스트하세요.
사람이 확인할 수 있는 합격 기준을 정하세요. 제품 코드는 바뀌지 않는다, 승인되지 않은 번역은 보낼 수 없다, 실패한 요청은 화면에 표시된다, 검토자는 원문으로 돌아갈 수 있다. 자격을 갖춘 검토자에게 의미와 어조를 평가받으세요. 결함을 기록하고, 변경 후에는 같은 테스트를 반복하세요.
명확한 견적 요청서를 준비하세요
업무 흐름, 샘플 필드, 언어 쌍, 예상 처리량, 데이터 규칙, 인수 테스트를 보내세요. 각 항목에 출시 필수인지, 이후 릴리스로 미뤄도 되는지 표시하세요. 전제 조건과 제외 사항은 서면으로 받으세요.
Vavus는 맞춤형 프로젝트의 범위를 서면으로 정리해 드립니다. [4] 견적 페이지에서 기존 애플리케이션과 개선하려는 업무를 설명해 주세요. 제안된 연동, 배포, 테스트는 프로젝트 범위에서 확정해야 합니다.