Effective UI에 대한 서평이다.
30 페이지는 정독하고 나머지는 그냥 큰 글자만 보는 수준에서 훌터봤다.
어쩌자고 책 제목을 그렇게 지웠을까? Effective Java나 Effective C++ 등과 같은 명저 반열에 오르고 싶었던건가. UX를 하는 사람들이라서 네이밍 혹은 마케팅에 탁월한걸까? 그 탁월함이 글쓰기에 발휘되었다면 좋았을 것을...
물론 오해다. 저자들 다수가 일하는 회사 이름이 그럴 뿐이다.
책에 UI는 없다. UX도 없다. 이 단어들이 등장하지 않는 것은 아니다. 자주 등장하지만 이 책은 좋게 평가해도 소프트웨어 개발 방법론에 지나지 않는다. 재미없기로는 대기업 SI 방법론 매뉴얼과 우열을 가르기 쉽지 않다. 대기업 SI 방법론 매뉴얼은 간결하다는 미덕이라도 있다만 이 책은 그나마도 없다.
소프트웨어 개발 방법론이라면 이 책보다 월등히 좋은 책들이 많다는 점에서 이름 하나는 잘지었다.
자 그럼 Effective UI는 어디에 있는가?
Showing posts with label 소프트웨어 개발. Show all posts
Showing posts with label 소프트웨어 개발. Show all posts
2010-04-20
2009-11-27
Option, Preference, Parameter, Attribute, Property
애플리케이션을 설정할 수 있어야 한다. 이를 Option, Preference, Parameter, Attribute, Property 등의 용어 중에서 무엇을 설명할까?
Parameter
웹 애플리케이션이라면 HTTP 파라미터와의 혼돈으로 사용하지 않는 것이 좋다.
Attribute
모델(혹은 객체)의 속성으로 사용하는 쪽이 더 좋다.
Property
자바라면 System.getProperty 메소드와의 혼돈으로 사용하지 않는 것이 좋다.
Preference 혹은 Option
둘 중에 무엇을 선택해야 할지는 모르겠다. Preference는 사용자와 관련된 느낌을 준다. 누군가와 대화를 할 때는 Option이 더 좋다. 사용자와 애플리케이션에 대해서 따로 설정한다면 둘 다 사용하면 된다. 그렇지만 둘을 굳이 분리해야 하는가?
Option/Preference는 컨텍스트에 따라서 달라저야 하는가?
예를 들어 파일 업로드 최대 크기를 보자.
- 전체 애플리케이션에 설정할 수 있다
- 모듈에 따라서 다르게 설정할 수 있다. 모듈은 계층적이다.
- 사용자 혹은 그룹에 따라서 다르게 설정할 수 있다. 그룹은 계층적일 수도 있다.
이렇게 하면 유연성을 얻지만 복잡해진다.
Parameter
웹 애플리케이션이라면 HTTP 파라미터와의 혼돈으로 사용하지 않는 것이 좋다.
Attribute
모델(혹은 객체)의 속성으로 사용하는 쪽이 더 좋다.
Property
자바라면 System.getProperty 메소드와의 혼돈으로 사용하지 않는 것이 좋다.
Preference 혹은 Option
둘 중에 무엇을 선택해야 할지는 모르겠다. Preference는 사용자와 관련된 느낌을 준다. 누군가와 대화를 할 때는 Option이 더 좋다. 사용자와 애플리케이션에 대해서 따로 설정한다면 둘 다 사용하면 된다. 그렇지만 둘을 굳이 분리해야 하는가?
구현을 java.util.prefs 패키지로 한다면 Preference를 사용하여야 겠지만...
Option/Preference는 컨텍스트에 따라서 달라저야 하는가?
예를 들어 파일 업로드 최대 크기를 보자.
- 전체 애플리케이션에 설정할 수 있다
- 모듈에 따라서 다르게 설정할 수 있다. 모듈은 계층적이다.
- 사용자 혹은 그룹에 따라서 다르게 설정할 수 있다. 그룹은 계층적일 수도 있다.
이렇게 하면 유연성을 얻지만 복잡해진다.
2009-11-25
패키지 소프트웨어 갖추어야 하는 것들
패키지 소프트웨어가 갖추어야 하는 것들을 나름대로 정리해봤다.
자동 업데이트
Saas가 갖는 장점들이다.
What are the Advantages of Web-Based Software?
그리고 이는 패키지 소프트웨어의 단점이 된다. 모든 것을 극복할 수 없겠지만 PC 용 소프트웨어 처럼 자동 업데이트 기능만 있다면 만족할 수 있다.
패키지가 단순할 수록 자동 업데이트 구현이 쉽다.
이 때 데이터베이스 구조와 같은 내부적인 것들도 자동으로 변경해야 한다.
데이터 백업 및 복원
데이터가 날아가면 끝이다. 백업은 필수다. 백업을 하면 복원도 덩달아 필요하다.
손쉬운 건 일자별 백업이다. 일자별 백업을 하면 오늘 발생한 데이터는 어떻게? 결국 트랜잭션 로그를 남겨야 한다.
하드 디스크는 무조건 2개 이상이 필요하다.
이벤트 처리
무슨 일이 일어나는지 기록하면 좋다. 꼭 필요한 건 아니다.
스케줄러
주기적으로 데이터 백업을 수행하려면 스케줄러가 필요하다. Crontab 수준일 필요는 없다. 그러나 Crontab 만큼 별다른 고민없이 구현 가능한 것도 없다.
PC에 설치하는 개인용 소프트웨어가 아닌 서버에 설치하는 웹 기반 소프트웨어를 대상으로 한다.
자동 업데이트
Saas가 갖는 장점들이다.
What are the Advantages of Web-Based Software?
그리고 이는 패키지 소프트웨어의 단점이 된다. 모든 것을 극복할 수 없겠지만 PC 용 소프트웨어 처럼 자동 업데이트 기능만 있다면 만족할 수 있다.
패키지가 단순할 수록 자동 업데이트 구현이 쉽다.
이 때 데이터베이스 구조와 같은 내부적인 것들도 자동으로 변경해야 한다.
데이터 백업 및 복원
데이터가 날아가면 끝이다. 백업은 필수다. 백업을 하면 복원도 덩달아 필요하다.
손쉬운 건 일자별 백업이다. 일자별 백업을 하면 오늘 발생한 데이터는 어떻게? 결국 트랜잭션 로그를 남겨야 한다.
하드 디스크는 무조건 2개 이상이 필요하다.
이벤트 처리
무슨 일이 일어나는지 기록하면 좋다. 꼭 필요한 건 아니다.
스케줄러
주기적으로 데이터 백업을 수행하려면 스케줄러가 필요하다. Crontab 수준일 필요는 없다. 그러나 Crontab 만큼 별다른 고민없이 구현 가능한 것도 없다.
2009-11-24
패키지와 프레임워크
예전 회사에서는 프레임워크 개발을 했다. 스프링과 같은 자바 프레임워크였고, 이를 기반으로 많은 SI 프로젝트들이 진행되었다.
지금 회사에서는 패키지 솔루션 개발을 한다. 말로만 패키지지 실제로는 SI인 솔루션들도 많지만 설치 이후에 거의 수정을 하지 않는 진정한(?) 솔루션을 개발한다.
프레임워크 개발은 익명의 다수의 개발자를 대상으로 하기 때문에 제약이 많다. 학습과 경험에 의해서 이것 저것 고쳐야 할 것들이 보여도 수정하기가 어렵다. 이 문제를 해결하려고 잡다한 시도들을 했다.
컴포넌트 기반 개발을 축으로 무조건적으로 인터페이스와 구현을 분리하고, IoC 패턴으로 컴포넌트 간의 상관 관계를 쉽게 수정할 수 있도록 했다. 결과적으로 늘어나는건 적용된 디자인 패턴 숫자와 XML 파일... 그리고 이에 비례한 복잡도...
프레임워크 개발을 할 때는 중요하지 않은 문제를 중요하다고 간주하며 살던 시기였다.
솔루션을 개발하면서는 가능한 쉽게 가는 쪽을 선택했다. 골격은 MVC 패턴을 준수했지만 설정 부분을 다 하드코딩으로 처리햇다. XML 파일을 수정하나 코드를 수정하나 차이도 없고, 컴파일러가 오류를 잡아 주기 때문에 오타 가능성이 현격하게 낮아진다는 장점도 있다.
HiveMind와 같은 IoC 컨테이너도 쓰레기 통으로 던졌다. 필요한 객체를 직접 생성해서 쓰면 되지 굳이 set 메소드를 만들고, 이를 XML 파일에 설정해야 할 이유를 찾을 수 없었다.
물론 솔루션 개발에서 이런 태도로 전환할 수 있었던 것은 내가 작성한 코드를 다른 것에 영향을 주거나 받지 않고 쉽게 수정할 수 있기 때문이다. 현재의 나와 지금 함께 개발하고 있는 개발자들, 그리고 미래의 나와 미래에 나와 함께할 개발자들 혹은 내가 떠난 후 내 일을 인수 인계받을 개발자들만을 염두하면 된다.
결론적으로 어떤 코드든 쉽게 수정할 수 있다는 것이 솔루션 개발의 장점이다.
요약하면 유연성에 대한 태도도 바뀌었다. 전에는 고도의 기법을 통한 확장 가능성을 유연성으로 이해했다면 지금은 쉽게 이해할 수 있도록 간결하게 작성하는 것을 유연성을 확보하는 통로로 받아들이고 있다. 쉽게 이해할 수 있도록 간결하다면 수정하는 건 어렵지 않다.
지금 회사에서는 패키지 솔루션 개발을 한다. 말로만 패키지지 실제로는 SI인 솔루션들도 많지만 설치 이후에 거의 수정을 하지 않는 진정한(?) 솔루션을 개발한다.
프레임워크 개발은 익명의 다수의 개발자를 대상으로 하기 때문에 제약이 많다. 학습과 경험에 의해서 이것 저것 고쳐야 할 것들이 보여도 수정하기가 어렵다. 이 문제를 해결하려고 잡다한 시도들을 했다.
컴포넌트 기반 개발을 축으로 무조건적으로 인터페이스와 구현을 분리하고, IoC 패턴으로 컴포넌트 간의 상관 관계를 쉽게 수정할 수 있도록 했다. 결과적으로 늘어나는건 적용된 디자인 패턴 숫자와 XML 파일... 그리고 이에 비례한 복잡도...
프레임워크 개발을 할 때는 중요하지 않은 문제를 중요하다고 간주하며 살던 시기였다.
솔루션을 개발하면서는 가능한 쉽게 가는 쪽을 선택했다. 골격은 MVC 패턴을 준수했지만 설정 부분을 다 하드코딩으로 처리햇다. XML 파일을 수정하나 코드를 수정하나 차이도 없고, 컴파일러가 오류를 잡아 주기 때문에 오타 가능성이 현격하게 낮아진다는 장점도 있다.
HiveMind와 같은 IoC 컨테이너도 쓰레기 통으로 던졌다. 필요한 객체를 직접 생성해서 쓰면 되지 굳이 set 메소드를 만들고, 이를 XML 파일에 설정해야 할 이유를 찾을 수 없었다.
물론 솔루션 개발에서 이런 태도로 전환할 수 있었던 것은 내가 작성한 코드를 다른 것에 영향을 주거나 받지 않고 쉽게 수정할 수 있기 때문이다. 현재의 나와 지금 함께 개발하고 있는 개발자들, 그리고 미래의 나와 미래에 나와 함께할 개발자들 혹은 내가 떠난 후 내 일을 인수 인계받을 개발자들만을 염두하면 된다.
결론적으로 어떤 코드든 쉽게 수정할 수 있다는 것이 솔루션 개발의 장점이다.
물론 패키지 솔루션에서도 데이터베이스와 파일 구조를 변경하거나 외부 개발자들에게 공개한 오픈 API를 변경하는 것은 곤란한 일이다.
요약하면 유연성에 대한 태도도 바뀌었다. 전에는 고도의 기법을 통한 확장 가능성을 유연성으로 이해했다면 지금은 쉽게 이해할 수 있도록 간결하게 작성하는 것을 유연성을 확보하는 통로로 받아들이고 있다. 쉽게 이해할 수 있도록 간결하다면 수정하는 건 어렵지 않다.
2009-11-22
소프트웨어 개발이 추구해야 하는 방향
소프트웨어 개발 조직은 개발 비용을 절감해야 한다. 이는 개발 생산성을 높이는 것의 다른 이름이다. 그렇다면 다양한 요소로 이루어진 비용에서 어떤 비용을 줄이는데 초점을 맞추어야 하는가?
소프트웨어 개발 비용(total)은 이렇게 구성된다.
costtotal = costdevelop + costmaintain
일반적인 견해대로
costdevelop < costmaintain
이라면 유지보수(maintain) 비용 절감이 우순 순위를 갖는다.
유지보수 비용 구성은 아래와 같다.
costmaintain = costunderstand + costchange + costtest + costdeploy
켄트 백은 이중에서 기존 코드를 이해(understand)하는데 소요되는 비용이 가장 큰 비중을 차지한다고 주장한다.
그 주장에 동의한다면 소프트웨어 개발 비용(total)을 최소화하려면 코드 이해에 소요되는 비용을 줄어야 한다는 결론에 도다른다.
초기 개발 단계에서 유지 보수 비용을 회피하거나 최소화하는 방법으로 고도의(혹은 복잡한) 개발 기법을 이용해서 확장 가능한 소스를 개발하는 구현 전략은 유효할까?
이 시도가 갖는 첫번째 문제점은 시도 자체가 미완성으로 끝날 가능성이 높다는 점이다. 미래는 예측하기 어렵다. 불확실성을 제어할 방법이 마땅치 않다.
두번째로 일어날 일을 예측하기 어려운 점도 있지만, 예측한 일이 일어나지 않는다는 점도 문제점이다. 확장을 위해서 개발해 놓은 것들이 사용되지 않는다면 그 비용을 회수할 방법이 없다.
세번째로 돈의 시간 가치를 생각했을 때 비용 발생 시점을 현재보다는 미래로 연기해야 한다는 재무적인 측면에서의 문제점도 있다.
* 이 글은 켄트 벡이 쓴 구현 패턴(Implementation Patterns)을 인용하고 해석한 것이다. 그 중에서도 4장 Motivation을 다룬다.
소프트웨어 개발 비용(total)은 이렇게 구성된다.
costtotal = costdevelop + costmaintain
일반적인 견해대로
costdevelop < costmaintain
이라면 유지보수(maintain) 비용 절감이 우순 순위를 갖는다.
유지보수 비용 구성은 아래와 같다.
costmaintain = costunderstand + costchange + costtest + costdeploy
켄트 백은 이중에서 기존 코드를 이해(understand)하는데 소요되는 비용이 가장 큰 비중을 차지한다고 주장한다.
그 주장에 동의한다면 소프트웨어 개발 비용(total)을 최소화하려면 코드 이해에 소요되는 비용을 줄어야 한다는 결론에 도다른다.
초기 개발 단계에서 유지 보수 비용을 회피하거나 최소화하는 방법으로 고도의(혹은 복잡한) 개발 기법을 이용해서 확장 가능한 소스를 개발하는 구현 전략은 유효할까?
이 시도가 갖는 첫번째 문제점은 시도 자체가 미완성으로 끝날 가능성이 높다는 점이다. 미래는 예측하기 어렵다. 불확실성을 제어할 방법이 마땅치 않다.
두번째로 일어날 일을 예측하기 어려운 점도 있지만, 예측한 일이 일어나지 않는다는 점도 문제점이다. 확장을 위해서 개발해 놓은 것들이 사용되지 않는다면 그 비용을 회수할 방법이 없다.
세번째로 돈의 시간 가치를 생각했을 때 비용 발생 시점을 현재보다는 미래로 연기해야 한다는 재무적인 측면에서의 문제점도 있다.
* 이 글은 켄트 벡이 쓴 구현 패턴(Implementation Patterns)을 인용하고 해석한 것이다. 그 중에서도 4장 Motivation을 다룬다.
2009-10-14
Debt Metaphor
경제 위기 탓일까. 소프트웨어 개발 분야에서도 빚이 응용되는 것이...
Martin Fowler가 쓴 TechnicalDebtQuadrant을 재미있게 읽었다.
코드를 잘 짜는 것보다는 구현 자체가 미덕인 경우가 있다. 이 것이 개발자 의식 속에서 이루어진 선택인지 아니면 타성에 젖어 일어나는 일상적인 현상인지에 대해서 관찰하는 것이 필요하다.
책임감 있는 개발자라면 언젠가는 돌아봐야 하기 때문에...
Martin Fowler가 쓴 TechnicalDebtQuadrant을 재미있게 읽었다.
코드를 잘 짜는 것보다는 구현 자체가 미덕인 경우가 있다. 이 것이 개발자 의식 속에서 이루어진 선택인지 아니면 타성에 젖어 일어나는 일상적인 현상인지에 대해서 관찰하는 것이 필요하다.
책임감 있는 개발자라면 언젠가는 돌아봐야 하기 때문에...
2007-02-07
애플리케이션 개발의 목표
예전에 참여했던 프로젝트에서 애플리케이션을 어떻게 개발할 것인지에 대한 고객 질문에 답하기 위해서 정리한 내용입니다.
설계의 목적 및 방향
본 애플리케이션은 아래의 사항을 만족시키는 것을 목적으로 설계함.
설계에서 적용하는 기술 및 기법
위의 목적을 달성하기 위해서 아래의 설계 기술 및 기법을 적용함.
애플리케이션 인도 이후의 손쉬운 유지 보수 지원
요구 사항 변경이나 새로운 기능 요구에 부합하기 위한 확장성 지원
사용자가 애플리케이션을 사용하여 업무 수행을 하는데 지장이 없는 성능 보장
애플리케이션의 주요 기능이나 데이터를 인증을 받지 않은 사용자가 접근하는 것을 방지하는 보안 기능 지원
용이한 테스트가 가능하도록 설계하여 높은 수준의 품질 보장
전체 애플리케이션에 대한 일관성 유지
컴포넌트 아키텍처를 구성하기 위해 적용된 패턴 및 기준이 명시되었는가?
네트워크 부하 감소
재사용
결합도
설계의 목적 및 방향
본 애플리케이션은 아래의 사항을 만족시키는 것을 목적으로 설계함.
- 애플리케이션 인도 이후의 손쉬운 유지 보수 지원
- 요구 사항 변경이나 새로운 기능 요구에 부합하기 위한 확장성 지원
- 사용자가 애플리케이션을 사용하여 업무 수행을 하는데 지장이 없는 성능 보장
- 애플리케이션의 주요 기능이나 데이터를 인증을 받지 않은 사용자가 접근하는 것을 방지하는 보안 기능 지원
- 용이한 테스트가 가능하도록 설계하여 높은 수준의 품질 보장
- 전체 애플리케이션에 대한 일관성 유지
설계에서 적용하는 기술 및 기법
위의 목적을 달성하기 위해서 아래의 설계 기술 및 기법을 적용함.
애플리케이션 인도 이후의 손쉬운 유지 보수 지원
- 중복의 최소화(동일하거나 유사한 기능이 중복되어 설계되는 것을 방지함).
- 동일하거나 유사한 구조를 갖는 기능을 하나의 컴포넌트로 통합하여 설계(분리하여 설계하면 애플리케이션 관리 비용이 증가하고, 시스템 성능에 부정적인 영향을 미침).
- 모든 컴포넌트는 추상 상위 컴포넌트 클래스를 상속하도록 설계하여 공통적인 기능을 제공함.
요구 사항 변경이나 새로운 기능 요구에 부합하기 위한 확장성 지원
- CBD(Component-Based Development)에 충실하여 컴포넌트의 인터페이스와 구현을 분리.
- 컴포넌트를 사용하는 클라이언트 코드의 변경 없이 컴포넌트의 구현부 변경.
- 다양한 디자인 패턴(Model-View-Controller, Inversion Of Control, Strategy/Status, Command 패턴 등)을 적용하여 변경이 용이하도록 설계.
사용자가 애플리케이션을 사용하여 업무 수행을 하는데 지장이 없는 성능 보장
- 안정적인 성능을 보장하기 위해서 POJO(Plain Old Java Object) 방식을 통해서 컴포넌트 설계 및 구현.
- 분산 기능이 필요한 경우에 한해서 성능에 부정적인 영향을 미치는 EJB를 제한적으로 사용.
- 웹 UI에서 이미지의 사용을 최소화하고 웹 브라우저로 전송되어야 하는 HTML의 양을 최소화함.
- 변경이 없거나 변경 빈도가 낮은 데이터(코드, 부대 코드, 메시지 등)를 캐싱하여 불필요한 DB 작업을 최소화함.
- 자바 스크립트를 이용하여 보안에 문제가 없는 기능을 웹 브라우저에서 수행하여 서버의 부담을 최소화함.
- DataSource 및 Connection Pooling 기능을 사용하여 안정적인 DB 성능 보장
애플리케이션의 주요 기능이나 데이터를 인증을 받지 않은 사용자가 접근하는 것을 방지하는 보안 기능 지원
- 권한을 중심으로 보안 기능 설계(Role 디자인 패턴 적용).
- 사용자 로그인 시 사용자에게 할당된 권한 부여.
- 모든 URL에 대해서 권한 매핑을 하여 권한을 가지고 있지 않은 사용자가 접근하는 것을 원천적으로 방지함.
- 메뉴, 버튼, 화면, 화면의 특정 영역에 대해서 권한을 가지고 있지 않은 사용자는 볼 수 없도록 함.(Limited View 디자인 패턴 적용).
- 주민등록번호 등 주요한 데이터에 대해서 암호화하여 관리하고 불필요하게 노출되는 것을 제거함.
용이한 테스트가 가능하도록 설계하여 높은 수준의 품질 보장
- WAS(Web Application Server)와 독립적으로 테스트를 수행할 수 있도록 설계(HTTP 및 RMI-IIOP 프로토콜에 독립적으로 컴포넌트 설계).
- JUnit을 이용하여 자동화된 개발자 테스트 수행.
- 일일 주기의 자동화된 빌드를 통한 계속적인 단위 형상간 통합을 수행하여 시스템 통합 단계에서의 문제점을 최소화함.
- 자동화된 소스 코드 Inspection을 수행하여 소스 코드의 품질을 높임.
전체 애플리케이션에 대한 일관성 유지
- CSS(Cascading Style Sheet)를 이용하여 전체 UI의 구조(색상 및 위치)에 대해서 일관성을 유지함. 또한 변경이 필요한 경우 한번의 수정으로 전체 애플리케이션에 반영되도록 함.
- 소스 코드 표준 규약을 IDE(JBuilder)를 통해서 자동적으로 부여함으로써 완전한 코딩 표준 준수.
- 각종 설계 및 구현 표준을 작성하고, 지속적인 Peer Review 및 Code Review를 통한 표준의 준수 여부 체크.
컴포넌트 아키텍처를 구성하기 위해 적용된 패턴 및 기준이 명시되었는가?
네트워크 부하 감소
- 컴포넌트 구현 방식으로 분산 처리가 필요 없는 경우에는 EJB가 아닌 POJO를 사용한다.
- EJB를 이용한 컴포넌트 구현 시 Fine grained 한 방식이 아닌 Coarce grained 한 방식으로 설계 및 구현한다.
- EJB를 이용한 컴포넌트 구현 시 Local Interface를 사용해야 하나 제우스 WAS에서는 동일 프로세스 내에서는 Remote Interface와 Local Interface 간에 성능 차이가 없음으로, 테스트의 용이성 및 Fail Over 지원을 위해서 Remote Interface를 사용하여 구현한다.
- EJB를 이용한 컴포넌트 구현 시 EJB를 호출하는 클라이언트는 Service Locator 디자인 패턴을 이용하여 EJBHome 객체에 대해서 캐싱을 한다.
재사용
- Variation이 있는 부분에 대해서 Extension Point를 제공한다.
- Variation은 Strategy/State 디자인 패턴을 적용하여 구현한다.
- IoC 디자인 패턴을 활용하여 클라이언트는 컴포넌트 구현부가 아닌 인터페이스에만 의존하게 한다.
- 특정 기술 및 프로토콜(RMI-IIOP)에 대한 의존을 지양한다.
- 모든 컴포넌트는 공통 기능을 제공하는 BaseComponent를 상속하여 설계한다.
- 여러 컴포넌트들이 절차를 공유할 때에는 템플릿 메소드 디자인 패턴을 적용하여 설계한다. 이 경우에는 Inner 클래스 사용을 허용한다.
결합도
- 기능 구현에 있어서 개별 컴포넌트의 완전성을 추구하여 컴포넌트가 의존성을 최소화한다.
- 그러나 완전성 추구는 기능(혹은 코드) 중복 방지에 우선하지 않는다.
- 따라서 중복 방지를 위한 컴포넌트 간의 의존을 허용한다.
- 컴포넌트 설계 기법 뿐만 아니라 객체지향 설계 개념도 충실하게 반영하기 위해서 컴포넌트 간의 상호 참조를 일정부분 허용한다. 단, 이는 같은 형상 내에서만 허용한다.
- 형상 간에는 타 형상의 Sys 컴포넌트에 대해서만 참조를 허용한다. 이는 Facade 디자인 패턴을 적용한 것이다.
- 같은 형상 내에서는 컴포넌트 상호 간의 순환 참조가 꼭 필요한 경우에는 허용하나 최대를 이를 회피해야 한다. 그러나 타 형상 간에는 순환 참조를 절대 허용하지 않는다.
2005-07-18
Agile 북 리뷰
Agile 방법론과 관련한 Extreme Programming Explained 2nd, Crystal Clear, Agile Project Management 등의 책에 대한 서평이다.
1. 개요
Addison-Wesley에서는 Agile 방법론(통상적인 방법론 이상을 의미)과 관련한 다양한 유형의 책을 출판하고 있다. 이 출판사는 이런 유형을 두개 시리즈로 분류하고 있다.
The XP Series
Kent Beck이 편집자로 있고, XP(eXtreme Programming) 방법론과 관련한 내용을 다루는 시리즈.
The Agile Software Development Series
Alistair Cockburn, Jim Highsmith가 편집자로 있고, Agile 방법론과 관련한 다양한 내용을 다루는 시리즈. Agile의 철학에 대한 설명을 기본으로, DSDM, Lean, Crystal 등의 방법론을 다루기도 하고, Use Case, 형상관리 등의 기법을 다루기도 함. 사실상 XP를 제외한 Agile에 대한 모든 것을 다루는 시리즈로 간주할 수 있음.
2004년까지 별도로 진행되던 XP/Agile Universe와 Agile Development Conference가 2005년부터 Agile 2005 Conference로 통합된 것처럼 더 이상 두 시리즈의 구분에 큰 의미는 없다. XP를 중심으로 하던 논의가 이제는 Agile이라는 폭 넓은 화두를 중심으로 해서 진행되고 있는 특징을 반영할 뿐이다.
이 두 시리즈에서 다루어지지 않는 대표적인 Agile 관련 내용으로 Scrum, FDD(Feature Driven Development) 방법론이 있다. 그리고 Addison-Wesley 외에 Agile과 관련한 대표적인 시리즈는 Andy Hunt와 Dave Tomas가 편집자로 있는 The Pragmatic Programmer를 들 수 있다.
아래는 Kent Beck의 Extreme Programming Explained(이하 XPE) 개정판과 Alistaire Cockburn의 Crystal Clear, Jim Highsmith의 Agile Project Management(이하, APM) 등에 대한 서평이다.
2. Agile 방법론
Agile 방법론을 특정 기법이나 도구의 사용 여부로 다른 방법론과 구분하는 것은 유익하지는 않다. XP의 12 기법을 모두 적용한다고 그것이 바로 Agile적이다라도 단정지을 수는 없다. 그보다는 Agile Alliances’s Manifesto에 대한 충실도가 중요하다. 결국 신뢰에 바탕한 관계지움에 대한 고민이 Agile의 척도여야 한다.
아래의 책들은 다양한 기법에 대해 설명하고 있는데 이들에만 집중하면 큰 흐름을 잃어버리는 우를 범할 수 있다. Agile 자체에 대한 고민을 중심으로 저자들이 제시하는 기법에 집중을 해야 그 기법에 대한 이해도를 높일 수 있으며 큰 흐름을 받아들일 수 있다.
3. Extreme Programming Explained 2nd
Agile과 XP를 세상에 알린 1999년에 출간된 XPE에 대한 개정판이다. 개정판이라고는 하지만 별개의 책이라고 해도 무리가 없을 정도로 다시 쓰여졌다. 그러나 XP란 무엇인가와 XP가 추구하는 것은 무엇인가에 대한 설명서라는 초판의 목적에는 여전히 충실하다.
XP에 대해서 개괄적으로 설명하는 첫장(What is XP?)으로 시작하며, XP를 구성하는 요소 및 기법에 대해서 설명하는 내용들(Exploring XP)과 XP의 바탕이 되는 철학을 설명하는 내용들(Philoshophy of XP)로 구성되어 있다.
XP는 사회적 변화에 관한 것이다(XP is about social change)라는 책의 첫 문장처럼 초판에 비해서 개정판은 기법 혹은 기술에 대한 비중을 줄었고, 철학과 태도에 대한 내용의 비중이 늘었다. Test-First Programming과 같은 특정 기법의 선호도에 대한 논쟁이 XP가 궁극적으로 추구하는 바에 대한 주목을 분산시키는 것을 방지하기 위함이다. 초판 이 후 12개 Practices 중 몇 개를 실제로 사용하는 가를 놓고 XP를 하느냐 하지 않느냐를 판단하던 우스운 상황이 개정판 이후에는 없을 것이다.
XP가 작은 규모의 프로젝트 뿐만 아니라 큰 규모의 프로젝트에도 적용할 수 있다고 명시한점과 요구사항이 불확실하고 변경이 잦은 프로젝트 뿐만 아니라 요구사항이 비교적 명확한 프로젝트에도 적용할 수 있다고 한 점이 초판과 비교해서 크게 변경된 부분이다.
그리고 기법을 기본(Primary)과 부가(Corollary)로 구분하였다. 부가적인 기법은 기본 기법에 익숙하지 않은 상황에서는 사용하기 어렵다는 것을 명확하게 하였다.
C3 프로젝트에 대한 비교적 자세한 서술과 테일러즘과 TPS(Toyota Production System)에 내용, 그리고 Offshore 개발에서의 XP의 적용 가능성에 대한 내용들도 추가되었다.
결과적으로 초판에 비해서 개정판 내용의 완성도가 더 높음에도 파급 효과는 크지 않았다. 이는 Kent Beck이 책에서 지적한대로 초판에서는 낮설던 내용들의 상당수가 5년이 지난 지금에는 현장에서 일상적으로 사용되고 있는 상황에 기인할 것이다. XP의 새로운 점을 기대하기 보다는 잘 정리된 XP의 설명서를 읽는다는 점에서 접근하는 것이 좋을 것이다.
4. Crystal Clear : A Human-Powered Methodology for Small Teams
Alistaire Cockburn은 프로젝트의 규모(주로 개발자의 수로 측정)와 위험도에 따라서 다양한 방법론이 필요하다고 보며 이들을 Crystal 방법론 집합으로 지칭한다. 이중 규모가 작고(8명 이하) 위험도가 낮은 방법론을 Crystal Clear로 지칭한다. 또한 이런 세분화된 방법론도 프로젝트 초기에 그 프로젝트의 상황에 맞게 변경되어야 한다고 본다. 이 점이 다른 Agile 방법론들과의 큰 차이이다. 따라서 그는 XP나 Scrum 등의 방법론 주창자들에 비해서 Methodology Shaping을 중시한다.
Agile 방법론에 대한 설명이나 입장을 밝힌 Agile Software Development라는 책의 연장선에서 Crystal Clear라는 구체적인 방법론에 대한 기술서이다. 그러나 그 양식은 기존의 방법론의 표현 방식과 많이 다른데 이는 절차보다는 특질(Properties)를 중시하는 Cockburn의 생각의 반영이다.
Crystal 방법론 집합은 7개의 특질을 이해하는 것이 중요하며, 이 중 마지막 특질(Technical Environment with Automated Tests, Configuration Management, and Frequent Integration)은 The Pragamtic Programmer에서 더 자세하게 설명되고 있다.
Crystal Clear에서는 Frequent Delivery, Reflective Improvement, Osmotic Communication 특질은 항상 적용해야 하며 나머지는 선택사항이다. 실제로 방법론의 기본 줄기는 이 세가지 특질을 충족시키는데 충실하다. Frequent Delivery를 가능하게 하기 위해서 다양한 규모의 사이클로 프로젝트가 반복적으로 계획되며, 각 사이클의 마지막에는 Reflective Improvement를 가능하게 하는 활동들이 있다. 그리고 문서나 보고 또는 회의에 의한 의사소통 보다는 비공적식적인 일상적인 의사소통을 중시한다.
보통의 방법론 책자와 비교해서는 괜찮지만 전체적으로 약간은 지루한 부분이 존재한다. 산출물에 대해서 다루는 부분(Examined - The Work Products)과 사례 부분(Tested - A Case Study)이 이에 해당한다.
따라서 처음부터 책 전체를 읽기 보다는 2장 Applied(The Seven Properties)과 3장 In Practice(Strategies and Techniques)를 우선 읽고 필요에 따라서 다른 부분을 읽는 것이 효과적일 것으로 판단된다.
5. Agile Project Management
Jim Highsmith는 프로젝트 관리라는 측면에서 Agile 방법론에 대해 서술했다. 그의 말대로 현장에서 좋은 프로젝트 관리자란 야근을 하는 개발자를 위해서 피자를 준비하는 사람일 것이다. 프로젝트 관리자가 그 이상을 하려고 한다면 무가치한 짐을 개발자에게 지운다고 생각하는 것이 일반적인 개발자들의 생각이다. Jim Highsmith는 이런 수동적인 혹은 부정적인 의미로 다가오는 프로젝트 관리를 Agile이라는 측면에서 좀더 긍정적이고 능동적인 측면으로 변화시키려 한다.
우선 고객과 제품(Customers and Products), 그리고 리더십과 협업(Leadership-Collaboration)의 측면에서 Agile 방법론의 원칙을 제시한다. 그리고 개발 단계(Phase)를 Envision, Speculate, Explore, Adapt and Close로 구분하고 각 단계에서 적용할 수 있는 기법(Practices)들에 대해서 설명한다.
다른 Agile 방법론에 비교할 때 프로젝트 관리에 대한 초점을 맞추는 특징과 함께, 가치를 창출하기 위해서 어떤 제품을 탐색하고 개발할 것인가와 관련한 부분에 많은 초점을 두고 있기도 하다.
6. 정리하며
3권의 책은 저자의 특징에 따라 Agile 방법론을 바라보는 상이한 관점에서 쓰여졌다. Kent Beck은 프로그램머의 입장에서, Alistair Cockburn은 방법론 전문가의 입장에서, Jim Highsmith는 비즈니스 컨설턴트의 입장에서 Agile 방법론에 접근했다. 앞으로는 Agile 방법론을 현장에서 적용하면서 입증한 혹은 발견한 내용들과 테스트와 같은 작은 영역에서의 좀더 전문적인 Agile 방법론에 대한 적용을 중심으로 논의가 이루어질 것이다.
1. 개요
Addison-Wesley에서는 Agile 방법론(통상적인 방법론 이상을 의미)과 관련한 다양한 유형의 책을 출판하고 있다. 이 출판사는 이런 유형을 두개 시리즈로 분류하고 있다.
The XP Series
Kent Beck이 편집자로 있고, XP(eXtreme Programming) 방법론과 관련한 내용을 다루는 시리즈.
- Extreme Porgramming Explained
- Extreme Programming Installed
- Planning Extreme Programming
The Agile Software Development Series
Alistair Cockburn, Jim Highsmith가 편집자로 있고, Agile 방법론과 관련한 다양한 내용을 다루는 시리즈. Agile의 철학에 대한 설명을 기본으로, DSDM, Lean, Crystal 등의 방법론을 다루기도 하고, Use Case, 형상관리 등의 기법을 다루기도 함. 사실상 XP를 제외한 Agile에 대한 모든 것을 다루는 시리즈로 간주할 수 있음.
- Agile Software Development
- Agile Software Development Ecosystems
- Agile and Iterative Development: A Manager’s Guide
- Writing Effective Use Cases
2004년까지 별도로 진행되던 XP/Agile Universe와 Agile Development Conference가 2005년부터 Agile 2005 Conference로 통합된 것처럼 더 이상 두 시리즈의 구분에 큰 의미는 없다. XP를 중심으로 하던 논의가 이제는 Agile이라는 폭 넓은 화두를 중심으로 해서 진행되고 있는 특징을 반영할 뿐이다.
이 두 시리즈에서 다루어지지 않는 대표적인 Agile 관련 내용으로 Scrum, FDD(Feature Driven Development) 방법론이 있다. 그리고 Addison-Wesley 외에 Agile과 관련한 대표적인 시리즈는 Andy Hunt와 Dave Tomas가 편집자로 있는 The Pragmatic Programmer를 들 수 있다.
아래는 Kent Beck의 Extreme Programming Explained(이하 XPE) 개정판과 Alistaire Cockburn의 Crystal Clear, Jim Highsmith의 Agile Project Management(이하, APM) 등에 대한 서평이다.
2. Agile 방법론
Agile 방법론을 특정 기법이나 도구의 사용 여부로 다른 방법론과 구분하는 것은 유익하지는 않다. XP의 12 기법을 모두 적용한다고 그것이 바로 Agile적이다라도 단정지을 수는 없다. 그보다는 Agile Alliances’s Manifesto에 대한 충실도가 중요하다. 결국 신뢰에 바탕한 관계지움에 대한 고민이 Agile의 척도여야 한다.
아래의 책들은 다양한 기법에 대해 설명하고 있는데 이들에만 집중하면 큰 흐름을 잃어버리는 우를 범할 수 있다. Agile 자체에 대한 고민을 중심으로 저자들이 제시하는 기법에 집중을 해야 그 기법에 대한 이해도를 높일 수 있으며 큰 흐름을 받아들일 수 있다.
3. Extreme Programming Explained 2nd
Agile과 XP를 세상에 알린 1999년에 출간된 XPE에 대한 개정판이다. 개정판이라고는 하지만 별개의 책이라고 해도 무리가 없을 정도로 다시 쓰여졌다. 그러나 XP란 무엇인가와 XP가 추구하는 것은 무엇인가에 대한 설명서라는 초판의 목적에는 여전히 충실하다.
XP에 대해서 개괄적으로 설명하는 첫장(What is XP?)으로 시작하며, XP를 구성하는 요소 및 기법에 대해서 설명하는 내용들(Exploring XP)과 XP의 바탕이 되는 철학을 설명하는 내용들(Philoshophy of XP)로 구성되어 있다.
XP는 사회적 변화에 관한 것이다(XP is about social change)라는 책의 첫 문장처럼 초판에 비해서 개정판은 기법 혹은 기술에 대한 비중을 줄었고, 철학과 태도에 대한 내용의 비중이 늘었다. Test-First Programming과 같은 특정 기법의 선호도에 대한 논쟁이 XP가 궁극적으로 추구하는 바에 대한 주목을 분산시키는 것을 방지하기 위함이다. 초판 이 후 12개 Practices 중 몇 개를 실제로 사용하는 가를 놓고 XP를 하느냐 하지 않느냐를 판단하던 우스운 상황이 개정판 이후에는 없을 것이다.
XP가 작은 규모의 프로젝트 뿐만 아니라 큰 규모의 프로젝트에도 적용할 수 있다고 명시한점과 요구사항이 불확실하고 변경이 잦은 프로젝트 뿐만 아니라 요구사항이 비교적 명확한 프로젝트에도 적용할 수 있다고 한 점이 초판과 비교해서 크게 변경된 부분이다.
그리고 기법을 기본(Primary)과 부가(Corollary)로 구분하였다. 부가적인 기법은 기본 기법에 익숙하지 않은 상황에서는 사용하기 어렵다는 것을 명확하게 하였다.
C3 프로젝트에 대한 비교적 자세한 서술과 테일러즘과 TPS(Toyota Production System)에 내용, 그리고 Offshore 개발에서의 XP의 적용 가능성에 대한 내용들도 추가되었다.
결과적으로 초판에 비해서 개정판 내용의 완성도가 더 높음에도 파급 효과는 크지 않았다. 이는 Kent Beck이 책에서 지적한대로 초판에서는 낮설던 내용들의 상당수가 5년이 지난 지금에는 현장에서 일상적으로 사용되고 있는 상황에 기인할 것이다. XP의 새로운 점을 기대하기 보다는 잘 정리된 XP의 설명서를 읽는다는 점에서 접근하는 것이 좋을 것이다.
4. Crystal Clear : A Human-Powered Methodology for Small Teams
Alistaire Cockburn은 프로젝트의 규모(주로 개발자의 수로 측정)와 위험도에 따라서 다양한 방법론이 필요하다고 보며 이들을 Crystal 방법론 집합으로 지칭한다. 이중 규모가 작고(8명 이하) 위험도가 낮은 방법론을 Crystal Clear로 지칭한다. 또한 이런 세분화된 방법론도 프로젝트 초기에 그 프로젝트의 상황에 맞게 변경되어야 한다고 본다. 이 점이 다른 Agile 방법론들과의 큰 차이이다. 따라서 그는 XP나 Scrum 등의 방법론 주창자들에 비해서 Methodology Shaping을 중시한다.
Agile 방법론에 대한 설명이나 입장을 밝힌 Agile Software Development라는 책의 연장선에서 Crystal Clear라는 구체적인 방법론에 대한 기술서이다. 그러나 그 양식은 기존의 방법론의 표현 방식과 많이 다른데 이는 절차보다는 특질(Properties)를 중시하는 Cockburn의 생각의 반영이다.
Crystal 방법론 집합은 7개의 특질을 이해하는 것이 중요하며, 이 중 마지막 특질(Technical Environment with Automated Tests, Configuration Management, and Frequent Integration)은 The Pragamtic Programmer에서 더 자세하게 설명되고 있다.
Crystal Clear에서는 Frequent Delivery, Reflective Improvement, Osmotic Communication 특질은 항상 적용해야 하며 나머지는 선택사항이다. 실제로 방법론의 기본 줄기는 이 세가지 특질을 충족시키는데 충실하다. Frequent Delivery를 가능하게 하기 위해서 다양한 규모의 사이클로 프로젝트가 반복적으로 계획되며, 각 사이클의 마지막에는 Reflective Improvement를 가능하게 하는 활동들이 있다. 그리고 문서나 보고 또는 회의에 의한 의사소통 보다는 비공적식적인 일상적인 의사소통을 중시한다.
보통의 방법론 책자와 비교해서는 괜찮지만 전체적으로 약간은 지루한 부분이 존재한다. 산출물에 대해서 다루는 부분(Examined - The Work Products)과 사례 부분(Tested - A Case Study)이 이에 해당한다.
따라서 처음부터 책 전체를 읽기 보다는 2장 Applied(The Seven Properties)과 3장 In Practice(Strategies and Techniques)를 우선 읽고 필요에 따라서 다른 부분을 읽는 것이 효과적일 것으로 판단된다.
5. Agile Project Management
Jim Highsmith는 프로젝트 관리라는 측면에서 Agile 방법론에 대해 서술했다. 그의 말대로 현장에서 좋은 프로젝트 관리자란 야근을 하는 개발자를 위해서 피자를 준비하는 사람일 것이다. 프로젝트 관리자가 그 이상을 하려고 한다면 무가치한 짐을 개발자에게 지운다고 생각하는 것이 일반적인 개발자들의 생각이다. Jim Highsmith는 이런 수동적인 혹은 부정적인 의미로 다가오는 프로젝트 관리를 Agile이라는 측면에서 좀더 긍정적이고 능동적인 측면으로 변화시키려 한다.
우선 고객과 제품(Customers and Products), 그리고 리더십과 협업(Leadership-Collaboration)의 측면에서 Agile 방법론의 원칙을 제시한다. 그리고 개발 단계(Phase)를 Envision, Speculate, Explore, Adapt and Close로 구분하고 각 단계에서 적용할 수 있는 기법(Practices)들에 대해서 설명한다.
다른 Agile 방법론에 비교할 때 프로젝트 관리에 대한 초점을 맞추는 특징과 함께, 가치를 창출하기 위해서 어떤 제품을 탐색하고 개발할 것인가와 관련한 부분에 많은 초점을 두고 있기도 하다.
6. 정리하며
3권의 책은 저자의 특징에 따라 Agile 방법론을 바라보는 상이한 관점에서 쓰여졌다. Kent Beck은 프로그램머의 입장에서, Alistair Cockburn은 방법론 전문가의 입장에서, Jim Highsmith는 비즈니스 컨설턴트의 입장에서 Agile 방법론에 접근했다. 앞으로는 Agile 방법론을 현장에서 적용하면서 입증한 혹은 발견한 내용들과 테스트와 같은 작은 영역에서의 좀더 전문적인 Agile 방법론에 대한 적용을 중심으로 논의가 이루어질 것이다.
The key factor in becoming agile is realizing that principles are most importanat than practices - that what we believe drives what we do.Agile Project Management, 261p
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. 참고 자료
소프트웨어 비즈니스에서 오픈 소스가 갖는 시사점을 밝히고 그 활용 영역을 제시한다.
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. 참고 자료
- The Open Source Definition
- 오픈 소스의 경제학적 의미와 진흥 정책의 필요성, 최은창, 마이크로소프트웨어 2004년 1월
- 독점 소프트웨어 vs. 오픈 소스「뜨거운 역할 논쟁」
- TOGAF, The Open Group Architecture Framework
- COTS-Based Systems (CBS) Initiative
- Open Source's Lessons for Historians
- The Success of Open Source
- Open Sources: Voices from the Open Source Revolution
- Free Software vs. Open Source
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월 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-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?
비즈니스 애플리케이션
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
고전...
광의로 반복적 개발이란 무엇인가를 반복하면서 시스템을 개발하는 걸 의미한다. 이렇게 넓은 의미에서 본다면 단순히 코딩/단위 테스트가 반복되는 개발도 반복적이다. 그래서 반복적 개발이 가치를 지니려면 반복의 대상이 되는 활동의 폭 혹은 수에 대한 협의의 의미 부여가 필요하다.
논의의 단순화를 위해 시스템 개발이 요구수항 수집, 요구사항 분석, 설계, 구현(단위 테스트를 포함한), 테스트, 배치 등의 활동으로 구성된다고 가정하자.
앞 에서 예로 든 반복은 구현이라는 단위 활동 내에서 이루어질 뿐이다. 반복적 개발이 가치가 있으려면 하나의 활동 내에서가 아닌 여려 활동들이 결합하여 반복되어야 한다. 이 때 활동들의 결합은 근접한 것(설계와 구현, 요구사항 수집과 요구사항 분석 등) 사이에서 이루어지는 것이 통상적이다.
따라서 반복적 개발이란 요구사항 수집, 요구사항 분석, 설계, 구현, 테스트, 배치 등의 활동이 둘 이상으로 결합되어 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를 참조하면 될 듯
함.
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. 책
A Pattern Language (Christopher Alexander)
http://www.amazon.com/exec/obidos/tg/detail/-/0195019199/qid=1095828690/sr=8-1/ref=pd_csp_1/102-2278079-3987351?v=glance&s=books&n=507846
http://www.amazon.com/exec/obidos/tg/detail/-/0195019199/qid=1095828690/sr=8-1/ref=pd_csp_1/102-2278079-3987351?v=glance&s=books&n=507846
읽을 여유 없음...
The Timeless Way of Building (Christopher Alexander)
http://www.amazon.com/exec/obidos/tg/detail/-/0195024028/qid=1095828690/sr=8-2/ref=pd_csp_2/102-2278079-3987351?v=glance&s=books&n=507846
읽을 여유 없음...
Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)
http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/qid=1095833214/sr=8-1/ref=pd_csp_1/102-2278079-3987351?v=glance&s=books&n=507846
Pattern Hatching (John Vlissides)
http://www.amazon.com/exec/obidos/tg/detail/-/0201432935/qid=1095833762/sr=1-27/ref=sr_1_27/102-2278079-3987351?v=glance&s=books
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=*
Core J2EE Patterns, 2nd (Deepak Alur, Dan Malks, John Crupi)
http://www.amazon.com/exec/obidos/tg/detail/-/0131422464/ref=pd_sim_books_5/102-2278079-3987351?v=glance&s=books
http://www.amazon.com/exec/obidos/tg/detail/-/0131422464/ref=pd_sim_books_5/102-2278079-3987351?v=glance&s=books
Patterns of Enterprise Application Architecture (Martin Fowler)
http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/ref=pd_sim_books_2/102-2278079-3987351?v=glance&s=books
http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/ref=pd_sim_books_2/102-2278079-3987351?v=glance&s=books
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를 구매하기 매우 어려운 경우에는 Eclipse나 NetBeans와 같은 오픈 소스 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를 사입함으로써 소스 코드에는 일체 영향을 주지 않으면서 원하는 모니터링을 수행할 수 있다. 이를 가능하게 하는 솔루션으로는 P6SPY와 JDBInsight 등이 있다. 이중 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. 참고 자료
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를 구매하기 매우 어려운 경우에는 Eclipse나 NetBeans와 같은 오픈 소스 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를 사입함으로써 소스 코드에는 일체 영향을 주지 않으면서 원하는 모니터링을 수행할 수 있다. 이를 가능하게 하는 솔루션으로는 P6SPY와 JDBInsight 등이 있다. 이중 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. 참고 자료
- The Top 10 Elements of Good Software Design
- Hot Deployment ? How hot is this!
- Advanced Classloading in J2EE
- Understanding J2EE Application Server Class Loading Architectures
- Clustering and Load Balancing in Tomcat 5, Part 1
- Approaches to Mocking
- J2EE Application Development?What a Professional Architect Really Thinks
- Iterative Development: The Use of J2EE Best Practices
2004-04-20
Learning Organizations and Software Developer
출처 : IEEE Software March/April 2004
URL : http://www.computer.org/software/homepage/2004/s2fte.htm
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?]
냉소적인 Martin Fowler의 정의를 옆으로 비켜 놓는다면, 이 글을 GoF의 한 명인 Ralph Johnson의 생각을 Martin Fowler가 정리하는 혹은 빌리는 방식으로 진행됩니다.
우선 Ralph Johnson은 아키텍쳐가 정의되는 범주를 전체 환경이 아닌 개발자가 생각하는 환경으로 묶습니다.
Ralph Johnson이 든 예를 확장하면, 소프트웨어를 J2EE로 구현할지? .NET으로 구현할지는 후자의 정의로는 아키텍처의 구성요소가 되지만, 두전자의 정의를 따르면 아키텍처의 구성요소가 아닌 것이 됩니다.
혹시 Presentation Layer, Business Layer, Integration Layer 등을 칠판에 그리고는 이게 우리가 개발할 시스템의 아키텍처라고 하시지는 않습니까? 뻔한 그림을 가지고. 끊임없이 지루하게 반복되는 교수의 지껄임처럼.
[The architect's roles]
몇 일간 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. 여담으로 마지막에 최종적으로 나오는 코드를 통해 각주가 필요없는 코드란 무엇인가를 알 수 있습니다..
작년에 인터넷을 통해서 대충 보긴 했는데, 오늘 책을 따라가면서 이클립스로 코딩을 하면서 다시 읽었는데 으시시(?)하군요. 영화 [유주얼 서스펙트]나 [식스 센스]와 같은 마지막 반전이 오랜만의 독서의 졸음을 확 달아가게 합니다.
둘은 볼링점수를 계산하는 프로그램을 작성합니다. 둘이서 함께 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. 여담으로 마지막에 최종적으로 나오는 코드를 통해 각주가 필요없는 코드란 무엇인가를 알 수 있습니다..
Subscribe to:
Posts (Atom)