상단메뉴 바로가기 본문 바로가기 본문 하위메뉴 바로가기 하단 바로가기

회사소개

IT 신기술들을 어떻게 적용할 것인가?

관리자   /   2004-07-19

현대는 하루가 다르게 새로운 기술이 나오는 세상이다. 과학 기술 분야 중에서도 정보통신 분야는 특히 가속화 되는 것을 피부로 느끼고 있다. 기술 발전이 가속화 될수록 문명의 이기를 사용하는 인간의 편익도 함께 증대되겠지만 역기능 또한 간과할 수 없다.

그 중에서도 필자가 관심을 갖는 부분은 정보 통신 분야에 종사하는 기술 인력들의 이탈 현상이다. 다른 기술 분야는 잘 모르지만 필자가 30년 동안 몸 담고 있는 정보통신 분야 중에서 소프트웨어만 보더라도 이 분야에서 핵심으로 일하던 동료, 선배들이 새로운 기술을 수용하는 데 있어 어려움을 토로하는 것을 자주 듣게 된다. 그 분들 중에서도 이 분야에서 주도적으로 선진 기술을 이끌어 온 분들도 많은데 새로운 기술 화두가 나오면 대체로 반응은 “내가 이 나이에 뭐 하겠다고……” 하면서 애써 피하는 경우를 자주 목격한다. 그리고 더러는 하던 일과는 다소 상관 없는 다른 분야로 이동하든가 심하면 지금까지 하던 자신의 핵심 역량과는 관계 없는 전혀 다른 업종으로 바꾸는 것을 보게 된다. 그런 경우를 목격할 때마다, 그가 가지고 있는 지식이 사장되고 마는 것이 아깝다는 생각을 자주 하게 된다. 젊은 시절 신천지를 개척해야 한다는 나름대로 사명감을 가지고 축적했던 많은 경험들은 “이제 새로운 기술이 도래했으니 더 이상 쓸모 없는 것 아니냐?”는 사회적 인식에도 문제가 있지만, 그런 관행을 분석하여 문제의 원인을 찾아내고 적절한 방안을 강구해야 하는데도, 그냥 쉽게 동조해 버리고 마는 기술 인들에게도 문제는 있다. 그러나 문제의 핵심을 조금만 들여다 본다면 개발자들이 사용하는 프로그래밍 언어가 무엇인가에 따라서 인종차별에 비견되는 언어차별 현상이 개발자들 스스로의 사고 밑바닥에 깔려 있음을 알 수 있다.

