도서출판 인사이트

Fit, 통합 테스트 프레임워크

두루 — Tue, 23 Feb 2010 14:54:47 +0900

워드 커닝햄과 릭 머그리지의 공동 저작 『Fit for Developing Software』가 『불확실성과 화해하는 프로젝트 추정과 계획』을 번역하신 이병준 님의 수고로 번역되어 발간을 기다리고 있습니다. 번역서 제목은 『Fit, 통합 테스트 프레임워크-Fit 테스트는 소통이다』입니다. 워낙 유명한 책이라 이름에 걸맞은 번역을 하시느라 개인적으로 어려운 상황임에도 불구하고 무척 고생을 많이 하셨습니다. 번역서 제목도 직접 지어주셨습니다. 이 자리를 빌려 깊은 감사의 말씀 전합니다.

Fit 테스트는 소통이다

이 책이 지닌 의의에 대해 데이브 토마스(Dave Thomas)가 명쾌하게 짚어 냈습니다.
“아무리 좋은 접근법을 써도, 사용자가 원하는 소프트웨어와 실제로 만들어진 소프트웨어 사이의 간극은 남아 있다. Fit 덕분에 마침내 그 무한 루프에 마침표를 찍을 수 있게 되었다. Fit은 애자일 개발이라는 퍼즐을 구성하는 중요한 한 조각이다.”

또한 이 책이 가진 고유한 성격에 대해서는 켄트 벡(Kent Beck)의 표현으로 단번에 알 수 있습니다.
“이 책이 가진 고유한 장점은, 고객/테스터/분석가와 프로그래머 사이의 인터페이스를 다루는 방식이다. 그들 모두가 얼마나 효율적인 소통을 갈망하는지 이 책을 통해 배울 수 있을 것이다. Fit이 추구하는 바는 사업 중심적인 팀원을 위한 언어를 창조하는 것이기 때문에 프로그래머만을 위한 것이 아니다. 사업가만을 위한 Fit 책도 역시 말이 되지 않는다. 그 언어를 만드는 과정에 프로그래머가 참여해야 하기 때문이다. 그 모두를 고려한 결과로 만들어진 이 책은, 팀의 소통을 증진한다는 목표를 공유하는 많은 사람들에게 호소력을 가진다.”

Fit 은 소통과 균형 그리고 기민성을 위한 통합 테스트 프레임워크다

흔히 소프트웨어의 가치와 품질을 결정짓는 핵심적인 요소는 각 이해관계자가 소프트웨어에 무엇이 필요한지를 생각하고, 이에 대해 의견을 교환하는 실질적인 과정이 있느냐는 것과 프로그램이 제대로 동작하는지, 그리고 기능이 추가되더라도 계속 그 상태를 유지할 수 있을 것인지 검증하는, 사업적인 관점에서의 자동화된 테스트가 있느냐는 것일 겁니다. 하지만 많은 프로젝트에서 이 작업들을 제대로 수행되지 못하여 사업적 요구사항들을 실제 프로그램으로 바꾸는 단계에서 실패를 맛보곤 합니다.

문제는 시스템과 연관된 사람들이 사업적 요구사항들을 충분히 이해하지 못해서 그럴 수도 있겠고 요구사항을 깊이 있게 성찰할 수 있게 할 만한 명료한 방법이 없기 때문일 수도 있겠습니다. 뭐 한마디로 말한다면 그런 요구에 대해 소통할 방법이 없다는 말도 되겠습니다. 뭐 이러면 소통 부재-> 솔루션 불통-> 품질 저하-> 시스템 장애, 불 보듯 뻔한 일들이 발생하겠죠.

Fit (Framework for Integrated Tests)는 이런 문제들을 해결하기 위해 고안된, 아주 강력한 자동 테스트 프레임워크입니다. 사업적 관점에서 테스트를 수행하는 데 아주 탁월합니다. 테스트를 표현하고 그 결과를 자동으로 점검하기 위해 테이블을 사용하는데, 이걸 사용하면 프로그래밍 경험이 없는 사람들도 테스트를 작성할 수 있기 때문에 시스템의 전반적인 개발 과정을 훨씬 쉽게 이끌어 나갈 수 있습니다. 범용의 열린 프레임워크라서 다양한 형태의 테스트를 표현할 수 있도록 확장도 아주 손쉽습니다.

이쯤에서 저자들이 말하는 Fit 테이블의 가치에 대해 좀 살펴보겠습니다.

1. 소통(Communication): 시스템을 원하는 사람들이 그 요구사항에 대해 구체적으로 토론할 수 있도록 해 준다. 소프트웨어가 당초 목표한 바와 달리 구현되는 일은 생각보다 흔하다. 이는 무엇이 필요하고 무엇이 가능한지에 대한 이해도가 높아지는 대신 애초의 모호한 상태 그대로 남아 있기 때문이다. 피드백을 충분히 받지 못하는 탓에 벌어지는 일이다.

2. 기민성(Agility): 사업적 요구사항 변화에 맞추기 위해 반드시 필요한 소프트웨어 설계 변경 작업을 지원함으로써 소프트웨어의 상태를 항상 바람직하게 유지할 수 있도록 해준다. 자동화된 테스트가 있으면 소프트웨어를 쉽게 변경할 수 있고, 이미 만족된 요구사항이 변경 결과로 깨어지지 않도록 보장하기 용이해진다.

3. 균형(Balance): 문제의 수와 심각성을 감소시키고, 문제를 더 빨리 찾아내고 또한 그 문제가 다시 반복되지 않도록 함으로써, 문제 교정 작업과의 균형을 맞추는 데 더 적은 시간을 쓰도록 해 준다.

소통을 테스트하라!

Fit은 다양한 영역에서 많은 분들에게 의미를 줍니다. 우선 테스터나 관리자에게 의미가 있겠지만 사업가, 사업 분석가, 시스템 분석가에게 더욱 큰 의미가 있습니다. 그밖에 프로그래머, 소프트웨어 아키텍트, 소프트웨어 엔지니어에게도,, 두말하면 잔소리겠죠.

이 책은 강컴, 교보, 예스24, 인터파크에서 (조만간 ^^) 예약 구매 가능합니다.

한 재소자가 보낸 편지

인사이트 — Fri, 19 Feb 2010 09:29:51 +0900

어제 뜻밖의 편지를 받았습니다.

낯선 주소와 이름의 편지가 도착해 있기에, 뭔가 계산서라도 왔나 하고 열어보니 화성 직업훈련 교도소의 한 재소자가 보낸 편지입니다.

편지의 내용은.....

(공개해도 인적사항이 드러나거나 하는 건 아니라 전문을 실었습니다.)

