이제 3월에 개학하면 4학년이 됩니다. 생각해 보면 사회 진출에 대해 그다지 생각을 안 해봤던 것 같습니다. 병역 특례로 사회 경험, 회사 생활을 했다고는 하지만, 졸업을 안한 상태에서 다닌 회사의 느낌은 사실 군대와 크게 다를 바가 없는 것 같습니다. 진짜 사회에 나왔다는 느낌보다는 앞으로 나올 사회에 대한 연습이란 느낌이 강하거든요.

지금까지는 막연히 학부를 졸업하면 석사나 석박 통합 과정에 진학해야겠다고 생각을 했습니다. 사실 공대 박사 과정에 대해서 별로 환상은 없습니다. 다른 분야와는 달리 공학 박사는 자기 전문 분야의 박사일 뿐이지 ‘지식인’이란 느낌이 들지 않습니다. 사회생활을 통해 만나본 박사님들도 제가 생각했던 모습은 아니었던 것 같습니다.

병역 특례를 마치고 학교로 돌아온 많은 친구들이 더 이상 컴퓨터로 밥 먹고 살고 싶진 않다고 합니다. 병역 특례의 특성상 여건이 열악한 중소 벤처를 경험했기 때문 일수도 있지만, 비교적 여건이 나은 업체에서 일했던 친구들도 생각이 별반 다르지는 않습니다. 이미 치학전문대학원으로 진학한 친구들도 있고, 진로를 바꿔서 공무원이나 공기업을 준비하는 친구들도 많습니다.

지금 당장은 국가의 산업 발전을 책임질 이공계의 산업 역군이란 단어는 설득력이 없습니다. 당장 무엇을 해서 어떻게 살아가야 좋을지에 대한 생각이 먼저입니다. 비범한 천재들처럼 남들과는 다른 뚜렷한 비전 같은 것도 없습니다. 요즘은 그저 남들은 뭐해서 먹고 사나 그게 궁금합니다.

너무 보잘 것 없다는 생각이 듭니다. 거대한 나라, 기업, 사람들, 그 속에서 내가 할 수 있는 일, 나밖에 할 수 없는 일이란 게 있을까요? 아니면 최소한 나 스스로가 만족하면서 할 수 있는 일이란 게 있을까요? 아차, 그것만으로는 부족합니다. 남들만큼 혹은 그 이상 돈도 벌고 싶고 행복이란 게 있다면 그걸 찾아보고도 싶습니다. 나는 무엇을 해야할까요?

윤석찬님의 글 ‘오픈 소스 개발자 그들을 주목하라’을 읽고 의견을 달아봅니다.

오픈 소스(Open Source)가 중요하다는 말이 많이 들린다. 구글과 IBM 같은 굴지의 대기업이 오픈 소스를 지원해서 어떤 반사 이익을 얻는지에 관한 분석도 쉽게 찾아 볼 수 있다. 하지만 정작 우리 주변의 개발자들과 이야기를 나눠보면 오픈 소스가 아직까지 바다 건너 다른 동네의 이야기란 생각이 든다. 오픈 소스 세상에서 우리나라 개발자들은 여전히 닫힌 세상에 살고 있는 것이다.

사실 그렇게 비관적인 것만은 아니다. 우리나라 개발자들은 실은 오픈 소스에 무척 익숙하며 많은 혜택을 누리고 있다. 우리나라에서 소프트웨어 개발은 대가가 중소 규모의 벤처 업체를 중심으로 이루어진다. MS나 썬, IBM처럼 신제품 개발에 필요한 컴포넌트나 라이브러리를 업체가 소유하고 있는 경우는 드물다. 필요한 코드는 전부 외부에서도 조달해야 하고, 규모가 영세한 벤처 기업이 코드를 조달할 수 있는 곳은 결국 오픈 소스이다.

예를 들어 현재 개발하는 제품이 이미지 디코딩(image decoding) 기능이 필요로 하면 어떻게 하는 게 좋을까? JPEG, GIF, PNG 등의 이미지 포맷 명세서를 보고 처음부터 다시 디코더를 만들 것인가? 성능 좋은 디코더를 개발하는 게 주업인 업체가 아닌 이상, 영리한 개발자라면 오픈 소스 프로젝트를 찾아볼 것이다. 각각의 포맷에 대해 이미 검증된 오픈 소스 프로젝트(libjpeg, libungif, libpng)가 있음을 알 수 있다. 영리한 개발자라면 이런 오픈 소스를 적극 활용할 것이다.

