"할아버지가 될 때까지 엔지니어로 남는 것이 소망이다"

유경상 | 드원테크놀러지 수석 컨설턴트
ksyu33@theonetech.co.kr

애플리케이션 개발을 시작하면서 가장 먼저 주목한 기술은 무엇이었나요.
COM이었습니다. 원래는 코바(CORBA)를 하고 싶었는데 사정이 생겨 코바를 할 수 없게 됐습니다. 그래서 대응되는 다른 기술을 알아보다 찾은 것이 COM/DCOM이었습니다. 그래서 COM 공부를 시작했고 그 이후로 MS 기술을 주로 다루게 됐습니다.

COM에서 어떤 가능성을 발견하셨죠.
가능성이라기보다는 코바를 못하는 데 대한 보상 심리(?)로 시작했습니다.(웃음) 일단은 기본 아이디어가 좋았어요. 물론 코바도 같은 아이디어에서 출발했지만요. 사실 윈도우 3.1 시절부터 기반에는 COM 기술이 있었습니다. 그러던 것이 1995년부터 외부에 노출시켜 쓰기 시작했고 대표적인 예가 액티브X 입니다. 비록 처음에는 OLE 기술을 위해 태어난 것이기는 하지만 점점 발전하면서 인터넷 환경과도 잘 맞게 되었죠. 그래서 시작했고 지금까지도 그 때 공부한 것들을 유용하게 쓰고 있습니다. 현재 MS 운영체제 역시 많은 부분에서 COM이 쓰이고 있습니다. 아마도 COM이 완전히 사라지려면 상당한 시간이 걸릴 것 같습니다.

COM 자체는 이제 닷넷으로 포장되어 전면에 드러나지 않게 됐는데, 그동안 COM이 끼친 영향에 대해서는 어떻게 평가하시나요.
닷넷 프레임워크가 처음 나올 당시 이름은 COM+ 2.0이었습니다. 원래 COM 기술을 제대로 쓰려면 C++를 써야 하는데 그렇게 하면 작업량이 많아지는 불편함이 있었습니다. 그래서 처음에는 COM 객체를 쉽게 쓸 수 있게 하는 목적으로 설계됐는데 나중에 플랫폼 의존성을 줄이기 위해 자바처럼 가상 실행 환경으로 다시 태어났던 것이죠. 닷넷 초창기에 역컴파일러로 분석해 보면 COM+ 2.0이란 용어가 많이 쓰인 것을 볼 수 있습니다. 그러다 마케팅 관점에서 닷넷이란 이름으로 전파된 것입니다. 닷넷도 COM의 후예라고 볼 수 있는 것이죠.

COM 외에 어떤 기술들을 다루시나요.
MS 기술 트렌드를 따라가게 됩니다. 주로 닷넷과 XML 웹 서비스 기술을 다뤘고 X-인터넷 기술 중에서는 스마트 클라이언트 관련 프로젝트를 많이 했습니다. 개인적으로는 분산 트랜잭션이나 WCF 같은 커넥티드 시스템, 원격 호출 쪽으로 관심이 많습니다.

말씀하신 COM에서 닷넷으로 변화한 과정의 경우처럼 MS 기술은 똑같은 것이 작명이 계속 바뀌어 좀 혼란스럽지 않나 하는 생각이 듭니다.
그냥 따라가야죠.(웃음) MS는 소프트웨어 라이선스를 파는 회사라는 특성 때문에 항상 새로운 것을 내놓고 사용자들이 업그레이드 하도록 유도해야 합니다. 오피스의 경우 새로운 사용자 인터페이스가 계속 나오는 것은 그 때문이죠. 운영체제의 경우는 애플리케이션이 많이 나오는 것이 중요한데요. 애플리케이션이 지속적으로 개발되게 하려면 개발 환경에 신경을 많이 쓸 수밖에 없습니다. 개발자들의 구미를 당길 수 있는 새로운 기능이나 현란한 사용자 인터페이스를 만들 수 있는 프레임워크들이 그 예죠. 이름이 자주 바뀌는 것이 좀 혼란을 주기는 하지만 개발자를 위한 기술 마케팅이 중요하니까요. 어쩔 수 없는 것 같습니다.

