fender
20k
2020-02-22 11:40:51 작성 2020-02-22 13:56:06 수정됨
2
2843

컴포넌트 중심 개발에 대한 환상과 자바에 남은 흔적


요즘 자바를 처음 공부하는 분들이라면 거의 대부분 기업용 웹 서비스 구축을 목표로 하고 있을 것입니다. 그리고 우리나라의 경우라면, 사실상 예외없이 스프링MVC를 기반 기술로 사용하는 중일 것 같습니다.

그런 분들이라면 어쩌면 가끔씩 자바를 하면서 "도대체 이런 건 왜 필요하지"라는 생각이 드는 경험을 하게 될지 모르겠습니다. 예를들어 웹에 배포할 내용을 war 파일로 압축을 한다던가, web.xml을 복잡하게 기술한다던가 하는 부분은 다른 언어에선 찾아보기 힘든 관행입니다.

아니면 스프링을 쓰면서 @Inject와 @Autowired의 차이가 궁금했을 수도 있고, 또는 탐캣과 웹로직이나 웹스피어 같은 'WAS'의 차이점에 대해 의문을 가진 경험이 있었을 지 모르겠습니다.

전에 비슷한 내용으로 J2EE와 스프링의 관계에 대한 글을 쓴 적이 있으니 보다 자세한 내용이 궁금하신 분들은 참조하시면 좋겠습니다. 오늘은 자바 입문자를 기준으로 왜 자바에 war 파일 같은 컴포넌트 중심 개발의 흔적이 남아있는지에 대해서만 간략하게 이야기해볼까 합니다.

자바가 처음 등장했을 때는 자바를 설계한 사람들에게는 매우 원대한 꿈이 있었습니다. 그리고 아마도 몇 번의 결정적인 오판이 없었다면 지금 쯤 데스크탑부터 게임까지 IT의 모든 분야를 자바가 지배하는 세상이 되었을 가능성도 낮지 않습니다.

이는 엔터프라이즈 자바의 경우도 비슷한데, 특히 당시엔 컴포넌트화 된 개발에 대한 상당한 환상이 있었고, J2EE를 설계한 아키텍트들 또한 최대한 그런 방식의 개발이 가능하도록 스펙을 구상했습니다.

즉, 이들은 자바가 곧 엔터프라이즈 시장을 장악하게 되면 이를 중심으로 큰 컴포넌트 시장이 탄생할 것이라고 상상했습니다. 예를들어 기업 시스템을 구축한다면, 그런 시장에서 게시판 모듈을 사고, 또 다른 회사에서 주문 처리 컴포넌트나 재고 관리 컴포넌트 등을 사서 이를 조합만하면 된다고 생각한 것입니다.

그래서 이러한 컴포넌트 중 웹 프론트엔드는 war라는 압축 형식으로, 그리고 EJB는 jar의 형식으로 판매/배포하고, 최종적으로 이를 모두 'ear'로 묶어서 각 기업의 어플리케이션 서버에 배포하는 방식을 구상합니다.

하지만 이렇게 여러 회사에서 만든 컴포넌트를 조합할 경우, 당연히 사용자나 권한, 혹은 데이터베이스 설정 같은 부분에서 충돌이나 중복 작업이 발생할 수 밖에 없습니다.

예컨대 여러 기업에서 사용하도록 만들어서 판매하는 게시판 컴포넌트의 '관리자'라는 개념이 특정 기업의 어떤 직책에 해당하는지, 그리고 사용하는 데이터베이스 정보는 예를들어 주문 관리 시스템이 사용하는 것과 다른 것인지 같은 문제가 생기는 것입니다.

이를 해결하기 위해 각 컴포넌트를 구성하는 압축 파일 안에는 web.xml이나 ejb-jar.xml 같은 디스크립터(descriptor)라는 메타 정보를 포함하도록 했습니다.

이 경우, 사용자 권한이나 데이터베이스 연결 풀 같은 공통 정보는 어플리케이션 서버 측에서 모두 관리하고, 게시판 컴포넌트를 만드는 업체에서는 web.xml에 추상적으로 '관리자'라는 역할이 필요하다던지, 아니면 '게시판 디비'라는 데이터베이스 연결이 필요하다던지 이름만 명시하게 됩니다.

