MORE AGILE: 4월 2014

2014년 4월 29일 화요일

도메인 주도 설계와 애자일 개발

왜 모델링이 필요한가?

우리들이 프로그램을 제작하는 과정은 현실의 어떠한 사물이나 동작을 대상으로 하여 이를 추상적 형태로 변환시키고, 변환된 추상적 개념들을 이용하여 컴퓨터 안에서의 여러가지 형태로 실체화 시키는 일련의 과정을 거치게 된다.

프로그래밍에 있어서 어려운 점 가운데 하나는 구현하고자 하는 대상의 본질적인 원리를 정확하게 파악하기가 쉽지가 않다는 점이다. 우리가 오감을 통해 관찰 할 수 있는 범위는 구현 대상의 외형boundary에 한정되기 때문에 이러한 외형에 대한 관찰과 기존 지식을 통해 대상의 본질을 추론해 내야만 한다. 이러한 추론을 통한 추상화 작업을 프로그래밍에 있어서는 모델링이라 부르며 대상의 본질에 통찰해 내는 과정이 제한된 감각과 지식의 틀 안에서 이루어진다는 점 때문에 종종 플라톤 철학의 이데아론에 빗대어 지기도 한다.

인식과 실체의 사이에는 늘 일정한 갭이 존재하기 마련이다.

결국, 구현 대상에 대한 이해도를 바탕으로 본질을 정확히 파악해 내고 이를 추상화 해 내느냐가 프로그램의 완성도를 결정하게 된다고 할 수 있다.

모델링에 대해서 좀 더 알아보고 싶다면 아래의 기사를 읽어볼 것을 권한다.(영문)

Models, Views, and Diagrams : What is a Model? - SourceMaking.com

모든 프로그램은 모델을 지닌다

설계문서를 일체 만들지 않는 프로그래밍이라 해도 모델링 작업은 반드시 거치게 되어 있다. 최소한 우리 머리속 에서라도 말이다. 하지만 두명 이상이 이러한 대상에 대한 인식을 공유하고자 할 때에 모델은 언어를 통해 세상에 그 모습을 드러 낼 수 밖에 없게 된다. UML과 같은 패턴언어는 경험을 패턴화 함으로서 지식 전달에 필요한 시간과 노력을 단축시키는데 사용된다.

혼자서 진행하는 프로젝트라 하더라도 모델링은 부족한 인간의 기억력을 보완해 주고 추상적 개념들을 시각화 해 나타내 줌으로서 프로그래밍에 적지않은 도움을 준다.

객체 지향 프로그래밍과 절차적 프로그래밍

객체 지향 프로그래밍Object-Oriented Programming, OOP이 무엇인지는 많은 문서들에서 설명되고 있으므로 굳이 여기서 언급하지는 않겠다. 다만 필자가 여기서 분명히 해 두고자 하는것은 OOP의 대비되는 개념으로 흔히 구조적 프로그래밍structured programming이 언급되는 경향이 있는데, 이는 잘못된 인식이라는 것 이다.

프로그램을 객체의 조합으로 보느냐 명령어의 조합으로 보느냐에 대한 기준으로 패러다임을 나누고자 한다면 OOP의 대칭점에 있는것은 절차적 프로그래밍procedural programming이며, 프로그램의 복잡성을 관리하기 위해 계층적인 구조를 가지는 구조적 프로그래밍의 사상은 OOP에도 그대로 살아 있다고 볼 수 있을것이다.

절차적 프로그래밍은 오랜 기간동안 프로그래밍 패러다임의 주류를 이루었으며 지금까지도 처음 프로그래밍을 배울때에도 절차적인 프로그래밍을 통해서 프로그램을 구현하는 방법을 배우게 된다. 이때문에 OOP가 주류가 되었다고 하는 지금까지도 형태는 OOP의 흉내를 내고 있지만 프로그램의 실제 구조는 절차적 프로그래밍을 띄고 있는 경우가 대부분 이다.

절차적 프로그래밍은 배우기 쉽고 빠르게 작성할 수 있으며 성능에 있어서도 효율적인 경우가 많아 아래 소개할 PoEAA에서도 트랜잭션 스크립트 패턴이란 이름으로 취급하고 있다.

PoEAA의 등장과 도메인 주도 설계

2002년 마틴 파울러는 Pattern of Enterprise Application Architecture(이하 PoEAA)를 통해 엔터프라이즈 어플리케이션에 있어서 OOP가 가져야 할 모습에 대한 재 발견을 이끌어 낸다. PoEAA는 디자인 패턴Design Pattern을 단순히 확장한 개념이라기 보다는 OOP본래의 패러다임에 충실하게 엔터프라이즈 어플리케이션의 각 요소들의 본질과 관계를 새롭게 패턴화 하여 정의하고 있는데, 이 책에서 확립된 개념들은 이후 등장하는 많은 아키텍처들에 큰 영향을 주게 된다.

에릭 에반스는 2003년 PoEAA를 기반으로 하여 패턴간의 상호 연관성을 실제적인 예제를 곁들여 해설한 도메인 주도 설계Domain-Driven Design(이하DDD) 를 발표한다. 이 책은 출간 직후부터 열렬한 환영을 받는데, 일정수준 이상의 복잡도를 지니는 어플리케이션 개발에 있어서 복잡성을 관리 할 수 있는 실천적인 전략과 패턴들을 제공하고 있었기 때문이다.

DDD의 네비게이션 맵

DDD에서에서 한가지 아쉬운점은, 의도적인지는 몰라도 PoEAA에서 기술한 여러 개념들에 대한 설명을 생략하고 있어 사실상 PoEAA를 먼저 읽지 않고는 제대로 이해하기가 힘들다는 점 이다. 비단 기업용 어플리케이션이 아니더라도 효율적인 소프트웨어 개발을 위해 모델링에 관심이 있는 개발자라면 이 두권의 책을 꼭 읽어둘 것을 강력히 권한다.(DDD의 경우 국내에도 이대엽씨의 훌륭한 번역으로 번역서가 출간되어 있지만 PoEAA는 절판이되어 구할수가 없다. )

DDD와 애자일 개발의 궁합

