오픈 소스 소프트웨어 번역 과정에서 따르는 과제들

p5js 코어 라이브러리 및 웹사이트 담당자 (steward)로 활발히 활동하고 계시는 Kenneth Lim님과 지난 12월 인터뷰를 진행했습니다. p5js 웹사이트 및 기술문서 번역 작업이 어떻게 시작되었는지, 그리고 오픈소스 소프트웨어를 번역하고 유지하는 데서 겪는 특별한 고민들에 관해 이야기 들어봤습니다.

오픈소스 소프트웨어 기여의 시작

A (Alm Chung): p5.js를 맨 처음 어떻게 만나셨고, 오픈 소스 소프트웨어에는 언제부터 기여하기 시작하셨나요?

K (Kenneth Lim): 제가 p5.js를 만나게 된 것은, 다른 분들의 경우랑 크게 다를 것 없었다고 생각해요. 대학교에서 접하게 된 프로세싱(Processing)을 통해 인연이 시작되었죠. 예전에도 조금씩 코딩을 해보긴 했지만, 프로세싱은 처음 시작해보는 것이었고 엄청 진지하게 뭘 한다거나 그런 건 아니었어요. p5.js는 2015년도나 2016년도쯤에 접했던 것 같아요. 첫 느낌은 프로세싱과 같았는데, 제가 더 자주 쓰던 자바스크립트(Javascript) 언어로 되어 있어서 바로 쓰기 시작했어요.

p5.js 프로젝트에 참여하기 시작한 것은 기술 문서 (documentation)를 통해서였어요. 지금도 이렇게 문서 개선을 통해 참여해보는 것을 다른 사람들에게도 많이 권하고 있고요. 문서를 읽다가 오타나 사소한 문제들이 보이면, 이걸 어떻게 고칠 수 있을까? 하고 생각해보는 거죠.

거기서부터 시작해서 천천히 더 스케일이 크고 기술적인 작업들로 옮겨갔어요. 한번은 스마트폰 센서 데이터(예: 가속도계(accelerometer) 데이터)를 다루는 부분을 개선하는 프로젝트를 맡은 적이 있어요. 이미 존재하던 코드가 제대로 작동하고 있지 않았죠. 이 프로젝트를 하게 된 계기는, 제 개인작업에서 비슷한 API를 썼던 경험이 있어서 기여를 해볼 수 있지 않을까 생각했어요. 그래서 이 프로젝트를 진행해 나가다가, 여러 우연이 겹쳐서 여기까지 오게 되었네요.

A: 그럼 p5js에 참여하시게 된 계기가 개인 작업이었군요. 자신의 작업에서 라이브러리를 쓰다 보면 자연스럽게 버그를 찾기도 하고, 개선점들이 떠오르기도 하죠. 그러다가 직접 개선 작업에도 손을 대시게 되고요.

K: 네, 많은 기여자 분이 그런 식으로 시작하시는 것 같아요. 게다가 제가 기여하려고 했던 부분은 제가 전문적으로 잘 파악하고 있는 내용도 아니었어요. 오히려 코드의 문제점들을 대략 인지하고 있지만, 실제로 개선 작업을 하기 전에 공식 MDN (Mozilla Developer Network) 웹 기술 문서들을 공부하거나 API가 실제로 어떻게 작동하나 시간을 써서 탐구해봐야 하는 케이스에 가까웠죠. 저는 p5js 프로젝트가, 누군가가 이미 준비된 전문가가 아니어도 기여를 할 수 있다는 점이 너무 좋다고 생각해요. 그저 자신이 선택한 지점에 시간을 쓰면 되는 거죠. 저희가 빨리 진행하라고 닦달하지도 않고요. “어 아직 안 끝났어?” 이런 말도 절대 안하고요! 그저 자기 속도에 맞춰 배우고, 고칠 것을 고치면 되죠. 기여의 과정에서 가장 중요한 것도 배움이고요.

A: 센서 데이터 프로젝트 다음으로 진행하신 큰 프로젝트는 p5js 공식 문서 웹사이트를 번역하시는 일이었죠? 왜 그 다음으로 이 프로젝트를 작업하시기로 결정하셨었나요?

K: 프로세싱 재단 펠로우쉽(Processing Foundation Fellowships)을 알게 된 게 2016년도쯤이었어요. 이때 스페인어 번역은 이미 완성되어 있어서 웹사이트에서는 스페인어를 제공하고 있었어요. 거기에서 아이디어를 얻었어요. 제가 영어와 중국어를 할 수 있으니까, 펠로우쉽 오픈콜에 번역 프로젝트로 지원하면 되겠다고 생각했죠. 그래서 지원을 하긴 했는데, 사실 처음에 제 제안은 탈락했었어요. 재단에서 이 프로젝트에 알맞는 멘토를 찾지 못했던 게 이유였죠.

이런 사정으로 번역 프로젝트는 한 일 년쯤 멈춰 있었고, 결국 2018년도에 시작된 거예요. 번역 프로젝트는 좋은 아이디어였지만, 다음 해에 한 번 더 지원 과정을 거쳐야 했어요. 마침 지원을 한 그 때 Lauren이 대학에서 연구기금 공모전에 지원을 준비하고 있었는데,마침 제 프로포절이 공모전에 딱 잘 맞았어요. 그래서 Lauren이 제 프로포절로 연구기금 공모전을 내봐도 좋겠냐고 물어왔고, 저는 흔쾌히 승락했죠. 이 프로포절로 저희는 기금을 받았고, 멘토 Xin도 찾았어요. 이 모든 게 2018년도 한 해 안에 일어난 일이었죠. 어떻게 하다 보니 다 잘 셋업하고 무사히 진행할 수 있었네요.

