도서출판 인사이트

프로젝트가 서쪽으로 간 까닭은

두루 — Fri, 06 Nov 2009 13:55:56 +0900

조직이 미친 듯이 바빠야 잘 돌아가는 거라고 믿는 당신에게,
프로젝트에 구린 냄새가 느껴지지만 뭔 문젠지 말로 표현하기 힘든 당신에게,
"빌어먹을,,, 난 관리를 왜 이 모양으로 할까..."라고 비탄과 한숨에 푸욱 쩔어 있는 당신에게,
리마커블한 관리자가 되기 위해 불철주야 노력하고 있는 당신에게,
프로젝트에 참여하는 인간 군상들의 행동 패턴을 잘 분석하고 재밌게 쓴 책이 없을까 탐색 중인 당신에게,

이 책은 바로 당신의 것입니다.
---------------------

19회 졸트상 (일반서적 부문) 수상에 빛나는 『Adrenaline Junkies and Template Zombies』가 박재호, 이해영 님의 번역으로 출간을 기다리고 있습니다. <피플웨어>와 <데드라인>, <리스크관리(곰과함께 춤을)>로 유명한 톰 드마르코, 팀 리스터 외 애틀랜틱 시스템 길드 회원 네 명이 공저한 이 책은 프로젝트의 성공과 실패를 가늠하는 인간 행위를 86가지의 패턴으로 이야기하고 있습니다.

아드레날린 중독증 패턴

조직이 미친 듯이 바쁘게 움직여야 생산성이 높다라고 믿는다.

번역서의 제목은 <프로젝트가 서쪽으로 간 까닭은>입니다. 배용균 감독의 <달마가 동쪽으로 간 까닭은>이란 영화가 한때 유명했었죠. 여기서 '동쪽'의 의미가 득도, 완성, 성취라면 '서쪽'의 의미는 실패, 쇠락, 함몰입니다. 이 제목은 'Extremely Agile'이란 블로그에서 아주 재미난 소설을 연재하고 계시는 이병준 님께서 주셨습니다. 이자리를 빌려 감사 드립니다.

생선 썩는 내 패턴

프로젝트 냄새를 맡고 판단한 능력이 부족하다.

공저자들의 경력을 합치면 총 150년이나 됩니다. 그들이 지닌 프로젝트 관리/컨설팅 경험을 토대로 프로젝트 진행 과정에서 나타나는 다양한 군상들의 행위가 그 성공과 실패에 어떠한 영향을 미치는지에 대해 통찰력 있는 필치로 그려내고 있습니다. 각 꼭지마다 테마에 맞는 사진이나 그래픽이 꾸며져 있고 간결하고 유머러스한 문체로 이루어져 있어 앉은 자리에서 다 읽어낼 수 있을 정도로 편한 책입니다.

침묵은 암묵적인 동의다 패턴

체념어린 침묵과 동의를 구분하지 못한다.

하지만 그렇다고 내용까지 쉬운 책은 절대 아닙니다. 분명하기도 하거니와 절대 간단치 않습니다. 넓고 깊은 통찰이 녹아 있습니다. 조직을 관리해본 경험이 있는 사람이라면 누구나 한번쯤 고민해봤을 법한 문제를 저자들 특유의 통찰력으로 본질을 꿰뚫어 잘 드러내고 있습니다. 그래서 한 꼭지 한 꼭지 힘을 주어 읽는다면 그만큼의 영감을 얻게 될 것입니다. 에세이가 말하고자 하는 사회적, 심리적 핵심을 제대로 이해한다면 비단 소프트웨어 개발 프로젝트에서만이 아니라 모든 프로젝트에서 능히 통할 만한 내용이라고 봐도 무리가 없을 것입니다.

프로젝트 매춘부 패턴

"아니오"라고 말하지 못하는 관리자가 있다.

신비에 싸인 프로젝트 성공과 실패의 원인들, 이 책은 그 원인을 이해하는 단서를 줄 것입니다. 그것은 바로 프로젝트에서 가장 중요한 요소인 사람을 이해하는 출발점이기도 합니다. 이책을 읽어가시면서 조직 내 인간 군상들의 행동 패턴을 명료하게 이해하고 문제 해결 방법의 실마리를 쥐게 될 겁니다.

말린 몬스터 패턴

어떤 조직은 개발자가 왕이다.
허나 어떤 조직은 개발자가 졸이다.

이 책은 단순히 긍정적인 행동 패턴만 나열하지 않습니다. 조직 내 존재하는 온갖 부정적인 패턴을 용감하고 솔직하게 그리고 때론 무척 과감하게 사정없이 까댑니다. 컨설턴트 입장에서 조직의 부정적인 측면을 발설하는 데 무척 조심스러웠을 텐데 말입니다. 긍정적인 패턴도 보통의 흔한 예와 다르게 차별화한 점도 매우 이채롭습니다.

숨겨진 아름다움 패턴

숭고한 프로젝트를 만드는 위대한 개발자를 위한 윤리학.

이책을 누가 읽어야 하냐구요? PM, PL분들은 말할 것도 없고 조직 내 조금이라도 힘 있는 자리에 있는 사람이라면 개발자라도 반드시 봐야 할 책입니다. 아니 프로젝트 조직에 참여하고 있는 사람이라면 지위고하를 막론하고 누구나 봐야 합니다. 너와 나 그리고 프로젝트를 이해하고 그 안에서 뭔가를 이루고자하는 이들 모두 말입니다.

이 책을 먼저 본 스폴스키, 콕번, 요돈, 로크는 이런 서평을 썼습니다.

피플웨어를 집필한 친구들이 만든 또 다른 걸작이다. 소프트웨어 프로젝트에서 살아남은 사람이라면 누구나 이 책에서 소개한 패턴을 확실히 이해함과 동시에 대다수의 패턴에서 많은 교훈을 얻을 것이다. 이 책은 진짜 재미있다.

조엘 스폴스키 | 『조엘 온 소프트웨어』 저자

이들이 아니라면 도합 150여년에 이르는 경험을 토대로 자주 부딪히는 상황을 이처럼 인상적인 이름으로 잡아내지 못하리라. 여러분도 이 책에 나오는 패턴 이름을 금방 사용하게 되리라 생각한다. 나도 이미 내 책에서 사용하기 시작했다.

알리스테어 콕번 |『 애자일 소프트웨어 개발』저자

책에서 소개하는 86가지 패턴은 프로젝트와 관련한 조직에서 일한 사람이라면 잔인할 정도로 친숙한 개념이다. 다행스럽게도 일부 패턴은 권장할 만한 좋은 패턴이다. 하지만 슬프게도 많은 패턴은 우울할 정도로 익숙할 뿐 아니라 팀 생산성, 품질, 사기에 놀랄 만큼 파괴적인 영향을 미친다.

에드 요돈 |『죽음의 행진』저자

사람들은 언제나 자신과 남을 이해하려 애쓴다. 살아 남으려면 이해가 필요하니까. 이해는 단순한 생계에서 자아실현에 이르기까지 생존의 질을 좌우한다. 개별적으로, 남과 더불어, 제도 안에서, 사람들이 하는 활동은 태도와 행동이라는 독특한 프레임워크를 형성한다. 이들 복잡한 요소의 역학을 인지하려면 통찰력과 인지력이 필요하다. 이와 관련한 세 가지 시도가 떠오른다.
중국인들에게는『주역』이 있다. 건축가들에게는『A Pattern Language』가 있다. 정신 의학자들에게는『정신 장애의 진단 및 통계 편람Diagnostic and Statistical Manual of Mental Disorder』이 있다.
이 책은 세 가지를 멋지게 혼합하였다. 조직 안에서 프로젝트에 참여하는 사람들이 만들고 따르는 패턴을 소개한다. (득이 되는 패턴과 해가 되는 패턴을 모두 소개한다.) 날카롭고, 재미있고, 정확한 책으로 확실히 읽을 가치가 있다.

