얼마 전에 내가 담당하는 (다양한 서비스 로그를 분석해서 순위 데이터 제공) 서비스에 문제가 있는 것을 파악하고 급하게 수정 작업을 진행했다. 적당히 테스트해보니 문제가 해결된 것같아서 그대로 커밋을 해버렸다. 다음날 실 서비스를 확인하는 별다른 문제가 눈에 띄지도 않고 데이터도 정상적으로 나오고 있어서 전날 버그수정이 제대로 이뤄졌다고 생각했다. 그런데 2주 정도가 지난 후에 조금 다른 문제가 계속 발생하고 있음을 깨달았다. 처음에는 다른 곳 (데이터 가공에서 변수에 따른 가중치 산정)에 문제가 있는 것같아서 또 급하게 수정했다. 그 다음날 서비스는 정상적이지만 조금 이상하다는 것을 느꼈다. 그래서 다시 테스트런을 하고 소스코드를 면밀히 검토하니 2주 전에 수정할 때 프로그램에 또 다른 간단한 버그가 심어졌음을 발견했다.
그 순간 깨달았다. 버그 수정이 또 다른 버그를 양산한다는 것을… 열역학에 따르면 자연상태에서 엔트로피는 증가할 수 밖에 없다. 프로그램 버그, 즉 프로그램 복잡도도 그런 것같다. 프로그램에 문제가 있어서 코드를 수정하거나 기능 추가를 위해서 새로운 코드를 삽입할수록 코드는 복잡해지고 미처 깨닫지 못한 새로운 버그가 심겨지는 것같다. 그래서 많은 개발자들이 새로운 이터레이션에서 기존 코드를 수정보완하기 보다는 처음부터 새롭게 프로그램을 짜는 것같다. 특히 다른 사람이 만들어놓은 코드라면 대략적인 로직만 이해하고 처음부터 다시 시작하는 경우가 많다. 그래도 생길 버그가 안 생기는 것도 아니다.
열역학에서 엔트로피를 증가시키지 않기 위해서는 외부에서 에너지가 꾸준히 공급되어야 한다. 프로그램 버그도 그런 것같다. 그 프로그램이 더 이상 복잡해지지 않고 버그 프리가 되기 위해서는 프로그래머 혼자서 밤을 새가면서 그 코드를 면밀히 검토한다고 해결되지 않는다. 심플한 경우라면 가능하겠지만, 몇천 몇만 라인이 넘어가는 프로그램인 경우 자신이 짠 코드에서 버그를 찾아내는 것이 여간 어려운 것이 아니다. 그렇기 때문에 두명이서 한조를 이뤄서 코딩을 하는 것을 권장하는 경우도 있다. 두 사람이 서로 의논해서 로직을 정한 후에 (때론 합의된 로직이 없어도 된다) 한명은 컴퓨터 앞에서 해당 로직을 구현하고, 또 다른 한명은 그저 등 뒤에서 프로그래맹되는 것을 지켜보면서 잘못된 것이 있는지 확인하는 그런 페어링을 추천하기도 한다.
이 방법론이 효과가 있다는 얘기는 자주 듣지만, 막상 내가 그렇게 프로그래밍을 해야 한다면 절대 못할 것같다. 익숙해지면 생산성이 향상되겠지만 익숙해지는 과정이 너무 길 것같다. 내가 짠 소스코드가 나 아닌 다른 사람에게 공개된다는 것은 마치 내 속살을 그대로 보여주는 것과 같을 거다. 많은 대중 앞에서 강연을 할 때도 그렇고 이렇게 불특정 다수를 향해서 생각을 글로 표현할 때도 대중 앞에서 발가벗겨지는 기분을 느낀다. 대중강연이나 블로깅의 경우 그래도 적당히 수위조절이 가능하기 때문에 완전히 발가벗겨지는 것같지는 않지만, 업무에서 발생하는 프로그램의 경우는 자의적으로 감출 수가 없기 때문에 더 어렵다. 완벽하고 심플한 프로그래밍이 가능했다면 커플을 이뤄서 코딩을 할 필요조차 없을지도 모른다. 커플코딩뿐만 아니라, 이제껏 담당하던 서비스를 타인에게 이관할 때도 비슷한 경험을 한다.
그래도 혼자서 코딩을 하다보면 버그가 버그를 부르게 되고 프로그램은 복잡해지기 때문에 엔트로피를 감소시키듯이 코딩에서도 외부의 에너지가 필요한 것같다. 처음에 조금은 불편하겠지만, 타인의 눈을 통해서 내 코드가 면밀히 까발려지고 테스팅이 된다면 결과적으로 더 만족할만한 결과물이 나올 것이다. 이를 잘 알지만 막상 실천은 어렵다.
(2013.05.24 작성 / 2013.05.28 공개)
페이스북 페이지: https://www.facebook.com/unexperienced
