올바른 자바 프레임워크 선택하기

자바의 경우 선택할 수 있는 프레임워크의 수와 다양성에서 타 언어를 압도한다. 아마 자바와 비견되는 다양한 프레임워크를 제공하는 언어는 PHP정도가 아닐까? (사실 갯수로만 따지자면 PHP의 프레임워크 수는 자바를 상회한다!!) 하지만 목적에 맞는 프레임 워크를 선택하지 못한다면 필요없는 학습 코스트와 런타임 오버헤드를 감수해야만 할 것이다.

The Curious Coder's Java Web Frameworks Comparison!에서는 프레임워크 선택에 대한 고려사항으로 다음과 같은 항목을 꼽고있다.

1. 고속 프로토 타이핑 - 얼마나 빠르고 쉽게 프로토타이핑이 가능한가
2. 기능 - 얼마나 많은 기능들이 제공되는가
3. 사용성 - 얼마나 사용하기 쉬운가
4. 인기도 - 많이 사용하는 프레임워크는 풍부한 도큐먼트와 커뮤니티의 지원을 기대할 수 있다
5. 프레임워크 생태계 - 열성적인 오픈소스 커뮤니티의 지원을 받는 프레임워크들은 스스로 진화하고 확장해 나감으로서 보다 완벽한 모습을 띄게된다.
6. 처리능력과 확장성
7. 코드 유지보수와 업데이트의 용이성
8. UX, Look and feel - UI관련 기능

오늘은 최근 프로젝트에서 사용한 프레임워크들에 대해서 느낀점을 간략히 정리해 보고자 한다.

Spring(SpringMVC) vs JavaEE(6또는7) vs Struts

Spring는 현재 자바 프레임워크의 대세이다. 1800건 이상의 개발자 설문조사를 바탕으로 작성된 Developer Productivity Report 2012에의하면 Spring은 30%의 시장점유율로 자바 프레임워크의 산업표준이라 할 수 있으며 실제 표준인 Java EE 6조차 DI 인젝션과 같은 아키텍쳐상의 주요 컨셉을 상당부분 차용하고 있는 실정이다.  차기 Spring 4.0에서는 역으로 한발 앞서 공개된 Java EE 7 주요 아키텍처 컨셉의 상당부분을 포용함으로서 두 프레임워크는 더욱더 닮은 모습을 띄게 되었다.

최신버전의 Spring과  JavaEE는 모든면에서 서로 닮은 모습을 하고 있으나 어플리케이션 서버의 선택에 있어서 매우 유연한 Spring에 비해 JavaEE는 JavaEE 지원 어플리케이션 서버에서만 구동이 가능하다. 게다가 JavaEE인증을 받은 서버라 할 지라도 특정 DB만을 지원하는 JPA 구현과 같이 세부 사양에 대한 구현방식이 약간씩 다른경우가 있으므로 프레임 워크 선택시엔 표준 사양 세부 항목들의 지원 여부를 따져보고 제약사항을 꼼꼼히 확인해야 한다.

결국 Spring과 JavaEE 양자간의 선택이라고 한다면 오픈 소스의 유연함과 확장성인지 개발 표준에 대한 신뢰성에 대한 선택이 될 수 있을것이다.

Struts는 초기 자바웹 프레임워크의 대표주자로 스마트UI가 주류를 이루었던 시절에 등장하여 오늘날의 MVC패턴이 자리잡는데 큰 역할을 하였다. 현시점에선 다른 프레임워크들에 비해 생산성이나 기능등의 많은 면 에서 뒤떨어지는 모습을 보여주고 있기는 하지만 오랜기간동안 많은 웹 어플리케이션들이 Struts 베이스로 만들어졌기에 오늘날에도 Spring과 JavaEE에 이어 시장점유율 3위를 차지하고 있다.

Hibernate VS JPA VS iBatis(myBatis)

이번엔 퍼시스턴스 프레임워크를 살펴보자. Hibernate는 대표적인 ORM 프레임워크이며 JPA는 퍼시스터스 사양이다.  잘 알려진 JPA의 구현으로는 Eclipselink와 Hibernate등이 있으며  JavaEE와 Spring에서 지원된다. 기존의 Hibernate ORM과 JPA의 가장 큰 차이점은 데이터 영속화에 대한 정보를 XML에서 관리하느냐 어노테이션에서 관리하느냐의 차이점과 관계형 데이터 베이스를 오브젝트가 보다 쉽게 사용할 수 있도록 한 HQL 과 Criteria Query의 존재라 할 수 있겠다.

