이번 장에서는 아키텍처의 “심플함”이라는 면에서 살펴보자.
왜 심플해야 하는가? 그것은 복잡한 것이 나쁘고 잘못된 것이기 때문이다.

필요이상의 복잡한 아키텍처는 반드시 더 많은 돈과 시간을 요구한다. 또한 이 복잡함은 개발자의 생산성 및 애플리케이션의 성능을 떨어뜨릴 뿐만 아니라 많은 버그의 잠재적인 원인이 된다. XP의 가장 중요한 교훈의 하나는 “가능한한 가장 심플한 것을 하라”이다.

그러면 왜 사람들은 복잡한 아키텍처를 사용하거나 복잡한 구조속에서 애플리케이션을 개발하는가? 내 생각에는 우선 복잡한 기술이 주는 이상적인 그러나 필요로 하지 않는 기능들의 유혹이 있기 때문이다. 아무래도 폼이 나지 않는가? 고객에게 장황한 아키텍처의 다이어그램을 그려가면서 멋진 프레젠테이션을 할 때의 반응은 짜릿한 것이다. 뭔가 대단한 기술을 쓰는 것을 자랑하고 싶을 수도 있다. 덕분에 개발단가나 용역비가 상승되기도 한다. 또는 다른 경쟁업체나 유명업체가 사용하고 있다는 것을 은근히 내세워 고객을 자극하기도 편하다. 두번째는 무지함 때문이다. 그냥 남들이 쓰니까. 그것이 유명하다고 하니까. 유명 세미나나 인터넷 아티클에서 뭔가 멋진 기술이라고 소개하니까. 그러니까 나도 이번 프로젝트에 쓰면 되겠다라는 결론을 내리고 개발자들을 다그쳐 그런 아키텍처를 도입하게 한다. 충분한 사전검증도 없이 말이다.

결국 프로젝트는 갈수록 그 복잡한 기술과 아키텍처로 인해 시간이 지연되고 비용은 올라만 간다. 점점 빠듯한 일정을 감당못한 나머지 아키텍처를 무시하고 땜방식 기술들을 마구 끌어들이기도 한다. 결국 후에 아무도 손 못대는 엉망진창인 걸레시스템을 만들어 놓고 나몰라라 떠나기도 한다.

필요없는 아키텍처의 복잡성은 누구에게나 도움이 되지 않는다. 저자가 많은 세미나나 컨퍼런스, 포럼등에서 많난 유명 아키텍트나 컨설턴트들은 J2EE의 기존 아키텍처로 수행한 프로젝트들에서 다 동일한 문제점을 안고 고생을 하거나 실패했던 경험이 있음을 고백했다고 한다.

J2EE 아키텍처의 복잡성은 어디서 기인하는가?

첫째는 필요없는 EJB의 사용이다. EJB는 매우 복잡한 기술이고 역시 복잡한 요구사항이나 기능에만 적합하다.

둘째는 분산객체(distributed object) 기술이다. 분산객체 기술은 최첨단 고급기술의 대명사가 아닌가. 하지만 이 분산객체 기술은 장점보다 단점이 더 많다. 가장 중요한 이슈는 역시 성능이다. 성능은 확장성(scalability)에 반비례하기 때문에 확장성을 위해서 일부 성능을 손해보아야 한다는 것이 그간의 정설이다. 하지만 정말 그런가 확인해 봤는가? 확장성을 위해서라는 이유로 무시하기엔 분산객체기술의 성능은 너무나도 형편없다. 게다가 분산객체는 OO의 장점을 많이 포기해야 한다. 게다가 그 불편한 TO(Transfer Object)를 과다하게 필요로 한다. 결국 분산객체는 많은 리소스 낭비를 가져오게 된다.

