헤세의 사랑 - 사랑하는 사람은 행복하다 헤르만 헤세 : 사랑, 예술 그리고 인생
헤르만 헤세 지음, 폴커 미켈스 엮음, 이재원 옮김 / 그책 / 2009년 6월
평점 :
구판절판


오직 앞만 보며 달리고 있는 지금, 가끔은 뒤도 돌아보고 위도 올려다 보자고 다짐하지만 그게 그리 마음 먹은 대로 되지 않는다. 그러던 와중 헤르만 헤세의 글을 담아놓은 "헤세의 사랑"이라는 책에 대한 캠페인을 위드블로그에서 보게 되었고, 아무리 바쁘게 살아가고 힘들게 살더라도 잊지 말아야 할 것들을 다시 생각해보고자 캠페인에 신청하고 운 좋게 선정되어 이 책을 읽기 시작했다.

이 책을 두 번 읽고 난 지금은 이 책을 읽으려고 마음 먹은 것이 참 잘 했다는 생각이 든다. 이 책에 대한 여러 가지 평가가 있겠지만, 내 경우에는 지금 내 상황에서 이 책을 읽은 것이 여러 면에서 도움이 되었다.

헤르만 헤세를 모르는 사람은 없을 것이다. 헤르만 헤세는 1877년 독일에서 태어나 선교사인 아버지의 뜻에 따라 신학교에 들어갔지만, 신학교가 맞지 않아 도중에 자퇴하고 자살 시도까지 한 후 정신병원에 입원하기도 했다. 이후 작가의 길을 걸었고, 많은 소설과 단편집, 산문집, 시, 비평 등을 발표하며 인기를 얻었다. 1, 2차 세계대전을 겪으며 전쟁에 대해 비판하는 글을 쓰기도 했으며, 1946년에는 소설 "유리알 유희"로 노벨문학상을 받게 된다. 그리고는 1962년 뇌출혈로 영면에 들었다.

이 책은 헤르만 헤세가 쓴 많은 책과 글에서 사랑과 행복, 음악에 대한 좋은 글귀나 시 등을 모아 하나의 책으로 엮어놓은 것이다. 이 책은 무엇인가를 이해하려고 읽는다는 것은 그리 좋은 생각은 아니라고 본다. 그냥 마음 가는 대로 틈틈히 각 글귀들을 하나의 시처럼 편하게 읽을 수 있는 책이다. 이 책은 헤르만 헤세의 소설, 비평이 아니고 하나의 시집이다. 하지만, 한 문장 한 문장 곱씹어가며 읽다 보면 내려야 할 지하철 정거장을 그냥 지나칠 수도 있다. 이 책을 읽다가 두 번이나 되돌아온 적이 정도이니, 지하철에서 이 책을 읽을 때는 주의해야 한다!

위에서도 말했지만, 이 책에서 다루고 있는 주제는 크게 사랑과 행복, 음악, 이렇게 세 가지로 볼 수 있다. 그 중에서 행복에 대한 글귀들이 나에게 많은 도움이 되었다.

사랑은 행복과 다르지 않다. 사랑할 수 있는 사람은 행복하다.

마르틴의 일기 중에서, 1918년
헤세의 사랑, 헤르만 헤세 지음, 폴커 미헬스 엮음, 이재원 옮김, 그책, 2009년 5월, 87쪽.

그래, 맞는 말이다. 우리는 행복을 갈구한다. 정작 무엇이 행복인지도 모르면서, 그저 행복을 찾아 헤매고 있다. 결국 행복은 사랑하는 것에서 얻을 수 있다는 것은 우리는 알지 못하고, 혹은 알고 있더라도 너무 쉽게 잊는다.

행복이나 불행은 밖에서 오는 게 아니다. 행복이나 불행이 우리의 삶에 어떤 영향을 주는가는 일어난 일을 받아들이는 우리 마음 자세에 달려 있다.

"모리스 메테를링크" 감사의 글, 1900년 6월.
헤세의 사랑, 헤르만 헤세 지음, 폴커 미헬스 엮음, 이재원 옮김, 그책, 2009년 5월, 91쪽.

인간이 자신의 욕망에 거리를 두게 되는 것은 시간을 통해서뿐이다. 그런 점에서 시간은 멋진 발명품이다. 그런데 이렇게 지지대 또는 버팀목 구실을 하는 시간은, 우리가 자유로워지려면 가장 먼저 버려야 하는 것이었다.

클라인과 바그너, 1919년.
헤세의 사랑, 헤르만 헤세 지음, 폴커 미헬스 엮음, 이재원 옮김, 그책, 2009년 5월, 95쪽.

