명확하지 못한 단어가 주는 문제

08 Mar 2019 » Story

2018년에 (일단은) SA로 일하게 되었는데, 기존의 솔루션을 단일제품으로 변경하는 과정이었다.

개발팀에서는 오래된 DB Table 기반에서 조금이나마 Domain 기반의 개발로 넘어가고자 하는 과정이었기에

기존에 작업된 도메인을 분석하다가 눈에 걸린 것이 ‘서버(Server)’라는 도메인이었다.

Server라는 이름만으로는 도메인의 명확한 의미를 파악하기 어려웠는데,

속성은 연동, 혹은 API 호출 대상으로써의 의미였던 한면, 실제 물리적인 장치를 의미하는 장치 도메인을 상속하고 있었기 때문이다.

모호한 용어의 사용으로 의미가 전달되지 않는 이러한 문제는 흔히 발생한다.

이런 고민은 정말 흔하면서도 끊이지 않는 고민이다.


이것이 정말 중요한 문제일까?

프로그래밍 언어는 컴퓨터가 이해하기 쉬운 저급언어에서, 사람이 이해하기 쉬운 고급 언어로 발전해왔고, 실제 현대에 많이 사용하고 새로 등장하는 언어들이 대부분 고급 프로그래밍 언어라는 것을 감안하면 ‘사람이 이해하는 코드’의 중요성은 우리 모두가 충분히 알고 있다. 그리고 그 안에는 수많은 클래스, 함수, 변수의 명칭이 자리를 차지하고 있다..

오랜 세월 수없이 논해진 이 주제에 대해서는 아래와 같이 많이도 언급되고 있다.

프로그램을 작성할 때는 컴퓨터만을 고려하기 쉽다. 하지만 타인을 고려해서 프로그램을 짜면 여러가지 좋은 점이 있다.
내 코드는 좀더 이해하기 쉽고 깔끔해지며, 더 효율적이 되고 생각은 명확해진다.(중략)
크누쓰는 프로그램을 책처럼 읽을 수 있어야 한다고 주장했다. (pp 34-35)
내가 사용하는 비용 절감 전략은 모든 프로그래머가 커뮤니케이션하기 쉬운 코드를 짬으로써, 유지 비용을 줄이는 것이다. (p 48)
- Kent Beck, 켄트 벡의 구현 패턴(전동환 역), 에이콘

이는 단순히 용어의 사용에 한정지어 언급한 것은 아니지만 켄트 벡이 (책처럼) 읽기 쉬운 코드를 작성함으로써 프로그램에서 커뮤니케이션의 가치를 강조하고 이를 통해 비용 절감이 가능하다고 주장하는 것은 명확해 보인다.

이런 일을 방지하기 위해, 개발자는 읽는 사람의 입장에서 생각하고 자신의 코드를 리팩토링하는 데 일치된 노력을 기울여 읽는 사람이 그것을 이해할 수 있도록 해야 한다. (p. 114)
- Robert C. Martin, 클린 소프트웨어(이용원, 김정민, 정지호 역), 제이펍 (원제 : Agile Software Development, Principles, Patterns, and Practices)1

사실 이 책에서는 습관적이라고 할만큼 많은 부분에서 불명확한 용어를 수정하는 과정이 등장하지만 그 중 한 문장을 인용하였다.

이러한 문제를 방지하려면 메서드명을 잘 지어야 한다. 메서드명만 봐도 그 메서드의 의도를 한눈에 알 수 있어야 한다.(중략)
일상에서도 그렇듯 처음부터 이름을 제대로 짓기란 어렵다. 그래서 그저 이름에 불과하니 그냥 내버려두자는 자기합리화를 하게 된다.(중략)
코드는 컴퓨터보다 인간이 알아보기 쉽게 작성해야 한다. (중략)
이 기술을 발전시키는 것이야말로 진정으로 노련한 프로그래머가 되는 열쇠다. (p 325)
- Martin Fowler, Refactoring(김지원 역), 한빛미디어

이 주제를 가지고 논한 부분이 이 외에도 많지만. 사실, 5년전에 처음 읽은 이 책이야 말로, 이 글을 쓰게된 고민의 시작점이었다.


이것이 왜 어려운가?

마지막에 인용한 마틴 파울러조차는 이러한 과정이 어려운 일이라고 말한다. 심지어 ‘일상에서도’조차 말이다.

하지만 분명히 생각컨데, 이 작업은 이들이 생각하는 것보다 우리에게 훨씬 어려운 문제일 것이다.

의미를 (자신들의) 자연어로 옮기면 되는 영어권 개발자들과 달리,

우리는 이 과정에서 의미를 모국어로, 모국어를 영어로 옮기는 2개의 자연어에 대한 이해를 필요로 한다.