일반적으로 EJB를 기반으로한 J2EE아키텍처의 가장 큰 장점으로 주목받아 온 것은 Web tier와 EJB tier를 분리시켜서 독자적으로 수평확장(Scale out)할 수 있게 해서 대용량의 부하를 감당하도록 무한한 확장성을 가질 수 있다는 것이다. 클러스터링된 Web container 머신 4대와 EJB Container서버 8대. 사용량에 따라서 부하가 걸리는 tier의 서버를 증가시켜서 확장성을 극대화 시킨다는 것이 J2EE 아키텍처의 가장 큰 자랑이자 분산객체 기술의 이상형이다.

저자는 이런 생각이 매우 왜곡된 미신일 뿐이라고 말한다. 실제로 co-located된(web-tier와 business logic tier가 같은 머신에서 공존하는) 시스템보다 더 뛰어난 remoting기반의 분산객체구조의 시스템을 본 적이 없다고 말한다. 사실 나만해도 그런 remoting구조의 아키텍처를 최종적으로는 가장 이상적인 구조로 보아왔다. 즉 시스템 규모가 커지면 결국 그리로 가야하지 않는가 생각했던 것이다. 하지만 리모트콜(RMI)을 사용하는 것에서 오는 모든 장점보다 네트웍과 마샬링의 부하에서 오는 단점들이 훨씬 더 크다는데 문제가 있다. J2EE의 분산객체기술은 J2EE/EJB 마케팅의 가장 주요한 포인트였는데 실제로는 현실과는 너무 거리가 있는 아이디어일 뿐이다.

그럼 대안은 무엇인가? 단일서버에서 돌아가는 시스템으로 만족하고 수직확장(Scale up)만을 할 수는 없는 노릇이다. 하지만 presentation layer와 business logic layer가 공존하는(co-located)구조도 얼마든지 확장(scale out)이 가능하다. Co-located architecture는 사실 훨씬 간편하게 확장이된다.

결론적으로 분산객체(독립된 ejb-tier를 가지는 경우) 아키텍처가 더 나은 확장성을 가진다는 생각을 버려야 한다. 구지 필요하다면 최소한의 애플리케이션의 단면(vertical slice)구조를 가지고 테스트해보라. 단위 서버의 효율을 최대로 하여 스케일링의 필요성을 최소화 하는 것이 무턱대고 분산객체를 쓰는 것보다 나음을 기억하자. 분명 J2EE의 분산객체기술은 그 자체로 뛰어난 것임에는 분명하다 하지만 그 용도와 필요성은 매우 극소수의 경우에만 적용된다.

셋째는 J2EE의 모든 기술을 과도하게 적용하려고 하는 것인데 이는 그 시스템에서 필요로하는 요구사항과 상관없는 기술을 적용하고 싶어하는 욕심에서 비롯된 것들이 많다. J2EE가 지원하는 기술들이 실제 그 시스템의 요구사항이 아닌 경우 결국 그것이 시스템의 복잡성을 증가시키는 주요 이유가 될 것이다.

또 한가지 주요한 복잡성의 원인으로 “패턴중독(pattern-sickeness)”가 있다. 패턴은 기본적으로 좋은 것이다. 하지만 J2EE계에는 너무나 많은 독자적인 패턴들이 등장하고 제시되고 있다. 책에서 잡지에서, 인터넷 각 사이트마다 저마다의 패턴들을 만들어 내놓곤 하는데 이 모든 패턴들이 항상 모든 종류의 시스템에 적절한 것이 아니다. 많은 아키텍트들은 얼마나 많고 다양한 패턴을 자신의 시스템에 적용했는가에 너무 많은 관심을 가지곤 한다. 패턴을 적용하는 이유는 심플함을 주기 위해서 이다. 패턴적용이 오히려 시스템을 더 복잡하게 만들고 있다면 다시 심각하게 사용을 고려해보는 것이 바람직하다.

넷째는 문화적인 원인이다. 개발자, 개발회사, 개발그룹 안에는 나름대로 전통과 문화가 존재한다. 때론 이 문화들이 아키텍처를 복잡하게 하는 이유가 되기도 한다.

