책 이야기 - 실천 반복형 소프트웨어 개발

왜 반복형 개발인가?

 Disciplined Agile Delivery (DAD)를 비롯해 애자일 개발에 가장 큰 영향을 끼치고 있는 인물인 Scot Ambler는 2007년부터 자신의 웹 사이트에서 비 정기적으로(거의 1-2년에 한차례)프로젝트 성공에 대한 설문을 진행해 오고 있다. (2013년 투표는 2013년 12월1일 현재 진행중이며 결과가 나오면 살펴볼 기회를 가져보려 한다.)

아래 표는 가장 최근 이뤄진 2011년의 조사 결과이다.

 여기서 눈여겨 보아야 할 것은 성공률 1위가 애자일 개발이 아닌 반복형 개발이라는 점이다.
 반복형 개발은 순차 점증적 개발(Iterative and incremental development)과 동일한 의미 이며 폭포수 개발 방식과 마찬가지로 여러가지 수정모델이 존재하는데, Rational Unified Process로 흔히 불리우는 Unified Process가 대표적이며,  2위와 3위에 오른 애자일 소프트웨어 개발 프로세스들 또한 반복형 개발에 근간을 두고 있다.

반복형 개발 VS 애자일 개발 VS 폭포수 모델

 애자일 개발과 반복형 개발은 실상 프로젝트 내부에서 이뤄지는 작업의 내용면에서는 사실상 큰 차이가 없다고 보는데, 두가지 개발 방식에 대한 차이는 무엇을 하는가 보다는 무었을 지향하는가에 있기 때문이다.

 애자일 개발은 가치 지향적이다. 애자일 개발은 프로세스나 계약, 절차보다 완성된 소프트웨어가 지니는 가치를 가장 중심에 놓고 프로세스를 바라보는 관점을 지닌다. 
반복형 개발은 폭포수 개발과 마찬가지로 기본적으로는 절차 지향적이다. 인적 자원에 크게 의존 할 수 밖에 없는 소프트웨어 개발 프로젝트가 필연적으로 지니게 되는 불가시성을 최대한 배제하기 위해 반복적이며 점진적으로 계획하고 실행하는 방법을 택하고 있다. 
XP나 스크럼과 같은 애자일 개발 프로세스들은 기본적으로 반복형 개발을 기초로 하여 개발 프로세스들을 확립하였다. 짧은 개발주기, 지속적인 통합/배포, 그리고 회고를 통한 피드백이 그것이다. 

 엔터프라이즈 어플리케이션 개발에 있어서 애자일 개발이 지니는 최대의 약점은 고객으로 부터 듣는 질문중 가장 단순하면서도 가장 흔히 듣는 질문인 "그래서 얼마면 되는거요?"라는 질문에 답변하기가 까다롭다는 점이다. 특히나 대규모의 프로젝트에서 "일단 한번 해 보시면 얼마나 좋은지 아실껍니다." 라는 답변으로 고객을 안심시키기는 쉽지가 않다는 이야기 이다.

 그렇다고 견적내기 편하다는 이유로 폭포수 모델을 택하기엔 너무나도 많은 대가를 감수해야만 한다. 폭포수 모델이 오늘날 천덕꾸러기 신세를 면치 못하는 이유는 만들어 내야 하는 소프트웨어에 대한 복잡성이 검토를 통해 예측 가능한 법위를 넘어섰기 때문이다. 

 현대의 사회 시스템은 끊임없이 복잡한 방향으로 변화하고 있으며 이를 추상화 하여 다루는 소프트웨어도 함께 복잡성을 더해가고 있다.  이에 대해 반복형 개발은 끊임없이 완성된 소프트웨어를 만들어 내고 그에 대한 피드백을 통해 프로젝트를 통제해 나가는 방식을 취함으로서 이러한 복잡성에 대응해 나가고 있다.

 즉, 고객이 진정 원하는 소프트웨어의 사양은 완성된 소프트웨어를 직접 만져보기 전에는 확정하기 어렵다. 따라서 검토만으로 해결 할 수있다고 주장하는것은 너무나 천진 난만한 생각이며, 이에 대한 대가로 지불되는 것은 대부분의 개발 현장에서 개발자들의 땀과 눈물이 될 것이다.  

실천 반복형 소프트웨어 개발에서 다루는 내용

이제 본론인 책 이야기를 할 시간이다.

 저자인 쓰다씨는 현재 일본 마이크로소프트에서 테스트 전문가로 활동하고 있으며 필자가 소속된 豆蔵Mamezou의 OB이기도 하다.

저자는 이 책의 대상 독자에 대해 책 머리에 다음과 같이 밝히고 있다.

• 3~5년정도의 소프트웨어 개발 경험이 있는 분
• 프로젝트 팀을 리드하는 위치이며, 팀운영방침을 정해야 하는 분
• 지금부터 프로젝트팀을 리드하는 위치에 서게되는 분
• 프로젝트팀의 운영에 대해서 문제의식을 가지고 있는 분
• 개발중인 소프트웨어의 품질을 제어할 수 없어서 곤란을 겪고 있는 분
• 개발을 지원하는 툴을 도입하고 싶지만, 조직의 문화적 저항에 부딧혀 뜻을 이루지 못하는 분
• 툴을 도입하기는 하였으나 제대로 활용하는 방법을 알지 못하는 분
• 폭포수개발 프로세스에서 벗어나고 싶은 분
• 반복형 개발을 시험해 보고 싶지만, 몇번을 반복해도 끝이 나질 않아 실패한적이 있는 분

 이 책에서는 언어나 생산되는 소프트웨어에 관계없이 다양한 소프트웨어 개발 프로젝트에서 사용 가능한 범용적인 반복헝 개발의 원칙과 규율을 제시하고 있다.

 책에서 소개하는 원칙과 규울은 단순히 이론에 그치는것이 아니라 현재 나와있는 최적의 개발지원 환경들(빌드, 형상관리, 이슈트래킹, CI)이 개발 규모와 진행상황에 따라 어떻게 연동되어 운용 되어야 하는지를 구체적인 예제와 함께 설명하고 있다.

 개인적으로 이 책의 가장 맘에 드는 부분은 일방적으로 이러한 방식이 가장 좋습니다 라고 강요하는 식이 아니라 스스로 각자의 개발 현실에 맞는 프로세스를 찾아 나갈 수 있도록 다양한 힌트를 제시하고 있다는 점이다.

품질과 납기를 동시에 잡는 비장의 무기 - 타임박싱 관리 기법

 저자인 쓰다씨가 반복형 개발에서 특히 중요하게 생각하는 개념은 타임박싱기법 이다.
