'의사소통'에 해당되는 글 3

  1. 2010.12.20 피드백 이야기, 인생을 바꾸는 피드백
  2. 2009.11.02 아키텍트 이야기
  3. 2009.10.29 사랑하지 않으면 떠나라! (4)

피드백 이야기, 인생을 바꾸는 피드백

소통(Communication)이 중요하다는 것은 새로운 것은 아니다. 우리가 어떤 사회에 있던 그 사회 내에서의 소통은 정말 중요하다. 소통이야 말로 그 사회를 유지시키는 기본이 되면 건강한 사회를 만드는 밑거름이 된다.

이걸 모르는 사람은 없다. 하지만 많은 사람들이 알면서도 행하지 않는다. 왜 알면서도 소통하려고 노력하지 않는 걸까. 아마도 그 방법을 모르거나 미숙하기 때문이 아닐까 싶다. 사실 이건 나 또한 마찬가지다. 이에 대한 책들을 읽고 많은 생각을 하지만 막상 실천에 옮기려고 하면 그게 참 어렵다. 뭔가 쑥스럽기도 하고 또 내가 나서서 이렇게 해야 하나 싶기도 하고.

이렇게 시간이 지나가면 갈수록 소통 없는 사회, 조직은 허물어지기 마련이다. 여기저기서 삐그덕거리는 소리가 들리고 서로 간에 불신만이 쌓여간다. 늦었다고 생각할 때가 빠른 법. 후회할 때는 이미 늦은 것이다.

이 책에서는 소통의 가장 기본이 되는 피드백에 대한 이야기를 하고 있다. 피드백이 무엇인가? 다른 사람의 어떤 행동이나 말에 대해 대응을 하는 것을 말한다. 그런데 이 피드백이라는 것이 쉬운 건 아니다. 정말 어렵더라. 어떻게 하면 이런 피드백을 잘 할 수 있을까? 그리고 어떻게 하면 좋은 피드백이 되는 것일까? 이 책에서 우리는 이 질문에 대한 답을 찾을 수 있을 것 같다.

우리가 아는 가장 큰 오해 가운데 하나는 '말하지 않아도 알거야'다. 정말 가까운 사이에서는 표현하지 않아도 다 이해할 거라는 착각. 하지만 이런 혼자만의 믿음은 기실 무관심을 그럴듯하게 포장한 것뿐이다. 칭찬으로든, 미소로든, 비판으로든, 손짓으로든, 서로의 생각을 함께하지 않는 인간관계는 머지않아 황폐해지고 만다.

<피드백 이야기>, 리처드 윌리엄스 지음, 이민주 옮김, 토네이도, 2007년 3월, 책 표지.

우리가 잘못 생각하는 것 중 하나가 위에 나온 것처럼 표현하지 않아도 상대방이 알아줄 것이라는 것이다. 상대방이 어떤 생각을 하고 있는지 말하지 않는데 어떻게 그 사람의 생각을 알 수 있겠는가. 마찬가지로 내가 어떤 생각을 하는 지 표현해야 상대도 내 마음을 알고 이해해줄 것이다.

이 책에서 이야기하는 피드백의 네 가지 유형은 다음과 같다.

  • 지지적 피드백 - 소통의 긍정적인 에너지에 바탕
  • 교정적 피드백 - 기존에 형성된 관계를 개선, 발전시켜 나가는 데 유용
  • 학대적 피드백 - 맺고 있는 관계들에 부정적 영향을 미치는 피드백
  • 무의미한 피드백 - 어떤 면에서는 학대적 피드백보다 더 학대적인 피드백

당연한 이야기이지만 '지지적 피드백'이 가장 이상적인 피드백이다. 지지적 피드백의 가장 확실한 예는 칭찬이다. 칭찬은 고래도 춤 추게 한다지 않는가. 지지적 피드백을 꾸준히 받은 사람은 생각하는 것과 행동하는 것이 다르다고 한다. 물론 항상 지지적 피드백을 할 수는 없다. 경우에 따라서는 잘못한 일을 지적하고 이를 고치도록 하는 '교정적 피드백'도 필요하다. 어떤 경우에 지지적 피드백을 주고 어떤 경우에 교정적 피드백을 줄 것인지는 어려운 문제라고 한다. 이건 경험에 의해 배울 수 밖에 없고 꾸준히 노력해야 이를 구별할 수 있다고 한다.

