Archive for April, 2009


한계? 그곳에서 한걸음 더 나아가기

Wednesday, April 22nd, 2009

자주 들리는 빌딩의 엘리베이터는 무척 느립니다. 정말로 느려서 절묘한 타이밍으로 엘리베이터를 놓치면, 오랫동안 기다려야 하는 사태가 벌어집니다. 물론, 정확히 말하자면 엘리베이터가 느린 것은 아니고, 문열고 닫는 시간이 보통 엘리베이터에 비해서 정말로 깁니다. 그래서 엘리베이터를 놓치는 경우, 차라리 가까운 층은 걸어서 올라가는 편이 낫습니다.

며칠 전, 밤 늦게 그 빌딩에 갈 일이 생겼습니다. 그날도 운수 좋은 날인지 엘리베이터 앞에 도착했을 때, 엘리베이터는 방금 출발한 상태였습니다. 3층에 볼 일이 있었기 때문에, 엘리베이터를 기다리기를 포기하고 계단으로 올라 갔습니다. 계단을 돌아 2층에 도달했을 때, 평소 같으면 열려 있을 2층 계단 문이 닫혀 있더군요.

2층으로 통하는 문의 손잡이를 돌려봤지만, 문은 열리지 않았습니다. 왠지 모를 불안이 엄습했죠. “혹시 3층 문도 잠겨 있는 거 아니야?”하는 생각이 들었기 때문이죠. 3층으로 통하는 계단을 반쯤 올라가서 3층 문을 쳐다봤습니다. 평소 같으면 활짝 열려 있을 3층 문도 닫혀 있더군요.

이런!

떠나버린 엘리베이터를 참을성 있게 기다리지 못한 과거의 제 자신을 탓하면서, 발걸음을 돌려 다시 1층으로 내려갔습니다. 아까 올라간 엘리베이터가 아직 내려오지 않았는지, 엘리베이터는 꼭대기 9층을 찍고 내려오기 시작했습니다. 엘리베이터는 중간에 몇 번 섰기에, 역시나 오랫동안 1층에서 기달려야 했습니다.

드디어 1층에 도착한 엘리베이터를 타고, 전 3층 버튼을 눌렀습니다. 다행히 같이 탄 승객 가운데 2층을 누르는 사람이 없어서, 엘리베이터는 고속으로(?) 3층에 도착했습니다. :) 엘리베이터에 내려서 굳게 닫혀 있던 3층 계단문 손잡이를 봤습니다. 그런데 잠금 장치의 위치가 조금 이상했습니다. ‘혹시나 ‘하는 생각에 문 손잡이를 돌려봤더니, 문이 열리더군요.

아~ 정말!

***

몇 달전 토요일 낮에 지인과 점심을 먹고 있을 때, 지인이 고객에게서 전화를 받았습니다. 지인의 고객은 공장에서 자재를 관리하는 사람이었는데, 일요일에 공장을 돌리기 위해서 지인이 공급하는 원재료가 필요했죠. 지인이 납품하는 원재료는 창고에 보관된 상태였습니다. 그런데 토요일에는 창고 직원들이 오전 근무를 마치고 퇴근하기 때문에, 지인의 고객에게 원재료를 납품할 수 없을 가능성이 높았습니다.

지인의 고객은 무척이나 다급한 듯, 지인에게 꼭 원재료를 일요일 오전까지 납품해달라고 요청했습니다. 지인은 최선을 다해보겠다고 말을 전하고 나서 전화를 끊고, 출고를 담당하는 부하 직원에게 전화를 걸어서 “중요한 고객이고, 고객이 무척 급한 상황이니까 창고직원들하고 통화를 해서 납품할 수 있게 처리하라”고 지시를 내렸습니다.

시간이 조금 지나고 나서, 출고 담당 직원이 다시 전화를 걸었습니다. 출고 담당 직원은, 창고 직원들과 통화를 해보니 모두 퇴근한 상태여서 월요일 오전이나 되서야 출고할 수 있다고 이야기하는 듯했습니다. 부하직원의 이야기를 들은 지인은 이렇게 말했습니다.

