코드 가독성과 실력

 프로그래머에게 코딩은 많은 부분을 차지한다. 개인적으로는 어떻게 구현할 것인가에 How, 알고리즘(해결방법)이 그 무엇보다도 중요하다고 생각한다. 그래도 생각만하고 아무것도 하지 않는다면 무슨 소용인가? 결국 코딩이라는 일종의 손가락 노동을 통해 output 을 내야 하는 것도 프로그래머의 역할이다. 단순하게 손가락 운동이라고 했지만 사실 작가가 소설을 쓸때 작품 구상후 한자한자 써내려가면서 문체에 신경을 쓰듯이 코딩도 아이디어를 어떻께 표현하느냐에 따라 성능, 유지보수등이 판가름 난다. 이중 유지보수 얘기를 하자면 빼놓지 않고 나오는 것이 가독성이다.

 흔히들 가독성 있게 코드를 작성한 사람이 좋은 프로그래머라고 한다.(개인적으로 착한 프로그래머라는 말이 더 어울릴듯). 전임자가 만든 소스를 받아 들고 유지보수를 해야 하는 입장에선 무엇보다 로직을 빨리 파악하고 수정할 수 있어야 되는데 이때 걸림돌 중 많이들 생각하는 것이 얼마나 알아보기 쉽게 작성했느냐다. 하지만 때때로 성능을 위해서 매크로, 복잡한 비트 연산등을 사용할 수 있다. 물론 가독성이라는 누구에겐 쉽게 읽히고 누구에겐 전혀 이해되지 않는 외계어로 느껴질 수 있다. 그래서 코딩 컨벤션(convention)을 두고 있지만 모든 프로그래머가 딱딱한 규칙에 얽매이는 것을 싫어해서인지 잘 지켜지지 않는다. 나조차 평소 몸에 베인 코딩 스타일을 포기하고 컨벤션을 따른다는 것이 꽤 신경 쓰이는 일이다.

 과연 코딩 컨벤션을 지키고 누가봐도 한번에 알아볼 수 있는 코드를 짜는 것이 그 프로그래머의 실력을 말해주는 걸까? 이런 착한 프로그래머를 싫어할 사람은 없을 것이다. 하지만 누가봐도 한번에 알아 볼 수 있는 코드라는 것이 정말 있을까? 100라인 정도에 그리 어렵지 않은 로직을 표현하고 있는 코드만을 생각하면 코딩 컨벤션을 지키는 것이 눈에 쉽게 들어오고 이해도 빨리할 수 있도록 도움을 준다. 하지만 10라인 이하의 짧은 코드에서도 복잡한 수식으로 되어 있다면 나같이 수학에 약한 사람은 코드를 수식으로 만들어 내는 과정이 꽤 힘들다. (수식은 주석으로 적어주면 아주 효과 적일것 같다.) 이제 천라인, 만라인 되는 코드를 보자. 한가지 간과할 수 있는게 우리는 코딩 가독성이라고 하면 눈앞에 보이는 몇십줄짜리 코드만을 생각하는 경향이 있는데 실제 코드를 이해 한다는 것은 프로그램 전체를 이해한다는 커다란 그림을 내포하고 있다. 현재 코드 파일을 스크롤하며, 정의 부분을 따라가고, 또 다른 코드 파일을 열고 함수를 찾아가며... 등과 같은 일련의 코드 읽는 작업들이 수없이 반복된다. 함수들의 호출 루트를 따라가며 어떻게 이런 함수를 쓰게 되었는지 알게 되는 과정에 많은 공을 들인다. 몇백만라인의 윈도우, 리눅스 이걸 코딩 컨벤션을 지키고 최대한 알기 쉽게 표현했다고 해서 나같은 프로그래머가 쉽게 알아 들을 수 있을까? 이렇게 시스템 프로그래밍쪽을 예로 들자면 아마 부가적인 설명이 많이 필요할 것이다. 대학교에서 운영체제 시간에 몇줄 안되는 코드에 주석도 없는(아마 주석없이 코드만 보면 이해할 것이라고 생각하는가 보다)부분들에 대해 책에서는 몇페이지에 걸처 설명을 줄줄이 설명을 늘어놓은 경우가 있다. 이런식으로 코드를 짜는 OS 를 만드는 몇몇 천재들이 만들어놓은 것들을 보면 우리는 코드 이해력이 많이 떨어진다는 것을 체감할 수 있을 것이다. 극단적인 예를 들었지만 많은 프로그래밍 수요가 있는 응용프로그램 개발에 있어서도 별반 다르지 않다. 물론 가독성 있는 코드를 생산하는 취지는 좋지만 가독성의 기준이 객관적일 수 없다는 것을 알아야 한다. 아래 A,B 프로그램의 의견 중 누가 옳은지 판단 할수 없다. 이건 마치 정장을 즐겨 입느냐 청바지에 셔츠를 좋아하느냐의 차이와도 같다.

 A 프로그래머 왈 "변수명은 소문자로 시작하는게 편하고 중괄호는 다음 줄에 시작하는것이 익숙해."
 B 프로그래머 왈 "아니, 나는 변수명은 변수타입을 명시하는 prefix 와 언더바로 시작하고 중괄호는 제어문 바로 옆에서 시작하는것이 좋아."

 최근 Go, Python 같은 프로그래밍의 언어를 보면 들여쓰기, 중괄호의 위치, 변수명(Go에서는 변수명 첫자가 대/소문자냐에 따라 외부에서 액세스 여부가 갈린다.)까지 고정되어 있어 지켜지지 않으면 컴파일 단계에서 에러가 발생하게 된다. 결국 컨벤션을 프로그래머가 신경쓰지 않을 정도로 일반화되고 최대한 구현 방법에 집중할 수 있도록 하는 방향으로 발전한다. 아직까진 좀더 디테일한 부분까지는 언어가 제약하고 있진 않지만 Go, Python 등 최신 트렌드의 언어들은 코딩 스타일의 많은 부분을 고정시켜 놓고있다. 아마 점점 이런한 방식으로 발전한다면 지금보다는 코딩 스타일 변형 폭이 줄어들어 대부분의 프로그래머들이 같은 코딩 스타일로 통합(?)되는 효과가 있을 것이다.

 말하고싶은건 코딩 스타일에 따라 가독성이 좋다 안좋다라고 하는 것으로 프로그래머의 실력을 가늠해선 안된다는 것이다. 나도 가끔 변수명, 들여쓰기 부터 이해가 가지 않는 로직을 볼때면 스트레스가 이만 저만이 아니다. 그렇다고 이 프로그래머의 실력이 개떡같다고 단정지으면 안된다. 암호처럼 되어 있는 코드도 차분한게 이해하는 노력이 필요하다. 실제 나이가 지극하신 아키텍트들의 오래된 코딩 습관을 보면 메모리 절약을 위해 또는 조금의 성능향상을 위해서 매크로나 기타 비트 연산에 많은 공을 들이는 것을 자주 본다. 지금 시대의 컴퓨팅 파워를 봤을때 예전처럼 효과가 있진 않지만 이런 코드를 보며 배울 수 있다는 것에서 의미가 있다. 처음에는 쉽지 않겠지만 이것도 실력있는 프로그래머로써의 자질이라고 생각한다. 이렇게 말한다고 해서 정말 최소한의 탭간격도 지키지 않고, 일관성없는 스타일로 버무려진 스파게티 코드를 작성한 프로그래머라면 단언컨대 나쁜(실력 없는) 프로그래머가 분명할 것이다. 남의 코드를 보고 비평할 수 있으려면 그 코드를 완벽히 이해하고 잘못된 부분을 찾아 낼 수 있는 능력을 키워야 한다.