jMeter 을 이용한 웹 프로그램 부하 데스트

1. 소개

JMeter는 다른 아파치 재단의 프로젝트들과 같이 공개소프트웨어이며 100% 자바기반의 성능 테스트 도구이다. 설치하는 것도 아주 간단해서 http://jmeter.apache.org/ 에서 설치파일을 다운로드하고 설치할 경로에 압축을 푸는 것만으로 설치가 끝난다. 프로그램 실행은 "bin/jmeter.bat" 파일을 더블클릭하면 된다.

그림-1. Apache JMeter 메인화면

2. 확장

널리 알려진 JMeter Plugins 을 사용하면 JMeter 에서 제공하지 않고 있는 다양한 기능들을 사용할 수 있다. 플러그인 설치는 http://code.google.com/p/jmeter-plugins/downloads/list 에서 최신 버전의 패키지를 다운로드하고 압축파일에 포함된 JMeterPlugins.jar 를 JMeter 설치 위치의 ${JMETER_HOME}/lib/ext 에 복사한다.

JMeter 는 디폴트로 드레드 카운터를 JTL 파일들에 저장하고 있지 않는다. JMeter JTL 파일을 사용할 계획이라면 아래와 같이 ${JMETER_HOME}/bin/jmeter.properties 파일을 수정하여야 한다. (아직 이해가 오지 않고 있음. )

변경전 

#jmeter.save.saveservice.thread_counts=false

변경후 

jmeter.save.saveservice.thread_counts=true

이제 JMeter  을 다시 시작한다. JMeter Plugins 에서 제공하는 기능들은 이름이 모두 jp@gc 로 시작되기 때문에 쉽게 구분이 가능하다. 

그림-2. JMeter Plugins

JMeter 에서 파일로 저장하기 기능을 사용할 계획이라면 각 플러그인 모듈에서 Configure 버튼을 클릭하고 Save Active Thread Counts 항목을 채크하고 저장한다. 

그림-3. JMeter Plugins 기능들의 Configure 화면

JMeter 을 사용하다 보면 OutOfMemoryException 이 발생하는 경우가 있는데, 이경우 $JMETER_HOME/bin/jmeter.bat 파일에서  HEAP 와 NEW 값을 아래와 같이 변경한다.

set HEAP=-Xms512m -Xmx1024m

set NEW=-XX:NewSize=256m -XX:MaxNewSize=256m

3. 부하 테스트

부하테스트는 JMeter 에서 제공하는 기본 ThreadGroup 가 아닌 JMeter Plugins 에서 제공하는 Stepping Thread Group (이하 Thread Group) 을 사용하여 단계적으로 부하를 더 많이 줄수 있도록 하였다. 여기에서 Thread 는 사용자를 의미한다. 

세로운 Test Plan 을 생성하고 아래 그림과 같이 Add > Threads(User) >jp@gc - Stepping Thread Group 을 추가한다. 

그림-4. Stepping Thread Group 추가

Stepping Thread Group 설정에서 값을 조정하여 어떻게 부하를 줄 것인가를 설정한다. 그례프를 보면 이해가 더 쉽다. 문서에서는 5초 간격으로 5명 사용자를 생성하며 최대 100 명 까지 생성한다. 이상태를 500 초동안 유지하다가 15초 간격으로 5 명씩 사용자를 제거하도록 하였다. 

그림-5. Stepping Thread Group 설정

이제 실재 HTTP 요청을 다음과 같이 실행하도록 설정한다. 

1. 로그인 (여러 사용자로 로그인 처리를 수행하기 위하여 CSV 파일을 사용한다.)
2. 특정 페이지 조회 

직접 HTTP Request 을 설정하지 않고  HTTP Proxy Server 를 사용하여 로컬 브라우저에서  접속하는 페이지들을 녹화하여 사용할 수 도 있다. 본 문서에서는 사용하지 않았다. 

HTTP 페이지 호출은 아래 그림-6과 같이 좌측 트리에서 jp@gc - Stepping Thread Group 을 선택하고 Add > Sampler > HTTP Request 을 클릭하여 추가한다.

그림-6. HTTP Request 추가

 이제 어떻게 해당 URL 을 호출할 것인가를 지정한다. 여기에서는 POST 방식으로 username, password 파라메터 값을 전달하도록 하였다.

그림-7. HTTP Request 설정

그림-7에서 값을 표시할 때 ${username} 형식으로 설정한 것은 CSV 파일에서 데이터를 읽어 사용하기위서이다. CSV 파일 데이터는 그림-8과 같이 CSV Data Set Config 를 추가하여 정의할 수 있다. (CSV Data Set Config 는 로그인 HTTP Request 와 동일한 레벨에 위치하여야 한다.)

그림-8. CSV Data Set Config 추가

여기에서는 CSV 파일은 엑셀데이터를 CSV 파일로 변환하고 헤더데이터만을 제거하여 사용하였다. 설정은 아주 간단하며 읽어들일 파일이름과 내부적으로 사용할 데이터 이름을 지정하면 된다. 이름을 앞의 HTTP Request 설정에서 파라메터 값으로 설정하면 된다.

그림-9. CSV Data Set Config 설정

