[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2016년 10월 31일 월요일

[Book] AngularJS 기초편 : MVC 패턴을 구현하는 자바스크립트 프레임워크..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

AngularJS 기초편 표지AngularJS 기초편 : MVC 패턴을 구현하는 자바스크립트 프레임워크 - 10점
브래드 그린, 샤이엄 세샤드리 지음
김지원 옮김
한빛미디어

구글이 만든 자바스크립트 프레임워크인 Angular.js에 대한 책이고 국내에서 Angular.js를 주제로 한 책은 현재로썬 유일한 것 같고 이 책은 한빛미디어의 리얼타임이라는 이름으로 출간하는 이북으로 나온 책이다. 최근엔 Angular.js는 왜 좋은가?라는 글에서 Angular.js를 소개하기도 했는데 최근에 Angular.js에 관심을 많이 가지고 있기 때문에 마침 책이 나와서 구입해서 읽어봤다.

개인적으로 Angular.js로 웹어플리케이션을 만들어보고 있기 때문에 내부의 자세한 동작방식은 다 모를지라도 기본적인 컨트롤러 작성해서 스코프 연결하고 서비스나 디렉티브 작성해서 애플리케이션을 어느 정도는 만들 수 있게 되었다. 할때마다 새로운 장벽에 계속 부딪히고 있기는 하지만... 튜토리얼 정도만 따라해보고 레퍼런스 문서 참고해서 삽질하면서 어느 정도 파악하기는 했지만 기초적인 내용에서 빠뜨린 부분도 있을 것 같아서 이 책을 봤다.

제목에서 알 수 있듯이 Angular.js에 대한 기초를 다루고 있다. Angular.js가 취하고 있는 기본적인 접근을 설명하고 프로젝트를 구성해서 개발하는 방법을 설명하고 있다. 그리고 마지막에서는 간단한 예제 프로그램을 작성해 보면서 Angular.js를 어떻게 사용하는지 살펴보고 있다.(예제는 번역서에서 현재 최신 버전인 v1.0.7로 업데이트 되어 있다.) 번역은 읽기에 무리는 없는데 일부 번역에서 좀 불편한 부분이 있었다. 대표적으로 Dependency Injection은 의존성 주입이 일반적으로 사용되는 단어라고 생각되는데 여기서는 종속물 주입이라고 되어 있는데 나는 이 종속물이라는 말의 의미가 책을 읽는 내내 잘 와닿지 않았다.

개인적으로 Angular.js의 러닝 커브가 꽤 상당하고 스코프나 디렉티브, 서비스등을 포함해서 Angular.js 답게 작성하려면 이해해야할 내용들이 꽤 되기 때문에 설명하기가 꽤 어렵다고는 생각하고 있다. 이 책은 150 페이지 분량인데 이미 좀 만져봤다는 점을 감안하더라도 아주 기초적인 내용정도만 다루고 있다. 기초적인 내용 위주로 설명하고 있기는 한데 많은 내용을 적은 분량으로 다루고 넘어가다 보니 부분 기능에 따라 이걸 읽고 이해할 수 있을까 하는 의문이 드는 경우가 좀 있다.(다 설명하려고 해도 만만치 않겠지만...) 읽어본 느낌으로는 이미 Angular.js로 어플리케이션 개발을 하고 있다면 아주 가벼운 마음으로 읽거나 굳이 안읽어도 될 것 같고 Angular.js를 처음 공부해 보고자 하는 사람한테는 시작점으로 괜찮아 보인다.(한글 자료는 워낙 적다보니 그런 면에서는 큰 도움이 될듯..)

추가적으로 이 책은 AngularJS의 번역서이다. 읽고 나서 알게 된건데 책 제목이 기초편이라서 고급을 다룬 책이 한권 더 있나 생각했었는데 그건 아니고 원서를 반으로 나누어서 기초편을 먼저 내고 다음 책을 또 낼려는 것으로 보인다. 원서의 목차와 비교해 보면 이 책은 원서의 4장까지의 분량이다. $http, 디렉티브등을 다루는 5~8장까지가 다음 책으로 나올 것이라고 생각한다.(독자 입장에선 약간 속은 느낌같기도...)

[EP] 개발자를 위한 ‘共感(공감)’ 세미나 12회 발표자료 : 혼자서 프로젝트 수행하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

지난 7일 교보타워에서 공감 세미나가 있었다. 오랜만에 참석하는 공감세미나이긴 하는데 이번에는 KSUG쪽 세션을 맡아서 발표자로 참석을 하게 되었다. 처음에는 첫 세션을 맡았지만 낮에 갔다와야 할 곳이 생겨서 마지막 세션으로 바꾸었지만...

이번 세션은 그냥 사석에서 얘기를 나누다가 프로젝트 할때 아이콘 폰트는 뭐 쓰고 프레임웍은 뭐 쓰고 이런 얘기를 나누다가 fupfin님이 그걸 발표해도 괜찮겠다고 해서 시작되었다.(그때는 농담인줄 알았지만...) 잉여력을 발휘해서 학습 겸 개인 프로젝트를 많이 하는 편인데 그럴때 사용할만한 도구들을 소개하는 발표였다.


혼자서 프로젝트 수행하기 from Outsider

나는 네이밍을 잘 못하는 편인데 특히 이런 발표나 글 같은 경우 내용은 채우겠는데 제목짓는 건 참 어렵다. 나름 고민해서 지은 제목이긴 하지만 개인 프로젝트를 하면서 도움이 될만한 도구들의 소개가 위주인데 제목에서는 잘 안타난것 같아서 아쉽다. 처음에 발표하기로 하고 이런 저런 유용한 도구를 소개하는 것도 괜찮겠다고 생각은 했지만 막상 발표준비를 하다보니 발표시간만큼의 분량이 잘 생각나지 않았다. 상황별로 누가 물어보면 뭐 쓰면 좋겠다 라고 대답해 줄 수 있겠지만 막상 처음부터 생각하니까 "내가 무슨 도구를 쓰더라", "이 도구는 다들 알고 있는 것 아닌가?"하는 생각이 많았다. 그래서 처음부터 기획하고 디자인하고 서비스하는 과정에서 내가 사용하거나 참고할 만한 도구를 위주로 자료를 만들었다. 이런 도구를 설명하는 발표는 해당 도구나 서비스를 아느냐 모르냐의 차이일뿐 어떤 사전지식이나 내공(?)이 필요한건 아니라서 꽤 유용하다고 생각하지만 자칫하면 다들 하는 너무 쉬운 것만 말할 수도 있어서 조심스럽기도 하다. 다행히 끝나고 몰랐던게 많았다고 해주신 분들이 계셔서 다행이었다.

추가적으로 기존에는 발표자료를 만들때 그림을 많이 넣는 편이다. 이전에는 거의 전 페이지에 이미지를 넣어서 만들었는데(이미지 찾는데 시간이 엄청 걸린다.) 최근에는 발표내용을 전달하는데 얼마나 유효한가에 대해서 좀 의문이 들었다. 발표자료 만드는 스킬을 좀 더 올리고 싶은데 적절한 상황에서 이미지를 활용하는 것은 전달에 도움이 되지만 그냥 습관적으로 이미지를 넣어서 만드는 경우도 많은 것 같아서 이번에는 이미지를 좀 자제하고(스샷이 많았지만) 텍스트를 넣으려고 했다.(발표자료 만드는건 역시 어렵;;;)

2016년 10월 28일 금요일

[NEWS] 트위터가 심상치 않다..

일에 들어가기 앞서서 빠르게 뉴스 하나를 올리고 일을 시작해야겠다.. 다름 아닌 트위터 관련 뉴스이다..

크게 두가지인데 하나는 인력 감축이며, 다른 하나는 서비스 종료에 대한 것이다.. 머 일반적인 회사의 패턴이라면 패턴이라 할 수도 있고, 세계적인 IT 추세가 그럴 수도 있다고 할 수도 있지만 우선 기사적인 부분에서 읽다보면 각자의 생각이 틀려질 수 있기에 간단하게 정리를 해서 올려본다..

9% 대의 인원감축 계획
트위터는 27일 오전 3분기 실적 결과 보고를 겸한 서한에서 "글로벌 인력의 9%(약 350명)를 감축할 계획"이라고 밝혔다.이달 초 매각 절차를 밟았지만, 디즈니와 구글 등이 인수 가격을 제시하지 않았고, 가장 유력한 인수 협상자로 알려졌던 세일즈포스마저 공식적으로 인수에 관심이 없다는 뜻을 밝히면서 트위터의 매각은 무산됐다. 이에 따라 트위터가 독자생존을 위해 인력 감축 등의 조처를 할 것이라는 전망이 제기됐었다.

IT 전문매체 테크크런치는 "트위터가 가까운 미래에 매출을 향상시킬 능력이 있는지에 대해서는 여전히 의문부호"라면서 "페이스북의 매출 신장세나 스냅챗같이 최근에 부상한 플랫폼들이 광고주들을 끌어당기고 있는 것과는 대조적으로 트위터는 정체 또는 하락 국면에서 벗어나지 못하고 있다"고 분석했다. 이 매체는 "독자생존을 위해서는 어떻게 트위터의 과거의 영광을 재점화할 수 있는 전략이 나올 것이냐가 관건"이라고 말했다.

바인서비스 종료
트위터가 동영상 서비스 '바인(vine)'을 종료한다. 27일 정보기술(IT) 전문매체 폰아레나는 트위터가 몇 달 안으로 바인 서비스를 종료한다고 밝혔다. 바인은 지난 2012년 트위터가 인수한 동영상 서비스다.

트위터는 공식 성명을 통해 "당장 바인 애플리케이션(앱)이나 웹사이트에는 변화가 없을 것"이라며 "바인 서비스가 종료되기 전까지 이미 올려둔 콘텐츠를 내려 받을 수 있을 것"이라고 말했다. 매각실패, 구조조정, 등 1세대 소셜네트워크서비스(SNS) 트위터의 악재가 이어지고 있는 셈이다. 올해 들어 트위터의 주가는 23% 떨어졌다.

2016년 10월 20일 목요일

[Hobby] 나의 취미 FIFA Online 3..

약 2개여월 만에 해당 카테고리에 글을 올려본다.. 다른 취미도 물론 항상 잘 병행하고 있지만.. ㅋㅋㅋ..

해당 기간 동안 피온에서 가장 큰 변화라면 다른 부분들도 있지만 개인적으로는 유럽 레전드가 출시를 했다는 것이다.. 기본적인 혜택이나 케미는 월드 레전드와 같다고 보면 되는데 그 중에서 난 베론을 영입 했다.. 돈을 열심히 모으다가 다른 선수를 영입할까 생각도 물론 했지만 기왕이면 내 기준인 피지컬 180 cm 이상이면서 금액도 어느정도 맞는 선수 중에 기왕 쓰는거 새로 나온 선수를 써보자 하는 생각에 베론을 영입했다..


스테미너가 안좋다 어떻다 이런 저런 말이 많긴 하지만 내 기준에서는 상당히 좋다고 생각한다.. 키가 크니 헤딩에서도 상당히 좋았고, 패스도 그만하면 준수하고, 공격쪽에 배정이 되면 골도 잘 넣었기 때문이다..

머 우짜든둥 선수가 이제는 저렇게 구성이 되었고 선수 자체가 과거와 많이 바뀌진 않았지만 그동안 강화도 하고 해서 즐라탄, 시우바 처럼 강화된 선수도 보인다..

지금도 돈을 열심히 모으고 있는데 이번 목표는 수비를 보강하고 싶어서 드사이를 생각하고 있다.. 돈만 많으면야 더 좋은 선수 소위 말하는 1대장을 영입하고 싶지만 그건 어디까지나 꿈이고.. 그렇다고 해서 현질을 하고 싶지도 않고, 다른 사람처럼 시간을 엄청나게 투자해서 사재기, 강장 장사 등등을 할 생각도 없다..

그냥 게임이 서비스 종료되는 시점까지 최대한 열심히 할 수 있는데까지 해서 선수도 바꾸고 재미나게 해보는거지.. ㅎㅎㅎ 물론 그전에 돌연 접을 수도 있고.. ㅋ

아래는 이제는 어느정도 기준이 되고 내 손에 맞어가는.. 이제서야 맞어간다는게 참 웃기다.. ㅋㅋ 그동안 얼마나 많은 실패를 했던가.. ㅎㅎ.. 포메이션이다.. 난 5-1-4 에 SW [스위퍼] 를 둔 포메이션을 사용한다.. 전술은 전형적인 선 수비 후 역습 또는 크로스 전술이다.. 손이 안되니 머..



오늘은 이정도로 하고 다음 포스팅 할 시점이 다시 된다면 그 때는 좀 더 많은 변화가 생겼으면 한다 그리고 집에서 포스팅을 해서 포메이션, 전술 등등을 정식으로 올려보고자 한다.. ㅎㅎㅎ

[NEWS] 오라클과 아마존이 클라우드 대결을..??..

어제에 이어서 오늘도 눈에 들어오는 기사가 보이는구나.. 오라클과 아마존이 클라우드 서비스 대결을 벌인다고 한다.. 그것도 한국 시장에서 말이다.. 왜 한국에서 그런 대결을 하는 것일까 하는 생각에 기사를 보게 되었다..

클라우드를 아주 잘 아는 것은 아니지만 보안적인 문제 때문에 아주 강추하기에는 좀 애매하다고 생각을 했다.. 하지만, 아무래도 세계에서 2등이라면 서러워할 두 기업이 국내시장 점유율과 보급에서 세계시장의 평균치와 비교 했을 때 수치가 낮다보니 공격적으로 마케팅을 하는듯 하다.. 기회가 되면 나도 두 기업의 서비스를 사용해볼 수 있기를 바라며 아래는 기사 일 부분을 갖고 왔다..

출처 : 머니투데이 김지민 기자

오라클은 최근 한국 시장에 SaaS(서비스형소프트웨어) 클라우드 서비스를 잇따라 출시했다. AWS가 해오고 있는 IaaS(인프라형서비스)와 달리 오라클의 강점인 기업용 소프트웨어(SW)로 클라우드 시장을 공략하겠다는 계산이다.

오라클은 ‘편리하게 클라우드로 옮겨 갈 수 있다’는 점을 강조하고 있다. 고객들이 자사 데이터센터에서 클라우드를 활용할 수 있도록 한 것. ‘클라우드 머신’이 대표적이다. 정보 유출에 민감한 기업들을 위한 이 서비스는 보유한 데이터를 다른 공간으로 옮기지 않고도 클라우드 서비스를 활용할 수 있다는 점이 핵심이다. 고객이 원할 경우 언제든 오라클 클라우드 인프라를 이용할 수도 있다. 클라우드 이전을 고민하는 기업들에게 보다 간편한 방식을 제시하면서 시장을 점유해 나가겠다는 것이 오라클의 전략이다.

기업들의 클라우드 도입 물결이 거세지면서 아마존과 오라클의 주도권 경쟁이 갈수록 격화될 것으로 예상된다. IDC에 따르면 한국의 클라우드 도입률은 지난해 대비 1.7배 증가한 63%로 세계 평균인 68%를 밑도는 것으로 조사됐다. 이는 그만큼 클라우드 시장이 앞으로 더 성장할 수 있을 것으로도 해석된다. 하이브리드 클라우드 도입률도 한국이 55%로 전 세계 평균 도입률인 47%보다 높았다.

[UFC] UFC 마감뉴스..

출처 : SPOTV NEWS

2016년 10월 19일 수요일

[NEWS] 자바스크립트 생태계 통합될까..

출처 : 지디넷코리아 임민철 기자

자바스크립트 관련된 뉴스가 눈에 띄었다.. 읽어보고 생각보다 괜찮은 내용이고, IT 일반적인 기술 내용이 기사 1면에 나왔다는 것이 신기하기도 해서 겸사 겸사 글을 갖고 왔다.. 다만, 내가 생각해서 쓴 글이거나 그런 부분이 아니기에 전체적으로 게시하지 않고 편집해서 게시한다.. 이하는 해당 내용이다.. 근데 자바스크립트라고 하니 왠지 햄이 떠오르는군.. ㅋㅋㅋㅋ..

■파편화는 필연?
짐작컨대 파편화는 2가지 현상을 뭉뚱그려 지칭하는 것 같습니다. 하나는 같은 이름을 쓰는 기술에 관련된 코드가 개발 및 구동 환경 측면에서 통일성이 없거나 약한 것입니다. 다른 하나는 기술을 다루는 개발자 커뮤니티의 경험과 지식이 모이고 쌓이기보단 산산이 흩어져서 참고하기 어려운 것이고요. 전자는 업계에 공인된 사실이고, 후자는 흔히 접할 수 있는 실무자의 고충입니다. 파편화를 논하는 게 이상해 보일지도 모르겠습니다. 자바스크립트라는 언어 자체는 일련의 국제 표준(ECMAscript)에 기반하니까요. 하지만 어떤 프로그래밍 언어가 잘 정리된 표준에 기반해 만들어졌다는 사실과, 그 언어를 사용해 프로그래밍을 하는 환경은 전혀 별개 사안입니다.

일단 사용자들이 쓰는 각 브라우저 개발사가 저마다의 자바스크립트 엔진을 구현하고 있죠. 브라우저 종류와 버전에 따라 같은 코드가 다른 결과를 내는 게 현실이에요. 또 개발언어의 형태를 변형하거나 기능을 확장한 (슈퍼셋) 언어, 또는 기존 버전을 보완하기 위한 수많은 라이브러리가 있고요. 활용 범위에 비해 그에 내장된 함수같은 게 부족하다는 지적에 시달려 온만큼 그걸 보완할 수단이 필요했거든요.

한 마디로, 서비스 운영 환경이나 개발 의도에 따라 자바스크립트 코드가 돌아가는 사용자 환경도, 개발 도구와 환경도 제각각이라는 겁니다. 그래서 자바스크립트라는 공통분모를 제외하면 실용적인 단일 접점을 찾기 어려울만큼 거대하고 파편화된 커뮤니티가 형성됐고요. 자바스크립트 전체 생태계를 관통하는 뚜렷한 구심점 없이 다양한 현장의 개별적인 문제 해결 수단이 자생한 결과라 볼 수 있겠네요.

■리눅스재단, JS재단 출범 "자바스크립트 오픈소스 키우겠다"
리눅스재단이 지난 17일부터 영국 런던에서 열리고 있는 유럽 오픈소스컨퍼런스(OSCON Europe)에서, 자바스크립트 기반 웹 애플리케이션과 서버 측 애플리케이션 개발 기술에 관련된 오픈소스 프로젝트를 육성하겠다는 구상을 제시했거든요.

공식 발표에 따르면 리눅스재단은 컨퍼런스 현장에서 'JS재단(JS Foundation)'이라는 이름의 비영리조직을 통해 여러 자바스크립트 관련 오픈소스 프로젝트 후원에 협력하겠다고 선언했습니다. 주요 웹 기술 업계에서 널리 활용되고 있거나 전도유망하다고 판단한 프로젝트를, 리눅스재단의 우산 아래 적극 밀어주겠다고 나선 모양새죠.

JS재단 발족과 함께 공개된 첫 후원 대상은 23가지입니다. 저마다 자바스크립트 개발 영역에서 이미 인지도를 얻은 오픈소스 프로젝트입니다.

■JS재단, 파편화 해결 실마리?
영국 IT미디어 더레지스터는 이 소식을 다음과 같이 전했습니다. "자바스크립트 프로젝트들의 위용을 키워줄 프로젝트가 리눅스재단에 의해 발족했다. JS재단이 자바스크립트 애플리케이션과 서버측 프로젝트를 육성한다. 광범위한 자바스크립트 기술 채택과 개발을 주도하고 협력을 촉진하기 위한 중심에 두려는 의도다. JS재단은 개발자와 툴 제작자가 빠른 변화 추세를 받아들이도록 도울 것이다."

미국 지디넷은 "(JS재단은) 고품질 표준과 장기적인 지속가능성을 장려할 모범사례와 정책을 촉진함으로써 자바스크립트 애플리케이션 및 서버측 프로젝트를 돕기로 했다. …(중략)… 자바스크립트 개발자는 발전하나 뒤죽박죽인 오픈소스 기술 포트폴리오에 의존해 핵심 애플리케이션을 만들고, 테스트하고, 배포한다. 재단 목표는 핵심 자바스크립트 솔루션과 관련 기술의 광범위한 채택과 개발 진척을 주도하는 것이다."

공식 발표 내용과 외신들의 이런 관측으로 짐작해 보면, JS재단을 통해 선별된 오픈소스 프로젝트는 상대적으로 그렇지 않은 프로젝트나 기술에 비해 커뮤니티의 관심과 지원을 이끌어내는 데 유리할 것 같습니다. 다종다양한 오픈소스 프로젝트로 어수선한 자바스크립트 생태계가 공신력을 갖춘 후원자의 선별을 통해 정리되는 결과를 맞을 지도 모릅니다.

■다양성 위협 여지에 주목
경쟁관계에 있는 자바스크립트 기반 오픈소스 프로젝트 중 하나가 JS재단의 후원 대상이 될 경우 빠르게 사용자층을 늘리고 참여 개발자 생태계를 확대할 수 있습니다. 시장관점에선 독점 사업자간 경쟁으로 묻히는 기술에 비하면, 소외된 오픈소스 기술을 쓰더라도 사용자 부담이 적겠죠. 사용자 입장에선 장기적으로 기술 난립의 혼란을 줄일 수도 있고요. 하지만 다른 성숙된 오픈소스가 소외될 가능성도 있습니다.

JS재단은 여느 오픈소스 후원 재단처럼 비영리조직을 표방했습니다. 재정을 충당하는 회원사뿐아니라 다른 웹기술 표준화 조직과도 협력한답니다. 글로벌 웹표준화기구 '월드와이드웹컨소시엄(W3C)'과, 브라우저 개발업체간의 웹기술표준화 협력 커뮤니티인 '웹 하이퍼텍스트 애플리케이션 기술 워킹그룹(WHATWG)'과, 서버측 자바스크립트 프레임워크 기술 커뮤니티의 주축인 '노드JS재단' 등과도 일한다 하고요.

앞으로 W3C와 WHATWG와 노드JS재단을 비롯한 수많은 웹기술 관련 단체와 소속 회원사와 거기서 일하는 개발자와 외부 개발자 커뮤니티를 아울러 많은 눈들이 JS재단을 지켜보겠죠. 삼성전자나 IBM을 비롯한 회원사들에겐 저마다 JS재단을 지렛대 삼아 사업적 이익에 맞물리는 방향으로 자바스크립트 생태계를 이끌려는 바람이 있을텐데, 그 바람이 생태계 전체에 도움이 된다는 걸 입증할 의무도 있으니까요.

2016년 10월 18일 화요일

[Book] 린 스타트업..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

린 스타트업 - 8점
에릭 리스 지음, 이창수.송우일 옮김/인사이트

이 책은 린 스타트업 운동을 만든 에릭 리스(Eric Ries)가 린스타트업에 대해서 설명한 책이다. 린 스타트업은 도요타의 린 방법론에 착안(아마도?)해서 스타트업에 적용한 방법론이도 에릭 리스가 3D 아바타 채팅 서비스를 만드는 IMVU라는 스타트업에서 일하면서 배우고 알아낸 것을 시작으로 린스타트업을 본격적으로 연구하게 되고 이 책은 그 결과인 린 스타트업에 대해서 정리한 책이다.

요즘의 추세대로 린 스타트업도 애자일과 비슷한 면이 있다. 애자일이 개발부분에 포커싱이 되어 있다면 린 스타트업은 이러한 부분이 스타트업이라는 사업 분야까지 확장되어 있기 때문에 평소에 이러한 부분이나 애자일에 관심이 있다면 완전히 새로운 개념을 얘기해 주거나 하진 않겠지만 에릭 리스의 경험과 연구를 하면서 다른 회사들로부터 얻어낸 사례등을 통해서 꽤 정리가 잘 되어 있고 사업적으로 생각할 수 있는 많은 관점을 제공해 주고 있다고 생각한다. 여러 모로 인상깊은 부분이 많이 있었다.

에릭 리스는 린 스타트업을 지속적인 혁신을 만드는 새로운 방법으로 정의하고 있고 여기서 말하는 스타트업을 우리가 일반적으로 얘기하는 소규모로 새로 시작해서 도전한 회사들만을 얘기하는 것이 아니라 극심한 불확실성 속에서 새로운 제품과 서비스를 만드는 조직을 모두 스타트업으로 정의하고 있기 때문에 대기업이라고 하더라도 비슷한 도전을 하고 있는 조직은 린 스타트업을 적용할 수 있다고 얘기하고 있다. 그래서 린 스타트업은 창업가는 어디에다 존재할 수 있고, 스타트업은 제품만으로 성공할 수 없으므로 창업가의 정신은 관리이고 유효한 학습을 계속 할 수 있어야 하며 만들고 측정하고 배우는 과정을 최대할 빨리 반복하면서 혁신 회계에 집중해야 한다.

그리고 에릭 리스는 기존의 스타트업들이 실패하는 이유를 시장조사나 정교한 전력/기획등에 현혹되서 이를 성공의 지표로 여겼고 기존 경영방식의 실패를 보면서 "일단 해보자"라는 방식에 길들여졌기 때문이라고 보고 있다. 스타트업을 만든다는 것은 조직을 만드는 것인데 기존의 관리 기법이 창의성을 죽여버릴까봐 걱정하는 경우가 많은데 오히려 "일단 해보자"라는 방식이 조직을 혼란스럽게 만드는 경우가 많다는 것이다.

린 스타트업은 책 내내 "만들기-측정-학습"의 과정을 강조하고 있는데 여기서 중요한 것은 유효한 학습이어야 한다는 것이다. 그래서 어떻게 측정하고 상황에 따라 어떤 측정 경과를 보고 어떤 부분은 조심해야 하는지를 설명하고 실패해도 학습했으니 괜찮다는 변명을 주의하라고 하고 있다. 즉, 결과가 나온 후에 끼워 맞추거나 실패를 감추는 것이 아니라 극심한 불확실성 속에서 성과를 측정하기 위한 까다로운 방법론이라는 것이다. 그래서 어떤 부분이 가치를 창출하는 부분이고 어떤 부분이 낭비인지를 찾는 것이 중요하고 "얼마나 많이 만들었느냐"가 아니라 "얼마나 제대로 된 학습을 했느냐"를 가지고 생산성을 측정해야 한다는 것이다. 회사를 바쁘게 움직이게 하는 것이 목적이 아니라 정말 필요한 일에만 하게 하는 것에 집중하게 해야 한다는 말은 특히 많이 와닿았다. 그러면서 예를 든 것이 어떤 기능을 몇개월에 걸쳐서 개발해서 공개했더니 소비자들이 원하지 않는 기능이었다는 것이었다.(실제로 바쁘고 열심히 했지만 그것 자체가 의미 없었다는 얘기다.) 그래서 린 스타트업에서는 "만들기-측정-학습"의 과정을 빠르게 반복하는 것을 강조하고 있고 MVP(minimal viable product)가 그 핵심 중 하나이다.

그리고 스타트업은 "이 제품을 만들수 있을까?"하는 것이 주요 질문이 되기 보다는 "이 제품이 과연 만들 가치가 있는가?", " 이 제품과 서비스를 기반으로 우리가 지속가능한 사업을 만들 수 있는가?"가 되어야 한다.(여기에는 무척 공감한다. 이 질문이 선행되어야 어떻게 만들지.. 혹은 그 방법이 안되었을 때 다른 방법으로 해결할 수 있을지를 고민할 수 있다.) 그래서 가설을 실제 과학적으로 테스트하면서 실험을 하고 이 실험으 목표를 비전을 바탕으로 지속가능한 사업을 구축하는 방법을 찾는데 있다. 책에서 모든 스타트업이 정기적으로 "방향을 전환할 지 아니면 고수할지"에 대한 회의를 진행하는 것을 권장하고 있다. 에릭 리스의 경험에 따르면 수주이내면 너무 잦고 수개월 이상은 너무 뜸하다고 하는데 이런 회의를 정기적으로 하는 것은 참 좋은것 같다.

린 스타트업의 목적은 제품을 더 효율적으로 만드는 것이라기 보다는 "지속 가능한 살업을 만드는 방법"을 최대한 빨리 배우는 것이다. 대기업이라면 내부 혁신팀이 자리를 잡아가면서 실험을 지속해 나갈수 있는 플랫폼을 만들어야 하는데 이런 것들은 모두 최고 경영진의 책임이다. 린 스타트업에 대한 실천적인 방법도 여러가지로 제시하고 있는데 인상적인 것은 큰 일괄 작업 크기를 줄이라는 것이다. 여기서 큰 일괄작업 크기라는 것은 제품의 완성형이 나오기까지 돌아가는 프로세스를 얘기하고 이 부분이 클수록 중간에 잘못되었음을 깨달았을 때 작업 크기가 너무 커서 오히려 비효율적이 된다는 것이다. 이 부분은 오히려 시스템의 문제인데 이를 줄이기 위해서 더욱 더 큰 작업 크기를 요구하는 악순환이 된다는 것이다. 그리고 다섯번 '왜'라고 묻는 과정을 권장하고 있다. 이는 도요타에서 사용한 방법인데 어떤 문제가 발생했을 때 그 문제가 왜 발생한 것인지 다섯번 물어봄으로써 그 문제를 막기 위한 근본적인 해결책을 찾는 과정인데 참 괜찮아 보인다.
책에서 많은 이론적인 설명과 함께 실천적인 얘기도 하고 있어서 유용하지만 당연히 다루는 문제 자체가 쉽지 않으므로 이 책대로 한다고 성공한다거나 그러진 않을 것이다. 각 회사나 조직마다 자신만에 맞는 방법을 찾아가는 과정이 필요하겠지만 이 책이 얘기하는 부분은 여러가지로 곰곰히 생각해 볼만 하다고 생각하고 조직을 이끄는 사람이라면 읽어보라고 권하고 싶을 정도다. 마지막으로 이 책에서 에릭 리스는 "린 스타트업은 틀이지 따라야 할 청사진이 아니다"라고 얘기하고 있다.

몇가지 책에서 인상적이었던 부분을 얘기하자면...
몇년 전 큰 미디어 회사에 제품을 판매하는 어떤 스타트업이 자기네 엔지니어들이 별로 열심히 일하지 않는 것 같다고 자문을 요청한 적이 있다. 하지만 문제는 엔지니어링 팀에 있지 않았다. 문제는 의사 결정을 하는 회사의 프로세스에 있었다. 고객은 있었지만 고객을 잘 이해하지 못하고 있었다.
실수가 생기면 그 실수를 저지르기 쉽게 만든 우리가 부끄러운 일이다.
1. 첫실수에는 전부 관대하라.
2. 가능한한 실수를 두번 하게 하지 말라.
"전혀 해서는 안 될 일을 매우 효율적으로 하는 것만큼 무용한 짓은 확실히 없다." - 피터 드러커

My Comment..
흠.. 이런 것도 있었구나.. 햄이 올려둔 지식들을 보다보면, 신기한게 많다.. 이 책도 그런 부분중에 하나다.. 참 많은 것을 알게 해주는 햄이다.. 대단하심.. ㅎㅎㅎ..

[DEV] 모바일 사파리에서 스크롤 구현과 관련된 문제..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

HTML5가 나오고 나서 웹에도 엄청난 변화가 일어났지만 초반에 열심히 쫓아가다가 너무 많이 쏟아져 나와서 한참동안은 너무 깊게 파지는 않고 있었고 모바일은 딱히 만질일도 없었기 때문에 기본적인 수준 이상으로는 크게 관심을 두지 않았었다. 지금은 프론트앤드쪽 작업을 하고 있으므로 모바일도 좀 알아야 되겠다 싶어서 모바일웹쪽을 만져보고 있는 중이다. 개인 프로젝트에서 모바일 웹을 작업하고 있는데 스크롤을 구현하는게 상당히 골치가 아팠다. 스크롤은 어디나 들어가는 아주 일반적인 기능이라고 생각하고 있었음에도 구현하는데 여러가지 어려움이 상당히 많았다.

모바일에서 스크롤 관련 라이브러리로 가장 유명한 것은 iScroll이다. 현재는 4버전이 최신 버전이고 iScroll 5가 베타상태에 있다. 처음에는 iScroll로 작업을 했는데 처음 사용해봐서 제대로 구현못한 건지 모르겠지만 아주 깔끔하게 안되는 부분이 좀 있었고 안드로이드 기기로 넘어가니 퍼포먼스가 너무 안나왔다. 그래서 OS 탑재된 네이티브 스크롤을 직접 이용하기로 하고 iScroll을 제거하고 직접 구현하고 있는데 그 가운데 스크롤에 관련된 내용을 좀 정리해야 좀더 다양한 기능 구현 및 최적화를 할 수 있을것 같아서 정리를 한다.(이미 다 아는 내용인데 나만 이제 확인한 것 같긴 하지만)
일단 내가 가진게 iOS라서 iOS에 맞추어서 작업을 하고 있다. 안드로이드에서도 동작하리라고 생각하지만 많은 테스트를 해보진 않았다. 예제는 Angular.js를 사용했는데 이벤트나 좌표를 추적해서 보여주기 위한 것이므로 스크롤과는 상관이 없다. 그리고 스크롤을 설명하는 예시일 뿐이므로 퍼포먼스가 많이 고려되어 있지는 않다.(누가 잘아시는 분이 설명을 해주시면 감사.)

스크롤

스크롤 영역으로 지정하는 것은 딱히 모바일 웹에 특화된 것은 아니다. 스크롤을 사용할 곳의 크기를 지정하고 CSS 속성에서 overflow: auto;로 지정하면 된다. 이러면 해당 영역보다 작을때는 상관없지만 해당 영역보다 내용이 많아지면 자동으로 스크롤이 동작하게 된다. 가로나 세로만 하고 싶다면 overflow-x: auto;, overflow-y: auto; 같은 식으로 작성하면 된다. 다음 예제를 보자.(스크롤은 스샷을 찍어서 설명하기가 어렵고 또 동영상을 찍기고 쉽지 않아서 실행해 볼 수 있는 예제를 만들었다. 이벤트가 다르므로 데스크탑에서는 제대로 동작하지 않을 수 있으므로 모바일장비에서 테스트해봐야 한다.)

실행가능한 예제 링크

각 동작을 한눈에 볼 수 있도록 예제를 구성했다.(폭이 좁아서 블로그내에서는 예제를 실행해보기 어려우므로 모바일에서 띄워보는게 확인하기 좋다.) 상단에는 좌표관련 정보를 표시하고 좌측에는 예제의 스크롤 영역이 있다. 우측에는 스크롤 동작과 관련한 이벤트가 출력되도록 했다. 모바일에서는 마우스가 없으므로 터치이벤트를 통해서 스크롤이 동작하게 되는데 터치할 때 touchstart이벤트가 발생하고 움직이면 touchmove가 발생하고 손가락을 뗄 때 touch가 발생한다. 움직이지 않고 바로 떼면 touchmove가 발생하지 않고 바로 touchend가 발생한다. 여기서는 스크롤 영역에 대한 테스트이므로 touchmove를 통해서 스크롤이 될 때 scroll이벤트도 함께 발생한다.

좌표와 관련해서는 스크롤 영역에는 scrollTop이라는 속성이 존재한다. 가장 최상위에 있을 때는 scrollTop이 0이고 스크롤을 내릴 수록 값이 커지게 된다. 각 이벤트에 대한 좌표를 알 수 있도록 touchstart, touchmove, touchend 의 좌표를 따로 표시하도록 했다. 예제소스는 jsFiddle에서 볼 수 있으므로 따로 전체소스를 담지는 않겠다.

모멘텀(momentum) 스크롤

앞에서 본게 기본 스크롤 영역이지만 이 스크롤을 실제로는 사용할 수 없다. 모바일에서 스크롤을 할 경우에는 가속도가 먹어서 손가락을 튕기면 스크롤이 빠르게 이동하는 스크롤을 사용하고 사용자에게도 이게 당연한 동작이다. 이를 모멘텀 스크롤이라고 부르는데 앞에서 본 예제는 손가락을 떼는 순간 스크롤이 멈추기 때문에 사용하기가 아주 불편하다.
iOS 즉 모바일 사파리(웹뷰 포함)에서 모멘텀 스크롤을 사용하려면 스크롤 영역에 -webkit-overflow-scrolling: touch; CSS 속성을 지정한다. 이 스타일만 지정하면 스크롤이 자연스러운 모멘텀 스크롤로 동작하게 된다.

실행가능한 예제 링크

이제 스크롤이 아주 자연스러워 진 것을 볼 수 있다. 하지만 
모멘텀 스크롤에는 몇가지 문제가 좀 있다.(이는 iOS의 버그수준이라고 생각하는데 어쨌든 문제가 있다.)
모멘텀 스크롤 중에는 scrollTop이 업데이트되지 않는다. 모멘텀 스크롤을 손가락으로 스크롤 영역을 튕겨서 동작하므로 즉 touchend이벤트가 발생한 이후에도 스크롤이 계속 이동하게 되는데 tocuchend이벤트까지는 scrollTop이 갱신되지지만 touchend이벤트가 발생한 이후에 모멘텀 스크롤가 동작하는 동안에는 scrollTop이 변하지 않고 모멘텀 스크롤이 시간이 지나서 자동으로 멈춘 순간 scroll이벤트가 발생하면서 scrollTop이 갱신된다. 그래서 현재 스크롤이 어느 위치에 있는지 찾을 수가 없고 심지어 모멘텀 스크롤이 동작하고 있다는 것 조차 알 수가 없다.(나중에 scroll이벤트가 발생하므로 모멘텀 스크롤이 동작했었구나 정도만 알 수 있다.)

모멘텀 스크롤에서 선택영역 사용하기

모멘텀 스크롤에서 선택영역을 함께 사용하지 않는다면 큰 문제는 없다. 아주 자연스럽게 스크롤을 할 수 있지만 나는 다음과 같이 하고 싶었고 어플리케이션에 따라 다르겠지만 당연한 동작이라고 생각했다.
  • 스크롤을 자연스럽게 사용할 수 있어야 한다.(이건 당연히...)
  • 리스트를 터치하면 선택했음을 알 수 있도록 색상을 변환한다.
  • 터치한 상태에서 스크롤을 하기 시작하면 선택하고자 한 것이 아니므로 선택은 취소되고 스크롤이 동작한다.
  • 스크롤도중에 클릭한 것은 선택하기 위한 것이 아니라 스크롤을 멈추고자 하는 것이므로 선택이 되지 않는다.
  • 리스트를 선택한 후에 손가락을 떼면 선택으로 동작한다.
scrollTop이 업데이트되지 않으므로 모멘텀 스크롤중의 터치도 잘못된 좌표가 인식된다. 말로 설명하려니 어려운데 스크롤 영역에 li같은 태그에 클릭 효과가 나도록 :active로 스타일을 주었을 경우 모멘텀 스크롤 중에(멈춘뒤 말고) 클릭을 해서 멈춘다면 현재 클릭한 부분이 선택영역으로 잡히지 않고 모멘텀 스크롤을 시작하기 전에 해당 위치에 있던 엘리먼트가 선택된 것으로 표시가 된다. :active 스타일이 다른 위치에 가서 먹고 실제 이벤트도 여기서 발생한다. 이는 다음 예제에서 확인해 볼 수 있다.

실행가능한 예제 링크

그래서 맨 앞에 얘기한 조건대로 클릭할 경우 리스트의 스타일을 변경해 주기 위해서 :active상태를 쓸 수 없다고 생각했다. 내가 생각한 방법은 선택에 대한 CSS 클래스를 주어서 터치이벤트에 따라 조건에 따라 클래스를 넣었다 빼었다 하는 것이다. 이렇게 하려면 지저분한 플래그가 꽤 필요하고 그래도 해결이 되지 않아서 스크롤에 대한 가속도를 측정하는 방법을 시도했다. 마지막 4개의 이벤트의 시간간격을 측정해서 모멘텀 스크롤처럼 손가락을 튕긴 것인지 아니면 그냥 스크롤을 하다가 손가락을 뗀 것인지를 판단하려고 한 것인데 일단 내 개인 프로젝트에서는 잘 동작하고 있다. 완벽하진 않지만 한 95%의 경우에서는 제대로 동작하는 것으로 보인다. 사실 이 부분도 예제로 만들려고 했지만 이건 잘 안됐다. 내가 만든것에서는 여러가지 UI가 섞여있어서인지 가속도 측정이 예제로 다시 구성하니 전혀 다르게 나와서 구성할 수가 없었다.(어째서!!!) 일단 내가 시도한 방법이 범용적으로는 쓸 수 없다고 생각해서 좀더 고민을 해봐야겠다. 정말 이 버그가 iOS 7에서는 해결이 되었으면 좋겠다. ㅠ

My Comment..
해당 글은 내가 아는 분야가 아닌 모바일 쪽이긴 한데 좀 신기하기도 하고 이런것도 있구나 하는 관점에서 읽어보고서 갖고 왔다.. 

2016년 10월 11일 화요일

[Talk] 나는 성과제를 별로 좋아하지 않는다..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

수많은 회사를 다녀본 것은 아니지만 내가 다녀본 회사들도 그렇고 들어본 얘기로도 국내 회사들은 대부분 성과제를 도입하고 있다. 하지만 보면 볼수록 불합리한 제도라는 생각밖에 들지 않고 시간이 갈수록 그따위 성과제에 연연하기 보다는 성과 좀 포기하고 맘편히 사는게 더 낫다고 느끼고 있다.
성과제의 원리는 간단하다. 더 열심히 혹은 더 잘 일하면 돈(혹은 그와 비슷한)으로 보상해 준다는 것인데 우리는 학교를 다니는 것은 아니므로 더 열심히 보다는 보통은 더 잘 즉 결과를 만들어내는 것에 초점이 맞추어져 있다. 이는 얼핏 보면 자연스러운 논리인 것처럼 보이지만 실상은 전혀 아니라고 생각한다. 제조업이가 전통적인 산업에는 어울리는지 몰라도 최소한 IT 분야에는 오히려 방해가 된다.

성과에 대한 평가를 어떻게 하지?

만약에 봉투접기라던가 인형에 눈알 붙히기 같은 작업이라면 성과제는 유효할 것이다. 평소에 100개 만드는데 100개 이상 만들면 그만큼 돈 더 준다고 한다면 아마도 만드는 갯수가 올라갈 것이다.(물론 품질등 확인해야할 여러 요소들이 있겠지만.) 하지만 IT는 그렇게 단순하지 않고 한 부분에 집중하고 있는 벤처라면 좀 낫겠지만 조직이 클수록 누가 잘한 성과인지 판별하는 건 거의 불가능하다고 본다.

A 사업이 소위 대박이 낫다고 하자. 이 대박의 공은 누구의 공일까? 간단히 보면 해당 사업을 추진한 사업부나 세부 내용을 기획한 기획쪽에 둘 수 있고 해당 사업을 개발한 개발팀도 포함될 수 있다. 그러면 회사의 공통인프라에 가까운 QA나 네트워크팀, 서버관리쪽은 어떤가? 물론 이부분에서 엉망이었다면 사업을 성공할 수 없었을 지도 모른다. 이런 부서의 성과는 어느정도로 평가해야 하는 걸까? 사업이나 기획에서는 무리한 요구를 했는데 개발이나 QA 혹은 다른 부서에서 좀더 합리적인 제안을 한게 성공의 주요 요인일 수도 있다. 이런걸 판별할 수 있기나 한가? 그리고 신규사업이란 건 보통 새로운 도전이고 결과가 보장되지 않는다. 그래서 보통은 현재 회사를 지탱하고 있는 수익을 내는 사업이 있고 어찌 보면 이런 사업들이 있었기에 다른 부서가 신규사업에 도전할 수 있는 것이었다. 그러면 이러한 사업을 하는 팀은 성과를 어떻게 평가할 것인가?(보통은 익숙해져서인지 성공한 사업도 수년이 지나면 더 성과를 내기를 바라지 현상 유지로 좋다는건 한번도 보지 못했다.)

성과를 주면 사람들이 더 열심히 일할까?

옆팀이 대박이 나서 엄청난 성과급을 받았다고 했을 때 "나도 내년에는 미친듯이 해서 성과급을 받겠어!"라고 하는 사람은 단 한명도 보지 못했다. 사람들은 대부분 자신이 상당히 열심히 잘 일했다고 생각하기 때문에 일반적인 반응은 "난 안해!"라는 것이다. 왜냐하면 이건 일을 잘한 것의 결과이기도 하지만 사람들은 다 잘 해왔기 생각하기에 그 결과는 좀 운빨로 보이기 때문인듯 하다. 그리고 성과제가 그렇게 유효하다면 전통적으로 회사의 기반이 되는 사업을 하는 사람은 아무도 없이 선택권이 있다면 새로 대박이 날 것처럼 보이는 회사로 다 몰려갈 것이다. 그러면 돈은 안되지만 유지는 해야하는 사업(어느 회사나 이런게 있다.)은 누가 하지? 일에 대한 열정도를 떠나서 경험상 그냥 시키니까 하는 거지 이런 일을 하고 싶어하는 사람은 없고 회사가 필요했다는 면에서 성과가 있지만 이들은 상대적인 박탈감을 느끼게 된다.

그리고 돌아가는 상황들을 보면 실제 성과를 내기 보다는 성과를 낸 것으로 포장하는 움직임이 훨씬 커진다. 왜냐하면 이게 훨씬 쉬운 일이기 때문이다. 모든 걸 성과로 연결시킴으로 써 각 조직들은 성과를 내기위해서 움직이지만 해당 사업이 잘못되었다고 생각했을 때 잘못을 인정하고 다른 길로 가는 것이 회사로써는 훨씬 생산적인 일이지만 그게 올해의 성과이기 때문에 잘못되었다고 깨달아도 인정하지 않고 성과가 나는 것으로 포장하게 되고 해당 사업과 회사는 점점 엉망이 되고 임원레벨(특별히 깨어있지 않다면)에서는 잘못된 성과보고를 보고 있을 가능성이 크다.

이러한 대표적인 제도가 내가 가장 멍청하다고 생각하는 KPI(Key Performance Indicators)인데 연간 혹은 분기별 목표를 잡고 움직인다는 건데 IT처럼 빠르게 움직이고 상황에 따라 움직여야 하는 분야에서는 KPI는 악에 가깝다. KPI를 적용하면 경험상 일을 제대로 하는 것보다 일은 적당히 하면서 KPI로 잡아놓은 일을 해내는게 성과를 내기에 훨씬 낫다.(물론 대부분은 이런거에 상관없이 팀장재량으로 인사고과가 결정되는 듯 하지만) 해당 KPI가 현재 팀에 도움되는지 회사에 도움되는 지 같은건 상관없고 KPI를 정했으면 그냥 거기에 집중하는게 개인에게 낫기 때문에 중간에 방향전환(KPI 조정시기 같은 형식적인게 있긴 하지만)을 하거나 KPI보다 회사에 도움되는 일을 찾기 보다는 그냥 KPI를 수행한다.

아무리 오랫동안 봐도 왜 유지되고 있는지 도저히 이해하기 어려운 제도 중 하나이다. 윗분들의 의도인지는 모르겠지만 거의 동작하지 않는다는 부분에서 여전히 이해할 수 없고 이건 이러한 정책을 정하는 사람들이 고민하기 싫어서 그냥 하던거 계속하는 식의 직무유기라고 밖에는 생각되지 않는다. 그럼 어떻게 하냐고 물을 수도 있지만 내 영역은 아니라서 나도 정확히 알수는 없지만 성과제로는 해결책이 아니라고 말하고 싶었던 거다. 내 얕은 생각으로는 그냥 1/n을 하면 되지 않는가 싶고 일잘하는 사람과 아닌 사람은 어차피 팀이나 같이 일하는 사람이 알기 마련이고 인사고과등 다른 접근 방법도 충분히 있다고 생각한다.

My Comment..
이것은 내가 항상 구경하는 햄의 블로그에서 역시나 가져온것인데.. 꽤나 오래전에 햄은 성과제도에 대해서 언급을 하였다.. 나는 햄처럼 지대한 관심을 갖고 개발에 임하는것도 아니고 그렇다고 해서 엄청난 공부를 한다거나 그러지는 않는다.. 물론 더 오래전과 비교하면 나름 관심을 갖으려고 노력은 하지만 말이다.. ㅋㅋㅋ.. 무튼.. 옛날부터 나도 성과제도에 대한 의문점은 항상 갖고 있었기에 해당 글을 읽으면서 공감이 되어서 갖고 왔다..

시간이 나름 꽤 흘렀지만 여전히 성과제도란 것이 존재하고 그 성과제도 때문에 다들 연연하고, 누구는 웃고 누구는 씁쓸함을 감수해야되는 것은 참 안타깝다.. 지금의 내 위치와 배경은 성과제도를 신경쓰지 않아도 되는지라 상관없지만, 다른 배경에 있는 성과제도 때문에 수 많은 교육에 참석을 해야되고, 직무 시험을 봐야되는 사람들을 곁에서 지켜보자면.. 저렇게 일을 잘하는 사람이 왜 시간을 뺏겨가면서까지 저런 말도 안되는 평가를 위해서 시간을 소비해야되나 싶다..

[UFC] UFC 마감뉴스..

출처 : SPOTV NEWS

2016년 10월 6일 목요일

[JAVA] 21장 엔터프라이즈 자바빈(EJB) 통합..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

21. 엔터프라이즈 자바빈(EJB) 통합

21.1 소개

경량 컨테이너인 스프링를 때로는 EJB의 대안으로 생각한다. 대부분의 어플리션과 유즈케이스는 아니지만 트랜잭션, ORM, JDBC 접근의 영역에서 풍부한 기능을 지원하도록 통합하는 많은 경우에 스프링을 컨테이너로 사용하는 EJB 컨테이너와 EJB로 동일한 기능을 구현하는 것보다 더 낫다고 생각한다.

하지만 스프링을 사용하는 것이 EJB의 사용을 막는 것은 아니라는 것이 중요하다. 사실 스프링은 EJB에 접근하고 EJB와 EJB의 기능을 구현하기 쉽게 한다. 게다가 EJB가 제공하는 서비스에 접근하는데 스프링을 사용하는 것은 이러한 서비스의 구현을 나중에 클라이언트 코드를 변경하지 않고도 로컬 EJB, 원격 EJB, POJO (plain old Java object)의 변형으로 투명하게 바꿀수 있게 한다.

이번 장에서 스프링이 EJB 접근과 구현을 어떻게 도와주는지를 살펴본다. 스프링은 상태가 없는 세션 빈(SLSBs, stateless session beans)에 접근할 때 특정 값을 제공하므로 이 부분부터 얘기해 보겠다.

21.2 EJB에 접근하기

21.2.1 개념

로컬 혹은 원격의 상태가 없는 세션 빈의 메서드를 호출하려면 클라이언트 코드는 보통 (로컬이나 원격) EJB Home 객체를 획득하는데 JNDI 검색을 수행해야 하고 실제 (로컬 혹은 원격) EJB 객체를 획득하려고 해당 객체의 'create' 메서드를 호출한다.
반복되는 저수준 코드를 피하려고 많은 EJB 어플리케이션은 Service Locator 패턴과 Business Delegate 패턴을 사용한다. 클라이언트 코드 곳곳에서 JNDI 검색을 하는 것보다 이 방법이 낫지만 일반적인 구현체는 중대한 결점을 가진다. 예를 들면 다음과 같다.
  • Service Locator나 Business Delegate 싱글톤에 의존하는 EJB를 사용하는 일반적인 코드는 테스트하기가 어렵다.
  • Business Delegate 없이 Service Locator 패턴을 사용한 경우 어플리케이션 코드는 여전히 EJB home의 create() 메서드를 호출하게 되고 예외를 다룬다. 그래서 어플리케이션 코드가 EJB API와 복잡한 EJB 프로그래밍 코델에 묶이게 된다.
  • Business Delegate 패턴의 구현은 보통 EJB의 같은 메서드를 호출하는 다수의 메서드를 작성해야 하는 곳에 상당한 코드중복을 유발한다.
스프링의 접근은 코드없이 business delegates처럼 동작하는 프록시 객체(보통 스프링 컨테이너에 설정한)를 생성하고 사용할 수 있게 한다.이러한 코드에 실제 값을 추가하지 않고 별도의 Service Locator나 JNDI 검색, 하드코딩된 Business Delegate의 중복된 메서드를 작성할 필요가 없다.

21.2.2 로컬 SLSBs에 접근하기

로컬 EJB를 사용해야 하는 웹 컨트롤러가 있다고 해보자. 베스트 프렉티스를 따르고 EJB Business Methods Interface 패턴을 사용할 것이므로 EJB의 로컬 인터페이스는 EJB에 특화되지 않은 비즈니스 메서드 인터페이스를 확장한다. 이 비즈니스 인터페이스를 MyComponent라고 하자.

1
2
3
4
5
Java

public interface MyComponent {
  ...
}

Business Methods Interface 패턴을 사용하는 주요 이유 중 하나는 로컬 인터페이스의 메서드 시그니처와 빈 구현 클래스간의 동기화를 자동으로 보장하기 때문이다. 다른 이유로는 나중에 필요하다면 서비스의 구현을 POJO(plain old Java object)로 바꾸기 아주 쉽기 때문이다. 물론 로컬 홈(home) 인터페이스를 구현해야 하고 SessionBean과 MyComponent 비즈니스 메서드 인터페이스를 구현하는 구현 클래스를 제공해야 할 것이다. 이제 웹계층 컨트롤러를 EJB 구현체와 연결하기 우해서 필요한 Java 코딩은 컨트롤러에 MyComponent 타입의 setter 메서드를 노출하는 것 뿐이다. 컨트롤러에 인스턴스 변수에 대한 참조를 아낄 수 있다.

1
2
3
4
5
6
7
Java

private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
  this.myComponent = myComponent;
}