크리스토퍼 로크 |『 웹강령95』 공저자

다음은 번역을 해주신 박재호 님과 이해영 님의 서문입니다.

박재호

프로젝트를 진행하는 도중에 뭔가 문제가 생긴다는 낌새가 느껴지는 경우가 있다. 하지만 느낌만으로 상부에 보고하지는 못한다. 현재 상황과 향후 추이가 어떻게 될지 파악해서 문제 원인과 해법을 내리지 않는 이상 불평분자로 낙인 찍힐 가능성이 높기 때문이다. 그렇다고 해서 충분한 정보를 수집해서 모든 사람이 만족할만한 정보를 수집하기까지 마냥 방관하고 있을 수도 없다. 시간이 흘러 프로젝트 후반으로 갈수록 쓸 수 있는 카드가 적어지기 때문이다. 자, 이런 상황에서 당신이라면 어떻게 하겠는가? 겁쟁이 경기에서 이기도록 운을 바라고 구경만 할 것인가?

이 책은 가슴으로는 알고 있지만 머리로는 정리되지 않은 프로젝트 행동 패턴을 알기 쉽게 정리하고 있다. 이 책 서문에도 나오듯이 이 책 저자 여섯 명은 다 합치면 총 150년에 이르는 경험을 토대로 패턴을 분류해서 표현하고 있다. 프로젝트 경험이 풍부한 사람이라면 이 책을 읽는 동안에 여러 차례 (패턴을 보면서) 환호성이나 (안티 패턴을 보면서) 비명을 지를지도 모른다. 어찌 되었거나 “이건 바로 딱 내가 겪은 이야기잖아!”라는 깨달음과 “아니 세상이 이런 중요한 사실을 모르고 지나갔다니!”라는 안타까움이 교차할 것이다. 이 책을 읽고 나면 단순히 뭔가 문제가 있다는 낌새를 넘어서 구체적인 용어를 사용해서 동료들과 토론도 가능하고 상사에게 보고도 가능해진다. 다시 말해, 패턴과 패턴 뒤에 숨어있는 추상화라는 강력한 무기를 사용해서 적극적으로 문제점을 공략할 수 있게 된다. 이게 바로 이 책의 가장 큰 특징이자 장점이다.

보통은 번역서나 저술서의 책 판형을 놓고 뭐라고 말하지 않은 성격임에도 불구하고 이번에는 특별히 출판사에게 책 판형을 최대한 줄여달라고 부탁했다. 한 번 읽고 나서 그냥 책장에 고이 보관하기 보다는 들고 다니며 필요할 때마다 참고할 가능성이 높은 책이기 때문에 언제 어디서나 들고 다니도록 휴대성을 높이는 편이 좋겠다는 생각이 들었기 때문이다. 미리 각 패턴과 안티 패턴을 충분히 숙지해서 평상시 프로젝트에 임하다가 뭔가 수상쩍은 구석이 있으면 남몰래 슬쩍 책을 펼쳐봐서 다시 한번 이미 남들이 겪은 경험을 활용하도록 하자. 혹시 점심 먹고 나서 커피점에서 혼자 이 책을 읽고 있는 사람을 만나면 품고 다니는 똑 같은 책을 보여주며 다음과 같이 슬쩍 물어보자. “저는 요즘 이런 패턴 때문에 고민이 많습니다. 당신은 요즘 어떤 패턴 때문에 고민하고 계세요?” 그리고 마음이 통한다면 잠깐 시간을 내어 토론해봐도 좋겠다.

이해영

가까운 지인이 소위 ‘“기울어가는’” 회사에 다닌다. 부자가 망해도 3년은 간다고, 아주 오랫동안 기울어가는 회사다. (참고로, 미국 회사다.) 그런데 이 책을 번역하면서 지인으로부터 들은 이야기가 계속 떠올랐다. “야, 이거 완전히 너네 회사 이야기잖아.”

그 회사는 속사정을 속속들이 모르는 내가 봐도 대여섯 개가 넘는 패턴이 금방 눈에 띄었다. 근래 몇 년에 걸쳐 여러 차례 인력을 감축하며 허리를 졸라매는 「몽땅 연필」패턴, (일정이 아니라 시장성 측면에서) 실패가 뻔한 프로젝트를 추진하는 「생선 썩은내」패턴 닮음 꼴, 누군가 잘리면 그 사람이 맡은 시스템을 아무도 모르는 「후보 선수 없음」패턴, 관리자가 왕에다 충원은 무조건 인건비가 싼 인도 사무소에서 하는 「말린 몬스터」패턴, 가장 젊은 개발자가 경력 10년차인 「“영계와 노땅」” 패턴……

이 책은 강컴, 교보문고, 예스24, 인터파크에서 예약판매하고 있습니다.

고객의 재발견_3

두루 — Tue, 27 Oct 2009 17:59:03 +0900

이해관계자중심 사고방식은 나로부터의 개혁을 요구한다.

이 책의 저자 칼 케슬러와 존 스웨이처는 ‘나로부터(in‐place)’라는 표현을 좋아한다고 합니다. 어떤 조직적 변화 혹은 개혁을 이루고자 할 때 목성만 높이는 전면적인 캠페인은 별로 좋아하지는 않기 때문이라고 합니다.
사실 세상 이치가 그렇듯, 모든 것을 한 번에 바꾸려고 하는 시도는 무모하기 짝이 없는 노릇이죠. 게다가 변화 뒤에 엄청난 이익이 기다리고 있다는 선동적인 장밋빛 약속은 그 약속이 지켜지기도 전에 무모함으로 마무리되거나 순수하게 참여했던 인간들은 완죤 비인간화시킨 경우가 비일비재하죠.
빈 깡통이 요란하다고, 소문난 잔치에 먹을 것 없다고, 특히나 이런 시끄러운 일회성 내지는 몰이성적 개혁 캠페인들은 그것의 목적인 성공적인 변화나 개혁보다는 어떻게 하면 캠페인을 잘 치를까에 목을 매고 모든 역량을 쏟아 붓기도 합니다. 주객이 전도된 안타까운 현장이죠.

물론 모든 사물의 단순한 변화(shift)에도 일정하게 에너지 낭비를 초래하듯, 개발 조직에서 단순하게나마 현상적인 변화만 이루려 해도 경영적으로는 비즈니스적인 위험을 감수해야 하는 측면이 있습니다. 하지만 실질적으로 개선하기 위해서는 어느 정도의 위험을 기꺼이 감수하겠다고 하는 선각자적인(?) 리더십이 없다면 현재와 같이 급변하는 시장 환경에서는 답이 없다고 보는 게 맞을 겁니다.

이해관계자중심 사고방식은 마치 애자일 사고방식에서의 그것처럼 내재적 접근법을 중시합니다. 최고경영자가 선각자적으로 바뀌면 뭐 훨씬 적용이 수월해지겠지만, 현실은 그렇게 녹록치 않죠. 그래서인지 실질적으로 현장에서 맨파워를 발휘하는 프로젝트 리더의 역할을 중요시합니다. 각 장마다 ‘리더의 역할’이라는 챕터를 따로 둘 정도로요...