이 과정에서 우리는 ‘번역’ 이라고 하는 작업이 가지는 의미까지 고민해야 한다.

말하고 싶은 것은 이것이 개발자만의 문제가 아니며, 어제오늘의 일도 아니라는 것이다.

20세기 최고의 철학자는?

이 사람이 루드비히 비트겐슈타인(Ludwig Josef Johann Wittgenstein),

비트겐슈타인은 그의 후기 철학으로써 대표되는 “철학적 탐구”에서 이렇게 말한다.

According to the use theory of meaning, the words are not defined by reference to the objects they designate, nor by the mental representations one might associate with them, but by how they are used
- Wittgenstein, Philosophical Investigations

의미론의 사용 이론에 따르면, 단어들은 그들이 지정하는 물건에 대한 참조나 그것과 연관될 수 있는 정신적 표현에 의해서 정의되는 것이 아니라 어떻게 사용되는지에 의해서 정의된다

여기서 주장하는 것은 _단어가 어떤 맥락에서 어떤 목적을 가지고 사용되었는지가 그 단어를 의미있게 만든다_는 것이다.


언어라는 틀이 가진 기본적인 한계

문제
이 그림속 생물을 표현하는 ‘가장 적절한’ 단어를 고르시오.
① 동물 ② 고양이 ③ 흰고양이 ④ 터키쉬 앙고라

이 문제를 풀 수 없는 것은, 사진으로는 전달하고자 하는 의미 - 맥락과 목적 - 이 다 전달되지 않기 때문이다.

그리고 그것을 이해하지 못한 채 다른 제 3자에게 전달할 경우, 그 단어는 의미없는 단어가 된다.

따라서 최초의 작성자로부터 의미의 누락이 없도록 주의해야 하며, 이것은 코드에서도 마찬가지이다.

코드에서는 특히 ‘간결한 코드’ 라는 표현이 ‘짧은 코드’ 로 오인되고 있는데,2

이 표현의 원문은 [concise]이고, 본래 의미는 이렇다.

Giving a lot of information clearly and in a few words;brief but comprehensive.3

이는 읽기 쉬운 코드를 강조하는 내용이 같이 나오는 맥락까지 고려한다면, ‘간결한’ 보다는 ‘명료한’, 혹은 ‘간명한’으로 번역되는 것이 훨씬 적절하다.4

짧고 정확하게 표현할 수 있으면 좋지만, 아래의 극단적인 예시처럼, 짧은 것에만 집중하면 문제가 생길 수 있다.

public class  {
 // ship? pare? stomach? 의미의 누락이 모국어 여부와 무관함을 알 수 있다.
}

언어와 언어는 1:1로 매칭될 수 없다.

프로그래밍 언어간에도 해당 언어의 철학, 그리고 그 발전과정에서의 시대적 요구사항 등에 따라 실제 구현된 API가 달라 실제 100% 1:1 매칭이 어렵듯이,

문화와 사회의 특성이 반영된 자연어 사이에서도 의미가 1:1로 매칭되기엔 매우 어렵다.

우리가 한국어로써 받아들이고 있는 개념을 영어로 번역하는 과정은 실제 Java로 구상한 프로그램을 C++로 구현하는 정도의 난이도를 생각해도 무방할 것이다.

이 부분에 대해서 착각이 생겨나는 이유가, 영한사전을 통해 찾아보면 단어와 단어가 1:1로 매칭되기 때문인데,

국어사전이나 영영사전을 통해서 언어의 의미를 파악하려 하면 단어의 뜻은 문장 형태로 설명되어 있다는 것을 알 수 있다.

예를들어 우리말이 가지고 있는 ‘시간(時間)’과 ‘시각(時刻)’은 영어에서는 기본적으로는 ‘Time’이 되어버린다.5

한가지 더, 중역의 문제 또한 심각하다.

7~80년대, 혹은 그 이전에 외국어 능력자가 부족하던 시절 일본어 서적을 중역하는 과정에서나

의미 이해가 부족한 상태에서 국내에 시판되는 영한사전6을 통해 ‘무성의하게’ 번역하는 경우도 이러한 문제는 더욱 크게 만든다.

언어는 의미 전달을 위한 수단이며, 그러기 위해서는 본래 의미를 잘 이해하고 그것을 새로운 틀로 조심스럽게 옮겨담아야 한다.

흔하게 보이는 경우는 ‘그럴싸한’ 표현을 위해, 혹은 무성의하게 의미를 고려하지 않고 틀만을 옮기는 경우인데, 이 경우 십중팔구 내용물을 흘리게 된다.


