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시간 안에 시작된다.