변경 가능한 요구사항, 작은 계획

우리가 소프트웨어를 개발하는 동안 요구사항이 변경되지 않는 경우는 거의 없다.

요구사항은 수시로 바뀐다. 출시가 당장 내일인 경우에도 변경되는 경우도 있다.

그리고 우리는 요구사항의 변경이 얼마나 큰 위험을 가져오는지 알면서도 요구사항을 수시로 변경한다. 때로는 변경하지 않기 위해 처절한 몸부림으로 저항하기도 한다.

요구사항은 왜 변경되는것일까? 그보다 요구사항은 변경 가능한 것일까?

여기서 가장 중요한 것은 소프트웨어가 눈에 보이지 않는 것이다.

만약 우리가 집을 짓는다면 우리는 매순간 우리가 내린 결정이 집을 건축하는 과정에 어떤 영향을 미치는지 즉시 알아낼 수 있다.

부지 선정, 집의 위치, 토지 다지기, 기초 공사, 콘크리트 붓기 등등 매순간 매순간의 작업에 대해 그 작업이 완료된 후 어떤 결과를 가져올 것인지 예측해낼수 있다.

때문에 각각의 시공이 진행될수록 우리가 마음을 바꾸거나 실수를 고치기가 점점 더 어려워진다는 것을 쉽게 깨달을 수 있다.

하지만 이런 건축과 달리 소프트웨어는 눈에 보이는 형체가 없다. 이것이 우리가 소프트웨어 개발 도중 요구사항을 쉽게 바꾸는 계기를 제공하게 된다. 우리는 중간 과정에서 '일의 실체'를 볼 수 없기 때문에 언제나 요구사항을 변경한다. 그리고 그러한 요구사항의 변경은 우리에게 반드시 어려운 시련의 시간을 가져다 준다.

하나 예를 들어보자.

여러분이 정사각형 모양의 방을 만든다고 가정해 보자. 그런데 콘크리트로 벽을 세울 때 실수로 한 대각선의 길이가 다른 대각선 길이보다 길어졌다고 가정해보자. 이것은 인접한 두 변이 모두 길어졌다는 것을 의미한다.

안타깝게도 콘크리트가 완전히 굳은 후에 이 실수를 발견하고 말았다. 이 실수를 고치지 않으면 예정되어 있던 가구나, 벽지, 외장재 등 모든 남아있는 시공 과정에 영향을 미치게 된다.

때문에 이제 실수를 만회하기 우해서는 잘못된 두 변에 모두 콘크리트를 다시 부어야 한다. 그러기 위해서는 잘못 만들어진 벽을 허문 후 새로 작업을 해야한다. 이것은 쉬운 일이 아니다. 비용도 들어간다.

때문에 건축에서는 어떤 일을 시행하기 전에 충분한 검토를 거치고 과정 중간 중간에도 계속해서 정밀한 확인 작업을 거쳐나간다.

반면에 여러분이 보험금 계산 프로그램을 만든다고 가정해보자.

보험회사에는 만 18세 이상의 성인만이 보험에 가입할 수 있다.

그런데 보험 가입 연령이 만 18세라고 들었는데, 시스템을 만들고 나니 실제로는 보험 가입은 만 18세가 아닌 년도 기준 18세라는 것을 알게 되었다. 프로그램의 수정은 생일 기준으로 18세를 계산하던 것에서 년도 기준으로 18세를 바꾸는 것이 될 것이다.

프로그래밍을 정확히 모르는 사람의 관점에서 이러한 작업은 별 것 아닌 것처럼 보인다. 하지만 개발자 관점에서 생각해보면 상황은 매우 복잡하다. 생년월일을 입력받아 계산하던 UI를 년도만 입력받도록 변경해야할 수도 있으며, 생년월일로 나이를 계산하던 함수를 년도만으로 나이를 계산하는 함수로 바꿔야 할 수도 있다.

이 뿐만이 아니다. 이 상황을 변경함으로써 발생하는 요구사항이나 설계문서, 테스트 케이스 등 중산 산출물의 변경도 고려해야한다.

