Babytook's T Blog

이승준 (마이크로소프트웨어)
2004/06/10

컨버전스(convergence)는 보통 ‘융합’으로 번역하는데, 기술 통합, 하이브리드(hybrid), 잡종적 지식, 퓨전 등과 맥을 같이하는 트랜드 이름이다. 이러한 맥락에서 디지털 컨버전스는 디지털을 매개로 가전, IT 기술, 컨텐츠, 서비스 등이 서로 유기적으로 합쳐지는 트랜드이다. 따라서 복합기, 카메라폰, 휴대폰뱅킹, 텔레메틱스 등 IT와 가전 분야에서 급속하게 일어나고 있다.

컨버전스는 비단 IT 분야에서만 일어나는 현상이 아니다. 정치는 물론 경제와 사회, 문화 등 인간이 살고 있는 세상의 전반에 걸쳐 일어나고 있는 혁명적인 변화다. 팝페라, 퓨전 레스토랑 등 결국 컨버전스란 다양한 분야의 경계가 무너지면서 다양한 결합이(디지털 기술의 힘을 빌어) 아주 빠르게 진행되는 것으로 요약할 수 있다.

디지털 컨버전스, 과연 새로운 것인가? 아니다. 이미 있어 왔고 앞으로도 계속 진행될 일이다. 디지털 컨버전스 역시 새로운 트랜드임은 분명하지만 ‘새로운 곳에 놓인 진부한 것’일 뿐이다(참고자료 ①). 우리가 디지털 컨버전스를 새롭게 논의하는 것은 바로 통합의 속도 때문이다. 디지털의 힘으로 아주 강하게 통합되기 때문에 사람들에게 이전의 통합과는 전혀 다르게 느껴지며 그 속도 때문에 이전의 통합과는 질적으로 다른 통합이 되고 있다.

컨버전스 시대의 기술 수요의 변화
많은 엔지니어들은 본능(?)적으로 계속 새로운 것을 찾는다. 새로운 기술은 새로운 영역을 개척하는 재미를 선사하기 때문이다. 90년대 말에서 2000년 초반에는 인터넷, 무선 기술, 모바일 등의 기술은 개발의 패러다임을 엄청나게 바꾸어 놓았다. 그렇다면 디지털 컨버전스가 엄청난 기술의 소용돌이와 급격한 변화를 가져온 것일까? 답은 ‘그렇기도 하고, 그렇지 않기도 하다’이다. 이것은 새로운 것이 정말 새로운 것인가라는 질문에 대한 답과 같다.

새롭다? 그렇지 않다?
‘그렇다’라는 측면부터 생각해보자. 컨버전스는 지금까지 ‘분야’라는 용어로 분리된 여러 가지 영역의 벽을 빠르게 허물고, 그 경계를 없앨 것이다. 이런 분야가 없어지는 변화들은 기술에 대한 요구를 빠르게 변화시켜 갈 것이고 다양한 서비스들이 출연할 것이다. 발명이 또 다른 발명에 대한 수요를 낳듯 기술이 다른 기술에 대한 수요를 만들고, 서비스는 다른 서비스에 대한 수요를 창출해 낼 것이다. 디지털 컨버전스를 통해 지금까지 보지 못했던 다양한 기술, 컨텐츠, 서비스들이 빠르게 등장하고 또 빠르게 사라져 간다.

향후에 소프트웨어 개발자들은 지금보다 훨씬 다양하고 복잡한 기기에 프로그래밍을 할 것이다. 현재도 휴대폰, PDA 등 다양한 기기들에 대해 개발하고 있는데 향후 훨씬 더 다양한 경우들의 조합과 다양한 기술을 구사하게 될 것이다. 이전과 다른 점은 그 변화의 속도와 개별화(personalization)를 들 수 있다. 휴대 인터넷 등 대부분의 정보 장비가 개인화되며, 현재는 무시되거나 버려지는 세세한 정보들도 가공의 대상이 될 것이다.

‘그렇지 않다’라는 측면에서는 우리가 새롭다고 받아들이는 것들이 정말 새로운 것인지 생각해 볼 필요가 있다. 지금까지 존재했던 것들은 앞으로도 존재할 것이며, 지금 행해진 것들은 앞으로도 행해질 것이니, 하늘 아래 새로운 것은 아무것도 없다(참고자료 ②). 아무리 시대가 바뀌어도 소프트웨어 개발은 자체가 혁명적으로 바뀌거나 개발 방법 자체가 획기적으로 바뀌는 일은 없을 것이다. 소프트웨어 개발은 매우 느린 속도로 발전하고 있다. 그 이유는 한가지이다. 소프트웨어 개발은 기계가 대신 할 수 없는 일이며 사람은 기계가 아니라는 점이다.

