»
S
I
D
E
B
A
R
«
스크럼 요약 정리
Jul 24th, 2014 by Wegra Lee

4~5년 전 스크럼 공부하며 정리해 놓은 마인드맵이다.

대부분 <스크럼: 팀의 생산성을 극대화시키는 애자일 방법론>의 내용이라 보면 된다.

이미지가 엄청 크니 확대해서 보시길..

Scrum

스크럼 주의점 몇 개
Jul 23rd, 2014 by Wegra Lee
최근 팀에서 태스크보드를 쓰기 시작하면서 스크럼 용어가 언급되어
몇 가지 중요한 것 당부한 글…
스크럼에서는 기본적으로 ‘개인’은 별 의미가 없습니다. ‘팀’만 생각합니다.
누구 한 사람이 특정 작업을 완료하지 못했어도 결국 팀의 책임입니다.
누군가에게 잡무가 너무 많다면 이를 막거나 줄여주거나 대신 해주어야 하며, 방도가 없다면 어쩔 수 없는 거죠.
기술 문제에 봉착해 있다면 해법이나 길을 알려줘야 합니다.
팀은 공동 운명체..!!
이를 위해선
누가 뭘 하고 있는지, 어떤 문제가 있는지 활발히 공유하고 서로 도와야 합니다.
그 방법으로 태스크보드, 일일 스크럼 회의, 회고 같은 도구 쓰게 됩니다.
태스크보드는 팀의 목표와 진척 현황을 상시로 한 눈에 살펴보고, 목표를 상기하기 위한 도구입니다. 무언가 제대로 안되고 있다면 표가 나겠죠. 일일 스크럼 때 활용하기도 하고요.

보드에 붙이는 업무는 가능하면 (집중했을 때) 4시간 안에 끝낼 수 있는 단위로 나누는 게 좋습니다. 하루하루 지날 때 Done으로 옮기는 포스트잇이 있고 없고가 성취감에 큰 영향을 주기도 하고, 며칠이 지나도 계속 Doing 상태면 다른 이뿐 아니라 자신도 현황 파악이 안되고 목표도 불분명해져 관리가 안 됩니다.

일일 스크럼은 보다 적극적인 상황 공유 수단입니다.
매일 ‘같은 시간’에 ‘모든 팀원’이 모여 각자 다음 ‘세 가지’를 이야기합니다.
  • 어제 한 일
  • 오늘 할 일
  • 봉착한 문제
이중 가장 중요한 것이 봉착한 문제입니다. 모든 팀원은 이 문제를 해결할 방법을 고민하고 알려줘야 합니다. ‘고민, 잘 모르겠는 것, 실수 등을 편하게 털어 놓으면 누군가가 노하우를 알려준다’는 분위기가 형성되지 않으면 서로 벽이 생기고 사람들이 위축됩니다.
회의 시간은 최대 15분으로 제한합니다. 길어질 이슈는 일일 스크럼 후에 담당자만 따로 모여 이야기합니다.
<같은 시간, 15분 이내, 상황 공유>를 통해 다른 회의를 최소화하고 각자 일에 집중할 수 있게 합니다. 따라서 시작 시간이 들쑥날쑥 하거나 회의가 길어지면 효과가 반감됩니다.
회고는 주로 더 큰 관점의 노하우 공유나 제도 개선 방안 등을 논하는 자리입니다. 자아 비판이 아닙니다. 주로 이런 논의가 이루어집니다.
  • 평소 이런 게 좀 잘 안된다고 생각했는데, 이렇게 하면 나아질 것 같다
  • 이번에 이렇게 해봤는데 괜찮았으니 계속 해보자.
  • 이 아이디어는 막상 해보니 처음 생각같은 효과가 없었다. 취소하거나 방식을 바꿔서 다음엔 이렇게 해보자.
[업데이트] 책리뷰 <개발자 영어, 코드로 감 잡다>
Jul 2nd, 2014 by Wegra Lee

<개발자 영어, 코드로 감 잡다>

