재밌는 기사가 떴다. 마이크로소프트가 Windows Server의 가상화 기술인 Hyper-V에서 리눅스를 돌릴 수 있는 리눅스용 드라이버 소스를 GPL v2 하에서 기증했으며 앞으로 유지보수도 제공할 예정이란다. 리눅스 진영에서는 리눅스와 GPL에 대한 마이크로소프트의 태도 변화를 환영한다는 입장과 마이크로소프트가 진정 오픈 소스를 끌어 안아 mixed 환경을 대비하고 있다고 소개하고 있다.
이 드라이버를 탑재한 리눅스 배포판은 마이크로소프트의 가상화 기술인 Hyper-V 상에서 동작할 수 있게 된다.

이것에 대한 VMWare의 반응을 궁금하다는 내용도 ...

관련기사
http://www.networkworld.com/news/2009/072009-microsoft-linux-source-code.html
http://www.networkworld.com/news/2009/072009-microsoft-linux-kernel-cloud.html?ts0hb&story=mslinux

마이크로소프트가 오픈 원칙, 오픈 및 오픈 소스, 공개 표준, 오픈 소스 관련 단체 기부, 소스 코드 기부  등을 이야기하면서 시장에 다가가도 늘 왜곡된 시선들이 있어왔다. 한마디로 쑈를 한다는... 시장의 색안경이 조금 옅여질 수 있을까 ?

Posted by 장현춘

지난 시간에는 프레임웍 기반 개발이란 어떤 의미가 있으며 이때 사용할 수 있는 범용 개발 프레임웍은 어떤 것들이 시장에 나와 있는지에 대해 살펴보았다.

Framework-based Development – 개념
Framework-based Development – 적용
Framework-based Development – 종류
Framework-based Development - 오픈 소스 적용 사례

이번 시간에는 주제를 좁혀서 범용 개발 프레임웍 중에서 닷넷 개발자 생태계 내에서 성장하고 발전해가는 오픈 소스 프레임웍의 적용 사례를 살펴보고자 한다. 오픈 소스 프레임웍들을 실제 적용하여 비지니스를 하고 있는 사례들을 살펴봄으로해서 닷넷 개발자 생태계의 건강성을 확인하고 닷넷 오픈 소스 프레임웍의 현재와 미래를 가늠해보는 시간이 되었으면 한다.

대부분의 SI 업체들은 SI 프로젝트에서 공통적으로 사용할 표준 개발 프레임웍이라는 것을 가지고 있는데, 대부분 오픈 소스 기반의 범용 프레임웍들을 조합하여 기본적인 기능을 제공하고 이를 기반으로 자사가 가지고 있는 도메인 특화된 노하우를 올리거나 일반 범용 프로임웍이 제공하지 못하는 모니터링이나 툴 최적화 기능 등을 묶어 제공하는 경우가 일반적이다. 아래 그림에서 보듯이 범용 프레임웍들의 조합을 통해 시장에서 입증된 QoS (품질요소)를 제공하고 그 기반위에 고객에게 전달할 가치를 부가적으로 제공하게 된다. 고객에게 전달할 가치가 범용 프레임웍만으로 끝난다면, 이것만 가지고 고객에게 어필(별도의 비용 청구 등)할 수 없을 것이다. 혹은 특정 회사가 개발하여 제공하는 프레임웍이라는 것이 시장의 범용 프레임웍들의 조합만으로도 제공할 수 있는 가치를 전달한다면 고객에게 외면 받을 것은 자명하다.

국내외를 막론하고 기업이 오픈 소스 기반의 프레임웍을 사용한 경우 일반적으로 그 사실을 외부에 알리는 것을 꺼려하는 경우가 있다. 이런 이유로 Spring.NET의 해외 적용 사례를 보더라도 유럽의 굴지의 온라인 여행사라든가, 어떤 도메인의 유명한 기업 정도만 밝히는 경우가 허다하다. 국내에도 마찬가지여서 외부로 드러나는 적용사례는 극히 드물다. 오늘 소개할 사례를 이전 DevDays 2008과 Open & Interop Day에서 적용 사례 발표를 했던 기업들이다.

