한국어

the team

Pledge among translators

Inhwa Yeom & editor Jihyun Lee

Table of Contents

  1. 번역에 도움이 되는 툴과 유의점들
  2. 번역 작업 중 마주치는 딜레마들
    1. 어미에 따라 달라지는 말의 느낌
    2. 문장 내 어휘의 결을 통일하기 (고유어, 한자어, 외래어)
    3. 원문을 살리면서도 어색함을 줄이기
    4. 앞에 오는 명사에 따라 바뀌는 조사
  3. 기술 용어 색인
  4. 번역자의 반짝이는 개입

구어로서의 한국어는 매우 유동적이고 유연하지만, 그 글쓰기 체계는 매우 까다롭습니다. 특히, 매년 조금씩 개정되는 맞춤법으로 인해 때로는 한국어를 모국어로 사용하는 화자조차도 혼동을 겪을 정도이지요. 외국어로 된 내용을 한국어로 번역하려고 할 때 우리 모두가 한국어 전문가가 될 필요는 없습니다. 하지만, 한국어로 완성된 번역문이 한국어 사용자들에게 영어 원문의 의미를 명확하게 전달하기 위해서는 번역에 기여하는 분들의 세심한 주의가 필요합니다.

FES의 영어 원문과 번역문은 모두 누군가의 창작물입니다. 그러므로 원문을 신규 번역하거나 재번역할 때, 우리는 모두 원작자이자 2차 창작자로서의 역할을 수행하는 셈입니다. 특히, FES 한국어 번역은 기여자님이 지닌 고유의 배경에 따라 무엇을 어떻게 번역하는지가 매우 다채로워질 수 있고, 따라서 그 문학적 가능성이 무궁무진합니다. 다만 이 다양함이 원문의 이해를 저해하지 않기 위해서는, 현재 한국어 사용자들이 따르고 있는 약속을 번역 기여자 또한 준수하려는 노력이 필요하겠지요.

저희 FES 한글번역팀은 기여자님의 번역의 자유를 최대한 보장하되, 아래의 몇 가지 약속들을 제안하고 싶습니다.

  1. 상용화된 도구를 쓸 때는 도구의 기능과 한계를 인지하면서 씁시다.
  2. 단어를 선별하고 문장구조를 다듬는 고민을 거쳐 글의 가독성을 높여 봅시다.
  3. 커뮤니티 내 통일된 용어와 톤을 유지하려 노력하고, 예전 번역의 한계 지점을 발견했을 때에는 새로운 대안을 함께 생각해 봅시다.

번역에 도움이 되는 툴과 유의점들

오늘날 편리하게 발달한 기계 도구를 통해 우리들은 예전보다 손쉽게 번역의 세계에 접근할 수 있습니다. 하지만 도구를 사용하기에 앞서, 기여자님의 번역 결과물이 한국어 사용자들에게 정확한 지식을 전달할 수 있도록 한국어 어문 규범에 어긋나지 않는 문장 작성을 부탁드리고자 합니다. 아래의 사이트를 참고하면 간단하게 내가 쓴 번역문의 맞춤법 준수 여부를 판단할 수 있습니다.

국립국어원에서 제공하는 1) 표준국어대사전, 2) 맞춤법 검사기, 3) 외래어 용례 찾기 기능을 활용하면, 문법, 띄어쓰기, 철자, 표기법 등에 유의하면서 보다 편리하게 번역문을 작성, 검토할 수 있습니다. 특히, 국립국어원의 '온라인 가나다' 상담은 한국어 맞춤법에 대한 Q&A 데이터베이스인 동시에 전문가의 답변으로 의문을 해소할 수 있으므로 유용합니다. 이곳에서는 나와 같은 궁금증을 가졌던 누군가가 먼저 질문한 내역을 검색해볼 수도 있고, 국어학 전문가들이 답변한 신뢰할 만한 내용을 확인할 수도 있습니다. [국립국어원: 상담사례 + 온라인 가나다] (편집자 주)

번역의 모든 단계에서 한국어 규범들을 일일이 확인하며 문법 규칙의 옳고 그름에 너무 얽매일 필요는 없습니다. 어문 규범의 검토는 번역문의 완성도를 보다 끌어올려야 할 단계에 더욱 필요합니다. 반면 전반적인 내용을 옮기는 게 중요한 초벌 번역 단계에서는 지나치게 완벽한 문법에 집착하는 것이 오히려 효율성을 떨어뜨릴 수도 있습니다. 영어로 된 많은 내용을 한국어로 빠르게 가져오고 싶을 경우, 구글 번역기(Google Translate) 나 국내 기업 네이버의 파파고(Papago)와 같은 기계 번역 툴을 활용하는 것도 좋은 방법입니다.이런 기계 번역 툴은 해를 거듭할수록 정확도가 향상되고 있어, 번역문의 완성도를 가장 효율적으로 검토할 수 있는 방법이기도 합니다.