이 다음부터는 컨트롤러의 어떤 비즈니스 메서드에서도 이 인스턴스 변수를 사용할 수 있다. 이제 스프링 컨테이너 외부의 컨트롤러 객체를 획득한다고 가정하면 EJB 프록시 객체가 될 LocalStatelessSessionProxyFactoryBean 인스턴스를 (같은 컨텍스트내에서)설정할 수 있다. 프록시의 설정(컨트롤러의 myComponent 프로퍼티의 설정)은 다음과 같은 설정으로 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Xml

<bean id="myComponent"
    class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
  <property name="jndiName" value="ejb/myBean"/>
  <property name="businessInterface" value="com.mycom.MyComponent"/>
</bean>

<bean id="myController" class="com.mycom.myController">
  <property name="myComponent" ref="myComponent"/>
</bean>

AOP 개념을 사용하도록 하지 않았더라도 내부에서 스프링 AOP 프레임워크덕에 많은 작업이 이뤄진다. myComponent 빈 정의는 비즈니스 메서드 인터페이스를 구현하는 EJB의 프록시를 생성한다. EJB 로컬 홈(home)은 구동시에 캐싱되므로 딱 하나의 JNDI 검색만 존재한다. EJB가 호출될 때마다 프록시는 로컬 EJB의 classname 메서드와 EJB에서 대응되는 비즈니스 메서드를 호출한다.
myController 빈 정의는 컨트롤러 클래스의 myComponent 프로퍼티를 EJB 프록시로 설정한다.
아니면 (많은 프록시 정의가 있는 경우에는) 스프링의 "jee" 네임스페이스의 설정요소를 사용하는 것을 고려해봐라.