기술 자체를 다루는 기술
이제 기술의 시대는 갔다? IBM 소프트웨어 그룹의 부사장 단 앳킨스(Donn B. Atkins)가 작년 IBM의 온디맨드 전략을 소개하면서 이제 단일 기술이 업계 전체에 영향을 주는 시대는 지나갔다는 평을 했다(앳킨스는 기술 중심에서 비즈니스 중심으로 옮겨간다고 이야기한다). 기술이 중심인 시대는 서서히 막을 내리고 있다.

시대가 바뀌면서 새로운 신기술이 요구되고 있는데 그 새로운 기술은 우리가 흔히 말하는 그런 종류의 기술이 아니다. 바로 기술 자체를 다루는 기술(Technology on Technologies)들이다. 이 수요는 크게 두 가지로 요약될 수 있다. 하나는 개발의 속도를 높이는 가속 기술(Accelerating Technology)과 기술 사이를 연결하는 접착 기술(Glue Technology)이다.

전 세계가 인터넷으로 통합되고, 국가, 언어의 경계가 점차 없어지면서 새로운 신유목민이 등장한다. 프랑스 자크 아탈리 가상현실과 신유목민이 미래 사회의 양대 축이 될 것이라고 한다. 이제 사람들은 휴대할 수 있는 모든 것을 가지고 방랑을 시작할 것이다.

새천년은 속도와 통합의 시대이다. 이제 ‘기술이 아닌 기술’에 대한 수요가 생기고 있다. 즉, 지금까지 기술이라고 생각하지 않았던 새로운 기술이 필요하게 되었는데 그것은 바로 ‘속도’에 대한 기술(가속 기술)과 ‘통합’에 대한 기술(접착 기술)인 것이다. 정리하면 가속 기술은 생산, 유통, 소비, 피드백 등의 흐름을 가속하는 기술이고, 접착 기술은 기술과 기술을 연결하는 기술이다.

우리는 여전히 선택을 해야 한다. 뭐든 잘 할 수 없으며, 그래서도 안 된다. 잘 할 수 있는 것을 선택하고 거기에 집중하여 경쟁력을 키워야 한다. ‘선택과 집중’이라는 전략은 여전히 유효한 전략이며, 속도와 통합의 수요는 크게 증가할 것이고, 여기에 가속 기술과 접착 기술은 선택과 집중이라는 전략을 뒷받침하는 기초 체력이 될 것이다.

개발 속도를 높이는 가속 기술
개발 속도는 개발의 생산성과도 직결되는 문제이다. 다양한 소프트웨어 기술, 방법론, 프레임워크 등… 이 노력들은 결국 개발의 생산성을 높이고자 하는 것이라고 할 수 있다. 프로그래밍 측면에서 객체지향 기술, CBD(Component Based Development), 디자인 패턴 등의 소프트웨어 공학의 기술들은 모두 개발의 생산성을 높이기 위한 기술인데, 이 기술의 근간을 이루는 것은 결국 재사용성(reusability)이다. 즉, 가능한 한 이미 검증된 부분을 다시 사용함으로서 개발의 생산성을 높이자는 것이다.

요즘 국내 개발자들 사이에 애자일 방법론(Agile Methodology) 중의 하나인 XP(eXtreme Programming)가 화두가 되고 있다. RUP(Rational Unified Process)와 같이 덩치가 큰 기존의 방법론에 비교해 볼 때, XP 자체는 매우 경량인데 이것은 실용성(pragmatism)을 강조한 것이라고 볼 수 있다. XP의 목표는 ‘고객에게 최고의 가치를 가장 빨리’이다. 소프트웨어 개발에서 품질과 기능성 역시 중요하지만 개발 속도 또한 매우 중요한 요소이다.

프레임워크를 구성하고 비즈니스 로직만을 개발하여 프레임워크 위에 올려 시스템을 운영한다는 발상은 이미 널리 통용되고 있는 아이디어이다. J2EE, 닷넷과 같은 범용 프레임워크도 있고 스트럿츠(Struts)와 같이 특정 분야(웹 애플리케이션)를 위한 프레임워크도 있다. 프레임워크 기반의 개발은 CBD와 맞물려 크게 호응을 얻고 있다.