다시한번 말하지만 DDD는 지금까지 없던 새로운 개발 패러다임이 아닌 OOP 본래 모습을 되찾자는것이다. 하지만 OOP의 관점에서 객체를 모델링하는것은 말처럼 쉬운 일이 아니다. 동일한 객체라 할 지라도 시각에 따라 다양한 모습의 모델이 존재 가능하며, 복합적으로 상호작용을 하며 움직이는 객체를 설명하기 위해 다양한 모델이 동시에 존재하기도 한다.

인간의 표정에 대한 CG구현은 보이지 않는 뼈와 근육의 움직임에 대해서 모델링이 가능해진 시점에서야 자연스러움을 인정받게 되었다. 이러한 사물(객체)의 본질에 대한 고찰이야 말로 DDD를 수행해야 하는 가장 큰 이유이자 DDD의 수행이 어려운 이유이기도 하다.

DDD 수행에 있어서 애자일 개발 프로세스가 필요한 이유는 두가지이다.

첫번째는 바운더리를 통해 도메인 모델을 추론해 내는 작업을 한번에 해 내는것이 어렵기 때문으로, 모델이 올바른가를 증명하기 위해서는 이를 구현한 코드를 작동시켜보는 방법이 가장 유효한데, 동작을 통해 다시 모델을 개선시키고 구현을 통해 확인해 나가는 방법이 바로 스크럼과 같은 짧은 주기의 반복형 개발 프로세스. 즉, 애자일 프로세스이다. 반면, 한번 정해진 모델에 대해 변경이 쉽지 않은 폭포수형 개발 방식으로는 DDD를 수행하는것이 사실상 불가능하다.

Scrum으로 진행하는 DDD Flow(출전:MSDN)

도메인 정제 프로세스(출전:domainlanguage.com)

두번째는 모델링에서 구현에 이르는 일련의 작업들이 도메인 영역에 대한 이해도에 직접적으로 연관되어 이루어지므로 폭포수 개발에 따른 전통적인 역할분담(업무분석가or도메인 전문가, 설계자, 코더)으로는 엄청나게 늘어나는 커뮤니케이션 비용을 감당 할 수 없지만, 애자일 개발이라면 도메인 전문가에서 개발자에 이르는 커뮤니케이션 라인이 매우 심플하므로 이것이 DDD에 있어서 애자일 개발 프로세스가 필요한 두번째 이유이다.

위에 소개한 Model Exploration Whirlpool(모델 개발 소용돌이)은 DDD에 기반한 개발에서 많이 채택되는 프로세스인데, 눈에 보이는 부분인 시나리오에서 시작해 모델과 코드를 만들어 나가는 작업을 반복해서 수행함으로서 차츰 완성도를 높여 나가게 된다. 이러한 작업들은 기간을 나누어 구분해서 작업하는것이 아니라 동시 다발적으로 늘 이루어져야 하며 특히 시나리오와 모델의 정제작업은 사실상 분리가 불가능하므로 같은 사람이 수행 할 수 있어야 하며 DDD의 저자인 에릭 에반스는 모델 설계자가 코딩 작업에 참여하는것을 완전히 배재해서는 안된다고 말하고 있다.

2014년 4월 27일 일요일

엔터프라이즈 시스템에 있어서의 클라우드 컴퓨팅 도입

지난 20일, 삼성SDS의 과천센터에서 발생한 화재로 삼성 금융계열사의 홈페이지 접속과 온라인 결제가 중단되었었다. 비단 화재와 같은 재난 상황이 아니더라도 IT서비스를 본업으로 하지 않는 기업에서 사내 정보시스템 운영을 위해 물리적 서버를 운영하는것은 상당히 골치아픈 문제이다.

지금까지 국내의 클라우드 컴퓨팅 이용은 모바일게임, 인터넷계 기업의 웹 시스템이 주류를 이루었고, 사내 시스템의 경우엔 글로벌 비즈니스에만 주로 사용되어 왔다. 필자가 근무하는 일본 지역의 경우, 수년 전부터 불어닥친 정보 인프라의 클라우드화 열풍에 힘입어 이제는 어느 개발현장에서나 사내 정보시스템에 클라우드 컴퓨팅을 사용하는 풍경이 결코 낮설지 않다.

사내 정보시스템의 클라우드화에는 분명한 장단점이 존재한다. 이번 포스팅에서는 사내 시스템의 클라우드 마이그레이션이라는 테마로 사내 시스템의 클라우드화에 따른 장점과 과제를 정리해 보고자 한다.

사내 시스템과 클라우드 컴퓨팅

기업에서 사용되는 정보 시스템은 어느곳이나 비슷한 목표와 과제를 지닌다. 시간이 흐를수록 점차 정보시스템에의 의존도는 높아져 가고 있으며 그에따른 문제점도 빠른 속도로 표면에 등장하고 있다. 일반적으로 손꼽히는 현대 기업 IT부서의 현황과 문제점을 정리해 보자면 다음과 같다.

부족한 운영 인원 : 기업의 IT부서에서 시스템의 운영은 몇명의 시스템 관리자에 의존하는 형태가 많으며, 아예 시스템 관리 자체를 아웃소싱 하는 경우도 많다. 소수의 운영 요원으로 하드웨어에서 OS, 각종 미들웨어를 포함한 수많은 시스템 관련 소프트웨어를 효율적으로 관리/운영하기는 쉽지 않은데 그나마도 여유가 생기는 시점에 운영요원들에 대한 교육이나 외부 교육 컨설팅 등을 통해 질적 수준을 향상시키기 보다는 개발업무나 엔드유저 요구 대응과 같은 다른 업무를 병행시키는 경우가 다반사이다.
적절한 스케일링 전략의 부재 : 기업활동에 따른 시스템의 규묘와 복잡성은 날로 증가하는 반면에 이에 대응하는 시스템의 스케일링은 더디게 이루어진다.
서버 관리의 부담 증가 : 서버의 규모는 적게는 몇대에서 많게는 수백대에 이르는 경우도 있는데, 노후서버 교체, OS및 미들웨어의 업데이트및 모니터링과 같은 방대한 운영 업무들을 수작업에 의존하는 경우가 많다.
장애 대책 부재 : 앞서 소개한 세가지 요소들이 합체하면 "장애 대책 부재"로 변신을 하게 된다. 적은 인원으로 많은 업무를 수행하면서 주먹구구식으로 스케일링을 진행하다보니 수작업 미스에 의한 2중 3중의 재 작업이 발생하기 쉽다. 이러한 상황에서 서버의 구성을 2중화 하거나 백업시스템을 구축하는것은 아예 엄두도 못내는 경우가 태반이다. 장애 대책의 부재는 어느순간 치명적인 손해를 입히면서 그 모습을 드러내는데, 정보시스템에 점점더 많은 것을 의존하고 있는 현대기업의 특성상 그 손해가 기업의 생존을 위협하는 수준이 될 수 도 있다.