1
2
3
4
5
6
7
8
Xml

<jee:local-slsb id="myComponent" jndi-name="ejb/myBean"
    business-interface="com.mycom.MyComponent"/>

<bean id="myController" class="com.mycom.myController">
  <property name="myComponent" ref="myComponent"/>
</bean>

이 EJB 접근 메카니즘은 어플리케이션 코드를 엄청나게 간소화 한다. 웹계층 코드(또는 다른 EJB 클라이언트 코드)는 EJB 사용에 대한 의존성을 같지 않는다. 이 EJB 참조를 POJO나 목(mock) 객체, 테스트 스텁등으로 교체하고자 한다면 자바 코드를 변경하지 않고 myComponent 빈 정의를 변경하면 된다. 게다가 JNDI 검색이나 어플리케이션의 다른 EJB관련 코드를 한줄도 작성할 필요가 없다.
실제 어플리케이션의 벤치마크와 경험에 따르면 이 접근(대상 EJB의 리플렉션 호출(reflective invocation)을 포함해서)의 성능 부하(performance overhead)가 최소이고 일반적인 사용해서는 발견할 수 없는 정도임을 나타낸다. 어플리케이션 서버의 EJB 인프라와 관련된 비용때문에 어떤 식으로든 EJB에 세밀한 호출을 원치 않는다는 점을 기억해라.
JNDI 검색과 관련해서 한가지 주의할 점이 있다. 빈 컨테이너에서 이 클래스는 싱글톤으로 사용하기 가장 좋다.(프로토타입으로 만들 이유가 없다.) 하지만 해당 빈 컨테이너가 싱글턴을 미리 인스턴스화했다면(다양한 XML ApplicationContext에 따라서) EJB 컨테이너가 대상 EJB를 로그하기 전에 빈 컨테이너가 로드되는 문제가 있을 것이다. JNDI 검색이 이 클래스의 init() 메서드에서 수행된 후 캐시되지만 EJB는 아직 대상 로케이션에 바인딩되지 않았기 때문에 이 문제가 발생한다. 이 팩토리 객체를 미리 인스턴스화 하지 않고 처음 사용할 때 생성하도록 해서 해결할 수 있다. XML 컨테이너에서 lazy-init 속성으로 이를 제어한다.
대부분의 스프링 사용자들은 관심이 없겠지만 EJB와 동작하는 프로그래밍적인 AOP를 사용하려면 LocalSlsbInvokerInterceptor를 참고해라.

