Skip to main content

코딩 호러의 이펙티브 프로그래밍

이펙티브(effective) 라는 단어는 이상하게도 소프트웨어 관련 서적의 제목으로 많이 등장하고 있다. 이펙티브 자바[1], 이펙티브 C++[2], 이펙티브 STL[3] 등 이펙티브를 제목으로 하고 있는 많은 책들을 어렵지 않게 찾아볼 수 있다. 아마도 이것은 프로그래머들이 중요하게 수행하고 있는 업무 중에 하나가 소프트웨어를 시스템에서 효율적으로 동작하게 하는 것이기 때문일 것이고 이런 제목의 패턴들은 그들의 관심을 쉽게 끌기 위한 것으로 생각한다.

내가 최근에 읽은 '코딩 호러의 이펙티브 프로그래밍(Effective Programming: More Than Writing Code)[4]'도 이펙티브의 제목 패턴을 가지고 있었다. 아마 나도 이펙티브라는 단어 때문에 나도 모르는 사이에 관심을 가지고 선택하게 된 건인지도 모르겠다. 이 책은 제프 앳우드(Jeff Atwood)가 그의 코딩 호러(Coding Horror)[5]라는 블로그에 포스팅한 내용을 책으로 엮어 낸 것이다. 예전에 조엘 스폴스키(Avram Joel Spolsky)[6]가 했던것과 매우 비슷하게 말이다. 심지어 제프는 조엘과 가까운 사이로 공동으로 스택 오버플로우를 창업하기도 했다. 내 생각에 그는 물론 매우 뛰어난 프로그래머이겠지만 어떤 면에서는 조엘의 쫓는 팔로어(Followers)  정도가 아닐까 라고 생각한다.

이 책은 프로그래머들이 알고 있으면 좋을 내용이 다수 담겨져 있다. 하지만 글쓴이의 주관이 많이 반영된 것으로 반드시 그가 주장하는 것이 맞다는 과학적인 근거는 없다. 따라서 나는 이런 류의 책을 읽는 독자는 그가 주장하는 것을 받아들일지를 본인의 경험에 비추어 다시 재검증하는 과정이 꼭 필요하다고 생각한다. 나 또한 이러한 검증 과정을 거쳤다. 내가 이 책을 읽으면서 공감했던 부분과 그렇지 못했던 부분이 있었는데 그것들을 정리하면 다음과 같다.

먼저 나는 프로그래머를 여덟 개의 단계로 나누어 분류한다는 것에 공감하지 못했다. 제프 앳 우드는 프로그래머에는 여덟 단계가 존재한다고 했다. 프로그래머의 최고 단계로는 다익스트라(Dijkstra)[7]나 도널드 커누스(Donald Knuth)[8]같이 죽은 후에도 그들의 코드가 쓰이는 죽은 프로그래머의 단계가 있다고 말한다. 그리고 빌게이츠(Bill Gates)[9] 처럼 널리 알려져 있고 비즈니스에도 성공한 성공적인 프로그래머도 있으며, 유명한 프로그래머, 이직 걱정 없는 일할 수 있는 프로그래머, 평균적인 프로그래머, 아마추어 프로그래머, 주위에 나쁜 영향을 미치는 프로그래머가 있다고 정의한다.

여덟 가지 분류 중에 나는 아마 평균적인 프로그래머는 되지 않을까라고 생각한다. 이렇게 생각한 이유는 단순히 프로그래머라는 직업으로 수년간 직장생활을 하고 있기 때문이다. 내 명함에도 프로그래머라고 적혀있고 그 명함을 다른 사람에게 인사차 건네도 내가 하는 일에 대해서 의심하는 사람은 없을 것이다. 그리고 아직은 다행히 회사에서 그만 나오라는 소리를 듣고 있지 않으니 나는 아마추어나 나쁜 프로그래머는 아닐 것으로 생각한다. 하지만 나는 어느 회사나 나를 원하고 있지는 않고 기술적으로 직장 걱정이 없을 만한 수준은 아니니 그 이상의 단계는 되지 않을 것이라고 생각한다.

