SW 이론과 현실의 괴리

필자는 '소프트웨어의 이론과 현실의 괴리'라는 제목으로 강연한 적이 있다.

소프트웨어 분야에서 주먹구구식으로 일을 하다가 이래서는 안되겠다 싶어 제대로 된 이론을 도입해 좇아 하다보면 대부분 이론과 현실의 괴리에 부딪히게 된다. 이론에서는 이렇게 주장하지만 현실에는 맞지 않는다는 경우가 생긴다. 이론을 가르치면서도 이론대로 안 된다고도 말한다.

이론과 현실의 괴리는 닭과 달걀의 문제와 비슷하다. 이론을 진심으로 이해하려면 경험이 있어야 하고 이론을 발전시키고 정립하려고 해도 경험이 있어야 한다. 경험 끝에 이론이 정립되기 때문이다. 반면에 경험을 제대로 쌓으려면 이론을 알고 효과적으로 따라 해야 한다. 결국은 이론과 경험을 병행해서 발전해 나가는 방법이 옳은 것이다.

운동을 체계적으로 해 본 사람이라면 같은 맥락으로 공감하기 쉬울 것이다. 운동을 제대로 배우기 위해서는 이론도 약간 배우고 실제로 시도해보고 또 더 많은 이론을 배우고 또 시도해보고 이런 식으로 진행하게 된다. 좋은 이론 책을 다 외운다고 해도 운동을 잘 할 수는 없다.

소프트웨어 관련된 수 많은 이론들은 대부분 대동소이하다. 예나 지금이나 바뀐 것은 별로 없다. 특히 기본으로 돌아갈수록 더욱 그렇다. 세상에서 제일 좋은 이론을 찾아 헤매는 것과 같이 비효율적이고 불가능한 일은 없다. 그런 것은 애초부터 존재하지 않기 때문이다. 배우는 사람의 환경, 특성과 경험에 따라 이해하기 쉽게 잘 정리해 놓은 교재는 있을지 모르나 모든 사람에게 다 적용되는 가장 좋은 방법을 적어 놓은 이론 책은 없다고 단언할 수 있다.

필자가 접한 개발방법론만 해도 20여년 전의 미국방부의 개발론부터 GTE, General Electric의 개발론 등 수도 없이 많다. 각 회사에서 새로운 방법이 나온 것은 아니다. 기본은 폭포수 모델이라고 대동소이 하다. 각 회사의 개발환경과 프로젝트에 맞게 조금씩 변형해서 사용하는 것이다. 사용하는 용어나 문서 이름이 조금씩 다르기도 하다.

인터넷이 나오고 벤처붐이 지나면서 근래 들어 경쟁이 치열해져 개발시간을 단축하고 불확실한 기술에 대한 리스크를 줄이기 위해 여러가지 변형된 개발방법론이 나오긴 했으나 기본은 항상 같다.

개발방법론을 현실에 적용하는 방법을 얘기하다 보면 자주 듣는 질문이 있다. 어느 방법론이 제일 좋은 가라는 질문과 각 단계에서 나오는 산출물에 대한 제일 좋은 표준 템플릿(Template)을 구해 달라는 것이다. 이 질문은 이 세상에서 가장 좋은 음식이 무엇이냐고 묻는 것과 같다. 회사에 개인에 따라 다를 수 밖에 없기 때문이다.

내 답은 항상 똑 같은 데 '그런 것은 없다'고 한다. 회사마다 다르고 프로젝트마다 다르고 중요한 것은 한 회사에서 통일된 템플릿을 사용해서 누구든지 쉽게 이해할 수 있게 하는 것이 더 중요하다. 통일된 템플릿의 중요성은 문서를 볼 때 원하는 내용이 어디 부분에 있을 것이라는 것을 이미 알고 있기 때문이다. 어느 템플릿을 사용하건 하나를 선택해서 각자의 입맛에 맞게 커스터마이즈하고 통일하면 된다. 그렇게 해도 프로젝트마다 표준에서 약간씩 변형된 템플릿을 사용하게 되는 것은 피할 수 없다.

이론을 모르면 실패한다. 그리고 이론을 너무 중시해도 실패한다. 이론을 모르면 당연히 'Best Practice'라는 오랜 경험의 결과로서 나온 노하우의 혜택을 받지 못하고, Best Practice가 나오기 위해 거쳤던 같은 시행착오를 거치게 될 것이다. 이론을 너무 중시하게 되면 비효율적인 시간 낭비와 중복된 정보가 여기저기 기록될 수 밖에 없다. 수천명이 개발하는 소프트웨어의 개발방법론이나 수십명이 개발하는 소프트웨어 개발방법론이나 이론은 똑같이 얘기하나 실행은 다를 수 밖에 없고 달라야 한다.

개발방법론의 기본인 폭포수모델 방법론과 거기에서 파생된 많은 방법론이 있는데 개발단계로 보면 요구사항분석, 상위설계, 하위설계, 구현, 테스트의 순서를 거의 예외 없이 지나게 되는데 각 단계에서 수 많은 산출물이 명시되어 있다. 하지만 명시된 산출물을 다 만드는 프로젝트는 한번도 경험해 보지 못했다. 항상 필요한 대로 선택된 핵심 산출물만 만들었다.

똑같은 개발방법론을 사용하더라도 회사마다 다르고 프로젝트마다 다르다. 적절한 문서를 선택하는 것이 어렵고 그것이 핵심 성공요소이다. 적당한 문서를 선택한 다음에도 선택한 문서의 어느 부분을 선택적으로 작성하느냐가 두 번째 핵심이다. 이것은 책이나 교육으로는 해결할 수 없는 감각적인 판단 영역이다.

미국의 대기업에서는 거의 문화적으로 정착되어 있고, 소프트웨어 역량성숙도 모델인 CMM의 레벨 3에서도 주요 프로세스 영역의 하나로 나오는 '동료검토'라는 것이 있다. 동료의 작업을 검토한다고 하면 쉬워 보일지 모르나 건설적인 비판과 토론이 얼마나 어려운지는 검토나 토론을 해본 사람이면 공감할 것이다.

잘못하면 시간만 낭비하고 감정 상하고, 안하느니만 못한 상황이 될 수도 있다. 동료검토 만큼 중요한 것도 없으나 시간이 없다는 변명으로 대부분 안하고 만다. 제대로 해도 시간 낭비하는 듯이 보이고 능률적인 실행을 하기도 어렵다. 하지만 오류를 줄일 수 있는 핵심 프로세스중의 하나이다. 서로 배운다는 입장으로 임해야 하고 꼭 해야 한다고 권유한다.

결론적으로 이론도 경험의 바탕이 없이는 효용이 없다. 선 무당이 사람 잡는다고 무조건 이론대로 좇아 하면 더 큰 문제가 생긴다.

한 편에서는 이론대로 해야 한다고 주장하면서도 이론대로 실행하려고 하면 '그렇게 하면 안 된다'고 하는 모순에 빠지는 것 같으나 이론과 현실과의 괴리를 잘 이해하면 타협된 방법을 찾아낼 수 있을 것이다. 이 판단은 이론과 경험을 동시에 갖춘 전문가의 영역이라고 할 수 있을 것이다.

/김익환 SW컨설턴트 ik_kim@yahoo.com