이제 Thread Group 에 HTTP Cookie Manager 을 추가하여 로그인 이후 일정동안 세션이 유지될 수 있도한다. HTTP Request 는 순차적으로 발생되기 때문에 로그인 이후에 인증이 필요한 페이지 요청을 설정하여 사용하는 경우에 필수 적이다.

그림-10. HTTP Cookie Manager 추가

이제 마지막으로 부하테스트 결과를 다양한 그래프로 볼 수 있도록 Thread Group 에 필요한 Listener 를 추가한다. 추가는 좌측 트리에서 Thread Group 를 선택하고 그림-11 과 같이 추가하면 된다.

그림-11. 결과 리포팅을 위한 Listener 추가

부하 테스트 결과는  문서에서는  그림-12 과 같이 다양한 결과 뷰를 추가하였다. 기본적으로 차트 결과는 기본으로 제공되는 Graph Results 는 보기가 어렵기 때문에 JMeter Plugins 에서 제공하는 다양한 그래프를 사용하는 것이 더 도움이 될 것 같다.

그림-12. 결과 리포팅 Listener

부하테스트는 Run 메뉴를 사용하거나 아래와 같이 실행 아이콘을 클릭하면 된다.

그림-13. 테스트 실행 메뉴

4. 부하 테스트 결과 

4.1 View Results Tree 

테스트된 결과들에 대한 상세 정보를 볼 수 있다. 여기에서는 실제 테스트 계획을 수행하기 이전에 등록된 HTTP Request 가 올바르게 동작하는가를 확인하는데 유용하게 사용되었다. 

4.2 Summary Report

테스트된 결과들에 대한 요약 정보를 보여준다. 

그림-15. Summary Report 

4.3 jp@gc - Response Times Over Time

테스트 시간에 따른 응답 시간을 그래프로 보여준다. 문서에서는 5초 간격으로 5명 사용자를 생성하며 최대 100 명 까지 생성한다. 이상태를 500 초동안 유지하다가 15초 간격으로 5 명씩 사용자를 제거하도록 하였다. 

그림-16. Response Times Over Time

4.4 jp@gc - Response Times vs Threads 

사용자 변화에 따른 응답 속도 

그림-17. Response Times vs Threads

4.5 jp@gc - Transaction Throughput vs Threads

사용자 변화에 따른 초당 처리 건수

그림-18. Transaction Throughput vs Threads

4.6 jp@gc - Composite Graph

여러 결과 그래프를 함께 보여준다. 문서에서는 다음 결과 그래프들을 함께 보여주도록 설정하였다.

• jp@gc - Active Threads Over Time
• jp@gc - Response Times Over Time
• jp@gc - Transactions per Second 

그림-19. Composite Graph

5. 리모트 

JMeter 의 remote 기능을 사용하여 여러 시스템을 사용하여 부하테스트를 수행할 수 있다.

이를 위하여 다음과 같은 사항을 점검하여야 한다. 

• 부하 테스트를 실행할 모든 클라인언트 장비들의 방화벽을 OFF 한다.
• 부하 테스트를 실행할 모든 클라인언트 장비들은 동일한 서브넷이여야 한다.
• 부하 테스트를 실행할 모든 클라인언트 장비에서 부하 테스트 대상 서버에 접근이 가능하여야 한다. 
• 부하 테스트를 실행할 모든 클라인언트 장비에 동일 JMeter 버전이 실행되어야 한다.

앞에서 사용되었던 JMeter 프로그램 폴더를 압축하여 부하 테스트를 실행할 원격 클라인언트 장비에 설치한다. 설치는 압축을 푸는것으로 충분하다.

이제 각 클라인언트 장비에서 ${JMETER_HOME}/bin/jmeter-server.bat 을 더블 클릭하여 프로그램을 실행한다. 

JMeter GUI 가 실행되는 장비에서  ${JMETER_HOME}/bin/jmeter.properteis 파일을 수정하여 원격 클라이언트 장비 IP 을 설정한다. remote_hosts 값에 IP 를 적어주면 된다. 

remote_hosts=112.136.181.44,112.136.181.45,112.136.181.46

설정이 완료되면 JMeter 을 실행한다. Run 메뉴의 Remote Start 에서 특정 IP 을 선택하면 

해당 IP 의 리모트 JMeter 을 통하여 테스트가 실행된다. Remote Start All 을 클릭하면 등록된 모든 리모트 JMeter 을 통하여 부하테스트가 진행된다.

프로세스 필요한가?

일반적으로 기업들은 경쟁업체와 차별화 된 경쟁력 강화 수단으로 신제품이나 새로운 서비스를 가장 중요하게 여기고 있다. 물론 기업이 경쟁력을 강화하여 성장과 이익을 추구하기 위해서 신제품은 필수적이면서 가장 중요한 요소이다. 문제는 신제품이나 새로운 서비스만으로 지속적으로 경쟁업체와 차별화를 유지하기가 어렵다는 것이다.

