Experiments never fail

물리화학시간, 왠만한 공식에서 우리는 델타표시를 볼 수 있다. 변화량이란 뜻. 그 절대량은 알기 힘드니, 특정 시간동안의 변화량을 가지고, 수식으로 표현되었던 많은 물리량들.

예를 들면, 엔트로피 같은 것이다.


그 절대적인, 엔트로피는 계산이 힘드니까, 변화량을 주로 따진다. 열역학 제 2법칙도 마찬가지.

소프트웨어개발도 유사하다. 어떤 프로젝트가 있고, 그 프로젝트를 묘사하는 코드가 있다면, 그리고, 우리가 그 코드에 대해 어떤 작업을 수행해야한다면, 그것은 변화량으로 표기되어야 한다.

이 개념이 잘 서지 않은 채 하는 개발과정은 관리를 어렵게 한다. 적절한 SCM안에서 나의 변화작업은 몇번 리비전을 기초로 만들었는가를 묘사해야한다. 즉, 시간축에 대한 고려가 늘 되어 있어야 한다.

예를 들어, Django의 원래 소스를 내 임의대로 고쳐서 쓰고 있다고 하자. 다른 시스템에 적용하거나, 다른사람에게 나의 변경을 알려주려면, 계속적으로 변화하는 Django의 변화흐름내에서, 구체적으로 몇번 리비전을 갖고 수정한 것인가가 묘사되어 있어야 한다. 저 패치가 r7568 을 기준으로 작성된 것이고, 현재 Django 리비전이 7724라면, 저 패치를 쓰고싶은 사람은 svn up -r7568 명령으로 과거로 잠시 돌아간 뒤, patch 명령으로 패치하고, 그리고 다시 svn up 명령으로 현재로 돌아와야 한다.

이렇게 놓고 보면, 저 패치파일은 정말로 변화량을 담고 있음을 알 수 있다. 특정 시점에서 부터의 변화량. 그리고, 그것은 SCM 등으로 쉽게 타임머신을 타고 왔다갔다 할 수 있다. Subversion, Trac등으로 프로젝트진행을 해보면, 실제로 전체 프로젝트의 결과물은 이런 하나하나 변화량의 총합이다. 사용자의 새로운 요구사항, 성능의 개선 및 리팩토링등이 모두 새로운 변화량을 만들고, 전체 프로젝트를 구성한다.

(사실, 개발관련에 계신 분들이라면 이미 다들 알고있으며, 쓰고 있던 얘기. 오픈소스 프로그램에 패치를 주고 받는 많은 일들이 사실 다 이런 방식으로 동작하고 있다.)