참 이율배반적이다. 우리는 보다 나은 삶을 위해, 행복을 위해, 성공을 위해, 시간에 쫓기며 산다. 하지만, 헤르만 헤세는 우리가 자유로워지려면 가장 먼저 시간을 버려야 한다고 말한다. 과연 우리는 시간을 버릴 수 있을까?

성공은 언제나 가장 가치 있는 사람에게 주어지는 것은 아닙니다. 행운의 변덕 덕택으로 성공을 얻게 된 사람은 그 성공에서 자만심이 아니라 책임감을 배워야 할 것입니다.

"헤르만 헤세 상" 제정과 관련하여 어느 장관에게 보낸 편지, 1955년.
헤세의 사랑, 헤르만 헤세 지음, 폴커 미헬스 엮음, 이재원 옮김, 그책, 2009년 5월, 98쪽.

그리 많은 내용은 아니지만, 헤르만 헤세의 생각과 철학을 들여다보기에는 그리 부족해 보이지 않는다. 왜 많은 사람들이 헤르만 헤세의 글을 좋아하는지 알 수 있을 듯 싶다.

아 직은 이 책에서 이야기하는 모든 내용이 마음 깊이 와닿지는 않는다. 내 마음이 삭막해져 있기 때문일 수도 있고, 이런 내용을 받아들이기에는 아직 내 문학 소양이 부족한 것인지도 모르겠다. 책을 읽으며 긁적여놓은 메모들을 보니 처음 읽을 때와 그 다음에 읽을 때의 생각들이 조금씩 다르다는 것이 재미있다. 아마 나중에 시간이 흐른 뒤 다시 읽어보면 분명 또 다른 생각을 하게 될 것이다. 그 때는 무슨 생각을 하게 될 지 궁금하기도 하고 기다려진다.

댓글(0) 먼댓글(1) 좋아요(0)
좋아요
북마크하기찜하기 thankstoThanksTo
  1. 헤세의 사랑
    from thoughts.mooo 2010-02-13 21:39 
    오직 앞만 보며 달리고 있는 지금, 가끔은 뒤도 돌아보고 위도 올려다 보자고 다짐하지만 그게 그리 마음 먹은 대로 되지 않는다. 그러던 와중 헤르만 헤세의 글을 담아놓은 "헤세의 사랑"이라는 책에 대한 캠페인을 위드블로그에서 보게 되었고, 아무리 바쁘게 살아가고 힘들게 살더라도 잊지 말아야 할 것들을 다시 생각해보고자 캠페인에 신청하고 운 좋게 선정되어 이 책을 읽기 시작했다. 이 책을 두 번 읽고 난 지금은 이 책을 읽으려고 마음 먹은 것이 참 잘..
 
 
 
이기적 유전자 - 30주년 기념판
리처드 도킨스 지음, 홍영남 옮김 / 을유문화사 / 2006년 11월
평점 :
구판절판


내가 이 책을 다 읽게 되리라고는 기대하지 못했다. 중간에 다른 책들을 읽기도 했지만, 결국은 거의 3주 정도 걸려서 읽고야 말았다! 책을 읽는다는 것이 이렇게 힘든 일이라는 것을 참 오랜만에 느끼게 만들어준 책이었다.


쉽지 않은 책이다. 이건 지금까지 더하기나 빼기를 겨우 겨우 하던 아이가 적분과 미분을 가르쳐주는 책을 읽는 것과 비슷한 정도의 난이도를 느끼게 했다. 더군다나 이 책의 번역은 원문을 그대로 한글로 옮겨놓은 것이라 생각될 정도였기 때문에 읽고 이해하는 것이 더욱 힘들었다.

분명 한글로 쓰여있지만, 어순이나 단어 선택, 표현 등을 영문의 방식과 흡사했다. 그래서 읽으면서도 문장을 서너번씩은 읽어야 이해할 수 있는 문장들이 많았다. 이건 내가 이런 식으로 변역된 책을 읽는데 익숙하지 않기 때문일지도 모르겠다. 이런 식으로 번역되는 책은 전공서적이 대부분인데, 전공서적이야 이런 번역서를 읽느니 차라리 원서를 보는 것이 마음 편하기 때문에 이런 번역서에 익숙하지 않는 것은 당연하다.

리처드 도킨스가 쓴 "이기적 유전자"는 진화에 대한 책이다. 유전자의 관점에서 진화론을 해석하고 이에 대한 이야기를 하고 있는 책이다. 이 책에서 리처드 도킨스가 주장하는 "진화"에 대한 것은 책의 끄트머리에 잘 정리되어 있다.