인사이트 담당자님 안녕하십니까?

저는 현재 화성 직업훈련 교도소에서 생활하고 있는 재소자입니다.

비록 한순간의 실수로 죄를 짓고 이렇게 죗값을 치르고 있으나, 머지 않은 사회 복귀를 준비하며 하루하루를 열심히 살아가고 있습니다.

다름이 아니라, 현재 제가 공부하고 있는 분야에 귀 출판사의 도움이 절실하기에 이렇게 펜을 들었습니다.

저는 사회에 있을 때 전산분야에서 일하였기에, 출소 후에도 비슷한 분야에서 전공과 경력을 활용하고자 생각중입니다.

그런 이유로 프로그램 개발에 대해 더욱 깊숙히 학습하고자 하나 책을 구입하려 하여도 책 제목을 몰라 신청하지 못하는 상황에 놓였습니다.

현재 안드로이드 등 모바일 개발 분야로 공부하가자 귀 사의 '프로그래밍 오브젝티브 C 2.0' 등의 책을 보며 학습하는 중이나 더 이상의 책 제목을 구하지 못해 손을 놓고 있는 실정입니다.

안드로이드 등 개발과 관련하여 Java, C#, XML과 관련된 도서류의 목록을 얻고자 하니 도움 주시면 감사하겠습니다.

교도소 내 작업으로 월 4만원 정도의 책을 구매할 돈이 생기기에 월 1~2권을 독파하는 속도로 학습을 계획 중입니다.

부디 잠깐의 시간을 할애해 주시어 이 부족한 자에게 희망을 심어주시길 부탁드립니다.

2010년 2월 8일

000 드림

편지를 읽고 첫 느낌은 (좀 천박하지만) "엥! 요즘은 교도소에서도 컴퓨터를 다룰 수 있나?" 였습니다. 밖에서처럼 전면적인 컴퓨팅 환경까지야 아니겠지만, 개개인이 하기에 따라선 할 수 있는 게 꽤 있나 봅니다.

두 번째로 떠오른 이미지는 영화 '쇼생크 탈출'의 주인공 앤디(팀 로빈스)가 사서가 되어 도서 확충을 위해 각계에 편지를 보내는 장면. ㅎㅎㅎ

셋째는 "와~ 모바일 열풍이 대단하구나. 11척 담장 안에서까지 이런 생각을 할 정도로"

그 다음에야 요청사항에 눈이 갔는데, 이거 어쩌죠. 저흰 모바일 개발과 직접 관련이 있을 만한 책이 별로 없는데....

아이폰 개발 책으로 터칭! 아이폰, 오브젝티브 C가 있으나, 한 권은 있으시고, 안드로이드를 다룬 책은 없지만, 안드로이드가 Java 기반이니 '자바 세상을 덮친 Eclipse(이클립스)' 정도가 바로 떠오르고.... 음..... 이 글을 쓰며 출판사에 널린 저희 책들을 둘레둘레 보는데, 딱 맞다 싶은 책이 없네요. 혹 이 글을 읽는 분 중에 책 리스트를 정리해 주실 분이 계시면(저희 책이 아니더라도), 책 몇 권을 보내드리며 그 리스트를 같이 보내드리면 괜찮겠다 싶네요.

아무튼 징역이 얼마나 남았는지 모르겠지만, 본인 스스로 '죗값'을 치르고 있다고 생각하시고, 복귀를 위해 열심히 준비하고 계신 듯하니, 그 노력에 성과가 있길 바라겠습니다. 복귀 이후 사회에 기여할 수 있는 분으로 다시 자리잡기 위해 더 분발해 주시길 기원하구요.

“띠지, 꼭 해야 하나요”를 고민하며

JOE; — Fri, 12 Feb 2010 15:56:53 +0900

서점에 가면 화려한 문구로 치장한 책들이 눈에 띈다.

대개 책에 띠지를 둘렀다.

재미있어 보이는 책이 보이는데, 양장본이다. 한 번 훑어보려고 책을 펼치니 양장본의 표지와 함께 자꾸 띠지가 벗겨지려 한다.

어차피 읽기 시작하면 버려버릴 띠지를 대체 왜 자꾸 둘러놓는 건가. 두껍기까지 해 가는 길에 버리게 생겼다.

제가 띠지를 보고 받는 느낌은 이렇습니다. 대개 ‘거추장스럽다’에 그칩니다.

자, 난데없이 띠지 얘기를 왜 꺼내느냐...

인사이트에서 새로운 책을 내며 띠지를 두를 일이 생겼는데, 과연 쓸모 있느냐라는 질문이 문득 머릿속을 스쳤기 때문입니다.

앞서 말씀드렸듯이 개인적으로 띠지를 별로 좋아하지 않습니다. 불편함이 가장 큰 이유고, 광고를 목적으로 만들었다는 건 알겠는데, 제게 뭐 그리 큰 광고 효과는 주지 못하기 때문입니다.

띠지를 보면 숫자를 내세우는 문구가 많습니다.

10만부 이상 팔린 스테디셀러!

3주 만에 52쇄라는 경이적인 기록!

그만큼 많은 사람이 읽었다는 뜻이고, 많은 사람이 선택한 책이니 믿고 사라는 얘기일 테지요. 제 입장에서는 ‘많이 팔렸다고 내게도 좋은 책이란 법은 없지’하는 생각을 하게 됩니다. 몇 만 명이 봤든 몇 만 부가 팔렸든, 그런 숫자를 내세우는 홍보문구라면 오히려 종이 낭비에 불과한 것 아닐까 하는 생각도 들고요.

구글에서 ‘띠지’라는 키워드로 검색하면 띠지에 대한 다양한 생각들이 쏟아집니다.

<라이브러리 & 리브로>라는 잡지는 ‘띠지 추방 캠페인’을 벌이기도 합니다.

띠지를 하지 않으면 출판사 입장에서야 제작비도 절감하고, 편잡자 입장에서는 강렬한 띠지 문구를 뽑아야 하는 고생을 하지 않아도 되기는 한데, 또 대다수 출판사에서 그것을 모르는 바는 아닐 텐데, 왜 띠지를 만드는 것일까요.

이런 물음에 이보다 허심탄회하고 솔직한 고백은 없을 것이기에, 북스피어라는 출판사의 블로그의 글을 인용해 봅니다.

** 주의: 다음 공감은 어디까지나 편집자의 개인적인 것임을 밝혀 둡니다.

실은 연말 즈음에 결산을 하며 나름대로 고민해 보았다. 그리고 스스로에게 물었다.

― 대관절 너는 왜 띠지를 하려고 하는가.

