#자바를 이용한 웹 서버 개발 환경 이해하기.

이번 ‘휴먼디자인프로젝트'를 하면서 가장 먼저 해야 하는 것은 바로 Github를 통한 협업이 가능한 로컬 개발 환경 구축이었다. 3명의 팀원이 동시에 개발을 진행해야 했기 때문이다.


일단 웹 서버는 자바를 기반으로 만들기로 했다. 배경 지식이 전무한 상태에서 제대로 될 리는 없었다. 일단 이전처럼 개발환경 세팅과 관련한 책을 찾았고 그렇게 발견한 책이 ‘Head First Servlet & JSP”였다. 일단 이 책을 적어도 1주일동안 읽고 공부하기로 팀원들과 계획을 세웠다.


하지만 그 계획은 제대로 이루어지지 않았다. 어느 정도 책을 읽고나면 로컬 개발 환경을 구축할 수 있을 거라는 막연한 생각을 했었지만, 책을 아무리 읽어도 도저히 감은 잡히지 않았다.


결국 NEXT의 조영호 교수님께 로컬 개발 환경과 관련하여 도움을 받기로 했다. 


스터디가 시작되면서 교수님의 자바 웹 서버와 Servlet, JSP에 대한 관계는 다음과 같은 한 문장이었다.


자바를 통해 웹 서버를 개발하려면 정해진 룰에 따라야 한다는 것이다. 


그에 관련한 룰에 대한 스펙이 바로 서블릿과 JSP였다. 우리 팀은 마치 서블릿과 JSP만 알면 다 될 거라 생각하고 ‘Head First’만 매달리고 있었으니 로컬 개발 환경 설정이 막연하게 느껴진 것은 당연했다.


무언가를 공부해야 한다면, 정말 그에 알맞은 자료나 책을 조사하고 선택하는 것이 가장 중요한 일인데도 불구하고 이를 잊고 너무 태만하게 공부한 탓에 팀 전체에 아까운 시간을 날리게 된 셈이다.


구체적인 서블릿이나, JSP의 스펙을 이번 포스트에서는 다루지 않는다. 어차피 ‘Head First Servlet & JSP’에서 매우 상세하게 다루고 있기 때문이다. 기타 디렉토리 구조 가이드도 역시 마찬가지이다.


# 로컬 개발 환경에 대한 메이븐의 필요성

각각의 로컬 개발 환경을 가지게 될 개발자들의 컴퓨터에는 컨테이너라고 부르는 Apache tomcat을 설치하게 된다. 그러다 보니, 컴퓨터 별로 개발 환경의 상세 디렉토리 구조는 달라지기 마련이다. 하지만, 매우 기본적인 뼈대 디렉토리는 (webapps나  sample과 같은) 기본적으로 같다. 약속이기 때문이다.


그리고 각각의 페이지(login이나 logout)에 대해 해당하는 기능을 구현하는 자바로 구현한, 즉 서블릿을 갖게 된다. 그러한 서블릿들을 컴파일하여 생성된 클래스 파일들은 tomcat 내의 디렉토리로 옮겨주면 된다. (이것이 바로 흔히 개발 서버에서 불리는 ‘배포’라는 작업이다.) 하지만, 매번 컴파일을 할 때마다 생성된 클래스 파일들은 새로이 tomcat에 복사하는 것은 매우 귀찮은 과정이다. 이러한 과정을 자동화 한 도구들은 여러가지가 있지만 이번 프로젝트에 주로 사용하는 것은 ‘이클립스’와 ‘메이븐’이다.


조금 더 자세히 설명해보자.


한 개발자가 자신의 랩탑에 자바 프로젝트를 생성한다. 이 프로젝트 내에는 servlet.java 라는 식의 서블릿을 다수 가지고 있게 될 것이다. 그리고, 필요한 라이브러리 (*.jar)들도 프로젝트 내에 보유하게 된다. 또, WEB-INF라는 디렉토리 내에 web.xml 등의 파일을 만든다.

그리고 컴파일 된 클래스들을 보관하기 위한 임의의 B라는 디렉토리를 생성한다. 이 때, tomcat에 테스트를 하기 위해서는 생성된 클래스 파일들을  tomcat에 복사하기만 하면 된다. 


이렇듯 프로젝트 별로 디렉토리의 구조는 달라질 수 밖에 없게 된다. 이러한 차이점은 협업이나 공유가 이루어지는 환경에서는 큰 단점으로 작용했고, 이로 인해 ‘표준 디렉토리 구조’라는 것을 제정하게 된다.

이러한 표준 디렉토리 구조를 바로 ‘메이븐’이라고 부른다.


