When GEF met EMF

이클립스의 GEF(Graphical Editing Framework)를 처음 접하는 개발자는 복잡한 GEF의 프레임워크에 당황하게 됩니다. 참고할 수 있는 자료가 한정되어 있다는 것과 대부분의 학습서가 영문으로 구성되었다는 이유 때문입니다. 한국 IBM에서는 한국의 개발자들이 쉽게 IBM의 제품군과 오픈소스 프로젝트에 참여할 수 있도록 많은 영문 원서를 번역하고는 있지만 한계가 있고, 특히 GEF와 EMF(Eclipse Modeling Framework)에 관련된 내용은 번역된 편수가 적습니다.

이 스크린캐스트를 통해 막연하게 GEF와 EMF에 대한 공부를 하는 한국의 개발자에게 도움이 될것이라고 기대해 봅니다.본 스크린캐스트에서는 이클립스의 프로젝트중 하나인 GEF와 EMF를 사용하여 간단한 네트워크 모델 편집기를 제작하는 방법을 설명합니다. 이 과정에서 스크린캐스트 시청자는 EMF와 GEF를 어떻게 사용하는지에 대한 학습을 할 수 있으며, 이클립스의 에디터 플러그인 개발 절차에 대한 학습도 가능합니다.

함수형언어의 로망 Ocaml

오늘은 공식 홈페이지에 있는 Objective Caml 에 대한 소개에 있는 overview를 살짝 살펴 보며 여담을 해보려고 합니다.

Objective Caml 은 Caml 언어중 가장 인기 있는 변형입니다. 언어의 입장에서 본다면, 핵심적인 부분은 Caml 언어로 되어 있으며 module system 만큼이나 강력한 Object-oriented layer가 sound(건전)하며 polymorphic type system(다형 타입 시스템)과 type inference(타입 추론)을 지닌채로 연결되어 확장된 것입니다.

아마 많은 분들에게는 굉장히 낯설게 느껴지는 용어들이 있을 겁니다.

sound 하다는 것은 safe 하다는 의미와 유사합니다. "잘못이 없는 것을 잘못된 것일 수 있다 라고 알려주기는 할 지언정 잘못된 걸 잘된 거라고 잘못 알려주는 일은 없다." 라는 의미를 지닙니다. 잘못이 없는 것을 잘못된 것일 수 있다고 의심하는 건 불편한 문제이긴 하지만 안정성을 해치지는 않습니다. 하지만 잘못된 것을 잘못된 것이라고 알려 주지 않는다면 이것은 큰 문제를 일으키게 됩니다. 이런 일을 발생하지 않는 다면 이것을 "sound 하다"라고 표현합니다.

사실 C언어가 만들어지던 시기에는 아직 Programming Language자체를 design 하는 것에 대해서 크게 관심이 없었답니다. 주로 어떻게 compiler를 쉽게 만들 수 있을까? 라는 것을 연구를 많이 했죠. 그 결과로 지금은 compiler를 만드는 방법은 완숙한 단계이고 PL 연구자들에게 큰 관심의 대상은 아닙니다.

문제는 그렇게 "이렇게 하면 될 것 같은데?" 정도의 생각으로 만들어낸 언어이다 보니 생각치 못했던 문제들이 많이 발생하게 되었습니다.

바로 bug의 일상화.

bug가 있는 것은 너무나도 당연하게 되는 것입니다.

특히 C언어로 programming 할때 정말 흔하게 접하게 되는 오류가 segmentation fault 에의한 오류 입니다.

기존의 명령형 언어들은 인간의 사고방식 보다는 컴퓨터의 사고방식에 가까이 있는 언어입니다.
최초에는 명령에 번호를 부여해 번호를 가지고 직접 프로그래밍을 했었습니다. 이것이 바로 기계어 이죠. 번호로 프로그램을 짠다는게 상상이 됩니까? 음 이 문제를 해결한 것이 바로 번호대신 연상되는 단어를 사용하자. 라는 것이었습니다. 예컨데 ADD JMP 같은 것이죠. 단지 번호를 단어로 바꾼 것 뿐이죠. 이것이 어셈블러의 탄생입니다. 그리고 자주 사용되는 패턴 몇가지를 묶어 문장으로 만든 것이 현재 사용되는 명령형 언어의 탄생이라고 볼 수 있습니다.
이렇게 기계어에서 부터 조금씩 추상화 되어 올라오면서 구멍을 조금씩 메워 나가는 과정에서 나온 것이 C언어, PASCAL, ... 등등 입니다.