이 책을 읽으며 보통 '교정적 피드백'이라고 생각하는 것들이 대부분 '학대적 피드백'에 속한다는 것을 알게 되었다. 다른 사람의 잘못을 지적하고 이를 교정하기 위해 우리는 상대를 학대하고 있었던 것이다! 이게 아니라는 걸 알았으니 이제부터는 고치도록 노력해야지.

피드백은 모든 사회에서 중요하다. 직장도 사회의 하나이므로 직장 내에서도 피드백은 상당히 중요하다.

모든 직원의 생산성의 기반에는 대인관계의 피드백이 필수조건으로 깔려 있습니다. 그것도 없이 사람들은 직장에서 문제를 증명해 보이려고 하죠. 최선의 해결책을 찾기 위해 우리가 무수히 많은 돈과 자원을 쏟는 그런 종류의 문제들 말이에요. 하지만 피드백만 적절히 받으면 사람들은 서점에 있는 책들이 추구하는 그런 일들을 기꺼이 해내려고 합니다.

<피드백 이야기>, 리처드 윌리엄스 지음, 이민주 옮김, 토네이도, 2007년 3월, 30쪽.

회사라는 것은 수익 창출을 위해 사람들이 모인 조직이다. 아무래도 이러한 목적을 갖고 있는 특수한 조직이다 보니 원하는 목적을 얻기 위해 직장 내에서의 의사소통은 항상 중요한 이슈로 취급된다. 하지만 모르긴 몰라도 많은 회사에서 의사소통 때문에 고민이 많을 것이라고 생각한다. 지금 내가 다니고 있는 회사도 예외는 아니어서 이런 문제가 항상 지적되고 있다.

솔직히 말하면, 수익을 내야 한다는 압력 때문에 수많은 상사들은 직원들의 불필요한 행동을 줄이거나 없애도록 도와야 한다는 소임을 종종 잊어버립니다. 직원들이 쓸데없는 행동을 멈추도록 하는 가장 효과적인 방법은 직원들의 피드백 통을 채워주는 것입니다. 여러분의 지지적 피드백이 다른 누군가의 통을 채워서 그 사람의 기분이 좋아진다면, 그 사람의 성과는 올라가고 문제를 일으킬 가능성은 낮아집니다. 다시 말해 오늘 약간의 시간을 투자하면 내일의 문젯거리가 줄어든다는 거죠. 문제가 줄어든다는 것은 어떤 뜻인가요? 바로 가장 중요한 손익상태가 좋아진다는 뜻입니다. 결국 효과적인 피드백은 비즈니스 수익으로 직결된다는 것을 아시겠죠?

<피드백 이야기>, 리처드 윌리엄스 지음, 이민주 옮김, 토네이도, 2007년 3월, 171쪽.

원하는 성과를 내라고 닥달하는 것보다는 적절한 피드백을 주는 것이 더 좋은 효과를 가져온다는 것을 잊거나 혹은 모르고 지낸다. 직장 내에서의 의사소통은 대부분 상사들에 의해 주도된다. 즉, 직원들이 좋은 성과를 내기 위해서는 상사가 잘 해야 한다는 말이 되는 것이다.

성공적인 조직이 되기 위해서는 우선 개개인이 성공해야 한다.

<피드백 이야기>, 리처드 윌리엄스 지음, 이민주 옮김, 토네이도, 2007년 3월, 217쪽.

어떤 조직이든 그 조직의 가장 큰 자산은 그 조직을 이루고 있는 구성원이다. 조직이 성공하기 위해서는 구성원들 개개인이 성공해야 한다. 반대로 구성원 개개인이 성공하기 위해서는 조직이 성공해야 하는 것이다. 이 둘은 땔래야 땔 수 없는 관계가 아닐까 싶다. 이 당연한 것을 너무도 쉽게 잊어버린다. 직원 개개인의 성공을 보장하는 회사가 결국은 성공하게 된다. 실제로 그런 사례를 우리는 봤고 지금도 그런 회사에 들어가기 위해 많은 구직자들이 노력하고 있는 거 아니겠는가.

