강팀장의 Web E.Y.G(웹이야기)

1. Listen : 명령만 하지 말고 부하 직원의 이야기를 경청하라

[#M_ 내용보기 | 내용닫기 | 리더가 지시와 명령에 익숙하면 부하 직원들이 자신의 역량을 충분히 발휘하기 어렵다. 이런 현상은 특히 피라미드형 조직에서 많이 볼 수 있다. 피라미드형 조직에서는 수평적 조직에 비해 쌍방향 커뮤니케이션이 아닌 위에서 아래로 진행되는 일방적 커뮤니케이션이 이루어지기 쉽다. 이처럼 커뮤니케이션이 주로 윗사람 중심으로 일방적으로 진행되면 윗사람은 아랫사람의 생각을 읽을 수 없기 때문에 일 중심의 지시와 통제를 점차 강화하게 되고 이러한 관계가 일상적인 것으로 굳어진다. 그 결과, 부하 직원은 자신의 능력을 발휘하기 보다는 윗사람의 눈치를 보거나 지시에 따르는 수동적인 업무 수행만 하게 될 뿐이다.
이러한 현상은 상하간 심리적 거리감 때문에 발생한다. 켈의 법칙(Kel’s law)에 따르면 피라미드형 조직에서는 직급이 한 단계씩 멀어질수록 심리적 거리감이 제곱으로 커져 직급간 두터운 벽이 존재하게 된다고 한다. 예를 들어, 동료들 사이의 거리를 1로 할 때 부하 직원과 바로 윗 직급 상사와의 거리는 2가 되고 이 때의 심리적 거리감은 4가 되는 것이다.


심리적 거리감으로 인한 직급간 장벽을 제거하기 위해서는 리더가 적극적으로 부하 직원들의 의견을 구하고 경청하는 자세를 가져야 한다. 존슨앤존슨의 전 CEO였던 짐 버크도 “나는 재직 중 일과의 40%를 직원들과 의사소통하는데 할애했다. 그만큼 커뮤니케이션은 중요하다. 그 중에서 가장 중요한 것이 경청이다”라고 말한바 있다.


리더가 경청하는 자세를 가지려면 우선 부하 직원들이 자신의 의견을 자유롭게 이야기할 수 있도록 개방적인 환경을 만드는 것이 중요하다. 이런 환경을 조성한 후에 리더는 부하 직원의 이야기를 몰입해서 듣고 공감하는 자세를 가져야 한다. 대화 도중에 고개를 끄덕이거나 질문을 하는 것도 좋은 예가 될 수 있다.
이처럼 리더가 지시와 명령보다는 적극적인 경청의 자세를 보이면 부하 직원들은 좀 더 자신감을 갖고 자신의 업무에 자발적이며 창의적인 태도로 임하게 될 것이다.

사람의 행동은 주위의 기대에 따라 결정되는 경향이 있다. 따라서 리더가 부하 직원의 탁월한 성과 창출을 기대한다면 그들에게 관심을 보이고 잘해낼 수 있을 것이라는 기대를 표현하는데 인색해서는 안 된다.
미국의 교육학자 로젠탈과 제이콥슨 교수도 한 실험을 통해 기대와 성과 사이의 관계를 밝혀냈다. 한 초등학교에서 전교생을 대상으로 지능 검사를 실시하고 검사 결과와는 무관하게 무작위로 학생들을 선택하여 학생들의 담당교사들에게 “이 학생은 지적 능력이 우수하여 앞으로 학업 성취도가 매우 높을 것이다”라고 알려주었다. 8개월 후, 다시 지능 검사를 실시하여 처음과 비교한 결과, 이 학생들의 평균 지능 점수가 다른 학생들보다 매우 높았을 뿐만 아니라 예전에 비하여 성적이 큰 폭으로 향상된 것으로 나타났다. 결국, 교사가 어떤 학생에게 ‘이 아이는 장차 성적이 크게 오를 것’이라고 기대를 하면 그런 기대를 받은 학생은 그것에 반응하여 실제로 성적이 올라간다는 것이다. 이처럼 기대감이 성과에 미치는 영향을 ‘피그말리온 효과(Pygmalion effect)’라고 한다.


피그말리온 효과를 기업 상황에 적용해 보면, 리더가 부하 직원들을 업무 능력이 떨어지는 사람으로 대하면 실제로 성과 향상을 기대할 수 없지만, 부하 직원들을 존중하면서 뛰어난 능력을 지닌 사람으로 대하면 높은 성과를 창출할 수 있다는 것이다.


이 효과를 인재 경영에 잘 활용하는 리더도 있다. 한 CEO는 신입 사원이 입사하는 날“우리 회사는 항상 최고의 인재만을 뽑습니다. 따라서 오늘 뽑힌 당신들에게 거는 기대가 큼니다”라는 말로 인사를 대신한다고 한다. 신입 사원들도 “최고의 인재라는 자부심과 잘할 수 있을 것이라는 자신감을 가지게 되었다”라는 반응을 보였다고 한다. 이처럼 부하 직원에 대한 관심과 기대가 이들의 잠재력을 이끌어내고 자신감을 얻게 하는데 중요하다는 점을 리더는 잊어서는 안될 것이다.

리더의 칭찬만큼 부하 직원을 신바람나게 만드는 것도 없다. 얼마 전 온라인 채용 사이트인 파워잡(www.powerjob.co.kr)이 직장인 1,500여명을 대상으로 ‘직장 생활을 즐겁게 하는 리더의 한 마디는 무엇인가?’에 대해 조사한 결과에서도 ‘일 처리를 아주 잘했군’을 꼽은 사람이 27%로 가장 많았다. ‘역시 자넨 우리 회사의 핵심 인력이야’라고 응답한 사람도 전체 응답자의 20%를 차지했다.


누구나 리더와 부하 직원 사이에서 격려와 칭찬이 중요하다고 생각하지만 실제로 이를 실천하기란 쉽지 않다. 그래서 칭찬에도 기술이 필요하다. 가장 효과적인 칭찬은 구체적이고 즉각적이면서 공개적으로 하는 것이다. 칭찬하고자 하는 내용이 모호하거나 시기를 놓치면 칭찬의 효과가 감소될 수 있기 때문이다. 공개적으로 하는 것도 중요하다. 부하 직원들은 리더뿐만 아니라 동료들로부터 인정받을 때 사기가 진작될 수 있다.


38세의 젊은 나이에 미국 최대 철강 회사의 CEO가 된 찰스 슈왑은 자신의 성공 비결에 대해 “나에게는 사람들의 열정을 불러 일으키는 능력이 있는 것 같다. 그것은 자신의 잠재력을 발휘하게끔 만드는 격려와 칭찬이다”라고 말했다.


리더가 부하 직원을 성공으로 이끌고 싶다면 결점을 들추어내기 보다는 가능한 칭찬하려고 노력하라. 리더의 칭찬 한 마디가 직원들의 사기를 좌우하기 때문이다.

옛말에 ‘용인불의 의인불용(用人不疑 疑人不用)’이라는 말이 있다. 사람을 쓸 때는 의심하지 말고, 의심 가는 사람은 쓰지 말라는 의미이다. 그만큼 리더와 부하 직원 사이에 신뢰가 중요하다는 의미이다. 현대 경영학의 대가인 워렌 베니스도 상사 부하간 신뢰의 중요성을 역설하면서 리더와 관리자의 근본적인 차이점이 “관리자는 통제에 의존하지만 리더는 신뢰를 고취시킨다”고 말한바 있다.


리더가 부하 직원을 신임하지 못하면 이들도 자신이 맡은 일에 최선을 다하지 않을 뿐더러 실패에 대한 처벌이 두려워 적극성도 상실하게 된다. 그래서 부하 직원을 신임하지 못하는 리더는 이들의 발목에 줄을 매놓은 것과 같다고 이야기할 수 있다. 조금이라도 잘못 돌면 줄이 부하를 꽁꽁 묶고 잡아당기게 되며, 이 상태가 오래 지속되면 부하들은 자연히 움직일 수 없게 되어 창의성과 적극성도 말살되기 때문이다.


리더가 부하 직원을 신뢰하는 모습을 보이려면 사사건건 간섭하고 통제하기 보다는 믿고 맡기는 것이 필요하다. 예를 들어, 리더가 부하 직원에게 업무 지시를 내릴 때는 전체적인 일의 윤곽과 방향성만 일러주고 나머지는 이들의 자율성에 맡기는 것이 바람직하다. 이렇게 하면 부하 직원도 업무에 대해 책임의식을 갖고 적극적으로 임하게 될 것이다.


때로는 실수를 용인하고 그것을 통해 배움을 얻게 만드는 것도 리더가 부하 직원에게 신뢰를 보여주는 한 가지 방법이 될 수 있다. 리더가 실수를 엄격하게 처벌하기만 하면 부하 직원들은 처벌에 대한 두려움 때문에 과감하게 일을 수행하지 못할 수 있다. 반면, 리더가 부하 직원을 신뢰하면서 때로는 실수도 과감하게 인정한다면 이들은 실패의 원인을 철저하게 분석함으로써 새로운 도약의 에너지로 활용하게 될 것이다.

최근 온라인 채용 사이트인 커리어(www.career.co.kr)에서 ‘가장 따르고 싶은 직장 상사는 누구인가?’에 대해 설문 조사를 실시한 결과, 응답자의 45%가 ‘일하는 방법(노하우)을 가르쳐 주는 상사’라고 답했다. 많은 직장인들이 상사의 친절한 가르침을 원하는 것이라 할 수 있다.


인재는 타고나는 것이 아니라 만들어진다는 말이 있다. 가르침과 배움 없이 인재가 만들어지기 어렵다는 의미이기도 하다. 그런 의미에서 리더의 중요한 역할 중 하나는 코칭을 통한 육성이라 할 수 있다. 하지만 어떤 리더는 자기 밑에 능력 있는 사람이 너무 적다고 푸념하며 아무것도 하려 하지 않는다. 인재가 부족하다고 불평하기 전에 일하는 방법을 가르쳐주는 리더가 될 필요가 있다.


일을 가르치려면 우선 부하 직원에게 일의 필요성을 이해시켜야 한다. 부하 직원에게 무조건 하라는 식으로 밀어붙이기만 한다면 부하 직원은 왜 그 일이 필요한지 의문이 생기기 마련이다. 일의 목적이 무엇이며 그것이 조직의 성과에 어떤 영향을 미치는지 리더가 부하 직원에게 상세히 알려줄 필요가 있다. 일의 필요성을 이해시킨 다음에는 방법론을 가르쳐야 한다. 부하 직원이 그 일의 필요성을 이해했다고 해도 구체적인 작업 절차를 모른다면 부하 직원은 움직이지 못하기 때문이다. 예를 들어가면서 일하는 순서와 방법을 자세히 가르쳐 주는 것도 좋은 방법이 될 수 있다.


리더가 일하는 방법을 가르쳐주면 부하 직원들은 업무 수행을 통해 무언가 배우고 있고 자신이 성장하고 있다는 느낌을 받게 될 것이다. 이런 과정들이 쌓이면 부하 직원들은 점차 일에 대해 자신감을 가지게 된다.

누구나 강점과 약점을 동시에 가지고 있다. 기획 능력은 뛰어나지만 관리 능력이 부족할 수 있고, 업무 능력은 탁월하지만 외국어 실력이 떨어질 수도 있다. 그러나 약점을 보완하는데 주력하면 강점을 효과적으로 활용하는데 소홀하게 될 수도 있다. 따라서 리더는 부하 직원의 장점을 파악하여 이를 개발하는데 주력해야 한다.


인재 활용 측면에서 탁월한 능력을 보여주었던 조조는 휘하 장수에게 한 가지 장기만 있어도 그것을 끌어내어 맘껏 발휘할 수 있는 기회를 주었다고 한다. 일례로, 조조가 서쪽의 장로로 원정가는 틈을 타 손권이 합비를 공격한 적이 있었다. 합비는 장료, 이전, 악진이라는 세 장수가 지키고 있었는데 조조는 장수들의 장점만을 취하여 전쟁에서 이길 수 있는 전략을 세웠다고 한다. 남과 공을 다투지는 않지만 혼자서 제 몫을 다하기에는 역량이 부족한 이전을 전투 경험이 풍부하면서 개인적 이익을 돌보지 않는 장료와 짝을 이뤄 성 밖에서 싸우게 하고, 전투에서 몸소 병졸들 앞에서 용감하게 싸울 줄 아는 악진에게는 성을 지키도록 하였다. 그 결과 세 장수는 손권의 대군을 무리칠 수 있었다. 사람을 파악하고 활용할 줄 알았던 조조가 세 장수의 장점을 살리고 단점을 피하여 결국 승리를 일궈낸 것이다.


“결점은 40%만 보고 장점은 60%를 보라”는 말이 있다. 부하 직원에게 단점이 있더라도 장점을 살피고 그것을 살릴 수 있도록 만드는 것이 리더의 중요한 역할임을 명심해야 할 것이다.

1. 사용자 PC/PDA에 전용 브라우저 및 UI 콤포넌트 설치

“화면 XML File”을 보기 위해서는 새로운 브라우저 혹은 뷰어가 필요하고 C/S 기능을 처리하기 위하여 각종 UI Component가 필요하므로 이를 설치해야 화면을 볼 수 있게 된다. 물론 과거 C/S처럼 화면단위로 매화면 정보를 컴파일하여 설치하는 것이 아니라 한번만 다운로드하면 된다. 화면의 표현은 서버에서 화면 속성 및 배치 정보를 다운로드 받아 그대로 표현하게 된다.

2. XML 화면처리용 브라우저 구동

사용자(혹은 자동으로)는 브라우저를 구동한다. 여기서 브라우저는 웹 브라우저가 아니다. 화면XML을 처리하기 위한 브라우저이다. 제품마다 뷰어, 플레이어, 버추얼 엔진이란 용어를 사용한다.

3. 환경(Configuration) 파일 로딩 및 브라우저 환경 세팅

이 부분은 MiPlatform 및 몇몇 제품에서 환경 설정 및 버전관리, 히스토리 관리를 위하여 서버에서 다운로딩 받게 된다. MiPlatform에서는 브라우저가 구동된 후 환경 파일을 로딩하도록 되어 있다. MiPlatform에서는 이를 Start XML이라고 부른다.

4. 화면 XML 로딩 및 화면 브라우징

화면 XML 파일을 브라우저가 로딩하여 XML을 사용자에게 보기 좋은 형태로 표현하게 된다.

5. 화면을 데이터와 연계하여 처리

예를 들어, 사용자가 화면에서 ‘조회’ 버튼을 누르면 DB에서 데이터를 가져와 화면상에 보여주게 된다. 이상이 전체적인 X인터넷 화면처리 순서가 된다. 이제 이에 대한 각 부분에 대하여 설명하고자 한다.

사용자 PC에 브라우저 및 콤포넌트 설치

제일 먼저 X인터넷 화면인 XML 파일을 보려면 먼저 사용자 PC에 브라우저와 각종 콤포넌트가 설치되어야 한다. 브라우저는 XML 파일을 Parsing 및 Browsing하기 위해 필요하다. 실제로 브라우저 및 콤포넌트는 각 X인터넷 솔루션 벤더에서 제공하게 된다. MiPlatform은 위 브라우저 및 콤포넌트를 EXE 형태로 브라우징하는 경우와 ActiveX 형태로 브라우징되는 경우 등 2가지 형태로 제공한다. 그렇다고 MiPlatform에서 2가지 형태에 대해 화면을 별도로 구현해야 하는 것은 아니니 걱정하지 않아도 된다.

EXE 형태로 브라우징한다는 뜻은 웹 브라우저 등과 관계없이 독립된 애플리케이션 형태로 브라우저가 구동되어 화면을 동작하게 됨을 의미한다. 반면 ActiveX 형태로 브라우징한다는 뜻은 웹 브라우저나 C/S 등의 기존 애플리케이션 화면 위에서 MiPlatform 화면이 동작된다는 것을 뜻한다. X인터넷 솔루션 벤더에 따라 2가지를 모두 제공하는 경우가 있고 ActiveX 형태만 제공되는 경우가 있다. 몇 제품은 자바 혹은 별도의 독자적인 플랫폼을 가진 제품도 있다.

혹자는 클라이언트 설치 문제와 관련해서 “브라우저와 콤포넌트를 설치하지 않고 화면을 볼 수 없는가?”라는 질문을 한다. 하지만, 이는 “HTML을 보고자 하는데 IE 브라우저를 설치하지 않고 볼 수 없는가?”라는 질문과 동일한 질문이기 때문에 불가능한 요구사항이다. 왜냐하면, 현재 우리가 제일 많이 사용하고 있는 MS IE 브라우저는 HTML에 대하여는 화면을 예쁘게 보여주지만 XML은 그냥 XML 원문자체를 보여주기만 한다. 이를 사용자에게 예쁘게 보여주려면 기본적인 브라우저와 콤포넌트는 설치되어야 하는 것이 당연하다.

또 다른 이는 C/S 또는 자바 애플리케이션의 화면배포 문제와 MiPlatform 설치를 혼동하여 질문을 하는 경우도 있다. C/S의 경우는 개발된 화면모두가 사용자 PC에 설치되어야 한다. 하지만, X인터넷이 지향하는 바는 이와 같이 개발된 각 화면을 사용자 PC에 설치되지 않는 것을 목표로 한다. 따라서, 기본적인 모듈인 브라우저 및 콤포넌트만 설치하고 화면은 웹의 HTML처럼 실시간으로 로딩되어야 한다. 즉, C/S의 경우는 원하는 모든 파일을 사용자 PC에 설치해야 하므로 사이즈가 큰 데 비해 X인터넷의 경우는 기본 모듈만 설치하면 되므로 사이즈가 적게 되는 것이다.

그림 3. X인터넷을 도입한 웹 트리이딩 시스템 (한국투자증권)

그림 4. 다양한 기기 및 외부 컴포넌트와의 연동이 가능한 eXtended Internet

또한, X인터넷 용어 중에 스마트 클라이언트(Smart Client)라는 용어가 있다. 웹 상에서 스마트 클라이언트에 대한 설명을 보면 추상적인 느낌이 강한데 이 스마트 클라이언트가 정확히 무엇인지 묻는 분이 많다. 정확한 표현은 아니겠지만 스마트 클라이언트는 기본적으로 사용자 PC에 설치되어야 하는 모듈, 즉 브라우저 및 콤포넌트라고 이해하면 쉬울 것 같다. 이제, 실제로 사용자 PC에 브라우저 및 콤포넌트를 설치하는 방법을 간략하게 소개하면 다음과 같다. ActiveX 형태로 사용할 경우는 CAB 파일만 설치하면 되므로 별도의 설명이 필요없을 것으로 생각하여 EXE 형태로 사용할 경우에 대하여만 설명하겠다. MiPlatform에서는 Updater라는 버전 관리 모듈을 제공한다. Flex 등 많은 X인터넷 제품들이 내부적으로 비슷한 기능을 내포하고 있다.

Updater의 동작원리를 상세히 살펴보면 다음과 같다. 먼저, ActiveX의 경우는 HTML에서, EXE 형태는 타 애플리케이션에서 Updater를 구동한다. Updater가 구동되면 먼저 Update XML을 웹서버로부터 수신하여 패치, 업그레이드할 파일 목록 및 정보를 확보하게 된다. 이 목록을 이용하여 클라이언트에 기설치된 정보와 다운로드 받은 목록에 기록된 정보를 비교하여 업그레이드 여부를 결정하게 된다.

이에 시스템 운영자는 사용자에게 MiPlatform 설치를 위해 HTML(ActiveX Updater구동용) 또는 애플리케이션(EXE 형태의 Updater 구동용) 및 Update XML을 제작해야 할 것이다.

XML 화면처리용 브라우저 구동

이 경우도 EXE 형태로 사용하는 경우와 ActiveX형태로 사용하는 경우에 대해 구분하여 설명한다. ActiveX 형태로 사용하는 경우에는 먼저 ActiveX를 구동하기 위한 HTML을 제작한다. 이 HTML에 브라우저 ActiveX를 올리고 최초 URL을 연결하여 주면 된다. 이후의 화면제어는 MiPlatform 브라우저에서 처리하게 된다.

주의할 점은 HTML은 단순히 ActiveX를 구동하는 용도이고 화면 브라우징은 MiPlatform 브라우저에서 처리된다는 것이다. EXE 형태로 사용하는 경우는 대부분의 프로젝트에서 Updater의 브라우저 구동기능을 직접 이용한다. Updater의 방법을 사용하거나 구동하고자 하는 애플리케이션에서 MiPlatform 브라우저 EXE 파일을 직접 호출하면 된다.

환경 파일 및 브라우저 환경 세팅

MiPlatform에서는 프로젝트 단위(애플리케이션 대그룹)로 환경을 구축한다. MiPlatform에서는 프로젝트의 모든 환경정보가 Start XML이라는 환경(Configuration) 파일에 담겨져 있다. MiPlatform 브라우저가 구동되면 최초에 이 Start XML 파일을 웹서버로부터 다운로드 받아 환경을 설정하고 화면을 로딩하도록 구성되어 있다.

Start XML은 MIPlatform에서 제공하는 PID(Presentation Interface De-veloper)를 이용하여 구현하며 Style, Domain 정보, 전역변수 등과 애플리케이션 그룹에 대한 정의 및 사용하게 될 콤포넌트, 통신용 어댑터, MDI 관련정보, 다국어 지원항목 등으로 구성되어 있다.

여기서 주목할 점은 MiPlatform의 경우 콤포넌트 및 통신용 어댑터를 Start XML 내에 기술하여야 한다는 것인데 이는 MiPlatform의 큰 장점이기도 하다. MiPlatform은 콤포넌트 및 통신용 어댑터를 MiPlatform에서 기본 제공하는 것을 사용하게 할 수도 있고 사용하지 않게 할 수도 있도록 설계되어 있다. 이는 기업에서 이미 사용중인 추가 콤포넌트나 별도 통신 프로토콜을 MiPlatform에 플러그인 방식으로 지원하게 된다.

화면 XML 로딩 및 화면 브라우징

화면 XML은 기존의 HTML구현처럼 일반 에디터를 사용하여 직접 편집 할 수도 있겠지만 대부분의 X인터넷 제품과 마찬가지로 MiPlatform은 화면 디자인 툴인 PID(Presentation Interface Developer)를 사용하여 구현하면 된다. 개발툴 UI도 일반적인 C/S 툴과 상당히 유사하며 개발방법 또한 C/S의 화면 개발방법과 상당히 유사하다. 필자가 여러 개발자에게 MiPlatform을 교육하여 본 결과 웹만 해보셨던 개발자들에 비해 C/S를 개발하셨던 분이 교육효과 및 달성도가 큰 이유이기도 하다.

일반적으로 화면제작 툴을 이용하여 화면을 구현하게 되면 다음과 같은 순서를 따르기 마련이다. 신규 화면의 생성, 화면에 콤포넌트 배치하기, 각 콤포넌트의 Property를 조정하여 예쁘게 만들기(예를 들어, 색깔이나 폰트의 조정 등)의 순서로 진행된다.

여기까지는 웹 화면이나 C/S화면이나 구현방법이 동일하며 MiPlatform 역시 동일하다.

그 다음으로 해야 할 것이 데이터를 다운로드하여 메모리에 저장한 데이터셋과 콤포넌트를 연동(Binding)하는 절차이다. 이 부분은 C/S의 구현 방법에서 일반적인 방법이며 많은 X인터넷 제품들이 데이터셋 바인딩(Binding) 방식을 제공하고 있으며 개발생산성 제고에 큰 도움이 되는 기능이다.

그림 5. MiPlatform 개발툴 PID(Presentation Interface Developer)

웹의 경우 화면 구현시 JSP나 ASP 등의 페이지 형태로 화면을 구현한다. JSP나 ASP로 HTML을 구현할 때 제일 불편한 사항은 결과 화면을 눈으로 직접 보지 않는 상태에서 단순 에디터로만 편집한다는 점이다. X인터넷 개발툴은 최종 출력형태를 확인하면서 개발이 가능하여 이 역시 개발생산성을 제고하는데 도움이 된다. 마지막으로 이렇게 만들어진 화면에 각 콤포넌트들의 이벤트에 원하는 로직을 구현하게 된다. 이와 같이 만들어진 화면 및 이벤트 처리 스크립트는 화면 XML 파일 형태로 저장하게 된다. 웹의 HTML 파일처럼 생각하면 이해가 쉬울 것이다. 단, C/S나 자바 애플리케이션처럼 컴파일을 하지는 않는다. 개발자 PC에서 만들어진 화면을 개발툴의 Deploy 기능을 이용하여 웹서버에 배포하여 놓으면 HTML을 웹 브라우저에서 보듯이 MiPlatform 브라우저에서 화면 XML을 볼 수 있게 된다.

그림 6. X인터넷을 도입한 기업은행 스마트 u뱅킹 사례(MiPlatform)

화면을 데이터와 연계하여 처리

먼저, 이 부분의 설명에 앞서 독자들에게 이런 질문을 하고 싶다. “C/S는 웹보다 빠르다. 왜일까?”

물론, C/S는 컴파일 방식이고 웹은 Interpreting 방식이기 때문에 C/S가 빠른 것은 당연하다. 그러나, 정작 이 질문의 중요한 요지는 웹화면에서 ‘조회’ 버튼을 누르면 화면이 리로딩되기 때문에 응답속도가 느려진다는 것이다.

C/S는 화면이 데이터 버퍼 콤포넌트(화면에 보이지 않는 데이터를 저장하는 콤포넌트)와 프레젠테이션 콤포넌트(데이터를 화면에 보이도록 하는 Grid, EditBox 등의 콤포넌트)로 분리하도록 되어 있는 반면 웹은 소스 페이지에 데이터 요소와 프레젠테이션 요소가 나누어져 있지 않다. C/S의 경우 대개 데이터만 처리하는 콤포넌트가 별도로 존재하며 프레젠테이션 콤포넌트는 바인딩이라는 기술을 사용하여 데이터를 사용자에게 보여지게 된다. 데이터는 데이터 버퍼 콤포넌트만 보유하게 된다.

즉, C/S는 화면의 변화없이 데이터만 서버의 DB 등으로부터 가져와서 데이터 버퍼 콤포넌트에 넣게 되는 것이다. 데이터만 변하게 되므로 화면의 리로딩이 없고 N/W 트래픽도 적어지고 응답속도도 빨라지게 되는 것이다. 이에 반해 웹은 HTML 자체가 데이터와 화면요소가 분리되지 않으므로 데이터가 변하면 HTML을 전부 다시 가져오게 된다. 따라서 N/W 트래픽도 많아지고 화면을 리로딩할 수밖에 없는 것이다. 많은 X인터넷 제품도 용어와는 무관하게 C/S와 유사한 방식을 따르고 있어 화면의 리로딩을 없애고 있다.

이외에 몇 가지 DB연동 및 통신 관련해서 기본적인 개념과 관련해서 뜻밖의 질문들을 정리하여 본다.

● N/W는 HTTP 프로토콜을 기본적으로 사용한다?

왜냐하면, 전호에서도 언급하였듯이 X인터넷은 웹이 아니다. N/W측면에서 보면 HTTP만 사용하는 것이 아니라 TCP/IP를 수용하여야 한다. 그러나 TCP/IP는 데이터의 Layout에 대한 규정이 없으므로 HTTP를 사용하게 된다. HTTP를 사용한다는 것은 웹서버를 사용한다는 뜻이다. 의외로 많은 분들이 웹서버를 왜 사용하는지 모른다. 웹서버는 HTTP 프로토콜을 처리하기 위한 통신 Daemon이다. 물론 보안시 HTTPS의 지원이나 웹 서비스시 SOAP 지원도 있다.

● 서버측에서 DB로부터 데이터를 어떻게 가져올까?

데이터는 웹의 애플리케이션인 JSP/ASP/PHP 등을 사용하면 된다. DB의 데이터를 처리하려면 File형태로 가져올 수는 없고 애플리케이션 형태가 되어야 함은 물론이고 웹서버를 사용하므로 JSP/ASP/PHP 등을 사용하게 되는 것은 너무나 당연하다. 물론, DB가 아니라 일반 레가시 시스템이어도 전혀 문제가 없다. 왜냐하면, 레가시 연계는 MiPlatform에서 처리하는 것이 아니라 WAS에서 이미 제공하고 있는 중요 기능이기 때문이다. 혹자는 MiPlatform의 서버측 라이브러리가 레가시와 연계되는 것으로 착각하시는 분도 있다. 하지만, 라이브러리가 레가시 연계를 지원한다면 오히려 기존의 시스템을 변경하는 일이 일어날 수도 있는 문제가 생기게 된다.

● JSP 등의 애플리케이션에서는 무엇을 하면 될까?

JSP 등의 애플리케이션에서는 웹서버로부터 전달된 XML 형태의 데이터를 DB에 넣거나 DB로부터 데이터를 추출하여 XML 형태로 웹서버에 전달하면 된다. 이러한 처리를 웹과 비교하여 설명하면 웹도 거의 동일한 처리를 하지만, 웹의 경우 JSP는 프레젠테이션 콤포넌트에 대한 처리(Table Tag 등의 처리)도 포함하지만 MiPlatform은 데이터만 처리하게 되는 점이 다르다. 웹을 구현해보신 분은 알겠지만 편집기로 화면요소를 제어한다는 것이 말처럼 쉽지만은 않다. 많은 분들이 MiPlatform을 사용하면서 JSP에서 화면을 뺀 데이터만 처리하게 되어 웹에 비해 많이 편하다는 말씀을 많이 한다. DB나 레가시와의 연계는 기존 웹에서 처리하던 것과 동일하게 사용하면 된다. JSP등에서 발생한 데이터는 XML 형태로 N/W으로 전송되어 MiPlatform 브라우저로 전달되며 이러한 XML의 내용은 해당 데이터셋의 내용물이 된다.

PDA에서 화면 보기

위에서 언급한 내용은 모두 PC를 기준으로 한 것이며 여기까지는 eXecutable Internet의 영역에 해당한다. 하지만, 위에서 언급한 화면을 PDA에서 보고 싶다면 어떻게 해야 할까?

즉, eXtended Internet으로 영역을 확장했을 경우의 구현방법에 대해 알아보자.

먼저, PDA라면 대표적인 PDA OS인 WinCE에서 동작되는 Smart Client(브라우저 및 콤포넌트)가 필요하다. 여기서, 이러한 의문이 생긴다. X인터넷에서 Extended Internet의 구현은 개발자의 몫인가? 솔루션 벤더의 몫인가?

이 질문에 대한 답은 “솔루션 벤더의 몫이다”가 답이다. 어떠한 기기나 OS에서 화면을 볼 수 있느냐 하는 문제는 솔루션 벤더가 제공하는 브라우저나 콤포넌트가 해당 OS를 지원하느냐 하는 것과 동일한 의미이다. 개발자는 해당 OS의 프로젝트시 겪었던 경험만 적용해서 화면을 재구성하기만 하면 된다.

PDA용 화면을 PC용 화면과 별개로 새로이 작성하는 것이 아니다. 실제로, MiPlatform의 경우는 PC에서 구동되던 화면 XML을 PDA(WinCE)에서 동작시킬 경우 별도로 제공되는 PDA용 MiPlatform 모듈을 사용하면 되고 기능의 차이는 거의 없다. 그렇다고 개발자가 PDA용 화면을 재개발하지는 않는다. PC용 화면을 가져다가 PDA용 화면 사이즈에 맞게 콤포넌트를 재배치하거나 리사이징 하기만 하면 된다. 이때, 개발자의 PDA에 대한 경험이 약간 필요하게 되는데, 예를 들어 이미지의 경우 PDA 무경험자라면 PC의 것을 그대로 쓰겠지만, 유경험자라면 중요치 않은 이미지는 화면에서 제거시킬 것이다.

왜냐하면, PDA에서는 통신요금이 유선과는 다르게 사용량당 요금이 부과되므로 요금을 줄이는 방안을 강구해야 한다는 것을 PDA 개발 유경험자는 알고 있기 때문이다.

최근 ZD넷 블로거로 활동하고 있는 리차드 맥매너스(Richard McManus), 러셀 셔(Russel Shaw), 조에 맥켄드릭(Joe McKendrick)의 블로그에서 웹 2.0에 대한 내용을 찾아봤다. 맥매너스는 자신의 블로그명인 ‘웹 2.0 익스플로러’에 걸맞게 ‘웹 2.0은 존재한다’는 진영에 속해 있다.

그러나 “웹 2.0은 마케팅 슬로건에 불과하다”고 주장하는 셔(zdnet.com의 IP 텔레포니, VoIP, 브로드밴드 블로거)는 “웹 2.0은 존재하지 않는다”는 진영에 속한다. 웹 2.0의 수호자로 최근 떠오르고 있는 인물은 ‘웹 2.0은 존재한다’는 글을 게시한 SOA(Service Oriented Architecture) 블로거 맥켄드릭이다.

그러나 맥매너스조차 자신의 ‘다른 블로그’에서 웹 2.0이란 용어(웹 2.0은 죽었다, R.I.P 참조)가 나오게 된 배경에 대해 의구심을 나타냈으며, 최근 포스트를 통해 웹 2.0을 기술적으로 분석한 셔는 마치 자신이 월드와이드웹 전쟁을 시작한 것 같은 느낌을 받고 있다.

웹 2.0이 뭘까? 월드와이드웹 전쟁에 끼어들고 싶지는 않지만 누군가 나에게 이 같은 질문을 던진다면 웹 2.0은 컴퓨터 2.0에 더 가깝다고 대답할 것이다.

우리가 알게 됐고, 또 사랑하게 된 컴퓨터는 이제 빠른 속도로 과거의 유물(이 때문에 이제는 컴퓨터를 ‘언컴퓨터(uncomputer)'라고 부른다)로 전락하고 있다. 그뿐 아니라 인터넷 기반의 API와 구글, 야후, MS, 세일즈포스닷컴, 이베이, 테크노라티, 아마존 등 수많은 기업들과 정부가 제공하는 데이터베이스 인터페이스의 새로운 집합체로 다시 태어나고 있다.

과거의 API 집합체가 운영체제 측면에서 가장 흥미롭고 혁신적인 애플리케이션 개발이 수행된 플랫폼이었다면 새롭게 등장한 인터넷 기반의 API는 완전히 새로운 종류의 애플리케이션 개발을 유도하는 활동 공간이 되고 있다.

1개 이상의 새로운 API를 공공 혹은 사적인 데이터베이스와 창의적으로 결합하는 혼합(mashup) 애플리케이션이 단 하나도 웹에 등장하지 않은 채 거의 하루가 지나고 있다.

인터넷 사용자들에게 실질적인 가치를 제공하는 혁신적인 사이트로 필자가 최근 관심을 갖게 된 사이트가 3개 있다. 샌프란시스코의 주차관련 사이트인 파킹카마닷컴(ParkingCarma.com), 멀티플 리스팅 서비스(Multiple Listing Service)의 주택 매물을 양방향 매핑에 통합한 집리얼티(ZipRealty), 맵섹스어펜더스닷컴(mapsexofferders.com)이다. 맵섹스어펜더스닷컴은 이름만으로도 사이트의 성격을 추측할 수 있을 것이다.

이러한 새로운 API 집합체는 여러 가지 측면에서 “네트워크가 곧 컴퓨터”라는 썬의 지난 슬로건을 입증해준다. 과거의 컴퓨터는 이제 유물로 변하고 있고, 운영체제의 전통적인 업데이트와 유지 방식도 변화되고 있다. 오픈소스 운영체제도 물론 예외가 아니다.

신성한 전쟁을 시작할 생각은 없지만 리눅스 등 오픈소스 운영체제의 ‘공식’ 커널조차도 이제는 질서정연한 체계를 갖고 있는 컴퓨터 전문가 위원회의 감시 하에 놓여 있다. 비교해서 말한다면 API의 집합체인 윈도우 등 사유 운영체제는 개발 측면에서 볼 때 리눅스 같은 오픈소스 운영체제보다 훨씬 더 권위적이다.

하지만 그렇다고 해서 인터넷 기반의 새로운 API 집합체인 새로운 운영체제가 리눅스보다 권위적이지 않다는 말은 아니다. 어쨌든 누구나 자신의 API를 언제라도 추가해 ‘새로운 운영체제’를 강화시킬 수 있게 됐다.

일부 인터넷 업계 거물들은 내부 개발 방식에 의해서든 아니면 딜리셔스(del.icio.us)와 플릭크(Flickr)처럼 M&A를 통해서는 자신들의 API 포트폴리오를 빠르게 확산시키고 있으며, 이 포트폴리오를 설명하기 위해 ‘플랫폼’이라는 단어를 사용한다. 이처럼 간단한 플랫폼이 개발자들의 개발 활동을 독려할 것이라는 데는 의심의 여지가 없지만 오랜 역사를 가진 API에서 그동안 우리가 보아왔던 몇 가지 기억할 만한 일들은 짚고 넘어가야 할 것 같다.

1980년대로 한 번 돌아가보자. 당시에 등장했던 최고의 제품(uber, 크로스 플랫폼 API 포함) 몇 가지는 실리콘밸리나 중국의 수백만 달러짜리 근사한 연구실이 아닌 누군가의 창고에서 탄생했다. 우리 앞에는 몇 가지 혼란스러운 상황이 놓여 있으며, 한 가지 분명한 것은 지금 이 자리에 안주해서는 안 된다는 점이다.

그동안 우리가 익숙했던 환경과 비교해보면 쉽게 액세스가 가능한 API의 급속한 확산은 그야말로 언컴퓨터(uncomputer)식 환경이다. 새로운 API에 우리가 익숙해지느냐 그렇지 못하느냐는 별개의 문제다. 여기서 핵심은 지금까지 제안된 모든 커널을 수정할 때 거쳐야 했던 제다이 기사들(Jedi Knights)의 원탁 회의가 어느 곳에도 존재하지 않는다는 사실이다.

또한 테크크런치(TechCrunch) 편집자 마이크 아링톤은 새로운 혼합(mashup) 애플리케이션이 하루가 멀다하고 등장하는 것처럼 끊임없이 API 관련 소식을 전하고 있다. 아링톤은 새로운 API가 사용가능해지면 곧바로 블로그에 소식을 올리면서 새로운 API 특종을 다루는 데 상당한 솜씨를 발휘하고 있다.

‘언컴퓨터(uncomputer)’에 대해 아직도 확신이 서지 않는가? 그렇다면 다음 내용을 고려해보라. 누구라도 언제나 기본적인 사용자 인터페이스인 새로운 API를 자유롭게 추가할 수 있다. 그리고 이 인터페이스는 새로 추가된 API의 이점을 활용하기 위해 업데이트할 필요도 없다. 언컴퓨터(uncomputer) 같은 세상 아닌가.

이러한 상황을 기존의 운영체제에 새로운 API를 추가할 때의 상황과 비교해보라. 업그레이드 주기마다 모든 종류의 특별한 하드웨어, 새로운 소프트웨어, 그리고 비용까지 맞춰야 하기 때문에 업그레이드 자체가 고통스러운 일이었을 게다. 하지만 수백만 가지의 혼합(mashup) 애플리케이션을 누구나 사용할 수 있게 되면 자신의 앞에 어떤 기술이 놓여있든 상관없이 “우리가 도대체 지금까지 생각한 게 뭐지? 이런 걸 왜 진작 하지 않았을까?”라며 수많은 사람들이 지금까지 했던 방식을 되돌아보게 될 것이다.

마지막으로 한 가지 더 언급할 것은 여기에는 생태계 스토리가 존재한다는 사실이다. 즉 새로운 API의 집합체는 과거의 집합체보다 더 편리하게 개발자들이 따라올 수 있도록 유도한다. 이러한 과정을 “목표 도달(reach)”이라고 칭하며, 타깃 마케팅이라는 말로도 알려져 있다.

새로운 API 집합체는 과거의 집합체보다 애플리케이션 개발자들의 활동 폭을 더욱 넓혀주고, “혼합 애플리케이션 아티스트(메리 하더가 최근 필자와의 대화 도중 만들어낸 신조어)”들이 전보다 더 빠르게 애플리케이션을 출시할 수 있도록 해준다. 맵빌더닷넷(mapbuilder.net)에 접속해 API가 특정 유형의 RMD(Rapid Mashup Development)에 어떻게 적용되는지를 보게 되면 아마 놀랄 것이다.

그런데 과연 개발자들이 자신이 구워낸 케익을 가져가고, 또 먹을 수도 있게 될까? 이러한 생태계 내에서라면 대답은 ‘그렇다’다. 이유는? OS X 애플리케이션을 운영하는데 OS X는 갖고 있지 않고, 윈도우 애플리케이션을 운영하는데 윈도우는 갖고 있지 않으며, 리눅스 애플리케이션을 운영하는데 리눅스는 갖고 있지 않은 사람들이 수없이 많이 이 세상에 존재하기 때문이다.

하지만 브라우저를 갖고 있지 않은 사람은 거의 찾아보기 어렵다. 또한 새로운 API 집합체가 등장하기 전에도 애플리케이션 개발자들은 이처럼 풍부하고 손쉬운 생태계에 이미 노출돼 있었다. 거의 모든 시장에 접속할 수 있을 정도로 광범위한 브라우저를 통해서 말이다. 이제 더 이상 컴퓨터는 필요하지 않다. 그것이 곧 언컴퓨터(uncompute)다.