IMG_4587수년 전부터 ‘개발자를 위한 영어’라는 주제에 관심이 있었고, 책을 써볼까 하는 생각도 했던 터라 이 책이 나온다는 소식에 반갑고도 한편으론 아쉬웠다. 어떤 책인지, 내 생각과는 무엇이 비슷하고 다른지 무척 궁금하여 저자에게 연락도 해보고 출간과 거의 동시에 주문했다. 정작 그래놓고 이런저런 핑계로 이제서야 읽게 되었다.

하지만 아쉬움이 많이 남는다.
적어도 내게는 잘 와 닿지 않고, 다른 이에게 권해볼 마음도 솔직히 들지 않는다.
이 책의 콘셉트는 개발자에게 익숙한 프로그래밍 언어 소스 코드의 구조를 빌려 영어를 가르친다는 것이다. 재미난 접근이지만 문제가 있다. 프로그래밍 언어란 컴퓨터에 로직을 가르친다는 제한된 목적만으로 만들어진 절제된 언어다. 사람끼리의 원활한 의사소통을 위해 수천 년을 진화해온 영어와는 비교할 수 없다. 작은 것으로 더 큰 것을 설명하려다 보니 여러 가지로 한계가 있지 않았나 짐작된다.

기본 개념은 문장을 하나의 완제품이라 보고, 완제품을 만들기 위해 여러 부품(문장 구성 요소)을 조립해가며 영어를 익힌다는 것이다. 그 부품들을 뭐는부품(주어), 뭐한다부품(동사), 뭐를부품(목적어), 어떤부품(형용사), 어케부품(부사) 등으로 부른다. 여기서의 문제는 십수 년간 영어를 공부한 사람이든 십수 년간 개발을 해온 사람이든 가리지 않고 너무 생소한 용어를 사용한다는 점이다. 도서관에서 맘 잡고 공부한 건 아니지만, 책 읽는 내내 이 용어들에 익숙해지지 못했다.

다양한 예외가 등장한다. 수식하는 위치(앞/뒤) 과거형, 과거분사형, 관사, 복수형, 절과 구, 의문문 등 영어를 배우기 위해선 꼭 필요하지만 위와 같은 간단한 구조에서는 표현할 수 없는 특성이 많아, 결국은 ‘이럴 땐 이렇게’, ‘요럴 땐 요렇게’가 될 수밖에 없다. ‘코드로 감 잡다’는 부제를 가지고 있지만, 코드의 범위를 벗어나 원래 영어를 배우기 위해 필요한 모든 요소를 잘 맞지 않는 틀과 익숙하지 않은 용어로 배우려 하는 것 같다.

너무 신랄한데ㅡㅡ 아무튼 그렇다. ;;

저자께는 죄송하지만, ‘영어를 더 쉽게 배워보겠다’라는 진지한 생각보다는 ‘영어를 이렇게도 설명할 수 있구나?’가 궁금한 사람에게 추천함직하다는 게 솔직한 총평이다.

[업데이트]

저자인 나솔님과 나눈 이야기 요약..

나: 작은 걸로 큰 걸 설명하려니 또 하나의 낯선 문법이 만들어진 거 같아요. 우리 나라 개발자는 다들 영어를 배웠으니, 낯선 문법보단 익숙한 영어 문법이 나을 지도..

나솔님: 어떤 말씀인지 알겠어요.

나: 색다르고 체게를 완성도 있게 구축한 건 높이 평가해요. 그리고 영어를 갈구하는 개발자들이란 시장의 존재를 입증한 선구자시기도 하고요. 그래서 앞으로 경쟁작 많이 나올 겁니다.

나솔님: 시장 드러나게 하기가 바로 원하는 거였어요. 혼자선 한계가 있죠.

나: 새로운 방식이 시선 끌기는 좋지만, 실효성은 아직 물음표네요. 실효성을 높이려면 추가적인 노력이 필요할 거에요.

나솔님: 물론이죠. 책 한 권으로 끝낼 생각은 아닙니다.