자연 선택의 근본적인 단위로 생존에 성공 또는 실패하는 기본적인 것, 그리고 때때로 무작위적인 돌연변이를 수반하면서 동일한 사본의 게보를 형성하는 기본 단위를 자기 복제자라고 한다. DNA 분자는 자기 복제자이다. 자기 복제자는 일반적으로 뒤에서 기술하는 이유에 의해 거대한 공동체적 생존 기계, 즉 운반자 속에 집단화한다. 우리가 가장 잘 알고 있는 운반자는 우리 자신과 같은 개체의 몸이다. 그러나 몸은 자기 복제자가 아니다. 그것은 운반자인 것이다. 그 점은 지금까지 오해되어 왔기 때문에 특히 강조한다. 운반자 그 자신은 스스로를 복제하지 못한다. 운반자는 자기를 구성하는 자기 복제자들을 증식하도록 작용한다. 자기 복제자는 행동을 하지 않는다. 또한 세계를 지각하지도 못하며 먹이를 잡거나 또는 포식자로부터 도망치지도 않는다. 자기 복제자는 그와 같은 모든 것을 하는 운반자를 만든다.

이기적 유전자, 리처드 도킨스 지음, 홍영남 옮김, 을유문화사, 2006년 11월, 428쪽.

위 글과 같이 리처드 도킨스는 이 책과 이전의 논문들을 통해 진화의 기본 단위는 생명체나 그 생명체의 집단이 아니라 유전자라고 주장하고 있다. 스스로 사고나 행동을 하지 못하는 유전자가 어떻게 진화의 중심에 있을 수 있을까. 그것은 유전자의 DNA에 이러한 절차를 갖는 방식들이 프로그래밍되어 있고 이것에 의해 유전자를 갖는 생명체가 그에 맞는 사고와 행동을 하게 된다는 것이 기본 철학이다. 이러한 관점에서 여러 형태의 동물 행동과 사회 현상을 이야기하고 설명하고 있는 이 책은 읽으면 읽을 수록 흥미진진해졌다.

평소 자연과학에 대한 관심은 많지만, 이런 주장은 처음 들어보는 것이라 상당히 신선하고 재미있었다. 이런 관점에서 이야기되는 동물사회학은 이전에는 이 책에 나와있는 방식으로 설명하는 것을 생각해보지 못했던 새로운 것들이었고 생명체가 번식하고 진화하는 과정들은 도킨스가 주장하는 것에 너무 딱 들어맞았다.

도킨스의 "이기적 유전자"에 이어지는 "확장된 표준형"이라는 책을 읽어보고 싶은데, 이 책을 번역한 분이 번역을 했더라. 그래서 또 다시 나를 자학의 구렁텅이에 빠뜨리는 짓을 하는 것은 심하다 싶어 이 책은 포기하고 다음에 개정 번역판이 나오거나 다른 분이 번역하면 읽어볼 생각이다.

분명 재미있고 좋은 책임에도 불구하고 이런 식으로 번역이 되어 있는 것이 너무 안타깝다! 내가 아는 것이 적고 지적 수준이 떨어지기 때문에 이 책을 읽는 것이 힘들었을지도 모르지만, 이 책이 여러 추천 목록에 들어있는 것은 이해하기 힘들다. 이 책을 읽는 것보다는 다른 책 두세권을 더 읽는 것이 낫다고 생각하며, 꼭 이 책을 읽어야겠다면 번역서를 읽는 것보다는 원서를 보는 것이 낫다고 생각한다.

댓글(0) 먼댓글(1) 좋아요(3)
좋아요
북마크하기찜하기 thankstoThanksTo
  1. 이기적 유전자
    from thoughts.mooo 2010-02-13 21:39 
    내가 이 책을 다 읽게 되리라고는 기대하지 못했다. 중간에 다른 책들을 읽기도 했지만, 결국은 거의 3주 정도 걸려서 읽고야 말았다! 책을 읽는다는 것이 이렇게 힘든 일이라는 것을 참 오랜만에 느끼게 만들어준 책이었다. 쉽지 않은 책이다. 이건 지금까지 더하기나 빼기를 겨우 겨우 하던 아이가 적분과 미분을 가르쳐주는 책을 읽는 것과 비슷한 정도의 난이도를 느끼게 했다. 더군다나 이 책의 번역은 원문을 그대로 한글로 옮겨놓은 것이라 생각될 정도였기 때..
 
 
 
카인의 징표
브래드 멜처 지음, 박산호 옮김 / 다산책방 / 2009년 9월
평점 :
절판


