Search
🔵

a1.2.a9.3. [info] title: 기술서 번역 관련내용 공유 (시행착오를 줄이기 위한 팁 등)

생성
🚀 prev note
♻️ prev note
🚀 next note
♻️ next note
14 more properties

1. 기술번역서 작성 시 절차

단계
비고
예시
 출판 계약
 가이드 숙지
- 편집자를 통해 인계
 역할 분배
- 마일스톤 및 일정 계획
 본문, 초록, 부록 번역
- 편집자 피드백
 역자소개 작성
 역자의 말 작성
 감수자 모집
 지인검토 모집
 지인검토
 베타리딩 모집
 1차 조판
- 지인검토 피드백 반영
 베타리딩
- 편집자의 DRI 이지만 역자가 구해도 됨
🫶🏻 추천사 요청
- 지인검토자, 베타리더
 소스코드, 깃허브 정리
 2차 조판
- 베타리딩 피드백 반영
 감수자 검토
🫶🏻 감수평 요청
 3차 조판
 출판

2. 가이드 숙지

작업 디렉터리 구조 및 역할

원고 워드파일 서식

워드에서 서식을 적용하는 창
출판사에서 워드파일 서식을 제공합니다.
Google Docs 를 이용해 워드파일을 편집하는 경우 서식이 제거되고 파일이 깨지기 때문에 일부 편집자님들은 사용하지 않는 경우가 있습니다. 기능적으로도 열악하고 느린 감이 없잖아 있으니 일단 불편하더라도 Google Docs 대신 MS Word 를 사용하세요.
아직 번역작업을 시작하지 않았는데 편집자님이 MS Word 사용을 고집하신다면 꼭 Google Docs 등 협업도구 사용을 반드시 제안해 보세요.

워드파일 협업

이 내용은 MS Word 에 한정되는 내용입니다.
아직 MS Word 는 동시작성을 허용하지 않습니다. 그 대신, 변경내용 추적기능을 활성화하고 작업을 한 뒤, 클라우드에 업로드하고 노티를 보내면 다른 사람이 변경사항과 댓글을 확인하는 형태로 작업합니다.
워드 변경내용 추적 (워드가 많이 느려집니다)

3. 역할 분배

편집자와 역자

편집자님이 역자에게 기대하는 부분

직역보다 의역을 중요하게 여깁니다.
한국 독자 중심의 흐름을 중요하게 여깁니다.

역자 개인

역자의 권한과 역할

부드러운 번역을 위해 단어를 하나 빼거나, 문장을 넣거나, 문장의 앞뒤 순서를 바꿔 버려도 됩니다.
문화권이 달라서 비유의 내용이 터무니없다면 아예 빼버리고 한국 패치를 해도 됩니다.
문장이 누락되면 때 편집자님께서 피드백을 달아 주십니다. 그때 설명을 드리면 됩니다.
소스코드의 경우, 주석 정도만 번역해도 괜찮습니다.
스크린샷 화면의 경우, 영문 화면만 존재한다면 번역하지 않아도 됩니다.
콘솔 출력 등은 상황에 따라 번역하기도 하고, 번역하지 않기도 합니다.
돌지 않는 소스코드를 확인해야 합니다.
오동작 코드의 경우 원저자에게 문의하거나 직접 수정해야 할 수 있습니다.
직접 수정하는 경우, 역자의 github 저장소를 게시할 수 있습니다.

역자와 역자

1역자 선정
파트 분량 DRI 설정

4. 본문 번역

번역 워크플로 팁