21.2.3 원격 SLSB 접근

원격 EJB에 접근하는 것은 SimpleRemoteStatelessSessionProxyFactoryBean나 설정 요소를 사용하는 것외에는 본질적으로 로컬 EJB에 접근하는 것과 같다. 물론 스프링을 사용하든지 사용하지 않는지 간에 원격 호출의 개념이 적용된다. 즉, 다른 컴퓨터의 VM에서 객체의 메서드를 호출하려면 사용 시나리오와 실패처리를 다르게 처리해야 한다.
스프링의 EJB 클라이언트는 스프링을 사용하지 않은 접근보다 더 많은 장점을 제공한다. 보통 EJB 클라이언트 코드를 로컬 EJB 호출과 원격 EJB 호출간에 변경하는 것은 문제의 소지가 있다. 이는 원격 인터페이스 메서드가 RemoteException를 던지도록 선언해야 하고 클라이언트 코드는 이를 다뤄야(로컬 인터페이스 메서드는 다루지 않는다) 하기 때문이다. 로컬 EJB용으로 작성한 클라이언트 코드를 원격 EJB로 바꾸어야 한다면 보통 원격 예외에 대한 처리를 추가해야 하고 원격 EJB용으로 작성한 클라이언트 코드를 로컬 EJB로 변경해야 한다면 바꾸지 않고 놔두어도 되지만 불필요한 다수의 원격 예외처리를 하거나 이러한 부분을 제거해야 한다. 스프링 원격 EJB 프록시를 사용하면 Business Method Interface에 RemoteException를 던지도록 선언해서 EJB 코드를 구현하지(RemoteException을 던지는 부분을 제외하고는 동일한 원격 인터페이스를 가지면서) 않고 두 인터페이스를 동일한 것처럼 동적으로 다루도록 프록시에 의존할 수 있다. 즉, 클라이언트 코드든 체크드 RemoteException 클래스를 다루 않아야 한다. EJB 호출중에 던져진 실제 RemoteException은 체크드가 아닌 RemoteAccessException 클래스(RuntimeException의 하위클래스)로 다시 던져질 것이다. 대상 서비스를 클라이언트 코드가 인지하거나 신경쓸 필요없이 로컬 EJB와 원격 EJB(또는 평범한 자바 객체더라도) 구현간에 변경할 수 있다. 물론 이는 선택사항이므로 비즈니스 인터페이스에 RemoteExceptions를 선언하지 않을 이유는 없다.