이러한 문제점을 해결하기 위한 수단으로 클라우드 마이그레이션에 대한 고려는 다음과 같은 가치를 지닌다.

운영의 효율화 : 시스템 인프라를 아웃소싱함으로써 시스템 관리자는 노동 집약적 물리적 서버 관리에서 해방된다.
장애 발생시의 대응과 시스템 백업 지원 : 클라우드 컴퓨팅이 지닌 큰 장점중에 한가지는 백업및 장애 대응에 있어서 높은수준의 지원을 받을 수 있게 된다는 점이다.
자유로운 스케일링 : 정보 시스템의 처리량에 대응하여 빠르게 시스템 자원을 늘리거나 줄이는것이 가능해 진다.
비용 절감과 도입 용이 : 단순히 서버 하드웨어비용이나 전기세만 놓고 보자면 사내에 서버를 두고 운영하는것이 더 싸게 먹힌다고 생각할 지 모르지만, 장애대응이나 운영비용을 모두 포함시켜 생각한다면 클라우드 컴퓨팅은 비용절감에 확실히 도움이 된다. 게다가 초기 투자비용이 거의 들지 않는점도 큰 매력이다.
고수준의 보안대책 : AWS나 MS Azure와 같은 퍼블릭 클라우드 서비스들은 대부분 프라이빗 VPN을 제공하여 인터넷을 통한 외부의 공격으로 부터 보호된 네트워크를 통해 클라우드 자원에 접근할 수 있도록 하고 있다.
모니터링 툴 제공 : 일반적으로 전산실을 운영할 경우 각종 하드웨어와 소프트웨어의 상태를 모니터링 하는데 들어가는 비용이 상당하다. 대부분의 클라우드 서비스는 높은수준의 모니터링 환경을 무상으로 제공하고 있다.
빅데이터 처리 : 기업에서도 점차 빅데이터 처리에 대한 수요는 커져가고 있으나 이를 처리할만한 자원이 부족하여 엄두를 내지 못하는경우가 많다. 클라우드 컴퓨팅을 이용한다면 대량의 데이터를 효율적이면서도 경제적으로 처리하는것이 가능해진다.

클라우드 컴퓨팅 도입의 과제

여러가지 장점에도 불구하고 보수적인 성향의 사내 시스템에 있어서 클라우드 컴퓨팅의 도입은 넘어야 할 산이 많다.

보안

프라이빗VPN을 사용한다고 하더라도 여전히 보안 문제는 기업이 클라우드 컴퓨팅을 도입하는데 있어서 큰 걸림돌로 작용하고 있다. 아무래도 기업활동의 핵심영역을 외부로 이동시키는 문제이다보니 경영자의 입장에선 신중에 신중을 기할 수 밖에 없는것이다.

이러한 인식의 문제는 단기간에 해결하긴 어렵지만 아마존이나 마이크로소프트와 같은 클라우드 서비스 사업자들이 적극적으로 국내에서 마케팅을 펼쳐나간다면 차츰 인식을 개선해 나갈 수 있을것으로 기대한다.

클라우드 환경에서의 보안에 대해서는 다음의 내용이 참고가 될 것이다.

전문가의 부재

사내 시스템의 클라우드 마이그레이션에서 또 한가지 큰 걸림은 기존 물리 서버에서 가상서버 시스템으로 전환하는 작업에 대한 경험을 지닌 전문가가 많이 부족하다는 점 이다. 일본에서도 이러한 전문가를 확보 할 수 있느냐 없느냐가 클라우드 컴퓨팅 도입 자체를 가능하게 하는 중요 요소로 작용한다. 하지만, 클라우드 컴퓨팅으로의 전환을 전문적으로 수행할 수 있는 경험과 실력을 지닌 엔지니어는 전체 운영 엔지니어 중에서도 극히 소수이며 여기에 DevOps적 역량을 지닌 엔지니어라고 하면 유니콘 개발자 수준의 귀중한 존재로 취급받는 실정이다.

미국내 시스템 운영 관련 직종의 급여 변동추이 (출전:indeed.com)

클라우드 컴퓨팅 마이그레이션을 수행하기 위한 전문가에게 요구되는 역량은 다음과 같다.

기존 물리 서버 환경과 가상 컴퓨팅 환경에 대한 높은 이해도
호환성과 관련된 OS및 하드웨어 구성에 대한 지식
서버 구축및 설정 자동화에 대한 지식
가상화 환경의 시스템 구성및 관리/모니터링 노하우
성능 관련 노하우
최적의 비용산출을 위한 이용 플래닝 능력

일본의 경우 아마존과 마이크로 소프트에서 무상으로 각각 자사의 클라우드 컴퓨팅에 대한 교육과 세미나를 실시하고 있으며, 특히 아마존의 경우 필요한 지식을 담은 서적을 자사의 ebook플랫폼인 Kindle을 통해 무상으로 배포하고 있다.

경영자의 인식부족

많은 장점에도 불구하고 국내에서 클라우드 컴퓨팅 도입에 있어서 무엇보다 큰 장벽은 경영자의 클라우드 컴퓨팅에 대한 인식 매우 낮다는 점 인듯 싶다.

국내 클라우드 시장 폭발적 성장, 그러나 인식의 장벽은 제자리 - 마이크로소프트

하지만 필자의 경험상 기존 전산실 관리나 인프라 아웃소싱에 비해 클라우드 켬퓨팅 사용의 장점은 비용대비 효율 면에서 매우 뚜렷하게 나타난다. 보수적이기로는 우리나라에 못지 않은 일본의 기업들도 이제는 당연하게 클라우드 컴퓨팅을 받아 들이는 모습을 볼때, 효율성을 최우선으로 하는 기업의 생리에 따라 결국 국내또한 엔터프라이즈 클라우드 컴퓨팅이 대세로 자리잡지 않을까 예측해 본다.

결론

