Blog

지난 11월 팀 브레이는 프레임워크 비교하기 (원문: Comparing Frameworks)라는 써서 블로그에 올렸다. 이 글에서 팀 브레이는 PHP, Java 그리고 Ruby on Rails를 여러 측면에서 비교했다. 확장성, 개발속도, 개발도구, 그리고 유지보수성의 관점에서 점수를 매겼는데, 그 결과가 사뭇 흥미로웠다. [그림 1]의 도표를 보면 PHP와 Ruby on Rails와 비교해 자바가 고전하는 것을 알 수 있다. 팀 브레이의 의견이 공신력 있다고 말할 수는 없지만, 그가 선 마이크로시스템즈 사의 직원임에도 불구하고 이 같은 견해를 피력한 것은 의미심장하다. 실제로 다양한 개발자 커뮤니티에서 팀 브레이의 글을 두고 이런저런 이야기가 오갔는데, 이견이 있긴 했지만 많은 사람들이 공감대를 나누었다.

[그림 1] 프레임워크 비교

닷넷은 과연 어떤 점수를 받을까?

팀 브레이는 프레임워크 비교하기에서 닷넷은 오픈 소스가 아니니 검토할 가치조차 없다는 투로 말했다. 그래서 안타깝게도 닷넷은 비교 대상에서 아예 제외됐고, 개발자 커뮤니티의 다양한 의견을 들을 기회도 사라졌다. 그래서 이 자리를 빌어 필자의 의견을 피력해볼까 한다. 처음에는 닷넷의 단점을 중점적으로 다루고, 이어서 장점이 무엇인지 알아보도록 하겠다.

시작하기에 앞서

본격적으로 평가하기 앞서 몇 가지 사전 지식을 알아두자. 이 글은 Java, PHP, Ruby on Rails (통칭RoR)를 닷넷과 비교하고 장단점을 분석한다. 그런데 자바와 PHP는 프로그래밍 언어인 반면에 RoR은 프레임워크를 뜻한다. 자바와 PHP를 위한 프레임워크도 있다. 오히려 프레임워크 종류가 다양하고 우열을 가리기 힘들어서 프레임워크가 아닌 프로그래밍 언어로 표기한다.

일반적인 시스템 구성도 간략히 숙지해놓자. PHP와 RoR은 소위 LAMP (Linux, Apache, MySQL, PHP)라 불리는 환경을 주로 사용한다. 닷넷은 주로 윈도우 운영체제와 그 안에 포함된 IIS 웹 서버를 채택하는데, 사실 선택권이 거의 없다. 다만 데이터베이스는 Microsoft SQL Server가 아닌 오라클 또는 MySQL 등을 선택하는 경우도 많다. 자바는 닷넷보다 유연하다. 윈도우든 리눅스든 상관없지만, 웹 애플리케이션 개발 시에는 주로 리눅스와 아파치 조합을 사용한다.

필자 노트 ? 프레임워크란?

IT 분야에서 사용하는 용어는 여러 가지 의미를 가지거나 모호한 단어들이 많기 때문에 정확한 용어의 의미를 이해하지 않고서는 글의 내용을 올바로 이해하기 힘들다. GoF의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson) 교수는 프레임워크를 “소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것”이라고 정의하였다. 프레임워크는 라이브러리와 달리 애플리케이션의 틀과 구조를 결정할 뿐 아니라, 그 위에 개발된 개발자의 코드를 제어한다. 프레임워크는 구체적이며 확장 가능한 기반 코드를 가지고 있으며, 설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되어 있다.

마이크로소프트웨어 2006년 8월호 중 ‘프레임워크 활용전략’에서

플랫폼 구성 비용

닷넷 프레임워크를 채택한다는 것은 MS 제품으로 플랫폼을 구성해야 한다는 뜻이다. 데이터베이스와 몇몇 영역에서 선택권이 있기는 하지만, 대부분으로 MS 제품이 차지한다. 윈도우 서버 라이센스부터 시작해서 개발자를 위해 운영체제와 개발도구를 구입해야 한다. 장기적으로 보면 거기서 그치지 않는다. 백업 솔루션 등 시스템 운영에 필요한 소프트웨어 대부분이 상용이기 때문이다. 닷넷 프레임워크 이후로 사정이 나아지긴 했지만, 여전히 윈도우 환경은 오픈 소스 프로젝트의 혜택을 적게 받는 것이 사실이다.

이렇게 써놓고 보니 돈 들어가는 게 장난이 아닌 것처럼 보인다. 하지만 다르게 생각해볼 측면도 있다. 우선 개발자를 위한 운영체제 구입은 자바나 PHP로 개발할 때도 마찬가지다. 서버는 리눅스를 채택하더라도 개발자는 여전히 윈도우에서 작업하는 게 일반적이기 때문이다.

