찰떡같이 제대로 구현했다고 믿었던 부분에서 버그가 발견되었을 때, 인식의 오류는 영원히 해결할 수 없는 문제임을 깨닫는다. 끊임없는 셀프 코드 리뷰와 몇 번의 타자 코드 리뷰에 의해서 모든 버그가 해결될 거라고 인식하지만 그런 일은 Hello, World 프로그램에서만 일어난다. 그렇다면 인식의 오류를 최대한 줄일 수 있는 방법은? 역시 실험과 증명이다.
소프트웨어 개발은 공학의 한 부분이다. 대학교에서 과학과 공학을 배울 때를 떠올려 보면 항상 실험과 증명이 빠지지 않는다. 실험은 도구를 이용한 물리, 화학 실험만 의미하는 것이 아니다. 수학의 경우 문제를 정의하고 그 문제를 풀기 위한 수식을 만들어 내는 과정이 여러 번의 시도를 거쳐 반복되기 때문에 실험이라고 볼 수 있다. 컴퓨터 공학의 경우 코딩을 하는 과정, 그 코드가 의도한 대로 작동하는지 확인하면서 계속 코드를 고치는 과정이 곧 실험이다. 머릿 속 생각을 코드로 작성하는 과정은 심적으로 고통스럽다. 그러나 그 고통이 문제를 해결했다는 걸 절대로 증명하지 않는다.
20대 후반까지는 이를 깨닫지 못했다. 코딩만 열심히 하고 적당히 돌아가면 소스 서버에 소스를 커밋하기 일쑤였다. 제대로 증명하지 않아서 생기는 문제에 대해서는 늘 합리화를 했었다.
'테스터가 따로 있어야 하는 거 아닌가?'
이는 과학자 또는 공학자로서 명백히 잘못된 생각이다. 논리적 비약이 될 수도 있겠지만 그 합리화에 빠진 당신은, 이론과 초기 아이디어만 내놓고 실제 구현 및 증명은 대학원생들에게 맡긴 뒤 논문의 First Author로 이름을 올리는 교수들과 별 다를 바 없다.
사용자가 많은 상용 제품(저의 경우는 TmaxSoft JEUS였습니다)을 다루면서 여러 가지 경험을 통해 이 부분에서 태도가 많이 달라졌다. 기능 추가, 버그 수정 후에는 늘 자동화 테스트를 작성한다. 테스트 자체를 잘못 만들어서 실수를 하는 경우도 있지만 이 정도는 '인간이니까.' 라고 합리화해도 될 것 같다. 테스트 코드 자체를 실험하고 증명하는 과정을 거쳐야 하고 다시 그 과정을 또 실험 증명해야 하고, 계속 recursive하게 해야 하는데 한 사람이 이걸 다 하는 건 거의 불가능하다.
2014년 경에 coursera 에서 sedgewick 교수의 알고리즘 강의를 들으면서 더욱 많이 달라졌었다. 강의 중간에 컴퓨터 알고리즘을 구현한 코드에 대한 실험과 증명에 관한 얘기가 등장한다. 쥐나 토끼 등을 이용한 생물 실험은 실험 결과를 제 타이밍에 맞추느라 밤샘을 해야 할 수 있고 실험 결과가 좋지 않으면 밤샘을 반복해야 한다. 즉, 몸이 힘들다. 소프트웨어는 1시간 안에 수도 없이 빠르게 테스트 해볼 수 있다. 하드웨어나 운영 체제의 문제라면 시뮬레이터를 만들 수도 있다. 아직 높은 수준의 시뮬레이터를 만들어 보지는 못했지만 간단하게나마 DB 시뮬레이터를 만들어 보기도 했고, 네트워크 TCP 시뮬레이터를 작성하기도 했다.
처음에는 테스트 작성이 오래 걸렸지만 태도가 바뀌고 3, 4년이 지난 이후부터는 코드 구현부터 자동화 테스트 작성까지 어느 누구보다 빠르게 해낼 자신이 생겼다. 말 그대로 그냥 '하다 보면 된다'. 실험과 증명을 해야겠다고 마음을 고쳐먹고 하기 시작하면 테스트 코드 작성도 금방 숙달된다.