많은 애플리케이션 서버벤더들이 복잡한 아키텍처와 기술을 조장한다. 자신들의 시스템의 복잡성과 높은 비용을 정당화하기 위한 이유가 아닌가 싶다. Markitecture라는 신조어가 있다. 마케팅을 목적으로 만들어낸 복잡한 구조의 아키텍처를 말한다. 복잡한 다이어그램과 화이트페이퍼에 나오는 환상적인 아키텍처는 고객의 흥미를 끌고 고가의 시스템과 라이센스를 팔아먹기에 적합할지 모른다. 하지만 그것이 현실에서는 얼마나 한계가 있는지 경험해 본 사람은 잘 알 것이다. 영업사원의 말과 해당 업체가 제공하는 교육이나 세미나의 결론을 믿지말고 반드시 스스로 검증하고 확인할 것.

또 개발툴의 복잡성도 문제가 된다. 특히 UML기반의 개발과정은 과연 바람직한 것인지 의문이다. 많은 경우 UML기반의 툴을 이용한 개발은 위험할 수 있다. 중요한 것은 개발현실이다. 과연 UML기반의 툴을 이용해서 개발하는 것이 얼마나 agile methodology에 적합한가 또 working code와 얼마나 잘 연동이 되서 잦은 리팩토링이 가능하게 하는지 코드를 생성하고 개발하는데 얼마나 효과적인지 곰곰히 생각해볼 노릇이다. UML기반의 프로세스 내지는 그 기반의 툴이 얼마나 시스템개발과 아키텍처를 심플하게 해줄 수 있는가 직접 점검해 보라.

어떤 경우는 특정팀의 자만심이 문제가 되기도 하는데 자신들의 시스템은 뭔가 특별하고 대단한 것이라고 생각해서 이미 검증되어 있는 잘 알려진 프레임웍을 쓰려하지 않고 스스로 개발한(in-house) 아키텍처를 이용하려는 경우가 있다. 내 경험으로 보자면 좀 실력이 뛰어나다고 생각하는 젊은 개발자들이 이런 유혹에 잘 빠지는데 항상 결과는 똑같다. 복잡하고 완성도 떨어지는 아키텍처에 스스로 발목잡혀 고생만 하게되는 경우다. 누구나다 개발자로서 한 때는 자신이 마음먹으면 못할 것이 없으며 누구보다도 뛰어난 엔지니어라는 환상을 같게 된다. 인터넷에 유명 포탈에서 다른 사람들의 실수를 보면 비웃으면서 나는 저들보다 낫다고 자만하게 된다. 어떤 사람들은 개발 3-4년차의 엔지니어가 그런 유혹에 잘 빠진다고 하는데… 뭐 아무튼 결론은 항상 겸손해야 한다 이다. 자신은 생각보다 별로 뛰어난 엔지니어가 아닐 경우가 더 많다고 생각하면 항상 맞을 것이다. 내 자신에게도 자꾸 적용해야 할 말이다. 뛰어난 많은 엔지니어들의 고민과 경험 속에서 만들어진 결과물들을 겸허하게 수용해야 할 때가 있음을 기억하도록 하자.

또 하나의 경우는 개발자 자신에게 있기도 한데. 좀 더 고급스러워 보이는 기술을 사용해서 자신의 커리어를 확장시키려는 경우 또는 실제 사용하는 기술의 상세한 내용과 결과를 알지도 못하고 경험도 없으면서 문서작업과 모델링에나 몰두하는 아키텍처들이다. 또는 정말 이유을 알 수 없는 제멋대로 행동을 하는 고집불통 개발자인데 이런 사람은 팀에서 빨리 빼버리는 것이 모두에게 도움이 될 것이다.

