[지디넷코리아]나날이 새로운 기술들이 쏟아지는 가운데 닷넷도 수년이 흘렀다. 벌써 많은 프로젝트들이 닷넷 기술을 적용해서 수행되었지만, 아직도 왠지 닷넷을 낯설게 보는 개발자들을 주변에서 쉽게 찾아볼 수 있다.

필자는 이전 기술에 대한 이해를 바탕으로 과감히 새로운 기술을 받아들이되 충분히 자기의 것으로 소화시켜 실무에 적용하라고 조언하고 싶다. 또한 단순한 개발 기술에만 집중하지 말고 패턴과 아키텍처에 대한 이해에도 관심을 가지는 것이 중요하다고 생각한다.

필자가 본격적으로 프로그래밍을 시작하게 된 것은 D조선 연구소에 근무하게 되면서부터이다. 당시 생산관리 부서에서 생산계획을 하는 시스템이 DOS 기반으로 되어 있어 GUI 지원이 부족하기 때문에 업무 수행에 어려움이 있으니 연구소에서 윈도우 기반으로 시스템을 개발해 달라는 요청이 있었다.

당시만 해도 윈도우 환경에서 프로그램을 개발할 수 있는 사람이 일반 제조업체에는 많지 않았던 때였다. PC 성능은 그리 좋지 않은데 생산계획 업무에서 사용하는 데이터의 양은 많고 UI는 복잡한 터라, 개발은 MFC를 사용하기로 하였다.

1년간의 개발을 통해 시스템을 현업에 배포했다. 많은 개발 프로젝트들이 그렇듯이 프로젝트의 어려움은 그 때부터 시작이었다. 많은 요구사항 변경이 있었고 수많은 버그들과의 싸움이 있었다. 어렵사리 현업 적용에 성공을 하고, 2차, 3차 후속 프로젝트를 수행했지만 서서히 회의가 들기 시작했다.

기업 내부에서 진행하는 프로젝트니 기간이 연장되고 현업 요구사항이 바뀌어도 그대로 수용하면서 갈 수 있었지만, 만약 외부에 프로젝트를 줘서 진행했다면 성공할 수 있었을까? 한사람의 개발자요 프로젝트 리더로서 충분한 생산성을 내고 있으며 경쟁력을 가지고 있나? 이런 의문과 장래에 대해 고민하면서, IT 업계로 이직을 하게 되었다.

최신 기술에 과감히 도전하라
이직한 업체는 CBD 등의 방법론과 아키텍처 컨설팅을 전문으로 하는 회사였다. 규모는 30여명 되었지만, 업계에서는 나름대로 인정받는 회사였다. 회사에서 수행하는 프로젝트는 주로 금융권 시스템에 대한 컨설팅이었고 기술 기반도 대부분 자바를 사용하는 것들이었다. 자바에 대해서는 언어 정도만 알고 있는 상태였기 때문에 J2EE 쪽을 집중적으로 스터디하고 있었는데 회사에서의 첫 번째 미션은 엉뚱하게도 닷넷을 사용해야 하는 일이었다.

회사의 홈페이지와 인트라넷은 ASP.NET으로 개발되어 있었는데 인트라넷 기능에 일일업무 보고를 위한 기능을 추가하라는 것이 필자에게 내려진 첫 번째 임무였다. 주어진 시간은 일주일. 필자는 그때까지 MS 기술을 사용한 개발을 주로 하기는 했지만 MFC와 COM 기반의 윈도우 애플리케이션 개발이 주였기 때문에 닷넷을 사용하거나 웹 기반 애플리케이션 개발을 해본 경험이 없었다.

그저 흥미삼아 책을 보면서 홈페이지 정도 만들어본 것이 전부인 데다 닷넷이라면 왠지 어렵고 복잡한 딴 세상의 물건인가보다 하고 살았기 때문에 당장 일주일 안에 닷넷으로 회사 사람들이 모두 사용할 기능을 만들라는 것은 상당히 부담스러운 일이었다.

C#은 이전에 보아둔 적이 있는 터라 ASP.NET 기본서를 놓고 인트라넷 코드를 살펴보니 의외로 내가 너무 겁을 내고 있었다는 생각이 들었다. ASP.NET에서는 디자인과 코드를 분리해서 작업할 수 있게 되어 있기 때문에 디자이너가 만들어준 페이지와 별도로 필요한 기능을 하는 코드를 해당 클래스에 구현하고 간단히 연결만 해주면 되었다.

