한국의 비즈니스에서는 대체로 하나의 공통점이 있다. 무형의 가치를 잘 인정하지 않으려고 한다. 자동차나 냉장고 같은 하드웨어는 제 값을 받고 파는데 문제 없지만 소프트웨어는 그 가치를 잘 인정하려고 하지 않는다. 한번 만들어 놓으면 원가 없이 복사만 하면 사용할 수 있기 때문에 돈 내고 소프트웨어제품을 사는 것을 아까워 한다. 하물며 그냥 대화나 하면서 자문을 해주는 것에는 돈을 지불할 생각을 하지 않는다. 구체적인 형체가 있는 것에는 돈은 아깝지 않게 내는데 컨설팅식의 자문이나 방향 설정이라든지 하는 것은 으레 공짜로 하려고 한다. 저녁이나 한번 사면 된다고 생각한다. 여기에는 두 가지 문제가 있다. 첫째가 돈을 내려고 하지 않는다는 점이고 둘째는 지속적인 컨설팅 없이는 효과가 나지 않는다는 것이다. 정당한 대가를 지불하지 않으면 누가 시간 낭비하면서 지속적인 컨설팅을 해주겠는가? 한두번 만나고는 더 이상 안 만날 것이다.
소프트웨어개발을 하려고 하면 컴퓨터도 필요하고 운영체계도 필요하고 소스코드를 적기위한 도구등 필요한 것이 많다. 개발시작 전에 이런 것을 다 결정해야 한다. 전산고문이 “이런 개발도구를 사용해야 합니다” 하는 결정을 내린다고 하자. 이러한 결정이 잘못 선정된 개발도구로 수 많은 엔지니어가 밤새워서 열심히 일하는 것보다 중요한 것이다. 이렇게 중요한 정보를 공짜로 주워 들으려고 한다. 이를 결정하기까지는 수 많은 시행착오를 거치면서 정립된 경험과 동물적인 감각이 필요하다. 그리고 결정을 내리기 위한 자료수집도 필요할 지 모른다. 하지만 마지막으로 나온 결론은 간단하다. 그러니 그런 말 한마디에 왜 돈을 내느냐고 생각한다. 이미 다 알았는데 더 이상 필요 없다고 생각하기도 한다.
프로그래머들이 만들어 내는 소스코드는 물론 시간도 걸리고 양도 방대하다. 하지만 올바른 길을 갈 때 그 가치가 있는 것이다. 전산고문의 한마디 말을 가치를 기준으로 해서 보면 모든 엔지니어의 임금을 더한 것보다 중요할 수 있다. 정량적으로 측정하기는 힘들다. 가끔 소프트웨어의 가치를 억지로 정량적으로 측정하기 위해 소스코드의 줄 수를 세는 경우가 있는데 이 역시 말도 안 되는 것이다. 뾰족한 수가 없으니까 궁여지책으로 나온 방법이다. IT ROI(투자회수대비)를 측정하는 방법이 있다고 주장하는 사람들도 있다. 이것 역시 궁여지책끝에 나온 부정확한 방법이다. 기술쪽에서 자라온 사람들이 보면 사기라고 볼 수도 있다. 마치 그림을 한 장 사서 회사에다 걸어놓았는데 이 그림에 대한 투자가 얼마나 생산성에 기여했는지를 계산할 수 있다고 주장하는 것과 다를 바 없다. 이러한 것은 오랫동안의 기업경영에서 오는 직감적인 판단의 영역이다. 정량화하기는 어렵지만 주관적인 판단을 내려야 하는 경우는 수도 없이 많다.
언젠가 한국에서 게임을 개발하는 업체인 E사를 방문한 적이 있다. 친구가 부탁을 했었다. 자기 동생이 관련되어 있는 회사인데 제품에 문제가 있는데 고치면 또 다른 문제가 생기고 해서 고객들의 불평이 끊이지 않는다는 것이었다. 방문을 해서 개발팀장들을 모아놓고 회의를 했다. 그 즉시 문제를 알 수 있었다. 개발 프로세스가 전혀 정립되어 있지 않은 것이었다. 학교숙제하는 식의 주먹구구식의 개발이었다. 너무 고칠 데가 많은 중에도 가장 필요가 있을 듯한 개발관리도구를 사용하라고 충고해 주었다. 모두들 진지하게 자세히 질문도 하고 어떻게 적용하는지를 가르쳐 주었다. 그리고 자세한 내용이나 실제 상황에서 벌어질 일은 모든 경우가 다르므로 각 경우에 맞게 진행하면서 조정을 필요로 한다고 말해 주었다. 그리고 그것은 일주일에 한 번 정도 개발과정을 계속 지켜보면서 자문을 해야 가능하다고 하였다. 물론 자문료는 비싸다고 했다. 사실 프로그램하며 일하는 사람들의 관점에서 보면 비싸기는 하다. 하루 와서 말 몇 마디 하고 가는 것처럼 보이는데 자기들 한달 월급을 지불하려면 아깝기 그지 없다. 그래서 그런지 더 이상 자문을 요청하지 않았다. 물론 처음 자문도 공짜였다. 나 역시 바쁜 와중에 자문을 계속 할 수 있는 처지도 아니어서 더 이상 확인하지는 않았다. 나중에라도 부탁하면 친구를 생각해서 억지로 시간내야 하는 처지였으니 말이다. 그 회사가 경영에 어려움을 겪고 있던 것을 고려하면 비싼 돈을 지불하면서 자문을 받을 처지는 아니었다. 또 새로운 방법으로 변화하는 것에 대한 두려움도 있었다. 새로운 방법론이 정립되기까지 변경 후 초기에는 개발속도가 느려질 수 밖에 없다고 얘기했기 때문에 어려운 결정이었을 것이다. 아마도 그 때 사용하던 방법 그대로 개발하고 있을 것이다. 계속 똑 같은 문제를 가지고 있을 것이고. “나는 내 방식대로 살겠다”는 의지의 한국인이다.
몰라서도 못하고 알아도 제대로 하기 힘드는 것이 올바른 소프트웨어 개발이다. 모든 운동이 마찬가지이지만 혼자서 골프교본 없이 골프를 배우기도 힘들지만 마치 골프교본 한 권 주었다고 골프를 잘 칠 수 없는 것과 마찬가지다. 누가 말 한마디로 잘못된 점 교정해 준다고 고쳐지던가? 천만의 말씀이다. 진정 골프를 잘 치려면 계속해서 실전과 함께 전문가한테서 레슨을 받아야 한다. 필드에 나가 실전만 하는 것도 문제가 있고 연습장에서 레슨만 받는 것도 문제가 있다. 실전과 교육이 적절히 균형을 이루어야 한다. 교육은 특히 좋은 선생한테서 받아야 한다. 경험이 많아서 그 사람의 특성에 맞는 방법을 가르칠 수 있어야 한다. 획일적으로는 안 된다. 골프뿐 아니라 모든 운동이 그렇고 소프트웨어개발도 비슷하다. 나도 가끔 골프 레슨을 받는데 돈이 아깝다는 생각이 들기도 한다. 하지만 나 혼자서는 골프실력이 늘기는 어려우니까 아깝지만 할 수 없다. 그러니 소프트웨어개발의 컨설팅도 그렇게 생각할 것이다. 안타까운 일이다. 그 회사는 다행히도 게임업체이니까 그래도 성공할 수 있는 여지는 남아 있다. 다른 소프트웨어와 달리 조금 결함이 있어도 사용할 수 있기 때문이다. 하지만 회계프로그램이나 영업프로그램같이 결함을 용납하지 않는 응용프로그램의 경우에는 시장에서 실패할 것이 뻔하다.
소프트웨어로 성공하기 위해서는 근본적으로 배움에 투자할 줄 알아야 한다. 전문가에게서 제대로 된 방법을 꾸준히 배워야 한다. 불행히도 한국에는 소프트웨어의 역사가 너무 짧아 좋은 전문가를 찾기 어렵다. 올바른 지도 없이 자수성가 하기는 오랜 시간이 지나도 제대로 되기 어렵다. 잘못된 문화가 뿌리깊게 자리 잡기 전에 조금이라도 빨리 제대로 된 소프트웨어 문화를 정립해야 할 때다.
댓글 없음:
댓글 쓰기