리더로서 개발팀 전체가 이 개발방식을 도입하는 데 나로부터라는 내재적 접근을 누구보다 점진적이고 광범하게 할 수 있다는 생각일 겝니다. 그리고 현장에서 살을 부딪치며 서로 교감(communication)하지 않고, 조직적 맥락과 역량을 고려하지 않는 번개불에 콩볶아 먹듯 급한 변화는 사상누각이 될 개연성이 훨씬 많을 것이기 때문일 겝니다.

저자들은 경험에서 팀원 각자가 스스로 실천하고 거기서 성공과 실패를 경험하게 함으로써 점진적이지만 광범위하게 변화를 도입하는 것이 더 성공적이라는 판단이 선 듯합니다. 팀이 이해관계자중심 개발기법들의 가치를 조금씩, 천천히, 점진적으로, 직접 체험하게 하는 방법이 변화는 늦을지 모르지만 그 기반은 탄탄하다는 확신일 것입니다.

한편 개발 프로세스 논쟁에 빠지지 말 것을 주문합니다. 물론 이 책에서는 개발방법론과 도구로서 린 애자일방식을 가장 선호하지만 그렇다고 애자일 방식이 꼭 필수사항은 아니라고 강조합니다. 현실적으로 애자일 방법론을 채택하지 않은 프로젝트가 훨씬 많으며 이 접근법이 모든 개발팀들에게 적합하다고는 볼 수 없다는 입장입니다. 내재적, 점진적 접근법의 기조가 여기서도 관철됩니다.

그러면서 이해관계자중심 개발기법은 여러 다양한 개발방법론들과 병행하여도 효과가 있다고 주장합니다. 이 개발기법으로의 성공요인은 팀이 이해관계자중심 사고방식에 대해 얼마만큼 신뢰하느냐이지 규정화시키고 범주화시킨다고 성공하는 것은 아니라는 생각입니다.

날마다 새롭게, 천천히

일일신우일신(日新日日新又日新)하라는 공자의 말씀은 많은 맥락으로 해석되고 있습니다만, 특히 ‘나로부터’라는 관점에서 널리 쓰이고 있는 듯합니다. 이러한 입장으로 이해관계자 개발기법을 하루하루 실천한다면 프로젝트와 조직에 문화적 새바람을 불러올 수 있지 않을까 조심스럽게 기대해 봅니다. 만약 이렇게 된다면 동시에 고객과의 소통 또한 별무 문제일 거 같습니다. 소통의 문제는 결국 사람의 문제일 가능성이 높고 사람의 문제는 문화적, 정서적 주파수를 잘 맞춰야 나머지 것들도 잘 따라가곤 하니까요. 이해관계자중심 사고방식(OID)이 개발자와 고객 간의 주파수 튜닝에 도움이 되길 바랍니다.

고객의 재발견_2

두루 — Sun, 18 Oct 2009 02:50:28 +0900

고객과 반복해서 대화해야 하는 이유

"아빠, 우리 백화점에 가자. 나 드레스가 필요해."
"그래 그럴까? 우리 귀염둥이."
"아빠, 걱정 마. 나 뭐 살지 알고 있거든! 은 목걸이를 해야 하니까, 무릎까지만 오는 파란색 하이 네크라인 드레스가 필요해."

… 나중에 쇼핑몰에서…

"우리 딸, 그건 핑크 드레스고 무릎 아래까지 내려오잖아. 그리고 가슴 선이 너무 파였는데. 하이 네크라인 드레스는 어쩌고? "
"아빠 바보. 이게 진짜야. 이게 내가 찾던 거라니까! "

... 그리고 집에 돌아와서는...

어디서든 ‘대화’는 필수죠. 굳이 호모 로쿠엔스(homo loquens)라고 규정 내리지 않더라도 자신이 속한 어느 영역에서든 대화는 소통의 가장 기본적인 단위죠. 가끔, 뭐, 대화는 하수들이나 하는 소통 방식이라고 ‘깨달음’ 혹은 ‘영성’이 먼저라고 하시는 분들도 계시긴 하지만, 고난한 속세에서 살아남아야 하는 중생들이야 가장 기본적인 대화에서 소통의 단서를 잡지요. 하기야 그것도 잘 못하거나 혹은 안 하거나 하는 게 현실이지만 말입니다.

그런데 대화 한번 한다고 의사소통이 다 된 거라고 혹은 잘 될 거라고 믿는 건 너무 안이한 생각일 겁니다. 위 귀염둥이가 진짜루 원한다는 게 ‘분홍 보자기’라는 걸 누군들 상상이나 했겠습니까? 모든 고객들이 이 귀염둥이마냥 변덕이 죽 끓듯하다고 희화화 할 수는 없겠습니다만, 현업에서 나름 업을 쌓아가는 이들의 말씀을 들어보면 완전히 틀린 얘기는 아닐 성 싶습니다.^^

이해관계자중심 개발방식에서는 개발과정에서 이해관계자와 반복적으로 대화하라고 권합니다. 그래야 이해관계자의 상황과 요구를 제대로 파악할 수 있다고 합니다. 그런데 여기서 중요한 게, 단순히 파악만하고 넘어가라는 정도가 아니라 파악된 내용을 반복적으로 심화시키라고 합니다. 파악하는 거 자체도 쉬운 일이 아닌데 파악했다고 손 놓고 있지 말고 더욱 심화시키라니,,, 참......

반복적으로 이해관계자와 소통하며 그들의 목표에 대한 이해를 심화해야 하는 이유는 무엇일까요? 답은 뭐 대략 눈치 채셨을 거라 사료됩니다만, 어쩌면 지극히 단순하리라 봅니다. 처음부터 모든 것을 완벽하고 정확하게 정의한다는 것이 사실상 불가능하기 때문일 겁니다. 소프트웨어라는 제품이 눈으로 보기 전에는 이게 고객 자신이 정말 원하는 건지 아닌지를 정확히 알 수 없다는 물성의 한계가 명확하기에 너도 알고 나도 아는 완결된 형태의 제품을 만들기란 참으로 어려운 문제겠죠. 그래서 저자들이 소프트웨어를 설계한다는 것은 마치 어린 딸아이를 데리고 쇼핑몰에 가는 것과 비슷하다고 한 모양입니다.

또 저자들은 주관적 추측이나 논리적 추정이나 다같이, 이 환장할(?) 불확실성을 극복하기에는 턱없이 모자란다면서 ‘감정이입 디자인(empathic design)’이라는 개념까지 차용하며, 대화의 심화를 강조합니다. face-to-face에서 블로그, 위키, 커뮤니티까지 할 수 있는 모든 대화 방법을 이용해 고객의 요구사항을 계속적으로 피드백 받아야 한다고 합니다. 그렇다고 무턱대고 대화하라는 건 또 아니고, 이해관계자가 누구인지, 그들이 기대하는 TO-BE 미래목표가 무엇인지 잘 살펴서 거기에 맞게 대화하라고 합니다. 이 지점에서 궁금해지는 건 이런 조건을 충족한다고 과연 대화라는 게 잘 될까하는 점입니다.