신제품이나 새로운 서비스를 개발한다는 것은 상당히 많은 투자와 노력이 따르는 일이다. 그럼에도 모든 신제품을 고객들이 찾아주지는 않기 때문에 시장에서 성공을 점치기는 어렵다. 따라서 기업들은 일정 부분 실패를 각오하고, 고객의 취향을 예측하여 신제품이나 서비스를 시장에 선 뵈는 것이다. 그런데 이렇게 어렵게 개발한 신제품이나 새로운 서비스를 경쟁업체가 모방하여 쫓아오면 어떻게 될까?

오늘날 동일한 시장에서 경쟁하고 있는 기업끼리의 기술력은 이제 그 차이가 극히 미미한 것이 현실이다. 특정 업체가 새로운 제품이나 서비스를 시장에 선보이면, 경쟁업체에서도 바로 비슷한 제품이나 서비스를 개발하는 것은 이제 흔한 일이 되어 버렸다. 따라서 기업 입장에서는 끊임없이 엄청난 R&D 투자를 함에도 불구하고 경쟁업체와의 차별화 기간은 점점 짧아지게 되고, 차별화를 위해 또 새로운 R&D 투자를 하게 되는 악순환을 반복할 수 밖에 없다.

그러나, 신제품이나 새로운 서비스 외에 프로세스의 혁신을 통해서도 경쟁업체와 차별화가 가능하다. 프로세스 혁신에 의해 R&D 기간을 단축하거나 고객 서비스 시간을 단축 하는 것은 고객의 요구에 신속한 대응이 가능함을 의미한다. 경쟁업체가 고객 대응하는데 7일 걸리던 일을 3일만에 해결할 수 있다면 당연히 이로 인한 고객만족도는 극적으로 향상될 수 있지 않겠는가? 때문에 오늘날의 기업들은 경영혁신의 실천 수단으로 프로세스의 혁신을 추진하기 위하여 많은 노력을 기울이고 있는 것이다.

더욱이 프로세스에 의한 차별화는 경쟁업체에서 모방하기가 쉽지 않다. 프로세스 혁신은 업무 절차, 관련 정보 시스템, 그리고 조직까지의 변화를 수반하는 일이기 때문이다. 물론 경쟁업체도 경영혁신을 위한 프로젝트를 추진하여 비슷한 성과를 낼 수 있도록 프로세스 혁신을 시도할 수 있지만, 적어도 프로젝트를 통해 안정화까지에는 2년 정도의 시간이 걸리게 되고, 그 때까지는 계속 차별적인 우위를 지켜갈 수 있다. 뿐만 아니라 경쟁업체가 프로젝트를 수행하는 기간 동안에 또 새로운 프로세스 변화를 추진할 수 있으므로, 한번 프로세스 혁신에 의해 차별적인 우위를 만들어 내면 지속적인 경쟁우위를 지켜갈 수 있는 토대가 구축되는 것이다.

그 외에도 프로세스 혁신을 통해 얻을 수 있는 것은 많이 있다. 프로세스 단축에 의한 업무처리 시간의 감소는 그만큼 비용 절감의 효과를 얻을 수 있다. 동일한 일을 수행하는데 투입되는 인력의 시간이 줄어들기 때문에 원가절감에 의한 경쟁력 강화 및 이익의 증대를 기대할 수 있다. 또 불필요한 일을 없애고, 단순반복 작업의 자동화 등을 통한 업무수행 효율의 증대는 여유 시간의 창의적인 활동으로 전환을 가능하게 하여 개인과 기업의 전반적인 역량 향상도 가능하게 해 준다. 동일한 일을 남과 다르게, 훨씬 더 나은 성과를 창출할 수 있도록 수행한다는 것은 그만큼 차별적인 경쟁우위에 있고, 발전 가능한 여지를 확보할 수 있음을 의미한다. 기존의 경쟁요소에 추가적으로 프로세스 혁신을 통한 우위 요소를 더하여 지속적으로 앞서 갈 수 있는 기회를 적극적으로 찾는다면 미래의 비전은 더욱 우리와 가까워질 수 있으리라고 생각해 본다.

바보들의 황금

소프트웨어 문제점들이 지속된 이유 중 하나는 일부 비효율적인 기법들이 겉으로 보기에는 매력적이라 것이다. 과거 골드러쉬 동안 일명 바보들의 황금이라 불리는 황철금에 속았던 투기꾼들 처럼 소프트웨어 개발자들은 바보들의 황금이 떨치는 유혹에 넘어갔다.

거대한 바위를 옮기는데 어떤 팀은 그냥 밀기 시작한다. 어떤 팀은 무작정 바위를 옮기려고 하지 않고 먼저 옮길 방법을 고민하고 나무를 베어 굴림대로 사용하기로 한다. 조금 더 현명한 팀은 잘 닦인 길과 통나무 굴림대를 가지고 바위를 움직이기 시작한다. 이 부분에서 이야기하고자 하는 것은 아무 생각 없이 일을 시작하는 것 보다 우선 계획을 세우고 그 일에 대한 생각을 해본 뒤에 효율적인 방법으로 일을 하는 게 빠른 시간에 일을 끝낼 수 있다는 것이다. 출발점을 빨리 떠났다고 해서 결승선에 빨리 가까워지는 것은 아니다. 