타임박싱이란 기간 안에 끝낼 수 있는 작업과 그렇지 못한 작업을 선별하여 다음 반복에 넘기는 프로젝트 관리 기법을 지칭하는 것으로 정해진 시간 속에서 개발 사이클을 반복해야 하는 반복형 개발에서 품질과 납기를 지켜내기 위해 매우 유용한 개념이라 할 수 있다.

타임박싱 기법에 대해서는 아래 포스팅에서 자세히 다루고 있다.

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

그래서 얼마면 되는거요?

 마지막으로 아까전에 했던 "그래서 얼마면 되는거요?"라는 고객의 질문에 대해서 필자는 다음과 같이 답변을 하고자 한다.

"반복형 개발이 더 싸지지는 않을지 모릅니다. 하지만 같은 비용의 폭포수 개발과 비교하자면 위험 요소들의 제어가 훨씬 쉬워지며, 무엇보다 좋은 품질의 소프트웨어를 생산하는것이 가능해 집니다."

 반복형 개발(또는 애자일 개발)은 개발자가 편해지자고 하는것이 아니다. 오히려 개발자는 폭포수형 개발에 비해 훨씬 많은 작업들을 수행 해야만 한다. 그렇기 때문에 빌드하고 에러를 체크하고 코드 품질을 유지하는 등의 작업들을 철저하게 자동화 해 나감으로서 사람만이 할 수 있는 창조적인 작업에 보다 많은 시간을 투자 하는것이 가능해지는 것이다.

 개발 현장에서 애자일 프로세스의 도입을 검토하고 있거나 이미 도입하였더라도 프로세스의 개선에 목말라 하는 모든 이들에게 이 책을 꼭 추천한다.

성공한 스타트업이 미국에서 많이 나오는 이유는?

패기, 도전정신... 이런 단어들이 예능방송 이외의 곳에서 들려오지 않게 된 지가 꽤 오래된듯 싶다.  이미 우리사회는 도전하지 않아도 먹고살만하기 때문일까? 그보다는 실패에서 감수해야 하는 댓가가 너무나도 크기에 젊은이들이 몸을 사리게 된 것은 아닐까 싶다.

클라우드 컴퓨팅의 등장으로 개인이 무한대의 컴퓨팅 파워를 손에 넣을 수 있는 시대가 왔다. 더 이상 돈 걱정 하지 않고 두뇌 하나로도 승부가 가능한 시대가 열린것이다. 인재의 질로 우수하기로는 세계에서 둘째가라면 서러운 대한민국에서 혁신적인 서비스들이 나오기 위해서는 무엇이 필요할까?

Quora에서 ”성공한 스타트업이 미국에서 많이 나오는 이유는?”이란 주제로 이루어진 논의가 있었는데, 상당히 심도있는 답변들이 올라왔기에 이 자리에서 소개한다.

대부분의 성공한 스타트업은 왜 미국에서 나오는 것일까요?
저와 제 친구들은 미국인은 아닙니다만 이전부터 왜 대부분의 성공한 스타트업이 미국에서 이루어졌는가에 데해서 자주 토론해 왔습니다.
미국은 다른나라들이 가지지 못한 무언가를 가지고 있는 것일까요? 문화? 커뮤니티? 얼리어답터? 투자자? 환경?

Robert Scoble - 저는 Rackspace의 창업에 대해 공부하고 있습니다.

저는 전세계를 돌면서 스타트업 기업들과 만남을 가져왔습니다. 미국이 다른 나라들과 차별되는 점은 다음과 같습니다.

1. 롤 모델에의 접근성 - 애플 본사에에서 한 CEO를 만난적이 있습니다 그는 우리에게 애플이 창사 당시부터 성장하는 모습을 보아 왔다고 했습니다. "애플이 할 수 있다면 누구라도 해 낼 수 있습니다." 그가 우리에게 전한 말 이며, 이것이 롤모델이 뒤로 갈 수록 중요해 지는 이유입니다.

2. 자본에의 접근성 - 에플은 창업을 하기위해 투자가 필요했습니다. 모든 창업이 그러하듯이 말이죠. 자기자본과 친구들나 가족의 돈으로 창업이 가능한 사람은 몇 명 되질 않습니다. 하지만 이곳에서는 롤 모델 덕분에 친구와 가족들의 돈을 빌리는것이 좀 더 쉽습니다. 만약 우리가 당신에게 만달러를 주어 창업을 하고(실제로 GoPro는 그 정도 자본으로 제가 사는 집에서 2백야드도 떨어지지 않은 곳에서 창업했습니다.) 어느날 수십억 달러의 회사가 되어 있을지도 모르는 일 입니다. 지구상에 몇명이나 그런 일이 가능할까요? 제가 알기론 그다지 많지 않습니다.

3. 비지니스 기반에의 접근성 - 창업을 하는데 도움이 되는 변호사가 필요 하십니까? 그들이 여기 있습니다. 사무실과 창업에 도움이 필요한가요? 창업에 즉시 사용 가능한 300개의 사무실들을 지금 보러 가 보세요. PR팀? 창업전에 상담 할 수 있는 맨토? 차 쓸 일이 밥먹들이 있다구요? 상장을 준비하는 방법을 아는 재무 담당자요? 그밖에 필요한것들이 다 미국에 있습니다. 아, 물론 다른 나라라고 위에 열거한 것들이 없는건 아닙니다. 하지만 샌프란시스코, 시에틀, 보스톤 ,뉴욕, LA만큼 풍부하진 않습니다.

4. 배급에 대한 접근성 - 당신의 새로운 서비스를 어떻게 사람들에게 전달할 생각입니까? 앱스토어는 어떤가요? 아마존, 애플, 구글, 마이크로소프트, 그리고 페이스북이 앱스토어를 제공하고 있습니다. 이젠 누구도 배급문제로 고민하지 않습니다. 검색엔진을 써 보는건 어떻습니까? 뉴욕이나 샌프란시스코에서는 보다 많은 사업제휴와 배급에 대한 기회를 얻을 수 있을것 입니다. 아시다 시피 대부분의 기술관련 언론이 센프란시스코와 뉴욕에 몰려있기 때문이지요.

5. 수익 창출에 대한 접근성 - 광고를 하고 싶으신가요? 뉴욕이 짱이지요. 세계 어느곳보다 미국은 부유한 시장입니다. (적어도 중국이 추월하기 전까지는) 다른 시장으로의 접근성도 좋은 관계로 월드 와이드 브랜드를 런칭하기도 수월합니다.