21.2.4 EJB 2.x SLSBs 접근과 EJB 3 SLSBs 접근 비교

스프링의 EJB 2.x Session Bean 접근과 EJB 3 Session Bean 접근은 아주 투명하다. 를 포함해서 스프링의 EJB 접근자는 투명하게 런타임에서 실제 컴포넌트에 맞게 맞춰진다. home 인터페이스를 찾으면(EJB 2.x 방식) home 인터페이스를 처리하고 home 인터페이스가 없으면(EJB 3 방식) 바로 컴포넌트를 호출한다.
Note: 평범한 JNDI 검색에 사용할 수 있는 컴포넌트 참조가 완전히 노출되므로 EJB 3 Session Bean에서 JndiObjectFactoryBean / 를 효과적으로 사용할 수 있다. 명시적으로 / 검색을 정의하면 일관성있고 더 명확한 EJB 접근 설정을 할 수 있다.

21.3 EJB 구현을 지원하는 스프링 클래스 사용하기

21.3.1 EJB 2.x에 기반한 클래스

스프링은 EJB를 쉽게 구현하도로고 편리한 클래스를 제공한다. 이 클래스들은 EJB가 트랜잭션 경계와 (추가적으로) 원격을 담당하고 POJO로 EJB뒤에 비즈니스 로직을 좋은 방법을 권장하도록 설계되었다.
상태를 보관하든 보관하지 않든 세션 빈이나 Message Driven 빈을 구현하려면 AbstractStatelessSessionBean, AbstractStatefulSessionBean, AbstractMessageDrivenBean/AbstractJmsMessageDrivenBean를 각각 상속받아서만 구현해야 한다.
실제로 구현을 평범한 자바 서비스 객체레 위임하는 상태없는 세션 빈의 예제를 생각해 보다. 다음과 같은 비즈니스 인터페이스를 가지고 있다.