언제나 느끼지만 의사소통이라는 것은 참 어렵다. 의사소통을 하기 위해 피드백은 아주 중요한 수단이며 피드백을 어떻게 하느냐에 따라 그에 따른 효과는 큰 차이를 보인다는 걸 잊지 말자.


신고
Trackback 1 Comment 0

아키텍트 이야기

유난히 정년이 짧은 프로그래머, 개발자라는 직업. 보통 30대 후반이 넘어가면 개발자로서는 늙었다는 말을 많이 들으며, 자의 혹은 타의에 의해 개발자의 길을 벗어나 관리직 등의 개발이 아닌 다른 길을 찾아야 하는 경우가 많다. 프로그램 개발이라는 것이 창의력을 많이 요구하는 것이다 보니 이런 풍토가 생겨나고 이것이 거의 정해진 것인 양 받아들여지고 있다. 안타깝지만 이것은 현실이다.

이 정도 경력이 되면 이전에는 눈에 보이지 않던 것들이 서서히 보이기 시작하고 개발 프로젝트의 전체적인 흐름 파악도 어느 정도 될 시점인데, 이제는 프로그래밍을 그만 둬야 하나? 지금까지 익혀온 기술과 눈치(?)가 아깝게 느껴진다. 프로젝트 관리자 등을 맡아서 프로젝트의 성공을 위해 일을 할 수는 있지만, 지금까지 쌓아놓은 개발 노하우는 어디에 써야 한단 말인가. 그냥 그대로 묵혀놔야 할까. 아깝다.

나이가 먹어서도 계속 프로그래밍을 할 수 있는 방법은 없을까? 어느 정도 실력과 연륜을 쌓은 개발자로 현장에서 일할 수 있는 방법은 없을까? 이 책에서는 하나의 길을 제시하고 있다.

바로 아키텍트라는 것인데, 아키텍트는 아래와 같이 정의할 수 있다.

아키텍트는 아키텍처를 설계하고 그것을 시스템 개발 전체에 미치게 하는 것이 임무다. 개발팀의 중심인물로, 팀원을 이끈다는 의미에서 '프로젝트 리더(PL)'와 겹치는 부분도 있지만, 시스템 기획 같은 초기 단계에 기술 전문가로 참여하거나, 시스템이나 프로젝트의 특성에 맞춰서 문서세트를 구성하는 등, 활동무대는 더욱 폭넓다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 11쪽.

그럼 아키텍처는 무엇인가? 아는 사람은 다 아는 이 단어는 건축에서 기초와 골격에 비유할 수 있다. "시스템 전체의 대략적인 구성과 거기에 구체적인 구현지침을 합친 개념" 정도라고 이 책에서는 이야기하고 있다.

이 책에서 이야기하는 아키텍트의 주요 업무로는 다음과 같은 것들이 있다.

  • 요구사항 정의에 참여
  • 아키텍처 설계
  • 프레임워크 준비
  • 문제 해결
  • 테스트 지원
  • 개발 이외의 업무 지원

이 내용들을 보면 프로젝트 관리자(Project Manger, PM)의 역할과 비슷해 보이는데, 프로젝트 관리자는 프로젝트가 원활하게 수행되도록 하는 데 중점을 두는 반면, 아키텍트는 설계와 프레임워크 개발 등 프로젝트의 기술적인 핵심 부분을 담당하게 되는 역할이라고 할 수 있다.

아키텍트가 하는 일은 결정된 명세를 프로그래밍하는 프로그래머나, 프로젝트의 원활한 진척을 계획하는 프로젝트 관리자의 업무와 다르다. 기술적 관점에서 시스템 전체를 넓게 바라볼 수 있는 존재가 바로 아키텍트다. 아키텍트라는 말은 '책임 설계자'로 번역하는 것이 정확할 것이다. 아키텍트의 역할이 애플리케이션의 설계와 구현 전체를 책임지고 개발팀을 이끄는 것이기 때문이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 19쪽.

