테크데이즈 미니 토요세미나 발표자이신 김경균님을 미리 만나 보았습니다
오늘은 유비베이스의
김경균 님을 만나 뵈었습니다.
김명신: 안녕하세요 김경균님. 최근에 하시고 계신 일에 대해서 간단히 소개 부탁드립니다.
김경균: 네, 최근에 유비베이스라는 회사에서 주로 마이크로소프트에서 개발한 Lync라는 기업용 메신저 소프트웨어를 교환기나 외부 시스템과 연동하는 일을 수개월간 진행하고 있습니다. 이러한 메시징 소프트웨어는 단순한 TCP/IP 통신 외에도 VoIP(Voice Over IP)기반의 통신이나, CSTA(Computer-Supported Telecommunication Application) 관련 프로토콜, Telephone API 등과 같이 일반 기업용 응용 프로그램 개발 시에 사용하는 기술과는 조금 다른 기술에 대한 이해를 필요로 합니다. 외부 시스템이나 장비 연동을 하려면 아무래도 잘 작성된 문서나 스펙에 의존할 수 밖에 없는데요, 최근 프로젝트는 전임자의 퇴사와 부실한 문서화 등으로 상당히 고전하고 있는 것이 사실입니다. 물론 잘못된 문서보다는 나을 수 있을지 모르겠으나, 연동을 위해서 응용 프로그램을 디버깅해야 하는 유쾌하지 못한 상황에 처해 있는 것은 사실입니다.
김명신: 사실 국내 개발 프로젝트들을 살펴보면 너무나 과도한 문서화를 요구해서, 개발보다 문서작성에 시간이 더 많이 걸린다고 불만을 토로하시는 개발자도 있고, 김경균님처럼 부실하게 문서를 만들어 놓은 탓에 차기 프로젝트를 진행하는 데 걸림돌이 되는 경우도 있는 것 같습니다. 개발 프로젝트에 있어 문서화의 정도는 어느 수준이 적합할지요?
김경균: 저도 문서화에 대한 다양한 시각이 있음을 알고 있습니다. 어떤 개발자들은 소스 그 자체가 이미 완벽한 문서이므로 추가적인 문서는 필요하지 않으며, 소스가 문제를 정확히 설명할 수 있도록 작성하라는 극단적인 주장도 있고, 일부 국내 대기업에서와 같이 소프트웨어 공학의 연구 과정이나 CMMI 등을 기준으로 자체 개발한 거의 100여종에 이르는 산출물 리스트를 접한 적도 있습니다. 개인적인 생각으로는 문서화는 가능한 최소화 하는 것이 좋지 않을까 합니다. 개발 진행 과정의 편의를 돕기 위한 문서라면 모를까 대부분의 문서들이 프로젝트 완료 이후에는 그 가치가 현저히 떨어지거나 쓸모 없게 되는 경우가 많은데, 이런 문서들의 작성은 최소한으로 하는 것이 좋을 것 같습니다. 물론 외부 시스템과의 연동 규격서나, 운영 매뉴얼 등은 반드시 있어야 하는 문서 중에 하나일 것으로 생각됩니다. 또한 업무 처리 로직이 너무 복잡한 경우에도 반드시 문서화가 필요한 부분일 수는 있겠습니다. 물론 소스 코드는 그와 상관 없이 깔끔하게 작성할 필요가 있겠지요.
김명신: 지금 진행하시고 계신 프로젝트 이외에도 국내 대기업과 상당히 다양한 개발 프로젝트를 진행하신 것으로 알고 있습니다. 현업에서 그러한 프로젝트를 진행하시면서 겪으셨던 어려움이나 에피소드 같은 것이 있을까요?
김경균: 실제 현업에서 개발을 담당하다 보면 여러 가지 형태의 제약이나 어려움이 없을 수 없습니다. 그 중에 가장 큰 것이 무엇이냐 라고 물어보신다면 역시 사람의 문제라 말씀드릴 수 있을 것 같습니다. 개발 프로젝트의 진행 중에는 특별한 경우가 아니라면 다양한 업무와 역할을 담당하는 개발자 분들과 같이 일을 하는 것이 보통이겠지요. 저 같은 경우는 주로 프로젝트의 핵심 공통 모듈 개발을 많이 진행하곤 하였는데, 다른 개발자 분들과의 협업 시에 역할 분담과 기술 지원에 애를 많이 먹었던 기억이 있습니다. 공통 모듈은 보통의 경우 프로젝트의 주요 기능을 다루거나 혹은 다른 개발자분들께서 자주 사용하시는 부분들에 대한 추상화 계층을 제공하기 위한 경우가 많은데요, 이 모듈은 왜 이렇게 만들었느냐는 긍정적인 비판 외에도, 이것은 왜 만들어 주지 않느냐 혹은 이 모듈은 사용할 수 없다라는 식의 이야기도 간혹 듣곤 했습니다. 사실 공통 모듈 개발이라는 것이 외부에서 보면 뭔가 하는 일이 없어 보이기도 하고, 뭔가 잘못되면 공통 모듈의 문제인 것만 같고 그런 것 같습니다. 프로젝트의 성공이 공통 모듈을 잘 개발해서라고 평가되는 경우는 별로 없지만 실패의 원인을 공통 모듈로부터 찾으려는 시도는 사뭇 비일비재 합니다. 또 다른 관점에서는 기술이 문제일 경우도 있더군요. 정확히는 기술 그 자체의 문제라기 보다는 기술을 이해하지 못하는 개발자의 문제라고 보는 편이 좀 더 정확한 것 같습니다. 개발자의 업무와 역할은 사실 요구되는 일과 그 결과가 다른 업종에 비해서 명확하기 때문에, 같이 일을 해보고 그 결과를 드려다 보면 개발자의 성향이나 능력치가 드러날 수 밖에 없는 것 같습니다. 수년 전에 외부의 커뮤니티에서 꽤나 이름이 알려진 개발자분과 함께 일할 기회가 있었습니다. 하지만 수개월 후에 그분이 만들어 내신 결과물은 명성에는 걸맞지 않은 수준이었고요, 그 분도 그걸 아셨는지 더 이상 일을 하지 못하시고 떠나시더라고요. 개발자는 명성 보다는 능력과 결과로 본인을 증명할 수 있어야 한다고 생각합니다.
김명신: 그렇다면 개발자가 반드시 가져야 하는 역량이라는 것이 있을까요? 제 주위의 일부 학생들은 개발 그 자체가 좋긴 하지만, 업종 자체가 3D이고, 젊었을 때 잠시 잠깐 밖에 할 수 없는 일이기 때문에 개발자로서의 수명이 너무 짧은 것 같다고 토로하는 분이 있는 것 같습니다. 이 점에 대해서는 어떻게 생각하시는지요?
김경균: 제 주위에 훌륭한 개발자라고 생각되는 몇몇 분들을 보면 나름의 특징들이 조금 있기는 합니다. 대부분이 어떤 문제 상황에 봉착했을 때, 문제 해결을 위해서 과도하리만큼 놀라운 집중력을 보이는 분들이 많은 것 같아요. 정보통신업이라는 것이 고도의 지식집약적 산업이고, 육체적인 노동 보다는 지적 노동을 필요로 한다는 점에서 이는 사실 특별한 것은 아니라고 할 수도 있겠습니다만 다른 업종에 종사하시는 분들에게는 이러한 특징으로 인해 개발자들은 조금 이상하거나 다르다고 생각하실 수도 있을 것 같다는 생각을 해보았습니다. 그리고 정보통신 산업이 3D 산업인 나라는 아마 한국밖에 없지 않을까 합니다. 소프트웨어 개발과 관련된 다양한 직업들 예를 들면 컨설팅 업무나, 소프트웨어 아키텍트, 개발자 등에 이르기 까지 정보통신 관련업은 많은 나라에서 가장 각광 받는 직업이자 최고의 부가가치를 생산하는 산업으로 인정 받고 있는 분야입니다. 이러한 분야가 3D 산업으로 분류되는 것은 그 분야에 있는 분들에게도 좋지 않겠지만 국가적으로도 불행한 일이 아닐 수 없다고 생각합니다. 게다가 개발자가 수명이 정해져 있다는 것에도 동의하기 어렵습니다. 개발은 젊어서만 할 수 있다고 생각하는 것은 편견에 가깝고요, 자기계발을 꾸준히 하여 개발 역량을 보전할 수만 있다면 나이와 상관없이 개발은 계속하실 수 있으리라 생각합니다. 하지만 이는 개인의 역량의 문제로만 볼 수는 없고 사회적인 통념이나 보수의 문제와 연관 지어 고민해볼 부분인 것 같습니다. 실제로 많은 SI업체들이 경력이 많고 개발을 잘 하는 고급 개발자 한명보다 적당한 중급 혹은 초급 개발자 여러명을 선호합니다. 이는 개발업종을 사람의 머리수로 계산하는 어처구니 없는 사고방식일 뿐입니다. 응용 프로그램의 본수로 프로젝트의 규모를 측정하고, 그것을 근간으로 개발자 수를 산정하기 때문인데요, 제 개인적인 생각으로는 아무리 단순한 개발이라도 고급개발자 한 명이 중급 개발자 여러 명보다 훨씬 낫다고 생각합니다. 이런 비유가 어떨지 모르겠지만 중급 개발자가 삽이라면 고급 개발자는 포크레인인 것이지요. 그럼에도 기술적인 사리판단이 정확하지 않은 매니저들이 고급 개발자들 보다는 중급 혹은 초급 개발자들을 선호함에 따라 실제로 능력과 경험을 겸비한 개발자들이 설자리가 점점 좁아지는 것이 사실입니다. 이는 안타까운 현실임에는 분명한 것 같습니다.
김명신: 기술 그 자체에 대한 이야기를 조금 나누어 보면 어떨까요? 최근에 공부하시면서 가장 재미있었던 부분이나 혹은 가능성을 발견하신 부분이 있으시다면 어떤 부분일까요?
김경균: 대학교 다닐 때 C++와 같은 언어를 배우기는 했지만, 사회생활을 시작하면서 본격적으로 접한 언어가 C#이었습니다. 그런데 C#에서는 델리게이트라는 요소가 있습니다. 처음 C# 언어를 공부할 때는 제가 이 부분을 잘 알지를 못했어요, 게다가 이벤트 드리븐 아키텍쳐(event driven architecture)나 최근 JavaScript에서 문제점이라고 지적하는 콜백을 근간으로 한 비동기 모형 등은 사실 별로 관심사가 아니었어요. 그런데 어느날 이벤트를 근간으로 한다는 것에 대한 호기심이 생겼고, 그것이 델리게이트로 무명 메서드(anonymous method)로 다시 람다 표현식(lambda expression)으로 그리고 LINQ로 발전하고, 그 적용영역이 확장되는 것을 보면서 즐거웠던 기억이 있습니다.
김명신: 수년간 ASP.NET MVP로 활동을 하신 것으로 알고 있습니다. 마이크로소프트의 웹 개발 기술은 사실 ASP로부터 시작해서 이미 상당히 오랫동안 거의 정점에 이를 만큼 그 완성도가 높다고 평가 받고 있습니다. 이에 대해서 의견이 있으실까요?
김경균: 그렇습니다. 말씀하신 바와 같이 마이크로소프트의 ASP와 ASP.NET이라는 이름으로 상당히 오랫동안 웹 개발 기술을 계승 발전시켜 왔습니다. 하지만 그 내면을 드려다 보면 상당한 자기 혁신과 변혁의 노력들을 살펴볼 수가 있습니다. ASP에서 ASP.NET으로의 전환이 그 한 단면일 수 있습니다. 스크립트와 마크업을 교묘히 섞어 사용하던 ASP의 시대에서 서버 사이드 컴포넌트와 이벤트 드리븐 방식의 ASP.NET으로의 변화는 진일보한 발전임에 분명하였습니다. 그 이후에는 다시 MVC 모형을 전폭적으로 수용한 ASP.NET MVC 모형이 최근 버전 5.1까지 출시가 되었지요. 게다가 WebPage나 SPA와 같은 웹 페이지 개발 기술과 더불어 WebAPI, SignalR 과 같은 웹 서비스 개발 기술, IIS와 같은 웹 애플리케이션 호스팅 기술, 최근에는 트렌드에 맞추어 경량화 웹서버, 경량화 웹 플랫폼 기술, 웹 호스팅 환경과 웹 어플리케이션의 분리를 도모하는 등 끊임없이 발전하고 진화하는 모습을 보여주고 있습니다. 사실 정점에 이르는 완성도보다는 현실의 변화를 즉각적으로 반영하고 따라가 주기를 많은 개발자들이 희망한다고 생각합니다. 물론 그 다음은 기술적 리더쉽이겠지요. 부족한 부분이 많이 있다고 생각은 듭니다만, 마이크로소프트가 최근에 웹 개발 프레임워크를 전격적으로 .NET Framework과 분리하여 1~2년만에 한번씩 업데이트가 나오던 이전과 다르게 수주에서 수개월에 한번씩 최신의 업데이트가 나오는 것은 상당히 고무적이라고 생각이 듭니다.
김명신: 아 그렇군요. 변화 무쌍한 웹 개발 트렌드를 따라가는 것이 쉽지는 않을 것 같다는 생각이 많이 드네요. 그럼에도 불구하고 이번 세션에서 발표하실 내용은 ASP.NET의 고전이라 할 수 있는 웹폼에 대한 내용인 것으로 알고 있습니다.
김경균: 그렇습니다. 현재까지 ASP.NET을 이용하여 웹 사이트를 개발하시는 분들의 대다수가 여전히 웹폼을 즐겨 쓰시는 것으로 알고 있습니다. 최신 기술 변화의 흐름을 놓치지 않는 것만큼이나 중요한 것이 기존 기술에 대한 계승 발전일터인데요, 이런 관점에서 웹폼은 여전히 현재 진행형인 기술입니다. 최근에는 와우! 하는 새로운 기술은 덜 도입되었지만 개발자들의 피드백을 중심으로 정말 필요한 기술들이 제법 추가되었습니다. 개인적으로는 가려운 부분만을 정확히 찍어서 긁어주는 듯한 느낌을 많이 받았습니다. 아주 많은 부분에서 획기적인 변화가 있었던 것은 아니기 때문에, 제가 이번 테크데이즈 미니 토요 세미나에서 정리해 드리는 부분만 잘 이해하신다면 그것만으로도 충분하지 않을까 생각하고 있습니다.
김명신: 그렇게 말씀 해 주시니까 그 세션은 꼭 들어가야겠다는 생각이 드는군요. 그럼 토요일 행사장에서 뵙겠습니다. 감사합니다.
김경균: 감사합니다.