아버지는 말하셨지, “공짜 점심은 없단다!”
자본주의에 공짜 점심은 없답니다. 그런데 오늘 영등포 역을 지나다 토마스의 집이라는 곳을 봤습니다. 큰 간판에 “토마스의 집”이라는 이름과 함께 “무료 점심 제공”이라는 글이 적혀 있더군요. 아니 토마스의 집에서는 공짜로 노숙자들에게 점심을 제공해 준다는데, 자본주의에 공짜 점심이 없다는게 말이 되나요? 이 이야기를 한 사람을(아버지 말고요.) 데려다가 토마스의 집에서 무료 점심을 나눠 주는걸 보여 줘야 하는게 아닐까요?
자 흥분을 가라 앉히고, 저만 흥분하거 같습니다만… “자본주의에 공짜 점심은 없다” 라는 말을 왜 했는지 잠깐 고민해 보죠.
이 말의 참뜻은 공짜로 점심을 먹는 사람 입장이 아니라, 사회 전체로 볼 때 뜻을 알 수 있습니다. 누군가가 기적을 일으켜 공짜 점심이 無에서 나타나지 않는 이상, 공짜 점심을 제공해 주는 재원은 누군가의 주머니에서 나와야 합니다. 여러분이 낸 세금일 수도 있고, 김밥집 할머니의 기부금일 수도 있고요. 아무튼 누군가는 공짜 점심을 만드는 비용을 제공해 주어야 한다는게 이 말의 요점입니다. 따라서 우리 사회 전체로(System 관점) 보았을 때 이 세상엔 공짜 점심이란 있을 수 없답니다.(아버지가 틀리시는 경우는 거의 없더군요.)
연말인데다가 지금 Project Leader를 맡고 있는 프로젝트 마무리 때문에 정신이 없습니다. 사실 프로젝트 완료 시점은 아닌데, 고객 요구로 한 개의 프로젝트에 두번의 Release 계획이 잡혀 있습니다. 두 번의 Release라는 이야기만 들으면, Iterative 방식의 Process라는 생각이 들지도 모릅니다. 총 3개의 모듈 가운데 1개의 모듈을 먼저 개발 완료하고, 2개의 모듈은 내년 4월에 완료할 예정입니다.
그렇다면 2번의 Release라는 표현보다는 2번의 프로젝트 완료라고 말하는게 더 맞겠네요. 올해 12월까지 완료해야 하는 모듈은 제가 고객 요구 분석, 개발 명세서 작성까지 하고, 개발은 Outsourcing 하고 있습니다. 물론 도움말이라던지, 인수 테스트는 제가 담당하고 있습니다.
이번 프로젝트를 통해서 “자본주의에 공짜 점심은 없다”라는 말의 뜻을 새삼 느끼고 있습니다. 보통 우리나라에서는 제안서 작성 업무에 투입된 공수를 청구하지 않는게 일반화된 관행입니다. 따라서 프로젝트 수주 제안 작업을 할 때 많은 공수를 투입하지 않습니다.
대형 SI 프로젝트가 아닌 이상, 많이 잡아 대여섯 번의(이건 진짜 많은 경우입니다. 보통 두 세번, 제 경험 상에는요.) 고객 상담을 한 후 최종적인 제안서가 완성이 됩니다. 물론 많은 경험이 있는 고참 개발자와 영업팀이 협의해서 제안서를 만들지만, 시간적 자원적 한계로 이렇게 만들어진 제안서에는 프로젝트의 최종 이미지와 간단한 시스템 구성도, 대략적인 공수, 프로젝트 완료 기간(대부분 고객이 D-day를 정해 줍니다.) 정도를 담습니다.
이 제안서는 하얀 종이 위에 연필로 아주 기초적인 스케치만 해 놓은 상태입니다. 그릴려는 그림이 어떤 것인지 대략적인 윤곽만 짐작할 뿐 정확한 형상은 알 수 없습니다. 물감을 칠 한다면 얼마나 많은 물감이 필요한 건지, 시간은 얼마나 걸리게 될 건지 알 수가 없습니다. 따라서 소요되는 물감의 양과 시간을 알기 위해서는 밑 그림을 좀 더 자세히 그릴 필요가 있습니다.
하지만 여기에 딜레마가 있습니다. 왜 그런지 정확히 모르겠지만 관행이라고 말하는 것이 정답이 아닐까 합니다. 보통 제안작업이 끝나고 산출된 공수와 기간으로 프로젝트 계약이 완료 됩니다. 그 이후 기간이 조정되거나 금액이 늘어 나는 것은 고객도 용납하지 않을 뿐더러, 설계가 끝난 후 프로젝트를 수행하는 회사 내에서도 금액이 늘어나거나 기간이 늘어 난다고 이야기 하는 것은 절대 금기시 되는거 같습니다. 그런 이야기를 하는 PL이나 개발자들은 무능하거나, 방어적이고 소극적인 사람으로 낙인이 찍히게 되죠.
이 때부터 프로젝트 팀의 토요일과 일요일은 모두 Working day로 설정이 됩니다. 제 경험 상 프로젝트 계획 수립 시 토요일과 일요일을 Working day로 설정하면, 그 프로젝트는 100% delay되더군요. “월화수목금금금”의 계획표를 가진 프로젝트는 꼭 해야할 업무도 뛰어 넘거나 간략히 하고 Coding부터 시작합니다. 밑그림을 제대로 그리지 못한 상태에서 도화지는 크고, 그릴 시간도 없어 무슨 그림을 그릴지 생각하지도 않고, 색부터 칠하는 것처럼요.
결국엔 프로젝트 팀원들은 납기를 맞추기 위해 품질을 떨어뜨리는 전략으로 침묵의 공모를 합니다. 물론 PL도 명시적으로 품질을 떨어뜨리라는 지시는 하지 않지만 암묵적으로 개발자와 공범이 되는 길을 택합니다. 이렇게 해도 결국에 Delay가 되고 품질이 떨어진 제품이 고객에게 전달됩니다.
나비의 날개 짓이 태풍을 일으키는 카오스 이론처럼, 프로젝트 초반의 공짜 제안 작업이 프로젝트의 품질을 저하 시킵니다. 따라서 여기서도 자본주의의 공짜 점심은 없다라는 이야기가 얼추 들어 맞는거 같습니다. 이 문제점에서는 고객, SI 업체, 프로젝트 팀원 어느 누구도 자유로울 수 없습니다. 다만 관행이라고 여겨졌던 일에 목표 달성을 위해, 이제는 의문을 가져야 하는게 아닐까요?
이 문제점의 해결책은 프로젝트 기간을 크게 두 구간으로 나누는 것으로 얻을 수 있습니다. 첫번째 기간에는 제안 작업에 소요되는 비용을 별도로 받고, 실제 고참 설계자가 투입이 되어 고객 요구 분석과 간단한 사용자 인터페이스 설계, 대략적인 아키텍쳐를 구성하는 겁니다. 이 작업이 끝나게 되면 대략적으로 소요되는 기간과 공수가 산정이 됩니다. 물론 이 때 나온 결과도 100%의 정확성을 가지고 있다고 보장할 수 없지만, 공짜 제안서와 비교할 수 없는 정확도를 가집니다. 고객이 이 때 나온 결과가 꼭 필요한 시스템이라는 판단이 들 때는 산정된 공수의 80% 수준에서 계약을 한 후 프로젝트를 진행합니다. 80% 수준의 공수로 계약하는 이유는 이 기간에 산출된 공수도 100%의 정확도를 보장할 수 없기 때문입니다. 최종 프로젝트 금액은 프로젝트가 완료된 후 소요된 공수를 정산해서 모자른 공수는 청구하거나, 반대로 남는 공수는 다시 고객에게 되돌려 줍니다.
어떠세요? 좀 복잡하고 고객 입장에서 기존의 계약 방식 보다 돈이 더 들어 보인다구요? 물론 표면 상으로는 그럴 수 있습니다. 하지만 알 수 없는 프로젝트 범위를 기반으로 산정된 공수에 질 낮은 결과물을 없는 것보다, 다소 비용이 비싸도 훌륭한 S/W를 얻는게 좋지 않을까요? 다시 한 번 이야기 하지만, 아니… 아버지 아까 모라고 하셨죠?
“아들아! 다시 한번 말하지만, 자본주의에는 공짜 점심이 없단다!”
※ 제가 마무리 하고 있는 지금 프로젝트에 문제가 많다는 뜻이 아닙니다.(오해하지 마세요!) 다만 그동안 생각했던 것들이 이번 프로젝트를 통해서 정리된다는 뜻입니다. 여러모로 수고해 주시는 김팀장님과 이선임님, 조주임님께 감사 합니다.(이 글을 안 보실지 모르지만요.) 아무쪼록 프로젝트 잘 마무리하고 맛난 거 먹으러 가자구요!