아래는 이랜드 시스템의 표준 개발 프레임웍에 적용되어 있는 오픈 소스 프레임웍에 대한 내용이며, 황용호 팀장께서 발표하신 슬라이드에서 가져왔다. 이랜드 시스템의 Formular#은 Spring.NET + NHibernate의 조합을 통해 기본 기능을 제공하고 비지니스 특성상 북경 개발 센터와의 원활한 협업을 위해 사용되는 툴들에 대한 add-on 모듈이라든지, 테스팅 자동화와 같은 기능을 제공하고 있다.

예스24에서는 iBATIS.net을 현재 운영 중인 쇼핑몰에 적용한 사례를 최만석 팀장께서 발표하였으며 아래는 그 일부이다.

SK C&C에서는 개발 프레임웍인 NEXCORE.NET에 적용된 오픈 소스 프레임웍에 대해 설명을 하셨으며 아래는 이진우 대리께서 발표한 자료에서 발췌했다. NEXCORE.NET은 ASP.NET MVC + Spring.NET + iBATIS.NET 혹은 Entity Framework 등으로 구성되어 있으며 Visual Studio에 통합된 자동화가 인상 깊은 프레임웍이다.

위에서 언급된 세가지 사례는 발표 자료와 함께 동영상 자료가 DevDays 2008에 게시되어 있으므로 좀 더 상세한 내용을 원하시는 분은 DevDays 2008 싸이트를 참고하시길...

그 밖에도 국내 또 다른 SI 업체의 개발 프레임웍에 ASP.NET MVC가 사용되고 있으며, 닷넷 솔루션 파트너사의 일부 솔루션에도 NHibernate가 사용되고 있음을 확인할 수 있었다.

마지막으로, 오픈 소스 프레임웍들을 적용하여 사업을 할 경우에 이들에 강제하고 있는 라이선스 정책에 대해서도 관심을 가질 필요가 있다. 오픈 소스는 곧 무료이기에 내 맘대로 가져다 고쳐 쓰면 되지..라는 잘못된 생각에 빠져 마냥 가져다 쓰다가 저작권 위반으로 소송으로 가는 경우가 심심찮게 보고되고 있다. 위에서 언급된 것들 중 가장 많이 사용되는 프레임웍의 라이선스 정책을 보면, Spring.NET과 iBATIS.NET이 Apache License 2.0을 채택하고 있으며, NHibernate가 LGPL을 채택하고 있다. 즉, 이것들 모두 상용 제품 만드는데 사용할 수 있으나 NHibernate가 채택한 LGPL의 경우에는 좀  더 엄격하여, 가져다가 소스를 수정했으면 NHibernate 관련 부분의 소스를 공개하여야 하는 제약이 있다. 물론 이 보다 더 엄격하여 GPL의 경우, 오픈 소스 소프트웨어를 가져다 쓰면, 이와 링크 형태로 엮일 지라도 메모리 상의 영역을 함께 쓰는 모든 소프트웨어의 소스 코드 전부를 공개해야하며 상용 소프트웨어와의 결합을 금지하고 있다. 다만, 이 경우에도 배포만 하지 않고 웹 싸이트에서 서비스 형태로 제공된다면 설령 GPL일 지라도 공개할 의무는 없다.

각종 오픈 소스 소프트웨어의 라이선스 정책에 대한 간단한 설명과 비교자료를 원하시는 분은 예전 정통부와 컴퓨터프로그램보호위원회가 함께 펴 낸 오픈 소스 SW 라이선스 가이드를 참고하시길...