이 책은 실제 개발 프로젝트에서 일어날 만한 일을 예로 들어 아키텍트 C가 이를 어떻게 풀어나가며 어떤 일을 하는지를 설명하고 있다. 이 흐름을 따라가면 아키텍트가 주로 어떤 일을 해야 하고 어떤 것들을 알아야 하는지 파악할 수 있을 것이다. 이 책에서도 강조하고 있는 부분은 개발자라고 해서 개발만 잘 하면 되는 것은 아니라는 것이다. 개발자가 아키텍트의 역할을 제대로 수행하기 위해서는 무엇보다도 비즈니스를 이해하고 의사소통 능력이 필요하게 된다.

아키텍트는 기술력을 토대로 시스템 개발과 IT를 활용하는 비즈니스에 이르는 넓은 범위에 대해 깊은 이해가 있어야 한다. 이러한 아키텍트의 역할을 이미 다양한 비즈니스 현장에서 요청하고 있다. 비즈니스에 대한 IT의 영향력이 커지면 아키텍트의 필요성 역시 높아질 것이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 214쪽.

물론 아키텍트는 개발팀 내에서 최고 개발자이기 때문에 기술적인 능력도 뛰어나야 한다. 단순히 자신이 알고 문제를 해결하는데 끝나는 것이 아니라, 이러한 기술력을 바탕으로 다른 팀원들이 해결하기 힘든 경우 도와줄 수 있어야 하며, 기술적인 문제에 대해 개발자가 아닌 다른 부서의 사람들을 이해시킬 수 있어야 한다. 즉, 기술력 뿐만 아니라 이를 풀어서 설명할 수 있는 능력과 의사소통 능력이 중요하다는 말이다.

아키텍트는 책임 설계자이며 최고 개발자로서, 개발팀을 이끌 수 있을 정도의 전문적인 기술과 역량이 요구되는 역할이다. 기술에 대해 잘 알고 있는 팀원들을 결속시키기 위해서는 그들이 인정할만한 기술력이 필요하다. 이와 동시에 개발팀과 비즈니스의 가교 역할을 해야 한다. … 아키텍트는 시스템 개발이라는 활동에서 기술자와 비즈니스 관계자들이 서로 협조할 수 있도록 조정자 역할을 한다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 215쪽.

기술자가 흔히 하는 실수는 전문용어를 남발하는 것이다. 그 기술을 아는 사람들끼리는 전문용어를 쓰는 것이 의사소통에 도움이 될 지 모르겠지만, 이런 기술을 모르거나 익숙하지 않은 사람에게 자세한 설명 없이 전문용어를 무분별하게 쓴다면 이야기를 하기 싫다는 뜻으로 받아들여지기 딱 좋을 것이다. 전문용어는 상대를 봐가면서 쓰도록 하자. 전문용어를 쓰지 않고도 상대에게 내가 하고자 하는 말을 제대로 전달할 수 있어야 제대로 된 기술자가 아닐까?

비기술자인 결정권자에게 기술자의 의견을 적절하게 전달하는 데는 어려움이 많다. 기술적으로 정확한 판단과 근거, 부적절한 판단이 가져올 위험요소를 이해시키려면, 프로그램을 한 행씩 지적하며 설명하거나, 프로그램 언어나 제품 등에 대해 자세하게 가르쳐야 하기 때문이다. … 비기술자에게 의견을 전달할 때는 전문용어를 되도록 쓰지 않고, 도표나 비유를 이용하여 설명한다. 문제가 복잡한 경우에는 개요만을 정확히 전달하는 방법으로 앞서 말한 실수를 피할 수 있다. 물론 때에 따라서 정확하고 자세하게 설명하지 않아도 되는 상황도 있을 수 있다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 181쪽.

아래는 이 책을 감수하신 한의근님이 책의 첫머리에 하신 말씀이다. 그리고, 내가 하고 싶은 말이기도 하다.

기술자의 정년은 마흔이라는 말을 들을 때마다 안타깝다. 나이가 많아지면 그만큼 경륜이 생기는데도 관리직 일을 맡아 경험을 충분히 활용할 수 없게 되는 경우를 적지 않게 보아 왔다. 현재 가지고 있는 소망 중 하나는 나이가 들어서도 장인 기술자로 남고 싶다는 것이다.

