코드를 잘 뽑아내고 싶은가? 그럼 컴퓨터를 버려라.

나의 컴퓨터와 관련된 인생 중에서 아직도 가장 중요한 경험이라고 하면 바로 컴퓨터를 시작했던 국민학교 2학년때의 경험이 아닐까 한다. 학교에서 특활로 컴퓨터부에 들었는데 처음에 책 한권을 사라고 하고는 1년 내내 특활을 하지 않았다. BASIC라고 적혀 있는 노란책만 나에게 주어졌다. 컴퓨터실은 1년 내내 잠겨 있었다. (오히려 그전에 누님들이 그 학교에 있을때 어머님이 잠시 배우셨다고;; 대체 몇년도야 @.@;) 초보자용 입문서와 가로줄이 그어져 있는 공책, 그리고 연필이 나에게 주어진 모든 연장이었다. 그리고 나는 그 상황에서 입문서의 한장 한장을 넘겨가며 코딩을 시작했다. 나의 공책 위에서 프로그램은 돌아갔고 거기서 난 디버깅을 했으며 결과물도 볼 수 있었다.

어제 일본에 계신 다른 개발자분과 이야기를 하면서, 불과 1~2년 전만 해도 일본에서 '코딩'의 '코'자만 할 줄 알아도 70만엔(곱하기 7~8 하면 우리나라 돈으로 환산 가능)에 뭔가 그림나부랭이(개발자가 하는) 하나라도 그리면 100만엔이라고 한다. 사실 이런 사실은 그당시에 듣고는 있었다. 한국의 많은 개발자들이 일본으로 뛰쳐 나갔다. 그리고 나서는 코더 인플레이션이 일어났다. 한국에서 온 코더들만 5천명 이상이 될것이고, 중국이나 기타 나라에서도 일본에 모이다 보니 코딩장이의 월급은 이제 큰 메리트는 사라졌다. 허나 이것만이 전부는 아니다. 말 그대로 '개'나 '소'나 다 달려들다 보니 산출물의 수준도 낮아지고 있다는 것이다.

계속적으로 등장하고 있는 언어나 기술, 라이브러리, 플랫폼은 계속 쉽고 빠르게 무엇인가를 생산해 내는 것이다. 언어 하나를 14일만에 습득해서 바로 실전에 투입할 수 있도록 해주겠다는 책도 나오고 있지 않은가. 뭐 대학시절에도 교수님들이 언어 나부랭이야 금방 배울 수 있는거 아니겠어? 라시고는 바로 프로젝트를 쏟아 내기는 하셨지만 코딩을 막 시작하는 사람들에게까지 이것이 전파되고 있다는 것이 문제겠다. C를 시작한지 이제는 15년이 되어 가는 나는 아직도 가끔 몇몇 문장에서 말문(뭐 코딩이랄까)이 탁탁 막히는데 3개월 학원 과정 나오신 분이 나보다 코드를 더 잘 뽑아 내고 있는것 같다란 느낌도 받았다. 그러나 물론 그 코드가 형상관리 레포지토리에 커밋(메인 소스에 적용되는 과정)되는 순간 그대로 취소되는 경우도 많다.

언젠가 나도 생긴 버릇이지만 조금 짜고 컴파일 하고 돌려본다. 뭐 TDD(Test-Driven Development)에서는 좋은 것일지 모르겠지만 로직이 흐르고 정상적으로 동작함을 기계에게 의존하게 된다. 이것이 지속되다 보면 코드의 흐름을 머리속에서 놓쳐 버린다. 부분부분 분명 뭔가를 받고 뭔가를 토해내고는 있지만 이 시스템이 뭘 하고 있는지에 대한 감은 점점 놓친다.

속성 코스로 탄생한 코더들이 흔히 겪는 한계로 보이는 것은, 단위 모듈의 동작성은 그런대로 되는데 옆모듈 고려하세요라고 하는 순간 패닉에 빠진다. 쓰레드간 동기화라든가, 객체에 접근할 때 락 쓰는 것들이 모든 경우에 정석이 있는 것도 아니고 직접 풀어보자니 이해도 안된다. 그래서 어려워 하는 요소중 하나일 것이다. 포인터도 모듈 안에서만 핸들링 되는거면 버티는데 누군가 던져주거나 누군가에게 주어야 할 물건이 되면 비명 몇마디 지른다. 2중이네 10중포인터니 100중 포인터니가 어려움을 증가시키는 것이 아니고 얼마나 넓은 스코프에서 포인터가 여행을 즐기는 가가 어려움과 연관이 있을 것이다. Pascal에도 있던 Call by Reference 개념도 const가 좀 붙어 주고 객체가 넘어가는거 까지는 되는데 한 30단계쯤 계속 불리고 있으면 힘들어 한다. 결국은 전역 변수로 밀어 넣기. 최근 일부 언어들은 (PHP를 예로 들자면) 포인터나 레퍼런스를 코더에게 숨겨버리는 짓도 하는데(이제는 코드들도 사용자 취급을 -ㅅ-) 덕분에 거대한 객체가 php.ini 설정이나 PHP 버전, 함수 특성등에 따라 지맘대로 복사되었다가 참조되었다가 해서 중간에 변경하여도 동작하는듯 하면서도 안된다. 로컬스코프만 봐서는 절대 풀 수 없는 문제이고 동작하기 어려운 코드를 생산한다. 글로벌 스코프를 볼 수 있는 안목이 필요하다.