하지만 역시 기반 자체가 약하기 때문에 태생적인 결함이 존재할 수 밖에 없었습니다. 이걸 인지하고 있음에도 표준화 기관에서는 그 문제를 해결하게 되면 현재의 형태와 너무 상이해지는 문제 때문에 그 인기성을 잃게 될 까봐 문제점을 해결하는 것을 포기할 수밖에 없었다는 얘기도 있습니다.

물론 기계에 가깝다는 점은 어셈이 그렇듯이 매우 효율적인 프로그래밍을 할 수 있다는 장점도 갖게 되지만, 발전하고 있는 하드웨어의 성능앞에 그 차이는 큰 의미가 없어지고 있습니다. (속도에 있어서 정말 중요한 것은 compiler에 따른 약간의 performance 차이보다는 logic이나 design에 따른 차이가 더 큽니다.)

소프트웨어 공학을 전공 하신 분이라는 소프트웨어 위기(Software crisis)라는 용어를 한번쯤 들어 보셨을 겁니다. 바야흐로 'bug' 라는 것이 프로그램 개발비용에 있어서 최고의 난적으로 떠오르기 시작한 것이죠.

이것을 해결하기 위해 나타난 도구중 하나가 "type system" 이라는 것이기도 합니다. 하지만, 우리의 용감한 C언어는 매우 약한 type system을 사용하여 융통성있게 type을 무시하는 기능을 제공해주고 있습니다. machine 자체의 동작을 잘 알고 있다면 유용하게 써먹을 수 있는 기능이지만 깜빡 실수라도 하면 굉장히 위험한 것이기도 하답니다.

그래서 아얘 이런 오류 자체가 발생할 가능성을 원천봉쇄한 것이 "strongly typed system" 입니다. "대충 이렇게 하면 될거 같은데?" 라는 발상으로 만들던 기존의 언어와는 달리 최근에는 아얘 "이 언어로 만든 프로그램은 이런 오류는 발생시키지 않는다." 라는 것을 증명할 수도 있습니다.

그리고 바로 이렇게 완벽한 증명의 바탕위에 만들어진 언어들이 functional language 입니다. 때문에 순수한 OCaml의 부분만으로 만들어진 program에서는 절대로 program이 멋대로 down되는 일이 발생하지 않습니다.
(아핫 하지만, 메모리의 한계성에 기인한 stack overflow 라던가-때문에 재귀함수들은 tail-recursive라는 방식으로 구현을 하게 됩니다- 고의적인 infinite loop같은 것은 별개의 문제입니다.)

하지만!!! 이런 순수한 부분만으로 program의 작성만으로는 저수준의 조작이 필요한 program은 작성을 못하게 됩니다. 그래서 library의 형태로 완벽하게 안전하지는 않을 수 있는 것들이 제공되어지고는 있습니다. 어쨌든 이들은 특별한 경우를 위해 제공되는 것일 뿐입니다. 그다지 많이 사용되지는 않는 것들이죠.

sound에 대한 얘기가 이렇게 길어져 버렸군요.. >.<

polymorphic type 으로 넘어가자면, C++ 이나 JAVA 같은 곳에서 흔하게 사용되는 overloading이라는 것을 아십니까? 함수 이름은 같은데 parameter에 따라서 다른 함수가 호출되는 것이죠.

이 overloading이라는 것이 바로 polymorphic을 흉내내기 위해 만들어진 것입니다. 때문에 ad-hoc polymorphism(임시적인 다형성) 이라고 부른답니다. 그나마 functional language의 polymorphism에 가장 가까이 다가가 있는 것이 C++에서 제공되는 template 이라는 것인데 이 녀석은 사실상 macro의 한 형태이기 때문에 제대로 type checking 을 할 수 없다는 치명적인 문제점을 가지고 있습니다.