제프 앳우드는 나 같은 평균적인 프로그래머는 자신에게는 자신에게 더 맞는 다른 직업을 찾기를 권하고 있다. 보통 평균적인 능력을 가지고 있는 사람들이 그렇듯 소수의 엘리트(elite)로 발전하지 못할 것이기 때문이라는데 나는 이 부분에 대해서 전혀 동의할 수 없었다. 심지어 나는 내가 평균적인 프로그래머라는 사실을 깨닫고 난 후 그의 이런 주장에 대해서 조금 기분이 나쁘기까지 했다. 하지만 곧 나는 그가 단순히 어떠한 과학적 근거 없이 매우 주관적인 주장을 하고 있다는 점에서 안심이됐다. 나도 그가 했던 것과 비슷하게 경험과 비유를 통해 그의 주장을 반박해본다.

나는 프로그래머는 예술가와 닮아 있다고 생각하지는 않는다[10]. 하지만 이해를 돕기 위해서 프로그래머를 유명한 예술가에 비유해 그 단계를 설명해 보려고 한다. 다익스트라 같이 뛰어난 업적을 이룬 사람을 화가로 비교하면 파블로 피카소(Pablo Ruiz Picasso)[11] 정도가 될 것이다. 왜냐하면 피카소는 주목할 만한 뛰어난 작품을 남겼을 뿐만 아니라 새로운 시도를 통해 역사적으로 뛰어난 업적을 이루었기 때문이다. 그리고 평균적인 프로그래머를 화가의 비유에서 찾는 다면 빈센트 반 고흐(Vincent Willem van Gogh)[12] 또는 에드바르 뭉크(Edvard Munch)[13] 정도일 것이라고 생각한다. 그렇게 생각한 이유는 고흐는 어렸을 때 부터 천부적인 재능을 발휘했다고 기록한 것을 찾을 수 없고 심지어 신학을 공부하는 등 화가와 다른 길을 선택하기도 했지만 청년 이후에 그의 노력이 결실을 맺어 뛰어난 작품들을 만들어 냈기 때문이다. 그리고 뭉크는 내가 아는한 유명한 작품이 '절규(The Scream)[14]' 이외에는 찾을 수 없었기 때문에 평균적인 화가가 아니였을까 생각한다.

피카소는 분명 뛰어난 화가임이 틀림없고 3만 점에 이르는 수많은 작품을 남겼지만, 그의 대표작품의 이름을 기억하고 있는 사람이 있는지 궁금하다. 미술을 전공한 사람을 제외하면 아마 대부분의 사람들이 알지 못할 것이다. 단지 피카소를 통해 입체적인 내용의 그림을 떠올릴 수 있는 정도뿐이다. 고흐나 뭉크의 경우는 어떠한가? 고흐의 '별이 빛나는 밤에(Starry Night Over the Rhone)[15]'나 뭉크의 절규는 그림을 잘 알지 못하는 일반인에게도 지금까지 사랑받고 있고 피카소보다 더 많은 사람들에게 기억되고 있다. 소프트웨어의 세계에도 마찬가지이다. 어느 일반인이 다익스트라가 개발한 알고리즘을 알고 있겠는가? 일반인은 현재 자신이 유용하고 사용하고 있는 소프트웨어만 알고 있을 뿐이다. 심지어 그 소프트웨어의 이름을 알지 못하고 사용할지라도 말이다. 이처럼 꾸준한 평범함이 만들어 내는 가치는 더 크다고 생각한다.

반면에 그가 주장한 고무오리 문제 해결법에 대해서는 공감했다. 고무오리 해결법이란 상징적인 고무오리에게 자신의 문제를 설명하므로써 설명하던 도중에 문제의 해결법을 스스로 찾을 수 있는 것을 말한다. 나의 경험을 돌이켜 보면 나 또한 이 방법으로 문제를 해결했던 적이 많았던 것 같다. 처음에 어려운 문제라고 생각하던 것이라도 주위 사람들에게 도움을 요청하기 위해 내 문제를 설명하는 도중 문제의 해결방법을 찾을 수 있을지도 모른다.

