'.NET'에 해당되는 글 272건

  1. 2018.11.08 [ASP.NET Core] 최신 버전에서 React+Redux+Javascript+TypeScript 를 사용하는 방법
  2. 2017.01.23 Language Server Protocol, OmniSharp-Roslyn 빌드 오류 해결
  3. 2016.11.16 [ASP.NET Core] Middleware, IHttpModule과 IHttpHandler 마이그레이션
  4. 2016.11.15 [ASP.NET Core] IControllerFactory 설정 및 마이그레이션
  5. 2016.08.09 [ASP.NET] Session state has created a session id, but cannot save it because the response was already flushed
  6. 2016.02.28 ASP.NET WebForm 에서 Dependency Injection 사용하는 방법
  7. 2013.09.24 [마이크로소프트의 몰락] .NET 개발자가 .NET 플랫폼을 떠나는 이유 (53)
  8. 2013.07.04 [TFS] 팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #2 (3)
  9. 2013.06.18 [TFS] 팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1 (2)
  10. 2013.06.13 [VS2012] VISUAL STUDIO 2012 UPDATE 2 한국어 패치 배포
  11. 2013.06.12 [TFS] 팀 파운데이션 서버(Team Foundation Server)의 $tf 폴더의 정체
  12. 2013.06.11 [TFS] 팀 파운데이션 서버(Team Foundation Server) 의 다양한 오류 유형 및 정보
  13. 2013.05.31 [ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)
  14. 2013.05.21 memcached, 분산 캐시를 이용하여 분산 Session 성능 향상 (2/2)
  15. 2013.05.20 memcached, 분산 캐시를 이용하여 분산 Session 성능 향상 (1/2)
  16. 2013.01.13 [TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2] (2)
  17. 2013.01.10 [TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2] (4)
  18. 2012.08.01 [월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며 (1)
  19. 2012.08.01 [월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
  20. 2012.06.06 Windows 8 SDK 에는 이것이 빠져있다? (2)
  21. 2012.03.25 TFS2010, MSDN Virtual Lab: Team Foundation Server 2010, 가상에 환경의 실습해 보자
  22. 2012.03.15 Visual Studio 11, SOLUTION EXPLORER 스마트하게 사용하기 (1)
  23. 2012.03.04 [HowTo] Visual Studio 11, VSX 업그레이드
  24. 2012.03.04 Visual Studio 11, 더욱 똑똑해진 코드 에디터 (1)
  25. 2012.03.04 Visual Studio 11, 검색 기능 강화
  26. 2012.03.04 Visual Studio 11, 프로젝트 호환성
  27. 2012.03.04 Visual Studio 11, Metro Style App 성능 및 품질 관리
  28. 2012.03.04 Visual Studio 11, Metro Style App 디버깅
  29. 2012.03.04 Visual Studio 11, Windows 8 Metro 응용 프로그램 템플릿 지원
  30. 2012.03.04 Visual Studio 11, 그 첫 만남

ASP.NET Core 2.1 또는 그 이상의 버전에서 dotnet new reactredux 템플릿에서 TypeScript 를 지원하지 않는다. 오직 Javascript 템플릿만 지원한다. 본 내용에서는 React+Javascript 를 React+TypeScript+Javascript 를 지원하는 환경으로 구성하는 방법을 알아본다.

1. 프로젝트 생성하기

다음의 명령을 입력하여 ASP.NET Core 의 React+Redux 프로젝트를 생성한다.

dotnet new reactredux -o aspnetcore-react-redux

프로젝트 생성이 성공하였다면 cd aspnetcore-react-redux 디렉토리로 이동한다.

2. package.json 파일 업데이트

ClientApp 디렉토리는 React+Redux 보일러플레이트가 설치된 경로이다. cd ClientApp 디렉토리로 이동한다.

ClientApp 디렉토리에 있는 package.json 파일에는 Spa 웹에서 사용할 npm 패키지를 설정할 수 있다. 이 파일을 열어 다음의 패키지를 추가한다.

package.json 파일

{
  "name": "aspnetcore_reactredux_typescript",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "bootstrap": "^3.3.7",
    "react": "^16.0.0",
    "react-bootstrap": "^0.31.5",
    "react-dom": "^16.0.0",
    "react-redux": "^5.0.6",
    "react-router-bootstrap": "^0.24.4",
    "react-router-dom": "^4.2.2",
    "react-router-redux": "^5.0.0-alpha.8",
+    "react-scripts": "1.0.17",
    "redux": "^3.7.2",
    "redux-thunk": "^2.2.0",
    "rimraf": "^2.6.2"
  },
+  "devDependencies": {
+    "react-app-rewired": "^1.6.2",
+    "react-scripts-ts": "^3.1.0",
+    "typescript": "^3.1.6",
+    "@types/jest": "^23.3.9",
+    "@types/node": "^10.12.2",
+    "@types/react": "^16.0.0",
+    "@types/react-dom": "^16.0.0",
+    "@types/react-router-bootstrap": "^0.24.4",
+    "@types/react-router-dom": "^4.2.2",
+    "@types/react-router-redux": "^5.0.0"
+  },
  "scripts": {
+    "start": "rimraf ./build && react-app-rewired start --scripts-version react-scripts-ts",
+    "build": "react-app-rewired build --scripts-version react-scripts-ts",
+    "test": "react-app-rewired test --env=jsdom --scripts-version react-scripts-ts",
+    "eject": "react-scripts eject"
  }
}

누락된 부분이 없는지 확인 후 다음의 명령으로 npm 패키지를 설치한다.

npm i

3. tsconfig.json 파일 생성

{
  "compilerOptions": {
    "baseUrl": ".",
    "module": "es2015",
    "moduleResolution": "node",
    "noUnusedParameters": false,
    "noUnusedLocals": true,
    "noImplicitAny": false,
    "target": "es6",
    "jsx": "react",
    "sourceMap": true,
    "skipDefaultLibCheck": true,
    "strict": true,
    "allowSyntheticDefaultImports": true,
    "experimentalDecorators": true,
    "strictNullChecks": true
  },
  "exclude": [
    "bin",
    "node_modules"
  ]
}

4. tslint.json 파일 생성

{
  "defaultSeverity": "error",
  "extends": [
    "tslint:recommended"
  ],
  "jsRules": {},
  "rules": {
    "interface-over-type-literal": false,
    "quotemark": false,
    "ordered-imports": false,
    "object-literal-sort-keys": false,
    "arrow-parens": false,
    "one-variable-per-declaration": false,
    "only-arrow-functions": false,
    "semicolon": [
      true,
      "ignore-interfaces"
    ],
    "no-console": false,
    "member-ordering": false,
    "variable-name": [
      true,
      "ban-keywords",
      "allow-leading-underscore"
    ],
    "member-access": false,
    "comment-format": false,
    "no-var-requires": false,
    "max-line-length": false,
    "jsx-alignment": false,
    "jsx-curly-spacing": [
      true,
      "never"
    ],
    "jsx-no-lambda": true,
    "jsx-no-multiline-js": true,
    "jsx-no-string-ref": true,
    "jsx-self-close": true
  },
  "rulesDirectory": []
}

5. config-overrides.js 파일 생성

/* config-overrides.js */

module.exports = function override(config, env) {
    //do stuff with the webpack config...
    return config;
}

6. 파일 확장자 변경

이제 Javascript 를 사용할지, TypeScript 를 사용할지 결정하여 파일 확장자를 다음과 같이 변경하면 된다. (단, 파일 확장자를 변경하지 않아도 무방하다)

  1. js -> jsx
  2. js -> tsx


자세한 소스 코드는 이 링크를 참고하기 바란다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

마이크로소프트(Microsoft)는 VSCode 에서 다양한 개발 편의 기능을 제공하기 위한 Language Server Protocol 을 공개했다. 이 프로토콜의 C# 버전이 바로 OmniSharp-Roslyn이 되겠다.

그 외에 다양한 언어의 구현체가 등장했는데, 어떤 개발 언어가 구현 되었는지 아래의 링크에서 확인하기 바란다.

필자는 OmniSharp-Roslyn 을 git clone 하고 빌드하게 되면 다음과 같은 오류를 만났다.

개발환경

  • OS: MacOS Sierra
  • Version: 10.12.2

The type initializer for 'System.Net.Http.CurlHandler' threw an exception.

위의 이슈는 아래와 같이 보고가 되었다.

이 이슈는 다음과 같이 해결하면 된다.

brew update
brew install openssl
ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/


Posted by 땡초 POWERUMC
TAG c#, OmniSharo

댓글을 달아 주세요

ASP.NET Core Middleware

ASP.NET Core Middleware 는 모든 요청과 응답을 처리하는 파이프라인이다. 레거시 ASP.NET 과 ASP.NET MVC 에서는 이를 IHttpModuleIHttpHandler를 통해 구현하여 처리하거나, Global.asax.cs 에서 처리 가능하다.

IHttpModule 이 주로 사용되는 경우는 권한 처리 등과 같이 다양하게 사용된다. 모든 요청은 이 IHttpModule을 파이프라인을 통과하게 되고, 응답을 제어할 수 있기 때문이다.

이 파이프라인이 오늘에 와서 ASP.NET Core Middleware 에서 그 역할을 대신하게 된다.

- 레거시에서 파이프라인

최초 레거시 ASP.NET 은 ‘ASP.NET 파이프라인’은 최초 요청부터 마지막 응답까지 컨텍스트가 흐르는 순서가 있다. 이것이 IIS 7.0 부터 IIS 서버와 통합이 되었다.

아래 그림은 IIS 7.0의 응용 프로그램 생명주기(즉 파이프라인)이다.

Application Lifecycle
https://msdn.microsoft.com/en-us/library/bb470252.aspx

- ASP.NET Core Middleware

ASP.NET Core 는 크로스플랫폼을 지향하는데, IIS 는 마이크로소프트 윈도우에서만 실행 가능한 웹/응용프로그램 서버이다. 따라서 ASP.NET Core 를 크로스플랫폼에서 호스팅하려면 IIS 서버에서 적용되었던 파이프라인 개념을 버려야 했다. 그래서 나온 개념이 Middleware 다.

Middleware 또한 IHttpModule이 수행하는 요청과 응답을 제어하는 역할을 한다.


https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware

다만, Global.asax.cs 에서 Session 생성/소멸과 같은 이벤트를 Middleware 만으로는 세세하게 제어하지 못한다. 아마도 다른 접근 포인트가 있는지 좀 찾아봐야 겠다.

IHttpMoudle과 IHttpHandler 마이그레이션

자세한 마이그레이션 과정이 MSDN 문서에 훌륭하게 설명되어 있어서 링크로 대체하고, 간단한 샘플만 남긴다.

참고로 Middleware는 UseMvc() 메서드 이전에 남겨야 한다. 그렇지 않으면, Middleware 가 동작하지 않는다.

Startup.cs
public class Startup
{

    // 생략...

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole(Configuration.GetSection("Logging"));
        loggerFactory.AddDebug();

        app.UseApplicationInsightsRequestTelemetry();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseBrowserLink();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
        }

        app.UseApplicationInsightsExceptionTelemetry();
        app.UseStaticFiles();

        // 미들웨어 등록
        app.UseMiddleware<FrameworkMiddleware>();

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=Home}/{action=Index}/{id?}");
        });

    }
}
FrameworkMiddleware.cs
public class FrameworkMiddleware
{
    private readonly RequestDelegate next;

    public FrameworkMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        Console.WriteLine("==========================================");
        await next(context);
        Console.WriteLine("------------------------------------------");
    }
}



자세한 내용은 아래 링크를 방문하기 바란다.
https://docs.microsoft.com/en-us/aspnet/core/migration/http-modules

Posted by 땡초 POWERUMC

댓글을 달아 주세요

IControllerFactory

IControllerFactory 는 컨트롤러 객체를 반환하거나 객체 릴리즈 시키는 팩토리 인터페이스이다. ASP.NET MVC 4 까지 지원하지 않았던 DI(Dependency Injection) 기능을 사용하기 위해 이 인터페이스를 구현하여 사용하였다.

ASP.NET Core 에서는 객체 주입(Injection) 할 때 한 가지 큰 단점이 있다.

생성자 주입(Constructor Injection) 으로만 DI(Dependency Injection) 기능을 사용할 수 있다. 이 방법은 필자가 가장 좋아하지 않는 방법인데, 그 사용성이 여간 귀찮을 수 없다.

이 아티클에서는 프로퍼티 인젝션(Property Injection) 이 가능한 Unity Application Block 을 사용하기 위해 IControllerFactory 를 마이그레이션 하는 것을 목표로 한다.

- 레거시 ASP.NET MVC 에서 IControllerFactory 설정

Controller 클래스들을 IoC(Inversion of Control) 컨테이너(Container) 에 담아 놓고, 꺼내쓸 때 DI(Dependency Injection) 을 시키는 방식이다. 이렇게 하면 사용하는 입장에서는 복잡한 객체와 인스턴스 관계를 파악할 필요 없이 꺼내 쓰면 되는 것이다. 당연 단위 테스트에서도 간결하게 사용할 수 있게 된다.

global.asax.cs

ControllerBuilder 클래스를 이용하여 IControllerFactory 인스턴스를 설정한다.

// 종속성 주입 설정
Application.Lock();
{
    Container = configureContainer();
    ControllerBuilder.Current.SetControllerFactory(new FrameworkControllerFactory(Container));
}
Application.UnLock();

FrameworkControllerFactory.cs

public class FrameworkControllerFactory : DefaultControllerFactory
{
    private readonly IFrameworkContainer container;

    public FrameworkControllerFactory(IFrameworkContainer container)
    {
        this.container = container;
    }

    #region Overrides of DefaultControllerFactory

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        if (controllerType == null)
        {
            requestContext.HttpContext.Response.Redirect("/", true);
        }

        var controller = container.Resolve(controllerType);
        return controller as IController;
    }

    #endregion
}

- ASP.NET Core 에서 IControllerFactory 설정

ASP.NET Core 에서는 상당수 서비스 클래스와 인스턴스들이 IoC Container 에 등록되어 여기에서 객체를 불러 사용하고 있는 형태다. IServiceCollection 인터페이스에 서비스에 ASP.NET Core 가 동작하기 위한 코어 클래스들이 등록되어 있다.

IServiceCollection 에 Singleton 객체로 services.AddSingleton<IControllerFactory, FrameworkControllerFactory>(); 하게되면 IControllerFactory 가 등록된다.

그럼 IServiceCollection 에는 IControllerFactory 가 두 개 등록이 되어있는데, 나머지 하나가 DefaultControllerFactory 클래스이다. 이 때, ASP.NET Core는 가장 마지막에 등록된 IControllerFactory 클래스를 반환한다.

먼저, Nuget 을 통해 Unity Application Block 을 설치한다.

Startup.cs

public class Startup
{
    public static IUnityContainer Container = new UnityContainer();

    public void ConfigureServices(IServiceCollection services)
    {
        // Add framework services.
        services.AddApplicationInsightsTelemetry(Configuration);
        services.AddMvc();

        // IControllerFactory 설정
        services.AddSingleton<IControllerFactory, FrameworkControllerFactory>();
    }
}

FrameworkControllerFactory.cs

public class FrameworkControllerFactory : IControllerFactory
{
    public object CreateController(ControllerContext context)
    {
        return Startup.Container.Resolve(context.ActionDescriptor.ControllerTypeInfo.AsType());
    }

    public void ReleaseController(ControllerContext context, object controller)
    {
    }
}

모든 설정이 다 되었으면, Unity Container 에서 DI(Dependency Injection) 을 수행하는 HomeController 가 정상적으로 동작하게 된다.

HomeController.cs

public class HomeController : Controller
{
    [Dependency]
    public MessageService MessageService { get; set; }

    public IActionResult Index()
    {
        MessageService.Say();

        return View();
    }
}

public class MessageService
{
    public void Say()
    {
        Console.WriteLine("MessageService Resolved. ===========================");
    }
}


Posted by 땡초 POWERUMC

댓글을 달아 주세요

오류 유형은 아래의 웹서버 로그와 같이 “세션ID 가 생성 되었지만, Response 가 Flushed 되어 저장할 수 없다”.

Session state has created a session id, but cannot save it because the response was already flushed

이 현상은 다음의 경우의 수를 모두 만족할 경우 발생하게 된다.

  • 웹서버(IIS) 가 리사이클링 되고,

  • 웹서버에게 첫 요청이 가고,

  • 코드에서 Session 속성을 사용하기 전이고,

  • 서버 코드에서 Response 를 Flush 하고,

  • 웹브라우저가 아닌, 네트워크 라이브러리를 통해 호출을 하고,

  • Global.asax.cs 의 Session_Start 이벤트가 발생할 때


분석을 해보면 (MSDN 에서 ASP.NET Application Page LifeCycle(영문)을 참고), PreRendering 단계 이후에 SavePageStateTo 를 수행하는 것을 알 수 있다. 따라서 인터넷을 통해 찾은 해결 방법이 Session 속성의 객체를 한 번 호출해 주는 것으로 이런 현상을 제거할 수 있다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

개요

ASP.NET WebForm 에서 Dependency Injection 을 사용하는 방법을 소개한다. IoC Container 를 이용하여 System.Web.UI.Page 를 상속하는 페이지에서 Injection 을 해야 하는데, 이를 위해 IHttpHandlerFactory 를 사용하는 방법을 소개한다.

여기에서는 필자가 꾸준히 만들어 온 Unity ContainerWindsor Castle 을 기반으로 하는 Umc.Core 프레임워크를 사용한다.Umc.Core 프레임워크에는 Unity Auto Registration 기능등이 모두 포함하기 때문에 프로젝트 셋업에 편리하다는 장점도 있다.

샘플 프로젝트는 필자의 github 에서 다운로드 받을 수 있다.
https://github.com/powerumc/WebForm-DependencyInjection 

프로젝트 셋업

먼저 프로젝트를 만들고, nuget 을 이용하여 umc.core 프레임워크를 설치한다.

nuget install umc.core

그리고, Umc.Core 에 구현에 놓은 IHttpHandlerFactory 를 샘플 프로젝트에 추가해 놓았다. 이를 web.config 에 추가해 주면 된다.

<system.webServer>
    <handlers>
      <add name="WebFormPageHandlerFactory" verb="*" path="*.aspx"  type="WebForm_DependencyInjection.FrameworkContainerPageHandlerFactory"/>
    </handlers>
</system.webServer>

FrameworkContainerPageHandlerFactory 클래스의 구현은 아래의 코드를 참고하면 된다. 다만, 아래 구현 코드에서 BuildManager.CreateInstanceFromVirtualPath 를 대신 사용하면 절대 안된다.

public class FrameworkContainerPageHandlerFactory : IHttpHandlerFactory
{
    public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
    {
        var handler = BuildManager.GetObjectFactory(url, false).CreateInstance();
        if (handler.GetType().ToString().StartsWith("ASP."))
        {
            var container = context.Application["container"] as IFrameworkContainer;
            return container.Resolve(handler.GetType().BaseType) as IHttpHandler;
        }

        return handler as IHttpHandler;
    }

    public void ReleaseHandler(IHttpHandler handler)
    {
    }
}

웹 응용프로그램 Bootstrap

그 다음 할 일은 어떤 컴포넌트들을 IoC 에 등록하고 이를 Composition 할 지 코드를 통해 구현한다. ASP.NET WebForm 에서는 Global.asax.cs 의 Application_Start 메서드에 구현하는 게 가장 적절하다.

그러나 이는 RELEASE 용 빌드인 경우가 그렇고, 개발 중인 경우, 즉 DEBUG 모드 빌드인 경우 Session_Start 에 구현해 놓는 것도 좋을 것 같다.

public class Global : System.Web.HttpApplication
{
  private static IFrameworkContainer container;

  protected void Application_Start(object sender, EventArgs e)
  {
      container = new FrameworkContainerForUnity();

      var catalog = new FrameworkAssemblyCatalog(Assembly.GetExecutingAssembly());
      var visitor = new FrameworkDependencyVisitor(catalog);
      var resolver = new FrameworkCompositionResolverForUnity((FrameworkContainerForUnity)container, visitor.VisitTypes());
      resolver.Compose();

      Application.Lock();
      Application["container"] = container;
      Application.UnLock();
    }
  }

FrameworkAssemblyCatalogFrameworkCatalog를 구현한 클래스로 컴포넌트를 등록하는 방법을 구현하는 클래스다.

FrameworkDependencyVisitor 는 catalog 에서 검색된 컴포넌트들을 구석 구석 방문해서 Comsoition 을 위해 객체 그래프를 그리는 클래스다.

FrameworkCompositionResolverForUnity 는 객체 그래프를 IoC Container 에 등록하는 클래스다.

이렇게 몇 줄의 코드로 Auto Registration 과정이 모두 끝난다.

서비스 구현

간단하게 Dependency Inection 을 테스트하기 위해서 IEmailService 인터페이스와 이를 구현한 코드다.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Web;
using Umc.Core;

namespace WebForm_DependencyInjection.Services
{
    public interface IEmailService
    {
        bool Send(string to, string contents);
    }

    [DependencyContract(typeof(IEmailService))]
    public class EmailService : IEmailService
    {
        public bool Send(string to, string contents)
        {
            HttpContext.Current.Response.Write("Send email.");
            return true;
        }
    }
}

페이지 구현

이제 모두 다 됐다. Dependency Injection 이 필요한 프로퍼티에 [DependencyInjection] 특성을 선언하면 Index 페이지 인스턴스가 생성될 때 컨테이너에 등록된 컴포넌트가 주입된다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Umc.Core;
using WebForm_DependencyInjection.Services;

namespace WebForm_DependencyInjection
{
    public partial class Index : System.Web.UI.Page
    {
        // Here.. Injection for IEmailService.
        [DependencyInjection]
        protected IEmailService EmailService { get; set; }

        protected void Page_Load(object sender, EventArgs e)
        {
            EmailService.Send("", "");
        }
    }
}


Posted by 땡초 POWERUMC

댓글을 달아 주세요

.NET 플랫폼이 나오고 십 여년 동안 마이크로소프트(Microsoft)는 .NET 플랫폼 시장을 개척하고 활성화 하기 위해 많은 투자를 아끼지 않았다. 많은 사람들이 주저 없이 .NET 개발에 뛰어 들었고, 비주얼 스튜디오(Visual Studio) 편리한 개발 도구는 .NET 플랫폼 개발에 필수 도구가 되었다.

하지만, 이제 한 때 과거의 이야기가 되어가고 있다. .NET은 새로 익히기 꺼려지는 플랫폼 중 하나가 되었고, 사회에 진출하는 새로운 .NET 개발자는 더 이상 예전처럼 양성 되지 않고 있다. 여기에 근거하는 사실을 매우 구체적으로 적고 싶으나 단순히 구체적인 한 두 가지의 문제라기 보다 복합적인 문제이므로 이를 읽는 독자는 넓은 시야로 가볍게 읽어주길 바란다.



[출처] 링크


그리고 본문에 잘못된 내용이나 사실에 근거를 대라고 지적하시는 것도 좋으나 그 정보는 직접 찾아 보고 반론을 제기해 주면 필자가 굳이 구구절절 같은 설명을 할 필요가 없어지므로 발전적인 토론이 될 것이라 생각한다.

1. .NET 플랫폼에 너무 많은 투자를 한 것

그야말로 .NET 개발 언어 중 대표적인 C#은 많은 다양한 프로그래밍 언어의 장점을 수용했다. 루비(Ruby), 파이썬(Python), 스몰 토크(Smalltalk)와 오브젝트 C(Objective C), 리스프(Lisp) 등의 프로그래밍 언어의 장점을 C# 언어에 녹아냈다. 이로써 C# 2.0, C# 3.0 시절엔 .NET 플랫폼의 춘추전국시대라고 해도 과언이 아닐 정도이다. (좋게 말하면 개방적인 언어가 되겠고, 나쁘게 말하면 줏대 없는 잡탕이라고 볼 수 있겠다.) 그와 함께 WCF(Windows Communication Foundation), WPF(Windows Presentation Foundation) 등 새로운 기술의 쏟아내는 기염을 토해냈다.

하지만 다른 측면에서 다른 분야의 기술과 그걸 밥벌이 하는 개발자들은 결국 소외될 수 밖에 없다. 그리고 그런 기술들은 기술 발전이 정체 되고, 지원이 끊기거나 지원 규모가 작아지게 된다. 대표적으로 비주얼 베이직(Visual Basic)과 ASP(Active Server Page), 실버라이트(Silverlight) 등이 사망 선고를 받게 된다.

다음은 각각 사망할/사망한 날짜이다.

최근 .NET 개발마저 침체기임이 틀림없다. .NET 플랫폼의 기본은 .NET 프레임워크(.NET Framework)이지만, 이 기본 라이브러리마저 파편화가 되고 있다. 엄밀히 말해 실버라이트, 윈도우 RT(Windows Runtime), .NET 프레임워크는 전혀 다른 메모리 공간에 로드 되는 외형만 비슷한 라이브러리이다. 자바처럼 JRE, JVM을 기초로 모든 코드가 실행되는 것과 다르다. 따라서 실버라이트, 윈도우RT, .NET 프레임워크는 각각 코걸이, 귀걸이 등 물리적으로 전혀 다른 구성 요소로 본다. 이는 마이크로소프트가 1년 앞도 염두하지 않고 급하게 설계하고 개발한 것이며, 아직 까지도 이런 릴리즈가 꾸준히 계속 되고 있다. 이는 뭔가 새로운 버전이 출시할 때마다 하위 호환성을 버리는 악순환이 된다.

2. 네이티브(Native)를 죽여버린 것