아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 6쪽.


신고

'Books' 카테고리의 다른 글

이기적 유전자  (2) 2009.11.12
카인의 징표  (4) 2009.11.08
아키텍트 이야기  (0) 2009.11.02
사랑하지 않으면 떠나라!  (4) 2009.10.29
내 통장 사용설명서  (8) 2009.10.23
보랏빛 소가 온다  (0) 2009.10.22
Trackback 2 Comment 0

사랑하지 않으면 떠나라!

이건 연애 소설의 제목이 아니다. 수필이나 시집도 아니다. 이건 개발자들의 처절한 삶을 극복하게 도와줄 책이다.

IT 직종, 거기에서도 개발자들은 상대적으로 낮은 임금과 열악한 근무 환경에서 일을 하고 있다. 남들이 보기에는 멋있어 보이는 직업이지만, 실상 안을 들여다보면 처참하기 그지 없다. 밥 먹듯이 야근하는 것은 기본이며, 자기를 위해 시간을 투자하는 것은 사치일 정도로 어렵게 살고 있는 것이 개발자들의 삶이다.

엎친 데 덮친 격으로 개발자가 멋있어 보이는 것인지 먹고 살기 좋다는 헛소문이 떠돈 탓인지 개발자들이 넘쳐나고 있다. 그렇지 않아도 열악한 근무 환경으로 인해 어려운데 넘쳐나는 개발자들로 인해 자신이 원하는 좋은 자리를 찾는 것도 힘들어지고 있다. 물론 이런 건 어디나 다 마찬가지일 거다. 개발자에게만 한정된 어려움은 아니라는 것은 안다.

그렇다면, 이런 어려움 속에서 우리는 어떻게 해야 할까? 개발자들이 앞으로도 자기 자리 지키면서 먹고 살기 위해서는 어떻게 해야 할까? 그냥 지금 하는 있는 일이나 잘 하고 있으면 회사에서 정년 혹은 퇴직할 때까지 먹여 살려줄까?

이 책의 지은이 차드 파울러는 흔치 않은 경력을 가지고 있다. 음악을 했고 색소폰을 하다 우연한 기회에 개발자로 일을 시작하여 지금은 꽤 알려진 개발자이다. 한 회사의 인도 개발센터를 맡으며 인도에서 생활하기도 했고, 다른 여러 나라의 개발센터 개설하는 것을 돕기도 했다. 이 책은 이런 일을 겪은 차드 파울러가 개발자가 앞으로 어떤 생각과 어떤 준비를 해야할 것인가를 말해준다.

이 책의 서론에는 개발자들이 비즈니스 관점에서 자신의 경력을 위해 집중해야 할 네 가지 측면이 나와있다.

  1. 자신의 시장을 선택하라. 집중할 기술과 비지니스 분야를 신중하게 고른다. 리스크와 보상의 균형을 어떻게 맞출 것인가? 수요와 공급을 어떻게 결정할 것인가?
  2. 자신에게 투자하라. 지식과 기술은 자신이라는 상품의 주출돌이다. 지식과 기술에 적절하게 투자하는 것은 자신의 시장성을 높일 수 있는 중요한 부분이다. 단순히 비주얼 베이직(Visual Basic)으로 프로그래밍하는 것만으로는 더 이상 충분하지 않다. 새로운 경제 환경에서는 어떤 기술이 필요할까? 해외 또는 국내 경쟁자들과 어떻게 경쟁할까?
  3. 실행하라. 단순히 뛰어난 기술을 갖춘 직원을 고용하는 것으로는 회사에 성과가 나지 않는다. 직원은 회사를 만족시킬만한 가치를 만들어내야 한다. 여러분은 무리하지 않고 그러한 페이스를 어떻게 유지하는가? 자신이 회사를 위해 좋은 가치를 만들고 있는지 아닌지 어떻게 인지하고 있는가?
  4. 마케팅 하라. 역사상 최고의 제품이라도 아무도 모르면 팔리지 않는다. 여러분은 회사와 업계에서 자신을 전혀 알리지 않고 어떻게 인정받는가?

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 30쪽.

