들어가기 앞서

팀 파운데이션 서버(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

댓글을 달아 주세요

[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으로 저장했다가 다시 복원했다가 하다가 메인 트리에 올릴 수 있을 때 체크인 하는 방식으로 쓸 수 있고 또는 아직 체크인 하기 전의 코드를 팀원이 리뷰하는 용도로 쓸 수도 있고요.

최근 2년 동안 다양한 개발 분야의 기술들이 물망에 오르는 굉장히 뜻 깊은 해였습니다. 2년 전이면 Microsoft 강성재 차장과 함께 처음으로 "Visual Studio 한국 공식 팀"을 창설하면서 http://vsts2010.net 이 탄생한 시기이군요. 2008년 12월에 팀이 창설되고, 2009년 1월 5일이 팀 블로그 2주년이 되는 날이었군요.

바로 저희 "Visual Studio 한국 공식 팀" 블로그에서 한홀 한홀 정성스럽게 작성된 포스트들이 2년 여간의 기술 흐름을 대변해 주고 있으며, 그리고 2011년의 기술도 짐작해 볼 수 있는 짧지만 굵은 변화의 흐름과 함께 여기까지 온 것 같습니다.

우리 팀이 함께 해왔던 핵심 키워드의 태그는 무엇이었을까요?

  • Visual Studio 2010
  • .NET 4.0, .NET Framework 4.0
  • ASP.NET MVC
  • C# 4.0
  • C++0x, C++/CLI
  • Parallel Computing
  • WCF
  • Cloud
  • Application Lifecycle Management

   

그리고 위의 태그들에 대해 더 자세히 살펴보더라도 생소한 기술과 이름, 아키텍처, 환경 등이 2년 동안 격변을 일으키며 변화를 해왔다는 사실입니다.

2011년 이전까지는 여러분들에게 선택권이었던 것들이, 이제는 필수가 되어야 한다고 해도 과언이 아닐 겁니다. 비즈니스 요구사항의 단면을 보면 업무적인 요인, 시대적인 배경 등인데, 이 시대적인 배경에는 트랜드+시장+기술+… 이 있을테고요. 그리고 '우리가 이 시대적인 배경 중 '기술'에 한 배를 타고 흐르고 있는가…?' 에 다시 한번 생각해 볼만 합니다.

예전 2010년 6월 1일 REMIX10 세미나에서 여러분에게 말씀 드린 마지막 문구가 다시금 생각이 나네요.

http://www.techdays.co.kr/2010spring/remix10/session3_1.html

   

여러분의 생존전력은 바로 아래에 해답이 있습니다. 여러분들에게 필요한 것, 그리고 그 가능성이 있다고 판단하시면 2011년 생존을 위하여 달려보는 것은 매우 멋진 2011년 한 해가 될 것입니다.

   

.NET 프레임워크

.NET Framework .NET 의 과거와 현재, 그리고 미래
.NET Framework .NET Framework 4.0 의 특징
.NET Framework .NET Framework 4.0 마이그레이션 이슈
.NET Framework .NET 스마트클라이언트 한계 극복 [1]
.NET Framework .NET 스마트클라이언트 한계 극복 [2]
CLR 1. Hello 世界
CLR 2. CLR! CLR! CLR!
CLR 3. MSCorLib & Metadata
CLR 4. Assembly
CLR 5. Assembly - Strongly named assemblies
CLR 6. Assembly - GAC(Global Assembly Cache)
CLR 7. System.Object
CLR 8. System.Object (2)
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-2. 네이티브 랩퍼 만들기
Managed Extensibility Framework [MEF] 1. Managed Extensibility Framework 이란?
Managed Extensibility Framework [MEF] 2. Parts 와 Contracts 선언
Managed Extensibility Framework [MEF] 3. Export 선언
Managed Extensibility Framework [MEF] 4. Import 선언
Managed Extensibility Framework [MEF] 5. Catalog 사용
Managed Extensibility Framework [MEF] 6. Lazy Exports
Managed Extensibility Framework [MEF] 7. Exports and Metadata
Managed Extensibility Framework [MEF] 8. Strongly Typed Metadata
Managed Extensibility Framework [MEF] 9. Recomposition
Managed Extensibility Framework [MEF] 10. Querying the CompositionContainer
Managed Extensibility Framework MEF Preview 6 공개
Managed Extensibility Framework MEF 는 Generic Type 을 지원하지 않는다!
Managed Extensibility Framework MEF 에 Generic Type 을 지원하기 위해서..?
Managed Extensibility Framework MEFGeneric 코드 플랙스에 공개합니다.

   

애자일 개발

Agile Development [Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
Agile Development [Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
Agile Development [Better Code]Visualize Code Relationships
Agile Development [Testing] TDD (Test-Driven Development-테스트 주도 개발)
Agile Development [Testing] BDD (Behavior-Driven Development?행위 주도 개발)
Agile Development [Testing] Moq.NET (T/B Driven Development)
Agile Development [Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
Agile Development 애자일에 대한 고찰
Agile Development [ALM-Test] 1. 왜 단위 테스트를 해야 하는가?
Agile Development [ALM-Test] 2. 한국적인 애자일 모델의 필요성
Agile Development [협업 1] 협업 도구의 통일성과 협업 인프라 관리
Agile Development [ALM-Test] 3. 테스터에 대한 오해와 진실
Agile Development [ALM-Test] 4. 테스터(SDET) 의 역할
Agile Development [ALM-Test] 5. 테스트 계획
Agile Development [ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
Agile Development [ALM-Test] 7. TDD vs 계약기반 테스트
Architect Development Architect Development ?
Architect Development 몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development 몽당연필과 함께 하는 VSTS 2010 모델링 1/4
Architect Development Windows Server AppFabric - Velocity 란?
Architect Development WCF=SOA 에 대한 고찰

   

ASP.NET 4.0

ASP.NET 4.0 [ASP.NET 4.0] 1. Core Service - Extensible Output Caching
ASP.NET 4.0 [ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(1)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Designer & Deployment
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Core Services
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - New Features in the Microsoft Ajax Library
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(1)
ASP.NET 4.0 Razor in WebMatrix
ASP.NET 4.0 Razor in WebMatrix(2) 코드의 재 사용
ASP.NET 4.0 Razor in WebMatrix(3) ? WebMatrix Helper
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(3)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(4)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(5)
ASP.NET MVC M, V 그리고 C의 각방생활(1) - ASP.NET MVC vs ASP.NET WEB FORM
ASP.NET MVC M, V 그리고 C의 각방생활(2) - ASP.NET MVC와 인사나누기
ASP.NET MVC M, V 그리고 C의 각방생활(3) - 초간단 사이트 만들기(1)
ASP.NET MVC M, V 그리고 C의 각방생활(4) - 유효성 검사
ASP.NET MVC M, V 그리고 C의 각방생활(5) - 초간단 사이트 만들기(2)
ASP.NET MVC M, V 그리고 C의 각방생활(6) - 유효성 검사(2)
ASP.NET MVC M, V 그리고 C의 각방생활(7) - 함께 즐겨요~ jQuery
ASP.NET MVC M, V 그리고 C의 각방생활(8) - jQuery와 탭메뉴 그리고 파샬뷰
ASP.NET MVC M, V 그리고 C의 각방생활(9) - jqGrid 사용해보자
ASP.NET MVC M, V 그리고 C의 각방생활(10) - jqGrid를 이용한 paging과 sorting
ASP.NET MVC ASP.NET MVC 3 Preview 1 이 릴리즈 되었습니다.
ASP.NET MVC M, V 그리고 C의 각방생활(11) - jqGrid로 데이터 추가,편집,삭제해보기
ASP.NET MVC M, V 그리고 C의 각방생활(12) - 테스팅 그거, 아무나 하나?
ASP.NET MVC JailBreak From Controllers and Actions
ASP.NET MVC VSTS2010 에서 Razor 코드 하이라이팅 지원하기

   

C# 4.0

C# [C# 4.0] Named and Optional Parameters
C# [C# 4.0] Duck Typing
C# [C# 4.0] New Extension Method "Zip"
C# [C# 4.0] Generic Covariance And Contra Variance
C# Welcome to Dynamic C#(1) - 첫만남.
C# Welcome to Dynamic C#(2) - Wanna be a polyglot.
C# Welcome to Dynamic C#(3) - 마음이 넒어진 C#
C# Welcome to Dynamic C#(4) - 극과극 비교체험.
C# Welcome to Dynamic C#(5) - Return to Dynamic.
C# Welcome to Dynamic C#(6) - Return to Dynamic (2)
C# Welcome to Dynamic C#(7) - 아낌없이 표현해 주는 나무
C# Welcome to Dynamic C#(8) - DLR이 나무를 사랑하는 이유
C# Welcome to dynamic C# 외전(1) - Generate From Usage.
C# Welcome to dynamic C# 외전(2) - Generic Method.
C# Welcome to dynamic C# 외전(3) - 감시하는 자와 감시당하는 자.
C# Welcome to Dynamic C#(9) - Dynamic Returns Again.
C# Welcome to Dynamic C#(10) - Dynamic Returns Again.(2)
C# Welcome to Dynamic C#(11) - The Phantom of The Dynamic
C# Welcome to Dynamic C#(12) - dynamic은 외로운 아이.
C# Welcome to Dynamic C#(13) - 아직도 가야할 길.
C# Welcome to Dynamic C#(14) - 철지난 만우절에 낚여서 파닥파닥.
C# Welcome to Dynamic C#(15) - A/S for dynamic.
C# Welcome to Dynamic C#(16) - dynamic이라도 이건 안되는 거임.
C# Welcome to Dynamic C#(17) - 필요한 말만 하고 삽시다.
C# Welcome to Dynamic C#(18) - 이름을 붙이면서 벌어진 일들.
C# Welcome to Dynamic C#(19) - 위너 고르기.
C# Welcome to Dynamic C#(20) - 어르신과 대화하는 법.
C# Welcome to Dynamic C#(21) - 인덱스의 힘.
C# Welcome to Asynchronous C#(0) - C#의 전설.
C# Parallel Programming [C# 4.0] Parallel Extension - [1] 병렬 처리
C# Parallel Programming [C# 4.0] Parallel Extension - [2] 병렬 처리 아키텍처
C# Parallel Programming [C# 4.0] Parallel Extension - [3] TPL(Task Parallel Library)
C# Parallel Programming Welcome to Parellel world(1) - Here comes a new challenger!
C# Parallel Programming Welcome to Parallel C#(1) - 굿바이, 그리고 안녕~~?
C# Parallel Programming Welcome to Parallel C#(2) - 계속 되는 개념 찾기.
C# Parallel Programming Welcome to Parallel C#(3) - 작업의 기본.
C# Parallel Programming Welcome to Parallel C#(4) - 작업의 기본 Part 2.
C# Parallel Programming Welcome to Parallel C#(5) - 병렬작업에서 예외가 생기면 어케...?
C# Parallel Programming Welcome to Parallel C#(6) - To be continue...
C# Parallel Programming Welcome to Parallel C#(7) - Excuse me.
C# Parallel Programming Welcome to Parallel C#(8) - 취소 쉽게 하기.
C# Parallel Programming Welcome to Parallel C#(9) - 백지장은 맞들지 말엉.
C# Parallel Programming Welcome to Parallel C#(10) - 이보게, 잠깐 뒤를 돌아보지 않겠나.

   

C++/CLI

C++/CLI C++/CLI는 미운 오리새끼 or 백조
C++/CLI .NET에서의 C++/CLI의 의미
C++/CLI [Step 01] 'C++/CLI가 뭐야?'에 답하기 && 가장 많은 프로그래밍 언어로 만드는 프로그램 만들기
C++/CLI [Step 02-1] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [Step.02-2] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [step.03] 배열
C++/CLI [Step. 04] nullptr, interior_ptr, pin_ptr
C++/CLI [Step. 05] 관리 코드의 array를 비관리 코드에 포인터로 전달
C++/CLI [Step. 06-1] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 06-2] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 07] 비관리 클래스에서 관리 클래스를 멤버로, 관리 클래스에서 비관리 클래스를 멤버로
C++/CLI [Step. 08] 프로퍼티 ( property )
C++/CLI [Step. 09] 델리게이트 (delegate)
C++/CLI [Step. 10] 이벤트 ( event )
C++/CLI [Step. 11] 열거형( enum )
C++/CLI [Step. 12] for each
C++/CLI [Step. 13] parameter array
C++/CLI [Step. 15] static 생성자, initonly, literal
C++/CLI [Step. 14] 인터페이스 ( interface )
C++/CLI [Step. 16] array 클래스에 non-CLI 오브젝트 사용
C++/CLI [Step. 17] 델리게이트에 비관리 함수를 할당하기 그리고 다음 예고
C++/CLI [Step. 18] 순수 가상 함수
C++/CLI [Step. 19] char* -> 관리코드, 관리코드 -> char*
C++/CLI [Step. 20] 닷넷에서 HalfNetwork를 사용하자 - 1
C++/CLI [Step. 21] 닷넷에서 HalfNetwork를 사용하자 - 2
C++/CLI [Step. 22] 닷넷에서 HalfNetwork를 사용하자 ? 3
C++/CLI [Step. 23] 닷넷에서 HalfNetwork를 사용하자 ? 4
C++/CLI [Step. 24] 닷넷에서 HalfNetwork를 사용하자 ? 5
C++/CLI [Step. 25] 닷넷에서 HalfNetwork를 사용하자 ? 6(마지막)

   

C++0x

C++0x [VC++] 1. 큰 변화가 기대되는 Visual C++( VC++ )
C++0x [VC++] 2. C++0x의 auto
C++0x [VC++] 3. static_assert
C++0x [VC++] 4. 우측 값 참조( RValue Reference ) - 첫 번째
C++0x [VC++] 5. 우측 값 참조( RValue Reference ) ? 두 번째
C++0x [VC++] 6. 우측 값 참조( RValue Reference ) - 세 번째
C++0x [VC++] 7. 우측 값 참조( RValue Reference ) - 네 번째
C++0x [VC++] 8. 우측 값 참조( RValue Reference ) ? 다섯 번째
C++0x [VC++] 9. Lambda ( 람다 ) - 첫 번째
C++0x [VC++] 11. Lambda - 두 번째
C++0x [VC++] 12. Lambda - 세 번째
C++0x [VC++] 13. Lambda - 네 번째
C++0x [VC++] 14. decltype
C++0x 대용량 파일 조작을 위한 C++0x의 변화
C++0x nullptr
C++0x VC++ 10에 구현된 C++0x의 코어 언어 기능들
C++0x C++0x 관련 책 "Visual C++ 10과 C++0x"
C++0x "Visual C++ 10과 C++0x" pdf 파일
C++0x [Plus C++0x] 람다(Lambda) 이야기 (1)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (2)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (3)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (마지막회)
C++0x [STL] 1. What's new in VC++ 2010?
C++0x [STL] 2. unique_ptr (1/2)
C++0x [STL] 3. unique_ptr (2/2)
C++0x [STL] 4. make_shared
C++0x [STL] 5. 에 추가된 새로운 함수들 (1/5)
C++0x [STL] 6. 에 추가된 새로운 함수들 all_of, any_of, none_of (2/5)
C++0x VS2010에서 nullptr의 알려진 버그
C++0x RValue Reference에 의한 STL의 성능향상 테스트
C++0x [STL] 7. 에 추가된 새로운 함수들 copy_if, copy_n, find_if_not (3/5)
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [0]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [1]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [2]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [3]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [4]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [5]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [6/7] 완결!
VC++ 10 Concurrency Runtime PPL task를 이용한 피보나치 수 계산
VC++ 10 Concurrency Runtime 인사 및 Multi Core, Multi Thread...그리고 VC++ 10
VC++ 10 Concurrency Runtime Concurrency Runtime
VC++ 10 Concurrency Runtime Parallel Patterns Library (PPL)
VC++ 10 Concurrency Runtime 양보할 줄 아는 Concurrency Runtime의 event
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - Task
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - 병렬 알고리즘
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for_each 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_invoke
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 마지막회
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - combinable
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 2
VC++ 10 Concurrency Runtime Concurrency Runtime(ConcRT)의 디버그 모드에서 메모리 leak 문제
VC++ 10 Concurrency Runtime Asynchronous Agents Library 소개
VC++ 10 Concurrency Runtime Asynchronous Agents Library - agent. 1 ( 상태 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? agent. 2 ( 기능 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library - message 전달 함수. 1 ( 전송 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message 전달 함수. 2 ( 수신 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 1. ( 인터페이스 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 2. ( unbounded_buffer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 3. ( overwrite_buffer & single_assignment )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 4. ( call )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 5. ( transformer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 6. ( choice )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 7. ( join & multitype_join )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 8. ( timer )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 1. ( critical_section & reader_writer_lock )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 2. ( event )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 9. ( custom )
VC++ 10 Concurrency Runtime Concurrency Runtime - 만델브로트 프랙탈 ( Mandelbrot Fractal ) 예제
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 1. ( Scheduler )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 2. ( SchedulerPolicy )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 3. ( ScheduleGroup )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 4. ( ScheduleTask )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 5. ( Context blocking )
Visual C++ 10 About Visual C++ 10
Visual C++ 10 디버깅 모드에서 역어셈블리 코드 보기
Visual C++ 10 Visual C++ 10의 변화
Visual C++ 10 [Upgrade to VC++ 10] _WIN32_WINNT 버전 문제
Visual C++ 10 VS2010 C++ 프로젝트의 디렉토리 설정

   

클라우드 컴퓨팅

Cloud 구름 속의 미래 : Windows® Azure™ Platform [1]
Cloud SQL Azure - CTP1
Cloud SQL Azure 알아보기 (1) - 데이터베이스 개체 생성
Cloud SQL Azure 알아보기(2) ? 데이터베이스 스키마 마이그레이션, 데이터 전송
Cloud 구름 속의 미래 : Windows® Azure™ Platform [2]
Cloud SQL Azure 사용 시 주의점(1) - 방화벽 설정
Cloud SQL Azure 알아보기(3) ?SQL Server 2008 R2 Nov CTP
Cloud SQL Azure 알아보기(4) ? SQL Azure Cloud App
Cloud SQL Azure 알아보기 (5)- SQL Azure 이점과 T-SQL 지원
Cloud [MS@클라우드컨퍼런스] MS 클라우드 기술과 플랫폼
Cloud 클라우드 기반 분산 컴퓨팅을 위한 AppFabric (1) : 아하! App 분산!
Cloud Hello Windows Azure / Windows Azure Platform의 이해
Cloud Hello Windows Azure / Gallery of 'Powered by Windows Azure Platform'
Cloud Hello Windows Azure / Windows Azure 개발 환경의 구축
Cloud Hello Windows Azure / Understanding Windows Azure Development Process
Cloud Hello Windows Azure / Windows Azure Tools for Visual Studio 1.2 출시
Cloud Hello Windows Azure / Windows Azure Platform 최신 소식 업데이트 (종합) [수정]
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #1
Cloud Windows Azure Update: Microsoft Project Code-Named "Houston" CTP 1
Cloud SQL Azure와 Excel 2010의 PowerPivot
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #2
Cloud Windows Azure Update: CloudStorageAccount 클래스 사용 시 주의 사항
Cloud SQL Azure Update: Dynamic Management View
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #3
Cloud Windows Azure Update: myAzureStorage
Cloud SQL Azure 와 SQL Reporting Service
Cloud Windows Azure Update: Windows Azure CDN의 활용
Cloud [작업 중] Windows Azure Update: Adaptive Smooth Streaming with Windows Azure Storage

   

게임 개발

Direct3d Mobile [d3dm 기초] 1. wm6.x 개발환경 세팅
Direct3d Mobile .NET 기반에서 공개소스 게임엔진 포팅하기
DirectX 11 [JumpToDX11-1] 사라진 Direct3D 오브젝트를 찾아서...
DirectX 11 [JumpToDX11-2]DeviceContext...넌 누구냣!!
DirectX 11 [JumpToDX11-3] Feature Level
DirectX 11 [JumpToDX11-4] ID3D11View
DirectX 11 [DX11_#1]D3D Buffer( 1 / 2 )
DirectX 11 [DX11_#2]D3D Buffer( 2 / 2 )
DirectX 11 [DX11_#3]기본적인 설정
DirectX 11 [JumpToDX11-5] 새로운 시대를 여는 DirectX11...
DirectX 11 [JumpToDX11-6] 커맨드(Command)...
DirectX 11 [DX11_#4]텍스트, 버튼 출력
DirectX 11 [JumpToDX11-7] 간편해진 리소스 처리.
DirectX 11 [JumpToDX11-8] Deferred Contexts
DirectX 11 [JumpToDX11-9] Multi-threaded Rendering 을 위한 API.
DirectX 11 [JumpToDX11-10] GPGPU 를 위한 DirectCompute.
DirectX 11 [JumpToDX11-11] DirectCompute 를 위한 한걸음!
DirectX 11 [JumpToDX11-12] DirectCompute 의 절차.
DirectX 11 [JumpToDX11-13] Tessellation 등장.
DirectX 11 [DX11_#5]DirectX11의 활용 사례(1/3)
DirectX 11 [JumpToDX11-14] DirectX9 세대의 테셀레이션( ID3DXPatchMesh 편 )
DirectX 11 [JumpToDX11-15] DirectX9 세대의 테셀레이션( IDirect3DDevice9::DrawXXXPatch편 )
DirectX 11 [알콜코더의 미리 배워보는 DirectX 11 - 입문편] 0. 누구를 위한 연재인가
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #1
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #2
DirectX 11 [JumpToDX11-16] DirectX9 세대의 테셀레이션( D3DXTessellateNPatches편 )
DirectX 11 [알콜코더의 미리 배워보는 DX11 ? 입문편] DX11에서 무엇이 추가되었나?
DirectX 11 [JumpToDX11-17] DirectX9 세대의 테셀레이션( ATI 라이브러리편 )
DirectX 11 [발표자료] 예제로 느껴보는 다이렉트X 11의 매력
DirectX 11 [JumpToDX11-18] DirectX11의 테셀레이션 ( 테셀레이션을 위한 하드웨어의 등장편 )
DirectX 11 [알콜코더의 미리 배워보는DX11 입문편] DirectX 11의 특징들
DirectX 11 [알콜코더의 미리배워보는 DX11-입문편] 1. 튜터리얼01 : 디바이스와 스왑체인의 생성

   

F#

F# Welcome to F#(1) - 첫만남.
F# Welcome to F#(2) - 두번째 만남.
F# Welcome to F#(3) - 사소한 탐색전.
F# Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
F# Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
F# Welcome to F#(6) - 비교본능.
F# Welcome to F#(7) - 클리프 행어.
F# Welcome to F#(8) - 은총알과 엄친아.
F# Welcome to F#(9) - 메이져 데뷰.
F# Welcome to F#(10) - 인도음식 카레.....?
F# Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
F# Welcome to F#(12) - 공동작업 좋치아니항가

   

MFC

MFC [MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개
MFC [MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
MFC [MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
MFC [MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
MFC [MFC/윈도우 7 멀티터치] #2 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #3 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #4 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #5 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #6 : 예제 코드 올립니다

   

RIA

RIA Expression Blend3 preview - 1.인터페이스
RIA Expression Blend3 preview - 2. Photoshop import
RIA Silverlight 3 & Blend 3 RC 공개!!!
RIA Silverlight 4 Beta 공개
RIA .Net Ria Service + IIS6 + Silverlight 4 Troubleshooting!!
RIA 실버라이트 비하인드 코드에서 바인딩하기.
RIA .Net Ria Service 와 Entities 그리고 Stored Procedure 하다가 생긴일..
RIA 실버라이트 프로그래머가 할 수 있는 최소한의 블랜드 디자이너를 위한 배려

   

SharePoint 2010

SharePoint 2010 Visual Studio 2010 에게 바란다 - SharePoint 14 Development
SharePoint 2010 SharePoint 2010 Overview
SharePoint 2010 SharePoint 2010 개발 환경 구성
SharePoint 2010 SharePoint 2010 개발 환경- Hello World 웹 파트 생성 및 배포하기
SharePoint 2010 SharePoint 2010 Web Part 생성
SharePoint 2010 SharePoint 2010 Visual Web Part
SharePoint 2010 SharePoint 2010 Feature
SharePoint 2010 SharePoint 2010 Event Receiver
SharePoint 2010 SharePoint 2010 데이터 기술
SharePoint 2010 SharePoint 2010 Server Object Model
SharePoint 2010 Visual Studio 2010 출시에 따른 SharePoint Developer Tools
SharePoint 2010 SharePoint 2010 LINQ to SharePoint
SharePoint 2010 Client Object Model - .NET
SharePoint 2010 Client Object Model ? Silverlight (1)
SharePoint 2010 Client Object Model ? Silverlight (2)
SharePoint 2010 Client Object Model - Javascript(1)
SharePoint 2010 Client Object Model - Javascript(2)
SharePoint 2010 Client Object Model ? 정리
SharePoint 2010 SharePoint 2010 개발환경 구축 가이드
SharePoint 2010 REST -.NET
SharePoint 2010 REST ? Silverlight
SharePoint 2010 REST - jQuery
SharePoint 2010 SharePoint 2010 프로젝트 디버깅
SharePoint 2010 SharePoint 2010 Developer Dashboard

   

Team Foundation Server

Team Foundation Server Visual Studio Team System 2010 (CTP10) - 작업 항목 링크
Team Foundation Server TFS 2010 설치 하기
Team Foundation Server TFS 2010 Build Service 설치
Team Foundation Server TFS 2010 설치 과정 중에 TF255040 문제
Team Foundation Server Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
Team Foundation Server Team Foundation 트러블 슈팅 가이드
Team Foundation Server Visual Studio Team Foundation Server 2010 를 설치해보자
Team Foundation Server Visual Studio Team Foundation Server 2010 설치 전 할일
Team Foundation Server VS TFS 2010 설치편 - 설치전 IIS, .NET 설치
Team Foundation Server VS TFS 2010 설치편 - 설치 시작
Team Foundation Server VS TFS 2010 구성편 - 설치 후 TFS 구성으로 점심 얻어먹기 편
Team Foundation Server VS TFS 2010 사용편 - SourceSafe? 버려~
Team Foundation Server [HowTo] Team Foundation Server 의 로컬 매핑 캐시 제거하기
Team Foundation Server [HowTo] SharePoint 2010 Beta 깨끗하게 제거하기
Team Foundation Server [HowTo] SCVMM 의 Install Virtual Guest Service 작업 중 2941 오류
Team Foundation Server [HowTo] TFS2010 의 Tfs_Analysis 웨어하우스 데이터베이스가 망가졌을 경우
Team Foundation Server [PPT] 테스트와 가상화의 만남 - 테스트 가상화(Lab Management)
Team Foundation Server Team Foundation Server 2010으로 업그레이드, 마이그레이션, 동기화
Team Foundation Server Visual Source Safe 사용자를 위한 TFS2010 시리즈

   

Visual Studio 2010

Visual Studio 2010 Visual Studio Team System 2010 CTP 만료 해결하기
Visual Studio 2010 Visual Studio 2010 의 특징
Visual Studio 2010 Visual Studio 2010 내부 빌드 최신 동영상: C# 4.0 Language + IDE + WPF Shell + Editor
Visual Studio 2010 Visual Studio 2010 & .NET 4.0 참고 자료들
Visual Studio 2010 Visual Studio 2010 Beta 1 설치부터 살펴보기
Visual Studio 2010 멀티 모니터 사용
Visual Studio 2010 Visual Studio 2010 Beta 2 출시
Visual Studio 2010 Visual Studio 2010 Beta 2 설치 미리 보기
Visual Studio 2010 VS 2010 Beta 2 설치 과정에서 Silverlight SDK 문제
Visual Studio 2010 VS2010 베타2의 WPF & Silverlight 디자이너 성능 향상 팁
Visual Studio 2010 VS 2010 기능 소개 01 인텔리 센스 기능의 변화
Visual Studio 2010 Visual Studio 2010과 Blend Preview for .NET 4 통합 문제
Visual Studio 2010 VS 2010 기능 소개 02 - IDE의 기능 추가
Visual Studio 2010 VS 2010 기능 소개 03 - IDE의 변화
Visual Studio 2010 Visual Studio 2010 출시 일정
Visual Studio 2010 VS 2010 기능소개 04 - Visual C#&VB 개발자 IDE Tips & Tricks 첫번째
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010 RC 공개 임박!
Visual Studio 2010 Visual Studio 2010 RC 공개
Visual Studio 2010 C#에서 IntelliSense가 동작하지 않을 때 문제 해결 방법
Visual Studio 2010 똑똑한 검색을 지원하는 VSTS 2010의 "Navigate To" 검색
Visual Studio 2010 실버라이트4 RC와 블렌드 4 베타 공개
Visual Studio 2010 윈도우폰 7 개발환경 공개
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (2회) - VS IDE
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (3회) - Box Selection
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (4회) - Call Hierarchy
Visual Studio 2010 Visual Studio 2010 출시와 완소 정보 총 정리
Visual Studio 2010 Visual Studio 2010 e-book 무료로 다운로드 하세요
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (5회) - Navigate To
Visual Studio 2010 Visual Studio 2010 RTM 추가 완소 정보
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (6회) - Generate from Usage
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Just for fun! / Visual Studio Express Edition
Visual Studio 2010 왜 Visual Studio 2010 이여야 하는가?
Visual Studio 2010 Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요
Visual Studio 2010 Just for fun! / DreamSpark는 대학생 여러분을 위한 솔루션입니다.
Visual Studio 2010 VS2008 을 VS2010 에서 동시에 개발하기
Visual Studio 2010 VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우
Visual Studio 2010 Introducing Visual Studio LightSwitch! - Enjoy your development
Visual Studio 2010 Visual Studio Hotfix List
Visual Studio 2010 곧 다가올 기술, Microsoft Research [1/2]
Visual Studio 2010 곧 다가올 기술, Microsoft Research [2/2]
Visual Studio 2010 Visual Studio 31 (1) - 시작, 그리고 Intellisense
Visual Studio 2010 Visual Studio 31 (2) - Startpage
Visual Studio 2010 Visual Studio 31 (3) - Temp Project
Visual Studio 2010 Visual Studio 31 (4.1) - Visual Studio 2010 Productivity Power Tools, Part 1
VIsual Studio Extensibility [Blueprints] S+S Blueprints
VIsual Studio Extensibility Visual Studio 2010 SDK 와 Readme
VIsual Studio Extensibility Visual Studio 2010 Extension Manager
VIsual Studio Extensibility [VSIX] 1. What is different from before version?
VIsual Studio Extensibility [VSIX] 2-1. How to start VSIX programming
VIsual Studio Extensibility [VSIX] 2-2. How to start VSIX programming
VIsual Studio Extensibility MousePresentationTracker - MEF 세미나 예제
VIsual Studio Extensibility [VSX] 1. Visual Studio Extensibility,, 그 시작
VIsual Studio Extensibility Visual Studio 2010 확장 모델인 VSIX 버그
VIsual Studio Extensibility VSGesture v2.0 for VS2010 is now available for download

   

우리 블로그 소식

VSTS 2010 팀 블로그 Visual Studio Team System 2010 공식 팀 블로그 맴버소개
VSTS 2010 팀 블로그 Visual Studio Team System 2010 팀 블로그 소개
VSTS 2010 팀 블로그 VSTS 2010 팀 블로그/스터디 맴버를 모집합니다.
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 지원을 마감합니다
VSTS 2010 팀 블로그 Visual Studio Team System 2010 Beta 1 공개
VSTS 2010 팀 블로그 [MSDN 주간 세미나] 발표자료 / .NET Framework와 Visual Studio : 현재와 미래 1, 2
VSTS 2010 팀 블로그 VSTS 2010 팀 3분기 맴버 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 세미나 동영상 - 6월 10일
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 추가 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 트위터를 오픈하였습니다.
VSTS 2010 팀 블로그 TECH DAY 2009 행사 오픈!!!
VSTS 2010 팀 블로그 VSTS 2010 공식 블로그 Viva 2010팀 멤버 추가 모집 공고
VSTS 2010 팀 블로그 [세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나
VSTS 2010 팀 블로그 Visual Studio 2010 팀에서 팀원 모집합니다.
VSTS 2010 팀 블로그 한국 Visual Studio 2010 사용자를 위한 트위터 커뮤니케이션
VSTS 2010 팀 블로그 C++ 개발자와 함께하는 Visual Studio 2010
VSTS 2010 팀 블로그 [무료 세미나] ReMIX 10
VSTS 2010 팀 블로그 6월 1일, 대한민국 웹 컨퍼런스의 지존 ReMIX 10가 개최됩니다!
VSTS 2010 팀 블로그 REMIX10 의 VS2010 팀 후기
VSTS 2010 팀 블로그 6월 1일, REMIX10 세미나 세션 공개
VSTS 2010 팀 블로그 [세미나] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
VSTS 2010 팀 블로그 9월 13일에 개최하는 KGC에서 강연을 합니다.
VSTS 2010 팀 블로그 KGC10에서의 VS2010 스터디 팀의 활약 모습
VSTS 2010 팀 블로그 [VSKOREA] Visual Studio 2010 정보가 한 눈에…
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [후기] C++ & 게임 개발자를 위한 개발 생산성 및 퍼포먼스 향상 전략 세미나

   

WCF

WCF WCF란 무엇인가?
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
WCF WCF의 기본 - Service Contract
WCF WCF의 기본 - Data Contract
WCF WCF 서비스의 동시성(Concurrency) - 1
WCF WCF 서비스의 동시성(Concurrency) - 2
WCF WCF - Serialization
WCF WCF Hosting - WAS를 이용한 Hosting
WCF 도메인을 여러개 등록했을때 WCF 서비스를 호스팅 할수 없어요 ㅠㅠ
WCF WCF Hosting(2) - ASP.NET 호환성(Compatibility)
WCF WCF Hosting (3) - Windows Service를 이용한 Hosting
WCF WCF Security (1) - SSL을 이용한 전송계층에서의 보안 설정
WCF WCF Security (2) - 전송 계층에서의 메세지 인증 (사용자 지정 인증)
WCF WCF Troubleshooting (1)
WCF WCF Service Configuration Editor
WCF WCF Troubleshooting (2)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2011.01.11 00:15 Address Modify/Delete Reply

    대박이군요!

  2. 구조신호 2011.06.03 18:09 Address Modify/Delete Reply

    오 한곳에 다 모여있으니 좋네요~~~~!!!!
    감사합니다!!

TDD vs 계약기반 테스트

단위 테스트를 어떻게 해야 잘 하나…?

단위 테스트를 어떻게 해야 잘 하는지는 사실 논란의 여지가 굉장히 많습니다. 왜냐하면

  • TDD를 해본 사람 vs 안해본 사람
  • TDD가 능숙한 사람 vs 능숙하지 않은 사람
  • 개발 툴에서 TDD를 제공하는 환경 vs 제공하지 않는 환경
  • 테스트 지식이 있는 사람 vs 없는 사람

어쨌든 목표는 동일합니다. 작성된 코드에 대한 테스트를 수행하는 것이죠. 일반적으로 테스트의 목표에 따라 테스트 방법이 달라질 수 있지만, 흔히 단위 테스트는 기능 범위에 한하여 테스트 코드를 작성하는 방법입니다. 어떻게 코드가 변경이 되든, 어떤 데이터소스 이든지 간에 성공해야 할 테스트는 반드시 성공하고, 실패해야 할 테스트는 반드시 실패해야만 기능이 올바르게 동작한다는 것을 최소한으로 보장할 수 있다는 것입니다.    

무엇이 단위 테스트를 어렵게 하나?

단위 테스트는 어떻게든 하는 것은 매우 쉽지만, 어떻게 해야 잘 할 수 있고, 시간을 단축하는 방법도 매우 중요합니다. 맹목적인 단위 테스트는 테스트의 목표를 상실하게 만들 수 있고, 의미 없는 더미(Dummy) 테스트 코드가 되기가 매우 쉽습니다. 그리고 더미(Dummy) 단위 테스트 코드를 양산하는 방법도 매우 쉽습니다.

  • 테스트에 대한 지식이 없는 경우
  • 처음부터 목적/목표가 없는 테스트 코드 작성
  • 테스트 방향이 잘못 설정된 경우
  • 단위 테스트 관리 방안이 없는 경우
  • 처음부터 잘못된 디자인이나 구현 도중 발생하는 디자인 결함

그리고 일반적으로 인간의 생각의 흐름은 매우 순차적입니다. 복잡한 생각 등을 결국은 순차적으로 나열을 하게 되지요. 그 대표적인 것이 자신의 머리 속에만 존재하던 사건을 도식화하는 것이 바로 육하원칙(5W1H) 입니다. 이런 육하원칙과 같이 테스트 대상을 명확하게 테스트 코드로 구현하는 것도 매우 중요한 부분입니다.

  • Who - 누가
  • When - 언제
  • Where - 어디서
  • What - 무엇을
  • Why - 왜
  • How - 어떻게

그리고 마지막으로 단위 테스트를 하는 것 중 "무엇을 테스트해야 하나?" 입니다. 테스트 대상을 어떻게 쪼개어 테스트를 해야 가장 생산적이고, 중복되지 않는 테스트를 작성하는가는 즉시 테스트의 관리 비용과도 영향을 미치는 중요한 부분이기도 합니다. 즉, 테스트 코드가 중복이 되면, 관리되는 테스트 코드의 양이 늘어나고, 그 테스트 결과가 반드시 성공/실패해야 함에도 그렇지 않게 될 수 도 있습니다.

흔히 열광하는 TDD(Test-Driven Development) 도 마찬가지입니다. 이론적으로 그 용이성은 필자도 인정하지만, 사실은 매우 실용적이지도 않고, 효과적이지도 않습니다. 더불어 위의 나열한 테스트 지식, 목표, 테스트 방향, 관리 방안, 디자인 측면에서도 명확하지 않는다면 쥐약과도 다름이 없습니다. 즉, 테스트라는 것에 집중되어 그 목표, 방향을 제시하기 힘들며, 객체지향적인 코드를 만들기도 어려우며, 실제로 지저분한 코드를 만들기 매우 쉬운 방법이기도 합니다.

즉, 인간의 생각은 매우 복잡한데, 순차적인 도식화 작업을 하지 않은 채로 순차화를 시키려 하니 테스트 코드의 품질과 소스 코드의 품질은 기대 이하가 대부분이었습니다.    

계약 기반의 테스트

최근에는 계약 기반(Contract-Based)의 아키텍처 또는 패턴의 개발이 매우 활발합니다. 코드적으로 추상화를 통해 매우 명확하며, 이런 추상화된 모형을 통해 완벽하게 모형의 인터페이스를 통해 시그너처를 구현해 나가는 방식입니다. 정확하게 계약 기반의 개발도 아니며, TDD, BDD(Behavior-Driven Development)도 아닌 그 중간적인 형태를 취하는 방법입니다.

계약 기반(Contract-Based)의 개발 방식은 이전에 자주 세미나에 언급을 하였습니다. 자동차보험의 경우 계약서와 아래와 같은 계약 명세가 존재 합니다. 이 명세가 바로 인터페이스의 모형과 시그너처에 해당한다고 봐도 무방합니다.

아래는 자동차보험의 계약 명세에 대한 상세적인 약관입니다. 이 약관은 계약 명세에 대해 자세하게 약관을 명시하고 있으며, 이것을 인터페이스의 구현이라고 보셔도 무방합니다.

즉, 인터페이스의 모형과 시그너처는 단순히 객체지향적인 인터페이스를 넘어, 계약(Contract)적인 관점의 신뢰를 이루기도 합니다. 바로 그 계약을 잘 설명했던 TechDays 2010 Spring 의 슬라이드를 몇 장 재활용해보면^^

 

계약 기반의 개발과 테스트의 장점

물론 이 계약 기반의 개발과 테스트의 장점이 없다면, 필자 또한 이렇게 침을 튀기며 얘기하지는 않을 겁니다. 이전에 얘기했듯이 테스트는 하면 할수록 어려워지고, 또한 관리하기도 무척 버거워집니다. 그 과정에 의지와 다르게 테스트의 목적과 목표가 소실되고, 테스트의 방향성을 상실하는 경우가 허다합니다. 그리고 잘못된 초기 디자인이 특히 돌이키기 힘든 어려움이 될 수 있습니다.

사실 어떤 기가 막힌 테스트 기법도 명세(인터페이스의 모형, 시그너처)가 변경이 되면 많은 노가다(?)를 감수해야 할 수 밖에 없습니다. 바로 리팩토링(Refactoring) 작업인데, 좀 더 나은 코드/디자인을 위한 것이긴 하지만, 너무 많은 리소스나 비용이 필요하다면 이 리팩토링 작업이 전혀 즐겁지 않는 작업이 되기도 합니다.

하지만 절대 변하지 않는 진리 중 하나는, 쪼개진 것을 합치는 것은 쉬워도, 합쳐 놓은 것을 쪼개기는 매우 어렵기 때문입니다.

각설하고, 계약 기반 테스트가 TDD보다 좀 더 효과적인 이유는

  • 허술하게 하는 TDD는 테스트 목적/목표가 불명확한데 테스트 코드를 먼저 짠다?
  • 보험의 약관을 가지고 명세를 만들어 간다? 무지 어렵겠는걸…?
  • 디자인 목표가 없는 추상화가 과연 올바른 추상화인가…?
  • 코드는 생각을 먼저 하고 짜는 것이 방어적/효과적/객체지향적인데, 타이핑 먼저…?

위의 나열한 몇 가지 이유만으로, 필자는 TDD를 싫어하는 이유이기도 하지만 특히 싫은 이유는 리팩토링부터 시작하는 코드는 죽어라 리팩토링으로 끝나기 마련입니다. (리팩토링을 반드시 그 자체의 의미에 두고 하는 얘기는 아닙니다) 뒤돌아서면 내심 찜찜한 기분도 들고, 좀 더 완벽함에 가깝게 디자인하려 하지 않은 것이 어찌 완벽함에 가까워지겠습니까.

물론 어떤 테스트 기법이든지 "경우에 따라 잘 맞을 때가 있고 안맞을 때"가 있습니다. 다만, 이런 TDD 기법 하나로 찬양하다시피 어떠한 올바른 방향을 제시하지 않는 것은 매우 위험한 발상이기도 합니다. 필자는 TDD 의 울타리에서 벗어나야만 올바른 TDD 를 할 수 있다고 생각을 하며 이만^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

샘플 프로그램으로 시작해보자고!!

아주 간단한 Windows Forms 어플리케이션을 작성해 보았습니다. 실제로 실무에서는 이렇게 간단한 프로그램을 만드는 개발자도 없겠지만, 아주 간단한 것 부터 시작하여 테스트의 필요성과 테스터의 역할이 얼마나 중요한지 알 수 있는 시간이 되길 바랍니다.    

아래의 윈폼 어플리케이션은 숫자A와 숫자B 를 더하여 결과를 보여주는 프로그램입니다. 아래와 같이 간단하게 디자인을 하였습니다.

   

소스 코드는 더할나위 없이 간단합니다. 특별한 설명은 하지 않겠습니다.

이 프로그램으로 1과 2 값을 입력하면 당연히 3이라는 결과가 출력되어야 합니다 아래와 같이 말이죠.

프로그램이 완벽하지요?? 정말일까요?? 특히 프로그램을 개발하는 개발자의 시각은 테스터와 매우 다릅니다. 일반적으로 개발자에게 스팩(Spec)을 구현하는 명세서가 전달이 됩니다. 아래는 간단한 구현 명세서 입니다. (단, 화면 명세서가 아닙니다)

   

구현 명세서

제목

두 숫자를 입력 받고 합을 구하는 기능

기능

1. 테스트 박스 1에 숫자를 입력할 수 있다.
2. 텍스트 박스 2에 숫자를 입력할 수 있다.
3. 새로운 텍스트 박스에 텍스트 박스 1과 텍스트 박스 2의 합을 출력한다.

   

테스터(SDET) 의 힘이 발휘되는 순간!

개발자는 위의 명세서를 보고 두 숫자를 입력 받아 출력하는 프로그램을 아래와 같이 구현합니다.

사실상 동작에 아무런 문제점이 없지만, 테스터의 시각에서는 전혀 다릅니다. (물론 구현 명세서가 부정확하긴 합니다) 즉 숫자의 입력 범위가 매우 불확실합니다. 정수만 입력되는 Integer 값인지, 32Bit 부동 소수점을 표현하는 Float 인지 아무런 정보가 없기 때문이겠지요.

테스터는 바로 버그를 발생시킬 수 있는 프로그램의 코드나 사용성에 대해 즉각 테스트를 수행합니다. 개발 소스 코드가 제공이 된다면 해결 방안까지 제시할 수 있겠지만, 그렇지 않는다면 오로지 테스터의 경험과 실력에 의존할 수 밖에 없습니다. 그렇기 때문에 SDET 는 개발자(SDE) 와 동등한 기술 능력을 갖추거나 그 이상의 능력을 필요로 하게 됩니다.

위의 간단한 프로그램을 테스트하기 위해서는 SDET 는 테스트 케이스(Test Case) 를 작성합니다. 테스트 케이스(Test Case) 를 작성하는 목적은 기능이 올바르게 동작한다는 가정하에 잠재적인 버그(Bug) 를 유도하는 작업입니다. 그리고 테스트 케이스에 대해서는 차후에 자세히 다루도록 하겠습니다.

만약, SDET 가 아래와 같은 값을 입력했다면 어떻게 될까요? 즉시 프로그램은 오류를 뱉고 말 것입니다. 아래와 같이 말이죠.

   

물론, SDET 는 소프트웨어 버전이 매번 릴리즈 될 때마다 위와 같이 무식하게 수동 테스트(Manual Test) 를 수행하지 않을 것입니다. 이 수동 테스트를 개선하기 위해 자동화 테스트를 수행할 것이며, 이 부분 또한 차후에 설명할 예정입니다. 간단히 설명하자면 반복적으로 테스트를 수행한 가치나 목적이 있다는 자동화 테스트 대상이 될 수 있습니다.

위의 무식한 테스트 과정을 자동화 하기 위해 단위 테스트(Unit Test) 를 사용하여 아래와 같이 작성할 수 있습니다. (아래의 UI 테스트와 관련된 부분이며 마찬가지로 차후에 상세히 설명할 예정입니다, 단, 자동화 테스트 이외의 비기능 테스트가 무식하다는 것은 아닙니다.)

   

이 테스트는 아쉽지만, 무자비하게 오류를 발생합니다. 프로그램 소스 코드의 int.Parse 는 정수 값만 변환 가능하므로, 소수점이 포함된 "1.1" 값은 FormatException 을 발생하게 됩니다.

이런 결함에 대한 버그 리포트를 개발자에게 할당하게 되면, 아마도 아래와 같이 프로그램의 소스 코드가 int.Parse 에서 float.Parse 로 변경될 수 도 있겠지요.

위와 같이 코드를 수정하면 프로그램을 정상적으로 동적을 합니다. 아래와 같이 말이죠^^

   

정말 버그가 해결된 것일까?

FormatException 에 대해 SDET 가 테스트한 테스트 코드를 통해 개발자(SDE) 가 코드를 수정하였습니다. 그리고 원하는 테스트는 다행스럽게도 통과(Pass) 했습니다.

   

모든 소프트웨어는 그 품질을 향상하기 위해 테스트를 진행합니다. 하지만, 버그가 없는 소프트웨어란 있을 수가 없습니다. 위와 같은 다행스럽게 SDET 가 버그나 결함을 발견하였더라도 앞으로 발견될 잠재적인 버그는 언제나 소프트웨어가 내포하고 있습니다. 즉, 완벽한 소프트웨어는 없다는 것이지요. SDET 는 이러한 버그와 잠재적인 버그를 효과적으로 발견 해야하는 매우 중대한 업무를 수행하는 직군입니다.

현대의 소프트웨어는 인터넷의 발달로, 언제나 제작사에게 피드백을 건의하고 버그를 건의하는 시스템이 구축이 되어 있습니다. 그 중 Microsoft 의 대표적인 것이 아래와 같습니다.

  • CEIP(Customer Experience Improvement Program)

    고객 또는 사용자의 동의하에 고객 경험 개선 프로그램에 참여할 수 있습니다. 이 정보는 고객의 피드백을 수집하기 위한 정보로 활용이 됩니다.

  • WER(Windows Error Reporting)

    Microsoft Windows 제품은 실제 매우 광범위한 영역과 자원과 비용이 할당된 제품입니다. 이 제품에서 발생하는 오류나 버그를 수집하기 위해서 WER 프로그램이 윈도우 내부에 탑재가 되어 있습니다. 이 정보를 기반으로 윈도우의 차기 버전이나 패치 버전에서 우선 순위로 할당되는 중요한 정보로 활용이 됩니다.

  • CER(Corporate Error Reporting)

    일반 고객이 아닌 기업 대상으로 소프트웨어를 사용한다면, 기업 내부에서는 오류 정보가 Microsoft 로 전송되는 것을 원치 않을 경우가 많습니다. 왜냐하면 기업의 시스템의 배치, 소프트웨어의 활동 등이 기밀 정보가 될 수 있고, 매우 조심스러운 부분이기 때문입니다. CER 은 Microsoft 로 정보가 전송되지 않고 기업 내부에서 관찰할 수 있는 프로그램입니다.

  • 스마일 전송 프로그램 : 추후에 설명할 예정입니다. 간략하게 고객이나 사용자의 감성을 데이터베이스화 하고자 하는 Microsoft 사용성 향상을 위한 프로그램 입니다.

   

개발자 보다 더 똑똑한 테스터!

위의 int.Parse 를 float.Parse 로 바꿈으로써 버그가 해결되었다고 볼 수 있습니다. 하지만 진정으로 버그가 해결되었다고 볼 수 없기도 합니다. 왜냐하면 테스트 케이스를 만족하지만 다양한 부류 집단인 '베타 테스트'에서는 전혀 다른 결과가 나올 수 도 있으니까요. 그리고 테스터는 바로 이러한 버그의 발생을 아키텍처/코드/기능적인 부분을 고려하여 버그를 유도할 수 있습니다.

만약, 유능한 SDET 라면 Float 으로 인한 결과 값 버그를 아래와 같은 테스트 케이스로 작성할 수 있습니다.

   

왜 결과 값이 당연이 1이 되어야 하지만, 1.000054 라는 황당한 값이 나왔을까요? 바로 컴퓨터의 내부 연산이 2진수로 이루어 진다는 것을 모르는 개발자나 테스트는 위와 같은 오류를 예감하지 못할 것입니다. 저 또한 제니퍼소프트의 정성태 과장님을 통해 이러한 문제를 처음 알게 되었으니까요.

정성태 과장님의 설명에 의하면,

"2진수의 소수점 표현들이 자리수에 따라서 1/2, 1/4, 1/8, 1/16, 1/32, 1/64 와 같은 식으로 표현이 되는데, 십진수 0.5 는 다행히 정확하게 1/2 에 맞아 떨어지지만, 십진수 0.6 은... 겨우 0.1 차이일 뿐인데 0.10011001100110011001 와 같은 2진수로 되어 버립니다. 근데 이것도 근사치일 뿐이지 1001 패턴이 계속 무한 반복 되어버리죠. 정밀도를 높이면 0.6 은 0.010011001100110011001100110011001100110011001100110011 로 표현이 되어버립니다."
더 자세한 내용은 http://k.daum.net/qna/view.html?qid=3wykn&aid=3xIOa 참고하세요.

만약, 이러한 문제가 회계 업무나 우주 공학에 적용이 된다면, 수억, 수십, 수 조원이 투입된 프로젝트에서 불에 뻔하듯 우주선이 폭발하거나 궤도를 이탈할 수 도 있는 심각한 문제를 발생할 수 있습니다. 실제로 이러한 문제로 일부 고객은 손해 금액에 대하여 마이크로소프트를 대상으로 법적인 대응을 한 사례도 있습니다.

Microsoft 가 이 문제를 몰라서 그랬을까요? 그렇지는 않습니다. IEEE(Institute of Electrical and Electronics Engineers) 표준으로 사용되었던 C 언어와 Pascal 언어간의 원활한 데이터 전달을 위해 C# 의 Float 도 같은 방식의 연산이 사용된 것입니다. 더 자세한 내용은 http://support.microsoft.com/kb/42980/ko 를 참고하세요.

   

그럼 어떻게 해결하나?

위와 같이 int.Parse 는 결함을 유발하기 매우 쉽지만, float.Parse 의 경우 더 깊은 이해가 필요합니다. 만약 테스트 케이스(Test Case) 가 이것을 유추하지 못한다면 얼마 되지 않아 소송에 휘말릴 수 있는 충분한 근거가 되겠지요. 만약 구현 명세서를 간파한 SDET 라면 이 수치에 대한 근거를 요구할 것이며, 테스트 과정에서 IEEE 745에 대한 테스트를 수행했을 테니까요.

현명한 테스터라면 float.Parse 의 타입을 Decimal 로 변경하기를 권장할 것입니다. Decimal 은 부동 소수점의 오류나 반올림에 대한 이슈를 해결할 수 있는 구조체(Struct) 입니다. 즉, 아래와 같은 구현이 회계 업무에 버그가 없는 코드가 될 것입니다.

   

테스터의 역할

테스터(SDET) 는 위의 간단한 예시와 같이 다양한 테스트를 진행하는 역할을 수행합니다. 그리고 그 역할이 매우 단순하고 초보 개발자가 수행할 수 있는 단순한 작업이 아님을 알 수 있습니다.

테스트 케이스(Test Case) 를 만들고, 다양한 테스트 시나리오를 계획하는 테스트 계획(Test Planning) 을 함으로서 소프트웨어의 잠재적인 버그를 하나씩 제거하는 매우 막중한 임무를 수행하는 직군입니다. 그리고 SDET 의 역할이 개발자(SDE) 의 코드적인 목적을 정확하게 간파하지 못하거나, 제품 전체적인 아키텍처, 프로세스를 이해하지 못한다면 더욱 더 많은 문제에 봉착하게 됩니다.

본 회에서 SDET 가 가지는 역할을 강조하기 위한 것이며, 추후에 테스트를 수행하기 위한 공학적인 기법에 대해서 차근 차근 알아보도록 할 예정입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지송 2010.08.06 15:47 Address Modify/Delete Reply

    잘보고 갑니다. float 연산관련해서는 글보고 처음 알았네요.

    다음에 또 들리겠습니다. 더운 여름 잘 보내세요.

테스터에 대한 오해와 진실

이전 단원에서 "왜 단위 테스트를 해야 하는가" 에 대해 이야기를 해 보았습니다.

그리고 테스터의 역할 정의를 아래와 같이 하였습니다.

  • 업무 도메인의 이해
  • 테스트 도구 사용
  • 전반적인 테스트 시스템 인프라 와 운영체제(OS) 의 이해

하지만 필자도 테스트에 대한 공부를 시작하면서 몇 가지 오해를 하였던 것이 사실이었습니다. 필자는 대부분 SI, 컨설팅, 솔루션 개발을 하였고, 개발자 대신에 테스트를 해 주는 역할이 테스트라는 엄청난 함정에 빠졌던 것입니다. 자칫 함정에 빠진 이유는 SI 개발과 SM 이라는 유지 보수 업무의 장기 선상으로만 빗댄 것이었죠. 더불어 테스터의 역할은 업무에 따라서 충분히 달라질 수 있다는 것을 알게 되었습니다.

아마 대부분의 IT 개발직에 몸 담으신 분들이라면 저와의 생각과 크게 다르지 않을 것이라고 생각합니다. 일반적으로 작은 조직에서는 테스터(Tester) 직무만 보유하지만, 특히 대기업, 솔루션 업체나 게임 업계에서는 QA(Quality Assurance-품질 보증) 팀을 자체적으로 보유하는 것으로 알고 있습니다.

QA(Quality Assurance) 팀은 주로 소프트웨어의 버그/결함을 발견하고 개선하기 위한 업무가 수행됩니다. 그렇다면 이 QA 팀의 테스터는 기술자인가? 아니면 그냥 그저 그런 테스터인가? 기술자라면 어느 정도의 기술 요구사항이 필요한지, 그냥 테스터라면 어떤 단순 업무가 수행되는지, 궁금하지 않으십니까?    

소프트웨어 1위 업계는 어떻게 구성이 되었는가?

단연, 소프트웨어 1위 업계는 Microsoft 입니다. Microsoft 는 초기 솔루션(제품) 이 개발되기 시작하면서(당시 1979년 인턴부터 시작하여) 테스터를 모집하여 참여했다고 합니다. 초기에는 STE(Software Test Engineer) 와 SDE/T(Software Development Engineer in Test) 라는 두 개의 직함이 있었는데, STE와 SDE/T 의 직무는 사실상 약간의 차이를 보였습니다.

STE 의 직무는 테스트 플래닝(Test Planning), 핵심 테스트, 테스트 자동화와 같은 테스트를 리드하는 직무였고, SDE/T 는테스트 코드 작성, 코드 리뷰, 테스팅 툴 개발 등 실제로 일선에서 테스팅을 수행하는 직무였습니다. 2002년도 부터 SDE/T 직함을 없애려고 하였고, 2005년도에 SDE/T 가 SDET 로 명명되었습니다. 실제로 당시 시대적 배경으로 암시해보면 STE 의 비중보다 SDET 의 비중과 직원 증가율이 높았습니다. 왜냐하면 STE 는 주로 자동화 테스팅과 관련된 직무를 수행했는데, 사실상 시대적인 기술 한계 등으로 많은 활성화가 되지 않았던 것 같습니다.

결국 SDET 로 테스트 관련 직군이 모두 통합이 되었지만, SDET 도 각 직급이 존재하였습니다.

  • SDET1 : 테스트 케이스를 구현
  • SDET2 : SDET1 과 큰 변화는 없지만, 영향력이 고객과 직접적으로 의견을 교환할 수 있습니다.
  • Senior Software Development in Test : 테스트와 관련된 아키텍처가 가능하고, 문제를 해결할 수 있는 능력
  • Principal Senior Software Development Engineer in Test : 조직을 관리하고 테스트 방법론, 테스트 기술 혁신을 제시
  • Partner Software Development Engineer in Test : 조직 및 제품 전반을 이해하고 기술 혁신을 선도

특히, 현재 Microsoft 의 SDET 의 인원은 9,000명 넘는 인원이 직무를 수행 중이며, Microsoft Office 2007 제품에는 3,000 여명의 SDET 가 투입되었다고 합니다. 아래는 2008년도 대비 전세계 80,000여명이 넘는 직원 중의 각 분야별로 인원입니다. 특히 '제품 개발 및 지원' 은 SDE/SDET/Op(Operations)/IPE(International Project Engineering-현지화) 등등 을 모두 합한 것으로 9,000명의 SDET 라는 것은 거의 SDE 보다 SDET 가 더 많다고 합니다.

Op(Operations)
IT 분야를 관리하고, 네트워크, 서버를 관리 및 유지보수 하는 분야입니다. 즉 Microsoft 의 인프라를 주로 담당하며, 효과적으로 비용을 절감하거나 품질 좋은 서비스를 제공하기 위한 분야입니다.
IPE(International Project Engineer)
Microsoft 제품은 대부분 다국어 제품으로 출시하는데 각 나라의 특성에 맞게 변형하는 역할 (참고 : 국제화(i18n, internationalization): (1) 그거 번역하는거 아냐?)

SDET 의 자격 요건!!

SDET 는 적어도 소프트웨어 업계 1인자인 Microsoft 에서는 매우 중요한 직무임이 틀림이 없습니다. 그것이 우리나라에서는 SDET 의 역할이 그리 중요하지 않거나, 빅3 SI 업계에서는 공학적인 측면만을 강조하고 있다는 느낌이 드는 것도 사실입니다. (적어도 .NET 분야에서는 말이죠^^;)  

SDET 는 소프트웨어나 제품이 출시하기 위해 매우 막중한 임무를 수행하는 직무입니다. 한 명의 SDET 가 최선을 다하지 못한다면 버그/결함이 고스란히 고객에게 영향을 미치게 될 것이 분명합니다. SDET 는 소위 우리나라의 '베타 테스터'와 같이 먼저 사용해보고 평가나 버그를 제작사에게 알려주는 것이 아닌, 버그/결함을 제거하는 사명을 띠는 매우 크리티컬한 분야입니다.

버그와 결함에 대해서는 다음 회차에 명확히 할 예정입니다.

그렇다면, SDET 는 어떤 자격 요건을 갖추어야 할까요?

  1. C# 과 같은 객체지향적 언어 또는 필요한 언어적인 기술을 완벽히 갖추어야 한다.
  2. 특정 버그/결함을 디버깅하거나 리팩토링/개선이 가능해야 한다.
  3. 제품에 대한 기술적인 배경 지식을 갖추어야 한다.
  4. 제품이나 도메인에 대한 전체적인 프로세스/아키텍처를 이해할 수 있어야 한다.
  5. 테스트 케이스를 계획하고 테스트 공학적인 지식을 갖추어야 한다.
  6. 다양한 방법/기법으로 테스트 케이스를 작성할 수 있어야 한다.
  7. 테스트 케이스를 작성하거나 테스트 자동화에 대한 지식이 있어야 한다.
  8. 개발, 기획, 운영 팀 등과 커뮤니케이션을 원활하게 할 수 있어야 한다.

만약, 이 중에서 5개 이상 스스로 가능하다고 판단되지 않는다면, 필자와 함께 "[ALM-Test]" 연재를 꾸준히 구독하길 바랍니다. 그리고 5개 이상 수행이 불가능하다면 이미 SDET 가 아닌, "베타 테스터"라고 자칭하셔야 합니다.

필자 또한 테스팅 분야에 관심이 많았지만, 본격적으로 막 뛰어는 풋내기나 다름이 없기 때문에, 꾸준히 저와 함께 정보를 공유하거나 경험이 많은 분들의 가르침이 필요하다고 생각을 합니다.^^    

왜 테스팅 분야에 뛰어 들었나요?

저는 약 1.5년 전부터 애자일(Agile) 방법론과 프로세스에 매우 관심을 갖게 되었습니다. 그리고 결국 깨닫게 된 것은 애자일을 경험하면서 우리나리 현실과 부합되지 않는다는 것을 몸소 느꼈습니다. 물론 제가 잘못된 애자일을 수행했을 가능성도 없지 않겠지요. 애자일은 점진적이고 반복적인 프로세스로 단지 프로세스 뿐만 아니라 사람 그리고 인격을 강조한 기만한 방법론이지만, 사실상 우리나라에서는 조직의 작은 팀 내부에서만 불화음 없이 수행 가능하던 그저 그런 것이었습니다. (참고:애자일에 대한 고찰)

어떠한 고객도 관심 없는 XP(eXtreme Programming), Scrum 를 수행하면서 자기 만족 수준에 불과했으니까요. 하지만, 일부 애자일 프로세스가 권장하는 방법을 버리고, 개선/조합하니 왠걸??? ^^

어떤 미친 기업에서 SDE:SDET=1:1 비율로 배치가 가능하며, 아무리 좋은 사례를 가져와도 실패하고 맙니다. 뿌와쨔쨔님의 영어이야기 중 "한국 미국, 자기소개의 차이점?" 을 보면서 또 한번 느낀 것이, 조직 단위 뿐만 아니라, 개인 단위로 이미 상하관계가 형성된다는 것입니다. (물론 단지 이런 이유 뿐만은 아닙니다)

Visual Studio 와 .NET 은 이미 테스팅 분야에 혁신을 진행하고 있고, 우리나라에서 소외되는 테스팅 분야에서 많은 할 일이 남아 있을 것 같아요. 작은 경험이나마 공유하고 도움이 되는 실전 테스팅 기법에 대해서 차근 차근 공부하면서 여러분들에게 알려드릴 계획입니다. 그리고 함께 생각을 정리하는 시간이 되길 바랍니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. dekorasyon 2012.04.19 22:11 Address Modify/Delete Reply

    아주 좋아요. 감사

  2. boya badana 2012.06.30 02:24 Address Modify/Delete Reply

    아주 좋아요. 감사

  3. 감사합니다 2019.01.31 15:23 Address Modify/Delete Reply

    본문 내용중에
    일부 애자일 프로세스가 권장하는 방법을 버리고, 개선/조합하니 왠걸???
    이런 내용이 있는데 개선 / 조합을 통해 어떤 프로세스가 탄생했는지 궁금합니다^^

본 원고는 월간 마이크로소프트 2010년 3월호에 기고한 원문입니다.

 

Visual Studio 2010 활용한 ALM(Application Lifecycle Management)

 

 

 

 

 

  1. ALM 이란 무엇인가?
  2. 효율적인 프로젝트를 위한 애자일한 프로세스 프로세스 강요
  3. 명확한 작업의 관리와 지속적인 통합 추적성
  4. 과거와 현재를 알면 미래가 보인다 가시성
  5. ALM 가상화의 만남 Test and Lab Management

 

엄준일 : 닷넷엑스퍼트(.NETXPERT) 선임 컨설턴트로 재직 중이며, Microsoft Team System MVP 활동하고 있다. 많은 대기업 프로젝트와 컨설팅 경험을 바탕으로 좋은 소프트웨어를 만들기 위한 기반을 만들며, .NET 우리의 미래 동반자임을 확신하고 꾸준히 새로운 기술을 전파하고 있다. (http://blog.powerumc.kr)

 

 

 

 

작성자: 엄준일 선임/ Microsoft MVP

감수자:안재우 수석/Microsoft MVP


ALM(Application Lifecycle Management) 의 개요

 

최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.

   

ALM 이란?

ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.

   

ALM 등장배경

예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.

   

SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.

   

그림 1 일반적인 폭포수(Waterfall) 모델

   

하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.

   

그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.

   

폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.

   

그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.

   

ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.

   

그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.


 

프로세스 강요(Process Enactment)

일관된 프로세스를 강요해야 함

가시화(Visibility)

모든 전반적인 활동에 대한 진행 상황을 볼 수 있어야 함

추적성(Traceability)

모든 활동이나 산출물 등 연관 관계를 추적할 수 있어야 함

1 ALM 3대 구성 요소

   

   

하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.

   

이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.

   

ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.

   

그림 2 ALM 의 전체적인 컨셉

   

최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.

   

ALM 0.5 (미성숙 단계)

단순히 여러 가지 소프트웨어 개발 도구를 통합한 제품

ALM 1.0

개발 프로세스의 일관성과 소프트웨어 개발 도구를 통합하고, ALM 실현이 가능한 제품

ALM 2.0

다양한 플러그인의 조합 가능하고 크로스 플랫폼 간의 표준적인 방안을 제시.
조직 내부 뿐만 아니라 시장에서의 각종 요구 사항 또는 변화에 대응

표 2 ALM 의 단계별 정의

   

위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.

   

ALM 의 오해와 진실

ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.

   

Q: 그럼 도대체 ALM 은 무엇인가요?

A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.

   

ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.

   

최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.

   

Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.

   

실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.

   

하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.

   

분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.

   

Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?

A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.

   

소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.

   

Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?

A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.

   

아래는 오픈 소스 중에 .NET 환경에서 사용할 수 있는 도구들을 정리한 표입니다.

  

Feature

Visual Studio

Team Foundation Server

Open Source

요구 사항 및 변화 관리

요구 사항 관리

이슈 관리

제품 관리

TFS Work Item Tracking

Trac

Trac Explorer

Redmine

설계

모델링

디자인

Visual Studio UML

Objecteering

StarUML

UmlDesigner

구현

개발

Visual Studio

SharpDevelop

MonoDevelop

소스 관리

TFS Source Control

SVN

TortoiseCVS

테스트

단위 테스트

Visual Studio

NUnit

NUnit Addin for Visual Studio

Test Driven.NET

성능 테스트

Visual Studio

FWPTT load testing web applications

NTime

테스트 관리

Visual Studio

Test and Lab Management

?

UI 테스트

Visual Studio

.NET Framework UI Automation Library

Avignon (HTML, Winform Test based java)

지속적인 통합

빌드 자동화

TFS Team Build

NAnt

통합

TFS Source Control

TFS Team Build

CruiseControl.NET

코드 리뷰

코드 인스펙션

Visual Studio

FxCop

StyleCop

코드 메트릭스

Visual Studio

Reflector Addin

코드 커버러지

Visual Studio

NCover

팀 코드 리뷰

Visual Studio

Review Board

SmartBear

프로세스

프로세스 강요

TFS Process Template

?

보고서

SQL Server Reporting Service

?

역할 구분/보안

TFS

?

팀 포털/정보 공유

Sharepoint

FlexWiki

ScrewTurn Wiki

다른 도구와 통합

Microsoft Office

Sharepoint 등

?

확장성

TFS Object Model

Visual Studio Extensibility

?

표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교

   

하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 머샤머샤 2010.04.13 17:40 Address Modify/Delete Reply

    ALM 0.5, 1.0, 2.0 마치 CMMI Level 1,2,3... 같은 느낌으로 다가옵니다. :)

    0.5 단계라도 효율적으로 잘 사용 하는 팀도 많을것 같습니다만, (중요한건) 모든 개발팀원들이 ALM에 깊은 관심을 가지고 있는 것은 아니고, 팀이 Long-Run하면서 계속 느낌을 유지하는 것도 쉬운일은 아니기 때문에, TFS처럼 잘 짜여진 시스템으로 잘 세팅해 두면 정말 좋겠지요.

    물론, TFS를 유지하기 위한 팀의 노력은 계속되어야 하겠지만 말입니다.

    • 땡초 POWERUMC 2010.04.13 21:20 신고 Address Modify/Delete

      좋은 의견입니다.
      저 또한 머샤님과 크게 생각이 다르지 않습니다.
      다만, ALM 0.5 세대는 단순히 통합을 위한 의지이지,
      어떠한 가치있는 활동을 위해 ALM 1.0 보다 힘들거라는 생각입니다.
      말씀대로 어떤 것을 선택하셔도 유지 관리하기 위한 노력은 필요합니다.

Team Foundation Server 2010 은 많은 부분 획기적인 변화를 가져왔습니다. 기능적인 부분은 더할 나위 없거니와 관리적인 부분은 이전 버전을 운용해 보신 분이라면 과히 편해졌다고 할 수 있습니다. AT(Application Tier) 와 DT(Database Tier) 전반적인 부분에 걸쳐 한 자리에서 관리적인 부분을 모두 커버할 수 있기 때문입니다.

하지만, Team Foundation Server 2010 의 새로운 기능 중의 Test & Lab 부분이 상당히 강력해졌지만, 새로운 플랫폼과의 결합과 새로운 개념 등으로 환경 구축이 쉽지만은 않습니다. 필자도 이러한 부분에서 많은 부분 시행 착오를 겪으며 정리한 내용을 공유하고자 합니다.

Team Foundation 의 운용을 어렵게만 느끼지 마시고, 문제가 발생하면 바로 아래의 링크를 통해서 확인해 보는 것도 좋은 방법일 것 같습니다.^^

이 문서는 지속적으로 업데이트 될 예정입니다.

마지막 업데이트 : 2010-04-06

   

Test & Lab Manager

[HowTo] 가상 Lab 환경의 가상 머신 시작하기
[HowTo] Lab Manager 환경 구성 중 TF260078 오류 해결하기
[HowTo] 가상 Lab 배포 중 오류 해결하기 TF259115
[HowTo] Lab Manager 에서 가상 Lab 환경 만들기

   

Visual Studio 2010

[HowTo] Work Item 쿼리를 Excel 로 내보내기 할 수 없는 경우 TF80012 에러

   

Team Foundation Server 2010

[HowTo] Team Foundation Server 2010 FQDN 설정 방법
[HowTo] TFS 설치 중 Reporting Services 관련 오류 Error 28805
[HowTo] Team Project Collection 옮기거나 복원하기 TF246081
[HowTo] TFS 2005/2008 데이터베이스를 TFS 2010 으로 마이그레이션
[HowTo] Team Project Collection 이름 변경하기

   

System Center Virtual Machine Manager

[HowTo] SCVMM 에서 암호화된 파일 전송을 사용하지 않으려면?
[HowTo] SCVMM 라이브러리 템플릿 만들기
[HowTo] SCVMM 의 라이브러리 템플릿 배포 작업이 무한 대기할 경우

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요