결론 - 원래 힘든거다. 우리 같이 힘내자.

  • 사람이 읽기 쉬운 코드를 작성해야한다는 것. 조금 더 포괄적으로 코드가 ‘사람에게의 의미 전달’의 역할을 해야 한다는 것은 수없이 강조되어 온 명제이다.
  • ‘목적’과 ‘맥락’이 누락된 언어의 사용은 (비트겐슈타인에 의하면) 무의미하다.
  • 언어라는 것은 의미를 전달하기 위한 하나의 틀이다. 그 안에 담는 과정에서 의미가 손실될 수 있다.
  • 우리가 영어권에서 태어나고 자라고 하지 않은 이상, 우리는 ‘번역가’로써의 역할도 함께 해야 한다.

기본적으로 언어라는 것은 의미 전달이라는 목적을 위한 ‘수단’에 지나지 않는다.

따라서 본래의 목적에 가장 적합한 수단을 찾아야 한다는 점은, 우리가 개발 과정에서 가장 적합한 기술을 선정하는 것과 프로세스를 공유한다.

먼저 전달하고자 하는 의미는 물론 그 의미를 담기 위한 표현도 다양하게, 그리고 잘 알고 있어야 한다.

의미만 이해하는 경우는 표현력이 부족하다고 하고, 표현만 다양하게 알고 있는 경우는 내용이 부실한 거다.7

그래서 이건 원래 힘들고 어려운게 맞긴 하다.

그래서 기술만 잘 이해하고 있다고 해서 좋은 기술서적을 쓰거나 번역할 수 있는 것도 아니고,

언어만 잘 이해하고 있다고 해서 좋은 기술서적을 쓰거나 번역할 수 있는 것도 아니다.

이런 부분이 우리가 번역을 2차 창작의 영역으로 보는 이유일거다.


덧붙임

이 글 전체에서 한번도 (명칭이란 표현을 일부 사용하긴 했지만) ‘이름을 붙인다(혹은 짓는다)’는 표현을 쓰지 않았다.

후배 개발자들의 교육을 진행할때 이러한 작업에 대해 이렇게 설명하곤 했다.

사실 우리가 일상적으로 말하는 메소드나 변수, 클래스의 ‘이름을 짓는다’ 라는 표현은 부정확한 표현이야.
개발하는 과정에서 우리가 ‘이름을 짓는’ 경우는 거의 없어. 대부분은 ‘정의하는’ 작업이지.
java를 쓰는 입장에선 낯설수 있지만 다른 언어에서 변수를 선언할때 ‘def’, ‘define’을 사용하는 의미를 생각해 볼 필요가 있을거야.

이러한 ‘정의’ 과정에서 나름 쓰는 방법은 이렇다.(당연히 나도 영어를 잘 못한다. 애초에 잘하면 이런거 고민 안해도 되는데)

① 의미를 한글로 담는다. ② 한글을 영어로 옮겨본다. ③ 옮긴 영어를 ‘영영사전‘을 통해 찾아본다.8 ④ ③번의 결과가 만족스럽지 못할 경우, ‘유의어 사전’을 통해 비슷한 표현들을 뒤져본다.9 ⑤ 후보군을 추려서 옆사람의 옆구리를 찌른다.


  1. 해당 책은 각기 다른 제목으로 두번 번역되어 출판되어 원제를 표기한다. 여기서는 참조한 서적은 2017년 재판. 

  2. SI의 (예전)실태
    실제 내가 SI에 있을때 돌던 용어사전이다. SFTRSC를 보고 Software Resource를 떠올릴 수 있는 사람이 얼마나 될까.
    이런데서 개발을 했다 보니, 이런 당연한 주제를 놓고 입에 불을 뿜게 되는 것에 양해를 부탁드린다. 

  3. - oxford English Dictionary - concise 

  4. 다음 영한사전 - concise 

  5. 물론 한국어만 쓰면서도 이것을 잘 구분 못하는 것이 원인인 경우가 더 많았지만.. 

  6. 국내에 현재 시판되는 모든 영한사전은 영일사전을 중역한 것이다.
    10년 전에 하나, 시도는 있었지만 아쉽게도 판매는 더이상 하지 않는듯 하다. 한번 보고 싶긴 했는데.. 

  7. ‘말할 수 있는 것에 대해 명료하게 말해야 하고, 말할 수 없는 것에 침묵해야 한다.’ - 논리철학논고, 비트겐슈타인
    다뤄보고 싶지만, 다음을 기약한다. 지금도 이 글은 길어서, 이 주석은 군더더기 제거중에 추가되고 있다. 

  8. 영영사전은 papago와 조합해서 쓰면 부담이 조금 덜하다. 물론 딥러닝 수준 이상으로 영어 문맥을 알 고 있다면 필요 없다. 

  9. 이건 한국어로 글을 쓸때도 같이 적용되는 방식이다. 유시민 작가, 강원국 작가 등도 비슷한 팁을 말한 적이 있다. (위 영영사전에도 이러한 기능이 있다.) 


Tags : philosophy