범용 혹은 특수한 목적에 맞게 설계된 프레임워크 외에도 특정한 산업에 적합하도록 만들어진 프레임워크도 있다. 보통 이런 프레임워크는 개발팀 혹은 개발회사에서 자체적으로 개발해 가지고 있거나 개발자 개인이 자신을 위해 개발하기도 한다. 이러한 노력을 꾸준히 하지 않는 개발자 혹은 개발회사는 항상 개발에 더 많은 노력을 들여야 하기 때문에 더 높은 비용이 들게 된다.

시대가 바뀌면서 새로운 신기술이 요구되고 있는데 그 새로운 기술은 우리가 흔히 말하는 그런 종류의 기술이 아니다. 바로 기술 자체를 다루는 기술들이다.

기술 사이를 연결하는 접착 기술
필자는 닷넷을 주로 다루지만 일을 하는 도중에 거의 항상 요구받는 부분이 바로 자바로 구축된 기존 시스템과의 연동 문제이다. 닷넷의 입장에서 보면 자바로 구축된 시스템이 레거시(legacy)이기 때문이다. 자바와 닷넷, 이 둘은 기술적인 우위를 논하거나 그 차이를 가지고 논할 필요가 없을 만큼 기술적으로 서로 대등하다.

쓰이는 환경과 상황에 따라 그 장단점이 다르게 나타난다. 앞으로 더욱 필요하게 되는 것은 이런 서로 다른 기술 혹은 플랫폼들이 서로 공존할 수 있도록 하는 기술들이다. 이런 접목 기술에 대한 필요성과 요구는 많지만 정작 두세 가지 분야에 대해 깊은 지식을 가지고 이를 연결하고 융합할 수 있는 엔지니어는 실제로 그리 많지 않다.

기술은 특정한 문제를 해결하는 데 사용된다. 지금까지는 특정 분야의 깊이 있는 기술이 각광을 받았지만 이제는 점차 기술과 기술을 연결하는 기술이 필요하게 됐다. 애플리케이션의 규모가 커지면서 데이터베이스, 네트워크(혹은 인터넷)는 애플리케이션의 기본이 되었고 분산객체 기술이 이루지 못한 대통합을 XML 웹 서비스가 준비하고 있다(XML 웹 서비스가 각광을 받는 이유는 바로 접착 기술로서 그 가능성을 인정받았기 때문이다). 상호운용, 애플리케이션 통합, 플랫폼 이식, 레거시 통합 등이 더 큰 조명을 받게 될 것이다.

간단한 예를 들어 보자. 플래시 플레이어(flash player)는 아주 널리 쓰이는 리치 클라이언트(rich client) 기술이다. 지금까지 플래시 플레이어와 컨텐츠는 자바 애플릿을 대신해 사용자에게 인터랙션이나 비주얼을 제공하는 데 주로 사용되어 왔다. 그러나 요즘 들어 플래시는 웹 서비스를 제공하는 서버와 웹 서비스로, 직접 통신하는 웹 서비스 클라이언트로 종종 쓰이고 있다. 예전에 플래시는 플래시였고 서버는 서버였다. 이제 플래시의 리치 클라이언트 기술은 EJB 서버 혹은 닷넷 서버와 웹 서비스로 연결되어 다양하고 화려한 서비스를 가능케 하고 있다.

이제 개개의 기술 자체보다 기술 간의 연결이 더 중요하게 되었다. 두세 가지 기술을 효과적으로 연결하는 방법을 적용하는 것이 훨씬 높은 부가가치를 창출하는 열쇠가 되고 있다. 이 글에서는 XML 웹 서비스를 예로 들고 있지만 독자 여러분의 실무에서는 훨씬 더 다양하고 구체적인 접착 기술들이 존재한다. 연결 기술, 통합 기술 등 그것을 무엇이라고 부르던 기술과 기술 간의 공존을 가능하게 하는 접목 기술이야 말로 항상 새로운 개발 영역이다.

[그림 1] 가속 기술과 접착 기술의 개념도.

당신은 소프트웨어 엔지니어인가
나는 내가 할 수 있다고 생각하는 일로 나를 평가하지만 남들은 내가 이미 한 일로 나를 평가한다. 일정 수준의 소프트웨어 엔지니어가 되기 위해 알아야 할 것들에는 무엇이 있을까? 객관적인 기준으로 제시할 수 있는 것으로 ACM, IEEE Computer Society에서 관리하는 ‘소프트웨어 엔지니어링의 지식 체계(Software Engineering Body of Knowledge)’를 들 수 있다. 약칭해서 ‘SWEBOK’라고도 하는데 관련 웹 사이트(www.swebok.org)에서 그 내용을 볼 수 있다. SW EBOK에 따르면 소프트웨어 엔지니어링은 다음 10가지 분야가 있다.