사진작가 최민식 님은 ‘렌즈는 세상을 향해 열려 있어야 하고 사진은 보는 이들의 마음을 움직여야 한다’고 합디다. 사진이라는 게 작가와 세상이 만난 결정적인 순간을 관객과 작가가 소통하고 공명하게 하는 거라면, 잘 찍었다고 말하는 사진이 단순히 기교나 기술만 갖고 말하는 건 아닐 뿐 아니라 또 그렇게 될 리도 만무일 겁니다. 먼저 세상을 향해, 타인에 대해, 마음이 열려 있어야 하겠죠.

이해관계자중심 사고방식(OID Thinking)에서 말하는 대화도 단순히 기교나 기술을 의미하지않습니다. 고객에 대한 감성적 이해와 이성적 분석이 상호 유연하게 결합되어야 한다는 생각이 짙게 깔려 있습니다. 먼저 고객에 대해 마음을 열고 피드백을 받고 분석하고 다시 소통하는, 고객과 서로 마음이 움직이는 대화를 지향하는 겁니다. 말은 쉽지만 참 어려운 구석이 많습니다.

'많은 대화가 곧 많은 이해다'라는 등식이 성립되긴 힘들어 보입니다. 하지만 길든 짧든 유의미한 대화를 한다면 그에 따른 성과가 나오리라 믿습니다. 모든 게 그렇듯이, 프로젝트라는 시공간 내에서도 고객과의 대화로 제대로 된 성과를 내려면 의미 있는 대화가 되어야 할 겁니다. 이를 위한 여러 가지 조건 중에 하나가 대화 당사자들이 관점과 태도를 어떻게 가져가야 할까가 아닌가 생각해 봅니다. 사진에서의 스냅샷이 ‘결정적인 순간으로 영원’을 잡듯, 고객과의 진실한 대화로 ‘결정적인 고객의 영원한 마음’을 잡으시길 기원해 봅니다.

고객의 재발견_1

두루 — Wed, 14 Oct 2009 10:27:13 +0900

이해관계자를 이해한다.

표준국어사전에서 고객의 의미를 찾아보면 이렇습니다.

「명사」
고객(顧客)
1. 상점 따위에 물건을 사러 오는 손님. ≒화주(華主)
2. 단골로 오는 손님. ‘단골손님’, ‘손님’으로 순화. ≒상객04(常客)

일반적인 상점에서 정기적으로 물건을 사러오는 손님이란 의미에서라면 고객의 의미는 자연스럽게 다가옵니다. 또한 비즈니스의 일반 범주에서 거론되는 ‘고객은 기업 경영에 있어 가장 중요한 존재’ 내지는 ‘기업 가치를 창조할 수 있는 동반자’라는 의미도 쉽게 다가옵니다.

"과연 내 고객은 뉴규?"

그런데 이렇게 가볍게 다가오는 고객의 의미가 소프트웨어 개발에서는 시각의 각도를 조금만 틀어도 참으로 복잡해집니다. “지금 당신의 고객은 누구죠?”라고 질문하며 간단하게 한 마디로 말해달라면 얘기는 참 달라집니다. 고객사? 갑? 갑의 임원직원? 갑이 지정한 아웃소싱업체? 아니면 모두?

‘고객 만족’이란 구호는 이제 일상 마케팅에서 무슨 교의처럼 보여집니다. 말 그대로 정말 고객을 만족시키려면 고객이 누구인지부터 알아야겠죠. 그러고 나서 그 고객이 궁극적으로 달성하려는 목표를 파악해야겠죠. 무엇을 꾸밀 때 항상 통시성을 외면하면 안 되듯, 고객의 과거를 포함한 현재 상황과 미래 희망 상태를 잘 이해해야 뭐가 돼도 될 것입니다. 상황이 이런 데다가 고객이 한 부분이 아니고 여러 부분이면, 그리고 이런 여러 고객의 이해와 요구가 메트릭스처럼 3차원 공간에서 서로 엉켜있으면, 사태는 참으로 복잡해집니다.

"이런 모습일까?"

현재까지 고객을 유형과 역할별로 나누어 세분화한 다음 그에 맞는 대응을 어떻게 하는지에 대한 책은 국내에 소개가 된 바가 없는 거 같은데, 이 책 『이해관계자중심의 소프트웨어 개발』은 이런 복잡함을 매우 세련되게 추상화시켜 과연 ‘고객이란 무엇이고 성공이란 무엇이며 프로젝트 개발자가 궁극적으로 지향해야할 부분은 무엇인지’에 대해 아주 자세히 그리고 무척 실용적으로 말하고 있습니다. 자신이 만들고 있는 제품의 실제 사용자와 더불어 궁극적으로 비즈니스 가치를 드높이는 주인공인 고객이 누구인지 어떻게 대응해야 하는지에 대해 분석적 기준을 제시하고 있습니다. 프로젝트 리더에서 매니저, 제품 소유자, 일반 개발자에 이르기까지 이해관계자의 실체를 파악하는 데 도움이 될 것입니다.

"아니면 이런 모습?"

또한 더 나아가 프로젝트 팀이 성공하기 위해서는 왜 이해관계자의 입장에서 성공을 정의하고 이해관계자를 정확히 파악해야 하는지 그 이유를 세련된 이론적 얼개와 실천적 벼리를 들어 설명하고 있습니다. cross-function 능력을 갖춘 전체팀(whole-team)이 되어야 하는 이유, 이해관계자의 조직적 맥락을 이해해야 하는 이유, 제품의 소비가능성(consumability)을 용이하게 해주는 각종 메타작업을 잘 해야 할 필요성 등, 성공하는 프로젝트를 꿈꾸는 이라면 꼭 읽어봐야 할 내용들로 가득 차 있습니다.

아무쪼록 이 책이 고객의 비즈니스 가치를 실현하고 개발팀의 창의성을 구현하려는 accountable한 이들에게 도움이 되었으면 싶고, 과실은 서로 나누고 기쁨은 서로 배가 시키는 프로젝트 성공의 한 길에서 기분 좋게 고객과 악수하는 데 조금이나마 도움이 되길 바랍니다.

이해관계자중심 소프트웨어 개발_ 고객의 비즈니스 가치를 드높이는 개발접근법

두루 — Mon, 05 Oct 2009 15:59:46 +0900

IBM에서 수십 년 잔뼈가 굵은 칼 케슬러와 존 스웨이처가 쓴 <Outside-in Software Development>(부제:A practical approach to building successful stakeholder-based product.)의 한국어판이 나옵니다.

한국어판의 제목은 <이해관계자중심 소프트웨어 개발>(부제:고객의 비즈니스 가치를 드높이는 개발 접근법)입니다.

워낙 생소한 구석이 있는 접근법이라 처음에 번역자를 모시기 어려워 여러 가지 시도를 했었습니다. 다행히 <영국에서 개발자로 일한다는 것>이란 컬럼을 마소에 연재하셨던 차영호 님이 번역을 맡아주셨고, 성심성의껏 탈고해주셔서 무사히 발간에 이르게 되었습니다.

이 책은 이해관계자를 중심에 두고 사고하고 소통한 결과물을 토대로 개발하여, 고객의 비즈니스 가치를 향상시킬 수 있는 성공적인 제품을 만드는 색다른 개발 접근법을 말하고 있습니다.

막연히 추상화되어 있는 '고객'이란 키워드를 세분화하고 구체화하여 각 이해관계자에 맞는 전술을 살펴봄과 동시에 그에 기반한 개발 전략을 짜는 데 유용한 내용으로 일관하고 있습니다.