중요한 고객이고 모처럼 우리한테 어렵게 하는 부탁이라고 말했잖아. 그런데 창고 직원들이 퇴근했다는 말을 듣고 나한테 그대로 전하면, OO씨가 한 일은 내 이야기를 단순히 창고 직원들한테 전한 꼴이잖아. 내가 OO씨에게 바라는 것은, 어떻게 하든 창고 직원들하고 이야기를 해서 일요일 오전에 고객에게 물건이 전달되게 하는 것이란 말이야. 그 과정에서 내가 지원해 줄 게 있다면, 나에게 도움이 필요하다고 이야기하는 게 더 건설적이겠지. 다시 한번 창고 직원들하고 통화해서 일이 되도록 만들어 봐.

지인은 전화를 끊고 나서, 부하 직원이 일을 어떻게 잘 처리할지 걱정하더군요. 30분 정도 시간이 흐르고, 부하 직원이 다시 전화를 걸었습니다. 지게차 기사분들에게 추가 수당을 지급하고, 창고 직원이 다시 출근해서 제품을 출고하기로 설득했다는 좋은 소식을 전했습니다. 지인은 부하 직원의 깔끔한 일처리를 칭찬하면서 전화를 끊었습니다.

후일담으로 들은 바에 따르면, 지인의 푸쉬 덕분에 부하 직원이 일처리하는 방법을 배웠다고 고마워했다고 합니다.

***

2층 문이 닫혔다고, 3층 문도 닫혔을 것이라는 설익은 추측으로 삽집을 했던 저나, 퇴근했다는 창고 직원들의 말을 듣고 토요일 출고는 불가능하다는 말을 전한 직원, 모두 피상적인 한계에 봉착했을 때 발걸음을 돌리는 선택을 했습니다. 인생은 선택의 연속이고, 여러 선택 가운데 더 나아가는 선택말고 돌아가는 선택을 해도 얻는 게 있다는 게 인생의 묘미이지만…

스스로 만든 한계 속에서 더 나아가지 못하는 게 아닐까요? 사실, 몇 걸음 더 옮겨서 문손잡이를 돌려보는 수고를 더 하거나, “죄송하지만 다시 창고에 가셔서 오늘 출고해 주시면 안 될까요?”라는 부탁을 하는 것은 큰 일도 아닌데, 그것을 하지 못해 우리는 쉽게 가거나 조금 더 얻을 수 있는 것을 놓치는 게 아닐까 합니다.

꼬랑지 : ‘겸손한 개발자~’ 출간 이벤트의 참여율이 저조합니다. 아직 아차상의 기회가 많이 남았습니다. 한걸음만 나아가시면 아차상의 기회가? 자 도전해 보세요~

[이벤트] 겸손한 개발자가 만든 거만한 소프트웨어

Thursday, April 16th, 2009

인사이트에서 ‘겸손한 개발자가 만든 거만한 소프트웨어’ 출판 기념으로, 이벤트를 진행하고 있습니다. 이벤트 내용은 프로젝트에 참여하시면서 의사소통에서 겪은 문제점이나 해결책을 적어주시거나, 의사소통과 관련된 가상의 상황을 블로그에 작성하셔서 인사이트의 블로그로 트랙백을 걸어주시면, 세 분을 추첨해서 회의시간에 미스터 피자 2판을 드린다고 합니다.

추첨이 안 되셨더라도, 아차상으로 응모하신 10분에게 ‘겸손한 개발자가 만든 거만한 소프트웨어’를 드린다고 합니다. 아직 많이들 응모하시지 않은 걸로 봐서, 적어도 책을 받으실 가능성이 농후한 듯합니다. :)

이벤트 상세 안내

[출판공지] 겸손한 개발자가 만든 거만한 소프트웨어

Wednesday, April 8th, 2009