그런데 왜 기여는 안하는 것일까? 가져다 쓸 것은 많지만 딱히 기여할 만한 것들은 없어서일까? 근데 개발 활동이라는 게 그럴 수가 없다. 개발은 필연적으로 부산물을 만들기 마련이다. S/W 컴포넌트는 전자 부품처럼 해당 규격의 부품만 끼운다고 곧바로 동작하지 않는다. 간단한 라이브러리 하나를 가져오더라도 현재 제품에 맞춰 수정해야 하며 이 과정에서 불충분한 기능 하나 두쯤은 직접 개발하게 된다. 필요한 기능을 추가할 수 있다는 게 오픈 소스의 가장 큰 매력이니깐 말이다. 또 오픈 소스가 널리 사용되는 만큼 어느 정도 안정성이 검증되어 있다지만, 이를 가져와서 사용하다보면 필연적으로 부족한 기능이나 버그를 발견하기 마련이다.

적극적으로 프로젝트를 개발하고 운영하진 못할지라도, 이렇게 오픈 소스를 활용하는 과정에서 생긴 부산물만 적극적으로 다시 오픈 소스 프로젝트에 환원한다면 우리나라도 오픈 소스에서는 손꼽힐만한 나라도 부상할 수도 있다.

근데 현실은 왜 이럴까? 첫 번째 이유로 개발업체가 오픈 소스 프로젝트 활용하고 있다는 사실을 숨기기 때문이다. 공개를 떳떳하게 하지 못하는 이유로 보통은 라이선스(license) 문제를 든다. 상당수의 오픈 소스가 코드를 공개하라는 요구를 하는 GPL로 작성되어 있기 때문이다. 아파치(Apache)나 BSD 라이선스처럼 비교적 자유로운 이용을 허용하는 경우도 있지만, 아직까지 코드 공개가 회사 자산 전부의 유출이라고 해도 과언이 아닌 중소 벤처가 이를 수용할 수 있을 리가 없다.

라이선스 문제만이 아니다. 우리나라에서 오픈 소스의 이용을 공표하는 것은 실상은 그 업체가 자체적인 기술력이 없음을 보여주는 커밍아웃에 가깝기 때문이다. 우리나라에는 원천 기술이 없다는 이야기를 많이 하는데 실상이 그렇다. 상당수의 상용 제품들이 실상은 오픈 소스 프로젝트를 가져다가 외양을 바꾸고 예쁘게 치장해서는 마치 새로운 제품인 것처럼 팔기 때문이다.

초창기 난립했던 보안 업체들이 만든 상당수의 방화벽(firewall)이나 침임탐지시스템(intrusion detection system), 암호 시스템 등이 대부분 OpenSSL 같은 오픈 소스 프로젝트를 가져와 시작했다는 이야기가 있다. 개발자가 한 회사 제품의 소스만 이해하면, 다른 회사로 옮겨도 업무를 파악하는데 별로 시간이 걸리지 않는다는 이야기가 있었을 정도다.

또 하나의 문제는 의사소통의 장애일 것이다. 의사소통이라는 게 개발자들의 영어 실력만을 문제시하는 것은 아니다. 언어가 첫 번째 장벽이라면, 두 번째 장벽은 의사소통 그 자체에 있다. 오픈 소스를 가져다가 자기 입맛에 맞게 고치는 일은 혼자서 해치울 수 있지만, 패치를 제출하고 버그를 보고하는 일은 다른 개발자들과 소통을 필요로 한다. 코드에 기능을 추가하거나 수정을 가했으면, 어떤 이유에서 그러한 수정을 했는지 명확히 전달할 수 있어야 한다. 하지만 다른 오픈 소스 개발자들과 적극적으로 의사소통을 하고, 내 의견을 전달하는 것이 생각보다 힘든 과정이다.

우리나라 오픈소스 개발의 현황을 살펴보면 이런 점이 두드러진다. 대부분의 개발자가 다른 개발자와의 의사소통을 힘들어한다. 어렵게 시작한 국내 오픈 소스 프로젝트도 다른 개발자의 도움을 받는 일이란 극히 드물다. 개발자들은 의사소통이 어려워서 기존의 프로젝트에 참여하기보다는 자신만의 새로운 프로젝트를 만드는 쪽을 선호한다. 그래서 오픈 소스 프로젝트는 대부분 아이디어 선에서 정체되어 있는 경우가 많으며, 이름만 다른 유사 프로젝트가 전부 초기 단계에서 벗어나지 못하는 웃지 못 할 상황이 벌어지고 있다.

