부제: 네가 못 하는 일이라고 세상에 없는 건 아니다

한국은 물론 전 세계적으로 대규모로 소프트웨어 번역이 발생한 시점은 일반적으로 윈도우 95 출시를 꼽습니다.

1990년대를 잠시 언급하고 넘어가자면
- 당시 상당히 비싼 개인용 컴퓨터의 하드디스크 용량은 약 2GB, 램 8MB 가량
- 1990년대 초반 일반적인 하드디스크 용량은 20MB(단위 잘못 쓴 것 아님) 이후 후반쯤 가서야 가정용으로 1GB가 일반적으로 깔리기 시작
- 주변기기 합한 모든 컴퓨터 가격의 절반을 램이 차지함
- 이동식 저장장치는 1.44mb 플로피 디스크(그나마도 심심하면 오류가 나서 안 읽힘)
- 모뎀(전화선)을 사용한 최대 인터넷 속도는 약 56Kbps
(현재 기가인터넷이 최대 1Gbps이고, 이는 1Kbps의 백만 배라는 점을 감안하면, 그냥 굉장 히 빨라졌다고 이해하면 됩니다. 안정적이지도 않아서 3메가짜리 파일 하나 다운받는 데 하루 종일 걸리는 건 다반사)
- 지금보다 매우 상당히 절제해서 인터넷을 사용하면 전화세가 20만원 나오던 시절
- 대졸초임 임금이 세전 100만원이 안 됨

팩스와 우편이 인터넷보다 빨랐던 시절입니다.

윈도우 95에 정확히 ‘번역해야 할’ 텍스트가 얼마나 들어가 있었는지는 알 수가 없으나 코드 기준으로 1100만줄이 들어가 있었다고 합니다. 전작인 윈도우 3.1은 3백만 줄이었고요.
https://www.nytimes.com/1995/07/31/business/microsoft-s-mobilization-overview-windows-of-opportunity-for-microsoft.html

여하튼 이런 상황에서 윈도우 95 번역 썰은 구전설화로 떠돌다가, 우연히 재미있는 영상을 찾아서 소개해 봅니다.
https://www.youtube.com/watch?v=KJ7Sb8Yl_x8



당시 소프트웨어 번역 과정과 현재의 번역 과정이 엄청나게 크게 다르지는 않은데,
(원문에서 번역해야 할 부분을 추출 -> 번역 -> 원본에 집어넣고 컴파일해 확인 -> 수정 -> 반복)
하드웨어와 소프트웨어 환경으로 인한 차이가 존재합니다.

- 인터넷이 매우 느림. 오늘 번역한 3메가짜리 파일이 운 좋으면 내일 도착한다고 생각하면 됨
- 부팅화면 번역을 하려고 컴퓨터를 직접 재부팅해 봤다는 얘기가 나옴(...)
- 자택에 윈도우 95가 작동되는 컴퓨터를 여러 대 갖출 인간이 매우 매우 매우 드물었음
- 오늘날 트라도스 같은 건 없었고, 있더라도 당시 하드웨어 사양이 못 따라감
- 트라도스의 기능은 원시 파일에서 번역할 텍스트만 추출하는 것임
- 소스 코드와 텍스트 분리가 불가능해서 직접 보고 작업할 수밖에 없음
- 소스 코드, 영어, 한국어를 함께 이해하는 인력이 급박히 대규모로 필요했던 것으로 보임
(영어 하나만 해서는 안 됨. 영어 원어민들이 Press any key to continue에서 any 키가 어디 있냐고 마소에 전화했다는 썰이 돌아다녔음)
- 소스 코드를 직접 보고 작업해야 함(보안 문제)+인터넷 느림+하드웨어 딸림+소프트웨어 딸림의 환장의 콜라보
- 결국 저분도 한국마소 본사로 출근했던 것으로 보임. 현재의 재택근무 형태는 아님.


https://linuxreviews.org/42.9_GB_Of_Microsoft_Source_Code_Leaked:_Historicans_Can_Now_Study_The_Source_Code_For_MS-Dos_3.3_To_Windows_XP