1.
1회독: 영→영 번역할 부분의 책 내용을 우선 번역 없이 읽어보는 것을 추천합니다. 공역을 하는 경우, 번역하는 분야에 대해서 어느정도 이해하고 있는 것이 아니라면 뒷부분 번역을 맡았더라도 책을 처음부터 읽어 보세요. 왜냐하면 챕터 간 의존성이 없다고들 하나, 생각보다 그렇지 않은 경우가 많습니다. 욕심을 내면서 이것저것 바꾸고 문장 순서도 바꾸고 코드도 바꾸고 하면서 차근차근 나아가는데 뒤에서 앞의 내용에 의존성을 발견해 버리면 그때는 정말 비참해집니다. 적어도 모든 페이지의 내용을 2~3문장으로 요약할 수 있는 상태, 실습 코드는 모두 작동을 확인한 상태에서 시작합시다. 1달(읽기) + 3달(번역) = 4달 vs 5달(읽기+번역) 정도 퍼포먼스 차이가 납니다.
2.
2회독: 영→영 책 전체를 다 읽었다면, 번역하는 부분으로 돌아옵니다. 번역하는 장(chapter)의 흐름을 다시 한번 되새겨 봅니다.
3.
2회독: 영→한 서식이 적용된 워드파일에 원문 한 문단을 복사(cmd + c) 서식 없이 붙여넣기 합니다(cmd + option + shift + v). 그리고 그 아래에 번역문을 작성합니다. 처음에는 집중하되 너무 퀄리티에 집착하지 않습니다. 어차피 한번 더 해야 합니다. 문단 번역을 마치면 원문을 삭제합니다. 하나의 장(chapter)이 끝날 때마다 편집자님께 피드백을 요청드립니다. 형편없는 상태로 피드백을 요청드리는 이유는, 편집자님의 스타일을 이해하고 빠르게 나의 번역 퀄리티에 대한 객관적인 피드백을 수렴하기 위함입니다.
4.
2회독: 영→한 2~3을 반복합니다. 중간에 편집자님이 이전 장에 대한 피드백을 마쳤다는 노티를 주신다면 하던 일을 중단하고 돌아가 피드백을 확인하고 수정합니다. 반드시 번역문을 조금이라도 더 작성하기 전에 최대한 편집자님의 피드백을 최대한 들어 보겠다는 마인드로 진행해야 합니다.
5.
3회독: 한→한 다시 처음으로 돌아갑니다. 이제 원문을 최대한 참고하지 않고 한글만 보고 더 부드러운 한글로 다듬습니다. 만약 1을 안 한채로 바로 2~3을 시작했다면, 2~3을 하면서 쌓인 지식으로 인해 더 보이는 문장들이 많아지므로, 내 번역을 참을 수 없는 수준이 되어 있기 때문에 다 갈아엎으며 원문을 참고하게 됩니다. 이렇게 하면 다시 수정할 일이 정말 많이 생기게 됩니다. 마찬가지로 한 개 재번역을 마칠 때마다 다시 피드백을 요청드립니다.

모범 사례

직역보다 의역 선호

