코드를 짜 내려 가는 것은 답이 정해진 창작 행위다. 열 명의 개발자에게 같은 기능을 제시해도 열 개의 다른 코드가 나오는 것이 창작의 증거다. 그렇지만 코드가 맞물려 실행된 결과는 코드를 작성하기 전에 이미 정해져 있다. 개발자들은 각자의 답을 향해 가고 있는 것이다.

버그를 만들지 않는 개발자는 존재하지 않는다. 아니 사실, 코드를 짜는 것은 버그를 만드는 과정에 가깝다. 나는 온갖 버그를 만들어 낸 다음 그 버그를 하나씩 없애는 과정에서 희열을 느낀다. 개발을 마법의 한 종류라고 생각하는 사람은 '왜 처음부터 완벽한 프로그램을 명령하지 않는 것이지? 개발자는 다 변태인가? 자신이 만든 프로그램이 이상 동작 하는것에 희열을 느껴?' 라고 생각할 수 있겠지만 이 것은 오해다.

프로그램의 표면적인 부분은 오히려 개발자보다 디자이너의 공이 크다. 디자이너는 개발자가 만든 버그를 어떻게 하면 사용자가 눈치채지 못하게 할 것인지, 어떻게 하면 화를 내지 않게 할 것인지를 고민하고 개발을 마법의 일종으로 여기게 포장해준다. 아마 개발을 '신기한 것'으로 인지하고 있다면 훌륭한 디자이너 선생님들의 작품에 익숙해져 그럴 것이다.

'버그를 만들지 않고 프로그램을 짜기'란 스케치와 덧칠 없이 붓을 한 번만 들어 명작을 만들라는 주문과 같다. 개발자에게도 디자이너에게도 고객에게도 스케치 뿐인 제품은 버그 덩어리로 인식된다. 훌륭한 제품으로 나아가기 위해서 개발자는 스케치를 그리고 끝없이 덧칠하는 과정이 필요하다. 이 과정이 버그를 만들고 없애는 과정인 것이다.

어떨 땐 이 과정이 너무나 순탄하고 완벽해서 왜 버그가 없는지 제 자신을 의심하게 만들지만, 어떨 땐 내가 쓴 코드가 왜 동작하지 않는 것인지 한참을 쳐다보고 고뇌에 잠기게 한다.

사실 개발자는 컴퓨터와 대화를 나눌 수 있다. 하지만 개발자가 아닌 사람이 본다면 정신병원에 입원할 가능성이 있고, 정신병원 의사 선생님이 개발자 겸직중일 가능성이 낮기 때문에 일부러 그 사실을 숨기는 것이다. 나는 두 시간이 지나도 버그가 해결 되지 않을 땐 컴퓨터에 말을 걸어본다.

console.log('씨발왜안돼ㅡㅡ')