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프로토콜 매커니즘과 보안기능 향상을 제공한다.