自由禮讚/예술로서의 컴퓨터프로그래밍으로부터 트랙백.
컴퓨터 프로그래밍을 예술로서 바라보는 것은 좋은 관점입니다. 그러한 관점은 프로그래머로 하여금 스스로 디자인과 코드를 좀더 나은 방향으로 이끌어가기 위한 동기를 부여합니다. 따라서 프로그래머가 자신이 하는 일을 예술이라 생각하는 것은 중요하다고 생각합니다.
그러나 어느 쪽이건 극단을 경계해야 합니다. 예술 모델에는 두 가지 중대한 단점이 자리하고 있습니다.
첫째로, 예술이라는 개념은 주관적인 미의식에 깊게 의존하고 있다는 점입니다. 어떤 것이 더 아름다운 디자인인가, 어떤 것이 더 아름다운 코드인가 하는 것은 좀처럼 합의점에 도달하기 어려운 논쟁을 유발할 가능성이 있습니다. 또한 프로그램에서 미를 추구해야 한다는 점을 타인, 특히 상사에게 납득시키기 어렵습니다. 일정을 일 주일 연기해야 한다는 보고를 올리면서 그 이유로 '프로그램의 아름다움을 높이기 위해' 를 든다면, 프로그래밍에 대해 잘 알지 못하는 관리자는 뭐라고 생각할까요?
둘째로, 예술 모델로는 실제 개발에서 굉장히 중요한 요소인 일정과 비용을 고려하기 힘듭니다. 클베가 몇 달 안 남은 상태에서, 엔진 전담이 아님에도 불구하고 엔진의 완성도를 높이기 위해 자신의 온 시간을 쏟고 있는 게임프로그래머의 경우를 생각해 봅시다. 그는 자신의 엔진이 아름다운 프로그램이 되기를 바랍니다. 그래서 엔진의 미적인 가치를 높이기 위해 일합니다. 그러나 그것이 회사를 위해, 팀을 위해, 그리고 자신의 경력을 위해 좋은 일이라고 단언할 수 있을까요?
그래서 저는 개발을 엔지니어링 모델로 해석하는 것을 더 선호합니다. 인력과 시간을 비롯한 각종 자원 및 제약조건이 주어진 상태에서 다양한 퍼포먼스 메트릭(예를 들어, 기말 프로젝트의 경우라면, 학점)을 최대화하는 다변수함수 최적화 문제가 되는 것이지요. 이때 아름다움은 궁극적으로 추구해야 할 대상이 아닌, 장기적으로 비용을 낮추기 위한 하나의 경험적(heuristic) 전략으로 변합니다. 탭4가 좋은가 탭8이 좋은가의 논쟁은 결론에 이르기 힘들지만, 그러한 논쟁을 하는 것보다 팀 내에 하나의 코딩 표준을 정의하고 그에 모두가 따르는 것이 시간을 절약하는 길이라는 것은 모두 동의할 수 있는 일입니다. 당장 리팩토링을 해야 하는 것이 아름다움이라는 주관적이고 애매모호한 기준을 충족하기 위해서가 아니라, 장기적으로 버그의 가능성을 줄여서 결국 비용을 절감하기 위해서라고 주장하는 것이 상대를 설득하기 더 좋겠지요.
우리가 사는 세상은 우리가 원하는 만큼 아름답지 않습니다. 따라서 세상에 맞춰가야 하는 우리의 프로젝트에서는 때로는 아름다움을 트레이드오프의 대상으로 삼기도 해야 합니다. 크누쓰 선생님은 그분의 글에서 그러한 면을 감추고 계신 것 같지만 말입니다. :)
4월 27일 0시 40분에 추가:
'프로그래밍은 무엇이다'라고 말할 때, 우리는 프로그래밍이라는 행위가 어떤 것인지를 재정의하는 것이 아니라 프로그래밍을 어떤 관점으로 바라보는가를 이야기합니다. 그래서 프로그래밍은 공학이기도 하고 예술이기도 합니다. 두 가지 관점은 상호배타적이지 않습니다. 따라서 어떤 관점이 옳은 관점인지를 논하는 것보다 어떤 경우에 어느 관점을 택하는 것이 더 유리한가, 자신이 왜 이러한 관점을 갖고 있는가를 얘기해보는 것이 서로의 발전에 도움이 됩니다. 그러나 '프로그래밍은 무엇이 아니다'라고 말하는 순간, 다른 관점으로 프로그래밍을 바라볼 수 있는 가능성 한 가지를 닫아 버리게 되는 것입니다.
그리고, '아주 가끔씩'이 아니라 '자주', 예술적인 감각이 전체 비용을 감소시킨다고 저는 믿습니다:) 아름다움을 고려하는 것은 프로그래밍 전반에서 굉장히 유용하게 사용할 수 있는 경험적 전략입니다. 제가 경계하는 것은 극단으로 치우쳐서 다른 것을 보지 못하게 되는 상황이지, 예술 관점 자체가 아닙니다.