이 중에서 많은 실무 개발자들이 코딩하고 실행 파일을 만들어내는 소프트웨어 구현 작업을 소프트웨어 개발의 거의 전부라고 생각한다. 하지만 그것은 전문 소프트웨어 엔지니어가 알아야 할 10가지 지식 영역 중 하나에 불과하다. 다른 질문을 하나 해보자. 독자 여러분이 속한 팀에서 개발시 소스코드 관리 시스템을 사용하는가? 만일 사용하지 않는다면 지금 소속된 팀의 개발 방법에 큰 문제가 있다고 생각해도 과언이 아니다.

오래 전에 필자가 작업 의뢰를 받았던, 어떤 인터넷 기업에는 대략 20~30명의 개발자가 있었다. 그렇게 많은 개발자들이 있었음에도 불구하고 이 개발팀에서는 CVS나 소스세이프(SourceSafe) 같은 버전 관리 도구를 사용하지 않았다. 더구나 한 곳에 모아 두고 관리하지도 않았다. 각종 개발 문서들도 모두 개인이 따로 가지고 있었고, 산출물 또한 따로 관리되고 있었다(극히 최소한의 형상 관리조차 없었던 것이다).

개발자간의 버전 문제와 수정 문제로 개발자들은 머리 아파했고 급기야 개발자 사이에 개발 영역을 서비스별로 나누어 다른 영역의 개발에 절대 손을 대지 못하게 했다. 그러다 보니 필요한 기능을 중복해서 개발하게 되고 개발자 한 사람이 그만두게 되면 그 부분은 아예 손을 대지 못하게 되었다. 소스코드나 문서 관리에 대한 정책이 없다는 것은 개발팀의 개발 효율을 떨어뜨리는 것이 아니라 조직 전체의 효율에 부정적인 영향을 준다. 이런 일들이 희귀한 일이 아니다. 아직도 이렇게 진행되는 프로젝트가 셀 수도 없이 많이 있다.

주변을 둘러보면 1~2년 개발에 참여해 본 경험으로 소프트웨어 엔지니어를 운운하는 개발자들도 있다. 정말 1~2년으로 소프트웨어 엔지니어가 되는 것이 가능한 것일까? 그렇지 않다. 소프트웨어 엔지니어는 코더(coder)와는 다르다. 소프트웨어 엔지니어로서의 자긍심을 가지려면 최소 5~7년은 돼야 하고 개발 경험뿐만 아니라 여러 개의 프로젝트 관리 경험을 가지고 있어야 한다.

여러분이 다른 사람에게 자신을 소개할 때 어떻게 소개하는가? 자바 개발자, C++ 개발자, 혹은 닷넷 개발자로 소개하지 않는가? 특정 언어에 종속적인 개발자는 별로 바람직한 모델이 아니다. 주변에 게임 개발 분야에 종사하는 개발자들과 이야기해 보면 개발자들은 보통 언어나 플랫폼으로 자신을 소개하지 않는다. 즉, 다이렉트X 개발자라고 하지 않는다. 그냥 게임 개발자라고 한다.

기업용 소프트웨어 개발자들도 이제 특정 프로그래밍 언어나 플랫폼이 아닌 시장 혹은 고객을 중심으로 전문화될 필요가 있다. CRM 개발자, ERP 개발자처럼 솔루션 전문가와 금융 엔지니어와 수직 시장(vertical market)의 지칭하는 용어로 이뤄진 소개를 보게 될 것이다. 이것은 이름의 문제를 넘어 ‘생각의 변화’를 필요로 한다.

일의 맥락 속에서 일하라
이 글의 내용과는 직접적인 관련은 없지만 우리가 일상에서 “수고하십시오” 혹은 “수고하세요”라는 말을 흔히 쓴다. 이 말을 영어 표현으로 무엇이라고 할까? 직역하면 아마도 ‘Work Hard’가 될 것 같지만, 실제로 답은 ‘Don’t work too hard’이다. 즉, 달리 표현하면 ‘열심히 일하지 마라’이다. 좀 더 정확하게 해석하면 ‘너무 힘들게 일하지 마십시오’ 혹은 ‘너무 무리하지 마세요’인 것이다. 다시 말하면 ‘Don’t be a workaholic’으로 ‘일벌레 되지마’, ‘쉬어가며 일해’라는 뜻이 된다. 많은 개발자들이 밤을 새며 일중독자(workaholic)로 일하고 있는 것을 자랑삼아 이야기하곤 한다. 하지만 정말 일하는 시간동안 높은 집중도를 가지고 효과적으로 일했는지는 다시 생각해 볼 일이다.