6. 인재에 대한 접근성 - 오늘날의 대부분의 기업들은 빅데이터 전문가를 필요로 합니다. 예를 들면 하둡을 이용한 클러스터 처리 같은거 말입니다. 당신의 지역에서 그 일을 할 수 있는 사람을 쉽게 구할 수 있나요? 아마 아닐껍니다. 하지만 샌프란시스코 근방이라면 쉬울껍니다. 구글을 비롯해 HP,  시스코, 선, 야후와 같은 수많은 IT기업들이 최고수준의 기술과 사업적 재능을 지닌 인재들이 끊임없이 배출되는 스텐포드 대학에서 시작했습니다.

7. 관리자에 대한 접근성 - 당신은 단 두명이 라면을 먹어가며 시작하는 기업이라 할 지라도 CEO의 역할은 가장 중요하며 사실상 성공과 실패가 CEO HR의 단계에서 이미 결정 됩니다. 세계 탑 클래스의 언론을 다룰 수 있는 방법을 이해하고 있습니까? 래리페이지의 사무실로 찾아가서 구글과 사업거래를 성사 시킬 수 있나요?

8. 제품에 대한 접근성 - 오클리, GM, 포드, 보잉 그리고 그 밖에 수많은 메이커들이 미국에서 물건을 만들어냅니다. 이 사실은 그러한 물건들을 만들어 내는 방법을 만드는 사람들도 미국에서 찾기 쉽다는 이야기 입니다. 애플은 중국으로 생산라인을 옮겼습니다만, 여전히 많은 중국의 제품들은 미국 시장을 겨냥해서 만들어지고 있습니다.

9. 수많은 찬스들 - 샌프란시스코 지역에서 저녁 식사를 하거나 커피를 마시다 보면 수많은 스타트업 기업들과 대형 기업들의 임원들과 우연히 마주칠 기회를 가지게 됩니다. 아마 이러한 우연을 일상적으로 접할 수 있는 곳은 지구상에 이곳밖에 없을껍니다. 저는 그러한 우연들이 거대한 비즈니스로 거래로 이어지는 현장을 목격해 오고 있습니다. 큰 고기는 작은 강이나 개천에선 놀지 않는법 입니다.

Rony Gao - 국제 비즈니스 전문가

Rovert Scoble의 멋진 답변에 추가해 보겠습니다. 인구수를 살펴 보면 금방 답이 나오죠. 3억명이라는 인구는 분명 스타트업에게는 더 없는 축복입니다. 우리들이 미국에서의 기회에 대해서 말 할때 곶잘 간과하는 부분이 있는데, 미국의 인구는 나머지 G7인구를 합친 것과 거의 맞먹는다는 점 입니다.

Patric Keane - www.produckworld.com에서 근무
이 주제에 대한 글이 Paul Graham의 블로그에 잘 정리되어 있습니다.

Why Startups Condense in America

요약해서 보자면
1. 미국은 이민을 받는다.
2. 미국은 부자 나라다.
3. 미국은 경찰국가가 (아직은)아니다.
4. 미국은 나은 대학을 가지고 있다.
5. 미국에선 해고가 자유롭다.
6. 미국에선 적은 고용으로도 일이 가능하다.
7. 미국은 너무 까다롭지 않다.
8. 미국은 거대한 국내 시장을 가지고 있다.
9. 미국은 밴처 펀딩이 있다.
10.  America Has Dynamic Typing for Careers. (해석 불가)

쓰면서 보니 시장과 인구면에 있어서는 2천5백만이라는 인구가 몰려있는 서울도 제법 큰 기회를 제공하는 도시라는 생각이 든다. 인적 물적 인프라도 나쁘지 않은 만큼 서버 인프라의 부담을 크게 덜어줄 수 있는 클라우드 서비스의 등장이 새로운 밴처 열풍의 기폭제가 되었으면 하는 바램을 적어본다.

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

자바의 경우 선택할 수 있는 프레임워크의 수와 다양성에서 타 언어를 압도한다. 아마 자바와 비견되는 다양한 프레임워크를 제공하는 언어는 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를 고려해 볼 것 을 추천한다.

기술적 부채에 대처하는 자세 Ver2.0

 기술적 부채Technical Debt라는 말을 들어 본 적이 있는가? 1992년 Ward Cunningham이 비 기술자들에게 문제를 전달하기 위해 사용하기 시작한 단어로,  간단히 말해 꼭 해 두지 않아도 또는 프로젝트가 끝날 때 까지(심지어는 끝나고 나서도) 티가 잘 나지 않는 작업들을 지칭한다.

 일반적으로 잘 알려진 기술적 부채로는 악취 나는 코드, 테스트 커버리지, 적절하지 못한 객체 모델링과 같은 작업들이 있다.

기술적 부채를 둘러싼 순환구조

 Ward Cunningham이 부채라는 표현을 쓴 이유는 복리이자가 발생하기 때문으로 이 문제를 제대로 다루기 위해서는 문제를 순환구조로서 파악하지 않으면 안된다.

기술적 부채의 악순환

기술적 자산의 선순환

 기술적 부채가 지닌 대표적인 특징은 빌린 사람과 갚는 사람이 일치 하지 않는다는 점인데, 빌린 사람은 최초 개발자에 해당하고 갚아야 하는 사람은 표면적으로는 유지 보수 개발자이고 본질적으로는 시스템 소유자(프로젝트 오너)라 볼 수 있다. 기술 부채는 소프트웨어를 사용하는 앤드유저에게는 직접적인 가치를 제공하지 않기때문에 관리업무에서 흔히 소외되는 요소중 하나로, 좀 더 직설적으로 이야기 하자면 코드 가독성을 높이기 위해 고객에게 릴리즈 일정을 조정해 달라고 할 수 없다는 뜻이다.

 금융 부채와 마찬가지로 적절하게 컨트롤 되기만 한다면 기술적 부채가 꼭 나쁘기만 한 것은 아니다. 적절한 기술적 부채의  운용은 프로젝트 진행에 상당한 융통성을 가져다 주기 때문이다. 채무를 예로 들자면 단기 상환채무를 장기 상환채무로 옮긴다던가 보다 많은 이자가 발생하는 부채를 적은 이자가 발생하는 부채로 옮기는 것과 같은것이다.

 하지만 이자는 어딘가에 몰아넣고 잊어버릴 수 있는것이 아니다. 시간과 함께 착실히 증가하게 되며 이를 제대로 인지하고 관리해 두지 않는 다면 프로젝트나 비지니스를 망치는 심각한 문제로 커 질 수도 있다. 이 점 때문에 기술적 부채는 이상과 현실 사이에서 영원히 고통 받는 프로젝트 매니저들에게 중요한 숙제거리이다.