소프트웨어를 개발하는 것도 이와 같아서 전체 소프트웨어 개발 팀중 75%는 무작정 바위를 밀면서 프로젝트를 시작한다. 이러한 개발방식을 "일단 작성하고 고쳐보는 개발"이라고 한다. 계획이나 설계 없이 바로 코딩으로 들어가는 것이다. "일단 작성하고 고쳐보는 개발"의 매력은 실행즉시 진척상황을 파악할 수 있고 효과적인 프로젝트 진행을 위한 어떠한 준비 및 훈련도 요하지 않는 다는 것이다. 그러나 거대한 바위를 옮기 것처럼 출발점을 빨리 떠났다고 해서 결승선에 빨리 가까워지는 것은 아니다.

"일단 작성하고 고쳐보는 개발"에 익숙한 개발자들은 테스트나 기술 리뷰를 불필요한 부담이라고 하지만, 품질을 버리고 비용이나 시간을 줄이려는 시도는 대부분 비용을 높이고 일정을 늘리기만 한다. 결함은 일찍 제거할 수록 좋은 효과를 얻는다. 결함 제거를 통하여 좋은 효과를 기대할 수 있는 프로젝트에서 비용이나 일정을 품질과 맞바꾸려는 시도는 겉으로 보기엔 매력적이지만 실제적으로 전혀 쓸모 없는 "바보들의 황금"일 뿐이다. 

터무니 없이 생산성을 높일 수 있다고 자랑하는 새로운 기술들과 몇몇 방법론들을 은빛 총알(Silver Bullet)이라고 부른다. 이러한 새로운 혁신들은 마술도 아니며 쉽지도 않다. 적절한 훈련을 거치고 현실적으로 이루어질 수 있는 기대를 하면서 프로젝트 성격에 맞는 혁신을 일으킬 때만이 장기간에 걸친 전략으로써 의의를 갖는다. 벼락부자가 되려는 마음으로 그것을 적용하려 들면, 혁신은 "바보들의 황금"이 되어버린다. 

 하드웨어 는 일단 만들고 나면 바꾸기 어렵다는 점에서 하드하며 소프트웨어는 바꾸기 쉽다는 점에서 소프트 하다고 알려져 있다.그러나 소프트웨어 시스템이 점점 더 복잡해짐에 따라 이러한 믿음은 소프트웨어 개발에 있어 오히려 해약이 되었다. 소프트웨어 역시 더이상 변형할 수 없는 부분이 존재하게 된다. 이러한 문제를 해결하기 위하여 가능한 확장 가능한 형태로 설계하는 문제는 비용과 직결된다. 유연성과 비용의 균형을 맞추어 어느 정도 하드하게 또는 소프트하게 만들지를 결정하는 것은 어려운 문제이다.

마지막으로 겉으로 보기엔 매력적이지만 실제적으로 전혀 쓸모 없는 "바보들의 황금"을 가려내기 위하여 소프트웨어의 특성들을 아래와 같이 정리하고 있다.

1. 프로젝트의 성공은 프로젝트 초기에 얼마나 빨리 코딩하는가에 달려 있지 않다.
2. 생명에 관련된 시스템을 만들지 않는 한, 결함의 수를 비용과 프로젝트 일정과 맞바꿀 수 없다.  결함 개수에 초점을 맞춘다면 비용과 기간에 걸린 문제는 자연히 해결될 것이다.
3. 은빛 총알은 프로젝트에 유해하다.  어쨌거나 업계의 역사를 볼 때 기업에서는 끊임없이 새로운 은빛 총알을 제안하겠지만 말이다.
4. 건성으로 프로세스를 개선하려는 것은 특히나 더 위험한 일이다.  이 경우 은빛 총알이 오히려 미래에 있을 개선 시도를 갉아먹게 된다.
5. 이름에도 분명 소프트라는 단어가 들어 있는 데도 불구하고, 소프트웨어는 소프트하지 않다.  그리고 소프트웨어를 소프트하게 하기 위해서는 비용이 든다.

출처: Professional 소프트웨어 개발

소프트웨어 공학이란 ?

소프트웨어 공학이란 ?

소프트웨어 공학이란 소프트웨어의 품질과 생산성을 향상시키기 위하여 사용자의 요구사항을 체계적으로 분석하여 설계 및 구현, 구현된 시스템의 시험 그리고 유지보수 및 폐기 시까지 소프트웨어 전수명주기 간에 걸쳐 이루어지는 체계적인 접근법을 말한다.

[Sommerville, in “Software Engineering”]

소프트웨어 엔지니어링은 신뢰성 있고 실제 머신에서도 효율적으로 작동하는 소프트웨어를 얻기 위해 올바른 엔지니어링 원칙을 확립하고 사용하는 것이다

[A Report on a Conference Sponsored by the NATO Science Committee. NATO 1969]

“The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.

(소프트웨어의 개발, 운영 및 유지보수에 체계적이고, 훈련이 잘 된 정량적인 접근 방법을 적용하는 것으로,소프트웨어 개발및 관리를 공학적으로 접근하는 것을 말한다)”

