사람 검토

대부분의 콘텐츠는 엔진이 결과를 반환하는 즉시 배포할 수 있습니다. 하지만 예외도 있습니다. 규제 고지, 의료 안내문, 브랜드를 대표하는 헤드라인처럼 그런 콘텐츠는 고객이 불만을 제기한 뒤가 아니라, 실제로 공개되기 전에 사람이 번역을 읽고 승인해 주길 바라게 됩니다.

자동화된 흐름에 사람을 넣는 일반적인 방법은 대개 번거롭습니다. 누군가 읽는 동안 요청을 계속 열어 두거나, 자체 검토 대기열을 만들거나, 번역 벤더의 API를 직접 연동해야 하죠. 이 단계는 그 과정을 작업 내부에서 처리합니다. humanEdit이 활성화되면 비동기 작업은 엔진을 실행한 뒤 사람 단계에서 일시 중지됩니다. 이 사람은 사내 팀원일 수도, 외부 전문 인력일 수도 있습니다. 그리고 그들의 편집본으로 다시 이어서 진행되며, 그 결과는 뒤따르는 모든 단계로 전달됩니다.

이 단계는 로컬라이제이션 파이프라인의 세 번째 단계이며, 다른 모든 단계와 마찬가지로 Async Localization API를 통해 생성된 작업에만 적용됩니다. 파이프라인이 처음이라면 개요부터 시작하세요.

이 페이지에서 다루는 내용

• 일시 중지 방식
• 내부 검토
• 권한
• 외부 검토
• 타임아웃
• 단계 활성화

일시 중지 방식#

핵심 번역 단계가 끝나면 작업은 AI 번역을 사람에게 넘겨 검토를 받습니다. 검토자는 이를 읽고 그대로 승인하거나 수정본을 제출합니다. 그 후에야 작업이 계속 진행됩니다. 사람의 결과물은 승인본이든 수정본이든 이후 모든 단계의 입력이 되며, 최종적으로 작업의 outputData이 됩니다.

작업을 몇 분, 몇 시간, 심지어 하루 동안 멈춰 두는 데 가장 먼저 떠오르는 반론은 비용입니다. 아무 일도 일어나지 않는 동안 열린 요청이 자원을 계속 잡아먹기 때문이죠. 하지만 이 단계는 그런 방식으로 작동하지 않습니다.

검토 모드는 엔진별로 두 가지를 선택할 수 있습니다. 차이는 누가 읽느냐뿐이며, 일시 중지, 재개, 그리고 결과 전달 방식은 동일합니다.

내부 검토#

사내 팀이 Lingo.dev 대시보드에서 직접 번역을 검토합니다. 대기 중인 검토 항목은 조직의 Human Reviewer 페이지(/orgs/<org-id>/human-reviewer)에 들어오며, 새 항목이 도착하면 검토자에게 알림이 전송됩니다. 검토자는 항목을 맡은 뒤 번역을 그대로 승인하거나 수정본을 제출합니다. 작업은 그 결과물로 즉시 다시 이어집니다.

이미 누군가 작업 중인 항목은 다른 검토자가 가져갈 수 없습니다. 할당은 배타적입니다. 한 번에 한 명의 검토자만 항목을 맡을 수 있으므로, 두 사람이 같은 번역을 동시에 수정하고 서로의 작업을 조용히 덮어쓰는 일은 없습니다. 문자열은 해당 검토자가 해제하거나 제출할 때까지 잠깁니다.

내부 검토는 새 엔진의 기본 모드입니다. 팀 내부에 해당 언어 전문성이 있고, 제3자를 거치지 않은 채 최종 문구를 완전히 통제하고 싶을 때 적합합니다.

권한#

내부 검토는 조직의 모든 사람에게 열려 있지 않습니다. Human Reviewer 페이지는 권한으로 제한되므로, 검토 중인 번역은 접근 권한을 부여받은 사람에게만 보입니다. 조직 관리자는 역할(Settings → Roles)을 통해 접근 권한을 할당합니다.

이 두 권한은 의도적으로 분리되어 있습니다. 검토자에게는 번역 검토만 있으면 충분합니다. 이 단일 권한만으로 가져오기, 수정, 승인, 제출까지 전체 작업이 가능합니다. 검토 관리는 운영을 총괄하는 사람을 위한 권한으로, 조직 전체의 기록과 통계 보기를 추가하지만 이것만으로는 대기열 접근 권한이 생기지 않습니다. 검토도 하고 보고도 하는 리드에게는 둘 다 부여하고, 대기열 처리만 하는 사람에게는 첫 번째만 부여하세요.