갖가지 답변이 머릿속에서 튀어나왔다. 하지만 대부분 진부하기 짝이 없었다. 차마 여기 쓰기도 민망하다. 그 가운데 가장 압권은.

― 그거 말고는 할 게 없으니까.

...였다. 역시, 한심해. 그러니 이 부분에 대해서만큼은 얼마든지 혀를 끌끌 차셔도 무방하다. 나는 솔직히 띠지가 얼마나 독자들의 ‘니이~~~~~~즈(needs)’를 자극하는지 잘 모른다. 구체적인 데이터를 들이대는 사람으로부터 설명도 들었지만, 어쩐지 납득이 잘 되지 않는다. 뭐 개인적으로 띠지가 있는 책을 보면 ‘음, 띠지까지 둘렀으니 뭔가 있어 보이는군’ 하는 감상이 들 때도 있다. 하지만 요새 띠지 안 하는 책이 어딨나. 그런 식으로, 플러서 마이너스를 계산해 총합적으로 따져보면...

― 역시 안 하는 게 남는 게 아닐까.

나는 그렇게 생각한다. 정말이다. 헌데 막상 책을 낼 때만 되면, 띠지를 하지 말아야 할 이유 따윈 까맣게 잊어버린 채 띠지를 해야 할 이유를 사무실 책상 한가득 늘어뜨려 놓고 있는 거다. 왜냐.

― 그거 말고는 할 게 없으니까.

띠지를 만드는 데 드는 비용으로는, 그 어떤 광고도(예컨대 대형 서점의 매대 행사도, 온라인 서점의 배너도, 불특정 독자에게 보내는 대량 메일) 불가능하다. 띠지를 만들 수 있는 제작비 정도로 할 수 있는 ‘책 선전’은, 없다.

신문과 라디오 곳곳에 공격적인 마케팅을 하는 굵직한 출판사들이 아닌 바에야 홍보하는 데 제약이 있는 것이 사실입니다.

비용에는 한계가 있고, 이런 비용을 활용하여 홍보할 만한 수단이 뭐가 있을까를 고민해보면 결국 띠지라는 결론에 도달합니다.

맥락에서 약간 벗어나는 얘기이지만... 얼마 전에 책을 사며 경험한 일을 떠올려 봅니다.

종로 반디앤루니스에 방문했을 때인데, 시간이 남아 각 분야 코너를 돌며 책을 구경하고 있었죠. 소설 코너에 가니 역시나, 여전히 일본 소설이 많더군요.

장르문학 쪽을 기웃거리다 보니 미나토 가나에의 『고백』이라는 소설이 보입니다. 여기에도 띠지가 있더군요. 그런데 띠지 문구가 심상치 않습니다.

내 딸을 죽인 사람은 우리 반에 있습니다

이 강렬한 문구에 저도 모르게 책을 집어 들고 서너 쪽을 읽어보았으며, 덥썩 책을 구입했습니다.

띠지라면 이 정도의 강렬함은 담아야 하겠구나 싶었습니다.

‘띠지, 꼭 해야 하나요’라는 물음에 여러 글도 읽으면서 고민했지만 결국 이렇다 할 확신을 세우지도 못하고, 마땅한 대안을 발견하기는 어렵다는 사실만 새삼 깨달은 것 같습니다.

그래도, 굳이 띠지를 할 양이면 종이 아깝지 않게, 독자의 불편함을 좋은 방향으로 바꾸려면, 진정 눈과 마음을 확~ 끌어당기는 좋은 띠지 문구를 고안하는 것이 바로 편집자의 최선이겠다는 생각을 해봅니다.

2010년도 벌써 2월의 중순입니다.

1월의 계획이 잘 지켜지지 않았다 하시는 분들은 구정을 새해로 여기시고 심신을 가다듬어 새롭게 하려던 바를 이어나가시기 바랍니다.

명절 잘 보내시고, 새해 복 많이 받으시길... : )

사용자 경험 스케치 함 해보시죠.

두루 — Tue, 09 Feb 2010 18:25:30 +0900

Bill Buxton이 쓴 <Sketching User Experience>의 번역서를 준비하고 있습니다. 원서로는 사용자 경험 업계(?)에서 너무나 유명한 책이어서 사뭇 소개한다는 게 좀 뭐하지만, 혹시라도 번역서를 기다리시는 분들이 계실지 몰라 맛보기로 한두 꼭지 소개하려 합니다.

이 책의 구성은, 1부는 비교적 이론적인 거, 2부는 비교적 실용적인 거를 다룹니다.

아무래도 이 블로그를 보시는 분들이야 이론보다는 실용적인 거를 보고 싶어하시지 않을까 합니다만 1부와 2부에서 비교적 길지 않은 거루 한 꼭지씩 올려보도록 하겠습니다.

이번에 올릴 원서의 꼭지 제목은 <Sketches are not Prototypes>입니다. 아시는 분들이야 뭐 당연한 거 아냐? 하실지 몰라도 비교적 짧은 글이지만 Bill의 내공이 묻어 나는 거 같아 올려봅니다. 함 보시죠.

스케치는 프로토타입이 아니다

연습만큼 훌륭한 선생님은 없다.

-퍼블리어스 사이러스

인터랙션 디자인에서의 스케치란 무엇인지 간단히 살펴봤다. 그렇다면 다음과 같은 의문점이 남는다. “인터랙션 디자인에서 스케치란 프로토타입과 동일한 것인가? 저 수준low-fidelity 프로토타입과 같은 것인가?” 그 답은 “아니다!”이다. 스케치와 프로토타입의 차이는 너무 명확하다. 적어도 내게는 그렇다.

디자인 콘셉트를 탐색할 때 스케치와 프로토타입 어느 쪽도 활용할 수 있다. 하지만 스케치와 프로토타입을 제작하는 목적은 서로 다르다. 두 방법은 디자인 프로세스의 다른 단계에서 적용된다. 스케치는 초기 아이디어를 탐색할 때 사용한다. 반면 프로토타입은 주로 후반부에 활용하게 된다.

디자인 콘셉트가 좁혀지고 명확해지는 단계에서 프로토타입을 제작한다. 스케치와 프로토타입은 비용과 시기, 제작 분량 등 여러 요소에서 차이가 있기 때문이다. 그 결과물을 얼마나 쉽게 폐기할 수 있는지도 달라진다.

프로토타입은 스케치보다 제작하는데 더 많은 시간과 노력이 요구된다. 그만큼 적은 수의 프로토타입을 제작하게 되고, 그 결과물을 쉽게 버릴 수 없다. 한 번 제작하는데 시간이 오래 걸리기 때문이다.

디자인 프로세스의 초반부에는 여러 콘셉트를 탐색해야 한다. 아이디어는 아직 명확하지 않은 경우가 많다. 이때는 스케치가 적절한 방법이다.