누락된 자동화 테스트 

 제때에 작성해 두지 않은, 또는 부실하게 작성되어 실행 패턴에 대한 커버리지가 부족한 자동화 테스트는 대표적인 기술 부채이다. 멀쩡하게 동작 하는 것 처럼 보였던 코드들은 지름신 에게 휘둘린 후 애써 모른 척한 신용카드 청구서처럼 때가 되면 어김 없이 당신을 찾아와 비용 지불을 요구할 것이다.  버그의 처리 비용은 생성 후에 얼마나 빠른 시간 내에 처리 되느냐에 따라 달려 있다는 것은 이미 여러 연구에 의해 밝혀진 사실이다.

 이에 반해 테스트 케이스를 작성하는 과정 자체는 테스트 대상이 되는 실행 코드에 대한 통찰력을 늘리는 데에도 많은 도움을 준다. 이것은 채무의 반대되는 의미로 기술 자산이라 불러도 좋을듯 하다. 

 자동화 테스트는 젠킨스와 같은 CI툴과 만나 더욱더 놀라운 시너지 효과를 낸다. 프로젝트의 누군가가 새로운 소스를 커밋 한다면 CI서버는 이를 감지하여 자동화 테스트를 실행하고 그 결과 최단 시간에 새로운 코드가 발생 시킬 수 있는 문제점들을 알려준다.

 자동화된 테스트 코드의 가장 큰 장점은 코드가 사양 변경에 매우 견고해 진다는 점 이다. 제대로 작성된 테스트 코드를 가지고 있다면 추가되는 사양 변경에 대해 두려움 없이 작업을 할 수 있을것이다. 테스트 결과는 수정한 내용이 다른 코드들에 부작용 없이 잘 움직인다는 것을 보증해 줄 것이며 만약 예상치 못한 문제가 생기더라도 즉각 CI를 통해 이를 인지 하여 대처 할 수 있을 것이다.

 성실하게 작성된 테스트 코드들은 부채가 아닌 착실하게 신뢰성이라는 이자를 불려가며 당신의 코드를 더욱더 가치있게 만들어 줄 것이다.

만약 프로젝트 일정중에 잠시잠시 여유시간이 생긴다면 언제나 자동화 테스트를 추가하고 또 추가하라. 언제나 녹색을 유지하는 테스트 결과 그래프는 당신의 작업을 더욱 즐겁게 만들어 줄 것이다.

리팩토링

 리펙토링은 특히 자동화 테스트와도 밀접한 관계를 지닌다. 요즘같이 좋은 툴이 리펙토링을 지원하는 시대에도 어쨌든 소스코드가 변경된다는것은 테스트가 필요함을 의미하기 때문이다.

리팩터링에 대해서는 아래의 글을 참고하길 바란다.

Java언어로 배우는 리팩토링(PDF) 

 여기서 한가지 짚고 넘어가고 싶은 것은 많은 사람들이 리팩토링을 단순히 소스코드를 보기 좋게 하여 가독성을 높이는 작업 쯤으로 인식하고 있는데 객체 지향 프로그래밍에서 리팩토링은 보다 심오한 의미를 지닌다.

 자바와 C#을 비롯한 많은 언어들을 객체 지향 프로그래밍이 대세가 되었다는 지금에도 실상 동작하는 코드의 내부를 들여다보면 트랜잭션 스크립트 패턴을 이용하는 경우가 거의 대부분이다. 하지만 진정한 객체 지향 프로그래밍을 위해서는 도메인 모델링 패턴이 반드시 필요 하며 이를 위해서는 반복 적인 객체 모델링 작업이 필수적이다.

 다만 도메인 모델 패턴은 플라톤의 이데아론에 비견될 정도로 한번에 완성된 모델을 제시하는 것이 쉽지 않기 때문에 모델 변경과 구현의 사이클을 지속적으로 행하는 반복적 정제가 거의 필수이자 최선의 개발방법으로 여겨진다.

도메인 모델 패턴에 대해서는 최범균님의 블로그에 상세히 소개되어 있다.

 리팩토링 작업은 기능 추가 및 개선 작업 과는 별도로 진행되는 특성이 있으므로 프로젝트를 원활히 돌리기 위해서는 고수준의 형상관리 능력을 요구 받는다. 즉, 메인 스트림의 개발을 멈추지 않으면서 브런치로 리팩토링을 진행하고 다시 이를 머지 하는 과정이 필수적이라고 할 수 있다.

결론

 프로젝트 내부에서 기술 채무는 빨리 제거 하는 것 만이 능사는 아니다. 서론에서 기술한 바와 같이 기술적 채무는 개발자가 게을러서 발생하는 것이 아니며, 스케줄 진행상 거의 필수 불가결하게 발생하게 되므로 적절하게 관리만 된다면 프로젝트 진행에 상당한 융통성을 가져다 줄 수 있다.  물론 처음부터 기술 부채가 발생하지 않도록 노력 하는 것은 중요하지만 사안에 따라서는 프로젝트 이해 관계자들의 승인 하에 과감한 이월(유지 보수 관리자에게 떠 넘기기)을 선택 하거나 아예 디폴트를 선언하는것도 한가지 방법이 될 것이다.  디폴트 선언(냄새나는 코드 무시하기)에 대해서는 Eric Evans가 제안한 전략적 설계가 좋은 지침이 될 것이다. 

 기술 부채는 금융 부채와 마찬가지로 한꺼번에 상환 하기 어려운 경우가 대부분이기 때문에 프로젝트 매니저는 스케줄 관리에 기술 부채 상환에 대한 부분을 반영하고 전략적으로 유지 되도록 관심을 기울여야 할 것이다. 작업 관리에 Trac이나 Redmine과 같은 이슈 트랙커를 사용하고 있다면 이러한 기술 부채를 다루기 위한 별도 카테고리를 만들어 관리하는 것도 좋은 방법이다.

 기술적 부채의 관리에 관한 보다 심도있는 논의는 InfoQ에 Sven Johann과 Eberhard Wolff가 개제한 Managing Technical Debt를 읽어볼 것을 추천한다.

It will fail. Keep it simple. - 핀터레스트의 스케일링 노하우

4월달에 포스팅한 QCon Tokyo 2013에 대한 글에서 핀터레스트(Pinterest)의 스케일링에 대한 Marty Weiner씨의 강연에 대해서 언급한적이 있다.

핀터레스트는 국내에서는 잘 알려져 있지 않지만 일종의 사진중심의 SNS로 북미 지역에서는 상당한 인기를 끌고 있다.