외부 검토#

특정 로캘에 대해 사내 검토자가 없는 경우, 번역은 외부 제공업체를 통해 자격을 갖춘 전문 번역가에게 전달됩니다. 작업은 같은 방식으로 일시 중지되며, 제공업체가 수정된 번역을 반환하면 다시 이어집니다. 코드에서 바뀌는 것은 없습니다. 달라지는 것은 누가 문자열을 읽느냐이지, 작업의 동작 방식이 아닙니다.

외부 검토에는 두 가지 등급이 있으며, 구분 기준은 콘텐츠가 요구하는 정확도 수준입니다.

이 부분은 분명하게 짚고 넘어갈 필요가 있습니다. 외부 검토는 실제 사람 번역가가 반대편에 있는 방식이므로, 그에 따른 처리 시간과 비용이 듭니다. 더 빠른 모델이 아닙니다. 사람의 판단이 핵심인 경우, 즉 규제 문구나 리스크가 큰 카피에 사용하고, 그런 수준의 검토가 필요하지 않은 대부분의 콘텐츠에는 AI 전용 경로를 활용하세요.

타임아웃#

사람이 개입하는 단계에는 AI 단계에는 없는 위험이 있습니다. 사람이 끝내 응답하지 않을 수 있다는 점입니다. 검토자가 휴가 중일 수도 있고, 제공업체가 밀려 있을 수도 있으며, 항목이 잊힐 수도 있습니다. 제한이 없다면 작업은 영원히 기다리게 됩니다.

그래서 대기 시간에는 상한이 있습니다. 사람이 결과물을 내놓을 때까지 워크플로가 얼마나 기다릴지 설정하며, 동일한 timeoutHours 설정이 두 검토 모드 모두에 적용됩니다. 응답 없이 타임아웃이 만료되면 이 단계는 skipped로 표시되고, 작업은 AI 번역을 최종 결과물로 삼아 계속 진행됩니다. 기본값은 48시간입니다.

대가를 분명히 말하자면, 타임아웃이 발생하면 검토되지 않은 AI 번역이 그대로 배포됩니다. 대부분의 콘텐츠에는 이것이 올바른 대체 동작입니다. 무기한 멈춰 있는 작업보다 배포된 번역이 낫기 때문입니다. 하지만 분명한 트레이드오프이기도 합니다. 어떤 경우에도 사람이 반드시 승인해야 하는 콘텐츠라면 넉넉한 타임아웃을 설정하고 스킵 시 알림을 받으세요. 검토가 있으면 좋은 정도인 콘텐츠라면 짧은 타임아웃이 파이프라인을 계속 움직이게 해줍니다.

단계 활성화#

humanEdit은 다른 모든 파이프라인 단계와 마찬가지로 구성됩니다. 엔진의 Pipeline 탭에서 엔진 수준 기본값을 설정하고, 필요하면 요청별로 재정의할 수 있습니다. 전체 2계층 모델은 파이프라인 구성에 설명되어 있으며, 이 단계에 해당하는 형태는 다음과 같습니다.

{
  "humanEdit": {
    "enabled": true,
    "provider": "internal",
    "tier": "standard",
    "timeoutHours": 48
  }
}

provider은 모드를 선택합니다. 사내 팀용이면 internal, 그렇지 않으면 외부 제공업체를 사용합니다. tier(standard 또는 pro)은 외부 검토에 적용되며 내부 검토에서는 무시됩니다. timeoutHours은 위 섹션에서 설명한 상한 시간입니다. 단일 제출에 대해 재정의하려면 create call의 pipelineConfig 안에 이 블록을 전달하세요. 이를 생략하면 작업은 엔진 설정을 상속합니다.

이 단계가 실행되면 작업 아래의 stepId: "humanEdit"에 상태가 completed, failed, 또는 skipped로 기록됩니다. 이는 모든 단계가 생성하는 동일한 단계 레코드입니다. 이러한 레코드를 읽는 방법은 파이프라인 실행 관찰에서 다룹니다.

다음 단계#