안타깝게도 현장에서 이런 생각을 갖고 있는 개발자를 만나기는 어려운 일이다. 이런 비슷한 생각들을 가진 사람이라도 현실의 벽이라는 것에 부딪혀서 제대로 해보지 못하고 포기한 경우도 있다. 그 벽을 넘는 것이 당연히 쉬운 일은 아닐테고 그걸 넘어서야 발전이 있을텐데 현재에 정체되어 버린, 어떻게 보면 현실과 타협해버린 삶을 살고 있는지도 모르겠다.

넘쳐나고 있는 개발자들, 날로 늘어가는 새로운 기술들. 이 틈바구니 속에서 나를 돋보이게 하고 앞으로도 개발자로 살기 위해서는 무엇을 해야할까? 남들 다 알고 있는 기술을 알고 있다는 것만으로는 부족하다. 요즘은 Java나 C, Python, PHP 등을 알고 있다고 그게 내세울만한 것이 되지 못한다. 개발자라면 누구나 다 알고 있는 거 아냐? :-)

어떤 기술에 투자할지 생각하는 것만으로는 충분하지 않다. 이제 기술은 필수품이 되어버렸다. 결국 프로그래머들은 비즈니스 담당자들이 비즈니스를 책임지는 동안 편하게 앉아서 단순히 프로그래밍 언어를 익히거나 운영체제를 공부하는 일만 할 수 없게 되었다. … 회사에서 계속 쓸모있는 사람으로 남고 싶다면 자신이 속한 비즈니스 분야에 뛰어들어야 한다. 실제로 소프트웨어 개발자는 비즈니스 분야를 이해하고 그에 해당하는 소프트웨어를 잘 개발할 수 있어야 할 뿐만 아니라 그 분야 권위자가 되어야 한다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 43쪽.

맞는 말이다. 어떤 것이든 어떤 분야든 비즈니스가 적용되지 않은 곳은 없고 그걸 이해하지 못한다면 개발자는 단순히 코딩을 하는 기계에 불과할 것이다. 제대로 알고 일을 하자.

비즈니스 분야를 잘 선택해야 하는 중요성에 비춰보면 포트폴리오를 완성할 때 여러분이 선택한 회사나 업계는 자신에게 중요한 투자처다. 자신이 투자해야 할 비즈니스 분야에 대해 아직 정말 진지하게 생각해 보지 않았다면 지금이 바로 생각해야 할 때다. 하루가 지나갈 때마다 기회를 잃어버리는 것이다. 정체된 비즈니스 분야에서 개발 일을 계속 하는 것은 고이자율 예금 상품이 나왔는데 이자율이 낮은 계좌에 예금을 계속 내버려두는 것과 같은 좋지 않은 투자 선택이다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 45쪽.

이건 참 쉽지 않은 것이다. 지금 몸 담고 있는 곳을 벗어나 새로운 것에 투자하는 것, 쉽게 결정할 수 있는 일이 아니다. 여기에는 상당한 위험이 존재하고 그 위험을 제대로 극복하지 못할 때에는 경력 자체가 흔들릴 수도 있다. 하지만, 미래를 위해서는 적극적인 투자가 필요할테고 현실에 안주하는 것은 결국 도태를 의미하기 때문에 뭔가 방법을 찾기는 찾아야 한다. 역시 그건 위험을 감수하고 도전하며 투자하는 것이 아닐까.

직업을 선택하는 기준은 무엇인가? 사람에 따라 다르겠지만, 난 좋아하지 않는 일을 직업으로 선택하는 것은 불행이라고 생각한다. 어떻게 좋아하지도 않는 일을 하루 종일 할 수 있단 말인가. 아무리 먹고 살려고 하는 일이라도 말이다. 더군다나 일의 성과나 능률도 좋아하는 일과 그렇지 않은 일의 경우에는 차이가 많이 생긴다. 열정을 가지고 일을 할 때의 성과가 더욱 좋다는 것은 누구나 인정할 것이다.