기계번역이 잘못된 것은 아니지만 기계번역은 직역을 하는 경우가 많습니다. 그대로 번역하면 어색해집니다.
한빛 편집자님은 직역이 아니라 부연설명이 추가되더라도 적절히 의역된 것을 중요하게 생각하십니다. 결국 책을 읽는 것은 한국 독자이기 때문입니다.
wasn’t able tocouldn’t 의 문맥상의 차이를 아시나요? 우리는 이런 것에 집착할 수 없습니다. 우리는 문학작품을 번역하는 것이 아닙니다. 독자들은 기술을 올바르게 이해하고 싶어하지 원문의 느낌을 생생히 느끼고 싶어하지 않습니다. 어차피 영어를 정말정말 잘하지 않는 이상 원문을 그대로 옮길 수 없습니다.
처음에는 이러한 것들로 인해 욕심을 내곤 하지만 시간을 잡아먹을 뿐입니다. 이해한 대로 옮기세요.
원문
기계번역(Google 번역, NAVER CLOVA)
작업 후
chapter2, A crude and straightforward example of AutoML is an Excel spreadsheet that performs linear regression. You tell Excel which column is the target to predict and then which column is the feature.
AutoML의 조잡하고 간단한 예는 선형 회귀를 수행하는 엑셀 스프레드시트이다. 엑셀에 예측할 대상인 열과 특성인 열을 알려준다.
AutoML은 쉽게말해 데이터가 담겨 있는 엑셀에 어떤 열이 모델이 추론해야 하는 값을 담은 열이고 어떤 열이 특징을 담은 열인지 표기하기만 하면 특징값을 입력받아 추론값을 반환하는 머신러닝 모델을 자동으로 만드는 시스템이다.
chapter2, The first item is an alias that allows me to type the command flask-azure-ml, cd into a directory, and source a Python virtual environment in one fell swoop.
첫 번째 항목은 내가 명령 flask-azure-ml, cd를 디렉터리에 입력하고 Python 가상 환경을 한 번에 소싱할 수 있는 별칭이다.
스크립트의 첫번째 부분은 flask-azure-ml 명령어를 사용하면 자동으로 cd 명령어를 이용해 작업 디렉토리를 옮기는 동시에 파이썬 가상환경을 활성화하도록 설정하는 역할이다.
chapter2, This crash-course approach temporarily ignores the creator of code used by others in favor of the consumer of code and libraries, i.e., the data scientist or MLOps practitioner.
이 벼락치기 접근 방식은 코드 및 라이브러리 소비자, 즉 데이터 과학자 또는 MLOps 실무자를 위해 다른 사람들이 사용하는 코드 작성자를 일시적으로 무시합니다.
이러한 벼락치기 접근 방식은 ‘다른 사람들에게 사용되는 코드’ 를 만드는 일에 대해서는 생각하지 않는다. 대신, 데이터 과학자들이나 MLOps 실무자들이 하는 것처럼 ‘코드를 소비하는 방법’ 을 배우게 될 것이다.
chapter2, After these topics, if you are curious, you will have a solid foundation to move onto more complex computer science–focused topics. These advanced topics are not necessary to be productive immediately in MLOps.
이 주제들을 배우고 나면, 더 복잡한 컴퓨터 과학에 초점을 맞춘 주제로 넘어갈 수 있는 탄탄한 토대가 마련될 것이다. 하지만 컴퓨터과학에 초점을 둔 고급 주제는 즉시 생산적인 MLOps를 작성하는데 필요하지 않다.
이 내용들을 배우고 나서, 만약 당신이 정말 컴퓨터과학에서 다루는 주제들에 대해 궁금하다면 그때 공부해도 늦지 않다. 아래 내용들은 좋은 기반 지식이 될 것이다. 어쨌든 거듭 강조하지만 지금 당장 MLOps에서 생산적인 일을 하는 데에 전통 컴퓨터과학적 지식은 별로 도움이 되지 않는다.
chapter2, In the visualization shown in Figure 2-15 from the 2015–2016 NBA season, the computer “learned” how to group the different NBA players.
2015년과 2016년 시즌의 [그림 2-15]는 데이터 시각화 결과에서 컴퓨터가 다양한 NBA 선수들을 그룹화하는 방법을 ‘학습’했다.
[그림 2-15] 에 나타난 시각화에는 2015년부터 2016년까지 2년간의 데이터를 바탕으로 머신러닝 모델이 NBA 선수들을 분류하는 기준을 학습한 결과가 나타나 있다.
chapter2, This version may or may not be the optimal solution in a more extensive set of coordinates
이 버전은 보다 광범위한 좌표 집합에서 최적의 솔루션이 될 수도 있고, 아닐 수도 있다.
25번의 반복을 통해 찾아낸 경로가 세상에서 가장 좋은 경로일 수도 있고, 아닐수도 있다.
chapter4, I like the description of continuous as persistence or recurrence of a process. CI/CD are usually mentioned together when talking about the system that builds, verifies, and deploys artifacts.
나는 연속성을 프로세스의 지속성 또는 반복으로 설명하는 것을 좋아한다. CI/CD는 일반적으로 아티팩트를 빌드, 확인 및 배포하는 시스템에 대해 이야기할 때 함께 언급된다.
필자는 ‘지속적’ 이라는 단어의 의미를 ‘동일한 프로세스의 반복’ 이라고 설명하는 것을 좋아한다. 시스템을 빌드하고 검증하거나 그 과정에서 나타난 다양한 부산물들을 배포하는 반복적인 작업에 대해서 이야기할 때, 동일한 프로세스의 반복이라는 관점에서 ‘지속적’ 통합(CI)과 ‘지속적’ 배포(CD) 라는 두 단어가 함께 등장하는 경우가 많기 때문이다.
chapter5, … Similarly, I have come up with something I call the Automator’s law.
… 비슷하게, 나는 내가 ‘자동화 법칙’ 라고 이름붙인 생각이 있다.
… 이 세상에는 ‘자동화 법칙’이란 이름을 붙이기 좋은 패턴이 있다고 생각한다.
chapter5, Remember the DevOps practices described earlier in the chapter? MLOps builds on those practices and extends specific items to target machine learning systems directly.
이 장의 앞부분에서 설명한 DevOps 관행을 떠올려 보자. MLOps는 이러한 관행을 기반으로 머신러닝 시스템을 집중적으로 개선한다.
이 장의 앞부분에서 설명한 DevOps의 모범 사례를 떠올려보자. MLOps는 이러한 DevOps 모범 사례를 기반으로 머신러닝 시스템에 해당하는 부분을 개선한다.
chapter5, … it is easy to dive into either of these self-handicapping strategies.
… 자기불구화 전략으로 쉽게 뛰어들지도 모른다.
… 이러한 자기불구화 전략 중 하나를 실천해 버릴지도 모른다.
chapter5, In Figure 5-7, note that in manual data science, everything is bespoke.
[그림 5-7]에서 수동 데이터 과학에서는 모든 것이 맞춤화되어 있음을 알 수 있다.
[그림 5-7]에 나타난 수작업 위주의 데이터 과학에서는 모델 학습에 필요한 데이터가 필요할 때마다 데이터가 한땀한땀 다시 가공된다.