QCon SanFrancisco 2012에서의 강연 동영상(영어)

영어의 압박이 있긴 하지만, 스케일링에 대한 살아있는 노하우를 얻을 수 있는, 서버의 규모를 키워나가야 하는 인터넷 서비스 관련자에게는 귀중한 노하우가 되리라 생각한다.

추가: 포스팅 이후에 국내의 한 블로거가Junichi Niino씨의 블로그 포스팅을 번역한 글을 발견했기에 링크를 추가한다. 프레젠테이션 내용과 함께 잘 정리되어있다.

QCon Tokyo 2013 Scaling Pinterest 강연내용 요약 (한글)

스크럼 개발팀의 최적 인원수는 몇명일까?

8월 말경 참가했던 "폭포수 개발 경험자를 위한 스크럼 강좌" 에서 있었던 일이다.  교육 내용중에 스크럼 개발팀의 최적인원은 5인에서 9명까지라는 내용이 있었는데 어떤 근거로 그러한 수치가 나왔을까가 의문이었다.

개인적으로 팀의 인원구성은 금전적인 영향 이상으로 프로젝트에 큰 영향을 미치는데, 이른바 무임승차 팀원의 발생과 그로 인한 팀웍의 저하때문이다.

얼마전 휴가중에 읽은 '착각하는 CEO(유정식저)'에서 이러한 나의 의문에 관련된 부분이 있어 내용을 요약해 소개해 보고자 한다. 참고로 이 '착각하는 CEO'에서는 팀 운영과 관련해서  깊은 심리학적 통찰력을 제공하고 있으므로 팀 매니지먼트에 관심있는 분은 꼭 읽어두길 권한다.

패트릭 라플린의 연구결과에 따르면 고도의 사고를 요하는 문제풀이에서 팀을 이뤄 문제를 풀 경우의 정답에 이르기 까지 필요한 질문의 수를 조사해 평가하는 방식으로 다음과 같은 사실을 이끌어냈다.

개인의 성적 ≒ 2인그룹의 성적 < 3~5인그룹의 성적

라플린이 이 연구를 통해 얻어낸 결론은 다음과 같다.

1. 문제 해결의 효율성은 세 명 이상일때 가장 좋다.
2. 세명 이상의 그룹에서는 인원이 추가되어도 문제 해결력이 더 좋아지지 않는다.

그렇다면 그룹이 다섯명을 넘어설때에는 어떠한 일이 발생할까?

조셉 렌줄리는 각각 한 명, 세 명, 여섯 명, 열두 명으로 이루어진 그룹을 구성하여 창의적인 발상을 제시하라고 지시했다. 각 그룹의 창의성을 평가하니 세명짜리 그룹과 여섯 명짜리 그룹은 차이가 거의 없었다. 팀원 한 명이 평균적으로 그룹에 기여한 바를 측정하니 그룹 규모가 커질수록 그 값이 줄어드는 이른바 무임승차자가 발생했기 때문이다.

팀원수가 적정수준을 넘어서게 되면 무임승차 하는 인원이 발생하기 쉬워진다.

'착각하는 CEO'에서 저자 유정식씨는 적절한 팀원의 수를 연구, 문제해결과 관련된 팀원은 3~5명, 단순한 업무를 수행하는 운영위주의 팀은 열명정도를 하나의 팀으로 묶는것이 좋다고 하는 안토니 제이의 의견을 팀 구성 최적 인원수의 근거로 제시하고 있다.

스크럼팀은 대부분 운영보다는 연구, 문제해결을 위한 팀으로 볼 수 있을것이고 이에 따라 필요한 최저인원은 3명이지만 실제로는 4인 이상이 적합할 것이다. 대체로 팀원중 한 명은 팀 리더가 되어 실제적인 업무외에 내외부 커뮤니케이션 관련 업무에 많은 시간을 할애해야 하기 때문이다.

따라서 위의 연구 결과를 토대로 필자가 내린 견론은 팀으로서의 시너지 효과를 내면서 무임승차 없이 최고의 효율을 기대할 수 있는 개발팀의 인원 수준은 4~7명으로, 8명 이상의 인원이 된다고 하면 두개의 팀으로 나누는것이 스크럼팀으로서는 더 높은 효율을 낼 수 있을것이다.

다만 이는 어디까지나 작업 스케줄을 개인이 아닌 팀단위로 생각하는 스크럼팀에 한정된 이야기로, 전통적인 폭포수 개발 관리법에 의한 개발을 수행하는 팀의 경우는 운영위주의 팀으로 보고 단일 팀에 대해 최대 10명정도까지는 효율적인 운영이 가능할 것이다.

JAVA EE 7에 추가된 "핫" 한 기능들

오늘은 6월 12일 발표된 자바 엔터프라이즈 에디션 7(이하 Java EE 7)에 새로이 추가된 기능들을 간략히 살펴보고자 한다.

전체적인 방향성은 Spring의 장점을 받아들인 Java EE 6 의 흐름을 계승하고 있으며, 눈에 띄는 큰 변화라고 한다면 HTML5를 비롯해 WebSocket과 JSON서포트 그리고 크라우드 환경에 대한 지원을 들 수 있겠다. 이 외에 잡 플로 컨트롤을 가능하게 하는 배치 프레임워크의 등장이 눈에띈다.

Glassfish4를 필두로 Java EE 7을 지원하는 어플리케이션 서버가 속속 등장하고 있는 상황에서 조만간 Spring과 함께 엔터프라이즈 어플리케이션의 표준으로 자리 잡을것으로 기대된다.

HTML5
우선 가장 큰 특징으로 꼽는것이 HTML5의 지원이 되겠다. 단순히 스팩에 대한 지원 뿐만이 아니라 보다 편리하게 HTML5를 이용 할 수 있도록 여러 기능들을 추가해 놓았다. 아울러 최근 웹 트렌드를 반영하고자 크롬을 포함한 웹 브라우저들이 잇달아 지원을 시작한 WebSocket과 웹상에서 데이터 프로토콜의 표준으로 자리잡은 JSON에 대한 서포트도 주목 할 만 하다.WebSocket과JSON은 아래 별도항목으로 자세히 다루도록 하겠다.

WebSocket
Java EE 7의 WebSocket지원은 HTML5의 등장과 더불어 미래 웹 기술을 방향성을 보여준다. WebSocket은 장점은 기존의 HTTP상에서 구현되던 Ajax나Comet에 비해 보다 적은 오버헤드로 쌍방향 통신이 가능하다는 점 이다. 즉, HTTP기반 프로토콜은 각각의 Request와 Response별로 HTTP헤더를 첨부해 보내는 형식으로 커넥션을 반복해서 맺어야 했던것에 비해 WebSocket은 한번의 핸드쉐이크 이후에 하나의 연결을 계속해서 재 사용 할 수 있다는 것이 매리트이다.

