Trados Studio 프로젝트의 작업 흐름

트라도스 스튜디오를 사용하는 프로젝트는 일반적으로 아래와 같은 흐름으로 이루어집니다.

  1. 클라이언트(보통 PM)가 프로젝트를 만듭니다. 

  2. 클라이언트가 프로젝트에서 번역가/리뷰어에게 보낼 패키지를 만듭니다. 여기서 패키지는 두 가지로 나뉩니다.
    – 프로젝트 패키지(Project Package, .sdlppx): PM이 번역가/리뷰어에게 특정 작업(번역 또는 리뷰)을 완료하도록 요청하기 위해 생성하는 파일 패키지
    – 반환 패키지(Return Package, .sdlrpx): 번역가/리뷰어가 위 특정 작업을  완료한 후에 PM에게 전송하기 위해 생성하는 파일 패키지

  3. 번역가/리뷰어가 클라이언트에게 받은 프로젝트 패키지(.sdlppx)를 가져오기(import) 한 다음, 컨텐츠를 번역/리뷰하고 반환 패키지(.sdlrpx)를 만들어 클라이언트에게 돌려보냅니다.

  4. 클라이언트가 처음 패키지를 만든 프로젝트로 반환 패키지를 가져오기 합니다. 이렇게 하면 프로젝트의 컨텐츠가 업데이트됩니다. 

여기서 퀴즈를 하나 내겠습니다. 위와 같은 일련의 주기를 고려했을 때, PM이 리뷰어에게 .sdlrpx 확장자 파일을 주면서 리뷰를 요청할 수 있을까요?

정답은 ‘아니요’ 입니다. 위 작업 흐름에서 리뷰어는 처음에 프로젝트를 만들지 않았으므로 반환 패키지를 받을 일이 없고, 반환 패키지를 가져오려 해도  불가능합니다. Freelance 버전에서는 어차피 사용할 수 없는 기능이거든요.

만약 PM이 여러분에게 반환 패키지를 보내며 번역이나 리뷰를 요청한다면 덥석 수락하지 말고 먼저 왜 그랬는지 물어보아야 합니다. 아마 PM이 일을 시작한 지 얼마 되지 않았거나 트라도스를 잘 이해하지 못해서 그랬을 확률이 높습니다. 전체 작업 흐름에서 여러분이 맡은 번역/리뷰라는 역할이 차지하는 위치를 명확하게 이해하는 데 모쪼록 도움이 되기를 바랍니다.

Related Post

마침내 Trados를 구매하다 10년전 번역을 처음 시작했을 때 멋모르고 Trados를 샀습니다. 이리저리 둘러보고 쑤셔보고 눌러보다가 화딱지가 나서 때려쳤지요. ㅎㅎ 그 뒤 MemoQ를 필두로 XTM, Memsource 등 이런저런 캣툴을 전전하다가 구세주 같은 Fluency Now(당시에는 Fl...
Trados Studio 패키지 파일 오류를 우회하는 방법... Trados Studio(이하 트라도스)를 쓰다 보면 패키지 파일이 문제를 일으키는 일이 의외로 자주 있습니다. PM에게 받은 패키지를 가져오기(Import) 할 수 없을 때가 간혹 있는데, 원인도 다양합니다. 다른 캣툴도 마찬가지이지만, 특히 트라도스를 주로 사용하는...
Trados Studio 저렴하게 구매하기 업계 1위라고 광고하는 Trados Studio(이하 트라도스)는 가격도 1위입니다. 캣툴 중에서도 최고가를 자랑하기 때문에 덥석덥석 쉽게 사볼 만한 제품은 아닙니다. 트라도스로 작업을 하려면 최소 Freelance 버전(Starter 버전은 기능 제약이 많으므로 구매...
CAT tool 시장에 대한 이해(1): 트라도스, 정말 꼭 필요할까요?... 번역을 막 시작하려고 하는 분들뿐만 아니라 이 분야에서 오래 활동해 오신 분들께도 CAT tool은 늘 중요한 주제가 아닐 수 없습니다. CAT tool은 컴퓨터와 테크날러지에 익숙지 않은 번역가들에게 사실 골칫거리입니다. 넘어야 할 산과 같은 존재인 것이지요. 하...

2 thoughts on “Trados Studio 프로젝트의 작업 흐름

  1. 프로젝트 패키지를 PM에게서 받아서 작업을 하던 중 일부 문장들의 세그먼트가 잘못된 경우 어떻게 하는 것이 좋을까요? 저는 이상하게 보이지 않을 만큼 적당히 편집해서 보냈는데요. PM에게 세그먼트가 잘못 되었다고 말하고 새로 패키지를 받는 게 맞을까요? 이미 번역이 한창 진행 중인 경우 패키지를 다시 받는 것도 어려워 보여서 질문 드립니다.

    1. – 오류가 일부 세그먼트에 국한되고 번역 결과물에 영향을 미칠 수준이 아니라면 완료한 파일을 보내면서 문제가 있는 세그먼트들을 알려 주는 것이 좋습니다. 일 잘하는 PM이라면 피드백을 주어서 고맙다고 할 것입니다.

      – 소스 세그먼트를 편집할 수 있다면 단순 오탈자 한두 개 정도는 번역가가 직접 수정하고 PM에게 알릴 수도 있습니다. 그런데 PM 입장에서는 번역가가 소스를 수정하는 일이 달갑지 않을 수 있습니다. 세그먼트 편집이 가능하더라도 소스에 오류가 있다면 원칙적으로 PM에게 미리 언급하는 것이 좋습니다. 간혹 레이아웃이 깨지는 등 문제가 발생하기도 하고 나중에 뒷말이 나올 수 있으니까요. 그래서 대부분의 프로젝트는 처음부터 소스를 건드리지 못하게 설정이 되어 있습니다.

      – 서식이 단순한 문서여서 번역가가 편집해도 소스에 별 문제가 없을 정도라면 PM에게 소스 편집을 허용해 달라고 제안해 볼 수도 있습니다. 단, 이건 추가로 수고가 들어가는 부분이니 번역료에 반영해야 하겠습니다. OCR이 불가능한 PDF 같은 것이니까요.

      – 세그먼트에 오류가 너무 많아서 결과물에도 영향을 끼칠 정도라면 다소 번거로워도 PM에게 상황을 설명하고, 패키지를 새로 만들거나 일부 .sdlxliff 파일만 교체하는 식으로 방법을 강구해 달라고 요청하시는 편이 좋겠습니다.

댓글을 남겨주세요(댓글은 모든 사람이 볼 수 있습니다).