기계번역 오류 주의

기계번역이 문맥을 고려하지 않는 번역을 내놓는 경우가 종종 발생합니다. 예를 들어 우리는 같은 단어라도 문장에서 어떻게 사용되느냐에 따라 긍정성, 부정성이 달라질 수 있다는 사실을 알고 있습니다. 일반적으로 글로벌 맥락을 기계번역기가 올바르게 처리하지 못해서 발생하는 문제입니다.
이 잘못 만들어진 기계번역을 바탕으로 문장을 다듬어나가다 보면 뒤늦게 글을 잘못 이해하고 있음을 알아차리는 상황이 발생하곤 합니다. 이 경우 차라리 기계번역의 도움 없이 원문을 곧장 번역하는 것이 훨씬 빠를 수 있으므로 기계번역 어시스턴스 사용 시 주의가 필요합니다.
차라리 chat-gpt 를 사용하세요.
원문
기계번역(Google 번역, NAVER CLOVA)
오해상황 예시
번역 개선
chapter2, A crude and straightforward example of AutoML …
AutoML의 조잡하고 간단한 예…
chapter1 에서 필자가 무슨 말을 했는지는 모르겠지만, 아무튼 전반적으로 AutoML을 부정적으로 보고 있구나(X)
crude 는 그냥 강조 표현.
chapter2, For example, instead of spawning threads on a single machine, you could spawn AWS Lambda functions in the cloud, which behaves like an operating system with infinitely scalable resources.
예를 들어 단일 시스템에서 스레드를 생성하는 대신 클라우드에서 동일한 AWS 람다 함수를 여러 개 생성할 수 있다. 이 함수는 무한하게 확장 가능한 리소스를 사용하는 운영 체제처럼 작동한다.
앞부분에서 One way to think about a cloud is that it is an operating system. 이 나왔으므로, whichLambda function 이 아니라 the cloud 를 의미함. 이 문장만 보고는 알 수가 없음. 번역기에 이전 문장까지 한번에 넣어도 같은 문제가 발생함.
chapter2, In addition, for a model deployed to production, it is beneficial to have a notebook checked in alongside the code that deploys the model to serve as a README for thinking behind the project.
프로덕션 서비스에 도입되는 모델의 경우, 프로젝트 배경과 모델 설명을 포함한 리드미와 노트북 코드를 함께 체크인 하는 것이 좋다.
영문장에서 ‘REAMDE’ 가 필요하다는 말이, 진짜 README 가 필요하다는 표현이 아니라 코드를 설명하는 주피터 노트북이 README 처럼 기능함을 의미함.
특히 프로덕션 서비스에 사용되는 모델의 경우, 모델을 배포하는 소스코드를 담은 저장소에 프로젝트에 대한 이야기를 담아 README 파일처럼 기능할 수 있는 노트북 파일을 동봉하면 추후 소스코드와 모델을 이해하는 데 많은 도움이 될 수 있다.
chapter2, Let’s run this “greedy” algorithm 25 times. Notice that it finds a “good” solution of 129.
탐욕 알고리즘을 25번 실행하면 129개의 솔루션을 발견할 수 있다.
탐욕 알고리즘을 25번 다시 실행했을 때 발견한 가장 짧은 거리는 129 이다.
chapter3, Virtual machines were as large as the data when initially configured: …
초기의 가상 머신은 가상 머신이 실행되는 환경의 크기와 같이 데이터가 컸다.
‘한 번 설정된 이후’ 무겁다는 것을 의미함. 그리고 VM의 크기는 VM에 할당된 디스크의 크기와 동일함.
한 번 구성이 완료된 가상 머신은 굉장히 무거웠다. 호스트에서 가상 머신이 차지하는 디스크 용량은 가상 머신에 할당된 디스크 용량과 완전히 동일했기 때문이다.
chapter6, There are two common operations specific to ML that cloud providers need to monitor and capture useful metrics.
머신러닝 작업을 위해 클라우드 서비스 제공자들이 모니터링을 수행하기 위해 우리가 입력해 주어야 하는 두 가지가 있다. / 클라우드 제공자가 유용한 메트릭을 모니터링하고 캡처하는 데 필요한 머신러닝 관련 두 가지 일반적인 작업이 있다.
문장에서 specific to ML이라는 표현이 하고자 하는 말은 ‘머신러닝 작업의 경우에는’ 측정항목과 모니터링이 이렇게 수행된다는 것을 알려주고 싶은 것.
머신러닝 모델에 대해 클라우드가 자동으로 측정항목을 생성하고 모니터링하도록 만들기 위해서는 보통 두 가지 작업이 선행되어야 한다.