EBS에서 방영했던 "공부의 왕도[16]"에서도 이와 비슷한 내용이 나온 적 있다. 내용은 미국 명문대 학생들과 우리나라 보통의 학생들을 비교해보면 실제로 어렸을 때에는 우리나라 학생이 더 어려운 문제를 잘 푸는 경향이 있다. 하지만 우리나라 학생은 자라면서 그 능력을 꾸준히 향상시키지 못하고 있었는데 그것은 혼자 공부하는 습관 때문이었다. 이와 반대로 미국 명문대 학생들은 어렸을 때는 기본 능력이 조금 뒤처져 있을지 몰라도 자라면서 여러 사람과 문제를 나누고 서로의 토론을 통해 더 많이 배울 수 있다고 한다. 이처럼 프로그래머의 세계에서도 여러 사람들과 자신의 문제를 나눌 때 더 많은 것을 배울 수 있다고 생각한다.

그리고 회의는 짧게 하라는 그의 주장에도 공감했다. 그는 극단적으로 회의는 일이 죽으로 가는 장소라고 말하고 있다. 나는 그 정도는 아니어도 회의가 잦아지면 일에 지장을 주는 것은 불가피하다고 생각한다. 그렇게 때문에 그는 어떤 회의라도 한 시간을 넘기면 안 되고 모든 회의에 명확하게 정의된 목표가 있어야 한다고 주장한다. 그리고 그가 제안한 회의에 참석하기 전에 회의에서 필요한 일을 먼저 하라는 것과 회의 참석하는 것은 선택사항으로 하는 것 그리고 회의를 마무리할 때는 할 일을 정리하는 것은 나도 꼭 필요하다고 생각한다.

여기까지가 내가 "코딩 호러의 이펙티브 프로그래밍"을 읽고 느낀 점들의 기록이다. 이 외에 좋은 내용들이 많이 담겨져 있다. 추후 책을 읽어볼 사람들을 위해서 서두에 말했듯이 책의 내용을 자신에게 맞게 취사선택해야 한다는 것을 다시 한 번 상기시키며 글을 마친다.


References

[1] (2009). 이펙티브 자바(EFFECTIVE JAVA) – Daum 책. Retrieved August 18, 2013, from http://book.daum.net/detail/book.do?bookid=KOR9788986044768.
[2] (2008). Effective C++ (이펙티브 C++) - Daum. Retrieved August 18, 2013, from http://blog.daum.net/shuaihan/15437997.
[3] (2006). 이펙티브 STL - 알라딘. Retrieved August 18, 2013, from http://www.aladdin.co.kr/shop/wproduct.aspx?ISBN=8956743118&partner=egloos.
[4] (2012). Amazon.com: Effective Programming: More Than Writing Code ... Retrieved August 18, 2013, from http://www.amazon.com/Effective-Programming-More-Writing-ebook/dp/B008HUMTO0.
[5] Jeff Atwood (2004). Coding Horror. Retrieved August 18, 2013, from http://www.codinghorror.com/.
[6] (2003). Joel on Software - 조엘 온 소프트웨어. Retrieved August 18, 2013, from http://korean.joelonsoftware.com/.
[7] (2006). 데이크스트라 알고리즘 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%81%AC%EC%8A%A4%ED%8A%B8%EB%9D%BC_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98.
[8] (2004). 도널드 크누스 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%8F%84%EB%84%90%EB%93%9C_%ED%81%AC%EB%88%84%EC%8A%A4.
[9] (2003). 빌 게이츠 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%B9%8C_%EA%B2%8C%EC%9D%B4%EC%B8%A0.
[10] (2011). 라떼군 이야기 (Mr.Latte Story): 해커는 화가를 닮지마라. Retrieved August 20, 2013, from http://www.mrlatte.net/2009/09/blog-post_5748.html.
[11] (2004). Pablo Picasso - Wikipedia, the free encyclopedia. Retrieved August 19, 2013, from http://en.wikipedia.org/wiki/Pablo_Picasso.
[12] (2003). Vincent van Gogh - Wikipedia, the free encyclopedia. Retrieved August 20, 2013, from http://en.wikipedia.org/wiki/Vincent_van_Gogh.
[13] (2003). Edvard Munch - Wikipedia, the free encyclopedia. Retrieved August 20, 2013, from http://en.wikipedia.org/wiki/Edvard_Munch.
[14] 파일:The Scream.jpg - 위키백과 - Wikipedia. Retrieved August 20, 2013, from http://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:The_Scream.jpg.
[15] (2008). File:Starry Night Over the Rhone.jpg - Wikimedia Commons. Retrieved August 20, 2013, from http://commons.wikimedia.org/wiki/File:Starry_Night_Over_the_Rhone.jpg.
[16] (2010). 공부의 왕도 - EBSi. Retrieved August 18, 2013, from https://www.ebsi.co.kr/ebs/pot/pote/retrieveStdKingIntro.ebs.