그림 51: 시간 흐름에 따른 디자인 깔때기의 역동성

위의 내용은 그림 51에 잘 나타나 있다. 사용자 중심의 프로세스에서는 각 단계가 반복적으로 이뤄진다. 둥근 화살표가 이를 보여주고 있다. 초기 단계에는 스케치를 중점적으로 진행하다가 후반부에는 프로토타입으로 이동하게 된다. 색상 변화가 이 점을 잘 나타내고 있다. 또한 그래프의 색상은 아이디어를 창출하는 단계에서 사용성 테스트로 옮겨가는 과정을 보여준다.

관리자의 관점에서 그림 51을 살펴보자. 가장 중요한 요소는 위로 상승하는 붉은 화살표일 것이다. 이 화살표는 디자인 콘셉트와 아이디어를 판단하는 평가 기준을 의미한다. 각 아이디어에 들어가는 시간과 노력에 따라 콘셉트를 선택하거나 폐기하는 기준이 달라진다.

프로세스의 초기 단계에는 콘셉트를 설정하는 비용이 매우 저렴하다. 쉽게 얻은 만큼 쉽게 폐기할 수 있다. 아이디어의 개수가 많을수록 좋다. 하지만 시간이 지날수록 콘셉트 하나에 들어가는 노력은 점점 커진다.

각 아이디어를 평가하는데 좀 더 명확하고 구체적인 기준이 요구된다. 어떤 아이디어를 선택하고 어떤 콘셉트를 폐기할 것인지, 어디에 좀 더 시간과 노력을 투자할 것인지 신중히 결정해야 한다.

프로세스의 초기 단계에는 제품에 들어가는 투자비용이 적다. 이때야 말로 여러 가지 아이디어를 탐색하고, 새로운 내용을 배우고, 즐겁게 놀아볼 수 있는 단계다. 여러 콘셉트를 시도해보고 제품에 대해서 깊이 이해할 수 있다.

처음부터 완성 제품의 세부사항에 대해 고민하는 것은 오히려 부정적인 효과를 가져온다. 빌 브랜든이 블로그에 쓴 글을 살펴보자. 이 글은 여기서 이야기하고자 하는 요점을 명확하게 전달한다.

스케치 프로토타입

아이디어를 자극하는 디자인을 결정짓는

제안하는 설명하는

탐색하는 수정하는

질문하는 답변하는

시도하는 점검하는

선동하는 해결하는

추상적인 구체적인

애매한 묘사하는

그림 52. 스케치와 프로토타입 비교

스케치와 프로토타입에는 여러 가지 차이점이 있다. 위 그림은 스케치와 프로토타입을 제작하는 목적과 의도를 잘 보여준다. 이는 스케치에서 프로토타입으로 변화하는 과정이다. 가운데 화살표는 이 과정이 연속적이라는 것을 나타낸다. 명확히 흑과 백으로 구분되는 개념이 아니다.

도자기 제작 수업의 첫 날이었다. 교사는 학생을 두 그룹으로 나눴다. 교실 왼쪽에 앉아 있는 학생들은 오로지 양으로만 성적을 매길 것이고, 교실 오른쪽 학생들은 오로지 질로만 성적을 매길 것이라고 말했다. 성적을 매기는 방법은 아주 간단했다.

'양'으로 승부를 매기는 그룹은 학기말에 그 동안 만든 도자기의 무게를 재는 것이다. 도자기 무게의 합이 25킬로그램을 넘으면 'A', 20킬로그램을 넘으면 'B'를 받는 식이다. 반면 '질'로 승부를 내는 그룹은 완벽하게 만든 도자기 하나만 제출하면 됐다.

그런데 학기말에 재미있는 일이 발생했다. 가장 훌륭하게 만들어진 질 좋은 도자기는 '양'으로 성적을 받는 그룹에서 나온 것이다. '양'으로 승부를 내는 그룹은 수많은 도자기를 만들어 내느라 정신이 없었다. 많은 도자기를 만드는 동안 실수를 거듭하며 결국 훌륭한 도자기를 만드는 법을 배운 것이다.

반면 '질'로 승부를 내는 그룹은 책상에 앉아 완벽한 도자기를 만드는 이론을 터득하는 데 시간을 쏟았다. 하지만 굉장한 이론에도 불구하고 엉터리 도자기 밖에는 보여줄 수 없었다.

백스터는 디자인 프로세스의 초기 단계야 말로 투자 대비 기대효과가 높은 때라고 설명했다. 초기 단계에는 투자에 들어가는 비용과 노력이 적고, 여러 가지 가능성을 탐색해 볼 수 있는 선택의 여지가 많기 때문이다.

물론 이것은 양날의 칼과도 같다. 잘못된 결정을 눈치채지 못하고 통과시키거나, 중요한 기회를 놓쳐버리면 그 만큼 나중에 돌아오는 손실도 크기 때문이다(이런 손해는 실제 수익과 직접 연결된다). 이른 단계에 여러 번 실패해야만 더 큰 손실을 막을 수 있다.

매도 먼저 맞는 것이 낫다는 옛말을 기억하자.

하지만 초기 단계에 적절한 투자와 실험을 시도하는 회사는 많지 않다. 특히 소프트웨어 회사의 경우는 더욱 그렇다. 보통 이런 회사는 초기 단계에 디자인에 투자할 만한 자본과 여유가 없다고 주장하는 경우가 많다.

하지만 아이러니 하게도 나중에 가서 잘못된 디자인을 수정하느라 발생하는 엄청난 비용은 잘도 지불하곤 한다. 디자인은 엉망이고 출시일도 늦어지기 마련이다. 이런 비용은 처음 사업 계획에는 전혀 책정되지 않았던 것이다. 하지만 초기 단계에 제대로 디자인을 거치지 않았다면 당연한 결과다.

디자인 연구 없이 바로 제품 개발에 착수하는 것은 위험하다. 결국 제품을 어떻게든 완성하고 판매하게 되더라도 고만고만한 제품밖에는 만들 수 없다. 기존의 제품과 차별화된 혁신은 꿈도 꿀 수 없다. 다양한 가능성을 탐색해보지 않고 바로 최종 제품을 만든다고 생각해보자. 결과는 불을 보듯 뻔하다.

기회가 단 한 번밖에 없다면 이미 알고 있는 것을 시도할 수밖에 없다. 위험을 감수하려고 하지도 않고 다양한 가능성을 탐색하지도 않는다. 기존에 익숙한 것에서 다른 혁신을 꾀하려고 하지 않는다.