저자도 밝히듯이, 이 책은 임원, 관리자, 일반 직원을 망라하여 프로그램의 모든 영역에 걸쳐 있는 모든 이에게 필요한 책입니다. 굳이 직군을 들자면, 프로그래머와 테스터, 기술문서 작성자, 설계자, 지원 기술자, 아키텍트, UI 설계자, 성능 스트레스 테스터 등입니다. 또 도움이 되는 분야를 들자면, 마케팅/영업, 비즈니스 전략, 제품관리, 비즈니스 개발, 가격 선정, 금융, 서비스 등 그 범위가 엄청 넓습니다. 아무쪼록 각 분야에 실질적인 도움이 되었으면 하는 바람입니다.

추천사는 <린 소프트웨어 개발>을 Mary와 같이 쓴 톰 포펜딕이 썼습니다.

이해관계자중심의 사고는 팀이 소프트웨어를 구현할 때 사용하고 있는 기존의 접근법을 보완하는 역할을 하기도 하지만, 성공을 측정하는 방식 자체를 변화시킵니다. 성공적으로 이해관계자중심의 개발방식을 따르는 개발팀은 작업 과정에서 많은 것을 학습하고 적용합니다. 절대 추측으로 일하지 않습니다.
- 톰 포펜딕 (Tom Poppendieck)

간추린 내용은 아래와 같습니다.

핵심 이해관계자들에게 최상의 비즈니스 가치를 제공할 수 있는 소프트웨어를 개발하라

꿈의 프로젝트가 있다고 상상해보자. 제품은 생산성도 높고, 사기도 높은 소프트웨어 전문가 팀에 의해 설계되고 개발된다. 제품은 고객들이 원하는 사항을 정확하게 파악하여 출시되고, 출시되기가 무섭게 여기저기서 열띤 호응을 받으며 채택된다.
이 책에서 소개하고 있는 혁신적인 ‘이해관계자중심’의 소프트웨어 개발방식을 적용한다면, 여러분의 다음 프로젝트가 바로 이와 같은 ‘꿈의 프로젝트’가 될 수 있다.

이해관계자를 사고의 중심에 두고 개발하여 소프트웨어의 진정한 가치를 드높이라

IBM에서 가장 존경받는 소프트웨어 리더라고 할 수 있는 칼 케슬러(Carl Kessler)와 존 스웨처(John Sweitzer)는 ‘이해관계자중심의 소프트웨어 개발방식’을 통해 프로젝트의 진정한 가치가 무엇인지 깨달았다. 이해관계자들의 이해와 요구를 올바르게 파악하고 최종 고객의 실질적인 요구사항를 조율하여 개발 작업에 통합시켰다. 광범위한 시장에서 단기간에 고객을 장악할 수 있는 소프트웨어를 어떻게 제공할지, 고객의 비즈니스 가치를 어떻게 높일지, 이 책은 그 해결책을 여실히 보여주고 있다.

이해관계자중심 개발방식은 어떠한 프로젝트 유형에도 유용하다

저자들은 프로젝트 유형이나 범위에 상관없이 어떤 개발팀이라도 즉각적으로 도움을 얻을 수 있는 완벽한 이론적 프레임과 실용적 실천기법들을 제시하고 있다. 그 접근방식은 활용면에서 실제로 이미 증명되었다. 이로서 개발자는 고객과의 대화에서 효율성을 높일 수 있고, 더욱 향상된 가시성과 명확성을 가지고 우선순위를 결정할 수 있으며, 작성한 코드들이 최상의 비즈니스 가치를 제공 할 수 있을 것이다.

이 책은 다음과 같은 내용을 담고 있다.
-이해관계자를 파악하고 이들이 속한 조직 및 비즈니스 맥락을 이해한다.
-프로젝트가 충족시켜야 할 중/단기 이해관계자 목표를 명확히 분석한다.
-프로젝트의 각 기대사항들을 더욱 효과적으로 실제 결과물로 치환한다.
-더욱 ‘소비가능(Consumable)’한 소프트웨어, 즉 손쉽게 배포하고 사용하며, 지원할 수 있는 시스템을 개발한다.
-이해관계자들의 목표와 지속적으로 조율한다.
-제품을 제공한 이후에도 장기간 진행되는 변화를 이해관계자들이 지속적으로 관리할 수 있게 돕는다.
-이해관계자 기반의 개발방식을 추진하는 데 필요한 리더십 기술을 습득한다.
-----------------------------------------------------------------------

마지막으로 차영호 님의 서문을 아래 싣습니다.

아마도 제 짧은 식견 때문이겠지만, 애자일 세계에서 고객에 대하여 이렇게 체계적으로 설명한 글은 아직 보지 못했습니다.

제가 처음 애자일을 접한 것은 2002년 즈음이었습니다. 김창준씨가 XP(eXtreme Programming)에 대해 마이크로소프트웨어 지에 기고한 글을 읽고, 흔히 말하는 "아하!" 하는 순간을 가졌습니다. 당시 개발방법론은 폭포수 방식이 유일했고, 또 코딩을 하기 전에 반드시 종이와 연필로 순서도를 그리며 개발 설계를 해야만 제대로 개발하는 것이란 분위기가 대세였습니다. 저는 이에 대해 설명할 수 없는 불편함과 반감을 가지고 있었습니다. 개인적으로는 먼저 설계하기보다 직접 코드를 작성하면서 조금씩 설계를 다듬어 가는 것을 좋아했기 때문이었습니다.

한편 비즈니스의 요구사항은 조금씩 계속 변하는데, 그럴 때마다 비즈니스 팀과 신경전을 벌이기보다 좀 더 건설적으로 해결할 수 없을까 하는 고민을 가지고 있었습니다. 이때, XP는 ‘점진적 설계’라는 말로 제가 가지고 있던 불편함과 고민을 명쾌하게 설명해 주었습니다. 이후 저는 애자일 개발의 열렬한 팬이 되었고, 애자일은 제 개발 업무와 경력에 큰 도움이 되었습니다.

IBM 출판 부문에서 나온 『OUTSIDE-IN SOFTWARE DEVELOPMENT』는 애자일의 여러 원칙 중에서 ‘고객’에 초점을 맞추고 있습니다. XP나 스크럼에서는 ‘고객’ 혹은 ‘제품 책임자(Product Owner)’가 추상화되어 지나치게 간략히 취급하고 넘어가는 경향이 있습니다. 그러나 실제 애자일 방식으로 개발하다 보면, 고객의 역할이 참으로 다양하고 중요하다는 것을 많이 느끼게 됩니다. 이 책 『이해관계자중심 소프트웨어 개발』은 이해관계자를 4가지로 세분화하여 심도 있게 그리고 구체적으로 탐구합니다. 어떻게 이들과 더 잘 의사소통할 수 있는지, 어떤 방식으로 이들의 요구사항에 접근해야 하는지, 이들이 무엇을 진정으로 원하고 있는지 (때로 고객들은 자신이 무엇을 원하는지 잘 모르기도 합니다), 이들의 비즈니스가 성공하려면 우리 개발자들이 어떤 솔루션을 제공해야 하는지 연구합니다. 아마도 제 짧은 식견 때문이겠지만, 애자일 세계에서 고객에 대하여 이렇게 체계적으로 설명한 글은 아직 보지 못했습니다.