지난 수 십여년간 네이티브(Native) 기술의 암흑기였다. 더 이상 Visual C/C++ 6.0 컴파일러는 멀티 코어 CPU에 대응하기 힘들어지고 울며 겨자 먹기로 상위 버전으로 업그레이드를 할 수 밖에 없었다. VC 6.0에서 VC 2008/2010으로 약 십여년의 시간적인 격차가 벌어진 개발 도구와 개발 환경으로 옮겨야 했다.

UPDATE 2013-10-04
참고로 'Visual C/C++'이라 표기한 것은 C 언어 프로그래밍과 C++ 프로그래밍이 모두 가능하다는 의미이다. 아시다시피 Visual C/C++ 의 컴파일러는 다음처럼 Microsoft C/C++ Compiler 라고 표기되어 있기 때문에, 이를 통용하여 Visual C/C++이라고 표현하였다. 'Visual C 라는 것은 없다'고 하시는 분이 계셔서, 이 부분에서 오해의 소지가 없도록 하였으면 한다. 

또한, MSDN 의 일부 문서는 C/C++ 언어를 모두 다루는 문서가 있으니 MSDN의 C/C++ Languages 섹션을 참고하면 된다. 정확한 표기는 'Microsoft C/C++'로 표기하는 것이 정확하지만, Visual Studio IDE와 연관된 부분은 'Visual C/C++'이라 표기하는 것이 더 어울리지 않을까 생각한다.

참고: C 프로그램 컴파일 - http://msdn.microsoft.com/ko-kr/library/bb384838(v=vs.90).aspx

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

simple.c
Microsoft (R) Incremental Linker Version 9.00
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:simple.exe
simple.obj

업그레이드는 컴파일러 뿐만 아니라 개발 도구마저 상위 버전으로 바꾸는 것은 매우 불합리하다. 컴파일러만 바꾸면 되지만 개발 도구까지 상위 버전으로 바꾸어야 하는 비합리적인 개발 환경은 오직 Visual C/C++ 밖에 없을 것이다. (그 외 윈도우 폰, 윈도우 8 앱 개발 환경도 마찬가지다)

그렇게 .NET 플랫폼이 춘추전국시대를 맞이하는 동안 마이크로소프트의 대부분의 SDK의 APIs 들은 .NET 용으로만 제공되었다. Visual C/C++로 만들고 싶어도 만들 수 없는 것이 더 많아지게 되었다. 아니, 만들 수는 있겠지만 ‘만들고 싶지 않다’는 표현이 맞을 것이다.

3. 실험적인 기술을 너무 서둘러 릴리즈 한 것

웹 2.0과 함께 떠오른 ASP.NET 기술 중 AJAX.NET 이 되겠다. 당시 AJAX 대표 라이브러리 중 prototype과 script.aculo.us 등이 대세임에도 불구하고 ASP.NET 서버 랜더링 모델을 고수하는 AJAX.NET을 내놓았다. 결국, 채 2년도 되지 않고 ASP.NET 웹 프레임워크는 jQuery를 공식적으로 지원하고 기존의 AJAX.NET은 어떤 언급도 없이 그렇게 버려졌다.

실버라이트(Silverlight). 이 기술은 애당초 세상에 나오지 말았어야 하는 기술이라 본다. 돌이켜보면 실버라이트 3.0 버전을 실버라이트 1.0 버전으로 나왔어야 경쟁력이라도 있었고 시장에서 기술적인 신뢰를 얻을 수 있었다. 물론 마이크로소프트(Microsoft)는 서둘러 어도비(Adobe)를 따라잡고 싶은 심정은 십분 이해된다. 하지만 이 실버라이트 기술 하나 믿고 시작한 개인과 회사는 시간, 인력, 기타 리소스의 금전적인 규모가 치명적인 타격을 주기에 충분하다. 한 마디로, 실버라이트 쇼크(shock)다.

실버라이트는 아직 까지 윈도우 폰 개발, (그 외 쉐어포인트(SharePoint))에 필요한 기술이다. 아직까지 실버라이트 개발을 하고 있는 분들에겐 미안하지만, 브라우저를 기반으로 하는 실버라이트 응용 프로그램은 거의 모조리 자취를 감췄다.

윈도우 폰 7. 조심스러운 부분이다. 다만 필자의 생각은 이 윈도우 폰 7이 정상적인 스마트 폰인지, 아니면 프로토타입 폰인지 아직도 구분하기 힘들다. 그리고 필자는 후자라고 생각한다. 다음의 인용을 보면 윈도우 폰 7은 Windows CE/Compact 7 커널 기반이지만, 윈도우 폰 8은 Windows NT 커널을 사용한다.

Windows Phone 7 is based on the Windows Embedded CE kernel – the next generation of the Windows Embedded CE platform will be Windows Embedded Compact 7 when released, and the current version is Windows Embedded CE 6.0 R3. Although Windows Phone 7 was built on the Windows Embedded CE kernel at its core, the Windows Phone team has incorporated innovative features and functionality on top of the platform to develop an OS specifically designed to meet the needs of mobile phone manufacturers. [2]

여기서 예상할 수 있는 것은 윈도우 폰 7은 이미 버린 카드이다. 왜냐하면, 윈도우 폰 7은 윈도우 폰 7.8 버전까지 업데이트를 할 수 있는데, 윈도우 폰 7과 8은 서로 전혀 다른 커널을 사용하므로 윈도우 폰 7 사용자는 윈도우 폰 8 운영체제로 업데이트를 할 수 없기 때문이다. 한 가지 재미있는 것은, 업데이트 ‘7.8’ 버전 번호를 보고 유머러스 한건지, 약올리는 건지 분간이 안된다. ㅎ

윈도우 8. 윈도우 8의 앱 개발 기반은 진흙 위에 빌딩을 세우는 것과 같을 정도로 안정적이지 못한 릴리즈이다. 결국 윈도우 8.1에서는 또 윈도우 8과 하위 호환성을 상당 부분 포기해야 했다. 이는 윈도우 폰 8도 마찬가지다. 윈도우 8 앱의 기반은 WinRT(Windows Runtime)인데, 이 WinRT도 완성도 면에서 프로토타입이라고 확신한다. 여기에 대해서는 아래의 필자의 글을 참고하기 바란다.

4. 플랫폼 사용자를 플랫폼에 가두는 것

물리적인 측면에서 .NET 플랫폼의 확장은 돈으로 직결되고 돈으로 귀결된다. 아주 간단한 예로 .NET 플랫폼이 클라우드에서 동작 가능한 Auto Scaling 환경이라고 치자. 서비스에 부하가 가중되면 필요에 따라 이를 분산하기 위해 스케일 아웃(scale out)이 필요할 때가 있는데, 이때 당장 윈도우 라이선스 부과라는 문제부터 해결해야 할 것이다.

마이크로소프트 윈도우즈(Windows) 서버 제품을 사용하는 순간부터 마이크로소프트의 제품을 사용해야 하는 처지에 놓이고 만다. 다음과 같이 말이다.

  • LDAP, Authentication, Certification -> 엑티브 디렉토리,(Active Directory)
    DNS -> 윈도우즈(Windows) DNS 서버
  • 웹 서버 -> IIS(Internet Information Services)
  • 가상화 -> Hyper-V
  • 응용 프로그램 서버 - COM+, WCF(Windows Communication Foundation)
  • 스크립트 언어 -> PowerShell

.NET 플랫폼과 매우 친숙하게 어울릴 수 있는 구성 요소들이다. 물론, 반드시 선택하지 않아도 되는 차선책은 있지만, 그렇게 되면 아름다운 아키텍처를 절대 만들 수 없게 된다. 솔루션 도입에서도 마찬가지로 사내 클라우드(Private Cloud) 구축에 Hyper-V과 결합하는 System Center 제품군은 최선책이고, 차선책은 없다.

위의 경우는 단적인 일부 예일 뿐이다.

.NET 플랫폼 또한 '그들만의 리그(League)' 일 뿐이다. 그들만의 리그 속에서는 환상적인 조합이지만, 조금만 밖에서 지켜보면 하나의 당이 모든 것을 통제하는 공산당 아키텍처와 다를 바가 없다.

5. 개발자를 경청하지 않는 마이크로소프트의 By Designed 철학

마이크로소프트의 모든 최종 답변은 이것으로 통한다. 바로 “BY DESIGNED-의도된 설계”.

섣부른 릴리즈(Release), 구조적인 아키텍처의 결함, 비효율적인 사용자 경험(UX) 등의 고객이나 사용자의 이의에 대해 마지막 (비)공식적인 마이크로소프트의 답변은 "by designed-의도된 설계" 라고 한다. 로드맵(roadmap)에서는 보여주지 않는 By designed 때문에 개발자와 회사들을 곤란한 상황에 빠트린다.

재미있는 일이 벌어졌는데, 마이크로소프트는 일방적으로 Microsoft SQL Server 라이선스 기준을 변경했다. 필자는 이것도 큰 범주에서 "By Designed" 철학과 전혀 무관하지 않다고 본다. 원래 CPU 라이선스(per cpu license)를 코어 라이선스(per core license)로 일방적으로 변경하는 바람에 SQL Server를 사용하는 멀쩡한 회사들을 불법 사용자로 취급 되어 라이선스가 부과되고, 이를 뒤늦게 안 영세(?)한 곳에서는 마른 하늘에 날벼락이 떨어지는 꼴이다. 합법적인 절차라 하더라도 충분히 고객들에게 분노를 살 수 있을 것이다. 이 라이선스 정책에 대해서는 다음의 링크를 참고하기 바란다.

"BY DESIGNED", 오리발 내밀기에 최고의 답변이자 최악의 답변이다. 필자도 이 말을 (불리할 때?) 쓰는 것을 좋아하지만, 반대로 또 가장 싫어 한다.

6. 개발자의 스스로 성장할 자생력을 죽여버린 것

제국 마이크로소프트는 개발자 생태계를 너무나 심각하게 교란 시킨다. 모든 개발 환경은 통제된 환경 하에서만, 그리고 통제된 방법으로 사용되길 원한다.

.NET 플랫폼 환경은 최선책은 있지만 차선책은 없다. 웹 개발만 예를 들어 보아도 자바(Java)는 스트럿츠(Struts), 스프링 MVC(Spring MVC), 플레이 프레임워크(Play Framework) 등 충분히 시장에서 검증된 웹 개발 프레임워크가 있다. 여기에 자바 언어보다 더 심플하고 강력한 언어인 스칼라(Scala), 그루비(Groovy)를 결합하면 폭발적인 생산력을 낼 수 있다.

하지만, ASP.NET은 ASP.NET MVC 이외에 차선책은 없다. 참고로 ASP.NET 웹 폼은 최선도, 차선도 아니다. 자세한 이야기는 다음의 필자의 글을 참고하기 바란다. 더불어 필자가 2009년에 쓴 글임을 감안하고 읽어 주길 바란다.

ASP.NET 웹 폼을 제외한 이유는 ASP.NET 웹 폼은 생산성 향상을 할 수 있는 기능 요소를 보여주기 위한 ASP.NET이 제공하는 기능의 일부이다. 그러므로 ASP.NET 웹 폼이 ASP.NET 전체 아키텍처에 영향을 주는 요소가 절대 아니므로 ASP.NET 웹 폼을 ASP.NET 웹 플랫폼과 동일 선상에서 비교하는 오류를 범하면 안되는 것을 당부한다. 즉 ASP.NET은 반드시 ASP.NET 웹 폼으로 개발하지 않아도 된다. 이 웹 폼은 사용자 정의 컨트롤로 구현된 컨트롤에 불과한 것이다. 자세한 내용은 MSDN 링크를 참고 하기 바란다. [3]

따라서 자바 플랫폼 웹 개발자들을 만나게 되면 다양한 기술과 경험에 대한 이야기를 들을 수 있고 충분히 토론할 만한 주제가 있는데 반면, .NET 웹 개발자들의 주요 관심사는 ASP.NET MVC 코드 조각을 찾아서 해결한 문제나 트러블 슈팅하는 팁 공유가 대부분이다. 그러므로 일반적인 .NET 웹 개발자는 자바 웹 개발자의 열린 사고 방식을 따라갈 수 없다고 결론을 내렸다.

뽀송뽀송한 .NET 플랫폼 테두리에 갇혀 있다면 우물 안의 물이 원래 당연히 썩는다고 생각할 거다. 하지만, 테두리 밖에서 바라보면 우물 안의 물이 원래 썩는 게 아니라 흐리지 않기 때문에 썩는 다는 걸 깨닿게 될 것이다.

7. 모든 것을 심각하게 통합한 것

.NET 개발자는 비주얼 스튜디오(Visual Studio) 없이는 단 한 줄도 코드를 만들어 내지 못한다. 단 한 줄, 과장된 표현이긴 하지만 비주얼 스튜디오(Visual Studio) 이외에 다른 대안이 없다.

통합은 곧 깡패다. 팀 파운데이션 서버(Team Foundation Server)에 체크인(Checkin)된 소스 코드를 받으려면 어이없게도 비주얼 스튜디오가 반드시 필요하다. 팀 탐색기(Team Explorer)가 설치된 비주얼 스튜디오 쉘(Visual Studio Shell)이 없으면 TFS Power Tools 같은 것도 무용지물이다. 왜냐하면 TFS 클라이언트 도구는 팀 탐색기에 포함된 필수 런타임이 반드시 필요하기 때문이다. 그 외 더 자세한 내용은 다음의 필자의 글을 참고 하기 바란다.

만약 마이크로소프트가 망한다면 기술의 기반, 개발 환경, 기타 솔루션 등 모든 것은 그저 한 줌의 재가 될 것이다. 소스 코드를 공개한다고 해도 그 일부는 더 장래가 밝은 1인자에게 기부될 것이다.

현재까지 100년 이상 된 IT 기업은 전세계에도 없다.  "영원히 위대한 기업, 영원히 호황을 누리는 산업은 없다. 다만 영원히 뛰어난 전략적 움직임만 존재할 뿐이다." [4] 마이크로소프트가 100주년이 된다면 IT 기업이 아닌 애플에 부품을 대주는 ‘제조업’ 회사일 수도, 플레이 스테이션을 유통 시키는 ‘무역업’ 회사일 수도, 그 아무도 모른다.

UPDATE 2013-10-04
IT 기업 중 100년 이상이 된 기업은 IBM으로 2011년도에 100주년이 되는 해였다. 댓글로 정보를 제공해 주셔서 감사합니다.

언젠가 (차선책이 없는) 통합된 제품을 쓰는 이들은 엄청난 대수술을 받아야 할 지 모른다. 마치 흔들리는 이빨만 뽑을 수 없고 잇몸 전체를 들어내야 할 수도...


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. 지나가던사람 2014.08.19 15:36 Address Modify/Delete Reply

    글 잘 읽었습니다.
    닷넷 개발만 10년넘게 하다가 최근 1년정도 php, java, python 등등 하고 있는 사람인데,
    저는 잘 모르겠습니다. 방금 언급한 언어들이 아직은 닷넷보다 미숙한 탓도 크겠지만,
    vs에 비해 개발 툴(이클립스, 인텔리제이)에서 느껴지는 답답함과 생산성, 유지보수의 불편함
    개발 프레임워크의 복잡성,, 이런 것들이 너무 크게 자리잡고 오히려 이런 것들이 쌓이니
    개발이 재미가 없어지고 있습니다.
    너무 닷넷에(편한 개발환경에) 익숙해져 말씀하신대로 변화에 적응력이 떨어진 거 같은 생각도 듭니다.
    닷넷이 망한(?) 원인은 여러 설명을 해주셨지만 제가 보기엔 기술의 흐름(ria, 오픈소스)에 대한 대응이 실패한 것이 크고 플랫폼 독립성이라는 주제에 대해 간과한 점, MS 제품군에 종속성을 유지하려 한점,
    라이센스에서의 독재성(?) 뭐 이런것들이 주요 원인이라 생각이 드네요.
    전 그래도 닷넷을 사랑합니다.
    10년넘게 개발해 오면서 닷넷이 아닌 다른 걸 선택했다면 쓸데없는 스트레스를 너무 많이 받았을 거 같네요..ㅎ 그만큼 닷넷이라는 기술에 있어서는 자바나 다른 언어들과 비교해도 뛰어나다고 생각합니다.

  3. 일단 공감, 그리고. 2014.08.24 22:32 Address Modify/Delete Reply

    MS는 MS DOS / Windows로 굳어진 OS 개발회사라는 틀을 벗어나는 것이 가장 시급하지 않은가라고 생각합니다. 90년 초반 MS-DOS를 사용하다 DR-DOS로 옮겨가던 사람들이 오피스 때문에 다시 Window 3.1를 다시 돌아보던 기억이 납니다. 그 때도 많은 사람들이 MS 욕은 엄첨 했었지만, 그건 특정 업체에만 국한되었던 것은 아니었죠. MS에서 느끼는 답답함은 그 시절과 크게 다르지 않은 것 같습니다. 오히려 닷넷때문에 이미지가 호전되었었다고나 할까요. :-) IBM, Oracle... 모두 다 사활을 건 생존경쟁에 서 있는 "업자"들일 뿐. 회사는 솔루션에 적합한 개발 플랫폼을 고르면 그만, 개발자는 회사에서 선택한 플랫폼이 머든 제발 리펙토링이라도 제대로 했으면 하는 쿨럭 -ㅁ- ㅋ

  4. 흠.. 요즘에는.. 2014.09.29 00:23 Address Modify/Delete Reply

    아주 새로운 데에서 닷넷이 풀리고 있습니다.
    혹시라도 닷넷을 망해가는 언어로 생각해서 더이상 배우는 사람이 나오지 않을까 몇 자 적어봅니다.

    마이크로소프트 닷넷 프레임워크를 멀티 플랫폼에서 돌릴 수 있도록 변환하는 작업이 오픈 진행되고 있습니다.

    Xamarin Studio 가 대표적인데, 닷넷으로 구현된 프로그램이 안드로이드, IOS, 윈도우 모두 돌아갈 수 있도록 합니다. 그 언어는 C#이고요..

    그 Xamarin studio 의 기본 툴이 MonoDevelop인데, 이건 요즘 각광받는 유니티에서 사용되고 있습니다.
    닷넷 관련 소스 및 커뮤니티도 상당히 크고요.

    MS가 전면에 나서서 하지는 못하지만 (회사 특성상) 멕시코 개발자가 시작한 MonoDevelop은 큰 반향을 일으키고 있습니다.

  5. feel 2014.11.14 11:19 Address Modify/Delete Reply

    어제자 발표입니다.
    우리의 목소리를 MS가 들은 걸까요? 이제 정신차리려고 하나 봅니다.

    http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/

  6. 병팔이 2015.04.14 00:11 Address Modify/Delete Reply

    내용 중 7번에 공감 100% 입니다. SDK만 가지고 IDE 없이 빌드를 해보고자 했으나 너무나 큰일이더군요. 스케줄 빌드 같은 것은 대체 어떻게 하란 말인지? 그리고 SDK 설치했는데 나오는 경로명에 Visual Studio 뭐 이런 게 왜 섞여 나와야 하는건지. .NET 설치하는데 SQL Server 공짜로 깔아줘서 고맙다고 박수칠 줄 알고 넣어준건지. 하여간 너무 바보같고 monolithic한 덩어리를 만들어버렸습니다. 더 이상 기술향상은 안해도 좋으니 하루라도 빨리 깨끗이 나눠만 줬으면 좋겠습니다.

  7. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  8. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  9. hewon 2015.06.21 16:13 Address Modify/Delete Reply

    2015년 6월에 이 컬럼을 보는데 정말 정확하게 찍어보신것 같습니다.
    특히 윈도우폰이나 RT의 미래에 대해서는요.
    닷넷 개발하는 개발자 입장에서는 자기가 개발했던 제품이 언제 단종되나 두근두근하면서 개발하고 있습니다.

  10. MonoDevelop 2015.08.08 19:34 Address Modify/Delete Reply

    MonoDevelop 한글판이 익숙치 않아 영어로 놓고 있었는데 언제부터인가 언어 설정을 english로 해도 계속 한글이 튀어나와서 아주 괴롭습니다. 이거 어떻게 방법 없을까요?

    • 땡초 2015.08.09 00:17 Address Modify/Delete

      맥 버전을 사용하신게 맞나요?
      확인 차 여쭤봅니다.

  11. Yuhan 2016.04.05 11:22 Address Modify/Delete Reply

    옛날 게시물이니 그려려니하다 2015년도 글도 보여서 얕은 지식과 의견 몇자 적어봅니다.

    상당히 MS를 까기위한 편견만 가지고 접근하시는듯 한 부분이 많이 보입니다만.

    언어적인 측면에서는 2015년에는 이미 C#이 Java를 뛰어넘었다고 볼 수 있습니다.

    LINQ, Lambda Expression 등 현재는 Java가 언어적인 측면에서 오히려 .Net을 따라가고 있는 인상을 주고 있죠.

    사실 저도 원래 .Net 개발자이지만, 최근들어 Java로 프로젝트를 계속 진행하고 있습니다.

    Java가 좋아서도 아니고, 그저 국내 시장에 자바를 선호하는 경향이 강할 뿐 사실

    자바 4~5년 / 닷넷 6년 개발 해본 입장에서 어마어마하게 많은 중괄호와

    인터페이스 오히려 간결하지 못한 코드, 뭐 할려고만 하면 추가해야되는 플러그인이나

    아주 사소한것까지 추가해야되는 다양한 프레임워크로 스트레스 많이 받습니다.

    (StringUtils라는 클래스가 몇개의 라이브러리에 중복되어 섞여있습니까.)

    괜히 Groovy가 나왔겠습니까.

    그렇다면 Java를 버리고 Groovy를 배우는게 맞을까요? 이러면 자바 개발자가 아닌게 되는건가요?

    언어적 완성도 측면에서는 Java는 더이상 C#의 상대가 되지 않습니다. 2013년에도 말이죠.

    C#을 쓰지 않아도 배워야 하는 이유는 이것 하나만으로도 충분합니다.

    4번 제외하고는 사실상 진짜 닷넷에 대해 편파적으로 바라보는 자바개발자가 쓴 글 처럼 느껴지는데.

    이거랑 똑같이 자바도 단점 끄집어 내면 한도 끝도 없습니다.

    • 땡초 POWERUMC 2016.04.05 13:44 신고 Address Modify/Delete

      맞는 말씀입니다.
      굉장히 편파적으로 바라보면서 쓴 글입니다.

      하지만 자바 진영은 오픈 커뮤니티로 합의에 의해 주도되지만,
      MS는 상업적 기업이니 같은 시각으로만 바라보기 힘들기도 합니다.

      좋은 의견 주셔서 고맙습니다.

  12. 설마 2016.06.17 01:21 Address Modify/Delete Reply

    MS가 이 글을 본걸까요.. 3년이 지난 지금은 이 글에서 꼬집은 문제점이 대부분 해결되었다는 점이 신기하네요 ㄷㄷ

  13. John 2016.07.08 13:46 Address Modify/Delete Reply

    많은부부에서 공감을 얻고갑니다 자바 개발로 시작해서 현재 닷넷 개발을 하고있는데 위에 말씀하신분이 적으신것 처럼 언어적 편의성 은 C# 이 훨씬 우월하긴 합니다 , 그 편의성때문에 가끔 가독성이 떨어질때에도 있는데 작성하는 입장에서는 엄청 좋기도하고,, 그리고 닷넷이 정확히는 CORE 닷넷출시하면서 위에 말씀하시는 모든 문제들을 대부분 해결하거나 제안을 제시했습니다 마소가 좋은녀석들이라서 그런것은 아니고 , 시장경쟁력에서 워낙 많이 밀리고 또 대세가 그러하니 변경한것 같습니다 좋은 글 잘읽고 갑니다

  14. 요원009 2016.10.27 15:31 신고 Address Modify/Delete Reply

    엔지니어 출신 이사들 내쫓음 -> MBA 출신들 데려옴 -> 말아먹은 게 한 두개가 아님.

    말아먹은 것들이 저 위에 다 나오네요. 정신차리고 엔지니어 출신들 다시 모셔오니 정상 궤도로 올라오는 느낌입니다. 요즘 C# 너무 강력해요 ㅎㅎㅎ

  15. 나그네 2017.02.05 21:45 Address Modify/Delete Reply

    요즘 Java가 마소 보다 악질인 오라클 놈들 때문에 정나미가 떨어져서 C#으로 왔습니다. 나중에 ClojureCLR 프로젝트에나 참여하고 싶네요. 요즘 마소가 제공하는 자료도 너무나 많고(MSDN, Visual Academy 등) 리눅스 지원에 오픈소스 프로젝트도 많이 해서 진짜 많이 변한 것 같네요. 그놈의 윈도우의 괴상한 구조(특히 레지스트리)는 변함이 없지만 윈10이 마지막이라고 하니 다음 OS는 제발 개발자나 서버 관리자들에게도 일반 유저에게도 편리한 OS로 나오길...

  16. 얌전맨 2017.06.20 09:53 Address Modify/Delete Reply

    MS가 정말로 이 글을 읽고 반성한것처럼 저 시기 이후로 많이 달라졌습니다. 글 쓰신분의 예리한 통찰력에 감탄하구요. 자마린이 통합된 VS2017 출시로 다시 한번 C#에 희망을 걸어봅니다.

  17. 지나가다 2017.07.15 18:56 Address Modify/Delete Reply

    잘 읽었습니다.
    그런데, 외국을 보면 Java 가 우리나라 처럼 이렇게 융성하지도,
    .Net 이 한국처럼 저조하지도 않아요.

    이유는 딱 하나입니다.
    자기 돈 아닌 돈으로 프로젝트 하는 공무원들과
    국가 공인 프레임웍을 Java 로 만들어 놓은 사람들.

    아마 본인이 회사 사장인데,
    본인 회사 프로젝트를 전자정부 프레임웍을 써서 프로젝트 하라고 하면 하겠습니까?

    그리고, Java 진영에서 떠들던 MVC...
    숙련자들이 모이고, 원활한 커뮤니케이션이 되야
    중급이하의 개발자들이 모여서 대충 개발할 수 있는
    PHP, .Net 언어들만큼의 퍼포먼스가 나온다고 한다면...

    이건 공무원이 자기 돈 아닌 자금으로 진행하고,
    업자들은 그 열매를 받아 먹는 구조에서만 가능한겁니다.

  18. ㅇㅇ 2019.03.05 15:27 Address Modify/Delete Reply

    비교하려면 객관적인 도표자료는 필수인데 내용이 너무 주관적이고, 정보 신뢰도 그닥..
    실버라이트가 2021년에 사망이라.. 2010년에 이미 개발중단입니다. 2021년에는 웹브라우저에서 지원이 중단되는겁니다.
    사람들이 여기서 논쟁을 많이 하는 이유는 글을 이따구로 써놓으셔서 인거 같습니다.
    그럼 20000

    • 땡초 POWERUMC 2019.03.05 16:16 신고 Address Modify/Delete

      객관적인 자료는 본문 중에도 링크에 있습니다.
      https://support.microsoft.com/ko-kr/lifecycle/search/?ln=en-us&c2=12905
      2011년 12월에 출시한 SL5 가 있는데 2010년에 개발 중단이라뇨.
      그리고 10년이면 강산도 변한다고 하는데, 이미 6년이나 지난 글에 너무 큰 의미를 두지 않으셨으면 합니다.

  19. 그럼 글을 내리거나 수정하시는게 낫지 않나요? 2019.03.27 13:32 Address Modify/Delete Reply

    그럼 글을 내리거나 수정하시는게 낫지 않나요?

    분쟁 유도글 같아 보여서 올려봅니다.

    • 해구름 2019.04.08 12:40 신고 Address Modify/Delete

      2013년에 작성된 글이니 감안하고 보면 될 것 같습니다. 저도 2013년에는 마소에 대해 감정이 좋지 않았습니다. 폐쇄적이고 멋대로인데다가 제대로 되는 것도 별로 없었거든요. 샤티아 나델라가 지금의 마이크로소프트로 만들지 못했다면, 이 글은 좀더 공감 받았을지도 모르죠.

  20. 천하귀남 2019.04.18 10:19 Address Modify/Delete Reply

    최근 닷넷을 시작하면서 과거와 현재의 차이가 많아 뭐가 뭔지를 이해하기 힘들었는데
    당대의 상황을 이해 가능하게 해주는 글이라 많은 도움 받았습니다.

    문제를 언급하는것도 훌륭한 자료입니다. 불편하다고 지운다면 자료가 아니지요.

  21. 공부중입니다 2019.04.24 19:53 Address Modify/Delete Reply

    지금은 닷넷 전망을 어떻게 생각하시나요??

팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #2

팀 파운데이션 서버(Team Foundation Server) 는 2005년 처음 시장에 공개되었다. 이 시기에 많은 버그와 설치 자체가 매우 난이도가 높아서 많은 사람들의 원망을 샀다.

참고 - TFS를 쓰지 말아야 하는 진짜 이유 #1 (링크)

TFS를 쓰지 말아야 하는 진짜 이유 #1을 정리해 본다.

  • 통합? 모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.
  • 특정 제품(Visual Studio)에 완벽하게 통합되어 외부와 완벽하게 격리된 솔루션이다
  • 우리나라에는 전문가가 없다
  • 전문가적인 서비스를 제공하는 업체도 없다
  • 마이크로소프트 제품으로 발라야 한다
  • 예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다
  • 제대로 된 기능이 하나도 없다

TFS를 쓰지 말아야 하는 이유 중 기능적인 요소로는 다음과 같다. (차후에 자세히 다루겠다)

  • 데이터베이스에 소스 코드가 저장되다보니 DB 로그 사이즈는 DB 용량(데이터)의 수십 배가 넘어간다
  • 모든 서버 통신은 SOAP 프로토콜을 사용하므로 매우 느리다
  • 작업 항목(WorkItem) 관리, 이슈/버그/개발 등을 관리하기에 매우 비효율적이고 쓰는 것 자체가 스트레스로 발전할 수 있다. (다른 이슈 관리 툴에 비해)
  • 모든 기능에 제한이 너무 많다

1. 팀 파운데이션 서버(Team Foundation Server)[1]

구글 트랜드(Google Trends)는 아래의 그래프와 같이 새로운 버전이 나올 때 조금씩 치고 올라가는 것을 알 수 있다. 하지만, 시간이 지날수록 이탈하는 사용자가 많을 것이고, 현재는 엉망으로 만들었던 TFS 2005 버전보다 더 관심이 줄어든 것으로 보인다.



2. TFS vs SVN

필자도 사실 이걸 보고는 깜짝 놀랬다. SVN(아파치 서브버전)이 알려진 시기는 TFS 2005와 몇 년 차이가 나지 않지만, SVN은 그야말로 LTE처럼 뻥 뚫린 고속도로처럼 고속으로 성장을 했다. 반면에 Team Foundation Server는 바닥에서 지렁이 기듯이 기어다닌다.



3. TFS vs SVN vs GIT

SVN과 GIT이 끼니 더이상 TFS에 대해서 할말을 잃게 만든다. 이쯔음 되면 TFS를 쓰는 사람들은 분명 M빠거나 멋모르고 쓰는 것이 분명하다.



4. TFS vs SVN vs GIT vs Mercurial

따로 TFS는 해설이 없어도 될 것 같다. 아래의 그래프가 여실히 보여주고 있으니 말이다.



결론

99% 중에 1%라면 매우 희소성이 있고 가치가 있어 보일 수도 있다. 필자가 그랬다. 스스로 가치 있다고 판단한다면 분명 그것은 가치가 있는 것이다.

하지만 소스 제어를 비롯한 ALM은 혼자만 가치를 느껴서는 절대로 공존할 수 없는 도구의 집합이다. 통합이 완벽해서 완전히 격리된 ALM 제품은 소프트웨어에 생명을 불어 넣기에 바라보는 안목을 작아지게 만든다. 툴에 종속되어 생각을 제한해서는 안된다.

100명 중 99명이 No 라고 말할 땐 그만한 이유가 있다. TFS는 2005년부터 시작되었고 현재 2013년이다. 횟수로 8년이 되었지만, TFS는 여전히 고질적인 문제를 해결하고자 하는 노력을 하지 않는 것 같다. 현재의 TFS 2012/2013 은 TFS 2005 초기 버전 그 이상을 아직도 뛰어 넘지 못했고, 앞으로도 뛰어 넘지 못할 것이다.

  • 성능
    점점 느려진다. 28GB 넘는 바이너리가 없는 소스코드를 인트라넷 네트워크에서 10시간 넘게 받은 적이 여러번이다.

  • 확장성
    SDK로 깨잘되는 것 말고 할 수 있는 확장 포인트가 거의 없다.

  • 사용성
    애자일보드/칸반(Kanban), 드래그&드롭, 이런거 보여주면서 사용성이 좋다고 하면 오류다. 실무에서 거의 쓸 일도 없고 더 불편하다.

  • 크로스플랫폼
    Team Explorer EveryWhere 가 크로스플랫폼을 지원한다고? 만약 이클립스를 안쓰면 어쩔건데…? 답이 없다. 다양한 개발툴 대부분이 TFS를 지원해 주는 플러그인이 없고, 지원이 된다고 해도 소스 제어 수준에서만 지원을 한다. 그러므로 통합의 의미 자체가 희석되어 버린다.


  1. ‘TFS’ 트랜드 검색 시 merida/matts 등의 통계에 방해되는 데이터가 포함되어 Team Foundation Server 로 탐색을 하였음.  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 조경민 2014.05.14 18:36 Address Modify/Delete Reply

    참 안타까운 현실이네요.. 안타까운 마음에 글 남겨봅니다..
    저희 회사에서는 아직도 TFS 2010을 사용하고 있습니다. 물론 제가 서버 구축(MOSS연동까지..)부터 관리까지 다 하고 있는 상태이구요. 용도는 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청) 관리 위주로 사용하고 있습니다. 소스관리는 시도를 했다 결구 SVN으로 갈아탔지요.. 요즘 SVN은 AD와 연동이 되서 그나마 다행이었네요.
    제가 기존 TFS에 매력을 크게 느꼈던 부분은 양식의 커스터마이즈와 한글화 때문이었습니다.
    위에 언급한 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청)모두 양식을 커스터마이즈 해서 사용하고 있습니다. 필드까지 싹 변경 할 수 있기 때문에 저에게는 엄청난 강점으로 느껴졌었습니다. 아주 심플한 혹은 강제화 할 수 있는 양식으로 탈바꿈할 수 있다는 부분은 큰 매력이였네요. 지금도 물론 잘 사용하고는 있지만 근래 JIRA 등의 동향을 보고 싶어 검색하다 여기까지 오게 됬네요.
    지금으로써 제일 불편한점은 간트차트를 사용하지 못한다는 것 외에는 크게 없는데.. JIRA를 데모해보면 또 어떻게 바뀔지 모르겠네요.
    환경적인 내용 외에 위 언급드린 내용 기준으로 비교되는 글이 더 있음 정말 좋을 듯 합니다. ^^

    아 그리고 한글화는 아직도 TFS가 최고라고 생각되네요 ㅋㅋ이넘의 짧은 영어는 언제나 발목이..

    좋은 글 잘 읽었습니다. 앞으로도 좋은 정보 부탁드립니다.
    감사합니다.

  2. 남뉴 2014.07.02 11:21 Address Modify/Delete Reply

    재밌는 글 감사합니다. 전 오히려 개발소스버젼관리시스템 자체에 회의감이 듭니다. 여러 사람이 쉽게 소스를 관리하는건 장점이고 권한에 따른 제한도 있어서 장점일 것 같지만, 오히려 잘못된 버젼 관리로 인한 문제가 더 많아 질때가 있습니다.(이건 직급이 높아도 경험이 많아도 문제가 발생합니다. )
    덕분에 압축과 시스템을 병행하고 있습니다. 마치 종이로 인쇄하고 다시 PDF나 문서파일로 웹에도 올리는
    형상이죠

  3. 지나가는이 2015.04.20 16:06 Address Modify/Delete Reply

    훌륭한 정보 잘보고 갑니다. 감사합니다.

팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1

필자는 얼마 전에 다음과 같은 글을 썼다. TFS를 그다지 좋아하지 않는 분의 글을 검색 중에 우연히 찾게 되었고, 이에 대해 필자의 의견을 남긴 적이 있다.

개인적인 의견에 필자가 반박한 것이기도 했지만, 필자는 기능적인 면에서 반박을 한 것이라 상대방의 마음이 상할지 몰랐으나, 다시 돌이켜보면 미안한 맘이 계속 든다.

과거 필자는 MS Visual Studio ALM MVP 로서 이 제품을 써야할 이유를 말할 수 있었으나, 지금은 중간적인 입장에서 TFS를 쓰지 말아야 하는 진짜 이유도 써보고 싶었다. 최근 필자는 TFS 이외의 다양한 제품을 접하면서 TFS를 쓰지 말아야 하는 이유에 대해 더욱 확신이 들었다.

우리나라에는 전문가가 없다

우리나라에 팀 파운데이션 서버(Team Foundation Server) 전문가가 없다. 그러므로 당신에게 도움이 될 만한 전문가의 손길은 없을 것이다. 팀 파운데이션 서버(Team Foundation Server) 는 모든 것을 통합한 ALM(Application Lifecycle Management) 제품이다. ALM(Application Lifecycle Management)을 이해하려면 가장 먼저 소프트웨어 공학부터 시작하고 이해해야 한다. 그리고 사용자 측면과 관리적 측면 모두를 이해하고 솔루션 환경을 제공해야 한다.

ALM 제품을 쓰기전에 소프트웨어 공학을 설명하지 못하면 왜 팀 파운데이션 서버(Team Foundation Server)를 써야 하는지도 설명할 수 없다. 소프트웨어 공학은 50년도 되지 않는 짧은 역사를 가졌지만 공학적인 분야에서 이만큼 빠르게 변화하고 발전한 공학도 없을 것이다. 그래서 소프트웨어 공학이란 것이 정확한 기준을 섣불리 경계를 짓기도 애매한 학문이다.

그리고 소프트웨어 공학과 최근 빠르게 확산되는 애자일(agile)에도 많은 시간을 쏟아서 경험을 축척해야 한다. 소프트웨어 공학은 정량적인 측정이 가능하지만 애자일은 다르다. 팀원간의 관계와 팀이 축척한 또는 개개인의 경험이 큰 작용을 하고 애자일이란 툴적인 측면에서도 적극적이어야 한다. 필자도 소프트웨어 공학과 애자일을 공부하면서 처음 블로그에 쓴 글로부터 불과 4년 밖에 채 되지 않는다. 학문이라는 것은 알면 알수록, 배우면 배울수록 모르는 것이 점점 더 많아지는 것은 왜그럴까 ^^;

TFS 전문가는 골고루 다 알아야 한다. 이것 저것 모두 통합된 제품이므로 당연한 것이다. Team Foundation Server, Visual Studio Ultimate 외에 알아야 할 것들이 더 많다.

전문가적인 서비스를 제공하는 업체도 없다

한 마디로, 팀 파운데이션 서버(Team Foundation Server) 기술을 서비스하는 업체들은 다 망했다. 그러므로 만약 당신의 회사에서 TFS 컨설팅이나 서비스를 받고자 한다면, TFS 전문가가 올 확률은 거의 없다고 봐도 된다.

실제로 운영하다 장애가 생겨도 우리나라에서는 제대로 된 서비스를 받기 힘들다. 국내 팀 파운데이션 서버(Team Foundation Server) 전문가가 있는 업체가 한 군데도 없다. 한 곳의 전문 업체가 있었지만 TFS 사업을 접었다고 전해들었다.

필자의 과거 전 회사에서는 TFS 컨설팅을 했었고, 그런 업체가 몇 군데 더 있었지만 지금은 TFS의 수요도 없을 뿐더러 한 번 도입하면 다른 솔루션으로 갈아탈 수 없는 폐쇠성을 가지고 있어 도입의 실효성에 대해서도 논란이 있다.

image-1
이미지 링크

마이크로소프트 제품으로 발라야 한다

TFS 도입을 결정하는 순간 마이크로소프트(Microsoft)의 제품으로 완전히 발라버려야 한다.

가장 먼저 발라야 하는 것은 윈도우 서버(Windows Server) 이다. 가장 최신의 버전인 Team Foundation Server 2012는 윈도우 서버 2008 R2 부터 설치할 수 있다. 항상 최신 버전에 잘 적응을 하는 것이 이로울 것이다.

두 번째로 발라야 하는 것은 엑티브 디렉토리(Active Directory; AD)이다. 다른 LDAP(Lightweight Directory Access Protocol; 경량 디렉터리 액세스 프로토콜)의 OpenLDAP 은 전혀 지원하지 않는다. 예를 들어, 사내에서 리눅스(Linux) 서버에 OpenLDAP을 쓴다면 당장 OpenLDAP 데이터를 Active Directory로 마이그레이션을 해야할 지도 모른다. 좀 더 똑똑한 방법으로는 Active Directory와 OpenLDAP을 동기화 하는 방법도 있지만, 결국 유지 관리의 피로도는 급격하게 늘어날 것이다. (물론, AD 없이 쓸 수도 있지만, 없이 쓸 생각을 하면 앞이 캄캄하다)

세 번째로 발라야 하는 것은 Microsoft SQL Server 데이터베이스 제품이다. 왜 MySQL을 지원하지 않는지 기술적으로 이해하기가 힘들다. 물론 이 제품에서 분석 서비스(Analysis Services)와 리포팅 서비스(Reporting Services)를 제공하는데, 이거 안쓰고 싶어도 써야 한다. 이거 안쓰면 TFS가 매우 초라해 지기 때문이다.

네 번째로 발라야 하는 것은 IIS(Internet Information Services; 인터넷 정보 서비스)이다. 너무도 당연한 이야기지만…

다섯 번째로, 옵션으로 쉐어포인트(SharePoint)를 바를 수 있다. 이것을 바르려고 하는 순간 전용 서버를 고려해야 할 것이다.

예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다

모든 것이 통합된 TFS 구동하는 환경은 또 매우 복잡하고 오류의 원인을 찾는 것이 매우 힘들 수도 있다. 그러므로 MS 제품 이것 저것을 알아야 하고 계속…….. 배워야 하는 악순환이 계속된다.

필자는 6년이 넘게 거의 논스톱으로 직접 운영하는 TFS 서버가 있다. 서버도 직접 구매했었고, 소음 때문에 코로케이션으로 쓰다가 서버는 팔고, 결국 규모를 데스크탑 두 대로 줄여서 집에서 돌린다. 자동 업데이트가 설정이 되었는지 원인은 모르겠으나 서버 재부팅 후에 TFS 서비스들이 먹통이 되는 경우가 많았다.

실무에서도 많이 겪는 문제 중 하나가 윈도우 업데이트(Windows Update) 서비스이다. 필자가 몸담았던 회사 중에 운영 조직에서 윈도우 서버 전문가들이 직접 관리했지만, 가끔은 윈도우 업데이트 후에 정상적인 서버 작동이 되지 않아 윈도우 업데이트를 롤백(rollback) 하는 경우가 다반사였다.

대충이라도 모르면 어디서 튀어나온 트러블인지도 예측할 수 없다. 권한 구성만 해도 엑티브 디렉토리, IIS, MSSQL, 쉐어포인트 다 따로 해줘야 하는데 이 제품들이 서로 자기 오류가 아니라는 듯한 메시지만 보여준다.

제대로 된 기능이 하나도 없다

얼마 전에 필자가 쓴 글이다. 글의 요지는 ‘모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.’ 이다.

[ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)

크로스 플랫폼(Cross Platform)을 지원하는 Atlassian 의 제품 몇 개와 비교해 보자.

  • TFS 이슈관리 vs JIRA (atlassian)  
    음.. 이건 알만한 사람이면 다 안다. TFS를 JIRA와 비교하는 것이 실례이다. redmine과 같은 오픈된 제품에 비해서도 TFS는 장점보다는 단점이 더 많다. TFS 이슈관리가 MS OFFICE 플러그인을 제공하긴 하지만, MS OFFICE에서 플러그인으로 다루는 것이 더 불편하다. 플러그인을 너무 대충 만들어놓고 OFFICE 통합이라고 하는 것은 좀 무리수다.

  • TFS 코드뷰어 vs STASH (atlassian)
    이것도 TFS는 STASH에 비교하는 것이 실례이다. STASH의 특성이 조금 다르긴 하지만, github 의 인트라넷 버전이라고 봐도 무방할 것이다. 그만큼 TFS 코드뷰어에 비해 잘 만들어 졌다.

  • TFS 팀 빌드 vs BAMBOO (atlassian)
    TFS 팀 빌드는 할 수 있는 것이 거의 없다. BAMBOOJenkins에 비교 자체가 실례이므로 넘어간다. 이미 BAMBOO는 Amazon EC2 같은 클라우드와 통합이 되었다. 이에 비해 TFS는 이제 베타 버전으로 인터넷을 통해 서비스를 테스트 중이다. 특히 BAMBOO는 다양한 소스 제어를 지원하는 것도 장점이다.

Atlassian의 통합성은 TFS의 복잡한 구성보다 더 간단하다. Atlassian 제품은 각 제품간에 긴밀하게 통합이 되어있으며, 다른 3rd party 제품까지 다양하게 통합할 수 있다. Atlassian 은 제품마다 REST 형태의 API 를 제공하는데, 제품간에 응용 프로그램 수준의 인증이나 Oauth 인증 등 다양하게 각 제품을 연결할 수 있다.

필자는 Atlassian 제품은 모든 제품을 라이센스를 직접 구매하여 집에서 호스팅을 하면서 공부하는데, 서로 간에 긴밀하게 잘 통합되어 있으며, 상당히 많은 Addon이 제공되어 매우 쉽게 기능을 확장할 수 있다.

#1의 결론

이번 #1에서 이야기한 ‘팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1’은 주로 TFS의 외적인 부분에서 언급하였다. 앞으로 TFS 제품을 Atlassian과 다른 오픈된 ALM 솔루션과 기능적인 면으로도 비교해 볼 예정이다.

이슈 관리/ 소스제어/ 빌드/ 테스팅/ 릴리즈, 그 외에 다양한 면에서 비교해 보면서 진짜 이유를 조금씩 파헤쳐 볼 것이다.

image-2
이미지 링크, 이런 것도 통합인가?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지나가는사람 2019.08.28 15:25 Address Modify/Delete Reply

    이미 오래전 글이긴 하지만 본 김에 첨언하자면...

    TFS는 Windows VS를 사용하는 환경이라면 엄청나게 강력한 툴이며, 기능또한 강력하다 생각합니다.

    물론 언급한 것 처럼 마소의 제품군을 사용해야 그 위력이 재대로 발휘되는 만큼 어느정도의 마소 제품군의 강제성은 있습니다만 이 이유로 사용하지 말아야 한다는 것은 논리적 비약이라 볼 수 있겠네요.

    차나리 제목이 TFS 구축 시 유념해야 할 사항 혹은 TFS 기능을 100%로 끌어올릴 수 있는 방법 이정도가 제목이였으면 더 좋지 않았을까 싶네요..

  2. 지나가는사람 2019.08.28 15:31 Address Modify/Delete Reply

    덧붙여 MS제품에 잔지식이 많아야한다 즉, 어렵다는 것이 TFS가 좋지 않다라고 말하는 것도 논리적 비약이라 보여지네요.

    SQL Lite가 Oracle 혹은 Sql Server에 비해 가볍고 사용하기 편하다는 이유로 Oralce DB는 SQL Lite보다 좋지 않다. 라고 말하는 것이 억지라고 생각되거든요.

    물론 좋은 제품이라하면 기능의 접근성이 좋고 직관적으로 이해하기 편해야 하는 것은 맞지만 역으로 기능이 많고(복잡하고) 익히기에 어렵다는 이유로 그것이 좋지 않다라고 말하는 것은 아니라는 것이죠.

VISUAL STUDIO 2012 UPDATE 2 한국어 패치

한국어 패치 개요

비주얼 스튜디오(Visual Studio) 2012 Update 2 버전을 설치한 사용자는 일부 프로젝트 템플릿의 주석 및 실행 결과가 영문으로 변경된다. 이 경우 여러 사람과 함께 소스 저장소로 체크인이 있을 경우 소스 코드의 포함된 한글/영문을 제대로 인식하지 못해 충돌(conflict)가 발생할 수 있다.

이 문제를 해결하기 위해 프로젝트 템플릿을 기존의 Visual Studio 2012 Update 1 ASP.NET MVC 프로젝트 템플릿에 포함된 한글로 모두 변경하였다.

파이썬(Python)으로 설치 파일을 만들었는데, 예외 처리를 하지 않아서 오류가 있을 수 있으니 오류 발생 시 수동으로 진행해 주시면 됩니다.

업데이트 대상

Visual Studio 2012 Update 2를 설치 후 ASP.NET MVC 4 프로젝트 템플릿이 영문으로 바뀌는 현상이 발생




한국어 패치가 필요한 대상

한 명 이상의 팀원과 공동 작업을 할 경우 영문/한글 주석을 충돌로 인식하는 문제가 발생할 수 있다.

  1. ASP.NET MVC 4 로 프로젝트를 만든 경우
  2. 한 명 이상의 팀원과 소스 제어(Source Control)에 체크인 해야 하는 경우

설치 방법

http://powerumc.github.io/VS2012_UPDATE2_KOR_PATCH/
  1. ZIP 파일을 다운로드 받는다. 다운로드 링크

  2. 다운로드 받은 ZIP 파일 압축을 푼다.

  3. CD VS2012_UPDATE2_KOR_PATCH-master 를 입력하여 압축 푼 폴더로 이동한다.

  4. CD dist 폴더로 이동한다.

  5. vs2012u2_patch.exe 를 실행한다.

    Downloading… c:usersumcappdatalocaltemptmprqavidmaster.zip
    99% |####################################################################### |

    Extract unzipping… c:usersumcappdatalocaltemptmprqavidmaster
    unzipdir = c:usersumcappdatalocaltemptmprqavidmasterVS2012_UPDATE2_KOR_PATCH-master
    Install… c:usersumcappdatalocaltemptmprqavidmasterVS2012_UPDATE2_KOR_PATCH-master
    BasicMvcWebApplicationProjectTemplatev4.1.csaspx Install… c:usersumcappdatalocaltemptmprqavidmaster
    VS2012_UPDATE2_KOR_PATCH-master

    …. 생략 ….

    Complated Installation VS2012 Update 2 Korean Patch

    Support by http://blog.powerumc.kr

지원 문의

  • 대표사이트 : http://powerumc.kr
  • 블로그 : http://blog.powerumc.kr
  • 커뮤니티 : http://devwith.com


Posted by 땡초 POWERUMC

댓글을 달아 주세요

$tf 폴더

팀 파운데이션 서버(Team Foundation Server) 2012 버전부터 로컬 워크스페이스(local workspace) 에 매핑된 폴더 중 $tf 파일이 생긴 것을 알 수 있다. 이 폴더는 숨김(hidden) 속성이 적용되어 있어 안보인다면 숨김 폴더도 보이도록 윈도우 익스플로어(Windows Explorer) 에서 설정을 변경하면 된다.