시스템을 복잡하게 의도적으로 만드는 경우도 있다. 결국 개발비용을 극대화 시켜서 고객으로부터 과다한 이익을 챙기는 경우인데 솔직이 내가 보기엔 적지 않다. 아무리 고객사 엔지니어가 뛰어나다고 해도 최첨단의 화려한 기술로 가득찬 100페이지짜리 제안서에 20페이지가 넘는 각종 다이어그램을 가져가서 또 유명업체의 기술적인 근거자료들을 제시하면서 설명하면 쉽게 넘어오는 경우가 많다. 하지만 그 결과로 만들어진 코드가 정말 그 제시한 화려한 장점들을 가지고 있는지는 아무도 알 수 없이 끝나는 것이 대부분이다. 오늘날 많은 세계적인 컨설팅 업체들도 전략적으로 그런 행동을 하는 것을 알만한 사람은 다 알 것이다. 근래들어 많은 대기업들과 정부기관들 – 오랫동안 컨설팅회사의 제시한 시스템을 그냥 무비판적으로 받아들여 사용해왔던 – 이 서서히 그런 모습에 의문을 품고 하나씩 검증하며 시스템을 세분화해서 도입하려는 추세를 보이고 있다. 매우 바람직한 일이라고 본다.

다음에 생각해 볼 것은 그럼 과연 얼마나 심플해야 하는가이다. 무조건 심플하기만 하면 좋은가? 혹시 너무 나이브해지는 것은 아닌지?

핵심은 그 심플한 아키텍처가 고객의 실제 요구사항에 충분히 부합하는 것인가 프로젝트 초기에 검증해보라는 것이다. 또 한가지는 심플한 아키텍처라고 하더라도 추가적인 요구사항이 발생함에 따라서 scale up할 수 있어야 한다는 것이다.

이제 J2EE계에도 변화의 바람이 불고 있다.

많은 개발자들이 경험을 통해서 분산아키텍처의 도입을 피하고 있으며 EJB는 그 복잡성으로 인해서 가능한한 사용하지 않으려는 노력이 이루어지고 있다. 심지어는 SUN조차도 말이다. 또 그 대안으로 여러 Lightweight container들이 등장하고 있고 Entity bean의 대안으로 JDO나 Hibernate등이 사용되어지고 있다. 또 agile methodology와 open source기술의 사용이 늘고 있는 점이다. 이런 모든 흐름은 결국 많은 경험을 통해서 개발자들 자신을 통해서 주도되고 있다. 내가 자바와 그 환경을 좋아하는 이유중의 하나는 SUN과 같은 업체가 주도해서 기술과 흐름이 가는 것이 아니고 전세계 흩어진 많은 풀뿌리 개발자들 스스로가 깨닫고 원하는 방향으로 흐름이 이루어지고 있다는 것이다.

요구사항을 가장 잘 충족시키는 – 잘 작동하는 가장 심플한 것을 찾으라. 그 태도가 당신을 진정 뛰어난 J2EE 개발자로 만들어 줄 것이다

Related posts:

  1. J2EE Development without EJB 정리는 이만
  2. J2EE Development without EJB (2) – Goal
  3. J2EE Development without EJB (3) – Architecture
  4. J2EE Development without EJB (5) – EJB, Five Years On
  5. J2EE Development without EJB (6) – Lightweight Container & IoC
  6. J2EE Development without EJB (1) – Why "J2EE Without EJB"?
  7. SpringFramework vs. J2EE?

Facebook comments:

to “J2EE Development without EJB (4) – The Simplicity Dividened”

  1. 넘 좋은 글입니다. 진심으로 감사드려염~

  2. We have decided to open our POWERFUL and PRIVATE web traffic system to the public for a limited time! You can sign up for our UP SCALE network with a free trial as we get started with the public’s orders. Imagine how your bank account will look when your website gets the traffic it deserves. Visit us today: http://voxseo.com/traffic/

  3. Thanks for the nice blog. It was very useful for me. Keep sharing such ideas in the future as well. This was actually what I was looking for, and I am glad to came here! Thanks for sharing the such information with us.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha