(서평) 프로그래밍은 상상이다 - 자극스러운 내용이지만, 자극적이지 않게 다가오다.

사실 나는 영화를 볼때 예고편이나, 영화에 대한 평가를 가급적이면 듣지 않으려고 한다.

첫째는 편견을 갖지 않기 위해서고, 둘째는 기대감을 갖지 않기 위해서다.

그렇지만 예외도 있는데, 내가 좋아하는 감독이나, 배우가 출연할 때에는 기대감을 갖고 보기도 한다. 이래 저래 예고편이나 관련 정보를 얻기도 하고.

책을 고를때에는 그와 반대로 최대한 많은 정보를 얻고 책을 선택한다. 잘못 선택한 책이 미치는 여파는 생각보다 크기 때문이다.

하지만 임백준씨는 나에게 너무 많은 영향을 주셨고, 임백준씨의 책에 너무 감명 받은 것들이 많은지라, 임백준씨의 책이라면 목차를 보지 않고도 바로 구입하곤 한다.

그리하여 목차도 모르고 받아본 이번 책은 프로그래밍과 상상의 연관관계인줄 알았거늘…!!

그간 기고하셨던 컬럼의 모음집이었을 줄이야…!!

잠깐 충격을 받았지만 다시 정신을 차려보니, 내가 읽었던 글은 하나도 없었다. (이런…마소 정기 구독해달라고 회사에 요청이라도 해야 하나?)

가격이 오른 만큼 페이지수도 두터워져서 읽을거리가 많아졌다는 즐거움에 책을 읽기 시작했다.

이 책을 읽기전에 나도 모르게 가졌던 생각은, 미국과 유럽의 개발 환경이 이상적일 것이라는 점이었다.

책의 서문에서도 밝히셨지만, 어느정도야 더 좋은 면도 있겠지만 전반적으로 우리와 크게 다르지 않다는 것을 알게 되었고, 미국에서도 기준에 부합하지 않는 프로그래머를 채용하게되 고생하거나, 유지보수 프로그래머로써 겪는 애환, 잘못된 기술 선택으로 인한 고통등 결국 문제는 사람(실제 같이 일하는 사람이거나, 나보다 전에 이 일을 했던 사람의 결정, 결과물 등… 결국 사람에 관련이 없을 수 없단 의미로)이었다.

내가 이 책을 읽기전에 고민했던 좋은 프로그래머의 자질에 대한 생각을 다시 하게된 챕터도 있었다.   내가 경험한 바로는 머리가 좋은 사람은 대부분 자신의 판단과 경험을 지나치게 의존해 같이 일하기 힘든 사람이 되곤 한다.

문제 해결 마인드도 차이가 났는데, 문제를 해결하는 능력자체는 뛰어났지만 문제를 단순화 시키려는 노력이나, 문제를 쉽게 풀려는 노력이 부족한 사람이 많았다.

그런 점들은 프로그램의 엔트로피를 상승 시키는 결과를 낳기 때문에 좋은 프로그래머라 할 수 없다.

내가 느끼기에 좋은 프로그래머란 어려운 문제를 푸는 사람보다, 어려운 문제를 쉽게 푸는 사람이라고 생각한다.

임백준씨는 이런 내 생각에 덧붙여, 꼼꼼한 사람이기도 하더라라는 의견도 제시해주셨다.

나는 일을 빠르게 처리하긴 했지만, 일을 많이 할 뿐 실속이 부족했다. 내 자신이 좋은 프로그래머라는 확신을 못갖는 이유가 바로 이런 부분에서다.

나는 프로그램을 작성하고 유지보수 할 때 큰 흐름을 보려는 노력을 많이했고, 실제로 그렇게 해왔다고 생각하는데, 전체적인 흐름에서 작은 변화가 끼칠 수 있는 파장에 대한 고민을 별로 하지 않는 나쁜 습관이 있다.

그렇다보니 문제가 발생했을 때 원인이 뭐였는지, 왜 그런 문제가 발생했는지는 빨리 깨닳지만 거기 까지였다.

문제가 발생하지 않을 만큼 침착한 검토를 하거나, 다양한 상황의 테스트를 거치지 않고 있었다.

내가 하는 일이 촌각을 다투는 상황일 경우가 빈번하고, 그런 상황일수록 복잡한 테스트를 거치기 힘들다는 점으로 봤을 때, 테스트는 편해야 하고, 어느정도 선까지는 자동화 되어있어야 한다.

또한 유닛 테스트 코드가 많아, 쉽게 모듈 테스트 할 수 있는 상황이 많다면, 코드간의 결합도가 낮다는 이야기고 그렇게 되어 있는 프로그램은 실수할 여지가 적다.

성급해질 수 있는 긴급 상황에서의 실수를 줄이는 것은 심리적인 요인을 다스리는 것도 중요하겠지만, 환경적인 요건도 중요하다.

사람은 누구나 실수할 수 있기 때문에, 실수할 여지를 줄이는 노력을 하는것이 좋은 프로그래머다 라는 생각을 갖게 되가는 요즘, 임백준씨도 비슷한 생각을 하셨다는 점에서 좋은 프로그래머에 대한 기준은 거의 다 비슷하구나 싶었다.

상황 중심 프로그래밍 (관점 지향 프로그래밍이라 주로 불린다는) 에 대한 이야기도 흥미로웠는데, 사실 서버쪽 프로그래밍은 유지보수에 대한 문제가 큰 이슈이기 때문에, 상황별로 쓰레드가 별도로 돌거나, 로직을 별도로 돌리며, 객체별로 결합도를 줄이려는 노력을 하고 있다. (아닌 서버가 있을지도 모르지만…적어도 내가 보거나 개발한 서버들에 한해선) 그래서 어떤 로직에서 얼만큼의 시간을 소요하고, 어떤 기능묶음별로 무언가를 해야 할 때 알 수 있는 방법을 이미 마련해둔 상태이지만, 그렇지 않은 경우라면 느끼는 점이 많을 챕터라는 생각이 들었다.

컬럼 모음집인 만큼 이외에도 프로그래머의 자질, 웹 2.0, 패턴, Pov-Ray와 같은 다양한 흥미로운 주제도 많이 접했다.

페이지를 너무 많이 쓰신상태이셔서인지 챕터 5는 PDF로 제공해주셨는데, 개인적으로 책으로 소장하는걸 더 좋아해서 가격이 조금 더 올라가더라도 책에 포함 되어 있다면 좋았겠단 생각이 들어 조금 아쉬웠다.

임백준씨의 책을 읽을때마다 느끼는 거지만, 글 솜씨도 좋으시고 일을 진정 사랑하는 프로마인드를 통해 나에게 늘 자극을 주시고 경각심을 일으켜 주셨다.

내 실력이 좋은지 나쁜지 여부는 큰 관심이 없었고 인기 있는 게임을 만들고 싶었을 뿐인 나에서 좋은 프로그래머가 되고 싶은, 진짜 ‘프로’그래머가 되고 싶은 맘을 갖게 해주셨고, 그 길을 몸소 실천하고 계신 임백준씨의 다음책이 벌써부터 기대된다.

좋은 프로그래머란 무엇일까?

어느 날 문득, ‘좋은 프로그래머’란 어떤 의미일까라는 생각을 하게 됐다.

내가 떠올린 좋은 프로그래머를 분류 해보자면 ‘실력은 보통이지만 같이 일하기 좋은 프로그래머’, ‘굉장히 능력이 뛰어난 슈퍼 프로그래머’, ‘매우 꼼꼼해서 실수를 거의 하지 않는 프로그래머’ 정도로 나뉘어졌다.

생각해보니 나는 어떤 부류에도 포함이 되지 않았다.