2002년 월드컵의 영웅 히딩크가 우리나라 대표팀을 맡으면서 선수들에게 가장 먼저 주문한 것이 바로 축구를 ‘즐기라’는 것이었다. 그는 애국심으로 축구를 한다고 16강에 갈 수는 없다고 했다. 무조건 열심히 일한다고 일이 잘 되는 게 아니다. 열심히 일하는 것과 일을 잘하는 것은 아무런 관계가 없다. 열심히 일하는 것보다 중요한 것, 그것은 스마트하게 일하는 것이다. 그리고 스마트하게 일하는 것보다 중요한 것은 바로 스마트하게 일하는 방법을 개발하는 것이다.

그렇다면 스마트하게 일하는 것은 어떤 것을 말하는 것일까? 다양한 이야기가 있을 수 있지만 한 가지만 짚어 보자. 가장 먼저 이야기할 수 있는 것은, 일의 맥락(context) 속에서 일하라는 것이다. 자신에게 주어진 일만 잘하는 것으로 팀 전체의 일이 잘 진행되지 않는다. 일의 맥락 속에서 일한다는 것은 전체 작업 중에 내가 하는 부분이 어디며 어디쯤 와 있고 다른 사람들의 작업과 어떻게 연계가 되는지를 파악하고 작업하는 것을 말한다(이를 위해서 협력해야 할 사람들과의 효과적인 의사소통을 가능하게 하는 커뮤니케이션 기술이 매우 중요하다). 최소한 일을 시작하기 전에 이 일을 해야 하는 당위성을 다시 생각해 보고, 어떻게 효과적으로 풀어낼지에 대해 생각하는 시간을 가져야 한다.

프로젝트 관리, 사람을 사람으로 보자
독자가 프로젝트 관리자(project manager)라면 프로젝트 팀을 리드하는데 많은 고민을 할 것이다(혹, 프로젝트 관리자가 아니라 할지라도, 여러분은 언젠가 프로젝트 관리자가 되어야 할 것이다). 소프트웨어 산업의 특성 중 하나가 열 사람의 한걸음보다 한 사람의 열걸음이 더 빛이 난다는 점이다. 그럼에도 불구하고 소프트웨어를 개발하는 것은 개인이 아니다(혼자 만들 수 있는 정도 수준의 소프트웨어는 이미 상품 가치가 없다고 볼 수 있다). 소프트웨어는 개발뿐만 아니라, 분석/설계, 공정관리, 품질관리, 형상관리, 테스트, 문서화, 매뉴얼, 마케팅 등 다양한 활동의 산물이기 때문에 이미 한 사람이 할 수 있는 범위를 크게 벗어난다. 개인이 아닌 팀이 소프트웨어를 개발한다(참고자료 ③).

연구 자료에 의하면 개발자의 개발 역량(performance)은 개인에 따라 10배 정도 차이가 나는 것으로 알려져 있다. 팀 역시 마찬가지이다. 비슷한 경력을 가진 사람들로 구성된 팀이라 할지라도 10배까지 차이가 난다. 그런 차이가 생기는 가장 큰 원인은 무엇일까? 이는 소프트웨어는 기술이 아니라 문화이기 때문이다(참고자료 ④).

개발자가 회사를 통해 얻고자하는 것은 월급이 아니다. 개발자는 함께 배우고, 느끼고, 자신이 몸담을 만한 좋은 팀을 원한다. 개발자는 월급에서가 아니라 일하는 과정과 산출물에서 보람을 느낀다. 프로젝트 문화, 팀 문화는 단지 프로젝트를 성공시키는 데만 필요한 게 아니라 지속적으로 조직을 성장시키는 열쇠가 된다.

아직도 많은 프로젝트는 팀 내의 한 사람의 기여에 절대적으로 의존하는 형태로 진행되며 소스코드 관리 시스템을 사용하지 않는 프로젝트도 수없이 많다. 개인이 모든 것을 잘 할 수 없고, 그래서도 안 된다. 한 사람에게 의존하는 프로젝트는 일하는 사람과 그렇지 않은 사람 모두를 힘들게 한다. 그리하여 버전 2.0을 만들 수 없게 된다.