Popular posts from this blog

클라우드 컴퓨팅(Cloud Computing) 기술 정리

1. 클라우드 컴퓨팅(Cloud Computing)이란?

클라우드 컴퓨팅에 대해서는 현재 매우 다양한 정의가 존재한다. 이 중 몇 가지를 정리하면 다음과 같다. 첫 번째 정으로 클라우드 컴퓨팅은 다양한 클라이언트 디바이스에서 필요할 때 언제든지 인터넷을 이용한 공유 풀에 있는 서버, 스토리지, 어플리케이션, 서비스 등과 같은 IT 리소스에 쉽게 접근할 수 있게하는 모델이다.

또 다른 정의로는 서로 다른 물리적 위치에 존재하는 컴퓨터들의 리소스를 가상화 기술로 통합해 제공하는 기술이라고도 생각할 수 있다. 개인적으로 클라우드 컴퓨팅의 개념을 이해는데 세일즈포스닷컴(www.salesforce.com)[1]이 만든 이 동영상[2]이 전반적인 이해를 돕는데 매우 유용하다. 아래 그림은 여러 대표적인 클라우드 서비스들의 사용 예를 보여주고 있다.



1.1. 클라우드 컴퓨팅의 장점[4]

사용자가 자신의 필요에 따라 무한정의 컴퓨팅 자원을 사용할 수 있다는 환상(Illusion)을 제공한다. 그러므로 사용자는 하드웨어와 소프트웨어 시스템을 제공하는 계획을 미리 세울 필요가 없다. 사용자는 작은 시스템으로부터 시작할 수 있고 시스템 자원에 대한 요구가 증가함에 따라 시스템 자원을 증가시키면 된다. 필요에 따라 짧은 시간을 단위로 (예를 들어 프로세서를 시간 당 또는 스토리지를 날짜 당) 사용하고 비용을 지불하면 되고 필요가 사라지면 자원을 더 사용하지 않을 수 있다.

1.2. 기존 클라우드 컴퓨팅 사례1.2.1. 아마존
EC2(컴퓨팅 서비스)Auto Scaling(자동으로 서버 생성 가능)Elastic Load Balancing(소프트웨어 로드벨런싱 기능)CloudWatch(모니터링 정보 제공)Amazon Elastic Block Store(EBS, 빠르고 안정적인 스토리지)Amazon Simple Storage Service(Amazon S3, 스토리지 서비스)SimpleDB(데이터베이스 서비스)
1.2.2. 구글
GFS(구글파일시스템, 대용량 파일 처리 가능 시스템)MapR…

규칙기반 전문가 시스템 (Rule-based expert system)

컴퓨터로 어떤 일을 시킬 때 보통은 명확한 규칙에 따라서 처리하게 된다. 그 이유는 아직 컴퓨터는 인공지능을 갖지 못하였다. 인간처럼 여러 가지 지식과 현상을 조합해 사고하지 못한다는 말이다. 그 때문에 사람이 컴퓨터의 능력을 이용해 어떤 일을 처리할 때는 일련의 규칙이 필요했다. 예를 들면 IF … Then … Else로 표현되는 규칙을 적용하는 것이다.