잘 알고 지내는 어느 원로 교수는 명문 대학에서 컴퓨터공학을 전공한 후, IT분야 연구소에서 실전에서 충분히 프로그래밍 훈련을 받았지만 대학에서 후진을 양성하기에는 어려움이 많다고 토로했다. 자신이 C언어에 익숙한데, 강의실에서는 C++와Java를 사용하고 있고, 따라서 실전 예를 들어 개념을 설명해 주기 어렵다는 얘기였다. 필자가 그에게 조언해 준 것은 모델링과 패턴 그리고 CASE 위주로 개편하면 언어 문제가 줄어들고, 또 그렇게 하는 것이 더 실용적 방안이라고 제시했지만 쉽게 받아들이지 못했다.
그래도 대학에서 교수가 느끼는 박탈감은 차리리 사치인지도 모른다. 산업 현장에서 언어 차별을 경험한 사람들은 당장이라도 언어를 다시 배워서 직접 해결해 버리고 싶은 심정이 일어날 때도 있다. 그러나 우리 나라 SI 환경에서 프로젝트 관리자나, 프로젝트 리더들 입장에서 그게 쉬운 일이 아니다. 프로젝트 한 개를 수행하려면 빈번한 회의와 고객 만나서 현안 문제도 협의해야 하고 요구사항 이견 조정하는 일이 쉽게 끝나지 않은 상태에서 새롭게 배워서 팀에 기여할 수 있기란 보통 어려운 일이 아니다. 그래서 수퍼(super) 프로그래머 소리를 들을 정도의 실력자라 하더라도 고집스럽게 구현 전문가로 남아 있기가 우리나라 현실에서는 여간 힘들지 않다.
최근에 이르러서도 프로그래밍 언어가 COBOL에서 C, 그리고 C++을 거쳐 Java로 그리고 120C#으로 지금도 계속 출현하고 있는 것을 지켜 보았듯이 기존 프로그래밍 언어가 퇴조하고 새로운 언어가 등장하는 것은 인류 역사에서 자연어의 흥망성쇠에 비유될 수 있을 것이다. 따라서 프로그래밍 언어로 직업을 계속 유지할 사람은 스스로에게 결심 선언을 해야 한다 “나는 새로운 언어가 나올 때 마다 부지런히 습득하여 어떤 언어 환경에서든지 구현할 수 있는 수퍼 프로그래머가 되겠습니다” 라고. 그런데 혹시 그런 생각을 한다면 오기일 뿐이므로 더 가치 있고 조직에 도움이 되는 방안을 찾아야 한다.
그리고 설령 그렇게 할 수 있는 환경이라 하더라도 ROI를 고려할 때 설득력이 없다. 프로그래밍에서는 모듈이나 함수(function)을 주로 다루기 때문에 경험에서 우러나오는 지적 요인이 크게 작용할 여지가 없기 때문이다.
구체적인 프로그래밍 일이라면 건강과 추진력 그리고 적성 있는 중급 프로그래머가 안성 맞춤이다. 그 대신 지적 경험이 비즈니스 프로세스에서 기여하려면 프로세스 계획 단계와 아키텍처 설계 단계에서 입력이 되어야만 가치 그대로 반영할 수 있다. 따라서 그에 합당한 프로세스를 찾아내야 하고 그것을 이용해서 가치를 축적할 수 있는 용기 즉 메커니즘을 확립해야 한다. 그리고, 그러한 용기에 가치를 축적해 가는 중요성을 전사적으로 공유해야 한다. 다행이 OMG에서는 여러 추상화 수준에 걸쳐서 이음매 없이 연동 시킬 수 있도록 MDA라고 하는 계층적 모델을 제시하고 있다.

이에 부응하여 우리 업계도 추상화 지식들의 중요성을 인식하여 커뮤니티로 발전하여 활동하고 있다. 수년 전부터 활동하고 있는 소프트웨어컴포넌트표준화 포럼은 우리나라 소프트웨어 업계를 CBD로 개발 패러다임을 바꾸는 원동력이 되었다. 또한 한국MDA 포럼과 소프트웨어모델링기술 포럼이 창립되어 있으므로 관심을 갖고 참여하여 공동 발전을 도모하자.

여기서 잠시, 우리와 다른 분야에서 전문가들은 어떻게 지속해서 자신의 능력을 발휘하고 있는가를 음미하면서 우리의 전문성 유지 방향을 가늠해보고자 한다.

법조인은 공개된 법률이라는 잣대를 가지고 고객 사건을 위임 받아 서비스를 제공한다. 그는 선배들로부터 경험을 배우면서 실전을 익히고 나면 연륜에 비례해서 문제 해결 능력도 향상된다. 선배들의 경험을 매우 중요시하여 그들이 내린 판결 사례를 발판으로 삼고 거기서부터 새로운 변화를 전개하는 점에서 연결성이 있는 것이다. 바로 판결 사례집이 선/후배 간에 지혜를 주고 받을 수 있는 연결 고리가 된다.

우리 IT문화는 어떤가? 특정 도메인에서 관련 업무를 오랫동안 서비스했다고 하자. 분명 그 곳에는 많은 지식들이 있어야 한다. 조직에서 선배가 물려줄 수 있는 지혜는 무엇이며 어디에 있는가? 만일 있다면 그 지혜는 후배가 실제 업무에 사용할 수 있는 것인가? 또 후배가 선배로부터 얻고자 하는 것은 무엇인가? 법조인들이 법률 서비스에 필요한 자산을 축적해 가듯이 우리 IT인들도 경험자와 신참자 간에 명시적으로 주고 받을 수 있는 자산을 만들어 가야 한다.