로버트 쿠퍼는 제품을 개발하는 데 다양한 가능성을 탐색하는 과정을 포커게임과 비교한 바 있다. 쿠퍼는 이 과정이 주식을 투자할 때 위험을 감수하는 것과도 유사하다고 말했다. 마이크 백스터는 도박의 법칙을 다음과 같이 설명했다.

모든 것이 불확실할 때에는 판돈을 낮게 걸어야 한다. 하지만 상황이 조금씩 분명해지면, 투자도 크게 해야 한다.

14장에서는 디자인 프로세스의 초반부와 후반부에 아이디어와 콘셉트를 다루는 태도가 달라야 한다는 점을 살펴봤다. 큰 그림에서 바라볼 때(디자인, 개발, 영업 등 전반적인 제품 개발 프로세스를 생각할 때)나 작게 생각할 때(디자인을 고민할 때)에 모두 해당하는 말이다. 디자인 측면에서는 초기 단계에 아이디어를 구상하고 스케치를 하는 과정과 후반부에 프로토타입을 제작하는 과정이 전혀 달라야 한다.

XCode의 화면과 책의 내용이 다르다구요?

너굴; — Tue, 26 Jan 2010 16:53:04 +0900

『터칭! 아이폰 SDK 3.0』과 『프로그래밍 오브젝티브 C 2.0』을 독자들께서 많이 찾아주시다보니, 책에 대한 불만 사항도 그 어느 때보다 많이 접하고 있습니다.

그 중에 가장 자주 접하는 내용은 바로, XCode의 화면과 책의 설명이 다르다는 것입니다.

책이 나올 당시, 그러니까 2009년 7월(터칭) 혹은 9월(오브젝티브)까지의 최신 버전으로 작업했음에도 불구하고, 이후 XCode의 버전이 올라가면서 몇몇 화면들의 구성이 바뀌었기 때문인데요.

『터칭! 아이폰 SDK 3.0』의 2장에서는 인스펙터 창의 위치가 바뀐 것 때문에 많이들 어려움을 겪으셨습니다. 아래는 예전 인스펙터 창입니다. Identity 창의 인스펙터 탭에서 액션을 설정했었죠.

다음은 3.1.2의 인스펙터 창입니다. iPhoneRefViewController를 선택 후, Library 창의 Classes 탭에 보면 Actions 항목이 나타납니다.

출처: 『터칭! 아이폰 SDK 3.0』의 저자이신 강덕진 님께서 블로그에 올리신 글 - http://maclove.pe.kr/36

『프로그래밍 오브젝티브 C 2.0』에서도 비슷하게 바뀐 내용이 있습니다. 13쪽에서는 새 프로젝트를 시작할 때 나타나는 화면에서 Command Line Utility를 선택하면(아래 그림), 오른쪽 구획에 Foundation Tool이 나타나야 하는데요(아래아래 그림).

새 버전에서는 아래와 같이 바뀌었습니다. 왼쪽 구획에서 Application을 선택한 다음 오른쪽 구획의 Command Line Tool을 선택합니다. (아래 그림)

그 다음에 아래와 같은 그림이 나타나면 Type을 Foundation으로 지정하고 Choose 버튼을 눌러서 새 프로젝트를 시작합니다.

비슷하면서도 다른 부분 때문에, 프로그래밍에 처음 도전하거나 익숙치 않은 분들께 불편을 끼쳐드렸습니다. 이 내용들은 모두 재쇄를 찍으면서 수정이 되거나, 관련 사항을 책에 표시했구요.

책이라는 매체가 고정성이 강하다보니, 미리 구입하신 독자들께 수정된 내용을 알리기가 참 쉽지 않습니다.

해서, 스프링노트에서 정오표(터칭! 아이폰, 오브젝티브 C)를 관리하고, 저,역자의 블로그에서 해당 내용을 공지해보기도 하지만, 독자들께서 검색할 때 찾아진다는 보장도 없구요. ㅠㅠ

그래도 최선을 다해서, 잘못된 정보를 바로 잡고 또 널리 알리는 인사이트가 되겠습니다. 사랑과 관심이 담긴 따뜻한 지적 부탁드립니다. ^^

네트워크 없는 세상에서도 살아남는 Git

너굴; — Fri, 22 Jan 2010 20:26:27 +0900

요즘은 네트워크 없는 세상을 상상하기가 참 힘들어졌습니다. 광대역 통신망을 넘어 무선으로도 네트워크에 항상 연결되는 세상이니까 말입니다.

그렇지만 여전히 네트워크에 접속하기 힘든 상황도 존재합니다. 지하철이나 기차, 비행기, 크루즈 여행 등에서는 아무래도 제약이 따르겠죠. 하지만 열정적인 개발자들은 이런 상황에서도 키보드를 붙들고 버그와 씨름을 합니다.

이런 상황에서 코드를 수정하다 보면 가끔씩은, 이전 리비전으로 되돌리고 싶어지는데 네트워크에 접속되지 않기 때문에 되돌릴 방법이 없기도 합니다. 아니, 수정된 코드를 안전하게 저장할 방법이 없다고 해야겠습니다.

이런 문제와 함께 기존의 버전 관리 시스템에서 지적되던 단점들을 보완한 버전 관리 시스템을 소개합니다. 리눅스의 개발자로 널리 알려진 리누스 토르발스(Linus Torvalds)가 개발했다고 해서 유명세를 타기도 한 Git은, 빠른 속도와 분산형이라는 장점을 들고 개발자들 앞에 섰습니다. 또, 기본 시스템들에서 번거롭기 짝이 없던 브랜치 생성과 합치기(merge) 방법이 아주 쉽고 간단해졌습니다.

그리고, 이렇게 매력적인 Git의 사용법을 배울 수 있는 책도 나왔습니다. ^^

『Git, 분산 버전 관리 시스템』

제목은 좀 딱딱하지만, 내용은 아주 말랑말랑하답니다. 먼저, 개인 컴퓨터에 Git을 설치합니다. 복잡한 설정은 거의 필요없구요. 그 다음에 간단한 HTML 파일을 하나 만들고, Git에게 관리하라고 명령합니다. 파일을 조금씩 수정하면서 Git에게도 해당 사항을 알려줍니다. 파일에 태그도 붙여보고, 브랜치(branch)도 만들어봅니다.

만들다 보니 다른 이들과 공유할만한 프로젝트가 되었다면, 이때 네트워크 상의 저장소(repository)를 추가한 후 푸싱(pushing)과 풀링(pull) 기능으로 코드를 공유합니다.

이렇게 조금씩 기능들을 배우다보면 어느새 Git에 능숙해진 스스로를 발견하실 수 있을 겁니다.

