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