[Definition by IEEE Computer Societ]

 즉, 소프트웨어 공학이라는 것은 소프트웨어의 개발, 운영 및 유지 보수에 체계적이고, 훈련이 잘되고 정량적인 접근 방법을 적용하는 것을 의미하며, 이는 곧 소프트웨어에 공학적으로 접근하는 것을 말한다. 1968년10월 7일 ~ 11일 간 열린NATO 소프트웨어 엔지니어링 컨퍼런스에서 소프트웨어 위기(Software Crisis)라는 용어가 처음 언급된 이후 소프트웨어 개발에 공학적인 접근 방법의 필요성이 제기되면서 소프트웨어공학이라는 용어가 처음 소개되었으며 이후로 약간씩의 수정이 가해졌지만 소프트웨어공학의 정의는 대체로 유사한 내용을 담고 있다.

 이러한 역사적 배경때문에 소프트웨어 공학의 출발은 상업용 어플리케이션이 아닌 국방 또는 정부 시스템을 개발하기 위한 요구사항들을 충족시키기 위하여 발전되었다. 실재로 소프트웨어 개발에서 체계적이고, 훈련되고, 정량화를 통한 측정 가능한 접근방식은 안정성이 최우선 가치가 되는 시스템 개발에서 아주 효과적인 것으로 증명되었다. (그러나 상업용 어플리케이션은 안정성이 최우선 되는 시스템과는 다르다.)

 소프트웨어공학 관련 기술 및 지식은 다양한 분류가 가능하겠지만 2004년 IEEE 컴퓨터 학회는 소프트웨어공학 전체를 10개의 기술 분야로 분류하고 각 기술별로 필요한 상세 지식을 정의한 Guide to SoftWare Engineering Body Of Knowledge (SWEBOK 2004) 를 내놓았다. (소프트웨어 공학자가 알아야할 지식의 범위에 대한 표준 ISO/IEC 24773) 

1. 소프트웨어 요구 사항
2. 소프트웨어 설계
3. 소프트웨어 구현
4. 소프트웨어 시험
5. 소프트웨어 유지 보수
6. 소프트웨어 형상 관리
7. 소프트웨어 공학 관리
8. 소프트웨어 공학 프로세스
9. 소프트웨어 공학 도구 및 방법
10. 소프트웨어 품질

 소프트웨어 공학은 진실 또는 거짓의 개념이 아닌 유용한가/유용하지 않는가 의 개념이다. 유용한가의 여부는 해보지 않고서는 알수 없다. 무턱대로 비판없이 사용하는 것은 브룩스가 이야기한 은빛 총알과 다르지않다.

참고서적 및 자료

Software engineering: Report of a conference sponsored by the NATO Science Committee

Steve McConnell, Code Complete 2

Steve McConnell, Professional software development

Guide to SoftWare Engineering Body Of Knowledge (SWEBOK 2004)

R.S. Pressman,  Engineering: A Practitioner's Approach

Gray Pollice, http://www.ibm.com/developerworks/kr/library/pollice/index.html

소프트웨어는 무엇이라 말할 수 있는가 ?

소프트웨어란 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 말한다. 소프트웨어에 프로그램 이외의 문서와 정보를 포함시키는 이유는 이들 모두가 소프트웨어 생산 행위의 결과이기 때문이다. 또한 프로그램은 프로그램 언어로 작성된 코드, 즉 정적인 표현을 의미하지만 소프트웨어는 프로그램이 컴퓨터를 가동시킨다는 동적인 의미도 포함하고 있다.
소프트웨어는 종이나 자기 디스크와 같은 유형의 매체에 저장되지만 개념적이고 무형적이다. 건축이나 자동차는 그 생산물을 보고 그 구조를 쉽게 파악할 수가 있으나 소프트웨어는 그 생산물의 구조가 코드 안에 숨어 있다. 이를 소프트웨어의 비가시성(invisibility) 이라고 한다. 소프트웨어의 다른 특성으로 복잡성(complexity)을 들 수 있다. 소프트웨어는 개발 과정이 복잡할 뿐만 아니라 전산화 대상 업무, 소프트웨어 시스템 자체가 난해하다. 소프트웨어는 수학이나 물리학에서 볼수 있는 규칙적이고 정형적인 구조가 없다. 요구나 환경의 변화에 따라 적절히 변형시킬 수 있는 특징(conformity)이 있다.
Brooks, 1987

소프트웨어를 정의하는 것은 어려운 일이지만 다음과 같은 특징을 가지고 있다고 본다.

• 소프트웨어는 부드럽다(soft). 적응력이 있으며 변경되기도 한다. 기계 엔지니어들이 설계하고 구현한 물리적 장치와는 매우 다르다.
• 광범위하게 적용될 수 있는 몇 가지 소프트웨어 규칙들이 있다. 화학 엔지니어와 전기 엔지니어들은 물리학과 화학의 기본 원칙을 따라 설계한다. 만약 소프트웨어 법칙이 있다면 아직 그것들을 발견하지 못한 것 같다. 컴퓨터 하드웨어 디자이너들은 정확한 공식을 사용하면 그들이 설계하는 칩에서 발생하는 열의 양을 계산할 수 있지만 소프트웨어 엔지니어들은 프로그램 사이즈 같은 제품 속성을 측정할 방법 조차도 합의에 이르지 못한다.
• 소프트웨어는 대량으로 생산되지 않는다. 자동차 같은 경우는 대량 생산이 가능하다. 액세서리는 변화시킬 수 있지만 기본 디자인을 반복적으로 사용한다. 소프트웨어는 그렇지 않다. OS 같은 특정 프로그램을 복사하여 수백만 사용자들에게 배포할 수는 있지만 단 하나의 실제 프로그램만 구현해야 한다. 제조 과정에는 카피를 만드는 것이 포함되지만 또 다른 동일 제품을 구현하는 것은 포함되지 않는다.
• 소프트웨어의 스펙은 지속적으로 변한다. 심지어 개발 사이클 후반에도 바뀔 수 있다. 절반 정도가 완성된 다리를 보고, "저기요, 내가 보기에 이 다리가 여기 보다는 저쪽에다 짓는 것이 나을 것 같은데요! " 라고 말하는 고객은 없을 것이다. 불행히도 그와 같은 요구 사항에 대한 변경 요청은 소프트웨어에는 끊임없이 발생한다.

