2004-12-07

오픈 소스의 이해와 활용

1. 개요

소프트웨어 비즈니스에서 오픈 소스가 갖는 시사점을 밝히고 그 활용 영역을 제시한다.


2. 오픈 소스의 이해

오픈 소스는 어떤 것의 개발/배포/사용에 있어서 특정한 내용을 포함한 라이센스 규정을 충족시키는 것을 의미한다. 대부분의 오픈 소스가 소프트웨어를 대상으로 하지만, 문서나 방법론 등과 같이 많은 사람들이 공동 작업을 통해서 이루어 낼 수 있는 것들에 포괄적으로 적용될 수 있다.

오픈 소스가 최소한으로 지켜야 하는 주요한 라이센스 요소들은 아래와 같다. 이는 OSI(Open Source Initiative)의 The Open Source Definition 문서에서 발췌한 것이다.

  • 소프트웨어의 사용이 무료여야 하며, 이를 토대로 개발한 다른 소프트웨어를 판매하거나 배포하는데 제약이 없어야 한다.
  • 소프트웨어의 원본 소스 코드에 무료로 쉽게 접근할 수 있어야 한다.
  • 누구나 소프트웨어를 수정하여 이를 원본 소프트웨어와 동일한 라이센스 하에서 배포할 수 있어야 한다.
  • 소프트웨어 사용 목적이나 사용자 그룹에 차별이 없어야 한다.
  • 오픈 소프트웨어는 특정한 기술에 중립적이어야 하며, 다른 소프트웨어의 사용을 강제하지 말아야 한다.

오픈 소스로 간주되는 다수의 라이센스가 존재하며, 이들의 대부분은 위의 조건을 충족한다. 따라서 소스를 공개하지 않는 프리웨어(Freeware)나 쉐어웨어(Shareware) 등은 오픈 소스가 아니고, 정부 등 제한적인 사용자 그룹에게만 소스를 공개하고 그 소스 이용에 제한을 가하는 몇몇 기업들의 행위 역시 오픈 소스에 해당할 수 없다. 다양한 오픈 소스 라이센스의 종류와 각각의 라이센스 상세 내용은 다음 문서를 참조 한다.


3. 오픈 소스의 현황

오픈 소스 소프트웨어는 여러 분야에서 큰 성공을 거두고 있다. 예를 들어, 대표적인 오픈 소스인 리눅스 운영 체제를  미국 대기업의 40%가 사용하고 있고, 아파치 웹 서버는 전 세계 웹 서버의 65%를 차지한다. 그리고 SendMail은 전 세계 이메일의 80%를 처리하고 있다.

오픈 소스는 OSI라는 자발적/비영리 단체의 캠페인 활동으로 꾸준히 확산되고 있으며, 세계적인 오픈 소스 개발자 지원 사이트인 GNU, SourceForge.net, OSTG(Open Source Technology Group), 아파치 등 크고 작은 커뮤니티들이 활성화되어 전 세계 오픈 소스 소프트웨어의 확산 및 개발자 간의 응집을 주도하고 있다.

또한 최근 몇 년 간은 새로운 비즈니스로서의 오픈 소스에 대한 관심이 증대되면서 이를 이용한 신규 비즈니스를 창출하고자 하는 기업들의 참여가 늘어나고 있다. Eclipse에 소스 코드를 기증한 IBM을 비롯하여, Sun, 애플, Novell 등의 업체들이 오픈 소스를 적극적으로 지원하고 활용하고 있다.


4. 오픈 소스의 일반적인 이슈

오픈 소스와 관련해서 언급되는 일반적인 이슈에 대해서 간단하게 정리한다.


오픈 소스와 프리 소프트웨어(Free Software)의 차이는 무엇인가?

오픈 소스에 참여하는 개발자들은 오픈 소스를 이용한 소프트웨어 개발이 더 좋은 소프트웨어를 생산한다고 믿는 경제적 동기를 중시하고, 프리 소프트웨어를 지지하는 개발자들은 프리 소프트웨어는 도덕적으로 옳으며 그렇지 않은 상용 제품은 도덕적으로 옳지 않다고 보는 윤리적 동기를 중시한다. 결국 오픈 소스와 달리 프리 소프트웨어를 기반으로 개발한 소프트웨어는 판매할 수 없다.

현재 오픈 소스는 OSI를 중심으로, 프리 소프트웨어는 FSF(Free Software Foundation)를 중심으로 발전하고 있는데 경제적 동기를 인정하는 쪽으로 이 둘의 차이가 좁혀지고 있다.


오픈 소스 소프트웨어의 품질을 신뢰할 수 있는가?

오픈 소스 소프트웨어에 따라서 다르다. 전 세계적으로 약 8만 5천 건의 오픈 소스 프로젝트가 존재하며 이 중 아파치 웹 서버와 같이 높은 품질 수준을 달성한 소프트웨어도 있고, 그렇지 않은 이름도 모를 소프트웨어도 존재한다.

그런데 일차적인 관심은 오픈 소스 방식을 통한 소프트웨어 개발이 아닌 오픈 소스 방식으로 개발된 양질의 소프트웨어 활용에 있다.


오픈 소스 소프트웨어를 상업적으로 이용할 수 있는가? 그리고 오픈 소스 소프트웨어를 이용해서 개발한 소프트웨어의 소스를 공개해야 하는가?

오픈 소스 소프트웨어를 상업적으로 사용하는데 제한은 없다. 단, 오픈 소스 소프트웨어 자체를 변경한 경우에 한해서 변경한 내용에 대해서 공개해야 하는 경우가 있다. 그리고 오픈 소스 소프트웨어를 이용하여 개발한 소프트웨어에 대해서는 독자적인 새로운 라이센스를 가져갈 수 있다.


라이센스와 관련한 법적 문제 발생 시 이를 해결할 수 있는가?

오픈 소스 소프트웨어가 저작권 침해 등으로 소송을 당하는 경우, 상용 소프트웨어를 사용한 경우와는 다르게 이를 사용한 업체도 함께 고소를 당할 수 있다. 아직까지 이에 대한 뚜렷한 대처 방안은 없지만 오픈 소스 커뮤니티 전체가 부담을 나누어 짐으로써 위험을 분산시킬 수는 있다.


오픈 소스 소프트웨어는 문서를 포함한 참고 자료가 부족하고 기술 지원이 부실하지 않은가?

오픈 소스 소프트웨어는 상용 소프트웨어에 비해서 공식 문서가 부족한 것이 사실이다. 그러나 웹의 발전과 개발자 및 사용자 커뮤니티의 활성화로 인해서 필요한 자료를 쉽게 획득할 수 있다.

그리고 기술 지원의 부족을 새로운 사업 기회로 인식할 수 있다. 오픈 소스 소프트웨어에 대한 지원을 주 업무로 하는 SpikeSource와 같은 회사가 그 예가 된다.


오픈 소스에 대한 시장의 실패에 대해서 정부가 개입해야 하는가?

오픈 소스 소프트웨어가 상용 제품과 비교해서 품질이 높거나 양질의 품질에 가격경쟁력을 가지고 있음에도 불구하고 시장에서 배척 받을 수 있다. 이는 상용 소프트웨어가 가지고 있는 네트워크 효과에 근간한 규모의 경제 때문에 발생하는 시장의 실패이다. 따라서 이런 경우에 정부가 시장에 개입할 필요가 있다는 의견이 있다.

급속한 경제 발전으로 인해서 소프트웨어에 대한 수요가 높아지고 있는 브릭스(BRICs, 브라질, 러시아, 인도, 중국) 국가에서는 상용 소프트웨어의 사용에 따른 비용 부담의 축소와 자국의 소프트웨어 산업을 보호하기 위한 수단으로 오픈 소스의 사용을 정부 차원에서 적극 장려하고 있다.


모든 소프트웨어는 오픈 소스로 개발되어야 하는가?

현재로서는 알 수 없다. 하지만 오픈 소스가 독점적 소프트웨어 업체의 영향력을 축소시켜 새로운 사업 기회를 창출하고, 의사 결정에 있어서의 선택의 폭을 늘려줄 것이라고는 짐작할 수 있다.


5. 오픈 소스의 기대 효과

오픈 소스 활용을 통해서 소프트웨어 구매 비용 절감, 취약한 분야의 기술력 확보, 신규 서비스 시장 개척 등의 효과를 얻을 수 있다.


비용 절감

COTS(Commercial Off-The Shelf Software) 방식의 개발에서는 컴포넌트 조달이 주요한 이슈이다. 여기서 컴포넌트는 CBD(Component Based Development)에서 지칭하는 것보다는 큰 개념으로 웹 브라우저, 웹 서버, 웹 어플리케이션 서버, 데이터베이스 관리 시스템 등을 지칭한다. COTS에서 오픈 소스를 하나의 조달 창구로 사용할 수 있으며 이를 통해서 비용 절감을 이루어 낼 수 있다.

오픈 소스 소프트웨어만으로 가능한 부분에 상용 소프트웨어를 사용하는 것은 낭비이다.

단, 어떤 상황에서 오픈 소스 소프트웨어로 상용 소프트웨어를 대체 할 수 있는지에 대한 기준을 자체적으로 보유하고 있어야 한다. 오픈 소스인 아파치 톰켓으로 몇 명까지의 동시 사용자를 감당할 수 있는지에 대한 정확한 자료가 준비되어 있어야 오픈 소스 소프트웨어의 사용을 고객에게 제안하고 설득할 수 있을 것이다.


취약한 분야의 기술력 확보

기술력 부족으로 특정 영역의 어플리케이션 개발에 참여하지 못하거나 참여하더라도 기술력을 지닌 협력 업체에 대한 의존도가 높아 수익을 기대할 수 없는 경우에 오픈 소스를 활용할 수 있다.

부족한 기술력을 보충해 줄 오픈 소스를 찾아 이를 적극적으로 활용하는 것이 하나의 안이 될 수 있다.


신규 서비스 시장 개척

상용 소프트웨어는 개발 업체가 그 소프트웨어에 대한 서비스 시장을 장악하고 있기 때문에 참여할 수 있는 부분에 큰 제약이 존재한다. 그러나 오픈 소스 소프트웨어에 대해서는 기술지원/교육/컨설팅 등의 서비스 시장에 제약 조건 없이 참여할 수 있다. 특히 여러 오픈 소스 소프트웨어를 통합하여 패키지 형태로 제공하는 서비스 분야에 주목해야 한다.


6. 오픈 소스의 활용 영역

기업이 오픈 소스 사용에서 라이센스를 준수하고, 기타 저작권과 관련한 사항을 침해 하지 않는다면 이를 활용하는데 별다른 제약은 없다.

오픈 소스의 활용은 3 단계로 이루어진다. 1 단계는 다양한 오픈 소스를 하나의 제품으로 패키징하여 배포하는 것이다. 리눅스 배포판을 만들어 파는 것이 여기에 해당한다. 2 단계는 오픈 소스를 기반으로 새로운 상용 소프트웨어를 만들어 판매하는 것이다. ACE(Adaptive Communication Environment)를 이용해서 범용적인 게임서버를 구축하는 것이 여기에 해당한다. 마지막 3 단계는 1 단계와 2 단계에서 만들어낸 산출물에 대한 서비스를 제공하는 것이다.

오픈 소스를 활용할 수 있는 일반적인 영역은 아래와 같다.


데스크 탑 사무 자동화 환경 구축

리눅스 운영 체계를 기반으로 오픈 오피스, 모질라 웹 브라우저 등의 다양한 오픈 소스 소프트웨어를 이용하여 MS 윈도우 패키지에 대응되는 데스크 탑 환경을 구축하는 것으로 정부 정책 방향에 따라서 시장이 확대될 수 있다.

노벨 리눅스 데스크 탑이 대표적인 사례이다. 향후 BRICs 국가들과 국내 공공 시장 및 중소규모 업체에서 수요가 발생할 수 있다. 국내외 업체와의 협력을 통해서 이 시장에 진출하거나 독자적인 사업을 할 수도 있다.

몇 년 전에 비해서 리눅스 기반의 오픈 소스 데스크 탑 환경이 상용 제품에 견줄 수 있는 품질 경쟁력을 확보했다는 사실을 주시해야 한다.


웹 어플리케이션 구축

현재 많은 웹 어플리케이션들이 LAMP(J), Ruby, 파이선 등의 오픈 소스에 기반하여 구축되고 있으나, 기업용 어플리케이션 시장에서의 비중이 상대적으로 낮다. 이런 기업용 어플리케이션 시장에까지 오픈 소스 플랫폼을 적용 시킬 수 있다. 오픈 소스 플랫폼을 기업용 웹 어플리케이션 시장에 적용하여 비용 절감 효과와 오픈 소스 플랫폼에 대한 서비스 시장에 진출할 수 있다.


서버 어플리케이션 구축

도메인에 독립적인 서버 어플리케이션의 근간을 이루는 오픈 소스 플랫폼이 존재한다. 각각 C와 C++, 파이선 언어로 구현된 APR(Apache Portable Runtime)이나 ACE(Adaptive Communication Environment), Twisted가 대표적이다.

APR과 ACE, Twisted 등을 활용하여 웹 혹은 C/S 기반이 아닌 특화된 서버 어플리케이션 구축 사업에 진출할 수 있다.

단, APR과 ACE, Twisted 등의 플랫폼에 대한 내재화 작업이 필요하다.


개발 도구로의 활용

소프트웨어 개발에 필요한 개발 도구 소프트웨어 분야에도 많은 오픈 소스가 존재한다. 주로 프로그래밍 도구와 형상 관리 도구에 집중되어 있다. 오픈 소스 개발 도구를 중심으로 사내 개발 도구 표준을 재정립함으로써 도구 사용에 따른 비용 부담을 줄이고, 불법 소프트웨어 사용에 따른 부가적인 위험을 회피할 수 있다.


라이브러리로의 활용

소프트웨어를 구성하는 특정 기능을 오픈 소스 라이브러리를 사용하여 구현하는 것이다.
현재 오픈 소스의 활용이 가장 활성화된 영역이다. 오픈 소스 라이브러리를 사용함으로써 추가적인 비용 부담 없이 개발 시간을 줄일 수 있다.

단, 어떤 기능을 어떤 오픈 소스 라이브러리를 이용해서 구현할 수 있는지에 대한 전사 차원의 표준 카탈로그를 마련/공유함으로써 라이브러리 조달과 관련한 부대비용을 줄이려고 노력해야 한다.