A: 이 경험을 상세하게 들려주셔서 감사합니다. 공모전에서 지원하는 많은 분들은 과정보다도 결과를 먼저 접하다 보니, 선정 과정이 순차적으로 딱딱 진행해서 잘려나가는 것이라고 생각하기 쉽거든요.

K: 저희 repo에 pull을 하시려는 분들, 특히 기술 문서 번역을 pull 하시려는 분들께 가끔 설명해드리려 하곤 해요. 전체 기술 문서 번역 작업은 꽤 오랜 기간이 걸리는 프로세스에요. 지금 있는 번역들도 펠로우쉽이나 Google Summer of Code 프로그램을 통한 기금으로 만들어졌습니다. 번역 프로젝트는 장기간에 걸쳐 진행되기 때문에 최대한 기여자분들께 기금을 지급하려 하고 있습니다.

A: 번역 작업뿐만 아니라 번역을 위한 프레임워크도 셋업해 주셨죠. 예를 들어 용어 사전(glossary)과 같이 개별 언어를 넘어 보편적으로 사용할 수 있는 포맷을 제시해 주셨죠. 여기에 더해 번역 작업 진행이 어느 정도인지 트랙(track=추적)할 수 있는 시스템을 고민 중이신 것도 언급해 주셨고, 기술 문서를 데이터에 입각해 렌더링하는 시스템을 새로 디자인하는 이야기도 해주셨습니다. 이는 모두 아직 진행 중인 프로젝트로 알고 있습니다.

p5js에 새 프로젝트나 아이디어를 제안할 때, 여태까지 시도되지 않은 완전히 참신한 아이디어를 제시해야 할까요? p5js 프로젝트가 협력적이고, 분산된 프로젝트이다 보니 때때로 Github repo를 살펴보는 것만으로는 각 서브 프로젝트의 상세한 진행 상황을 그려보기에 부족하다고 느낄 수 있습니다. 관계자들에게 연락을 해 보고, 꼼꼼히 조사해야 현재 진행 상황에 대한 윤곽이 나올 때가 있어요.

Kenneth님께서 생각하시기에는 p5js에 새 아이디어를 어떤 식으로 제시하는 게 가장 좋은 방법일까요?

K: 만약에 내놓으려고 하는 제안이, 자신이 겪고 있는 구체적인 이슈를 다루거나 자신이 사용하는 언어로 라이브러리를 쓰기 편하게 만드는 방향이라면, 상대적으로 설득력을 많이 얻을 것 같아요.

하지만 제안하시려는 새 기능이, ‘이런 기능이 있으면 멋지지 않을까’ 정도의 주장이라면 p5js에서 새 기능 추가에 요구되는 접근성 (accessibility) 증대 요구 조건을 충족하기가 힘들 것 같아요. 하지만 비록 이 요구 조건이 없었다고 가정해도, p5js처럼 커다란 프로젝트에서 모두를 설득해 새로운 기능을 추가하는 것은 언제나 힘든 일이겠지요.

새로 추가되는 기능마다 누군가는 그 기능을 유지하는 노동을 해야 합니다. 만약에 새로 제안된 기능이 라이브러리에서 현재 잘 작동 중인 코드를 바꾸게 될 경우에는, 대신 add-on 라이브러리를 만드는 것을 부탁드리고 있어요. 하지만 반면에 새로 제안된 기능이 작동 중인 코드와 별개의 상황이라면, 그러한 경우에는 당연히 문제없이 제안을 실행해볼 수 있겠죠. 물론 이 경우에도 공식 프로젝트의 일부로 진행을 원하신다면 펠로우쉽과 같은 프로세스를 밟고 진행하셔야 됩니다. (하지만 언제나 예외는 있습니다!)

우리에게 맞는 번역 도구

A: 세계화 프로젝트 이야기로 돌아가 볼까요. 프로젝트 초반에 특별히 논의된 이슈들이 있을까요? 어떤 식으로 논의가 전개되었나요?

K: 세계화 프로젝트는 계속 변화하고, 계속 진화해가는 프로젝트에요. 지금 당장도 제 머릿속에 새로운 생각들과 아이디어들이 들어 있기도 하고요. 세계화 프로젝트의 시작은 제 펠로우쉽으로 시작되긴 했는데, 그때도 있는 글을 문자 그대로 번역만 하는 데 국한되지 않았어요. 그런 번역 작업은 전체 프로젝트의 절반에 불구했죠. 나머지는 번역 결과물을 어떻게 유지해야 지속 가능할까에 대한 고민이었네요.

“지속 가능”에 대한 고민이라는 것은, “지금 내가 이 번역을 마치고 나면, 그 결과물을 계속 관리/유지하는 게 현실적으로 가능한가?”라고 물어보는 거에요. 번역물을 최신 버전으로 유지한다는 것은, 다시 말해서, 번역 코드를 이용하는 경험이 (최신 버전인) 원문 코드를 이용하는 경험과 차이가 없어야 한다는 거에요. 일단 그 점이 있고요. 또 하나는, 이용자뿐만 아니라 개발자의 경험이라는 것도 있잖아요? 혹은, 번역자의 경험이라고 할 수도 있으니: 번역 작업에 종사하는 노동자의 “노동의 질” 또한 어떻게 하면 최대한 윤택하게 만들 수 있을까, 에 대해서도 질문해 보게 돼요.

이 프로젝트를 처음 시작할 때는 git diff 기능을 쓴 가장 기본적인 기능을 갖춘 트랙킹 시스템을 쓰고 있었어요. 일단 번역 파일의 git diff를 구하고 diff들을 새로운 파일에 저장했어요. 그리고는 이 다른 파일들도 변경될 예정이니 체크해보세요, 뭐 대략 그런 기능들을 제공했죠.