이 폴더는 여러분이 주로 작업하는 작업 영역(Workspace)일 경우 생각하는 것 보다 훨씬 많은 용량을 차지하고 있다. 이 폴더는 특성상 늘어나면 늘어나지 절대 줄어들 일이 없다. 대부분의 시간이 지날수록 코드의 라인은 늘어나고 변경이 일어나는 부분도 많아진다.

이 폴더가 내심 꺼림직해서 지워도 또 다시 생긴다. 이 폴더는 Team Foundation Server 2012 버전을 쓰고 + 로컬 작업 영역(Local Workspace)로 매핑된 폴더에 생긴다. 이게 의외로 골치 이프기도 하고 문제가 되기도 한다.

$tf 폴더, 왜 생기나…

이 폴더은 네트워크가 오프라인(offline) 상태로 중앙 서버에 연결할 수 없는 경우 스텐바이(standby)하고 있다. 물론 오직 오프라인(offline)을 위한 폴더는 아니다.

팀 파운데이션 서버(Team Foundation Server) 2012 + 로컬 작업 영역(local workspace) 조합이면 백퍼 생기는 폴더다. 일종의 소스 코드의 스냅샷(snapshot) 과 메타데이터(Metadata) 정보를 가지고 있다. [1]

image-1
[이미지 참조 링크]

이 폴더가 생기는 주된 이유 중 하나가 네트워크가 오프라인(offline)이 될 때 서버로 연결할 수 없으므로 이 로컬 작업 영역을 참조하게 된다. 팀 파운데이션 서버(Team Foundation Server)는 변경집합(change set) 단위로 데이터베이스(MSSQL)에 저장하는데, $tf 안에 변경집합(change set) 정보를 데이터베이스 처럼 활용하여 저장하게 된다.

image-2
[이미지] $tf 폴더 내부 구조, 각 파일은 zip 압축이 되어있다.

정체성을 잃은 TFS 소스 제어

이런 오프라인 기능을 지원하는 건 반갑다만 팀 파운데이션 서버(Team Foundation Server) 는 처음부터 오프라인을 고려하고 만들어지지 않았다. 전략적으로 비주얼 스튜디오(Visual Studio) 를 사용하는 기업이나 단체를 대상하기 때문에 오프라인(Offline) 가능성이 매우 낮은 환경을 대상으로 하는 솔루션이다.

필자의 경우 예전부터 작업하던 모든 $tf 폴더의 용량이 1GB를 훨씬 넘었고, 이런 빈번하게 작업하는 폴더를 여럿 가지고 있다. (최근 용량이 많이 차지해서 과감하게 $tf 를 지워버렸다.)

SVN 또한 .svn 이라는 숨김 폴더가 있는데 이를 ‘Administrative Directory’ 라고 부른다. 이 관리 디렉토리는 SVN을 사용하면서 변경되는 파일의 정보를 저장한다. SVN도 마찬가지로 .svn 폴더의 용량이 증가하게 되는데, 이런 경우 작업 중인 디렉토리를 복사할 때 .svn 디렉토리도 함께 복사가 된다. 최근 SVN은 이 폴더가 최상위 루트에 하나만 생기도록 변경되어 작업 디렉토리마다 .svn 폴다를 신경써야 할 필요가 사라졌다.

git 으로 잘 알려진 대표적인 분산 제어 방식의 소스제어(Distributed Version Control) 또한 로컬의 스테이징 저장소(Staging Area)를 이용한다.

사실 팀 파운데이션 서버(Team Foundation Server) 는 애시당초 오프라인에 대한 대안이 없었다. 네트워크가 오프라인이 되고 파일을 체크아웃을 하면 로컬 작업 파일이 읽기 전용(Read Only) 파일 속성이 해제되고 서버와 연결이 끊겨도 수정이 가능하다. 다시 네트워크가 사용이 가능할 때 ’온라인 상태’로 변경할 수 있는데, 이 때 체크이웃된 사실을 서버에 통보하게 되고 서버는 이 때 체크이웃 상태로 변경한다. 오프라인 상태일 때의 변경 집합은 온라인 상태에서 병합하게 되는 시나리오를 가지게 되는데, 로컬에 저장했던 변경 기록은 병합할 때 충돌(conflict)를 줄일 수가 있다.

하지만 좋은 오프라인 정책이 있더라도 경험적으로 알 수 있은 것은 오프라인(서밋이 일어나지 않는)이 오래될 수록 충돌(conflict)은 피할 수 없다. 비교적 간단하게 병합(merge)할 수 있는 어느 정도의 단계를 넘어서면 병합 도구는 변경이 일어난 부분과 일어나지 않은 부분을 제대로 분간하지 못하는 상황까지 온다.

$tf 폴더는 생기는데, 이를 제한할 수 있는 방법이 없어…

어떤 이유던 간에 $tf의 용량은 점점 커진다. 그러나 이 폴더의 용량을 제한할 수 있는 설정은 존재하지 않는다. 그리고 git 을 함께 사용하는 개발자는 소스 코드가 보관된 폴더에서 .gitignore 에 $tf 를 제외할 수 있도록 설정을 하기 바란다.

다만, $tf 폴더가 가지는 몇 가지 장점이 있다. 그러나 오프라인(offline) 일 때 굳이 파일의 버전을 비교할 예외적인 상황도 없었고, 오프라인 일 때 파일 이름을 변경한 경우도 있으나 다시 온라인일 때 무리 없이 파일의 상태가 반영이 되었다. 그러므로 필자는 수 년을 사용하면서 이 장점을 얻기 위한 예외적인 상황을 거의 몇 번밖에 만나보지 못했다.

MSDN 에서 $tf 폴더에 대해 자세하게 기술이 되어 있지 않으나 참고가 필요한 분은 이 링크[2]를 통해 확인하기 바란다.


  1. References - Team Foundation Server - Trying to understand Server versus Local Workspaces
    http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/11/30/team-foundation-server-trying-to-understand-server-versus-local-workspaces.aspx  ↩

  2. References - Team Explorer Everywhere의 새로운 기능
    http://msdn.microsoft.com/ko-kr/library/jj155781.aspx%23local  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

들어가기 앞서

팀 파운데이션 서버(Team Foundation Server) 는 구성과 운영이 매우 까다로운 ALM(Application Lifecycle Management) 솔루션 중의 하나다. 그간 오류에 대해 정리하는 의미로 팀 파운데이션 서버(Team Foundation Server) 를 운영하면서 겪을 수 있는 여러 가지 경우의 오류를 리스트업 해본다.

앞서, 마이크로소프트(Microsoft)의 제품이 가지는 여러 통합 제품은 공통적인 단점을 가지는데 그것은 통합되는 요소들이 모두 자사 제품임에도 불구하고 환경적인 요소에 매우 민감하다는 점이다.

image–1

통합된 만큼 오류 유형도 광범위

팀 파운데이션 서버(Team Foundation Server)는 윈도우 서버, SQL 서버, 웹 응용 프로그램 서버(IIS, Inernet Information Services), 그리고 쉐어포인트(SharePoint) 등과 통합이 되는데 심각한 경우 매우 작은 요소들로 인해 일부 서비스의 작동 자체가 멈춰버린다.

예를 들어 엑티브 디렉토리(Active Directory)나 데이터베이스 서버가 변경되거나 백업(Backup), 복원(Restore) 계획, 그리고 서버간의 인증이나 그룹, 맴버, 역할 그리고 시스템의 환경적인 변수 등 큰 범위부터 작은 범위까지 다양하게 나타난다.

때문에 매우 구체적으로 자원을 운용할 수 있는 장점과 함께 운영 규모가 커질수록 통합된 각 제품에 대해 매우 깊은 솔루션 지식이 요구된다. 대부분 상세한 오류 메시지를 제공하지 않고 추상적인 메시지를 제공하기 때문에 통합된 제품의 상호 관계를 확실히 이해하고 ‘감(Feeling)’으로 잘 때려 맞춰야 하는 경우도 생기게 된다.

단, 필자가 나열한 것 보다 더 많은 오류 발생과 해결이 있었으나 사소하거나 기억할 필요가 없다고 생각한 것들은 블로그에 올리지 못한 것도 다수 있다.

팀 파운데이션 서버(Team Foundation Server) 오류 해결

팀 파운데이션 서버(Team Foundation Server) 운영 정보


Posted by 땡초 POWERUMC

댓글을 달아 주세요

불완전한 통합, 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.

팀 파운데이션 서버(Team Foundation Server)는 모든 것을 통합한 마이크로소프트(Microsoft)의 ALM(Application Lifecycle Management) 솔루션이다.

통합… 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.이 통합이라는 것은 이 시대엔 단점으로 작용될 수도 있다는 생각이 든다. 지난 2005년부터 2010년까지 ‘통합’ 이라는 것이 장점이라고 생각했었다. 모든 것을 올인원(All in One) 해 놓았다는 것만으로 주목을 끌 수 있었지만, 2013년 최근에는 이제 더 이상 ‘통합’이 장점이 될 수 없다는 결론을 내렸다.


[이미지] 통합... 현실적인 통합과 이상적인 통합


(현실적인 통합?)
출처 : 이미지 링크

(이상적인 통합?)
출처 : 이미지 링크


필자는 비주얼 스튜디오 팀 시스템(Visual Studio Team System) 2005 버전부터 팀 파운데이션 서버(Team Foundation Server)를 사용해왔다. 필드에서는 이와 관련된 다수의 기업 컨설팅과 강의를 진행하였고, 그 외 레거시 개발 환경과 소스 컨트롤(Source Control)을 커스터마이징한 소프트웨어를 납품하는 등 대략 8년을 넘게 비주얼 스튜디오(Visual Studio)와 팀 파운데이션 서버(Team Foundation Server)와 동거동락하며 지냈다. 물론, 8년을 넘게 사용하면서 좋은 점도 많지만 그렇지 않은 점도 확실히 있다.

그 동안 한 가지 ALM 솔루션만 사용할 때는 미처 몰랐던 것들이 많았지만, 여러 가지 ALM 제품을 접하면서 ALM 솔루션 간에 장/단점을 필자의 기준에 좀 더 객관적으로 판단할 수 있는 계기가 되었다.

과거 ALM은 오픈 소스 진영을 중심으로 조금씩 발전해 왔다. SVN 소스 제어 컨트롤을 중심으로 각각 독립적인 유닛(Unit)으로 배포가 되고 플러그인 등을 활용하여 조금씩 연동을 할 수 있었다. 그런 와중에 마이크로소프트(Microsoft)는 개발툴과 ALM을 통합한 ‘팀 시스템(Team System)’ 발표하였고, 그 당시 여러 오픈 소스가 가진 것들을 한 곳에 통합하여 사용할 수 있었다. 이 때까지는 ‘통합’ 이라는 것 자체가 장점이던 시대이다.

하지만, 최근 ALM은 조직의 성숙도에 맞는 전문적인 ALM 툴을 사용하는 추세이다.

아쉽게도 팀 파운데이션 서버(Team Foundation Server)는 각각의 모든 기능들이 전문성을 갖추기에는 매우 부족한 것도 사실이다. ‘이슈 관리, 빌드, 소스 제어’, 아마도 딱 떠오르는 대표적인 벤더 및 오픈 소스들이 있을 것이다. 이슈 관리(Issue Managements), 빌드(Builds), 소스 제어(Source Control) 등, 타 벤더의 전문적인 툴과 비교하면 각각의 기능은 타 벤더에 비해 열악하다.

대표적인 ALM 벤더들과 차이가 나는 것은 마이크로소프트(Microsoft)의 팀 파운데이션 서버(Team Foundation Server)는 범용성을 추구하고, 전문적인 것들은 SDK(Software Development Kit)를 사용하여 커스터마이징을 하거나, 3rd party 벤더의 몫으로 남긴다. 대인배적인 모습이긴 하지만, 현재까지도 여전히 팀 파운데이션 서버(Team Foundation Server)를 중심으로 한 생태계가 형성되지 않았다는 것 또한 단점으로 작용한다.

필자는 최근 아틀라시안(Atlassian)의 ALM 제품에 매력을 느끼고 있다. 각각의 기능들이 매우 뛰어나고, 필요하다면 언제든지 필요한 기능의 소프트웨어와 통합이 가능하다. 설치부터 통합까지 매우 간단하다. 그리고 어떤 운영체제에서도 설치와 운영이 가능한 ‘크로스 플랫폼(Cross-Platform)’ 이라는 점은 팀이나 조직에서 선택의 폭이 넓고, 또 하나, 데이터베이스, 웹 서버 등 선택의 폭도 넓다. (반면, 팀 파운데이션 서버(Team Foundation Server)는 설치는 쉽지만 구성(Configuration)이 복잡하고 운영(Operation)에 더 많은 리소스가 필요하다)

그리하여 앞으로 필자는 여러 ALM 솔루션을 벤치 마킹하면서 ALM 솔루션들 간에 장단점 등을 비교/분석하여 함께 공유할 예정이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

세션 저장소 커스터마이징

지금까지 살펴본 바 세션 정보를 memcached를 이용하여 세션 정보를 성능과 관리, 그리고 확장가능성 측면에서 만족할 만한 솔루션이다.

여기에서 좀 더 나아가 쿠키 등을 이용하여 서브 도메인(Sub Domain)의 웹 응용 프로그램에 인증을 하거나 브라우저를 닫고 새로운 브라우저로 재접속 한 경우 기존 세션을 유지할 수 있도록 기능을 개선할 수 도 있다.

과거에는 SSO(Single-Sign-On)을 구현하기 위해 쿠키로 서브 도메인을 인증하는 경우 domain 에 의해 쿠키가 공유가 가능하다는 점을 이용하여 구현하기도 했다. 물론, SSO 솔루션들이 많이 있었지만, 수천 수만명의 사용자가 관리 대상이 아니라면 굳이 비싼 SSO 솔루션을 쓸 필요는 없었다.

세션 저장 방법 커스터마이징

ASP.NET MSSQL Session Table 또는 Windows Azure SQL Session Table은 다음과 같이 정의된다. (MSDN에 정의된 테이블 참조 1)

CREATE TABLE [ASPState].dbo.ASPStateTempSessions (
    SessionId         nvarchar(88)  NOT NULL PRIMARY KEY,
    Created          datetime       NOT NULL DEFAULT GETUTCDATE(),
    Expires          datetime       NOT NULL,
    LockDate            datetime        NOT NULL,
    LockDateLocal     datetime      NOT NULL,
    LockCookie       int             NOT NULL,
    Timeout          int             NOT NULL,
    Locked           bit             NOT NULL,
    SessionItemShort    VARBINARY(7000) NULL,
    SessionItemLong  image        NULL,
    Flags             int            NOT NULL DEFAULT 0,
)   

CREATE NONCLUSTERED INDEX Index_Expires ON [ASPState].dbo.ASPStateTempSessions(Expires)  

CREATE TABLE [ASPState].dbo.ASPStateTempApplications (
    AppId             int            NOT NULL PRIMARY KEY,
    AppName          char(280)    NOT NULL,
)   

CREATE NONCLUSTERED INDEX Index_AppName ON [ASPState].dbo.ASPStateTempApplications(AppName)

이 두 테이블에서 가장 중요한 것은 다음의 두 개의 Private Key가 되는 필드이다.

  • AppId

    웹 응용 프로그램을 구분하는 고유 Id 값이다. IIS는 여러 개의 웹 응용 프로그램을 호스팅할 수 있는데, 이 웹 응용 프로그램을 구분하는 값으로 사용된다.

  • SessionId

    웹 응용 프로그램 내에 세션 키로 사용되는 값이다. 일반적으로 이 값은 해쉬된 값으로 중복되지 않는다.

따라서 여러 웹 응용 프로그램에서 같은 SessionId를 사용할 수 있다면 인증에 대한 SSO(Single-Sign-On)은 구현되는 것과 마찬가지다. 그러므로 위의 테이블 중 dbo.ASPStateTempApplications 테이블은 없어져도 된다.

만약 MS SQL을 사용하여 세션 저장소로 이용하는 경우 SQL Session Provider가 사용하는 Stored Procedure의 Where 절에 AppId를 빼기만 하면 된다.

필자는 SQL Server가 아닌 memcached를 이용하므로 위의 구성은 굳이 생략이 가능하다.

MemCached Session Store Provider 커스터마이징

ASP.NET은 클라이언트(웹 브라우저를 사용하는 사용자)를 구분하기 위해 해시된 세션 키 값을 사용한다고 했다. 이 해시된 값은 없어도 되지만, 웹 응용 프로그램 내부적으로 세션을 사용한다면 반드시 필요한 키 값이다.

클라이언트에게는 서버 내부적으로 사용하는 해시된 키 값을 쿠키에 저장하고, 서버로 요청이 오는 경우 이 쿠키 값의 해시된 세션 키 값을 이용하여 세션 데이터를 조회하게 된다. 만약, 이 해시된 세션 키 값이 없다면 새로운 세션으로 인식한다.

SSO를 구현하기 위해서 신원이 확인된 사용자마다 완전히 유일한(Unique)한 키 값이 필요하다. 예를 들어, 이 값은 사용자의 고유 번호가 될 수 있고, 사용자 아이디 또는 이메일과 같은 유일한 값이 되어야 한다. 세션 키는 매번 변할 수 있는 값이기 때문에 유일한 값이긴 하나 사용자마다 변하지 않는 유일한 값이 될 수 없다.

이를 구현하는 방법은 매우 간단하다. SessionStateStoreProviderBase 추상 클래스를 구현할 때 Id 값을 고의로 변경하면 된다.

public sealed class MemcachedSessionStateStore : SessionStateStoreProviderBase
{
   void Command(Action action)         
   { 
        var pool = SockIOPool.GetInstance(); 

        // 필자의 원격 memcached IPs     
        pool.SetServers(new string[] { "192.168.0.23:11211", "192.168.0.23:11211", "192.168.0.23:11211" }); 
        pool.InitConnections      = 3;
        pool.MinConnections       = 3;
        pool.MaxConnections       = 5;
        pool.SocketConnectTimeout = 1000;
        pool.SocketTimeout        = 3000;
        pool.MaintenanceSleep     = 30;
        pool.Failover             = true;
        pool.Nagle                = false;
        pool.Initialize();

        action();
   }

   public override void SetAndReleaseItemExclusive(HttpContext context, string id, SessionStateStoreData item, object lockId, bool newItem)
    {
        try
        {
            if (context.User.Identity.IsAuthenticated)
            {
                id = context.User.Identity.Name;
            }

            var data = new SessionData()
                {
                    Id      = id,
                    LockAge = TimeSpan.FromMinutes(10),
                    LockId  = id,
                    Exfires =  DateTime.Now.AddMinutes(10)
                }.ToBinaryBytes().ToBase64();

            Command(() => new MemcachedClient().Set(id, data));

        }
        catch (Exception e)
        {
            // 생략...
        }
        finally
        {
        }
    }

    public override SessionStateStoreData GetItem(HttpContext context, string id, out bool locked, 
                                                                                    out TimeSpan lockAge, 
                                                                                    out object lockId,
                                                                                    out SessionStateActions actionFlags)
    {
        return GetSessionStoreItem(false, context, id, out locked, out lockAge, out lockId, out actionFlags);
    }

    public override SessionStateStoreData GetItemExclusive(HttpContext context, string id, out bool locked,
                                                                                            out TimeSpan lockAge,
                                                                                            out object lockId,
                                                                                            out SessionStateActions actionFlags)
    {
        return GetSessionStoreItem(true, context, id, out locked, out lockAge, out lockId, out actionFlags);
    }


    public override void CreateUninitializedItem(HttpContext context, string id, int timeout)
    {
       if (context.User.Identity.IsAuthenticated)
        {
            id = context.User.Identity.Name;
        }

        var data = new SessionData()
        {
            Id = id,
            LockAge = TimeSpan.FromMinutes(10),
            LockId = id,
            Exfires = DateTime.Now.AddMinutes(10)
        }.ToBinaryBytes().ToBase64();

        Command(() => new MemcachedClient().Set(id, data));
    }

    public override SessionStateStoreData CreateNewStoreData(HttpContext context, int timeout)
    {
        return new SessionStateStoreData(new SessionStateItemCollection(), SessionStateUtility.GetSessionStaticObjects(context), (int)timeout);
    }

    private string Serialize(SessionStateItemCollection items)
    {
        var ms = new MemoryStream();
        var writer = new BinaryWriter(ms);

        if (items != null)
            items.Serialize(writer);

        writer.Close();

        return Convert.ToBase64String(ms.ToArray());
    }


    private SessionStateStoreData Deserialize(HttpContext context, string serializedItems, int timeout)
    {
        var ms = new MemoryStream(Convert.FromBase64String(serializedItems));
        var sessionItems = new SessionStateItemCollection();

        if (ms.Length > 0)
        {
            var reader = new BinaryReader(ms);
            sessionItems = SessionStateItemCollection.Deserialize(reader);
        }

        return new SessionStateStoreData(sessionItems, SessionStateUtility.GetSessionStaticObjects(context), timeout);
    }  

// 이하 생략...  
// 이하 생략...  
// 이하 생략...

}  

인증된 사용자와 인증되지 않은 사용자의 세션 데이터

필자는 memcached의 사용자 세션 키를 다음과 같이 정의하여 구현하였다.

  1. 인증되지 않은 사용자는 해쉬된 세션 키를 사용한다.
  2. 인증된 사용자는 인증 정보를 세션 키로 사용한다. (UserName 정보)

모든 클라이언트의 웹 브라우저 쿠키에 ASP.NET 세션 키가 ASP.NET_SessionId 쿠키 값으로 저장된다. 이 값은 ASP.NET이 생성한 해쉬된 값이므로 언제든지 변할 수 있다가도, 사용자가 웹 응용프로그램에서 인증을 하게 되면 해쉬된 세션 키를 사용하지 않고 사용자 계정으로 세션 키 값을 대체하게 된다.

이 코드가 위의 코드 중에 다음과 같이 구현한 부분이다.

if (context.User.Identity.IsAuthenticated)
{
    id = context.User.Identity.Name;
}

그럼 현재까지 구현된 부분으로 다음과 같은 시나리오로 테스트를 하고 결과를 보자.

  1. 익명으로 웹 사이트 접속
  2. 익명 사용자의 세션 키 값을 memcached 에서 조회 (해쉬된 세션 키 rlvh3y4edt1nyzrt42sdgnvu)
  3. 웹 사이트 로그인 (로그인 사용자 계정 powerumc)

  4. 인증된 사용자의 계정으로 memcached 에서 조회

그럼 분산된 웹 응용 프로그램이나 다른 도메인의 웹 응용 프로그램 간에 서로 인증을 해보자. 폼 인증을 사용한 웹 응용 프로그램이므로 다른 웹 응용 프로그램에 폼 인증을 시킬 수 있는 방법만 있으면 된다. 웹 응용 프로그램 간에 토큰 값을 넘길 수 도 있고, 또는 요즘 유행하는 다른 인증 매커니즘을 이용할 수 도 있다.

어쨌든 서로 다른 웹 응용 프로그램이 하나의 memcached 세션 서버에 연결이 가능하다면 신원이 인증된, 위에’서 테스트 한 사용자 계정 ‘powerumc’는 어느 웹 응용 프로그램에서 세션을 조회하더라도 존재하게 된다.

사용자는 웹 브라우저를 완전히 닫거나 운영체제를 완전히 재시작하였다고 하더라도 세션이 만료되는 통상적인 시간인 약 20분 이전에 로그인만 한다면 이전에 저장된 세션 데이터를 가져와 마지막의 최신 상태를 유지할 수 있게 된다.

결론

지금까지 memcached를 이용하여 Session State Store Provider를 만들고 이를 활용하는 방법을 알아보았다. 분산된 세션 저장소를 사용해야 하는 경우 memcached를 이용하면 신뢰된 성능을 보장받을 수 있고, 세션 데이터를 유지하는 방법을 변형하여 좀 더 보안을 높이거나 유연하게 상호운용을 가능하도록 할 수도 있다.

  • 분산된 세션 저장소를 확장
  • memcached를 이용하여 신뢰할 수 있는 성능 발휘
  • 세션의 보안을 강화하거나 격리시킬 수 있는 방법이 가능
  • 세션의 상호운용성을 높여 서로 다른 도메인간에 인증 가능
  • 서로 다른 도메인간에, 서로 다른 플랫폼 간에 세션 데이터 공유 가능

이 외에 여러 가지 기법들을 활용하여 더 많은 것들을 가능할 수 있다. 세션의 활용이 웹 개발 플랫폼에서 그만큼 중요하고 보안과 직결되는 요소인 만큼 이 기회에 세션에 대한 내용을 모두 정복해 보기 바란다.

  1. MSDN에 정의된 테이블 참조 http://msdn.microsoft.com/en-us/library/aa478952.aspx


Posted by 땡초 POWERUMC

댓글을 달아 주세요

필자는 일전에 이와 관련되어 상당한 분량의 포스팅을 올린 적이 있다. 총 5회의 아티클 중 마지막 회를 모두 작성하지는 못했지만, 지금 이 내용이 그 마지막 회의 내용과 어느 정도의 내용과 유사하다고 보면 된다.


그 중, 4회 아티클 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]5’의 내용은 본 아티클의 내용에서 매우 중요한 기초 내용이 된다. 이 글을 읽고 있는 독자 중 잘 이해가 되지 않는다면 필자가 이전에 작성한 포스팅을 반드시 읽어보기를 바란다.

그리고 위의 필자가 작성한 링크의 아티클은 5년전에 작성된 글임을 인지해 주길 바란다. 그 때는 필자가 지금보다도 더 실력이 형편 없었을 뿐더러 현재 추구하는 웹 개발의 트랜드와 상이한 면이 있을 수도 있을 것이다. .NET Framework 버전과 개발툴의 버전도 지금 사용하는 버전과는 한참 예전 버전이었다. 하지만 5년이 지난 글임에도 기초적인 내용은 모두 탄탄하게 짚고 넘어가므로 한번씩 보는 것도 나쁘지 않다.