마지막으로 개발도구 구입비용도 충분히 변동될 수 있다. 특히 여러분의 회사가 시스템을 직접 개발하는 게 아니라면 그렇다. 개발 업체가 이미 라이센스를 확보하고 있을 가능성이 크다. 물론 라이센스 비용 중 일부를 짊어져야 할지도 모르겠지만, 그렇게 크지는 않을 것이다. 이 경우에는 운영에 필요한 수준에서만 라이센스를 구입하면 될 것이다.

개발 도구를 구입해야 하는 경우에는 어떨까? 영세한 개발 업체나 이제 사업을 시작하는 기업이라면 Visual Studio 라이센스 비용이 걱정될 수 있다. 개발자의 역할에 따라 적절한 제품을 고르면 배용을 절감할 수 있긴 하다. 모두가 Team System 같은 상위 제품의 기능을 쓰지는 않기 때문이다. 그렇다고 하더라도 이클립스라는 오픈 소스 개발도구가 있는 자바나 LAMP 진영에 비하면 부담되는 것은 사실이다. 물론 닷넷에도 오픈 소스 IDE나 솔루션이 없지는 않다. 하지만 그런 걸 채택하면 PHP나 RoR은 몰라도 닷넷이 자바보다는 뒤쳐진다고 밖에 말할 수 없다. 닷넷이 보장하는 생산성도 Visual Studio와 같은 훌륭한 개발 도구 없이는 빛이 바래는 것이 사실이다. Visual Studio 대신 오픈 소스인 Sharp Develop 를 사용하는 모습이 그렇게 매력적이지는 않을 것이다. 그나마 마이크로소프트가 무료로 사용할 수 있는 Visual Studio Express Edition을 내놓아서 상황이 나아지긴 했다. 그러나 여전히 비용 면에서 PHP와 RoR에 한참 뒤지고, 자바에 못 미치는 것이 사실이다.

기술 종속

마이크로소프트 사의 기술은 배타적인 성격이 강해서, 도입하는 기업이 리스크 부담도 져야 한다는 비판을 종종 듣는다. 특히 기술 지원이 언제까지 이뤄질 것인가 하는 것이 걸림돌이다. 한때 PHP와 쌍벽을 이루던 ASP가 어떻게 됐는지 생각해 볼 일이다. ASP.NET으로 오면서 ASP는 더 이상의 발전이 없는 상태다. 게다가 ASP.NET과 ASP는 그 이름을 공유하고 있긴 하지만, 사실상 완전히 다른 기술이라 ASP에서 ASP.NET으로 업그레이드하기 어려웠다. 기존 ASP 기술이 사양길을 걸어내려 간 것을 PHP가 나날이 도약하고 있는 상황과 비교해보면 암울하기까지 하다. PHP는 버전 5까지 내놓은 상태고, 웹 프레임워크만 해도 10여 종이 넘는다. ASP 사태를 한번 겪은 회사나 개발자의 경우에는 닷넷 기반 기술을 웹에 도입하는데 부정적일 때가 종종 있다.

물론 오픈 소스 진영이라고 해서 무한정 커뮤니티의 지원을 받을 수 있지는 않다. PHP처럼 장수하려면 Zend 같은 업체가 나와서 커뮤니티를 이끌어줄 수 있어야 한다. 순수하게 비영리 커뮤니티의 힘으로 기술이 성숙할 수 있으리라고 믿지는 않는다. PHP 같이 장수하는 오픈 소스 프로젝트가 있는가 하면, 중간에 사장되는 오픈 소스 기술도 무시 못할 만큼 많다. 실제로 필자가 즐겨 사용하던 NDoc이라는 닷넷 문서화 도구는 널리 사용되었음에도 불구하고, 자발적인 참여가 전혀 이뤄지지 않아서 지난해에 프로젝트가 중단되어 버렸다.

기술 종속 문제에 대해 비판적일 수밖에 없지만, 그래도 닷넷 프레임워크는 ASP보다는 훨씬 미래가 밝다. 닷넷 프레임워크가 세상에 얼굴을 내민 지 벌써 5년이 지났지만, 마이크로소프트 사의 로드맵을 찬찬히 살펴보면 여전히 이 기술은 한참 발전하는 단계에 와 있을 뿐이라는 사실을 알 수 있다. 새로운 윈도우 운영체제 비스타에는 닷넷 프레임워크 3.0이 기본 탑재됐고, WPF 등의 신기술이 소개됐다. 게다가 닷넷 프로그래밍 언어인 C#은 앞으로도 새 기능이 추가될 예정이고, 조만간 Python이나 Ruby 같은 언어로도 닷넷을 사용하는 모습도 지켜볼 수 있게 될 것 같다.

