개꿈닷넷의 소프트웨어 이야기

아직 권위 뒤에 숨어서 비열하게 웃는 것을 익히지 못한 저는

무진장 멀었나 봅니다 ^^

프로그래밍 언어에 대해서 자세하게 알고 있지 않은 사람들은, 프로그래밍 언어를 마치 인간의 언어로 착각하곤 한다.

그러한 착각속에서 생기는 또 다른 착각은, 프로그래밍 언어를 번역하는 컴파일러도 있으니, 그러한 것과 유사하게 자연어(인간의 언어)도 완벽히 번역할 수 있는 번역기를 만들 수 있을 것 이라는 생각이다. 물론, 일이 시작되기도 전에 이 일은 절대로 불가능 합니다. 라는 말을 하려고 하는 것은 아니다.

하지만, 사람들이 생각하는 '완벽한' 이라는 수식어는 굉장히 엄격한 기준을 가지고 있다. 필자는 여기서 '완벽한 자연어 처리기' 는 거의 불가능에 가깝다고 단언할 수 있다. '거의' 라는 수식어를 붙인 것은 필자의 미비한 실력과 관점으로 미래의 일까지 완전히 예측하기에는 어려움이 있어서 이며, 최소한 필자의 개인적인 의견으로는 완벽한 자연어 처리는 불가능하다.

왜 불가능할까? 그 질문에 대답하기 위해서는 완벽한이라는 수식어에 대해서 좀 더 알아볼 필요가 있다. 완벽한이라는 것은 누가 어떤 이야기를 하건 간에, 그 의중을 반드시 파악해야 한다는 것이다. 하지만, 이는 불가능하다. 누가 '앗 뜨거' 라고 말한 것을 가지고, 그 상황을 완전히 이해할 수 있는 사람이 있을까? 그 사람은 뜨거운 불에 데였을 수 도 있고, 뜨거운 음식을 먹고 있었을 수 도 있다. 이렇게 자연어는 반드시 필요한 항목도 없어질 수 있기 때문에, 심지어 사람이라고 할지라도 이 자연어를 완전하게 이해할 수 는 없다. 그렇기 때문에 항상 miss communication 이 발생하는 것이다.
앞의 이야기를 간단하게 요약하자면, 사람조차도 자연어를 완벽하게 처리할 수 없는데, 이를 기계가 처리하기에는 어렵다는 이야기이다. 물론, 이것이 사람이 못한다고 해서 기계가 못한다는 관점에서 접근하는 것은 아니다. 그렇다면, 사람이 못하는 무한 계산 삽질을, 기계는 할 수 있기 때문이다. 하지만 이 경우는 이것과 명백히 다르다. 이는 자연어 자체의 불명확성에 기여한 결과이다.

일반적으로 프로그래밍 언어를 처리하는데에는, 엄격한 문법이 존재한다. 자연어에도 이러한 문법이 존재하지만, 프로그래밍 언어처럼 엄격하지는 않다. 왜일까? 곰곰히 생각해보면, 우리가 프로그램을 작성할때, 즉 프로그래밍을 할 때, 언제 문법오류에 대해서 보고 받는지에 대해서 알아볼 필요가 있다.

일부 프로그래밍언어들은 코드를 직접 입력할 때, 경고를 하기도 한다. 비주얼 베이직과 같은 경우인데, 사실 이러한 경우는 잘 없는 특수한 경우이다. 실질적으로 대부분의 프로그래밍 언어들은 컴파일을 하는 시점에서 사용자에게 '잘못된 문법입니다' 라는 경고를 알려주고, 더 이상 진행하지 않게 된다.
프로그래밍 언어를 해석함에 있어서 문법에 어긋난 표현이나, 허용되지 않는 표현을 걸러내는 것은 매우 중요하다. 사실상 이는 컴파일러에서는 처리 도중 에러를 만난 셈이 되지만, 실제로 프로그래머의 입장에서는 표현을 걸러내짐을 당한 입장이 된다. 더 이상 어떠한 것도 진행되지 않고, 반드시 에러난 그 코드를 수정하여야만 하기 때문이다.
하지만, 자연어에서는 이러한 것이 없다. 어떻게 입력을 하더라도, 누군가 와서 '야 너 이거 무슨 소리야?' 라고 말하는 사람은 거의 없다. 즉, 어떤 입력이라도 일단 받아들이는것이 자연어 처리의 특징이라는 것이다. 또한, 그렇게 특이한 입력들이 증가하는 것은, 언어가 점점 발전함에 따라서 더 많아진다.

