소프트웨어 테스팅의 경로 의존성에 대한 단상

일전에 경로 의존성에 대해 이야기 한적이 있었다.

경로 의존성에 대한 것은 이전 포스팅을 읽어보시기 바란다. 한번 한 얘기 두번 하는거 생각보다 쉽지 않습니다.

갑자기 웬 경로 의존성이냐?

Extreme Programming 2판을 읽으면서 소프트웨어 테스팅이 왜 개발 과정에서 중요한 대우를 받지 못하는지, 왜 소프트웨어 개발의 성공율이 획기적으로 개선되지 못하는 가에 대한 경로 의존성을 생각하게 되었다.

인류의 짧으면서도 짧지 않은 역사 속에서 가장 먼저 시작된 프로젝트는 무엇일까?

그것은 아마도 건축이 아닐까? 싶다. 지금도 이집트나 세계 곳곳에서 수천년동안 그 위용을 자랑하는 수많은 건축물들이 남아 있다.

고고학자들은 지금의 기술로도 불가능할거라는 건축물들도 있다. 어쨌든 수많은 프로젝트에서 건축이 인류가 시작한 가장 오래된 프로젝트의 유형 중 하나라는 데는 별다른 큰 이견이 없을 것이라고 생각한다.

건축은 그 오래된 역사 속에서 많은 방법들이 시도되었고 그 수많은 방법과 경험, 실패 속에서 정제되어 최근에 있어서는 그 신뢰성은 믿을만한 수준에 도달했다. 물론 무너지는 건물도 있긴 하지만.. 가장 신뢰성 높은 관리 방법론을 가지고 있는 프로젝트인 것은 확실한 듯 하다.

그리고 건축은 그 오래된 역사속에서 다른 종류의 프로젝트 관리 방법론에 많은 영향을 끼쳤고 많은 프로젝트관리 방법론이 건축에 관한 메타포를 근본으로 하고 있는 경우가 많다.

최근에 많이 논의되고 있는 Pattern 도 그 시작은 건축이었다.

어쨌든 건축의 프로젝트 관리 방법론을 기반으로 하는 수많은 관리 방법론들은 실제로 커다란 문제를 일으키는 경우는 많지 않다.

그런데, 우리가 한가지 간과하고 있는 것이 하나 있다. 우리 주변의 많은 프로젝트들은 물리적인 세계를 관리하는 경우가 많다는 것이다. 건축은 분명 우리가 쉽게 인식할 수 있는 물리적인 것이다. 철강, 선박 등 많은 것들은 우리가 쉽게 인식할 수 있는 물리의 세계에 속해 있다.

그런데 소프트웨어는 어떨까?

소프트웨어 프로세스의 많은 관리 방법론들도 그 근간을 건축에 두고 있는 경우가 많다. 그런데, 소프트웨어는 우리가 인식할 수 있는 물리의 세계에 속해 있는 것이 아니다.

소프트웨어는 철저하게 인간의 논리적인 인식 과정 속에 있는 비물리적인 세계에 속한 분야이다.

물리적인 세계와 비물리적인 세계의 간극은 결국 소프트웨어 개발 방법론에 의해 만들어진 많은 수의 소프트웨어들을 클루지로 만들어버렸다.

우리가 수천년동안 지속했던 건축에 의한 방법론은 우리의 많은 사고 방식에 선입견으로 박혀 있고 그러한 선입견으로 우리는 소프트웨어를 대하고 있다.

한가지 예를 들어본다면, 우리가 어떤 건축물을 건설하면서 중간 중간 건설한 결과물을 테스트 하는 경우를 본적이 있는가?
건설에서는 건축물에 대한 테스트는 건물이 완성되고 난 후에 감리라는 형태로 테스트를 하고 승인을 하는 방식을 취하고 있다.
이것이 수천년동안 우리가 프로젝트의 결과물을 테스트 하는 방법이었다.
그러한 관습은 소프트웨어 개발에 그대로 적용되었다. 우리는 소프트웨어를 개발하면서 중간에 테스트 하는 것에 대하여 무의식적으로 거부감을 드러내거나 그 중요성을 인식하지 못한다.
폭포수 모델로 대표되는 소프트웨어 개발 방법론에서 테스트는 제품이 모두 만들어진 후에 시작하는 것이 매우 당연한 것이 되었다.

물론 초기의 건축에서는 프로토 타입등을 통해 기술을 습득한 흔적을 우리는 고대의 건축물들에서 찾을 수 있다. 하지만 수천년동안 축척된 경험에 의해 최근에는 어떤 건축물들을 지을 때 실제적인 프로토타입을 만드는 경우는 많지 않다.

프로토 타입에 대한 많은 부분은 지금은 시뮬레이션이 그 역할을 수행하고는 있다. 혁신적인 디자인과 소재에 대한 탐구를 통한 건축물은 지금도 진화중이다.

하지만 소프트웨어 개발 방법론은 수십년째 거의 제자리에 가깝다. 변화의 물결은 아직은 거세지 못한 것 같다. 테스트를 개발 초기부터 시작해야 한다는 개념은 아직까지도 많은 사람들에게 낯선 개념이다.

하지만 분명한 것은 소프트웨어와 건축물은 그들이 속한 세계가 다르다는 것이다.

속한 세계가 다르다면 우리는 그 각각을 다른 시각으로 볼 수 있어야 한다.

한가지 더 생각해 본다면, 실제 우리의 세계에서 처음에 움막을 만들고 그 다음에 사람이 그 움막에 살면서 움막을 개보수해서 2층 빌라를 만드는 일이 가능할까?
불가능하다. 만약 우리가 움막을 2층 빌라로 만들기 원한다면 우리는 움막에서 나와야 하고 움막을 완전히 없애고 그 위에 2층 빌라를 지어야만 한다.

하지만 소프트웨어는 그렇지 않다. 우리는 작년에 사용하던 시스템을 사용하면서 올해 새로운 시스템을 만들고 그 시스템을 기존의 시스템에 덮어 씌우는 것에 대해 별다른 거부감이 없다.

트위터의 @hrg 님은 컴퓨터는 수학에서 태어났고, 생물학에서 생각하는 법을 배웠고, 물리학에서 움직임을 배웠고, 이제는 심리학에서 사람과 대화하는 법을 배우는 중 이라고 말씀하신 적이 있다.

마찬가지로 소프트웨어 프로세스는 분명 건축에서 많은 개념과 메타포를 물려받았지만 이제는 그 틀을 벗어날 필요가 있다고 생각한다.

그것은 그들이 속한 세계가 다르기 때문이라고 생각한다.

여러분은 소프트웨어의 본질에 대해 얼마나 이해하고 계십니까? 소프트웨어의 특성에 맞는 관리 방법에 대해 얼마나 생각하고 계시나요?

많이 부족한 글입니다. 이 글에 대한 많은 아이디어는 'Extreme Programming 2판' 에서 빌려왔습니다. 자세한 내용을 원하시는 분은 해당 책을 읽어보시기 바랍니다.

생각을 글로 옮긴다는 것이 아직도 많이 익숙하지가 않습니다. 댓글이나 트랙백 등으로 많은 의견을 나누었으면 합니다.