책을 받아든 첫 느낌은 책이 상당히 무겁다는 것이었다. 책의 무게가 무거웠다는 것이 아니라 책에서 풍기는 분위기가 왠지 무거워 보였다는 말이다. 600여 쪽 정도 되는 이 책은 책을 읽는 동안 나를 상상과 어지러움 속에 빠져들게 했다.

카인, 책 제목에 나와있는 카인은 누구인가? 카인은 아담과 하와의 큰 아들로 인류 역사상 첫번째 살인을 한 사람으로 성경에 기록되어 있다. 그것도 동생인 아벨을 죽인 존속살인을 한 사람이다. 카인이 아벨을 죽인 이유는 하나님이 농부인 자신의 제물보다 목동인 아벨의 제물을 더 좋아했기 때문이라고 한다. 그래서 이를 시기하여 동생 아벨을 몰래 꾀어내어 돌로 쳐서 동생을 죽였다. 이렇게 동생 아벨을 죽인 카인을 하나님은 용서해주고 대신 벌로 평생 유랑 생활을 하도록 했으며, 이 때 "카인의 징표"를 주었다고 한다. "카인의 징표"는 살인자의 징표가 아니라, 카인을 하나님의 용서했으며 다른 사람들이 그를 해치지 못하도록 하는 보호자의 징표라고 알려져 있다.

이 책에서 나오는 또 하나의 이야기는 슈퍼맨이다. 슈퍼맨은 미국에서 만들어진 영웅 중 하나이다. 이 영웅 슈퍼맨은 제리 시걸이 창조했고, 제리 시걸의 아버지 미첼 시걸은 의문의 죽음을 당하게 된다. 하지만, 미첼 시걸의 죽음은 의문투성이고 제리 시걸도 생애 수많은 인터뷰를 했지만 자신의 아버지에 대한 이야기는 한 번도 하지 않았다고 한다.

이 소설에서 제리 시걸의 역활은 이 소설에서 기본이 되는 단서를 제공하는 것이다. 제리 시걸의 아버지 미첼 시걸은 러시아 군대에 있을 때 하나의 역사적인 토템를 찾게 되었고, 그것을 제리 시걸에 물려주었다. 그 토템은 하나님의 뜻에 의해 아담이 작성하고 이를 아벨에게 물려줬지만 카인이 가로챈 "거짓의 서"로 알려져있으며, 그것을 찾을 수 있는 단서를 제리 시걸은 그림으로 남겨놓았다.

이 두 가지 이야기를 바탕으로 소설 "카인의 징표"는 시작된다. 소설에 나오는 주인공은 칼 하퍼, 전직 ICE 요원이었으며 잘못된 행동으로 인해 ICE에서 쫓겨난 후 노숙자 쉼터에 근무하고 있다. 전직 목사인 선배 루즈벨트와 순찰 도중 우연히 총상을 입은 아버지 리오드 하퍼를 만나게 된 칼은 이 때부터 아버지와 함께 "죽음의 서"를 쫓게 된다.

아들 칼과 아버지 리오드의 관계는 미묘하다. 칼이 어렸을 때 아버지 리오드는 정신적인 문제가 있는 어머니와의 말다툼 중에 어머니를 밀어 넘어뜨리면서 어머니를 죽게 만든다. 이 모든 모습을 본 칼은 아버지를 어머니를 죽인 사람으로 기억하게 된다. 그리고 칼은 아버지가 교도소에 수감되면서 아버지와 떨어지게 되고, 한 공원에서 총상을 입은 채 쓰러져있는 아버지를 19년 만에 만나게 된다. 소설 속에서 계속 이어지는 아들과 아버지의 미묘한 관계, 서로를 마음 깊이 믿지 못하지만 서로 부자 간의 애틋한 마음을 느끼게 하는 장면들은 소설 속에서 계속 이어진다.

소설 속에서 "죽음의 서"를 쫓는 것은 칼과 리오드만이 아니다. 리오드의 심리치료사로 "죽음의 서"를 찾는 여정에 함께 참여한 세레나가 있고, 동료를 죽인 혐의로 칼과 리오드를 추격하는 연방요원 나오미가 있다. 그리고, 전직 경찰인 엘리스는 "죽음의 서"를 찾는 일이 자기 가문의 숙명이라는 것을 알고 칼과 경쟁하며 "죽음의 서"를 쫓고 있다. 그리고, 이들을 지켜보고 다른 이들의 뒤에서 이들을 조정하는 "예언자"가 있다. 왜 이들은 "죽음의 서"를 찾으려고 하는 것일까? 그리고, 이들 사이에서 칼은 무사히 "죽음의 서"를 찾을 수 있을까? 도대체 "거짓의 서"란 무엇일까?