이와는 달리 ML에서는 정말 제대로된 generic polymorphism을 제공하고 있습니다. polymorphism에 대해서는 나중에 더 자세히 얘기하도록 하겠습니다. :)

그리고 우리의 hope!! type inference(타입 추론) :) 정말 멋진 기능입니다. 우리가 일일이 type을 지정해주지 않아도, 대부분의 경우 compiler가 알아서 type을 붙여준답니다. 치밀한 이론적 배경을 가진 논리적인 type의 추론이기 때문에 실수로 잘못된 type을 붙이는 일은 없습니다.

우리가 의도하지 않았던 type이 붙어있는 것을 발견하게 된다면, 그것은 우리가 그 value를 잘못된 방법으로 사용하려고 했다는 것을 의미합니다. 그리고 실제로 OCaml로 programming을 하면서 가장 많이 접하게 되는 오류 메시지가 바로 이 type 오류 일 것입니다. :)

이렇게 무수하게 발생하는 type 에 대한 오류 메시지가 바로 우리의 program이 안전하게 만드는데 일조를 하고 있는 것입니다.(사실 이것은 strong type하고 밀접합니다.) :)

type inference에 대해 아쉬운 점이 있다면, 이 system으로 인해 overloading을 사용할 수가 없다는 점도 있지만, 이미 더 훌륭한 polymorphic system이 있으므로 overloading을 그다지 중요하지 않답니다.

soundness, polymorphic type, type inference 이것들은 functional programming이 내세우는 대표적인 장점들입니다. 이 장점들을 포기하지 않고 object oriented paradigm을 포함시켰다는 것은 정말 대단한 일입니다. :)

이로 인해서 생기는 O'Caml 의 oop 는 다른 oop 와 차별화 된답니다. (물론 ocaml의 object system에서 부족한 부분도 있기도 하지만 말입니다.) 이 뿐만 아니라 나중에 object에 대해서 다룰 때 언급하겠지만, O'Caml의 object system에만 있는 독특한 feature들도 있답니다. :)

사실 object가 없더라도 이미 module 만으로 충분하지만 표현의 다향성을 위한 것이랄까요?
module system + object system의 결합도 무척 볼만하답니다. :)

나날이 펼쳐지는 멋진 O'Caml의 세계를 기대하세요~
노상훈 2004.10.26

MVC 예찬론

Model-View-Controller Song
Lyrics by James Dempsey

Model View, Model View, Model View ControllerMVC’s the paradigm for factoring your code,into functional segments so your brain does not explode.To achieve reusability you gotta keep those boundaries clean, Model on the one side, View on the other, the Controller’s in between.

MVC 는 코드를 기능에 따라 나눠주는 패러다임이지
우리의 머리가 쉴 수 있게 해주지
재사용을 위해서는 깔끔하게 나눠줘야 한다네
한쪽에는 모델이, 다른 편에는 뷰가 , 그 사이에는 컨트롤러가 있다네

Model View - It’s got three layers like Oreos do.Model View creamy Controller

모델 뷰, 크림 샌드 쿠키처럼 삼층으로 되어 있지
모델 뷰 컨트롤러
모델 뷰, 모텔 뷰, 모델 뷰 컨트롤러

Model objects represent your applications raison d’tre.Custom classes that contain data logic and et cetra.You create custom classes in your app’s problem domain,then you can choose to reuse them with all the views,but the model objects stay the same.

모델 객체는 애플리케이션의 존재의 의미지
데이터, 논리 같은 게 전부 들어있는 객체지
그 클래스는 애플리케이션이 문제 해결을 위한
클래스지
어떤 뷰에 대해서도 재사용할 수 있지
뷰가 바뀌어도 모델 객체는 그대로 남지

You can model a throttle in a manifold,Model level two year old.Model a bottle of fine Chardonnay.Model all the twaddle stuff people say.Model the coddle in a boiling eggs.Model the waddle in Hexley’s legs.