다양한 분야의 대가에 대한 전기나 다큐멘터리를 보면 이같이 열정적으로 몰두하는 행동 패턴이 나타난다. 재즈 색소폰의 대가 존 콜트레인(John Coltrane)은 소문에 따르면 입술에 피가 나도록 연습했다고 한다. 물론 타고난 재능도 능력에서 중요한 구실을 한다. … 그러나 우리 모두는 열정을 쏟을 수 있는 일을 찾아냄으로써 평범함을 벗어나 한 단계 더 도약할 수 있다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 82쪽.

열정을 가지고 일을 한다는 것은 여러 면에서 좋은 일이다. 당장 지금 하고 있는 일의 성과가 올라가게 될 것이며, 이에 따라 여러 일에 좋은 영향을 미칠 것이다. 그래, 나비의 날개짓 하나가 허리케인을 불러오는 거야!

그리고, 자신에게 투자하는 것은 정말 중요하다. 끊임없이 투자하고 발전하지 않는다면 도태될 수 밖에 없다. 하루가 다르게 변하고 있는 이 세상에 나만 변하지 않는다면 결과는 뻔하다. 그리고 이런 투자는 위에서 이야기한 "열정"을 가지고 해야할 일이다. 열정이 없는 투자, 즉 마지못해 새로운 기술을 배우거나 지금 당장 프로젝트에 적용하기 위해 다른 언어를 대충 살펴보는 것은 시간 낭비다.

이런 경험을 한 적도 있다. 새로운 기술에 대해 스스로 찾아보거나 공부할 생각은 하지 않고, 처음 접하는 것이기 때문에 개략적인 것들을 추려서 세미나를 부탁하는 사람을 본 적이 있다. 누구는 태어날 때부터 그 내용에 대해 알고 태어난 것인가? 알고 있는 것을 공유하고 또 그 과정에서 내가 아는 것을 정리할 수 있기에 응하기는 했지만, 그런 생각은 참 마음에 들지 않는다.

소프트웨어 개발자에게 적용할 수 있는 노자의 교훈은 다음과 같은 것이다. "물고기 한 마리를 달라고 하면 하루 동안 먹는다. 물고기 잡는 법을 가르쳐 달라고 하면 평생 동안 먹는다." 그러나 가르쳐 달라고 부탁하기보다는 차라리 스스로 찾아서 배우라.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 93쪽.

무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가르쳐 보라. 어떤 것에 대한 이해를 구체화하는 데 가장 좋은 방법은 다른 사람들이 이해할 수 있도록 그것을 표현하는 것이다. 말을 한다는 것은 단순한 행동이지만 불분명한 사고를 다루는 데는 특효약이다. 인형과 같은 물체와 얘기하는 것은 소프트웨어 개발에서 전승되어온 잘 알려진 문제 해결 수단 중 하나다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 104쪽.

개발을 하다 보면 지겨운 일을 해야할 때도 있다. 이럴 때는 능률도 오르지 않고 짜증이 나기도 한다. 어떻게 하면 이런 일들을 즐겁게 할 수 있을까? 이것을 반대로 생각해보면, 지겨운 일은 왜 지겨울까? 왜 아직도 재미가 없을까?

대부분의 기술자에게 일이 지겨워지는 것은 다음과 같은 두 가지 근본적인 이유 때문이다. 좋아하는 일을 하면 창조력이 발휘된다. … 그냥 넘어가고 싶은 일들은 창조력을 발휘할 여지를 주지 않는 일일 것이다. … 지겨운 일이 지겨워지는 두 번째 이유는 첫 번째 이유와 명백히 밀접하게 연결되어 있다. 지겨운 일은 도전적이지 않다는 것이다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 156쪽.

그렇다면, 어떻게 해야 지겨움에서 벗어날 수 있을까? 이 책에서는 이를 위해 "지겨운 일을 완벽하게 하려고 노력해 보는 건 어떨까?"라고 제안하고 있다. 일을 완벽하게 하는 것은 사실 불가능하다. 하지만, 완벽하게 하려고 함으로써 일은 어렵게 느껴질 것이고 그럼 결과적으로 지겨움에서 벗어날 수 있다는 것이다. 어찌 보면 맞는 말인 것 같기도 하다. 앞으로는 지겨운 일을 만날 때 이 방법을 시도해 봐야겠다.