혹시 지금 개발 중인 프로젝트에 Git을 도입하고 싶은데, 버전 관리 시스템을 통째로 바꾸는 모험은 원하지 않는 분들을 위해서, 기존 시스템을 유지하면서도 Git을 사용하는 방법도 알려드립니다.

게다가 무료로 사용할 수 있는 Git 서버인 GitHub와 이클립스용 Git 플러그인인 EGit의 사용법을 한국어판에만 특별히! 넣어두었습니다.

Git과 함께라면, 노트북을 들고 무선 공유기 신호를 찾아 이 카페 저 카페를 헤메지 않으셔도 된답니다. ^^

『프로그래밍 jQuery』를 번역하시고 증보판 내용까지 작성하셨던 김성안 님, 이두원 님께서, 이번에도 번역과 함께 부록을 집필해 주셨습니다. GitHub가 영문 서비스라서 어려우셨던 분들, 이클립스에서 Git을 사용하고팠던 분들께 도움이 되리라 생각합니다. ^^

구글 앱 엔진은 클라우드 컴퓨팅의 미래다?

JOE; — Wed, 20 Jan 2010 17:53:10 +0900

클라우드가 수면으로 떠올라 주목받은 지도 벌써 5년여가 되었고, 클라우드 컴퓨팅은 IT 세상을 움직이는 차세대 기술로 인정받고 있습니다.

명실상부한 클라우드 컴퓨팅 서비스 1인자 아마존을 비롯해 2009년에는 구글에서 구글 앱 엔진을 발표했고, MS, Sun, IBM 등 줄줄이 클라우드 컴퓨팅에 뛰어들고 있으니 앞으로 치열한 경쟁이 벌어질 것으로 예상되기도 합니다. 또한 각 서비스가 어떤 특징과 강점을 들고 나올지도 기대가 되구요.

2009년 4월 구글이 구글 애플리케이션 엔진(Google Application Engine, 이하 구글 앱 엔진)이라는 이름으로 클라우드 컴퓨팅 환경을 발표한 이후, 구글 앱 엔진이 과연 아마존을 뛰어 넘는 서비스가 될 수 있을까에 대해 의견이 분분합니다.

(현재 구글의 문서에는 영문표기(Google App Engine)와 ‘구글 애플리케이션 엔진’이 혼용되고 있습니다. 『구글 앱 엔진 시작하기: 파이썬과 자바로 함께 배우는』(근간)에서는 구글 애플리케이션 엔진으로 썼는데, 이는 구글의 한국 번역 문서의 표기를 따른 것입니다.)

더불어 이 두 서비스의 장단점, 다른 점을 비교한 자료도 심심찮게 발견할 수 있습니다.

아마존과 구글이 제공하는 Paas 솔루션(2008.4)

애플리케이션에 적합한 클라우드 플랫폼 선택하기(IBM DeveloperWorks에서)

아마존과 구글이 지원하는 자원량 비교

같은 선상에 놓고 비교하기보다는 프로젝트나 애플리케이션의 특성에 따라 선택을 하여야 할 것 같습니다. 클라우드 컴퓨팅은 개발자들이 기능 구현에만 집중하도록 도와주는 도우미가 아니라, 구현하고자 하는 애플리케이션의 컴포넌트입니다. 한번 도입하면 써도 되고, 안 써도 되는 게 아니라 미우나 고우나 애플리케이션의 생명주기 동안 벗어날 수 없는 플랫폼입니다. 그래서 애플리케이션의 요구사항에 맞는 클라우드 컴퓨팅 서비스를 선택해서 프로젝트 조직과 프로세스에 안착시키는 것이 관건입니다. 마치 개발언어나 웹 애플리케이션 프레임워크를 선택하는 것처럼 말이죠.

이쯤에서 이런 의문이 들기도 합니다.

그러면 왜 굳이 구글 애플리케이션 엔진에 관심을 가져야 할까?

이에 대해 『구글 앱 엔진 시작하기: 파이썬과 자바로 함께 배우는』(근간)의 저자 박상엽 님은 프로젝트의 고충을 덜어주는 역할로서의 구글 앱 엔진을 소개하는 동시에 개발자가 기능 구현에만 집중할 수 있도록 해 준다는 큰 장점이 있지만, 아무리 좋다 하더라도 구글 앱 엔진 역시 도구일 뿐임을 기억하라는 글을 써 주셨습니다.

웹 서비스의 개발과 운영은 그 서비스가 어떤 형태를 띠고 있든, 결국 하나의 경영활동이라 믿습니다. 프로젝트의 상황과 요소들은 완벽하지 않아서 선택과 포기를 반복할 수밖에 없습니다.

구글 애플리케이션 엔진은 계정 신청을 하고 바로 기능개발을 하면 됩니다. 가용성과 확장성을 보장하고자 복잡한 네트워크나 백업 시스템을 설계할 필요 없이 서비스로 사용하면 됩니다. 대신 구글 애플리케이션 엔진을 이용하면 시스템과 네트워크, 그리고 분산처리에 관한 기술은 쌓을 수 없습니다. 프레임워크, 패턴 활용도 제약을 받습니다. 하지만 그만큼 서비스에 더 집중할 수 있습니다.

구글 애플리케이션 엔진은 PaaS 서비스를 계획하는 사람에게는 영감과 벤치마크 사이트를, 웹 서비스를 준비하는 조직에게는 든든한 기댈 곳이 될 것입니다. 머릿속을 맴도는 아이디어와 현실 사이에서 밤잠 이루지 못하는 학생들에게도 구글 애플리케이션 엔진은 여러분이 꿈을 펼칠 수 있는 좋은 기회를 줄 겁니다. 바라건대 구글 애플리케이션 엔진이라는 기술에 매달리지 말고, 그 주위와 이면의 현상들을 같이 살펴봐 주기 바랍니다. 이 책이 여러분의 꿈을 이루는 작은 디딤돌이 되었으면 좋겠습니다.

조만간 구글 앱 엔진을 다룬 국내 최초의 책이 발간됩니다. 이미 해외엔 구글 앱 엔진을 다룬 책이 몇 권(1, 2, 3) 발간되어 있습니다만, 저희가 이번에 발간할 책은 집필서입니다. 자바/파이썬을 동시에 설명하고 있죠.

일단 표지만 살짝 공개해 봅니다. 조만간 발간 소식으로 다시 뵙겠습니다.

목차를 보시려면 more를 클릭하세요.

1장 구글 애플리케이션 엔진

1.1 클라우드 컴퓨팅

1.2 클라우드 컴퓨팅의 장점과 단점

1.2.1 구글 애플리케이션 엔진이란

1.2.2 구글 애플리케이션 엔진의 목적

1.2.3 구글 애플리케이션 엔진을 이용하는 사이트