자동차의 움직임도 모델로 만들 수 있고
아이의 뒤뚱거림도 모델로 만들 수 있어
근사한 와인도 모델로 만들 수 있고
사람들 말하는
것도 모델로 만들 수 있어
물 속에서 팔팔 끓는 달걀까지도
바닷물의 출렁임도 모델로 만들 수 있어

One, two, three, four.Model View - You can model all the models that pose for GQ.Model View Controller

모델 뷰, GQ 모델의 포즈도 모델로 만들 수 있네
모델 뷰 컨트롤러

View objects tend to be controls that view and edit,Cocoa’s got a lot of those, well written to its credit.Take an NSTextView, hand it any old Unicode string,the user interacts with it, it can hold most anything.But the view don’t knows about the Model:That string could be a phone number or the words of Aristotle.Keep the coupling loose and so achieve a massive level of reuse.

뷰 객체는 표시하고 편집하기 위한 컨트롤
코코아에는 훌륭한 컨트롤이 가득하네
NSTextView 하나만 집어서, 아무 유니코드
문자열이나 건네줘 보세
사용자가 조작할 수도 있고, 거의 무엇이든 담을 수 있네
하지만 뷰는 모델의 대해 모른다네
그 문자열을
전화번호일 수도 있고, 아리스토텔레스의 작품일 수도 있네
연결을 느슨하게
재사용용을 최고로 끌어 올리세

Model View - All rendered very nicely in Aqua blueModel View Controller

모델 뷰, 아쿠아 블루로 멋지게 표시되네
모델 뷰 컨트롤러

You’re probably wondering now.You’re probably wondering how,the data flows between Model and View.The Controller has to mediate,between each layer’s changing state,to synchronize the data of the two.It pulls and pushes every changed value.Yeah.

궁금하겠지
궁금할거야
데이터는 모델과 뷰 사이에서 움직이지
컨트롤러는 둘 사이의 중계자
각 계층의 상태가 바뀔때면
그
둘의 데이터를 동기화 시켜주지
바뀐 값들을 부지런히 날라주지

Model View - mad props to the smalltalk crew!for Model View Controller

모델 뷰, 스몰토를 만든 이들에게 영광 있으리
모델 뷰 컨트롤러

Model View - it’s pronouced Oh Oh not Uh UhModel View Controller

모델 뷰, 어어가 아니라 오오라네
모델 뷰 컨트롤러

There’s a bit more on this story, a few more miles upon this road,well nobody seems to get much glory writing controller code.Well the model is mission critical and gorgeous is the view,But I’m not being lazy, but sometimes it’s just crazy how much code i write is just glue.And it wouldn’t be so tragic,but the code ain’t doing magic:it’s just moving values through.And I wish I had a dimefor every single time I set a TextField’s stringValue.

이 얘기도 거의 끝나가네
조금만 더 가면 된다네
컨트롤러 코드를 만드는 사람들은
그리 빛을 발하지 못하네
모델은 중요한
임무를 맡지
뷰는 예쁘게 치장하고 사람들 앞에 나타나지
나는 게이름뱅이. 하지만 때론 미쳐 돌아가지
아무리 많은 코드를 작성해도
연결 고리만 될 뿐이지
그리 비참한 것은 아니라네
별 볼일 없는 코드긴 하지만 말이지
열심히 값을 떠 날라
주지
텍스트필드에 문자열을 보낼때마다
100원씩만 받아도 좋겠어

Model View - how we’re gonna deep-six all that glueModel View Controller

모델 뷰
어떻게 하면 지루한 일을 집어치울까
모델 뷰 컨트롤러

Controller’s know the Model and View veryuahh - intimately They often are hardcoding which is very verboten for reusability.But now you can connect any value you selectto any view property.And I think you’ll start binding,then you’ll be finding less code in your source tree.Yeah I know I was astounded,that’s not even a rhyme.

컨트롤러는 모델과 뷰 모두하고 친하네
재사용의 가장큰적, 하드코딩도 종종 쓴다네
하지만 모델키를 어떤 뷰 속성에도 마음대로 연결할
수 있다네
일단 연결을 하다보면
소스 트리에 들어가는 코드는 그리 많지 않을 듯해
남들이 자동해 해놓은 것 때문에 우쭐해
있어
그건 꽁짜로 얻을 수 있는 것이지