JSON
군살 없는 데이터 표현방식으로 최근 각광받는 JSON에대한 API가 추가되었다. 개인적으로 JSON은 확작성과 가벼움을 동시에 갖춘 텍스트 베이스 데이터 포멧으로 향후 웹 뿐만 아니라 다양한 분야에서 기존 데이터 포멧을 대체해 나갈것으로 기대하고 있다.

JMS 2.0 API
Java EE에서 JMS지원은 특별히 새로울것도 없지만 JMS2.0의 경우 송수신을 위한 간편한 API가 추가된 점이 눈에 띈다.

클라우드 환경 지원
사실 Java EE 7 사양 발표시에 가장 주목하고 있던 부분이지만 아쉽게도 이번 7에서는 기본적인 사항들만 지원한다고 하는 어정쩡한 형태가 되고 말았다. (이러한 어정쩡함 때문에 아마도 상용 프로젝트에서 이 Java EE 7 의 클라우드 지원 기능을 이용하는 케이스는 찾아보기 어려우리라.) 본격적인 클라우드 지원은 Java EE 8부터 가능할 것이라고 하는 예측이 많지만 완벽한 형태의 네이티브 클라우드의 지원이 가능할 것인지에 대해서는 클라우드 자체도 아직 표준이 정착되지 않은 상황인지라 회의론도 만만치 않다.

배치 프레임워크
엔터프라이즈 어플리케이션에서 배치 어프릴케이션이 차지하는비중을 생각한다면 이제와서야 프레임워크에서 지원된다는 점은 다소 늦은 감이 있다. 그동안 Jboss나 WebSphere와 같이 밴더별로 지원해 오던 배치잡 관련 기능(스케줄링, 잡 플로우 컨트롤)이 표준 사양화 됨에 따라 향후 엔터프라이즈 어플리케이션 개발에 많은 영향을 끼칠것으로 기대된다.

JAX-RS 2.0
심플함을 추구하는 경향상 SOAP보다 REST가 대세로 자리를 굳혀가는 모양새다. 7부터는 JAX-RS 2.0의 지원으로 RESTful서비스와 관련하여 보다 다양한 기능들을 제공하고 있다.

병렬처리 관련 기능 강화
병렬처리와 관련한 유틸리티가 추가되었다. 특히 주목할 부분은 7 부터 도입된 하이레벨 스레드 컨트롤 기능이다.

CDI
큰 인기를 끈 Java EE 6에 이어서 7에서도 CDI가 지원되고 있다.

Servlet 3.1
당연하게 들릴지도 모르지만 최신 서블릿 사양인 Servlet3.1이 7에서 지원된다.
Servlet 3.1은 논-블로킹 I/O를 포함한 향상된 HTTP프로토콜 매커니즘과 보안기능 향상을 제공한다.

자바 디컴파일 솔루션 소개

오픈소스가 주류를 차지하는 오늘날에도 자바 라이브러리 (jar) 파일에서 자바 소스를 추출해 내야 하는 경우가 종종 생기곤 한다. 이러한 경우 이 글이 도움이 될 수 있을 것이다.

1. Jar 파일 갯수가 적을 경우
JD-GUI
단독으로 동작하는 어플리케이션으로 어노테이션등 자바 5 이후의 소스에 대해서도 디컴파일을 가능하게 해준다. JAR 파일 단위의 디컴파일을 지원하며 디컴파일 된 소스는 패키지 구조 그대로 폴더에 저장된다. 디컴파일 하고자 하는 jar 파일이 적을경우 대단히 훌륭한 솔루션 이지만 jar파일이 수백개에 이른다던지 하는 경우 커맨드라인 인터페이스를 지원하지 않아 일일이 GUI를 통해 디컴파일을 해야만 하는 번거로움이 있다.

JD-Eclipse (Eclipse Plugin)
이클립스의 경우 JD-Eclipse를 추천한다. jadclipse도 같은 기능을 하는 플러그 인이기는 하나 기능적으로 최근까지 꾸준히 업데이트를 해 오고 있는 JD-Eclipse가 보다 나은 선택이 되리라 본다. (jadclipse는 2009년11월 업데이트를 마지막으로 개발이 멈춰있는 상태이다.)

2. Jar 파일 갯수가 대단히 많을경우
이 포스트를 작성하는 2013년 5월 현재. Java Decompiler 프로젝트에서 아직까지 커맨드라인 인터페이스를 제공하지 않는 관계로 수백개에 이르는 Jar파일을 디컴파일 해야 하는 경우에 의지력을 시험받는 경우가 생겨난다. 만약 자신의 인내심의 한계를 넘어가는 객수의 jar 파일들을 디컴파일 해야 하는 경우 다음과 같은 방법을 사용해 일괄적으로 디컴파일이 가능하다.
※단, 이 경우 제약이 있는데, jad 디컴파일러 자체가 워낙에 오래된 디컴파일러 이다 보니 어노테이션 같은 자바 5 이후의 문법에 대해서 제대로된 디컴파일이 되지 않는다는 점 을 주의해야 한다.

준비물
jad
jadretro
cygwin (리눅스나 유닉스의 경우 필요 없음. 위도우 쉘이나 파워 쉘을 사용하고자 하는 경우는 각자의 환경에 맞게 스크립트를 수정하여 사용할 것.)

①디컴파일 하고자 하는 jar파일들을 한자리에 모은다.
②7zip과 같은 압축 관리 툴을 이용해 jar 파일들을 각각의 파일명으로 된 폴더 아래 압축을 풀어낸다.
③java 5 이후의 컴파일러로 컴파일된 class파일들의 경우 jadretro를 이용해 jad가 디컴파일 가능한 형태의 바이너리 파일로 변환시켜 준다.

(for f in `find [class파일 저장 폴더] -name '*.class'`;do jadretro $f;done)

④폴더명을 jad컴파일러로 넘겨주어 디컴파일을 실행

(for f in `ls -1 [class파일 저장 폴더]`;do `jad -o -r -sjava -d[소스파일 저장 폴더]/$f/ tmp/$f/**/*.class` ;done)

QCon Tokyo 2013