프로젝트 관리 시스템으로 프로젝트를 관리하는 것이 프로젝트 관리에 큰 도움이 되는 것은 사실이다. 팀 개발의 퍼포먼스와 프로젝트의 성공은 문화적인 측면과 심리학적인 측면이 훨씬 강하게 영향을 준다. 즉, 소프트웨어 개발은 사람이 하는 일이기 때문에 기계적이고 철저한 관리가 이뤄진다고 해서 반드시 성공적인 프로젝트가 되는 것은 아니다. 패스트푸드를 만드는 데는 철저한 공정과 관리가 필요하지만 소프트웨어 개발을 그렇게 진행했다가는 오히려 역효과가 난다.

‘믿음’이라는 효과적인 개발 도구
필자는 10년이 넘게 다양한 프로젝트를 수행해 왔지만 아직도 프로그래밍 작업을 계속하면서 프로젝트 관리에 대해 많은 고민을 하고 있다. 프로젝트를 수행하면서 가능한 상세한 체크 리스트를 가지고 꼼꼼하게 일정을 확인하는 것이 프로젝트를 잘 수행하는 방법이라 믿었던 적도 있지만, 머지않아 이런 식의 관리가 실제로는 큰 효과가 없다는 것을 알게 되었다. 나 자신을 포함해 개발자들에게는 일종의 자존심 같은 것이 있다는 것을 발견했다. 즉, 오류가 있거나 혹은 기능적으로 떨어지는 프로그램을 만드는 것에 대해 스스로 참지 못하는 것이다.

이런 상황에 놓이면 개발자는 꾸준히 코드를 개선하려고 한다. 관리 측면에서 보면 개발이 매우 느리게 진행되는 것으로 보인다. 심한 경우 관리와 개발자간의 마찰로 이어지기도 한다. 일정 위주의 재촉은 단기적으로 효과가 있을지 모르지만 장기적으로 볼 때 소프트웨어의 품질을 높이는 데는 별로 도움이 되지 않는다. 또 일정 확인은 필요한 것이지만 개발자의 자세를 의심하는 것은 오히려 더 큰 역효과를 가져온다. 필자는 프로젝트 일정을 포함하여 가능한 범위 내에서 가능한 많은 결정권을 실제 개발하는 개발자에게 위임하는 것이 훨씬 높은 효율을 낸다는 것을 발견했다. 물론, 프로젝트를 지원하는 관리 도구 역시 프로젝트를 효과적으로 수행하는 데 큰 도움을 준다. 그러나 그것보다 더 효과적인 개발 도구가 있다. 그것은 바로 서로에 대한 ‘믿음’이다.

프로젝트 관리는 매우 어렵고도 복잡한 일이다. 그러나 문화적인 측면에서 보면 어렵기만 한 것은 아니다. 배를 만드는 공장 안에서 팀원들에게 배를 만들라고 지시만 하지 말고 일을 멈추고 같이 나가서 바다를 보여줘라. 팀원들은 열심히 배를 만들어 바다에 띄울 것이다. 여기에 아주 간단한 원리가 있다. 프로젝트를 수행하는 것은 사람이다. 따라서 사람을 사람으로 보면 된다. 그럴 의지가 있고 그럴 수 있다면 당신은 이미 훌륭한 프로젝트 관리자가 될 자격을 이미 갖춘 것이다. 다시 이야기하거니와 ‘소프트웨어는 기술이 아니라 문화’이다. 그것이 소프트웨어 개발이 가지는 큰 매력이기도 하다. 관리자가 해야 할 일은 일을 시키는 것이 아니라 일에 전념할 수 있는 환경을 만들어 주는 것이다(참고자료 ⑤).

배를만드는 공장 안에서 팀원들에게 배를 만들라고 지시만 하지 말고 일을 멈추고 같이 나가서 바다를 보여줘라. 팀원들은 열심히 배를 만들어 바다에 띄울 것이다.

소프트웨어는 기술이 아니라 문화이다. 관리자가 진정해야 할 일은 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어주는 것이다.

리더의 조건
필자가 미국 명문대를 다니는 학생을 만난 적이 있었다. 그때 대학입시에 대해 이야기를 나누었다. 필자는 우리나라의 입시지옥에 관한 이야기를 했는데 오히려 그 학생은 한국 학생들의 입시가 훨씬 수월한 것 아니냐고 반문했다. ‘한국에서는 공부만 잘하면 되지 않는가?’ 하면서 자신은 입시를 위해 학과 공부는 물론 운동, 봉사, 사회활동 등을 모두 잘 해내야 했다는 것이다. 교육제도에 대한 이야기를 떠나, 리더는 지식뿐만 아니라 다양한 경험과 활동을 통해 만들어진다는 평범한 상식을 생각해면 오히려 수긍이 가는 이야기였다. 리더가 되기 위해서 다방면의 모든 것을 잘 해내야 한다는 이야기는 아니다. 코딩만 잘하는 개발자는 되지 말아야겠다.