ASP.NET이 지원하는 분산 세션 상태(Session State)

일반적으로 1대 1의 물리적인 관계는 분명 분산환경이긴 하지만 분산 환경이라고 말하지 않는다. 어떤 물리적인 환경에 배치하든, 통계학의 분산에 대한 기대값이나 편차의 해는 변하지 않기 때문이다.

분산 환경에서 더 나은 성능을 내기 위한 알고리즘과 휘발성인 메모리 안에서 데이터가 유실되지 않도록 원자성(Atomicity)을 유지할 수 있는 방법을 제공해야 한다. 또 웹 서버의 세션이라는 특징은 매우 빈번하게 엑세스 되고, 업데이트와 삭제 작업도 매우 많이 발생한다.

하지만, 안타깝게도 memcached[1]는 ‘get’ 명령의 원자성(Atomicity)를 보장하지 않는다고 한다.

A series of commands is not atomic. If you issue a 'get' against an item, operate on the data, then wish to 'set' it back into memcached, you are not guaranteed to be the only process working on that value. In parallel, you could end up overwriting a value set by something else.


하지만 괜찮다. 웹 서버의 세션은 동시다발적인 병렬 작업으로 요청이 들어올 수 없는 구조이다. 웹 서버로 사용자의 요청이 들어올 때, 사용자의 웹 브라우저에 가진 쿠키 값이 신원보증을 하는 값, 또는 해시된 세션의 키 값이다. 그러므로 한 세션에 대해 동시에 여러 클라이언트(사용자 웹 브라우저)의 요청은 있을 수 없는 일이다.

하지만 불가능한 것도 아니다. 예전에는 자바스크립트가 허용되는 게시판이나 이와 유사한 환경에서 악성 스크립트를 심어 놓으면, 그 글을 보는 누군가는 브라우저의 쿠키 값을 취득하여 해커에게 보내고, 해커는 세션이 만료되는 20분(일반적인 세션 만료 시간) 전에 취득한 세션 값으로 재 요청을 하게 되면 다시 세션이 연장되고, 세션이 로그인된 상태인 경우 해커도 로그인된 상태로 입장하는 것이 가능하다

때문에 완전히 같은 해시된 세션의 키 값으로 여러 클라이언트(사용자의 웹 브라우저)의 요청이 온다는 것은 사용자의 세션 값이 털려서, 누군가 악용하고 있다고 보는 것이 맞다.

그러므로 아주 정상적이고 일반적인 환경에서 원자성을 제공하지 않는 ‘get’ 명령은 전혀 문제가 되지 않으며, 오히려 원자성을 보장할 수 없는 문제로 더 좋은 Read 성능을 낼 수 있기 때문에, memcached 가 세션 서버로 사용하기에 redis[2] 보다 더 좋을 수 있다.

ASP.NET이 제공하는 세션 관리 요약

아무런 설정이 없다면 In-Proc, 즉 로컬 머신의 메모리를 사용하게 된다. 만약 불행히도, Win32 DLL을 참조하는 웹 응용 프로그램이라면 웹 서버의 메모리의 크기 따윈 무시하고 최대 2GB 밖에 사용할 수 없게 된다.

이를 극복하는 방법으로 윈도우 서비스로 백그라운드로 실행되는 ASP.NET Session State Service 서비스를 사용하면 좋다. 여러 웹 응용 프로그램이 하나의 Session State Service에 연결되더라도 웹 응용 프로그램마다 고유의 Identity Key(Guid)가 할당되고, 이를 Primary Key로 구분하게 된다. 이 NT Services가 다운되거나 재시작하지 않는 이상 웹 서버의 세션은 항상 유지할 수 있다.

긴급한 패치로 웹 응용 프로그램을 업데이트 해야 하는 경우, IIS가 재시작 되는 경우가 발생할 수 있는데 이 때 Worker Process에 의해 구동되는 In-Proc 세션 정보는 모두 초기화된다. 웹사이트에서 뭔가를 구매하려는 사용자가 있었다면 큰 사고로 이어질 수 있지만, Session State Service에 세션 정보가 저장이 되므로 IIS 재시작 후에도 웹 응용 프로그램은 세션 정보를 모두 안전하게 유지할 수 있다.

보통 웹 서버와 Session State Service간에 통신을 하기 위해 방화벽의 특정 포트를 개방해야 하고, 내부적으로 서로 간에 소켓 통신에 사용되는 전용 프로토콜이 존재하므로 Session State Service를 확장하기란 쉽지 않을 것이다.

이런 경우, ASP.NET에서 MS SQL Server를 이용하여 세션 정보를 저장하는 방법을 제공해 준다. 세션 정보에 추가하고 싶은 정보나 DB상에 기록되어질 특정 필드를 추가하여 사용할 수 있고, Oracle 또는 MySQL을 사용하여 세션 상태를 저장할 수도 있다.

위의 링크 중 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]13’에 예제로 구현된 Oracle Session Store Provider 예제가 있으니 참고하길 바란다.

memcached를 이용하는 세션 저장소

memcached를 세션 저장소로 이용하는 것은 ASP.NET Session State Services의 역할과 구현만 다를 뿐이지 매우 유사하다. memcached도 메모리를 저장소로 이용하여 빠르게 캐시하고 요청에 빠르게 응답할 수 있는 간결한 구조로 구현된 오픈소스이다.

특히 memcached를 이용할 경우 ASP.NET Session State Services로 불가능한 클러스트링이 가능하기 때문에 수평적으로 세션 서버를 확장할 수 있다. 한 대의 세션 서버만 있는 경우보다 로드벨런싱의 자유도가 더 높고, 세션 서버의 장애에도 대처가 가능하다. 또 하나의 장점이라면 저가형 장비를 병렬로 구성이 가능하기 때문에 세션 서버를 구성하기 위한 금전적이거나 물리적인 많은 제약이 사라지게 된다.

memcached와 redis, 두 가지 오픈소스를 고려하고 있었는데, 세션 서버에 memcached가 더 적합하다고 생각하여 memcached만 다룬다. memcached의 소스 코드가 더 가볍고 취향이나 요구사항에 따라 코드를 변형하기에 더 적합하지 않을까 생각한다. 그리고 자칫 복잡해질 수 있는 구조적인 아키텍처를 좀 더 간결한 memcached로 표현하는 것이 글을 보는 입장이나 쓰는 입장에서 편하다고 믿는다.

memcached는 C언어로 구현이 되어있고, GNU C 표준 라이브러리를 사용하므로 여러 운영체제에서 사용이 가능하다. (ASP.NET Session State Services는 윈도우 환경에서만 사용이 가능하다) 물론 필자는 맥킨토시, 리눅스, 윈도우에서 memcached를 컴파일, 구동이 잘 됨을 확인하였다.

간단하게 사용자의 세션 정보를 저장할 클래스를 하나 간단하게 만들었다. 외부에서는 오직 참조만 하여 사용할 수 있도록 internal 생성 메서드를 하나 가지고 있다.


다음은 ASP.NET MVC 프로젝트로 만든 간단한 예제이다.

web.config
1
2
3
4
5
6
<sessionState mode="Custom" customProvider="MemcachedSessionStateStore">
    <providers>
        <add name="MemcachedSessionStateStore"
             type="Umc.Core.Web.SessionState.Memcached.MemcachedSessionStateStore, Web.SessionState.Memcached, Version=1.0.0.0, PublicKeyToken=eed8f2bc3bfc4c7a, Culture=neutral"/>
    </providers>
</sessionState>

  

HomeController.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class HomeController : Controller   
{
   private static readonly string KEY_OF_USER_SESSION = "__USER_SESSION_KEY__";
   public UserIdentity SessionStore
    {
        get { return (Session[KEY_OF_USER_SESSION] as UserIdentity) ?? UserIdentity.Empty; }
        set { Session[KEY_OF_USER_SESSION] = value; }
    }
 
 
    public ActionResult Index()
    {
        Session[KEY_OF_USER_SESSION] = UserIdentity.New("POWERUMC"
                                                        , "Junil, Um"
                                                        , "powerumc at gmail.com");
 
 
         /*
          // 맴버쉽 사용자 인증 설정 생략...
        var ticket = new FormsAuthenticationTicket(...);
        var user = new GenericPrincipal(new FormsIdentity(ticket), ... )
         * */
 
 
        return View();
    }
}

 

위와 같이 클라이언트의 세션 키를 이용하여 memcached의 서버에 세션 키를 이용하여 세션 값을 저장한다.

telnet 'get' 명령 결과
MPOWERUMC:~ powerumc$ telnet 192.168.0.23 11211
Trying 192.168.0.23...
Connected to 192.168.0.23.
Escape character is '^]'.
get laaymm13uyu03bofhdydi4iq
VALUE laaymm13uyu03bofhdydi4iq 0 477
AAEAAAD/////AQAAAAAAAAAMAgAAAF1XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZCwgVmVyc2lvbj0xLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWVlZDhmMmJjM2JmYzRjN2EFAQAAAEpVbWMuQ29yZS5XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZC5NZW1jYWNoZWRTZXNzaW9uU3RhdGVTdG9yZStTZXNzaW9uRGF0YQQAAAATPElkPmtfX0JhY2tpbmdGaWVsZBg8TG9ja0FnZT5rX19CYWNraW5nRmllbGQYPEV4ZmlyZXM+a19fQmFja2luZ0ZpZWxkFzxMb2NrSWQ+a19fQmFja2luZ0ZpZWxkAQAAAgwNAgAAAAYDAAAAGGxhYXltbTEzdXl1MDNib2ZoZHlkaTRpcQC8oGUBAAAAAPAWAzAi0IgJAwAAAAs=
END

 

 

ASP.NET의 세션이 실제로 저장이 되었는지 확인해보자. telnet을 통해 memcached 포로토콜의 명령을 입력하여 확인하면 된다.

현재 브라우저에서 연 세션 값은 쿠기에 저장이 되어 있다. 쿠키에 저장된 세션의 키 값은 ‘laaymm13uyu03bofhdydi4iq’ 이다.


telnet에 접속하여 memcached에 저장된 세션 키의 값을 조회된다.

memcached 세션 저장소로써 활용

memcached 오픈 소스 솔루션을 이용하여 메모리 캐시를 이용하여 ASP.NET 세션 상태를 저장할 수 있도록 구성해 보았다. 이제 얼마나 좋은 성능을 낼 수 있는지 측정이 필요한데 본 아티클에서는 memcached를 세션 서버로 활용할 때에 대한 성능의 문제는 다음에 기회가 되면 더 심도있게 다루어 보도록 하겠다.

그리고 ASP.NET 뿐만 아니라, JSP 또는 Servlet, 그 외에 여러 웹 개발 프레임워크에서 쉽게 사용할 수 있다. memcached는 C#, Java, Python 등 여러가지 언어로 memcached서버에 연결할 수 있는 클라이언트 라이브러리를 어렵지 않게 찾을 수 있다.

이번 아티클에서는 MemcachedSessionStoreProvider 소스 코드를 제공하지 않았다. 물론, 필자의 위 코드를 실행하기 위해 MemcachedSessionStoreProvider 소스 코드가 있어야 한다. 이 코드는 다음 아티클에서 조금씩 작성해 나갈 예정이다.

memcached 에 대한 자세한 내용은 아래 링크의 구글 코드에 들어가면 컴파일 및 실행 방법과 유지관리 방법에 대한 위키가 있다.

memcached wiki, https://code.google.com/p/memcached/wiki/NewStart



[1]: C언어로 구현된 고성능 분산 메모리 객체를 캐시하는 서버. Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

[2]: 키/값을 저장할 수 있는 분산 서버로 데이터의 구조체 뿐만 아니라 문자열, lists, 빠른 검색을 위한 hashes 등을 지원. Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain stringshasheslistssets and sorted sets.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]
[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]


지난 1편의 글에 이어, 어떤 분이 원문을 쓰신 분에게 이런 말을 남겼다.

이 코멘트에 대해 원문을 쓰시는 분은 아래의 링크로 반박의 글을 작성하셨다.

원문 : http://imjuni.tistory.com/488

   


필자의 입장에서는 상용 솔루션이 커스터마이징을 해야 쓸만한 제품이란 것은 제품을 구매한 사용자 입장에서는 그리 달갑지는 않을 것이다. 대신 3rd party 벤더나 오픈 소스를 이용하여 기능을 더 보탤 수 있고, SDK API를 이용하여 직접 도메인 제약에 맞게 만들 수도 있을 것이다.

원문을 읽어보면 저 분은 TFS에게 어떻게 데였는지 모르겠지만, 병적으로 거부하는 것 같다. 그렇다고 싫어하는 이유에 대해 근거가 있거나 정확하게 잘못된 정보를 바탕으로 작성이 되었다는 것에 매우 안타까움을 느낀다.



첫 번째로, 위의 원문에서 아래와 같이 잘못된 정보를 가지고 있다.

   

일단 TFS에서는 VCS 기능을 어느 정도 확장을 할 수 있다. 이때 TFS Server는 물론이고, 클라이언트인 Visual Studio Extensibility를 이용하여 클라이언트도 확장할 필요가 있다. 이는 비단 TFS 뿐만이 아니라 SVN도 마찬가지다. 고로 어느 범위까지 확장할 것인가 결정에 따라 개발을 해야 할 범위가 틀려질 수 있다.

   

두 번째로, TFS를 Git와 비교한다는 것은 좀 무리가 있다고 본다.

Git는 유명한 리눅스를 개발한 리누스 토발즈에 의해 분산 버전 관리할 수 있는 소스 제어 솔루션이다. 분산 버전 제어가 자칫 매우 유연해 보일 수 도 있을 것이다. 이에 반해, TFS는 중앙 집중 방식의 소스 제어 솔루션이다.

기업에서 통제가 되지 않는 소스 제어는 보안적인 이슈나 소스 코드 유출 등의 사고가 생기가 마련이다. 이런 점에서 분산 버전보다 중앙 집중 방식이 기업에서 개발 환경 조건에 더 부합한다고 본다.

이런 장단점 등으로 오픈 소스를 지향하는 사람들은 분산 버전 관리 방식인 Git를 선호한다.

반면에, TFS는 TFS란 제품이 나오기 전부터 Microsoft 내부적으로 이슈 관리와 소스 제어를 할 수 있는 솔루션을 만들어 사용하고 있었다. Microsoft는 소프트웨어 기업이다. 소프트웨어를 잘 개발할 수 있도록 Team Foundation이라는 제품으로 발전하면서 상당히 많은 노하우가 녹아있는 제품이다.

SVN는 CVS가 Atomic Transaction(원자성)이 보장되지 않는 이유의 심각한 문제로, SVN으로 다시 태어났다.

   

원문을 쓰신 분은 필자가 이해하기 힘든 이유로 CodePlex와 Git를 비교하는 것은 '중국이 한국보다 인구가 많으니 강대국이다.'라는 논리와 같다.

잘못된 정보만을 가지고 TFS를 혐오하는 것은 바람직하지 않다고 본다. 안된다고 하는 많은 기능들이 이미 예전부터 지원했던 것인데 원문을 쓰신 분은 이런 기능을 이용하는 방법을 몰랐던 것이지, TFS 자체의 문제는 아니다.




이런 말을 해주고 싶다.

도구는 단지 도구일 뿐이다.
쓰는 사람이 잘 써야 좋은 도구이다.
잘 쓸 수 없는 도구는 그 사람의 잘못이지 도구의 문제가 아니다.
 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 나그네 2013.01.13 17:36 Address Modify/Delete Reply

    git 든 svn 툴이든 오픈소스 제품군만으로도 충분 해서. .굳이 tfs 도입할 이유가 생각나지 않는군요.

    vs 플러그인으로 연동하면 그만이라서..

  2. JIN 2016.08.29 11:56 Address Modify/Delete Reply

    정성스레 작성하신 글 잘 보고 갑니다..
    TFS를 프로젝트에 처음 적용해 나가면서 어떤것인가 하고 경험해 가는 중에 포스팅 하신 몇몇 글들을 읽었습니다. ALM툴/서비스는 처음인지라 TFS가 정말 적당한지 어떤지에 대한 개념도 없이 아래의 몇가지 장점만으로 선택을 했습니다.
    처음엔 제목만 보고 아뿔싸 'TFS' 문제가 많은가보다 하고 심장이 쫀득해졌다가,
    객관적으로 분석해주신 내용을 보고 오히려 최고는 아니었어도 현재로써는 적절한 선택이었다는 생각이 들더군요..

    1. 현재 팀원이 1.2(12명 아닙니다 ㅎㅎ)명.. TFS 정책상 부담없이 쓸수 있고, 중장기적으로 팀이 5명까지 커질일이 없다는점
    2. 현재 Visual Studio를 사용중이며
    3. 1의 이유로 새로운 툴/서비스에 대한 시장조사/검증 자체가 부담
    4. 중앙 집중식 버전 컨트롤
    5. 그나마 접하고, 본게 이것
    6. 처음엔 단지 소프트웨어 버전컨트롤 이상도 이하도 아닌 이유로 사용함
    7. FDA 승인을 필요로 하는 제품 개발과 깊은 관련이 생기면서 Validation 문제에 봉착
    (FDA regulation 의 Validation 입니다 이는 Software의 Validation과는 다른 훨씬더 확장된 내용을 다루고 있습니다. 첨언하면, Software의 Validation하면 Software의 Specification과 Use case를 따르는 기능의 검증이 촛점이라면, FDA의 것은 SDLC를 어우르는 광범위한 Traceablity, 시스템 검증, 변경 관리 등등.. 전사적으로 등골빠지는 것중의 하나가 FDA 승인이죠..)
    8. 다만 7의 결과물이 Documented Evidence 가 되어야 하는게 FDA의 요구사항입니다. TFS내의 WORK ITEM과 Design Specification, Code, Test, Debug(issue) 등의 결과물이 문서상에 존재해야 한다는것이었죠.. 이 작업은 사람을 미치게도 할수 있는 부분입니다.. ㅎㅎ 이부분은 TFS에서도 직접적으로 문서화를 위한 솔류션을 통합한것은 아닌거 같더라구요 때문에 Modern Requirements라는 솔루션을 채택했습니다.. 이는 TFS상의 WORK ITEM의 부모자식관계 변경 이력, User Requirements, Design Specification, Code, Test, Debug(Issue) 의 Traceability등을 자동으로 생성해주는 역할을 합니다..
    9. 그 외에도 TFS가 'Microsoft' 라는 알려진 기업의 솔루션이기에 직접 구축한 Opensource based 시스템이나 시장에 인지도가 없는 회사의 솔류션일 경우 FDA의 Audit시에 수없이 많은 질문을 야기할 가능성을 줄여줄수 있다는 점도 큰 몫이었습니다.

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]





 
예전에 인터넷에서 자료를 찾는 중에 Team Foundation Server를 무척 혐오한다는 사람의 글을 읽게 되었다. 매우 잘못된 정보로 Team Foundation Server와 Visual Studio를 바라보는 것을 매우 안타깝게 생각한다. 이 글을 작성된 지 1년 정도 되었는데, 필자는 오늘에야 비로서 이 내용을 바로 잡고자 한다.

필자는 Microsoft 제품과 직접적으로 관련되지도 않았고, 더 이상 Microsoft MVP도 아니다. 그러므로 필자의 답변은 최대한 중립적인 입장에서 작성하였다. 물론, 필자는 Team Foundation Server를 사용한다. 하지만, 반드시 Team Foundation Server만 사용하지는 않는다.

그리고 글의 작성자는 Team Foundation Server의 기능과 Visual Studio IDE 기능을 모두 Team Foundation Server의 문제로 지적하고 있다. 이런 툴의 기능에 대한 혼돈이 있어 필자의 답변 또한 편의상 글 작성자의 의도에 맞게 Team Foundation Server로 통일하였다.

아래의 원문의 글을 작성하신 분의 글은 검은색이고,
필자가 답변한 글은 어두운 붉은 색으로 표시하였다.




원문 : 
http://imjuni.tistory.com/464 


 

단순한 거부 반응이 아니라 왜 TFS를 쓰기 싫을까? 개인적으로 TFS를 정말 오랫동안 써보고 또 TFS를 이용하여 공동 작업을 해보기도 한 결과 TFS는 정말 사용해서는 안될 도구라는 사실을 지속적으로 느꼈고, TFS를 제발 쓰지 않았으면 하는 생각을 계속 하게 되었다. 하지만 TFS는 생각보다 사용되는 곳이 많다. 그 이유는 가장 적은 비용으로 ALM 도구를 도입할 수 있다는 것 때문에 TFS를 도입하게 된다. 그런데, 가장 큰 문제는 ALM을 위해서 TFS를 도입하면 반대 급부로 TFS 때문에 개발자의 생산성이 저하되어 TFS를 도입한 비용만큼 개발자의 생산성이 저하된다. 그리고 제발 TFS가 가지는 ALM 기능이 VCS에 포함된다는 착각은 하지말자. Work item을 생성하거나 체인지 셋을 묶거나 추적하는 등의 기능은 ALM이면서 Issue Tracker이기 때문에 가능한 기능들이다. 이러한 기능은 Jira 또는 Code Beamer, Trac, Launchpad 와 같은 도구에서 제공하는 기능이지 SVN이나 Mercurial에서 제공하는 기능이 아니다. 정말 이런 대착각은 하지말자. 또한 Martin Fowler가 조사한 Vcs Survey에 따르면 TFS의 인지도는 0%다. 정말로 0%다. 링크를 따라가면 확인할 수 있다. 설마 Martin Fowler가 이름 없는 사람이고 그래서 그 조사를 믿을 수 없다는 이야기는 하지말자. Martin Fowler는 그 유명한 Refactoring의 저자이자, 애자일과 관련하여 아주 유명하신 분이다.


왜 TFS를 쓰면 안될까? 번역과 경험을 토대로 이 글을 써보자.

1. 크기: 이 부분은 MS가 참 미쳤다. SVN은 TortoiseSVN을 쓰면 15MB 많아야 20MB면 충분하다. 심지어 자체 웹서버가 내장된 tortoiseHg도 24MB면 충분하다. 웹서버도 없고 아무것도 없는 TFS는 Visual Studio Extension이라는 이유로 VS 필수 구성요소를 모두 설치해야 되기 때문에 200MB가 넘는다. 솔직히 요새 200MB면 껌이기 때문에 그리 부담도 되지 않지만 타 시스템과 비교하였을 때 10배 이상 크기가 큰 것은 확실하다. 넷북이나 가벼운 시스템에서 구동시키는 것은 확실히 부담되는 크기임이 자명하고, 부인해서도 안될 것이다. 뿐만 아니라 덩치가 크다는 것은 그만큼 메모리를 많이 소비한다는 뜻과 동일하다. TFS는 그만큼 가볍지도 않고, 용량도 많이 차지하는 거대 도구라는 것을 인정해야 한다.

SVN의 용량과 TFS의 설치 용량을 비교하는 것은 의미가 없다.

 
Team Foundation Server(이하 TFS)는 설치 시에 소스제어 기능만 선택적으로 설치할 수 없다. 그래서 설치 시에 모든 기능이 포함하여 설치하게 되는데, 이 중에는 소스제어, 작업항목, 빌드, 팀 탐색기(소스제어 클라이언트) 등이 모두 포함된다. 그리고 이 기능이 원활하게 동작하기 위해서 VC++ 재배포 패키지, .NET Framework 재배포 패키지 등이 설치 파일에 모두 포함이 된다.

 
마찬가지로 SVN을 소스제어로 이용하고, 그 외에 빌드, 이슈 트래킹 툴  등을 모두 갖추고 설치한다면 TFS보다 설치 용량이 더 많아질 지도 모른다.


그래서 용량이 크다는 이유로 TFS가 싫다는 이야기는 이야기의 논재에 벗어난 것 같다.





2. 읽기 전용 파일: 왜 이런 구조로 개발 되었는지 이해할 수 없지만 TFS에서 관리하는 모든 파일은 읽기 전용이다. 파일을 고쳤다고 하더라도 실제로 체크 아웃을 한 것이 아니라면 전혀 반영되지 않으며 이를 알 수 있는 방법은 Visual Studio 탭에 표시된 잠금 표시와 저장할 때가 되어서야 나오는 읽기 전용이므로 이를 해제해 달라는 말을 보았을 때다. 이 경우 일단 저장을 하고 다시 체크인을 한 뒤 다시 또 저장을 해야 한다. 만약 이 와중에 충돌이 발생하면 끔찍한 결과를 초래 한다. 읽기 전용 파일이 문제가 되지 않는다고 주장하는 사람은 빈번하게 충돌이 발생하는 환경에서 개발을 해보지 않은 것으로 판단 된다.

TFS의 소스를 파일을 내려받은 클라이언트의 파일은 읽기 전용이라는 점은 필자로 여러모로 불편한 점이 있다고 생각한다. SVN과 비교하자면 불편한 점이 확실히 맞다. 

 
TFS는 윈도우 탐색기나 커맨드 라인을 통해 파일을 수정하려 한다면 읽기 전용 파일이기 때문에 수정하여 저장할 수 없다. 이 경우 읽기 전용 파일 속성을 해제해 주어야 한다. 하지만, 수정하려는 파일을 체크인 하려고 한다면, 먼저 체크아웃을 해 주어야 한다. 체크 아웃을 하지 않으면 체크인 시에 수정된 파일로 간주하지 않기 때문에 변경 집합에서 제외되므로 체크인을 할 수 없다.

반면, SVN또는 기타 소스제어에서는 윈도우 탐색기 등에서 파일을 수정하면 알아서 체크아웃을 시키거나 체크아웃 과정을 자연스럽게 유도한다. 