정리하면 우리나라에서 오픈 소스 하기란 어렵다. 사실 많은 사람들이 오픈 소스를 이야기하는 만큼 오픈 소스를 후원함으로써 직접적인 이익을 얻을 수 있는지도 의문이다. 구글이나 IBM 정도의 거물 S/W 회사라면 뭔가 비전을 가지고 이를 전략적으로 활용할 수 있겠지만, 당장 한 명의 개발 인력이 아쉬운 중소 규모의 우리 벤처가 거창하게 오픈 소스를 후원한다는 것도 실상은 우스운 면이 많이 있다.

하지만 개발자 개인의 입장에서 보면 오픈 소스는 여전히 매력적이다. 회사 일과 별개로 자신이 만들고 싶은, 자신이 필요로 하는 제품을 만들 수 있는 즐거움은 개발자들의 특권이다. 개발자가 천대 받는 한국 IT 현실에서 세계의 개발자들과 소통하며 인정받는 일은 누구나 누릴 수 없는 기쁨이기도 하다.

또한 오픈 소스 프로젝트는 자신이 스스로 결정하기 힘든 회사 프로젝트와는 별개로 자신의 경력을 쌓을 수 있는 곳이다. 사실 혼자 공부하고, 학교에서 배우는 것만으로는 실제 개발에 필요한 실용적인 지식을 습득하기 어렵다. 오픈 소스는 큰 규모의 소프트웨어를 어떻게 개발해야 하는지를 배울 수 있는 이상적인 장소이다. 이렇게 쌓은 경력은 자신의 커리어를 만들어 나가는데 중요한 역할을 한다. 구글이 채용한 파이썬 프로젝트의 반 로섬, 파이어 폭스 개발자인 벤 구저, Gaim 개발자인 션 이건 등 유명한 오픈 소스 개발자들도 다들 자기만의 작은 프로젝트로 시작한 것이다.

미국 대학에서는 소프트웨어 산업으로 나아갈 학부 졸업생들을 위해 실용적인 프로그래밍 과목을 개설하는데, 여기서 빠지지 않는 것이 오픈 소스 프로젝트에 기여하는 것이다. 메릴랜드 대학의 경우 ‘CMSC433 프로그램 언어 패러다임과 기술’의 프로젝트 중에 하나가 오픈 소스 프로젝트를 하나 선정하고, 여기에 버그 패치와 기능 추가 등의 구체적인 활동을 해서 보고서를 제출하는 일이다. 이런 과정을 통해 학생들은 자연스럽게 오픈 소스 개발 과정을 몸에 익히고 업계에 진출해서도 오픈 소스를 적극 활용한다.

우리도 당장 자기 업무에 사용하는 오픈 소스에 작은 패치라도 하나 제출해 봄이 어떨까?

왕멀님의 “디자인패턴에 빠져봅시다. Head First Design Patterns“을 보고 써봅니다.

2005년 마소 11월호에 “디자인 패턴과 프로그래밍 언어”라는 주제로 글을 쓴 적이 있는데, 재미있게 잘 보셨다는 분과 무슨 소리인지 전혀 모르겠다는 분으로 반응이 나뉘더군요. 디자인 패턴이 별 것 아닌 것처럼 보여도 설명하려면 꽤 까다롭다는 걸 그때 알았습니다. GoF를 비롯한 디자인 패턴 책이 어렵다고 하시는 분들도 많고요. 이때 혜성 같이 등장한 패턴계의 반항아가 있었으니, 헤드 퍼스트 디자인 패턴입니다.

『Head First Design Patterns』(Freeman, O’Reilly, 2004)은 Univ. of Maryland에서 교환학생으로 있을 때 들은 CMSC433 Programming Language Technologies and Paradigms이란 과목의 교재 중 하나였습니다.

과목 성격 자체가 실용 개발 교육에 가까웠던지라 처음 한 달 반 정도를 디자인 패턴에 할애하더군요. 처음에 교과서를 보고 그 가벼움에 놀랐습니다. 그림이나 예제도 풍부할 뿐더러 패턴이 무엇인지 가르치기 보다는 패턴이 왜 필요하고 어떻게 탄생했는지를 자연스럽게 보여줍니다. 마치 물고기를 던져주기 보다는 낚시하기 법을 가르치는 셈이죠.

헤드 퍼스트 시리즈가 이런 기획으로 출판계에 나름 돌풍을 일으켰던 것 같은데, 헤드 퍼스트 시리즈는 디자인 패턴 말고 자바, 서브릿(Servlet), 오브젝트 등 여러 주제가 있습니다. 확인은 못했지만 아마 비슷한 형태로 기획한 듯싶습니다.

다음은 수업 시간에 참고한 디자인 패턴 관련 참고 자료입니다.

• Design patterns reading groups 
• OO Principles 
• Big Moose Saloon on Design Patterns 
• Design Patterns web page 
• Portland Pattern Repository 
• Design Pattern catalog at Rice 
• Another design pattern catalog

객체지향프로그래밍(이하 OOP)는 ‘잡힐 듯이 잡히지 않는 사랑’일까? 소프트웨어 개발자 K 씨는 지난 3년간 현장에서 자바를 이용해 프로젝트를 수행해 왔다. K는 클래스를 디자인 하고, 클래스의 객체를 생성하며, 메시지 패싱을 통해 프로그램을 수행하고, 필요에 따라 클래스를 상속 받아 새로운 클래스를 정의하기도 한다. 이제 K 씨에게 질문을 해보자. 그렇다면 도대체 OOP는 무엇이라 정의할 수 있습니까?

“음, 모든 소프트웨어는 객체로 이루어져있고…… 음……”

사실 OOP 언어를 배울 수는 있어도 OOP가 무엇인지 개념을 잡기는 힘들다. 수년 동안 객체지향 기술로 프로젝트를 수행해 온 베테랑 개발자들조차 정작 OOP가 무엇인지 물으면 확신을 갖고 이야기하지 못한다. 혹은 주섬주섬 개념을 주워 섬기지만 숙련된 개발자들 사이에서도 통일된 OOP의 정의를 발견하기란 어렵다.

OOP가 무엇이냐고 물으면 어설프게 단어를 늘어놓는 수밖에 없다. OOP는 객체, 클래스, 데이터 캡슐화, 상속, 메쏘드, 메시지 패싱, 폴리몰피즘(Polymorphism), 추상화, 정보 은닉 등등 OOP스러운 단어들이 모여서 유기적으로 하나의 패러다임을 형성했다는 정도랄까? 개개의 개념이 어떤 식으로 서로 얽혀 있는지 내가 사용하는 프로그래밍 언어는 저 개념들을 어떤 식으로 비벼서 맛있는 밥으로 만들었는지 설명하려면 그저 막막하기만 하다.

『 Communcations of the ACM 』 Feburary 2006/Vol 49, No.2에 실린 ‘The Quarks of Object-Oriented Development’(이하 CACM)는 이 문제를 정면으로 다루고 있다. 1960년대 시뮬라(Simula) 언어가 처음 OOP의 개념을 도입한 이래 어느 누구도 이것이 OOP의 전부다라고 정의하지 못했다. 각자 자신의 필요에 따라 몇 가지 개념을 정의하고, 나머지는 널리 알려져 있다고 가정해 버린 것이다.

여러 학자들과 개발자들이 ‘OOP의 핵심(essence)이 무엇이냐’라는 질문을 대답하려고 애썼지만 아직까지 어디까지가 OOP인지는 결론을 못보고 있다. 저자 암스트롱(Armstrong)은 OOP의 핵심에 대해 이야기 하려고 한다. 저자가 제목에 사용한 쿼크(quarks)라는 단어는 물리에서 더 이상 쪼갤 수 없는 가장 작은 입자의 단위를 말하는데, OOP에서 이런 쿼크가 되는 개념이 무엇인지 찾아 나섰다.

여기서 저자가 사용한 접근 방식이 흥미롭다. 암스트롱은 1966년부터 2005년까지 출간된 객체지향개발 관련 저널, 서적, 컨퍼런스 등을 망라하여 총 88개 자료에서 OOP의 개념이라고 정의한 요소들을 샘플링 해내었다. 그 결과 상속(88%), 객체(78%), 클래스(71%), 캡슐화(63%), 메쏘드(57%), 메시지 패싱(56%), 폴리몰피즘(53%), 추상화(51%) 등이 상위권을 차지했다. 하위권에는 프레임워크(1%), 재활용(3%), 커플링(2%) 등등 비교적 덜 빈번한 OOP의 개념들이 차지하고 있음을 알 수 있다.

상위 8개 OOP 개념은 비교적 광범위한 동의가 이루어졌음을 알 수 있다. 하지만 OOP 책을 몇 권만 읽어보면 각 책들이 같은 개념이라도 조금씩 다른 방법과 메타포를 사용해 설명하고 있음을 알 수 있다. 하위를 차지한 항목은 더 심각하다. 개념을 기술한 저자의 관점에 따라 OOP의 요소가 달라졌고, 저자가 개발 주기(분석, 디자인, 구현)에서 어느 시기를 강조하는지에 따라 의견을 달리했다.