요구되는 것 이상을 하는 것
제품의 품질 정도와 수준은 고객의 요구에 맞춰지는 것이지 개발자가 결정하는 것이 아니다. 그런데 실제 고객은 개발자들이 생각하는 것만큼 높은 품질의 산출물을 원하지 않는다. 그렇다고 고객의 품질 기준에 맞춘다면 오히려 높은 비용이 든다.

많은 회사들은 품질보다 생산성에 초점을 맞춘다. 품질은 여유가 있을 때 따지는 것으로 이해하고 있는 관리자들이 많은데 과연 그럴까? 언뜻 보면, 품질과 생산성은 상충되는 조건이다. 품질을 높이려면 더 많은 노력과 시간이 투입되어야 하므로 높은 생산성을 기대하기 힘들다. 반대로 높은 생산성을 가지려면 적은 노력과 시간으로 정해진 산출물을 만들어야 하므로 높은 품질을 기대하기 힘들다. 바로 이 경우가 문제이다. 적은 노력과 시간으로 품질보다 생산성에 집중했을 경우 오히려 품질에 집중했을 때보다 결과적으로 더 많은 비용이 든다는 사실이다.

고객이 원하는 품질을 달성하는 팀은 성공할 수 없다. 그 이상을 만들어야 한다. 즉, 고객이 원하는 품질이 아닌 개발팀에서 정한 품질을 만족하도록 해야 한다는 것이다. 그것이 오히려 장기적인 안목에서 비용 절감 효과를 가져온다.

삶아지는 개구리
개구리를 뜨거운 물에 넣으면 박차고 뛰어 오르지만 찬물에 넣고 서서히 끓이면 개구리는 환경의 변화를 인지하지 못하고 ‘아~ 따뜻하다’ 하면서 그대로 삶아져 죽는다. 변화를 감지하고 있으나 체감을 못하는 것을 비유하는 이야기이다. 삶아진 개구리(Boiled Frogs, 참고자료 ⑪)가 되지 않으려면 항상 자신이 지금 무엇을 하는가를 생각해 봐야 한다. 지금 여러분이 있는 곳이 따뜻하고 편안하다면 다시 주위를 둘러보라. 세계는 확실히 빠르게 변하고 있지만 그것을 느끼고 대처할지 말지를 결정하는 것은 여러분이다.

우리 사회는 젊은 인력을 건실한 ‘생산자’로 키우는 것이 아니라 우매한 ‘소비자’로만 키우고 있다. 교묘한 상업주의가 생산문화가 아닌 소비문화만을 부추기고 있다. 사회적인 현상으로 돌릴 것이 아니라 그 틀을 깨야 한다. 엔지니어가 제대로 된 대접을 받지 못하는 것은 어제 오늘의 일이 아니다(역사 속에서 엔지니어가 대접받는 시대는 철기시대가 유일한 시기였다). 엔지니어 스스로 그렇게 만든 것은 아니었을까? 기술이 활용되고 이용되는 측면을 등한시해 왔고 글쓰기를 포함한 커뮤니케이션에 많은 노력을 기울이지 않았다. 이제 엔지니어들도 커뮤니케이션 능력을 배양하고 적극적인 문화의 생산자가 되려는 노력을 기울어야 한다.

[그림 2] 프로젝트 관리 지식 체계

답은 없으되 방향은 있다
누구에게나 딱 맞아 떨어지는 답은 없다. 우리가 별을 보고 항해하는 것은 그 별에 도달하기 위해서가 아니다. 별을 보고 항로를 잡기 위해서이다. 이제 한두 가지 기술을 가지고 십년을 먹고 사는 시대는 지났다. 점차 기술 중심에서 시장 중심, 비즈니스 중심, 고객 중심으로 바뀌고 있다. 개인은 이런 변화 속에서 큰 일을 이루어 낼 수 없다. 이제 다락방에서 PC를 가지고 소프트웨어를 만들어 히트작을 꿈꾸는 그런 시대는 지나갔다.