이 부분에서 불만을 주장하신 분은 '일단 저장을 하고 다시 체크인을 한 뒤에 다시 저장을 해야 한다'는 방법은 잘 이해하기도 어렵거니와 잘못된 방법이다. 이 경우 필자가 이야기 한 것처럼 강제로 수정한 파일은 언제든지 다시 체크아웃을 한 후에 체크인을 하면 된다. 단, 특정 버전 받기를 하게 되면 모든 파일을 덮어씌우기 떄문에(Overwrite) 체크인 전에 특정 버전 받기를 실행하면 안된다. 물론 이런 경우는 극히 드물겟다. (최신 버전 받기는 변경된 파일만 덮어씌우므로 최신 버전 받기는 강제로 수정한 파일이 안전하게 수정된 내용으로 보존된다.)

하지만, 불만을 주장하신 분의 이야기 처럼 빈번하게 충돌이 발생하는 환경이라면 어떤 소스제어 솔루션을 사용하더라도 빈번하게 충돌이 발생하게 되어있다. 이런 충돌 상황을 빈번하게 겪어 충돌을 피할 수 있는 경험적인 감각을 익힐 수 있을 정도의 지능을 가진 사람이라면 대부분의 충돌이 발생하는 상황을 최대한으로 피할 수 있다.





3. 솔루션 파일 수정 무한 반복: 몇 가지 상황이 되면 이 경우를 만나게 된다. 예를 들면 VPN으로 사내 망에 접근할 때 TFS 서버 이름이 변경되는 경우 이다. 이 때 VPN으로 접근한 사람이 솔루션 파일에 TFS 이름을 바꾸면 나머지 사람은 그 솔루션 파일을 받은 뒤 다시 바꿔야 하고, VPN 작업자는 또 바꾸고, 이러한 무한 반복이 실행 된다. 또 다른 경우로는 솔루션 파일이 바인딩 되지 않은 경우 솔루션 파일을 바인딩 하기 위해서 솔루션 파일을 변경하고 다른 사람은 그 바인딩 정보를 솔루션 파일에 기록하기 위해서 변경하고 그러면서 자신에게 바인딩 하는 과정을 또 거치는 등 역시 무한 반복이 실행 된다. 발생하는 일 자체는 그리 짜증나지 않지만 무한한 반복으로 인해서 체인지셋 관리에 어려움을 겪게 된다. Subversion 또는 Mercurial은 근본적으로 이러한 일이 발생하지 않는다. 두 VCS에서 프로젝트 파일이란 단순히 관리가 필요한 텍스트 파일에 불과하기 때문이다.

이 부분은 글을 작성하신 분의 의견에 공감한다.


다만, SVN의 경우는 소스제어 바인딩 정보가 .svn 숨김 폴더에 저장되기 때문에 이런 문제가 발생하지 않지만, 폴더마다 .svn 숨김 폴더에 캐시된 데이터가 쌓이는 문제도 함께 가지고 있다. SVN 최신 버전에서는 폴더마다 .svn 숨길 폴더가 만들어 지는 문제를 최상의 폴더 한 곳에만 생기게 하도록 수정되었다고 한다.




4. .net 안쓰는 사람: Java 또는 PHP, Ruby, Python 등을 이용하여 개발할 경우 TFS로 인해서 얻는 반사 이익이 급격히 줄어든다. 솔루션 파일을 통한 간편한 프로젝트 추가 기능을 사용할 수 없고 디렉토리를 통채로 삽입할 경우 바이너리 파일이나 의미 없는 파일을 일일히 GUI로 제거해 주어야 한다. 반면 TortoiseSVN 또는 TortoiseHg는 Ignore list를 편집하여 간편하게 복수 파일을 관리하지 않을 수 있다. 또한 다른 도구와 다르게 비교 도구를 자체적으로 지정할 수 없고, 체인지셋 간 비교가 원활하지 않다. 이와 같은 단점으로 인해서 생산성이 저하 된다. 또한 Maven, Ant와 같은 오픈 소스 빌드 도구를 사용할 수 없고 MSBuild와 같은 도구만 사용가능하여 TFS 장점을 취하기 힘들다. 만약 Eclipse, Aptina 등과 같은 도구를 사용할 때는 2개의 IDE를 사용하거나 Teamprise를 사용해야 하는데 Teamprise는 MSDN Account가 있을 때 무료이다. Visual Studio Ultimate with MSDN 라이센스가 필요하다. 따라서 .net을 사용하지 않는 사람은 추가 비용이 발생할 수 있다는 것을 확실히 인지해야 한다.

필요 없는 파일의 확장자를 필터링하여 통채로 소스제어에 바인딩 또는 체크인할 수 있는 기능은 예전부터 TFS에 있는 기능이다. 그리고 비교 도구로 파일이나 체인지 셋, 폴더 등 비교하는 기능도 사용자가 별도로 설정할 수 있는 기능이 예전부터 존재한다.

그리고 라이센스 부분에서 TFS가 상용 솔루션인 점을 감안하면 당연히 클라이언트 라이센스 정책이 있다는 점은 당연하지 않을까?

이 부분도 다시 확인해 보시길...





5. Same Directory Archive: 사용자 디렉토리 경로와 TFS 경로를 일치 시키는 일을 한다. 사실 SVN과 Mecurial, Git와 같은 도구는 Point to Point, Central Repository의 특정 지점과 지점을 프로젝트로 연결함으로서, TFS 처럼 경로를 강제하지 않는다. TFS가 경로를 강제한다는 말은, Repository에 만들어진 Directory structure가 실제 사용자 Directory structure와 일치시킨다는 것이다. 일반적인 VCS에서는 프로젝트 단위로 연결하기 때문에 프로젝트 하위 Directory structure는 관리되지만 프로젝트 상위 Directory structure는 따로 관리하지 않는다. 관리하지 않더라도, VCS 자체에서 branch 별로 Directory를 만들거나 구조적인 관리가 가능하지만 사용자는 최종적으로는 프로젝트와 프로젝트가 연결되는데 반해 TFS는 프로젝트 상위, 하위 모든 Directory structure를 일치 시킴으로서 불편을 유발한다. 예를 들면, A, A', A'' 프로젝트가 있다고 가정하면 A'와 A''는 A 프로젝트 branch일 때 TFS는 관리자가 만든 구조로 세 프로젝트를 관리해야 하지만 SVN 또는 Mercurial은 A와 branch내부에 A'와 A''를 둘 수 있다. 개발자가 원하는 방식으로 프로젝트를 관리할 수 있다.

말씀하신 것처럼 소스제어의 폴더 구조를 반드시 따를 필요가 없다. 사용자가 작업영역(Workspace)를 이용하여 폴더 구조를 정의할 수 있다. 그리고 유용한 것 중, 공개 작업영역을 이용하면 누군가가 정의해 놓은 구조를 모든 사람이 공개 작업영역을 이용하여 같은 개발 구조를 가져갈 수도 있다.

이 부분도 다시 확인해 보시길...





6. 충돌 처리 미흡: 충돌이 일어날 때 TFS는 일반적으로 3가지 선택지를 준다. 다른 사람의 소스를 원복 하는 것, 내 소스를 원복하는 것, 자동으로 머지를 하는 것 3가지 선택지가 있다. 일반적으로 어떠한 도구라도 자동 머지는 믿을 수가 없고, 나 살자고 다른 사람이 작업한 결과물을 버리게 할 수 없기 때문에 내 소스를 버리게 된다. 이 경우 지금까지 작업한 것이 모두 사라지게 되는데 이를 방지하기 위해서는 Local Workspace를 제외한 또 다른 사본이 필요하게 된다. 이는 이중으로 머지를 하게 만드는 수고를 하게 함으로서 정말 고통 스러운 작업을 지속적으로 유발한다. 정말 이 과정에서 수없이 많은 충돌과 누락을 발생시키는데 도저히 이 방식을 용납하기 힘든 정도이다.

이렇게 고생하면서 충돌 처리를 하시는 점이 이해가 가지 않는다. 이런 소스의 버저닝 문제로 소스 제어를 사용하는데, 그 자체가 용납하기 힘들 정도이면 소스제어 기능을 충분히 활용하지 못하는 것 같다.




7. offline 상태에서 완벽한 무력화: 일반적으로 오프라인 상태에서 유효한 SCM은 분산 SCM인 Git, Mecurial을 제외하면 SVN도 유효하다고 보기는 힘들다. 다만, TFS와 SVN이 근본적으로 다른 점이라면, TortosieSVN을 이용한다면 어떤 파일이 수정되었는지 알 수 있다. 또한 작업 이전에 프로젝트를 모두 복사한 뒤 자유롭게 작업하고 그 결과물이 마음에 든다면 그 소스를 바로 커밋할 수 있다. 커밋한다면 실제 Repository에 반영된다. TFS로 동일작업을 해야 한다면 일단 사본을 만들고, 그 사본으로 작업한 뒤 원래 Local Workspace에서 수정한 파일을 "기억을 더듬어서" 일일히 Check out을 한 뒤 하나씩 복사해야 한다. 완벽하게 Check out이 끝난 뒤라면 통채로 복사해도 상관은 없지만 중요한 것은 Check out을 한 뒤 해야 하는 것이다. 만약 당신이 30개의 파일을 수정했다면 30번 Check out을 해야 한다. 만약 Git, Mercurial을 사용한다면 Local Repository에서 revision을 관리하며 작업을 지속하는 것이 가능하다.

TFS와 Visual Studio에서 온라인 상태로 바인딩된 소스제어가 오프라인으로 변경이 되고, 코드 변경 작업이 완료된 후 다시 온라인 상태로 전환이 되면 변경된 파일은 체크 아웃 상태를 유지한다. 그리므로 일일이 기억을 더듬어서 작업할 필요는 없다.

이 부분도 다시 확인해 보시길...





8. 비용: TFS는 단점만 가진 SCM이지만, 자체적으로 ALM 기능을 포함하고 있기 때문에 비용이 수반된다. ALM이 반드시 필요한 경우라면 가장 저렴한 비용으로 구축할 수 있지만 TFS를 사용함으로서 얻는 불이익이 ALM 도입 비용을 상회할 지 모른다. 또한 TFS 사용을 위해서 VS가 전혀 필요하지 않는 사람도 VS를 TFS 라이센스로 모두 구입해야 하므로 사실 비용이 썩 저렴하다고 보기 힘들다. 만약 Issue Tracker 또는 ALM이 필요하다면 Jira와 같은 도구를 도입하고 SCM을 따로 구축하거나 Trac + Mercurial, Launchpad + Mecurial 같은 솔루션을 사용하는 것이 현명한 방법이라 생각한다. 이를 통해서 VS가 필요없는 사람에게 TFS VS를 구입 해줄 필요가 없으므로 비용을 절감할 수 있고, 또한 VS 역시 TFS 버전으로 구매할 필요가 없으므로 비용을 절감할 수 있다. 심지어 SCM 서버도 리눅스 등을 이용하여 구축할 수 있으므로 서버 비용도 절감할 수 있다. (다만 리눅스 엔지니어를 채용하는 비용이 추가적으로 발생할 수 있습니다)

TFS 라이센스 부분에서 TFS를 사용하려는 사용자가 모두 Visual Studio를 구매할 필요가 없다. CAL(Client Access License)만 구입하면 된다.

그리고 오픈 소스를 이용하여 ALM 환경을 구성하는 것은 그 조직이나 그 사람의 자유이다. 그것이 관리하기 편하고, 사용자가 원한다면 오픈 소스를 사용하는 것도 좋은 방법이다. 다만, 오픈 소스를 이용하여 모든 ALM 환경이 구성된 경우, JRE 버전, 새로운 버전으로 업그레이드와 데이터 마이그레이션, 오류 등으로 자유 소프트웨어 진영에서 어떠한 지원도 받을 수 없을 것이다. 이런 점에서 상용 솔루션은 어떤 지원을 받거나, 책임의 소지를 확실히 구분할 수 있다.

이 부분도 다시 확인해 보시길...





 



Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 안들이 2013.01.11 02:25 Address Modify/Delete Reply

    일단 닷넷에서 자바로 넘어 온 입장해서 적자면..

    1. 윈도우 플랫폼이 너무 고가정책이다.
    어떤 걸 도입하든 MS제품으로 도배가 되는데 제품 라이센스 체계가 굉장히 복잡하고 비용또한 유닉스보다 저렴한 정도이지 리눅스의 무료(오픈소스)에 비하면.. 넘사벽입니다.

    흔히 유지비용을 MS에서 더 저렴하다고 하지만 리눅스기반에 오픈소스 제품군에 부분적으로 컨설팅이나 유료제품군을 사용하는게 훨씬 더 저렵합니다.

    2. 사용자 수가 절대적으로 적고 참고할 만한 자료가 없다.(멘토 부족..)
    라이센스 정책이 고가에 인증부분이 강화되면서 불법라이센스가 거의 사라졌지만 비례적으로 관련 정보나 생태계도 같이 사라지고 있습니다.
    (최근 윈도우 서버 2012가 출시 되었지만 네이버에서 검색해보면 아직도 MS에서 출시 이벤트를 한건지 출시 이벤트 정보만이 C&P 하듯이 몇페이지외에 실질적인 정보가 거의 없습니다..)

    3. 리눅스/자바/이클립스 체계가 충분한 개발장비가 되고 있다..
    VS 2012를 잠깐 써본 적이 있는데.. 정말 좋아졌더군요.(사실 경쟁자가 없을정도로 잘 만들었죠.. 무겁다는 것만 빼면..) 하지만 리눅스든 윈도우든 맥이든 자바에 이클립스만 있어도 충분히 개발환경을 만드는데 충분하더군요. 버전업이 되었다고 자바버전이 올라갔다고 이클립스를 갈아 치우지 않아도 되고..
    VS의 경우 이제 매년 갱신해야 하지요..(얼터밋이 1900만원이던가..매년..)


    안드로이나 애플이의 IOS 나 OSX 든 운영체재는 무료나 아주 저렴하게 풀고 개발환경도 무료나 저렴하게 풀고 플랫폼을 확산하는데 주력하고 있는데.. 또 제품들도 충분히 나와주고 있고요.. 그런데 비싼 OS에 개발환경을 갖출 이유는 없겠지요..자바로 만들어도 윈도우 대응도 되고요..-_-

    MS가 부활하려면 OS비용을 아주 낮은 비용으로 책정하고 (연 19800원? 이나 무료) 윈도우 스토어와 모바일 스토어를 통합해서 스토어를 통해서 수익을 적극적으로 만드는게 현실적으로 보입니다..
    하지만 MS는 포기하지 않겠지요.. 점유율이 떨어진 만큼 비용을 올려서 수익을 만들고 있으니까요.. 지금도..

  2. 안들이 2013.01.11 02:33 Address Modify/Delete Reply

    윈도우 블루(차기버전)가 무료정책이고 윈도우 서버도 비용이 실 웹서비스나 웹서버로 도입가능할 정도로 저렴해지고 비주얼 스튜디오가 10만원 이하로 책정 되면 다시 윈도우 플랫폼을 써보고 싶네요..

    (도대체 받지도 않을 기술지원은 왜 포함하는건지.. msdn 문서도 문서화 제공부분에서 필수적인 것인데.. 장점이라며 비싸게 책정되고 있는 msdn 구독료는 이해하기 힘드네요..-__- 요즘 게임업체들도 모바일로 전환하거나 외국으로 나가면서 리눅스 플랫폼에 오픈소스 제품군을 적극적으로 준비하는 업체가 많더군요.)

  3. 아름드리 2013.01.11 09:36 Address Modify/Delete Reply

    3번 항목의 .svn 숨김 폴더는 근래에 최상위 폴더에만 생성되도록 변경되었습니다.

  4. 공도 2013.01.13 08:42 Address Modify/Delete Reply

    7번에 덧붙여서, Git의 로컬 커밋과 개념이 다르지만 Shelve 기능을 활용하면 팀에 영향주지 않고 개인적으로 커밋하는 효과를 얻을 수 있죠. 몇 번이든지 Shelve Set으로 저장했다가 다시 복원했다가 하다가 메인 트리에 올릴 수 있을 때 체크인 하는 방식으로 쓸 수 있고 또는 아직 체크인 하기 전의 코드를 팀원이 리뷰하는 용도로 쓸 수도 있고요.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며


본 글 이외에 Visual Studio 팀 블로그를 함께 운영하는 강보람 MVP님의 "Welcome to Metro User Interface" 컬럼과 남정현 MVP님의 "Windows Server 8 미리 보기" 컬럼은 필자의 블로그에 기재하지 않은 점 또한 참고하기 바라며, 저작자의 동의하에 추후에 공개가 될 수 있습니다.



시대가 바뀌면서 Windows도 전통적인 모습에서 벗어나서 새로운 흐름을 만들고자 하는 노력이 시작된 것 같다. 물론 기존의 데스크 탑은 여전히 널리 사용될 것이다. 일상적인 업무에서 사용하는 응용 프로그램이 굳이 메트로 사용자 인터페이스 형태를 띌 필요는 전혀 없을 테니 말이다. 그리고 앞으로도 계속해서 기존의 데스크 탑을 타겟으로 하는 윈폼이나, WPF의 개발도 지속될 것이다. 하지만, 새로운 기회는 작은 틈에서 나오는 것이니 이 틈새를 잘 이해하기 위해서는 Windows 8의 메트로 환경을 잘 이해할 필요가 있다.

 

Windows 8과 Visual Studio 2012은 그야말로 N스크린에 감히 필수적인 환경이라고 말하고 싶다. 그 어떤 플랫폼도 데스크 탑과 테블릿, 모바일 등의 모든 기기와 환경 모두를 지원하는 것은 매우 어려운 일이다. 일반 사용자가 기기마다 사용하는 용도와 스타일이 다르고, 모바일 기기마다 해상도와 특징이 다르기 때문이기도 하지만, 하나의 개발 도구로 모든 상황을 대응할 수 있는 통합 개발 도구가 없는 것도 한 몫을 한다. 아니라고 말하는 독자도 있겠지만, 필자는 데스크 탑 환경까지 확장하는 N스크린을 말하는 것이고, 모든 N개의 스크린에서 똑같은 사용자 경험을 제공하는 것을 말한다. 이런 관점에서 Windows 8과 Visual Studio 2012은 그 해답을 제시하고 있으며, 충분히 가치 있고, 도전해 볼만하다. 이런 이유로 벌써부터 필자는 매우 흥분이 된다.

 

그리고 이 글에서 모두 소개하기는 어려웠지만, Windows Server 8은 그 동안의 Windows 운영 체제가 보여주었던 정적인 모습을 탈피하여 대규모 데이터 센터가 아닌 비용 문제 때문에 고민이 많은 수 많은 중소 규모의 IT 인프라에서도 효율적으로 시스템을 운영하고 애플리케이션 개발자들이 핵심에만 접근할 수 있도록 도와줄 방법을 제공하고 있다. 또한 메트로 스타일의 앱은 단순히 사용자 인터페이스에 관한 새로운 접근일 뿐만 아니라 데스크톱 가상화나 서버 관리자를 위한 새로운 종류의 서비스로 자리잡을 수 있다. 여전히 Charm Bar의 기능은 유용하게 사용할 수 있으며, Application Contract를 정확하게 지원하는 서버용 메트로 앱을 만들어 서버 관리자의 일을 덜어내거나 전혀 새로운 경험의 터치 기반 KIOSK를 손쉽게 만들 수도 있을 것이다. 이것은 전적으로 여러분의 선택에 달려있는 일이 될 것이다. 더 나아가서, Windows Server 8의 여러 기술들이 각종 호스팅 환경은 물론 Windows Azure나 Amazon과 같은 Public Cloud Computing 환경에도 전면적으로 도입이 된다면 더 멋지고 유용한 서비스들이 대거 등장하지 않겠는가 하는 것이 개인적인 생각이다.

 

참고 자료


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.02 10:05 Address Modify/Delete Reply

    재밌게 읽고 갑니다.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며

 

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.



 

성큼 다가온 Visual Studio 2012

Microsoft의 대표적인 통합 개발 도구인 Visual Studio 2012의 성장세가 무척 빠르다. 지난 10년전 .NET 플랫폼과 함께 대표적인 개발 도구인 Visual Studio.NET (2003버전)를 내놓았다. 그 때의 시간이 바로 엊그제 같은데 그 이후 Visual Studio 2005, 2008, 2010을 지나 Visual Studio 2012베타 버전을 필자가 사용하고 있으니, 짧은 10년동안 Microsoft를 비롯하여 개발 언어, 개발 툴, 이 모든 것이 굉장히 많이 변해 왔음을 새삼 다시 느껴진다. 이제 Windows 8라는 새로운 운영체제가 기다리고 있다. 그리고 이를 빛내줄 Visual Studio 2012.

 

성큼 다가온 Visual Studio 2012과 그 발자취

Visual Studio 2012를 먼저 논하기 전에 Visual Studio가 어떤 발자취를 남기며 발전해 왔는지 간단하게 살펴보는 것도 독자들이 Visual Studio 2012를 이해할 수 있는 좋은 방법이라고 생각한다. 물론 짧고 간단하게 모든 것을 설명할 수는 없지만, 전반적인 특징만으로 그 동안 개발 트랜드가 어떻게 바뀌었고, 시장의 요구 사항이 어떻게 변화하여 왔는지 한 눈에 알 수 있는 가장 좋은 방법이라고 생각한다.

 

Microsoft의 첫 번째 진정한 통합 제품으로 평가 받는 제품이 Visual Studio.NET (2003버전)이다. Microsoft의 전략적인 언어인 C# 1.0과 VB.NET(v7.0)이 .NET 개발의 대표적인 언어가 되었다. 기존의 VB를 세련된 객체지향 언어로 탈바꿈하면서 이전의 VB개발자들에게 .NET 개발의 문턱을 낮출 수 있는 매우 좋은 사례이기도 하다. (단, Visual Studio 2002는 논외로 하겠다)

이 이전의 개발도구는 하나의 도구에서는 하나의 언어로만 개발을 할 수 있었고, 개발 툴 역시 그 언어에 매우 종속적이고, 다른 언어로 전환하려면 이전의 개발 도구와 개발 경험 역시 많은 부분을 새로 습득해야 했다. 특히 J# 이라고 하는 Java 언어와 라이브러리를 제공하였는데, Java 개발자들을 .NET 플랫폼 안으로 끌어안기 위한 매우 독특한 사례이기도 하다. 실제로 J#은 웬만한 Java 소스 코드를 변경 없이 .NET 목적 파일로 컴파일 할 수 있었다.

Visual Studio는 하나의 개발 도구를 통해 여러 가지 언어를 선택하여 웹 응용 프로그램, 윈도우 응용 프로그램, 모바일 개발, XML, XML 웹 서비스를 개발을 통합하고, 여기에 포함되는 .NET Framework 1.0은 응용 프로그램을 빌드하고 실행하는 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임)을 제공, 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었다.

이 후, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework의 확산에 큰 공을 이루게 되었고, 실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있을 정도이다.

 

때는 2005년. Visual Studio 2005버전은 파격 그 자체다. 여기에 포함된 런타임인 ..NET Framework 2.0은 이전 .NET Framework 1.x에 사용된 코드를 대부분 갈아 엎었을 정도이다. .NET Framework의 뼛속까지 변신한 것이다. ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 '~2.0' 이라는 버전 번호를 붙였고, 많은 기능이 보완되고 확장되었다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 .NET Framework 3.5 SP1 까지 .NET Framework의 모태가 된다.

모든 것이 생소할 정도로 많은 변신이 있었는데, 그 중에서 C#과 VB.NET 언어가 대표적이다. Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic)이 등장하였다. 이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었다. 개발 툴도 많은 변화가 있었는데, IDE 자체의 외관도 많이 변했고, 개발 툴의 내부적인 코드에서 변화가 왔고 다양한 내부 인터페이스가 추가되었다. Visual Studio의 솔루션 탐색기에서 흔히 사용하는 '솔루션 폴더'도 이때 등장하였다.

그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었다.

 

.NET Framework 3.0은 새로운 개발 도구와 출시되지 않았다. 2005년 중순 Windows Vista 운영체제가 출시되면서 이에 대응하는 라이브러리가 포함이 되었다. 함께 새로운 기술도 대거 포함이 되었는데, 그 중에서 대표적으로 꼽으라고 하면 WPF와 WCF이다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었다. 또한, WCF는 여러 가지의 분산 통신 기술이 통합되었다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었다.

 


 

 

때는 2007년, 또 한번의 메이저 급 업데이트였다 언어적으로 LINQ라는 새로운 녀석 때문이다. LINQ(Language Integrated Query) 라는 이름에서 알 수 있듯이 익숙한 SQL Query 문법과 유사하여 객체 탐색에 있어 효율성이 매우 높아졌고, 그 성능도 일일이 손으로 짠 코드보다 더 빠른 경우가 있다. 이 LINQ의 기반이 되는 람다식(Lambda Expression), 익명 타입(Anonymous Type), 확장 메서드(Extension Methods)의 언어적인 새로운 스팩이 한데 아우러져 LINQ를 구성한다. XML객체, DataSet, 파일 시스템, 컬렉션 등 모든 대상이 LINQ 쿼리식의 대상이 된다. 이에 영향을 받아 JavaScript와 Java 언어에 영향을 주어 LINQ와 유사한 프레임워크가 등장하였지만, .NET 과 같이 언어적으로 통합이 되지 않았다. 마치 Method Chaining 패턴을 이용한 라이브러리로 분류된다.