스마트 클라이언트 프로젝트를 하면서 어려움을 많이 겪으셨다고 하던데, 기억에 남는 것이 있다면.
당시에는 관련 자료가 많지 않았습니다. MSDN을 찾아봐도 이런 방식의 기술이 있다 정도로만 나와 있었으니까요. 그런데 프로젝트에 기술을 적용하다 보니 다양한 기술적 문제가 생겼습니다. 로드 속도가 느리다거나, 동작을 제대로 하지 않는다거나 하는 문제가 있었습니다. 외국에도 사례가 없었기 때문에 직접 시행착오를 통해 문제 원인을 파악하고 해결해야 해서 고생을 좀 했습니다. ChartFX 라이선스 오류 때문에 고생했던 적이 있었는데 결국 역컴파일러로 코드를 파헤쳐 원인을 찾아냈고 라이선스 확인을 우회하는 코드를 만들어야 했었습니다. 그 부분이 아직도 가장 기억에 남네요.

당시로서는 앞서 가셨던 셈인가요.
앞서 나갔다기보다는 중노동을 많이 했죠.(웃음) 기술이라는 게 앞서 나가고 아니고의 문제라기보다는 경험의 많고 적음이 중요한 것 같습니다. 기술이야 공부하면 되지만 해당 기술에 대해 경험이 얼마나 풍부하냐에 따라 문제에 대한 대처 양상이 다르니까요.

집필이나 교육, 또는 컨설팅을 위해 닷넷 내부 구조를 분석하시는 것으로 알고 있는데요. 프레임워크 내부 구조를 파악해 두는 게 일반 개발자들에게도 도움이 될까요, 아니면 그냥 프레임워크가 제공하는 편리한 기능을 활용하는데 중점을 두는 것이 나을까요.
시간 여유가 있다면 프레임워크 내부를 열어보고 구조와 원리를 알아두는 건 항상 도움이 됩니다. 학습 속도도 빨라지고 내부 구조와 원리를 모르는 사람과는 문제 해결 접근 방식도 다르죠. 하지만 현실에서는 win32를 배우고 닷넷을 공부하는 경우는 매우 드뭅니다. 역순으로 배우는 것 역시 시간적으로 불가능하고요. 그래서 기술의 부익부 빈익빈 현상이 발생하는 것 같습니다. 예전부터 기초가 있던 사람은 기술 습득 속도가 빠르고 시간도 상대적으로 여유가 있어 원리 파악이나 응용 등 문제 해결에 도움이 되는 것들을 더 잘 알게 됩니다. 그 반대의 경우는 배우기도 바쁘고 일도 해야 하니 새로운 것을 배우는 데 더 오래 걸리고 시간은 점점 더 부족해지는 거죠. 앞으로는 이런 현상이 더 심해질지도 모르겠습니다. 갓 시작하는 개발자들은 기초를 다지는 데 상당한 시간을 투자해야겠죠. 정리해 보면 내부를 살피는 건 항상 도움이 됩니다만, 시간이 허락할지는 의문입니다.

고수준 프레임워크들이 나날이 발전하고 있지만 손이 많이 가는 하부 API들을 써야 하는 경우도 생길 것 같은데 어떤 기준으로 선택을 하시나요.
시간과 노력 투자 대비 효과로 판단합니다. 예를 들어 고수준 프레임워크에서 현재 충분한 API를 제공하지 않는 부분은 하부 API를 쓰는 편이 낫겠죠. 또는 상황에 맞는 언어를 골라 쓰는 것도 한 방법입니다. 비즈니스 로직 구현은 비주얼 베이직으로, 성능이 중요하거나 하부 구조를 건드려야 하는 부분은 C++로 구현해 COM 객체로 만들어 엮어 쓸 수도 있습니다.

프로젝트를 하다 보면 기술 외적인 문제들도 상당히 복잡할 것 같습니다.
기술적 한계를 고려하지 않은 요구사항이 들어오는 경우가 있는데 주로 설득을 합니다. 근본적인 원리를 이야기하면서 이해를 시키는 편인데, 설득이 잘 되지 않을 때도 있습니다. (웃음)

기술 발전이 현장에서 생기는 복잡한 문제들을 어느 정도 따라잡고 있다고 보시나요.
물론 기술들이 당면한 문제들을 따라가며 발전하고는 있습니다만 한국의 경우 기술에 맞춰 문제를 해결하려는 경향이 좀 있는 것 같습니다. 유행에 민감해서인지 신조어가 나올 때마다 그 쪽으로 몰리는 경우를 종종 보니까요. 기술이 먼저 비전을 제시하면 비즈니스가 그에 따르는 것이 아닐까 하는 생각이 듭니다.