하지만 팀은 엄청난 일들을 해낼 수 있다. 좋은 팀을 구성하고 꾸리는데 최선을 다해야 한다. 그리고 좋은 팀에는 좋은 리더가 필요하다. 여러분은 많은 경험을 통해 리더가 될 준비를 해야 한다. 왜 그런가? 독자가 입문한지 얼마 안 되는 사람이라고 하더라도 5년 이내에 팀을 리드하는 입장에 서게 될 것이기 때문이다. 글쓰기를 꺼려하고, 커뮤니케이션을 회피하는 개발자는 더 이상 리더 개발자가 될 수 없다. 기술자의 업무도 50%는 글쓰기이다(참고자료 ⑥).

또한 효과적인 커뮤니케이션 방법을 꾸준히 익혀야 한다. 유능한 SE는 동료 혹은 클라이언트와의 커뮤니케이션(communication) 능력에도 뛰어나다(참고자료 ⑦). 그리고 자원(resource), 범위(scope), 품질(quality), 그리고 시간(time)을 공부해야 한다. PMBOK (Project Management Body Of Knowledge, http://pmi.org)나 소프트웨어 공학론을 공부하라는 것이 아니라, 이 네 가지의 상관관계를 경험으로 배워야 한다. ‘~라고 하더라’라는 지식은 쓸모 없는 지식이다. 경험과 실수로부터 배우는 것을 두려워하지 않아야 한다(참고자료 ⑧). 그러기 위해서는 시키는 일만 잘 한다는 수동적인 마인드가 아닌 주도적(proactivity)인 사고가 필요하다.

한편 첨단 기술에 대한 환상을 버려야 한다. 첨단 기술은 회사가 필요로 하는 것이지 자신의 업무에 필요한 것은 아니다(참고자료 ⑤). 소프트웨어 개발은 사람이 하는 일이기 때문에 소프트웨어 개발에 특효약은 없다. 집중해야 할 것이 있다면 그것은 사람이다. OOP, UML, RUP, XP(TDD), CBD, 패턴 등 수많은 소프트웨어 관련 기술들이 있지만 그 기술 자체가 문제를 해결해 주는 것은 아니다. 시도하고 느끼고 체득하여 활용하고 이점을 누리는 것이 중요하다. 진정한 소프트웨어 개발은 반드시 공학이어야 한다(참고자료 ⑬). 단순한 기능인(craftman)으로 머물지 않고 기술자(engineer)가 되려면 일하는 방법 자체를 고민할 필요가 있다. 일하는 방법과 수순(process)에 관심을 가지고 연구할 필요가 있다.

그래 맞다. 다 옳은 이야기이다. 유치원에서 이미 배운 이야기이다. 하지만 기본을 얼마나 충실하게 수행하고 반성하고 배웠는지를 실제 그런 경험들을 하였는지를 스스로에게 물어보자. 전 세계가 인터넷으로 통합되고, 국가, 언어의 경계가 점차 없어지면서 여러 나라에서 일하고 여행하는 새로운 신유목민(nomad)이 등장한다. 현존하는 프랑스의 최고 지성이라 불리는 자크 아탈리(Jacques Attali)는 가상현실(Virtual Reality)과 신유목민(Nomadism)이 미래 사회의 양대 축이 될 것이라고 한다. 이제 사람들은 휴대할 수 있는 모든 것을 가지고 방랑을 시작할 것이다.

이런 여행에서는 사전적 지식보다 다양한 경험이 훨씬 더 중요하다. 엔지니어로서 새로운 시대로 향하는 여정이 좋은 여행이 되고 행운이 함께 하기를…. @

참고자료
① 자네 일은 재미있나, Dale Dauten, 세종서적
② 성서, 잠언 1장 9절
③ 프로젝트 데드라인, Ed Sullivan, 한빛미디어
④ 대한민국에는 소프트웨어가 없다. 김익환, 미래의 창
⑤ 피플웨어, Tom Demarco/Timothy Lister, 매일경제신문사
⑥ 한국의 이공계는 글쓰기가 두렵다, 임재춘, 마이넌
⑦ SE가 가져야 할 성공 마인드, Akizuki Akihiko/Uryu Sei, 이비컴
⑧ 하이브리드 세상읽기, 홍성욱, 안그라픽스
⑨ 프로젝트 쾌속 개발 전략, Steve McConnell, 한빛미디어
⑩ 링크, 알버트 라즐로 바라바시, 동아시아
⑪ The Pragmatic Programmer, Andrew Hunt/David Thomas, Addison Wesley
⑫ 미로, 지혜에 이르는 길, 자크 아탈리, 영림카디널
⑬ Professional 소프트웨어 개발, Steve McConnel, 인사이트

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.