드디어 두 번째 쓴 책이 나옵니다. 책에 얽힌 뒷이야기는 시간이 나는대로 적어보겠습니다. 이번에도 열심히 썼습니다. :)

겸손한 개발자가 만든 거만한 소프트웨어

리뷰

추천사

김준기 KAIST 학사과정

학부 3학년 때, 소프트웨어공학개론 수업을 들었습니다. 당시 수업에서 사용한 방법론은 바로 ‘폭포수 모델’이었죠. 하지만 아주 기본적인 변수 명부터 검사 로직에 이르기까지 팀원들 사이에서 서로의 생각을 동기화시키기 위해서는 엄청난 노력이 필요했고, 결국 수많은 밤을 새하얗게 불태우고 말았습니다.“지금 알고 있는 걸 그때도 알았더라면…”하는 생각을 가끔 해봅니다. 생각의 동기화란 무형의 대상을 다루는 소프트웨어 개발에선 아주 중요한 부분이고, 그때 필요한 방법들을 알고 실천하는 것은 “협업에 참여하는 개발자로서 필수 요소입니다.

학생이지만 텍스트큐브(Textcube)라는 꽤 큰 규모의 오픈소스 프로젝트에 3년 넘게 참여하면서 모든 사용자의 요구를 반영하기란 결코 쉽지 않은 일임을 깨달았습니다. 텍스트큐브가 어느 날 bloatware라는 소릴 들었을 때, “결국 이런 결과가 나오는구나.” 하는 생각을 했죠. 수많은 기능들을 넣다 보니 겸손한 개발자가 만든 텍스트큐브지만 누군가에게는 거만한 소프트웨어가 되어버린 것입니다. 아쉽게도, 학교 수업에서 배우는 것만으로는 이런 어려움들을 직접 경험해보기가 쉽지 않습니다. 이 책을 읽으면서 제 또래 학생들도 간접 경험을 해봄과 동시에 과제로 나온 팀 프로젝트에 글쓴이가 제시하는 방법들을 직접 적용해본다면, 앞으로 만날 수많은 협업을 성공적으로 이끌 수 있으리라 생각합니다.

박일 『스크럼』의 역자, NC소프트

수많은 게임 개발팀들이 새로운 게임을 만들기 위해 노력하고 있습니다. 그리고 그 숫자만큼이나 많은 게임들이 공개도 되지 못한 채로 접히게 됩니다. 제가 겪은 경우나 다른 분들의 얘기를 들어보면, 프로젝트가 접히는 가장 큰 이유는 기술력의 부족이 아니었습니다. 오히려 팀원들 간의 의사소통 부족이나 내부 갈등으로 인한 개발자들의 이직, 재미 요소의 검증 부재, 불편한 UI 같은 것들이 게임 프로젝트를 망치는 대표적인 이유였습니다.

『겸손한 개발자~』는 이전 책이었던 『도와주세요. 팀장이 됐어요』에서 한발 더 나아가 ‘어떻게 하면 프로젝트를 성공시킬 수 있을 것인가?’에 대한 실질적인 조언을 제공합니다. 책을 쭉 읽어본 후에 “우리 팀은 어떻게 더 좋아질 수 있을까?” “우리 프로젝트를 어떻게 더 개선할 수 있을까”를 고민해 본다면, 내 자식같이 소중한 프로젝트가 성공적으로 런칭할 가능성이 조금이나마 높아질 것입니다.

우리에게도 이런 내용의 책을 쓸 수 있는 저자가 있다는 것이 고맙습니다. 지금 코딩하는 데 바로 필요한 책은 아닙니다. 하지만 읽어둔다면 언젠가 어디선가 잘못될 위험을 줄여줄 수 있는 비타민 같은 책입니다. 앞으로도 자신의 경험을 잘 엮어서 알려주실 저자분들이 많이 나오길 기대합니다.

안영회 (주)아이티와이즈 컨설팅 SE그룹 컨설턴트, 한국스프링사용자모임(KSUG) 대표