현재 내가 생각하고 있는 좋은 코드와 개발 방향에 대한 의지가 너무 강해 같이 일하기 좋은 사람이 되지도 못했고, 슈퍼 프로그래머도 아니며, 실수 빈도도 낮지 않다.

상황이 이렇다보니 나 자신에 대한 확신을 갖기 어려워지고 있었다.

슈퍼 프로그래머는 타고 나는 것이니 패스하고 나머지 두개를 생각해봤다.

내가 같이 일하기 좋은 프로그래머가 되려한다면 어떻게 해야 할것인가?

내가 생각하는 옳은 방식을 버리고 다른 사람이 하자는 방식대로 따라 가기만 하면 일하기 좋은 프로그래머가 되는 것일까? 그건 아닌거 같았다.

그러면 과연 내 어떤 점이 문제였을까 고민을 해봤더니, 토론을 원하지만 토론을 원하는거 같지 않은 대화 습관이 문제였다.

내가 생각하고 있는것과 다른 이야기로 흘러갈 때 어투가 강해지고 목소리가 커지는 태도는 다른 사람들이 보기에 화가 난것 처럼 보였고, 대화하기 꺼려지게끔 만들었더라.

내 의지를 관철 시키기 위해 침착한 말투로 다른 사람을 잘 설득할 수 있다면, 내 의견을 관철 시킬 수도 있고, 일하기 좋은 프로그래머가 될 수도 있겠단 생각이 들었다.

남은 한가지 요건인 ‘꼼꼼한 프로그래머’가 되기 위해서 해야 할일은 무엇일까?

이 부분에서는 일정 부분 좋은 습관과 좋은 환경이 상당 부분 해결해 줄 수 있겠단 생각을 했다.

잘 찾아볼수 있게 할일을 리스트업하고, 우선 순위를 메기는 것만으로도 해야 될일을 놓치는 빈도가 적어질 수 있기 때문이다.

또한 규칙(예를 들면 코딩 인벤션과 같은 것들)을 세우고 그 것을 습관적으로 지킨다면 실수할 여지가 분명히 줄어들었다.

여기서 중요한 것은, 이미 적용중인 규칙을 바꾸려 할 때는 그 규칙이 적용된 모든 것을 바꾸거나, 바꾸지 않거나 해야 된다는 것이다.

규칙을 변경할 때 소급적용한다는 것은 안하니만 못한 결과를 낳았다. 다양한 규칙이 적용된 상태는 규칙이 없는 무질서한 상태나 마찬가지기 때문이다.

지금의 나를 돌아봤을 때 20살때 꿈꿔온 목표했던 것보다 많은 것이 이루어졌다.

그렇다보니 할 수 있구나 하는 자신감도 갖게 됐지만, 욕심이 더 해져 더 큰 목표와 많은 것을 갖게 되기도 했다.   20살 때 세웠던 내 목표중 하나는 ‘기술적으로 뛰어나고, 좋은 게임을 만드는 것’이었다.

하지만 지금은 좋은 사람, 좋은 프로그래머가 되고 싶은 목표로 바뀌었다. 내 꿈이 언제 또 변할지 모르지만, 내 변하고 있는 생각이 옳다고 믿고 최선을 다하면, 결국은 해피 엔딩이 되지 않을까 하는 추상적인 꿈을 꾸며 노력하는 수밖에 없는것 같다.

단점 고치기

사실 누구나 단점은 있다.

내가 생각하는 장점이 남이보기엔 단점일 수도 있으니 말이다.

하지만 중요한 것은, 다수가 단점이라고 하는 데에는 분명한 이유가 있기 마련이다. (뭐, 물리적인 단점이야 어떻게 할 수 있겠냐만은…)

다수가 말한다면 그 단점은 컴플렉스나, 민감한 사항이 아닌, 고쳐야하는 단점이 된다.

단점 고치기에 앞서 가장 먼저 중요한 것은, 그 단점이 왜 생긴 것인지 부터가 될 것이다.

단점이란 문제해결과 굉장히 밀접한 관련이 있다.