『이해관계자중심 소프트웨어 개발』에는 수많은 구체적인 사례와 경험담이 있습니다. 저는 이 책을 통해 IBM에서는 어떻게 프로젝트를 진행하는지, 어떤 문제들이 있으며, 문제가 있을 때 어떤 식으로 해결하는지, 개발자와 리더들은 어떤 생각을 가지고 있는지 살펴볼 수 있었습니다. IBM의 개발 업무 방식과 제가 근무하고 있는 Totaljobs.com의 프로세스들을 비교해 보면서 재미도 있었고, 또 많은 것을 배울 수 있었습니다. 또한 저는 인하우스(in-house) 개발팀에서 스크럼을 사용하고 있어서 그런지, 이런 방향이면 컨설팅 분야에서도 애자일을 활용할 수 있겠구나 하고 깨닫기도 하였습니다.

그러나 이 책은 단순히 애자일 방법론에 관한 책이 아닙니다. IBM의 고객들은 실로 다양하여, 어느 한 방법론을 위한 개발방식으로는 이들 모두에게 도움을 줄 수 없었습니다. 이 이해관계자중심 개발방식은 폭포수(waterfall) 방식에서 린 방식, XP(Extreme Programming)까지 모든 방법론에 적용할 수 있으며, 또 실제로 적용하여 훌륭한 성과를 보았습니다. 소프트웨어 개발의 목적이 고객에게 필요한 솔루션을 제공하는 것인 이상, ‘이해관계자중심 소프트웨어 개발방식’은 여러분이 그 목적을 이루는 데 큰 도움이 될 것입니다.

하여, 여러분에게 이 책의 일독을 권해드립니다. 이 책을 통해 우리 개발자들과 ‘고객’이 좀 더 가까워지고, 서로를 더 잘 이해할 수 있었으면 좋겠습니다. 그리하여 고객이 원하는 바로 그 솔루션을 제공함으로써, 개발자들이 흘리는 땀과 열정이 의미 있는 작업이 되고, 개발자들이 좀 더 우대받는 문화가 정착되기를 소망합니다.

켄트 벡 세미나 후기

너굴; — Wed, 09 Sep 2009 21:53:42 +0900

지난 포스트에 올렸듯이 좌충우돌했지만 무사히 끝낸 켄트 벡 세미나. 그 후기와 사진들을 올려 봅니다. ^^

1. 인사이트 도서전 : 쉬는 시간마다 많은 분들이 찾아와 저희 책에 관심을 보여주셨습니다. 켄트 벡의 책은 9월 2일 세미나보다는 적게 팔렸는데(인원 수에 비해), 아마 이는 자봉님들의 예상대로 9월 4일 세미나 참가자들이 평소 켄트 벡이라는 이름(그리고 명성)을 좀더 가깝게 접했던 분들이어서 그렇지 않았을까 합니다. 그래서 빨리 등록할 수 있었고, 이미 켄트 벡이 집필한 책 정도는 갖고 계신 분들이 많았구요. 현장에서 사인을 받기 위해 줄을 서신 분들이 갖고 나온 책들을 보니 『테스트 주도 개발』 표지가 바뀌기 전인 1판 1쇄를 들고 서 계신 분들이 상당히 많으시더라구요.

2. 열기가 느껴진 강연장 : 빈 자리를 찾기가 어려울만큼 많이들 오셨는데요. 비단 거금을 결재했다는 이유만은 아니라는 느낌을 받았습니다.

3. 포스가 느껴졌던 켄트 벡 : 켄트 벡의 한국 일정을 잠깐 들었는데, 주말을 빼고는 거의 쉬질 못하더군요. 2일 하루 종일 세미나, 3일도 삼성 멀티캠퍼스 강의, 4일엔 또 하루 종일 세미나, 늦은 시간까지 짬짬이 기자들과 만나기도 하고, xper들도 별도의 만남을 갖기도 했구요. 수요일(9일) 오전까지 워크샵을 마친 후 곧바로 비행기를 타고 중국으로 가서 목요일부터 또 강연... 그럼에도 후학들에게 자신의 깨달음을 하나라도 더 전해주려는 열정이 엿보였습니다.

4. 친절한 켄트 벡 : 유명한 사람은 왠지 대하기 어렵다는 편견을 깨준 켄트 벡. 인사이트 역자들과의 사진 요청에 흔쾌히 응해주셨습니다. 아침부터 저녁까지의 강연에 지쳤을 텐데도 다들 밝은 모습이네요. (금요일 오후니까 그런 걸까요? ^^)

사인회가 끝나고 점심을 먹기 전에는 저희 부스에 오셔서 『테스트 주도 개발』의 표지와 내지 디자인이 정말 마음에 든다며, 원서의 출판사인 Addison-Wesley 측에도 이런 식으로 만들 수 없냐고 건의했다고 하더라구요. (라고 김창준 님께서 통역해주셨습니다. ^^a)

9월 4일 세미나엔 저희 인사이트의 역자분들이 다수 참가하셨습니다. 왼쪽 사진 오른쪽부터 김경수 님(정규표현식, 애자일 회고), 박일 님(스크럼), 김성안 님(프로그래밍 jQuery), 김창준 님(익스트림 프로그래밍, 테스트 주도 개발), 켄트 벡, 한주영 님(사용자 스토리, 스크럼과 XP), 심우곤 님(사용자 스토리, 스크럼과 XP), 송우일 님(사랑하지 않으면 떠나라)

5. 저자와 역자의 사인이 담긴 『테스트 주도 개발』, 『익스트림 프로그래밍』 : 저희 사무실에도 아직까지 저자 사인이 담긴 책이 없었는데요. 뭐 꼭 그래야하는 건 아니지만, 그래도 소장해두면 폼 나겠죠? ^^

이렇게 세미나를 별 탈 없이 마쳤습니다. 세미나에 참여하셔서 열심히 강의를 들은 분들, 저희 부스에 오셔서 한 권이라도 구입해주신 분들, 세미나를 위해 수고하신 모든 분들께 감사의 마음을 전합니다. ^^

켄트 벡(Kent Beck) 방한과 사건 사고

인사이트 — Thu, 03 Sep 2009 19:20:38 +0900

9월 1일