비용대비 효용성뿐만 아니라, 보다 안정적인 기업경영을 위해서라도 사내 시스템에 클라우드 컴퓨팅을 도입하는것은 점차 필수 사항으로 자리잡아 갈 것으로 보인다. 다만 국내의 현실은 아직 클라우드 컴퓨팅에 대해 인식이 낮다는 점이 걸림돌이 되고 있다. 이러한 인식 개선을 위해서는 국내 기업에 대한 성공사례가 가장 좋은 마케팅이 될 것이다. 한국 시장 진출을 준비하는 아마존과 기존 인프라 사업자들간의 선의의 경쟁이 국내 클라우드 컴퓨팅의 보급을 촉진시키는 계기가 되길 기대해 본다.

2014년 4월 26일 토요일

자바 8 살펴보기

자바8을 배워둬야 하는 이유

지난달 18일 자바Java 8이 정식으로 발표 되었다.

자바의 버전 업은 크게 2가지로 구분하는데, 기능적인 부분의 개선이 주를 이루는 버전업을 진화계라evolution 하고 언어 자체의 형태에 변화가 오는 버전업을 혁명계revolution 라 칭한다. 자바 6,7이 전자에 속하며 자바 5와 이번에 발표된 자바 8이 후자에 속한다.

함수형 언어의 여러 개념이 도입됨으로 인해 자바 8는 자바 5보다 훨씬더 많은 변화를 자바 언어에 가져올 것으로 보이며 코드의 형태 자체가 이전의 자바와는 확연히 구별되는 모습으로 바뀔것이 확실하다.

이 말은 기존 자바 개발자들이 자바8을 제대로 사용하기 위해서는 새로운 언어 한가지를 더 배우는 정도의 학습 비용이 요구된다는 뜻으로, 2,3년후 새로운 문법에 최적화된 방식으로 자바를 배운 개발자와 기존 개발자간의 간격은 작성된 코드의 형태를 통해 뚜렷하게 드러날 것이다.

함수형 언어

우선 자바8을 들여다 보기 전에 함수형 언어의 개념에 대해서 이해하지 않으면 안된다.
함수형 언의 개념에 대해 잠시 시간을 내어 관련 기사들을 읽어 두도록 하자.

자바8의 모든것

캘리포니아에 있는 소프트웨어 개발사인 TechEmpower에서는 자사의 블로그 에 "Everything about Java 8"란 타이틀로 자바8의 새로운 기능들을 요약해서 소개해 놓았다. 본 포스팅은 이 기사를 요약/정리한 InfoQ의 기사를 기반으로 작성되었다.

자바8의 전체 기능에 대한 상세는 Java.net가 제공하는 기능일람을 참고하기 바란다.

인터페이스의 개선

인터페이스에 static 메소드를 정의하는것이 가능해졌다. java.util.Comparator에 추가된 static naturalOrder메소드를 살펴보자.

    public static <T extends Comparable<? super T>> Comparator<T> naturalOrder() {
        return (Comparator<T>) Comparators.NaturalOrderComparator.INSTANCE;
    }

default 지시자를 이용해 기본 메소드의 정의가 가능하게되어 인터페이스를 구현하는 기존 코드의 변경없이 새 메소드의 추가가 가능해졌다. 예를 들어 java.lang.Iterable에는 forEach메소드가 default로 정의되어 있다.

    public default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

처리해야할 데이터인 Customer와 처리 내용인 action이 메소드의 인자값으로 전달 가능하게 되어 Iterable Collection에 대한 반복처리가 매우 간단히 구현 가능하게 된다.

여기서 한가지 주의해야 할 점은 예외적으로 Object클래스의 메소드에 대해서 default구현은 정의 할 수 없다는 점이다.

함수형 인터페이스

함수 인터페이스functional interface는 단 하나의 추상 메소드가 정의 가능한 인터페이스이다. 인터페이스가 함수형 인터페이스임을 나타내는 수단으로서 FunctionalInterface 어노테이션이 도입되었다. 예를 들어, java.lang.Runnable은 다음과 같은 함수 인터페이스를 지닌다.

    @FunctionalInterface
    public interface Runnable {
        public abstract void run();
    }

하지만, 어노테이션을 통해 명시적으로 지정하지 않더라도 함수 인터페이스의 정의를 만족하는 인터페이스라면 자바 컴파일러가 주석의 유무에 상관없이 함수 인터페이스로서 취급한다.

람다식

함수형 인터페이스의 중요한 특성으로 람다식lambda expression을 사용한 인스턴스 생성이 있다. 람다식에 대한 자세한 설명은 아래 기사를 참고하자.

자바에서 람다 식이 필요한 이유 – 1
자바에서 람다 식이 필요한 이유 – 2

람다식을 이용하면 동작과 데이터를 모두 동적으로 설정하는것이 가능해진다. 아래의 예제들은 모두 왼쪽이 입력값이 되고, 오른쪽이 동작에 대한 정의이다. 입력값의 데이터 타입이 유추 가능하므로 생략되고 있다는 점에 주목하자.

    (int x, int y) -> { return x + y; }

    (x, y) -> x + y

    x -> x * x

    () -> x

    x -> { System.out.println(x); }

예를들어 Runnable 함수 인터페이스를 인스턴스화 하는것은 다음과 같다.

    Runnable r = () -> { System.out.println("Running!"); }

여담으로 필자는 위의 예제를 처음 접했을때 잠시 맨붕이 왔었다.
오래전 Lisp의 벽에 부딧혀 emacs에서 손을 뗀 필자에게 모습을 바꿔 찾아온 함수형 프로그래밍은 이제 10년 넘는 세월을 투자해 간신히 얻은 자바프로그래머로서의 지위에 대해 유통기간을 부여하고 있었다.

메소드 참조

메소드 참조method reference는 이미 이름이 있는 메서드를 대상으로 한 람다식의 간략형이며, 메소드 참조를 나타내는 예약어로서 (::)를 사용한다. 메소드 참조의 예와 그에 대응하는 람다식은 다음과 같다. 오른쪽이 메소드 참조, 왼쪽이 람다식이다.

    String::valueOf     x -> String.valueOf(x)
    Object::toString    x -> x.toString()
    x::toString         () -> x.toString()
    ArrayList::new      () -> new ArrayList<>()

캡처 vs 비캡처 람다식Capturing versus non-capturing lambdas

람다식의 외부에 정의된 static이 아닌 변수나 객체에 억세스하는것을 람다가 객체를 "캡쳐"한다고 부른다. 예를 들면 다음은 람다 변수 x에 억세스하는것이다.

    int x = 5;
    return y -> x + y;