아울러 알려지지 않았지만, 시장에서 오픈 소스 프레임웍을 적용하여 프로젝트가 진행되었거나 진행되고 있는 곳이 있다면 가능한 선에서 그 정보를 댓글이나 메일을 통해 공유하여, 오픈 소스를 적용하고자하나 용기가 없어 주저하고 계신 분들께 힘을 실어주시길....

Posted by 장현춘

지난 포스팅에서는 프레임웍 기반 개발이란 무엇인가 살펴보고, 닷넷 개발 생태계 측면에서 오픈 소스 기반의 프레임웍이 제공하는 가치에 대해 알아 보았다. 또한 이후 포스팅에서는 프레임웍 기반 개발의 장점과 적용시 유의사항에 대해 살펴보았다.

Framework-based Development – 개념
Framework-based Development – 적용
Framework-based Development – 종류
Framework-based Development - 오픈 소스 적용 사례

이번 시간에는 프레임웍 기반 개발시 적용할 수 있는 오픈 및 오픈 소스 프레임웍들에는 어떠한 것들이 있는지 살펴보기로 한다.

통상적인 웹 기반 애플리케이션을 개발할 경우 Presentation-Business-Data Tier라는, 일반적으로 얘기하는 3 Tier 아키텍처를 갖게 되는데, 각 Tier에서 사용할 수 있는 범용 개발 프레임웍으로는 아래와 같은 것들이 있다. (필자는 logical은 layer, physical은 tier라는 구분을 좋아하지 않는다. 인접하는 컴포넌트 사이에 수평적으로 서비스를 제공하고 주고 받는 사이를 tier, 한 tier내에서 수직적인 구조를 layer라고 구분하는 것을 좋아한다.)

전통적으로 프리젠테이션 티어 구현 기술로는 ASP.NET이 있었고 이는 널리 알려진 바대로 Page Controller를 구현한 일종의 MVC 프레임웍이다. 프리젠테이션 티어의 가장 큰 관심사는 사용자의 요구를 어떻게 효과적으로 처리할 것인가에 관한 것으로 MVC가 그 핵심이다. 엔터프라이즈 솔루션 아키텍처 디자인 패턴이라는 p&p가 제공하는 가이드에 Page Controller의 최상위 클래스가 복잡한 분기문으로 가득차게 되면 Front Controller를 고민하라고 했듯이, 일반적으로 Front Controller는 Page Controller 보다 좀더 복잡한 애플리케이션 구축에 활용하는 패턴이다. Front Controller 패턴으로 구현한 ASP.NET 기반의 MVC 프레임웍이 바로 ASP.NET MVC 프레임웍이며 현재 베타상태이다. ASP.NET MVC 이전에 시장에는 Castle Project에서 오픈 소스 기반으로 MonoRail을 만들어 배포하고 있었으며, 자바에서 포팅된 Maverick.NET이라는 것도 있었다. 그외 MVC의 View 부분을 치환할 수 있는 다양한 엔진들이 등장하였는데, 그 중에는 자바 template engine인 Velocity의 닷넷 버전인 NVelocity, MonoRail을 위한 View Engine인 Brail, Rails의 view engine으로 널리 쓰이는 Haml의 닷넷 버전인 NHaml 등이 있다. 향후 프리젠테이션 티어의 구현 기술로 가장 주목을 받을 것은 ASP.NET MVC임에는 이론의 여지가 없어 보인다.

