Talk about Software with hani

함수 길이 = 프로그래머 내공?

객체 지향 언어나, 구조적 언어나 모두 설계가 중요하다. 물론 100% 완성도를 가지고 있는 설계 문서를 가지고 개발을 한다는 것은 불가능하다. 따라서 80% 완성도를 가지고 있는 설계로부터 개발을 하게 되거나, 아니면 xp방법을 사용해서 간단한 story card로부터 개발을 시작해도 기능 중심의 함수를 만들다면 보면 함수가 100줄 혹은 아무런 생각없이 프로그램을 한다면 간혹 1000줄이 넘는 함수를 만들기도 한다.

물론 만들어 놓은 소스 코드의 길이를 보고, 프로그래머의 능력을 완벽히 판단할 수는 없지만, 프로그래머가 어느정도 연륜을 가지고 있는지 만들어 놓은 함수의 길이를 보는 것만으로도 충분할 때가 있다.

처음 프로그램을 짜게 되면, 솔직히 함수를 왜 나누어야 하는지, 언제 나누어야 하는지 감이 잡히지 않는다. 그렇기 때문에 머리에 생각나는대로 기능을 풀어 놓다 보면 if에 if가 꼬리에 꼬리를 물고 간혹 if로 해결이 안될 때는 goto문을 쓰기도 한다. 한동안 잊고 지냈던 goto 문을 프로젝트를 하면서 다른 프로젝트 팀원이 짜 놓은 기존 소스에서 발견했다. 그 때의 발견이 이 글을 쓰게 만드는 계기를 제공해 주었다. 그러니 생활의 발견인 셈이다.

잘 짜 놓은 프로그램을 살펴 보는 것은, 프로그래머로써 기쁨이자 한 수 배우는 순간이다. 그런데 잘 짜 놓은 프로그램의 공통점은 하나의 함수 길이가 20~30줄을 넘지 않는다. 이 수치는 개인적인 느낌이 강하다. 그렇기 때문에 실증적으로 제시할 근거는 없다. 다만 말하고 싶은 점은 함수의 길이가 매우 짧지도 길지도 않다는 것이다.

새로운 기능이 추가될 때 보통 새로운 함수를 만든다. 따라서 일단 함수를 나누는 가장 큰 근거는 기능이다. 그렇기 때문에 클래스의 멤버 변수값을 돌려 주거나 설정할 때와 같이 매우 짧은 소스 길이를 요구할 때도 별도의 함수로 나눈다. 이런 기능적인 측면 이외에 함수의 길이가 길어진다 싶으면 별도의 함수를 만들 수도 있다. 그런데 곰곰히 생각해 보면 함수가 길어진다고 함수를 나누는 것은 1000줄 짜리 함수를 100줄짜리 10개의 함수로 나누는 것과 똑같기 때문에 아무런 의미가 없을 수 있다

즉, 단순히 함수의 길이만 가지고 적당한 함수의 길이를 판가름할 수 없다는 이야기다. 그렇다면 언제 함수를 나누어야할까?

프로그램 언어도 언어다

프로그램 언어도 결국에 가서 언어인 셈이다. 일반적인 언어가 사람과 사람이 대화를 하기 위해서 하는 언어라면, 프로그램 언어는 컴퓨터와 인간이 대화를 하기 위해서 만들어 놓은 것이다. 그러나 단순히 프로그램 언어가 컴퓨터와 인간이 대화를 나누기 위한 것이라고 말해 버리면 스파케티 소스를 만들어도, 이만줄 짜리 함수를 만들어도 상관이 없다. 왜냐면 사람이 어떻게 프로그램을 만들어도 컴퓨터는 이해할 수 있기 때문이다. 하지만 프로그램 언어는 프로그래머와 프로그래머가 대화를 하기 위한 것이라고 정의하면, 프로그램을 잘 짜야 하는 것이 당연하다.

자동차 공장에서 자동차를 만드는 것을 S/W 회사에서 프로그램 짜는 것과 비교하기도 한다. 그러나, 어떤 이들은 S/W 회사에서 프로그램 짜는 것은 생산의 개념이 아니라, 순수한 설계의 기간이라고 한다. 즉, 컴파일하고 링크하는 것을 자동차 회사의 생산으로 간주하는 것이다. 따라서 S/W에서 보통 설계라고 부르는 단계는 진짜 설계 단계가 아니다. 프로그램을 짜기 위한 즉, 설계를 위한 사전 설계 작업인 셈이다.