HQL과 Criteria Query의 차이점에 대해서 Sivateja씨는 자신의 블로그에 다음과 같이 정리해 놓았다.

• HQL 은 데이터에 대해서 선택/비선택 작업이 모두 수행 가능하지만 Criteria는 단지 선택 작업만이 수행 가능하다.
• HQL은 정적 쿼리를 수행하기에, Criteria는 동적 쿼리를 수행하기에 적절하다.
• HQL은 페이징 컨셉을 지원하지 않지만 Criteria는 지원한다.
• Criteria는 일반적으로 HQL보다 수행속도가 느리다. (역자 주 : 이 부분은 최신 버전의 Eclipselink의 경우 차이가 많이 좁혀졌다.)
• Criteria는 동적으로 쿼리를 생성하기 때문에 안전한 SQL인젝션이 가능하다. 반면 HQL는 정적 쿼리이기 때문에 SQL인젝션에 대한 안전성이 보장되지 않는다.

대세는 점차 JPA로 옮겨가는 중인데, 자바 전체가 어노테이션을 지향하고 있다는 점 외에도, 도메인 주도 설계와 같은 도메인 모델 패턴에서 관계형 데이터베이스를 직접적으로 의식하지 않는 퍼시스턴스 레이어 설계가 가능하다는 점이 개발자들에게 받아들여지고 있다고 본다.

마지막으로 대표적인 SQL Mapper인 iBatis의 경우 기존 NativeSQL+JDBC 개발자들에게 친숙해서 많은 환영을 받는 반면 진정한 의미의 퍼시스턴스 레이어 구현과는 거리가 있다.
Transaction Script Pattern 개발에서는 iBatis 만으로도 충분히 대응이 가능하지만 Domain Model Pattern 개발시에는 ORM인 Hibernate나 JPA가 퍼시스턴스 층의 구현으로서 보다 나은 선택이 될 것이다.

Transaction Script Pattern과 Domain Model Pattern에 대한 설명은 최범균님의 블로그 포스트에서 상세히 설명하고 있으니 참고하기 바란다.

애자일 시대의 모델링 : 애자일 팀의 확장에 따른 문서화에 대한 조언

애자일 선언문에서는 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둔다고 명시하고 있다. 그렇다면 문서화따윈 과감히 건너뛰고 바로 코딩부터 하는것이 올바른 것일까?  

InfoQ에 이러한 질문에 대해 심도있게 다룬 기사가 올라왔기에 내용을 소개하고자 한다.

모델링을 포함한 문서화는 팀 규모의 확대와 더불어 기하급수적으로 증가하는 커뮤니케이션 비용을 해소하기 위해 매우 중요한 요소이다. 애자일 개발에 있어서 이상적인 설계와 모델링이란 의식공유를 위한 커뮤니케이션의 일부로서의 존재해야 한다. 또한 오버헤드를 제거하기 위해 문서와 코드는 중복된 정보를 다루지 않아야 한다. 코드로 표현 가능한것은 코드로 표현하고, 코드안에 포함되기 어려운 정보들을 문서화의 대상으로 삼아야 한다.

대표적인 애자일 개발 프로세스중 하나인 스크럼 프로세스에서는 특별히 설계에대한 언급이  없다. 그럼 스크럼은 설계가 없이 개발이 이루어지는 것일까? 

설계는 모든 소프트웨어 개발에서 끊임없이 이루어진다. 그것이 머리속에서든 화이트보드 상에서든 수백페이지 짜리 문서든지간에 말이다.

문서화는 애자일에 대치 되는가? 

애자일 선언에서는 대화(커뮤니케이션)가 문서화보다 가치 있다고 명시하고 있다. 이상적인 문서화는 이러한 커뮤니케이션의 토대가 될 수 있어야 한다. 개개인의 머리속에 존재하는 개념들을 공유하는데 도움이 되어야 한다. 그리고 그러한 공유를 위해 가장 효과적인 방법이 바로 모델링이다.