번역해야 할 내용이 많은 경우, 기계 번역 툴의 힘을 빌리면 손쉽게 초벌 번역을 생산해낼 수 있습니다. 적지 않은 분량을 아주 짧은 시간 안에 읽기 쉬운 언어로 바꾸어 주는 것은 기계 번역 툴의 부정할 수 없는 장점입니다. 하지만 앞서 이야기했듯 기계 번역툴에도 한계가 있습니다. 기계 번역 툴이 생산한 문장은 아직 불완전한 한국어이기 때문입니다. 일상에서 흔히 접하는 번역 툴의 실패 사례에서 볼 수 있듯, 문법적 혹은 맥락적인 면에서 비문이 생산되는 양상을 쉽게 발견할 수 있습니다. 그 이유는 다음과 같습니다. 현재 기계 번역은 기본적으로 글을 조각내어 연산하기에 (1) 적확한 맥락에 따라 문장을 번역해내지 못하고 (2) 문장 구조를 잘못 파악하는 경우가 있으며 (3) 여러 문서 간 통일성을 유지할 수 없는 치명적인 한계를 갖고 있습니다. 또한 온라인에서 다양한 경로로 수집된 문서들을 기반으로 학습된 경우가 많아 아래에서 다룰 한국어 어문 규범이 정밀하게 적용되어 있지 않을 가능성이 높습니다. 마지막으로 원문의 언어와 번역문의 언어가 어떤 것인지에 따라 번역 질의 차이가 커질 수 있으므로 번역 툴을 선택하실 때 유의해야겠습니다.

번역 작업 중 마주치는 딜레마들

번역 작업에서는 적확하게 뜻을 옮길 뿐만 아니라 쉬운 단어와 문장 구조로서 번역문의 가독성을 유지하는 작업이 동시에 일어나야 할 것입니다. 이 곳에서는 외국어를 한국어로 번역하면서 흔히 발생하기 쉬운 문법적 딜레마들을 모아 소개해보겠습니다.

어미에 따라 달라지는 말의 느낌

예시:

한국어는 공동체 구성원들의 관계 및 위계를 설정하는 데 높임법을 정밀하게 사용하며 한국어 사용자들 또한 이에 예민합니다. 따라서 같은 내용을 전달할 때에도 어떤 종결어미를 사용하는지에 따라 그 말이 주는 뉘앙스가 전혀 달라질 수 있습니다.

그래서 저희는 ‘확인해 보세요’라는 비격식체 종결어미를 최종 번역문으로 채택하였습니다. 예를 들어, ‘~확인하십시오.’라는 메시지와 ‘~확인해 보세요.’ 라는 말은 그 위계와 구속력 자체가 전혀 다른 말이 됩니다. 앞의 말(‘확인하십시오’)은 공식적인 상황에서 쓰는 격식체(‘합쇼체’)이며 청자와 화자 사이에 거리를 두는 어투입니다. 격식체는 예를 들어 지면으로 일방적인 전달이 이루어지는 공지사항이나 시험 문제 등에서 쓰일 수 있습니다. 반면 후자는 (‘확인해 보세요’) 비공식적인 상황에서 친밀감을 불러일으키는 비격식체(‘해요체’)이며 심정적으로 거리가 가까운 상대에게 편안하게 이야기하고 있는 듯한 느낌을 줍니다. 이러한 비격식체는 채팅이나 편지, 직접 만나서 이야기하는 대화 상황에서 보다 많이 쓰이는 말투입니다. (편집자 주) 어떤 종결어미를 채택하느냐에 따라 어떤 어조로 이야기하는지가 결정되고, 특정한 어조를 사용하는 화자의 이미지가 결정될 수 있습니다. 김철호 선생님의 정중한 ‘합쇼체' 친근한 ‘해요체'를 참조했습니다. 이는 브랜딩에서 커뮤니케이션 톤 설정이라 하여 중요 디자인 요소로 여겨집니다. 이러한 어미를 사용할 때, 하나를 일관되게 사용해야 한다는 점도 잊지 않아야겠지요. 만약에 어떤 하나의 메시지를 전달하면서 격식체와 비격식체를 모두 사용해 버린다면 청자는 그 메시지를 받아들일 때 화자의 태도나 상황을 해석하면서 혼란을 겪을 수도 있을 것입니다.