개발 방법론 및 아키텍처

XP, Crystal Clear 등의 Agile 방법론의 다수가 오픈 소스 방법론이며, TOGAF(The Open Group Architecture Framework)라는 지명도 있는 아키텍처 개발 프레임워크도 존재한다. 방법론과 표준 아키텍처 수립 및 개정에 오픈 소스 방법론 및 아키텍처 프레임워크를 라이센스 비용을 지불하지 않고 활용할 수 있다.

그러나 상용 방법론에 대한 라이센스 보호 장치가 상대적으로 취약함으로 큰 비용 절감 효과를 기대할 수는 없을 것이다.


7. 결론

LAMP와 LAMJ는 웹 어플리케이션 구축을 위한 플랫폼이다. 이는 리눅스(Linux) 운영 체계, 아파치(Apache) 웹 서버, MySQL 데이터베이스 관리 시스템, PHP 혹은 톰켓(Tomcat) 웹 어플리케이션 서버 등의 오픈 소스로 구성된 플랫폼을 지칭한다. 논리적으로 이 플랫폼을 사용하게 되면 소프트웨어 구매 비용은 0이 된다. 그렇다면 기업은 이 플랫폼 하에서 프로젝트를 수행할 수 있는가? 혹은 그 수행에서 어떤 결과를 이끌어 낼 수 있는가?

LAMP(J)로 고객의 요구사항을 부합할 수 있는가? 이 플랫폼이 특정 하드웨어에서 1,000 명의 동시 접속자에게 원활하게 서비스를 제공할 수 있는가? 상용 플랫폼과 비교해서 충분한 개발 생산성을 보장할 수 있는가? 메인 프레임, ERP, SCM 등의 기존 어플리케이션과 연동할 수 있는가? 개발자 교육 비용은 적절한가? 상용 플랫폼의 경우, 이에 대한 답변은 플랫폼 제공 업체의 책임이다. 하지만 LAMP(J)에서는 기업의 책임이 된다. 하지만 이 책임은 기업에게 새로운 시장 기회를 제공한다. LAMP(J)에 대한 신뢰할 수 있는 검증 자료를 확보하여 높은 수준의 서비스를 제공할 역량을 갖출 수 있다면 고객에게 비용 절감이라는 효과를 제공하면서 이 오픈 소스 플랫폼 서비스로부터 신규 매출을 창출할 수 있게 된다.

경쟁력 강화와 가치 창출을 위해서 고객에게 최적화된 시스템을 구축하여 공급해야 한다. 최적화란 효율과 효과라는 두 측면을 아우른다. 독점 상용 소프트웨어에 대한 과도한 의존은 효율이라는 측면의 약화를 야기한다. 불필요한 기능을 포함한 소프트웨어를 그 기능에 대한 비용과 소프트웨어에 대한 업체의 막대한 광고 비용까지 포함하여 높은 가격에 구매해야 하며, 업체에 의해서 주도되는 잦은 업그레이드 비용까지 부담해야 한다. 오픈 소스에서 이런 시장의 구조에 변화를 줄 수 있는 전략적 도구를 찾을 수 있을 것이다.


8. 참고 자료


2004-11-06

자바에서 한글 처리

1. ISO-8859-1에서 KSC5601로

String before = ...
String after = new String(before.getBytes("8859_1"),"KSC5601");


2. properties 파일에서 한글 읽기
 
(1) 1. 번 방식 사용
 
(2) native2ascii 도구 사용

native2ascii Before.poroperties After.properties

 
3. 주의 사항
 
(1) 이클립스에서 properties 파일 관리
 
속성에서 encoding을 MS949로 변경

2004-10-26

J2SE 1.4 Assertions

1. 프로그램 작성

Test.java

int month = ...

/* 메시지 없이 */
assert (month <13);

/* 메시지 포함 */
assert (month <13) : "The value of iMonth has exceeded 12";

메시지를 메서드 호출을 통해서 받을 수 있다. 단, 그 메소드는 void를 반환해서는 안된다.


2. 소스 컴파일

javac -source 1.4 Test.java


3. 프로그램 실행

java -enableassertions Test


4. Eclipse 3.0 설정

Java Compiler > Compliance and Classfiles 메뉴에서

Use default compliance settings 체크 박스를 비활성화하고 Generated .class files Compatibility와 Source Compatibility를 모두 1.4로 선택한다.

2004-10-13

Sun Tech Days 2004 참석 후기

장소 : 서울 서초구 반포동 메리어트 호텔
시간 : 2004년 10월 7일 (목) - 8일 (금)
개요 : 2개의 트랙으로 구성되어 있었으며, 발표자의 대부분은 Sun, SAP, Oracle, AMD의 본사 인력이었음(동시 통역으로 진행). 그리고 발표 내용의 80%는 자바 관련이었음.
홈페이지 : http://www.suntechdays.co.kr


세션 내용

8일의 자원 봉사 관계로 두번째 날 오후의 세션은 참석하지 못함.

(1) 기조연설 1 - James Gosling

The Future of Java라는 주제로 소프트웨어 개발의 복잡도를 극복하기 위한 노력들을 설명. J2SE 5.0, 도구(Sun Java Creator), 클라이언트 프로그램 등이 주요 주제가 되었는데 Sun Tech Days 전체가 각각의 부분들에 대해서 자세하게 다루는 식으로 지정됨.


(2) 기술시연 - 여려명

4가지 정도의 주제에 대해서 담당자들이 나와서 5분 동안 시연함. 그 주제는 리눅스/자바 기반의 데스크탑 환경, Wearable Computing, J2ME, Sun Java IDE를 이용한 성능 튜닝이었음. 별로 색다른 내용은 없었으며, 데스크탑과 Sun Java IDE 시연에서는 시연 중 에러가 발생하였음.


(3) Beyond Web Services: Developing Service-Oriented Applications (Raghu Kodali, Oracle)

SOA에 대한 설명을 Oracle ADF(Application Development Framework)를 중심으로 설명함.


(4) Think Applications, Run J2EE (Ivo Totev, SAP AG)

SAP의 NetWeaver와 자바/J2EE의 관계에 대해서 개괄적으로 설명함.


(5) J2EE Persistence : Explore your persistence options (조인영, Sun)

자바 환경에서 Persistence를 구현하는 것을 JDBC, JDO, EJB Entity Bean, Hiberate를 중심으로 비교 설명. 기초적인 수준에서만 다룸.


(6) SOA : Web Services and Business Process Modeling (Raghu Kodali, Oracle)

SOA를 웹 서비스에 초점을 두어서 설명함. (3) 세션과 연결되어 있었음.


(7) JavaServer Faces and Sun Java Studio Creator : Experience the Next Generation Web Application Framework (Rima Patel, Sun)

JSF에 대한 기본적인 설명과 JSF와 Struts 간의 관계를 보여줌. 그리고 이를 Sun Java Studio Creator를 이용해서 애플리케이션을 개발하는 것에 대한 데모


(8) NetBeans 4.0 and Sun Java Studio 7 Enterprise Edition : Maximize Developer Productivity (신상철, Sun)

Sun의 자바 개발 도구인 NetBeans와 Sun Java Studio 7에 대한 설명 및 데모. 다른 경쟁 제품과 비교했을 때 고유한 특징이나 장점을 찾기는 어려웠음.


(9) J2SE 5.0 : Watch and Hear the Tiger Roar! (Angela Caicedo, Sun)

J2SE 5.0에서 변경되거나 추가된 문법과 새로운 라이브러리에 대한 설명. J2SE 5.0을 이해하는데 발표 자료(PPT, 약 130장)를 사용하면 유용할 듯 함.


후기

새로 발표된 J2SE 5.0에 대한 내용, 웹 서비스/SOA, 다양한 개발 도구 등을 중심으로 짜여진 이번 행사는 내용 수준에서는 간단한 소개 수준이었음.

2004-10-12

마이 웨이

내가 좋아하는 야구팀, OB 베이스. 아무 것도 모를 7살 어린 나이에, 한국시리즈에서의 그 떨림에 좋아하게 된 팀.

절대로 그 어느 팀도 넘볼 수 없는 원년 우승팀이라는 자신감 하나로 꼴찌 OB라는 비아냥에도 불구하고 좋아한 팀.

당장이라도 박철순만 돌아오면 리그를 호령할 줄 알았던... 나의 학창 시절의 매일은 언제나 곰들의 전날 경기 성적에 따라서 좌우되던...


1994년, 여자 친구에게서 이별통고를 받을 때 이별하자는 말보다... OB 선수들의 집단 항명에 'OB 망했네'라는 그녀의 말이 더욱 가슴 아프게 다가오던...

그리고 그토록 기다리던 우승을 부산 출신 고참들이 즐비한 비무장지대 내부반에서 이등병으로 감격해하며 맞았던...

이름이 두산으로 변경되어서인지... 아니면 사느냐고 지쳐서인지... 예전 같진 않지만... 오랜만에 플레이오프 첫경기에서의 두산의 승리에... 옛 생각을 떠올리며...

2004-10-10

비즈니스 애플리케이션 프레임워크 & 컴포넌트