람다식으로부터 억세스 가능한것은 로컬변수와 블록구의의 파라매터중에 final이거나 사실상 final판정effectively final을 받은 것에 한정된다.

java.util.function패키지에는 많은 새로운 함수형 인터페이스가 추가되었다. 몇가지를 예로 들자면 다음과 같다.

Function <T, R> - T를 입력으로 R을 출력으로 반환
Predicate <T> - T를 입력으로 boolean을 출력으로 반환
Consumer <T> - T를 입력으로 아무것도 반환하지 않는다
Supplier <T> - 입력을 취하지 않고 T를 반환
BinaryOperator <T> - 2 개의 T를 입력으로 하나의 T를 출력으로 반환

java.util.stream

자바 8의 중요한 패러다임의 하나로 새로운 java.util.stream패키지는 스트림에 대한 함수형 조작을 제공한다. 좀더 알기쉽게 설명하자면 배열이나 리스트, 맵으로 대표되는 컬랙션을 스트림으로 다룰 수 있게 되었다는 것 이다. 다음은 컬랙션에 대한 스트림화의 예이다.

   Stream <T> stream = collection.stream ();

이것이 함수형 프로그래밍과 결합하면 다음과 같은 형태가 된다.

    int sumOfWeights = blocks.stream () filter (b -> b.getColor () == RED)
                                      . mapToInt (b -> b.getWeight ())
                                      . sum ();

위의 샘플코드는 stream패키지의 Javadoc에 실린 예로서, stream의 소스로서 blocks라는 Collection을 사용하고 있다. 그 스트림에 대해 filter-map-reduce를 실행하여 붉은색(RED)블록에 대한 무게(weight)의 합(sum)을 구하는 일련의 과정이 한줄의 코드에 집약되어 표현되고 있다.

제네릭 타입 인터페이스의 개선

이 개선은 자바 컴파일러가 형에대한 추론능력을 갖추는 것으로 제네릭 형식 메소드 호출시 인수에 대한 형 정의를 생략 가능하게 해 준다.
예를 들어 자바7의 코드가 다음과 같은 것 이었다면

    foo(Utility.<Type>bar());
    Utility.<Type>foo().bar();

자바8에서는 인수와 호출에 대한 추론이 자동적으로 이루어져 다음과 같이 형태가 된다.

    foo(Utility.bar());
    Utility.foo().bar();

java.time

새로운 날짜/시간 관련 API가 java.time 패키지에 추가되고 있다. 클래스는 immutable이며 스레드에 대해 안전하다. 날짜 및 시간 형식으로 Instant, LocalDate, LocalDateTime, ZonedDateTime이 추가되었으며 날짜와 시간 이외의 것으로서 Duration과 Period가 추가되었다. 새로 추가된 값 형식은 Month, DayOfWeek, Year, Month YearMonth, MonthDay, OffsetTime, OffsetDateTime등이 있다. 이런한 새로운 날짜/시간 클래스는 대부분이 JDBC에서 지원됨으로서 RDB연동의 효율적인 구현이 가능하다.

Collections API의 확장

인터페이스가 default 메소드를 가질 수 있게 됨으로써 자바8의 Collection API에는 다수의 메소드가 새롭게 추가되었다. 인터페이스는 모두 default 메소드가 구현되었으며 새로이 추가된 메소드의 일람은 다음과 같다.

Iterable.forEach(Consumer)
Iterator.forEachRemaining(Consumer)
Collection.removeIf(Predicate)
Collection.spliterator()
Collection.stream()
Collection.parallelStream()
List.sort(Comparator)
List.replaceAll(UnaryOperator)
Map.forEach(BiConsumer)
Map.replaceAll(BiFunction)
Map.putIfAbsent(K, V)
Map.remove(Object, Object)
Map.replace(K, V, V)
Map.replace(K, V)
Map.computeIfAbsent(K, Function)
Map.computeIfPresent(K, BiFunction)
Map.compute(K, BiFunction)
Map.merge(K, V, BiFunction)
Map.getOrDefault(Object, V)

Concurrency API의 확장

Concurrency API의 기능이 추가되었다. 몇가지를 소개해 보자면, ForkJoinPool.commonPool()은 모든 병렬 스트림 작업을 처리하는 구조이다. ForkJoinTak는 명시적으로 특정 풀을 가지지 않고, 일반적인 풀을 사용하게 되었다. 말도 많고 탈도 많았던 ConcurrentHashMap은 완전히 재 작성되었다. 또한 새로운 Locking처리의 구현으로서 추가된 StampedLock은 ReentrantReadWriteLock의 대안으로 사용할 수 있다.

Future인터페이스의 구현인 CompletableFuture에서는 비동기 작업의 실행과 체이닝을 위한 방법이 제공된다.

IO/NIO API의 확장

IO/NIO에 메소드가 추가되어 파일이나 입력 스트림에서 java.util.stream.Stream을 직접 생성할 수 있게 되었다.

BufferedReader.lines ()
Files.list (Path)
Files.walk (Path, int FileVisitOption ...)
Files.walk (Path, FileVisitOption ...)
Files.find (Path, int BiPredicate, FileVisitOption ...)
Files.lines (Path, Charset)
DirectoryStream.stream ()

새로운 클래스의 UncheckedIOException은 RuntimeException을 확장한 IOException이다.

클로징 가능한 CloseableStream이 추가된것 또한 눈여겨 볼만 하다.

리플렉션과 어노테이션의 변경

어노테이션이 더 많은곳에서 사용될 수 있게 되었다. 예를들면, List<@Nullable String>과 같이 제네릭 형식 매게변수에 작성할 수도 있다. 따라서 정적 분석 도구에서 감지 가능한 오류의 범위가 확대되어 Java의 built-in type 시스템 또한 강화되고 정교해졌다.

Nashorn JavaScript엔진

Nashorn은 새로 JDK에 통합된 경량 고성능 JavaScript구현 엔진이다. Rhino의 후속이며, 성능과 메모리 관리가 개선되었다. javax.script API를 지원하고 있지만, DOM/CSS와 브라우저 플러그인API는 포함되어 있지 않다.

java.lang, java.util, 그리고 그 밖의것들