'벽체를 잘못 세운 것'과 '보험금 산정 연령 설정'은 비중이 같은 문제라고 볼 수 있다.

하지만 벽체를 잘못 세운 것은 눈으로 볼 수 있지만 보험금 산정 연령을 잘못 설정한 것은 볼 수 없다.

많은 사람들이 보험금 산정 연령을 수정하는 것을 벽체를 허물고 새로이 벽체를 만드는 것이라고 생각하기보다는 건설 도면을 수정하는 것 정도로 생각한다.

결론적으로, 많은 사람들이 요구상을 급작스럽게 아무때나 바꾸는 경향을 보인다.

돌이켜보면 나 역시 테스트를 수행하면서 개발자에게 요구사항 변경을 그동안 너무 쉽게 얘기했다는 것을 깨달았다.

그렇다면 이러한 요구사항의 변경을 막아낼 수는 없는 것일까?

그것은 사실상 불가능하다.

왜냐하면 요구사항은 언제나 불완전하기 때문이다.

변경사항은 변할 수 밖에 없다.

하지만 만약에 우리가 소프트웨어를 개발하면서 요구사항을 변경하려는 의사결정을 하기 전에 한번 더 신중하게 생각하도록 만들 수 있는 담보성 중간산출물을 제시한다면 요구사항의 변경에 좀 더 신중해지지 않을까?

이러한 담보성 중간산출물을 제공하기 위해서 필요한 것은 개발주기를 짧게 가져가는 것이라고 할 수 있다.

최근에는 나 역시 테스트를 진행하는 분량을 되도록 잘게 나누어서 작게 가져가려고 노력을 한다.

무슨 얘기인고 하니 우리가 나침반도 지도도 없이 사막 한가운데에서 조난을 당한다면 어떻게해야 사막에서 탈출할 수 있을까?

1달? 2달? 짜리 거창한 계획을 통해서 탈출할 수 있을까?

그것보다는 매일 매일 하늘의 별자리를 확인하면서 우리 스스로 이정표를 만들어가면서 조심스럽게 탈출하는 것이 확률이 더 높을 것이다. 그렇지 않다면 분명 우리는 사막에서 길을 잃고 끝내 죽음에 이를 것이다.

예전에 어떤 책에서 읽었던 이야기 중에도 비슷한 이야기가 있었다. 사막 한가운데에 있던 어떤 마을 주민은 대대로 평생토록 한번도 마을 바깥으로 나가본적이 없었다고 한다. 마을 바깥으로 나간 사람들은 실종되거나 다시 마을로 돌아올 수 밖에 없었다고 한다.

그러한 마을에서 처음으로 바깥 세상에 도달한 한 사람이 있었다고 한다. 그 사람은 매일 밤 밤하늘의 별을 보며 자신이 어디로 가야하는지 결정해서 매일 매일 같은 방향으로만 나아갔다고 한다.

너무 완벽한 요구사항, 너무 거대한 요구사항은 우리로 하여금 소프트웨어 개발 과정에서 너무 쉽게 길을 잃어버리도록 한다.

우리에게 필요한 것은 확실한 것이다. 확실한 요구사항이라면 커다란 것보다는 작은것이 훨씬 정확하다.

우리에게 충분히 작고 명확한 요구사항이 필요한 것은 우리가 가야할 길이 그 결과를 알수 없을 정도로 뿌리 깊은 불확실성을 가지고 있기 때문이다.

사막에서 길을 잃어 죽고 싶지 않다면 충분히 작은 요구사항, 작은 계획, 짧은 개발 주기, 그리고 언제나 확인 가능한 중간 산출물이 필요하다.

이것이 애자일이 탄생한 배경이고 폭포수 모델의 약점이기도 하다.

즉, 변경사항이 없도록 강제하기 보다는 변경사항을 수용할 수 있는 방법을 찾는것이 더 나은 방법이라고 할 수 있다.