But I think it bares repeatingall the code you won’t be needing,when you hook it up in IB.

인터페이스 빌더에서 연결하기만 하면
똑같은 코드를 반복해서 만들지 않아도 되지
자동으로 해주니깐

Model View - it even handles multiple selections tooModel View Controller

모델뷰 여러군데를 선택한 것도 처리해 주네
모델 뷰 컨트롤러

Model View - hope I get my G5 before youModel View Controller

모델 뷰 분명히 남들보다 먼저 완성할거야모델 뷰 컨틀롤러

Yeah, yeah, yeah. Yeah.

예예예예

F# Language

F# -functional/imperative Mixed Language
함수형(functional)/절차형(imperative)의 혼합형의 프로그래밍언어는 프로그래밍 환경에 환상적인 패러다임이다. F#은 혼합형 프로그래밍 패러다임을 가지고 있는 프로그래밍언어이다.

Ocaml과 표준ML은 간단하고, 효율적인 표현으로 프로그래밍과, 제품개발, 그리고 에러율을 낮추고 제품수준을 높히려는 준-고급 프로그래머에게 최고의 프로그래밍문법을 제공한다.

F# 은 Ocaml 과 비슷한 핵심 언어를 가지고 있는 또다른 ML 계열의 언어로 .NET Framework의 가장 최상위에서 작동하며,이 언어는 "ML that fits with .NET" 이라는 목표로 개발되었다.

F#은 언어 전역에서 확장기능이 포함되어있다. 그리고 주로, C#이나 Visual Basic과 같은 .NET Framework 이하의 언어와 툴과 무손실로 연동되도록 핵심을 맞추었다. 또한 F#은 모든 .NET Framework의 API를 즉각적으로 액세스 할수 있다. 예를 들어 WinForm들과, DirectX같은것을 말한다. 또한 F#은 Caml을 핵심 언어로 했기 때문에, 많은 Caml 의 라이브러리를 크로스 컴파일하여, 개발하려는 프로그램에 사용할수 있다. 따라서, Caml 코드를 .Net 코드로 포팅(porting) 할수 있다.

F# 은 F# for Visual Studio로 Visaul Studio 2003과 Visual Studio 2005 beta 2 에서 Build/debug환경과 그래픽 디버깅, 인터랙티브형 문법 하이라이팅, 파씽과 타입체킹, 코드센스, 메쏘드팁과 같은 기존의 IDE환경에 제공하는 형태로 제공된다.

from : http://research.microsoft.com/en-us/um/cambridge/projects/fsharp 사이트내의 글이 었는데, 지금은 없네요. ^^;

해석 : 직접했음(오역이있을수 있으나 거의 비슷해요)

Abstraction(추상화)

[그림 1] 몬드리안의 나무

공대생이 보는 수많은 참고서에 보면 예외없이 등장하는 단어는 바로 '추상화' 이다. 추 상화라는 단어의 뜻은 주어진 문제나 시스템을 중요하고 관계 있는 부분만 분리해 내어 간결하고 이해하기 쉽게 만드는 작업이다.

이러한 과정은 원래의 문제에서 구체적인 사항은 되도록 생략하고 핵심이 되는 원리만을 따지기 때문에 원래의 문제와는 전혀 관계가 없어 보이는 수학적인 모델이 나오기도 한다.

이 기법은 복잡한 문제나 시스템을 이해하거나 설계하는 데 없어서는 안될 중요한 요소이다. 때문에 추상화가 많이 되어진 모델은 내부적인 개념을 이해하기가 점점 어려워진다. 그렇다면 왜 컴퓨터관련서적에 이리도 많은 추상화라는 단어가 나올까?

[그림1]은 몬드리안 -[Mondrian, Piet, 1872.3.7~1944.2.1 네덜란드의 화가 ]- 의 작품이다. 추상화의 과정을 함축적으로 보여준다. 인간이 이해할수 있는 가장 근본적인 내용만 담고 있다. 하지만 마지막 그림만 떼어놓고 본다면, 그림의 원래의 모습을 전혀 유추할수 없을 것이다. 이런것이 추상화 이다.

