많은 소프트웨어 방법론들을 보면(전부는 아니지만, 대개 유명하다고 싶은 것들을 몇가지만 보면),
오랜 역사와 시행착오, 그리고 경험을 축적하여 공학적으로 정리한 방법들을 다양하게 시도하고
제공한다. 건축 메타포의 형태로 끄집어 내 정리한 부분도 있고, 각종 제품 생산 라인을 정리한 부분도 있다.
공장에서 제품을 생산하는 예를 들어보자.
생산라인 A를 통해 최종 제품 A를 만든다. 맨 처음 사람은 제품 프레임을 꺼내 몇가지 선들을 붙이고 정리해서 컨테이너 벨트 위에 얹는다. 그 다음 사람은 다시 파워 유닛을 꺼내 프레임에 얹고 나사로 고정한다. 그렇게 흘러 흘러 맨 나중의 사람이 그 제품을 마무리하고 포장을 한다.
공장 생산 만능 주의 - 작업 흐름과 분업 그리고 예측이 가능해야 생산이다! 라고 생각하는 - 에 빠지신 분들에게는 정말이지 저 생산방식이 가장 효율적이고 완벽하다고 생각한다. - 또한 많은 공장들은 저렇게 생산하며, 큰 문제없이 잘 해오고 있다. - 그런데 왜 소프트웨어는 저렇게 안돼?
공장과 소프트웨어의 개발을 가만히 매칭 시켜보면, 우리도 그 공장 메타포를 은근히 이해하고 이용하고 있다.
컨테이너 벨트가 바로 일종의 폭포수 모델의 메타포라고 생각한다면, 컨테이너 벨트 옆에 앉아 부품을 하나씩 끼우는 사람들이 아키텍처, 설계자, 개발자, 테스터의 역할을 한다고 보면 된다. 이 공장 메타포가 이해가 안될지도 모르겠지만, 가만히 생각해 보면 이런 핑계를 대고 있지는 않는지 한 번 주변을 보자. 프레임이 구축되지 않아서, 설계가 빠져서, 이전 부분을 개발하는 개발자가 덜 개발을 하고 아파서 등등.....
이게 바로 공장 형태의 개발을 중시하는 모습이지 않을까 싶다.
자, 그럼 우리의 소프트웨어도 완벽한 분업과 완벽하게 시간을 잴 수 있겠네? 라고 미리 짐작하실 분도 있고, 아니면 그래서 우리 소프트웨어가 납기 못맞추고 제대로 못만든다고 생각할 수도 있다. ( 후자의 경우는 대개 작업 초반자가 깽판? 을 부려서 그런 현상을 발생한다고 생각한다. 설계 미스, 아키텍처의 부실 등등 )
그런데 내 생각은 다르게 보고 있다.
소프트웨어의 개발은 그 컨테이너 벨트 위에서 벌어지는 것이 아니라, 바로 그 컨테이너 벨트 자체를 만드는 것이라고 생각한다. 그리고 그 컨테이너 벨트를 이용하는 쪽이 고객이라는 사실이다.
공장마다 컨테이너 벨트의 종류와 배치가 전혀 틀리다. 생산품에 따라 전혀 틀리다. 몇가지는 비슷할 지 모르겠지만, 대개 틀리다. 또 어디서는 직선의 컨테이너 벨트가 다른 공장에서는 "ㄱ"자로 휜 형태의 컨테이너 벨트일 수 있다. 어디는 속도가 시속 1KM로 진행되면, 어디는 시속 1.5KM로 컨테이너 벨트가 흐른다.
고객이 가진 조건과 형태가 매번 할때마다 판이하게 틀리다. 공통화 시킬 요소가 너무 적다는 생각이다.
(윗 말에 반박의 내용으로 "MS 윈도 같은 경우 다양한 분야에서 다양하게 쓰인다" 라고 건넬지는 모르겠지만, 그게 그렇게 간단하게 만들어졌다고 생각한다면, 당신은 프로그래밍을 모르시거나, 정말이지 낙관주의자 인듯 싶다.MS 윈도 프로젝트는 애들 장난하는 프로젝트가 아니다. 수천명의 개발자가 다양한 생각과 다양한 의견 충돌을 어떻게 어떻게 조율하고 조정해서 만들어지는 것이다. 정말이지 MS 윈도가 지금까지 끌어온 윈도 시리즈를 보고 있으면 윈도 개발팀-그룹에 대한 무한 영광을 올리고 싶다)
우리가 닥쳐서 일하고 있는 SI라는 환경은 바로 이런 곳이다. 매번 고객의 요구가 바뀐다. 또 시대의 흐름에 필요한 컨테이너 벨트가 필요한데, 그 컨테이너 벨트를 만드는데 시간이 많이 걸리고, 변화에 유연하지 못하면 요 근좌 유행하는 소량 다품종 생산과 거리가 멀다. 고객은 컨테이너 벨트에 지랄하고, 개발자는 돈 조금 줘 놓고, 제멋대로 이것 저것 만들어 달라는 고객에 지랄한다.
왜 이런 현상이 발생했을까?
나의 주관적인 생각에는 다음과 같이 요약되지 않을까 싶다.
개발자측은 개발자 측 대로 컨테이너 벨트가 있어 이 안에서 나름 순서에 맞는 제품을 만든다.
(즉 가급적 똑같은 형태의 여러개의 제품이 나오길 기대한다.)
고객은 고객 측 대로 개발자의 생산품으로 컨테이너 벨트가 구축되어 돈벌이를 위한 제품을 만든다.
(즉 자기 입맛에 맞는 환경 구성용품을 사길 원한다.)
서로간의 양보가 없다면 이건 절대 끝나지 않는 무한루프의 게임이 된다.
근래 공부한 내용 중에 한가지를 대안점으로 들자면 바로 SCRUM 이다. (럭비의 SCRUM 작전이라고 한다. 무슨 긴 문장의 약자 따위는 아니다 ) 고객이 필요로 하는 점들을 나열한 뒤, 고객이 필요로 한다고 판단된 최소한의 기능을 구현하여 시연까지 될 수 있는 아주 작은 단위(2주? 3주? 한달? 그렇게 일정 기간 단위로 나눈)로 점진적으로 개발한다는 것이다. 초기에는 혼란의 연속이고 끊임 없는 개발일지는 모르겠지만, 조금씩 조금씩 하다가 보면, 미처 서로간에 놓치고 있던 문제점이나 생각을 정리하고 볼 수 있지 않을까? 고객이 원하는게 무엇이며, 개발자 측이 보여줄 수 있는게 무엇인지를 조금이나마 더 명확히 볼 수 있을 것이라 생각이 든다.
한번 고객과 개발자 측이 이런 문제로 무한루프에 빠져 있는 상황이라면, 한번 읽어보고 조금씩 하나씩 실천해보는 것도 좋을 것같다. 나 역시 이런 실천 방법들을 고민하고 생각하며 공부하고 있는 중이다.
(추천 도서 :
스크럼과 XP)
