2007/12/01   매너리즘 체인지 [1]
2005/03/14   누워서 읽는 알고리즘(2) [4]
2005/03/07   3월 구입 도서 목록 [2]
2005/03/07   누워서 읽는 알고리즘 [2]
2005/03/03   프로젝트는 왜 실패하는가? [2]

동료 책꽂이에 꽂혀져 있는 책 발견...
매너리즘 이라는 단어가 유독 눈에 확 들어왔다.

매너리즘 체인지
히비노 쇼조.히모토 아야카 지음, 이동희 옮김 / 국일미디어(국일출판사)







직장생활을 하는 사람들에게 매너리즘은 항상 싸워서 이겨야 할 대상이다.
내가 얼마전에 싸우다가 이기지 못한 놈이긴 한데, 지금은 이 놈과 싸우는 다른 사람들에게 힘을 보태주고 싶다.

읽어나가기에 그리 쉽지는 않다.
너무 개념적이라서일까?

그래서 이 책에서 전하고자 하는 내용들을 간추려서 정리해본다.

"프라이팬 위의 개구리"
찬물이 담긴 냄비에 개구리를 넣고 조금씩 온도를 높이면 개구리는 처음에는 기세 좋게 헤엄치며 돌아다니다가 점점 움직임이 둔해진다. 마치 온천에 들어간 것처럼 "아, 좋다"고 말하듯이 눈을 감고 있다. 그러다가 물이 더 뜨거워지면 뛰쳐나오지 못하고 마침내 삶아져 죽게 된다.
==> 냄비에 담긴 물의 온도가 점점 높아지는 것은 상황이 시시각각 변화함을 의미한다. 그것이 급속도로 변하든, 서서히 변하든...
==> 냄비에 담긴 물의 온도에 적응하는 것은 과거의 연장선상에서 안주하는 것을 의미한다. 사람은 적응의 동물인가?
==> 결론은 적응만 하다가는 결국 죽는다! 이다.
냄비를 프라이팬으로 바꿔보자. 프라이팬 위에 개구리를 올려놓고 불을 켠다. 냄비속의 개구리와는 다르게 가만히 있을 수 없는 개구리는 팔짝팔짝 뛰게 된다. 프라이팬을 뜨겁게 달구는 불은 변화를 의미한다.
뜨거워지는 프라이팬 위에서 개구리는 어쩔 줄을 몰라 팔짝팔짝 뛴다. 이것을 변화에 대한 저항이라고 볼 수 있다.
변화에 대한 저항을 하기는 하지만 변화를 타파하지 않으면 뜨거워지는 프라이팬 위에서 튀겨지는 개구리가 될 수 밖에 없다.

이 이야기는 변화에 대한 막연한 공포를 가지고 있는 사람 또는 조직에 대한 이야기이다.
즉 변화공포증을 가지고 있다라고 판단된다면 변화에 대한 공포를 없애야 한다.

"프라이팬 밖의 개구리"
앞에서 이야기한 상황과는 반대되게 뜨거워지는 프라이팬에서 탈출을 시도하다가 불 위로 떨어지는 개구리를 의미한다.
변화(뜨거워지는 프라이팬)에 대한 저항을 시도하다가 마침내 그 변화를 극복하기 위해서 프라이팬 밖으로 뛰쳐나갔지만 떨어진 곳은 지금의 변화보다도 더 무서운 뜨거운 불 위였다. 즉 위험을 피해 움직인 곳이 절대 안전지대는 아니었다.
다른 개구리가 프라이팬 밖으로 뛰쳐나가는 것을 본 개구리들은 지금의 변화를 벗어날 방법을 찾은 것으로 착각하여 똑같이 따라한다. 그러다가 똑같이 불 위에서 최후를 맞이한다.
남들 하니까 나도 따라한다 식의 변화탈출 시도를 전례의존증이라고 명명하였다.

오늘은 일단 위 두 가지 이야기에서 말하고 있는 변화공포증과 전례의존증에 대해서만 정리해보도록 하겠다.

변화공포증은 현재 느끼는 변화를 막연하게 두려워하여 이러지도 못하고 저러지도 못하다가 결국에는 변화에 잡혀먹히는 결과를 초래하게 만든다.
변화가 오면 반드시 생각해야 한다.
변화에 대한 대응으로서 변화에 성공한 남을 무조건 따라하는 증상이 전례의존증이다.
남이 성공했으니까 나도 성공하겠지 라는 안일한 사고방식으로는 결코 성공을 거둘 수가 없다.
남의 성공을 분석하여 나의 성공 방법화시키는 과정이 반드시 필요하다.

