마인드컨트롤 설립자 잭 심슨
여기 건축공학 엔지니어들이 있다. 그들이 이제 새로운 다리를 놓으려고 준비를 하고 있다. 가장 먼저 하는일은 수학적 계산을 통한 설계와 도면 작업이다. 그 이후 이제는 1:50사이즈로 줄인 다리를 제작하고 문제점을 파악한다. 그렇다고 해서 1:50사이즈로 줄여 제작된 다리를 보고 “야 다 된것 같다. 이제 트럭을 타고 건너볼까?”라고 이야기하지 않는다.

게임 엔지니어링은 약간 다르다. 기획 작업을하고, 구조를 준비해 순서도 등을 그려내고, 사전작업을 마무리한다. 이제 건축가들의 모형에 해당하는 프로토타입을 만들어 낸다. 그런데 마무리작업을 끝낸 프로토타입을 보고 “야 잘돌아가는 것 처럼 보이는데? 이제 깔끔하게 다듬고 버그를 잡은 다음에 팔아야 겠군”이라고 이야기 하는 것을 심심찮게 볼 수 있다.

▲ 마인드컨트롤 설립자 잭 심슨

만약 이것이 그저 프로그래머와 비즈니스 타입에 대한 관계 차원이기 때문이라고 생각한 결과라면 그 엔지니어는 낙점이다. 불편한 진실을 이야기 하자면, 프로그래머들은 종종 이렇게 믿곤(오해하곤) 한다. 이 능력(?)으로 인해 해킹이 발생하고 지속적으로 패치를 하고, 심지어 프로토타입을 뒤엎기까지 한다. 결과적으로 보면 낮은 비용으로 프로그램을 제작하는 것 조차 실패로 돌아간다. 

건축 설계 엔지니어들은 절대 “만약 이게 제대로 안먹으면(동작하지 않으면) 패치를 통해 해결하겠다”라고 이야기 하지 않는다. 전자 엔지니어들은 절대 “아 동작하는 것 같군, 우선 마감하고, 안되면 뜯어서 업그레이드 해야지”라고 이야기 하지 않는다. 이처럼 기계와 관련된 엔지니어들은 절대 그들의 제품을 두고 품질 저하 현상 등을 감추면서 팔아넘기려고 하지 않는다. 자동화된 모니터링 시스템을 통해 충분히 눈속임을 할 수 있음에도 불구하고 결코 그런 일은 없다.

소프트웨어 엔지니어들이 제대로된 일을 하려면 - 다른 창조적인 일들이 교훈을 주듯 - 프로토타입을 만들기 위해 준비된 시간과 공간, 그리고 제작물은 이용 가능하도록 완벽하게 만들거나, 아니면 일회용으로만 쓰여야 한다. 실패 없이는 전진도 없다. 그러나 당신의 실패에 당신의 고객들까지 가담시켜서는 안된다.