비지니스 티어의 가장 큰 관심사는 객체 라이프싸이클 관리이다. 사용자의 요구에 대해서 비지니스 도메인을 구현한 객체들을 얼마나 효과적으로 생성하고 관리하며, 프레임웍과 도메인 구현 엔티티 사이의 의존성을 줄여 향후 유지보수 측면에서 IT 부서의 부담을 줄여 줄 수 있는지가 관심사이며 여기에 핵심 키워드는 Dependency Injection, AOP 라 볼 수 있다. 전통적으로 일반 닷넷 객체 (PONO – Plain Old NET Object)로 원하는 비지니스 기능을 구현했으며 이때는 닷넷 프레임웍이 제공하는 기본적인 객체 생성 및 GC 매커니즘에 의존하고 개발자의 스킬에 의해 메모리 관리 등을 처리하였다. 하지만, 근래에 DI 기능을 기본으로 탑재한 컨테이너들이 수도 없이 출현하였고 가장 대표적인 것들이 위 그림에 나와 있다. Unity는 마이크로소프트 P&P 팀이 제공하는 것으로 Enterprise Library의 객체 라이프싸이클 관리 기능을 제공하는 ObjectBuilder의 Wrapper 클래스들로 구현되어 있으며 현재 Silverlight 지원하는 버전까지 제공되고 있다. 그 밖에 자바 진영의 대표적인 DI 컨테이너인 Spring이 포팅된 Spring.NET이 많은 개발자의 관심을 끌고 있으며 실제로 국내외 닷넷 프로젝트에 적극 활용되고 있다. DI 기본 기능에 프리젠테이션 티어와 데이타 티어의 각종 프레임웍에 대한 편리한 Wrapper 기능을 제공하는 것으로 정평이 나 있다. StructureMap은 Jeremy D. Miller가  만들어 유지보수하고 있으며 닷넷 진영의 가장 오래된 DI 컨테이너이다. Windsor 컨테이너는 Castle Project의 산물이며, NInject는 빠른 DI 기능 제공을 내세우며 근래에 등장한 컨테이너로서 실버라이트 및 .NET Compact Framework 지원 버전까지 제공한다. 많은 비지니스 티어 관련 프레임웍 중에서 전 세계적으로 가장 많이 사용되고 있는 것은 StructureMap으로 알려져 있으나 향후에는 Unity 아니면 Spring.NET이 대세가 되지 않을까하고 조심스럽게 점쳐 본다. 이유는 Enterprise Library의 DI 기능은 위에서 언급된 DI 컨테이너들 거의 모두를 사용하여 제공될 수 있으나 기본적으로는 Unity가 포함되어 있다. 따라서 이전부터 Enterprise Library를 써 오면서 ObjectBuilder에 익숙한 사람들은 많은 고민없이 Unity를 선택할 것으로 판단된다. Unity (Objectbuilder)는 시장에서 어느 정도 검증되었고 피드백도 좋다. Spring.NET은 자바 진영의 de-facto standard DI 컨테이너이며 이의 명성을 바탕으로 닷넷 진영에서도 빠르게 세를 넓히고 있다.

데이터 티어는 기본적으로 ORM (Object-Relational Mapping)을 제공하며 이 티어에는 Object와 RDB 사이의 Impedence Mismatch를 해결하는 다양한 기술들이 제공되고 있다. 전통적으로는 ADO.NET API를 사용하여 DAO 패턴을 적용하여 ORM을 처리하였고 지금도 가장 많이 쓰이고 있는 방식이 아닐까 생각된다. .NET Framework 3.5부터 등장한 LINQ (to SQL, Entity, Object, XML)는 개발자들로 하여금 SQL에 대한 두려움을 어느 정도 상쇄시켜 줄 수 있는 획기적인 DSL 방식의 해결책이다. Entity Framework은 마이크로소프트가 내놓은 진정한 의미의 ORM이라고 할 수 있으며 객체와 데이터베이스 테이블 사이의 다대다 매핑을 지원하며 둘 사이에 의존성을 갖지 않고 독자적으로 변경을 가할 수 있도록 고안된 추상화 레벨을 한 단계 끌어올린 ORM이다. NHibernate와 iBATIS.net은 자바 진영의 ORM 시장을 양분하고 있는 오픈 소스 기반의 대표적인 ORM 툴이며 이것들의 닷넷 버전이다. NHibernate와 iBATIS.net은 현재 국내외 프로젝트에서 주목을 받으며 적용된 사례가 있으며, 각각 고유한 장점이 있기에 적용하고자 하는 필요에 가장 잘 부합하는 것을 선택하는 것이 필요하다. SubSonic은 Rob Coney가 만든 오픈 소스 ORM으로 Rails의 scaffolding 기능까지 제공하고 있다. 또한 SubSonic은 .NET Framework 3.5 SP1에서 제공되는 ASP.NET Dynamic Data에 Scaffolding 기능을 제공하며 .NET Framework에 포함되었다. 하지만 여전히 SubSonic은 오픈 소스로 제공되고 있다. ActiveRecord는 역시 Castle Project의 ORM 관련 산물이다. ORM  툴들은 여기 예시된 것 이외에 상용을 포함하여 훨씬 많은 것들이 시장에 나와 있으며, 이 많은 프레임웍 중에서 LINQ, NHibernate, iBATIS.NET이 가장 주목을 많이 받을 것으로 기대된다. LINQ to NHibernate도 이미 시장에 나와 있듯이 핵심 기능은 NHibernate나 iBATIS.net을 쓰되 개발자 인터페이스 부분은 LINQ가 담당할 가능성도 있다.