문장 내 어휘의 결을 통일하기 (고유어, 한자어, 외래어)

(~하는 동안, ~하는 데, ~하는 중)

예시:

한국어의 어휘 체계는 고유어(순우리말)와 한자어, 그리고 외래어로 나눌 수 있습니다. 그래서 같은 어휘 체계에 속한 단어를 함께 사용하면 문장에 미세하지만 통일감이 생겨납니다. 위 예시 문장을 살펴보죠. ‘문제가 발생했습니다’에서 동사인 ‘발생하다’는 한문에서 유래한 한자어입니다. 그런데 앞 문장어구에 붙어 있는 부사어구를 살펴보면 ‘~하는 동안’과 ‘~하는 데’가 고유어인 반면, ‘~하는 중’은 한자어입니다. 따라서 우리는 ‘~중’과 ‘~발생했습니다’가 결합하는 편이 가장 통일성이 있다고 여겨 예시문 중 가장 마지막 문장을 최종 번역문으로 채택하였습니다.

추가로 “로드하다” “로딩하다”에는 영단어 load/loading이 외래어로 번역이 되었는데요, 외래어 번역 방식에도 다른 방식이 존재합니다. 한국어에는 일본어나 몽골어, 영어 등 여러 외국어에서 넘어와 한국어에 정착한 단어군이 존재합니다. 이 중에서 한국어에 비교적 깊이 정착하여 대체어가 없어진 단어는 외래어, 반면 한국어 내에서 자리를 찾지 못한 채 손님처럼 남아 있는 단어는 외국어라고 구분하여 명칭합니다. 여러 외국어 중에서도 특히 영어에서 넘어온 단어는 주로 현대문명의 많은 성과를 바쁘게 직수입하는 과정에서 도입되었기에 이 단어가 과연 외래어인지 외국어인지 그 구분이 모호해지기도 했습니다. (편집자 주) 이러한 번역 과정은 현재진행형이기도 합니다. 이와 같은 내용은 [3. 기술 용어 다루기] 챕터에서 심도있게 다루고 있으니 참고 바랍니다.

원문을 살리면서도 어색함을 줄이기

예시:

위 번역문은 함수를 다룰 때 나타난 에러 메시지를 번역한 문장들입니다.이 세 문장들은 비슷해보지만 면밀히 말해 자바스크립트 프로그래밍 언어 내에서 다른 상황 ‘변수가 입력되지 않았습니다’는 아무런 입력이 없는 상황만 담고 있지만 실제 코드에서는 ‘undefined’나 ‘null’값을 전달받은 상황 (arg == null) 도 포함하고 있습니다. “빈 변수를 받다”라는 표현이 ‘undefined’나 ‘null’값을 포괄적으로 표현하고 있지만, 이 경우 변수가 입력되지 않은 상황은 또 누락됩니다. 결국 모든 상황을 담고 한국어로도 자연스럽게 읽히는 “아무 값도 전달되지 않다”라는 표현을 써봤습니다.을 묘사하고 있고, 한국어 문장으로 어색한 정도가 달라첫 번째 문장은 가장 원어의 의미와 가깝지만 한국어 문장으로 보면 가장 어색합니다. 왜냐하면 ‘함수’라는 주어를 의인화하여 쓰는 경우가 한국어에서는 드물기 때문입니다. 물론 구어체에서는 있을 수도 있지만, 정제된 문장에서는 쓰지 않습니다. 한국어에서는 인칭인 주어를 생략할 수도 있기 때문에, 문장에서 비인칭 주어를 굳이 상정하는 방식은 다소 낯설게 느껴집니다. 이는 영어 문장에서 주어를 꼭 요구하는 방식과는 차이가 있다고 볼 수 있습니다. 한국어는 SOV형 구조이기 때문에 SVO형인 영어와 통사구조에서 차이가 납니다. 사실 영어 문장에서는 가주어 (‘it’ 등)이 존재하지만, 한국어에서는 주어를 생략하는 방식으로 문장이 쓰여집니다. 그래서 (이 함수는) 빈 변수를 받았습니다. 와 같은 표현이 자연스러운 한국어라고 보기는 다소 어렵습니다. 위 내용 중 비교적 한국어로서 자연스러운 문장은 다음 문장입니다: (이 문장에) 변수가 입력되지 않았습니다. (편집자 주) 저희에게 많은 고민을 불러왔습니다.