이런 논리로 기능을 만들고 있었는데, 꽤 초반에 막혀버리고 말았어요. 왜냐하면 웹사이트와 기술문서가 완전히 다른 방식으로 번역되고 있었거든요. 파일 포맷도 완전히 달랐고, 렌더링 방식도 완전 달랐기에, 서로 호환이 이루어지지 않았어요. 저희 프로젝트 스케일에서는 이 둘을 동시에 관리하기 너무 힘들었기에 다시 생각해봐야 했어요. 결국 이 툴 개발은 그에 앞서 이것 저것 맞춰야 할 것들이 너무 많아서 꽤 오랫동안 중단해야만 했어요. 기술 문서들이 렌더링 되는 방식도 바꾸고, 동시에 웹 사이트가 렌더링되는 법도 손보고, 애초에 이게 기술적으로 가능한 일인지 알아봐야 했고요.

생각해보니 이건 너무 큰일인 거예요. 그래서 도무지 손이 가질 않더군요. 결국 작년까지 질질 끌어버리고 말았어요. 그러다가 제가 석사 과정(Master of Research)을 시작하면서 드디어 시간이 생겨서 GUI(그래픽 유저 인터페이스)에 포커스하는 새 아이디어를 낼 수 있었어요.

한두 해 전 Mozilla Pontoon을 만날 기회가 있었는데, 이렇게 이미 존재하는 툴을 쓰는 게 우리 프로젝트에 좋지 않을까 생각이 들었어요. 그래서 한번 해보기로 결정한 후 조사해보고, 구현해보고. 어떻게 작동하나 지켜봤어요.

결과적으로 Pontoon은 대부분 괜찮게 돌아가긴 했는데요, 사실 아직도 p5js에 구현하는 건 주저하고 있어요. 왜냐면 Pontoon 인스턴스로 배포(deploy)하는 게 엄청난 작업이거든요. 그리고 이 인스턴스 자체가 로컬 인스턴스 전체를 써서 무겁게 돌아가고, 데이터베이스를 새로 따로 셋업해야 하는 상황이 만들어져요. 그리고 무료 인스턴스로는 용량이 충분하지 않기 때문에 유료 인스턴스를 써야겠죠. 이는 여러 모로 이상적이지 않은 해결법이에요. 현재로는 상용 서비스들이 더 좋은 옵션이 될 수 있을지 한번 고려해보고 있는데요, 이런 상용 서비스들이 오픈 소스 프로젝트들에게는 무료로 서비스를 지원하는 경우가 있기 때문입니다.

그래서 현재 계속 고민해보는 상태고요. 이런 의미로 번역 툴을 개발하는 프로젝트는 계속해서 바뀌고, 계속해서 진화하는 것이 되었다고 생각해요.

A: Pontoon에 대해 더 설명해 주실 수 있을까요? 본래 어떤 맥락에서 개발된 툴인가요?

K: Firefox로 유명한 Mozilla가 Pontoon 자신들의 세계화 혹은 지역화 니즈를 위해서 디자인하고 개발했어요. Firefox와 관련 결과물들의 모든 번역 프로세스들이 Pontoon을 통해서 제공되고 있죠. Pontoon전에는 Pootle이라는 Translate House가 개발한 또 다른 시스템이 있었는데요, 2000년대 초 혹은 90년대 말쯤 개발이 중단되었어요. 브라우저 기반 인터페이스로 번역을 관리하는 아이디어를 굉장히 초기에 제시한 프로젝트였는데, Pontoon이 여러모로 Pootle에서 아이디어를 얻어 만들어진 것 같아요.

Pontoon를 적용하는 데 한계가 느껴지는 이유 중 하나는, 본래는 UI (i.e., Firefox) 번역을 위해 만들어진 툴이지만 우리는 기술문서에 적용해보려고 하는 등, 더 범용적인 목적에 쓰려고 했기 때문이에요. 계속해서 문제점이 발생했죠.요. 일단 이 툴은 문서와 같은 긴 글을 번역하는 용도를 위해 디자인된 툴이 아니에요. 그리고 많은 수의 스트링(string)을 다루기 위해 디자인된 것도 아닌데, 라이브러리 프로젝트에서는 많은 수의 스트링들을 다룰 수 밖에 없습니다. 이런 맥락에서 Pontoon의 한계점들이 보이는데, 처음부터 본래 용도 외 다른 용도를 고려해 디자인된 게 아니니 이해는 가요. 어떤 부분은 쉽게 적용되겠지만 나머지 부분은, 우리 입장에선, 고생 좀 해야겠죠.

A: Pontoon의 이런 한계가 사용성 (usability) 디자인 이슈에서 기인한 일까요 아니면 단순히 필요한 기술이 부재하는데서 오는 걸까요?

K: 둘 다라고 생각해요. 일단 확실히 UX 문제점들이 있어요, 예를 들어: 인터페이스가 상대적으로 짧은 길이의 텍스트만을 고려하고 있는 점. Pontoon은 영어 단어의 경우 최대 20단어 정도만 받아줘요. 만약에 스트링 데이터가 그것보다 길어지면 인터페이스도 혼돈의 도가니가 되는데요, 스트링 데이터를 임의로 끊어버리고 일부만 보여주거나 억지로 한번에 보여주려고 하기 때문에 엉망진창이 됩니다.

이런 점이 디자인 이슈라면, 더해서 기술적인 한계도 있는데요. 바로 번역 간 관계를 나타내는 데 쓰이는 디폴트 포맷이 상당히 제한적입니다. 통상 번역 작업을 하면 JSON 파일 포맷을 쓰는데요, 이 경우 JSON파일이 제공하는, 키(key)와 값(value)을 담는 계층적 구조(nested structure)들을 쓸 수 있습니다. Pontoon의 번역 파일은 이런 것들을 하나도 지원하지 않아요. 계층적 구조 같은 것도 없습니다. 키-값을 짝지어주는 기능(key-value pairing)이 있지만, 키 부분에 들어갈수 있는 내용이 상당히 제한적이에요. 알파벳이거나 숫자(alphanumeric)여야만 하고, 특수 문자도 쓸 수 없습니다... 그래서 여러 경우에 이 제한을 우회하는 방법을 찾아야 하는 불편함이 있어요.