서양 음악은 소리를 모델링 할 수 있는 악보 덕분에 비약적으로 발전할 수 있었으며, 미술에서도 레오나르도 다빈치가 원근법 원리를 도입하면서 이후로 더욱 다양한 발전을 이룰 수 있었다. IT기술 인들도 악보처럼 보기만 하면 바로 연주할 수 있는 모델들을 후배에게 전수할 수 있어야 하고, 원근법과 같은 어느 일에서나 적용할 수 있는 원리들을 발굴해서 전수해야 한다.

그런데 한 발만 다가서서 들여다 보노라면 유용한 모델과 원리들이 많이 발굴 되어 있고, 지금도 열심히 만들어 가고 있지만 인식 부족으로 외면당하고 있다. ERD로 작성된 도메인 별 데이터 모델링에 관한 저서가 많이 나와 있고, 비즈니스 패턴, 분석 패턴, 설계 패턴에 관한 책이 우리 말로 출판되어 있다. 패턴 홈페이지도 비영리로 운영되고 있다.

외국의 경우를 보면 우리 경우와는 여러모로 다른 것 같다. 표준화 회의에 참석해 본 사람은 알겠지만 대체로 단체들을 이끌어 가는 사람들 중에는 백발이 성성한 사람들을 의외로 자주 목격할 수 있다. 연륜과 비례해서 지식도 쌓이고 또 그에 합당한 인정을 받는 사회적 제도가 뿌리 내려야만 지식 사이클이 가동될 수 있다. 신이 인간에게 준 선물 중에 세대에서 세대로 유전인자는 이동할 수 있게 했으나 유감스럽게도 지식은 복사를 허용하지 않았다. 그 대신 지적인 활동 기간을 육체 수명만큼은 허용했다. 따라서 인간은 신의 섭리를 이해하고 어떻게 하면 그 재능을 잘 활용할 수 있는지를 부단히 찾아내어야 한다. 올해에는 불황이 계속되는 와중에도 여러 명의 IT 전문가들이 한국을 찾았다. 혹은 정보통신 분야 교육 목적으로, 혹은 특정 프로젝트 컨설팅 목적으로 왔는데 그 사람들과 짧은 대화에서도 얻은 바가 많았다. 그들의 신기술에 대한 생각을 보면 그렇게 강조하는 것도 아니고 또한 무시하지도 않지만 그들의 언어 속에서 자연스럽게 융화 되어 생각과 말과 행동으로 나타나는 것을 목격할 수 있었다. 그것이 가장 위력 있는 전파 능력이 아닐까?

그렇다면 자연스런 지식 순환이 이루어 지려면 어떤 대안들이 있는가?

IT 업계에 발을 들여 놓은 후 일을 통해 얻은 귀중한 know-how들을 새 기술환경에서도 이식하여 쉽게 적용할 방법은 없을까? 필자는 이 문제에 평소 관심을 갖고 IT분야 정보통신 고수들을 만날 때마다 이런 관점에 관해서 의견을 나누곤 한다. 그래서 이 자리에서는 그런 과정을 통해서 형상화 했고 나름대로 시도해 본 몇 가지 사례를 소개하고자 한다.

- 추상 언어를 활용
유추로서 수학과 물리, 화학에서 추상언어 역할을 보자. 수학 에서 사용되는 여러 공식을 통해서 머리 속에 논리 개념을 형상화 할 수 있다. 스티븐 호킹의 강의실에서는 자연어 대신 미분 방정식만 보인다. 자연에서 일어 나는 화학적 변화는 화학 반응식으로 기술해야 명시적으로 이해된다. 이와 같이 자연어 대신에 도메인에 적합한 추상어를 활용하면 월등한 이득을 얻을 수 있다. 라이쁘니쯔와 뉴턴이 미적분 추상언어들을 만들지 않았다면 오늘날 과학 문명은 어느 정도나 지연되었을까? 그에 앞서 아라비아 숫자 채용을 하지 않고 로마 숫자만을 고집했다면 서양 사람들은 곱셈 나눗셈은커녕, 덧셈, 뺄셈이나 할 수 있었을까? 벤젠 육각형 고리를 케큘레가 생각해 내지 못했다면 얼마나 많은 유기화학자들이 힘들었을까? 이러한 몇 가지 예 만으로도 추상 언어의 위력을 짐작할 수 있다. 우리 IT를 책임지고 있는 CIO와 관리자들은 솔선 수범해서 추상 언어의 고유 가치를 인식하고 속한 조직에서 기본 언어로 사용해야 한다. 그래야 지식을 담을 수 있는 용기가 겨우 구비되는 것이다.