슈도 코드(pseudocode)라던가, 플로우 차트로 프로그램을 작성해 본적이 있는가? 단순히 디자인을 위해 형식적으로 그리는 그림이 아니다. 플로우차트는 그 차제만으로 프로그램이고 정상적으로 돌아야 하고 버그가 없어야 한다. 당연히 컴퓨터는 이해 못한다(CASE Tool이라던가, State Transition Diagram으로 시뮬레이션 하는 경우가 있기는 하지만;;). 그것을 돌릴 수 있는 것은 현재로서는 인간만이 가능하다. 인간이 씨피유가 되고 메모리가 되고 IO 장치가 되어 수행한다. UML Diagram 많이 그리는데 단순히 다큐멘테이션용 뿐만이 아니고 아직은 인간의 언어지만 프로그램이라 볼 수 있다. Use Case diagram도 그 차제만으로 펑션을 수행할 수 있다.

말단 함수 하나를 작성하는 코더에서 점점 큰 코드를 작성하고 싶다면 글로벌을 봐야 한다. 더불어 어느정도 규모가 되고 나면 더이상 한사람이 커버할 수 있는 코드로는 존재하기 힘든 단위가 된다. 추상화된 언어, 즉 아직은 코더의 실제 구현이 있어야 컴퓨터가 이해할 수 있는 것으로 작성되어 있는 것들을 만들 수 있는 능력과 그것을 수행시켜보고 디버깅 할 수 있는 능력을 연습해 보길 바란다. 최상위 아키텍쳐러가 걍 그림 그리는 것 아니다. 오히려 그런 사람들에게는 말단의 코딩실력까지 상당한 수준이 되어야만 한다. 자신의 선 하나가 실제로 구현될 것 까지 예상을 하며 큰 그림을 머리속에 수행시키고 디버깅하고 검증할 수 있는 사람만이 전체 그림을 그릴 수 있다. 뭐 아무나 그림 그리라면 그리기야 하겠지만(사실 그릴 수 있는 사람이 그리 많지도 않겠지만) 예쁘고 멋있고 쌈빡하고 섹시한 그림은 쉽게 나오는 것은 아니다.

혹 옆에 개발을 위한 디자인 문서 나부랭이(?)가 있다면 그 문서만으로 프로그램을 수행 시켜 보시라. 뭔가 부족한 부분이 있다면 다른 문서를 참고할 수 있다. 대신 참고 문서는 그 문서에서 Include(!) 하는 것만 가능하다. 잘 도는가? 잘 돈다면 디버깅을 해 보고, 잘 안되면 어디가 빠졌는지 찾아 보라. 무엇이 그 문서의 레벨(상세화 레벨)에서 빠졌는지 찾고, 대충 만들어 보는 작업들을 해 본다. 그림(Diagram)이나 말(Document)로 프로그램을 작성해 보는 방법. 남의 그런 프로그램을 돌려 볼 수 있는 것. 이단계 까지는 컴퓨터는 단숨히 문서 전달기구 혹은 문서 표시기에 지나지 않는다.

실제 코드를 작성하고는 컴퓨터에게 돌려보는 무책임한 코딩은 가능한 지양하기 바란다. 자신이 코드를 이해할때 만이 그 코드는 제대로 작성할 수 있다. 그리고 그 커버리지가 커질수록, 자신이 할 수 있는 규모가 커지고 봉급도 올라갈 것이라 본다.

최소한 막코드 타이퍼 2000명이 프로젝트 꼴통으로 몰아가고 박살나서 다시 코더 연봉 깍이는 악순환은 이제 그만. 한국에 개발자 대우가 낮다라고는 하지만 그게 역으로 봐서는 개발자의 평균적인 생상성이 그것밖에 안된다는 소리기도 하니 뭐...

~~~~

PS.
기획자든 아키텍쳐러든지 서브모듈 디자이너든지, 컴퓨터에게 뭘 시키고 싶으면 일단 그와의 대화 소통법 부터 배우길 권장한다. 물론 기계어까지는 내려올 필요는 없다.