지금까지 언급한 것들 이외의 패키지에도 많은 추가 기능들이 있다. 몇가지 주목할만한 것들을 들어보자면, ThreadLocal.withInital(Supplier)는 보다 컴팩트한 thread 로컬 변수의 정의를 허용한다. 오랜 숙원이었던 StringJoiner과 String.join(...)가 자바8에서 구현되었다. Comparator는 체인 또는 필드기반의 비교를 가능하게 하는 새로운 방식을 제안하고 있다. String 풀의 기본값이 25~50K까지 확장되었다.

그분이 오신다. 긴장하라

눈치 빠른 독자들은 중간쯤에서 눈치를 채셨겠지만 자바8에서 추가된 중요 패러다임들은 대부분 멀티코어 프로세서상에서의 병렬처리 구현과 관련이 있다.

사실 자바 8의 모습에 대해서는 2011년 하반기에 어느 정도 윤곽이 확정되었으며 2013년5월8일 기능 사양이 동결되고 이후 모습을 드러낸 OpenJDK 8을 통해 많은 사람들이 준비해 오고 있었다. 기업용 어플리케이션의 경우 안정성을 중시하는 특성상 JavaEE8이 발표된 이후로도 얼마간 시간이 더 흘러야 주류로 정착될 것으로 보이긴 하지만 함수형 프로그래밍functional programming개념은 병렬처리 아키텍처나 코드 작성상의 간결함에 대한 매리트가 분명한 만큼 오픈소스 프로젝트를 중심으로 발빠르게 확산이 이루어지고 있으며, 자바4에서 5로 넘어가는 기간보다는 빠르게 확산될 것으로 보인다.

이미 Tomcat과 Jetty는 자바 8을 지원하고 있으며 Spring및 Play와 같은 프레임워크도 자바8 정식 발표와 거의 동시에 자바8용 업데이트를 발표하고 있는 실정이다.

기존의 자바 개발자들은 긴장해야 한다. 멀티코어 개발에 대한 열망이 그 어느때보다 높은 현 시점에서 자바8이 가져올 변화는 예상보다 빠르고 치명적인 모습으로 우리앞에 나타날지도 모른다.

2014년 4월 15일 화요일

글로벌 고수들의 노하우 대 공개 - 2013 QCon 뉴욕 강연내용 모음 (Scaling)

QCon은 InfoQ에서 주최하는 개발자 컨퍼런스로 런던, 뉴욕, 샌프란시스코, 토쿄, 베이징,샹하이,리오 데 자네이로, 그리고 상파울로에서 2007년부터 해마다 개최되고 있다.

각 도시에서 개최하는 QCon이지만 뉴욕과 런던, 샌프란시스코가 규모가 가장 크다. 유료 행사인 만큼 참가비로는 뉴욕의 경우 400달러, 동경은 만엔정도의 거금이 들지만 페이스북, 링크드인과 같은 성공한 업계 최고의 서비스들의 살아있는 노하우를 전수 받을 수 있는 기회인 만큼 매회 초 만원인 인기 행사이다.
국내에도 블로그 등을 통해 후기를 찾아 볼 수 있는걸 보면 한국서 찾아가는 사람도 있을 정도로 아름아름 입소문이 나 있는듯 하다.

하지만 외국에서 하는 유료 행사라고 낙심할 필요는 없다.
모든 컨퍼런스 내용은 동영상과 동영상연동 슬라이드, 그리고 PDF로 제공되고 있으며 InfoQ에 가입만 하면 무료다.(페이스북과 트위터, 링크드인의 계정을 이용한 인증도 가능하다.)

작년인 2013년 뉴욕에서 있었던 강연내용들을 몇개 소개해 본다.

전체 강연의 내용은 아래 링크를 통해 관람 가능하다.
QCon New York 2013 Videos and Slides

기조연설: 봉건적 보안 세계에서 살아남기
Bruce Schneier는 보안전문가로 12권의 책을 집필했다. 컴퓨팅 환경이 클라우드, SaaS화 되어감에 따라 각각의 서비스 프로바이더의 보안정책에 종속되어 버리는 현실을 봉건적 보안 세계라 표현하고 여기서 어떻게 효율적으로 보안을 구성할 수 있는지에 대해 이야기 한다.

기조연설 : 기술혁신이 뉴욕타임즈를 살릴 수 있는가?
무려 뉴욕타임즈의 CIO인 Marc Frons와 CTO인 Rajiv Pant가 연사로 나섰다. 뉴욕타임즈의 디지털 구독 정책에 대해 설명한다. Rajiv Pant는 NodeJs, Scala, cloud, 그리고 big data를 활용해 지속적 배포Continuous Delivery를 실현하는 노하우를 공유한다.

LinkedIn에게서 배우는 구축과 스케일링
LinkedIn의 수석 앤지니어인 Jay Kreps는 LinkedIn의 데이터 인프라스트럭처와 관련 영역의 기술리딩을 담당하고 있다. 그는 LinkedIn 아키텍처의 발전과정을 통해 단일 어플리케이션과 단일 데이터베이스를 분산 서비스와 분산 데이터스토어로 스케일링 하는 것에 대해 강의한다.

Facebook Messages : HBase상에서의 백업및 복제시스템
페이스북의 HBase기술팀 스토리지 엔지니어인 Nicolas Spiegelberg는 매달 500테라바이트의 새로운 데이터가 발생하는 페이스북 매시징을 HBase상에서 구현하고 스케일링해 나갔던 분투기를 소개한다.

트위터 분해하기 - Service-Oriented Architecture를 둘러싼 모험
Jeremy Cloud는 고도의 동시성Concurrency 에대한 접근방법과 코드의 복잡성을 관리하는데 사용되는 몇가지 함수형 디자인패턴을 소개하는 것으로 트위터에서의 SOA에 대해 설명한다.

2014년 4월 13일 일요일

왜 클라우드 컴퓨팅은 DevOps를 필요로 하는가?

아이러브스쿨의 실패

2000년, 1997년경 시작된 피씨방의 성공과 함께 보급된 인터넷은 스타크래프트와 레인보우식스에 빠져있던 사람들에게 새로운 재미거리를 제시한다. 사람과의 관계, 아이러브스쿨이었다.
하지만 1년만에 500만명의 회원을 모으며 사회적 이슈의 중심으로 떠올랐던 아이러브스쿨은 정말 신기루처럼 한순간에 사라졌다.

20억 채무에 신용불량, 이혼까지… “성공에 대비하지 못해 실패했다”