개발 환경

LAMP 계열의 PHP나 Ruby와 같은 오픈 소스는 여러 가지 면에서 매력적이다. 플랫폼 구성이나 개발도구 채택에 있어서 비용이 적게 들고, 오픈 소스 라이브러리도 많다. LAMP의 멋진 장점에도 불구하고 닷넷이 눈에 띌 정도로 뛰어난 부분도 분명히 있다. 특히 Visual Studio (개발 도구)와 MSDN 라이브러리 (개발 문서)는 멋지다. 프로그래밍 언어나 프레임워크의 구성이 생산성에 미치는 영향을 과소평가할 수는 없지만, 개발 도구와 문서화가 생산성에 미치는 영향은 오히려 더 클지도 모른다.

웹 페이지에 버튼 하나 추가하는 법을 몰라서 몇 시간을 헤매는 경우가 종종 있다. 물론 문서화가 잘 되어 있다면 그런 어이없는 경우는 보기 드물어질 수밖에 없다. 오픈 소스 진영에서 MSDN 라이브러리만한 문서를 찾아보기란 그리 쉽지는 않다. 정말 잘 만들어진 문서를 종종 볼 수는 있지만, MSDN 라이브러리만큼 방대하고 예제를 잘 갖춘 경우가 거의 없다.

소프트웨어 개발의 혁신 중 하나는 통합개발환경(IDE)의 등장이었다. 코딩, 디버깅, 성능분석 등을 한 자리에서 해결할 수 있게 됨으로써 생산성이 상당히 향상될 수 있었다. VI 편집기를 애호하는 몇몇 개발자가 있기는 하지만, 아무리 그래도 Visual Studio와 같은 IDE와 비교하면 구석기 시대의 유물에 불과하다. 개발도구 면에 있어서 닷넷에 견줄 수 있는 것은 자바뿐이다. 자바는 이클립스와 NetBeans라는 훌륭한 IDE를 갖추고 있다. PHP는 보통 이클립스를 사용하지만, 자바나 닷넷 만큼 훌륭한 환경이라고 말하기는 힘들다. Ruby의 윈도우 개발환경에서는 RadRails라는 IDE가 가장 무난해 보인다. 하지만 Eclipse 기반의 이 IDE는 Intellisense와 같은 기본적인 기능마저 지원하지 않아서 무척 실망스럽다. Mac OS X에는 TextMate가 있다고 하지만, 역시 Visual Studio에 익숙해진 개발자에겐 단점이 아닐 수 없다.

웹 프레임워크로써의 닷넷 기술

닷넷 프레임워크는 매우 잘 구성되어 있다. J2EE 등의 자바 프레임워크는 산만하기 짝이 없는데 반해, 닷넷 프레임워크는 탄탄하다는 느낌이다. 아무래도 자바의 역사가 훨씬 길고, 닷넷 프레임워크만큼 하나의 회사가 완전히 주도권을 갖고 한 방향으로 이끌어나가지 않았기 때문일 것이다. 그런 측면에선 자바에 점수를 더 주어야 할지도 모른다. 요즘 인기를 끌고 있는 RoR의 경우에는 안타깝게도 실망스러운 구석이 있었다. 닷넷 프레임워크는 어떤 기능을 찾는 것이 아주 용이하다. System.Net은 네트워크 통신 기능을 담당하고 있고, System.Text는 문자 처리 기능을 갖추고 있다. 이름만 보면 어디에 어떤 기능이 있을지 대충 짐작할 수 있다. 하지만 RoR은 네트워크 통신 기능이 Socket, NET::FTP와 같은 라이브러리에 두서 없이 널려 있어서, 처음 구현하는 기능일 때는 헤매기 십상이다.

분명히 닷넷 프레임워크는 탄탄한 구성을 자랑한다. 하지만 ASP.NET이 웹 애플리케이션에 최적화된 환경이라고 생각하지는 않는다. 닷넷 프레임워크는 모든 종류의 애플리케이션 개발을 염두에 두었기 때문에, RoR과 같은 웹 프레임워크보다 복잡하고 최적화되어 있지 못하다. Tim의 말마따나 대부분의 웹 애플리케이션은 구조가 단순하다. 닷넷은 거의 모든 문제에 대한 해답을 제시할 수는 있지만, 어떤 경우에는 바퀴벌레 한 마리 잡으려고 소총을 난사하는 것 같다. 닷넷 기술을 제대로 이해하려면 제법 시간을 투자해야 하는데, 과연 그럴 가치가 있는 것일까? 이에 대한 대답은 ‘경우에 따라 다르다’이다. KLDP라는 오픈 소스 개발 커뮤니티엔 다음과 같은 글이 올라온 적이 있다.

