물론 이런 형태는 일부분이다(라고 믿고싶다). 조사된 내용이 있는 것도 아니라서, 얼마나 만연해 있는지도 알 수 없다. 단지, 이런 형태가 있긴 있다는 것, 그것도 한두 건은 아니었다는 것 정도만 알 수 있을 뿐. 때때로 어떤 조직에서는 일정 금액 이하의 프로젝트는 간소한 절차를 거쳐서 입찰을 낼 수 있는데, 큰 금액의 프로젝트를 잘게 잘라서 하나의 업체나 여러 업체에 갈라주기도 한다. 아마도 이런 프로젝트에 입찰하고 일 하는 업체들이 어느정도 정해져 있기 때문에 그런 것 아닐까 싶다.
당장 정당하게 입찰 과정을 거치는 정부부처에서조차도, AS나 업무의 효율성, 안정성 등을 따지면서 공공 프로젝트를 큰 업체에게만 맡기려 하는 현실. 그런 현실과 이런 상황은 맞물려 있다. 안정성을 추구한다는 것. 소프트웨어 사업도 실패율이 꽤 높은 사업이라는 것을 인식하고, 일정 비율은 실패할 수 밖에 없다는 것을 인식했으면 싶다.
저렇게 프로젝트를 발주하면 다른 사람에게서 심사는 안 받느냐면, 그것도 아니다. 아무리 간소화 해서 진행하더라도 심사와 평가는 다 받는다. 그런데 그게 또 주먹구구식이다. 여기서 퇴짜 놓으면 나중에 저쪽에서도 퇴짜 놓을 수도 있으니까, '좋은 게 좋은거다' 정신으로 해결. 왠만큼 엉망이지 않으면, 아니 다시 말해서, 문서 요건만 잘 갖춰 놓으면 크게 문제삼지 않는 분위기랄까.
해결책이라면, 외부 인사들을 통한 심사와 평가가 있을 테다. 사실 모든 프로젝트를 그렇게 엄격하게 한다면 숨통이 좀 막힐 수 있다. 사안에 따라 급한 것도 있을 수 있고, 사실 그냥 넘어가도 큰 문제 되지 않는 조그만 것도 있을 수 있다. 그러니 경우에 따라 평가만 제대로 한다든지 하는 유동성을 넣으면 될 테다. 평가만 제대로 꼼꼼하게 따져서 해도, 어느 정도는 뽀록나기 마련이다. 평가마저도 주먹구구식인 게 문제지.
이런 것들, 따지고 보면 개발 바닥을 흐려놓는 근본 원인들 중 큰 물줄기 하나다. 자기 제품만 개발한다고, 게임 개발을 한다고 해서 이런 것에서 크게 벗어나 있는 건 아니다. 부디 이런 내용들이 공론화 되어서, 색다른 방안을 모색하는 장이 열렸으면 싶다. 한두사람의 머리로 해결할 수 있는 내용은 아니기 때문이다.