앞서 말씀하신 운영체제나 코바의 경우처럼 하고 싶은 것을 못하게 되면 열의가 식는 경우가 종종 있는데 열정을 유지하는 비결이 있다면.
중학교 때부터 프로그래밍을 하는 게 좋았으니까요. 대학도 과를 정하고 선택했고요. 그래서인지 프로그래밍에 대한 재미가 지속됐습니다. COM도 나름대로 재미가 있었죠. 운영체제의 경우 계속 했다면 유명한 운영체제 개발자가 되지 않았을까 하는 생각이 들어 아쉬울 때가 가끔 있습니다. 그리고 기술을 특별히 가리지는 않아서 일단 하기로 결정하면 재미있게 하는 편입니다.

공부에는 어느 정도 시간을 쓰시나요.
집에 가서도 프로그램을 짭니다. 궁금한 건 프로그램을 짜서 눈으로 확인 사살(?)을 해야 하거든요. 개인 시간을 많이 쓰는 편입니다. 가족들이 좀 싫어하기는 합니다만….(웃음) 아직도 해야할 게 많고 제 스스로가 여전히 부족하다고 느낍니다.

예상대로 풀리지 않을 때 더 매달리시는 편인가요, 아니면 잠깐 거리를 두고 쉬시는 편인가요.
매달리는 편입니다. 짠 프로그램이 예상대로 작동하지 않으면 원인을 찾느라 가끔 밤을 새는 경우도 있고요. 최선책이 없으면 차선책이라도 찾아야 쉴 수 있습니다. 차선책도 없으면 어쩔 수 없겠지만 가능성이 보이면 꾸준히 시도해 봅니다. 문제 해결을 못하면 손에서 놓지 못하는 게 개발자들의 특성인 것 같습니다.(웃음)

안주하고 싶은 생각은 없었나요.
백발 노인이 될 때까지 이 일을 하고 싶은 것이 제 소망입니다. 제가 나이가 들어 컨설팅을 나가거나 강의를 할 때 업계에서 저를 어색해 하지 않는 분위기가 됐으면 좋겠네요.

갓 시작하는 개발자들에게 기술 선택에 대한 조언을 하신다면.
어느 것을 선택하느냐는 문제가 되지 않는다고 봅니다. 일단은 한 가지에 정통해야 합니다. 그렇지 못하면 살아남기 어려우니까요. 초보 개발자의 경우 시간이 부족하다는 어려움이 있지만 그 시기에 더 많이 노력을 해야 할 것입니다. 한 분야에서 두각을 드러내기 시작하면 다른 분야로 옮길 때도 상대적으로 어려움이 덜 합니다. 기술이 궁극적으로 지향하는 것은 비슷하기 때문에 플랫폼 차이가 중요한 것 같지는 않습니다.

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

올해 계획이나 관심사는 무엇인가요.
우선은 책을 한 권 잘 써서 내는 것이고요. 지금 하는 WCF(Windows Communication Foundation) 다음으로 WWF(Windows Workflow Foundation) 쪽 공부를 해보고 싶습니다. 후배 컨설턴트들을 키우는 일도 하고 싶고 기회가 되면 세미나도 하고 싶습니다. 개인적으로는 건강을 좀 챙기려고 합니다. 운동도 다시 시작하고요. 그리고 평소에 만나지 못한 사람들도 시간을 내서 자주 만나려고 합니다.

[유경상 소개] 드원 테크놀러지의 수석 컨설턴트로 근무하고 있으며 운영체제(리눅스)를 전공했고 현재는 MS 기술을 다루는 엔지니어다. COM/DCOM을 바탕으로 COM+를 거쳐 닷넷 기반 기술에 대한 컨설팅을 수행하고 있으며 지금은 웹 서비스의 새로운 프레임워크인 WCF에 관심을 갖고 있다.

*IBM developerWorks의 개발자 인터뷰는 릴레이 인터뷰 형식으로 다음 인터뷰 대상자는 유영창님입니다. 다음 인터뷰도 많은 기대 바랍니다.

[지난 인터뷰 보기]