UML로 대표되는모델링은 문장만으로 구성 할 수 없는 많은 정보들을 알기쉽고 간략하게 표현 할 수 있게 해 준다. 설계서의 목적은 커뮤니케이션의 토대가 되는것이지 납품 명세서의 목록을 채우기 형식적인 작업이 되어서는 안된다.

모델은 프로젝트 기간동안 지속적으로 갱신이 이루어지는 "유지모델"과 커뮤니케이션을 지원하기 위해 임시적으로 사용되는 "임시모델"로 나누어 관리 한다. "유지모델"은 프로젝트의 진행과 더불어 축척된 지식을 피드백하여 끊임없이 업데이트 되어야 하며, 화이트보드위에 그려진 클래스 다이어그램과 같이 그때 그때의 커뮤니케이션을 위해 작성되는 "임시모델"은

목적(그때 그때의 팀원간의 의식공유)이 달성에만 사용한다.

저자인 히라나베 캔지씨는 다음과 같은 세가지 형태의 모델을 유지모델로서 제안하고 있다.

1. 팀이 전체 시스템 구조의 개략적 인 아이디어를 얻기위한 시스템 " 아키텍처 "
2. 팀이 문제 도메인에서 사용되는 개념의 이해를 도와 줄 " 도메인 모델 "
3. 시스템의 일반 사용자를 이해하고 그들이 시스템에서 유용함을 얻는 방법에 대한 " 키 유즈 케이스 "

이 기사에서는 또한 팀의 규모확대와 더불어 어떻게 모델을 기반으로한 커뮤니케이션 프레임웍을 확대해 나가는지에 대해 매우 구체적으로 설명하고 있다.

간단히 요약하자면 타이거팀이라고 하는 이른바 초기 맴버들을 중심으로 전체적인 밑그림을 그리고 이 타이거팀의 맴버들이 주축이 되어 각 서브팀으로 설계에 대한 의식공유를 이끌어 나간다. 이때 중요한것은 서브팀에서 구체화된 모델은 다시 타이거팀으로 피드백하여 유지모델을 지속적으로 업데이트 해 나간다는 점이다.

저자는 설계의 의도와 이해를 공유하는데 유용한 팁으로 모델링 워크샾을 필요한 만큼 충분히 열고 벽이에 유지모델을 인쇄해 걸어놓고(또는 화이트보드에 프로젝트로 모델을 영사해 놓고) 그 모델위에 필기로 지식을 추가해 나가는  것을 추천하고 있다.

마지막으로 모델링에 대한 지식을 효과적으로 전파하는 데에는 사람에서 사람으로 지식을 전달해 나가야 한다. 단순히 문서만을 서브팀에 전달해서는 효율도 낮을 뿐더러 설계 의도가 충분히 전달되지 않는 경우가 많다. 가장 이상적인 방법은 타이거팀의 맴버가 서브팀의 일원이 되어 함께 코드작업까지 진행하며 모델과 아키텍쳐 지식을 전달하는 것 이다. 

저자는 기사 말미에 모델링에 대해서 몇가지 유용한 팁을 제안하고 있다.

전술 한 아이디어와 경험을 바탕으로 당신의 일일 모델링 작업 또는 모델링 워크숍에서 사용할 수있는 몇 가지 팁을 여기에 소개합니다.