다른 패러다임 언어의 개발자가 OOP를 익히는데 드는 노력은 OOP가 이해하기 어려워서만은 아닌 것이다. OOP가 제공하는 생산성 향상이란 달콤한 과일을 맛보기 위해서는 헷갈리는 개념의 홍수 속에서 살아남아야만 한다. OOP가 좀 더 광범위한 수용의 대상이 되려면 OOP의 핵심 개념을 제대로 정립하려는 노력이 선행되어야 할 것이다.

[IT,묵직] 고수님들, 성벽을 높이 쌓지 말기를… 을 읽고 써봅니다.

지난 6개월 동안 마이크로소프트웨어(이하 마소)에 했던 연재를 마쳤습니다. 비교적 초보 개발자를 위한 마소 주니어(Junior)에 ‘코드의 재발견’이란 이름으로 여러 프로그래밍 언어를 비교하는 글이었습니다. 뒤돌아 보면 조금 더 열심히 성실히 했어야 하는데 하는 후회만 남는 것 같아 가슴이 아픕니다.

써니님 블로그의 ‘고수님들, 성벽을 높이 쌓지 말기를……’을 읽고 내 글쓰기는 어떠했을까 하는 생각이 스스로를 돌아보게 되더군요. 사실 마소를 독자의 입장에서 읽을 때도, 필자가 되고 난 이후에도 다른 분들이 글이 어렵긴 마찬가지였습니다. 제 실력이 뛰어나지 않은 탓도 있겠지만 써니님 말씀대로 의도했던 아니던 어느 정도 고수들의 성벽 쌓기라는 게 존재하는 건 사실인 것 같습니다.

기술 분야의 글쓰기라는 게 참 어렵다는 생각이 듭니다. 글은 결국 누군가가 읽기 마련이고, 독자를 고려하지 않을 수 없습니다. 미국의 뉴욕 타임즈(New York Times)의 기사는 언어를 우리나라의 중학교(주니어 하이 스쿨) 수준으로 맞추라는 규정이 있다고 합니다. 기술 분야는 독자에 수준을 맞추기가 무척 어렵습니다. 독자의 유형이 너무 다양하기 때문입니다.

예를 들어 객체지향 프로그래밍을 설명한다고 했을 때, 독자가 프로그래밍 언어를 조금이라도 다루어 본 적이 있는지, C 언어로 프로그램을 시작했는지 Lisp으로 프로그램을 시작했는지 등에 따라서 설명 방법이나 용어 사용이 완전히 달라질 것입니다. ‘독자가 어디까지 알고 있다고 가정할 것인가’는 문제는 생각보다 무척 어려운 것 같습니다.

사실 잡지는 그 특성상 원고 마감이 있고, 부지런한 일부 필자들을 제외하면 저를 비롯한 대부분의 필자들은 마감에 맞춰서 허둥지둥 원고를 마무리할 때가 많습니다. 예상 독자와 비슷한 수준의 사람들에게 읽혀서 피드백을 받고 시간을 들여서 퇴고를 했다면 훨씬 더 깔끔한 원고가 나왔을지도 모르겠습니다. 이런 원고를 작성하는 일차적인 책임은 잡지사라기 보다는 해당 원고의 필자에게 있는 것이겠지요.

저는 아직 학생인지라 게으름에 대해 변명할 거리가 없지만, 이는 IT 업종의 특성과도 연관이 있지 않나 합니다. 마소에 원고를 기고하시는 대부분의 필자들은 사실 현역에서도 과중한 업무로 잠도 제대로 못 주무시는 분이 대부분일 것입니다. 이런 분들이 없는 시간 쪼개가며 원고를 작성하다 보니, 글을 읽을 독자들에 대한 배려가 상대적으로 부족할 수 밖에 없는 것이지요.

외국의 개발자들은 자신의 개인적인 열정과 노력으로 많은 글을 쓰기도 하지만, 마이크로소프트(MS)나 썬(Sun), IBM 등 굴지의 소프트웨어 대기업들의 전폭적인 지지를 받고 있습니다. 기업들은 개발자들이 자신의 생각을 정리하고 이를 공유할 수 있도록 충분한 시간을 줄뿐만 아니라 각종 개발 포탈 사이트를 개설해서 이런 활동을 적극적으로 장려하고 있습니다. 시스템이 모든 문제의 근원은 아니겠지만, 우리나라는 양질의 글이 많이 양성될 수 있는 환경은 아니라는 것이지요.