선임자가 만들어둔 다른 기능들을 참고해서 진행을 하니 그리 어렵지 않게 필요한 기능을 주어진 기간 안에 완성할 수 있었다. 필자와 닷넷과의 인연은 이렇게 뜻하지 않게 시작되었다.

하루가 멀다 하고 새로운 기술들이 쏟아져 나오고 있고 기존에 알고 있던 기술들도 계속해서 변화를 거듭하고 있다. 어떤 사람들은 이것들을 다 따라가는 것은 불가능하다며 새로운 기술을 습득하기를 포기하기도 하고, 혹은 자신이 가지고 있는 지식이 최고의 것이라 생각하여 새로운 것들을 무시하고 받아들이지 않는 경우도 있다.

새로운 기술이 늘 좋은 것은 아니며 시간이 지남에 따라 오히려 옛 것을 선택하는 것이 바람직한 경우도 있겠지만, 그러한 기존의 기술과 새로운 기술에 대한 이해를 바탕으로 정확한 취사선택을 할 수 있는 상황에서 판단할 문제일 것이다.

하지만 변화가 생명인 IT 업계에서 생존하기 위해서는 새로운 것에 대해 도전하고 이를 받아들이는 것을 두려워할 필요도 없으며 더더욱 게을리해서는 안된다. 엄청나게 많은 기술에 대해 한번에 이해하고 익히려고 하면 엄두가 나지 않을 것이다. 하지만 새로운 기술이라 해도 어느 날 아침에 하늘에서 뚝 떨어지는 것이 아니고, 기존 기술을 기반으로 진화해 나가는 것이기 때문에 하루하루 열린 마음으로 도전해간다면 많은 기술들을 진정 자신의 것으로 소화해낸 개발자가 될 수 있을 것이다.

COM이 닷넷을 이해하는 데 도움이 된다
MS의 빌게이츠를 립 서비스 전문가라고 혹평하는 이들이 있다. 물론 빌게이츠가 말한 것 중에 이루어지지 않은 것도 있고 출시 기한을 넘기는 것은 비일비재하기 때문에 그런 말을 들을 만하다는 생각이 들기도 하다. 하지만 필자는 빌게이츠가 비전을 제시하고 자신이 제시한 비전대로 업계를 이끌어나가는 사람이라고 생각한다.

MS의 기술들은 현재 상황에서는 완전히 이루어지지 않았지만 미래에 대한 로드맵을 제시하고 한 단계씩 이루어나가는 방식으로 만들어진다. 로드맵 상에서 새로운 기술로 만들어내지 못한 부분들은 기존의 기술을 확장하거나 경우에 따라서는 말도 안 되게 이름만 바꾸어서 집어넣어 두기도 한다. MS의 닷넷 기술 역시 이제 막 걸음마를 떼고 성숙하려고 하는 단계라고 생각하고, 많은 부분들이 기존 기술을 활용하고 있다(물론 로드맵에 따르면 언젠가는 새로운 기술로 대체될 것이지만).

이직한 회사에서의 첫 번째 프로젝트는 K통신사에서 COM/DCOM 기반으로 ARS 시스템을 구축하는 프로젝트에서 기술 컨설팅을 하는 것이었다. 기존 ARS 시스템들은 장비에서 제공하는 API와 라이브러리를 사용하고 소켓을 사용하여 통신하는 방식으로 돼 있었다.

기존 라이브러리들을 COM 래퍼(Wrapper)를 만들어 컴포넌트화하고 COM+로 컴포넌트 서비스를 제공하며 시스템간 통신은 DCOM 통신을 하도록 하는 것이 주된 내용이었다. 이 프로젝트를 수행하기 위해서 ATL을 사용해서 COM+ 컴포넌트를 만들기 위한 기술들을 다시 점검하고 프로토타입을 만들었다. 프로젝트가 끝나고 닷넷의 COM+ 컴포넌트 서비스를 들여다보니 기본적인 사항들은 완전히 동일하다는 것을 알게 되었다.

현재 버전의 닷넷 프레임워크는 CLR에 완전히 통합된 미드티어 서비스를 제공하지 못하고 있다. 닷넷의 미드티어 서비스는 <그림 1>에서 닷넷의 미드티어 서비스에 나타낸 것 같이 언매니지드 코드를 사용하는 COM+, IIS, 그리고 MSMQ를 기반으로 제공된다. COM+는 닷넷에서는 엔터프라이즈 서비스(Enterprise Service)로 이름을 바꾸었지만 실제 동작은 COM+ 서비스를 사용하기 때문에 닷넷의 컴포넌트 서비스인 엔터프라이즈 서비스를 이해하기 위해서는 COM과 COM+에 대한 이해가 필수적이라고 할 수 있다.