* 인터넷에서 비즈니스 애플리케이션 프레임워크 & 컴포넌트(이하 BAFC)에 대한 자료는 간단한 소개 이상은 찾기가 어렵습니다. 디자인이나 구현과 관련된 내용은 Martin Fowler의 Anaylsis Patterns(http://www.martinfowler.com/articles.html#N1003F) 외에는 없습니다. 그 이유를 나름대로 추론하자면 첫째는 BAFC에 대한 관심의 부족을, 두번째는 BAFC에 대해서 내세울만한 성과의 부족을, 세번째는 (업체들의) 그런 자료를 공개할 동기 부족을 들 수 있을 것 같습니다.



비즈니스 애플리케이션

ERP(Enterprise Resource Planning), CRM(Customer Relationship Management), SCM(Supply Chain Management), HRM(Human Resource Management) 등으로 대표되는 (영리 혹은 비영리) 비즈니스 업무 자동화와 정보 제공 및 분석을 위한 애플리케이션을 비즈니스 애플리케이션이라고 한다. 비즈니스 애플리케이션은 앞의 예처럼 패키지 형태의 솔루션일 수도 있고, 독자적으로 개발한 Custom-built 애플리케이션 형태일 수도 있다. 비즈니스 애플리케이션의 자세한 분류 체계는 PeopleSoft(http://www.peoplesoft.com/corp/en/products/ent/index.jsp) 혹은 SAP(http://www.oracle.com/solutions/index.html)을 참조한다.


Product Line

다양한 형태의 비즈니스 애플리케이션들은 공통점을 보유하고 있다.

첫 번째는 기술 플랫폼을 공유한다. J2EE(Java 2 Platform, Enterprise Edition)나 .NET과 같은 기술 플랫폼이 이에 해당한다. 물론 SAP 처럼 독자적인 기술 플랫폼을 보유하고 있는 업체도 있고, PeopleSoft 처럼 J2EE와 같은 표준 기술 플랫폼을 차용한 업체도 있을 것이다. 광의로 해석하면 운영 체제나 하드웨어까지도 이에 포함된다.

두 번째는 기술 프레임워크이다. 기술 프레임워크는 기술 플랫폼에 특화된 개발 표준으로 이해하면 된다. 물론 SAP 처럼 독자적인 기술 플랫폼을 지닌 업체에게는 기술 플랫폼과 기술 프레임워크의 구분이 불필요할 수 있다. 그러나 외부 표준 기술 플랫폼을 차용한 경우에는 이를 자신들에게 적합한 방식으로 가공한 기술 프레임워크가 있을 것이다. 예를 들어 Struts는 오픈 소스 진영의 J2EE에 대한 개발 표준(기술 프레임워크)이 된다.

세번째는 비즈니스 프레임워크이다. 애플리케이션의 유형과 독립적으로 존재 가능한 비즈니스 대상 혹은 프로세스의 설계 및 구현이 이에 해당한다. 예를 들면 화폐, 주문, 제품, 고객, 공급사, 직원, 결제 등이 이에 해당된다. 자세한 항목은 다음을 참조한다. (ftp://ftp.software.ibm.com/software/websphere/awdtools/businesscomponents/bcgtm.pdf) 이런 비즈니스적인 공통 요소에 대한 개발 표준을 BAFC로 이해하자.

수평적 통합에 기반한 솔루션 포트폴리오를 가지고 있는 업체들은 경쟁력 향상을 위해서 이 공통적인 요소들을 중복없이 공통적으로 관리하는데 관심을 갖게 된다. 이를 Product Line이라고 지칭할 수 있을 것이다.


비즈니스 애플리케이션 프레임워크 & 컴포넌트

현 시점에서 기술 플랫폼과 기술 프레임워크에 대한 성숙도는 상대적으로 높은 편이며 이제 관심의 초점은 BAFC로 넘어가고 있다. 이는 기술 플랫폼부터 애플리케이션까지 수직접 통합을 시도하는 IBM, MS, Oracle 등의 업체와 비즈니스 애플리케이션 개발 및 컨설팅에 집중하는 SAP, PeopleSoft, Siebel, webMethods 등의 업체들이 주도하고 있다.

(1) Microsoft Business Framework(이하 MBF)

MS 는 ERP, CRM 등의 제품 개발을 위한 Project Green(http://www.informationweek.com/story /showArticle.jhtml?articleID=15200123)을 진행하고 있다. MS가 이미 다양한 비즈니스 애플리케이션(http://www.microsoft.com/BusinessSolutions)을 보유하고 있기는 하지만 대부분이 M&A를 통해서 확보한 관계로 애플리케이션 사이에는 기술 플랫폼과 기술 프레임워크에서의 이질성이 존재한다. 이 이질성을 해소하기 위한 작업이 Project Green이다.

Project Green은 기술 플랫폼은 .NET, 기술 프레임워크는 Enterprise Library에 기반하고 있다. 그리고 동시에 애플리케이션 사이에서 공통적인 비즈니스 요소들을 MBF(http://www.gotdotnet.com/team/PDC/4121/DAT340.ppt)로 개발하고 있다. 따라서 Project Green을 통해서 개발될 애플리케이션은 MBF를 사용하여 구현될 것이다.

그러나 MBF는 WinFS나 Longhorn 등의 출시와 맞물리면서 그 진척이 주춤하고 있는 상태이다.(http://www.infoworld.com/article/04/09/01/HMlonghornmbf_1.html)

(2) IBM Business Components for WebSphere™ Application Server(이하 BC)

IBM은 ERP나 CRM 등의 솔루션을 직접 제공하고 있지는 않으며, 기술 플랫폼과 기술 프레임워크, 비즈니스 프레임워크 등을 제공한다.

기술 플랫폼은 J2EE(WebSphere), 기술 프레임워크는 Struts이다. 그리고 BC는 SanFrancisco 프로젝트와 연결되어 있다.

기 본적으로 Entity Bean을 포함한 EJB(Enterprise JavaBeans)를 중심으로 설계/개발되어 있는 BC는 비즈니스 영역에 구애받지 않고 공통적으로 사용할 수 있는 컴포넌트와 특정 영역에서만 사용 가능한 컴포넌트로 구분되어 있다. 전자는 Cross Domain Component(CDC)라고 하며 화폐, 달력, 계정, 고객, 파트너 등이 포함된다. 후자는 Business Domain Component(BDC)라고 하며 현재는 일반 회계, 주문 관리(Order Management), 창고 관리(Warehouse Management) 등의 영역에 해당하는 컴포넌트를 제공한다. 자세한 컴포넌트 목록은 다음을 참조한다.(ftp://ftp.software.ibm.com/software/websphere/awdtools /businesscomponents/basecomponentoverview.pdf)

(3) Oracle Application Development Framework(이하 ADF)

Oracle 의 ADF는 기술 프레임워크를 중심으로 비즈니스 프레임워크가 포함되어 있다. 그런데 ADF는 BC 혹은 MBF와는 상이하다. ADF는 라이브러리 혹은 컴포넌트 형태의 비즈니스 컴포넌트를 제공하는 것이 아니라 신속한 비즈니스 컴포넌트(BC4J)의 개발을 돕는 마법사 도구를 제공한다.


그 외에도 webMethods Composite Application Framework, SAP Composite Application Framework 등의 BAFC가 있다.


비즈니스 애플리케이션 프레임워크 & 컴포넌트의 특징

BAFC 는 일정한 Best Practices 및 디자인 패턴에 기반하여 설계되어 있다. 실질적으로 BAFC가 제공하는 재사용 가능한 컴포넌트 못지 않게 견고한 설계 기법 등이 더 중요한 역할을 할 수 있다. SanFrancisco 디자인 패턴이 대표적인 예이다.

Oracle의 JDeveloper, MS의 Visual Studio.NET 등 BAFC는 IDE(+ 모델링) 도구와 밀접하게 통합되어 있으며 일정 부분은 MDA(Model-Driven Architecture)를 지향하고 있다.

BAFC 는 다양한 트랜드와 연결되어 있다. SOA(Service Oriented Architecture), 웹 서비스, BPM(Business Process Management), BPEL(Business Process Execution Language), 포탈 등이 이에 해당한다.


시사점

성질 급한 A라는 고객을 가정하자. 어느날 A가 통상적으로는 6개월이 걸리는 B라는 애플리케이션을 4개월 안에 개발해 줄 것을 요청한다. 혹은 2개월일 수도 있다. 물론 A가 합리적이라면 그 댓가는 만족할 만한 수준일 것이다. 이는 A의 성질로 인한 것이 아니라 A가 속해있는 시장의 상황과 그 시장에서 경쟁적 우위를 확보하기 위한 불가피한 선택으로 받아들여야 한다.

우리는 A의 요구 사항을 총족 시킬 수 있는 역량을 갖추고 있는가? 혹은 그 역량을 확보하기 위해서는 어떤 부분에 투자하여야 하는가? 아마도 BAFC가 여러 많은 안 중의 하나임에는 분명해 보인다.

여기서 BAFC가 가치가 있는가에 대해서 논의하는 것은 무의미해보인다. 앞으로의 논의는 어떻게 BAFC를 우리의 것으로 만들 수 있는가가 초점이 되어야 한다.

How? Buy or Build?

2004-10-04

반복적(Iterative) 개발

무엇을 반복하는가?

광의로 반복적 개발이란 무엇인가를 반복하면서 시스템을 개발하는 걸 의미한다. 이렇게 넓은 의미에서 본다면 단순히 코딩/단위 테스트가 반복되는 개발도 반복적이다. 그래서 반복적 개발이 가치를 지니려면 반복의 대상이 되는 활동의 폭 혹은 수에 대한 협의의 의미 부여가 필요하다.

논의의 단순화를 위해 시스템 개발이 요구수항 수집, 요구사항 분석, 설계, 구현(단위 테스트를 포함한), 테스트, 배치 등의 활동으로 구성된다고 가정하자.

앞 에서 예로 든 반복은 구현이라는 단위 활동 내에서 이루어질 뿐이다. 반복적 개발이 가치가 있으려면 하나의 활동 내에서가 아닌 여려 활동들이 결합하여 반복되어야 한다. 이 때 활동들의 결합은 근접한 것(설계와 구현, 요구사항 수집과 요구사항 분석 등) 사이에서 이루어지는 것이 통상적이다.

따라서 반복적 개발이란 요구사항 수집, 요구사항 분석, 설계, 구현, 테스트, 배치 등의 활동이 둘 이상으로 결합되어 2회 이상 반복되는 형태를 지칭한다.


왜 반복하는가?

성공적인 시스템 구축을 위해서 반복한다. 자세한 설명은 Iterative Development(http://www.objectmentor.com/writeUps/IterativeDevelopment)를 참조한다.


반복의 강도

앞 에서의 정의를 빌려서 우리는 어떤 프로젝트가 반복적인 개발을 수행하고 있는지 아닌지를 판단할 수 있다. 그 다음으로는 반복의 강도를 계산해야 한다. 간단하게 반복의 강도는 결합되어 반복되는 개발 활동들의 수와 반복의 빈도를 통해서 파악한다.

반복의 강도 = 결합된 활동 수 X 반복의 빈도

[TODO] 반복의 강도와 프로세스 효율성의 상관 관계


반복하여 무엇을 개발하는가?

우리가 개발하는 시스템이 A, B, C 등의 서브시스템으로 분리되어 있다고 가정하자. 그리고 각각의 서브시스템(A)은 여러 기능(A1, A2, A3) 등으로 다시 분리된다고 보자.

이런 조건에서 무엇을 반복하여 개발하는가에 대한 질문에는 두개의 답이 있을 수 있다. 일단 반복 주기가 X, Y, Z 등의 3 주기로 구성된다고 가정하자.

첫번째는 (X-A), (Y-B), (Z-C) 등의 방식으로 개발하는 것이고, 두번째는 (X-A1, B1, C1), (Y-A2, B2, C2), (Z-A3, B3, C3) 등의 방식으로 개발하는 것이다.

모 든 서브시스템이 중요성, 복잡성 측면에서 동일하다면 어느 방식이든 문제가 없다. 단 이런 상황은 예외일 것이다. 따라서 중요하고 복잡한 서브시스템에 집중할 수 있어야 한다. 그리고 경우에 따라서는 프로젝트 중간에 특정 서브시스템을 개발 범위에서 함몰 비용을 최소화하면서 제외(포기)할 수도 있어야 한다. 결국 학습 효과를 충분히 발휘하는데에도 적합한 첫번째 방식이 바람직하다.

따라서 첫번째 개발 주기(X)에서 A, B, C 중 중요한 서브시스템을 먼저 개발한다. 중요한 것은 서브시스템이 사용자에게 제공하는 가치와 그것의 구현 위험도를 고려하여 결정하면 된다.

여기서 각 서브시스템의 중요도가 A, B, C 순이라고 가정하자. 그런데 기능 수준에서는 B의 기능 중 하나(B1)가 A의 기능 중 하나(A1)보다 중요도가 높다면 어떻게 무엇을 개발할 것인가?

이 때는 첫번째와 두번째 방식을 혼용해서 A2, A3, B1의 기능을 첫번째 반복 주기(X)에서 개발할 수도 있을 것이다.

[TODO] 첫번째 방식을 사용하여 효과를 극대화하려면 정교하게 고안된 인력 운영 기법을 갖추고 있어야 한다.


개발 속도(Velocity)

프로젝트 팀이나 개별 팀원의 개발 속도는 프로젝트 관리에 중요한 정보이다. 초기에는 개략적으로 개발 속도를 예측하고 반복을 진행하면서 그 속도를 실제적인 것으로 구체화해야 한다. 개발 속도의 단위는 반복 주기 단위로 한다.

개발 속도 = 하나의 반복 주기에 완료한 기능의 포인트

기능의 규모와 복잡성을 객관화하는 수단이 있어야 한다. 일단은 이를 추상화하여 기능의 단위라고 지칭한다. 실질적으로는 Function Point 등을 이용할 수 있을 것이다.


반복적 개발에 따른 이슈

(1) 고객의 참여

반복적 개발에는 (특히 요구사항 분석 활동이 반복에 포함된다면) 고객의 참여가 중요하다. 고객이 반복의 시작과 종료 시에 병목점이 될 여지가 높기 때문에 이를 고객의 적극적 참여를 통해서 해결해야 한다.

[TODO] 이번 반복에서 3개의 기능(A1, A2, A3)을 개발해야 한다. 그리고 이들 기능은 독립적인 서브팀(X, Y, Z)에 할당되었다. 각각의 기능에 대해서 요구사항을 내고 만들어진 기능에 대한 검증을 하는 고객이 독립적으로 존재한다면 갈등의 소지는 없다. 그런데 1명의 고객이 3개의 기능에 대해서 모두 총괄한다면 어떻게 할 것인가? 개발 팀의 대기 시간이 길어지는 명목 현상을 어떻게 해소할 것인가? 이전 반복에서 발생한 문제의 해결이나 미진한 기능의 추가 개발과 요구사항 분석 단계를 병행해서 대기 시간을 줄일 수 있을까? 혹은 각 서브팀별로 반복의 시작과 종료를 달리해서 대기 시간을 줄일 수 있을까?


(2) 짧은 반복 주기

반복에 요구사항 분석, 설계, 구현, 테스트 등의 활동이 포함된다고 가정한다. 반복주기는 최소 1주에서 최대 8주 이내에서 선택한다. 그리고 각 반복의 기간은 동일해야 한다. 그래야지만 평가 혹은 비교 기준으로 삼을 수 있다.

6 개월 이내의 프로젝트는 2 주 단위로 반복을 가져간다. 첫번째 1 개월과 마지막 1 개월은 요구사항 수집과 배치(인수 테스트 포함) 활동을 위해 사용한다고 하면 최대 8 차례의 반복이 가능하다.

12 개월 이내의 프로젝트는 4 주 단위로 반복을 가져간다. 첫번째 2 개월과 마지막 2 개월은 요구사항 수집과 배치(인수 테스트 포함) 활동을 위해 사용한다고 하면 역시 최대 8 차례의 반복의 가능하다.

대 략 XP(eXtreme Programming)는 1주 혹은 2주, Scrum은 4주(30일), RUP는 8주 이상의 반복 주기를 갖는다. 물론 Scrum을 제외하고 XP 혹은 RUP가 이를 공식화한 것은 아니다. 한 프로젝트에서 3 차례 이상의 반복이 가능하다면 반복 주기의 크기는 부차적이다. 반복 주기는 (고객에게) 의미 있는 가치를 제공하는 개발 팀의 속도를 고려해서 결정하면 충분할 것이다.


(3) Time-Box 준수

계획된 혹은 합의된 반복의 시작일과 종료일은 항상 준수한다.

정 해진 반복 주기 내에서 완료하기로 한 기능을 개발하지 못하는 상황이 왔을 때 개발 주기의 완료일을 연장하면 전체 반복 주기의 흐름이 깨진다. 개발 대상을 축소하더라도 개발 주기를 지키는 것이 현명하다. 기간의 연장은 이번 반복에서 (우리가) 실패했다는 사실을 은폐하는 도구로 사용될 가능성이 높으며, 이는 반성할 기회의 상실을 의미할 수 있다. 프로젝트 팀의 도덕성 유지를 위해서 Time-Box는 항상 준수한다.

[TODO] 앞의 서술에서 반복 주기를 서브시스템과 기능을 가지고 결정하는 듯한 입장을 명확하게 할 필요가 있다. 엄밀하게는 서브시스템과 기능을 가지고 Time-Box를 설계하는 것이 아니라 그 합의된 Time-Box에 서브시스템과 기능을 끼어 넣어야 한다. 닭이 먼저냐 달걀이 먼저냐의 문제로 비추어지기도 하겠지만 이는 반복적 개발에 대한 근본적인 문제이다.


(4) 반성과 학습

반복은 Time-Box 시간의 경과로 종료되지 않는다. 몇가지 질문들에 대한 대답과 다음 반복을 위한 준비 혹은 사색이 반복의 종료의 절대 기준이다.

이 번 반복에서 우리는 무엇을 했는가? 반복의 시작에 설정한 목표들을 총족시켰는가? 충족하지 못했다면 그 이유는? 그 이유에 대한 해결 방안은 있는가? 충족했다면 그 이유는? 일하는 방식은 적절했는가? 더 나은 방식이 있는가? 버려야(포기해야) 하는 것과 강화해야 하는 것은?

반복의 종료는 이렇게 간단한 다과와 함께 전체 프로젝트 팀원들이 참여한 미팅으로 종료되어야 한다.

[TODO] Scrum은 매일 아침 30분 이내의 회의를 갖는다. 이런 형태의 회의를 갖는 것이 바람직한가? 개발 주기가 짧다면 아침의 회의가 요식 행위가 되거나 반복 종료 미팅과 중복되지 않을까? 일일보고는?

[TODO] 대부분의 프로젝트에는 주간회의와 월간회의가 존재하는데 만일 반복 개발을 한다면 이를 Time-Box와 동기화 시켜야 한다.


(5) 기능 간의 의존성 관리

중 요한 기능을 먼저 개발한다라는 기준의 준수를 어렵게 하는 것이 기능 간의 의존성이다. 가령 중요도가 가장 높은 A1 기능은 중요도가 낮은 B1 기능에 의존하고 있다. 이런 상황에서 A1 보다는 B1을 먼저 개발해야 하는가? 이렇게 하면 가장 중요한 기능의 개발이 가장 뒤로 밀릴 것이다. 이를 극복하기 위해서 우리는 Mock 기법을 사용한다. 즉 B1 기능을 거짓으로 구현하는 것이다. 이 때는 B1 기능들의 인터페이스도 최소한으로 설계한다.


(6) 재사용

프로젝트가 시작한 후 얼마나 빠른 시간 내에 반복에 들어 갈 수 있는가? 이에 대한 대답이 프로젝트 팀의 역량에 대한 단적인 표상이 된다. 모든 것을 백지에서 시작한다면 반복에 들어가는 시간이 뒤로 밀려질 것이며 이는 최종적으로 반복 개발 자체를 불가능하게 한다.

반복은 프로젝트 팀이 일정 수준 이상의 역량을 확보하고 있을 때 가능하다. 반복적 개발이 역량이 낮은 팀의 생산성(시스템의 품질을 포함한)을 어느 수준 이상으로 높여 주지는 않는다.

예를 들어, 참조 아키텍처(Reference Architecture), 프로덕트 라인(Product Line), 애플리케이션 프레임워크, 컴포넌트, 개발 표준 등을 재사용할 수 있을 때 반복적 개발이 가능할 것이다.


참고자료

The Unified Software Development Process
반복적 개발은 프로젝트 위험에 대처하기 위한 것이라는 점을 잘 설명해준다.

Iterative Development
http://www.objectmentor.com/writeUps/IterativeDevelopment
왜 반복적 개발을 해야 하는가에 대한 짧은 대답.

Iterative and Incremental Development: A Brief History
http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf
반복적 개발에 대한 역사를 간략하게 짚어준다.

A spiral model of software development and enhancement
http://www.sce.carleton.ca/faculty/ajila/4106-5006/Spiral%20Model%20Boehm.pdf
고전...

2004-09-30

[책] Code Complete

Code Complete, 2nd (Steve McConnell)
 

좋은 책. 하지만 너무 늦게 접했다는 아쉬움을 갖게하는 책. 처음 프로그래밍을 시작하고 1년이 지난 후에 읽었다면 그 동안의 시행 착오를 많이 줄일 수 있었을텐데 하고...

1st를 읽었는데 2nd도 나쁘지는 않겠지...

[책] 소프트웨어 아키텍처

아키텍트란 누구(혹은 무엇)이어야 하는가라는 질문에 대한 답을 찾고 있다면 아래의 글이 도움이 될겁니다.
 
Who Needs an Architect? (Martin Fowler)

 
소프트웨어 아키텍처에 대한 책
 
Software Architecture in Practice, 2nd (Len Bass, Paul Clements, Rick Kazman)
 
이 책은 CMU SEI 작업의 결과물로서 아키텍처를 바라보는(혹은 설계/분석하는) 다양한 접근 방식들을 비지니스적인 것에 초점을 두고 설명하고 있다.

 
Applied Software Architecture (Christine Hofmeister, Robert Nord, Dilip Soni)
 
SAP보다는 순수하게 아키텍처에 대해서 접근하고 있음. 개괄적인 이해만을 위해서 Chapter 1. Introduction과 Chapter 12. The Role of the Software Architect를 참조하면 될 듯 함.

자바 릴리즈 모델

자바 릴리즈 모델에 대한 글입니다.

Tigers and Mustangs and Dolphins, Oh My! (Mark Reinhold)

2004-09-27

Agile Software Development

Agile Software Development(이하 ASD)에 대한 소개로는 다음의 글을 참조한다.
 
Manifesto for Agile Software Development
 
The New Methodology (Martin Fowler)
 
 
ASD와 관련된 사이트는 아래와 같다.
 
Agile Alliance
 
 
ASD와 관련된 책은 아래와 같다.
 
Agile Software Development (Alistair Cockburn)
 
철학책...
 

Agile Software Development Ecosystems
(Jim Highsmith)
 
ASD를 이끄는 주요 사람들과의 인터뷰와 적용 사례를 담고 있고, 7개의 ASD에 대한 개괄적인 설명을 포함한다. ASD를 이해하기 위한 개론서로는 가장 좋을 듯...

 
Agile Project Management : Creating Innovative Products (Jim Highsmith)
 

Organizational Patterns of Agile Software Development (James O. Coplien, Neil B. Harrison)


Agile and Iterative Development: A Manager's Guide (Craig Larman)
 
 
ASD와 관련된 컨퍼런스로는 아래와 같다.
 
The Agile Development Conference
 
XP 200X
 
XP Agile Universe

2004-09-22

[책] 디자인 패턴

1. 책
 
 
읽을 여유 없음...
 
 
읽을 여유 없음...
 
Design Patterns(GoF)를 읽고 나서 Chapter 2. Designing with Patterns를 읽으면 디자인 패턴에 대한 이해를 한층 높일 수 있을 듯.


Pattern-Oriented Software Architecture, Volume 1 (Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad, Michael Stal)
http://www.amazon.com/exec/obidos/tg/detail/-/0471958697/ref=pd_bxgy_text_1/102-2278079-3987351?v=glance&s=books&st=*


Pattern-Oriented Software Architecture, Volume 2 (Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann)
http://www.amazon.com/exec/obidos/tg/detail/-/0471606952/ref=pd_bxgy_text_1/102-2278079-3987351?v=glance&s=books&st=*
 
 
 
 

2004-05-28

J2EE 프로젝트 좋은 습관

J2EE(Java 2 Platform, Enterprise Edition)는 웹 애플리케이션 개발을 위한 표준 기술 플랫폼이다. 이 글은 J2EE에 기반한 프로젝트가 성공하는데 필요한 것들을 좋은 습관(Best Practice)으로 정리하는 것을 목표로 한다. J2EE 관련 좋은 습관에 대한 기존의 논의들이 주로 프로그래밍에 초점을 맞추어 왔던데 비해서 이 글에서는 전체 프로젝트 개발 주기를 중심으로 좋은 습관을 정리하였다.


1. 서론

소프트웨어 애플리케이션 개발은 방법론(Methodology)과 기술(Technology)과 사람(People)의 상호 작용을 매개로 진행된다. 따라서 프로젝트 개발 조직이 애플리케이션 개발을 통해서 고객에게 가치를 전달하려면 위의 3가지와 그 관계에 대한 충분한 고려가 선행되어야 한다.

J2EE(Java 2 Platform, Enterprise Edition) 기반 프로젝트라면 어떤 요소들을 고려해야 하는가? 이 글은 이 질문에 대한 바람직한 해답을 찾기 위한 시도의 일부이다.

아래에서 소프트웨어 개발 방법론 각 단계에서 J2EE 기반 프로젝트를 성공으로 이끌 요소들을 좋은 습관(Best Practice)으로 정리하였다. 그런데 명심해야 하는 것은 아래의 좋은 습관이 현업에서 개발하고 있는 애플리케이션의 품질 혹은 프로젝트 생산성을 실제로 향상시킬 수 있는가는 프로젝트 팀원들이 스스로 판단해야 한다는 점이다.


2. 공통

소프트웨어 개발 모든 단계에 공통적으로 적용할 수 있는 좋은 습관들은 아래와 같다. 주로 프로젝트와 그 산출물에 대한 관리와 프로젝트 팀원들간의 커뮤니케이션 수단과 관련된 내용들이다.


좋은 습관 1. 프로젝트의 모든 활동이 1 주 혹은 2 주 안에 완료될 수 있도록 계획하고 체크한다.

모든 프로젝트가 관리되어야 한다는데 이견이 있을 순 없다. 그렇다면 어떻게 하면 프로젝트를 손쉽게 관리할 수 있는가? 우선은 관리해야 하는 대상을 축소하는 것이 방법일 수 있다. 관리를 위한 관리 혹은 가치 창출에 대한 기여가 적은 활동 혹은 대상들에 대한 관리를 제거해야 한다. 그리고 프로젝트의 긴장도를 높여서 관리를 용이하게 만들 수 있다. 긴장도를 높인다는 것은 프로젝트 팀원의 자율적인 관리를 가능하게 함을 의미한다. 프로젝트 팀원들이 수행하는 업무의 기간을 1 주 혹은 2 주 안으로 조정하게 되면 프로젝트의 긴장도가 높아지며 이는 자율적인 관리 기능이 동작할 가능성을 높여줄 것이다. 이는 전체 프로젝트 관리의 초점을 과정이 아닌 각 활동의 결과로 자연히 이동시킨다.


좋은 습관 2. 대면(Face-to-Face) 방식의 커뮤니케이션을 중시하고 모든 이슈에 대해서 즉각적인 피드백이 가능하도록 한다.

전화, 메일, 메신저 등의 커뮤니케이션 수단은 대면 방식의 커뮤니케이션에 대한 보조로서만 의미가 있다. 프로젝트 팀원들의 자리 배치는 대면 방식의 커뮤니케이션을 활성화시키는 방안을 최대한 고려하여 설계한다. 그리고 모든 대면 방식의 커뮤니케이션이 성공적으로 수행되도록 하기 위해서는 이에 대한 피드백이 즉각적으로 제공되는 분위기를 조성해야 한다.


좋은 습관 3. 필요한 산출물은 만들고 불필요한 산출물은 만들지 않는다.

프로젝트의 산출물은 이후의 개발을 위한 것과 운영을 위한 것과 감리를 위한 것 안에 포함되는 경우에만 필요한 것이다. 이에 해당되지 않는다면 일체 불필요한 산출물이다. 그리고 가장 이상적인 것은 감리를 위한 산출물이 개발과 운영을 위한 산출물과 동일한 것이다.

특히 이후 개발을 위한 산출물이 이후 개발이 완료된 후에 작성되는 모순적 상황이 습관적으로 발생한다면 이 산출물이 실제로 필요한 산출물인지에 대해서 검증한다.


좋은 습관 4. 프로그램 소스 코드를 포함한 모든 산출물에 대해서 형상관리를 수행하고, 이를 웹을 통해서 접근할 수 있도록 한다.

형상 관리 도구를 사용해야 한다라는 당위적 주장보다는 형상 관리 도구를 사용했을 때 어떤 장점들이 있는지를 프로젝트 팀원들에게 실습과 다양한 사례를 통해서 경험적으로 설득한다.


좋은 습관 5. 이슈, 리스크, 버그를 자동화하여 관리하고, 이를 웹을 통해서 접근할 수 있도록 한다.

중요한 이슈들이 프로젝트 팀원들의 개인적인 수첩 혹은 머리 속으로부터 꺼내서 프로젝트 팀원들이 모두 공유할 수 있도록 한다.


좋은 습관 6. 용어집(Glossary)을 작성하고, 이를 웹을 통해서 접근 할 수 있도록 한다.

용어 및 그 의미를 통일하고 프로젝트 팀원들이 그 용어를 정확하게 사용하게 한다.


3. 사전 조사

소프트웨어 개발 방법론에서 사전 조사는 기술적인 솔루션의 제안과 타당성 검토를 수행하는 단계이다. J2EE 명세서와 자바 웹 애플리케이션 서버(이하 WAS)를 검토/선택하는 작업이 주요한 활동이다.


좋은 습관 7. J2EE 명세서는 최신 버전이면서 동시에 성숙도가 높은 버전을 선택한다.

경험적인 관찰의 결과 새로운 J2EE 명세서가 발표되는 시점과 이를 구현한 WAS가 출시되는 시점 사이에는 5 개월 정도의 간극이 존재한다. 그리고 그 WAS가 안정화 되는데 5 개월 정도의 시간이 추가로 소요된다. 결국은 최신 버전의 J2EE 명세서와 그를 구현한 WAS 제품의 성숙도를 동시에 고려해서 J2EE 버전을 선택해야 한다. 또한 판단 기준 시점을 프로젝트의 시작으로 할지 프로젝트의 종료 시점으로 할지에 대해서도 의사 결정시 고려해야 한다. 가령 프로젝트의 기간이 긴 경우, 프로젝트 초기 단계에서는 성숙도가 낮던 WAS 제품이 프로젝트 종료 단계에서는 높은 성숙도를 보일 수 있다.

그러나 판단에 있어서 기술적인 부분에 대한 고려도 잊지 않아야 한다. XML 웹 서비스를 이용한 프로젝트의 경우에는 성숙도가 낮더라도 XML 웹 서비스를 공식적으로 지원하는 J2EE 1.4 버전을 선택하는 것이 현명할 것이다.


좋은 습관 8. 자바 WAS는 프로젝트 팀원들의 친밀도를 기준으로 선택한다.

J2EE 버전이 선택되면 그 버전을 구현한 WAS를 선택하면 된다. 선택에 있어서 일차적인 판단 기준은 당연히 프로젝트 예산과 성능과 관련한 고객의 요구사항이다. 이런 사항들을 고려하면 몇 개의 WAS 후보 군이 형성되는데 이 후보 군중에서 하나를 선택할 때의 판단 기준은 프로젝트 팀원들의 WAS에 대한 친밀도가 된다.

일반적인 고정 관념보다는 다양한 WAS 제품 간의 사용법이나 동작 방식의 차이가 크지 않은 것이 사실이나 그럼에도 불구하고 개발 단계 초기에는 WAS에 대한 친밀도가 영향을 미칠 수 있음으로 이를 간과하지 않는다.


좋은 습관 9. 애플리케이션 플랫폼(J2EE 버전, WAS 등)은 테스트 단계까지는 변경할 수 있어야 한다.

.NET이나 PHP와 같은 다른 애플리케이션 개발 플랫폼에 대해서 J2EE가 갖는 장점은 다양한 WAS 구현 제품 중에서 프로젝트에 가장 적합한 것을 선택해서 사용할 수 있다는 점이다. 이런 장점을 극대화하려면 프로젝트의 초기 단계에서 선택한 WAS 제품을 프로젝트 진행 과정에서 추가로 혹은 신규로 도출된 요구사항이나 문제점 등을 고려하여 프로젝트의 마지막 단계에서도 다른 WAS 제품으로 용이하게 바꿀 수 있어야 한다.

이는 운영 단계에서도 고스란히 적용된다. 예를 들어, 사용자의 규모가 작았던 초기 운영 단계에서는 아파치 톰켓을 사용해서 서비스하다가 사용자의 규모가  감당하기 힘든 정도로 커진 경우에 WAS 만을 고성능의 제품으로 바꾸어서 사용자의 증가라는 문제를 일차적으로 해결할 수 있어야 한다.


좋은 습관 10. 자바 IDE는 항상 사용한다.

프로그래밍 생산성을 높이기 위해서 항상 자바 IDE(Integrated Development Environment)를 사용한다. IDE는 개발에 필요한 모든 도구들을 하나로 통한한 것으로 개발자가 여러 도구를 함께 사용하고 학습하는데 따른 불편함을 해소하기 위해서 사용한다. 그리고 제품 선정 시 프로젝트 팀원들이 자바 IDE 사용을 빠르게 학습할 수 있도록 숙련된 교육자 확보가 용이한 제품을 선택하는 것도 바람직한 일이다.

프로젝트 예산에 제한이 있어서 고가의 상용 IDE를 구매하기 매우 어려운 경우에는 EclipseNetBeans와 같은 오픈 소스 IDE 제품을 사용할 것을 적극 권장한다.


좋은 습관 11. 검증된 오픈 소스 솔루션을 적극적으로 사용한다.

자바에는 운영 환경에서 사용할 수 있는 다양한 오픈 소스 솔루션이 존재한다. 비용 절감을 위해 이런 오픈 소스 솔루션에 대한 사용을 권장한다. 아파치, SourceForge, java.net 등의 사이트를 참조한다.


4. 요구사항 분석

소프트웨어 개발 방법론에서 요구사항 분석은 시스템과 관련된 고객의 요구사항 도출 및 정의를 통해서 프로젝트 팀이 수행해야 할 프로젝트 범위(고객에게 인도할 소프트웨어 제품의 범위 및 특성)를 명확하게 파악하고 합의하는 단계이다.


좋은 습관 12. 요구사항은 변경 내용을 포함하여 항상 문서화하고 고객의 승인을 득한다.

소프트웨어 개발 방법론에서 요구사항 문서에는 요구사항 정의서, 요구사항 명세서, 유스 케이스 명세서 등이 있다. 이런 문서화된 요구사항이 없다면 개발하지 않는다. 그리고 변경된 요구사항이 기존의 요구사항 문서에 반영되어 있지 않으면 변경하지 않는다. 결국 요구사항 문서가 없다는 것은 요구사항이 없다는 것이다.

그리고 가능하다면 작성된(혹은 변경된) 요구사항 문서에 대해서 고객의 승인을 받는다.


좋은 습관 13. 비기능적 요구사항(성능, 변경 가능성, 사용 편리성 등)을 경시하지 않는다.

프로젝트의 모든 팀원들이 비기능적인 요구사항에 대해서 관심을 가질 필요는 없다. 그러나 최소한 1 명은 비기능적 요구사항에 대해서 관심을 가지고 있어야 한다. 그리고 바로 그것이 아키텍트의 책임이다.


좋은 습관 14. 각각의 요구사항을 개발하는데 필요한 자원을 예측하고 기록한다.

프로젝트 팀원들의 개발 생산성을 정확하게 측정하고 있으면 프로젝트 관리가 수월하게 된다. 요구사항을 구현하는데 필요한 자원의 예측 내용과 실제 결과의 차이를 분석하여 다양한 정보를 획득할 수 있다. 이런 정보들은 프로젝트의 성공에 긍정적인 영향을 미칠 것이다.


좋은 습관 15. 요구사항 산출물을 토대로 다른 프로젝트로부터 재사용 가능한 컴포넌트 목록을 확보한다.

요구사항에 대한 분석이 완료되면 개략적으로 다른 프로젝트에서 개발한 컴포넌트나 외부에서 소싱할 수 있는 컴포넌트 중 재사용 할 수 있는 것들의 목록을 작성한다. 이런 컴포넌트들을 인지하고 다음 단계인 설계를 진행하면 그렇지 않을 때보다 재사용률을 높일 수 있다.


5. 기능 설계와 테크니컬 설계

소프트웨어 개발 방법론에서 설계는 기능 설계와 테크니컬 설계 단계로 구성된다. 기능 설계는 고객의 요구사항이 어떻게 충족될 것인지를 충분한 구성과 세부 사항을 제시하여 보여주고, 요구사항을 시스템화하는 단계이다. 그리고 테크니컬 설계는 사용자 관점의 기능 설계 명세를 기술적인 관점의 테크니컬 설계 명세로 변환 하는 단계이다.


좋은 습관 16. 프레임워크를 기반으로 설계한다.

MVC(Model View Controller) 디자인 패턴과 Dependency Injection 디자인 패턴 등에 기반하여 만들어진 다양한 프레임워크를 사용하면 애플리케이션 아키텍처를 설계하는데 소요되는 시간 및 비용을 최소화할 수 있다. 또한 프레임워크가 제공하는 다양한 컴포넌트 및 서비스의 사용을 가정하고 설계를 함으로써 설계 혹은 개발해야 하는 부분을 대폭 감소시킬 수 있다. 따라서 프레임워크를 사용하여 프로젝트를 진행하기를 추천한다.


좋은 습관 17. ORM Persistence 프레임워크를 사용하여 설계한다.

ORM(Object-Relational Mapping)은 Persistence를 구현하는 도구 중의 하나이다. ORM 방식은 JDBC(Java Database Connectivity) API를 직접 이용하는 것보다는 성능이 저하된다는 단점을 지니지만, 개발 생산성을 높여주고, 유연한 도메인 모델 방식의 개발을 가능하게 한다는 장점을 지닌다. 단 선택 전에 ORM 도구의 도입으로 인한 비용 증가와 도구에 대한 학습 비용을 충분하게 고려해야 한다.

자바 진영의 JDO(Java Data Object)가 표준이며, 그 이외에도 Hibernate, iBATIS 등의 오픈 소스 솔루션과 오라클 TopLink 등의 상용 솔루션이 있다.


좋은 습관 18. 메뉴 및 화면은 Composite View 디자인 패턴에 기반해서 설계한다.

사용자가 브라우저를 통해서 보는 전체 화면은 여려 개의 (개념적) 구성 화면으로 이루어 진다. 이것을 하나의 프로그램(통상 JSP)으로 개발하는 것은 바람직하지 않다. 그래서 이를 독립적인 작은 프로그램으로 개발하고 이를 결합하는 방식을 취해야 한다. 이는 두 가지 방식으로 구현된다. 하나는 HTML의 템플릿 혹은 아이프레임을 사용하는 방식이다. 두 번째는 Composite View 디자인 패턴을 이용하는 방식이 있다. 후자가 전자에 비해서 유연하고 사용자 편리성을 높이는 장점을 지닌다.

이를 구현한 솔루션으로 타일SiteMesh 등이 있다.


좋은 습관 19. 권한 처리는 J2EE 명세서 및 WAS가 지원하는 모델을 우선으로 고려하여 설계한다.

J2EE 명세서는 웹 애플리케이션과 EJB에 대한 (선언 방식의) 권한 처리 서비스를 제공한다. 물론 이 기능으로 권한과 관련한 모든 요구사항을 충족할 수는 없지만 주요한 기능에 대한 해결은 가능하다. 따라서 이 기능을 충분히 사용하는 것이 바람직하며 이를 위해서 설계 시에 이를 충분히 반영한다.


좋은 습관 20. 타 시스템과의 인터페이스는 컴포넌트로 설계한다.

타 시스템과의 인터페이스를 처리하는 프로그램은 컴포넌트로 설계한다. 컴포넌트로 설계하면 Mock 방식의 테스트가 가능하며, 다른 프로젝트에서 재사용될 가능성도 높일 수 있다.


좋은 습관 21. 다른 프로젝트에서 재사용 가능한 컴포넌트를 추출하여 Extension Point를 함께 설계한다.

컴포넌트가 다른 프로젝트에서 재사용될 수 있으려면 부가적인 노력이 필요하다. 일체의 수정 없이 컴포넌트가 재사용될 확률이 낮다는 것을 고려하여 변경이 필요한 부분을 Extension Point로 설계하여 제공한다.


좋은 습관 22. 에러 코드 및 메시지를 정의한다.

시스템 혹은 업무 로직과 관련된 모든 에러를 에러 코드로 표상하여 통합 관리한다. 에러 코드는 문자열(혹은 숫자열)로 표시하거나 예외 클래스 타입으로 표현할 수 있다. 그리고 동시에 각각의 에러 코드를 설명하는 메시지에 대한 관리도 되어야 한다.


좋은 습관 23. 모든 코드 관련 기능을 하나로 통합하여 설계한다.

통상의 애플리케이션은 다양하게 많은 코드 성 데이터를 사용한다. 데이터 자체만으로 코드 성인지 아닌지를 분별할 수는 없다. 코드 성 데이터는 데이터의 수와 변경 경향으로 판단할 수 있다. 일반적으로 레코드의 수가 300개 미만이면서 변경 및 추가 등의 빈도가 낮은 데이터들이 코드 성 데이터에 포함된다. 이런 코드 성 데이터를 통합해서 관리하는 것이 효과적이다. 코드 데이터의 캐싱 및 UI에서의 표현 등의 기능을 통합해서 가져가야 한다.


6. 개발

소프트웨어 개발 방법론에서 개발은 테크니컬 설계 내용을 프로그램과 데이터로 변화하는 단계이다.


좋은 습관 24. 1 주 안에 개발을 완료할 수 있는 단위로 진행한다.

프로젝트에서 개발 단계가 차지하는 기간이 가장 길다. 이로 인해 개발 단계에서 긴장감을 유지하고 성취감을 장려하는 일은 쉽지 않다. 전체 개발 단계를 1주 단위로 나누어서 개발자가 자신이 개발한 모듈에 대한 결과물을 빨리 확인할 수 있도록 관리하면 이 문제를 어느 정도 해결할 수 있다.


좋은 습관 25. WAS가 아닌 J2EE 명세서에 맞추어서 개발한다.

특정 WAS만이 제공하는 라이브러리는 되도록 사용하지 않는다. 프로그래밍은 J2EE API와 J2EE의 명세서에만 의존해야 한다. 다음 문서를 참조한다. Build to Spec!(Liz Blair)


좋은 습관 26. WAS가 제공하는 기능 및 서비스를 충분히 활용하면서 개발한다.

WAS는 데이터소스를 비롯해서 다양한 서비스를 제공한다. 이 서비스들은 J2EE 명세서에서 지정한 표준과 그렇지 않은 것으로 구분된다. WAS가 제공하는 기능을 만들지 않는다. 그리고 특별한 장점이 없다면 WAS가 제공하는 기능을 다른 솔루션으로 대체하지 않는다.


좋은 습관 27. WAS의 클래스 로딩 구조를 파악한다.

클래스와 자바 라이브러리의 위치에 따라서 애플리케이션이 다르게 동작할 수 있다. 이런 구조에 대해서 올바르게 파악하고 있어야 문제가 발생하는 것을 미연에 방지할 수 있다. 그리고 이 구조는 WAS 마다 상이하다. 가령 아파치 톰켓의 클래스 로딩 구조는 다음에서 확인할 수 있다.


좋은 습관 28. 하루에 2번 이상 개발 중인 애플리케이션을 자동 빌드한다.

프로젝트 진척도 평가의 대상은 통합 서버를 대상으로 한다. 형상 관리 도구에서 매일 2번 이상 애플리케이션을 빌드해서 통합 서버에 배치하고 관리자는 이 내용을 대상으로 진척도 관리를 한다. 개별 개발자의 컴퓨터 혹은 머리 속에 있는 것은 관리 대상이 아니다.


좋은 습관 29. 정기적인 코드 리뷰를 통해서 개발 표준의 준수 여부를 확인하고 획득한 지식을 프로젝트 팀원들간에 공유한다.

개발 표준이 준수되고 있는가? 준수 여부를 어떻게 효율적으로 체크할 수 있는가? 첫 번째는 Code Inspection 도구를 사용해서 개발 표준 준수 여부를 파악할 수 있다. JetBrains의 IntelliJ IDEA IDE에서 제공되고 있는 다양한 Code Inspection의 기능들은 다음과 같다. 그리고 CheckStyle과 같은 도구는 코딩 표준이 지정하고 이를 체크할 수 있도록 해준다. 그러나 이 방식으로는 추상화의 정도가 높은 디자인 수준의 분석을 수행할 수는 없다. 이를 해결하기 위해서 주기적인 코드 리뷰를 수행한다. 그런데 코드 리뷰의 초기단계에서는 주로 개발 표준의 준수 여부에 초점을 두더라도 이후에는 좀 더 바람직한 방법을 찾아내서 이를 개발 표준에 반영해나가는 방향으로 유도하는 것이 바람직하다.


좋은 습관 30. 다양한 구현 메커니즘(Reflection and introspection, Dynamic code generation, Aspect-Oriented Programming)을 활용하여 소스 코드의 중복을 최소화한다.

통상적인 프로그래밍 기법만으로는 모듈화나 소스 코드의 중복을 최소화할 수 없다. 그러나 자바가 제공하는 몇 가지 기교를 사용한다면 이 문제점을 해결하는데 몇 걸음 더 앞으로 나아갈 수 있다.

첫 번째는 Reflection 기능을 사용하는 것이다. 이를 통하여 프로그램을 동적으로 처리할 수 있다. 그리고 자바 가상 머신의 성능이 계속해서 향상됨으로써 Reflection 기능을 사용하였을 때의 가장 큰 문제점이었던 성능 저하 문제가 많이 해소되었다.

두 번째는 코드를 직접 생성하는 것이다. 이는 소스 코드를 생성하는 정적인 방식과 클래스 파일을 만드는 동적인 방식이 있는데 두 방식을 사용하면 유사한 코드의 작성을 자동화할 수 있다. 여기서 주의해야 하는 것은 자동으로 생성된 소스 코드의 경우는 일체 개발자가 수정해서는 안된다는 점이다. 그리고 코드 생성과 관련한 좀 더 자세한 내용은 다음에서 확인할 수 있다.

세 번째는 AOP를 기술을 이용할 수 있다. 이 기술을 이용하게 되면 비즈니스 로직이 아닌 부분들을 일반 클래스에서 분리하여 독립시킬 수 있고 필요에 따라서 다양한 형태로 결합할 수 있게 해준다.


좋은 습관 31. 버그의 처리를 뒤로 미루지 않는다.

확연한 버그를 수정하지 않고 새로운 기능을 개발하는 것은 그 기능을 개발하는데 투입될 노력을 헛되게 만들 수 있다. 버그의 수정으로 인해서 버그 수정 전에 추가하였던 모듈에 대한 추가 수정이 필요한 경우가 있을 수 있기 때문이다.


좋은 습관 32. (가능한) 단위 테스트를 자동화한다.

JUnit 등의 단위 테스트 도구를 사용해서 단위 테스트를 자동화한다. UI(User Interface)에 대한 테스트와 DB와의 연동에 대한 테스트의 경우와 같이 아직 자동화하기 어려운 부분에 대해서는 이를 굳히 적용할 필요가 없다. 그리고 단위 테스트를 자동화하기 쉽게 설계하는 것이 좋은 설계 전략 중의 하나이다.


7. 테스트

소프트웨어 개발 방법론에서 테스트는 통합 테스트 및 시스템 테스트를 통하여 개발된 시스템이 기능, 기술 및 운영과 관련하여 설계 사항들과 부합하는지 증명하는 단계이다.


좋은 습관 33. 테스트는 운영 환경과 동일한 설정에서 진행한다.

통합 테스트와 시스템 테스트는 운영 환경과 동일한 설정에서 진행하여야 한다. 운영 환경에서 웹 서버와 WAS를 분리하는 경우나 클러스터링을 사용하는 경우 이와 같은 설정하에서 테스트를 해야 한다.


좋은 습관 34. 테스트는 요구사항 문서를 기준으로 진행한다.

테스트 케이스 혹은 테스트 시나리오를 작성하였다면 이 산출물들을 테스트의 평가 기준으로 사용하면 된다. 그러나 이런 산출물을 작성하지 않았다면 요구사항 문서로 이를 대체할 수 있다. 프로젝트 진행 과정에서 요구사항이 변경된 부분을 문서에 잘 반영해야 하는 이유가 바로 여기에 있다.

테스트 케이스 혹은 테스트 시나리오는 요구사항 문서와 중복되는 부분이 많기 때문에 이들을 작성한다면 프로젝트 팀원들의 부담이 배가된다. 특히 변경 사항을 잘 반영하지 않으면 무용지물이 되기 십상이다. 따라서 관리 및 산출물 작성 부담을 줄이기 위해서 요구사항 문서로 이를 대체하는 것이 바람직할 수 있다는 것이다.


좋은 습관 35. 통합 테스트는 J2EE 애플리케이션과 DBMS 간의 모든 SQL 쿼리 실행을 모니터링 하면서 진행한다.

DBMS와의 작업 모듈이 애플리케이션의 성능에 가장 큰 영향을 미친다. 그래서 다른 어느 부분보다 DBMS와의 연동 모듈에 대해서는 철저한 모니터링 작업을 수행해야 한다. 이 때 모니터링은 항상 애플리케이션의 소스 코드에는 일체 수정을 가하지 않으면서 이루어져야 한다. 이를 가능하게 하는 것이 바로 Proxy 디자인 패턴이다. 데이터소스와 JDBC 드라이 사이에 Proxy를 사입함으로써 소스 코드에는 일체 영향을 주지 않으면서 원하는 모니터링을 수행할 수 있다. 이를 가능하게 하는 솔루션으로는 P6SPYJDBInsight 등이 있다. 이중 P6SPY는 오프 소스 솔루션이다.


8. 구현

소프트웨어 개발 방법론에서 구현은 개발된 시스템을 고객에게 인계하기 위하여 수행되며, 실제 운영 환경을 구축하여 인수 테스트 및 사용자 교육을 수행하는 단계이다. 여기서는 주로 애플리케이션 배치와 관련된 좋은 습관들을 다룬다.


좋은 습관 36. J2EE 패키징 방법과 특성을 이해하고 애플리케이션은 ear 혹은 war 파일로 패키지하여 배치한다.

J2EE 애플리케이션을 패키지하여 배치할 것인가? 아니면 디렉토리 구조로 배치할 것인가? 디렉토리 구조로 배치하면 소스 코드 상의 에러 처리와 긴급한 변경 사항을 신속하게 반영할 수 있다는 장점이 있지만 몇 가지 구조적인 단점이 존재한다. 첫째로 애플리케이션의 관리 수준이 떨어진다. 별도의 패키지 작업을 거치지 않고 운영 중인 애플리케이션이 임의적으로 변경될 수 있으므로 현재 운영 중인 애플리케이션의 정확한 버전 관리가 어려워진다. 둘째로 WAS가 배치된 애플리케이션의 변경사항을 항상 모니터링 하도록 해야 함으로 WAS의 성능 저하가 발생한다.

반면에 ear이나 war로 배치하는 경우는 변경 사항이 발생했을 때 이를 반영하는데 걸리는 시간이 오려 걸린다는 단점이 있다. 또한 재배치가 이루어지는 경우에는 애플리케이션을 일시적으로 정지해야 하는 부작용도 있다. 테스트를 철저하게 수행해서 에러가 발생하는 빈도를 줄이고 변경 사항에 대한 반영을 일정한 프로세스를 거쳐서 수행한다면 이런 문제를 해결할 수 있다.


좋은 습관 37. 모든 배치 과정을 자동화한다.

형상관리 도구에서 소스 코드를 체크 아웃하는 것부터 패키지된 애플리케이션을 WAS에 배치하고 시작시키는 것까지 모든 배치 과정을 ANT 등의 도구를 사용해서 일괄 자동화한다.
이런 자동화 과정을 반복해서 수행하면서 검증하면 수작업시 발생할 수 있는 실수를 미연에 예방할 수 있다.


좋은 습관 38. JSP는 컴파일해서 배치한다.

사용자(웹 브라우저)의 요청에 의해서 처음 JSP가 실행되는 경우에는 JSP 파일이 서블릿과 클래스로 변환되는데, 이 시간이 길기 때문에 사용자가 시스템의 반응 속도가 느리다고 오판할 수 있다. 특히 고객과의 리뷰나 인수 테스트 시에 이런 문제가 발생하는 것은 바람직하지 않다. 그래서 대부분의 WAS는 배치시에 미리 모든 JSP를 컴파일하는 기능을 제공한다. 그리고 부가적으로 컴파일 에러가 발생하는 JSP를 사전에 수정할 수 있는 기회도 제공된다.


좋은 습관 39. 정적인 리소스는 웹 서버에 배치하고, 운영 중에는 메모리에 캐싱한다.

성능 향상을 위해서 HTML 문서와 이미지 파일과 같은 정적인 리소스와 자바 웹 애플리케이션을 분리해서 배치한다. 여기서 분리는 하드웨어의 분리가 아닌 정적인 자원을 처리하는 웹 서버와 동적인 작업을 담당하는 웹 애플리케이션 서버의 분리를 의미한다. 그리고 웹 서버에 배치된 정적인 자원의 변경 빈도는 상당히 낮음으로 이를 메모리에 캐싱하는 것이 바람직하다.

Caucho Resin과 같은 WAS에 따라서는 분리하지 않는 것을 권장하기도 함으로 이를 확인하여야 한다.


좋은 습관 40. 배치된 애플리케이션에 대한 신규 버전을 생성한다.

성공적으로 애플리케이션을 운영환경에 배치하면, 배치된 애플리케이션을 구성하는 소스 코드들에 대해서 신규 버전을 생성한다. 통상 개발 단계에서는 최신의 소스 코드만을 관리하면 되지만, 운영 중인 환경에서는 그렇지 않다. 운영 이후에 작거나 큰 변경 작업이 이루어지게 되는데 이 과정에서 다양한 버전의 애플리케이션이 생성되게 된다. 이를 효과적으로 관리하지 않으면 현재 어떤 버전의 애플리케이션이 배치되어 있는지를 파악하지 못할 수 있다.


좋은 습관 41. 운영 시스템에서 생성되는 로그 파일에 대한 백업 프로세스를 수립한다.

운영 중인 시스템은 다양한 로그 메시지를 기록한다. 웹 서버, WAS, 애플리케이션, DBMS 등이 다양한 로그 메시지를 여러 파일에 기록한다. 일정 시간이 지나면 로그가 기록된 파일의 크기가 커지게 되는데 이럴 경우 애플리케이션의 성능에 부정적인 영향을 미칠 수 있다. 이런 문제를 사전에 회피하기 위해서 로그가 기록되는 파일의 크기가 일정 수준을 넘어서면 새로운 파일에 로그를 기록하도록 수정하고, 기존의 파일은 미리 지정한 위치로 백업이 되도록 자동화된 프로세스를 수립하여야 한다.


9. 결론

이 문서에서 다루고 있는 대부분의 좋은 습관들은 J2EE 기술을 사용하지 않는 프로젝트에서도 적용할 수 있다. 그리고 읽는 이의 관점에 따라서 이 항목들에 대한 이견이 표출되는 것 또한 자연스럽다. 결국 적용 여부의 판단 기준은 프로젝트에 참여하고 있는 팀원들의 동의에서 찾아야 한다.


좋은 습관 42. 소프트웨어 애플리케이션 개발 프로젝트는 표준을 준수하는 과정이 아니라 표준을 만들어 나가는 과정이다.

프로젝트의 유토피아를 완벽한 개발 표준의 존재와 그것이 준수되는 무결점적 시스템에서 찾기는 버겁다. 표준 자체의 부족함과 표준이 적용되는 과정에서 발생하는 갈등을 인정하고 각 프로젝트의 다양성을 받아들였을 때 추구해야 하는 바가 분명해진다. 프로젝트는 (표준의) 부족한 부분을 메꾸어 가는 고단한 장정이며 동작하는 애플리케이션은 그 선물에 지나지 않는다. 여기서 필요한 것은 끈질긴 참을성이며, 기댈 곳은 고객과 프로젝트 팀원들과의 부단한 대화일 뿐이다.


10. 참고 자료



2004-04-20

Learning Organizations and Software Developer

출처 : IEEE Software March/April 2004
URL : http://www.computer.org/software/homepage/2004/s2fte.htm


Software development guru define insanity as "doing the same exact thing over and over and expecting different results.

소프트웨어 개발 권위자는 "동일한 일을 계속하면서 다른 결과를 기대하는 것을" 어리석은 것으로 정의한다.


Every suggestion would get a reply withing 24 hours.

모든 제안은 24시간 이내에 대답을 얻는다.


If the suggestion was good, the process for implementing it would begin within 72 hours.

제안이 좋다면, 그 제안을 구현하는 것은 72시간 안에 시작된다.

2003-09-07

Who Needs an Architecture?

가끔은 영화를, 특히 많은 사람들이 보는 그런 영화는 꼭 볼 필요가 있나 봅니다. 매트릭스와 같은.
 
 
몇 일간 Martin Fowler가 [IEEE Software(July/August 2003)]에 기고한 [Who Needs an Architect?]라는 글을 들고 출퇴근을 하고 있습니다.
 
의역하면 "도데체 누가 아키텍트를 필요로 하는가?"가 될 도발적인 제목은 글을 여러차례 읽어도 쉽게 그 의미가 다가오지는 않습니다. 풀어야 할 숙제 또는 응전해야 할 화두가 다소곳이 놓여져 있을 뿐입니다.
 
3 페이지가 채 되지 않는 글은 Martin Fowler의 동료로 소개되는 Dave Rice의 "We shouldn't interview anyone who has 'architect' on his resume."라는 푸념으로 시작하며, [What is architecture?], [The architect's roles], [Getting rid of software architecture]로 구성되어 있습니다.
 
Martin Fowler는 ThoughtWorks의 주요 아키텍트로 소개되는 Dave Rice의 명칭 분열증(Title schizophrenia)의 원인을 아키텍트의 독선적인 또는 잘난척하는 이미지(the smug controlling image at the end of Matrix Reloaded)와 아키텍트가 수행하는 기술적 리더십의 필요성의 갈등에서 찾습니다.
 
 
[What is architecture?]
 
I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.
                                                                                                                        - Martin Fowler
 
 
In RUP defines Architecture as the highest level concept of a system in its environment. The architecture of a software system is its organization or structure of significant components interecting through interfaces,...
                                                                                                                                     - RUP
 
 
There is no highest level concept of a system... Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment.... What makes a component significant? It is significant because the expert developers say so.
                                                                                                                     - Ralph Johnson
 
 
 
냉소적인 Martin Fowler의 정의를 옆으로 비켜 놓는다면, 이 글을 GoF의 한 명인 Ralph Johnson의 생각을 Martin Fowler가 정리하는 혹은 빌리는 방식으로 진행됩니다.
 
우선 Ralph Johnson은 아키텍쳐가 정의되는 범주를 전체 환경이 아닌 개발자가 생각하는 환경으로 묶습니다.
 
In most successful software projects, the expert developers working on that project have a shared understanding of the system. This shared understanding is called 'architecture'.... it makes clear that architecture is a social construct because it doesn't just depend on the software, but on what part of the software is considered important by group consensus.
                                                                                                                     - Ralph Johnson
 
Architecture is the set of design decisions that must be made early in a project.
                                                                                                        - Another style of definition
 
 
Ralph Johnson이 든 예를 확장하면, 소프트웨어를 J2EE로 구현할지? .NET으로 구현할지는 후자의 정의로는 아키텍처의 구성요소가 되지만, 두전자의 정의를 따르면 아키텍처의 구성요소가 아닌 것이 됩니다.
 
So, this makes it hard to tell people how to describe their architecture. 'Tell us what is important.' Architecture is about the important stuff. Whatever that is.

혹시 Presentation Layer, Business Layer, Integration Layer 등을 칠판에 그리고는 이게 우리가 개발할 시스템의 아키텍처라고 하시지는 않습니까? 뻔한 그림을 가지고. 끊임없이 지루하게 반복되는 교수의 지껄임처럼.
 
 
 
[The architect's roles]
 
So, if architecture is the important sutff, then the architect is the person who worries about the important stuff.

2003-08-16

A Programming Episode

Robert C. Martin의 [Agile Software Development]의 "6 장 A Programming Episode"는 밥 아저씨와 Robert S. Koss가 2000년 말 한 호텔방에서 함께 했다는 프로그램밍 과정을 에피소드 형태로 기술하고 있습니다.

작년에 인터넷을 통해서 대충 보긴 했는데, 오늘 책을 따라가면서 이클립스로 코딩을 하면서 다시 읽었는데 으시시(?)하군요. 영화 [유주얼 서스펙트]나 [식스 센스]와 같은 마지막 반전이 오랜만의 독서의 졸음을 확 달아가게 합니다.

둘은 볼링점수를 계산하는 프로그램을 작성합니다. 둘이서 함께 Pair Programming을 하면서 Test-Driven Developemnt와 리팩토링을 통해서 프로그래밍을 하는 과정을 상세히 기술하고 있습니다. 전부 40 페이지의 분량이긴 한데, 전체의 4/5가 (반복적인) 코드이기 때문에 많다고 느껴지지는 않습니다. 중간에 좀 졸립기도 하지만... 막바지에는...


성급하게 말하면 UML을 통해서 소프트웨어를 설계하려는 사람들의 등에 비수를 꽂고 확인 사살을 하는 내용이라고 생각하면 됩니다. 또한 디자인 패턴이나 객체 지향을 몽매하게 추종하는 사람도 쓴웃음을 숨길 수만은 없는...

하여간 2시간 정도 투자해서 Pair-Programming, Test-Driven Development, Refactoring에 대한 예증적인 경험을 할 수 있는 좋은 글인 것 같습니다.


범인이 케빈 스페이시라는 것을, 혹은 브루스 윌리스가 유령이라는 것을 알고 영화를 보는 것이 맥빠지듯...

책에 있는 내용과 인터넷에서 볼 수 있는 내용은 약간 다릅니다. 책에 있는 코드가 비교적 더욱 깔끔하고, 인터넷에 있는 글에서는 Kent Beck을 만날 수 있습니다.

http://www.objectmentor.com/resources/articles/xpepisode.htm


P.S. 여담으로 마지막에 최종적으로 나오는 코드를 통해 각주가 필요없는 코드란 무엇인가를 알 수 있습니다..

2003-04-24

Test-Driven Development

Test-Driven Development(이하 TDD)에 대한 이야기는 몇차례로 나누어서 진행하도록 하겠습니다. 오늘은 Java 환경에서 TDD를 하는데 꼭 필요한 JUnit Framework에 대한 이야기입니다.
 
 
본론으로 들어가기 전에 몇 가지 말씀드리겠습니다. 첫째는 다시 강조해 말씀드리지만 소개하는 책들이나 글들의 대부분은 저도 읽지 못했습니다. 여기 저기서 좋은 책이더라 혹은 좋은 글이더라는 입소문을 정리해놓고 언젠가는 한번 읽어야지 하고 생각하고 있을 뿐입니다. 설사 읽었더라도 10%도 이해하지 못한 수준으로 읽었을 뿐입니다. 그런데 보내는 글마다 "이 글은 저는 못읽었지만, 누가 그러는데 좋더라"라는 식으로 쓰는 게 어색해 보여서 당연히(?) 제가 읽었다는 투로 할뿐입니다.
 
둘째는 그래서 제가 이야기하는 주제에 대해서 저도 잘 모릅니다. 어쩌면 "주제 넘게" 설치고(?) 있는 것인지도 모르겠습니다. 알기 때문에 주장하거나 글을 쓰는 것이 아니라, 주장하고 싶기 때문에 주장하는 것이고 글을 쓰고 싶기 때문에 글을 쓰는 것입니다. 앎의 크기와는 별개로... 무식하면 용감해진다고 하는 것처럼. 제가 쓰는 글들이 학술 세미나에 발표될 논문도 아닌 거의 낙서(?) 수준인데 학문적 엄밀성 같은 건 없습니다. 그리고 알게 모르게 구라(?)도 좀 있습니다.
 
셋째는 제가 쓰는 글들이 "Agile" 적인 것에 집착(?)하면서 다른 것들을 의도적으로 폄하(?)하거나 무시(?)하는 경향이 있다는 것을 알고 있습니다. 금년 KBL 챔피언 결정전처럼 허재를 위해서 김승현과 김병철, 그리고 힉스가 저같은 허재의 팬들에게는 세상의 나쁜 놈이 되었던 것 처럼... 내년이면 저도 서른이군요. 제가 아무리 설쳐야 CMM이나 RUP가 가지는 위상에 변함이 없을거란, 그리고 Agile에 아무런 도움도 되지 않을 거란 정도는, 그리고 더 이상 세상이 "나"를 중심으로 돌아가지 않는 다는 정도는, 그리고 스스로의 능력의 크기 정도는 알 정도의 철은 들었습니다. 그러나 이것도 맞고 저것도 맞고 혹은 이것도 틀리고 저것도 틀리다는 식의 양비론 혹은 양시론적인 글쓰기는 쓰는 사람이나 읽는 사람이나 지루(?)하지 않을까요. 그건 조선일보만으로도 충분하다고 생각합니다. 앞으로도 쭉 Agile은 좋은 놈(?) RUP와 CMM은 나쁜 놈(?)입니다.
 
넷째, 제가 이런 글들을 쓰는 목적의 하나는 잘난 척(?)하려는 거고, 둘은 Agile을 주장하고 싶은 거고, 셋은 가지고 있는 생각들을 정리하려는 거고, 넷은 공유하려는 것입니다. 중요도 순(?)입니다.
 
 
JUnit Framework
 
"JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java. JUnit is Open Source Software, released under the IBM's Common Public License Version 1.0 and hosted on SourceForge."
 
Kent Beck과 Erich Gamma가 어느 컨퍼런스 참석을 위해서 타고 가던 비행기에서 함께 만들었다고 알려진 자바 환경에서의 단위 테스트 실행(?) 프로그램입니다. 당연히 비즈니스 클래스였겠지요... 정확하게는 xUnit architecture for unit testing frameworks(이하 xUnit Architecture)로 불리는 자동 단위 테스트 실행을 위한 개념적 디자인을 자바 환경에서 구현한 것으로 파악할 수 있습니다. 이는 MDA(Model Driven Architecture)의 전형적인 예라고 할 수 있습니다. 실제로 xUnit Architecture를 프로그램밍 언어에 맞게 구현한 것이 30여개에 이르고 있습니다. 동일한 디자인(xUnit Architecture)을 공유하면서 다양한 플랫품(언어)에서 구현했다는 점에서 MDA와 같습니다. 그러나 MDA는 하나의 디자인이 상이한 플랫폼들로 구현되는 과정의 자동화를 추구한다는 점에서 특정 프로그램밍 언어 개발자들에 의해서 직접 구현되는 xUnit Architecture와는 다릅니다. 아래의 사이트에서 JUnit Framework에 대한 많은(?) 정보를 얻을 수 있습니다.
 
www.junit.org

 
최소한 자바 개발자들에게는 Martin Fowler의 격찬(?)이 맞다고 생각합니다.
 
Never in the field of software development was so much owed by so many to so few lines of code.

많은 사람들이 단위 테스트를 위한 툴이라는 본래의 목적 외에도 JUnit Framework는 패턴 스터디 대상물로 적격이라고 말합니다. Design Pattern이 실제 프로그램에서 어떻게 구현되는지를 알 수 있게 해주며 동시에 소스코드의 양도 작기 때문입니다. 또한 Kent Beck이나 Erich Gamma가 아직도 개발에 참여하고 있기 때문에 대가의 코드를 직접 접할 수도 있습니다. [JUnit A Cook's Tour]라는 글을 참조하면 좋을 것 같습니다.
 
JUnit Framework에 대한 좋은 읽은 거리는 다음과 같습니다.
 
Test Infected: Programmers Love Writing Tests (Erich Gamma)
http://junit.sourceforge.net/doc/testinfected/testing.htm

JUnit Cookbook (Kent Beck, Erich Gamma)
http://junit.sourceforge.net/doc/cookbook/cookbook.htm

JUnit A Cook's Tour (Erich Gamma, Kent Beck)
http://junit.sourceforge.net/doc/cookstour/cookstour.htm

JUnit FAQ (Mike Clark)
http://junit.sourceforge.net/doc/faq/faq.htm

 
이상은 JUnit(3.8.1)을 다운받으면 그 안(doc 디렉토리)에 모두 들어 있습니다. JUnit FAQ는 계속 수정이 되기 때문에 웹에서 확인하는 것이 좋습니다.
 
Martin Fowler의 [Refactoring: Improving the Design of Existing Code]에도 JUnit과 관련된 장이 있습니다. [Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus]에도 내용이 있습니다.

 
JUnit Framework를 설치하고 사용할 줄 아는데 걸리는 시간은 아는 사람들의 도움을 받으면 1시간이면 충분합니다. 사용해보고 싶은 분들은 언제든지 말씀하세요. 다음은 eXtreme Programming(XP)에서의 TDD와 Test-First Programming(TFP)에 대해서 이야기하도록 하겠습니다.
 

 
잡설 하나.
 
xUnit Architecture는 .NET에서는 NUnit Framework로 구현되었습니다.
 
잡설 둘.
 
Grich Gamma의 [Test Infected: Programmers Love Writing Tests]는 꼭 한번 읽어보세요. 이 글은 The Problem, Example, Testing Practices, Conclusions으로 구성되어 있는데 Example을 빼면 1 페이지 정도의 분량입니다. JUnit Framework에 익숙하지 않은 상태라면 Example을 제외하고 읽으시면 됩니다.

2003-04-21

The Unified Software Development Process

1999년 중반부터 2001년 초반까지는 Addison Wesley의 "Object Technology Series"(흰 바탕 겉표지 하단 오른쪾에 Booch, Jacobson, Rumbaugh의 이름을 담은 사각형 박스 낙인(?)이 찍힌 그 책들)가 90년대를 뜨겁게 달구었던 백가쟁명의 시대를 마감하고 천하를 통일한(Unified) 시대로 역사(?)에 오랫동안 기억될 것입니다. 진시황의 진나라처럼 너무나 짧은 기간이었지만...
 

법가(Capability Maturity Model, CMM)에 기반한 그 짧았던 왕조는 자신만의 것이 옳다고 주장하며 분서갱유를 마다하지 않았으며, 불로장생(Model-Driven Architecture, MDA) 꿈을 버리지도 못했습니다. 그러나 그런 왕조의 폭정에 항거하여 단호하게 일어난 이들이 있었으니 그들이 바로 그 자랑스런 에자일 연합(Agile Alliance)이었으며, 그들에 의해 왕조는 그 막을 내렸습니다. 그러나 진시황이 동시에 도량형, 화폐, 거궤, 문자를(Unified Modeling Language, UML) 통일하는 등의 업적이 있었음은 부정할 순 없을 겁입니다.

아마도 탁월한 합리주의자이자 기능주의자인 시황제가 아니었더라면 이런 대업적을 단기간에 이룩하는 것은 불가능했을 것이다. 진시황은 극단적인 합리성과 동시에 극단적인 비합리성이 기묘한 형태로 어우러져서, 아주 꼼꼼하게 정무에 힘쓰는 반면에, 거대건축을 세우거나 선약찾기에 막대한 재정을 쏟아부어 부질없이 낭비를 거듭하는 양극단을 오고가는 극과 극의 이중성을 지닌 인물이었던 것으로 생각된다.
                                                                                                       - 어느 인터넷 사이트에서 펌
 
 
그 시대를 빛냈던 그러나 상대적으로 큰 주목을 끌지 못했던 책이 바로 Ivar Jacobson, Grady Booch, James Rumbaugh가 쓴 [The Unified Software Development Process (이하 UP)] 입니다. 동시에 나온 책 중 [The Unified Modeling Language User Guide]는 Booch 주도로, [The Unified Modeling Language Reference Manual]은 Rumbaugh 주도로 쓰여졌고, UP는 Jacobson 박사(일반적인 그에 대한 존칭임) 주도로 작성되었다고 할 수 있습니다. 사실 UML Reference Manual은 저자가 세명이기 때문에 나온 저주받은 책이라는 느낌이 들고 Rumbaugh 역시 상대적으로 과소평가를 받고 있습니다.


RUP(Rational Unified Process, 이걸 '러프'라고 읽는다면서요?)는 UP(Unified Process)를 상품화한 방법론입니다. 사실 RUP와 관련된 책들이 20권 정도가 있는데, 대표적인 책들이 위의 UP를 비롯해 Philippe Kruchten의 [The Rational Unified Process: An Introduction, 2nd]와 Craig Larman의 [Applying UML and Patterns, 2nd]라고 할 수 있습니다. UP는 깊은(?) 철학에 대해서 설명하는 책이고, Kruchten의 책은 제목 그대로 기대할 것 없는 소개서이며 동시에 Rational 사 툴의 광고 팜플렛 같고, Craig Larman의 책은 Agile에 입각한 실천적인 분석·설계 지침서라고 할 수 있습니다.

 
그리고 RUP에 대한 좋은 자료는 Rational의 [Object-Oriented Analysis and Design Using UML] 교육자료입니다. 현재 야간에 교육하고 있는 수업에서 사용하고 있는 그 자료입니다. 전 2001년 여름에 이 수업을 들었는데, 강사말고 교재만 좋습니다.(강사 멀리서 보면 이쁘고(?) 사람은 무척 좋았습니다. 당시 전 안경을 쓰지 않았슴.) 당시 강사가 RUP를 쓰는 프로젝트에서도 실제로는 Iterative하게 개발하지 않는다고 너무 솔직하게 말하더군요. UP 책의 1/3을 Iterative and Incremental Process 설명에 쏟아부은 Jacobson 박사가 알면 눈물 흘리며 슬퍼했을 겁니다.

글고 한 수강생이 CBD에 대해 질문하자 다른 강사는 이런 말은 했습니다. "CBD의 대가인 Jacobson 박사도 아직 CBD는 시기 상조고 어렵다고 했다. CBD는 현실에 적용하기 힘들거다.(뭐 대충 이런투로)". 솔직히 이 답변은 문제가 될 것이 없습니다. 저 스스로도 그 답변에 동의하고, 당시 RUP는 CBD를 주장하던 사람들로부터 RUP는 CBD 방법론이 아니다라는 공격을 받던 시기였으니까요. 근데 요즘은 RUP = CBD 더군요. 2년만에 RUP가 엄청난 발전을 한건지 아니면... "뻥"이 는건지...
 

개인적인 생각으로는 이정도 자료를 접한 다음은 더 볼 책도, 필요도 없다고 생각합니다. 필요한 건 단지 RUP로 진행되는 프로젝트 경험일 겁니다.
 
하여간 이 책들 중 UP를 읽지 않고 RUP는 논한다면 그는 사기꾼입니다. (UP가 담고 있는 내용을 다른 형태로 접했거나 프로젝트 경험이 많은 사람은 예외입니다.) 그 정도로 중요한 책이라고 할 수 있습니다.
 
 
UP는 크게 3 부분으로 구성되어 있습니다.
 
첫번째는 "The Unified Software Development Process"로 책 제목과 같으며, UP의 핵심 사상을 담고 있습니다. 그 핵심 사상은 "A Use-Case-Driven Process", "An Architecture-Centric Process", "An Iterative and Incremental Process"입니다. 그리고 "People are Crucial"이라는 내용도 있습니다. 이 내용을 보면 Agile로부터 공격받는 RUP를 바라보는 Jacobson 박사의 심정이 궁금합니다. Alistair Cockburn은 Use Case는 Drawing하는 것이 아니라 Writing하는 것이다로 더 많은 지지자(?)를 확보했고(Craig Larman의 책도 Cockburn의 Use Case를 따릅니다), 최소한 J2EE와 .NET 환경의 개발에서 4+1 View에 기반한 아키텍쳐는 아키텍쳐를 위한 아키텍처라는 느낌이 들기도 하며, 마지막 Iterative Process는 현실 프로젝트에서 세부적이고 복잡한 RUP의 개발 단계로 인해 사실상 Waterfall을 벗어나지 못했습니다.
그럼에도 불구하고 그 기본철학은 구구절절히 맞는 이야기들입니다


두번째는 "Core Workflows"로 요구사항 분석부터 테스트까지의 단계별 기법들에 대해서 설명하고 있습니다. 이 부분을 이해하기 위해서는 큰 그림을 그릴 수 있어야 합니다. 그 큰 그림을 그리지 못하면 망(?)합니다. UP를 이해하는데 있어서 가장 어렵고 무시되는 부분이 Iterative Process인데 그 이유가 책에서는 Core Workflows를 Waterfall 형태로 설명하고 있기 때문입니다. 이렇게 평면적으로 판단하면 안되고 입체적인(Iterative)를 것을 고려해서 큰 그림을 그릴 수 있어야만 Core Workflows를 바로 이해할 수 있습니다. 그럼에도 불구하고 Core Workflows는 너무 많은 내용과 형태의 중간 산출물과, 활동(Activity), 역할(Role)들로 필요 이상으로 복잡하며, 이 부분이 Agile 진영이 RUP(UP보다 더 복잡한)를 비판하는 가장 큰 논거입니다.

 
세번째는 "Iterative and Incremental Development"로, Core Workflows가 기술적 기법 중심이었다면, 이부분은 프로젝트 관리 측면에서 다루고 있습니다. 그 관리의 중심에 바로 "Iterative and Incremental" 철학이 녹아들어가 있습니다. 이 부분은 UP에서 가장 중요하지만 가장 재미없는 부분입니다. 2000년 여름인가 Jacobson 박사가 한국에 왔을 때 멀리서나마 볼 수 있는 기회가 있었습니다. 참석자 중 한명이 Jacobson 박사에게 Iterative Process가 "Divide and Conquer"와 뭐가 다르냐고 했을 때, 그리고 실제 Waterfall가 뭐가 다르냐고 했을 때, Jacobson 박사의 대답이 기억에 없습니다. 그 역시 "Iterative and Incremental"이라는 개념이 프로젝트 성공을 위해서 얼마나 중요한 것인가에 대해서는 명확하게 알고 있음에도, 복잡한 UP의 Workflow(Unified라는 말처럼 4가지 방법론이 합쳐져서 발생하며, 동시에 모델링 툴을 비롯한 도구에 대한 의존도 때문에) 때문에 실제 프로젝트에서 Iterative하게 간다는 것이 불가능(?)하다는 것을 인정하지 않을까하는 주제넘는 생각을 합니다.
 
 
잡설 하나.
 
5월에 있는 "XP 2003", 6월에 있는 "Agile Development Conference"와 함께 3대 Agile Conference인 "XP Agile Universe 2003(8월)"에 Ivar Jacobson 박사가 강연자로 나온다고 합니다. 그가 어떤 이야기를 할지가 벌써부터 궁금합니다. UP를 통해 그를 보면 Agile과 그 사이에는 종이보다도 작은 차이만이 있음을 믿게합니다.
 

잡설 둘.
 
위의 3개 Agile 관련 Conference의 공통점은 뭘까요? MS .NET이 모두 후원을 하고 있다는 점입니다. 삥을 뜯겨도 단단히 뜯기는군요.
 

잡설 셋.
 
Agile Alliance는 Agile 진영의 느슨한(?) 연합이라고 생각하시면 됩니다. Agile Alliance 현 이사회(Grady Booch)에 놀랍게도 Grady Booch가 있습니다.

2003-04-20

Scrum Software Development Process

제 머리 속을 맴도는 생각들을 친절하게도 정리한 것 같은 글입니다. Linda Rising과 Norman S. Janoff가 작성한 [The Scrum Software Development Processes for Small Teams (July/August 2000, IEEE Software)]입니다. IEEE Software는 Harvard Business Review에 견줄만한 저널인 것 같습니다.


Scrum Development Process는 "Agile Alliance"의 대표 주자 중 하나입니다. XP(eXtreme Programming)만이 Agile은 아닙니다. XP가 프로그래밍에 초점을 맞춘다면, Scrum은 Management Process에 초점을 맞추고 있습니다. Scrum에 대한 자세한 내용은 [Pattern Languages of Program Design 4]에 실린 [SCRUM: An extension pattern language for hyperproductive software development]를 참조하시면 됩니다.
 
http://ootips.org/yonat/Scrum.pdf
 
그 외 Scrum을 이끌고 있는 Ken Schwaber와 Jeff Sutherland의 홈페이지도 참조하시기 바랍니다.
 
http://www.controlchaos.com/
http://www.jeffsutherland.com/scrum/index.html
 
 
내용 하나
Most development teams respond with, 'Make the chaos go away! Give us better requirements!' Unfortunately or not, chaos is the reality in this new business environment - as software developers we must learn how to meet customer needs and turn this chaos to our advantage.(26 page)
Chaos(멍 청하고 변덕스러운 고객과 기술 및 시장의 급격한 변화 등)는 위협(Threat)이 아닌 사업기회(Business Opportunity)입니다. 멍한 고객이 요구사항을 바꾸자고 하면 화내지 말고 쓰다듬어 주어야 합니다. 이 이쁜 것... Just embrace change!
 
 
내용 둘
Scrum advocates the use of small teams - no more than 10 team members..... (In the big project,) We thought initially that we could simply divide larger teams into collections of smaller subteams, each no larger than 10. We found that when the subteams are independent and the interfaces well defined, this works. When the overlap is considerable and the interfaces poorly understood, the benefits are not as great. Clearly, this(Scrum) is not an approach for large, complex team structures, but we found that even small, isolated teams on a large project could make use of some elements of Scrum. This is true process diversity.(29 page)
아직까지는 Agile Software Development와 프로젝트 규모와의 관계에 대한 적절한 답은 위의 발췌 내용이라고 생각합니다. 결국 규모가 큰 프로젝트는 Agile 대신 다른 것(RUP? ... 옌 될까?)을 선택하거나 위의 조건(when the subteams are independent and the interfaces well defined)을 충족시키도록해야 할 것입니다. 이를 위해서 중요한 것은 Common Team, Core Team에 대한 고민입니다. 다른 Module Team은 주로 Common Team, Core Team과 Interface를 이룰 뿐 자신들끼리의 Interface는 적기 때문입니다.
 
 
내용 셋.
As in all projects, there must be an initial planning phase. During this phase, the project team must develop an architecture and identify a chief architect. During development, the team should be prepared to make changes to this architecture, but they need a plan, an architecture, and a chief architect at the start. The chief architect defines the development project's vision based on this architecture and ensures that visions consistency throughout all the development phases.... 'The Architect role should advise and control the Developer roles and communicate closely with the developers.'(30 page)
개인적으로 Architect라는 역할을 좋아하진 않지만 위의 발췌 내용이 바로 Common Team이 해야 하는 것을 정확하게 서술하고 있습니다. Iterative 개발이 가능하려면 바로 Initial planning phase(혹은 warming up time)을 획기적으로 줄여야합니다. 바로 이게 표준 프레임워크의 목표입니다. 워크 플로우, 동적 메뉴 관리, 인증 및 권한 관리, 개발 기법 및 표준의 제공 등... Enterprise Common Team이 Project Common Team(EPM Common 팀)을 리드하고 도와줌으로써, 프로젝트 구성원은 Core Team을 중심으로 움직이도록 해야합니다. Core Team은 해당 애플리케이션에서 가장 중요한 모듈을 개발하는 팀입니다. 인사애플리케이션 개발의 경우 Core는 임직원 및 부서를 포함한 조직 체계를 관리하는 모듈을 개발하는 것이 될테고, 프로젝트 관리 애플리케이션 개발의 경우 프로젝트 정보를 관리하는 것이 Core가 될 것입니다.
 
 
내용 넷.
A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver valuable functionality..... A sprint is time-boxed development, meaning that the end date for a sprint does not change, The team can reduce delivered functionality during the sprint, but the delivery date cannot change.(30 page)
Sprint 는 Iteration 주기와 Release 주기의 중간개념으로 생각하면 됩니다. Sprint의 기간은 무조건(?) 4주보다 짧아야 합니다. SCMS에 비해서 NRMS의 결과나 생산성이 떨어졌던 이유에 대한 답이라고 생각합니다. 도메인의 복잡도에 차이가 있기 했지만 SCMS의 경우에는 time-box를 지켰던데 비해서 NRMS에서는 계속 날짜를 미루면서 Waterfall도 Iterative도 아닌 애매한 방식으로 개발을 진행했던 것이 가장 큰 실수 였다는 개인적인 생각이 듭니다.
 
클라이언트 애플리케이션과 웹 애플리케이션 개발 사이에 나타나는 차이 중에 하나가 바로 Beta 버전의 존재라고 생각합니다. 클라이언트 애플리케이션에는 여러차례의 Beta 버전의 출시 후에 최종 제품이 릴리즈 되는 반면, 웹 애플리케이션에는 Beta 버전 개념이 없는 것 같습니다. Iterative 개발을 하기 위해서는 Beta 버전이라는 개념에 기반한 Dynamic Release 방식을 채택할 필요가 있다고 봅니다.
 
 
내용 다섯.
The organization can make one very important decision at the end of a sprint: whether to continue product development. Given what was delivered during the last sprit and the current state of the market, the stakeholder meeting should address the question, "Should this project contiune?" This is a business decision and must be made after considering all the technical and marketing issues.'(32 page)
어렵지만 회피해서는 안되는 고민인 것 같습니다. 안그러면 NRMS 처럼 됩니다.
 
 
 

저번 주는 5년 전에 배웠던 생산 관리 교제[Operations Management - Strategy and Analysis, 4th (Krajewski / Ritzman)]를 꺼내 읽어야 했습니다. CMM과 RUP에서는 Frederick Tayler의 과학적 관리법이나 포드적 생산방식의 냄새가 난다면 과장일까요. 5년전 생산관리 시간에도 그런 구다닥리 기법은 가르치지도 배우지도 않았습니다. Lean Manufacturing이나 JIT(Just-In-Time) 등에서 Agile의 냄새가 난다면 과장일까요.
 
At XP2002 in Sardinia, noted economist Enrico Zaninotto observed, "... it appeared to me that software industry was trying to mimic method of industrial organization already exhausted ... industrial organization theory changed its view during the 1970's." What the software industry had been trying to mimic over the last twenty years - a more defined and granular approach to the process of software development was discredited and abandoned by a manufacturing industry that embraced lean manufacturing. Enrico observed that lean manufacturing is much like Extreme Programming and the agile processess.
 
XP2002에서 Kent Beck이 이런 말을 했군요.
 
At XP2002, Kent Beck called for focus during the next year on "the year of the manager," as we move agile practices into IT management and even into the business and IT management relationship. Indeed! Agile causes profound changes to this relationship and practicing, educating, and assisting IT and business management in the change will be a major factor in the success of the agile processes over the next years.

이미 NEXT YEAR은 올해입니다. 그리고 벌써 4월말입니다. 중학교 때 보았던 찰리 채플린의 [Modern Times]가 보고 싶은 하루입니다. 그 우울한 웃음도...

2003-04-19

소프트웨어 개발과 생산 관리

OB(Organizational Behavior, 조직행동)와 OR(Operation Research, 경영과학)이 경영학의 양대 축입니다. 전략, 인사, 마케팅은 OB에 뿌리를 두고 있고, 생산관리, MIS, 재무·회계는 OR에 뿌리는 두고 있습니다. 경영학 전공자는 결국 OB를 추구하거나, OR를 추구하거나 경영학과 담을 쌓죠...
 
개인적으로는 OR을 OB보다는 선호했고, 그 중 생산관리 과목(비슷하게는 관리회계, 기업재무 등을 포함해서)에 관심을 가졌습니다. ERP(Enterprise Resource Planning), SCM(Supply Chain Management), CRM(Customer Relationship Manageemnt) 등은 모두 MRP(Material Requirements Planning)에서 발전된 개념입니다.
 

강의 교재는 [Operations Management - Strategy and Analysis, 4th (Krajewski / Ritzman)]를 사용했습니다. 이 때가 제대 후 복학해서 첫학기 였으니깐 98년 1학기 였습니다.(처음 조 모임에 나갔는데 조원들이 OHP로 발표를 한다고 하더군요. OHP가 뭔지 한참 고민했습니다.) 오랜만에 책을 다시 꺼냈는데 놀라운 사실을 발견했습니다. 책은 책장 속에서도 늙어가는 군요.
 
비즈니스 애플리케이션 개발도 생산관리에 기반하고 있거나 혹은 기반해야 합니다. 여기서 잠깐! 혹시 "테일러의 과학적 관리법"이나 "포드의 컨테이너 벨트"를 아신다면 잊어도 됩니다. 그런 구닥다리는 구팔년에도 가르치지 않았습니다. "쨈"없는 CMM 보다는 "쨈"있는 Operation Management를 PM 교육 교재로 삼는다면 PM들이 싫어하겠죠...


9 장 Layout에서는 작업장 또는 사무공간에 대해서 다루고 있네요. 현재 우리는 소프트웨어 개발 공간에 대한 고려가 미흡하다고 생각합니다. 개발자의 행동양식과 의사가 반영되지 않은 개발공간이란 슬픈일입니다. 이런 부분에 대한 고민이 아직은 사치로 보일 수도 있지만 작은 차이가 큰 차이를 만들지 않을까요. Alistair Cockburn이 [Agile Software Development]에서 개발 공간에 대해서 다루고 있습니다.

 
6 장 Work-force Management에서는 Job Specialization과 Job Generalization (Job Enlargement, Job Rotation, Job Rnrichment)에 대한 내용이 있습니다. 세부적인 Role 방식을 따르는 RUP는 Job Specialization을, Agile 방법론들은 Job Generalization을 따릅니다. 인도 사람들에게는 모르겠지만 한국은 Job Generalization이 맞다고 봅니다. 안그러면 기분상하고 쌈납니다.  Ed Romand이 [Mastering Enterprise JavaBeans 2nd]에서 이 부분에 대한 이야기를 하고 있습니다.