하지만 결국 당장은 필자 한 명 한 명이 조금이라도 더 노력하는 수밖에 없는 거겠죠.

영화에서나 보았을 법한 산업 스파이 이야기를 요즘은 심심치 않게 들을 수 있다. 특히 급속도로 발전하고 있는 중국의 경우 자국의 기술 확보를 위한 수단으로 합법, 불법을 구분하지 않고 첨단 기술을 흡수하고 있다. 규모가 영세한 벤처 기업의 경우는 말할 것도 없고 비교적 기술 보호가 철저히 이루어지는 대기업 조차도 산업 스파이에 무방비 상태에 놓여있다.

“국가 정보원에 따르면 2003년 이후 지난해 11월까지 산업 스파이 적발 건수는 총 61건으로 예상 피해액은 약 82조원이 넘는다고 추산된다. 연도별로 보면 2003년에 6건에 불과한 적발 건수가 2004년에는 26건, 2005년에는 29건으로 약 5배 가까이 증가했다.”[1]

위 추정치는 대기업에서 이루어진 불법적인 기술 유출만 포함하고 있다. 합법적인 M&A를 통한 기술 이전이나 벤처 기업의 기술 유출까지 포함하면 핵심 기술 유출로 인한 실제 피해액은 국정원의 발표를 크게 웃돌 것이다.

이런 사례들은 2004년 11월에 발의된 ‘산업 기술의 유출 방지 및 보호 지원에 관한 법률안’(산업 기술 유출 방지법)의 배경이 되었다. 이 법안의 취지는 훌륭하나 크게 2가지 내용이 문제가 되었다.

첫째로, 이 법의 제12조를 살펴보자. “국가핵심기술을 보유한 연구기관 등과 정부지원 아래 국가핵심기술을 개발․보유한 기업 등이 해외 매각․합작투자․기술이전 등을 하는 경우 산업자원부장관의 승인을 받도록 하고, 그 외 국가핵심기술 보유중인 기업의 해외 매각․합작투자․기술이전 등의 경우, 산업자원부장관에게 사전 통지토록 함.” 12조는 비교적 자유로운 기업 활동인 해외 매각, 합작 투자를 정부가 감시 통제하는 법안이다. 외국 자본의 상당수가 국내 핵심 기술을 노리고 들어오는 것은 사실이지만, 규제가 강화되면 국내로의 자본 유입이 차단되고, 심각한 투자 축소를 유발할 수도 있다. 빠르게 변화하는 기업 환경과 기술 수준을 감안하면 정부가 어떻게 이 법을 집행할지에 관해서도 효율성이 의심스럽다.

둘째로, 많은 이공계 인력의 빈축을 산 제 31조를 살펴보자. “산업기술을 부정한 방법으로 유출한자에 대해서, 해외유출의 경우 7년 이하 징역 또는 7백만원 이상 재산상 이득액의 2배 이상 10배 상당 벌금, 국내유출의 경우 5년 이하 징역 또는 5백만원 이상 재산상 이득액의 2배 이상 10배 상당 벌금에 처하도록 하고 이를 병과할 수 있도록 함.” 이 조항은 이공계 인력의 이직이나 창업을 자유를 상당 부분 제한할 수 있다. 기술 보호 명목 하에 기술 인력들이 특정 기업이 묶이고 부당한 대우를 받게 만들 가능성이 농후하다. 법의 제안 이유인 “보안의식 확산 및 제도적 기반의 구축을 통해 국내 핵심기술을 보호하고 전문과학․산업 기술인 및 연구개발자를 보호지원” 과도 배치되는 항목이다.

입법 취지는 타당하지만 본래의 취지와는 달리 기업 활동에 걸림돌이 되고, 국가적인 문제로 인식되고 있는 이공계 위기를 심화시킬 가능성이 크다. 또 법에 의해 처벌이 가능하더라도 일단 기술이 유출되고 나면 기업은 이미 심각한 피해를 입은 상태이므로 사후약방문 형태인 법률에만 의존해서는 곤란하다.

핵심 기술 유출을 방지하는 가장 효과적인 방안은 무엇일까? 핵심 기술 보호는 개발 공정을 모듈 별로 관리하는데 있다. 핵심 기술을 개발 공정, 혹은 모듈 단위로 나누고 각 연구원은 자신이 맡은 기술에만 접근할 수 있도록 공정을 관리하는 것이다. 소수의 핵심 인력을 관리하는 일은 수월하지만, 대부분의 연구원이 모두 기업의 핵심 기술에 접근할 수 있다면 기술 유출을 막는 일은 무척 어렵기 때문이다.