하지만, 실생활의 문제들은 이것들도 표현할 수 없는 것들이 너무 많다. 인간이 생각하는 거의 모든 것들이 이런 모호함의 집합이다. “오늘 날씨 너무 덥다. 시원하게 에러컨좀 틀어!”라고 했을 때 “너무 덥다.”, “시원하게” 등의 말들은 컴퓨터가 처리할 수 없는 것들이다. 몇 도로 온도를 유지했을 때 시원하다고 느끼는지 컴퓨터 자체만으로는 알 수가 없다. 컴퓨터는 정확히 수치화된 데이터만 가지고 처리하는 기계이기 때문이다. 이런 문제들을 처리하는 여러 방법의 하나인 규칙기반 전문가 시스템(Rule-based expert system)에 대해 얘기해 보겠다.

이처럼 컴퓨터가 처리해야 하는 문제들은 어떤 분야의 전문가가 처리하던 것을 컴퓨터가 대신하는데 의미가 있다. 나는 이것을 전문가의 지식을 처리한다고 정리한다. 그리고 전문가라고 불리는 사람들은 어떤 지식에 대해 규칙을 만들 수 있는 사람이고 규칙이란 앞서 얘기했던 대로 IF … Then … Else 형태로 표현할 수 있는 것을 말한다.

규칙기반 전문가 시스템은 관련주제에 지식이 풍부하고 관련 문제를 푸는데 능숙한 주제 전문가(domain expert), 전문가 시스템을 테스트하고 규칙을 추론할 수 있는 지식공학자(knowledge expert), 전문가 시스템의 개발 리더인 프로젝트 관리자(project manager), 프로그래머(programmer) 그리고 최종사용자(end-user)로 구성되어 있다.

또한, 규칙기반 전문가는 기반지식(knowledge base), 데이터베이스(Database), 추론 엔진(Interface engine), 해설설비…

인터넷이 우리 사회에 미치는 영향

믿기 어렵겠지만 몇 년 전만 해도 간단한 정보를 검색하기 위해선 백과사전이 필요했고 적은 분량의 백과사전에서 찾을 수 없을 땐 도서관에 가야 했고 또 작은 도서관에서 찾을 수 없을 땐 좀더 큰 도서관으로 가야 했었다. 과연 지금의 중학교, 고등학교 학생들은 과연 몇 명이나 이래야만 했던 사정을 이해해줄지 모르겠다.

하지만 이제는 사정이 달라졌다. 인터넷의 등장으로 예전처럼 정보검색에 수많은 시간과 노력을 쏟지 않아도 더 쉽게 더 좋은 자료를 검색할 수 있고 그를 여러 가지 형태의 미디어로 접할 수 있는 시대가 되었다. 예전에 ‘팀 버너스 리(Tim Berners-Lee)’ 가 처음으로 구체적으로 주장했던 하이퍼미디어(Hypermedia)와 그로 이루어진 인터넷으로 인해 우리 생활은 많이 변화했고 또 이제는 없어서는 안될 것으로 멀티미디어 환경으로 진화해 왔다는 사실은 아무도 부인하지 못할 것이다.

사실 인터넷의 등장만으로도 우리에겐 막대한 영향을 끼쳤다. 하지만 여기서 인터넷의 멀티미디어로서의 역할을 배제한다면 그 영향력을 전부 얘기하지는 못할 것이다. 멀티미디어로서의 인터넷은 위에서 얘기한 것처럼 빠른 정보검색은 물론이고 보다 효율적인 방법으로 정보전달의 기능을 가지고 있다.

대학교 1학년 때 처음 컴퓨터를 공부할 때 일이다. 네트웍에 대해 공부하고 있었는데 마침 네트웍을 설명하고 있는 동영상을 인터넷에서 발견했다. ‘The dawn of the Net’ 이라는 동영상 이였는데 네트웍 패킷이나 라우터, 라우터 스위치 등등 전체적인 네트웍에 대해서 알기 쉽게 설명한 동영상이었다. 이 동영상은 너무 쉽고 직관적이어서 누구라도 이것을 본 사람이라면 네트웍에 대해 모두 안 것 같은 착각을 하게 만들 정도였다. 하지만 대략적인 네트웍에 대해서 안다고 해서 전문가가 되었다고 말할 수는 없을 것이다. 간단해 보이는 현상 뒤에 숨겨져 있는 지식들을 모두 이해하고 설명할 수 있을 때 비로소 전문가라 부를 수 있을 것이다.

이런 멀티미디어적인 환경은 대부분에 사람들에게 보다…