참고로, Castle Project를 진행했던 Hamilton Verissimo와 SubSonic을 만든 Rob Conery 모두 마이크로소프트 직원이 되었지만, 현재 이들은 여전히 오픈 소스 프레임웍 개발에 전념하고 있다.

정리하면 다음과 같은 조합이 가장 현실적인 대안이 되지 않을까 한다.
ASP.NET MVC + { Unity, Spring.NET } + { LINQ, NHibernate, iBATIS.net }

이들 프레임웍들은 서로의 존재를 모르고 시장에 나온 경우가 많다. 따라서 이들 프레임웍들을 효과적으로 연동하기 위한 약간의 수고 필요한데, 대부분의 경우 특히 유명한 프레임웍들은 서로에 대해 연동하는 Wrapper를 자체적으로 제공하거나 MVCContrib과 같이 별도의 프로젝트에서 인접 티어의 프레임웍 연동 기능을 제공하고 있다. 예를 들면, MVCContrib은 ASP.NET MVC와 인접한 다양한 DI 컨테이너들 즉, Unity, Spring.NET, Windsor 등에 대한 연동 모듈을 제공하고 있으며, Spring.NET 자체적으로는 NHibernate에 대한 Wrapper를 제공하고 있다.

시장에서 가장 많이 사용하는 범용 프레임웍들을 조합하여 하나의 예로서 Billy McCafferty가 제시하는 것으로 Sharp Architecture가 있다.

그림에서 보듯이 Billy는 다양한 시도를 진행했다. 처음에 ASP.NET MVC + Spring.NET + NHibernate의 조합을 제시했다가 DI 기능만을 위해 Spring.NET을 쓰는 것이 비효율적이라 생각되어 Spring.NET을 빼고 DI 기능을 손수 PONO 형태로 구현했었다. 이후 NInject라는 가벼운 DI 컨테이너를 다시 도입한 빌드를 선보였고, 근래에는 NInject 대신에 Windsor 컨테이너를 조합한 빌드를 제시하고 있다. 따라서 Sharp Architecture 싸이트에 가보면 다양한 조합의 빌드를 다운받아 테스트해 볼 수 있다.

여기에서 언급된 다양한 프레임웍 및 관련 자료에 대한 링크는 다음과 같다.

마이크로소프트 제공

Patterns & Practices

http://www.microsoft.com/practices

CodePlex

http://www.codeplex.com

ASP.NET MVC

http://www.asp.net/mvc

ASP.NET MVC Contrib

http://www.codeplex.com/MVCContrib

Scott Guthrie Blog

http://weblogs.asp.net/scottgu/

Unity Application Block

http://www.codeplex.com/unity

Enterprise Library

http://www.codeplex.com/entlib

 오픈 소스 프레임워크

Sharp Architecture