컴퓨터에서의 추상화는 크게 두가지로 구분된다. 데이터추상화와 콘트롤추상화이다.
데이터를 추상화한다는것은 어찌보면, 과거부터 오래된 관습들과 수학적 개념들이 배후에 깔려있다.

예를들자, 어떠한 물건이 세개가 있다. 사람들은 공통적으로 약속을 하게된다. 어떠한 물건이 세개가 있을때 우리는 그걸 직접 그리지 말고, 기호를 이용하여 '3' 이라고 표시하기로...

그리고 그 숫자들과 숫자들이 할수 있는 모든 행위들을 나열해 주는 것이다. 세개의 과일과, 두개의 나무가 있다. 총 몇개인가? 총 5개

어떻게 머리속으로 생각이 됬을까? 3+2 가 생각됬다면 정상적으로 초등학교 산수를 마친것이다. 그렇다. 3은 세개라는 개념의 추상화된 수학적 모델이고, 각 수학적 모델은 더하라라는 연산을 + 라는 기호를 이용하여 추상화 했다.

인간이 가진 직관이나 논리를 일련의 식으로 나타내어 추상화를 수행할 수 있다.

컴퓨터에서의 추상화도 이와 같다. 컴퓨터라는 기계는 1하고 0만 이해할수 있는 정말 무식한 놈이다. 그런데 우리가 많이 쓰는 C언어에서는 컴퓨터가 변수에 값을 할당도 하고, 조건분기도 하며, 반복도 시켜준다. 정말 대단하지 않은가? 이것들이 바로 추상화의 과정을 거친것이기 때문이다.

값을 대입한다(assignment)

int a=2;

이렇게 추상화 되어 있는 식으로 부터 우리는 a 라는 변수에 정수 2를 넣는구나 할 것이다. 그러나 컴퓨터 입장에서 본다면 저 한줄은 정확히 4바이트의 기억공간에 00000~00010 을 넣는 행위가 될수 있다. 추상화된 것을 더 구체화해 살펴보면 컴퓨터의 일정 메모리영역에, 전기를 넣었다가 뺏다가 하면서 어떠한 상태를 유지하는것이다. 그러나 우리는 전기가 어떻게 작동되고 있는지 고려할 필요는 전혀 없다. 그냥 값을 대입하고 싶으면 a=3, b=2 와 같은 식으로 작성하기만 하면 나머지는 컴퓨터가 알아서, 해줄것이다.

컴퓨터가하는 연산들도 마찬가지이다. c=a+b 와 같은 것이 말이 되는가?
a+b를 더하면 a가 b만큼 더해져야 되지 않턴가? 우리가 배운 수학만 가지고 계산한다면 저 문장은 절대 풀수 없다. 추상화는 주어진 환경에 따라 아무 민감하다. 일반수학에서는 c는 a+b와 같다?? 가 되지만 프로그래밍언어인 C에서 이 문장은 a+b를 먼저 계산하고, c 변수에서 그 결과를 저장하자. 라는 개념을 추상화하는 것이다.

추상화는 우리가 대단히 이해하기 힘들고 복잡한 내부 과정과 개념들은 모두다 덮어두고, 이해하기 쉬운 구조만 표현해 내는 정말 대단한 기법이다. 조금만 깊게 생각해보면 우리가 사는 세상의 거의 대부분도 이 추상화라는 기법을 이용하고 있다.

Turing Machine

"튜링은 동성애자라는 이유로 체포되었고, 감옥에 갈 것인지 아니면 여성호르몬 에스트로겐을 맞을 것인지의 기로에서 후자를 선택했다. 호르몬 주사의 영향으로 신체의 변화를 겪게 되자 튜링은 모멸감을 견디지 못해 주사기로 사과에 청산가리를 주입한 후 백설공주처럼 독사과를 한 입 베어 먹고 자살했다. 53년 그의 나이 겨우 42세였다."

컴퓨터의 아버지, 세계 최초의 해커, 알란 튜링