그리고 워크플로우도 좀 제한적이에요. Mozilla가 Pontoon을 사용하는 철학이, 데이터베이스 시스템이 아니라 번역 파일 (transaltion files) 위주로 짜여져 있거든요. 그래서 그 파일들이 정보들을 다 가지고 있는 거예요. 이게 문제가 될 수 있는데, 작업하시는 분들 중 그 누구도 이 파일들에 대해 상세하게 걱정할 필요가 없었으면 해요. 이 파일들을 직접 만질 이유가 없으면 좋겠어요. 번역을 하기 위해서 이런 세부적인 것들을 걱정할 필요가 없다면 더 좋겠죠.

그래서 제가 꿈꾸는 기능은, 예를 들어 “예전 버전 스트링 (outdated string) 기능” 같은 게 있어요. 만약에 어떤 스트링이 원본 언어에서 바뀌었다고 생각해봐요. 이걸 “구버전"으로 마크해 두면 번역가분들이 이 부분을 따로 모아 검토해 보시면서 이 부분은 패스, 또는 이 부분은 바뀐 내용에 맞춰서 조금 고쳐봐야겠네, 하실 수 있겠죠.

이런 기능은 Pontoon의 구조를 통해서는 구현할 수가 없어요. 왜냐하면 Pontoon에서는 원본 파일을 오리지널로 보존하기 때문에 만약에 무언가를 업데이트 하려면, 파일 안에 있는 키(key)와 그에 상응하는 태그(tag)를 업데이트하지, 직접적으로 파일에 들어있는 값(value)을 업데이트하지 않아요. 보통 UI가 작동하는 형태에 맞춘 방법이죠. 만약에 어떤 UI에서 한 스트링이 바뀐 새 버전이 나와 버리면, 지금 작업하고 있는 버전을 따로 핀(pin)해두어야만 해요. 그 다음에 새 버전을 빌드할 때는, 이전에 작업하던 다른 버전이 아닌 이 새 버전 내부를 보게 되겠죠. 현재 쓰고 있는 소스 코드만 바꿀 수 있는 거예요.

하지만 저는 p5js 기여자분들이 이런 버전들이나 소스 코드 파일들에 대해 고민할 필요가 없었으면 좋겠어요. 자동으로 이런 파일들을 만들어버리면, 랜덤한 키가 배정되고.. 이 부분은 정말 어떻게 우회할 수 있을지 아직 잘 모르겠어요. 이미 존재하는 툴을 가져다 쓰게 되면, 우리에 맞는 해법이나 우회법이 있을 거라고 기대할 수 없어요.

A: 다른 옵션이나, 혹은 직접 새로운 툴을 개발하시는 것도 생각해보신거죠?

K: 아주 잠깐 상업 서비스들을 찾아봤었어요. iOS 앱이라면 POEditor와 Transifex가 널리 쓰이는 것 같더군요.

하지만 보다보니, 상업 서비스들도 Pontoon과 별로 크게 다를게 없었어요. Pontoon이 상업 서비스들보다 어떤 면으로는 더 많은 기능들을 제공하는 것 같아요. 하지만 상업 서비스들을 이용하는 것의 가장 큰 장점은 배포(deployment)에 대해서나 서버에 대해서 우리가 고민할 게 별로 없다는 거죠.

다른 고민할 점은 커스토마이제이션 (customization)과 같은 기능이 있겠고요. 그러고보니 Yukie Nomiya님이 웹사이트 번역 작업을 위해 트래킹을 작업해주셨었어요.⊕Yukie Nomiya의 Google Summer of Code 프로젝트에 대해서는 i18n Improvements and Italian translation에서 찾아보실 수 있습니다. Google Summer of Code 프로젝트의 일환으로 작업해 주셨지요. Pontoon이 해주는 프로세스들을 p5js 내부에서 처리하게끔 구현하는 아주 흥미롭고 좋은 프로젝트였습니다. 이런 식으로 맨 처음 시작부터 끝까지 우리가 시스템을 만들면 우리 목적에 딱 맞게 시스템을 짤 수 있다는 점이 좋습니다.

오픈소스 기여자 경험의 질

A: 폭 넓은 의미로, 세계화에 얽힌 이슈들에는 어떤 것들이 있을까요?

K: 많은 분들이 세계화(internationalization) 작업이라고 하면, 이걸 번역했으니 끝이다- 이런 식으로 생각하시기 쉬운 것 같아요. 하지만 많은 경우에 오픈소스 소프트웨어에서 세계화 작업이라는 게 여기서 끝나지 않습니다. 위에서 이야기했듯, UI를 번역하는 경우처럼 완성된 소프트웨어의 일부를 변경하고, 마무리 지은 후, 쉽(ship)해버리는 것으로 생각하기 쉬워요. 하지만 이 경우는, 예를 들어, 현재 개발 진행 중인 프로젝트의 기술 문서를 번역하는 경우와 같을 수 없습니다. 기술 문서의 정보가 틀려서 수정하거나 내용이 누락된 것을 발견할 수도 있으니 중간에 업데이트 과정이 계속 있을 거예요.

