Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

April, 2010

  • Korea Evangelist

    아키텍트 저널 그리고 소프트웨어 아키텍트란…

    • 0 Comments

    올 해는 글을 좀 열심히 써보겠다고 큰 소리친 바 오랩니다. 그런데 그 변명 거리를 마련하는데 또 두어달을 훌쩍 건너 뛰어 쉬었습니다. 그 사이 여러 사람의 노력으로 차곡 차곡 준비해 온 “아키텍처 저널 위키, http://www.architecturejournal.org/wiki“의 4/5월 읽을 거리를 미리 알립니다. 이런 애씀이 얼마나 많은 사람에게 얼마나 큰 도움이 될런지는 모를 일입니다.

    어쨌거나 좀 더 널리 읽히라고, 위키에 뭉쳐 올린 글은, 여기 블로그에도 알맞은 크기로 나누어 올리고 있습니다. 따라서 앞으로 읽을 거리와 생각할 거리와 공부할 거리는 차족 차곡 풍성해지겠지요. 올 가을 츰에는 알찬 수확을 조심스레 기대해 봅니다.

    image 그나저나 우리나라 소프트웨어 분야에 ‘아키텍트’란 사람들이 정말 있기는 한 것일까요? 국내 이 분야에서 만나는 사람마다, “열악하다, 척박하다” 소리를 너무 연거푸 들어서 그런지 정말 그런 일을 하는 사람이 있는 지 확신을 가지기가 어렵습니다. 아키텍처 위키를 준비하면서도 <누가 읽으라고?>란 질문에 끝없이 자문 자답하여 고민을 거듭 하던 것이지요.

    누구도 답을 내기는 어려운 문제입니다. 명함에 아키텍트라고 찍힌 직함을 많이 본다고 하여 모두 아키텍트라고 할 수도 없는 노릇입니다. 남 탓 할 것도 없이, 그냥 ‘구성도’라고 하면 될 수준 정도의 그림 제목에 ‘아키텍처’란 이름을 달면서 겉멋을 부리고 있는 저 자신의 모습부터가 마음에 거슬리니까요.

    그래서 4, 5월의 작은 개편에 맞추어 “아키텍처”란 무엇인가 “왜 아키텍처 저널”을 만들려고 했는가에 대한 아주 짧지만 마음 속에 담긴 글을 적어서 http://www.architecturejournal.org/wiki/Korea_Architecture_Journal:About 여기에 올려 보았습니다. 짧기도 하고 거칠기도 한 글이지만 조심스레 여기도 인용해 봅니다.

    소프트웨어 (또는 IT) 아키텍트는 소프트웨어 분야의 대목장(大木匠)입니다. 소프트웨어 아키텍트는, 큰 집을 짓는 대목장처럼, 스스로 지어야 할 집의 쓰임새를 또렷이 알고, 집이 들어설 곳에 어떤 힘이 미치게 될 지를 꼼꼼히 살펴서, 알맞은 집짓기 방법을 세울 줄 압니다. 집을 이루는 모든 재료의 성질을 잘 알고, 스스로 밝힌 집짓기 방법에 가장 알맞게 재료를 손보는 방법을 고를 줄 압니다. 실제로 오래 동안 손수 익히고 갈고 닦은 집짓기 경험을 간추려서, 집을 짓는 데 들어가는 기술과 돈과 사람 모두를 한 데 엮을 줄 알아야 비로소 대목장 곧 아키텍트란 말을 들을 자격이 있습니다. 거기에다 앞으로 보태질 쓰임새 까지 미리 그려보고 누구에게나 쉽게 풀어 이해시킬 줄 아는 힘을 갖추기까지 하였다면 더 말할 나위 없이 맞춤이라 하겠습니다.

    따라서 아키텍트는, 집짓기를 부탁한 사람의 바람을 알고 그 바람을 이루기 위해 풀어야 할 문제를 잡아내고 해석하여 이를 기술과 돈과 사람의 일로 통역하는 일을 해야하는 사람입니다. 이러한 대목장의 힘은 오래도록 꾸준히 읽기/나누기/생각하기를 되풀이 하지 아니하면 갖추기가 어렵습니다.

    이 곳(한국 아키텍처 저널,"Korea Architecture Journal")은 말 그대로 우리 나라 소프트웨어 대목장들과 그런 대목장으로 커가고자 하는 바람을 가진 이들에게 "(그냥 한글이 옮겨 적은 것이 아닌)우리말로 적힌" 배울 거리와 나눌 거리를 올려 놓고 널리 함께 하고자 하는 뜻으로 만들었습니다.

    2009년 말 쯤에 시작되어, 지금까지는 마이크로소프트에서 일하는 몇 사람이 새로운 기술과 산업의 흐름을 나름대로 해석하고 스스로의 의견을 널리 퍼뜨리는 목적으로 쓰이고 있습니다만 여러 분야 여러 조직의 "장이"들의 뒤섞여서 어느 한 쪽으로도 치우치지 않는 "깊고 넓은 이야기 마당"으로 자라나기를 진심으로 바라고 있습니다.

    또한 지금은 일부러 아무나 계정을 만들 수 없도록 막아 놓았습니다만, 곧 진정으로 이 일을 함께 하시기 바라시는 분은 누구라도 속해 있는 회사, 연령, 직위 그 무엇도 가릴 것 없이 그러한 즐거움 나눌 수 있도록 하는 길을 마련해 보도록 하겠습니다.

    { 물론 “Unix 골수 쟁이 …”과 “그냥 기술 이야기…”도 차차 이어가도록 해야겠죠. :) }

    2010년, 아들 둘 아빠가 되고만 4월에 … 

  • Korea Evangelist

    C# 4.0 뭐가 달라졌을까요?

    • 0 Comments

    C# 4.0이 정식으로 나온지도 벌써 1주일이 넘어갑니다.
    해외에서는 관련된 글들이 괘많이 나오고 있는데 국내에서는 상대적으로 많이 없습니다. (아~ 이래서 영어를 꼭 공부해야만 하는 것일까요?)
    C# 4.0에 대해서 다음과 같이 정리하는 글이 있어서 소개해 드립니다.
    1. Dynamic
    2. Convariance and Contravariance
    3. Optaionl Parametes.
    4. Named Arguments.
    5. Improved COM interop.
    자세한 글은 다음의 링크에서 보실 수 있습니다.
    http://blogs.msdn.com/csharpfaq/archive/2010/04/12/get-ready-for-c-4-0.aspx


    개발자를 위한 IT블로그 영욱닷컴(http://www.YoungWook.com)

  • Korea Evangelist

    [아키텍처 저널 번역] 21권 소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항 #1/3

    • 0 Comments

    image

    지난 번에 올렸던 "엔터프라이즈 소셜 컴퓨팅"은 현재 MSDN 싸이트에 공식적으로 번역물로 기재되었고  PDF 버전의 번역물 다운로드 링크도 추가되었다.

    아키텍처 저널 19권의 한글 MSDN 싸이트는 아래와 같습니다.
    http://msdn.microsoft.com/ko-kr/aa699428.aspx
    "엔터프라이즈 소셜 컴퓨팅"의 한글 번역 MSDN 싸이트는 아래와 같습니다.
    http://msdn.microsoft.com/ko-kr/aa699425.aspx

    이번 포스트는 아키텍처 저널21권에 수록된 "소프트웨어 + 서비스 및 클라우드 컴퓨팅을 위한 설계 고려 사항"이라는 아티클 번역물에 대한 것으로 여러분의 피드백을 기다립니다. 조금 길어서 세번에 걸쳐 리뷰가 끝나는 대로 포스팅을 진행하도록 하겠습니다.

    ------------------------------------------------------------------------------

    요약

    이 문서는 S+S(Software plus Services), 클라우드 컴퓨팅 또는 하이브리드 컴퓨팅으로 일컬어 지는 차세대 애플리케이션의 설계 패턴에 대한 Microsoft의 생각을 공유하기 위해 작성되었다. 여기에는 기업, 소프트웨어, 인프라 아키텍처 등 일반 아키텍처 도메인에 영향을 주는 S+S 아키텍처의 고려 사항과 패턴에 대한 견해가 실려 있다.

    서론

    많은 기업들이 체계적인 마스터 플랜을 따르기 보다는 그때그때의 요구사항에 맞춰 몸집을 키우는 IT 인프라를 보유하는 쪽을 선택한다. 이런 방식으로 확장된 기업 시스템은 강력하게 서로 결합되거나 혹은 완벽하게 분리된 여러 하위 시스템["사일로(Silos)" 시스템으로도 불림]으로 구성된 대형 모놀리식(monolithic) 구조체로 변하는 경향이 있다. 일반적으로, 이러한 시스템은 난해하고 일관되지 못한 인터페이스를 가지고 있으며 복잡하고 효율성이 떨어지기 때문에 비즈니스 혁신 속도가 느려진다. 이로 인해, IT 관리자는 정보 기술을 통해 어떻게 하면 핵심 비즈니스를 지원할 수 있을까에 집중하기 보다는 운영 및 장애 제거 프로세스에 더 많은 시간을 보내게 된다. 게다가 일부 기업의 IT 시스템은 기능면에서 부분적으로 중복되기 때문에 비즈니스 정보에 대한 뷰 자체가 단편적이고 일관되지 못하게 되어, 결국 기업의 재정 지출에 대한 합리적인 의사 결정에 영향을 끼친다.

    S+S(Software plus Services)는 SaaS(Software as a Service)의 확장 형태로서 조직이 비즈니스를 영위하는데 필요한 기술의 개발, 관리, 배포 및 운영 측면에서 더 많은 아웃소싱 옵션을 제공한다. S+S는 서비스 지향 아키텍처(SOA)의 원칙을 따른다. S+S는 애플리케이션 소프트웨어 및 서비스의 소싱, 파이낸싱, 배포와 관련된 다양한 방법을 제공하기 때문에, SOA를 지원하는 기업에서는 기술 선택의 폭이 넓어졌다. 합리적인 의사 결정을 내리고 S+S 모델을 채택함으로써 얻을 수 있는 잠재 혜택을 극대화하기 위해서는, IT 아키텍트와 의사 결정권자는 사내외에 존재하는 경제적, 규제적, 정치적, 재정적인 요인보다는 비즈니스 동인과 기술적 요구 사항에 중점을 두어야 한다.

    이 문서는 Microsoft Worldwide Services 컨설팅 조직이 S+S와 클라우드 기반 애플리케이션을 설계, 이관하는 과정에서 경험한 실제 사례를 근간으로 하고 있다. 또한, 기업, 소프트웨어, 인프라 아키텍처 등 일반적인 아키텍처 도메인에 영향을 미치는 S+S 아키텍처의 고려 사항과 패턴에 대한 견해가 나타나 있다.

    SOA, S+S, 클라우드 컴퓨팅

    2000년대 중반, 복잡한 IT 인프라 구조가 넘쳐나던 기업에 분별력을 제공하기 위해 다양한 SOA 사례가 소개되었다. 그 이후, 업계에서 가장 큰 인기를 끌던 SOA는 점차 주류에서 밀려나고 최근에는 “SOA는 죽었다”는 말까지 나오고 있다. 하지만 SOA가 오늘날까지도 지속되고 있는 중요한 패러다임의 변화를 이끌었다는 사실에는 변함이 없다.

    기술적인 측면에서 SOA의 핵심적인 영향력은 바로 일련의 SOA 원칙, 패턴 그리고 분석 프로세스들이다. 이들을 활용하여 기업은 IT 포트폴리오에 대한 인벤토리를 작성하고 리팩터링을 진행하여 일상적인 비즈니스 운영 작업을 지원하는 모듈화되고 핵심적인 서비스 기능으로 변모시킬 수 있다. SOA의 주요 목표는 비즈니스 목표에 맞춰 기업의 IT를 재구성하고(align) 비즈니스 요구에 IT 부서가 보다 민첩하게 대응할 수 있도록 지원하는 것이다. IT 솔루션의 민첩성 강화를 위한 SOA의 몇 가지 주요 원칙으로는 느슨한 결합(loose coupling), 관심 분리(separation of concerns), 표준 기반 기술 및 대단위(coarse-grained) 서비스 설계가 있다.

    그림 1. SOA, S+S, 클라우드 컴퓨팅을 통한 IT 최적화

    aa699437_a1f1(en-us,MSDN_10)

    SOA는 기업이 주요 서비스 기능을 식별하고, 비즈니스와 IT간 연계를 구축해 민첩성을 유지하도록 지원하는 반면, S+S는 사내에 배포된 클라우드 컴퓨팅 및 솔루션을 통해 IT 투자를 최적화할 수 있는 컴퓨팅 모델을 제공한다. 그러나 S+S는 SOA의 필요성을 없애는 것이 아니라 SOA를 지원하는 기업이 애플리케이션 소프트웨어 및 서비스를 소싱, 파이낸싱, 배포할 수 있는 여러 모드를 구축함으로써 기술 선택을 최적화할 수 있도록 도와준다.

    그림 1은 SOA, S+S 및 클라우드 컴퓨팅 스택 관계를 나타낸다.

    일반적으로 모든 조직에 적용할 수 있는 단 하나의 올바른 IT 포트폴리오가 있는 것이 아니기 때문에, 조직에 무엇이 가장 적합한가는 현재의 비즈니스 목표와 요구 사항에 달려 있다. 따라서 S+S 컴퓨팅 모델은 비용, 핵심 업무와의 관련성, 사용자 경험 및 혁신 가치, 비즈니스 차별성 등의 의사 결정 필터에 따라 특정 기술을 선택해 기업이 IT 포트폴리오를 최적화할 수 있도록 지원한다. S+S는 사업장내 (on-premises) 소프트웨어의 장점(예: 짧은 대기시간 및 풍부한 기능)과 클라우드 컴퓨팅의 장점(예: 유연한 확장성 및 아웃소싱)을 결합시켜 효과적인 하이브리드 분산 아키텍처 설계를 위한 보다 다양한 선택옵션을 제공한다.

    클라우드 컴퓨팅은 제공되는 서비스를 집합적으로 지칭하는 말이다. 현재 클라우드 컴퓨팅은 아래와 같은 벤더의 솔루션을 포함한다.

    * IaaS(Infrastructure as a Service). IaaS는 일반적으로 동적 확장이 가능하고 가상화된 계산 및 저장소 리소스가 서비스 형태로 제공되는 컴퓨팅 환경이다. 이 서비스는 서버 및 저장소 장치와 같은 하위 수준의 하드웨어에 대한 투자 요구로부터 서비스 고객 수를 산정한다.

    * PaaS(Platform as a Service). PaaS는 서비스 고객에게 운영 체제와 애플리케이션 플랫폼 수준의 추상화를 제공한다. 또한, 단일 시스템 상의 다중 고객 지원 (multitenant) 환경에서 고객별 요청 처리 시간을 스케줄링하고, 메모리 공간을 할당하고, 시스템과 애플리케이션의 무결성을 보장할 수 있는 시스템 리소스 관리 기능을 제공한다. 서비스 고객은 PaaS 애플리케이션 개발 도구를 사용하여 호스팅 플랫폼에서 실행되는 클라우드 애플리케이션을 구축할 수 있다.

    * SaaS(Software as a Service). SaaS는 타사 서비스 공급자에 의해 호스팅되는 비즈니스 및 소비자 애플리케이션을 의미한다. 서비스 고객은 웹 브라우저 또는 데스크톱에 설치된 애플리케이션을 통해 호스팅된 애플리케이션을 사용할 수도 있다. 어떤 경우에는, 기업이 자사의 데이터 및 비즈니스 프로세스와 SaaS 애플리케이션을 통합할 수 있도록 SaaS 공급자가 UI가 없는(headless) 웹 서비스를 제공하기도 한다.

    클라우드 컴퓨팅 솔루션은 기업 관리 인프라를 보완하고 다음과 같은 다양한 이점을 제공한다.
    * 추가 컴퓨팅 및 저장소 용량 등과 같은 리소스를 동적으로 할당하는 기능을 사용해 비즈니스 수요에 따라 IT 지출을 유연하게 조정할 수 있다.
    * 트랜잭션 및 가입 기반 클라우드 플랫폼을 사용하여 막대한 IT 투자 없이도 새로운 비즈니스와 작업 모델을 신속하게 테스트할 수 있는 혁신적인 애플리케이션 솔루션을 개발할 수 있다.
    * 아웃소싱된 솔루션은 모든 IT 자산을 효과적으로 관리 및 운영하는데 소요되는 지속적인 IT 비용과 책임(즉, 기회 비용)을 줄여준다.

    설계 고려 사항

    이 섹션에서는 S+S 기반 솔루션 설계 또는 채택 시 고려해야 할 비즈니스 및 기술적인 이슈에 대한 간략한 개요를 제공한다. 그림 2는 이 문서 구성에 사용된 프레임을 나타낸다. 이 프레임은 특정 아키텍처 관점을 중심으로 구성되었으며 공통 관심사(crosscutting concern)를 식별하여 S+S 전략의 일부로 간주되는 시나리오 유형, 설계 고려 사항 및 패턴에 관한 포괄적인 관점을 제공한다.
    이 정보는 S+S 전략을 채택함에 있어서 전체적인 영향을 평가하는 기준이 된다.

    엔터프라이즈 아키텍처

    엔터프라이즈 아키텍트 역할 가운데 가장 까다로운 것 중 하나는 끊임없이 변하는 비즈니스 요구 사항과 이러한 요구 사항을 일관성있게 충족시킬 수 있는 IT 조직 능력 간에 균형을 유지하는 것이다.

    그림 2. 아키텍처 관점 프레임웍

    aa699437_a1f2(en-us,MSDN_10)

    S+S는 IT 플랫폼, 애플리케이션 또는 애플리케이션(비즈니스) 서비스를 통합하거나, 때로는 아웃소싱하여 운영 비용을 절감할 수 있는 새로운 기술 배포 패턴을 제공한다. 또한, 조직은 S+S를 통해 시스템 전사 통합시 발생하는 마찰을 줄일 수 있다. 때로는 기존 채널들을 결합시키는 것만으로도 기존 비즈니스 관계에 정보 서비스를 제공할 수도 있다.
    엔터프라이즈 아키텍트는 먼저 최상위 수준에서 조직의 핵심 역량을 판단할 수 있는 기준을 마련하고, 어떤 애플리케이션이 이러한 핵심 역량을 지원하고 있는지, 그래서 어떤 애플리케이션이 사내에서 계속 유지해야 하는지 혹은 외부에 아웃소싱 주어야 하는지를 결정할 수 있는 프로세스를 마련해야 한다.

    다음은 몇몇 대규모 조직에서 사용되는 모델이다.
    * 회사에 특화된(proprietary) 미션 크리티컬한 시스템— 회사에 특화된 시스템, 혹은 미션 크리티컬한 시스템, 혹은 경쟁 우위를 제공하는 시스템은 무척 중요하기 때문에 외부(off-premises) 서비스 공급자에게 아웃소싱하기에는 위험부담이 너무 크다고 여겨진다. 따라서 이러한 시스템은 주로 조직내 기존 IT 부서에서 설계, 개발, 운영 및 관리한다.
    * 회사에 특화되지 않은 미션 크리티컬 시스템— 회사에 특화되어 있는 시스템은 아니지만 미션 크리티컬한 시스템인 경우, 개발은 다른 회사에서 할 수 있지만 설계, 운영 및 관리는 조직 내 기존 IT 담당 부서에서 담당한다.
    * 회사에 특화되지 않은 시스템— 표준화된 기능 및 인터페이스를 제공하는 특정 회사에 특화되지 않은 시스템은 서비스 공급자와 적절한 SLA(서비스 수준 계약)을 설정할 수 있는 경우, 클라우드 서비스 공급자에게 아웃소싱하기에 아주 적당하다. 이러한 시스템의 예로는 전자 메일, 일정관리 및 콘텐츠 관리 도구 등이 있다.

    이 모델은 애플리케이션 및 시스템을 평가하는 출발점을 제공한다. 하지만 조직마다 차이점이 존재한다는 사실을 고려해야 한다. 예를 들어, 예산 또는 전문가의 부재로 조직 내에서 핵심 시스템을 효율적으로 관리할 수 없는 경우에는 아웃소싱을 고려할 수 있다. 마찬가지로, 일부 미션 크리티컬한 시스템을 클라우드에 두면 적은 비용으로도 추가 기능을 제공할 수 있어 단점이 상쇄된다. 일례로, 지점 또는 신뢰할 수 있는 파트너는 사내 전용 인프라를 구축하지 않고도 시스템에 접근할 수 있다.

    그림 3. IT 성숙도에 따른 S+S 영향

    aa699437_a1f3(en-us,MSDN_10)

    그러나 단순히 애플리케이션을 외부(off-premises)로 이동시킬 기회를 식별하는 것으로는 충분하지 않다. S+S 기회를 활용하려면 의사 결정권자가 조직의 IT 성숙도를 명확하게 이해하고 있어야 한다. 이러한 이해가 있어야만 IT 인프라와 프로세스를 어떻게 변경해야 S+S 채택으로 얻을 수 있는 비용 절감 또는 ROI(투자 수익률) 극대화와 같은 이점을 실현할 수 있는지 결정할 수 있다.

    그림 3은 IT 성숙도("Enterprise Architecture as Strategy"에 근거한 성숙도 모델1)에 따른 다양한 수준에서 S+S 채택의 용이성을 나타낸 것으로, 조직 성숙도를 판단하지 않으면 예측된 ROI가 부정확할 수도 있다는 것을 보여준다.

  • Korea Evangelist

    4월24일, 윈폰 개발자 스프링 시즌에 여러분을 초대합니다!

    • 0 Comments

    다음 주 토요일, 포스코센터 한국 마이크로소프트에 진행 될 Windows Phone DevDays 2010 Spring Season 에 여러분들을 초대합니다! 이번 행사는 두 번째로 삼성전자 미디어 솔루션 센터 팀과 함께 합니다!  

    특히, 이번 행사는 윈도우 모바일 6.5로 업그레이드된 옴니아2에서 모바일 애플리케이션을 개발하는 방법을 삼성전자 개발팀으로 듣는 시간을 가지고, 윈도우 모바일 6.5 SDK에 대한 상세 분석과 Open GL ES 기반의 Galatea 게임 엔진으로 모바일 게임을 만드는 방법에 대해 알려 드리도록 하겠습니다.

    image

    참석하시는 모든 분들에게 WinMoDev T-셔츠 짧은 티를 드립니다. 또한 그 동안 윈도우 모바일 개발 관련하여 궁금히 여겼던 부분을 전문가에게 직접 물어 볼 수 있는 좋은 기회입니다!

    조기에 마감될 수 있으니 서둘러 여기로 등록해 주세요!

  • Korea Evangelist

    10분만에 모바일과 PC 버전 Twitter 프로그램 만들기

    • 1 Comments

    Silverlight 4를 사용해서 PC버전의 Twitter 프로그램과 Windows Phone 7의 앱을 간단하게 복사, 붙여넣기 만으로 만드는 과정을 보여 드립니다.

    개발자를 위한 IT블로그 영욱닷컴(http://www.YoungWook.com)
Page 2 of 4 (17 items) 1234