개발자 철학
철학은 아무것도 아닌 것에서 출발하여 아무것도 아닌 것에 이르는 수많은 길이다
- 앰브로스 비어스
철학(Philosophy)은 생각하는 방법(The way of thinking)이다. 고로 개발자에게도 철학이 필요하다. 생각하는 방법이 고차원화되고, 하나의 체계를 형성하면 우리는 그것을 하나의 철학이라고 부를 수 있게 된다. 인지하고 있든, 그렇지 않든, 어떤 형태든, 모든 개발자들은 철학을 가지고 있다. 없다고 생각하는 것은 자신의 철학을 정의하고 있지 않기 때문이다.
언어(language)는 철학을 표현하는 수단의 하나다. 그 한계에도 불구하고 가장 직접적이고 효율적인 표현수단이다. 지시적 기능과 정보전달의 기능 측면에서 보자면 인류역사상 언어만큼 효율적인 수단은 없다. 언어는 기본적으로 자연발생적이다. 사상과 문화, 역사가 언어를 자연형성해왔다. 그래서 다른 나라의 언어를 배우고자 하는 사람은 먼저 그 나라의 문화와 역사를 먼저 배우는 것이 효율적이다.
개발자가 사용하는 프로그래밍 언어 또한 고유의 철학을 가지고 있다. 정확히 얘기하자면, 프로그래밍 언어를 만든 창조자의 철학이 녹아 있다. 일반 언어와 달리 프로그래밍 언어는 사상적 기반위에서 창조된 작위적 언어다. 목적을 가지고 태어난 언어는 그 자체가 사상성을 내포하고 있다. 실질적으로 그 만들어진 용도가 사상을 결정한다. C와 같은 순차적 프로그래밍 언어나 JAVA와 같은 객체지향 프로그래밍 언어 모두 기본적인 설계는 단단한 사상적 기반, 즉 프로그래밍 언어의 철학에 기반하고 있다.
근래 많이 사용되고 있는 프로그래밍 언어인 파이썬(Python)의 경우 파이썬 사상(The Zen of Python)으로 그 철학이 명시되어 있다. 내용을 소개하면 다음과 같다.
The Zen of Python
Beautiful is better than ugly.
(아름다운 것이 추한 것보다 낫다)
Explicit is better than implicit.
(명확한 것이 함축적인 것보다 낫다)
Simple is better than complex.
(단순한 것이 복잡한 것보다 낫다)
Complex is better than complicated.
(복잡한 것이 꼬여있는 것보다 낫다 - Complex는 개수가 많아서 복잡하다는 의미이고 complicated는 추상적인 의미로 이해하기 어렵게 꼬여 있다는 정도로 생각하면 된다)
Flat is better than nested.
(단조로운 것이 엉켜있는 것보다 낫다)
Sparse is better than dense.
(분포되어 있는 것이 빽빽한 것보다 낫다)
Readability counts.
(가독성은 중요하다)
Special cases aren't special enough to break the rules.
(특별한 경우라도 규칙을 어길 만큼 특별하지는 않다)
Although practicality beats purity.
(비록 실용성이 순수성을 앞선다 할지라도)
Errors should never pass silently.
(오류를 절대 조용히 넘기면 안된다)
Unless explicitly silenced.
(명확하게 조용하지 않는 한)
In the face of ambiguity, refuse the temptation to guess.
(모호한 상황에서는 추측하려는 유혹을 거부하라)
There should be one-- and preferably only one --obvious way to do it.
(그것을 할 수 있는 분명한 그리고 가능하다면 유일한 한가지가 있어야 한다. )
Although that way may not be obvious at first unless you're Dutch.
(네덜란드사람(파이썬의 창시자)이 아니라면 처음에는 그 방법이 분명하지 않을 수도 있다)
Now is better than never.
(지금 하는 것이 하지 않는 것보다 낫다)
Although never is often better than *right* now.
(비록 하지 않는 것이 종종 지금 당장 하는 것보다 나을지라도)
If the implementation is hard to explain, it's a bad idea.
(만약 구현해놓은 것이 설명하기 어렵다면, 그것은 나쁜 아이디어다)
If the implementation is easy to explain, it may be a good idea.
(구현한 것이 설명하기 쉽다면, 그것은 좋은 아이디어일 수 있다)
Namespaces are one honking great idea -- let's do more of those!
(네임스페이스는 정말 좋은 아이디어다. 더 많이 사용하자!)
이 한 편의 경구들은 팀 피어스라는 사람이 지은 것으로 파이썬의 철학을 직접적으로 나타낸다. 파이썬 인터프리터 코맨드창에 "import this"를 입력하면 이 내용이 출력된다. 굳이 파이썬이 아니더라도, 위 문장들은 거의 모든 프로그래밍 언어 및 그 코딩에 있어 권장되는 사항들이다. 그리고 굳이 코딩이 아니더라도, 위 문장들은 거의 모든 업무적인 일들을 처리하는 데 있어 교훈으로 삼을만 하다. 마지막으로 굳이 업무적인 일처리가 아니더라도 위 문장들은 우리의 인생을 사는 데 있어 훌륭한 교훈들이다. 이 규칙들을 지키지 않고 있다면, 지금부터라도 지키는 것이 지키지 않는 것보다 낫다(Now is better than never). 비록 가끔은 지키지 않는 것이 지금 당장 하는 것보다 나을지라도 말이다(Although never is often better than right now).
프로그래밍언어안에 철학이 있듯이 개발자에게도 철학이 필요하다. 철학은 원칙과 확고한 기준을 의미한다. 타협하지 않고 지켜야 하는 자신만의 원칙은 팀과 개발조직의 원칙들과 조화를 이루어야 한다. 아무리 개인의 원칙이 뛰어난들, 팀의 원칙과 조화되지 않으면 프로젝트는 제대로 굴러가지 않는다. 파이썬 철학에서 살펴보았지만, 제대로 된 개발자의 철학이라면 제대로 된 팀의 규칙과 맞물리지 않을 이유가 없다. 파이썬 철학에도 나오지만 더럽게 코딩하지 않고, 가독성 좋은 코드를 만들어야 한다. 이것은 기본적인 배려다. 관계지향 프로그래밍(Relation-Oriented Programming)을 생활화해야 한다. 인간지향 프로그래밍(Human-Oriented Programming)이라고도 말할 수 있겠다. 모든 개발과 코딩은 사람을 향해 있어야 한다. 가독성 있는 코딩, 의미 있는 네이밍(Naming), 시의적절한 문서화 모두 확고한 철학을 가진 개발자로부터 나온다.
한가지 놓쳐서 안될 사실은 철학은 전문성 없이는 성립될 수 없다는 것이다. 구본형 작가의 <사자같이 젊은 놈들>에 나온 전문가와 철학의 관계에 대한 내용을 인용하면 다음과 같다. 사진을 찍을 때, 피사체의 조도와 각도, 혹은 기계와 장비의 사용법 등을 익히는 것은 기술자로서 테크닉의 영역이다. 이 일을 아주 잘 하면 훌륭한 사진기사라 불릴 수 있다. 그러나 무엇을 담을 것인가? 이것을 알고 있는 사람은 예술가다. 사진을 통해 자신을 세상에 표현하는 사람을 우리는 훌륭한 사진작가라고 부른다. 세상에 자신을 표현하기 위해서는 철학이 필요하다. 그리고 그 철학은 전문성 위에 서있어야 한다. 개발자로서 전문가로 인정받기 위한 척도의 하나는 비전문가들에게 전문적인 내용을 쉽게 설명할 수 있는 것이다. 비전문가인 배우자나 초등학생인 자녀도 이해할 수 있는 평범한 일상의 언어로 전문분야를 설명할 수 있어야 한다. 철학이 있는 개발자로 인정받기 위한 척도는 문제에 대한 구체적이고 실용적인 대안 뿐만이 아닌, 장기적이고 근본적인 방향 또한 제시할 수 있어야 하는 것이다. 지나친 일반론과 지엽에만 치우친 실무적 태도 모두 좋지 않다. 철학을 가진 개발자라면 지엽에 얽매여서 전체의 균형을 잃어서는 안된다. 또한 너무 일반론으로 흘러서 뜬 구름 잡는 이야기를 해서도 안된다. 멀리 보고 일관적이어야 한다. 그런 매의 눈은 철학 없이는 만들어지지 않는다.
일반적으로 개발자들의 철학은 대부분 경험으로부터 형성된다. 실천할 수 없는 철학은 아무 쓸모가 없다. 관념으로만 그친 사유는 힘이 없다. 그런 측면에서 경험은 분명 좋은 습득 방법이다. 하지만 경험만으로부터 철학을 얻으면 평범에 그치고 만다. 경험으로부터도 철학을 얻지 못하는 개발자들도 적지 않지만, 경험만으로는 결코 비범해질수 없다. 많은 경험이라도 그것이 지혜로 전환되지 않으면, 고집과 아집에 그칠 뿐이다. 경험이 많지만, 개발철학이 없는 완고한 개발자가 될 뿐이다. 이론만으로도 철학은 만들어지지 않는다. 남에게서 빌려온 철학은 지혜로 승화되지 않는다. 아무리 좋은 개발 프로세스라도 남이 만들어놓은 것을 내재화하는 것은 이론만으로는 불충분하다. 모방에 그치고 만다. 여기저기 좋다고 하는 것들은 다 긁어 모아보지만, 그것들은 정작 긴박한 상황에서 한줌 도움도 되지 못한다. 내것이 아니기 때문이다.
공자가 말하기를 지혜를 얻는데는 모방, 경험, 사색의 세가지 방법이 있다고 했다. 모방은 가장 쉽지만 만족스럽지 못 하다. 경험을 통해 얻는 방법은 확실하지만 가장 어렵다. 사색에 의한 방법이 제일 고상하고 효율적이다. 습득한 경험과 이론을 지혜와 철학으로 증폭시키는 방법은 사색이다. 개발을 하면서 마주치는 모든 이슈에 대해 그냥 지나치지 않는 자세가 필요한 이유다.