위의 기사에 나온 경영권을 둘러싼 잡음이 아이러브스쿨 실패의 모든것을 말해주진 않는다.
당시 서비스 자체가 빠르게 인기를 잃은 직접적인 원인은 서버의 확충. 즉, 서비스 스케일링에 실패했기 때문이다.
필자가 기억하는 아이러브스쿨의 마지막 모습은 사람들이 많이 접속하는 8시부터는 전혀 움직이질 않는 쓸 수 없는 서비스였다. 로그인해서 메뉴를 클릭해 동창모임에 찾아들어가는 것 만으로도 엄청난 인내심이 요구되었고, 그러한 상황은 수개월동안 지속되는 가운데 인내심이 바닥난 사람들은 뒤이어 등장한 프리첼과 다모임으로 빠르게 이동해 갔다.

2014년인 지금. 서비스 스케일링으로 실패했다는 기업은 찾아보기 어렵다. 클라우드 컴퓨팅의 등장으로 유연한 서버 인프라 환경이 정착되었기 때문이다.

DevOps와 클라우드 컴퓨팅

클라우드 컴퓨팅과 DevOps는 두가지 접점을 가진다. 한가지는 클라우드 컴퓨팅에서는 스케일 아웃Scale Out에 대응하기 위해 인프라 구성 작업이 매우 빈번하게 이루어지게 된다는 점이고 또 한가지는 이러한 구성작업이 단순한 설정작업Configuration에 그치는 것이 아니라 서버 어플리케이션의 릴리스에 따른 어플리케이션 버전관리, 데이터 마이그레이션, 그리고 이를 테스트하기 위한 버전별 자동화 테스트에 이르기까지 복잡한 일련의 작업들이 빠르고 정확하게 이루어져야 한다는 점 이다.

다시말해 클라우드 컴퓨팅에서의 DevOps는 서비스의 생명이라 할 수 있는 생산성과 유연성 그리고 안정성을 확보하기 위해 유용한 수단인 것이다.

DevOps는 요구분석에서 배포와 피드백에 이르는 일련의 작업들이
자동화 되고 끊임없이 반복되는 형태를 추구한다.
출전 : computing.co.uk

이와같은 DevOps의 필요성 때문에 AWS에서는 OpsWorks라는 툴을 제공하고 있으며, 다른 클라우드 사업자들도 비슷한 기능을 지닌 자동화 툴을 제공하고 있다.

AWS OpsWorks User Guide - Kindle용 무료서적
Azure의 Devops - MSDN블로그

구성관리와 DevOps

굳이 애자일 개발 이라는 단어를 꺼내지 않더라도 소스코드의 형상관리는 소프트웨어 개발에 있어서 필수 요소로 자리잡은지 오래다. 최근들어서는 소스코드뿐만이 아니라 문서, 설정, 데이터베이스에 이르기까지 다양한 영역에서 변경사항을 체계적으로 관리하려는 움직임이 두드러지게 나타나고 있다.

DevOps 구현을 위한 툴셋
출전 : drdobbs.com

아래의 링크는 각 영역별 구성관리 툴의 리스트이다.

이 외에도 최근에 데이터베이스 마이그레이션의 자동화 작업이 중요한 이슈로 떠오르고 있다. 데이터베이스의 마이그레이션 자동화 작업이란 간단히 말해 퍼시스턴스의 버전변경에 따른 DDL자동 생성은 물론 기존 데이터의 마이그레이션 패치 작업을 자동화 하는 것 이다.
현재 나와있는 데이터베이스 마이그레이션 툴에 대한 비교가 Flyway의 홈페이지에 잘 정리되어 있으므로 툴의 도입을 검토하고 있다면 좋은 참고가 될 것이다.

데이터베이스 마이그레이션 툴 기능 비교표(페이지 하단)

위의 툴들은 일반적으로 단독으로 움직이기 보다는 Jenkins와 같은 CI자동화 툴을 중심으로 유기적으로 연동되어 개발과 테스트, 배포가 하나의 연속적인 흐름으로 묶이게되는데, 이것이 바로 빠른 릴리스 구현을 목표로 삼는 DevOps가 구현된 모습이라 할 수 있겠다.

2014년 4월 9일 수요일

다른나라 프로그래머들 급여는 얼마나 될까?

소프트웨어 앤지니어라면 누구나 한번쯤 해외 취업, 특히 본고장 미국에서 일해보는 꿈을 가져 보았을 것이다. 얼마전까지 뉴욕에서 일하다 일본으로 돌아온 지인의 말에 의하면 확실히 미국에서 프로그래머로 일하는것은 수입면이나 근무 환경면에서 한국이나 일본보다는 몇발자국 앞서 있는 것이 사실인 듯 하다. 필자 또한 12년전에 일본으로 건너와 오늘에 이르기까지 프로그래머로서 일하고 있지만 여전히 미국에서 일하는 것에 대해 희망의 끈을 놓지 않고 있다. (하지만 영어 발음은 점점 일본화 되어가고 있다...)

오늘은 미국과 일본을 중심으로 다른나라의 프로그래머에 대한 수입을 살펴보고자 한다.

미국

유명한 프로그래밍 관련 웹진인 Dr.Dobbs에서는 매년 연봉과 관련하여 설문조사를 실시하고 있다. 아래 내용은 2013년 실시한 최신 설문자료로 삼천명의 프로그래머와 프로젝트 매니저가 설문에 참여하였다. 아래 표시된 금액은 기본급여base salary이다.

2013 Developer Salary Survey

우선 직함별 분류이다. 전반적으로 해마다 꾸준히 상승해 왔음을 알 수 있다.
Software developer와 engineer는 어떠한 기준으로 분류했는지 잘 모르겠다.

다음은 지역별 분류이다. 실리콘벨리가 속해있는 태평양 연안지역이 가장 높고 뉴욕이 속해있는 북동부가 그 다음 순이다.

회사 이익규모에 따른 급여수준이다. 대기업일수록 매니저와 일반사원 모두 높아지는것을 알 수있다.

나이에 따른 분류이다. 일본도 그러하지만 미국도 50세 이상의 개발자를 현장에서 보는것은 그리 드문일이 아니라 한다.

성별에 따른 차이이다. 특이한점은 평사원의 경우 약 10프로 이상 남성의 수익이 높은 반면, 매니저의 경우는 차이의 폭이 줄어드는것을 볼 수 있다.