p5js 프로젝트의 경우 업데이트 주기가 앞서 이야기한 UI 경우보다 훨씬 자주 일어나요. 그리고 “제대로 된 정보를 원한다면 영어로 된 기술 문서를 봐라. XX언어로 된 문서는 틀렸다”와 같은 경우를 정말 피하고 싶기 때문에 번역을 최대한 최신 버전에 맞춰 유지해 두어야 하죠. 비영어권 언어로 쓰여진 기술문서가 도태되게 내버려두는 것은 딱잘라 말해 옳지 않습니다. 영어를 쓰지 않는다는 이유로 누군가가 기준 이하의 경험을 하게 두어서는 안됩니다.

또 다른 부분으로 UX(사용자 경험, user experience)를 생각해보지 않을 수 없어요. 다양한 지점들이 있어요. 기술문서의 UX, 번역의 UX, 그리고 기여자들의 UX까지 생각해야 하죠.

엔드 유저(end-user)들의 입장에선, 번역문을 어떤 식으로 열람할지, 그리고 자신들이 필요한 정보를 찾기까지 얼마나 많은 클릭 수가 필요할지, 같은 부분이 중요하겠죠. 만약에 영어로 된 페이지에 당도했다면, 최소한의 클릭만으로 자신이 사용하는 언어로 전환할 수 있는가, 같은 점들을요.

그리고 번역문의 질 또한 빼놓을 수 없어요. 제가 중국어 번역을 작업하는 동안 노력을 기울였던 부분 중 하나가, 영어 문서를 번역한 느낌이 아니라 처음부터 중국어로 쓰여진 글의 느낌을 주고 싶었어요. 이렇게 하려다 보니, 같은 뜻을 전하기 위해 문장을 아예 새로 써야 하는 경우가 많았어요. 때때로 아예 원문 문장 구조를 잊어버리고 진행하려고 노력하거나, 혹은 자연스러운 문맥을 위해 문단 전체를 완전히 다 갈아엎었던 경우도 있었죠.

번역자의 UX를 논한다면, 일단 번역자분들이 구체적으로 어떤 방식으로 번역 작업을 하시게 될지 생각해봐야 해요. 이걸 고려하다 보니, 제 경우에는, 번역 프로세스에 git을 사용하는 횟수를 최대한 줄이는 방법을 계속 생각하게 되어요. 번역가분들이 꼭 git을 사용하는 법을 아셔야 할까? 오픈소스 소프트웨어에 기여하기 위해 반드시 개발자가 될 필요는 없잖아요.

하지만 현재 상황으로는, 최소한 repo에서 pull을 할 줄 알아야 하고, 웹사이트에 대한 구조도 대략적으로라도 알아야 하죠. 입력한 글이 어디에 나타나게 되는지도 알아내야 하고요. 거기에더해, 로컬에서 라이브러리를 빌드해서 오류는 없는지, 렌더된 페이지가 마지막에 어떻게 보이는지도 체크 할줄 알아야해요. 여기가 끝이 아니죠. 여기에 공식 repo를 fork해서 자신의 fork에서 Pull Request를 넣고.. 이 모든 과정을 아셔야하는거에요. 이게 다 준비단계에 불과한 거예요. 웹사이트 전체를 번역을 하든, 한 문장을 수정하든 간에, 기여 스케일에 관계없이 모두가 거쳐야 하는 과정이죠. 저희가 번역가분들께서 기여해주셨으면 하는 부분은 그런 부분이 아니니, 이런 준비단계들을 어떻게든 최소화하고 싶어요.

그리고 아까도 말씀드렸지만 번역자분들의 “노동의 질”도 생각해봐야 하죠. 제 연구를 진행하다가 알게 된 것인데요, 사람들이 기계 번역툴을 사용할 때 탭을 바꾸는 과정을 줄여줄수록 좋은 결과가 나왔대요. 예를 들어, 새 탭을 열고, 번역툴 웹사이트에 가서, 뭔가를 타이핑하고, 아웃풋을 확인한 다음에, 다시 원문이 있는 탭이나 창으로 찾아 가고. 이런 중간 프로세스들을 없앨수록 번역 작업 노동의 질이 크게 향상되었다고 해요.

A: 그리고 전에 개발자들의 “노동의 질”에 대해서도 언급해 주셨죠?

K: 맞아요, 개발자분들을 위해서는 전체 프로세스가 복잡하지 않고 단도직입적이 될 수 있게 노력하고 있어요. 자신의 코드가 제대로 번역이 될지 아닐지 걱정하시는 일이 없도록 해드린다는 이야기죠. 혹은 자신의 코드가 번역 시스템으로 들어가는 건지 아닌지, 이런 걱정도요. 이런 걱정에 들어가는 인지부하(cognitive load)나 실수가 발생할 수 있는 상황을 최소화하면 좋겠죠. 하지만 디자인 태스크는 잘하기가 참 힘들어요.

A: 현재 웹사이트의 경우, 번역 텍스트들을 코드와 따로 분리해두었고요, 따로 repo도 만들어 두셨죠. p5js의 어떤 컴포넌트들의 경우, 예를 들어, Friendly Error System (FES)과는 다르게요. FES 또한 패키지화해서 따로 분리될 수 있을 것 같아요. 하지만 번역과 코드가 더 이상 얽혀 있지(entangled)않다면 , 그런 부분에도 장단점이 있겠죠? 기여자분들은 정말 다양한 배경에서 오시는데, 아마 참여 계기나 무엇을 얻고 가고 싶은지 우선 사항(priority)도 다 다르실 거예요.

예를 들어 p5js를 영어가 아닌 다른 언어로 가르치고 싶으신 분들과, 장기적으로 미래에 개발자 커뮤니티의 일원이 되고 싶어 p5js 프로젝트에 오신 분들의 계기나 우선 사항은 다를 거예요. 어느 경우에는, 라이브러리의 모든 부분들을 한 곳에 모아서 보고 싶어하실 수도 있으니까요. 코드의 스케일에 따라 디자인 전략이 달라지려나요?

