Visual Studio 2010 공식 팀 블로그 @vsts2010

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

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

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

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

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

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

구현 명세서

테스터(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 가 가지는 역할을 강조하기 위한 것이며, 추후에 테스트를 수행하기 위한 공학적인 기법에 대해서 차근 차근 알아보도록 할 예정입니다.

협업이 필요한 이유

최근의 소프트웨어 개발은 점차적으로 엔터프라이즈화 되어 가고 있습니다. 대용량/대규모화 되어가고 있는 현대의 소프트웨어 생태계에서 마치 새로운 트랜드로 자리잡고 있는 엔터프라이즈 2.0 이 자리를 잡고 그 규모를 넓혀가고 있습니다. 엔터프라이즈 2.0 은 Web 2.0 과 결합된 의미로써 즉, Enterprise social software(http://en.wikipedia.org/wiki/Enterprise_2.0) 라고 보아도 크게 의미는 다르지 않습니다.    

엔터프라이즈 소프트웨어는 대용량/대규모/보안 등의 핵심 키워드로 그 아키텍처가 매우 민감한 부분이기도 합니다. 하지만 엔터프라이즈 2.0은 기존 엔터프라이즈에 개방/공유 등을 강조하면서 바로 협업과 맞물리는 부분이기도 합니다. 그리고 이러한 움직임은 국가적인 차원의 거버먼트 2.0(http://blog.powerumc.kr/252)과 매우 유사하기도 합니다.    

즉, 중요한 것 중 현대의 소프트웨어 개발은 더 이상 폐쇄적인 환경을 거부하며, 최소한의 자원과 리소스를 아끼고, 남은 자원을 극대화하여 새로운 가치를 생산하고자 한다는 것입니다. 단지, 소프트웨어 개발은 개발자 역량만 훌륭하다고 되는 것이 아니며, 개발자간의 원활한 커뮤니케이션, 각 팀과의 원활한 커뮤니케이션, 더 나아가 조직과의 커뮤니케이션과도 연관 고리가 존재하게 됩니다.    

콩 심은 곳엔 콩이 나고, 팥 심은 곳엔 팥이 나야 하지만, 실제 프로젝트에서는 콩 심은 곳에 팥이 나기도 합니다. 협업을 하다 보면 협업 자체가 어려운 것이 아니라, 사람을 대하는 것이 가장 어렵다는 것을 느낄 수 있을 것입니다. 그래서 애자일(Agile) 한 방법론이 최근 팀과 조직에서 관심의 대상이 되는 것과 같은 이치입니다. 애자일 방법론을 잘 하기 위해서는 사람과 인간성을 이해하고 신뢰를 쌓는 것이지만, 그렇게 애자일하게 너그러운 사람과 팀, 조직은 그리 흔하지 않습니다.    

그렇다면 뭐가 문제일까요? 사람을 대하는 것이 어렵고, 고로 협업을 하는 것이 어렵고, 고로 전체 프로젝트를 수행하는게 어렵습니다. 개개인의 인격과 인간성을 존중하기엔 시간이 넉넉치 않을 뿐더러, 그들 간의 업무를 조율하는 것은 더 어려워지고, 점점 위태로운 프로젝트가 되기도 합니다. 물론 필자 또한 이런 문제의 발원지가 되기도 해보았고, 이것을 조율하는 입장도 되어 본 경험입니다.    

그럼 이미 답은 나왔습니다. 바로 "강제성" 을 부여하는 것입니다. 강제성이라고 하면 오히려 비 애자일하다고 할 수 있겠지만, 바꾸어 말하면 "당신 하나 때문에~" 애자일을 하는 것이 아니라는 것입니다. 가장 표준적이면서도 쉬운 방법을 통해 목표의 방향성을 가지고 간다는 것이 더 중요할 수 있기 때문입니다.

어떻게 커뮤니케이션을 할 것인가?

사람과 사람, 팀과 팀, 조직과 조직, 기업과 기업, 이들 간의 커뮤니케이션은 매우 다양합니다. 메신저, 이메일, 그 밖에 다양한 방법이 존재합니다.    

사람마다 선호하는 방법은 틀리겠지만, 개인적으로는 메신저야말로 가장 업무적으로 방해가 되는 커뮤니케이션 방법이라고 생각합니다. 언제나 급한 분들에게는 가장 좋은 커뮤니케이션 방법이 메신저가 될 수 도 있을 것입니다.    

제가 가장 좋아하는 커뮤니케이션 방법은 이메일입니다. 제가 이메일을 열람하고 싶을 때 보고 업무를 처리하면 되니까요. 하지만 이메일은 기록되고 보관되기 때문에 가장 책임감을 발휘해야 하는 커뮤니케이션 방법이기도 합니다. 하지만 요즘 스마트폰의 열풍으로 직장이든 가정이든 이메일을 볼 수 밖에 없는 현실이 되었죠^^;    

최근에는 SNS 와 같은 방법으로 커뮤니케이션을 하기도 합니다. 우리가 흔히 알고 있는 트위터(Twitter) 와 같은 Public SNS 도 존재하지만, 기업 내에서 사용할 수 있는 Private SNS 도 있습니다. 간단 명료한 메시지라는 강점으로 최근 유행하는 방식이기도 합니다.    

Team Foundation Server 의 구성 요소를 통한 커뮤니케이션

Team Foundation Server(이하 TFS) 는 단독적으로 사용할 때 보다 여러 가지 구성 요소를 갖출 때 비로소 가장 효과적인 커뮤니케이션 방법을 제공해 줍니다.    

최소한으로 TFS 는 SQL Server 를 필요로 하며, SQL Server 는 TFS 를 통해 소스 제어(Source Control), 리포팅(Reporting) 서비스를 제공해 줍니다. Team Foundation Server 를 사용하는 목적으로 SQL Server 라이선스를 일부 무료로 제공하기 때문에 가장 저렴한 비용으로 커뮤니케이션을 할 수 있는 방법입니다.

이를 이용하여 최소한으로 이행할 수 있는 여러 가지 기능이 있습니다.

• 소스 제어(Source Control)
• 소스 코드 브랜치(Branch)
• 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
• 일부 오피스(Office) 제품 연동

     

하지만 위의 방법으로는 조금 부족한 감이 있습니다. 마찬가지로 Team Foundation Server 를 사용하게 되면, SQL Server, Sharepoint Server 의 일부 라이선스를 무료로 제공하기 때문에 더욱 효과적인 커뮤니케이션 인프라를 구축할 수 있습니다. 특히 SharePoint 는 팀 포털과 문서 관리의 이점 뿐만 아니라, 팀 워크플로우를 개선할 수 있는 다양한 방법을 제공합니다. 특히 큰 규모에서는 의사 결정권이라는 막강한 권한이나 프로세스가 존재하게 되는데, SharePoint 는 이러한 워크플로우를 상당히 효과적으로 개선할 수 있는 솔루션이기도 합니다.

• 소스 제어(Source Control)
• 소스 코드 브랜치(Branch)
• 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
• 다양한 오피스(Office) 제품 연동
• 팀 포털, 문서 관리, 팀 프로세스 개선

최근 가상화(Virtualization) 를 기반으로 클라우드 서비스가 매우 큰 개발 및 비즈니스 영역으로 자리잡고 있습니다. 소프트웨어 가상화는 물론이고 우리가 흔히 알고 있는 하드웨어 가상화 등 이러한 서비스 가상화를 통해 이전에는 상상하기 힘들거나 환경을 구성하기 힘든 영역까지 모두 커버하고 있습니다. Microsoft 에서는 이것을 가리켜 Dynamic IT 라고 칭하고 있습니다.

그 중, System Center 솔루션은 매우 다양한 역할을 수행합니다. 가상화 인프라와 서버 모니터링을 위해 다양한 솔루션은 아래와 같습니다.

SCVMM(System Center Virtual Machine Manager) 은 가상화를 통한 동적 서버 관리, 가상화를 통한 유지 관리 계획, 가상화를 통한 테스트 및 개발 환경 의 작업을 관리하고 단순화 위한 가상화 관리 솔루션입니다. 가상화 서버를 관리를 용이하게 하고, 물리적인 서버를 가상화로 쉽게 전환하거나 가상 호스트에 여러 개의 물리적 서버를 통합할 수 있습니다.

특히 이 솔루션은 ALM(Application Lifecycle Management) 솔루션 중 Team Foundation Server 2010 에서 테스트 가상화를 사용하기 위해 필요한 구성 요소이기도 합니다.

SCOM(System Center Operation Manager) 는 분산되어 있는 데이터 센터를 통합 관리를 하며 윈도우 운영체제 뿐만 아니라 다양한 리눅스, 유닉스 기반의 운영체제를 지원합니다. 이 솔루션을 이용하면 특정 장애나 서비스 성능, 가용성을 보장하기 위해 자동으로 조치를 취하도록 할 수 있습니다.

SCCM(System Center Configuration Manager) 는 네트워크 인프라에 존재하는 클라이언트 컴퓨터, 서버 컴퓨터 등의 구성을 중앙에서 관리합니다. 예를 들어, 일부 클라이언트 사용자의 컴퓨터는 윈도우의 업데이트를 꾸준히 사용하지 않는 경우가 있습니다. 이러한 경우 강제적으로 업데이트를 수행하도록 정책적으로 관리를 할 수 있습니다. 그 밖에 윈도우 방화벽 설정, 자동 업데이트 및 백신 프로그램 등을 정책적으로 설치되거나 구성하도록 강제화 할 수 있습니다.

현재 협업을 위한 기본적인 기반 환경은?

단지, 필자가 오늘 하고 싶은 이야기는 여러분들에게 여러 가지 솔루션이 이를 대체할 것이라는 암시를 주는 것이 아닙니다. 단지 협업은 혼자만의 노력으로는 불가능 한 것이며, 이것을 뒷받침해 줄 수 있는 도구가 있다는 것에 감사할 뿐입니다.    

대부분의 우리나라 조직은 상하 수직적인 관계입니다. 일을 던져주고, 그것을 받고 일을 하는 수직적인 줄타기 방식은 작업의 결과를 매우 가시적이고 평가하기 쉬운 방법입니다. 그리고 이런 방식에 저 또한 매우 길들여져 있으며, 일을 수행하는 입장에서도 매우 수월합니다. 수행 결과를 보여주기도 쉽고, 처리하기도 쉽습니다.    

다만 수평적인 조직(절대적인 수평은 없을 것이지만)에서는 오히려 상하 수직적인 방식과는 다릅니다. 항상 중간 과정에 서로의 동의와 협력이 필요하며, 그 성과 또한 개인의 성과가 아닌 우리의 성과가 될 테니까요.    

하지만, 여러 조직과 기업이나 프로젝트에서 일을 해 본 경험으로, 절대적인 상하 수직적, 수평적인 조직은 없다는 것입니다. 그리고 필자 또한 어떤 것이 바람직한지 아직은 확신을 하기 어렵습니다. 다만, "그때 그때 잘~" 이라는 것밖에는 ^^    

팀워크(Team Work) 란 팀이 무너지지 않고 존재할 수 있는 가장 큰 힘을 발휘합니다. 반대로 팀 워크가 수년간 같은 방식이고 개선되지 않고 제자리에 머물러 있다면 썩은 우물과도 같습니다. 왜냐하면 시대가 변함에 따라 개개인의 커뮤니케이션 방식은 바뀔 것이며, 점차적으로 개선되어 지지 않는다면 팀 워크가 아닌 커뮤니케이션 자체의 문제의 한계에 부딪히게 될 것입니다.    

일단 오늘은 협업에 대해 썰을 풀어 보았습니다. 그리고 협업을 위한 많은 노하우를 여러분들에게 알려드리고 개선해 나가고자 합니다. 언제든지 불편한 내용이나 피드백을 주시면 참고하여 개선하고자 하도록 하겠습니다.

이전 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [1]


이미 이전 포스트에서 얘기 했듯이, 똑같은 "단위 테스트"라는 단어를 가지고 개발자, 테스터, 고객은 각자 그 의미를 전혀 다르게 생각하고 있습니다. 이런 단어의 해석 조차 각자 틀린데, 애자일(Agility)하게 어떻게 소프트웨어를 만들 수 있을까요. 이미 "단위 테스트" 라는 작은 주제를 가지고 벌써부터 고객과 개발 조직간의 불화음이 발생합니다.

아니, 이미 개발 팀 내부에서부터 어디서 부터 시작해야 할지 어디둥절 할 수 있습니다. 그렇다면 과연 "단위 테스트" 가 결함의 발생을 줄이는 약이 될지, 팀 간의 커뮤니케이션 장애를 발생시키는 독이 될지, 그것은 아마 이 글을 읽는 독자 분들의 실천에서부터 시작될 것입니다.

이렇게 말도 많고 탈도 많은 단위 테스트를 왜 꼭 해야 하는지부터 짚고 넘어가 봅니다. 단위 테스트는 기능 또는 단위 별로 결함을 조기에 발견하기 위한 테스트 방법입니다. 하지만 "단위 테스트" 라는 단어만으로는 그 이해는 너무나도 상이하게 틀리다는 것입니다.

• 개발자 - 단위 테스트 코드를 만드는 것
• 테스터 - 개발중인 웹 어플리케이션 또는 클라이언트 어플리케이션 등을 만져보면서 기능 결함을 발견 하는 것
• 고객 - 문서!! 기능에 대한 산출물 또는 보고서

일단 "단위 테스트" 에 대한 이해가 달라도 현재까지는 상관이 없습니다. 왜냐하면 단위 테스트가 가지는 의미를 제대로 이해하고, 공감대를 형성하는 것이지 어떻게 수행할 지는 적어도 지금은 중요하지 않습니다.

단위 테스트에 대해, 국내에는 번역본이 대부분이라 사실 우리 나라 실정에 정말 맞는지에 대해 많은 고민을 하였고, 적어도 필자는 이런 고민을 방관하고 싶지는 않습니다. "NO" 를 외치고 싶을 때는 외쳐야 하지 않겠습니까?

왜 버그가 발생하는가?

일반적으로 버그나 소프트웨어의 결함은 어떻게든 발생할 수 밖에 없습니다. 아무리 기계적이고 단순한 코드를 개발한다고 하더라도, 코드 간의 상호 연동, 클래스 간의 연동, 컴포넌트(Components) 간의 연동, 레이어(Layer) 간의 연동, 더 나아가 시스템 간의 연동.. 즉, 연동 또는 상호 종속적인 관계가 발생하는 시점부터 버그는 이미 예견될 수 밖에 없습니다. 쉽게 얘기하면, A 란 코드와 B 란 코드가 있습니다. 이 두 개의 코드는 분명히 다른 목적에 의해 개발이 되었지만, 목적 자체가 틀린 코드가 상호 연동 또는 종속적인 관계가 발생하게 된다면, 과연 어떨까요? 이것은 코드 자체에서 발생되는 결함이라기 보다 상호 연관 관계에 놓이면서 발생하는 결함이라고 볼 수 있습니다. 그리고 대부분의 중요한 또는 큰 버그는 이러한 얽히고 설키게 되는 연동/종속 이란 문제로 발생됩니다.

만약 버그가 발생되지 않는 상황이라도 A와 B 코드는 언제든지 업그레이드가 될 수 있습니다. 기능이 변경될 수 도 있고, 기능이 추가될 수 도 있습니다. 아무것도 모르는 최종 사용자(End user) 는 잘 되던 기능이 갑자기 안된다면 좀 어이없어 할 것입니다. 일부 이러한 코드가 최종 사용자의 요구에 의해, 그리고 최종 사용자를 위해 변경되지만, 최종 사용자는 결함을 발생시킨 원인을 알고 싶지도 않고, 단지 개발 팀을 신뢰할 수 없을 뿐입니다.

즉, 이러한 버그가 조기에 발견되지 않는다면 버그는 지속적으로 증식을 하게 됩니다. 가장 대표적인 예라면, 월별, 년별 정산해 주는 기능이겠죠. 이곳에서 만약 버그가 발생한다면 몇 일, 아니 몇 주를 이 버그를 해결하기 위해 많은 시간을 소비해야 할 것입니다. 실제로도 필자는 주변에서 이와 유사한 버그로 인해 고생하는 동료 개발자들을 많이 보아왔습니다. 결과적으로 모든 코드에는 버그가 발생할 가능성이 있고, 그것은 바로 연동/종속적인 관계가 시작되면서 집중적으로 발생하게 됩니다. 그리고 잠재적인 모든 코드가 버그의 대상이 되고, 잠재적인 버그가 가장 위험하다는 것입니다. 잠재적인 버그는 지금의 나도, 너도, 우리 모두가 모르는, 언제 발생할 지 모르는 버그이기 때문입니다.

이러한 주제로 필자는 이미 Techday 2009 에서 온라인 세미나를 한 적이 있습니다. 아래의 링크를 통해 간략한 단위 테스트 기술에 대해 미리 익히는 것도 좋습니다.

http://www.techdays.co.kr/Sessions/View.aspx?Id=40&mSeq=43

단위 테스트가 주는 의미

단위 테스트는 많은 곳에서 장점을 이야기 합니다. 예를 들어, "결함을 줄이고, 잠재적인 버그를 줄이고, 코드를 리팩토링 하게 하며…." 등등… 단위 테스트가 실제로 이러한 많은 장점이 있는 것은 필자 또한 강력하게 권장하고 싶습니다. 하지만, 아시다시피 "단위 테스트" 에 대해 개발자, 테스터, 고객과의 공감대가 형성되지 않은 이 마당에, 저런 소리를 하면 정말 비즈니스적인 가치가 있을까요? 아마도 고객은 단위 테스트를 한답시고 비용과 시간이 늘어난다는 것을 절대 용납하지 않을 것입니다.

그렇다면 단위 테스트가 우리에게 주는 의미는 무엇일까요? 단위 테스트를 형용할 수 있는 모든 단어를 떠올려 보십시오. 참 많습니다. 하지만 고객과 개발 조직, 그리고 비즈니스 측면에서 어떤 단어가 가장 잘 어울릴까요.

바로 단위 테스트는 "신뢰" 입니다. 개발 조직에서 개발자와 개발자간의 코드에 대한 신뢰! 개발 조직과 테스트 팀간의 신뢰! 그리고 단위 테스트의 결과는 매우 명확해서 고객과의 신뢰로 이어질 수 있습니다. 이러한 단위 테스트로 인해 장기적인 비용이나 리소스 절감 효과 등은 잠재적인 비즈니스적인 신뢰로 이어질 수도 있습니다. 만약, 개발 팀 내의 단위 테스트는 다른 개발자가 만든 코드와 연동해야 할 때 대한 최소한의 신뢰를 가지는 매우 신사적인 행위입니다.

즉, 개발자, 테스터, 고객과의 단위 테스트에 대한 이해가 틀리다고 하더라도, 최소한 단위 테스트라는 것을 했고, 그 결과가 명확했을 때 그 관계에서 "신뢰" 가 형성될 수 있습니다. 젊은 개발자가 아닌 고객은 자신의 과거의 경험에 빗대로 단위 테스트라는 것이 어떤 것인지 잘 모르더라도, 매번 명확하게 결과를 보여준다면 비록 버그가 발생하였더라도, 버그의 발생 시점이 명확하고 이 버그의 해결 결과 또한 명확하다면 "버그" 라는 단어로 절대 날뛰는 일은 없을 테니까요.

애자일(Agile) 한 팀 모델! 무엇이 문제인가...

자! 이제 단위 테스트에 대해 어느 정도 확신을 갖게 되었다면, 이것을 수행하기 위한 팀 모델이 필요합니다. 하지만 이러한 팀 모델을 구축하기 위한 시도는 매우 말이 많고 신중해야 할 부분입니다. 애자일을 도입하여 실패했다는 많은 히스토리와 사례들이 범람하면서 과연 애자일이 좋은 것일까라는 고민을 해 보아야 할 시기인 것입니다.

애자일이라고 하면 일반적으로 통용되는 XP(eXtreme Programming) 의 팀 모델과 스크럼(Scrum) 의 팀 모델은 현저하게 차이가 납니다. 그리고 글로벌 소프트웨어 개발 업체 중 단연 1위인 Microsoft 의 정보 기술 솔루션인 MSF(Microsoft Solution Framework) 의 팀 모델은 모두 다 다르다는 것입니다.

일단 현재 우리나라의 팀 모델의 특색은 매우 다양하고 변칙적이며, 상하 수직적인 관계입니다. 예를 들어, 개발자를 동일 선상의 개발자가 아닌 "대리급", "과장급", 일부 "부장급" 도 코딩을 하기도 합니다. 그리고 단순히 "개발 조직"이라는 단어 조차 어색하게 사수, 부사수 달랑 두 명이 개발을 하기도 합니다. 편의상 아래와 같은 형태가 되는군요. (이 부분은 조직마다 매우 다른 형태를 띌 수 있습니다)

어떤 모델에서는 개발자, 아키텍처, 테스터로 구분하지만 필자는 이러한 팀 모델이 전혀 한국적이지 않다고 생각합니다. 애자일과 MSF(Microsoft Solution Framework) 에서도 언급하지만 개발 팀에서는 우두머리, 즉 대장을 두지 말라고 조언합니다. 위의 그림에서 PL(Project Leader) 는 바로 개발 팀의 우두머리이며, 가장 테크니컬 하거나 경력, 또는 업무 도메인 지식이 뛰어나야 합니다. 그리고 한국형 조직이나 문화 특성상, 윗사람 또는 상사에게 코드나 아키텍처적인 문제를 언급하는 것은 매우 조직력이 부족한 사람으로 비추어지기도 합니다.

예를 들어, 한국의 개발자는 코드에 굉장히 민감하고, 곧 코드가 자신의 자존심이라고 생각하는 경향이 짙습니다. 적어도 필자 또한 마찬가지 입니다. 개발자는 자신의 사수에게 코드적인 문제를 언급한다면 충분히 문제의 소지가 발생할 수 있습니다. 데이터베이스 개발자일 경우 자신의 사수에서 SQL 쿼리에 대한 성능적인 문제를 지적한다면 자신의 부사수가 잘난 체 한다거나, "경력도 얼마 안되는 놈이 좀 안다고 까부네" 라고 생각하기도 합니다. 상사와의 관계가 아닌, 동등한 개발자 간에서도 다른 사람이 자신의 코드에 대해 지적하는 것은 '거의 인간 관계를 포기한 것'과 다름이 없다고 봐도 무리는 아닐 것입니다. (물론 어떻게 얘기를 잘 하느냐는 문제도 있겠지만요)

결론적으로 애자일 또는 MSF 가 언급한 팀 모델은 굉장히 이상적이지만, 전혀 우리나라의 특성을 적용하기가 힘이 들 수 있습니다. 위에서 예를 든, 단편적인 예만 봐도 애자일 또는 MSF 의 자유분방한 팀 모델은 우리나라 현실에 도입되기는 매우 힘이 듭니다. 작은 조직이라면 모를까, 거대한 엔터프라이즈 프로젝트의 경우 많은 점점 더 큰 팀과 또는 다른 업체와 함께 일을 하는 경우가 발생하기 때문에, 팀 내부가 아닌 팀 외부로 까지 애자일한 행위는 절대 금물입니다.

한국적인 애자일(Agile) 한 팀 모델

많은 사람들이 오해하는 것 중에 하나가 애자일의 XP 와 스크럼을 도입하기 위해 그것이 요구 또는 원칙, 권장하는 방법들을 반드시 따라야만 한다고 생각합니다. 이미 지난 포스트에서도 언급했듯이 고객은 명확한 일정을 요구하는 폭포수 모델(Waterfall Model) 을 요구하는데, 팀 내외부적으로 애자일(Agile) 을 외치고 있다가는 고객이 원하는 어떠한 일정과 조건에도 맞출 수가 없습니다. 우리는 이 시점에서, 애자일이라는 단어가 주는 의미를 다시 한번 상기해 볼 필요가 있습니다. 어떠한 애자일, MSF 에서도 그것을 반드시 이행하라고 명시하지 않습니다. 다만, '이렇게 이렇게 해보니 좋으니 너희들도 이런 방법을 써봐라' 라는 권장의 의미이지 강요가 아니라는 것입니다.

어쨌든, 개발자라고 하면 아래와 같이 두 가지 형태의 개발자가 있을 것입니다. 유지보수 인력인 SM(System Management) 이 있겠고, 개발 인력이 있습니다. 두 형태는 같은 개발은 하는 것이 맞지만, 깊은 내막은 전혀 다른 개발을 하고 있습니다. 일반적으로 개발 인력은 개발이 마치면 유지 보수 팀 또는 인력에게 인수가 됩니다. 그리고 인도적인 차원에서 각종 산출물을 뽑아내어 유지 보수 인력에게 모든 추후 버그나 추가적인 기능 개발이 떠넘겨지게 됩니다. 즉, 유지 보수 인력은 1년 365일 전산 시스템이 잘 운영되고, 지속적인 국가 정책이나 기업 정책, 그리고 고객의 요구를 시스템에 반영하는 역할을 하게 됩니다. 이 과정에서 일부 개발 인력이 유지 보수 인력으로 자연스럽게 전환되기도 합니다.

하지만, 좀 더 큰 기업에서는 개발 팀만해도 매우 복잡한 형태를 띄게 됩니다. 일단 내부 개발자, 외부 개발자가 분리가 되며 기업의 내부적인 정보를 공유할 수 있는 권한이 있느냐 없느냐로 볼 수 있습니다. 뭐 이러한 경우 사적인 자리에 까지 이어져, 점심을 함께 먹는 동료가 정해지기도 합니다. ^^; 외부 개발자는 일반적으로 프리랜서나 개인 사업자를 등록한 사람들이 됩니다. 하지만 대부분 프리랜서나 개인 사업자는 기업의 하청 업체를 통해 계약이 되는 경우다 더 많죠.

필자 또한 이러한 팀 모델과 현실과의 많은 고민을 하면서, 과연 어떠한 것이 한국적인 팀 모델이 될 것인가에 대한 고민을 끝없이 하고 있습니다. 마찬가지로, 필자가 좀 더 성숙해 지면 아래에 언급하는 팀 모델에 대한 생각이 바뀔 수 도 있습니다. 어쨌든 필자의 경험상 아래와 같이 팀 모델을 권장합니다.

위의 선은 직접적으로 커뮤니케이션 할 수 있는 범위입니다. 자세한 롤 모델(Role Model) 까지는 언급하지 않겠지만, 대충 커뮤니케이션의 통로와 작은 하위 팀을 보면 이해가 갈 것입니다. 특히 핵심 개발자 팀은 그 관리자나 일반 개발자와만 커뮤니케이션이 이루어지며, 이 핵심 개발자 팀은 외부 또는 타 업체가 될 수 도 있습니다. 일반 개발자에서 파생되는 여러 종류의 개발자는 모두 일반 개발자로 들어갑니다. 그리고 고객은 오직 관리자와 직접적으로 커뮤니케이션이 이루어지며, 경우에 따라서 품질 유지 팀에 의해 보고를 받을 수 도 있습니다. 애자일의 자유분방한 커뮤니케이션의 트랜잭션(Transaction) 을 넓은 범위에서 최소한으로 우리나라의 실정에 맞도록 줄이는 것이고, 관리자가 권한을 일부 위임해 주는 형태가 되는 것입니다.

또 하나, 필자가 애자일(Agile) 에 대해 공부를 시작하면서, 가장 답답했던 것이 바로 "고객의 자발적인 참여"를 기대한다는 것입니다. 일반적으로 개발 팀 입장에서 느끼는 고객은 굉장히 권위적이며, 상하 수직적인 관계입니다. 과연 애자일하게 프로젝트를 하면서 점진적인 릴리즈(Release) 를 통해 1달에 한번의 반복(Iteration) 으로 총 1년 동안 12번의 반복을 통해 점진적으로 최종 릴리즈에 도달한다고 가정해 봅시다. 이 릴리즈마다 고객의 자발적인 참여와 의견을 교류하는 이상을 생각하며, 첫 번째 릴리즈를 보여줬을 때, 과연 고객은 소프트웨어 개선을 위해 적극적인 참여를 할까 아니면 "내가 원하는 소프트웨어는 이게 아닌데?" 라고 할까요.

과연 그렇다면 여러분은 애자일의 의미에 대해 고객에게 세미나를 할 것인가요, 아니면 어떻게든 설득을 할 것인가요? 이미 고객의 경향을 알고 있는데, 그러한 고객을 설득하고 이해시키는 계몽(啓蒙)을 할 수 있을지 의문입니다. 그렇다면 이미 답은 나왔습니다. 고객을 변화시키지 못할 바엔, 차라리 우리가 변하는 것입니다. 즉, 개발 조직 내에서 불필요한 소음을 줄이기 위해, 어디에서 문제가 발생하는지, 그리고 소통이 어떻게 이루어지는지에 대한 트랜잭션(Transaction) 에 대한 관찰이 필요하다는 것입니다.

그리고 위의 그림과 같이 필자는 최종적인 트랜잭션의 소통이 현재 한국적인 가장 이상적인 애자일이 아닐까 생각합니다.

각 역할 별로 간단히 정리하자면, 아래와 같은 마음 가짐과 자세가 필요하겠군요. 물론 모든 조건을 완벽하게 갖추기보다는 최소한의 자세와 지식이 갖는 것이 유리할 듯 합니다. 자신이 부족한 부분이 있다면, 팀 동료가 이것을 뒷받침 해 주어야 겠지요. (유지 보수 팀은 복잡성을 줄이기 위해 여기에서 제외합니다)

품질 좋은 소프트웨어를 위한 단위 테스트

필자가 단위 테스트에 대한 필요성을 얘기하다가 뜬금없이 버그와 팀 모델에 대해서 이야기 하는 것이 의문일 수 있을 것입니다. 하지만 이 내용 또한 이전 포스트에서 이야기 했듯이, 소프트웨어 품질이 떨어지는 것에 대해 어느 누구에게 몰빵(?)할 수도 없는 문제이며, 단위 테스트에 대한 공감대가 없다면 절대 할 수 없는 것이기 때문입니다. 애자일이 우리에게 많은 자율성(Autonomy) 와 타이트함(Tightly) 를 주는 것은 매우 환영할 일이지만, 일부 정책적인 강제가 없다면 애자일은 우리나라에서 이미 실패한 방법론 또는 프로세스일 뿐입니다. 왜냐하면 우리나라의 고객은 아직까지는 변하지 않을 테니까요.

어쨌든, 단위 테스트를 위한 팀 모델의 세팅을 이쯤에서 마칩니다.

애자일(Agile) 프로그래밍 기법 등이 대중화 되면서, 특히 XP(eXtreme Programming) 에서는 단위 테스트의 코드를 먼저 작성하라고 합니다. 그것이 바로 TDD(Test Driven Development) 입니다.! 그 이유는 다들 아시다시피 간단합니다. 바로 코드를 작성할 때 설계부터 하라는 것입니다. 좀 직설적으로 얘기하자면, 생각 좀 하고 만들라는 것이죠. 생각 없이 만들 코드를 나중에 리팩토링(Refectoring) 할 바에는 처음부터 리팩토링 비용을 줄이고, 좀 더 세련된 디자인으로 코드를 작성하라는 의미입니다.   

단위 테스트(Unit Test) 라는 의미에서도 사실 개발자와 테스터, 고객과는 굉장히 괴리감이 있는 단어이기도 합니다. "단위 테스트" 라는 똑같은 단어를 사용하지만 그것을 받아들이는 사람의 직책이나 파트(Job) 이 어디냐에 따라 틀리기도 합니다. 아마도 애자일(Agile) 이라는 트랜드를 아느냐 모르느냐의 기준이 될 수 도 있습니다.

• 개발자 - "테스트 코드를 만들라는 의미군!"
• 테스터 - "나더러 테스트 코드를 만들라거야? 아니면 각 기능별로 테스트를 하라는거야?"
• 고객 - "기능별 테스트를 어떻게?"

단위 테스트에 대한 개발자의 입장

우선 개발자를 봅시다. 필자는 개발자에게 TDD 를 강요하기란 굉장히 어려운 문제라고 생각합니다. 테스트 코드를 작성하는 것은 만들어진 코드의 양에 비례하여 추가적인 테스트 코드를 작성해야 합니다. 테스트 코드를 만드는 것이 문제가 아니라, 시간이 아깝다는 것이죠. 테스트 코드를 만들 시간에 더 생산성 있는(폼-Form 빼는 작업) 이 훨씬 더 나을 것입니다. 사실 우리나라 SI 프로젝트의 문제가 일단 소프트웨어를 만들고 난 다음에, 유지 보수 계약으로 버그를 잡아 치웁니다.

이런 구조는 실제 개발했던 사람과 유지 보수 하는 사람이 교체되면서, 유지 보수 인력은 이미 떠난 개발 인력들에게 "뭐 이런 쓰레기 코드를..!" 이라는 말을 할 수 밖에 없죠. 다시 개발했던 당사자의 입장으로 돌아가 보면, 빨리 빨리 대충 돌아가는 기능을 만드느냐, 느릿 느릿하지만 완벽한 기능을 만드느냐라는 기로에 설 수 밖에 없습니다. 여기서 고객은 언제나 쉽게 맘이 변합니다. 기존의 기능이 추가되거나 변경되면서 이미 완성된 기능에 지속적으로 덧칠을 할 수 밖에 없습니다.

그럼 TDD 를 왜 해야 하는가에 대한 의문점을 가질 수 밖에 없습니다. 단위 테스트조차 여유로운 작업이 아님이 분명한데, 테스트를 먼저하라니!!! 만약 누군가가 그것을 저에게 강요한다면 충분히 해명하거나 변경의 근거가 다분할 것입니다. 아마도 필사적으로 반대 입장에서 논의를 할 지도 모릅니다. 잘 차려놓은 테스트 코드를 돌려보는 관리자의 입장에서는 완벽한 프로세스일지 몰라도 적어도 개발자의 입장에서는 테스트 코드, 아니 TDD 마저 그저 먼 산일 뿐입니다.

단위 테스트에 대한 테스터의 입장

일반적으로 엔터프라이즈 어플리케이션(Enterprise Application) 은 기반이 되는 어플리케이션 프레임워크(Application Framework) 를 구축합니다. 범용 프레임워크를 이용하여 개발자가 사용하거나 소프트웨어나 업무 구조에 맞도록 도메인 집약적인 프레임워크로 파생하거나 전환됩니다. 이 과정은 진정한 기반 프레임워크에서 파생될 수 도 있고, 단순한 라이브러리 형태로 파생될 수 도 있습니다.

일단 팀의 구성원은, 개발 팀, 테스트 팀으로 구분합니다. 개발 팀은 오직 기능을 구현하고, 테스트 팀은 구현된 기능을 수동 테스트(Manual Test) 를 하거나 단위 테스트 코드를 작성하여 테스트를 수행합니다. 즉, 역할이 완벽히 분리되어 개발 인력은 개발에만, 테스트 인력은 원칙에 따른 테스트만 수행하는 형태입니다. 테스터가 테스트를 진행하면서 개발자가 구현해 놓은 기능에 결함이 발견되면, 개발자에게 이것을 알리고 반복적으로 테스트만 전담합니다. 이 프로세스에서 팀 간의 커뮤니케이션은 문서가 될 수 도 있고, 메신저가 될 수 도 있고, 메일이 될 수도 있습니다. 그것은 테스터에게 그리 중요한 것이 아닙니다.

하지만, 점점 더 고객은 특정 프레임워크나 아키텍처에 종속되길 원하지 않습니다. 그 이유는 과거의 잘못된 방법론이나 Non OOP(Object Oriented Programming) 의 확장성에 매우 민감합니다. 즉 기존에 어떤 아키텍처를, 어떤 프레임워크를 쓰던지 간에 현재와 미래가 더 중요할 수 밖에 없습니다. 이러한 과도기에서 과연 테스터는 무엇을 할 수 있을까요?

OOP 기반 프로그래밍은 추상화입니다. 그리고 추상화를 하다 보면 다형성을 따라가게 됩니다. 개발자나 아키텍처에게는 박수를 쳐줘야 하겠지만, 테스터의 입장에서는 전혀 그렇지 않을 수 있습니다. 즉, 테스터는 테스트 코드를 작성하기 위해 전체적인 아키텍처까지 이해해야 하는 어처구니 없는 상황이 발생할 것입니다. 아마도 잘 나가는 개발자들은 Mockup 을 이야기 할 것입니다. 그런데 누가 Mockup 을 할 겁니까? 아무것도 모르는 테스터? 아니면 코드를 작성한 개발자?

Mockup 에 대해서 아래의 링크를 참고 하세요.

http://blog.powerumc.kr/222

단위 테스트에 대한 고객의 입장

얼마 전에 엔터프라이즈 시스템의 확장성과 안정성에 대해서 고객과 미팅을 한 적이 있습니다. 고객은 현재의 프레임워크는 특정 프레임워크에 종속되어 확장이 불가능하며, 다른 프레임워크로 교체마저 불가능하다고 합니다. 그리고 과거의 기술을 사용하기 때문에 특정 벤더의 지원이 부족하고 그것을 이해하는 내부 직원도 없을 뿐더러, 시스템이 간혈적으로 다운되기도 한다고 합니다. 시스템이 돈(Money) 과 직결되는 문제라면 어느 누구도 나서서 고치겠다고 할 사람 없지 않겠습니까?

차세대 시스템에 대한 목표를 언급하면서 SOA(Service Oriented Architecture) 의 구현 산출물인 ESB(Enterprise Services Bus) 에 대해서 열심히 설명하면서, 단위 테스트에 대해서 언급을 한적이 있습니다. 그리고 대부분 고객의 관리자가 젊은 개발자가 아니기에, 이러한 최신 트랜드의 아키텍처와 방법론(?) 을 설명하면 기대 반, 의심 반으로 기대 심리를 갖기도 합니다.

하지만, 고객에게 단위 테스트에 대한 이야기를 언급할 때는 전형적인 과거의 산출물을 상상합니다. 바로 테스트의 이력을 볼 수 있는 문서이죠. 하지만 현재는 이미 그런 단위 테스트의 자동화와 산출물은 자동화가 되었음에도 불구하고 오히려 고객은 과거의 자신의 경험이 비추어 이해합니다. 이미 현재 시스템도 단위 테스트를 수행했고, 철저히 감사했음에도 불구하고 현재 이지경에 이르렀다는 것이죠.

즉, "단위 테스트" 라는 똑같이 형용하는 문자임에도 불구하고, 서로의 이해가 너무나도 부족합니다. 아마도 단위 테스트의 개념조차 없었던 코볼(Cobol), 포트란(Fortran) 의 원시 언어로 돌아가는 기분이 들었습니다. (학문적으로 고급 언어에 속하지만 과연 현재도 고급 언어일까?…) 즉, 그들과 눈높이를 맞출 수 있는 방법은 목표대로 보여주던가, 아니면 우리를 믿지 못하고 과거의 경험에 빗대어 비교할 것인가…

그렇다면 누가 단위 테스트를 수행해야 하는가?

아마도 이 섹션은 특히 필자의 개인적인 생각이기도 합니다. 어쨌든 "단위 테스트"에 대해 이렇게 이해 관계가 얽히는 풀기 힘든 문제이기도 합니다.

그럼 결론적으로 과연 누가 테스트를 수행해야 하는가 입니다. 아마도 필자의 개인적이고 경험적인 부분이므로, 다른 의견이 있다면 조언 부탁 드립니다.

우선 개발 팀과 테스터 팀의 조직적인 분할이 필요합니다. 즉, 팀 별로 역할 범위를 정확하게 명시함으로써 프로세스적인 측면에서 해결해야 할 문제라고 생각합니다. 이러한 문제는 Microsoft Solution Framework(MSF) 에서 잘 설명을 하고 있습니다.

아래의 필자의 분류는 우리나라의 전형적인 프로젝트 진행 구조를 고려하였습니다.

즉, 필자가 이렇게 구분한 의도는 어느 누군가에게 책임을 소프트웨어의 품질에 대해 소위 몰빵(?) 할 수 없다는 것입니다. 결국 가장 유연해야 할 책임과 역할의 구분이 명확하지 않는다는 것은 스스로의 무덤을 파는 것과 다를 바가 없습니다.

단위 테스트에 대한 적절한 대안은 있는가?

필자는 위와 같은 이유로 팀과 역할을 구분하여 단위 테스트를 수행하는 것을 권장합니다. 물론 위의 팀별 역할은 정답은 아니고, 조직의 형태에 따라 유연하고 적절하게 배분이 되어야 할 것입니다.

필자는 "단위 테스트" 라는 주제로 개인적인 견해를 이야기했지만, 더 나아가 소프트웨어를 개발하기 위한 방법론(SDLC-Software Development LifeCycle) 과 고객이나 기업의 거버먼스와 비즈니즈 가치가 결합되지 않으면, 좋은 소프트웨어를 절대 나올 수 없다고 생각합니다. 즉, 절대적인 방법론이 있고, 방법론을 적용한 경험이 있다고 해서 좋은 소프트웨어가 나올 수 없습니다. 극단적으로, 전산화가 제대로 되지 않은 업무 부처가 있음에도 불구하고 SOA 를 적용한다고 해서 절대 통합과 공유라는 컨셉을 가질 수 없는 것과 마찬가지 입니다.

애자일(Agile)의 대가인 켄트 백(Kent Back)은 아래와 같은 이야기를 한 바 있습니다.

Individuals and interactions over processes and tools
프로세스와 도구보다는 개인과 상호작용을

대부분은 애자일 선언의 이러한 용어로 인해, 매우 혼란스러워하거나 기존의 프로세스를 갈아치우려고 합니다. 마치 애자일의 XP 에서 이야기하는 원칙에서 하나라도 빠트리면 애자일이 아닌 것처럼 말입니다. 애자일의 주요 키워드는 "변화" 이지, 절대 강요가 아닙니다. 만약, 고객은 철저한 기간 엄수를 요구하는 폭포수 모델(Waterfall Model) 을 강요하지만, 개발 팀은 애자일(Agile) 만 고집한다면 그것은 서로 파멸로 가는 길이며, 애자일의 진정한 의미를 이해하지 않았다고 볼 수 있습니다.

켄트 백(Kent Back) 은 아래의 링크를 통해 위의 원칙에 대한 오해를 풀어내고 있습니다.

Tools for Agility - A White paper by Kent Beck, Three Rivers Institute

http://www.microsoft.com/downloads/details.aspx?FamilyId=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96&displaylang=en

.NETXPERT 의 안재우 수석님께서 저에게 조언을 주신 문서입니다.

오늘은 "단위 테스트" 에 대한 주제로 언급을 했습니다. 점차적으로 개발, 테스트에 대한 괴리감을 어떻게 줄이고 진정한 통합이라는 큰 주제를 통해 조금씩 파해쳐 보기로 하겠습니다. 

다음 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 가 필요한가?' 에 대해 이야기 부터 시작해봅니다.

애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.

TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.

TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 될 뿐입니다. 효용성 측면에서 TDD를 본다면 그저 빛 좋은 개살구로 보이기 쉽기 때문입니다.

애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 가 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 존중하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.