단점을 극복하는 과정은 문제 해결을 위한 과정과 매우 흡사하다.

단점을 통해 피해를 보는게 내 자신이 된다고 생각하면, 고치려는 데에 더 많은 노력을 기울이게 되고 결국은 고칠수 있게 된다.

가장 중요한 것은 고치려는 다짐과, 그 것을 지키려는 노력이다.

문제 해결에 끈기와, 정확한 문제 파악이 필요하고, 추리력이 필요한 것이라면, 단점 해결에는 의지와 노력만이 필요하다.

사실 단점 고치기란게 처럼 쉬운건 아니지만 자신의 단점을 많이 고쳐나갈 수 있다면 내 자신과 나를 대하는 사람들 모두에게 좋지 않을까 하는 생각이 든 김에 주절 주절 써보았다.

이 글을 쓰면서 프로그래밍도 결국 사람이 하는 일인데, 좋은 사람이 되어야 좋은 프로그래머도 될 수 있겠다 싶었다.

좋은 사람에 대한 기준은 사람마다 극명하게 다르지만, 나쁜 사람에 대한 기준은 거의 비슷하더라.

좋은 사람이 되고 싶긴하지만, 그런 말에 너무 휘둘리지 말고, 나쁜 사람이 되지 않도록 나쁜 습관만 고쳐도 중간은 가지 않을까 싶다.

루비를 시작했습니다.

Ruby

Ruby는 일본에서 개발된 프로그래밍 언어로, Perl의 자유로운 표현력과 모호함에서, 모호함을 제거하고 객체 지향적인 개념을 도입한 언어입니다.

윈도우와 연동되어 Win32Api를 사용하실 수 있고, Tk, C언어와의 연동 등 다양한 방법으로 활용 가능합니다.

속도상의 문제를 안고 있지만, 게임에서도 스크립트 언어로 채용되기도 했었고, Ruby on Rails나, IronRuby 등 Ruby를 활용한 사례가 늘고 있는 언어입니다.

오픈 소스 프로젝트이므로 직접 빌드해서 사용하실 수도 있고, 루비를 직접 분석할 의향이 없으신 분들은 배포용 릴리즈 버전만 다운 받아도 사용 가능합니다.

루비 공식 홈페이지

Try Ruby

루비 20분 가이드

루비 강좌

C++ 코드 작성시 주의 사항

R-Value를 써라

  • if문에서 변수를 Right Value로 두어라.
  • 실수로 비교문(==)이 아닌 대입문(=)이 사용했을 때의 실수를 막아준다.

상수성(const 키워드)을 애용하라.

  • 변경이 이루어지지 말아야 할 변수나 함수에 const 값 적극 이용하라.
  • const는 변경이 되면 안되는 상황을 인지하게 해준다.

IN,OUT 매크로를 적극 활용하라

  • 함수 인수의 IO가 어떻게 이뤄지는 IN, OUT 매크로를 써서 명시하라.

리턴값은 enum형이나 define으로 정의해서 공통된 값을 적극 사용하라.

  • 통일성 있는 규칙은 코드 분석이나 디버깅시에 직관적이다.

전역 변수는 자제하라.

  • static 변수나, 전역변수의 소멸 시점은 잡기 어렵다. 생성/소멸 순서가 중요하다면 특히나 static 또는 전역 변수로 설정하지 말아라.

# 가상 함수가 존재하는 구조체나 클래스 초기화를 memset을 사용하지 말라

  • 가상 함수 테이블까지 초기화 되어, 가상 함수 호출시 꼬일 가능성이 있다.
  • POD(Plain Old Data = 데이터로만 구성된 자료형)형에만 memset이나 memcpy 등의 메모리 관련 함수를 사용해야 한다.

의미가 있는 변수의 자료형은 typedef 해서 사용하라.

  • 돈, 캐릭터 인덱스 등의 자료형은 typedef 해서 사용하는 것이 자료형 변화에도 유연하고 명시적이다.