asp.net을 경험할수록 웹 컨트롤은 이게 아니라는 생각이 듭니다. 표준에도 어긋나고 틀에 박혀 커스터마이징이 힘들어 유연성이 떨어지며 생산성도 생각보다 떨어지더군요. asp.net는 웹 컨트롤이라는 환상에 지나치게 사로 잡혀서 구멍 난 추상화가 된 예라고 생각하고 있습니다.

필자 역시 같은 생각을 한 적이 있다. Community Server라는 닷넷 기반의 웹 커뮤니티 프로젝트가 있다. 닷넷에 익숙해지고 한참 자신감이 붙었을 때, 프로젝트에 참여해 볼 요량으로 소스 코드를 살펴본 적이 있다. 그때의 감상은 “참 깨끗하고 잘 짠 소스 코드 같은데, 도무지 무슨 의미인지 알 수가 없다”였다. 소프트웨어 개발 용어 중에 디자인 패턴이라는 것이 있다. ‘디자인 패턴: 재사용 가능한 객체지향 소프트웨어의 요소들’이란 책에는 디자인 패턴을 다음과 같이 설명한다.

각각의 패턴은 우리를 둘러싸고 있는 환경에서 반복적으로 나타나는 특정한 문제와 그에 대한 해결책을 설명한다. 그리고 그 해결책은 계속 사용될 수 있기 때문에 동일한 과정을 반복할 필요가 없다.

프로그래밍 과정에서 반복되는 요소를 추출해서 다음 번에 다시 써먹으려는 시도라고 생각하면 간단하다. 그리고 닷넷의 웹 콘트롤은 이러한 생각의 극단에 서 있다. 하지만 필자의 경우에도 그러했듯이 웹 콘트롤 개념은 지나치게 나아가서, 오히려 개발자를 혼란스럽게 하는 측면이 있다. 사실 웹 페이지 하나하나는 그렇게 자주 재활용되지도 않거니와 단추나 글자 하나를 바꾸는 작업이 자주 일어나기 때문에 재활용하는 데 한계가 있다.

프로그래밍 과정에서 반복되는 요소를 추출해서 다음 번에 다시 써먹으려는 시도라고 생각하면 간단하다. 그리고 닷넷의 웹 콘트롤은 이러한 생각의 극단에 서 있다. 하지만 필자의 경우에도 그러했듯이 웹 콘트롤 개념은 지나치게 나아가서, 오히려 개발자를 혼란스럽게 하는 측면이 있다. 사실 웹 페이지 하나하나는 그렇게 자주 재활용되지도 않거니와 단추나 글자 하나를 바꾸는 작업이 자주 일어나기 때문에 재활용하는 데 한계가 있다.

개발 속도

앞선 논의에서 조금씩 개발 속도에 대해 언급했다. 우선 Visual Studio가 없다면 뛰어난 생산성을 발휘하기 힘들다. Sharp Develop과 같은 오픈 소스 IDE도 인텔리센스와 같은 편리한 기능을 제공하므로 간단한 프로젝트를 진행하기에는 충분하다. 그러나 배포판의 크기만 비교해도 기능의 차이가 역력하다. Sharp Develop은 기껏해야 5메가바이트 이하지만, Visual Studio는 MSDN 라이브러리를 제외하고도 수백 메가바이트나 된다.

Visual Studio가 있다고 치자. 이젠 정말 빠르게 개발할 수 있을까? 어떤 것을 개발하느냐에 달렸다. 여러분이 소규모 쇼핑몰 사이트 등의 작은 애플리케이션을 개발할 생각이라면, 차라리 다른 웹 프레임워크가 낫다. 하지만 서로 다른 여러 시스템을 통합해야 하는 기업이라면 자바와 더불어 닷넷이 훌륭한 선택이 될 수 있다. 사실 PHP나 RoR과 같은 LAMP 계열은 시스템 통합에는 부족한 부분이 많다. 예를 들어 RoR은 2단계 커밋을 지원하지 않는다. 오라클이나 SQL Server 등이 서로 협력해야 하는 경우에는 큰 문제가 아닐 수 없다. 자바나 닷넷은 아무래도 기업 시장을 노리고 개발된 것이기 때문에 이런 측면에서 최고의 선택일 수밖에 없다.

유지보수성