<그림 1> 닷넷의 미드티어 서비스

COM에서 컴포넌트나 인터페이스를 식별하기 위해서는 CLSID와 IID 등의 GUID를 사용한다. 그러나 닷넷에서는 GUID를 사용해서 컴포넌트나 인터페이스를 식별하지는 않기 때문에 닷넷에서 컴포넌트를 만들 때는 COM에서처럼 GUID를 생성하고 관리할 필요가 없다.

이에 따라 원칙적으로는 닷넷의 엔터프라이즈 서비스를 사용하여 서비스드 컴포넌트(Serviced Component)를 만들 때 COM에서처럼 GUID를 신경 쓸 필요가 없다. 하지만 COM+가 COM 기반의 컴포넌트 서비스이기 때문에 실제 COM+에서 동작하는 컴포넌트가 되기 위해서는 GUID를 부여해야 할 필요가 있다.

닷넷 엔터프라이즈 서비스에서는 사용자가 이를 지정하지 않아도 COM+에서 동작할 수 있도록 자동으로 컴포넌트에 GUID를 부여해준다. 그런데 이 경우 GUID가 매번 변경됨에 따라 클라이언트에 배포된 프록시를 재배포해 줘야 하는 문제가 발생할 수 있다. 따라서 이러한 배치 문제를 제거하려면 모든 COM+ 컴포넌트에 GUID를 지정해야만 한다. COM에 대한 이해가 전혀 없는 상태라면 이와 같은 상황을 이해하고 대처하는 데 어려움이 있을 수 있다. 이와 같은 상황은 미들티어 서비스들이 완전히 닷넷 프레임워크에 포함될 때까지는 유지될 것 같다.

개발자 커뮤니티를 적극 활용하라
닷넷으로 분산 애플리케이션을 개발하는 경우 분산 객체간의 통신을 위한 방법은 전통적인 DCOM 통신을 이용할 수도 있고, 닷넷 리모팅(.Net Remoting), 그리고 XML 웹 서비스를 사용할 수도 있다.

DCOM 통신은 닷넷 이전의 COM 기반의 분산 아키텍처에서부터 사용되던 방법으로 언매니지드 코드로 작성된 객체들과 통신할 수 있다는 장점이 있는 반면 바이너리 프로토콜이기 때문에 방화벽이 있는 환경에서는 방화벽의 보안 정책과 맞물려 문제를 야기하는 경우가 종종 있다.

이에 반해 XML 웹 서비스는 HTTP 기반의 SOAP 프로토콜을 사용함으로써 방화벽에 별도의 포트를 개방하지 않고도 원하는 서비스를 제공할 수 있으며, 서비스를 사용하는 클라이언트가 다른 플랫폼이어도 무관하다는 장점을 가지고 있다. 닷넷 리모팅은 닷넷 애플리케이션간 통신을 위해 만들어진 기술로서 일반적으로 XML 웹 서비스보다 좋은 퍼포먼스와 기능을 제공해준다.

필자가 얼마 전에 수행한 프로젝트는 국내 D조선소의 생산 계획 시스템을 닷넷 기반으로 개발하는 것이었다. 아키텍처를 수립하면서 클라이언트 티어는 윈폼(WinForm)을 사용하고 비즈니스 티어에는 엔터프라이즈 서비스를 사용하되 티어간 통신에는 닷넷 리모팅을 사용하기로 했다. 티어간 데이터 전달 객체(Data Transfer Object)는 Strongly Typed DataSet을 사용하는 것으로 했다.

원칙에 충실하게 초기 아키텍처를 수립하고 프로토타입 시스템을 개발하여 아키텍처를 검증하는데 문제가 발생했다. 원격 객체에 대해서 Strongly Typed DataSet을 반환하는 메쏘드를 호출할 때는 문제가 없었는데, 반대로 Strongly Typed DataSet을 파라미터로 넘기는 메쏘드를 호출할 때는 보안 관련 예외사항(Exception)이 발생하는 것이었다.

틀림없이 뭔가 코딩을 잘못했을 것이라 생각하고 닷넷 리모팅 관련 서적을 다시 다 뒤져보았지만 원칙을 벗어나게 코딩한 부분은 전혀 없었다. 아키텍처 단계를 마무리해야 하는 시점은 다가오는데 원격 호출이 제대로 되지 않아서야 나머지 테스트를 진행할 수도 없는 상황이라 마음은 너무 조급했다.