http://code.google.com/p/sharp-architecture/

Castle Project (MonoRail, Windsor, ActiveRecord)

http://www.castleproject.org/

Ninject (DI)

http://ninject.org

Spring.NET (DI)

http://springframework.net

StructureMap (DI)

http://structuremap.sourceforge.net/Default.htm

S2Container.NET (DI)

http://s2container.net.seasar.org/en/index.html

autofac (DI)

http://code.google.com/p/autofac/

compactcontainer (DI for compact framework)

http://code.google.com/p/compactcontainer/

LinFu (DI)

http://code.google.com/p/linfu/

NHibernate (ORM)

http://www.hibernate.org/343.html

iBATIS.NET (ORM)

http://ibatis.apache.org/

SubSonic (ORM)

http://subsonicproject.com

Posted by 장현춘

프레임웍 기반 개발이라는 것은 말 그대로 엔터프라이즈 애플리케이션을 개발함에 있어서 기존에 만들어진 프레임웍의 조합을 통해 좀 더 빼르고 견고하게 원하는 결과물을 만들어 내는 것을 말하며, 이는 어느 특정 벤더의 개발 방법론도 아니고 개발 영역에서 자연스럽게 발전하여 체득된 개발 방식이다. SI 경험이 많은 대부분의 기업에게는 기업용 애플리케이션 개발에 있어서 경험으로 부터 다듬어져 프레임웍의 형태를 띄는 것들을 가지고 있다. 추상화 혹은 모듈화 정도의 차이가 있을 뿐, 혹은 대외적으로 홍보하는 이름이 있고 없을 뿐 대부분의 개발이 프레임웍 기반으로 진행되고 있다고 봐도 무방하다.

향후 몇 번에 걸쳐 프레임웍 기반 개발에 대해 살펴보기로 하자

Framework-based Development – 개념
Framework-based Development – 적용
Framework-based Development – 종류
Framework-based Development - 오픈 소스 적용 사례

이처럼 많은 개발사 혹은 개발자들이 경험으로부터 선호하게 되는 프레임웍이라 것은 선조 프로그래머들의 지혜를 재활용하는 많은 방법 중에서 가장 개발자에게 직관적이고 현실적인 재사용 수단이다. 즉, 남들이 만들어 시장에서 다양한 곳에 적용되어 능력을 검증 받은 코드셋을 가져다 내 환경에, 나의 프로젝트에 맞게 약간의 변형을 가하고 설정을 변경하여 재사용할 수 있는 잘 만들어진 클래스 집합인 것이다. 프레임웍을 분류하는 방식은 프레임웍의 정의만큼이나 다양하나 일반적으로 블랙 박스 vs 화이트 박스 혹은 라이브러리성 vs 개발 프레임웍(컨트롤) 혹은 아주 간단하고 자주 쓰이는 오픈 (오픈 소스) vs 상용 프레임웍 등이 있다.

프레임웍 기반 개발이라는 것은 상용이든 오픈이든 용도에 맞는 가장 적절한 프레임웍들의 조합을 통해 전체 프로젝트를 관통하여 사용될 뼈대를 완성하고 개발자들로 하여금 비지니스 로직을 구현하여 이 뼈대가 제시하는 Contract에 맞게끔 개발하도록 만드는 정형화된 개발 방식이다. 이렇게 시장에서 검증된 프레임웍들의 조합을 통해 자연스럽게 흔히 얘기하는 비기능적 요구사항 (소위 QoS 요소)들을 달성하고 개발자들은 주어진 도메인에 집중하여 고객에게 전달할 가치 (기능적 요구 사항 포함)를 창출하도록 만드는 것이다. 이를 통해 개발자들의 창의성과 생산성을 기반 프레임웍 개발에 쓰여 낭비하지 않도록 하며 좀 더 나은 고객 가치를 전달하는데 사용케하자는 것이다.