이번주 화요일, 개발자 커뮤니티인 InfoQ에서 진행하는 컨퍼런스인 QCon Tokyo 2013에 다녀왔습니다.
올해는 크라우드,모바일/HTML5,임베디드,에자일/모델링,빅데이터/분산처리를 중심으로 세션이 펼쳐졌으며 저는 개인적인 관심 분야인 클라우드와 DDD(Domain Driven Design)을 중심으로 세션에 참가하였습니다.

QCon Tokyo 2013 프로그램

개인적으로 인상깊었던 세션에 대해서 간단히 소개해 봅니다.

Scaling Pinterest - Marty Weiner

사진공유 서비스인 Pinterest의 엔지니어인 Marty Weiner씨가 처음 1명의 개발자와1대의 서버로 시작한Pinterest가 서비스 규모를 키워감에 따라 어떻게 스케일링 문제에 대응해 나갔는지에 대해 발표한 세션으로 실제 서비스 상에서 발생한 문제에 대한 성공과 실패에 대한 개발자의 생생한 경험담을 들을 수 있는 값진 시간이었습니다. 개인적으로는 이번 컨퍼런스에서 가장 건질것이 많지 않았나 싶습니다.
간단히 요약 하자면
-소규모에서는 MySQL이 짱임.
-스케일링 성공의 열쇠는 아마존 EC2/S3의 활용
-대규모 데이터베이스 구축에 있어서의 클러스터링 보다는 분할(Sharding)이 유리
프레젠테이션 자료는 위에 링크한 프로그램 안내표에서 받으실 수 있으며 조만간 동영상 링크가 추가될 예정입니다.

DDD를 스크럼으로 진행하자! 또는 스크럼을 DDD로 진행하자! - 하라다 키로

도메인 드리븐 디자인. 요즘 공부하고 있는 분야기인 한데 도통 감이 안와세 헤메이고 있습니다. 하라다씨는 어제도 같이 술한잔 했던 분인데 적지 않은 나이임에도 불구하고 열정으로 가득찬 열혈 개발자 이십니다. 솔직히 일본에서 일하면서 놀랐던 점은 나이 많은 분들이 현역에서 활동하면서 경험과 지식을 후배들 전해주고 있다는 점 입니다.

암튼 요약하자면
-처음부터 완벽한 모델링을 추구하려 하지 마라. 어차피 쓸모 없어진다. 빨리 만들어서 돌려보고 피드백 하라.
-전통적인 워터플 개발프로세스에선  DDD는 위의 이유로 성공하기가 어렵다.

DDD로 수행하는 Scrum 플로우

Model Exploration Whirlpool

하라다씨가 자신의 세션에서 필살기로 준비한 그림입니다. 문제는 아직도 제 눈에  C자 세개 겹처놓은것으로 밖에는 보이질 않는다는 점 입니다.
Model Exploration Whirlpool 설명 PDF자료


작은 오브젝트로 도메인모델을 작성하라 : DDD실전가이드 - 마스다 토루

바로위의 하라다 키로씨의 세션이 DDD와 에자일의 개념 소개에 치중한 반면 이번 세션은 실제 DDD를 개발에 적용함에 있어서 신경 써야 할 사항들을 구체적으로 제시합니다. 마스다 토루씨도 컨퍼런스후에 열린 맥주파티에서 이야기 할 수 있는 기회가 있었는데 제 아버지 연배임에도 개발 전반에 대해 이야기가 잘 통해서 놀랐습니다. (특히 클라이언트 뒷담화)

세션 내용을 요약하면
- 커뮤니케이션의 불완전함이 결국 모델의 불완전함으로 이어진다. 완벽한 소통을 위해서는 움직이는 프로그램을 하루라도 빨리 고객에게 제공하고 피드백을 받아야 한다. (위 세션 내용과 거의 같은 맥락임)
- 도메인 모델을 가능한한 잘게 나눌것
- 도메인 층을 UI.데이터베이스,외부인터페이스와 분리하여 관리할것
- 확장성을 생각한답시고 복잡하게 디자인하지 마라. 눈에 보이는것을 구현하는것으로 충분할 때가 많다.
- 도메인 오브젝트는 작명에 신경쓰고, 작게, 잘게.
- 무조건 작게 만들라! -예) 클래스는 50줄 이내, 메소드는 3줄 이내, 팩키지는 10파일 이내. 커지는것은 결국 재사용을 어렵게 하고 리팩토링을 힘들게 하여 점점 프로그램을 망가트린다.
등등등.. 암튼 적다보니 상당히 알찬 세션이였구나 하는 생각이 듭니다.

끝나고보니 버벅대는 영어로 들이대며 다닌 데다가 잘 못하는 술에 맥주한잔 마시고 얼굴이 벌게서 돌아다닌게 생각나 챙피한 하루였습니다. 요번 골든위크 연휴때는 조용히 집에서 에릭 에반스의 Domain Driven Design 이나 정독해 봐야겠습니다.

책 이야기 - 문장강화

문장강화.


대학교 교양수업시간에 읽은 이후 언제 다시한번 정독해야지 하고는 18년 이라는 세월이 흘러버렸다. (연수를 꺼내니 갑자기 울컥해진다.)

3년전 구입해서 충분히 숙성된 이 책을 지난 주말 아침 마눌님께서 주무시는 틈을 이용해서 읽어 보았다.

이 책의 놀라운점은 무려 쓰여진지 70년이 넘은 책 임에도 오늘날 글쓰기에 유용한 책을 거롤하는 자리에는 꼭 그 이름이 등장한다는 점과 책의 내용이  "고칠수록 좋아지는 것은 문장의 진리다" 라는 한줄로 요약이 된다는 점 일 것이다.

주옥같은 예문들은 읽는것 만으로도 내공이 쌓이는것을 느끼게 해 주는 말 그대로 무림 비급이라 할 수 있겠다.

집이 좁은 나같은 사람에게도 부담없이 eBook으로도 나와 있으니 모쪼록 글쓰기에 목마른 사람들에겐 꼭 읽어볼 것을 추천한다.

책을 다 읽고 보니 문득 옆에 놓여져 있는 맨먼스 미신에도 눈길이 간다. 문장강화에 비해서는 한참이나 어리지만 아직까지 읽히는 컴퓨터 관련 서적으로서는 최고령 (1975년 초판발행)이 아닐까 싶다.

뛰어난 통찰은 시대를 뛰어넘는다.

윈도우PC들의 소프트웨어 설치 원격 관리하기

회사 또는 소프트웨어 개발 프로젝트에서 신입 요원이 들어온 첫날 하는 일은? 다른건 몰라도 PC를 지급받고 필요한 소프트웨어를 설치하는 작업은 빠지지 않을까 한다. 오늘은 윈도우 환경 PC들에 대한 인스톨 작업의 자동화 및 원격 관리에 방법을 소개해 보고자 한다.