일주일을 고민했는데 의외로 해법은 아주 쉽게 발견됐다. 구글의 뉴스그룹(groups.google.com/groups?hl=en&lr=&group=microsoft.public.dotnet)을 조회해보니 이미 많은 사람들이 이 문제를 고민하고 해법까지도 친절히 나와 있는 것이었다.

문제는 닷넷 프레임워크가 1.1로 업그레이드되면서 보안을 강화하였고 이 때문에 이와 같은 상황에서 보안 오류가 발생하는 것이었다. 해법은 다음과 같이 서버측과 클라이언트측 각각에 대해 "typeFilterLevel"을 설정해주면 되는 것이었다.

문제를 해결하기 위해 혼자 고민하면서 일주일을 보내는 동안 잠을 자려고 누워도 온통 이 문제에 대한 생각뿐이었고, 관련 레퍼런스를 뒤져보면서 문제와 상관없는 부분까지 많이 배울 수 있었던 것은 좋았으나 필자와 동일한 문제를 고민한 사람들의 결과를 먼저 찾아보았더라면 바쁜 프로젝트 일정을 많이 아낄 수 있었으리라는 아쉬움이 남았었다.

이 문제를 해결한 이후로는 기술적인 문제가 발생하면 우선 관련 뉴스 그룹을 검색해서 나와 유사한 문제가 있었는지를 확인하고 있다. 필자가 자주 사용하는 개발자 커뮤니티는 <화면 1>과 같다.

<화면 1> 필자가 자주가는 커뮤니티

뉴스그룹(microsoft.public.dotnet)

GotDotNet(www.gotdotnet.com)

데브피아(www.devpia.com)

TheServerSide.Net(www.theserverside.net)

최근 개발자 커뮤니티를 통해 얻을 수 있는 것은 개발 중에 부딪힐 수 있는 단편적인 문제에 대한 해결 방법뿐 아니라, 많은 경험들의 집약체라 할 수 있는 패턴과 엔터프라이즈 프로젝트에서 자주 사용되는 닷넷 코드들을 클래스 라이브러리 형태로 만들어서 제공하는 애플리케이션 블럭(Application Block), 그리고 견고한 시스템을 만들기 위한 아키텍처에 관한 기사들에 이르기까지 많은 선임자들의 고민과 경험을 얻을 수 있다.

MS에서는 ‘Patterns & Practices’ 사이트(www.microsoft.com/resources/practices/default.mspx)를 통해 닷넷에서 사용할 수 있는 패턴과 애플리케이션 블럭, 그리고 아키텍처에 관한 좋은 기사와 서적, 그리고 클래스 라이브러리를 배포하고 있다. 약간의 관심과 노력을 기울인다면 시중에서 구할 수 있는 어떤 책보다도 양질의 정보를 담고 있는 정보를 얻을 수 있다.

<화면 2> Patterns & Practices 사이트

엔터프라이즈 애플리케이션들은 갈수록 복잡한 업무 프로세스를 반영하고 있고, 이를 구현하기 위해서 여러 기술을 복합적으로 사용하고 있다. 복잡한 시스템을 구축할 때 한 분야에만 시야를 고정시키고 구현 기술에만 포커스를 두게 되면 프로젝트 전체를 망치게 될 수 있다.

최근의 프로젝트에서는 체계적인 방법론과 아키텍처 수립을 기본으로 요구하는 경우도 많아지고 있고, 따라서 개발자들도 이에 대한 이해가 부족한 경우 고급 인력으로 인정받지 못하게 된다. 다행히도 우리 주변에는 우리가 노력하기에 따라서 이에 대한 이해를 하기에 충분한 정보가 제공되고 있다. 아직 이에 대해서 관심을 갖지 못했던 개발자라면 오늘이라도 관련 사이트를 돌아보며 마음가짐을 새로 하는 것도 좋을 것이다.

닷넷으로 개발하면 퍼포먼스가 나쁘다?
D조선 프로젝트가 진행되면서 개발이 마무리되어갈 무렵 현업 담당자들로부터 UI 퍼포먼스에 대한 이슈가 제기되었다. 이전에 사용하던 시스템에 비해 반응 속도가 너무 느리다는 것이었다.