여기서 생각해 볼 문제는 과연 어떤 프레임웍들을 조합의 대상으로 삼을 것인가 하는 점이다. 이 점에서 많은 부분 동의하지 못하는 분들도 있을 것 같은데, 필자는 가급적 오픈 (혹은 오픈 소스) 기반의 범용 개발 프레임웍들을 조합하길 권장하는 바이다. 흔히 말하는 범용 개발 프레임웍은 말 그대로 도메인에 특화된 로직을 품고 있지 않아서 대부분의 프로젝트에 쓰일 수 있는 기본 기능을 담고 있는 것들이다. 가령 로깅, 에러 처리등의 라이브러리들을 포함하여 객체 라이프 싸이클 관리, 모니터링 혹은 다른 레이어와의 인터페이스 모듈 등등 모든 프로젝트에서 항상 고민하는 것들이 포함된다. 세상에는 이미 나 혹은 내가 속한 팀, 더 나아가 우리 회사가 만들어 자랑스럽게 내세우는 프레임웍 보다 더 훨씬 더 잘 만들어 공개되어 우리 회사가 10년 아니 우리 회사가 망할때 까지 수행해도 다 못할 만큼의 전세계 수많은 프로젝트에서 다양한 환경에서 검증되어 발전해가는 즉, 닷넷의 개발 생태계 내에서 태어나 성장하는 뛰어난 범용 개발 프레임웍들이 널려 있다. 이제는 이러한 것들을 함께 공유하고 이러한 개발 생태계내에 우리도 일원으로 참여하여 생태계를 키우고 그로 인한 열매를 함께 향유하는 것이 필요하다.

오해하지 말 것은 필자가 범용 개발 프레임웍이라고 칭하는 부분이다. 도메인에 특화된 비지니스 프레임웍들을 여전히 상용으로 판매되고 있다. 가령 금융 패키지 혹은 코어 뱅킹, 제조 패키지 등등 도메인에 특화되어 있기에 닷넷에 대한 개발 노하우가 있다고 누구나 만들 수 있는 것도 아니며 도메인 지식이 풍부해야 진입할 수 있는 영역이기에 개발 생태계가 관장하기에는 아직 닷넷 개발 생태계가 성장하기 못한 면이 있다. 하지만 마음만 먹으면 누구나 만들 수 있는 범용 개발 프레임웍은 사정이 다르다. 전세계가 유사한 기능을 하는 비슷비슷한 프레임웍이 나타나는 이유는 간단하다. “난 쟤들 거 이런 이런 점이 맘에 안들어...” 이거다. 이렇게 만들어진 것이 대중의 사랑을 받게 되면 개발 프레임웍에 있어 de-facto standard로 자리잡아 칭송을 받게 되는 것이다.

고객이 입장에서 보면 오픈을 써야하는 이유는 더 극명하다. 벤더 종속적인 프레임웍을 도입하였을 경우 기반이 되는 .NET의 발전에 맞추어 유지보수해야 하는 문제며, 소스 코드를 포함한 소유권 문제 등도 있고, 프레임웍 개발사가 증명할 수 있는 각종 QoS 수준과 전세계 닷넷 개발 생태계가 증명할 수 있는 수준과의 신뢰성 등 고객은 이미 오픈 혹은 오픈 소스에 대해 많은 것을 알고 있다. 개발자들의 자유로운 접근과 사용, 그리고 그 과정에서 주고 받는 Q&A 및 피드백을 통해 오픈 프레임웍은 자연스럽게 생태계속에 편입되어 발전하게 되는 것이다.

다음 시간에는 현재 우리가 사용할 수 있는 프레임웍들에는 어떤 것이 있고 어떤 점을 고려하여 선정하여야 하는지 더 나아가 적용할 때 고민해야 할 부분등에 대해 함께 알아보도록 하자.