1.2.4 로드맵

1.3 요약

2장 Hello, World

2.1 윈도 사용자를 위한 개발 환경 구축하기

2.1.1 JRE와 이클립스 설치하기

2.1.2 윈도 사용자를 위한 파이썬 개발 환경 구축하기

2.1.3 윈도 사용자를 위한 자바 개발 환경 구축하기

2.2 리눅스 사용자를 위한 개발 환경 구축하기

2.2.1 JRE와 이클립스 설치하기

2.2.2 리눅스 사용자를 위한 파이썬 개발 환경 구축하기

2.2.3 리눅스 사용자를 위한 자바 개발 환경 구축하기

2.3 맥 OS X 사용자를 위한 개발 환경 구축하기

2.3.1 JRE와 이클립스 설치하기

2.3.2 맥 OS X 사용자를 위한 파이썬 개발 환경 구축하기

2.3.3 맥 OS X 사용자를 위한 자바 개발 환경 구축하기

2.4 Hello, World

2.4.1 파이썬 버전

2.4.2 자바 버전

2.5 요약

3장 검토 사항

3.1 웹 서비스 구현 이야기

3.1.1 도입

3.1.2 성장

3.1.3 성숙

3.1.4 쇠퇴

3.2 구글 애플리케이션 엔진의 구조와 기능

3.2.1 아키텍처

3.2.2 제약 사항

3.3 요약

4장 프로젝트 준비

4.1 형상 관리와 프로젝트 자동화

4.1.1 서브버전 저장소 생성

4.1.2 이클립스 서브버전 클라이언트 플러그인

4.1.3 저장소 체크아웃

4.1.4 프로젝트 자동화

4.2 예제 프로젝트

4.2.1 소개

4.2.2 시스템 자원 사용량 예측

4.3 설계

4.3.1 자바스크립트 - 구글 AJAX 라이브러리 API 활용

4.3.2 템플릿

4.3.3 URL

4.4 스켈레톤 만들기

4.4.1 파이썬

4.4.2 자바

4.5 요약

5장 테스트와 프로파일링

5.1 테스트

5.1.1 파이썬 버전

5.1.2 자바 버전

5.1.3 자바스크립트 버전

5.2 프로파일링

5.2.1 파이썬 버전

5.2.2 자바 버전

5.3 요약

6장 데이터스토어

6.1 파이썬 버전

6.1.1 저장

6.1.2 쿼리

6.1.3 수정

6.1.4 삭제

6.1.5 엔티티와 모델

6.2 자바 버전

6.2.1 저장

6.2.2 쿼리

6.2.3 수정

6.2.4 삭제

6.2.5 엔티티와 모델

6.3 인덱스

6.4 요약

7장 Coffee Shop 기본 기능

7.1 첫 화면

7.1.1 파이썬 버전

7.1.2 자바 버전

7.2 로그인과 사용자 정보 관리

7.2.1 파이썬 버전

7.2.2 자바 버전

7.3 커피숍 정보 등록

7.3.1 파이썬 버전

7.3.2 자바 버전

7.4 커피숍 정보 보기

7.4.1 파이썬 버전

7.4.2 자바 버전

7.5 커피숍 정보 수정

7.5.1 파이썬 버전

7.5.2 자바 버전

7.6 커피숍 정보 삭제

7.6.1 파이썬 버전

7.6.2 자바 버전

7.7 요약

8장 Coffee Shop 추가 기능

8.1 국제화(i18n)

8.1.1 파이썬 버전

8.1.2 자바 버전

8.2 오픈 API 만들기

8.2.1 파이썬 버전

8.2.2 자바 버전

8.3 Feed 만들기

8.3.1 파이썬 버전

8.3.2 자바 버전

8.4 URL 요청 서비스

8.4.1 파이썬 버전

8.4.2 자바 버전

8.5 memcache

8.5.1 파이썬 버전

8.5.2 자바 버전

8.6 이메일 서비스

8.6.1 파이썬 버전

8.6.2 자바 버전

8.7 스케줄 작업

8.7.1 파이썬 버전

8.7.2 자바 버전

8.8 요약

9장 릴리스와 운영

9.1 릴리스

9.1.1 파이썬 버전

9.1.2 자바 버전

9.2 데이터 업로드와 다운로드

9.3 관리자 콘솔

9.4 구글 Analytics

9.5 요약

부록A 파이썬과 자바

A.1 파이썬

A.1.1 자료구조형 클래스

A.1.2 모듈

A.2 파이썬 웹 프레임워크 - 장고

10.2.1 장고 템플릿 문법

A.3 자바

10.3.1 자료구조형 클래스

A.4 자바빈즈, JSP 그리고 JSTL

A.4.1 자바빈즈

A.4.2 JSP와 자바빈즈

A.4.3 JSTL

A.5 요약

부록B 자주 묻는 질문들

참고문헌

찾아보기

“세월을 견디는 디자인을 꿈꾼다” - 디자이너 오필민

너굴; — Mon, 04 Jan 2010 15:03:57 +0900

2006년 이후 인사이트 책 표지를 대부분 디자인 해주시는 오필민 님께서 시사in이 선정한 올해(2009년)의 북디자이너로 선정되었습니다.

수상 소식을 들은 인사이트 식구들의 질문과 오필민 님의 답변

너무 상을 독점하는 거 아닌가? 이젠 후배도 많은데~

-> 어쩌라구. 편집자들이 뽑은 건데.

올해 최고의 북디자이너 선정방식은 대표적인 출판사들의 편집자(장)들에게 추천을 의뢰하고, 다수의 표를 얻은 디자이너가 뽑히는 방식입니다. 편집자들은 "텍스트에 대한 이해 능력이 탁월하다"며 추천을 했구요. 오필민 님은 이미 2007년 출판인회의가 선정한 올해의 디자이너, 2006년 시사저널 선정 ‘가장 주목할 만한 북 디자이너’에 뽑히기도 하셨죠.

상금은 얼마나 돼~~?

그걸 왜. 얼마면 어때서.

어디에 쓸 건데~~?

술이나 먹지

술자리에 껴줄 거지?

인사이트를 왜? ^%$#@^&%*&^%$$%&^&#^&*

실없는 농담이 오갔고, 기어이 술은 얻어먹지 못했습니다. ㅠㅠ

2009년 겨울 홍대 앞 그 어드멘가에서 인사이트 식구들과 폴라로이드로 찍은 사진