1
2
3
4
5
6
Java

public interface MyComponent {
  public void myMethod(...);
  ...
}

다음과 같은 펑범한 자바 구현 개체도 있다고 하자.

1
2
3
4
5
6
7
8
Java

public class MyComponentImpl implements MyComponent {
  public String myMethod(...) {
    ...
  }
  ...
}

다음은 상태없는 세션 빈이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
Java

public class MyFacadeEJB extends AbstractStatelessSessionBean
    implements MyFacadeLocal {

  private MyComponent myComp;

  /**
   * Obtain our POJO service object from the BeanFactory/ApplicationContext
   * @see org.springframework.ejb.support.AbstractStatelessSessionBean#onEjbCreate()
   */
  protected void onEjbCreate() throws CreateException {
    myComp = (MyComponent) getBeanFactory().getBean(
      ServicesConstants.CONTEXT_MYCOMP_ID);
  }

  // for business method, delegate to POJO service impl.
  public String myFacadeMethod(...) {
    return myComp.myMethod(...);
  }
  ...
}

스프링 EJB 지원 기반(base) 클래스들은 기본적으로 생명주기의 일부로 스프링 IoC 컨테이너를 생성하고 로드해서 EJB에서사용할 수 있게 한다.(예를 들면 앞의 코드에서 POJO 서비스 객체를 얻으려고 사용했듯이) BeanFactoryLocator의 하위클래스인 전략(strategy) 객체로 IoC 컨테이너를 로드한다. 기본적으로 사용하는 BeanFactoryLocator의 실제 구현체는 JNDI 환경변수(EJB 클래스에서는 java:comp/env/ejb/BeanFactoryPath)로 지정한 리소스 위치에서 ApplicationContext를 생성하는 ContextJndiBeanFactoryLocator이다. BeanFactory/ApplicationContext 로딩전략을 변경해야 한다면 setBeanFactoryLocator() 메서드나 EJB의 진짜 생성자에서 setBeanFactoryLocator() 메서드를 호출해서 기본 BeanFactoryLocator 구현체를 오버라이드한다. 자세한 내용은 자바독을 참고해라.
자바독에 나와있듯이 생명주기내에서 보호하거나(passivated) 재가동(reactivated)해야 하면서 직렬화할 수 없는 컨테이너 인스턴스를 사용하는 상태를 가진 세션빈은 EJB 컨테이너가 저장할 수 없으므로 보호와 활성화에서 BeanFactory를 내리거나 다시 로드하려면 ejbPassivate()와 ejbActivate()에서 unloadBeanFactory()와 loadBeanFactory()를 수동으로 각각 호출해야 할 것이다.
ContextJndiBeanFactoryLocator 클래스의 기본동작은 EJB가 사용하는 ApplicationContext를 로드하는 것이고 이는 일부의 상황에서는 적합하다. 하지만 ApplicationContext가 다수의 빈을 로딩하거나 초기화하는데 시간이 많이 걸리거나 메모리를 많이 쓰는(하이버네이트 SessionFactory 초가화 등) 경우 각 EJB가 자신만의 복사본을 갖기 때문에 문제가 될 수 있다. 이러한 경우 기본 ContextJndiBeanFactoryLocator 사용을 오버라이드하고 여러 EJB나 다른 클라이언트가 사용할 공유 컨테이너를 로딩해서 사용할 수 있는 ContextSingletonBeanFactoryLocator같은 다른 BeanFactoryLocator를 사용하길 원할 것이다. 이 작업은 상대적으로 간단한데 EJB에 이를 위한 코드를 추가해서 할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Java