실제 윈도우 소스코드인지는 알 수 없지만 저기서 번역해야 할 부분은 Not a valid xml file:와 Entered objEnumInputEffectsCallback\r\n으로 보입니다.

저 분은 미국에서 컴퓨터공학을 공부한 뒤 귀국했는데, 우연히 1994년 소프트웨어 기술문서 번역사 구인광고를 보고 마소에 입사했다고 합니다.


https://www.linkedin.com/in/jaehoon-noh

지금이야 IBM과 마소와 트라도스의 가호 덕택에 속편하게 트라도스가 예쁘게 쌔워놓은 병렬식 화면이나 보고 타닥타닥 작업하면 그만입니다만, 당시 윈도우 95 한글화 작업에는 처음에 개발자가 붙어서 일하다가, 나중에는 외부 인력을 충원해야 했던 것 같습니다.



소스 코드를 보고 내용을 파악하는 것도 당연히 한계가 있어서(당시 도스를 벗어난 그래픽 기반 인터페이스로는 최초였음) 설치 과정을 직접 봐야 했던 듯합니다. 폰카로 찍으면 안됐냐고요? 에이 이 사람아...

희한하게도 윈도우 95에는 이중 조사가 거의 사용되지 않습니다. 저같은 문과생 번역노가다꾼이야 이중 조사를 처리할 능력이 없거나, 정보가 없거나, 게을러서 그렇게 하는데 아마 맥락을 알고 있는 개발자가 번역하니 직접 코드상으로 조사를 조져 주셨던 듯합니다. 번역가는 코드를 직접 수정할 수는 없으니 나름의 방법으로 조사를 조지면 됩니다.
* ‘임윤은(는) 체력이 0이(가) 되었다!’ 같은 것이 이중 조사
* 산업번역 가이드의 플레이스홀더 편을 참조하세요



마소 사내에서 중앙집중화된 용어집과 번역 메모리를 관리했다는 점은 짐작할 수 있지만 현재와 같이 트라도스 내부에서 편리하게 띄워주는 방식은 절대 아니었을 것입니다.
사내 전산망이 있고 용어 검색 기능을 임시방편으로 개발했더라도 거의 활용하지 못했을 겁니다. 현재도 고작 몇만 항목짜리 용어집을 넣으면 트라도스가 괘애애액 하는 걸 느낄 수 있는데, 문자열에서 문자를 분리한 뒤 전역일치 검색을 수행하는 방식 때문입니다. 저야 뭐 코파면서 트라도스가 알아서 해주겠지^^하고 있지만 그 당시에는 방법이 없었을 것...
그렇다면... 어떻게 수많은 사람들이 붙어서 번역했는데도 한 사람이 번역한 것처럼 일관성을 갖추었을까요?

번역 메모리를 외우고 있는 인간 메모리를 여러 단계에 투입해 해결한 것으로 보입니다.

* 여러 단계:
소스코드 보고 번역 -> 검수 -> 번역이 오락가락 -> 검수 -> 일단 오락가락 하는 건 잡음 -> 윈도우에 직접 컴파일하고 실행해 봄(컴파일에만 며칠 걸렸을 것) -> 그게 그 맥락이 아니었네... 여기는 번역 안됐네... 오락가락하는거 잡은 줄 알았더니... -> 다시 소스코드 보고 번역 -> 검수 ...
(추측입니다)







데스크톱을 바탕화면으로 걸리는 데 한 달이나 걸린 이유가 ‘이 용어가 괜찮은지 회의하느라’가 아니라.... 여러 사람이 소스코드를 하나씩 보면서 바꿨기 때문으로 추정됩니다. 결정 자체가 굉장히 빨리 되었어야만 그 많은 데스크톱과 유사 후보들을 바탕화면으로 한 달만에 바꿀 수 있었을 것이에요.

이런 일이 한국어 번역에만 일어난 것 같지는 않습니다. 물론 한국어는 로마자 기반 문자가 아니라서 중국어, 일본어와 더불어 한글 표시에 훨씬 큰 어려움이 있었다는 점도 참고할 만합니다.

