찌질이 비평가란  다음과 같이 정의를 내릴 수 있다.

"자신이 비평 대상이 될 수도 있는 빌미는 거의 제공하지 않으면서, 남의 글이나 프로그램 소스에 비난하기만을 즐길 뿐, 비평을 왜 하는지 근거있는 이유는 설명하지 않는다. 다시 말해서 근거없는 힐난을 일삼는 자들을 말한다."

남의 소스 코드를 보고 그 코드의 허접함을 신랄하게 비평할 수는 있다. 남의 잘못된 코드에서 결점을 찾아내고 이를 해결하려는 노력은 개발자로서 당연히 가져야 하는 자세다. 그런데...

타인의 코드에 대해서 비평만 가할 뿐 해결책을 제시하지 않는 자들이 종종 있다. 남의 소스를 뭉뚱그려 비난할 줄만 알지. 그 소스의 정확히 어떤 부분이 문제이므로, 그 부분을 개선한 소스를 제시하지는 못한다는 것이다. 더우기 이들은 남의 소스만을 비난하지, 자신의 소스를 공개하여 자신이 비난의 대상이 되는 경우는 지극히 꺼린다. 남을 비난하기만을 즐길 뿐, 자신이 비난 대상이 될 원천을 봉쇄해버리는 아주 겁쟁이이며 비겁한 존재들이란 것이다.

불행스럽게도 우리 개발 관련 분야에는, 이런 찌질이 비평가들이 매우 많음을 부인할 수가 없다. 찌질이 비평가들의 특징은 알맹이나 근거가 없는 비평을 잘한다는 것이다. 이들이 자주 사용하는 표현으로 다음과 같은 것들이 있다.

"기냥 허접하다."

"객체지향적이지 못하다."

"소스가 깔끔하지 못하다."

"상속을 하나도 사용하지 않았으므로 이건 구라 객체지향이야!"

"인터페이스를 하나도 사용하지 않았으므로 이건 허접 객체지향이야!"

"제대로 된 UML을 그리지도 않고 코딩하는 것이 무슨 개발이야!!"

상속과 인터페이스를 사용하지 않으면 객체지향적이지 아니하며, UML을 반드시 모조리 그려놓고 코딩에 임해야 한다고 우기는, 이 찌질이 비평가들은, 실제 자기소스를 우리한테 보여주는 경우는 거의 없으므로, 찌질이 비평가들이 얼마나 객체지향적으로 잘 상속하고 인터페이스를 잘 쓰는지, 그리고 얼마나 많은 UML 도면을 사무실 벽 전체에 도배하면서 코딩하는지, 우리는 확인할 방법이 별로 없다.

정작 이들에게 상속이나 인터페이스를 대체 어떤 경우에 사용해야 하느냐고 물으면, 허접한 약어나 용어 들이대기로 장시간을 돌려서 말하다가, 슬며시 "그딴 거도 모르세요? 좀더 공부하세요!"라는 아주 건방진 충고를 던져주고는 결론을 맺고 만다. 설령 자신의 소스를 보여준다 한들, 대체 왜 이부분에 상속을 사용했는지, 없어도 될 인터페이스는 왜 만들었는지 종잡을 수 없는 경우가 대부분이다.

이들이 작성하는 소스의 대부분은, 리팩토링의 반대개념인 리펑토링 중에서, 보물 찾기(Treasure hunt)식의 코드란 것이다. 실제로는 10 줄이면 충분할 코드를 쓸데없이 상속과 인터페이스를 들이대서 꽈배기처럼 비틀어서 100 줄로 만들어 놓은 코드란 것이다. 그 상상초월한 허접 소스를 보면 벌어진 입을 다물 수 없을 지경이 된다.

프로그램 소스이든 일반 게시물들이든 간에, 작성자가 되기보다는 비평가가 되는 것이 여러모로 편함은, 부인할 수 없는 사실이다. 원래 자동차를 만든다는 것은 무지 어려운 것이지만, 완성된 자동차에 대한 비평은 누구나 할 수 있는 것과 마찬가지이다. 그렇지만, 개발자 게시판을 보면, 작성자 수는 무지 적은 반면에 비평가를 자처하고 싶은 사람들이 너무 많다는 것은 심히 눈살 찌추려짐을 유발한다.

찌질이 비평가들의 심리 상태는 아주 간단하다. 뭔가 구체척으로 보여줄 실력은 없기에, 가장 만만하게 할 수 있는 비평만을 일삼고 이로 인해서 자신이 먼가 대단한 실력이 있다고 슬쩍 구라 치고 싶은, 열등감의 반대적인 표현일 뿐이다.

부하 중에 찌질이 비평가 성향의 개발자가 있다면 그나마 다행이다. 격리(골방으로 내 쫒기)로 해결할 수 있기 때문이다. 문제는 이런 찌질이 비평가가 팀장이거나 설계자라면, 팀 전체가 치명적인 상황에 도달하게 된다. 이들은 프로그램이란 실행되는 존재이며 코드는 실행되는 존재를 만들기 위해 작성하는 것이란 사실은 잊은체, 코드의 우아함이나 객체지향이니 리팩토링같은 개발론적 개념만을 추구하다 끝내는 프라젝트 전체 일정을 말아먹고 만다.

제대로 실행되지 못하는 코드는 객체지향이든 어떤 번지르르한 개발 개념으로 위장한다한들 쓰레기일 뿐이다. 다시 말해서 제대로 돌아가는 코드를 만들기 위해서 객체지향을 도입하는 것이지, 객체지향을 위해서 코딩하는 것이 전혀 아니란 것이다.  엄밀히 말하면 우리는 돈 받기 위해서 코딩하는 사람들이다. 이 돈을 제대로 받기 위해서는, 개발 일정과 요구 기능 완수가 필수임은 두말할 필요가 없다.

간혹 이처럼 달걀과 계란을 구분 못하는 찌질이 비평가 성향의 개발자를 볼 때 매우 안쓰럽다. 예전에는 이들을 미워했으나, 요즘 나는 이들을 동정한다. 사실 나도 한때 그런 찌질이 비평가인적인 시절이 분명히 존재했기 때문이다. 어쩌면 나 스스로도 아직까지도 찌질이 비평가적 성향을 모조리 버리지는 못한 것 같다.

좋은 게시판이란 올바른 비평가들의 수도 많아야 하지만, 좋은 글을 작성하는 사람들 수가 더 많아져야 함은 매우 당연한 것이다. 작성된 글이 너무 적은데 무슨 비평을 할수가 있다는 말인가? 델파이 관련 게시판에서 비평이나 비난으로 종종 물의가 일어나지만, 간혹 알맹이있는 토론이나 비평글이 있긴 하지만, 제대로 된 비평이나 비난은 너무 적다는 것은 무지 안타깝다.

추신 : 혹시 이 글을 읽은 후에,  명칭 작성 원칙, 들여쓰기 원칙,  객체지향과 리팩토링 등등의 개발 관련 기법들을 "개발 분야의 쓰레기"로 간주하고, 개발계의 "Peace"를 위해서는 이런 것들을 사정없이 내동댕이 쳐야 한다고, 귀하가 이해했다면 매우 곤란하다. 만일 그렇게 이해하신 분이라면 과거이든 앞으로든 간에, 내가 쓴글은 절대로 보지 않아야 한다. 내글은 귀하에게 정말 쓰레기일 뿐이다.