이런 생각의 연장선에서 프로그래밍을 바라보자. 제조 회사에서 설계도를 만드는 가장 큰 목적은 제품 생산과 관련된 여러 부서에 제품에 대한 정보를 공유하기 위함이다. 마찬가지로 S/W에서 프로그램을 짠다는 것은 다른 프로그래머와 제품에 대한 생각을 공유하기 위함이다. 그렇기 때문에 훌륭한 S/W를 만들기 위해서는 프로그램을 잘 만들어야 한다.

돌아서 이야기를 했지만, 앞서 얘기한 프로그램 단계를 순수 설계 단계로 바라 볼 것이냐 아니냐를 떠나서라도 프로그램은 프로그래머와 프로그래머가 S/W 시스템의 모습을 두고 나누는 대화 내지는 독백이다. 특히 블로그를 하면서 느끼는 점이지만 프로그램 언어는 일반적인 글 쓰기와 비슷한 점이 많다는 것이다.

생각의 호흡, 문단 그리고 함수

글을 쓸 때 문단을 나누는 것은 프로그램을 짤 때 함수를 나누는 것과 비슷하다. 문단을 나눌 때의 근거는 생각의 호흡이다. 글을 읽는 독자의 생각이나, 글을 정리하는 나의 생각이 머릿 속에 받아들일 수 있는 분량이 되었을 때 문단을 나눈다. 즉, 글을 읽고 한 템포 쉬고 나서 지금까지 읽은 내용을 머릿속에 받아들이고 자기 것을 만들 수 있는 분량이 한 문단이 된다. 이런 생각의 호흡 길이는 개인별로 많은 차이가 있다. 그렇기 때문에 글을 쓰는 사람의 입장에 따라서 문단의 길이가 차이가 나나, 평균적인 독자를 계산해 넣는 작가라면 문단의 길이가 정형화 된다.

글 쓰는 이의 생각을 잘 전달하기 위해서는 문단의 길이가 중요하다. 문단의 길이가 짧은 경우 생각의 호흡이 짧다. 따라서 짧은 문단은 이야기를 전달하기도 전에 독자에게 산만함을 준다. 반대로 너무 긴 문단은 새로운 내용을 받아들이는 것에만 열중하기 때문에 자기의 것으로 만들 시간이 부족하다. 생각의 호흡이 길기 때문에 독자에게 졸음을 선사할 수 있다. 이런 이유로 글 쓰는 이의 생각을 적절히 전달할 수 있는 문단으로 나누는 것이 중요하다.

이런 원리를 프로그래밍에도 적용할 수 있다. 하나의 함수는 문단에 비유할 수 있다. 따라서 적당한 함수의 길이는 프로그래머의 생각을 다른 프로그래머에게 전달하기 위한 수준에서 결정하는 것이 좋다. 즉, 하나의 작은 완결된 로직이나, 알고리즘을 다른 프로그램에게 전달할 수 있는 정도가 좋다. 프로그래밍할 때 함수가 길어진다고 생각될 때 생각의 호흡에 맞는 크기로 함수를 refactoring해야 한다. 이 기준을 염두해 두고 만든 클래스는 잘 쓴 산문과 비슷한 느낌을 준다. 함수 하나를 읽어 보면 이 함수에서 프로그래머가 무엇을 하고 싶은지를 한번에 알 수 있다. 그렇기 때문에 이 함수에서 다른 함수를 호출할 때 호출된 함수의 기능은 무엇일지도 짐작할 수 있다.

다시 처음에 화두로 돌아가 보자. 함수 길이 = 프로그래머 내공이라고 단정 지을 수 없다. 좋은 프로그램을 결정 짓는 요소는 너무나 많기 때문이다. 그러나 적절한 함수 길이가 훌륭한 프로그램의 필요조건은 아니지만 충분 조건이라는 사실에는 동의하지 않는가?

This entry was posted on Sunday, March 5th, 2006 at 2:50 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.