Read The Greate Code

작가들은 흔히들 질문을 받고는 한다.
"어떤 책이 당신에게 가장 큰 영향을 주었나요?"

우리도 질문을 받아야 한다.
"무슨 방면에 일하고 있나요?" 혹은 "요즘 하는 프로젝트는 무엇인가요?" 대신
"어떤 코드가 당신에게 가장 큰영향을 주었나요?" 라는 질문을 말이다.

명작을 통해 얻을 수 있었던 것은 필자에겐 두가지 정도가 있었던거 같다.
자신의 작품에 대한 모티브을 제공받고 명작이 쓰인 시대상을 벗어나고자 하는 사상을 제공받게 된다.

1. 자신의 작품에 대한 모티브을 제공
 - 나에게 가장 영향을 많이 주었던 코드는 무엇이었을까? 다시 말해 살면서 가장 많이 읽었던 코드는 무엇일까?
라는 질문이 아닐까? 그렇게 보니 역시나 win32를 배우던 시절의 "first.cpp"와 "Socket 프로그램" 코드였던거 같다. 둘다 아직도 코딩중 잘 풀리지 않을때 작은 창을 열어두고는 업무에 열중하는 척하며 연습하는 코드들이다.
 코드를 짜다보면 비지니스단이나 프레임워크단에서 헤메이는 경우가 많다. 하지만 개발툴을 잡고 있는 시간만 길뿐 아무것도 하지 않는 경우가 대부분인데 이럴때 메모장을 열어두고 가장 자신있는 코드를 적어나가다 보면 해결점을 찾아 낼때가 많다. 가장 자신있던 그 시절의 그 코드를 코딩하던 느낌이 살아나기 때문이 아닐까 생각해본다.

2. 시대상을 벗어나고자 하는 사상
회사를 다니면서 3~5년차 선배들에게 가장 많이 듣는 이야기가 있다. 그것은 바로 "현재 시스템은 다 뜯어 고쳐야해"라는 말이다. 시스템주기가 5년이라고들 한다 하지만 운영되고 있는 시스템이 3년이상되면 이미 만료를 바라보고 새로운 시스템에 대한 설계가 준비 되어야 한다. 이럴때 대게는 사용자 불만이나 시스템 결함이 나올때까지 개기고(?) 회사의 여유 정도에 따라 SI를 감행한다. 필자의 생각은 발등에 불이 떨어졌을때 움직이는 것 보다는 미리 SI팀을 모집하고 모집된 인원들의 역할을 분담해주고 역할에 대한 시스템 리뷰를 한후 팀을 새로운 기술교육을 받게 한 후에 SI를 시작하는게 이상적이라 생각한다. 현 시스템의 비지니스 레이어는 유지한채 기술적으로 새로운 접근을 시도 했을때 시스템의 진정한 리뉴얼이 가능하지 않을까?

최근에 리눅스 커널소스를 다시 읽는 경우가 빈번히 생기는 거 같다. 지금은 .NET 계통의 일을 하고 있지만 한때 공부했던 커널소스에 대한 향수병이 일어 주말에 읽던 책을 놓고 코드를 읽고는 감탄사를 토해내고는 한다.