로컬 개발환경 구성

개발 프레임워크를 구현하기 전에 개발환경을 준비해야 한다. 이 환경은 SWA가 프레임워크를 개발할 때도 사용하겠지만, 이걸 그대로 개발자에게 배포해서 실제 업무프로그램을 개발할 때도 사용해야 하니까 처음부터 가볍고 편리하게 사용할 수 있도록 하는 것이 중요하다. 결국 개발환경이 개발생산성에도 영향을 미친다는 의미다.

 

Java 버전 선택

WAS의 버전

가장 먼저 선택할 것은 Java 버전이다. 되도록 최근에 나온 버전 중에 버그픽스 버전이 높은 것이 좋고, WAS의 버전과 동일한 버전을 로컬 개발환경에서 선택해야 한다. 그래야 개발된 소스를 빌드해서 WAS에 배포했을 때 클래스파일의 버전문제가 발생하지 않는다.

인터페이스 대상의 버전

또 하나 Java 버전을 결정할 때 고려해야 하는 것은 인터페이스 대상 시스템이다. 인터페이스 대상 시스템과 네트워크로 통신할 경우, HTTP나 단순소켓의 경우는 문제가 거의 없지만 HTTPS 같은 SSL 통신을 한다면 Handshake가 원활하게 하려면 같은 버전을 선택하는 것이 좋다. 만약 다른 버전을 사용하게 된다면 프레임워크 구현 후에 꼭 PoC를 수행해서 문제가 없음을 확인해야 한다.

Java 종류

오라클이 사실상 Java를 유료화시키면서 무료로 Java를 사용하려면 OpenJDK를 사용해야 한다. OpenJDK도 여러 업체에서 만들기 때문에 적당한 업체의 버전을 선택해야 한다.

 

통합개발환경(IDE) 구성

IDE 제품 선택

다음으로 통합개발환경(IDE)을 선택해야 하는데 일반적으로는 이클립스를 사용하는 것이 좋다. 물론, IntelliJ 같은 좋은 유료 도구가 있긴 하지만, 통합개발환경 선택에서 가장 먼저 고려해야 할 것은 모든 개발자가 사용해야 한다는 것이다. 모든 사용자가 유료 도구를 사용할 수 있을만큼 프로젝트 비용이 충분하다면 좋겠지만, 아직까지 그런 프로젝트를 본 적이 없기 때문에 보통은 이클립스를 사용한다. 유료 개발도구를 사용하는 돈 많은 프로젝트에 투입되었거나 회사에 입사했다면.... 부럽다.

IDE 설치경로 고정의 장점

요즘은 개발도구를 모두 압축한 파일 하나만 전달하고 그것을 특정 경로에 압축만 풀면 개발환경 준비(IDE, JDK, 빌드도구, WAS 등)가 모두 끝나는 것이 업계 표준이 되었다.
이러한 방식의 장점은 개발환경 전달이 단순화되는 것 외에도 SWA에게 아주 중요한 것이 하나 더 있다. 개발자가 개발 중에 어떤 문제가 생겨서 SWA에게 도움을 요청했을 때 찾아 봐야 하는 폴더도 모든 개발자에게 동일하다는 뜻이다. 개발자마다 다른 경로에 다른 방식으로 개발환경을 설정하면 SWA가 문제를 찾을 때마다 일일이 설치프로그램을 찾거나 개발자가에 물어 봐야 한다. 하지만, 설치경로가 동일하면 SWA는 다른 것을 고민할 필요 없이 바로 의심가는 폴더를 찾아서 파일을 열어 볼 수 있어서 시간을 절약할 수 있다.

JDK 32bit or 64bit

일단 이클립스를 선택했지만, 여기서도 다양한 버전이 있기 때문에 어떤 버전을 선택할지 결정해야 한다. 일단, 개발자 윈도우 OS에 따라서 32bit인지 64bit인지를 선택해야 한다. 요즘 대부분이 64bit를 사용하기 때문에 문제는 없을 것이다.

IDE 설치 드라이브

다음으로 개발환경을 설치할 디스크 드라이브를 선택하는 것이다. 이것은 무조건 C드라이브를 추천한다. 개발환경을 구성할 때 각종 관련 프로그램이나 파일의 경로를 절대경로를 입력하게 된다. 그래서, 개발환경을 구성할 때도 모든 개발자에게 예외 없이 적용할 수 있는 디스크 드라이브를 사용해야 한다. 보통은 C드라이브 외에 D드라이브도 달려 있지만 가끔씩 D드라이브가 없는 경우도 있고, 보통 C드라이브에 가장 빠른 디스크를 사용하기 때문에 프로그램 실행 및 읽기/쓰기 속도가 빠른 C드라이브가 최적의 선택이다.

IDE 최적화

통합개발환경(IDE)에 대한 최적화도 필요하다. Spell Check나 각종 Validation이 켜져 있는 경우, 코드를 입력할 때나 개발툴을 시작할 때마다 내용에 대한 각종 체크를 수행하면서 굉장히 많은 시간을 소모하기 때문에 개발을 바로 하지 못 하고 기다려야 한다. 이런 기능들은 잘 확인해서 꼭 필요한 기능 외에는 모두 꺼 놓는 것이 좋다. 나 같은 경우는 일단 거의 모두 꺼 놓고 개발하다가 문제가 생기면 하나씩 켜는 방식으로 한다. 사실 아직까지 Spell Check와 Validation을 모두 꺼서 문제된 경우는 없었다.

Spring Tool Suite