나: 솔직히 물음표지만 여기서 끝내긴 아까우니 열심히 부탁합니다. 시장 드러내줘서 고마워요.

[저자 특강]

곧 8월 1일에 저자 특강도 있으니 관심 있는 분은 서둘러 등록~

책리뷰 <월스트리트저널 인포그래픽 가이드>
Jul 1st, 2014 by Wegra Lee

올만에 책 리뷰를 간략히 적어본다.

IMG_4568

<월스트리트저널 인포그래픽 가이드>
도나 웡 지음 | 이현경 옮김 | 인사이트

책 표지부터 내용, 편집까지 정말 군더더기 없이 깔끔한 책이다!!
직장인이라면 누구나 항상 책꽂이에 꽂아두고 도표를 그릴 때마다 한 번씩 뒤적여봐야 할 책이다.

몇 달 전 한 UX 강사로부터 최고의 인포그래픽 책이라는 극찬을 듣고 구입하게 되었지만,
인포그래픽 전반을 다루지는 않기 때문에, 다소 논란의 여지는 있을듯하다.
이 책의 주 대상은 차트와 표(table), 그중에서도 ‘월스트리트 저널’이라는 이름에서 알 수 있듯 경제/금융 쪽에 사용되는 것에 초점을 맞춘다.
그렇다고 이게 큰 단점이 되진 않는다. 막대 차트, 선 차트, 파이 차트, 표. 실상 우리는 이것 외에는 쓸 일이 평생 몇 번 없기 때문이다. (책에서는 픽토그램과 표도 살짝 다룬다.^^)
오히려 우리에게 꼭 필요한 핵심만을 간추려 알기 쉽게 설명한 액기스다.

1장 ‘기본 원칙’은 데이터 선정부터 글꼴, 색상, 숫자 사용 시 주의점 등 말 그대로 어느 경우에나 주의해야 할 원칙들을 설명한다.
2장 ‘똑똑하게 차트 그리기’는 본격적으로 선/막대/파이 차트, 표, 픽토그램, 지도 그리기를 다룬다. 항시 나쁜 예와 좋은 예를 함께 보여주어 짧은 설명만으로도 이야기의 핵심을 쉽게 파악할 수 있도록 구성했다.
3장 ‘차트 편람’은 차트를 그릴 때 많이 사용하는 기초적인 수학/통계 지식과 시장 지식을 설명하며 올바른 사용법을 알려준다.
4장 ‘난감한 상황’은 일부 데이터가 누락된 경우처럼 망설여지는 상황에서의 원칙과 대처법을 알려준다.
5장 ‘차트로 계획 세우기’는 팀 구성, 일정, 진척 보고 등 프로젝트 관리 정보를 차트로 표현하는 효과적인 방법을 소개한다.

Wisdom Compiler 3개월
May 13th, 2014 by Wegra Lee

나는 관심분야가 넓고 배우고 느낀 것을 동료에게 알리고 인터넷에 공유하길 좋아한다. 그 과정에서 남으로부터 역으로 배우고 깨우치는 희열도 짜릿하다. 하지만 현실과 싸워가며 꿈꾸는 멋진 작품과 이상적인 개발 문화를 이끌기에는 나의 역량이 턱없이 부족하여 조금씩 지쳐가고 있었다. 어느 사이엔가 꿈을 향한 시선을 반쯤은 돌리고 지내던 어느 날, 뜻밖에 찾아온 기회는 지금껏 몰랐던 새로운 방향에서 꿈을 바라보게 해주었다.

올바른 문화를 만들고 필요한 지식을 알려주는 걸 반드시 내가 직접 깨우쳐서 이끌 필요는 없지 않은가? 그러자 일찍부터 나보다 넓고 다양하고 깊은 지식을 수많은 개발자에게 알려주는 데 앞장서온 사람들이 보였다. 바로 편집자였다. 편집자란 당시 내겐 생소한 직업이었기에 확신할 수는 없었지만 적어도 3개월을 경험한 지금 생각엔 내가 제대로 보았던 것 같다.