K: 제 생각에는, 스케일을 떠나서 생각해본다면, 다 연결된 하나의 문제인 것 같아요. 한편으론, 제 이상 속에서는, 오리지널 텍스트와 번역 텍스트가 한 덩어리처럼 차이가 없었으면 한단 말이에요.

기여자분들 우리 모두 파일 목록들 속, 스트링 목록 속, 어딘가에서 작업하고 있을 텐데요, 구조가 어떻게 되어있든 결국에는 모든 스트링들이 하나의 거대 코드 덩어리에서 불려나오는 거죠. 소스 코드를 보시면 이 구조라는게 복잡도를 높이기도 해요: 템플릿 이름들이 한 무더기, 변수 이름이 한 무더기, 거기에다가 우리 스트링들도 한 무더기 있고. 복잡도가 올라갈수록 모든게 좀 더 불투명하게 되겠죠.

그 안에서 균형점을 찾아가는 게 되겠죠. 누구나 선뜻 아무 코드나 열어서 마구 실험해(hack)보실 수 있는, 그런 기회를 주는 디자인을 유지할 수 있는 균형점을 찾으면 좋겠죠. 실험해보시면서 뭘 망가트리는 것에 대해 걱정을 많이 안하셨으면 좋겠어요.

언어를 옮기며 마주친 고민들

A: 중국어로 웹페이지 번역 작업을 하셨을때 기술 용어 리스트를 만드셨었잖아요. 저희도 한국어로 FES를 옮기면서 기술 용어들을 번역하고 있는데, 이게 상당히 어려운 작업이더군요. 한국어는 특히 외래어를 번역하는 방식이 많아서 더 혼란스러워요. 소리나는 대로 적을 수도 있고 (음차 표기) 혹은 순수 우리말나 한자 단어로 뜻을 풀어 옮기기도 (자국어 번역) 해요. 심지어 한문으로 옮길때도 일본식 한자 단어를 참조할지, 아니면 중국식 한자 단어를 참조할지, 아니면 다른 새로운 방식을 고안해야 하나, 그런 고민까지 해보게 되더군요.

이런 배경에서, 영어 기술 용어를 중국어로 번역하신 경험에 대해 더 듣고 싶습니다.

K: 영어 기술 용어들을 번역할 때, 리스트를 만들며 하나 일정한 프로세스를 썼었어요. 그렇게 한 가장 큰 이유는 번역에 일관성을 주어, 사용자분들께 혼란을 줄 수 있는 상황을 최소화하려고 했어요.

목록을 만든 과정은, 각각의 스트링들을 작업하고 있다가 기술 용어를 만나게 되는데요. 프로그래밍 언어 전문 언어일 수도 있고요, 수학 전문 용어가 나오기도 했어요. 이런 기술 용어들을 만나면 선뜻 번역하기 쉽지 않더군요.

이럴 때 저는 일단 검색의 도움을 받긴 했는데, 그냥 번역툴을 쓴 게 아니라 분야-특정 자료들을 찾으려고 노력했어요. 흔히 쓰는 번역툴들이 (Google Translation 등) 아직 특정 분야에 맞춰 트레이닝 된게 아니라서 결과가 좋지 않더군요. 이렇게 검색을 하다가, 특히 중국어로 된 기술 포럼이라거나 MDN (Mozilla Developer Network), React, 혹은 Vue.js의 기술 문서와 같은 이미 중국어로 번역된 웹사이트들을 찾아보게 되었어요. 비슷한 맥락에서 작업된 중국어 번역들을 비교하며, 어떤 단어를 쓰고 있나? A 표현 아니면 B 표현을 썼나? 아니면 혼용해서 혼란이 있나? 이런 질문들을 던졌습니다. 최종 목표는 대다수가 합의하는 번역 단어가 먼저 있는지 찾아보는거였어요. 이 컨셉을 지시하기 위해 가장 흔히 쓰이는 단어가 뭘까 찾아본 거죠.

A: 좀 더 고민되는 상황을 이야기해볼까요? p5js를 한국 프로그래머들이 통상적으로 소통하는 방식을 기준삼아 기술 용어들을 번역했다고 칩시다. 그렇게 번역한 기술 문서나 에러 메시지를 사용해 다른 리소스를 찾으려고 하면 아무래도 제한된 결과들만을 접하게 되는 상황이 발생합니다. 왜냐하면 대부분의 리소스들은 아직 영어로 존재하니까요. 이 문제를 해결하기 위해, 혹자는 아예 영어 기술 용어 번역을 금지하거나 아니면 번역 단어를 동시에 표기하는 것을 추천하기도 해요.

K: 저도 그렇게 표기하는 경우를 공식 번역에서 본 적 있어요. 보통 “시작하기(Getting Started)”라든가 튜토리얼 페이지에서 그런식으로 표기하죠. 하지만 그 후에 이 용어가 나오면 그 때는 원문을 보여주지 않아요. 에세이를 쓸 때와 비슷한 방식이라고 생각합니다. 생소한 용어를 처음 시작할때 상세히 표기해주고, 그 후로는 사람들이 그 용어를 알고 있다고 상정하는거죠. 한가지 방법이 될 수 있겠네요.

제 경우에는, 제가 맨 처음 프로그래밍을 배울 때의 기억을 더듬어 보고, 그때의 경험을 기준으로 삼아 보곤 해요. 그 때 저는 진짜로 학교 사서 선생님을 찾아가서 프로그래밍 책들을 빌려왔었거든요. 그런데 책을 보니까 똑같은 문제가 있는 거예요: 책마다 용어가 다 다른 거예요! 모르고 읽고 있다가, 어느 순간 머리 속에서 연결되더군요: “아하, 이게 사실 다 같은 영어 단어였구나!”