Active Directory환경의 윈도우 PC들

의외로 많이 쓰여지지 않는 기능인데, 마이크로 소프트에서는 Active Directory의 그룹정책을 통해 원격으로 어플리케이션을 인스톨/제거 할 수 있는 관리 기능을 제공하고 있다.

HOWTO: Windows Server 2003에서 그룹 정책을 사용하여 소프트웨어 원격 설치

위 방법은 서버 2003뿐만이 아니라 Windows 2000 이후에 발표된 모든 윈도우 제품군들에 대해서 사용이 가능하나, 배포하려는 소프트웨어는 확장자가 msi이어야만 한다는 제약이 따른다. EXE로 배포되는 인스톨러를 MSI로 변환하는 툴은 아래 사이트에서 구할 수 있다.

Convert EXE To MSI

WPKG를 이용한 리모트 인스톨

Active Directory이외의 환경이나 msi파일 이외의 패키징으로 프로그램을 설치해야 하는 경우엔  WPKG를 추천한다. WPKG는 클라이언트 서버 프로그램으로 구성된 오픈소스 솔루션으로 다음과 같은 기능들을 제공한다.

• 윈도우PC에대한 완전 자동화된 프로그램 배포/업데이트/삭제
• MSI,EXE를 포함해 어떠한 포멧이라도 배포 가능
• 그룹이 다른 PC들 또는 단일 PC에 대한 프로그램 배포
• 간단한 사용법
• 커스텀 스크립트를 이용해 프린터 세팅, 월 페이퍼 변경, 시계 동기화, 레지스트리 변경을 포함한 거의 모든 종류의 윈도우 세팅 변경이 가능
• 로컬 도메인, 워크스페이스는 물론 인터넷과 VPN등의 네트워크 환경에서 동작 가능
• 윈도우즈2000에서부터 윈도우8 까지 다양한 윈도우 OS를 서포트. 
• 과거 작업들에 대한 목록 보존 가능
• 직관적인 웹 인터페이스 제공

WPKG 홈페이지

젠킨스(Jenkins)를 이용한 지속적 통합(CI:Continuous Integration) (1) - 미스터 젠킨스씨를 소개합니다.

젠킨스(Jenkins)를 이용한 지속적 통합(CI:Continuous Integration)

(1) 미스터 젠킨스씨를 소개합니다

(2) 젠킨스씨가 있는 개발풍경

고담시의 평화를 지키는 배트맨. 악당들과 싸움질에 바쁜 부르스 웨인의 곁에는 언제나 묵묵히 자리를 지키며 보좌해온 집사 알프레드가 있었다. 

이상적인 집사의 표상

배트맨에서 알프레드가 하는 집사 역할의 중요성은 <다크나이트 라이징>에서 아직 상당한 재산이 남아 있었음에도 전기 요금을 못내 전기가 끊기고, 그 결과 추운 대리석 바닥에서 자다가 안좋아진 컨디션으로 인해 베인이게 일방적으로 혼쭐이 나는 배트맨의 모습에서 잘 알 수 있다.

여담이지만 일상적인 집사 역할 이외에 알프레드의 역할은 다음과 같다.

• 배트맨 부재시 배트 케이브 경비
• 배트 모빌을 포함해 배트맨이 사용하는 각종 장비의 제작 및 정비
• 의료
• 비상시 전투 보조(특히 사격)

단, 출신이 그곳이다 보니 요리만큼은 잘 못한다 카더라...

아무튼, 물려받은 재산은 없어도 바쁘기 만으로 따지면 배트맨 부럽지 않은 우리 프로그래머들에게도 알프레드와 같이 묵묵히 온갖 굳은일을 처리해주시는 분이 나타나셨으니 그분이 바로 오늘 여러분들께 소개드릴 젠킨스씨이다.

이... 이분은 아니시고...

이분이 젠킨스씨 (2010년까진 허드슨)

젠킨스는 Agile창시자중 한명인 마틴파울러씨가 주창한 지속적 통합(Continuous Integration)을 구현하기 위한 자바 오픈소스 소프트웨어로서 웹 어플리케이션의 형태를 하고 있다. 국내에서는 허드슨이란 이름으로 더 잘 알려져 있으며 2010년 오라클과의 상표권 문제로 인해 젠킨스로 이름이 바뀌게 되었다.

젠킨스의 배경에 대한 좀 더 자세한 사항은 위키피디아의 해당 항목을 참고하기 바란다.

젠킨스가 제공하는 기능은 다음과 같다.

• 미려한 웹 인터페이스를 통한 간편한 설정
• 강력하고 편리한 레포팅 기능
• 지속적인 자동화 빌드
• 지속적인 자동화 테스트
• 커버리지 감시
• 코드 품질 감시
• 다양한 인증기반과 결합한 인증 및 권한관리 기능
• Groovy script를 이용한 고수준의 잡 스케줄링 기능
• 커맨드라인 인터페이스 제공
• 자동화된 배포 관리
• 분산빌드 기능
• 윈도우 커맨드 스케줄링 실행기능

이 외에도 지금도 활발히 추가되고 있는 수많은 플러그인을 통해 간단히 기능을 추가/확장 할 수 있다.

이렇게 강력하면서도 많은 기능들을 제공해 주지만 젠킨스는 노련한 집사의 이미지 답게 까다롭지 않으시다. (게다가 무보수이다!)

배포파일은 Java Web Archive(.war)화일 형태로 제공되어 기본적으로 자바가 동작하는 환경이라면 어디든지 동작하며 윈도우, Ubuntu, Red Hat, Mac OS X, BSD등 아홉가지 OS에서 동작하는 네이티브 패키지를 제공한다.

젠킨스는 이미지 그대로 집사와도 같이 귀찮은 잡무들을 해결해 줌으로서 개발자들이 본연의 창의적인 업무에 집중 할 수 있도록 도와준다. 굳이 Agile이라는 키워드를 꺼내들지 않더라도 젠킨스는 사용하기에 따라 거의 대부분의 프로젝트에서 개발자와 관리자에게 도움을 줄 수 있으리라고 확신한다.

관련링크

젠킨스 프로젝트 홈페이지

지속적 통합의 이점

픽션에 등장하는 집사들

다음번 포스팅에서는 젠킨스의 설치와 주요 플러그인에 대해서 알아보도록 하겠다.

블로그를 시작하며

Agile개발이라는 주제로 새롭게 블로그를 시작합니다.

작심삼일이 되지 않게 열심히 해 볼 생각입니다.
하루 하루 절실하게!
감사합니다.