4. 지속 가능한 소프트웨어

저는 지속 가능한 서비스 개발에 대해 자주 언급했습니다. 지금의 요구사항을 만족시키는 것은 물론 향후 요구사항 변경이 있을 때 빠르고 안정적으로 이를 수용하여 경쟁력을 갖는 서비스를 개발하는 것이 중요하다고 생각하기 때문입니다. 대부분의 경력이 서비스 개발 및 운영이어서 동작하게 만드는 것보다 운영을 하면서 다양한 요구사항을 수용하고, 개선할 수 있는 서비스 개발이 중요하다고 생각하기 때문입니다.

소프트웨어 변경은 본질 자체

1994년, 스탠디시 그룹

소프트웨어에서 항상 사용되는 부분이 7%, 자주 사용되는 부분이 13%라는 점이 인상적입니다. 즉 파레토의 법칙처럼 20%만 항상/자주 사용된다는 것입니다.

요구사항을 작성한 사람은 요구사항이 구현되어 사용할 수 있어야만 자신이 원한 것이 무엇인지 확신할 수 있다

고 합니다. 그래서 일정 준수를 위해 개발 시작 전에 요구사항을 확정하자는 말은 참 이상한 말이 됩니다. 이렇게 개발할 경우 일정 준수는 성공할지 모르지만 80%는 사용되지 않는 코드를 작성할 수 있기 때문입니다(사용도 안 할 코드를 뭐 하러 그리 열심히 작성했을까???).

소프트웨어의 비용

건축은 전체 비용의 90%가 빌드에 소요되고, 10% 정도가 유지보수에 소요된다고 합니다. 하지만 소프트웨어는 전체 비용의 80% 이상이 향후 변화하는 요구사항을 지속적으로 수용하는 유지보수에 소요된다고 합니다.

다른 제조업과 비교했을 때 소프트웨어에서 "품질과 비용"의 관계는 매우 비직관적입니다. 일반적으로 제주업에서는 품질이 좋으면 비용도 많이 듭니다. 스마트폰을 예를 들어보면 좋은 스마트폰은 비쌉니다. 하지만 소프트웨어는 다릅니다. 좋은 설계를 갖는 높은 품질의 소프트웨어는 향후 변경 비용을 낮출 수 있어서 비용 측면에서는 오히려 저렴할 수 있습니다.

이러한 비직관적인 관계 때문에 지속 가능성을 위한 소프트웨어의 품질은 설명하기도 어렵고, 이해하기도 어려운 것 같습니다. 개발자인 우리는 이러한 관계를 경영진이나 타 직군의 협력자들에게 비용, 재무 측면에서 설명하고 소통할 수 있어야 합니다.

“There are known knowns: there are things we know we know. We also know there are known unknowns: that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don’t know.”, Donald Rumsfeld

Unknow Unknows가 판치는 세상에서 초기에 요구사항을 명확히 끌어내고 빠르게 고정하는 것은 불가합니다. 미래를 내다볼 수 있는 마법의 수정자가 있다면 모르지만요...

우리는 예언자가 아니라 변경이 요구될 때 빠르고, 안정적으로 변경할 수 있는 소프트웨어 설계, 개발 역량을 추구해야 합니다.