소프트웨어 분야에서 추상 언어의 원조는 흐름도(flow chart)라고 할 때 이의를 제기할 사람은 없을 것이다. 초창기 프로그램 로직 설계에서 가장 많이 쓰이다가 F. Brooks가 그의 저서 Mythical Man Month에서 OS/360 개발 시에 도움 보다는 부담만 주었다 라는 말 한마디에 오랜 동안 천대 받다가 UML에서 Activity Diagram이라는 이름으로 화려하게 복권된 도구이다. 진정 가치 있는 것이라면 인위적으로 아무리 눌러도 다시 부활한다는 것을 보여준 예라고 할 수 있다. 소프트웨어에서 전문가들이 합의로 채택한 최초로 표준 추상 도구는 UML이다. 필자가 UML을 보급하고 있는 입장에서 소프트웨어 종사자들은 분석이나 설계 시 모델을 논의하고 개선하는 언어로서 UML을 사용해야 하는데, 아직도 각개 문서 작성에 머무는 것을 보면 유감이다.

- 추상언어로 지식 리파지토리를 구축
어떤 방법을 어떻게 시작할 것인가? 우선 말은 배워야 한다. 어플리케이션을 개발할 때 기본으로 필요한 말은 UML이다. 그 중에서도 Use case, Class diagram, Sequence diagram, 그리고 Activity diagram은 필수이다. 그리고 이것을 쉽게 그려주는 CASE 도구를 한 개 선정하자. 그리고 성공의 열쇠는 남이 하기를 바라기에 앞서 각자 자신의 지식을 나타내 보여주는 일이다. 만일 조직의 전문성이 비즈니스 프로세스라면 BPMN 말을 배운 후, 그것을 잘 작성할 수 있는 CASE를 선정한다.

- 전문도메인 지식을 메타정보화
조직마다 생존전략으로써 자신의 핵심 역량을 유지, 발전시키고 있다. 메타 정보로 구축해 놓으면 평소에는 일반 개선 작업을 하다가 새로운 시스템 요구가 왔을 때, 쉽게 생성할 수 있다. 이것은 마치 클래스를 한 번만 정의해 놓은 후, 필요할 때 인스턴스 한 개를 생성하는 것에 비유할 수 있다.

이밖에도 필자는 수학을 활용하여 논리를 단순화 시키거나, 디자인 패턴으로 설계 노하우를 담으려 하며, 분석 패턴으로 분석 노하우를 저장하고, 국내 표준화 기구에 참여하여 경험을 교류하고, OMG /MDA에 순응하여 아키텍처를 담는 등의 시도를 하고 있다.

마지막으로 적용 절차는 다음과 같이 점진적으로 생각할 수 있다.

1) 조직에서 생존 전략으로 삼고 있는 도메인에 대해서 도메인 모델을 작성한다.
2) 작성한 도메인 모델을 이용하여 워크샵을 실시하여 전사적인 공감대를 형성한다.
3) 다음 도메인 모델을 작성한다. (모든 도메인이 끝날 때까지)
3) 최종으로 전사 모델을 구축한다.


<참고 사이트>
Pattern 관련 사이트 http://hillside.net
Business Process 관련 사이트 http://www.bpmn.org
Business Process Trends http://www.bptrends.com
OMG Home Page http://www.omg.org


* 이 글은 '경영과 컴퓨터(8월호)' CIO칼럼에 게재된 내용입니다.