여하튼 마소는 1995년 말 윈도우 95 전세계 발매를 거치며 소프트웨어 번역 방식의 한계를 느꼈던 듯하고, 1997년경 트라도스의 아버지 요헨 후멜이 세운 슈투트가르트의 작은 회사 트라도스에 투자합니다. 마소가 언어 기술 회사에는 처음 투자한 거죠. 제가 만약 아버지였다면 투자금 받은 시점에서 휴대폰조차 없애고 속세와 연을 끊었겠습니다만 저 정도 능력자는 세상이 가만두질 않는다.

트라도스의 아버지 요헨 후멜이 말하는 번역과 AI의 미래
https://rebtion.net/learnfree/?mod=document&pageid=1&uid=11053

오늘날 저같이 가련한 수포자 문과생 번역충들은 트라도스에 비해 멀티텀을 열어볼 일이 많지 않고, 트라도스 2024에는 멀티텀을 별도로 실행하지 않고 트라도스에 통합한다는 말까지 나오고 있지만, 저 당시에는 워크벤치가 아닌 멀티텀에 가중치를 두었던 것으로 보입니다.
두 소프트웨어를 연동하는 건 당시로서는 하드웨어 측면의 어려움이 컸던 걸로 추측됩니다.

Microsoft Invests in Translation Support Software Supplier
(마소 번역 지원 소프트웨어 공급업체에 투자하다)
https://news.microsoft.com/1997/09/09/microsoft-invests-in-translation-support-software-supplier/

이후 하드웨어와 소프트웨어의 비약적인 발전 덕택에 어떤 일자리는 없어지기도 했을 겁니다. 그런데 새로 생긴 일자리도 분명히 존재합니다. 역사깊은 대갓집 문서, 이미지, 영상 편집 소프트웨어 등을 개발 하나도 못하고 소스코드도 못 읽는 제가 번역해서 먹고 삽니다. 플레이스홀더/태그 배우고 트라도스 켜서 번역메모리랑 텀베이스 입력하면 되는 건데요.

미래는 분명 불평등하게 펼쳐질 거에요. 다시 말해, 오늘날에도 번역 메모리가 뭔지 모르는 사람들이 있어요

트라도스가 필요없다고 주장하는 사람들이 있긴 있어요. 그런데 트라도스의 아버님도 설득에 실패한 걸 제가 어떻게 함....

분야가 어떻든 요즘은 .xml처럼 호환성 높은 포맷이 있고 트라도스의 구문 분석 능력이 상당히 발전해서 플레이스홀더/태그를 익혀야 하게 되었습니다. (호환성이 높다는 건 번역된 .xml이 종이인쇄된 책자는 물론 웹, 모바일 앱 등에 이식이 가능하다는 뜻) 모든 산업의 기본은 분업이고 산업번역도 예외가 아닙니다. 본인을 부품으로 여기고 기능을 더해야 먹고 살만한 수입이 나옵니다.