소프트웨어 개발의 어려움 - Microsoft Office Business Unit

과거 마이크로소프트사의 Opus(윈도우용 워드 프로세스 개발) 프로젝트는 유난이 어려움이 있었다. 이 프로젝트는 5년 이상의 개발기간을 거처 1989년 11월 30일에 배포되었다.

Opus 프로젝트의 종료 이후의 주된 이슈는

• 다음 프로젝트들은 어떤게 진행되어야 할 것인가 ?
• 어떻게 개발 프로세스의 속도와 효과을 높일수 있을 것이가 ?

이었으며 이러한 이슈들을 해결하기위하여 많은 노력과 시간을 ... 투자한다.

개발 프로세스 진화
마이크로스프트의 초기 개발 프로세스는 특정 형식이 없었고 일정 관리 방법론이나 소프트웨어 아키텍처을 그다지 중요하게 여기지 않았다. 이는 아마도 대부분의 개발자들이 정규과정을 거치지 않았기 때문에 미 국방부나 대기업의 MIS 부서에서 만들어진 아주 구조화된 소프트웨어 개발 방법론을 도입하지 못했을 것이다. 개발자들이 정형의 스펙 명세서 또는 디자인 명세서 없이 소프트웨어를 개발하는 것이 전혀 이상하지 않는 시절이었다.

80년대 중반 마이크로소프트는 소프트웨어를 작성하는데 기술적으로 우수하지만 이해하기 어렵고 사용이 어렵다는 평가를 자주 받았다. 80년대 초 마이크로소프트는 시장의 요구에 더욱 반응할 필요가 있었다. 빌게이츠은 마케이팅 전문가들과 다른 소프트웨어 출신들, MBA 를 이제 막 졸업한 이들을 영입하기 시작하였다. 새로 영입된 많은 이들은 기술 전문가들은 아니었지만 이들의 목적은 고객에 집중하도록 마이크로소프트웨어를 변화시키는 것이었다.

보다 일관된 관점을 위하여, 프로그램 관리 기능이 발전 되기 시작하였다. 최초의 프로그램 관리자가 되는 마케이팅 보조자 제이브 블루멘탈은 프로그램 관리자의 역할을 재 정립하였다. 이때부터 마이크로소프트에서 프로그램 관리자는 제품에 대한 설계와 스팩을 책임지게 되었다.

90년데에는 새로운 제품 개발을 위하여 여러 사람들이 리더쉽을 공유하게 되었다. 이들은 여러 그룹과 같이 일하였으며 전체 총괄 책임자는 존재하지 않았다.

 비즈니스 환경의 변화에 따른 윈도우용 워드 개발
1984년 9월 에 시작된 Word for Window 개발 프로젝트는 1986년 7월에도 여전희 가시적 결과물이 없었으며 과도한 압박을 견디지 못한 프로그램 관리자의 퇴사로 새로운 국면을 맏이한다. 빌게이츠는 새롭게 정립된 프로젝트 관리자 개념을 도입하고 새로운 팀을 구성한다. 많은 노력과 시련끈에 1989년 11월 30일 제품을 출시하게 된다.

비록 원래 계획된 출시 일자를 넘겼지만, Word for Windows 는 비평가들의 환호를 받았다. 유력 컴퓨터 저널 InfoWorld 가 워드 프로세스 분야의 최대 경쟁자인 WordPerfect 보다 높게 평가한 마이크로소프트의 첫번째 워드 프로세스 였다. 판매 역시 마이크로소프트의 예측을 넘어섰다.

워드프로세스 시장의 강자 WordPerfect 가 Windows 용 버전을 1991년 2월에 출시할것으로 발표하자 WinWord 는 새로운 버전의 출시를 준비한다.

제품 개발 향상을 위한 아이디어
소프트웨어 개발 프로젝트에서 반복적으로 발생되는 문제들 해결하려는 시도로 종결되었던 모든 프로젝트들을 리뷰하기로 한다.

ㄱ)프로세스
보다 정형화된 절차가 필요하다.
- 설계와 구현 단계가 구분하여 개발 초기의 방향성의 모호함을 제거한다.
- 객체지향 모듈로 개발되어 각각이 독립적으로 테스트 될 수 있게 하여 언제나 배포 가능한 제품을 보유하게 한다.