A: 각기 다른 레퍼런스 사이 용어 통일을 해주는 리스트가 있으면 도움이 될까요?

K: 중국어의 경우에는, 다른 표준 자형들, 정체(traditional Chinese)와 간체(simplified Chinese)가 나뉘어져있고, 거기에 더해 지정학적인 이유들로 문화권마다 완전히 다른 용어로 번역을 하곤 해요. 같은 언어라고 해도 하나의 번역이 간체에서는 허용되는 반면 정체에서는 허용되지 않기도 해요. 게다가 번역가들마다 번역들이 또 제각각이기도 하죠.

A: 그럼 정치적 혹은 문화적인 이유들로 이들 중 한 버전이 채택될 것이고, 해당 언어문화권 커뮤니티 사람들이 해당 버전을 유지하는 방식이 되겠군요. 어쩌면 어떤 커뮤니티가 해당 번역/언어에 좋은 관리자 (maintainer)가 될 수 있을지 고민하는 게 좋은 방향일지도 모르겠네요.

K: 번역자나 번역 관리자라면 번역하는 언어 문화권의 감수성을 지니고 있어야 한다고 생각해요. 저희 기술 문서를 보시는 분들 중에는 영미권 배경이 아니신 분들도 많아요. 이런 배경의 관점도 이해하며 번역 작업이 진행되어야 겠죠.

A: 번역 작업 중에서 되도록 중국어로 읽히기 가장 자연스러운 표현을 찾으신다고 하셨어요. 한국에서 쓰는 표현 중 “번역체”라는 게 있는데요. 어떤 분들은 이런 번역체 글이 비록 올바로 쓰인 한국어가 아니긴하지만, 이국적인 문체가 주는 특유의 느낌을 즐기시기도 해요.

혹시 중국어에서도 비슷한 일들이 일어나나요? 그리고 중국어와 영어 언어 차이에서 일어나는 문제들은 없었나요?

K: 대부분의 경우, 문장 구조의 차이에요. 어떤 식으로 문장 구를 나누고, 어떤 순서로 표현되는지.

하지만, 어쩌면 가장 확연한 예는 구두법(punctuation), 문장 부호 같아요. 중국어에서는 문장의 끝이 ‘.’(period)가 아니에요. 문장의 끝을 알리는 건 작은 동그라미 (고리점) ‘。’에요. 나머지 문장 부호들도, 예를 들어 콤마 라든가, 영문 문장 부호들과 비슷하게 생기긴 했는데 활자 너비가 달라요. 그래서 중국어 활자는 문장부호가 붙든 (punctuation-corrected) 붙지 않든 간에, 일관적으로 정사각형 형태를 띄어요.

그래서 어떤 문제가 생기냐면요, 개발자가 페이지를 생성하려고 하는데 마침표를 영문식으로 하드코드(hard-code)하려고 하는거에요. 이런 일들이 생각보다 꽤 자주 일어납니다.

템플릿(template)의 경우 이런 일이 있었어요. 여름에 프로젝트가 돌아가는 동안 특정 이름들, 예를 들어 링크 같은 것들은 번역하지 않았어요. 가을에도 번역 파일로 옮겨지지 않았는데, 이 링크들이 하드코드되어 버린 거예요. 문장 끝이 링크로 끝난 경우, 이 링크들에 마침표가 붙어버렸죠. 이 경우 문장 부호가 올바르게 적힌 것도 아닐 뿐만 아니라 주어-동사-목적어의 순서가 언어마다 다르니까 중국어를 포함해서 다른 언어들에서도 문제가 생겨버렸어요.

특정 아이템을 특정 부분에 하드코드 (hard-code)해두면 이렇게 문제가 생깁니다. 문장 구조가 고정되어서 바꿀수가 없으니까요. 이런 것들도 흔히 겪을 수 있는 어려움 중 하나겠네요.

A: 이런 이슈들을 다루는 내부 가이드라인이 존재하나요?

K: 네. 기여자들을 위한 문서(contributor docs)에 작업 방법들과 템플렛을 쓸 때 유의할 점들을 써뒀어요. 예를 들어, 문장부호를 하드코드하지 마시고, 만약에 작업 중인 언어에서 특정 스트링을 비어두기로 정했어도 (문장 구조 고정을 피하기 위해서)하드코드된 파트 앞으로 이 스트링들을 가져와야해요. 아까 이야기한 내용과 같은 이야기로, 개발자들이 알아두어야 할 사항들이죠.

A: 어쩌면 한국어에 국한된 이야기일지도 모르겠습니다만, 어떻게 하면 번역문의 톤이 포용성(inclusivity)을 담을 수 있을지 많이 고민하게 되더군요. 초대하는 느낌과 존중하는 느낌을 담은 한국어의 어미를 고르는 것도 조심스러운 작업이었습니다. 어떤 선택을 하느냐에 따라 사용자와 소프트웨어 간의 사이가 미묘하게 조정되는 상황이었어요.

K: 저도 중국어 번역 작업을 하면서 힘들었던 것 중 하나가 중국어의 톤이 영어 원문과 아주 달랐다는 거예요. 제 경우, 같은 내용을 담은 글이라도 중국어로 읽을 때와 영어로 읽을 때 다른 감각, 다른 감수성을 느낄 수 있거든요.