역사를 바탕으로 쓰여진 미스터리 소설들은 많이 있다. 이런 소설들의 특징은 사실을 바탕으로 하기 때문에 흥미진진하고 읽는 이로 하여금 그 책의 바탕이 되는 역사를 새롭게 인식하게 만든다는 것이다. 또한 이야기의 진행이 대부분 빠르게 진행되기 때문에 읽으며 긴장을 늦출 수 없다.

이런 이유들 때문에 많은 이들이 이러한 소설들을 좋아하지 않나 싶다. 나도 내가 좋아하는 두 분야, 역사와 추리라는 두 분야를 적절히 버무린 소설들을 좋아한다. "카인의 징표" 또한 지금까지 읽어던 어떤 미스터리 소설 못지 않게 재미있었으며 흥미로웠다.

이 소설의 큰 틀은 인간의 욕망과 가족에 대한 사랑이다. 모든 사건은 인간의 욕망 때문에 일어나며, 인간의 욕망으로 다른 사람을 다치게 하고 죽게 만들며 사실을 왜곡시킨다. 하지만, 그 와중에서도 변하지 않는 것은 가족에 대한 사랑이다. 끈끈한 가족의 사랑은 결국 어려움을 헤쳐나가게 만들며 어려움을 지나 서로 이해하게 된다.

댓글(0) 먼댓글(1) 좋아요(1)
좋아요
북마크하기찜하기 thankstoThanksTo
  1. 카인의 징표
    from thoughts.mooo 2010-02-13 21:40 
    책을 받아든 첫 느낌은 책이 상당히 무겁다는 것이었다. 책의 무게가 무거웠다는 것이 아니라 책에서 풍기는 분위기가 왠지 무거워 보였다는 말이다. 600여 쪽 정도 되는 이 책은 책을 읽는 동안 나를 상상과 어지러움 속에 빠져들게 했다. 카인, 책 제목에 나와있는 카인은 누구인가? 카인은 아담과 하와의 큰 아들로 인류 역사상 첫번째 살인을 한 사람으로 성경에 기록되어 있다. 그것도 동생인 아벨을 죽인 존속살인을 한 사람이다. 카인이 아벨을 죽인 이유는..
 
 
 
아키텍트 이야기
야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수 / 인사이트 / 2007년 4월
평점 :
절판


유난히 정년이 짧은 프로그래머, 개발자라는 직업. 보통 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쪽.



댓글(0) 먼댓글(1) 좋아요(1)
좋아요
북마크하기찜하기 thankstoThanksTo
  1. 아키텍트 이야기
    from thoughts.mooo 2010-02-13 21:40 
    유난히 정년이 짧은 프로그래머, 개발자라는 직업. 보통 30대 후반이 넘어가면 개발자로서는 늙었다는 말을 많이 들으며, 자의 혹은 타의에 의해 개발자의 길을 벗어나 관리직 등의 개발이 아닌 다른 길을 찾아야 하는 경우가 많다. 프로그램 개발이라는 것이 창의력을 많이 요구하는 것이다 보니 이런 풍토가 생겨나고 이것이 거의 정해진 것인 양 받아들여지고 있다. 안타깝지만 이것은 현실이다. 이 정도 경력이 되면 이전에는 눈에 보이지 않던 것들이 서서히 보이..
 
 
 
사랑하지 않으면 떠나라! - 개발자의 자기 계발과 경력 관리를 위한 52가지 실천 가이드
차드 파울러 지음, 송우일 옮김 / 인사이트 / 2008년 1월
평점 :
구판절판


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

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쪽.

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

댓글(0) 먼댓글(1) 좋아요(0)
좋아요
북마크하기찜하기 thankstoThanksTo
  1. 사랑하지 않으면 떠나라!
    from thoughts.mooo 2010-02-13 21:40 
    이건 연애 소설의 제목이 아니다. 수필이나 시집도 아니다. 이건 개발자들의 처절한 삶을 극복하게 도와줄 책이다. IT 직종, 거기에서도 개발자들은 상대적으로 낮은 임금과 열악한 근무 환경에서 일을 하고 있다. 남들이 보기에는 멋있어 보이는 직업이지만, 실상 안을 들여다보면 처참하기 그지 없다. 밥 먹듯이 야근하는 것은 기본이며, 자기를 위해 시간을 투자하는 것은 사치일 정도로 어렵게 살고 있는 것이 개발자들의 삶이다. 엎친 데 덮친 격으로 개발자가..