이렇게 예외가 점점 많아지는 것이 프로그래밍 언어와 자연어의 두번째 차이점이다. 프로그래밍 언어는 초기 설계시 정해진 문법 사항에 대해서 처리를 하고, 기타의 내용을 그냥 무시하도록 설계되지만, 자연어는 그렇지 않다. 복잡한 문법 사항과 유사한 이야기가 되겠지만, 복잡한 경우에 대한 처리도 해법이 존재해야 한다. 왜냐하면 사림이 그렇게 받아들이고 있기 때문이다.

이러한 문제들로 인하여, 프로그래밍 언어를 분석하는 기법을 가지고는, 자연어를 분석할 수 없고, 자연어를 분석하기 위해서는 구문 분석 뿐만 아니라, 문맥해석, 학습기능등의 여러가지 기능들이 필요하다.

2009년 2월달, Special Report 기사를 썻습니다.

주제는, 개인적으로 매우 관심있는 Programming Language 입니다.

지금은 사정상 못하고 있지만, 언젠가는 꼭 한번 제대로 해 보고 싶은 것 중 하나입니다.

아래는 기사의 개요입니다.

빠진 내용도 있고, 좀 길어진 내용도 있지만, 대체로 이정도의 내용입니다.

---------------------------------------------------------------------

주제 : 구조적 프로그래밍 언어의 이해

목차
1. 구조적 프로그래밍 언어란 무엇인가?
 - 프로그래밍 언어에 대한 사전적 의미
 - 프로그래밍 언어는 왜 존재하는가?
 - 구조적 프로그래밍 언어에 대한 사전적 의미
 - 구조적 프로그래밍 언어는 왜 존재하는가?

2. 프로그래밍 언어의 분류와 의미
 - 프로그래밍 언어의 분류는 왜 하는가?
 - 구조적 프로그래밍 언어로는 객체지향을 할 수 없나?

3. 프로그래밍 언어의 이해
 - 프로그래밍 언어는 어떻게 해석되는가?
 - 프로그래밍 언어는 일반 언어와 어떻게 다른가?

4. 왜 C 언어인가?
 - C 언어와 어셈블리 언어의 공통점
 - 시스템과 가장 가까운 고급언어로서의 C
 - C 언어를 한다는 것의 의미 (C 언어는 어셈블리 언어를 하는 것과 같다)

5. C 언어의 미래
 - C 언어의 과거와 현재
 - C 언어는 왜 살아남을 수 밖에 없는가

http://msdn.microsoft.com/en-us/library/ms633517(VS.85).aspx

아래의 comment 에 반전

이 함수는 대체 왜 존재하는거지??

이 글을 읽는 개발자 중 얼마나 많은 사람이 자신의 코드에 대한 자신감이 있는지 모르겠다.

나의 경우에는 어떤 경우에는 자신감 있는 코드도 있지만, 어떤 경우에는 스스로도 굉장히 불안한 코드를 실제로 작성하고 또 배포할 때 도 있다.

누군가가 이에 대해서 물어본다면, 나의 대답이 내가 어떻게 그 코드를 생각하느냐를 알 수 있을 정도로 나의 반응은 확연하다.

하지만, 가끔 자신의 코드를 과신하는 사람들이 있다.

한번은, 필자가 코드 리뷰를 진행하려고 했을 때였다. 누군가 그에 대해서 말을 했다.

'그렇지, 코드 리뷰는 꼭 필요해. 다른 사람의 스타일로 작성된 코드를 보는 것은 참으로 곤욕이거든'

맞는 말이다. 내가 아닌 다른 사람의 스타일로 작성된 코드를 보는 것은 상당히 곤욕스럽다.

하지만, 저 짧은 말에는 참으로 많은 의미가 담겨 있다. 그 사람이 평소에 그 코드를 어떻게 생각해봤는지가 모두 묻어나는 표현이기 때문이다. 즉, '그 코드는 스타일 빼고는 별로 고칠게 없어. 내가 좀 하지' 라는 생각까지 들어있는 것이다.

빈 말이라도 그런 말은 하지 말자. 자신의 코드가 완벽하다고 생각하는 사람일 수 록, 일하기 힘든 co-worker 이며, 다른 사람을 피곤하게 하는 사람이다.

본인은 그렇지 않은 사람이라고 생각할 수 도 있지만, 은근히 그런 사람이 많다. 물론 필자 본인도 그런 부류 중 하나일 것이다.

그런 부류가 될 수 없다면, 최소한 본인이 넘지 않아야 할 선을 넘어서 다른 사람에게 고통을 주고 있는 것은 아닌지, 적어도 일주일에 한번은 체크해보는 사람이 되도록 하자.

오늘 고속 버스를 타면서, 아무렇게나 소리를 지르는 아이를 보고, 인간은 참으로 오만한 동물이라는 생각이 들었다.