‘IT’, ‘SI’, ‘전산’ 등등 나름대로 규정지어 불리는 이 바닥에 대해 이만큼 알찬 산문은 처음 본다. 다양한 소재의 공감할 만한 글이 가지런히 잘 정리되어 있다. 앞장을 차지하는 글은 산업 초기라 그러리라고 짐작하지만, 소비자가 아닌 공급자 주도적 혹은 기술 주도적인 애플리케이션 개발의 단점을 꼬집고 자연스럽게 바람직한 방향을 이야기하고 있다.뒤 이어, 소프트웨어 개발을 둘러싼 조직의 문제를 이야기한다. 뜨거운 감자인 보상 문제 그리고 당연하게 강요되는 초과 근무 문제를 다룬다. 후반부는 프로젝트 관리에서부터 요구사항을 도출하고, 팀 협업을 끌어내는 과정에 대하여 생생하게 쓰고 있다. 이 부분은 저자의 이전 저술인 『도와주세요! 팀장이 됐어요』에서 이야기한 내용이 발효 과정을 거쳐 나타난 듯하다.

여러분이 만일 사용자에게 불평을 품어봤거나 야근에 지친 개발자라면 이 책은 다른 시각으로 우리의 현실을 볼 기회를 제공한다. 여러분이 만일 개발자에게 어렵게(?) 무언가 요구를 해야 하는 위치에 있는 기획자이거나 현업 개발자는 왜 그렇게 꽉 막혔는지 이해할 수 없는 분이라면 이 책이 흥미로운 사실을 알려줄 것이다. 그리고 여러분이 우리나라가 IT 강국이라고 해서 프로그램도 잘 만들 것이라 기대하고 있다면 이 책은 담담하게 현실을 이야기해준다. 마지막으로 프로젝트에서 팀장이나 관리자 로 일하면서 조언이 필요한 분이라면 당장 이 책의 후반부를 훑어보라고 권해주고 싶다. 우리나라에도 이런 개발자 산문 하나쯤 필요하다고 느꼈는데, 저자가 선수를 쳐서 책을 쓸 필요가 없어졌다. :)

유석현 디자인피버 Digital Experience Division UX 팀장

사용자의 경험을 예측하고 설계하고 방향성을 정립해야 하는 입장에서 보면 하나의 괜찮은 조언집이다. 난 소프트웨어 개발자가 아니고 사용자 경험(UX)을 설계하고 디자인하는 디자이너다. 처음 원고를 전달받을 때는 “이거 진짜 개발자들 이야기가 아닐까?”라고 생각했지만 한장 한장 원고를 넘기다보니, 실제로는 사용자 경험을 설계하고 만들어내는 사람들과 그런 조직 그리고 결과물에 대한 이야기였다. 사용자의 경험을 예측하고 설계하고 방향성을 정립해야 하는 입장에서 본다면 하나의 괜찮은 조언집이랄까. 단 한 줄의 소스코드도 없이, 포토샵 이미징 방법에 대한 이야기도 없이, 개발과 디자인과 결과물을 이야기 한다.

이 책은 소프트웨어를 만드는 개발자의 이야기를 골자로 하고 있다. 하지만, 실제로는 프로젝트를 수행하면서 겪는 많은 불필요한 과정들과 일상적으로는 이슈가 되지 못한다고 생각하지만 알고 보면 큰 이슈가 되는 문제에 대하여 친절하고도 쉬운 문체로 풀어놓고 있다. 일선의 개발자들뿐만 아니라 디자이너들 역시도 이 책을 읽어보기를 권한다.

그러나 사용자 경험(UX)이 대두되어 있는 지금의 업계 상황에서, 이 책은 더 이상 개발자나 디자이너만의 이야기가 아니다. 특히 경영자들의 시각에서 본다면 현재의 조직과 미래의 조직을 분석하고 설계하는 데에도 좋은 통찰을 줄 수 있을 거라 생각한다.

