한날의 낙서 [Hannal's scribbling]

문제, 문제, 문제

• 대체 왜 기획자는 개발자가 필요로 하는 내용을 기획서에 담지 않는지,
• PM은 왜 툭하면 시연 등을 요청하여 개발 일정을 뒤틀어 놓는 것인지,
• 개발자는 함께 일정을 잡아놓고선 만날 야근하고도 일정을 지키질 않는지,
• 다른 조직의 개발자는 이틀이면 된다는 일을 왜 우리 팀 개발자는 일주일짜리 일이라고 하는지,
• 왜 그리도 개발자는 하드디스크가 잘 고장나서 소스 파일을 날려먹는 일이 여느 사람보다 훨씬 많은 것인지,
• 기껏 다 만들었더니 왜 요구한대로 만들지 않았냐고 사장님이 버럭 화를 내시는 것인지,
• 우리는 우리대로 손해보고, 고객은 고객대로 사기 당한 것 같은 얼굴을 보이는 일은 왜 그리도 잦은지.

해결을 하는 것이 문제

프로젝트를 진행하면서 이러한 상황을 종종 볼 수 있다. 경력이 많은 사람일수록 설화인지 전설인지 구분하기 어려운 무용담, 아니 개발담을 많이 갖고 있다. 그리고, 이런 상황을 해결할 수 있는 방법은 경력자 수만큼, 혹은 서점에 있는 책 개수만큼 많다. 예를 들면, 개발자에게 필요한 내용이 기획서에 제대로 나와있지 않다면 화술이나 대인관계론을 공부하여 기획자를 효과있게 구박하거나 기획자에게 개발 공부를 시켜서 상황을 해소하는 식이다.

이런 방법들이 틀린 것은 아니다. 그러나, 여러 톱니바퀴가 맞물려 돌아가는 상황에서 어딘가 이빨이 맞물리지 않아서 문제가 발생했다면, 각 톱니바퀴를 절대 망가지지 않는 초합금으로 만들고 금테를 두르는 것만으로는 문제를 해결하기 어렵다. 톱니바퀴 자체가 아니라 톱니바퀴가 맞물려 돌아가는 전체 흐름, 즉 개발 공정을 봐야 한다.

훌륭한 소프트웨어 개발을 위한 방법을 쉽고 재미있게 배우자

Head First Software Development 는 개발 공정을 주제로 하는 방법론을 다루고 있다. 개발 공정 중 일부에 대해서, 혹은 방법론을 깊이 다루지 않는다. 소프트웨어 개발의 전체 흐름, 그리고 개발할 소프트웨어와 관계된 이해당사자에 대해 이야기를 하고 있으며, 이러한 내용을 가상으로 프로젝트를 시작하고 완료하는 공정에 비추어 친절하게 설명한다.

책 이름이 개발자를 위한 것 같지만, 실은 기획자나 프로젝트 관리자(PM)도 함께 봐야 할 책이다. 이들이 숙지해야 할 내용이 있기 때문에 그렇기도 하지만, 다정하고 친절하게 개발 공정을 설명하는 책이기에 그렇기도 하다. 마치 이야기 구성이 잘 짜여진 소설을 읽듯이 프로젝트 시작부터 완료까지 개발 공정 이야기를 편안하고 쉽게 읽을 수 있다.

내용 구성

책은 크게 계획, 업무 정의(사용자 스토리, 태스크), 이터레이션, 버전 관리, 테스트, 버그 관리에 대해 다루고 있다.

계획 과정에서 고객의 요구사항 파악 및 우선순위 도출을 하고, 사용자 스토리를 기반으로 업무(task)를 정의한다. 이 업무는 조직의 개발 속도 등을 감안하여 이터레이션(iteration)을 나누어 진행하며 마일스톤으로 향한다. 물론, 각 이터레이션에는 협업 환경에서 필수인 버전 관리 체계 따르기, 테스트 기반 개발(TDD : Test Driven Development), 그리고 버그 추적 및 관리를 하여 품질 관리 과정이 녹아 있다.

이 책은 이러한 각 과정을 12장(chapter)에 걸쳐 꼼꼼하고 친절하게 다루고 있다. 좀 더 자세히 말하자면, 책 구성과 내용이 주제보다는 독자에 기준을 두고 쓰여졌다는 생각이 들 정도이다. 이야기 전달력(스토리텔링)이 높다. 다른 기술서에선 한 두 단락으로 다룰 내용을 이 책은 내용 전달을 위해서 여러 쪽에 걸쳐 최대한 쉽게 풀어쓰고 각종 그림을 동원하기도 하고, 400장이 넘는 내용을 한 두 쪽짜리 연습문제로 내며(460쪽~463쪽) 깔끔하게 정리해서 책 이해를 돕는다.

이 정도면 불친절하고 꺼칠한 사수보다 Head First 책들이 더 낫다는 생각이 들지 않을까?

아쉬운 점

좋은 점이 참 많은 책이다. 하지만 아쉬운 점도 있다.

우선 책을 읽으면서 이러한 친절이 좀 과하다고 생각이 드는 점을 들 수 있다. 그림이나 사진 등으로 전달력을 높이는 건 좋은데, 오히려 시선을 흩뜨려서 집중을 해치는 경우도 간혹 있다. 나는 책에 줄을 긋거나 생각을 적으며 책을 읽는데, 이 책에 그러면 정돈되지 않아 산만해지는 꼴이 되어 버린다.

두 번째는 심심치 않은 오탈자이다. 다행히 뜻을 해치는 수준은 아니므로, 옥에 티가 뭍은 수준이라 할 수 있다.

서평을 마무리하며

앞서 말했듯이 난 이 책을 개발자 뿐만 아니라 기획자나 PM도 꼭 읽어야 한다고 생각한다. 책은 자바(Java)나 C#, C++ 같은 프로그래밍 언어를 알아야 한다고 하지만, 프로그래밍을 몰라도 충분히 소화할 수 있다. 그만큼 쉽게 이해하도록 쓰여져 있다.

설령 프로그래밍 언어를 몰라서 내용을 이해하기 어렵더라도 개발자에게 모르는 걸 물어보며 개발 공정을 이해하도록 노력해야 한다고 생각한다. 개발 공정이라면 마땅히 개발이 어떤 공정으로 흐르는지 알아야 하는데, 기획자나 PM은 “공정”에 자신만의 관점과 생각을 반영하여 개발 과정에서 소통 차질을 일으키곤 한다. 이런 문제는 개발 공정 중 “개발”에 지식을 쌓으면 어느 정도 해소되지만, “개발 공정”을 이해하여 개발과 공정 모두를 잡을 수도 있다. 물론, 프로그래밍이나 그래픽 디자인처럼 기획을 구현하는 “개발” 영역을 이해한다면 금상첨화이다.

이제 글을 열며 제기한 문제들을 해결하는 방법 하나를 꼽으며 글을 닫으려 한다. 이 책을 곁에 두고 읽으며 실천해보는 것이다.

책을 받다. 뒤통수를 맞다

OTL English

a77ila님께서 책을 내셨다며 하나 보내주신다는 말씀에 무척 고맙고 기대했다. 더욱이 영어에 대한 책이라고 하셔서 기대감은 더욱 컸다. 내가 영어를 못하기 때문에 그렇기도 하고, 그동안 a77ila님께서 블로그에 써오신 글을 보건데 분명 정석, 정론이라는 낱말이 딱 떠오를 책을 쓰셨을 것이라 생각했기 때문이다.

얼마 후 책을 받아 보고나서 뒤통수를 강하게 얻어맞은 기분이 들었다. 그것도 무려 세 방. 미리 말해두자면, 가장 세고 아팠던 한 방은 맨 마지막 것이다.

한 방은 내 예상을 깨는 내용, 그러니까 마치 임시 처방이나 철학이 없는 자기계발서를 떠올리게 하는 내용같아서 그랬다. 나 이런 책 무지 싫어한다. 심지어 빨리 뭔가를 이룰 수 있다고 하는 자기계발서 대부분은 사기책이라고 말할 정도이다.

또 한 방은 책 읽는 사람이 약오를만큼 공부를 정말 자~알 하셨기 때문이다. 자~알 했다는 말뜻은 성적같은 결과을 가리키는 것이 아니라 공부하는 과정을 가리키는 것이다. 책에 나온대로라면 a77ila님 눈에 나는 대단히 효율 떨어지고 지구만큼 두꺼운 책을 파고들 고지식쟁이이다. 책을 사면 1쪽이나 머릿말도 아니고, 표지 앞장에 있는 책 이름부터 꼼꼼히 보기 시작해서 맨 마지막쪽이라 할 수 있는 표지 뒷장에 적힌 책값까지 본다. 모르면 다시 읽는다. 물론, 다시 읽을 때는 목차를 보고 다시 볼 부분만 다시 읽지만.

a77ila님은 어떠하던가. 흔히 하는 말로 선택과 집중을 아주 잘하며, 집중도 들입다 파고드는 것이 아니라 갈래화를 거쳐 두뇌에 있는 방 중 잘보이는 곳곳에 예쁘장하게 넣는 것이다.

이쯤되면 제대로 당했다는 생각이 든다. 여느 때라면 “아뿔싸… 속았다. 뭐에 속은지 모르겠지만 아무튼 속았다. 그래서 더 약오르다”라고 중얼거렸을 것이다. 근데 더 당혹스러운 점은 그런 생각이 들지 않았다는 것이다. 내 입장에서는 인지부조화가 일어난 것이나 마찬가지이다.

이것이 세 번째 뒤통수 강타이다. 이 한 문장이 아니었으면 세 번째 뒤통수 강타는 없었을 것이다.

꼭 공부 못하는 사람들은 특징이 있는데, 그 첫 번째 특징은 자기가 뭘 하는지, 그리고 자기가 뭘 원하는지 도저히 감도 잡지 못한다는 것이다.

- 16쪽 중에서

English Hacking

a77ila님께선 원래 지으려던 책 이름은 English Hacking 이라고 하신다. 정말이지 이 이름이 더 어울린다. 이 책은 English Hacking 이 아니라 English Hacking 에 대한 내용을 다루고 있다. 현실성 있고 효율성 높게 공부하기 위한 각종 해킹 기법을 설명하는 것이다. 이 방법을 따른 공부 사례 중 영어를 든 것에 가깝다. 마치…

Hacking about Studying

- English 편 -

이런 인상이다.

이 책을 읽고 반성을 했다. 내 주 업은 기획이다. 회사 일이든, 개인 일이든, 놀러나가든, 구멍가게에 마실거리를 사러 나가든 기획 과정을 거친다. 기획이 몸에 배어 생활이 되었으며, 머리 속 생각 운용도 기획 논리 구조를 따른다. 그런데 공부 할 때엔 정말 무식할 정도로 계획과 기획없이 일단 달려들어 파고본다. a77ila님을 소환하여 책 내용에 나오는 그 친구분처럼 밥이라도 사드리며 뒤통수 맞아 마땅한데, 공짜로 책을 받아 맞았으니 이렇게 고마울 수가.

뒤통수 긁적이게 하는 아쉬움

책은 시종일관 재밌으며 글놀림은 경쾌하다. 비수처럼 파고드는 날카로운 문장이 살아 숨쉰다. 그런데 이 생생함을  어지럽히는 아쉬운 점이 있다.

먼저 모순으로 비춰질 수 있는 주장이 책 초중반과 중후반에 각각 나온다.

초중반에는 영어 얘기를 들을 때 맨 마지막에 들으라고 한다. 말을 하는 목적인 대상이 말 맨 뒤에 나오기 때문인데, 이는 영어 문장 구조가 주어 + 동사 + 목적어(절)이기 때문이다. Would F#df# $AF# coffee? 와 같이 말 앞부분을 대부분 놓쳐도 맨 뒤에 coffee가 나오니 대충 커피 마실 거냐고 묻는 것임을 알 수 있다는 것이다. 하긴. 목적어로 쓰이는 이름씨(명사)만으로도 소통이 가능하긴 하다.

그러나 이는 말(언어)과 소통으로 봤을 때 잘못된 내용이라 생각한다. 이름씨만 주고 받는 게 아니라 문장을 주고 받는 소통에서는 움직씨(동사)가 소통에서 뜻을 결정하는 역할을 한다. 그렇기 때문에 영어는 중요한 말이 앞에 배치되어 뒷부분을 놓쳐도 큰 지장이 없고, 우리말은 끝까지 들어봐야 뒷탈이 없다.

책에도 나오듯이 영어는 주어 생략을 허용하지 않는다. 그래서 가장 단순한 문장 구조이자 모든 영어 문장 구조의 근본이라 할 수 있는 주어 + 동사 구조가 거의 언제나 성립되는 것이다. 예외 상황이 별로 없다. 그래서 말을 주고 받을 때 뜻 전달에 필요한 핵심은 맨 앞에 다 나오는 셈이다.

이런 이유로 영어 특성 중 하나로 경제성이나 효율성을 말하는 것이다. 다행히(?) 이런 내용은 중후반에 나온다. 그렇기 때문에 초중반 내용과 중후반 내용이 부딪히는 것이다.

나머지 아쉬움은 첫 번째 아쉬움과 비교해서 아주 사소하다. 예를 들면, 우리글(한글)과 우리말(한국어)을 구분하지 않고 오용하는 것이다. 분명 말과 글은 다르다. 글은 말을 기호로 나타내는 도구일 뿐이다. 알파벳이 영어, 독일어, 프랑스어를 표기하듯이 말이다. 또 하나는 오타나 어색한 문장이 한 두 개 있는 정도. 마지막으로 꼽자면, 책값이 생각보다 비싸다.

공부 잘하고 싶다면, 영어 잘하고 싶다면 사도 좋은 책

첫 번째 뒤통수를 맞고 아직 얼얼한 상태에서 읽을 때만 하더라도 읽고나서 다른 사람이나 줘버려야겠다 생각했다. 그런데 읽다보니 힘차게 고개 끄덕이며 그동안 생각없이 공부해왔다는 억울함이 커졌다.

낱말은 일 대 일로 대응하는 뜻을 외우지 말고, 그 낱말이 어떤 상황과 쓰임새, 뜻으로 쓰이고 있는지 정황을 이해하고 상상하라는 말. 영영사전을 보는 목적이 바로 이것인데 어느 순간 영영사전에 나오는 영어 문장 자체를 외우는 실수를 했기에 더 뼈아프게 읽혔다.

영어 듣기가 되지 않는 이유는 영어를 읽으며 받아들이는 빠르기가 상대방이 말하는 빠르기를 쫓지 못하기 때문이라는 말. mp3가 닳고 닳아 음질이 떨어질 정도로 회화 mp3를 들었지만 내 귀에 들리는 것은 또렷한 영어 소리이지, 뜻이 아니었기에 더 뼈아프게 읽혔다. (참고로 mp3 를 아무리 듣는다고 음질이 떨어지진 않는다)

요즘 아는 사람이 영국 이민을 가려고 영어 공부를 하고 있다. 영어 공부나 공부법에 대해 얘기를 나누다 이 책을 추천했다. 이미 알아서 잘 공부하고 있지만, 그래도 이 책을 읽고 English Hacking 을 하여 더 높은 효율을 거두길 바라는 마음 때문이다.