덧붙여 소수의 핵심 인력에 대해서는 적절한 보상을 해주어야 한다. 불법적인 기술 유출의 핵심은 결국 자신의 연구 성과에 비해 적절한 대접을 받지 못하고 있다고 생각하기 때문이다. 단순히 연봉을 조금 올려주는 수준이 아니라, 핵심 기술에 특허를 걸려 있다면 특허권의 지분을 나눠주거나, 연구의 결과로 매출 발생시 이익의 일정 부분을 주는 방식 등으로 파격적인 대우가 필요하다.

핵심 기술 보호는 이제 기업의 사활이 걸린 문제가 되었다. 막대한 인력과 돈을 들인5~10년에 걸친 연구 개발의 성과를 경쟁사에게 빼앗기게 된다면 기업의 존립을 물론이고 국가 경제에 막대한 손해를 입힌다는 사실을 명심하자.

[1] 형민우, 「핵심 기술 보호는 문단속으로」『뉴스위크 한국판』 2006년 1월 18일, 16쪽에서 재인용

아직 IT 산업이 태동기에 있을 무렵인 1980년대에는 컴퓨터와 소프트웨어를 다루는 학과는 전산학과(Computer Science)로 불렸다. 당시 우리나라에 주업이 소프트웨어 개발인 회사는 거의 없었으므로 전산학과 졸업생들은 거의 대부분 기업이나 은행의 전산 업무 담당자로 취직을 했다.

1990년대 이후 IT 산업의 형성과 더불어 각 대학은 학과명을 전산학과에서 컴퓨터 공학과로 개명하기 시작했다. 전산학과는 왠지 기업의 전산 업무만을 연상시키므로, IT 산업을 이끄는 인재를 길러내는 학과의 이름으로는 적합하지 않다고 생각한 것이다.

컴퓨터 공학과의 영문 표기는 Computer Science & Engineering인 경우가 보통인데, 전산학과의 영문 표기에 공학(Engineering)이 단어가 추가 되었다. 공학은 과학 기술을 이용하여 인간에게 유용한 물건을 시간과 비용을 고려하여 만들어내는 학문을 일컫는다. 그렇다면 개명 이후 각 대학의 컴퓨터 공학과는 기존의 전산학과 무엇이 달라졌을까?

일단 커리큘럼만 살펴보면 큰 변화가 없었다. 전산학과의 교과목은 보통 프로그래밍 입문, 객체지향 프로그래밍, 자료 구조, 프로그래밍 언어, 데이터베이스, 컴파일러, 소프트웨어 엔지니어링 등을 포함한다. 물론 하드웨어를 다루는 학문인 디지털 시스템 설계, 어셈블리 프로그래밍, 컴퓨터 아키텍처 등도 공부한다. 컴퓨터 공학과의 교과목은 무엇이 다를까? 유감스럽게도 그다지 바뀐 것이 없다.

우리나라의 경우 삼성 전자나 LG 전자 등 대기업을 중심으로 전자 산업이 발달해 있다. 가전용 소형 전자 기기와 휴대폰, MP3 등을 중심으로 임베디드 시스템이 주류다. 또 한편에서는 중소규모의 벤처 회사를 중심으로 웹 어플리케이션이나 이동통신사와 관련된 콘텐트를 개발한다. 이런 소프트웨어는 하드웨어 지식이 별로 필요가 없다.

우선 컴퓨터공학과 졸업생이 하드웨어와 밀접한 연관이 있는 임베디드 시스템이 분야에 진출한다고 가정하자. 이 학생이 실무에 적응하는데 가장 큰 장벽은 하드웨어 지식이다. 어셈블리 프로그래밍, 시스템 프로그래밍, 컴퓨터 아키텍처 쪽 지식뿐만 아니라 일부 전자 공학의 지식도 필요하지만 학부 수준에서 이를 체계적으로 학습할 수 있는 경우가 드물다.

그렇다고 순수 소프트웨어 개발 쪽 경쟁력이 있는 것도 아니다. 대학에서 가르치는 전통적인 전산 과목은 그야말로 소프트웨어 개발을 위한 기초 도구일 뿐 실제 개발 방법론이나 프로그래밍 기술의 습득이 어렵다. 학과에 프로그래밍 관련 수업은 한 두 개 일뿐 거의 대부분 이론 습득에만 치중하기 때문이다.