일을 하면서 실수는 언제나 생길 수 있다. 사람에 따라 실수에 대처하는 방법이 다른데, 어떤 방법을 선택하느냐에 따라 다른 사람의 나에 대한 평가는 달라진다. 실수를 무작정 덮으려고 하지 말고, 아래와 같은 방법을 써보라고 파울러는 말하고 있다.

  • 알게 되자마자 문제를 제기하라.
  • 책임을 지라.
  • 해결책을 제시하라.
  • 도움을 구하라.

자존심이 쌘 사람이거나 높은 직책에 있는 사람이라면 이렇게 솔직하게 행동하는 것이 어려울 지도 모르겠다. 하지만, 잘못하다가는 배보다 배꼽이 더 커지는 사태가 발생할 수도 있음을 잊지 말자.

그리고, 우리는 일에 대한 약속을 너무 쉽게 한다. 그러다 이 약속을 지키기 위해 무리하게 작업을 하기도 하고 대충 작업을 마치기도 한다. 결국 이건 또 다른 문제를 일으키게 되고 잘못하다가는 무능력한 사람으로 낙인 찍힐 수도 있다.

"예"라고 말하는 것은 습관적이고 유해한 버릇이다. 그것은 좋은 사람인 척 하려는 나쁜 버릇이다. '할 수 있다'는 태도와 자신의 능력을 '거짓으로 말하는 것'은 차이가 크다. 후자는 자신뿐만 아니라 자신이 약속한 사람들에 대해서도 문제를 일으킨다. …

"아니오"라고 말할 용기가 있는 팀원이 있고 그 말이 사실이라면, "예"라고 말할 때에는 그것이 거짓말이 아님을 알 수 있다. 이런 사람이 하는 약속은 더 믿을 만하다. … 어떤 사람이 항상 "예"라고만 말한다면 엄청나게 재능이 있거나 거짓말을 하는 것, 둘 중에 하나다. 대개의 경우 후자다.

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 181쪽, 183쪽.

그리고, 자주 느끼는 것인데, 개발자라면 의사 소통이 중요하다. 어떤 요구 사항이 있을 때 이를 제대로 이해해야 하며, 보고서 등을 작성할 때도 전달하고자 하는 것을 제대로 전달할 수 있어야 한다. 그런 면에서 파울러는 "개발자는 글쓰기 능력을 배양한다"라고 말하고 있다. 특히 문법과 철자에 맞춰 제대로 적을 줄 알아야 한다라고 말한다. 아울러 논리적이고 체계적으로 자신의 생각을 글로 표현할 수 있어야 한다. 아무리 좋은 아이디어가 있다고 하더라도 그것을 다른 사람에게 제대로 설명할 수 없다면 무슨 소용이 있겠는가.

글쓰기 능력이 있으면 자신을 잘 인식할 수 있을 뿐만 아니라 내적으로는 자신이 어떤 길로 가고 있는지에 대한 진정한 통찰도 생긴다. 다른 사람이 분명하게 이해할 수 있도록 자신의 모국어로 자기 생각을 구성할 수 없는데, 프로그래밍 언어로 그렇게 할 수 있다고 어떻게 기대하겠는가?

사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 207쪽.

이왕 하는 일이라면 즐기면서 일을 하고 최선을 다해 자신이 하는 분야에서 최고가 되기 위해 노력해 보자. 하루 하루 닥친 일들 대충 처리해가며 살아갈 수도 있겠지만, 그보다는 조금만 더 앞을 내다 보며 인생을 사는 것이 멋지지 않을까? 용의 꼬리보다는 뱀의 머리가 되고 싶다. 그러기 위해 오늘 하루도 힘차게!

신고

'Books' 카테고리의 다른 글

카인의 징표  (4) 2009.11.08
아키텍트 이야기  (0) 2009.11.02
사랑하지 않으면 떠나라!  (4) 2009.10.29
내 통장 사용설명서  (8) 2009.10.23
보랏빛 소가 온다  (0) 2009.10.22
파인만 씨, 농담도 잘하시네  (5) 2009.10.21
Trackback 2 Comment 4