먼저 FES 코드를 열어 동작원리를 들여다 보니 변수를 입력하지 않은 상황은 물론, null 혹은 undefined를 넣은 경우까지 포괄하는 에러 메시지였습니다. 변수, null, 혹은 undefined와 같은 자바스크립트 프로그래밍 용어/개념을 어디까지 친절한 에러메시지에 담을지 논의를 거친 결과, 실제 코드 동작하는 범위를 포괄적으로 담고 원문의 의미를 잘 살리면서도 덜 어색한 세 번째 문장을 번역문으로 채택하였습니다.

앞에 오는 명사에 따라 바뀌는 조사

예시:

좀더 심화된 내용이지만 ‘이/가’는 조사, ‘은/는’은 보조사입니다. 한국어에서 ‘이/가’와 ‘은/는’은 모두 주어를 수식할 수 있지만 미묘한 뜻 차이가 있습니다.조사 및 보조사의 앞 단어가 어떤 발음으로 끝나는지에 따라 사용해야 할 형태도 달라집니다. 한국어의 글자는 ‘초성, 중성, 종성’이라는 세 가지의 블록으로 이루어집니다. 이 중에서 ‘종성’이 있는 글자를 두고 ‘받침이 있다’고 말하며 ‘초성’과 ‘중성’으로만 이루어진 글자는 ‘받침이 없는’ 글자입니다. 예를 들어 ‘파일’은 받침이 있는 글자로 끝나는 단어이며, ‘미디어’는 받침이 없는 글자로 끝나는 단어입니다. 혹시 앞 문장에서 ‘은’과 ‘는’이 어떻게 쓰이는지를 보셨다면 힌트가 될까요? 받침이 있는 글자 뒤에는 보조사 ‘은’이나 조사 ‘이’를 써야 하고, 받침이 없는 글자 뒤에는 조사 ‘가’나 보조사 ‘는’을 써야 한국어 문장으로서 자연스럽게 읽힙니다. 하지만 의미 단위를 옮기는 데 우선 주력하는 기계 번역 툴은 이러한 문장을 제대로 번역하지 못할 가능성이 높지요. 이럴 경우, 이처럼 작지만 중대한 오류를 짚어내는 부분은 우리 인간의 몫이 될 수 있겠습니다. (편집자 주) ‘은/는’을 사용하면 좀더 앞에 수식을 받는 주어의 차이나 특징이 강조되는 어감을 줍니다.조사와 보조사를 어떻게 쓰는 것이 발음상으로 올바른 한국어인지를 이해했다면, 이제 더욱 미묘한 부분인, 의미상 정확도를 어떻게 높이는지에 대해 짧게 이야기하려고 합니다. 한국어에서 ‘조사’는 주로 주어인 ‘체언’과 주로 동사인 ‘용언’을 이어주는 역할만을 합니다. 하지만 ‘보조사’는 문장 속에서 보다 특별한 기능을 수행하기도 합니다. 방금 쓴 문장에서 보조사를 찾아내실 수 있을까요? 바로 ‘는’과 ‘도’입니다. 그리고 그 앞의 문장을 보면 ‘만’이라는 보조사도 존재하고 있지요. 보조사의 기능 중 가장 두드러지는 것은 특성을 한정짓는 것입니다. (편집자 주)

우리는 이 문장을 번역할 때 특정한 파일에 문제가 있다고 하는 것보다도 어떤 파일이 특정한 브라우저에서는 열리지 않는다고 표현하는 게 더 낫다고 판단하였기에 두 번째 문장을 번역문으로 채택하였습니다.예시를 살펴보면 첫 번째 문장이 좀더 ‘미디어 파일’의 특이성을 나타내 주는 번역이라고 볼 수 있는데요. 바로 ‘은’이라는 보조사를 사용하여, 다른 대상과의 차별점(=이 브라우저에서 허용되지 않음)을 드러내 주었기 때문입니다. 그렇다면 두 번째 문장은 어떨까요? ‘미디어’라는 단어에 ‘가’라는 조사를 붙인 반면, ‘브라우저에서’라는 어구 끝에 ‘는’이라는 보조사를 붙였기에 ‘브라우저’라는 대상의 특이점을 더 강조하고 있다고 볼 수 있습니다. (편집자 주)