아마 어떤 특정 톤을 선택하느냐, 그리고 번역이 얼마나 유창하냐에 따라, 번역문이 아닌 본래부터 중국어로 쓰인 느낌이 들겠죠. 글의 톤이 올바른지 점검할 때 세심하게 체크해야 할 것들이 있는데, 예를 들면 인칭대명사 이슈가 있겠네요. 이 인칭대명사는 흔히 말하는 성별 인칭대명사 (gender pronouns)이야기는 아니에요. 왜냐하면 중국어에서는 인칭대명사에서 성별을 완전히 생략하는게 가능하거든요. 하지만 “you"라는 인칭대명사는 중국어에서 여러 레벨로 나뉠 수 있어요: 격식체와 비격식체 등으로요. 그럼 언제 어떤 버전을 써야 할까요? 제가 처음에 번역 작업을 할 때는, 최대한 격식체를 쓰고 모두 통일해보려고 했어요. 하지만 그렇게 번역을 하고 보니 텍스트가 너무 격식을 차린 것처럼 느껴지는거에요. 그래서 좀 더 캐주얼한 톤을 써보려고 비격식체를 섞어 보았는데, 생각해보니 실은 같은 단어가 그저 다르게 읽히고 있는 거죠. 어찌되든 같은 뜻을 전하는 거니까요.

새로운 만남들을 기다리며

A: 자, 분위기를 바꿔서 좀 다른 질문을 해볼까요? p5js를 잘 대표하는 성격 혹은 목소리를 상상해주세요.

K: p5js의 느낌이라면, 너무 격식을 차리거나(formal) 테크니컬(technical)한 느낌은 아니에요. 수퍼-프로페셔널(super-professional)하게 보이려고 노력하지 않고요. 오히려 엉망진창, 허당(mess)인 모습을 그대로 보여주는 걸 지향하는 것 같은데요? 전 우리 프로젝트가 엉망진창인 걸 인정하긴 하는데, 그런데, 잘 돌아가고 있잖아요?! 정말 누구나 들어와서 더 좋은 코드를 만드려 같이 노력할 수 있는 그런 분위기고요. 하지만 우리 프로젝트를 예컨대 자바스크립트 전문가들에게 보여주면, “왜 이 기능을 쓰지 않죠?” or “왜 그런 식으로 코드를 짰죠?” “왜 어쩌구 저쩌구?” 이런 반응이 나오겠지만요. 하지만 아시잖아요. 이 방식이 우리가 지향하는 목표를 위해서는 꽤 잘 맞게 작동하고 있죠. 그리고 이런 태도가 바로 p5js의 목소리고, 개성이라고 생각해요.

그리고 이런 특이한 태도를 다른 언어나 문화권으로 잘 번역해내는 작업은 쉽지 않은 일이 될거에요. 이런 경우에는 실제로 저희 소프트웨어를 쓰실 분들이 직접 참여하실 수 있게 하는게 최선이라고 생각해요. 일단 쓰시고, 참여하시게 기회들을 열어두는거죠.

A: 계속 변화하는 프로젝트니, 새로운 분들과 대화하고 새로운 분들이 참여하시다 보면, 새로운 방향도 보이고 새로운 아이디어들과 컨셉들도 생기겠죠.

K: 제가 학위를 마친 지 얼마 안되어서 연구 프로세스안에서 계속 생각하게 되네요. 예컨대, 포커스 그룹(focus group)같은 게 있을 수 있겠죠. 그리고 너무 자유로운 질문들보다는 더 구체적인 질문들을 떠올려 볼 수도 있겠고요. 저는 이런 방식으로 이야기하지만, 각자 이루고 싶은 일에 따라 더 도움이 되는 또 다른 옵션들이 있을거에요. 제가 이야기하는 것은 여러 방법 중 하나일 뿐이니까요.

A: 마지막 질문을 드리면서 이 인터뷰를 마무리지으려 합니다. 앞으로는 p5js에 어떤 참여나 기여가 일어나는 걸 보고 싶으신가요?

K: 제가 이 질문에 뭐라고 미리 규정해두고 싶은 건 없는 것 같아요. 하지만 동시에, 제 경우 딱히 새로운 아이디어를 찾고 있는 건 아니라고 말해 두고 싶어요. 위에서 이야기했듯, 너무 새로운 아이디어는 받아들여지기 힘든 게 현실이에요. 더 구체적인 조언이라면, 기여를 하고 싶다는 마음이 있으시면, 그리고 ‘오픈소스 소프트웨어에 기여한다는 게 어떤 걸까’ 고민하고 탐구하는 자세가 있다면 ,벌써 시작하는 지점으로 충분하다고 생각해요.

그리고 저희가 오픈소스 소프트웨어 기여라고 말할 때는, 꼭 코드를 써서 기여하는 것만 이야기하는 게 아니에요. 심지어 Github을 전혀 쓰지 않아도 돼요. 만약에 세계화나 지역화 기여를 생각하고 계시다면, 이미 있는 번역의 오류를 찾아 고치거나 더 읽기 좋게 편집해주시는 작업도 좋아요. 만약에 쓰시는 언어가 아직 번역되지 않았다면, Processing Foundation Fellowship 이나 Google Summer of Code 오픈콜에 프로포절을 꼭 내주세요. 혹은 이런 프로세스를 거치고 싶지 않으시다면, 서드파티(3rd-party) 번역도 환영해요.

그리고 서드파티 번역의 장점은 작업에 잘 집중할 수 있게끔 단순하다는 거예요. 저희가 링크를 걸 수 있는 번역은 있는데, 누가 관리할 의무가 있는가,와 같이 관리법에 대해 복잡한 부분들이 많이 없어져서 저희도 좋아요. 만약에 장기 관리자가 되시길 희망하시는 분이시라면, 이미 있는 번역들을 보시면서 시작하시는 것을 추천해요. 번역 프로젝트가 거대해서, 일정 부분만 작업하기를 희망하실 수도 있어요. 그리고 번역문 말고도 주변에 할 작업들이 아주 많습니다: 트래킹 시스템 (tracking system), 유저 인터페이스 (user interface), UX 디자인(user experience), 그리고 이 모든 부분들이 어떻게 돌아가는지에 대해 문서화하는 것 까지, 중요한 과제들이 많이 남아있답니다.

-끝-