/**
  * 기본 BeanFactoryLocator 구현을 오버라이드한다
  * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
  */
 public void setSessionContext(SessionContext sessionContext) {
   super.setSessionContext(sessionContext);
   setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
   setBeanFactoryLocatorKey(ServicesConstants.PRIMARY_CONTEXT_ID);
 }

그 다음 beanRefContext.xml 파일에 빈 정의를 생성해야 한다. 이 파일은 EJB에서 사용할 모든 빈 팩토리를 정의한다.(보통은 어플리케이션 컨텍스트의 형식이다) 대다수의 경우 이 파일은 다음과 같은 (businessApplicationContext.xml는 모든 비즈니스 서비스 POJO의 빈 정의를 담고 있다.) 하나의 빈 정의만 담고 있을 것이다.

1
2
3
4
5
6
7
Xml

<beans>
  <bean id="businessBeanFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg value="businessApplicationContext.xml" />
  </bean>
</beans>

위의 예제에서 ServicesConstants.PRIMARY_CONTEXT_ID 상수는 다음과 같이 정의될 것이다.

1
2
3
Java

public static final String ServicesConstants.PRIMARY_CONTEXT_ID = "businessBeanFactory";

사용방법에 대한 자세한 내용은 BeanFactoryLocator와 ContextSingletonBeanFactoryLocator의 자바독을 참고해라.