기술 용어 색인

기술 용어 번역에서도 마찬가지로, 기여자님들의 글쓰기가 친구같고, 친근하며, 친절할 것으로 기대됩니다. 필자는 FES 내에서 통일된 기술 용어를 사용하는 것이 독자를 위한 최소한의 ‘프렌들리함’이 될 수 있다고 생각합니다. 만약 FES 내에서 “parameter”가 한 문장에서는 “매개변수”로, 또 다른 문장에서는 “파라미터”라고 번역된다면, 사용자는 이를 어떻게 느낄까요? 혹자는 이러한 용어 차이를 낯설고, 어렵고, 불친절한 문장들이라고 받아들일지도 모릅니다. 온전히 통일하기에는 어려움이 있겠지만 그래도 이와 같은 시도를 계속해나가는 것이 우리가 사용자에게 제공할 수 있는 최소한의 공통된 ‘친절’일 것입니다.

따라서 미래의 기여자님들께 p5.js 홈페이지와 에디터 내에서의 통일된 번역어 사용을 권장하며, p5js.org/ko 색인을 소개해 드리고자 합니다. 이 색인은 현재 p5.js 홈페이지와 에디터상의 컴퓨터 프로그래밍 및 그래픽 전문 용어들에 대한 한국어 번역어를 포함하고 있으며, 자바스크립트 및 프로세싱 관련 서적, 온라인 포럼, 관련 업계 종사자 인터뷰 등을 참조하여 작성되었습니다. 이 색인은 누구에게나 열려 있는 공동 문서입니다. 그리고, 기술 용어 번역어에 대한 담론의 초석이 될 수 있기를 바랍니다. 추가나 수정이 필요할 경우, 언제든 논의주세요!

* 이 한국어 번역 색인의 형식은 케네스 림(Kenneth Lim)님의 2018년 프로세싱 재단 펠로우십 프로젝트의 일환으로 작성된 중국어 번역 색인을 참조합니다.

번역자의 반짝이는 개입

재미있게도 저희 번역 작업 중 논의가 가장 많이 되었던 문장은 다름아닌 FES의 자기소개였습니다:

예시:

p5js에서 쓰는 말들에는 다른 기술 언어와 같이 다수의 신조어를 포함하며 간혹 시적인 시도가 있기도 합니다. 게다가 FES의 영어 원문 중 몇몇 문장들은 생각보다 문법적으로 느슨하거나, 구어체로 작성되어 있기도 합니다. 이런 문장을 기계로 번역할 경우, 주어와 목적어가 뒤바뀌는 상황과 같은 기계 번역기의 한계를 종종 접할 수 있습니다. 바로 이러한 순간들에 ‘인간’인 우리 번역 기여자님들의 반짝이는 개입이 필요합니다.

예시 원문 중 “debugger”는 “에러를 찾는 디버깅 안내문”으로 풀이되었고, “friendly (구글 번역: 친숙한)”라는 표현 역시 “안내문”에 함축되었습니다. 모든 문장을 한글로 직역하기보다는, FES의 기능 설명을 전달하는 쪽에 초점을 둔 것입니다. 또한, 디버거를 1인칭 주어로 자칭하는 대신, 3인칭으로 표기하기도 했습니다. 마지막으로, “To turn me off”는 “안내가 필요없는 경우”로, “switch to”는 “대신 p5.min.js를 사용하세요”로 의역하였습니다.

현존 문장들이 어떻게, 그리고 왜 의역된 것인지. 그것은 원문을 가능한 정확히 전달하기 위해서일 수도, 원문도 미처 전달하지 못하는 내용을 포함하는 것일 수도, 원문의 문장 구조를 한국어 사용자에 맞게 재구성하는 것일 수도 있습니다. 원문과 현존 번역문의 행간을 읽어내는 것으로부터 친구같고, 친근하며, 친절한 번역이 시작됩니다. 원작자와 재창작자들의 의도를 (때로는 비판적으로) 사유하며, 한국어 사용자들을 위해 한층 더 친구같고, 친근하며, 친절한 번역문을 덧대주시기를 기대해봅니다.

그러니, "Friendly"란 프로그래밍 언어를 경험하는 사용자와 기계 사이의 상호작용 속에서 드러나는 틈새라고 할 수 있습니다. "Friendly"는 본질적으로 불완전하지만 완전하기를 바라는 시스템의 과잉이자 결핍처럼 존재합니다.