많은 사람들이 간과하는 것 중 하나는 유지보수비용에 비하면 개발비용은 아무것도 아니라는 것이다. 로버트 L. 글래스가 쓴 소프트웨어 공학의 사실과 오해의 목차를 살펴보자.

• 사실 41. 유지보수는 보통 소프트웨어 비용의 40~80%를 차지한다. 따라서, 유지보수는 아마도 소프트웨어 생명주기중 가장 중요한 단계일 것이다.

• 사실 42. 유지보수 비용의 60%는 개선 작업에 소요되는 비용이다.

• 사실 43. 유지보수는 문제가 아니라 해결책이다.

• 사실 44. 유지보수에서 가장 어려운 작업은 기존 시스템을 이해하는 것이다.

• 사실 45. 더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은 게 아니라) 유지보수가 필요하다.

유지보수에 있어서 객체지향 프레임워크인 닷넷은 단연 뛰어나다. PHP와 같이 이제 막 객체지향을 지원하기 시작한 언어에 비하면 놀라울 정도로 새 기능을 추가하고 기존 기능을 개선하기가 쉽다.

구인

아마도 이 기사에서 가장 짧지만 중요한 내용은 ‘구인’ 문제일 것이다. 소프트웨어 산업계의 종사자라면 최근의 구인난에 대해선 익히 알고 있으리라 생각한다. 몇 년 간 열악한 환경이 개선되지 않으면서 훌륭한 개발자들이 관리직이나 다른 분야로 나갔고, 신규 인력도 제대로 수급되지 않고 있다. 정부에서 이런저런 정책을 내놓는 것 같지만, 솔직히 말해 아무런 도움도 되지 않을 것이고 한동안 상황은 지금 이대로 일 것이다. 구인 부분에 있어선 RoR과 같은 신기술은 최악이다. 어디서 사람을 구할 것인가? 그런 면에서 닷넷은 비교적 상황이 좋다. 마이크로소프트라는 대형 벤더가 붙어있기 때문에 개발자 구하기는 그나마 쉬운 편이다.

웹 프레임워크를 넘어서

여기까지 웹 프레임워크의 관점에서 닷넷 기술을 살펴보았다. 마지막으로 데스크톱 애플리케이션의 경우를 고려해보자. PHP는 웹 애플리케이션 개발에만 사용할 수 있다. Ruby로 데스크톱 애플리케이션을 개발할 수는 있지만, 성능도 뒤지고 검증이 안 되었다. 자바는 리눅스든 윈도우든 상관없이 작동한다는 점이 매력적이다. 하지만 윈도우만 고려한다면 닷넷 만한 것이 없다. 실제로 기업용을 제외하고 자바로 작성된 데스크톱 애플리케이션을 찾아보기란 힘들다. 유려한 인터페이스를 구현하기가 힘든 탓일 것이다.

그 동안 한국에서는 닷넷 기반의 상용 애플리케이션을 거의 찾아보기 힘들었다. 하지만 비스타에 닷넷 프레임워크 3.0이 탑재된 이제는 진지하게 고려해야 할 때다. 메모리 사용량이나 속도 문제를 걸고 넘어지는 사람이 있다. 사실 아직도 많은 상용 애플리케이션을 Visual C++로 개발하는 이유도 이 때문이다. 하지만 여기에 필자 나름의 반론을 펼쳐 보겠다.

애플리케이션을 구동하는데 기본적으로 필요한 메모리가 분명히 문제가 될 수도 있지만, 사실 20 내지 30 메가바이트 정도도 허용 못하는 소프트웨어가 그렇게 많은지 의문이다. 속도 문제는 최적화 방법이 있다. 성능 문제를 지적하는 사람들이 이 기법에 대해 전혀 모를 때가 많다. 필자가 즐겨 사용하는 애플리케이션 중 상당수는 닷넷 기반이다. 마이크로소프트도 자사 제품에 닷넷 기술을 도입하는 비중을 늘리고 있는 듯 하다. 그런데 이 제품을 사용하는데 느려서 못 써먹겠다고 생각해 본 적이 없다. Paint .NET 이라는 그래픽 편집 도구가 있다. 닷넷 프레임워크 2.0에서 작동하는 이 도구는 성능이 매우 뛰어나서 간단한 이미지 편집에는 항상 사용하고 있다.

시장에서 이기고 싶다면, 메모리 1메가를 아끼는데 신경 쓰지 말고, 사용자가 원하는 제품을 적절한 시기에 내놓을 수 있는데 역량을 집중해야 한다. 윈도우 데스크탑 애플리케이션 개발에 닷넷 만큼 훌륭한 솔루션은 없다.