그렇다고 해서, 반드시 여기에 나와 있는 방법론을 따라야 한다는 이야기는 아니다. 조직의 현 상황과 다가올 미래의 상황에 맞게끔 리드미컬하게 최고의 소프트웨어와 사용자 경험(UX)을 설계하는 것이 좋다. 그것이 사용자 경험(UX)을 고려한 소프트웨어 만들기의 핵심적 가치다.

우리는 종종 주위의 지인들과 술을 마시거나 이야기를 하는 과정에서 좋은 생각(insight)을 얻는다. 이 책은 마치 경험 많은 선배 개발자/디자이너가 “이런 상황에서는 이렇게 하는 것이 어떨까?”라고 진지하면서도 기분 좋게 조언해주는 느낌이다. 원고를 받은 후, 퇴근하는 지하철에서 피식피식 웃으며, 때로는 집중해서 원고를 읽느라 6호선 이태원역을 지나친 적이 한두 번이 아니었다. 그만큼 이 책이 주는 사용자 경험은 즐겁다.

이만우 삼성전자 반도체 총괄팀 『도전! 임베디드 OS 만들기』의 저자

저자는 소프트웨어 개발 과정에서 소프트웨어가 ‘거만함으로 이어지는’ 여러 가지 문제에 대해 풍부한 경험과 통찰력으로 설명해 준다. 그리고 어떻게 하면 거만한 소프트웨어를 만들지 않게 프로젝트 팀을 이끌어야 하는지 설명한다. 자신의 프로젝트 진행에 대해 한 번이라도 진지한 고민을 해본 사람이라면 이 책을 읽어보고 그 해답을 얻길 바란다.

이준하 월간 마소「열이아빠의 RIA 이야기」의 필자

정말 오랜만에 책을 손에서 떼지 못하고 본 것 같다. 대형 프로젝트 경험이 없더라도 소프트웨어 개발에 참여해본 독자라면 어느 부분에서나 공감할 만한 상황들이 눈앞에 펼쳐진다. 마치 내 메신저 대화내용을 훔쳐본 것처럼 고민하고 있던 이야기들이 내 시선을 끌게 되고, ‘이거 뭐 다른 대안이 있을까’ 하는 호기심에 다음 장을 넘기게 된다.

왜 이런 일들이 끊임없이 나의 인생에 태클을 걸고 있는지, 수많은 밤샘의 결과가 사용자들에게는 왜 개떡 같은 결과로만 보이는지, 무엇이 발목을 잡고 있는지, 어떻게 변해야 하는지가 저자의 빡센 경험 속에 녹아있는 이야기들과 적절한 사례를 통해 드러난다. 바로 ‘어, 이렇게도 할 수 있겠구나! 하고 고개를 끄덕이게 된다. 사용자 경험이나 애자일과 같은 이야기가 외국 회사에나 있는 이야기라는 선입관을 가지고 있었다면, 이 책을 통해 내일부터라도 어떻게 실천할 수 있는지 만나보게 될 것이다.

최재훈 SK아이미디어 소프트웨어 개발자

이 책은 누구나 한번쯤 겪었을 경험담부터 이야기한다. 그리고 개발자와 조직의 관점에서, 사용자 경험의 관점에서 원인을 분석하고 모두가 만족하는 소프트웨어를 개발하는 방법을 이야기한다. 분석이 반이고 해결책이 반이지만 자칫 지루해지기 쉬운 구성은 저자의 박식함과 재치로 보상 받는다. 한번쯤 들어봤을 이론들이 등장하지만, 그것을 완벽히 흡수해 재창조하여 새로운 가치를 부여하는 저자의 재능이 빛난다.

황인석 KAIST 전산학과 박사과정, 『자바스크립트 완벽 가이드』역자