배척의 원리는 자유롭게 사귀도록 내 버려둔다면 타락할지도 모를 사람들에게만 적용된다. - 알란 튜링 (Alan Turing, 1912-1954, 영국)

그가 있기에, 지금의 우리가 있다고 말해도 과언이 아니다. 그래 분명한건 누군가는 분명히 알란이 생각했던것과 똑같은 이론을 구했을지 모르겠다. 사실 알론조 처치의 람다 계산법이 튜링머신과 같은 시스템이라는 것도 정설로 받아들여지고 있다.

혹자는,

"에이~~ 저양반이 개발한게 컴퓨터야?!", "IBM은?!","APPLE은?!","그래도, 프로세서는 Intel Inside 지..."

프로그래밍언어론 시간에, 교수님은 프로그래밍 언어의 본질에 대해 이야기해 주셨다!

머 익히 다들알고 있는 것이겠지만, 수업은 다음과 같이 질문으로 시작했다.

"컴파일러는 왜 모양이 다 다르지?! C면 C지 왜 C++, Java, Basic...이런걸 만들어서 자꾸 배우게 하나?! 정말 다른건가?!", "C로 만들수 있는걸, Basic으로 못만드나?!"

교수님의 질문에 난 자신있게,

"당연히 다른언어로 할수있고, 결과적으로 언어의 본질은 다 같습니다. 이유인즉 어차피 프로그램은 기계어로 바뀔수 밖에 없거든요~~"

이랬더니!! 교수님은 그에 대해 장대하게 설명해 나가기 시작했다!
설명은 Turing Completeness 에 대한것이었다. 모든 언어는 본질적으로 같다. 다양한 언어들이 있지만, 결국 튜링 머신에 의해 계산되는 것이다. 컴퓨터 과학에서 이것은 컴퓨팅 파워에 관한 것이다. 따라서 다음과 같은 대화는 오류가 있다.

철수 : 휴~~ 이번 프로젝트는 JAVA로 해야겠어~~
규리 : 왜!? BASIC으로는 못해?!
철수 : 응!! 아마 그런 기능이 없을꺼야!!! (Library..)

위의 대화는 다음과 같이 고쳐져야 한다.

철수 : 휴~~ 이번 프로젝트는 JAVA로 해야겠어~~
민혁 : 왜!? BASIC으로는 못해?!
철수 : 할수는 있지만, JAVA로 하는게 더 편해!! 라이브러리가 막강하거든,

컴퓨터 과학과 엔지니어링

마냥, 컴퓨터가 좋기만 했던 시절이 있었다. 아침에 눈을 뜨면, 컴퓨터에 자동으로 손이갔고, 컴퓨터가 부팅이 완벽하게 되어 그립던C:\>_가 나타나서, 깜빡깜빡 거리며, 마치 긴생머리의 귀엽고 아름다운 소녀가 눈을 똘망똘망 뜨며,, 그 눈동자 속에서 나의 모습을 보는것같은 느낌이 들어야지만, 이빨을 닦던 세수를 하던 밥을 먹었던 시절이었다.

가족들이 다들 피서를 갈때, 이제 컴퓨터를 약 48시간동안 못하겠구나, 가지말까?! 하고 고민하던 시절이 있었다. 이제는 어느덧 시간이 벌써 10년씩이나 흘렀고, 그때당시에 과학잡지에서나 보였을범짓한 일들이, 이제는 실제로 일어나고 있다, 전세계 컴퓨터의 네트웤으로 이제는 모든컴퓨터의 자원이 서로 공유되고 있고, 정보의 가치는 무한히 상승해 정보자체가 돈이 되는 세상이 되어버렸으며 홈네트워크로 핸드폰이라는 기계로 집에 있는 각종 가전제품을 제어하고, 유비쿼터스로 인해 이제는 모든 컴퓨터속에 인간이 감시를 받고 사는 시대가 된것이다. 내 옆에서 게임을하고 있는(컴퓨터고장으로 피씨방에서 집필을,,ㅜㅜ) 사람도 어쩌면 나를 감시하는 사람일지도 모른다는 생각이 드는 세상이 온것이다.

