기술 용어 다루기
전유진
기술 용어를 번역하기 전 선행되어야 하는 중요한 과정이 있습니다. 바로 외래어인 용어를 음차로 표기할지, 자국어로 뜻을 번역할지 판단하는 것이죠. 번역자는 두 갈래 선택의 기로에서 쉽지 않은 결정을 내려야 합니다. 이 어려움을 단순화하고, 전체적인 통일감을 우선해 둘 중 하나로 규칙을 정해볼 수도 있겠지요. 하지만 본 가이드라인에서는 성급히 둘 중 하나로 규칙을 정하기보다는, 음차 표기와 자국어 번역이 각각 필요한 상황에 관해 언급하고자 합니다.
음차 표기-정확한 이해를 돕는 도구
첫 번째로 음차 표기가 필요한 경우는 그 외래어가 이미 빈번하게 사용되어 전달력을 충분히 가지게 될 때입니다. 특히 대체할 자국어가 마땅치 않을 때에 더욱 효과적이겠죠. 예를 들어, FES에도 들어가 있는 ‘system’이란 표현을 생각해봅시다. 사전에서 system은 ‘제도', ‘장치', ‘체계' 등으로 해석됩니다. 틀린 해석이 전혀 아님에도 어쩐지 원래 표현하고자 하는 의미보다도 훨씬 거창하고 딱딱한 느낌을 줍니다. 아무래도 한자로 조합된 단어여서일까요? 그리고 system은 음차 표기로 자주 활용되고 있어서 그 자체로 이미 강한 전달력을 갖기도 합니다. ‘시스템'이라는 음차 표기를 선택하는 것이 정답이라기보다는 번역의 과정에서 두 다른 언어가 얼마나 섞이고 있는지, 다소 혼란스럽지만 현재 진행 중인 변화의 흐름을 읽어낼 필요가 있다는 것입니다.
그리고 번역의 대상이 기술용어일 때 더 많은 조건을 고려해야 할 수도 있습니다. 그 용어가 해당 문서/프로그램 안에서 얼마나 반복되는지, 고유한 것을 지칭하는 표현인지, 그리고 이 후에 그 용어를 매개로 사용자가 더 심화된 과정으로 나아가게 될 수 있는지 등을 생각해봐야 합니다. 다소 생각해볼 지점이지만, 무조건적인 자국어 번역을 경계해야 할 필요도 있습니다. 극단적인 예시지만 수학, 과학, 공학 등 누군가가 번역을 거친 전공서적이 우리말인데도 더 이해를 하기 어려운 나머지 그 원서를 다시 사서 봐야 하는 웃픈 상황을 상상해볼 수 있겠지요. 실제로 한국에서 기술 관련 전공서적을 보면 한자, 일본어식 표현이 많습니다. 예를 들어 ‘매개변수', ‘전역변수’, ‘재귀함수’ 등의 용어도 한국어이기는 하지만, 순우리말이 아니라 한자로 된 표현이죠. 조금 다른 분야의 예시이지만, ‘집적회로(integrated circuit)’에서 ‘집적'이라는 표현은 한국어 화자에게 잘 와닿지 않습니다. 자국어라고는 해도, 거의 쓰지 않아서 원어보다도 더 낯설게 느껴지는 경우입니다. 번역이라는 것은 원어와의 거리를 좁히는 일인데, ‘불친절한’ 번역은 오히려 독자가 원어의 의미에서 한 단계 멀어지는 결과를 낳게 됩니다.
물리와 전자공학의 영역에서 중요한 개념인 potential energy를 우리나라에서 ‘위치에너지’라고 번역하는 것도 ‘왜곡’은 아니지만, 원문이 담고 있는 핵심을 다 전달하지 못하는 아쉬운 사례 중 하나입니다. 덧붙여 하나의 개념을 지칭하는 표현이 다수로 존재하여 소통에 혼란을 야기하는 경우도 왕왕 있습니다. 많은 학문과 기술이 국외에서 유입되기에 발생하는 문제입니다. 기술 용어 번역의 경우, 청자가 번역이라는 수단을 통해 그 용어가 온 곳으로 다시 접근하기 용이한지를 고려해야 합니다. 번역된 표현을 제시한 환경 내에서는 당장 불편이 없더라도, 이 후 그 환경을 벗어나 추가적인 검색이나 학습을 할 때는, 확실히 원어가 용이합니다. 그리고 해당 번역표현이 일반화된 것인지, 그 번역 문서 내에서만 존재하는지 등에 따라 개별 번역의 질적 차이가 나는 문제로도 논의될 수 있습니다.
음차 표기를 하더라도 단순하게 1:1로 치환되는 형태가 아닐 수 있습니다. 그 용어에 담긴 기술적인 맥락을 어디까지 친절하게 제시할 것인지도 고려해야 합니다. FES를 설명하는 아래의 문장에서 등장하는 ‘디버거’에 관해서도 한번 생각해볼까요? "Welcome! This is your friendly debugger.” ‘디버거(debugger)'라는 단어 하나에도 많은 고찰이 담겨 있습니다. 디버깅(debugging)이라는 FES의 기능을 나타내면서, ‘-er’을 붙여 의인화하는 방식으로 친숙함을 더했습니다. 이 용어를 단순하게 음차 표기해서 ‘디버거'로 바꿔볼 수도 있겠지만 다소 어색함이 느껴집니다. 하지만 디버거라는 번역어는 FES가 하는 일(= 디버깅)을 핵심적으로 전달하고 있습니다. 해서 이 표현은 디버깅으로 형태를 바꾸어 음차 표기를 하고 ‘안내문'이나 ‘알림말' 같은 다른 자국어를 붙이는 식으로 문장을 구성해 볼 수 있습니다. “디버깅을 돕는 친절한 안내문입니다.” 같은 식으로요. 가능하다면 디버깅이 무엇인지 주석으로 짧게 덧붙여볼 수도 있겠지요. 물론 기술적인 맥락을 지나치게 설명하려고 해도 문장이 길어지기 때문에, 적절한 정도를 가늠해야 합니다. 마냥 길게 풀어서 쓰는 것이 쉽게 말한다는 / 친절하게 설명해준다는 것은 아니니까요. 너무 길면 독해의 피로도가 높아지고, 핵심을 파악하는 데 방해가 될 수도 있습니다.
자국어 번역-언어라는 장벽을 낮추는 수단
음차 표기보다 우리말로 의미를 풀어낸 자국어 번역이 더 나은 경우도 당연히 있습니다. 외래어와 그 기술이 국외에서 온 것이라고 해서 무조건 원어를 살리는 것이 맞을까요? 기술 문화에서 ‘오픈 소스'라는 표현을 자주 쓰지만, 여기에 ‘언어'의 장벽은 잘 고려되지 않습니다. ‘오픈 소스'는 분명 존재하지만, 그것에 접근하기 위해서 특정한 언어의 기술이 선행된다는 사실은 쉽게 간과됩니다. 그런 면에서 기술 용어의 번역이란 열린 세계로 진입하기 위한 계단을 쌓는 일이며 그 문턱을 낮추는 일입니다. 반대로 그 과정이 없다면 선행지식이 부족할 수 있는 누군가에게 ‘오픈 소스'는 ‘오픈'된 것이 아니겠지요.
이런 토대를 쌓는 것은 결국 그 기술의 개방성, 접근성과 직결됩니다. 특히 IT 기술, 소위 첨단 기술은 줄곧 앞만 보고 미래만을 향해 발전해온 경향이 있습니다. 이러한 경향에서는 뒤를 돌아보거나, 속도를 낮추거나, 따라오는 누군가를 위해 기다려주는 일이 드물지요. 어떤 기술이 특정 지역에서 새롭게 등장했을 때, 그 지역 외부에서 해당 기술에 접근하기 위해 요구되는 언어의 문제는 줄곧 부차적인 것으로 놓입니다. 그러나 기술의 발전 속도는 너무 빠르고, 기술 용어의 번역은 언제나 ‘(조금 덜 중요한) 나중의 일’이기 때문에, 점점 더 그 간극이 커지고 있습니다. 새로운 기술을 개발하는 것만큼이나, 그 기술을 폭넓게 나누는 개방성 내지 접근성의 고민은 꼭 필요합니다. 구체적으로는 그 기술(플랫폼, 서비스)이 제공하는 언어의 가짓수부터 개방정책, 세계화 전략, 공유방식, 플랫폼의 UX 디자인에 이르기까지 광범위한 사안의 문제입니다.
그 중 언어의 문제는 오픈 소스(open source)라는 문화 내에서 주로 자발적인 형태로, 개인의 기여에 많은 부분 의존해 왔습니다. 스스로에게 필요한 기술을 터득하기 위해, 교육이라는 목적으로, 혹은 더 많은 이들에게 공유하고자 하는 공익적인 의지에 의해 진행되어 온 기술 용어 번역의 여러 과정을 떠올려봅니다. 각각의 시도가 저마다의 가치를 가지고 충분히 큰 역할을 수행했다는 것에는 분명 의심할 여지가 없지만, 기술의 발전 속도를 늘 ‘쫓아가야만’ 하는 입장에 관해서는 생각해볼 필요가 있습니다. 하루하루 급변하는 기술과, 나름의 규칙과 통일성을 고민하면서 접근해야 하는 언어 번역, 그 두 가지 방식의 차이가 지닌 속도의 간극에 대해서 말입니다. 코로나 시대에 우리는 기술의 발전이 늘 진보로 이어지는 것이 아니라는 사실을 깨닫고 있습니다. 기술은 발전하는 만큼, 그로 인한 양날의 검과 같은 숙제를 남깁니다. 인류는 꽤 오랜 기간 그 책임에 대해서 모른 척 해왔고, 지구의 환경 파괴와 같은 자멸적인 결과에 대응해야 하는 상황이 왔지요. 마찬가지로, 이제 어떤 기술이건, 그 기술이 생산하는 효율적 가치에만 몰두할 것이 아니라, 반작용처럼 함께 발생하는 의무와 책임에 대해서도 생각해야 합니다. 많은 이들이 소비하고 활용함으로써 그 경쟁력과 존재가치가 높아지는 IT 기술의 경우에는 더욱 그렇습니다. 언어 번역의 문제는 더욱 많은 노력과 관심을 기울여야 하는 일임에도, 앞서 언급했던 속도의 간극으로 인해 그 해결은 어쩌면 앞으로 더 어려워질지도 모릅니다.이런 생각이 그저 우려로만 그치지 않도록 [5.기계번역/ 사이를 맴도는.] 섹션에서는 번역이 갖는 실천적 의미를 짚어주고 있습니다.
다시 음차 표기에 관한 논의로 돌아가 보죠. FES의 경우에도 지나치게 음차 표기에 의존하 여 구성하면, 코딩에 익숙하지 않거나 시작하는 이들에게는 이해의 단서조차 제공하기 어렵습니다. 번역이 필요한 대상을 고려하는 것은 FES가 제시하는 ‘Friendly’에 대한 고민이기도 합니다. 경계해야 할 극단적인 예시로, 조사만 제외하고 모두 음차 표기로만 구성된 다음과 같은 문장을 만들어볼 수 있겠죠. “로컬 리소스를 로드하는 데 클라이언트의 액세스가 블락당했습니다.” 이처럼 어순, 구조 등은 그대로 둔 상태로 용어만 음차 표기로 갈아치우면 어감이 다소 기계적이 됩니다. 만약 한글 음차 표기만 넣는다면 각 단어의 영어 철자를 찾아봐야 하는 수고도 추가될 수 있겠네요. 특별히 음차 표기를 해야 하는 이유가 아니라면, 대체할 수 있는 쉬운 자국어가 무엇일지 고민하는 과정이 필요합니다. 그러한 노력이 코딩이라는 전문 영역의 장벽을 낮추고, 더 많은 사용자에게 참여와 소통의 여지를 ‘친절하게’ 열어놓게 되는 길로도 이어질 수 있겠지요.
명사화 현상과 일관성을 의식하기
이런 기준으로 음차 표기와 번역을 결정하게 되면, 얼마나 쉽게 전달할 수 있는지-가 번역에서도 중요한 이정표가 됩니다. 앞서도 말했듯이 번역을 해서 원문보다 더 이해하기 어려워지는 경우를 가장 나쁜 예로서 경계해야겠지요. 특히 다른 언어를 번역하다 보면 정확하게 옮기기 어려운 의미를 뭉뚱그리기 위해 주어나 보어가 긴 명사의 형태로 나타나는 경우가 자주 발생합니다. 번역을 연구하는 영역에서는 이를 ‘명사화(nominalization) 현상'이라 이름붙이고 특별히 주의를 기울이기도 합니다. 예를 들어 ‘변수를 선언하는 것이 요구된다'는 ‘변수를 선언해야 한다'로, ‘값의 지정을 필요로 한다'는 ‘값을 지정하다'로 명사구로 뭉쳐진 부분을 풀었을 때, 문장도 가벼워지고 훨씬 쉽게 전달할 수도 있다는 거죠. 번역은 단순히 대체할 자국어를 찾는 것뿐만 아니라, 불필요하게 뭉쳐진 말을 풀어내고, 핵심이 되는 표현을 살려 적절한 위치에 재배치하는 과정이기도 합니다.
마지막으로, 음차 표기와 번역을 선택한 이후에는 선택한 방향의 통일성을 깨지 않도록 주의합니다. 어떤 용어를 한 곳에서는 음차 표기로, 다른 곳에서는 번역으로 처리한다면, 읽는 입장에서는 같은 용어도 다른 말인지 헷갈리고, 그 용어들 간의 관계를 파악하는 데 불필요한 피로도가 더해지니까요.[4.번역가 간의 약속]에서 p5.js의 기술 용어 색인을 소개하고 있습니다. FES를 포함해 프로그래밍 언어는 일종의 약속이라는 것을 생각해봅시다. 많은 기술 용어들이 한번만 등장하기보다는 반복적으로 사용된다는 점에서, 음차 표기와 번역을 선택할 때 통일성을 유지하는 문제는 둘 중 무엇을 선택하는가의 문제보다도 어쩌면 더 중요해 보입니다.