• 리버스 및 모델 : 많은 UML 도구는 저스트 인 타임 방식으로 코드를 시각화하는 "리버스 엔지니어링"기능을 제공하며 일부 툴은 로컬 소스코드에서 리버스 하는 기능 뿐만 아니라  Github 저장소에서 소스를 직접 읽어오는 기능도 가지고 있습니다. 
• 인쇄 및 필기 : 위에서 언급 한 것처럼 좋은 인터랙티브 모델링 워크숍은 벽 (또는 테이블)에 붙인 커다란 종이 사용하여 팀원들과 상호 작용을함으로써 촉진됩니다. 인쇄 한 큰 종이에 직접 내용과 의견을 써주세요.　
• 화이트 보드에 프로젝터를 비추고 직접 작성 : 워크샵에서 사용할 수있는 또 다른 모델링 공유 방법은 화이트 보드에 비친 영상에 대해 직접 필기를 하는 것 입니다. 프로젝트에서 화이트 보드에 "유지 모델"을 비추고 그 위에 코멘트 또는 내용을 직접 씁니다.
• 회고 : 나는 "유지 모델"간단한 버전을 제안했지만, 그것은 당신의 문제에는 맞지 않을지도 모릅니다. 그래서 처음에는 나의 제안 또는 당신이 생각한 간단한 "유지 모델"에서 시작하십시오. 그리고 각 스프린트마다 당신의 모델에 대해 회고하고, 어떤 모델이 잘 움직이고 있는지, 어떤 모델이 필요한지 또는 필요없는 것인지에 대해 검토합니다. 당신만의 "유지 모델"을 찾아 내십시오.
• 마인드 맵 모델링 : UML 및 기타 소프트웨어 엔지니어링 다이어그램은 사용자와 토론, 계획, 그리고 기타 여러가지 경우에 생각처럼 잘 작동하지 않지만, 시도 자체는 중요한 의미를 지닙니다. UML과 더불어 마인드맵을 만들어 사용하십시오. "Mind Map과 UML을 사용한 애자일 모델링"대한 자세한 내용은 사용자와 함께 만든 "사용자 스토리 탐구"샘플 을 참조하십시오.

끝으로 애자일 모델링에 대해 업계의 거장인 Martin Fowler씨와 Jack Reeves씨의 명문을 소개합니다.

• Martin Fowler, 2004, "Is Design Dead?"
• Martin Fowler, 1997, "The Almighty Thud"
• Jack Reeves 1992 "What is Software Design?"

애자일 모델링의 개념은 "Agile Modeling"책에서 처음 설명되어 있습니다. 그리고 "실천 UML"제 3 판에서 다시이 주제를 다룹니다.

• 스콧 W 느리게 걷는 사람, 2002, "민첩 모델링"
• 크레이그 라만, 2007, "실천 UML 제 3 판 객체 지향 분석 설계 및 반복 개발 입문"

모델링 워크숍 아이디어는 주로 Craig Larman과 Bas Vodde 책에서 영감을 받았습니다.

• Craig Larman and Bas Vodde, 2010, "Practices for Scaling Lean & Agile Development"  
• 아래 내용은 다운로드 할 수 있습니다 Chapter 8 from "Practices for Scaling Lean & Agile Development : Large, Multisite, and Offshore Product Development with Large-Scale Scrum"

"유지 모델"과 "임시 모델"아이디어는 여기서 가지고 왔습니다.

• Strategic Systems, 2012, "Agile Modeling by Example "

같은 문제를 다루고있는 또 다른 InfoQ 기사입니다. 아직 2 부를 계속 기다리고 있습니다.

• Lee Ackerman, 2011, "Agile Modeling : Enhancing Communication and Understanding"

민첩한 개발 및 아키텍처에 대해 더 넓게 다루고있는 기사

• Bill Opdyke, Dennis Mancl, Steve Fraser "Architecture in an Agile world, 2010", SPLASH workshop

모쪼록 시간을 내서라도 꼭 원문을 읽어두길 바라며 영어에 대한 압박을 느끼는 분이라면 일본어판의 구글 번역 링크를 참고하기 바란다.(매끄럽지는 않지만 내용을 이해하는데 큰 문제는 없을것이다.)

원문 링크

Modeling in the Agile Age: What to Keep Next to Code to Scale Agile Teams

일본어판 InfoQ 기사 구글번역 링크

민첩한 시대의 모델링 : Agile 팀 확대를 위해 코드의 다음에 무엇을 유지해야 하는가

이 글을 쓴 히라나베 캔지씨는 UML, ERM, Mindmap과 리버스엔지니어링을 지원하는 소프트웨어 디자인 툴인 Astah를 만든 Change Vision社의 CEO이다. Astah는 뛰어난 기능과 합리적인 가격으로 일본에서는 이미 보편적인 설계툴 로 자리잡은지 오래이다. 만약 무상으로 사용 가능한 UML설계툴을 알아보고 있다면 Astah Community를 고려해 볼 것 을 추천한다.