커리큘럼만 놓고 본다면 대학 과정은 소프트웨어도 하드웨어도 아닌 어정쩡한 경계선에서 양쪽 모두를 놓치고 있는 셈이다. 대안은 무엇일까? 각 대학은 컴퓨터 공학과 내부에서도 세부 분야별로 전문성을 강화하고 실용적인 교육도 병행해야 한다. 해답은 선택과 집중에 있는 것이다.

컴퓨터 공학으로 미국 내 10위 권인 메릴랜드 대학의 경우 우리나라의 컴퓨터공학, 전자 공학의 스펙트럼을 전산학(Computer Science), 컴퓨터공학(Computer Engineering), 전자공학(Electrical Engineering)이라는 삼분법으로 접근하고 있다.

전산학(CS)의 경우 졸업생들이 필드에서 주로 소프트웨어 개발을 할 것이라고 가정하고 교육한다. 따라서 기존 전산학과의 교육 과정과 아울러 실용적인 프로그래밍 개발 방법이나 기술을 가르친다. 예컨대 ‘CMSC433 Programming Language Technologies and Paradigms’이란 과목에서는 자바를 중심으로 이클립스(Eclipse)와 같은 통합개발환경(IDE), 디자인 패턴, 멀티 쓰레드 프로그래밍, XML 등을 가르친다. 수업은 철저히 실기 중심으로 이루어지고 학기 중 6-7개의 프로젝트를 진행하고 성적의 50% 이상을 반영한다.

반면에 파격적으로 제한을 없앤 부분도 있는데 우리나라에서 컴퓨터공학과에서는 거의 필수 과목인 운영체제(OS)가 메릴랜드 전산학과 학생에게는 필수가 아니다. 운영체제가 복잡한 소프트웨어를 이해하고 컴퓨터의 동작 원리를 파악하는데 많은 도움을 주는 것은 사실이지만, 대부분의 프로그래머가 운영 체제의 코어까지 알 필요가 없다는 것이다. 대신 멀티 쓰레드 프로그래밍이나 세마포어, 뮤텍스와 같은 개념은 자바를 통해 다른 과목에서 배우는 식이다.

반면에 임베디드 시스템이나 시스템 프로그래밍을 중심으로 소프트웨어와 하드웨어의 접점에서 일하고 싶은 학생들을 위한 코스가 바로 컴퓨터공학(CE)이다. 컴퓨터 공학과 학생은 운영체제와 컴퓨터 아키텍처, 시스템 프로그래밍 등을 필수로 하고 깊게 배운다. 그렇다고 일부 전자과 커리큘럼처럼 복잡한 전자기적 현상을 모두 다루는 것은 아니다. 컴퓨터 시스템을 이해하고 이용하는데 필요한 수준의 전자공학적 지식을 습득하는 것이다.

기존의 전산학과 학생들이 소프트웨어는 알지만 하드웨어 지식이 부족해 어려움을 겪었고, 대부분의 임베디드 시스템은 전자 공학 출신들이 만들었다. 전자 공학 출신들은 자신들의 원하는 프로그램을 만들 순 있었지만, 소프트웨어 관련 지식의 부족으로 안정적이지 못한 소프트웨어를 만들었다. 컴퓨터 공학(CE)는 이런 상황에서 필요한 인재를 길러내는 학과인 셈이다.

실무와 이론을 모두 갖추기 위해서는 메릴랜드의 예처럼 범위를 좁힐 필요가 있다. 이에 대한 반론도 물론 있을 수 있다. 대학은 기초 교육을 하는 곳인 만큼 포다 폭넓고 전반적인 이론 교육이 이루어져야지, 실무 교육이 강조되어서는 안 된다는 관점이다. 하지만 컴퓨터 공학은 어디까지나 실용 학문이다. 대학원이나 연구소에서 연구를 하더라도 자신의 논문이나 생각을 실제로 구현할 수 있어야만 하고 이런 교육은 대학에서 이루어져야 한다.

전산학이나 컴퓨터 공학이라는 학문은 다른 학문에 비해 역사가 짧은 반면에 다른 어떤 학문보다도 빠른 속도로 발전하고 있다. 그에 비해 전산학의 교육 과정은 그 변화의 속도를 따라가지 못하고 있다. 학생들에 어떤 이유로 컴퓨터 공학과에 지원하는지, IT 산업에서 어떤 인재를 원하는지를 분명히 파악하지 못하는 대학들은 쇠퇴하고 말 것이다.