새벽까지 Objective-C 책 인덱스를 마무리하고 느즈막히 출근. (인덱스 1,400개를 정리하는 작업은 그리 만만치 않습니다. (이전 블로그 글 참조)

『테스트 주도 개발(TDD)』 책이 네 권 밖에 남지 않았다고 창고에서 연락이 왔습니다. 헉~~ 내일(2일) 켄트 벡 사인회를 준비해야 하는데!!

사진은 http://pragmaticstory.com/1048에서 무단으로 긁어왔습니다. ;;

사무실에 책이 몇 권 있긴 했지만, 급히 서점에서 주문한 책들의 출고 중지를 요청합니다. (덕분에 yes24, 인터파크에서 책을 주문하신 고객들은 모두 하루 늦게 책을 받았을 겁니다. 너무 늦게 연락을 취하는 바람에 혼선의 우려가 있어 TDD 뿐 아니라 모든 책이 출고되지 않았거든요.)

책 재고가 그리 많지 않다는 건 알고 있어, 재쇄를 준비하는 중이긴 했는데, 이렇게 빨리 재고가 없어지라곤 생각하지 않았었습니다. 4일에 더 많은 분들이 모이는 세미나가 있으니, 느슨하게 진행했던 작업 일정을 서둘러야 합니다.(평소 일정이라면 인쇄 완료 후 4일~1주일)

우선 시간이 제일 많이 투여되는 하드커버 제책부터 일정을 확인합니다. 사정이 이만저만하니 9월 3일까지 작업을 마무리 하실 수 있으세요? 어떻게든 소량이라도 맞춰주겠다는 약속을 받았습니다. 약속을 받았다 해도 병목에 대한 답을 들었을 뿐이고, 제책에 돌입하기 위한 다른 모든 준비를 그 일정에 맞춰 당겨야 합니다. TDD 책 뒤에 붙을 CD 제작 일정도 2일까지 당겨 맞추고, 표지/본문 인쇄도 오늘(1일) 어떻게든 끝내도록 인쇄소와 협의합니다. 시간에 맞춰 감리도 가야하고.

다른 한편으론 응급 상황에 대처하기 위해 서울문고 코엑스, 강남컴퓨터 서적 등 재고가 있을만한 서점에 연락해 확인을 하고 반품을 요청할 수 있겠다고 얘기해 놓습니다. 강컴은 마침 재고가 떨어졌다고 통보해오고, 서울문고는 사정을 듣고 전 점에서 회수할 수 있도록 준비하겠다는 약속을 해줍니다.

9월 2일 켄트 벡 첫 세미나

창고에서 저희에게 책을 가져다주시는 담당자가 갑자기 병원에 가야 해서, TDD 출고가 오후에나 가능하겠다고 연락이 옵니다. 출고차를 갖고 움직이시는 분이라 병원이라도 쫓아갈까 했으나, 오후에 갖다 주면 되겠거니 해서 창고에서 책을 갖고 나오지 않았답니다. 기껏 서점에 출고하지 않은 보람이 없어지게..... ㅜㅠ

일단 출판사에 있는 책들만 들고 세미나에 가 자원봉사자들에게 전달하고 왔습니다. 책을 놓고 되돌아 나온 지 얼마 되지 않아(11시 30분 경) 가져간 책이 벌써 모두 팔렸다는 연락이 왔습니다.

허걱~ 책을 많이 갖고 가진 않았지만, 평일 그것도 유료 세미나에 참석할 정도 분들이라면 켄트 벡의 책 정도는 모두 구입하지 않으셨을까 하고 예상했었는데.... 빗나갔네요.

허겁지겁 창고(파주)로 출동해 어제 인터넷 서점에 출고 않은 책들을 회수합니다. TDD 말고 『익스트림 프로그래밍』 역시 책이 모두 팔렸다는 보고이기에 창고에 발주를 했더니, 창고에도 17권 밖에 남지 않았다는 연락이 옵니다.

"엥~~~? 10여일 전에 재고를 확인했을 땐 웬만큼 재고가 있지 않았나?"

9월 4일 세미나까지는 하루 반나절 남은 상황입니다. 게다가 사람은 두 배 이상 모이는 세미나구요. 또 발등에 불이 떨어졌습니다.

이번엔 소프트커버 책 제작에서 시간이 가장 많이 걸리는 인쇄/제본 담당자에게 연락을 취합니다. “지금 발주해 3일 저녁까지 가능할까요? 무리인 건 알지만......”

당장 답을 주지 못하네요. 현장에 확인하고 일정을 조율해 알려주겠다고만 합니다.

잠시 후 연락이 왔습니다. 종이를 지금 바로 맞춰 넣어주면 오늘 야근을 시켜서라도 일정에 맞추겠다네요. 휴~~ 감사!!

“표지 후가공은 없나요?” “있는데요.”

“....... 서둘러 주세요.” “네.”

표지 인쇄를 마치고 코팅 후 먹박(인쇄 코팅된 표지 제목 부분에 먹지를 대고 눌러 글씨를 만드는)까지의 공정을 다음 날(3일) 오전까지 마쳐야 제책에 들어갈 수 있습니다. 각 공정은 제작처 한곳에서 진행하는 게 아니라 따로 떨어져 있고..... 역시 각 공정을 담당하는 업체에 대지급으로 일을 마무리 해달라고 요청합니다. 판권 면을 교체한 필름도 제작해 보내구요.

저희가 할 수 있는 일정 세팅은 대략 마쳤습니다. 하루가 어떻게 가는지 모르겠네요.

아~ Objective-C도 마감입니다. 9월 8일 예약을 걸어놨기에 일정을 늦추기도 애매한 상황입니다. 급박하게 일을 처리하는 와중에 짬짬이 본문을 최종확인하고 출력소에 보냅니다. PDF를 받아서 점검하고, 수정사항을 반영해 다시 출력소로 보내고, 확인용 PDF를 받아 다시 점검합니다. 이제 Objective-C도 인쇄, 제책만 하면 마무리입니다. 휴~

우선 감사부터.....

급한 걸 넘어 무리한 일정으로 압박했음에도 두말없이 바로바로 챙겨주신 인쇄, 제책, 후가공, 종이 업체의 모든 담당자님들께 감사드립니다. 특히, 병목을 해결해 주신 문원사의 조이사님, 현문인쇄의 김경호 부장님 감사합니다.

그리고....반성

마침 켄트 벡의 책 두 권 모두 재쇄에 임박한 시점이라 재고가 그리 많지 않은 건 파악하고 있었고, 재고를 확인하긴 했지만, 추가 수요가 예측되는 상황임에도 일상적 재고만 확인하고 안이하게 대처해 급박한 상황을 만들었다는 점이겠죠.

더 중요하겐, 뭔가 상황이 닥치는 데도 아무데서도 경고음이 나오지 않았다는 점이랄까요?

아무래도 저흰 뭔가 시류를 맞춰 책을 내야하고, 베스트셀러를 목표로 공세적으로 움직이며, 때론 대박이 터져 급박하게 돌아가는 대중서 출판사라기보단, 한 권씩 차분히 책을 늘려가는 스타일이고, 평소 일정에 목숨(?)까진 걸지 않는 느슨함(?)에 푹~~~ 쩔어 있어 그렇지 않았나 하는 생각도 들고.....

오브젝티브-C 2.0에 뛰어들기!

너굴; — Wed, 26 Aug 2009 10:24:06 +0900

바로 작년까지만 해도 맥에서 개발하는 분들이 볼만한 국내서는 『코코아 프로그래밍』 뿐이었는데요. 단 1년 만에 참고할만한 서적들이 부쩍 늘었습니다. 관련 개발자들께는 기쁜 일이라 할 수 있겠지요?

여기에 기쁜 소식을 또 하나 더할까 합니다.

아마존에서 각종 카테고리의 베스트 1위를 차지하고 있는 『Programming in Objective-C 2.0』을 출간합니다! 아이폰 열풍에 힘입은 탓인지, 화이트 북까지 제치고 C 분야에서도 당당히 1위를 차지하고 있는(가끔 2위로 내려가기도 합니다만... ㅎㅎ) 이 책은 오브젝티브 C를 배우려는 초급자와 중급자가 반드시 참고해야할 멋진 책입니다. ^^

이 책의 특징이라면, 뭐니뭐니해도 오랫동안 많은 독자들이 '최고의 오브젝티브-C 책'이라고 인정한 책이라는 점입니다. 아마존을 살펴보자면, 2003년에 발간된 1판이나 2009년 2월에 발간된 2판에 대한 댓글이 모두 칭찬으로 가득함을 알 수 있습니다.

또한, Developer Library라는 원서의 부제답게 개발에 필요한 내용이 자세한 설명과 예제와 함께 빠짐없이 수록되어 있으니, 개발할 때 곁에 두면 친절한 선배 개발자의 음성을 들으실 수 있을 테구요. 다른 책에서는 깊이 다루지 않는 오브젝티브-C의 핵심적인 내용들도 이 책에서 모두 배울 수 있을 겁니다.

마지막으로, 이전에 프로그래밍을 전혀 경험해보지 못한 분들도 쉽게 배울 수 있는 난이도를 들 수 있습니다. 베스트셀러를 여러 권 집필한 경험이 있는 저자 스티븐 코찬(Stephen Kochan)이 초보자들도 쉽게 배울 수 있도록 친절하게 설명해준답니다. 오브젝티브-C를 공부하기 전에 C를 공부할 필요가 없다는 말이지요! ^^

번역은 박세현 님께서 맡아주셨는데요. 같은 기간에 오브젝티브-C와 관련된 또 다른 서적(『아이폰과 맥 OS X 개발을 위한 오브젝티브-C 2.0』)까지 번역하셨으니 정말 놀라울 따름입니다. 혹시 멀티태스킹이 되시는 건 아닌지... ^^

이로써 인사이트 내에서도 아이폰/맥 애플리케이션을 개발할 때 필요한 책은 왠만큼 구비가 되었습니다. 아이폰 애플리케이션을 만들려는 분들은 『터칭! 아이폰 SDK 3.0』으로 시작하시고, 맥 애플리케이션을 만들려는 분들은 『코코아 프로그래밍』으로 시작하시면 되겠네요. 여기에, 오브젝티브-C의 깊은 곳을 이해하지 않은 채 아이폰/맥 개발을 한다는 건 진정한 프로그래머가 아니라고 생각하시는 분들은 『프로그래밍 오브젝티브-C 2.0』으로 마침표를 찍으시면 되겠습니다.

자... 지금 강컴, 교보문고, 예스24, 인터파크에서 예약판매 중이니, 준비된 사수부터 엎드려 쏴! 질러주세요! ^^

아이폰 SDK 3.0의 이벤트 처리를 배워봅시다

너굴; — Wed, 19 Aug 2009 10:40:17 +0900

드디어 많은 분들이 기다리신 『터칭! 아이폰 SDK 3.0』이 발간되었습니다. '세계 최초!'라는 타이틀은 아쉽게도 『Beginning iPhone 3 Development』에 빼았겼지만 그래도 국내 최초는 말할 수 있겠네요. ^^

인터넷 서점에서 예약 구입을 하신 분들이라면 빠르면 오늘(19일) 오후부터 책을 받아보실 수 있을텐데요. 서점에 가지 않고도 내용을 살펴보고 싶은 분들을 위해 6장 「이벤트 처리」의 pdf 파일을 공개합니다.

아이폰 6장.pdf

6장에서는 먼저 아이폰 3.0의 이벤트 처리 방식을 배웁니다. 쉽사리 이해되지 않을만한 내용들은 아래와 같은 그림으로 친절히 설명해주지요.

이벤트의 발생과 소멸

이어서 멀티 터치, 두드림(tap), 닦아내기(swipe), 집기(pinch) 동작을 구현해보고, 3.0에 새롭게 추가된 흔들기 동작을 사용하여 실행 취소와 실행 복귀 기능도 사용해봅니다. 실행 취소와 실행 복귀가 엉키면 어떤 작업이 어떻게 진행되어야 하는지 혼란스러울텐데 이렇게 조금 복잡하다 싶은 내용들은 그림으로 설명합니다.

실행 취소/반복에 따른 스택 변화

마지막 부분에서는 역시나 3.0에 새로 추가된 클립보드 기능을 활용하여 베껴두기(cut)와 붙이기(paste)를 구현하면서 6장이 끝납니다.

붙여넣기 구현

저자이신 강덕진 님의 블로그(http://maclove.pe.kr)에도 재미있는 내용들이 많으니 들러 주시구요. 『터칭! 아이폰 SDK 3.0』을 구매하신 후 발송되기까지 설레는 마음을 즐겨보셔도 좋겠지요. ^^

정규 표현식과 오탈자 귀신 그리고 최댓값?

JOE; — Fri, 14 Aug 2009 17:40:26 +0900

정규 표현식이 발간된 지도 벌써 2주가 되었습니다.

'많은 사람에게 필요한 정규 표현식, 허나 무엇을 참고삼아 봐야 할지 모른다는 이 난감함'이라는 점에 착안해 책을 내었는데, 예상보다 많은 분이 관심을 가져 주시는 듯합니다.

그런데 책을 내고 2주도 채 지나지 않아 (건수로 치면) 네 건의 오탈자 신고가 들어왔습니다. 편집자로서는 성심성의껏 오탈자를 체크했는데, 이럴 때면 항상 뜨끔하기도 하고 아차 싶기도 하고 그렇습니다. 더군다나 글자 하나, 기호 하나가 첨가되느냐 누락되느냐에 크게 좌우되는 정규 표현식이기에 더더욱 아뿔사, 싶었지요.

그런데 오탈자 신고를 받고 보니 중복된 신고들이 보이더군요. 바로 최댓값과 최솟값입니다.

최댓값 vs 최대값, 최솟값 vs 최소값

최댓값일까요 최대값일까요, 최솟값일까요 최소값일까요.

답이 뭔지 너무 빤하게 질문을 던졌나 봅니다.

거두절미하고 말씀 드리면 최댓값, 최솟값이 옳은 표현입니다.

최댓값

「명사」『수학』

실숫값을 취하는 함수가 그 정의구역 안에서 취하는 가장 큰 값. ≒최대치「2」.

「반」최솟값.

최솟값

「명사」『수학』

실숫값을 취하는 함수가 그 정의구역 안에서 취하는 가장 작은 값. ≒최소치.

「반」최댓값.

출처: 국립국어원

수학책에서 항상 보기를 최대값, 최소값으로 나와 있어 그런 줄로만 알았는데, 약간 새로운 충격이었달까요.

제30항 사이시옷은 다음과 같은 경우에 받치어 적는다.
2. 순 우리말과 한자어로 된 합성어로서 앞말이 모음으로 끝난 경우
출처: 한국어문규정집2008

'값'은 순 우리말, 최대/최소는 한자어이며 최대(한자어) + 값(순 우리말)이 되어 위 법칙에 따라 최댓값으로 표기하지요.

(비슷한 말로는 목푯값, 기댓값, 절댓값 등이 있습니다.)

『손에 잡히는 정규 표현식』으로 열심히 공부하시는 독자분들 덕에 담당 편집자도 오랜만에 공부다운 공부를 한 듯합니다.

사실 정규 표현식 서적에 있어 가장 중요한 것은 바로 패턴과 예문이지요. 하여 한글 맞춤법에도 주의를 기울였지만, 예문에서는 단 하나의 오탈자도 허용하지 않겠다는 비장함으로 교정을 보았습니다.

그런데 정말 편집할 때는 오탈자 귀신이라는 게 있나 봅니다. 결국엔 이렇게 오탈자가 나와 버리니 말입니다.

오탈자 신고를 접수 받을 때마다 낯이 상당히 뜨거워지는 경험을 하곤 하는데, 완성도 높고 질 좋은 책을 위한 가시밭길이라고 생각한다면 감수할 만한 민망함이겠지요?

초판이 어서 빨리 팔려서 2쇄를 인쇄할 때 반영하고 싶은 마음이 큽니다.

지금까지 오탈자를 향한 편집자의 소박한 넋두리였습니다.
(더불어 소심한 판매 기원까지:))

하나 더,

『손에 잡히는 정규 표현식』으로 공부하실 분들에게 알립니다.

스프링노트 정오표를 꼭 미리 참조하세요~!