급여 이외의 지원 항목이다. 미국의 경우 살인적인 의료비때문에 의료 보험 가입이 매우 중요한 요소이다.

'올해 보너스 지급을 기대하는가?' 라는 항목이다. 아무래도 요즘 IT산업의 경우 전반적으로 호황을 누리고 있는만큼 보너스에 대한 기대도 크다고 볼 수 있겠다.

보너스에 대한 이유. 개인의 성과, 팀 성과, 회사의 이익배분 순으로 기대하는 순서가 나열된다.

마지막으로 일하는데 있어서 무엇을 가장 중요하게 생각하는가 라는 설문이다. 급여부분이야 어찌보면 당연하다 할 수 있겠지만 유연한 작업 일정이 두번째로 중요하게 생각하는 항목 이라는 것은 눈여겨 볼 만 하다.
아마도 삶의 질을 중시하는 분위기 속에서 일과 생활의 밸런스를 중요하게 생각한 결과가 아닐까 싶은데, 해마다 비율이 점차 높아지고 있는 것으로 보아 하나의 추세라는 것을 알 수 있다.

일본

이제 이웃나라 일본을 살펴보자. 아래 자료는 후생성에서 발표한 2012년도 임금 통계 자료이다.

초・중급개발자

사원수	10～99명	100～999명	1000명이상
평균연령	31.8	31	37.9
근속년수	5.8	6.2	12.1
월평균근무시간	159	160	176
월평균잔업시간	14	24	27
월급여	300,800	302,600	414,000
연간 상여급/기타	294,300	478,500	1,242,500
연수입	3,903,900	4,109,700	6,210,500

금융위기 이후 17배까지 치솟았던 엔 환율이지만 지금은 10배로 계산해도 무리가 없을것이다. 앞서 살펴본 미국과 비교하자면 사원수에 따라 급여가 상당히 차이가 많이 난다는 점인데 우리나라와 마찬가지로 일본의 소프트웨어 개발 산업도 하도급 구조를 가지고 있기 때문이 아닐까 싶다.

상급개발자

사원수	10～99명	100～999명	1000명이상
평균연령	36.3	36.6	36.2
근속연수	9	11.1	11.3 blog-post
월평균근무시간	163	158	150
월평균잔업시간	18	22	23
월급여	341,700	371,200	389,900
연간 상여급/기타	499,000	877,200	1,343,400
연수입	4,599,400	5,331,600	6,022,200

상급개발자 역시 기업규모가 클수록 많은 급여를 받는것으로 나타나고 있는데, 기업규모 비례해 연수입의 차이가 나는 요인중 한가지는 하청업체의 경우 잔업수당 지급기준이 월200시간이상 근무시에 발생하도록 하는 계약이 보편화 되어 있기 때문이기도 하다.
초・중급개발자의 급여와 비교해서 한가지 특이한 점이 있는데, 대기업에서의 연수입이 오히려 줄어들었다는 점 이다. 한가지 생각해 볼 수 있는것은 과장급 이상의 개발자의 경우 야근 수당이 사라지고 프로젝트 이익에 대한 보너스를 받는 형태가 많이 있다. 실제로 주변의 개발자들중에 과장으로 승진하고 오히려 실수령액이 줄어들었다는 사람들도 많이 보았다. 여기에, 2012년의 경우 엔고로 인해 일본 대기업들이 대부분 적자를 내던 시기로 그러한 상황적 배경도 어느정도 영향이 있었을듯 싶다.

자료만 보자면 2014년 현 시점의 평균급여면에 있어서 한국이 일본과 비슷하거나 물가면을 생각해 본다면 실제 소득수준은 다소 앞설 수도 있겠다는 생각을 해 본다. 다만, 필자의 경험상으로는 높은 전문지식과 업무에 대한 이해를 지닌 컨설턴트/아키텍트급 엔지니어는 억대연봉을 받는 개발자도 어렵지 않게 찾아 볼 수 있는것 또한 사실이다.

프로그래머는 매일매일 새로운 난관에 부딧히며 도전해 나가는 스트레스가 많은 직업이다. 프로그래머가 만족하면서 일하는데에는 급여도 중요하겠지만 일 외적인 개인생활에 대한 보장도 중요한 요소이다. 대한민국이 진정한 IT강국이 되기 위해서는 개발자들에 대한 금전적 대우 뿐만 아니라 근무환경 또한 선진화 시켜 나갈 수 있어야 하지 않을까 한다.

소스코드 기초 - 파일 네이밍, 파일 인코딩, 특수문자, Non-Ascii 문자
소스 포멧 - 괄호, 인덴트, 서술식, 줄당 문자수, 스페이스, 줄바꿈, 특정구문(Enum, 변수선언, 배열, 스위치문, 어노테이션, 커맨트, 변환자, 숫자)
네이밍 - 패키지, 클래스, 매소드, 상수, 비상수, 파라메터, 지역변수, 타입변수, 대소문자사용
프로그래밍 방법 - Override어노테이션, 예외처리, 정적 맴버변수, 종료자
Javadoc - 포멧, 요약단편, Javadoc이 필요한곳

몇가지 특이한 점을 꼽아보자면 다음과 같다.

와일드 카드 임포트 사용 금지 - 이클립스 보급 이후로는 사실상 와일드카드 임포트는 찾아보기 어렵게 되었다.
2스페이스 들여쓰기- 들여쓰기에 있어서 2스페이스냐 4스페이스냐는 프로그래밍 역사상 가장 오래된 논란거리중 하나인데, 어쨌든 구글은 2스페이스 인덴트를 택했다. 모니터가 크면 별 상관이 없지만 노트북으로 작업을 하는경우, 들여쓰기에 의해 코드가 한줄에 안보이게 된다면 은근히 짜증이 난다.
줄당 문자수 - 80 또는 100 문자. 80문자까지 제약하는것은 역시 노트북으로 작업하는 이가 많은 구글의 문화적 특성인 듯 하다.
C스타일 배열 선언 사용 금지 - String[] args ○ , String args[] X
스위치문 사용시엔 반드시 default구를 정의할것
지시자의 표기는 다음과 같은 자바언어 사양상의 등장 순서를 지킨다

public protected private abstract static final transient volatile synchronized native strictfp

구글에서는 다른 언어들에 대해서도 코딩 스타일 표준을 가지고 있다.

태그