스프링 프레임워크를 사용한다면 이클립스에 스프링 프레임워크 플러그인을 설치해서 사용하는 것보다는 STS(Spring Tool Suite)를 사용하는 것을 추천하고 싶다. 물론 스프링 프레임워크 플러그인도 추천 이클립스 버전을 제시하기 때문에 거의 문제가 발생할 가능성은 적지만, 이클립스가 마이너 업그레이드 등이 되면서 변경이 생겨 플러그인과 문제가 생길 가능성이 있다. 하지만, STS는 이클립스와 스프링 플러그인을 붙여서 나름 최적화시킨 버전이기 때문에 이클립스에 스프링 플러그인을 설치한 것보다 안정적일 가능성이 높다.

화면개발툴 플러그인

여기에 또 다른 이클립스 플러그인을 설치할 일이 생길 수도 있다. 화면구현을 JSP가 아닌 별도 화면 클라이언트 툴을 사용할 수도 있다. 이런 툴이 이클립스 플러그인 형태로 개발툴을 제공하는 경우도 있고 별도 개발툴 프로그램을 제공할 수도 있다. 별도 프로그램을 제공하는 경우는 그냥 설치해서 사용하면 되겠지만 이클립스 플러그인 형태일 경우는 서버 개발환경으로 사용하는 이클립스에 설치할지, 아니면 그와 별도의 이클립스를 구성해서 사용할지 결정이 필요하다.
일단, 화면 개발툴의 플러그인도 추천하는 이클립스 버전이 있을 것이다. 이렇게 이클립스 플러그인들이 늘어날수록 사용할 수 있는 이클립스 버전에 제약이 늘어나고, 가끔은 모든 플러그인을 만족하는 이클립스 버전이 없을 수도 있다. 그리고, 플러그인이 늘어날수록 이클립스가 무거워지고 플러그인들간의 충돌로 이클립스가 죽을 수도 있다. 그래서, 화면개발툴 플러그인처럼 무거운 것은 업체에서 추천하는 이클립스 버전에 별도의 프로세스로 띄워서 사용하는 것을 추천한다. 요즘은 대부분 개발자가 8GB RAM에 듀얼모니터를 사용하기 때문에 개발툴 2개 띄우고 테스트용 화면까지 보면서 테스트해도 무리는 없을 것이다.
화면 개발툴을 사용할 필요가 없는 개발자를 위해서 화면 개발툴 플러그인이 설치된 IDE와 플러그인이 없는 가벼운 IDE를 따로 제공하는 것도 방법이 될 수 있다.

WAS 플러그인

로컬 테스트를 위한 이클립스용 WAS 플러그인도 필요하다. WAS 버전이 결정되어 있기 때문에 이 버전에 맞는 플러그인을 설치해서 사용하면 되는데 여기도 보통 추천 이클립스 버전이 있으므로, 여기서도 이클립스 버전에 대한 제약이 생긴다. WAS 플러그인을 설치한 후엔 반드시 debug 모드로 동작이 되는지도 확인해야 한다. WAS의 debug 모드는 프로그램 버그를 찾는 데 있어 정말 위대한 기능이기 때문에 꼭 확인해야 한다.
가끔씩은 프로젝트에서 사용할 WAS와 동일한 플러그인을 사용하지 않을 수도 있다. WAS의 기능이 아주 많아서 한번 기동할 때마다 아주 오래 기다려야 하는 경우도 있을 경우에는 설정에서 사용하지 않는 기능을 비활성화시키는 경우도 있고, 그래도 안 되는 경우는 로컬 개발환경에만 비슷한 기능을 제공하는 가벼운 WAS와 플러그인을 사용하는 경우도 있다. 혹은, WAS 플러그인이 추천하는 이클립스의 버전이 다른 플러그인과 너무 동떨어져 도저히 맞출 수가 없거나, WAS 플러그인이 꼭 필요한 기능을 제공하지 않을 경우에도 다른 WAS의 플러그인으로 대체할 수 있다. 이렇게 로컬 개발환경의 WAS와 서버의 WAS가 다를 경우에는 개발서버에서 면밀한 테스트를 수행해서 혹시 WAS간의 구현 차이에서 발생할 수 있는 오류의 발생을 방지해야 한다.

형상관리 플러그인

소스형상관리를 위한 플러그인도 필요하다. 이것은 미리 형상관리서버를 설치하고, 플러그인에서 여기에 연결하는 테스트까지 완료해야 한다. 개발자에게 개발환경을 배포할 때는 형상관리 플러그인에 저장된 패스워드를 초기화하거나 테스트 때 사용한 형상관리서버의 계정에 대한 패스워드를 바꿔 놓아야 한다. 배포된 개발환경에서 바로 형상관리서버에 자동으로 로그인이 되면 개발자들은 계정정보를 변경하지 않고 그냥 쓰기 때문에 나중에 소스를 commit한 개발자를 찾기가 어려워진다.

기타 플러그인

프로젝트에서 소스 정적분석에 사용할 툴(PMD 등)도 설치해서 제공한다.
이외에 Maven이나 Ant 등의 빌드툴도 필요할 경우 설치하고, Maven을 사용한다면 Local Repository 등도 설정이 필요하다.

 

 

1. 소프트웨어 아키텍트란?

2. 요구사항 조사

3. 소프트웨어 아키텍처 설계

4. 개발 프레임워크 설계

5. 로컬 개발환경 구성

6. 개발프레임워크 준비

7. 개발가이드 작성 및 개발자 교육

8. 개발단계에서의 개발자 지원

9. 오픈 준비, 오픈, 안정화