그간 빅데이터, 게임, 보안, 자바, 프로젝트 관리 등 다양한 분야의 번역서를 기획하고 역자를 섭외해 일을 진행 중이다. 그중 일부는 최근 1/3 원고검토까지 마쳤다. 많은 일은 아니지만 욕심내지 않고 착실히 배우는 데 집중하고 있다.

교열 교육도 많은 도움이 되었다. 복잡하게만 느껴지던 우리말 체계도 안타까운 사정을 듣고 나니 애착이 생기고, 무엇보다 나름의 교열 원칙도 어렴풋이나마 틀을 만드는 기회가 되었다.

더불어 여러 IT 세미나와 모임에 참석하며 새로운 분야를 배우고 인맥도 쌓고 있다. 개발자 시절엔 당장의 업무와 관련 없고 바쁘다는 핑계로 미루기만 했던 활동들이다.

온통 배움의 연속이다. 대학 졸업 후 너무 오랜만이어서인지, 이 모두가 샤워의 상쾌한 물줄기처럼 삶에 생기를 북돋우고 있다.

물론 시행착오도 겪고 생각만큼 되지 않은 일도 있다. 행정/프로세스/기술 문제는 모르면 묻고 배우고 고치면 되지만, 저자나 역자를 보필하여 훌륭한 원고를 제때 만들어내는 노하우는 쉽게는 깨우치기 어려울 것 같다. 실제로도 지금 진행 중인 모든 책이 처음 목표보다 지연되고 있다. 느슨한 계약 관계에서 떨어져 일하다 보니 사람이란 변수의 영향은 소프트웨어 개발 관리보다도 훨씬 클 것이다. 특히나 창작이 대부분인 집필서라면 편집자도 함께 고뇌하고 함께 극복하는 자세가 필요하리라 본다.

또 하나의 어려운 숙제는 훌륭한 책을 기획하는 실력과 눈을 키우는 일이다. 책 만드는 과정에 익숙해지면 본격적으로 고민하기 시작할 주제로, 많은 개발자와 IT 꿈나무를 올바른 길로 인도하고 그들에게 꼭 필요한 지식과 지혜를 전해주는 작품을 만들어 보려 한다. IT 출판 편집자의 당연한 사명이면서 내가 이 길로 뛰어든 목표이기에 기꺼운 마음으로 도전하겠다.

마지막으로 새로운 본분에도 소홀히 하면 안 되겠다. 후배 개발자를 위하는 마음 그대로, 지금 함께 일하는 동료 편집자와 앞으로 들어올 후배 편집자에게도 내가 깨닫고 배운 것을 아낌없이 공유할 것이다. 최근 바빠져서 주춤했지만, 소통과 공유와 업무 효율 개선을 위한 활동도 틈틈이 진행하고 있다. 큰 성과를 내지 못하더라도 이러면서 서로를 배우고 팀과 하나가 되어 가리라 믿는다.

라이브러리 vs. 프레임워크
Apr 7th, 2014 by Wegra Lee

라이브러리와 프레임워크라는 프로그래밍을 조금만 하다 보면 접하는 흔한 용어이지만 그 정의나 차이점을 물어보면 선뜻 답하지 못하는 프로그래머가 많다.

라이브러리는 자주 사용하는 기능을 미리 만들어 놓은 API 집합이다. 최대값/최소값을 구하는 간단한 함수부터 윈도우나 글상자를 그려주는 GUI 클래스 등 종류는 무궁무진하다.

당신은 자신의 프로그램을 짜며 필요할 때마다 이들 라이브러리의 기능을 호출해 사용한다.

프레임워크는 당신의 코드가 동작하는 규칙과 틀(프레임)을 규정해준다. 즉, 당신의 코드는 프레임워크가 정해준 규칙과 틀에 맞춰 짜여지고 동작한다. 이런 프레임워크의 대표적인 역할은 바로 생명주기 관리다.