이전 시스템은 C++로 작성되었고 GDI를 직접 사용하는 것이었기 때문에 당연히 퍼포먼스가 좋은 데다 데이터베이스만 원격에 있고 나머지는 모두 클라이언트에서 구현된 팻 클라이언트(Fat Client)이기 때문에 퍼포먼스가 동일하기를 바라면 안 된다고 반은 구슬리고 반은 협박을 하였다.

그리고 개발자들 노트북에서는 그럭저럭 쓸만해 보이는데 현업이 이전 시스템에 너무 익숙해져서 불만을 표시한다고 생각하고 넘어가려 했는데 현업의 불만이 쉽게 수그러들지 않는 것이었다. 예전 같으면 2시간이면 처리할 일을 시스템이 느려서 이틀은 걸리게 생겼다고 아주 난리가 났다.

도대체 왜 그런가 하고 내려가 보았더니, 아뿔사! 현업 담당자의 PC가 펜티엄3 800㎒였던 것이었다. 프로젝트 초기에 계획한 하드웨어 사양에 한참 미치지 못하는 사양이라 많은 데이터를 올리는 경우 클라이언트단에 무리가 갔던 모양이었다. 사용자 환경을 면밀히 확인하지 못했던 것이 화근이었다. 부랴부랴 하드웨어 업그레이드를 요청하고 프로젝트팀에서도 UI 퍼포먼스 향상을 위한 조처를 강구하기로 하였다.

시간 여유를 들여 UI 프레임워크를 들여다보니 닷넷의 코드가 네이티브 코드보다야 당연히 느리기는 하겠지만 그래도 너무 느리다는 생각이 들었다. 메쏘드별로 수행 시간을 측정해보니 가장 많이 호출되는 메쏘드에서 검색을 하는 부분이 시간을 많이 소요하게 되어 있는 것을 발견하게 되었다.

이 부분에 Hashtable 클래스를 사용하여 검색하는 것으로 변경했더니 UI 반응 속도가 놀라울 만큼 빨라졌다. 자료구조를 적절하게 사용하는 것은 어찌 보면 아주 기본적인 것이지만 늘 기본을 지키지 않는데서 문제가 발생하는 법이다. 또한, 닷넷으로 개발하면 이전에 비해서 당연히 퍼포먼스가 떨어진다는 안이한 생각에 퍼포먼스에 대한 고려를 충분히 하지 못했던 것도 잘못된 점이었다.

프로젝트를 진행하다 보면 이와 유사한 경험을 종종 하게 된다. 또한, 이러한 문제는 대부분 프로젝트 후반에 일어나는 것이 일반적이다. 그런 경우에 흔히 사용하는 변명이 “운영 시스템에 문제가 있다”라거나 “이 기술은 아직 문제가 많은 기술이야”라는 것이다.

그러나 필자의 경우와 같이 문제는 운영 시스템이나 사용한 기술에 있는 것이 아니고, 설계와 개발시 기능 외적인 요소들에 대해 세심하게 고려하지 못하고 부분적인 기능만 만족시킨 채 자기 할 일을 다 했는데 나머지가 문제라고 생각하는 경우가 많다는 것이다. 프로젝트 중에 문제가 발생할 경우 자신이 담당한 부분이 단순한 기능 이외의 요소들을 충분히 반영했는지, 개념에 충실하게 코드를 작성했는지, 좀 더 넓은 시각으로 살펴보는 습관을 가지도록 하자.

변화를 따라가 보는 즐거움
최근 들어 닷넷으로도 많은 프로젝트들이 만들어지고 있어 닷넷 기술도 시장에서 어느 정도 받아들여지고 있는 것 같다. 많은 기술들이 그렇듯이 닷넷도 어느 날 하늘에서 뚝 떨어진 것이 아니고 기존의 기술을 기반으로 주변 기술들의 장점을 수용하면서 만들어지고 발전해가는 과정에 있다.

따라서 기존 기술들에 대한 이해가 새로운 기술의 깊은 면을 이해하는데 많은 도움이 된다고 생각한다. 이제 처음 개발자로 시작을 하는 입장에서 기존의 기술까지 이해하면서 새 기술까지 익히는 것은 어려운 일이겠지만 기존 기술을 이해하고 있는 개발자라면 새로운 기술을 받아들일 때 기존 기술과 비교해가면서 기술의 진화 과정을 살펴보면 좀 더 깊은 이해를 할 수 있으리라 생각한다.

닷넷 프레임워크 2.0 베타가 발표되고 또 많은 기술들이 적용되었다. 변화의 과정에서 어떤 점들이 달라지고 기술이 진화해가는지 따라가 보는 일도 즐거운 일일 것 같다. @

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