이 밖에 정말 헤아릴 수 없을 정도의 많은 진보가 있었다. 개발 도구와 개발 언어, 그리고 .NET 플랫폼의 기술이 발전한다는 것은 분명 매우 좋은 일이겠지만 아마 이 시기부터 많은 .NET 개발자들이 Microsoft의 기술 발전을 따라가기 벅차했었다.

 


2010년에 이르러, Visual Studio 2010버전이 출시되었다. 너무 빠른 .NET 기술의 발전의 탓일까, 이 때는 언어와 .NET Framework보다는 Visual Studio라는 개발 툴에 가장 초점이 맞추어졌다. 그 중 핵심 키워드라고 할 수 있는 것 3가지는 "시각화", "디버깅", "프로세스" 일 것이다. (필자의 의견이므로 Microsoft가 추구했던 것과는 다를 수 있다.) 이 세 가지의 핵심 키워드는 시각화, 협업에 있어 코드의 이해를 좀 더 쉽게, 그리고 복잡한 데이터를 한 눈에 알 기 쉽게… 디버깅-디버깅 시 데이터의 수집이 혁신적으로 발전하였고, 물리적으로 분리된 티어(Tier)간에 데이터 수집… 프로세스, 애자일을 강조하고 애자일한 통합 프로세스를 개발 툴에 제공.

.NET Framework 4.0은 .NET Framework 2.0기반이 아닌 새로운 프레임워크로 구성되었고, 멀티코어 처리를 위해 강력한 병렬 처리 라이브러리(Parallel Libraries)가 있다. 또, 동적 언어 런타임(Dynamic Language Runtime)으로 정적 형식과 동적 형식의 경계를 허물었으며, 루비(Ruby), Lisp, JavaScript, 파이썬(Phython), PHP와 같은 동적 언어와 상호 운용이 가능하다. 예를 들자면, C# 언어로 파이썬 개체와 상호 연동이 가능하다는 것이다.

 

  

제품의 버전 / 특징

2002년

  • Visual Studio .NET 2002 / .NET Framework 1.0 
    첫 통합 개발 환경 
    발매 당초의 제품명은 ' Visual Studio .NET 
  • C# 1.0 / Visual Basic .NET (7.0) 
    C# 은 마이크로소프트의 새로운 객체 지향 언어 
    Visual Basic 도 객체지향 언어

2003년

  • Visual Studio .NET 2003 / .NET Framework 1.1 (5월) 
  • C# 1.1 / Visual Basic .NET (7.1) 
    모두 버전 업 
  • Windows Server 2003 
    .NET Framework 1.1 표준 탑재