비유하자면 이렇다. 아기가 태어나면 출생신고를 해야 한다. 그러면 정부는 그 아이의 일생에 걸쳐 여러 가지를 요청하고 그에 응하지 않으면 제재를 가하기도 한다. 예를 들어 나이가 차면 의무교육인 초등학교에 가게 하고 성인이 되면 주민등록증을 발급해준다. 남자라면 병역 의무도 져야 한다. 돈을 벌거나 공공 인프라(전기/수도 등)를 사용하면 세금을 내야 한다. 마지막으로 생을 마감하면 사망신고를 하고, 정부는 더는 그 사람에게 신경 쓰지 않는다. 여기서 사람은 당신이 작성한 코드, 정부는 프레임워크에 해당한다.

한 가지 더! 정부는 사람들이 공통적으로 많이 쓰는 기능을 직접 준비하고 운영하기도 한다. 철도나 버스 같은 대중교통과 전기와 수도 같은 인프라가 그렇다. 사람들은 자신이 필요할 때마다 이를 이용할 수 있으니, 사람 입장에서는 이는 라이브러리의 개념과 같다. 즉, 프레임워크는 보통 라이브러리를 포함한다.

이상을 이해하기 쉽게 도식화해보면 다음과 같다.

라이브러리_vs_프레임워크

즉,

  1. 당신의 코드 호출하면 라이브러리고
  2. 당신의 코드 호출하면 프레임워크이며
  3. 프레임워크는 라이브러리를 포함한다.
[참관노트] UXCampSeoul 2014
Mar 31st, 2014 by Wegra Lee

주제: UXCampSeoul. 5th (Behind The Curtain)
일시: 2014/03/15

  • 행사 소개
  • 진행표
    • 부트캠프
    • 바캠프
  • 0. 시작 전 이모저모

  1. Design Beyond Design, Service Design & Strategy
  2. 생활에서 발견하는 새로운 지식
  3. UX 디자이너를 위한 글쓰기
  4. Space for UX
  5. 빅데이터와 SNS 시대의 소셜 경험 전략
  6. 커뮤니티 디자인이라 쓰고 회기동 안녕마을이라 읽는다
  7. IoT 시대에 임하는 UX 디자이너
  8. 당신의 디자이너를 찾습니다
  9. UX/UI 첫걸음

행사 소개