그나마 이미지나 영상편집 소프트웨어 같은 건 소프트웨어 영역이라고 짐작할 만하니 좀 희귀한 사례를 말씀드리겠습니다.
예전에는 농사, 목축업도 전부 인력으로 했지만 요즘은 이것조차 과학영농입니다.
딸기 농사란... 비닐하우스마다 온습도계를 갖다놓고 새벽같이 일어나서 확인해야 하고, 날씨 좀 따수워지면 습도 때문에 딸기가 무르기 때문에 후다닥 일어나 새벽부터 비닐하우스를 제때 걷어야 해요. 늦게 일어나면 하우스 농사는 망하는 것입니다. 또한 한국 땅은 이미 지력이 예전에 쇠한 지 꽤 되었기 때문에 비료를 줄 수밖에 없습니다.
농약이요? 집구석에서 상추라도 키워보신 분이라면 유기농을 추구하다간 절반 이상을 자연에 바쳐야 한다는 사실을 아실 것입니다. 벌레는 자연발생하는 게 맞아요.
예전에는 감으로 농약을 희석하고 비료를 뿌렸지만 요즘은 땅에 센서를 박아서 어떤 비료를 얼마나 희석해 땅에 뿌리거나 엽면시비(foliar fertilize)를 하고 온습도 고려해 어떤 시기에 농약을 어떤 걸 쳐야 할지 앱으로 알려줍니다. 이걸 누가 번역하냐고요? 소프트웨어 개발, 외국어 번역, 농사까지 동시에 가능한 사람이 세상에 얼마나 됩니까. 다 분업하는 거죠.
실제 이런 소프트웨어는 플레이스홀더/태그 다룰 수 있는 번역가가 번역한 뒤 농사 지을 수 있는 분한테 맡깁니다. 이런 사람들을 주제별 전문가(subject matter expert)라고 하고요. 주제별 전문가가 수정한 부분은 다시 번역가/리뷰어에게 맡겨서 확인합니다.
저는 그나마 엽면시비를 해보고 식물을 꽤 죽여본 자라 이 부분에서 용어 수정을 거의 받지 않았는데요..... 문제는 양계 앱을 번역할 때 일어났습니다.

*모두가 알고는 있지만 조금 잔인한 내용이 나옵니다
*저는 양계업자를 비난할 생각이 없습니다. ‘윤리적으로 키운’ 닭값 비싸면 시장에서 안 사잖아요.

대강 아시겠지만 공장식 양계업은 계란을 살덩이로 키워내는 작업입니다. 일반적으로 생물 암컷이 지방이 많기 때문에 수평아리는 효율이 안 좋다고 여겨집니다.
그래서 ‘처리’를 하는데, 제가 본 원문에서는 grinding이라고 하더라고요. 저는 분쇄라고 번역했습니다.
양계 주제별 전문가가 ‘렌더링’이라고 수정하셨더라고요. 그제서야 ‘양계 렌더링’을 검색하고는(검색 팁: 주제와 키워드를 같이 넣으세요) 수평아리 분쇄 작업을 한국에서는 렌더링이라고 한다는 것을 알았습니다. 영어 rendering은 이미 사망한 일체의 고기를 분쇄하는 작업을 뜻하니 원문에 들어갈 일이 없었던 겁니다.

이 작업을 끝내고 저는 몇달간 인간으로 태어난 걸 혐오하며 치킨을 먹지 못했습니다만 이건 별로 중요한 문제는 아니고....

기술과 도구는 근본적으로 분업과 전문화를 촉진합니다. 조선시대 말기에 저수지 확충되고 모내기(이앙법)가 상용화되면서 부농과 날품팔이로 나뉘었다는 얘기 국사교과서에 나오잖아요? 그래서 결국 사람들이 굶어 죽은 건 아닙니다. 분업과 전문화는 총생산량을 늘리거든요. 날품팔이 중에서도 장사로 대성한 사람들이 존재해요.

AI 기술이라고 근본적으로 다르지는 않다고 봅니다. 머리좋은 개발자와 엔지니어가 만들어 놓은 소프트웨어와 하드웨어 덕택에 예전엔 비싼 개발자가 하던 일을 오히려 저 같은 수포자 문과생도 할 수 있게 된 건 반론의 여지가 없는 사실이니까요. 심지어 모바일 애플리케이션 출시 주기가 단축되며 물량도 분야도 오히려 늘었습니다.

오역 하나 없던 윈도우 95에 비해 윈도우 11은 자동번역기로 급하게 때웠거나 번역 안 된 부분도 있던데, 그러면 어쨌든 번역 인력이 줄어든 거 아니냐고 생각하실 수야 있겠습니다. 아마 출시 직후에 설치하셨다면 기계번역으로 때운 부분이 많이 보였을 겁니다.