Posted by 장현춘
마이크로소프트가 MSDN 세미나의 일환으로 오픈 및 상호운용성 데이를 진행합니다. 마이크로소프트가 생각하는 오픈 스탠다드 (공개 표준), 오픈 소스 및 상호 운용성에 대해 알아보고 함께 논의하는 자리가 될 것으로 생각합니다.
오픈 스탠다드를 지향하는 마이크로소프트의 정책, 지원 노력, 오픈 스탠다드 기반 닷넷과 자바의 상호운용 (여건이 된다면 Azure 서비스까지), PHP 데모, 국내 오픈 소스 개발 프레임웍 적용 사례 등 다양한 주제가 마련되어 있습니다.


Posted by 장현춘

마이크로소프트가 예전부터 줄기차게 오픈 소스를 외쳐왔지만, 오늘날만큼 그 진정성이 인정을 받는 경우가 없었다. 근래에 들어 오픈 소스 랩을 만들고, Codeplex를 제공하여 많은 오픈 소스 프로젝트를 지원하고, 각종 특허에 대한 로얄티 없는 사용을 가능케하는 등 예전보다 한층 강화된 오픈 소스에 대한 포용정책을 진행하고 있다. 한 마디로 마이크로소프트에게 있어서 오픈 소스 커뮤니티 및 오픈 소스 소프트웨어는 상용 소프트웨어와 경쟁 및 보완 관계를 이루고 있으며 점차 뗄레야 뗄 수 없는 관계가 되어 간다는 것을 인식하고 있음을 보여주는 것이다.

이런 정책적인 드라이브 외에도 개발면에서도 각종 오픈 소스 프레임웍이나 라이브러리들이 각광을 받으며 점차 많은 프로젝트 싸이트에서 성공적으로 사용되어 개발자들에게 선택의 폭을 넓혀주고 있다. 국내외를 막론하고 닷넷 개발에서도 이제 오픈 소스 및 상용 소프트웨어가 개발자들의 선택을 받기 위해 경쟁하는 바람직한 모습이 보여지고 있으며, 이는 같은 영역에서 상용 소프트웨어가 오픈 소스 소프트웨어와 차별점이 없다면 고객의 선택을 받을수 없다는 점이 점점 명확해지고 있다는 것이다. 이는 상용 소프트웨어에게 있어서 도전이자 전체 소프트웨어의 건전성을 지속시키는 촉매제이기도 하다. 이 시점에 미국에서 열린 OSCON (O'Reilly Open source Convention)에서 의미있는 발표가 있었다.

지난 25일 미국에서 열린 OSCON (O'Reilly Open source Convention)에서 Sam RamJi가 발표한 바에 따르면, 마이크로소프트는 아파치 재단의 스폰서 레벨의 가장 높은 등급인 플래티넘 스폰서가 되었으며, 이전의 이클립스 재단과의 기술적 협력 관계와는 다른 성격의 오픈 소스에 대한 참여라고 밝히고 있다. 그 밖에도 GPL v2 기반의 PHP용 데이터베이스 접근 모듈인 ADOdb에 대한 패치를 제공하였다. ADOdb는 SQL Server에 접근할 수 있는 PHP 및 Python 전용 native driver로서 예전에 느끼지 못했던 빠른 성능을 제공한다. 또한 오피스 포맷을 포함하여 마이크로소프트가 보유한 각종 프로토콜 및 포맷에 대해 로얄티를 부과하지 않는 라이선스를 제공하고 있다고 밝히고 있다.

좀 더 자세한 사항은 아래에서 확인할 수 있다.
Microsoft and Its Open-Source Plans


그 밖에 마이크로소프트의 오픈 소스에 관한 각종 정보는 아래에서 확인할 수 있다.
Share Source Initiative
Open Source Community @ Microsoft

또한 마이크로소프트는 SourceForge.net의 다이아몬드 스폰서로서 SourceForge.net 2008 Community Choice Awards를 후원한다.
SourceForge.net 2008 Community Choice Awards

Posted by 장현춘