사실 오필민 님이 인사이트의 표지를 만들어 주고 계시지만, 아주 일부일 뿐이고 대표작은 다른 분야입니다. 시사in의 글에는 최근 화제작으로 <<나쁜 사마리아인들>> <<괴물의 탄생>> <<대한민국 소통법>> <<경계긋기의 어려움>> <<기다림의 망각>> 등을 거론하며 인문사회과학 서적 디자인에서 출발해 문학, 에세이로 영역을 확장 중이라고 소개하고 있죠.

꽤 오래된 기억이긴 하지만 오필민 님의 디자인을 보면서 아하! 하고 느꼈던 책을 소개하라면 <<반짝이는 박수소리>>를 들 수 있습니다. 조그만 웹 화면으론, 눈에 띄지 않는 회색의 작은 제목, 곳곳에 박힌 눈에 거슬리는 티눈이 보이겠지만, 막상 책을 손에 쥐면 반짝임과 손의 떨림이 ‘손으로 말하고 슬퍼하고 사랑하는 사람들의 이야기’라는 부제와 더불어 울림으로 다가옵니다.

언젠가 오필민 님께 이런 질문을 한 적이 있습니다.

수없이 많은 표지 디자인을 내놓으면서도 그런 수준을 유지하는 게 놀랍다. 끊임없이 샘솟는 아이디어와 발상의 근원은 어딧다고 생각하나?

당시 들은 답은 대략....

젊은 시절 습작 시. 무수히 많이 쓴 습작 시, 그게 감성의 원천이 되는 거 같다.

앞으로 장하준, 우석훈, 고종석, 강준만. 이름만 들으면 바로 알 수 있는 저자들의 저작물들, 부키, 시대의 창, 개마고원, 지호 등등 대표적인 인문사회과학 출판사들의 출판물을 구입하신 후 표지에 남다른 포스가 느껴진다면, 표지를 살짝 넘겨 책날개 밑쪽을 보세요. 누구의 이름이 기록되어 있는지.

ps1. 두루 님이 말하길, 오필민 님과의 술자리에서 인터뷰 기사에 인사이트 책을 올리시겠다고 말씀하셨다고 했는데, 결과적으로 올라가지 않은 걸 보니,,,, ㅉㅉ....두루 님의 알콜성 치매 증상이 이제 위험 수위에 다다랐다는,,, 되돌릴 수 없는 사실이 입증되었다는...

ps2. 오필민 님이 디자인한 인사이트의 표지 중 3권엔 2종류의 ‘오필민’이 아닌 다른 이름이 적혀 있습니다. 그걸 찾아 어떤 의미인지 가장 재미있게 해석해 준 분께 2010년 인사이트에서 발간할 책 5권을 선택해 받을 권리를 드리겠습니다. 기한은 1월 11일 오전 10시까지.

큰 이미지를 다시 올립니다. 실제 책은 제목과 바탕의 영문 글꼴에 은박이 되어 있고, 펄(pearl) 종이를 썼기에 반짝임이 있으나, 무광코팅으로 눅여 화려함을 죽였고, 꺼끌한 (시각적) 질감까지 느낄 수 있습니다.

오브젝티브 C 2.0 서평 이벤트 당첨자 발표!

너굴; — Thu, 24 Dec 2009 17:39:14 +0900

아이폰이 나오자마자 시작했던 오브젝티브-C 서평 달고 아이폰 받기 이벤트가 드디어 마감되었습니다.

여러분께서 자세하면서도 날카로운 서평을 올려주셨는데요. 이 자리를 빌어 서평을 올려주신 모든 분께 감사하다는 말씀 드립니다. 서평에 적어주신 내용들 덕에 『프로그래밍 오브젝티브 C 2.0』의 어떤 점이 잘 되었고 어떤 점이 부족한지 잘 파악할 수 있었습니다. (저희가 이벤트를 진행하면서 내세운 목적이기도 하지요. ^^)

아래는 저희가 파악한 『프로그래밍 오브젝티브 C 2.0』의 장, 단점입니다.

장점

기본서답게 오브젝티브 C의 기초를 탄탄하게 닦아준다.
번역문이 잘 읽힌다.
간단하지만 '아이폰 애플리케이션'을 만들 수 있다.

단점

다른 언어로 개발해본 사람에겐 불필요해보이는 내용이 많다. (설명이 지나치게 자세하다)
부록 '아이폰 애플리케이션 만들기'는 굳이 없어도 되었을 듯.
인덱스 상호 참조에 틀린 부분이 있다.
번역문이 단조로워 술술 읽히지 않는다.
처음 등장하는 용어에 대한 설명이 있었으면...

부록으로 실린 '아이폰 애플리케이션 만들기'는 장점으로도, 단점으로도 꼽혔구요. 기초적인 내용이 많은 점 역시 장점과 단점으로 모두 꼽혔습니다. ^^ 번역 문장의 호오는 개인차가 있는 편이라 결론을 내리기 어렵네요.

이제 뜸은 그만 들이고 당첨자를 발표해야겠죠? 추첨 대상은 저희 블로그에 댓글과 트랙백을 남겨주신 모든 분입니다. 원고 마감은 칼같이 해야겠지만, 시간을 조금 넘겼다고 해서 응모자를 칼같이 잘라내기란 마음이 아파서... ㅎㅎ

그럼 발표하죠. 아이폰을 받을 1위 수상자는... 두두두두두두...

아이폰은... 개발자 수준별로 장단점을 적어주신 simpurie 님께 돌아갔습니다. 축하합니다~~~ 자세한 지원금 수령 방법은 저희 쪽으로 메일(insight 골뱅이 insightbook 쩜 co 쩜 kr) 주세요. ^^
(매번 동영상을 넣다보니 좀 식상해서 이번엔 그냥 추첨했습니다. 결코 시간이 없었다거나 귀찮았던 건 아닌데... ㅡㅡ;)

다음으로 아이튠스 기프트카드를 받을 다섯 분을 추첨했는데요. 나머지 서평들 속에서 뎅ㅇ 님, BeyondNK 님, intelcpu 님, Lucidite 님, buggymind 님이 뽑히셨습니다. 기프트카드를 받으실 메일 주소를 비밀 댓글이나 저희 메일로 알려주세요. (아이튠스에 가입하신 메일이면 더 편하실 겁니다. ^^)

당첨자 서평 보기

simpurie 님 - http://simp.egloos.com/3491611
'뎅ㅇ' 님 - http://wannabewize.tistory.com/106
BeyondNK 님 - http://thinkingblog.tistory.com/109
intelcpu 님 - http://blog.yes24.com/document/1787202
Lucidite 님 - http://blog.yes24.com/document/1790753
buggymid 님 - http://www.buggymind.com/258

이상으로 오브젝티브 C 2.0 서평 이벤트를 마치겠습니다. 응모해주신 모든 분께 다시 한 번 감사의 말씀을 드립니다. ^^