원문이 정말 구리다고 생각하는 경우

내가 못해서 구리게 느껴지는 것인지 실제로 글이 구린 것인지 고민이 필요합니다.
하지만 아무리 생각해도 책이 구린 것이라면, 애초에 이런 책을 하겠다고 하지 말 것을 권하고 싶습니다.
구린 책을 구분하는 확실한 신호는 다음과 같습니다.
1.
책의 후기가 좋지 않다.
2.
저자가 자신을 지나치게 자랑한다.
3.
문장과 예제에 깊이가 없고 책 전체적으로 유기성이 떨어진다. (하지만 이것은 책을 정말 오랫동안 읽어보기 전까지는 빠르게 알아차리기 힘들기 때문에 주의해야 한다)
너무 구리다고 생각하면 셋 중 하나를 결정해야 합니다.
1.
빠른 중도 포기: 구린 글을 좋게 만드는 일은 엄청난 리소스가 들어가는 작업임.
2.
타협하고 구린 원문을 그대로 내기: 가장 가성비가 좋은 선택이라고 할 수 있음. (개인적으로 용납 불가)
3.
최대한 개선하기: 이 경우에도 어느정도까지 타협을 할 것인지를 결정해야 함.
이 섹션은 여러 명이 구린 책을 최대한 개선하는 경우 어떻게 협업해야 하는지를 담았습니다.
1.
위 번역 워크플로에서 처음으로 한글 타이핑을 시작하는 순간의 이야기입니다. 어차피 이런 책은 영어를 꼼꼼히 읽는 것이 시간 낭비일지도 모릅니다. Chat-GPT4 이상의 성능을 가진 번역기를 이용해 처음부터 끝까지 모든 문장을 번역하여 저장합니다.
2.
위 내용을 베이스라인으로 삼고 개선해야 하는 내용을 다음과 같이 분해합니다.
a.
문장 그 자체
b.
문단 내 문장 간
c.
문단 간
d.
문장-문단-장(chapter)간
3.
워크플로
i.
(번역 1회전) a, b 를 동시에 고려하며 수정합니다. 원문을 참고해야 할 수 있습니다. 추가하고 싶은 내용, 부실한 내용을 댓글로 달아 둡니다.
ii.
(번역 2회전) c 를 고려하며 수정합니다. 앞서 달아두었던 댓글을 최대한 반영합니다. 종종 눈에 들어오는 a, b 도 고쳐 줍니다.
iii.
(번역 3회전) c 를 다시 고려하고 이번에는 d 를 고려합니다. 마찬가지로 앞서 달아두었던 댓글을 최대한 반영합니다.