그렇게 하면 게시판 컴포넌트를 구매한 다음에 디스크립터를 고쳐서 실제 자기 회사의 어플리케이션 서버에 존재하는 권한이나 데이터베이스 같은 리소스와 연결을 하고 배포를 할 수 있습니다.

참 쉽죠? ...그럴리가요.

당연히도, 이런 탁상 공론은 EJB나 JSF 등의 현실과 동떨어진 설계와 맞물려서 극악의 개발 경험을 제공했고, 이는 엔터프라이즈 자바를 중심으로 한 컴포넌트 시장이라는 환상을 깨뜨리는 데 큰 기여를 합니다.

예를들어 처음 EJB 스펙이 나왔을 때는 배포를 위해선 앞서 말한 xml 디스크립터를 3-4개 씩 작성해야했지만, 하이버네이트나 JPA에 해당하는 EJB CMP는 심지어 'order by' 구문 조차 지원하지 않았습니다.

그래서 그런 부족한 부분들은 어플리케이션 서버를 만드는 업체들이 자체적으로 구현해서 제공하기 시작했고, 당연히 이런 내용은 업체마다 방식이 서로 달랐습니다. 가뜩이나 개발과 배포도 복잡한데 배포환경에 따라 호환도 되지 않는다면, 애초에 생각한 '거대한 엔터프라이즈 컴포넌트 시장'이란 건 실현 불가능한 환상임이 명확해 졌습니다.

이로 인해 EJB를 지원하는 이른바 '풀 스택' 어플리케이션 서버의 중요성이 점점 낮아지고, 비즈니스 로직도 컴포넌트화를 고려해서 별도의 EJB 모듈로 분리 배포를 하기 보단 그냥 간편하게 war 파일 안에 웹프론트엔드와 함께 관리하는 방식이 각광을 받게 되었습니다.

그렇게 자바 비즈니스 어플리케이션은 특정 풀 스택 서버 제품이 아닌 탐캣 같은 서블릿 컨테이너에 쉽게 배포할 수 있게 되었으며, 이제는 아예 war 컴포넌트로 배포하는 과정을 생략하고 컨테이너를 포함시켜 바로 구동하는 스프링 부트 같은 접근이 대세로 자리잡습니다.

그러한 추세와 맞물려 마이크로서비스와 같이 다시 비즈니스 로직이나 단위 시스템을 느슨하게 분리해서 배포하는 관행이 떠오른 것을 보면, 결국 비즈니스 로직을 컴포넌트로 분리한다는 엔터프라이즈 자바의 비전 자체는 좋았지만 결국 실무를 무시한 아키텍트들의 탁상공론이 이를 현실화하는데 걸림돌이 되었음을 짐작할 수 있습니다.

국내의 경우 초기엔 EJB를 도입하려는 시도를 했지만 이런 저런 실패를 겪고 스프링 기반으로 기술 통일을 해버렸기 때문에, 아직 해외에선 명맥을 유지하고 있는 J2EE 관련 기술이나 이러한 변화의 과정에 대해 잘 모르는 분들이 많은 것 같습니다.

특히 요즘엔 자바를 배운다면 무조건 스프링MVC부터 시작하기에 이런 부분에 대해 궁금한 분들이 계실 것 같아, 두서없이 생각나는 내용을 조금 정리해보았습니다.

15
8
  • 댓글 2

  • devcrema
    1k
    2020-02-22 13:44:02

    감사합니다. 요런 역사는 언제봐도 재밌는거 같네요 :)

    개발시작할때 getter setter는 왜 쓰는지, MVC에서 service와 component 차이는 무엇이고 어디서 나왔는지 등등

    당연하게 쓰고 있으면서 이해하지 못하고 넘어가는게 많았는데 쓰게된 확실히 배경을 알게되면 좀 더 잘 이해할 수 있는 것 같아요.

  • 멍태희
    519
    2020-02-26 14:38:59

     이 분이 쓴 글 중에서 내가 가장 감명깊게 읽은 글이 있어요


    기술내용보다 자바의 역사를 적은 글이죠


    기술이면 기술, 자바의 역사면 역사를 쫙~~~ 꽤뚫고 계신분이에요

    언젠가 한번 "자바의 역사" 를 현장에서 강의 듣고싶어요

    아님 책으로 ....


    http://local.okjsp.net:8080/article/319416

  • 로그인을 하시면 댓글을 등록할 수 있습니다.