C++에서는 Template라는 형태로 Generics를 제공해 왔습니다. 패턴적인 측면에서는 C#의 Generics와
크게 다르지 않으나, 결정적인 차이가 있다면 C#에서는 CLR이 지원한다는 것입니다. 일종의 매크로(템플릿에 제공된 각 형식
매개 변수에 대한 특수화된 형식을 생성)일 뿐인 C++의 Template과는 달리 Generics는 Runtime시에 JIT
컴파일러에 의해 적절히 해석되고 Native Code로 컴파일된다는 것입니다.
C++와 같은 후기 바인딩 방식에서는 단지 클래스 또는 인터페이스의 상속을 통한 바인딩이었기에 Logic의 확장이
어려웠고, 형식의 안정성에서의 문제점도 꼼꼼히 따져야만 했습니다. 적어도 전달되는 클래스는 같은 클래스에서 상속을 받거나 같은
인터페이스를 구현해야 했습니다. 물론, COM의 IUnknown 같이 자기기술자[Self-Descriptor]를 가진
클래스/인터페이스를 만들면 해결할 수 있겠지만 그 노력은 만만치 않습니다. C#의 Generics를 적용하면 'Logic'과
'Logic에 의해 다뤄지는 객체'를 명확하게 구분할 수 있습니다.
결국 Domain/Business Logic을 구현이라는 점에서는 크게 다를 바가 없지만 그 유연성에 있어서는 상당히 선택의 폭이 넓어졌다고 할 수 있습니다.
-- JAVA의 Generics (Parametric polymorphism) --
Java의 Generics는 Pizza라는 프로젝트로부터 시작되었으며, 이후 GJ라고 이름이 붙여졌고, JSR로 바뀐
것입니다. Sun사는 Java Virtual Machine을 수정할 필요가 없는 구현을 선택했습니다. 따라서 Sun사는 수정되지
않은 가상 시스템에서 Generics를 구현함으로 해서 많은 단점들을 가지게 되었습니다.
Java Generics는 어떤 실행 능률도 높여 주지 못합니다. Java Compiler는
List<Integer>라는 Parameterized Type을 만들면 Integer를 Object로 모두 변환하고
필요한 곳에 (Integer)형 변환을 실행합니다. 이는 수정되지 않은 Java Virtual Machine이 값
형식(Value Type)에 대해 Generics를 지원하지 못하기 때문입니다. 따라서 Java의 Generics에서는 실행
효율성을 얻을 수 없습니다.
Java의 Generics는 erasure of the type parameter(매개변수 타입의 말소)라는 것에
의존하기 때문에 Runtime시에 List<Integer>는 List라는 클래스와 동일한 클래스로 표현됩니다. 이것은
어떤 클래스가 List<Integer>인지 List<String>인지 Runtime시에는 알 수 없다는
것입니다. 이는 Runtime시에 Generics 형식의 Instance에 대한 형식 매개 변수를 확인할 수 있는 방법이 없으며
다른 리플렉션(Reflection) 사용이 엄격하게 제한된다는 의미입니다.
출처 : vs 2005로 배우는 C# 게임 프로그래밍
델파이2009에도 Generics가 추가 되었군요.
Template의 영향력이 크네요.
STL과 같은 구조의 라이브러리가 전언어에서 구현가능하겠군요.
STL은 Standard Template Library약자로
98년에 C++표준이 되어 C++컴파일러에는 모두 포함되어 있다.
지
난 2000년 6월 포럼 2000에서 처음 발표된 닷넷은 MS가 추진하고 있는 서비스 중심의 통합 플랫폼이라는 거대 전략이다.
모노(Mono Project)는 닷넷 프레임워크를 오픈소스로 구현하려는 프로젝트이다. 그 동안 서른 번의 릴리즈에도 불구하고
말도 안 되는 실현 불가능한 일이라 여겼는지 아니면 눈에 띄는 뚜렷한 결과물, 이를테면 비주얼 스튜디오 닷넷(이하
VS.NET)과 같이 눈에 착착 달라붙고 보여줄 수 있는 닷넷 개발 환경을 무작정 기대한 것일까. GUI 환경의 많은 Gtk#
애플리케이션들이 나왔지만 국내에선 일부 MS와 관련한 비판만 있었을 뿐 그다지 큰 반향을 일으키지는 못한 것 같다. 그럼 먼저
최근 활발히 개발되고 있는 MonoDevelop 모노 IDE(Integrated Development Environment)를
소개해 본다.
리눅스에서 새로운 통합개발환경
[화면 1]의 MonoDevelop은 Gtk#
기반의 통합개발환경(이하 IDE)로서 모노 기술로만으로 만들어진 C# 프로그램이다. Gtk#은 리눅스에서 사용자를 위한 편리하고
화려한 데스크탑 환경을 제공하는 그놈(GNOME)을 C# 바인딩한 것으로 최근 2.6이 발표된 그놈의 눈부신 발전에 힘입어
리눅스에서 미려한 각종 GUI 컨트롤을 쉽게 만들 수 있는 기반이 된다. 아직 몇 달 안 된 프로젝트이지만 신세대 IDE라면
갖추어야 할 코드 인텔리전스([화면 2]), 디버깅, 플러그인 기능을 내장하였다. 물론 2001년부터 시작하여 지금은 IBM을
비롯한 수십 개의 회사가 지원하는 경쟁자 이클립스가 있긴 하다. 자바로 만든 이클립스는 한번 더 언급하기로 하고 일단
MonoDevelop과 함께 선보인 멋진 발표 현장을 가 보자.
[화면 1] MonoDevelop 실행 화면
[화면 2] Intellisense 기능
Novell BrainShare 2004
지
난 3월에 있었던 노벨 세미나에서 미겔(Miguel de Icaza)과 에릭(Erik Dasque)은 리눅스에서 애플리케이션
개발을 얼마나 쉽고 빠르게 할 수 있는지 단적으로 보여주었다. 진행자의 신호에 빨간색 모노 티를 입은 미겔과 에릭이 등장했고
발표는 MonoDevelop을 띄워 놓고 진행되었다.우선 새로운 Glade# 프로젝트를 선택하자 기본적인 코드가 생성되었다.
그놈 UI 디자이너 Glade를 실행하고 버튼, 텍스트 입력 컨트롤 그리고 Gecko 웹 컨트롤을 배치하여 UI를 구성했다.
관련 닷넷 어셈블리 등록을 마치고 [리스트 1]과 같은 코드를 간단히 몇 줄 추가함으로서 웹 브라우저가 완성이 됐다.
[리스트 1] 웹 브라우저 예
using System;
using Gtk;
using Glade;
using Gecko;
public class GladeApp
{
[Widget] Frame frame1;
[Widget] Entry entry1;
WebControl web;
public static void Main (string[] args)
{
new GladeApp (args);
}
public GladeApp (string[] args)
{
Application.Init();
Glade.XML gxml = new Glade.XML ();
gxml.Autoconnect (this);
web = new WebControl ();
web.Show ();
frame1.Add (web);
entry1.Activated += load_url;
Application.Run();
}
이
것을 리눅스 프로그램이라 쉽게 믿을 수 있을까. 그것도 완벽하게 실행되는 환경이라면. 뿐만 아니라 닷넷의 특징이라 할 수 있는
윈도우?리눅스 바이너리 호환성, 즉 리눅스에서 컴파일한 실행 exe 파일을 윈도우에 복사하는 것만으로 윈도우에서 실행이
가능하다.
미리 보는 모노 1.0
이번에 발표되는 모노 1.0은 다음과 같은 기능을 포함할 것이다.
◆ C# 컴파일러
◆ 닷넷 CLR(Common Language Runtime)
◆ 닷넷 1.0과 1.1 API를 완벽하게 구현한 닷넷 클래스 라이브러리
◆ System.Web을 구현한 웹 서비스 애플리케이션 플랫폼
◆ System.Data를 비롯한 모노 데이터베이스 프로바이더
◆ 그놈 데스크탑 컴포넌트의 C# 바인딩인 Gtk#
◆ 자바 플랫폼 실행 환경 IKVM
C# 컴파일러
모
노 C# 컴파일러는 순수 C#으로만 작성된 프로그램이다. C#으로 된 컴파일러 소스를 컴파일하는 최초의 부모는 MS 컴파일러가
되는 셈이다. 컴파일러가 컴파일러 자신을 만드는 이러한 셀프 호스팅(self hosting)은 개발자들이 C# 언어를 이해하는
데 훌륭한 기본 바탕이 되었으며 많은 코드 재사용이 이루어졌다.
닷넷 CLR
다
양한 언어를 위한 공통적인 플랫폼인 닷넷 CLI(Common Language Infrastructure) 그리고 여기에 사용되는
중간 언어인 CIL(Common Intermediate Language) 코드를 위한 아키텍처 코드 생성과 실행은 모노 런타임이
맡고 있다. 이는 CIL 가상머신(VM), 클래스 로더, 가비지 컬렉터, 쓰레드 시스템, 메타데이터 접근 라이브러리를 위한
JIT(Just-in-Time) 엔진을 담당한다. 런타임 개발 도중 미리 네이티브 코드로 컴파일해 둬 성능을 극대화시키는
AOT(Ahead-of-Time)를 지원하기 위한 mini 런타임을 만들었고 현재 기본 런타임이 되었다. 모노는 현재
리눅스/x86, 솔라리스/SPARC, Mac OS/PowerPC 아키텍처를 지원한다.
닷넷 클래스 라이브러리
닷
넷 네임스페이스를 구성하는 어셈블리들의 방대한 닷넷 클래스 라이브러리를 구현하는 것은 무모해 보였다. 공개된 API만을 보고
내부 사정을 구현하는 작업이기 때문이다. 하지만 현재 MSCORLib(Multilanguage Standard Common
Object Runtime Library), System, System.Security, System.XML 라이브러리를
100% 완성하여 이를 1.0에 포함할 것이다. 게다가 MS가 지원하지 않는 모노 전속 라이브러리도 많아졌다. 또한 다양하고
방대한 라이브러리의 자동화된 테스트를 위한 유닛 테스팅 프레임워크와 각 수천 개의 테스트 케이스를 지속적으로 관리하였다.
ASP.NET, ADO.NET
ASP.NET
은 웹 서비스를 구축하기 위한 닷넷 환경이다. 이를 위한 관련 System.Web 라이브러리를 구현하였고 웹 서버 XSP 또는
아파치 모듈을 통해 웹 애플리케이션을 돌릴 수 있다. 이와 함께 ADO.NET을 지원하기 위해서 다양한 모노 데이터베이스
프로바이더(MSSQL, Oracle, MySQL, Interbase, IBM DB2, SQL Lite, Sybase, TDS)를
제공하고 있다.
Gtk#
그놈은 모노의 시발점이 된
프로젝트이다. 다양한 언어를 지원하는 그놈이긴 하지만 API 바인딩을 지속적으로 관리하기 위해선 수작업 노동이 동반된다.
Gtk#은 닷넷 특성을 최대한 활용하였다. [리스트 1]의 [Widget] 코드를 보라. 닷넷 애트리뷰트를 이렇게 적용할 수도
있음을 확인할 수 있다. 커스텀 XML 파일에 바인딩 정보를 넣어 자동 생성되는 Gtk#은 단순 C# 바인딩을 넘어 OOP,
닷넷 델리게이트 등 각종 트릭을 가능케 했다. [리스트 2]의 코드는 OOP의 대표적인 특징인 상속을 보여주고 있다. 알다시피
Gtk+를 비롯한 그놈 컴포넌트의 대부분은 C로 짜여져 있다.
[리스트 2] Gtk# subclassing
// Subclass.cs - Widget subclass Test
//
// Author: Mike Kestner
//
// (c) 2001-2003 Mike Kestner, Novell, Inc.
namespace GtkSamples {
using Gtk;
using System;
public class ButtonApp {
public static int Main (string[] args)
{
Application.Init ();
Window win = new Window ("Button Tester");
win.DeleteEvent += new DeleteEventHandler (Quit);
Button btn = new MyButton ();
win.Add (btn);
win.ShowAll ();
Application.Run ();
return 0;
}
IKVM
예
컨대 자바나 닷넷 선택의 기로에 있는 개발자들이 있을 것이다. 하지만 닷넷이 자바의 장점을 많이 흡수해서인지 졸탄(Zoltan
Varga)의 IKVM은 자바 클래스 라이브러리를 구현한 GNU Classpath를 이용하여 자바 플랫폼을 실행할 수 있게
해준다. 즉 이클립스를 모노 런타임으로 돌리는 것이다. 한편 그놈 진영에서도 자바냐 모노냐 하고 논쟁이 있는데 이런 프레임워크
선택 문제는 상황과 위치에 따라 자기 목소리를 낼 수밖에 없는 것 같다. 각각의 장단점을 파악하고 자신만의 경쟁 무기를 만드는
것이 좋을 것이다.
열정적인 커뮤니티, 모노 팀
그렇다면 어떻게 3년 만에 이 많은 것을
완성할 수 있었을까. 2001년 7월 9일, 4명의 지미안(Ximian) 해커로 시작한 모노 프로젝트는 현재 노벨이 지미안을
인수하여 노벨 소속 십여 명의 개발자와 130여명의 전 세계 각지의 자발적인 해커들이 참여하여 진행하고 있다. 모노 테스팅
프레임워크를 구축한 Nick Drochak과 XML 마스터 Atsushi Enomoto는 일본에서 참여하고 있다. Ben
Maurer는 도저히 17세라고 믿기 힘든 런타임 최적화 패치들을 쏟아내고 있다. 닷넷 시큐리티 구현에 주도한 Sebastien
Pouliot는 리눅스가 아닌 윈도우가 개발 환경이었다. Mainsoft와 같은 거대 업체에서 대량 지원을 하는 경우도 많았다.
모노에 관심만 있다면 제한없이 누구라도 참여하여 공헌하였다. 디스어셈블과 같은 불법 도용 코드는 사양하되 재사용하는 코드는
많았다.
생산성의 측면에서 소프트웨어 개발에 불필요한 중복 과정을 최대한 줄이는 것은 아주 중요하다. 가독성
높은 코드, 충분한 대화 후에 디자인하고 패치하고 테스팅 그리고 체계적인 버그 관리까지의 모든 과정은 모노 초기부터 모든
영역에서 꾸준히 지켜왔다. 열정적인 커뮤니티 현장은 그간의 메일링리스트 기록으로 확인할 수 있다. 주요 개발자들의 실제 만남이
지난 3월 5일에 열린 보스턴 미팅에서야 처음 있었으니 모노가 얼마나 전 지구적인 오픈소스 프로젝트인지 다시금 느끼게 한다.
모노 적용과 그 미래
아
직 1.0이 나오지도 않았지만 시장에서 모노를 쓰고 있는 개발사(ISV, Independent Software Vendor)가
있는지 궁금할 것이다. 독일 뮌헨 시는 350대 서버 규모의 시스템을 모노 ASP.NET으로 적용하였다. SourceGear라는
회사는 웹 서비스 클라이언트용 프로젝트 관리 애플리케이션 Vault을 내놓았고 리눅스에서 모노를 사용한 커맨드 환경을 지원한다.
임베디드 시스템 벤더들은 C 기반 SDK에 추가로 임베디드용 모노를 도입하고 있다. 이는 강력한 성능과 다양한 플랫폼을 지원하는
모노 클래스 라이브러리와 런타임이 있기에 가능하다.
닷넷이 어디까지 완전 자유로운지 현 상황에선 예측하기
어렵다. 하지만 비록 MS의 소송 가능성이 있다고 하더라도 모노의 가치는 분명 무시할 수 없다. 현대적인 개발 프레임워크의 모든
것을 제시하고 있기 때문이다. 효율적인 개발 환경이 필요했던 많은 개발자들에게 모노는 분명 희소식이다. 거대한 변화에 동참할
개발자는 모노를 두들겨 보길 바란다.
닷넷 커뮤니티 컨퍼런스는 닷넷 개발자들의 권익을 높이고, 닷넷 개발자들이 함께 어울릴 수 있는
개발자들만의 축제의 장입니다. 닷넷 개발에 관련한 전문가분들을 패널과 스피커로 모시고 진행되며 닷넷 개발자들과 함께 현재의 닷넷
기술을 조망하고 앞으로 나아갈 방향을 함께 모색해보는 시간이기도 합니다. 2009년 새로운 도약을 준비하는 닷넷 기술과 어울려
즐길 수 있는 개발자들의 행사 닷넷 커뮤니티 컨퍼런스에 당신을 초대합니다.
주최 커뮤니티
올해에는 HOONS닷넷 커뮤니티의 주최로 행사를 꾸리게 되었습니다.
해마다 주최커뮤니티를 선정하여 닷넷 커뮤니티 컨퍼런스 행사를 기획해 나갈 예정입니다.
닷넷이 탄생한지 어느덧 10여년이 지났습니다. 수많은 IT의 트랜드와 변화속에서 닷넷도 함께
진화해왔으며 지금도 끈임없이 진화하고 있습니다. 이번 시간에는 닷넷의 산증인이라 할 수 있는 마이크로소프트의 에반절리스트들을
모시고 향후의 닷넷은 어떻게 달라질 것인지에 대해서 살펴볼 것이고 또한 닷넷 개발자들이 지금 주목해야할 기술들은 어떤것들이
있을지 살펴보는 시간을 가지고자 합니다.
박경훈 (진행) / HOONS닷넷
현재 HOONS닷넷 커뮤니티 사이트를 운영 중에 있고, Microsoft Visual C#
MVP 로 2005년도부터 활동 중에 있다. 여러 컨퍼런스 및 세미나 행사에서 닷넷과 관련된 여러 기술들을 강의해 왔으며
10여권의 IT 서적을 집필하고 번역하였다. 2005년도에는 KBS에서 선정한 미래의 젊은 주역 60인에 선정되기도 하였으며
지금은 다양한 서비스를 개발하는 시도중에 있다.
강성재 / 한국마이크로소프트
2000년 .NET과 C# 전문가로 활동을 시작해서 2000년 NET#과 ASP+ 커뮤니티
운영을 시작해서 2001년 데브피아 C# 시샵과 MSDN 세미나를 통해 외부 활동을 넓혀 가던 중 2002년 한국마이크로소프트
커뮤니티 스페셜리스트로 입사 이후 2003년 개발자 전도사로 현재 까지 활동. 한국 TechEd와 2003년 이후 모든
Visual Studio 제품 발표회 등 현재까지 500번이 넘는 세미나 진행.
황리건 / 한국마이크로소프트
웹과 IT 분야에서 사용자를 고려한 디자인과 UX의 중요성을 알리는 이반젤리스트로써, NHN
에서 7년간 전문 플래시 개발자로 근무하였다. 현재는 마이크로소프트의 실버라이트, WPF, 서피스 등 사용자 환경의 UX 를
향상시키는 클라이언트 측면의 기술 활용법과 노하우를 전달하는 일을 하고 있으며, UX 전문 지식 팀블로그인
uxfactory.com을 운영하고 있다.
김대우 / 한국마이크로소프트
한국마이크로소프트 개발자 및 플랫폼 사업 총괄 부서 차세대 웹 플랫폼 팀 소속, 웹과 개발자의 일을 더 재미있게 만드는데 관심이 많으며 현재 Web Developer Evangelist로 근무 중
Java에서는 Struts, WebWork와 같은 탄탄한 프레임워크를 갖추고 MVC
Pattern 사용이 이미 보편화 되어 있는 반면에 .NET에서는 대중적인 프레임워크가 없어 MVC Pattern을 적용하는
사례가 적었습니다. 최근 .NET에서도 ASP.NET MVC Framework의 정식 버전이 출시되고 iBATIS.NET,
NHibernate, ADO.NET Entity Framework와 같은 쓸만한 OR Mapper들이 등장하면서 MVC
architecture style에 대한 관심이 높아지고 있습니다. 이 세션에서는 ASP.NET MVC Framework에
간략한 소개를 하고 최근 ASP.NET MVC Framework를 이용해 서비스를 개편한 예스24의 사례를 중심으로 기존
ASP.NET에 익숙한 조직이 MVC를 접하면서 겪었던 어려움과 대용량 시스템에 적용을 위한 이슈들을 점검해 보도록 하겠습니다.
최만석
현재 예스24에서 운영 및 개발을 맡아 시스템 팀장으로 근무하고 있으며 이전에는 기술 기획 및
유닉스 플랫폼에서 서버 개발 등 다양한 분야의 경력을 가지고 있다. 2003년부터 오픈소스 프레임워크를 이용해 유닉스 기반의
프로젝트를 수행한 것을 시작으로 다양한 프로젝트에서 오픈 소스 프로젝트를 적극적으로 이용해 왔다. 최근에는 인터넷 서비스에서
오픈 소스를 이용해 개발 생산성(Productivity) 및 신속성(Agility)을 높이는 데 큰 관심을 가지고 있다.
뜬구름 잡듯이 이야기하는 여러 가지 방법론이 난무하는 강호에 홀연히 등장하여 무림재패를
이뤄나가고 있는 애자일 방법론, 국내 유수의 소프트웨어 기업과 외국계 회사에서의 프로젝트 진행에 관련한 차이와 그 효율성과
장단점 등을 소개합니다. 실무를 겪으면서 있었던 흥미로운 애자일과 TFS의 공생관계, 그리고 애자일 방법론은 과연 우리의 만능
해결사인가에 대해 같이 논의해보는 시간이 될 것입니다.
서동진 / HOONS닷넷
현재 HOONS닷넷 ASP.NET 시삽로 활동 중이며, Microsoft ASP.Net MVP이다. MCAD, MCSD 등 여러 자격을 보유하고 있으며, 기술 서적을 집필하거나 기술 내용을 여러 방면에 기고하고 있다.
패턴은 단지 소프트웨어 설계에만 해당하는 이야기 일까요? 패턴은 여러분의 생각 그 이상의
다양한 주제들을 다루고 있습니다. 팀 구축, 생산성 향상, 메뉴얼 구축, 심지어 데이트하는 방법까지요.. 여러분이 가지고 있는
패턴의 오해를 풀어드리고 패턴의 3박자와 패턴으로 가는 빌드 오더를 소개해 드립니다. 약간 거짓말을 보때서, 코드를 떠나 설계의
관점에서 생각하면서, 생산성을 획득하는 두 마리의 토끼를 잡는 방법을 전달해 드리고자 합니다.
손영수 / 데브피아
데브피아 아키텍쳐 시삽이며, 소프트웨어 공학 스터디인 A&D Eva의 리더이다..
스터디 맴버들과 함께 패턴및 SE 관련 강좌를 무료로 공유하고 있는 EvaCast.NET 을 운영하고 있다. 부족한 지식이지만,
지식을 나눌땐 넉넉한 부자가 되기 위해 노력하고 있으며, 동시에 휼룡한 남편 2.0이 되기 위해 애쓰고 있다.
대부분의 닷넷 프로젝트에서 개발 프레임웍 안에 Enterprise Library를 응용해서
많이 사용합니다. 하지만, 프레임웍 개발자가 아닌 일반 업무 개발자들은 이 Enterprise Library에 대해 잘 모르는
경우가 많습니다. Enterprise Library는 잘 사용하면 개발의 생산성과 유연성을 향상 시키는데 많은 도움이 됩니다.
이 세션에서는 이 Enterprise Library 4.0에 대한 소개와 활용 방법에 대해 설명할 것 입니다.
한용희 / 롯데정보통신
롯데정보통신 품질경영팀에 재직 중이며, Microsoft Visual C# MVP이다. MSDN이나 데브피아 세미나 강사로도 활동 중이다.
컴퓨터를 이용하여 많은 작업을 하고 있는 현대인. 각각의 기능을 하는 다양한
Application이 존재합니다. Web Browser 내에서 이용하는 Web Application, OS 위에 인스톨하여
사용하는 Desktop Application 등으로 분류 할 수 있습니다. 하루가 다르게 발전하는 IT 기술 중
.NetFramework 3.0 기반의 Desktop Application의 미래에 대해 살펴보도록 하겠습니다.
조영국 / 메가존
現 메가존 UX Center 센터장이며, RIA 기반 프로젝트 컨설턴트 / PM 을 주 업무로
하고 있다. RIA 기반 기술을 이용하여 삼성전자, 안철수 연구소, 현대해상, 한화 등 파트너사와 웹사이트, 어플리케이션 개발을
하고 있다.
김재열 / 안철수 연구소
現 AhnLab에서 개발되는 통합보안관리시스템 패키지 소프트웨어를 개발하고 유지보수 하는
업무를 수행하고 있으며, 2006, 2008년 AhnLab TSC(Technical Steering Committee,
최고기술위원회) 위원을 역임하였다. 현재 AhnLab Policy Center, AhnLab TrusGuard Manager,
AhnLab TrusGuard LogServer, Absolute LogServer 제품을 담당하고 있다.
휴즈플로우는 실버라이트와 함께 생겨났고 실버라이트와 함께 발전하고 있는 회사입니다. 초기에는
실버라이트로 미디어플레이어를 만드는 일 외에는 할 수 있는 일이 많지 않았지만 점점 다양한 방면으로 실버라이트를 도입하고
있습니다. DeepZoom으로 으로 대표되는 이미지 서비스뿐만 아니라 기업의 복잡한 데이터 처리에 대한 에플리케이션까지
실버라이트로 시도되고 있습니다. 이러한 실버라이트 시장의 확장을 휴즈플로우의 사례에 비추어서 보여드리고자 합니다.
박건태
개발을 좋아하는 CEO. 현재 휴즈플로우 CEO로써 휴즈플로우에서 경영전반과 개발 지원을 맡고
있음. Silverlight MVP이기도 하며 현재 Naver 실버라이트 카페 스탭으로써 boxmile이란 아이디로 활동중.
2007년 5월에 CTO인 이길복(aka. Gilbert)과 휴즈플로우를 창업한 후 휴즈플로우를 실버라이트 전문 컨설팅 및
솔루션 업체로 만들어가고 있음. 현재는 실버라이트를 이용한 자체서비스를 개발중.
지난 3월, MIX09에서는 더욱 향상된 기능과 성능으로 무장한 실버라이트 3가 베일을
벗었습니다. 실버라이트 3는 RIA 개발 경험을 한 단계, 아니 최소한 두 단계 이상 끌어올릴 수 있는 다양한 장치들을 준비하고
있습니다. 이 세션에서는 실버라이트 3가 디자이너와 개발자에게 제공하는 향상된 RIA 개발 경험을 소개합니다. 특히 익스프레션
블렌드를 중심으로 보여주는 데모들은 디자이너가 RIA 개발 프로세스에 보다 적극적으로 참여하는 동기를 부여할 것입니다.
공인석 / HOONS닷넷
현재 휴즈플로우에서 근무중이며 HOONS닷넷 실버라이트 시삽을 맡고 있다. 실버라이트가 소개된
이래로 실버라이트를 활용한 개발에 매진하고 있다. 유령회사 공도소프트라는 블로그를 통하여 실버라이트에 관한 기술 자료, 컬럼,
강좌 등을 진행하고 있으며 HOONS닷넷 을 비롯한 관련 커뮤니티에 강사나 멘토로서 기여하고 있다.
김선구, 장미연, 이은아/ HOONS닷넷
HOONS닷넷에서 익스프레션 시삽을 맡고 있으며 익스프레션 기술 보급에 힘쓰고 있는
디자이너들이다. 이들이 익스프레션 툴과 함께하는한 익스프레션의 미래는 밝을 수밖에 없다는 것이 그들의 전망이고 또한 그렇게 되기
위해서 밤낮으로 노력하고 있다.
몇몇 컴퓨터 전문가의 전유물이었던 CUI(Character based User
Interface)를 기억하십니까? 커멘드라인에서 키보드 만을 두드려서 명령을 입력하는 방식이 이제는 마우스를 이용하는
GUI(Graphical User Interface) 환경으로 바뀌어 보다 많은 사람들이 컴퓨터를 쉽게 활용하게 되었습니다.
이제 다시 한번 인터페이스의 패러다임이 변하려 하고 있습니다. 일상에서 사용하는 사물 자체가 컴퓨터의 입력이 되고 마우스 없이
맨손으로 컴퓨터를 조작하는 NUI(Natural User Interface)가 서서히 우리 곁에 다가오고 있죠. 디스트릭트에서는
이것을 ‘만질 수 있는 UI’라는 표현을 하고 있습니다. 그 시작점으로 마이크로소프트 서피스라는 테이블 형식의 컴퓨터가
있습니다. 이번 세션에서는 서피스 컴퓨팅에 적용된 ‘만질 수 있는 UI’에 대해서 알아보고 이 기술이 윈도우7에 어떻게 적용될지
알아보겠습니다.
오일석 / 디스트릭트
마이크로소프트 MVP로 실버라이트와 WPF 기술에 관련된 활동하고 있으며 마이크로소프트
UX플랫폼을 활용한 UX 솔루션 확보에 집중하고 있다. 현재 디스트릭트에서 UX 솔루션 2팀을 이끌며 다가올 UX 시대의
주인공을 꿈꾸고 있다.
최영규 / 디스트릭트
디스트릭트(http://dstrict.com)에서 UX 솔루션 개발자로 일하고 있으며 WPF와 Silverlight를 기반으로 사용자의 새로운 경험을 가질수 있는 UX솔루션 개발에 노력하고 있다.
효율적인 UX를 구현하는 방법에 대한 관심은 클라이언트, 웹 환경 뿐만 아니라 TV등의 가전,
임베디드 환경에 까지 날로 확대 되고 있습니다. 본 세션에서는 키보드가 없는 환경에서 Wii Remote 만으로 조작할 수 있는
WPF 3D 기반의 웹 브라우저 제작을 통해 다양한 환경에서 사용성을 높일 수 있는 방법에 대해 함께 생각해보고자 합니다. 또한
3D 웹브라우저의 제작에 이용된 Wii Remote 제어와 제스쳐 인식 그리고 상호운용성을 개선할 수 있는 방법 등의 기술적인
노하우도 전달해 드릴 것입니다.
김영욱 / 닷넷채널
국내 유수의 대기업 프로젝트에 참여했던 풍부한 경험과 마이크로소프트 MVP로서 다양한 활동을
바탕으로 WPF및 Silverlight와 같은 UX기술에 전념하고 있다. 현재 한국마이크로소프트에서 개발 전도사로 활발히
활동하고 있다.
양승철 / UX베이커리
UX개발자 / 디자이너를 위한 커뮤니티인 UXBakery 에서 커뮤니티의 대표를 맡고 있다.
Microsoft Devdays 2008 및 커뮤니티 스터디에서 WPF와 관련된 강의를 진행해 왔으며 현재는 이 신생 커뮤니티
키우는 재미에 흠뻑 빠져있다.
전현상 / UX베이커리
UXBakery 커뮤니티의 운영진으로 참여하고 있고, 커뮤니티와 MS주최의 컨퍼런스에서
WPF, Silverlight 기술과 관련된 강의를 진행해왔다. 지난 2년간 WPF 관련 상용 프로젝트의 참여 및 삼성
소프트웨어 멤버십에서 진행해 왔던 연구로 얻은 지식을 공유하기 위해 노력중이다
한번 알바나 할까 봤더니 기존 계약된 회사들만 사용하던
API를 일반에 오픈하고 거기서 더 확장한 개념이더라.
SDK 구성을 보면
Widgets(Veloxsoft,유비벨록스) - 화면에 떠있는 위젯 개발)
WIPI(Innoace) GNEX(신지소프트 - Mobile C라는 언어. AnsiC에서 필요한 부분만 빼고 이벤트 방식으로 바꿈, SKT에서만 지원됨)
-> WIPI로 개발하자.
COGP(Innoace -Cross Over Game Platform)
-> 기존 소스에 COGP플랫폼을 추가시켜 다른 기기에서 그대로 사용할수 있게 변환
MUIF(Innoace - Multimedia UI Framework) -> 플래시,블렌드처럼 UI를 꾸미고 WIPI로 내부 로직을 꾸밀수 있음, 크로스 플랫폼 지원
개발자와 디자이너의 협업이 가능. UX
SKAF(SK Application Framwork)
-> Trolltech의 Qt와 같은 일을 하는 UI 및 이벤트처리를 위한 표준화 라이브러리라고 보시면 됩니다.
개발시 개발툴들은 거의다 제각각이다. 다행인건 대부분 VC6과 비슷하거나 VC6과 연동된다는거다.
개발시
WIPI,GNEX(로직)와 MUIF(UI)로 개발해서 핸드폰을 지원하고
WIPI,GNEX만 COGP로 모바일(스마트폰) 기기로 변환 하면 된다.
물론 위 내용은 WIPI에 익숙한 개발자나 핸드폰까지 지원할 개발자들의 이야기이고
아직 확정된 정책은 없지만 모바일(PDA) 프로그램까지 포함하는 범위이니
저 SDK가 아닌 Windows Mobile용으로 만든 어플도 올릴수 있다.(4월 22일 수정)
WIPI를 오픈마켓의 유일한 플랫폼으로 지향하는 것은 아닙니다. 이는 정책발표회 내용을 보셔도 아실 수 있을 거구요. 저희도 애플리케이션 오픈마켓의 중추는 열린 구조를 갖고있는 스마트폰 기반이 될 것이라 생각하고 있습니다.
현재 명B님을 포함해 많은 분들께서 "SKT가 너무 WIPI에만 focus하는것 같다"는 의견을 주고 있으신데요, 이는 플랫폼전환의 과도기에서 드러나는 현상으로 보아주시면 될 것 같습니다.
http://developer.itopping.co.kr/board/1700
아직..
일반 모바일(PDA)용 프로그램도 올릴수 있는건지는 정책에 대한게 확정 된게 없단다.
일반 모바일용 프로그램은 올릴 수 없고 저 SDK로 개발된 프로그램만 올릴 수 있다는 전제라면.
이게 과연 성공할까?
오픈마켓의 성공여부가 아니라.. 개발자 입장에서. 기존에 그쪽에서 일하던 업체들 말고
일반 개발자들이 이쪽에 그렇게 많이 관심을 가질지.. 또 괜찮은 프로그램들이 많이 나올지가 궁금하다.
기존처럼 게임만 계속 나오는거라면 기존에 만들던 회사들이 당연히 유리할 것이고
겉으론 비슷해보여도 애플의 앱스토어랑은 전혀 다른 성격이 되버릴테니까..
그냥 게임만 파는.. 게임만 개발하는 사람들만 모이는 모바일 마켓?
KTF쪽도 가만 있을것 같진 않은데 그쪽은 어떤 대응을 할까?
오픈 마켓이 우리나라에서도 성공했으면 좋겠다.
비록 처음부터 몇백 몇천을 벌순 없다해도 소프트웨어의 인식이 조금이라도 바뀌었으면 하는 바램이다.
머.... 음악
이론을 잘 알아야한다.... 감각이 있어야한다....열정이 있어야한다.....
땡땡땡... 다 틀렸습니다.
좋은 음악을
만들기 위한 조건들중 가장 중요한것은 그것들이 아닙니다.
음악 이론 많이 몰라도 좋은 음악은 만들 수 있습니다.
감각이
없어서 이론적으로나마 좋은 음악은 만들 수 있습니다.
열정이 없어도 핑핑 놀아가며 하기 싫은거 억지로 해서라도 좋은 음악은 만들수
있습니다.
그런데 꼭 필요한게 있습니다.
그것은....
좋은 음악을 들었을때...... '아~ 좋다~'
라고 느낄수 있어야한다는 겁니다..
좋은 음악을 듣고 좋은지 모르는 사람은 절대로 좋은 음악을 만들 수는
없습니다.
좋은 소프트웨어를 만들려면 좋은 소프트웨어를 봤을때 '우와~ 좋다~'라고 느낄 수 있어야합니다.
좋은 음악과
좋은 소프트웨어를 보고 느낄수 있는것은 그냥 저절로 되지는 않습니다.
많이 경험해
봐야합니다.
두번째 이야기...
한강에 벽돌을
쌓습니다.
강변이 아니라 강 바닥에 벽돌을 쌓습니다.
아시다시피 한강물이 썩 깨끗하지는 않습니다.
강 바닥에 벽돌을 쌓는것은 생각보다 어렵습니다.(물론 전
안해봤습니다. ^^)
그냥 헤엄치는것도 어려운데 한손에 벽돌을 들고 가야합니다.
좌우지간 갔습니다.
강바닥으로 내려가서 벽돌을 놓고 나옵니다.
나와서 보니 어떤가요?
기껏 쒜빠지게 열심히 했는데....
티도 안납니다.
다음날....
또 벽돌을 들고 헤엄쳐서 어제쌓은 벽돌 위에 한장 더 올려놉니다.
역시나
힘듭니다.
또 나와서 보니.... 이젠 허탈하기까지합니다...
두장이나 쌓았는데.... 역시나 티도
안납니다.
사흘...
나흘....
맨날 맨날 똑같은 짓을 해도.... 맨날 맨날
똑같습니다.
나는 정말 매일 매일 열심히 했는데... 아무리 쌓고 쌓아도 할때만 열심히 했지 나와서 보면 안보이기는
마찬가집니다.
이정도 되면 정신적으로 힘들어집니다.
이걸 계속 해야하나...하는
생각도듭니다.
그래서....
포기합니다............
에잉 확~ 쒜려 챠뿔쟈.... 하고
관둡니다.
그러면? 그걸로 끝이지요..... 머... 더 설명할것도 없습니다. 그냥
끝입니다.
그러나.....
포기하지 않고 계속 한다고 칩시다....
열흘, 한달, 일년,
이년.....
에잉 모르겠다.... 이거나 하나가 죽자....라고 생각을하고 맨날 맨날 똑같은 짓을
합니다....
그러면?
보이지 않는 벽돌이 쌓이고 쌓여서....
언젠가는 수면으로 떠오릅니다.
그때가 되면 벽돌을 한장 쌓으면
한장 쌓이는게 눈에 보입니다..
내 눈에만 보이는게 아니라 남들에게도 보입니다.
지금까지 힘들었던게 다
잊혀집니다.
그런데 사람들은 그걸 못참고 때려치웁니다.
열심히 쌓고 쌓으면 언젠가는
올라올텐데....
단지, 사람마다 수심이 조금씩 다를뿐인데.....
벽돌이 수면위로 올라오면 그때부터는 물속의 별돌을
다시 한번 살펴볼 필요가 있습니다.
남들에게는 안보이는 자신만이 아는 자신.....
기초를 든든히 해야 더 높이
올라갈수 있습니다.
개발을 하는 일도 .... 모든 학습을 하는 일도 다 똑같다고 봅니다.
포기하지 않고 열심히
하다보면 언젠가는 되기 시작합니다.
그때까지만 참고 열심히 합시다....
아... 이 얘기는 제 얘기가 아니라
고등학교때 읽은 허영만作 만화책에서 본 내용입니다. ( 참 유익한 만화져? ^^ )
세번째
이야기...
이 이야기는 저에게 '프로그래먼데 너무 힘들다. 실력도 없고...다른 직업을 알아봐야하냐' 라는 그런
내용의 메일을 보내온 분들께 공통적으로 해드린 이야기입니다.
제가 프로그래머가 된 과정을 그린 이야기인데... 머... 솔직히
쪽팔립니다만...이젠 하도 많이해서 ^^;;
자 그럼 이메일의 일부분 나갑니다.
시~ 작~
제가 29살 때의 이야기를
해보겠습니다.
전 29살 3월에 결혼했습니다.
그전에는 인켈에 7년간 오디오엔지니어로 다니다가 그만두고 인켈의 하청업체에 1~2년 다니다가 다시 유사한
전자쪽의 작은 업체를 다니다가 ... 머 그럴때였습니다.
전자쪽 직업을 가지고 있으면서 한가지 불만이 있었는데 임근이 너무 박하는거 였습니다.
당시의 "내"가 임근이 짠건 견딜만 했는데 그 바닥에서 정말 열심히 일했던 선배들이 임금이 박한건 정말 견디기
힘들었습니다.
왜냐면 그 사람들이 내 인생의 모델인데... 그 사람들이 어렵게 산다는것은 곧 나의 미래가 어렵다는것과
같기때문입니다.
그래서 언젠가는 직업을 바꿔야겠다고 생각하고 있었는데..
그러다가 29살에 결혼을 해버렸습니다.
결혼을하면 직업을 바꾸기가 더 힘들어지지요... 게다가 아내는 임신을하고....
해서리.... 애가 태어나기전에 바꾸자...... 라고 마음을 먹고....
그때부터 회사를 과감히 그만두고 델파이만 붙잡고 씨름을 했습니다.
당시에는 비디오 대여점이 뜰때였는데..... 그래서 비디오 대여점 관리 프로그램을 만들자라고 마음을 먹고 열심히
했습니다.
거짓말 안하고 정말로 10개월동안을 아무것도 안하고 코딩만 했습니다.
거의 책에만 의존하면서 했지요...
물론 벌이가 없으니 집안 꼬라지는 말이 아니고 그 와중에 애도 태어났는데.....
애 분유값을 대기도 정말 힘들었습니다.
한번은 한겨울이었는데 석유살 돈이 없어서 전기장판을 사서 애를 가운데 놓고 잤습니다.
그렇게 전기장판 생활을 하던중 어느날...
잠을 자다가 문득 깨보니 중간에 애가 없는거 였습니다.
벌떡 일어나서 보니 애가 저 위에 머리맡에 방바닥에서 자고 있었습니다.
물론 냉골이지요.... 애를 전기장판으로 옮기려고 보니 열이 나더군요....
애가 거의 실신 상태였습니다.
급히 119를 불러서 응급실로 실려가던.... 그런일도 있었습니다.
병원에 다녀와서는 어케든 보일러를 가동해볼려고 했는데 .....
돈도 없고 한밤중에 석유파는데도 없고 ....
간신히 간장파는 가게에서 간장통을 얻어다가 주유소에 가사 사정사정해서 석유를
얻어왔습니다...
그 석유가 일주일이 가더군요 ^^;;;;
암튼 당시에는 그랬습니다.
다행히도 장인어른께서 농사를 지으셔서 쌀은 있었습니다.
밥하고 김치만 먹고 살았지요... --;;
그러던중 이제는 더 이상 견디기 힘들어서 부랴부랴 비디오 대여점 프로젝트를 마무리하고 통신망에
올렸습니다.
당시에는 인터넷이 거의 안쓰일때였고 하이텔, 천리안, 나우누리에 올렸습니다.
그리고서는 아내에게 "자기야 조금만 기다려... 이거 팔아서 우리 나래 분유값이라도 벌어볼께..." 하며
...... (에혀....... --; )
암튼...
그랬는데 어케된일인지 한달이 지나도 전화 한 통 안옵니다. 정말 막막하더군요....
아내도 나도 이것만 믿고 견뎌왔는데....
하이텔로 메일이 하나왔습니다.
"당신이 만든 프로그램 잘 봤다... 그런데 당신은 프로그램은 잘 만드는데 비디오 대여점에 한번 앉아보지도 않고
만들었다" 라고 하더군요....
맞습니다.. 그냥 테이프 빌려주고 돈받고 돌려받고 그러면 되는 줄 알았지요....
정말 절망적이더군요....
다시 예전의 직업으로 돌아가야하나...
난 프로그래밍을 할 수 없다는 말인가...
정말 많은 생각을 했습니다.
해서 생각한것이.... 포기하고 그것을 디스켓에 넣어서 이력서를 써서 돌아다녔습니다.
팔아먹지는 못해도 프로그램을 만들수 있다는 증거는 될수 있으니깐요.....
그렇게 한달동안 매일 몇군데씩 다녔는데....
나이도 30인데다가 결혼에 애도 있고... 경력은 하나도 없고... 전공한것도
아니고.....
에혀.... 나라도 나같은 사람을 써줄리 없었습니다.
그러던중 여의도에 있는 한 업체에서 "당신의 그 무모한 용기가 가상하다"라는 이유로 --; 취업이
됐습니다.
첫월급 70만원.....
마누라랑 그 봉투 붙잡고.... 엉엉.....
에혀.....
그렇게 저의 본격적인 프로그래머 인생이 시작되었습니다.............
그러다가 하이텔 동호회였던 델마당에서 활동도하고.....
정말 열심히 했습니다...... 머... 다른 사람보다 한참 늦었으니 열심히 하는수 밖에
없었지요.....
그러다가 몇몇 기업에서 스카웃도 되가고.....
지금은.....
먹고 살만한 정도 프리랜서로 활동하고 있습니다.
이제부터....
제가 견딜수 있었고 이만큼 성잘할수 있었던 나름대로의 비결을 이야기해 보겠습니다.
첫째......
프로그래머는 자기만의 꿈이 있어야합니다.
큰 꿈을 항상 간직하고 있어야합니다. 지금 직장 생활을하고 고생을하는것은 그 꿈을 이루기 위해서 필요한 지식과
경험을 만들어 가는 과정입니다.
게임프로그래머라면 리니지나 스타크래프트 이상으로 히트할 수 있을만한 게임을
기획하세요....
지금부터요.... 물론 1~2년안에 완성할만한 간단한거 말구 정말 물건같은 물건을 기획해보세요.....
지금은 못만들더라도 지금부터 그것을 완성시킬수 있을만한 지식과 경험을 쌓아가세요...
그러다보면 언젠간 머릿속에서 이제 시간과 돈과 사람만 있으면 할수 있겠다...라는 판단이 들때 그때 실천에
옮기세여....
암튼.... 꿈이 있어야합니다.
첨부한 그림을 한번 보세요... 제 노트북 바탕화면입니다.
예전에 TV에서 방영하던 전격z작전에 나오는 자동차 "키트"입니다.
전 오래전부터 바로 저 차에 들어가는 소프트웨어를 만드는게 꿈을 갖고 있습니다.
물론 자동차용이아니라 일반 생활용이지요.... 말을하고 판단을 하고 알아서 처리해주는...... 인공지능 +
자연언어처리 + 학습 ... 머 그런겁니다.
이 꿈을 가지면서부터 지금까지도 모든 프로젝트를 할 때에 나의 꿈을 이루기 위해서 필요한 지식과 경험을
쌓는다라고 생각하며 일하고 있습니다. 물론 그 꿈은 진짜 꿈이고 언젠가는 코딩을 시작할겁니다.
직장생활을 하면서도 일처리.. 그리고 사람들과의 관계... 그 모든것들도 다 나의 꿈을 이루기위해 필요한
단체경영 방법을 배운다라고 생각하고 있습니다.
둘째......
프로그래머는 물건을 만드는 사람입니다......
건물을 만드는 사람이지 벽돌을 나르는 사람이 아닙니다.
어떻게 만들지도 중요하지만 뭘 만들지가 더 중요합니다.
프로그래머는 항상 머리속에 "방법"보다는 "대상"이 그려져 있어야합니다.
다시말해서 어떤 기능을 수행할수 있는 기술을 배우는데 모든 정력을 투자하지 말아야합니다.
물론 기술은 당연히 가지고 있어야합니다. 하지만 기술 자체가 목적이 되어서는 안됩니다.
기술이 아니라 물건에 항상 관심을 가지고 그 물건을 만들어 내기 위해 필요로 하는 기술을
배워야합니다.
프로그래머는 소프트웨어를 만드는 사람이기때문에 모든 소프트웨어를 평가할수 있는 자질이
있어야합니다...
제가 자주하는 이야기인데 좋은 음악을 만들기 위해서 필요로하는 첫번째 조건은 좋은 음악을 들었으때...
"아~~ 좋다"라고 느낄수 있어야합니다... 그래야 자기도 좋은 음악을 만들수 있습니다.
창의력을 요하는 모든분야의 일이 다 그렇습니다.
프로그래머도 마찬가지지요 모든 프로그램을 비평할수 있어야.. .좋은 물건을 만들수
있습니다.
그럴려면 소프트웨어, PDA, 핸드폰등 최첨단 IT기기에 민감하게 반을할 필요가있고 세상 돌아가는 일에도 관심을
가져야합니다.
세째.....
아이디어는 자기가 구현 할수 있는 기술의 범위 안에서 나옵니다.
둘째 이야기하고는 상반되는 말인데..... 둘째 이야기가 프로그래머로써 소프트웨어 프로젝트의 기획능력을 말한다면
세째는 기술에 관한 이야기입니다...
자기만의 좋은 물건을 만들려면 아이디어가 상당히 중요한데 아이러니컬하게도 엔지니어의 머리에서 나오는 아이디어는
그 엔지니어가 스스로 구현할수 있는 기술의 범위내에서만 나옵니다. 그러므로 프로그래머가 많은 아이디어를 배출해 낼려면 많은 분야의 기술을
습득하고 구현할 수 있어야합니다.
여기까지...끝...
정리....
자...
잔소리는 그만합시다... ^^;;
머... 결론은 목표를 가지고 열심히 하자는겁니다. ^^;;
현대의 프로그래밍은 OOP가 필수적입니다.
그냥 객체가 아니라
살아있는 객체를 디자인하고 구현할수 있는 사람이 제대로 된 물건을 만들고 그렇게 될때 자기가 목표로하는 꿈을 이룰수
있을겁니다.
음....
대한민국에 소프트웨어 업계는 아직도 희망이
있습니다.
왜나면....
불법 사용률이 짱 높기 때문이죠....
정품 사용률이 높음에도 불구하고 지금처럼
힘들었으면 그건 정말로 어려운겁니다.
그러나....
아직 사람들은 소프트웨어를 위해서 돈을 꺼내지 않고
있습니다.
정부와 기업과 사용자들간에 좋은 방안은 연구해보고 서로 서로 노력하여 정품 사용률이 높아질때....