하지만 1995년 당시의 환경을 고려하면 번역을 완벽하게 하는 것이 총비용을 줄인다는 점은 어렵지 않게 알 수 있습니다. 일단 CD로 구워서 배포하면 수정할 방법이 없거든요. 업데이트요? 아까 3메가 파일 하나 받는 데 운 좋으면 몇 시간 걸린다는 말씀 안 드렸습니까? 파일이 몇십 메가 단위로 커지면 다운로드 중 어딘가 결함이 생겨서 파일이 안 열립니다. 하루 몇 시간만 인터넷을 써도 전화세가 한달 20만원이 나오던 시대에 업데이트가 가능한 사람이 있었겠나요? 국민 전체의 컴퓨터 이해도나 영어 독해력도 높지 않던 시절 오역 때문에 마소 콜센터와 AS센터 인력이 갈려나갈 걸 고려하면 번역을 완벽하게 해서 내는 것밖에 답이 없었습니다.

지금은 한국만 늦게 출시한다고 욕을 먹느니 그냥 번역기로 돌려서 인간 적당히 넣어 아주 크게 틀린 부분만 고치고 내보내는 게 낫죠(이런 상황에서는 disclaimer로 영어와 한국어 기계번역 내용이 다를 때는 영어가 우선한다는 단서를 붙입니다). 이 작업을 light PE(Post Editing)라고 합니다.

이후에 light PE를 인간이 직접 번역한 레벨로 고쳐달라는 full PE 작업을 거치고 업데이트 때 다시 배포합니다. 예전처럼 업데이트 비용이 많이 들지 않으니 가능한 일입니다.

그러면 이 과정에서... 번역가가 갖추어야 될 지식은 무엇인가





















문맥 따라 정확히 번역하여 고객사님을 소송에 들게 하지 말고 기술 배워야 한다는 말이 심금을 울립니다.

맥락을 파악해야 한다는 말을 수포자 문과생이 주제넘게 조금 더하겠슴다.

Open with...

‘...로 열기’로 번역하면 배려붑니다.
아무 맥락도 없이 이것만 달랑 있으면 한국어 사용자가 직관적으로 이해하게 번역할 수 없습니다. 기계번역이요? 근본적으로 쓰레기를 넣으면 쓰레기를 뱉어내고, 아무것도 입력 안 하면 아무것도 안 뱉어내는 친구입니다. 데이터를 넣어야 결과물이 나오고, 그 데이터는 결국 누군가가 정제해서 넣고 있습니다.

여하튼 저 문자열은 여기 나옵니다.
(윈도우 3.1은 기억 안 나고, 최소 윈도우 95부터는 있던 shift 우클릭 하면 있던 기능입니다)


https://www.digitalcitizen.life/open-with-windows/

한글 윈도우에서는 [연결 프로그램...]입니다. 저걸 누르면 파일을 여는 데 사용할 수 있는 프로그램이 나옵니다.

소프트웨어 번역은 오히려 지금으로부터 30년 전 막 생겨나기 시작한 신규 직종입니다. 여기 대고 무턱대고 챗GPT가 나왔으니 소프트웨어 번역은 사라질 거라고 하면 그 사람에 한해서는 맞는 말일 거예요. 애초에 자기 세계에선 없는 일이니 사라진다고 생각할 수도 있겠죠. 거기선 존재했던 적이 없었으니 엄밀히 말하면 사라진다는 건 잘못된 표현이지만요.

Q 너는 대체 플레이스홀더랑 태그를 어디서 배움?
A 중딩때 html/css, perl cgi, php/mysql 배우고 웹개발자 되려고 했음. 웹개발 특성상 오픈소스가 대부분이라 남의 소스 갖다붙이기로 비슷한 결과를 낼 수 있었는데, 당시 마소 테스터 하는 프로그래머들 보고 지능지수의 격차를 느끼고 수능 준비함. 그때 배운 걸로 지금 먹고 살게 될줄 누가 알았나...

Q 그 사람들이랑 최소 10년은 차이났을 텐데 공부 꾸준히 해보지?
A 10년 전 번역실력이랑 지금 차이가 엄청나게 크지 않음. 더 이상의 설명은 생략함.

Q 나도 perl cgi 공부해야 됨?
A 역사공부 할거 아니면 산업번역 가이드 3장만 보시길 바람