요즘들어 나는 부쩍이나 생각이 많아졌다. 컴퓨터과학과, 컴퓨터 엔지니어링에 대해서 페이퍼를 써야겠다고 생각하고, 벌써 2주일이 흘렀다. 그동안 아무리 생각해도 컴퓨터과학과 엔지니어링의 차이를 알수가 없었다. 너무나 힘겹게 다른 여러 사이트를 보고, 몇몇 교수님들의 논문을 보구나서, 내 나름대로의 컴퓨터과학이라는 학문과 컴퓨터 엔지니어링에 대해 알수가 있었다.

필자가 여러 사이트를 찾아보건데, 컴퓨터 사이언스(CS)라 하는것은, 다음과 같다.
컴퓨터사이언스 = { 컴퓨터에대한 공부, 컴퓨테이셔널(computational) 시스템, 이론과, 디자인, 인공지능, 컴퓨터 시스템, 데이터베이스 시스템, 프로그래밍언어, 소프트웨어이론, 컴퓨터수학... }

우리가 하고 있는 프로그래밍이라는 것은 컴퓨터 과학 범주안에 있는 하나의 원소일뿐인것이다. 컴퓨터 과학자는 문제를 푸는사람을 말하는데, 여기서 푼다는것에 범주는 문제를 정의하고 그 문제를 과연 컴퓨터로 풀수 있을까 하는 것을 걱정하는 사람이다.

실질적으로 문제를 푸는 사람은 컴퓨터 프로그래머가 될것이다. 자 그렇타면, 컴퓨터 엔지니어링은 멀까?!컴퓨터 엔지니어링이란 새로운 컴퓨터과학의 응용품들을 매일같이 개발하는 것이다.

컴퓨터엔지니어는 컴퓨터과학과 전기공학으로 만난 일종의 우리가 쓰고 있는 컴퓨터에 쓰일 프로그램을 만드는 사람들이라 하겠다. 물론 전기공학과 컴퓨터과학으로 만난 것들에는 모바일폰이나, PDA같은 여러가지 제품들이 있다.

컴퓨터엔지니어는 컴퓨터라 불리는 모든것을 제어하는 컴퓨터세상의 신과 같은 존재가 되는것이다. 물론 그러기 위해선 각종 스펙을 줄줄꽤고 있어야겠지만 말이다.

정리를 하겠다. 컴퓨터과학과, 컴퓨터 엔지니어링, 대충보면 둘은 별반 차이가 없을꺼 같이 보인다. 그렇지만 CS와 CE 는 분명한 차이가 있다. 컴퓨터과학은 컴퓨터라는 기계 혹은 이론자체를 연구하는 학문이지만, 컴퓨터공학은 컴퓨터의 이론적인 사실을 받아들여서, 실제로 쓸수있는 먼가를 만들어 내는 학문이다. 처음에도 설명했지만, 필자는 이 두가지 학문을 상위 하위 개념으로 보았다. 그러나 시간이 지나면서 점점 두가지 학문은 동등한 레벨의 학문으로 봐야된다는데에 동의한다. 컴퓨터라는 제품을 만드는 회사와, 그 컴퓨터속에 들어있는 초고밀도직접회로(VLSI)를 만드는 회사 처럼 말이다. 이만큼 글을 쓰고 나니, 갑자기 머리속에서 정리한것들이 요동친다. 그렇다면 컴퓨터과학이 연구하는 컴퓨터의 본질이 머란말인가, 엔지니어링은 과학없이는 않되는것인가?

자료출처 :
http://www.umd.edu/
http://jamesthornton.com/
http://www.ece.uwaterloo.ca/~www_info/whatis_ce.html
http://web.mit.edu/catalogue/degre.engin.elect.shtml

늘 느끼는 거지만, 내가 알고있는것 즉 내 머리속에 뇌세포가 기억하고 있는것을 언어또는 글이라는 에너지를 통해 남의 뇌세포에 넣는다는 것은 참으로 신기한 일이다. 남이 쉽게 읽고 편안하게 받아들이는 책이 있는가 하면, 읽고읽고 또 읽어도 쉬운내용이지만 이해되지 않는 책이 있다.

글쓰기는 정말 어려운 일인것 같다.