더 중요한 것은 아무도 프라이팬으로부터 뛰쳐나가지 못하고 있는 상황에서 최초로 뛰쳐나감을 실행한 개구리의 마인드이다.
생각없이 프라이팬 위만 벗어나면 된다는 단순한 생각 때문에 미처 아래쪽에 있는 불을 고려하지 못하고 죽음의 길로 접어든 것이다. 만약 이 개구리가 전례의존증에 사로잡혀 있었다면 감히 프라이팬 위에서 뛰쳐나갈 생각은 할 수 없었겠지만, 무턱대고 앞으로 나가는 것도 그리 좋은 것은 아니다 라는 것을 깨우쳐 주기에 충분하다.

결국 이 책은 다음과 같은 결론을 말하고 있다.

변화공포증을 타파하여야 하지만 전례의존증에 사로잡혀서는 안된다.
변화를 받아들이고 새로운 상황에 대처하기 위해서는
1. 근본을 생각하고
2. 전체에서 사물을 바라보고
3. 미래를 생각하며 배우고
4. 계속적으로 다음 수를 생각해야 한다.

누워서 읽는 알고리즘
임백준 지음 / 한빛미디어

두 번째 정리 내용이다.

"분업이 불가피하기 때문에 실전 프로젝트에서는 개개인의 개인기 못지않게 팀워크(team work)가 중요하다."

사실 아직도 많은 프로그래머들은 나의 실력만 뛰어나면 되고, 내가 모든 것을 제대로 해낼 수만 있다면 어디에서든지 환영받을 수 있을 것이라고 생각한다.
그러나 어느 정도 제대로 된 조직에서 일해본 사람이라면 이런 생각이 옳지 않을 수도 있다는 것을 깨달을 수 있을 것이다.
내가 아무리 잘해낸다고 한들, 나 혼자서 많은 기능을 정해진 시간 안에 완성시킨다는 것은 요즘의 프로젝트 진행방법상 비효율적이며, 그렇게 만들어진 프로그램이 개인 프로젝트 이상의 의미를 갖기는 힘들어진다.
설령 많은 사람들에게 인정받는 프로그램이 나 혼자의 힘으로 만들어졌다고 하더라도 그것을 사용하는 사람들 역시 그 프로젝트에 있어서는 하나의 팀인 것이다. 고객이 요구하는 내용을 프로그래머가 제대로 캐치하지 않고 독단적으로 결정하여 개발해 나가게 되는 경우 팀워크는 당장 깨지게 되는 것이다.

"실제로 중요한 것은 문제를 푸는 속도가 아니라 끝까지 포기하지 않고 문제를 해결하려고 하는 '프로' 근성이다."

우리들에게 있어서 '프로'근성은 역시 지칠줄 모르는 노력에서부터 시작된다. 노력하지 않고 화려한 코딩 능력 및 기술을 습득할 순 없으며, 자기개발을 하지 않고는 더 이상의 발전은 없다. 결국 이런 바탕 위에서 '프로'그래머가 탄생하게 된다.

"각 알고리즘이 구현하고 있는 핵심적인 방법론을 '이해'하는 것이 중요하다. '이해'한 다음에는 '의심'을 해야 한다. 과연 이것이 최선일까? 혹시 여기를 이렇게 바꾸면 더 낫지 않을까? 이런 의심과 실험은 컴퓨터 프로그래머에게 가장 소중한 덕목이다."

요즘은 인터넷에서 손쉽게 다양한 소스코드를 구할 수가 있다. 프로젝트를 빠르게 완료하기 위해서는 이미 누군가가 만들어놓은 알고리즘을 가져다가 사용하는 것도 필요하다. 그러나 가져다가 사용하는 것으로 끝나서는 안된다. 왜 이 알고리즘이 내 프로젝트에 필요하며, 이 알고리즘은 도대체 어떤 구조로 수행되는 것인지 한번쯤은 고민해보고 사용하는 것이 필요하다.
그리고 반드시 개선 여지가 있는지에 대한 분석도 해볼 필요성이 있다.
자신이 스스로 만든 알고리즘 역시 사용자(다른 프로그래머)의 입장에서 한번쯤은 더 생각해보는 습관을 들일 필요가 있다.
너무 쉽게 얻는 것은 너무 쉽게 잃을 가능성이 크다.