ㄴ)프로젝트 관리
집중과 통제가 더 요구된다. 프로그램관리자가 제품에 대한 설계와 스팩을 책임지어 제품이 일관성을 유지할 수 있게 한다.

ㄷ)개발전략
코어 코드 접근법과 같은 제품개발에 있어 일관된 전략을 도입하여 생산성을 향상시킨다.

화물숭배 소프트웨어공학

이미지출처 : www.codeforsomething.com

아인슈타인 이후 최고 천재로 평가되었던 미국의 물리학자 리차드 파이먼 교수가 1974년 캘리포니아 공대 학위 수여식에서 행한 연설의 일부이다.

예전에 남태평양 어떤 섬에는 화물 숭배라는 종교를 믿는 사람들이 있었다. 당시에 섬 하늘에는 전쟁 물자를 수송하는 비행기들이 많이 다녔고, 섬 사람들은 비행기를 신의 전령이라 믿었다. 그들은 언젠가 신이 자신들에게도 비행기에 엄청난 물자를 실어 보내줄 것이라고 생각했다. 그래서 비행기가 섬으로 착륙할 수 있도록 활주로 비슷한 것을 만들기 시작했고, 활주로 좌우에는 유도등처럼 불을 피워 놓았다. 또 사람이 들어와 앉을 수 있도록 관제탐 같은 통나무 집도 만들었고, 대나무를 깎아 안테나처럼 달아 놓았다. 그 안에서 나뭇가지를 헤드셋처럼 묶고 앉아, 비행기가 착륙하기만을 하염없이 기다렸다. 그들은 이전에 다른 곳에서 본 진짜 활주로의 모습을 재현했다. 적어도 그 형태만큼은 완벽했다. 그러나 비행기는 오지 않았다. 나는 섬 사람들이 "과학적인 연구의 형태와 지침"을 따르기 때문에, 이것을 화물 숭배 과학이라 부른다. 그들은 뭔가 중요한 것을 잊고 있음이 분명했다. 왜냐하면 비행기가 한 대도 오지 않았기 때문이다.

파인먼은 소위 과학자들 가운데서도 과학적 방법의 모든 형식은 갖추었지만 존경이나 지원할 가치라고는 조금도 없는 유사과학(pseudo-science)이 있음을 지적하며, 이를 화물 숭배 과학이라 하였다. 그는 또한 정직함과 성실성이 결여된 과학을 화물 숭배와 다를 바 없는 유사과학으로 규정하여 크게 주의할 것을 당부하였다.

그의 연설 가운데 가장 놀라운 것은 정직한 과학을 위한 제1원칙으로 "스스로를 속이지 말라"는 원칙을 제시한 것이다. 그는 세상에서 가장 속이기 쉬운 것은 자기 자신이며, 자신을 속이지 않는다면 다른 과학자들을 속이지 않는 것도 쉬운 일이라고 하였다. 실험 결과가 유명 과학자의 논문에서 참조한 결과와 다를 때 별다른 가책 없이 자신의 실험 결과를 무시하고 참조한 결과를 존중한다든지, 예측된 결과와 일치하는 실험 결과만을 논문에 포함시키고 다른 결과의 발생 자체를 언급하지도 않는 행태 등은 스스로를 속이는 대표적인 부정직함의 사례일 것이다.

스티브맥코넬은 "프로페셔널 소프트웨어 개발" 에서 소프트웨어공학에서도 화물숭배 현상이 있음을 지적한다.

소프트웨어 개발 방식에는 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간사용, 오랜 경험을 통해 좋다고 판명된 소프트웨어 공학 기법들을 적용하여 프로젝트를 성공시키는 "프로세스 기반 개발"과 해당 분야의 최고 인재를 고용하고 전권을 위임을 통하여 동기를 부여하는 "책임 기반 개발" 있다.

이 두 개발 방법은 각각 현명하게 사용한다면, 비용을 절감하고 개발기간도 단축하면서 품질 좋은 소프트웨어를 만들어 낼수 있다. 그러나 두가지 방법다 완벽하게 실행되기는 어렵고, 제대로 수행하고 있는 지 알아내기도 어렵다. 그러나 대부분의 조직은 문제의 본질이 아닌 흉내내기에 머문다.

"프로세스를 중시한다고 사칭하는 조직"을 "관료조직"이라고 부른다. 이들은 소프트웨어 프로세스의 형태를 그 본질보다 더 중요하게 생각한다. 프로세스를 잘못 사용하면 오히려 개발자들의 사기가 떨어지고, 생산성도 저하된다.

"책임을 중시한다고 사칭하는 조직"을 착취조직이다 부른다. 이들은 결과(긴 근무시간)와 원인(높은 동기부여)을 혼동한다. 이런 조직에서는 직원들이 똑똑하게 일하는 것보다는 그냥 열씸히 일하는 것을 최고로 친다. 당연희 무질서하고 비효율적이다.

즉 문서화를 위한 문서화, 초과근무를 위한 초과근무, SW-CMM에 대한 비굴할 정도의 집착, 무비판적인 RUP나 eXtreme Programming 수용 등 본질보다 형식을 더 강조하는 모든 행위들은 화물숭배 소프트웨어공학이다.