메이븐은 빌드 도구이다. 특별한 점이 있다면, 표준 구조가 있다는 점이다. 즉, 메이븐을 통해 빌드를 하게 되면 소스 구조는 모두 같아지게 된다. 메이븐 이전에는 라이브러리를 사용하려면 프로젝트 내에 달아야 했지만, 메이븐을 사용하면 pom.xml의 설정을 통해 필요한 라이브러리도 ‘Maven Repository’에서 자동으로 다운 받아서 사용할 수 있게 된다.


메이븐에는 ‘아르케타입’이라는 것이 존재한다. 자바를 이용해 자주 작업하는 전형적인 프로젝트에 알맞게 디렉토리의 표준 구조를 뜻한다. 

이클립스와 메이븐을 동시에 사용 할 경우, 메이븐에서 이루어지는 각종 빌드 작업들은 이클립스가 자동으로 처리하게 된다. 기본적으로 메이븐을 통해 빌드를 하게 되면 war 파일이 생성이 되고, 이를 tomcat에 설치하는 게 일반적인 과정이었다. 하지만 이클립스의 도입 이후 위의 과정은 전부 자동화되었다. 


pom.xml에는 메이븐 자체의 빌드에 대한 상세 설정이 들어 있지 않다. 왜냐하면, 메이븐 내부적으로 빌드와 관련된 상세 순서나 설정이 이미 내장되어 있기 때문이다. 


기본적으로 메이븐을 통한 프로젝트는 이클립스에서 인식하지 못한다. 이 때, 메이븐 빌드 시, goal로 eclipse:eclipse를 설정하여 이클립스에서도 인식이 되게끔 할 수 있다. 이렇게 된 이유는, 이클립스는 ‘도구’에 불과하기 때문이다. 도구 별로 프로젝트를 인식하는 방법은 달라지기 마련이므로, 메이븐에서 일괄적으로 환경을 설정하여 빌드 할 수 없는 것은 당연하다.


즉, 메이븐이 하는 역할을 요약하면 다음과 같다.


표준적인 디렉토리 구조를 생성한다.

표준적인 빌드 절차(프로세스)를 가지고, 빌드를 수행한다.


개발자가 해야 할 일은 코딩과, 빌드에 필요한 리소스들만 명시해주면 된다.


# 배포와 출시

휴디처럼 여러 명이 팀을 이루어 개발이 이루어지게 될 경우 전체적인 개발 환경은 다음과 같다.


(다수의 개발자(로컬)) — 버전관리시스템(gitHub, svn) — 개발 서버 — 라이브 서버


다수의 개발자들이 개발 및 push한 코드는 gitHub에 쌓이게 된다. 그렇게 쌓인 코드에 대한 테스트나 데모 등은 개발 서버에서 이루어지고, 그러한 작업을 마친 프로젝트는 사용자가 이용할 수 있는 라이브 서버로 이동하게 된다.

이 때, gitHub에 있는 코드를 개발 서버에 전송한 뒤 메이븐으로 빌드를 해서 개발 서버 내의 tomcat에 올리는 작업이 필요하다. 조금 생각해 보면 이러한 작업은 매우 반복적인 작업임을 알 수 있다. 즉, 이러한 작업 또한 자동화 해주는 도구가 필요하다. 이러한 도구를 ‘지속적 통합 툴’, CI라고 부르며 대표적으로 jenkins라는 도구가 있다. 


이전에 박재성 교수님이 메이븐 강의 시간에 말씀 하셨던, 서버에서 빌드가 실패했을 때 알림이 가는 그 빌드의 순간이 바로 이 곳에서 이루어지는 빌드이다.

이러한 도구의 필요성은 협업 환경에서 매우 중요해진다. 다수의 개발자가 코드를 수정하는 만큼, 빌드 실패가 일어났을 때와 그 실패 여부가 개발자에게 알려질 때 까지의 기간은 짧을 수록 팀에게 유리해지기 때문이다.


gitHub에서 개발 서버로 코드를 가져온 뒤, 메이븐을 통해 빌드를 하고, 생성된 war 파일을 tomcat에 올리는 작업을 ‘배포’라고 부른다.

이렇게 배포된 버전 중, 충분한 테스트를 거친 버전은 라이브 서버로 옮겨서 (빌드를 마친 뒤 클래스 파일들을) 라이브 서버 내의 tomcat에 복사하게 된다. 이를 ‘출시’라고 부른다.



개발이라는 과정에는 사람의 노력이 매우 필요한 부분도 많지만, 컴퓨터를 통해 충분히 자동화 할 수 있는 부분들이 있다. 저러한 도구들을 왜, 어떻게 사용되는 지를 이해하면 개발 환경 설정에 대해 좀 더 빠른 이해를 할 수 있지 않을까 하는 생각이 든다.


 #번외: fabric

규모가 큰 서비스의 경우, 라이브 서버가 2대 이상으로 구성되기 마련이다. 이 경우, 각 라이브 서버 간의 통합을 유지하기 위한 도구가 바로 fabric이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 우너효