"어떤 사실을 정확하게 이해한 사람은 자신이 이해한 내용을 쉽고 간결하게 설명할 수 있지만, 그렇지 않은 사람은 중언부언하면서 쉬운 이야기를 어렵게 한다. 경험이 풍부하고 실력이 뛰어난 프로그래머가 작성한 프로그램을 읽는 일은 그래서 즐겁다. 코드에 군살이 하나도 없는 대신 구현하고 있는 논리가 잘빠진 근육처럼 탄탄하고 빈틈이 없다. 버그가 원래 군살을 파고든다는 점을 생각해 보면 알고리즘을 군더더기 없이 간결하게 만드는 것은 상당한 '실력'에 속하는 일이다."

정말 그렇다. 실력있는 프로그래머는 소스코드로 모든 것을 설명한다는 말이 있다.
굳이 주석을 길게 붙여놓지 않더라도 소스코드만 읽으면 모든 것을 이해할 수 있도록 코딩하는 것이 가장 바람직스럽다고 생각한다.

"개인적으로 제일 강조하는 부분은 코드의 '가독성'이다. 아무리 성능이 뛰어난 코드라고 해도 소스코드가 괴발개발이면 무조건 빵점이다."

어느 정도의 일반적인 규칙 정도는 지켜가면서 코딩하는 것이 동료를 위해서 좋은 일일 것 같다. 프로그래머들 사이에서는 프로그램.exe 가 아닌 프로그램소스.cpp 를 공유하기 때문이다.

3월달 목표 : 닥치는 대로 읽자!!

누워서 읽는 알고리즘
임백준 지음 / 한빛미디어

책을 읽으면서 마음에 새기고자 하는 문장 정도는 밑줄을 그어가면서 읽는 것이 책을 쓴 사람에 대한 예의가 아닐까...하고 생각해본다.

그런 의미에서 이 책을 읽으면서 밑줄 그은 문장들 중에서 특히나 공감가는 부분들을 한번 정리해보았다.

"일단 구체적인 날짜를 확인해 주었으면 시간을 엄수하는 것은 직업적 프로그래머에게는 생명과 다를 바 없는 약속이다. 프로그래머는 프로그램을 잘 짜면서 시간도 잘 지키는 사람과 프로그램은 다소 서툴게 짜지만 시간은 잘 지키는 사람으로 구분할 수 있다. 시간을 제대로 지키지 못하는 사람은 아예 프로그래머라고 불릴 자격이 없다."

실제로 프로젝트를 진행하다보면 최초 결정한 예상일정보다 늦어지는 일이 비일비재한 것이 현실이다. 늦어지는 이유를 따져보면...
1. 해당 업무 이외에 투자해야 하는 시간이 당초 예상보다 훨씬 많아서.
2. 해당 업무를 소화하는데 있어서 예상외의 일(알고리즘의 비효율성, 예상할 수 없었던 문제점 발생 등)이 터져서.
3. 몸이 아파서 또는 술을 너무 많이 마셔서.
4. 소스를 통째로 날려먹는 등의 천재지변성 사고에 의해서.
등등이 있을 것이다.

그래도 프로그래머라는 직업을 자신의 천직이라고 생각하는 사람이라면 예상일정을 좀 더 현실적으로 계획하거나 계획된 예상일정은 곧 죽어도 지켜야 한다는 것이 나의 지론이다.
어쩔 수 없이 일정을 지킬 수 없게 되는 경우(이런 경우...많다) 미리 PM에게 이야기를 해서 좀 더 시간을 벌거나, 일정을 지킬 수 있는 한도까지만 업무를 해결하는 것도 하나의 방법일 것이다.
너무 완벽하게 하려하면 너무도 당연하게 예상일정을 못 지키는 사태가 속출하고 만다.

예전에 회사워크샵에 가서 어떤 동료와 설전을 벌였던 기억이 떠오른다.
완벽하게 만드는 것이 진정한 프로그래머다. 라는 주장과 완벽하게는 못하더라도 기한내에 완성할 수 있는 능력을 갖춘 것이 진정한 프로그래머의 자세다. 라는 주장의 대립이었다.

나 역시 완벽함을 추구하는 사람 중의 하나이지만 전자의 주장을 쉽게 동의할 수는 없었다.
지금에 와서는 더욱 더 후자의 주장을 설파하고 다니는 상황이다.