21.3.2 EJB 3 주입 인터셉터

EJB 3 Session Bean과 Message-Driven Bean을 위해서 스프링은 EJB 컴포넌트 클래스에서 스프링 2.5의 @Autowired 어노테이션을 처리하는 편리한 인터셉터 org.springframework.ejb.interceptor.SpringBeanAutowiringInterceptor를 제공한다. EJB 컴포넌트 클래스에서 @Interceptors 어노테이션을 사용하거나 EJB 배포 디스크립터 (deployment descriptor)에서 interceptor-binding XML 요소를 사용해서 이 인터셉터를 적용할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
Java

@Stateless
@Interceptors(SpringBeanAutowiringInterceptor.class)
public class MyFacadeEJB implements MyFacadeLocal {

  // 일치하는 스프링 빈을 자동으로 주입한다
  @Autowired
  private MyComponent myComp;

  // 비즈니스 메서드를 위해서 POJO 서비스 구현에 위임한다.
  public String myFacadeMethod(...) {
    return myComp.myMethod(...);
  }
  ...
}

기본적으로 SpringBeanAutowiringInterceptor는 ContextSingletonBeanFactoryLocator에서 beanRefContext.xml 빈 정의 파일에 정의된 컨텍스트와 대상 빈을 가져온다. 기본값은 이름이 아니라 타입으로 가져오는 단일 컨텍스트 정의이지만 여러 컨텍스트 정의에서 선택해야 한다면 특정 로케이터(locator) 키가 필요하다. 로케이터 키(예를 들면 beanRefContext.xml의 컨텍스트 정의 이름)는 커스텀 SpringBeanAutowiringInterceptor 하위클래스의 getBeanFactoryLocatorKey 메서드를 오버라이딩해서 명시적으로도 지정할 수 있다.
아니면 SpringBeanAutowiringInterceptor의 getBeanFactory 메서드를 오버라이딩 하는 것을 고려해라. 예를 들면 커스텀 소유(holder) 클래스에서 공유된 ApplicationContext를 가져오는 식이다.

[UFC] 미들급 파이터 조쉬 샘먼 사망하다..

여느 때 처럼 아침에는 뉴스를 본다.. 거창하게는 아니지만 IT 뉴스를 보고, 스포츠 그리고 연예뉴스.. 기타 가십거리 등을 본다..

그러던 중 내가 좋아하는 스포츠 중 하나인 UFC 에서 기가막힌 소식을 들었다.. 선수 중 한명이 사망을 한 것인데.. 더욱 안타까운 것은 그의 나이가 28세에 불과하기 때문이다.. 그 이름은 바로 조쉬 샘먼 이다..



여느 선수처럼 엄청 유명한 선수는 아니지만, 한 선수가 은퇴가 아닌 부상 또는 사망 등에 의한 어쩔 수 없이 사라지는 것은 항상 안타깝다..

조쉬 샘먼을 지난 9월 30일 샘먼과 친구를 발견하고 바로 병원으로 후송했지만 발견 당시 혼수상태였으며, 그의 친구는 이미 사망한 상태였던 것으로 확인되었다고 한다..

병원으로 이송된 샘먼은 1주일 가까이 사경을 헤매다 결국 지난 5일 사망했다고.. 경찰은 약물 과다복용으로 인한 사망으로 추정하고 있다.. 다만 브로워드 카운티 수석 검시관은 "발견 후 며칠 동안 생존 상태였고, 사인을 테스트할 적절한 표본이 없다. 아직까진 약물 복용을 결정적 사인으로 보기 어렵다"는 입장을 밝혔다는데..

과거 프로레슬링 선수들의 사망때도 그랬고, 대부분의 격투기 관련 선수들은 직업 특성 자체 때문에 몸이 힘들고 체력적으로 힘들어서 그런지 약물에서 자유롭지가 못한듯 하다.. 어찌보면 비교적 약물에 대해서 관대하고 구하기 쉬운 해외 특성 때문일지도 모르겠다.. 무튼 안타깝다..

마지막으로 샘먼을 간략하게 소개해보자면 통산 16전 12승 4패의 미들급 파이터였으며, 지난 2013년 디 얼티밋 파이터(The Ultimate Fighter) 23 에서 케빈 케이시를 TKO로 꺾으며 화려하게 데뷔했다.. 12월 뉴욕에서 개최되는 UFC 파이트 나이트(Fight Night) 102에서도 올루웨일 밤보세 와의 경기가 잡힌 상태였다..

특히 샘먼은 지난 2013년 자신의 여자친구인 헤일리 베비스를 교통사고로 떠나 보내며, 자살을 생각했을 정도로 비극을 겪은 바 있다.. 이후 2014년에 힘겹게 옥타곤으로 돌아온 그는 복귀전에서 에디 고든을 하이킥으로 KO시키며, "이 승리를 천국에 있는 여자친구에게 바친다"라고 말해 감동을 자아내기도 했다. 하지만 2년 만에 샘먼도 결국 세상을 떠나며 안타까움을 더하고 있다..

고인의 명복을 빈다..

[UFC] UFC 마감뉴스..

출처 : SPOTV NEWS