스티브 맥코넬의 바보들의 황금

소프트웨어 문제점들이 지속된 이유 중 하나는 일부 비효율적인 기법들이 겉으로 보기에는 매력적이라 것이다. 과거 골드러쉬 동안 일명 바보들의 황금이라 불리는 황철금에 속았던 투기꾼들 처럼 소프트웨어 개발자들은 바보들의 황금이 떨치는 유혹에 넘어갔다.

거대한 바위를 옮기는데 어떤 팀은 그냥 밀기 시작한다. 어떤 팀은 무작정 바위를 옮기려고 하지 않고 먼저 옮길 방법을 고민하고 나무를 베어 굴림대로 사용하기로 한다. 조금 더 현명한 팀은 잘 닦인 길과 통나무 굴림대를 가지고 바위를 움직이기 시작한다. 이 부분에서 이야기하고자 하는 것은 아무 생각 없이 일을 시작하는 것 보다 우선 계획을 세우고 그 일에 대한 생각을 해본 뒤에 효율적인 방법으로 일을 하는 게 빠른 시간에 일을 끝낼 수 있다는 것이다. 출발점을 빨리 떠났다고 해서 결승선에 빨리 가까워지는 것은 아니다.

소프트웨어를 개발하는 것도 이와 같아서 전체 소프트웨어 개발 팀중 75%는 무작정 바위를 밀면서 프로젝트를 시작한다. 이러한 개발방식을 "일단 작성하고 고쳐보는 개발"이라고 한다. 계획이나 설계 없이 바로 코딩으로 들어가는 것이다. "일단 작성하고 고쳐보는 개발"의 매력은 실행즉시 진척상황을 파악할 수 있고 효과적인 프로젝트 진행을 위한 어떠한 준비 및 훈련도 요하지 않는 다는 것이다. 그러나 거대한 바위를 옮기 것처럼 출발점을 빨리 떠났다고 해서 결승선에 빨리 가까워지는 것은 아니다.

"일단 작성하고 고쳐보는 개발"에 익숙한 개발자들은 테스트나 기술 리뷰를 불필요한 부담이라고 하지만, 품질을 버리고 비용이나 시간을 줄이려는 시도는 대부분 비용을 높이고 일정을 늘리기만 한다. 결함은 일찍 제거할 수록 좋은 효과를 얻는다. 결함 제거를 통하여 좋은 효과를 기대할 수 있는 프로젝트에서 비용이나 일정을 품질과 맞바꾸려는 시도는 겉으로 보기엔 매력적이지만 실제적으로 전혀 쓸모 없는" 바보들의 황금"일 뿐이다. 터무니 없이 생산성을 높일 수 있다고 자랑하는 새로운 기술들과 몇몇 방법론들을 은빛 총알(Silver Bullet)이라고 부른다. 이러한 새로운 혁신들은 마술도 아니며 쉽지도 않다. 적절한 훈련을 거치고 현실적으로 이루어질 수 있는 기대를 하면서 프로젝트 성격에 맞는 혁신을 일으킬 때만이 장기간에 걸친 전략으로써 의의를 갖는다. 벼락부자가 되려는 마음으로 그것을 적용하려 들면, 혁신은 "바보들의 황금"이 되어버린다.

하드웨어 는 일단 만들고 나면 바꾸기 어렵다는 점에서 하드하며 소프트웨어는 바꾸기 쉽다는 점에서 소프트 하다고 알려져 있다. 그러나 소프트웨어 시스템이 점점 더 복잡해짐에 따라 이러한 믿음은 소프트웨어 개발에 있어 오히려 해약이 되었다. 소프트웨어 역시 더이상 변형할 수 없는 부분이 존재하게 된다. 이러한 문제를 해결하기 위하여 가능한 확장 가능한 형태로 설계하는 문제는 비용과 직결된다. 유연성과 비용의 균형을 맞추어 어느 정도 하드하게 또는 소프트하게 만들지를 결정하는 것은 어려운 문제이다.

마지막으로 겉으로 보기엔 매력적이지만 실제적으로 전혀 쓸모 없는 "바보들의 황금"을 가려내기 위하여 스티브 맥코넬은 소프트웨어의 특성들을 아래와 같이 정리하고 있다.

프로젝트의 성공은 프로젝트 초기에 얼마나 빨리 코딩하는가에 달려 있지 않다. 생명에 관련된 시스템을 만들지 않는 한, 결함의 수를 비용과 프로젝트 일정과 맞바꿀 수 없다. 결함 개수에 초점을 맞춘다면 비용과 기간에 걸린 문제는 자연히 해결될 것이다. 은빛 총알은 프로젝트에 유해하다. 어쨌거나 업계의 역사를 볼 때 기업에서는 끊임없이 새로운 은빛 총알을 제안하겠지만 말이다. 건성으로 프로세스를 개선하려는 것은 특히나 더 위험한 일이다. 이 경우 은빛 총알이 오히려 미래에 있을 개선 시도를 갉아먹게 된다. 이름에도 분명 소프트라는 단어가 들어 있는 데도 불구하고, 소프트웨어는 소프트하지 않다. 그리고 소프트웨어를 소프트하게 하기 위해서는 비용이 든다.