"아무리 간단한 코딩이라고 해도 프로그래머는 '실수'로부터 자유롭지 못한 인간이기 때문에 꼼꼼한 테스트는 '선택'이 아니라 '필수'다. 간단한 테스트를 통해서 미리 발견할 수 있었던 버그를 실제 사용자가 발견하는 것은 비용의 손실이기 이전에 프로그래머의 수치다."

그렇다. 맞다. 프로그래머의 수치다. 그런데 이런 현상이 "나도 어쩔 수 없다구" 라는 변명에 파묻혀 자꾸만 반복되면 나 자신에 대한 용서가 자연스러워지며 다른 사람들로부터도 자연스럽게 용서받을 수 있는 상황이 되어버린다. 아무렇지도 않게 용인되고 묵인되는 상황이 되다보면 프로그래머의 존재 자체는 무의미해져 버리게 된다.
프로그래머 존재의 이유는 프로그래머 스스로 만들어가야 하지 않을까라는 생각이 든다.

"실전 프로그래밍에서 발생하는 버그는 많은 경우에 특정한 알고리즘 자체가 품고 있는 논리적 결함보다는 프로그래머가 방어적 프로그래밍(defensive programming)을 게을리해서 발생하는 경우가 더 많다."

이 말 역시 크게 동감하는 부분이다. 버그는 바로 프로그래머 자신이 만드는 것이다. 따라서 버그를 줄이는 것 역시 프로그래머가 할 수 있는 부분이다.
방어적 프로그래밍 방법을 배우기 좋은 책을 추천하자면 "Writing Solid Code : 버그 안녕" 이 있다. 이 책에서는 버그를 줄일 수 있는, 그리고 버그를 빨리 발견할 수 있는 여러가지 코딩 기법들을 소개하고 있는데, 실제로 나에게 많은 도움을 주었다.

"프로젝트의 일정에 쫒기다 보면 사실 '방어적 프로그래밍'을 할 시간적 여유를 찾기 어려울 때가 많다. 하지만 그것이 습관이 된다면 결코 많은 시간이 걸리지 않을 것이다."

방어적 프로그래밍이 습관이 되어 있지 않기 때문에 그것을 습관화시키는데 드는 비용과 시간은 감수해야 한다. 말 그대로 습관을 바꾸면 그것이 습관이 되는 것이기 때문이다.

"타인의 시선을 의식하지 않고 혼자만의 코드를 작성하는 사람은 진정한 의미에서 결코 좋은 프로그래머라고 할 수 없다."

코딩 스타일에 대한 이야기이다. 나의 경우에는 가장 우선적으로 내가 읽기 편하게 코드를 작성한다. 예를 들면 (A == B) ? "yes" : "no"; 라고 쉽게 한 줄로 작성할 수 있다고 하더라도 굳이 일부러 다음과 같이 쉽게 풀어쓴다.
if (A == B)
{
    "yes";
}
else
{
    "no";
}
내가 쉬우면 다른 사람도 쉬울 확률이 크기 때문이다.

"좋은 프로그래머는 소설도 읽고, 영화도 보고, 농구도 하고, 기타도 치고, 정치 토론에도 참여하고, 연애도 하고, 술도 마시는 열정적인 사람이다. 진정한 상상력은 삶의 속살을 이해할 때 비로소 풍부해지기 때문이다."

그래서 나는 요즘 소설도 읽고, 영화도 보고, 정치 토론에도 참여하고, 연애도 하고, 술도 마시고 있다. 프로그래머는 창의성을 가진 사람이어야 하고, 창의성은 많은 것을 경험해봐야만 쉽게 이룰 수 있다고 생각하기 때문이다. 아직도 경험해봐야 할 것들은 많다.

아직 정리하지 못한 것들이 많은데, 차차 또 정리해 나가도록 하겠다.

프로젝트는 왜 실패하는가?
이토 켄타로 지음, 이소연 옮김 / 성안당
나의 점수 :

SI 프로젝트가 싫었는데 어쩔 수 없이 SI 프로젝트를 수행해온지 6년이 되었다. 싫기는 했지만 즐거움도 보람도 많이 느낀다. 과연 지금 내가 하고 있는 프로젝트는 성공한 것인지, 실패한 것인지...반 정도 읽었는데, 어떻게 하면 프로젝트를 성공시킬 수 있는지에 대한 명쾌한 해답이 있을 것 같은 책이다.

다 읽어보고 다시 한번 지금 수행하고 있는 프로젝트와 조인을 시켜봐야겠다~