이 책은 얼핏 보기에 현직 개발자나 관리자를 위한 내용으로 단정하기 쉽다. 그러나 이 책의 메시지가 가장 절실한 독자층은 한창 자신을 연마중인 우리 공학도들일지 모른다.이 책은 사람, 소통이라는 키워드를 던지고 있다. 우리 공학도들은 밤새 머리를 쥐어뜯으며 컴퓨터와 정확히 소통하려 노력한다. 이 과정을 통해 우리의 작품에 완벽함을 더하고 혼을 심는다. 하지만, 앞으로의 실전에선 훨씬 불완전하고 모호한 언어를 이용해 소통해야 하는 대상이 있다. 바로 우리가 함께 일할 동료들, 우리의 소프트웨어를 사용할 사용자들이다.그들과의 효과적인 소통이 결핍된 소프트웨어는 그저 완고한 예술가의 이해하기 힘든 작품이 되어 사람 위에 군림하려 할지 모른다.

이 책의 저자가 선사하는 풍부한 사례와 재치 있는 비유를 통해 거만한 소프트웨어를 예방할 수 있는 실전 노하우를 찾아보자. 카페인과 콜레스테롤을 주식으로 삼아온 우리들에게 영양의 균형을 찾아줄 소중한 비타민이 될 것이라 믿는다.

온라인 구매

자주 쓰지만 잘못 사용하는 단어

Monday, April 6th, 2009

가벼운 마음으로 ‘글쓰기 필수 비타민 50‘이라는 책을 읽었는데, 평소에 아무 생각 없이 쓰던 단어들을 틀리게 사용해 왔다는 것을 알게 되었습니다. 의외의 소득이었죠. ;) 명명백백하게 사실이라고 생각했던 게 거짓으로 판별되는 순간, 다른 사람에게서 전해 들은 것 가운데서 잘못된 게 제법 되리라는 생각이 듭니다.

“악법도 법이다.”라는 소크라테스가 남긴 유명한 말을, 사실 소크라테스가 하지 않았다는 사실을 알았을 때, 제법 신선한 충격이었습니다. 귀에 딱지가 앉을 정도로 다른 사람들에게서 들은 지식을 인용할 때, 이런 실수를 저지르기 쉬운데요. 특히, 글을 쓰면서 다른 사람에게서 전해듣거나 인터넷에서 읽은 지식은 반드시 참고문헌을 찾아서 해당 지식을 검증하는 부지럼함이 필요하죠.

글을 마무리하면서 책에서 읽은 잘못 사용하는 단어 몇 가지를 소개해 드립니다. 글 쓰실 때 참고하세요.

1)옥석구분

우리는 ‘옥석구분’이라는 말을 쓸만한 사람과 아닌 사람을 구분할 때 흔히 사용하죠. 하지만 옥석구분의 본래 뜻은 이런 뜻이 아니라, 서경에 나오는 “火炎崑岡 玉石俱焚”에서 유래한 단어라고 합니다. 즉, “곤륜산에 불이 붙으면 옥과 석이 모두 탄다.”하는 뜻으로서 옳은 사람과 그른 사람에 관계없이 모두 재앙에 처한다는 의미가 있습니다.

물론 한국어로 발음을 봤을 때, ‘구별하다’의 ‘구분(區分)’과 ‘모두 탄다’의 ‘구분(俱焚)’이 동일하기 때문에 이런 오해가 생겼죠. 이제는 흔히 사용하는 단어라서 이상하지 않지만, 이런 뜻이 있다는 것을 알았다면 앞으로 조금 주의해서 사용해야겠네요.

2)산수갑산

“산수갑산에 가더라도 우선 먹기나 하자.”하는 말이 있습니다. 여기서 사용한 산수갑산은 삼수갑산을 잘못 사용한 예라고 합니다. 삼수(三水)와 갑산(甲山)은 함경도 군의 이름으로서, 유배지로 유명했다고 합니다. 따라서 삼수갑산에 간다는 뜻은 ‘어떤 어려움을 겪더라도’라는 의미입니다. 그런데 사람들이 삼수를 산수라고 단정해서 사용하다가, 근래엔 산수를 많이 사용하게 되었습니다. 산수를 많이 사용하지만 그래도 ‘삼수갑산’이 맞는 표현이겠죠.