2005년

  • Visual Studio 2005 / .NET Framework 2.0 (12월) 
    ClickOnce 배포 
    제네릭 클래스 도입 
    ASP.NET 2.0, ADO.NET 2.0, Windows Form 2.0 
    리팩토링 기능 / 코드 스니펫 
    무료 Express Edition (C#, VB, C++) 
  • C# 2.0 / Visual Basic 2005 (8.0) 
    제네릭 대응 
  • Visual Studio 2005 Team System 
  • SQL Server 2005 지원

2006년

  • .NET Framework 3.0 (11월) 
    코어 부분은 .NET Framework 2.0 그대로 
    WPF(Windows Presentation Foundation) 
    WCF(Windows Communication Foundation) 
    WF(Windows Workflow Foundation) 
    CardSpace 
  • Windows Vista 
    .NET Framework 3.0 기본 탑재

2007년

  • Visual Studio 2005 Service Pack 1 (6월) 
  • ASP.NET AJAX 1.0 (추가 모듈) 
    AJAX Web Application 개발이 용이 
  • Expression Blend 
    Expression Studio 첫 제품 
    WPF 어플케이션의 GUI 구축
  • Visual Studio 2008 / .NET Framework 3.5 (11월 경) 
    개발 코드명 'Orcas' 
    WPF 의 GUI 설계 가능 
    Javascript 디버그 기능 및 IntelliSense 
    ASP.NET AJAX 표준 탑재 
    .NET Framework 2.0, 3.0, 3.5 선택 가능 
  • C# 3.0 / Visual Basic 2008 (9.0) 
    LINQ 기능 
  • SQL Server 2008 
  • Windows Server 2008 
  • Visual Studio Team System 2008

2008년

  • Visual Studio 2008 SP1 / .NET Framework SP1 
    ASP.NET Dynamic Data 
    ADO.NET Entity Framework / Data Services (Astoria) 
    WCF Atom Pub Services 
    클라이언트 프로파일(Client Profile) 
  • VSTS 
    Windows Server 2008 지원 
    SQL Server 2008 지원 
    성능 향상 및 개선 
  • Visual Studio SDK 1.1 (SP1) 
    Visual Studio Shell 재배포 패키지 경량화 
    DSL 출력 미리보기 등… 
  • Visual C++ 2008 
    오피스 리본 스타일 Interface 
    고급 GUI 컨트롤 등…

2010년

  • 사용자 친화적인 Visual Studio IDE
  • 코드 탐색 강화
  • 개발 툴에서 다양한 .NET Framework 개발 환경 제공
  • JavaScript 언어 개발 환경 강화
  • 다양한 플랫폼 지원
    • 64 Bit Mixed-Mode 디버깅
    • Managed 와 Mixed-Mode 의 Minidump 디버깅
  • Historical Debugger
    • 디버그 내용을 기록, 재생
  • 프로젝트 관리 및 프로세스 통합

 

 

Visual Studio 2012와 함께 매트로 앱 개발

Visual Studio 2012의 가장 큰 핵심은 바로 Windows 8 운영체제이다. Windows 8은 매트로 응용프로그램이라는 새로운 환경과 WinRT(Windows Runtime)인 새로운 런타임을 제공한다 그리고 Visual Studio 2012는 Windows 8 운영체제에 가장 최적화된 개발 툴이다. 독자들은 또 새로운 것을 배워야 하나라고 한숨을 쉴 수도 있을 것이다. 하지만 섣부른 독자들의 판단은 잠시 후에 하기 바란다. 왜냐하면 Windows 8 개발은 새로운 환경이면서도 새로운 환경이 아닐 수도 있다. Windows 8 운영체제를 사용하고 WinRT APIs 집합을 사용하는 것 이외에는 아무것도 변한 것이 없기 때문이다. 단지 바뀐 것은 여기에서 개발된 응용 프로그램은 데스크탑 컴퓨터, 테블릿, 모바일 환경 모두 실행되고 배포할 수 있다는 것이다.

최근 개발 환경을 엿보자면 C++을 사용하는 네이티브 개발과, NET에서 지원하는 C#과 같은 관리 언어, 그리고 웹 개발에 필요한 HTML과 JavaScript, 이 중에 단 한가지 기술 영역만 있으면 Windows 8 매트로 응용 프로그램 개발 준비는 끝이라는 것이다. 우리가 흔히 사용하는 스마트 폰을 보면 알 수 있듯이, 개발자는 단지 '위치 정보', '화면의 표현 방법', '데이터 연동', 그리고 스마트 폰을 가로로 볼 때와 세로로 볼 때와 같은 일상적인 기능을 제공하는 APIs를 익히기만 하면 된다. 기존에 Visual Studio를 사용하여 개발해 본 독자라면 그 만큼 진입 장벽이 낮다.

윈도우 폰7 개발처럼 테블릿 시뮬레이터가 제공이 된다. Windows 8 테블릿이 지원하는 대부분의 모든 기능을 이 시뮬레이터에서 테스트를 해 볼 수 있다. 윈도우 폰7 개발처럼 반드시 시뮬레이터가 필요한 것은 아니다. 실제 시뮬레이션이 필요 없다면 곧바로 로컬 데스크 탑에서 매트로 앱을 실행해 볼 수 있다.

Figure 1 Visual Studio 2012 매트로 앱 실행 및 디버깅

 

Figure 2 시뮬레이터 실행 환경

 

더불어 Visual Studio에서 제공하던 성능 측정 도구와 코드 정적 검사를 매트로 앱 개발 환경에서도 그대로 이용할 수 있다. 이는 곧 Visual Studio 2012이 Windows 8 개발에 가장 최적화가 되었다는 의미가 된다.

 

Figure 3 매트로 앱 성능 측정 및 진단

 

간략하게 나마 Visual Studio 2012과 Windows 8 개발에 대해 살펴보았다. 필자가 얘기한 것처럼 개발자에게 있어 새로운 환경이지만, 반대로 전혀 새롭지 않기도 하다. Visual Studio로 간단한 앱을 만들 수 있는 실력이라면 곧바로 Windows 8 매트로 앱을 개발할 수 있을 정도로 진입 장벽이 낮다. 물론, 좀 더 기술적이거나 독창적이고 예쁜 앱을 만드는 것은 더 많은 노력이 필요하다. 단지, 앱 개발자는 자신만의 앱 개발에만 집중하면 된다.

 

Figure 4 Windows 8 개발에서 배포까지

 

Visual Studio 2012과 함께 매트로 환경의 게임 개발

데스크 탑과 테블릿, 그리고 모바일 앱 중에서 단연 게임이 빠질 수 없다. 매트로 환경에서 게임 개발은 아직 시장이 포화되지 않은 장르이다. 그 만큼 게임 개발자에게 있어 매트로 환경에서 게임 개발은 매우 유혹적이기도 하다. 더 반가운 소식은 매트로 게임 개발에 필요한 지식은 게임 개발자에게 익숙한 C++언어와 DirectX다. DirectX를 이용하여 2D, 3D 게임을 개발할 수 있다.

얼마 전까지만 해도 Microsoft가 전략적으로 게임 개발을 지원하던 프레임워크인 XNA를 매트로 게임 개발에 지원하지 않는다. 대신 기존 게임 개발자에게 기존 개발 환경을 그대로 이어갈 수 있는 DirectX를 선택한 것이다.

Figure 5 DirectX 3D 샘플

Figure 6 DirectX 2D 샘플

 

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

협정 세계시(UTC) 시간으로 2012/06/01, Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 버전이 MSDN Subscription을 통해 공개가 되었다. 이번 버전에는 Windows 8 Consumer Preview(CP) 버전과 Visual Studio 11 Beta 버전에 비해 잔존하는 버그가 상당히 줄어들었다. Windows 8 CP 버전을 쓰면서 가장 사용하기 불편했던 점은 데스크톱 응용 프로그램들이 이유 없이 멈추고, Visual Studio 11 Beta 의 IDE가 자주 뻗어 버리는 현상이 눈에 띄게 사라졌다. 더불어 이 두 가지 Release의 성능도 눈에 띄게 향상되었다. 마이크로소프트의 많은 노고에 박수를 보내고 싶다.

   

Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 피드백

Windows 8 Release Preview에서 조금 변화를 원한다면, Metro 시작화면에는 Metro 응용 프로그램만 나열되었으면 한다. 그리고 폴더 기능이나 같은 카테고리 앱끼리 정렬할 수 있으면 더 좋겠다. 데스크톱 응용 프로그램과 Metro 앱이 마구 섞여 있으니 검색 기능 없이 찾기가 힘들다.

   

Visual Studio 2012 Release Candidate 버전에서는 아이콘의 컬러를 흑백에서 컬러로 바꾸었다고는 하지만, 필자 개인적으로는 솔루션 탐색기부터 산만해진 것은 변함이 없다. 컬러를 넣으려면 넣고 빼려면 빼지 말이다. 아이콘 컬러를 넣어달라는 수많은 사용자 피드백에도 불구하고 또 이렇게 산만해진 컬러링은 정말 최악이다.

결론은 둘 중 하나인 것 같다 사용자 피드백을 씹는다거나, 사용자 피드백이 좀 약했다던가...

   

   

Windows 8 SDK, 이빨 빠진 호랑이 격!

자! 이제 본론으로 들어가서 Windows 8 SDK(Software Development Kit)과 Visual Studio 2012에 매우 중요한 것이 변경되었다. 이미 pcworld.com 에서 Release 제품이 나오기 이전에 예고를 했다. Windows 8 SDK 에는 Command-Line 과 관련된 대부분의 실행 파일들이 포함되지 않는다. Windows 8 SDK는 이 링크에서 다운로드 받을 수 있다.

   

위의 Windows 8 SDK 링크를 참고하면 다음과 같은 문구를 찾을 수 있다. 이번 SDK가 DirectX SDK와 통합된 것은 그다지 관심이 없다. 다만, 빌드와 관련된 모든 Command-Line(명령줄)을 제거했다는 것이 중요하다.

   

Windows 8 SDK를 이용하여 단독으로 아무것도 할 수 없다. 일반적으로 마이크로소프트에서 제공하는 Software Development Kit(SDK)에는 개발에 필요한 대부분의 기능들이 포함되어 있다. 가장 중요한 것이 SDK 에 포함되어 있는 Compiler(컴파일러)이다. Visual C++, Visual C#, Visual Basic.NET 으로 작성된 소스 코드를 컴파일하기 위해서는 Compiler가 필요한데, Windows 8 SDK 에서는 제공해 주지 않는다. 그리고, 복잡한 워크플로우로 빌드되는 최근의 개발 환경에서 MSBuild.exe가 필요하다. MSBuild.exe는 인증 작업, 링크 작업, 리소스 병합 등 복잡한 작업을 순차적으로 처리해주는 매우 훌륭한 도구이다. Windows 8 SDK 에서는 이것도 빠져있다.

   

이제 좀 현실감이 올 것이다. 가장 먼저 타격을 받는 것이 바로 통합 빌드 시스템이다. 빌드 서버에 Visual Studio 2012를 설치하지 않으면 Windows 8 Metro App이나 .NET Framework 4.5, 그리고 최신 버전의 Visual C++ 소스 코드를 컴파일하거나 배포할 수 없다. 이는 좀 더 복잡해지는 라이선스 정책과도 교묘해진다. 일반적으로 Visual Studio의 라이선스는 개발자당 1 Copy의 Per User 라이선스이다. 그렇다면 빌드 서버에서 빌드를 하기 위해 Visual Studio를 설치했다면, 이는 Per User 라이선스를 적용 받는 것일까?

   

물론, 무료로 사용할 수 있는 Visual Studio 2012 Express 버전이 있다. 무료이고 상용으로 사용해도 제약이 없는 버전이지만, 제품 자체가 매우 최소한의 기능만 제공한다. Visual Studio Gallery 웹 사이트와 Visual Studio Extension Manager(확장 관리자)에서 제공하는 확장 기능을 사용할 수 없다. (단, Templates(템플릿), ToolBox(툴박스)와 관련된 것들만 수동으로 설치가 가능하다). 협업이나 형상 관리를 위해 SVN Source Control Provider(SVN 소스 제어 기능)나 Team Explorer(팀 탐색기)도 설치되지 않는다. 교육용으로는 적합할 지 모르겠으나, 실제로 기업 현장의 필드에서 사용하기엔 있으나 마나...

   

다시 원점으로 돌아가서 Visual Studio 2012과 .NET Framework 4.5의 새로운 기능을 살펴보자.

   

필자가 어림 잡아 새롭다거나 눈에 띄는 Features를 아래와 같이 아주 간단하게 정리해보았고, 나름대로 간략한 소감을 적어본다.

  • Visual Studio 2012
    • 매트로 앱 개발 - Visual Studio 2012는 매트로 앱 개발을 위한 툴 그 이상 이하도 아니다.
    • C++ Editor 개선 - 개선이 되었더라도 3rd-party 제품인 Visual Assist 를 $99 에 사서 쓰는 것이 더 좋다.
    • Graphics Tools - AutoDesk, Pixel Shader를 만들고 수정하기 편리해졌다. 그런데 이런 기능은 사용하기 늘 부족하기 때문에 NVIDIA Parallel Nsight 2.1 같은걸 쓰는 것이 이로울 것이다. 항상 느끼는 것이지만, 만들다가 만 Features가 Visual Studio에는 너무 많다.
  • .NET Framework 4.5
    • Portable Class Libraries - 마이크로소프트 BCL Team이 Visual Studio 2010 버전으로 공개했다. 그다지 새롭지 않다.
    • Parallel Computing - 가려웠던 부분을 상당부분 긁어줄 것 같다. Parallel 라이브러리에는 찬사를 보내고 싶다.

   

이 외에는 대부분이 성능적인 개선과 기능적으로 보강한 것들이 대부분이다.

   

   

이제 대략적인 결론이 나온다. 매트로 앱만 개발하기 위해서 굳이 Visual Studio 2012를 사용하는 것은 비용적으로 비효율적일지도 모른다. 매트로 앱은 Visual Studio 2012 Express for Windows 8 을 쓰고, 그 외의 시스템적으로 변경사항을 최소화하기 위해 Visual Studio 2010이나 Visual Studio 2008을 사용하고, 더불어 Windows 7 SDK and .NET Framework 4 또는 Windows 7 SDK and .NET Framework 3.5 SP1 을 사용하는 것이 좋겠다. 그리고 필자는 이번 SDK 에 Compiler 배포를 모두 제거한 것을 이해하기 힘들다. 사실상 .NET 환경의 개발자 또는 기업을 대상으로 돈 내놓으라는 것과 다를 바 없다. 그리고 마이크로소프트의 기술은 점점 발전하는데, 기술 이외의 것들은 퇴보적인 경향을 보인다.

   

참고로 다시 한번 상기하자면, 아래는 Windows 7 SDK for .NET Framework 4의 설치 화면이다. 이번 Windows 8 SDK 에는 아래의 대부분이 빠진다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 네모 2012.06.07 00:19 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

  2. 네모 2012.06.07 00:20 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

MSDN Virtual Lab에서는 Microsoft Team Foundation Server 2010 제품을 온라인으로 트레이닝 받을 수 있는 서비스가 있습니다. Team Foundation Server 2010 을 설치할 여력이 되지 않거나, 제품을 직접 시연하고 싶은 사용자에게 가상 환경을 제공해 주고, 가상 환경에서 여러 시나리오를 따라해 볼 수 있습니다.

이 MSDN Virtual Lab 환경은 Internet Explorer 만 있으면 곧바로 서비스를 체험할 수 있습니다. 다만, 이 서비스는 가상의 환경으로 제공이 되기 때문에 가상 환경에서 실습이 끝난 이후에는 생성된 팀 프로젝트와 데이터는 모두 삭제가 됩니다.

실습은 모두 3가지의 모듈로 제공이 됩니다.

   

먼저 실습을 하고자 하는 모듈의 주소를 Internet Explorer 를 통해 접속을 합니다.

   

Launch Virtual Lab을 선택하면 아래와 같은 팝업이 뜨는데, 실습 환경의 가상 환경을 제공하기 위한 준비를 합니다. 아마도 실습을 하기 위한 스냅샷으로 돌아가고 있겠지요..?

   

이 가상 환경 실습은 원격 데스크톱 연결을 이용하는데, Connect 버튼을 클릭하면 곧바로 가상 환경을 원격 데스크톱 세션을 통해 접속이 됩니다.

   

접속이 되면 가상 환경 접속에 접속할 수 있는데, 마치 Hyper-V 관리 콘솔과 같은 화면이 나타납니다. 물론 단 하나의 VS2010CTP 라는 가상환경에만 접근할 수 있습니다.

   

아래오 같이 가상 환경이 접속이 되면, 텅 빈 윈도우 바탕 화면이 나타나는데, Start 버튼을 클릭하면 우리가 실습에 필요한 모든 소프트웨어가 설치가 되어 있습니다. 우측의 패널에는 실습 단계를 차례대로 진행할 수 있고, 상단에 HTML과 PDF 문서를 다운로드 받을 수 있습니다.

   

사실 Team Foundation Server 2010의 MSDN Virtual Lab 서비스가 나온지는 좀 되었지만, 아직 많이 알려지지는 않은 듯 합니다. 소프트웨어 패키지를 구매하고 설치하고 MSDN을 통해 기능을 익힐 수 있지만, 이렇게 가상화 서비스를 이용해 부담 없이 하드웨어나 환경적인 제약 없이 실습 공간을 제공해 주는 것을 보면 Before Services 가 짱 이네요.

(BE란 ? 고객들이 제품 구매에 앞서 제품을 직접 써보거나 충분히 경험해 본 다음 구매를 결정할 수 있도록 하는 다양한 체험 프로그램 서비스를 말한다. 기존 서비스 방식인 애프터서비스(AS)는 고객들이 제품을 구매한 후 제품에 대한 차후 서비스를 받을 수 있다. )

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Visual Studio 11의 솔루션 탐색기는 이전 버전에 비해 매우 독특한 구조를 가지게 되었습니다. 그 중에서 Visual Studio 11에서 솔루션 탐색기 기능을 최대한 활용하는 방법을 살펴볼텐데요, 그냥 가볍게 보시면 될 것 같습니다.

1. 다중 인스턴스로 사용하기

다중 인스턴스는 솔루션 탐색기를 하나가 아닌 여러 개로 띄울 수 있는데요. 단, 현재 로드된 솔루션의 솔루션 탐색기 인스턴스를 생성할 수 있습니다. 만약, Visual Studio 11에서 여러 솔루션을 하나의 Visual Studio 11 인스턴스에서 실행할 수 있다면 다중 인스턴스의 솔루션 탐색기가 더욱 편리할 거라는 아쉬움이 있네요.

아래의 그림과 같이 우측 끝에 있는 아이콘을 클릭하면 똑같은 인스턴스를 생성한답니다.

여러 솔루션 탐색기의 인스턴스를 사용하여 프로그래을 작성하는 프로젝트에 스크롤을 위치시키고, 또 하나는 단위 테스트 프로젝트에… 또 하나는 전체 솔루션이 훤히 보이도록 띄어놓았습니다.

이제 하나의 솔루션 탐색기에서 마우스 스크롤 쫙쫙~ 올리고 내리고 할 필요가 없어졌네요. 더불어 멀티 모니터를 사용한다면 효과가 금상첨화겠지요?

   

2. 코드 파일 미리보기

중간에 보이는 아이콘의 이름 "Preview Selected Items"은 말 그대로 코드 파일을 미리 보는 기능이랍니다. 이 옵션은 Visual Studio 11을 설치하면 기본적으로 선택되는 옵션입니다.

이 기능은 솔루션 탐색기에 파일을 한 번 클릭할 때마다 에디터 창이 열립니다. 좌측의 빨간색 탭은 솔루션 탐색기에서 코드 파일을 더블 클릭하거나 F7을 누를 때 일반적으로 좌측부터 정렬되는 에디터입니다.

오른쪽의 노란색의 탭 하나가 바로 한 번 클릭할 때마다 열리는 미리 보기 탭입니다. (필자는 개인적으로 이 옵션을 껐답니다 ^^;)

   

3. 솔루션 탐색기를 격리시키기

솔루션 탐색기를 격리시키는 방법(용어는 필자가 나름대로 칭하였습니다)입니다. 이 방법이 꽤나 쓸만한 기능인데, 솔루션 탐색기의 선택된 항목이 솔루션 탐색기의 최상위 루트가 되는 기능입니다. 예를 들어, 아래와 같이 Core 프로젝트를 펼치면 굉장히 길어지는데요, 단위 테스트도 같이 하려면 Core.Tests 프로젝트도 펼쳐져 있어야 합니다. 이러다가 대부분 솔루션 탐색기가 위아래 정신 없이 스크롤하게 됩니다.

   

그럼 솔루션 탐색기 다중 인스턴스를 이용해서 좀 더 스마트하게 사용해 볼까요? 바로 "Scope to This" 기능입니다.

   

이 기능을 이용해서 아래와 같이 스마트하게 솔루션 탐색기를 배치할 수 있습니다. 자주 코딩하는 Core 프로젝트랑 Core.Tests 프로젝트랑 각각 최상위 루트에 배치해서 귀찮은 스크롤도 없어지고 하위 여러 자식의 트리구조를 없애서 보기에 깔끔해 졌네요.

   

이런 경우는 인터페이스 프로그래밍을 할 때도 매우 유용합니다. 인터페이스를 선언하고 이를 구현하면 서로간에 왔다 갔다 하는 경우가 매우 많거든요. "Scope to This" 기능으로 좌측에 인터페이스 파일 하나만 배치시키고, 우측에서는 인터페이스를 구현하고 파생되는 구현 클래스가 뭉쳐있는 폴더만 격리시켰습니다.

 

어때요? 이제 솔루션 탐색기를 스마트하게 사용할 수 있겠지요?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 희정 2012.03.26 17:31 Address Modify/Delete Reply

    아. Scope to This 기능은 정말 좋네요. :D

Visual Studio Extensibility 라고 부르는 VSX를 Visual Studio 2010에서 Visual Studio 11로 업그레이드를 해야 하는데, Visual Studio 11버전부터 그리 어려운 작업이 아닙니다.

과거 VSX 프로젝트를 Visual Studio 2008에서 Visual Studio 2010으로 업그레이드하려면 좀 골치가 아팠습니다. 기존에는 코드 에디터 제어를 Visual Studio Native에서 제공하는 Interface를 사용했지만, Visual Studio 2010부터 코드 에디터가 WPF로 바뀌면서 이 부분은 모조리 변경해야 했거든요.

  

  

아시다시피 Visual Studio Gallery에 공개한 VSGesture for VS2008버전과 VSGesture for VS2010의 구현이 완전 달라졌을 정도니까요. 물론 이 확장 기능은 필자가 VSGESTURE.CODEPLEX.COM에 공개해 놓았으니 소스 코드도 받으실 수 있습니다.

  

Visual Studio 11로 VSX 업그레이드에 대한 더 자세한 내용은 다음의 문서를 참고하시기 바랍니다.

http://msdn.microsoft.com/en-us/library/hh567449(v=vs.110).aspx

  

일단 Visual Studio 11에서 프로젝트를 엽니다.

Visual Studio 11에서 프로젝트를 열어보니, 알아서 몇몇 파일들은 알아서 체크아웃이 되네요. 아마도 Resources 파일과 관련해서 뭔가가 바뀌었나 봅니다.

  

Source.Extension.VsixManifest 파일을 엽니다.

이 메니페스트 파일은 배포에 필요한 정보를 담고 있습니다. 확장 기능의 고유 GUID와 확장 기능 이름, 버전, 컨텐트 정보 등이 담겨져 있습니다.

그런데 그냥 XML 파일이 열리네요. Visual Studio 2010 SDK를 설치하면 그나마 GUI가 제공이 되었는데, 아직 Visual Studio 11 Beta SDK 라서 제공이 안되나 봅니다.

  

[Visual Studio 2010 SDK 의 GUI Manifest 구성 에디터]

  

어쨌든 XML 파일이 열리더라도 그리 어려운 작업은 아닙니다. 그냥 몇 가지 구성만 추가해 주면 됩니다.

  

SupportedProducts 구성 추가

XML 내용의 SupportedProducts 섹션에 다음과 같이 Visual Studio 11버전과 지원할 Edition 목록을 추가하면 됩니다.

  

  

어셈블리 참조를 추가해 줍니다.

이 어셈블리들은 Visual Studio 11 SDK 를 설치하시고, 다음의 경로에서 찾을 수 있습니다.

%ProgramFiles(x86)%\Microsoft Visual Studio 11.0\VSSDK\VisualStudioIntegration\Common\Assemblies\v4.0

  

  • Microsoft.VisualStudio.Editor.dll
  • Microsoft.VisualStudio.Language.Intellisense.dll
  • Microsoft.VisualStudio.Shell.10.0.immutable.dll
  • Microsoft.VisualStudio.Shell.11.0.immutable.dll
  • Microsoft.VisualStudio.Shell.11.0.dll

  

  

그 외에…

실제로 VSX의 기능에 따라 변경해 주어야 할 부분이 더 많더군요. 그 부분은 VSX 개발하시는 분들이 알아서 하시리라 믿습니다.^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

개발자에게 Visual Studio 11의 가장 큰 장점 중에 하나가 될 바로 코드 에디터 입니다. 특히 C++ 개발자에게 원성을 샀던 부실했던 C++ 코드 에디터는 기존의 C,#, VB.NET 과 동등할 정도로 코드 에디터의 구현에 충실해 다른 확장 도구의 도움 없이도 충분히 사용이 가능합니다. (Visual C++ 의 코드 에디터는 그 흔한 코드 컬러링도 기대 이하의 수준이었거든요)

   

C++ 코드 에디터

C++ 개발자에게는 C++ 코드 편집기의 컬러링과 인텔리센스는 정말 희소식일 것 같습니다. C++ 개발자는 기본적인 코드 작성에 Visual Assist 툴에 많이 의존하였었지만, 이제 외부 도구의 도움이 없이도 코드 작성에 어려움은 없을 것 같습니다. 

아래의 Visual Studio 2010과 Visual Studio 11의 C++ 코드 에디터를 그냥 눈으로 쓱 훑어보시기 바랍니다.

   

Visual Studio 2010의 C++ 코드 에디터

   

Visual Studio 11의 C++ 코드 에디터

   

   

   

C++/CLI 코드 에디터

특히 C++/CLI 를 자주 쓰는 분들에게는 더욱 특별할 수 있을 겁니다. C++/CLI 는 이전버전까지 예쁜 컬러링은 물론이거니와 인텔리센스도 작동하지 않는 암울한 환경에서 코드를 작성해야 했었습니다. 특히 C++/CLI 를 이용하여 C++ 코드를 단위 테스트할 때 무척 유용하였는데, 이번 컬러링과 인텔리센스 기능으로 더욱 활용도가 높아질 것 같습니다.

마찬가지로 Visual Studio 2010의 C++/CLI와 Visual Studio 11의 C++/CLI의 코드 에디터를 한번 보시죠.

   

Visual Studio 2010 C++/CLI 코드 에디터

   

Visual studio 11 C++/CLI 코드 에디터

C#, VB.NET 과 동급한 레벨로 인텔리센스와 코드 컬러링을 제공합니다. 그리고 Code Snippet도 제공되니 코딩이 한껏 즐거워지겠네요.

   

   

   

JavaScript 코드 에디터

JavaScript 는 웹 개발 환경에서 필수 언어로써, 개발 툴에서 JavaScript 인텔리센스 지원이 점점 좋아지고 있네요. Visual Studio 11 Beta 에서는 JavaScript 인텔리센스의 성능이 향상이 되거나 HTML5 등을 지원하는데요.

그 중, Lazy Initialize와 Lazy Loading 부분에서 상당히 만족할만한 수준으로 인텔리센스 기능이 좋아졌습니다.

   

JavaScript 코드 에디터에 대한 더 자세한 내용은 다음의 링크를 참고하십시오.

http://msdn.microsoft.com/en-us/library/bb385682(v=vs.110).aspx

   

JavaScript 코드 에디터의 인텔리센스가 얼마나 똑똑해 졌는지 아래의 예시를 보면서 비교해 보시기 바랍니다.

   

Visual Studio 2010 JavaScript 인텔리센스

인텔리센스가 C#, VB.NET 과 다르게 인텔리센스의 범위가 축소가 되지 않고 그냥 다~~~ 보여주지요.

   

   

Visual Studio 11 JavaScript 인텔리센스

JavaScript 인텔리센스가 C#, VB.NET 에서 사용하는 것과 똑같이 입력하는 문자에 따라 점점 인텔리센스 범위가 축소가 됩니다. 그리고 인텔리센스 상자 오른쪽에 시그너처도 함께 표시해 주네요.

   

   

JavaScript OOP 프로그래밍 인텔리센스

특히 JavaScript OOP 프로그래밍을 할 때는 인텔리센스의 도움을 많이 받게 되지요. Visual Studio 11 의 JavaScript 구문을 제대로 분석하여 인텔리센스를 제공해 주는 것 또한 막강한 Visual Studio 11 기능이라고 할 수 있습니다.

특히 Visual Studio 2010을 사용할 때 필자는 JavaScript OOP 프로그래밍을 절대 Visual Studio 2010에서 하지 않았답니다. 왜냐하면 제대로 인텔리센스를 보여주지 못하거나 올바른 인텔리센스 목록이 제공이 되지 않으면, 아차 하는 순간 코드가 동작을 안하거든요.

   

마찬가지로 Visual Studio 2010과 Visual Studio 11의 JavaScript OOP 인텔리센스를 비교해보시죠.

   

Visual Studio 2010 JavaScript OOP 인텔리센스

아주 간단한 JavaScript Initialize 패턴과 Simple Factory 패턴의 New() 메서드를 인식하지 못합니다. 물론 아래의 코드는 잘못된 코드가 아니겠지요.

   

Visual Studio 11 Beta JavaScript OOP 인텔리센스

Visual Studio 2010 JavaScript 인텔리센스에 비해 Visual Studio 11 Beta 는 Lazy Initialize 패턴과 Simple Factory 패턴 구문을 정확하게 분석하여 인텔리센스 목록에 New() 메서드를 깔끔하게 보여주고 있습니다.

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 미냉이 2012.03.14 15:45 Address Modify/Delete Reply

    와우 정말 희소식입니다 ㅡㅠ

솔루션 탐색기의 코드 미리 보기

솔루션 탐색기에서 코드 파일의 클래스나 메서드, 필드 정보를 TreeView에서 확장하여 바로 볼 수 있게 되었군요. 물론 하위 정보들을 더블 클릭하면 바로 코드의 위치로 이동하겠죠.

   

설마 다른 개발 도구를 사용하는 분들이 보시면 여태 그런 기능도 제공이 안되었냐고 오해할 수 있을 수 있겠군요. 아래의 모든 기능들은 Microsoft에서 개발하여 배포한 Visual Studio 확장 도구를 통해 사용이 가능했었고, Visual Studio 11에 와서 Product Features로 들어가게 된 것들입니다.

   

이전 버전인 Visual Studio 2010에서 필수 앱이었죠.

PowerCommands for Visual Studio 2010, Productivity Power Tools

   

   

   

코드 윈도우 고정 핀

자주 사용하는 코드 파일을 아예 핀을 이용하여 좌측으로 고정할 수 있습니다. 필자는 구현 클래스나 참조 클래스들의 탭 위치가 뒤죽박죽이 되면 열 받아서 'Close All Windows' 를 해버리고 다시 정리하는 습관이 있었는데, 이 고정 핀 덕분에 효과를 톡톡히 보고 있습니다.

   

솔루션 탐색기 창의 다중 인스턴스

이번 Visual Studio 11에서는 솔루션 탐색기를 다중 인스턴스로 열어서 사용이 가능합니다. 아래의 그림과 같이 솔루션 탐색기가 여러 개가 열려 있지요.

필자도 이런 기능이 꼭 필요했답니다. 왜냐하면 솔루션의 폴더 구조가 복잡하거나 프로젝트 양이 많아지게 되면 솔루션 탐색기에서 마우스 휠을 올렸다 내렸다 하면서 파일을 찾느라 정신이 없거든요. 솔루션 탐색기를 한 두어개 열어놓고 미리 자주 탐색하는 위치에 스크롤을 해놓으면 훨씬 편리하겠지요…?

   

   

   

여러 툴 윈도우에 검색 기능 제공

여러 툴 윈도우에 검색 기능이 강화가 되었습니다. 자칫 "모두 똑같은 검색 아니야?" 라고 하실 수 있겠지만, 각각 검색의 기능은 다르게 작동합니다. 예를 들면, TEAM EXPLORER인 경우 원하는 Work Item을 찾거나 SharePoint 문서를 찾는데 활용할 수 있고, SOLUTION EXPLORER에서는 파일의 내용이나 파일 이름으로 검색을 할 수 있겠지요.

다음은 툴 윈도우에서 제공하는 검색 기능들 입니다.

   

솔루션 탐색기 검색

   

단위 테스트 검색

   

팀 탐색기 검색

   

도구 상자 검색

Posted by 땡초 POWERUMC

댓글을 달아 주세요

프로젝트 호환성

Visual Studio 11 에서 바로 와 닿는 편리함 중의 하나가 기존의 솔루션 파일과 프로젝트 파일을 어떤 변경 없이 그대로 열 수 있는 점입니다. 이전까지는 솔루션 파일의 구조와 프로젝트 파일의 일부 속성이 변경되어 새로운 개발 툴이 나올 때 마다 손이 갔었습니다. Visual Studio 가 해주는 자동 업그레이드를 그렇게 신뢰하지 않기 때문에 상위/하위 버전과 호환이 되도록 솔루션 파일과 프로젝트 파일을 변경했기 때문입니다. 과거에 Visual Studio 솔루션/프로젝트를 자동으로 업그레이드해 줄 경우 컴파일이 되지 않는 경우가 많았거든요.

   

   

이번 Visual Studio 11은 대부분의 솔루션/프로젝트의 구조를 변경 없이 그대로 상위 버전인 Visual Studio 11에서 사용할 수 있습니다. 재미있는 것은 예전에는 솔루션/프로젝트 업그레이드 마법사가 업그레이드를 진행하였는데, 이번 Visual Studio 11에서는 안전한 업그레이드인 경우 그냥 알아서 업그레이드하는 듯 합니다.

   

하지만, 모두 다 호환되는 것은 아닙니다. 우리가 평상시에 자주 쓰는 프로젝트 형식들은 아무 변경 없이 호환이 되지만, 일부 호환이 되지 않는 프로젝트 형식도 몇 가지 됩니다. 그리고 프로젝트 형식이 호환은 되지 않지만, 아주 사소한 변경이라면 Visual Studio 11이 그냥 알아서 업그레이드를 합니다. 여기에 대한 정보는 다음의 링크에서 확인할 수 있습니다. (

http://msdn.microsoft.com/en-us/library/hh266747(v=vs.110).aspx )

   

그 중에서 대표적으로 호환이 되지 않는 것들만 볼까요?

   

프로젝트 형식

  • Visual Studio 11 에서 열 수 없는 것들
    • Cloud tools
    • MSI setup (설치 프로젝트) - VS11 에서 없어졌지요.
    • Visual Studio Macro - VS11 에서 없어졌지요.
    • Windows Mobile - 프로젝트 형식이 없어졌지요.
    • Windows Phone - 프로젝트 형식이 없어졌지요.

   

   

  • Visual Studio 11 형식으로 업그레이드가 필요하고, 그 이후 Visual Studio 11 에서만 열리는 것들
    • F#
    • LightSwitch
    • Rich Internet Applications - 실버라이트를 의미하는 것일까요? ^^;
    • Visual Studio SDK/VSIX

         

         

  • 그 외 특수한 경우
    • Visual C++ 10.0 - 로컬 컴퓨터에 Visual Studio 2010과 Visual Studio 11 Beta 둘 다 설치되어 있어야 VC++ 10.0 프로젝트를 Visual Studio 11에서 열 수 있습니다.
    • Visual Studio 2010 Database (.dbproj) - 컨버전을 하면 열 수 있는데, 지원 안 되는 기능이 많네요. 꼭 문서 참고 하세요.

         

         

파일

  • BizTalk Flat file schemas - 파일을 추가 못함
  • Profile Reports File : 성능 프로파일 보고서 중 .vspx 파일만 열지 못함
  • Solution File : 솔루션 파일 중 .sou 파일이 있는데, 여기에 Break Point 등의 정보가 있는데 VS11 로 업그레이드 되고 나면 VS2010 에서 설정 정보를 잃어버릴 수 있다고 하네요.
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Metro Style App 성능 및 품질 관리

Visual Studio 2005부터 최상위 버전에서 제공하는 기능 중에 하나가 바로 Profile 기능입니다. Visual Studio Profile 기능은 Performance, Memory, Thread 와 같이 눈으로 보거나 사람이 오감을 이용하여 측정할 수 없는 부분을 정교하게 측정할 수 있습니다. Metro Style App 도 이런 Performance 를 측정하고 Code Analysis 로 코드의 품질을 관리할 수 있게 되었네요.

   

Metro Style App을 Profile하기 위해서는 디버깅 상태를 Local Machine으로 변경을 해야 합니다. 그리고 Analyze 메뉴에서 Launch Performance Wizard 를 선택하여 단계별로 원하는 Profile 단계를 선택하면 됩니다. Visual Studio를 이용하여 .NET 응용 프로그램 Profile을 해보신 분이라면 편하신 대로 Profile Windows에서 시작하셔도 됩니다.

   

Metro Style App의 어떤 Performance를 측정할지 정하였다면 아래의 Profile 방법을 하나 선택하시면 됩니다. 다만, Metro Style App 의 Profile 을 몇 가지 제한이 있네요.

CPU Sampling 의 경우 C#, C++, JavaScript Metro Style App 모두 Profile이 가능합니다. 다만, Instrumentation의 계측 형태의 Profile은 JavaScript Metro Style App만 지원을 합니다. 물론 .NET 응용 프로그램인 경우 모든 Profile을 모두 지원해 줍니다.

   

CPU Sampling 을 할 Metro Style App을 선택하고, 쭉 쭉 다음 단계로 이동하면 바로 Profile 을 시작할 수 있습니다. CPU Sampling 을 하려는 응용 프로그램의 모든 기능을 동작시키면 됩니다. 만들어 놓은 기능을 선택도 해보고, 쿡쿡 클릭도 해보고 하신 후, Stop Profile을 클릭하여 성능 측정을 마무리 합니다.

   

그럼, Profile 보고서가 완성이 되면 CPU Sampling 결과를 보여줍니다. 아래와 같은 보고서는 의외로 성능 지표를 분석할 때 중요한 정보를 줍니다. 아래의 Inclusive, Exclusive 등 성능 지표 결과를 보시기 어려우시다면, 꼭 Visual Studio 2010 의 성능 프로파일 MSDN 문서를 확인해보세요.

꾸준히 성능 관리를 하여 샘플링을 떠 놓으면 나중에 얼마나 성능이 좋아지고, CPU 리소스를 덜 차지하는지 비교도 해보고 하시면 Visual Studio 의 막강한 기능에 대해 다시 한번 놀라실 겁니다.

   

Visual Studio Profile 에 대한 자세한 내용은 다음의 링크를 참고 하십시오.

http://msdn.microsoft.com/ko-kr/library/z9z62c29.aspx

   

   

Metro Style App의 Profile이 완료가 되면, 아래의 그림과 같이 성능 보고서를 보여줍니다. 상단의 영역은 CPU Sampling 결과를 그래프로 보여주며, 하단은 구간별로 CPU에 가장 많이 부하를 주는 구간을 리스트업 합니다.

   

CPU Sampling 결과를 다차원으로 분석하기 위해 Current View 영역에서 항목을 선택하시면 됩니다. 프로세스별로 분석하거나 모듈, 클래스, 메서드 등의 단위로 세밀하게 분석할 수 있는 지표를 제공해 줍니다.

   

덧붙여 Metro Style App의 Profile 기능은 Visual Studio가 설치된 환경 뿐만 아니라, Visual Studio 가 설치되지 않은 환경에서도 Profile 기능을 제공 합니다. 다음의 문서에서 자세한 내용을 확인해보세요.

http://msdn.microsoft.com/en-us/library/hh696636(v=vs.110).aspx

   

   

Metro Style App 의 코드 분석

Visual Studio의 Code Analysis를 효과적으로 사용하신 분이라면 좋아할 듯 합니다. Metro Style App에서도 Code Analysis기능을 그대로 적용할 수 있습니다. 개발 초기부터 Globalization, Performance를 염두 해두신다면 Code Analysis가 큰 도움이 될 겁니다.

   

Code Analysis에 대한 자세한 내용은 다음의 링크에서 확인하십시오.

[Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요 http://vsts2010.net/39

[Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature http://vsts2010.net/41

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Metro Style App 디버깅

C#이나 C++, VB.NET 으로 한번쯤 디버깅을 해본 분이라면 Metro Style App 디버깅도 같은 방식으로 디버깅이 가능합니다. 기존의 .NET 응용 프로그램 디버깅 방식과 별 차이가 없기 때문에, 디버깅 경험 그대로 사용하셔도 됩니다.

   

   

Simulator 로 디버깅

Visual Studio 11에서는 WinRT 디버깅 환경은 일반적으로 Local Machine 디버깅과 Simulator 디버깅, Remote Machine 디버깅이 있습니다. 그 중 Simulator 디버깅 부분의 디버깅 환경이 굉장히 잘 되어있네요. 마치 ARM 코어가 탑재된 테블릿을 조작하는 느낌까지 듭니다. Simulator 디버깅은 시스템이 부팅된 후 Windows 8 구동에서 사용자 로그인까지 그대로 재현이 됩니다.

아래의 그림과 같이 디버깅 툴바 영역에서 Simulator 디버깅을 선택하고 디버깅을 시작하면 Simulator 가 구동이 됩니다.

Simulator 디버깅에 대해 더 자세한 내용은 다음의 링크를 참고하십시오.
http://msdn.microsoft.com/en-us/library/hh441475(v=vs.110).aspx

   

   

Simulator를 선택한 후 디버깅을 시작하면 아래의 그림과 같이 테블릿을 연상케 하는 Simulator 창이 뜹니다. 필자의 집 네트워크 환경은 Active Directory로 묶여 도메인으로 관리를 하고 있는데, Simulator의 사용자 로그인도 마찬가지로 도메인 로그인 되는 것을 확인할 수 있습니다.


Simulator를 통해 WinRT 샘플이 잘 동작하는 것이 확인되는군요.

   

혹시나 싶어 Simulator 디버깅 중에 Metro 바탕 화면에서 데스크탑 바탕화면으로 이동해 보았습니다. 제 로컬 컴퓨터 환경이 그대로 재현이 되네요.

Simulator 우측 패널에 터치 방식을 선택하거나 해상도를 조절하거나 테블릿을 회전시키는 조작을 하는 아이콘들이 있습니다.

   


Metro Style App 배포

Metro Style App 템플릿을 사용하여 프로젝트를 생성하면 모든 형태의 Metro 응용 프로그램의 프로젝트에는 Package.appmanafest 파일이 존재합니다. 이 파일은 Windows Store 에 앱을 배포할 때 앱 정보를 가지고 있는 파일입니다.

자세한 Metro Style App 의 배포에 대한 내용은 다음의 링크를 참고하십시오.
http://msdn.microsoft.com/en-us/library/hh454036(v=vs.110).aspx  

   

   

Metro Style App 프로젝트의 속성 페이지로 이동하면 아래의 그림과 같이 속성 페이지로 이동합니다. 이곳에서 앱의 이름과 Rotaions 타입, 전경색과 배경색 및 Splash 이미지, 그리고 앱의 호환 정보, 장치 정보를 설정하면 됩니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

지난 2012년 02월 29일, Windows 8 Consumer Preview 와 Visual Studio 11 Beta 버전이 공개가 되었습니다. 그 중 Windows 8 의 가장 큰 특징이라고 하면 WinRT(Windows Runtime)을 이용하여 Metro 응용 프로그램을 만들 수 있는 것이죠. 이전 Windows 7까지 Win32 API 를 이용하여 데스크탑 응용 프로그램을 만들었습니다만, Windows 8 에 와서는 이전 Win32 환경과 새로운 WinRT 환경에서 개발을 할 수 있습니다.

   

더 자세한 정보를 원하시면 다음의 MSDN 링크를 통해 확인하시기 바랍니다.

http://msdn.microsoft.com/en-us/library/bb386063(v=vs.110).aspx

   

쉽게 WinRT는 Metro Style App를 구동하기 위한 API 집합들이며, Win32의 Function APIs 가 아닌, 좀 더 세련되고 객체지향적으로 다듬은 차세대 윈도우 런타임이라고 생각하셔도 됩니다.

   

   

Visual Studio 11 은 Windows 8 의 Metro Style App 을 개발하기 위해 개발 템플릿을 지원해 줍니다. (프로젝트 템플릿 같은 그런 것들이죠). 그럼 Visual Studio 11 에서 제공하는 Metro Style App 의 템플릿은 어떤 것을 지원하는지 한번 볼까요?

   

분할 응용 프로그램

분할 응용 프로그램 템플릿은 사용자 지정하여 2열 보기에서 항목과 항목 세부 정보로 된 목록을 보기 위한 앱을 만들 수 있는 Metro 스타일 앱의 주요 기반이 됩니다. 이 보기에서 사용자는 항목 간에 빠르게 전환할 수 있으며 목록을 동적으로 업데이트할 수도 있습니다. 예를 들어 뉴스 읽기 프로그램, 스포츠 득점 앱, 전자 메일 앱 등이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

표 형태 응용 프로그램

표 형태 응용 프로그램 템플릿을 사용하여 Metro 스타일 앱을 만드는 것이 좋습니다. 이 템플릿을 사용자 지정하여 사용자가 범주 검색을 통해 완전히 빠져드는 콘텐츠를 찾는 앱을 만들 수 있습니다. 예를 들면 쇼핑 앱, 뉴스 앱, 사진 또는 동영상 앱이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

탐색 응용 프로그램

이 JavaScript 템플릿에는 기본 탐색, 앱 바탕 화면 도구 모음(앱 바) 및 표 형태 응용 프로그램과 분할 응용 프로그램 템플릿에서 사용되는 미디어 모드 기반 레이아웃이 제공됩니다. 탐색 템플릿에는 최소 페이지 조각 하나만 포함되어 있으며, 페이지 조각을 손쉽게 추가할 수 있습니다. 그런 다음 콘텐츠를 추가할 수 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

고정 레이아웃 응용 프로그램

이 JavaScript 템플릿은 콘텐츠가 고정 뷰포트에 맞게 되어 있다는 점을 제외하고 빈 응용 프로그램 템플릿과 동일한 최소한의 Metro 스타일 앱을 제공합니다. JavaScript에서 개발하는 대부분의 게임 앱에 이 프로젝트 템플릿을 권장합니다

DirectX 응용 프로그램

이 C++ 템플릿은 Metro 스타일 게임 개발에 사용할 수 있습니다.

   

Visual Studio 11 C# 언어에서 제공하는 Metro Style App 템플릿

   

Visual Studio 11 JavaScript 언어로 제공되는 Metro Style App 템플릿

특이하게도 JavaScript 언어로 제공되는 템플릿에만 고정 레이아웃(Fixed Layout) 템플릿을 지원하는군요.

   

Visual Studio 11 C++ 언어에서 제공하는 Metro Style App 템플릿

   

   

템플릿 샘플

각각 템플릿이 어떻게 구성되었는지 보기로 한 참에, 각 언어별로 제공되는 템플릿을 생성하여 Windows 8 에서 실행해 보았습니다.

   

JavaScript 템플릿으로 만든 Metro Style App Sample

   

   

C# 템플릿으로 만든 Metro Style App Sample

   

   

C++ 템플릿으로 만든 Metro Style App Sample

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

2012년 02월 29일, MSDN Subscriber를 통해 Visual Studio 11 Beta 버전이 공개가 되었습니다. 이전 Visual Studio 11 Developer Preview 버전 이후 외관과 기능적인 면에서 상당히 많은 변화가 생겼습니다. 이쯤에서 다시 한번 느낀 것은 '과연 Visual Studio를 능가하는 IDE 도구가 나올까?'. Visual Studio는 개발 툴 뿐만 아니라, 개발 활동에 직간접, 내외적인 대부분의 요소까지 최고의 플랫폼 도구라는 것이 자명한 것 같습니다.
 

다음의 링크를 통해 Visual Studio 11 Beta 버전을 다운로드 받을 수 있습니다.
http://www.microsoft.com/visualstudio/11/ko-kr


Visual Studio 11 Beta 버전을 시작을 알리는 설치 스크린샷 부터 시작해 보기로 합시다.
 





Posted by 땡초 POWERUMC

댓글을 달아 주세요