UXCamp는 UX(User eXperience)관련 전문가, 교육자, 학생 혹은 UX에 관심 있는 모든 사람들이 자유롭게 생각을 공유하는 행사입니다.
UXCamp는 미국, 캐나다, 유럽 등 전 세계에서 수차례 진행되었으며, 국내에서는 ’UXCampSeoul’이란 이름으로 2010년, 2011년 봄과 가을, 2012년 여름에 이어 다섯 번째 행사입니다. (from http://www.uxcamp.co.kr/#section_aboutus)

나머지는 PDF로 대체.. (귀찮음은 혁신의 어머니랄까ㅡㅡ)

[다운로드] [참관] UXCampSeoul 2014_UX캠프_20140315

[참관노트] 사물인터넷과 웨어러블 기술 (IoT & Wearable Technology)
Mar 19th, 2014 by Wegra Lee

주제: 사물인터넷과 웨어러블 기술 (IoT & Wearable Technology)
일시: 2014/03/13
주최: 플랫폼전문가그룹(PAG)
발표자: 최윤석 (오라클 전무, 플랫폼 형태로 나올 수 있는 제품 총괄)
발표자료: coming soon(really?)

용어 설명

사물인터넷(Internet of Things)

갖가지 주변 사물에 네트워크 기능을 추가하여 서로 연계한 서비스를 제공하는 기술이다. 과거 유비쿼터스(Ubiquitous) 컴퓨팅, 퍼베이시브(Pervasive) 컴퓨팅이라 불리던 기술/트랜드의 새로운 이름이라 생각해도 무방하다.

만물인터넷(Internet of Everything)

시스코(Cisco)에서 주창한 용어로, 사물뿐 아니라 동물/인체에까지 사물인터넷 개념을 확장한 것이다. 하지만 원래의 사물인터넷 개념에도 동물/인체가 포함되어 있었기 때문에 시스코의 마테팅용 용어라는 비판이 있다.

웨어러블 기술(Wearable Technology)

IT 기기를 옷처럼 입거나 악세서리처럼 몸에 걸칠 수 있는 형태로 만드는 기술로, 사물인터넷 시대로 가기 위한 주요한 기술 분야 중 하나이다. 현재는 나이키 Fuel Band, 삼성 갤럭시 기어(손목시계), 구글 글래스 등이 대표적이다.

0. 주요 메시지

  • 사물인터넷/웨어러블 시대가 ‘실제로’ 도래하고 있다.
  • 유비쿼터스/퍼베이시브를 외치던 시기엔 기술이 따라오지 못해 열풍이 금세 수그러들었다. 하지만 지금은 다양한 산업 현장에서 센서 네트워크가 적용되고 있고 웨어러블 소비자 제품이 팔리고 있다.
  • 클라우드 컴퓨팅과 동급 혹은 그 이상의 시장 규모로 성장할 것으로 전망된다.
  • 기술적으로는 아두이노와 라즈베리 파이, 센서 및 센서 네트워킹, 빅데이터 분석, 데이터 시각화, 인포그래픽, 보안, UX 등이 밀접하게 연관되어 있으며 사생활 보호와 법적 이슈가 있을 수 있다.

1. 전망

  • PC -> 모바일/타블릿 -> Other 순으로 시장이 변하고 있다. Other는 과연 무엇인가?
  • 클라우드와 동급 혹은 그 이상의 시장 가치로 평가된다.
  • 클라우드 펀딩 순위에서도 상위에 랭크되어 있다.

2. 분야

센서 + connectivity

  • 의학: 원격진료
  • 가정: 홈 오토메이션, 독거노인 보호
  • 도시 관리: 재활용품 수거, 주차, 오염도 측정, 가로등 관리, 전력 사용량 효율화(Smart Grid)
  • 산업: 공장 로봇 유지보수, 작업 환경 모니터링/안전 (Smart Manufactoring)

3. 사례/시도

4. 고려사항

  • 입는(혹은 걸치는) 부위에 따라 사람이 수용하는 정도가 다름(예를 들어 팔목은 괜찮지만 발목에 차는 것은 대부분 싫어함)
  • 법이 늦게 따라감 (구글 글래스 착용 시 교통 법규를 위반할 수도)
  • 수많은 주변 사물 같의 관리/연동 문제
  • 돈이 되는가?
  • 보안 및 사생활 보호

5. 레퍼런스 플랫폼

파라미테 객체
Mar 11th, 2014 by Wegra Lee

(원문) Introduce Parameter Object

Effective Unit Testing의7.3.9절에서 인용한 블로그 글이다.

파라미터 객체란?

항시 같이 몰려다니는 파라미터들이 있다. 그렇다면 이들을 묶는 객체를 만들어 대체하라.

Parameter Object

“파라미터 객체 추출”이라 알려진 리펙토링 기법이다.

메서드 호출이 연쇄적으로 일어난다면?

랄프 존슨(Ralph Johnson)은 리팩토링 책이 제시한 일반적 상황이 잘 이해되지 않는다 하였다. 거기서 말하는 일반적인 상황이란 이렇다. 서로를 호출하는 메서드가 한 뭉터기가 있다. 그리고 이 메서드들은 각각 수많은 파라미터를 가지고 있어서  파라미터 객체 추출 기법으로 리팩토링하고 싶은 상황이다. 하지만 각각에 파라미터 객체 추출을 적용하면 새로운 객체가 너무 많이 생길테니 고민이 된다. 우리는 객체 하나만을 주고받고 싶다.

그렇다면 연쇄적 호출이 시작되는 메서드에만 파라미터 객체를 적용하라. 그다음에 다른 메서드에는 다음의 ‘전체 객체 보존’ 기법을 적용하면 된다.

전체 객체 보존

한 객체에서 복수의 값을 얻은 후, 이를 다른 메서드를 호출할 때 입력 인자로 넘긴다.

그렇다면 차라리 객체를 통체로 넘겨라.

Preserve Whold Object

책리뷰 <폴리글랏 프로그래밍>
Mar 11th, 2014 by Wegra Lee

x9788968480867

폴리글랏(Polyglot)이란 여러 언어를 사용한다는 의미로, 아직 많은 국내 개발자에게 낯선 용어일 것이다. 나도 작년에 <Effective Unit Testing>을 번역하며 처음 접하게 되었는데, 그 책에서는  그루비 같이 자바가 아닌 언어로 자바 애플리케이션용 테스트를 만들면서 폴리글랏 시대라는 말을 사용했다.

다시 본론으로 돌아와,

한때나마 다양한 프로그래밍 언어를 사용할 줄 아는 것을 자랑으로 생각했던 사람으로서, 임백준씨의 <폴리글랏 프로그래밍>이란 책은 참으로 많은 생각을 떠올리게 해주었다.

짤막한 프롤로그에서는 저자의 이런저런 경험과 프로그래밍 언어 역사 중 재미난 이야기들을 빌어 폴리글랏 프로그래밍 시대가 도래했음을, 그리고 현재 대표적인 대세 언어 중 하나인 자바의 시대가 끝나감을 알린다. 아니! 어느 때보다도 호황인 듯한 자바가 죽어간다니!? 현실에만 안주하고 있는 자바 프로그래머는 자칫 자바 언어와 함께 도태될 수 있음을 지적한다.

본론은 크게 세 부분으로 구성된다. 자바, C#, 그리고 스칼라.

혜성처럼(?) 등장하여, 한 시대를 풍미하고 있는 자바! 하지만 노쇠함을 보여주는 증가가 이미 오래전부터 속속 드러나고 있었다. 매력적이던 이 언어는 이제 유행에 뒤처지고 갑갑한 기성세대가 되었다.

자바 때문에 위기감을 느낀 마이크로소프트가 J++ 이후 부랴부랴 내놓은 언어인 C#. 많은 면에서 자바를 모방한 아류 언어로 첫울음을 터뜨린 이 언어는 어느새 자바를 저만치 앞질러버렸다. 지금의 자바는 C#을 따라가기도 바쁘다.

아직 확실한 대세라고 부르기에는 점유율이 매우 초라하지만, 의미 있는 커뮤니티 규모와 성공 스토리를 확보한 함수형 언어 스칼라. 스칼라는 자바의 1/4 수준의 언어 명세만으로 자바 이상의 표현능력을 갖추고, 훨씬 간결한 소스코드로 사람들을 유혹하고 있다. 자바는 스칼라가 제공하는 기능을 일부라도 흉내 내고자 수년째 절치부심이다.

책 전체적으로 자바의 위기와 그렇게 된 재미난 역사적 사실과 철학적인 이야기들, 그리고 자바의 미래를 당장 엿볼 수 있는 다른 언어의 특징이 일관되게 묘사되고 있다. 하지만 저자가 에필로그에서도 밝혔듯, 자바는 낡았으니 다른 언어로 갈아타라는 메시지를 던지고자 하는 것은 아니다.

임백준씨가 말끔히 정리해놓은 문장이 있지만, 내식대로 표현해보자면 이렇다.

자바 세계에서 잠시 눈을 돌리면 새로운 패러다임의, 혹은 훨씬 진보한 (그래서 자바도 흉내 내려 부단히 노력 중인) 언어가 많이 있다. 그러한 언어들을 함께 쓸 줄 아는 프로그래머는 더 생산적이고 유연하여 어떠한 환경에서건 쉽게 적응하고 살아남을 것이다.

개인적으로는 2005년 이후 자바로부터 떠나 지내던 약 5년 동안의 이야기를 많이 들을 수 있어서 즐거웠다.

»  Substance: WordPress   »  Style: Ahren Ahimsa