고품질의 소프트웨어에 비용을 들일 가치가 있을까?

고품질의 소프트웨어에 비용을 들일 가치가 있을까?

 

2019.5.29 Martin Fowler

 

소프트웨어 개발 프로젝트에서 소프트웨어 품질을 개선하는데 시간을 쓰는 것과 가치 있는 기능을 출시하는 데 집중하는 것 사이의 일반적인 논쟁이 존재한다. 대체로 기능을 전달해야 하는 압박이 논쟁을 지배하기 때문에 많은 개발자는 아키텍쳐와 코드 품질에 관해 작업할 시간이 없다고 불평한다.

 

베터리지의 헤드라인 법칙은 물음표로 끝나는 헤드라인이나 제목을 가진 기사는 "아니오"로 요약할 수 있다는 격언이다. 나를 아는 사람들은 그러한 법칙을 뒤엎으려는 나의 열망을 의심하지 않을 것이다. 하지만 이 기고에서는 그보다 더 나간다. 즉 질문 자체를 뒤집는다. 이 질문은 품질과 비용 사이의 일반적인 트레이드오프를 가정한다. 나는 이 기고문에서 이런 트레이드오프가 소프트웨어에 적용되지 않으며 고품질의 소프트웨어가 실제로는 만드는데 더 저렴하다는 것을 설명할 생각이다.

 

참고: Betteridge's Law of Headlines 는 물음표로 끝나는 헤드라인의 경우, 답은 항상 No 이다 라는 법칙. 보통 내용이 조금 부족한데, 그걸 보완하고 싶을 때 기자들이 사람들의 시선을 끌기 위해서 이런 헤드라인을 쓰기 때문에 생긴 법칙.

 

비록 대부분의 내 글은 전문적인 소프트웨어 개발자를 대상으로 하지만 이 기고문은 소프트웨어 개발의 역학에 관한 지식이 전혀 없다고 가정할 예정이다. 소프트웨어 개발팀의 고객 역할을 하는 비즈니스 리더같이 소프트웨어 공수에 고민하는 모든 사람에게 이 기고가 가치 있기를 바란다.

 

우리는 품질과 비용 사이의 트레이드오프에 익숙하다

 

시작 지점에서 언급했지만 우리는 모두 품질과 비용 사이의 트레이드오프에 익숙하다. 내가 스마트 폰을 바꾸려고 한다면 나는 더 빠른 프로세서, 더 나은 화면 그리고 더 많은 메모리를 가진 비싼 모델을 선택할 수 있다. 또는 비용을 줄이기 위해 이런 특성 중 일부를 포기할 수도 있다. 이건 절대적인 규칙이 아니다. 가끔 우리는 고품질의 물건을 더 저렴하게 흥정할 수도 있다. 어떤 사람들은 특정 화면이 다른 화면보다 어떻게 뛰어난지 실제로 느끼지 못할 정도로 품질에 대해 각각 다른 가치를 부여한다. 하지만 대체로 고품질에  비용이 더 든다는 가정은 대부분의 경우 사실이다.

 

소프트웨어 품질은 수많은 것을 의미한다

 

내가 소프트웨어의 품질에 관해 이야기하고자 한다면 그게 무엇인지 설명해야 한다. 여기서 소프트웨어 품질에 수많은 것이 포함된다는 첫 번째 복잡성이 존재한다. 사용자 인터페이스를 생각해 보자. 그 인터페이스가 내게 필요한 과업으로 나를 쉽게 이끄는가? 그 인터페이스가 나를 더 효율적으로 만들어 주고 불만을 제거해 주는가? 소프트웨어의 신뢰성을 생각해 보자. 거기에 에러나 불만의 원인이 되는 결함이 존재하는 걸까? 소프트웨어의 또 다른 측면은 아키텍쳐이다. 소스 코드가 명확한 모듈로 구분되어 있어 프로그래머가 쉽게 찾고 이번 주에 작업할 코드 영역이 어디인지 이해하게 할 수 있나?

 

이와 같은 품질의 세 가지 예시가 전체 목록인 것도 아니다. 하지만 중요한 핵심을 나타내기에는 충분하다. 내가 소프트웨어의 고객이나 사용자라면 우리가 품질에 관해 논의한 것들에 관해 감사해하지 않을 것이다. 만일 사용자 인터페이스가 훌륭하다면 사용자는 말을 할 것이다. 만일 그 소프트웨어가 일을 하는 데 있어 자기 직원의 효율성을 올려줬다면 임원이 말을 할 것이다. 특히 사용자와 고객은 결함이 데이터를 망가뜨리거나 잠깐 시스템을 작동 불능 상태로 만들면 결함을 인지할 것이다.

 

따라서 나는 소프트웨어 품질 특성을 외부적인 것과 (UI 와 결함 같은) 내부적인 것으로 (아키텍쳐) 나눈다. 이런 구분은 사용자와 고객이 소프트웨어 제품이 높은 외부 품질을 지니고 있다고 느낄 수 있지만 내부적인 품질이 높은지 낮은지 차이를 말할 수는 없다는 차이를 가지고 있다.

 

언뜻 보기에 고객에게 내부 품질은 중요하지 않다

 

내부 품질이 고객이나 사용자가 볼 수 있는 것이 아니기 때문에 그게 과연 중요할까? 레베카와 내가 비행기 연착을 추적하고 예측하는 애플리케이션을 작성한다고 생각해 보자. 양쪽 애플리케이션이 동일하게 핵심 기능을 수행하고, 양쪽이 동일하게 우아한 사용자 인터페이스를 가지고 있고 결함이 거의 없다고 가정하자. 유일한 차이점은 그녀의 내부 소스 코드가 깔끔하게 정리되어 있지만 내 것은 엉망이다. 또 다른 차이가 있는데 나는 내 애플리케이션을 6달러에 판매하고 그녀는 그것을 10달러에 판매한다.

 

고객이 이런 소스 코드를 절대 볼 수 없고 그 앱의 실행에 영향을 주지 않기 때문에 레베카의 소프트웨어를 추가로 4달러를 지불하고 구매해야 할까? 이것을 일반적으로 말하면 높은 내부 품질에 더 큰 비용을 지불할 가치가 없다는 의미이다.

 

다시 말해서 이것은 내부 품질과 비용을 거래하는 건 합리적이지 않지만 외부 품질과 비용을 거래하는 것은 합리적임을 나타낸다. 사용자는 사용자 인터페이스가 추가 비용을 내기에 충분히 가치가 있는지 평가할 수 있기 때문에 더 나은 사용자 인터페이스를 얻기 위해 비용을 지불할지 말지 판단할 수 있다. 하지만 사용자는 소프트웨어의 내부 모듈 구조를 확인할 수 없고 더 나은지도 판단할 수 없다. 아무 효과도 없는 무언가에 비용을 더 지불할 필요가 있을까? 이것이 그런 경우이기 때문에 소프트웨어 개발자가 작업 결과물의 내부 품질을 개선하는데 시간과 공수를 투입해야 할 필요가 있을까?

 

내부 품질은 소프트웨어 개선을 쉽게 한다

 

그렇다면 소프트웨어 개발자가 내부 품질에 대해 이슈를 제기하는 이유는 무엇일까? 프로그래머들은 자신의 시간 대부분을 코드를 수정하는 데 쓴다. 심지어 신규 시스템에서도 대부분의 프로그래밍이 기존 코드 베이스의 맥락에서 이루어진다. 내가 소프트웨어에 신규 기능을 추가하려고 할 때 나의 첫 번째 작업은 이 기능이 기존 애플리케이션의 흐름에 어떻게 잘 녹아들지 확인하는 것이다. 그러고 나서 내가 넣을 새로운 기능이 자연스럽게 녹아들도록 흐름을 변경한다. 가끔은 이 애플리케이션에 이미 있는 데이터를 사용하기도 한다. 따라서 나는 그 데이터가 무엇을 나타내는지, 그 데이터 주변과 어떻게 연결되어 있는지, 내가 추가할 기능을 위해 어떤 데이터가 필요한지 이해해야 한다.

 

이 모든 것은 기존 코드를 이해하고 있는 나에 대한 이야기이다. 하지만 소프트웨어는 이해하기 어렵게 되기가 너무나도 쉽다. 로직은 꼬이고 데이터는 추적하기 어렵고, 토니는 어떤 것을 지칭하는 이름을 6개월 전에는 이해했을 것이다. 하지만 그가 회사를 떠난 이유만큼이나 내게는 미스테리하다. 이 모든 것이 개발자가 크루프트라고 (현재 코드와 이상적인 코드 사이의 차이) 부르는 것을 만들어 낸다.

 

내부 품질의 주요 기능 중 하나는 내가 그 애플리케이션이 어떻게 동작하는지 알기 쉽게 해주는 것이다. 따라서 나는 어떻게 하면 기능을 추가할지 알 수 있다. 만일 그 소프트웨어가 개별 모듈로 잘 나뉘어 있다면 500,000 라인의 코드를 모두 읽을 필요가 없고 몇 개의 모듈에서 수백 줄의 코드를 빠르게 찾을 수 있다. 만일 내가 명확한 이름 짓기에 공수를 투입했다면 세부 사항에 어려워하지 않으면서 다양한 영역의 코드가 무엇을 하는지 빠르게 이해할 수 있다. 만일 데이터가 기본 비즈니스의 언어와 구조를 잘 따른다면 고객 서비스 담당자로부터 받는 요청과 데이터가 어떻게 관련되어 있는지 쉽게 이해할 수 있다.  크루프트는 내가 어떻게 변경할지 이해하는 데 걸리는 시간을 늘리고 또한 실수할 기회를 증가시킨다. 실수를 발견하게 되면 그 결함이 무엇인지 어떻게 고쳐야 할지 이해할 필요가 있기 때문에 더 많은 시간을 낭비한다. 만일 내가 결함을 찾지 못했다면 결함을 생산하게 되고 이후에 수정하는 데 더 많은 시간을 소비한다.

 

내가 만든 변경 사항은 미래까지 영향을 끼친다. 나는 이런 기능을 빨리 집어넣는 방법을 알게 될 수도 있다. 하지만 이것은 혼란을 추가해 프로그램의 모듈식 구조에 위배되는 방법이다. 만일 내가 그런 경로를 따른다면 오늘날에는 더 빠르게 할 수 있을 것이다. 그러나 몇 주나 몇 달 이후 미래에 이 코드를 다룰 누군가의 속도를 떨어뜨린다. 팀의 구성원 중 한 명이 같은 결정을 내리면 애플리케이션을 쉽게 수정하는 방법이 수 주일의 공수를 유발하는 지점까지 빠르게 크루프트를 누적시킨다.

 

고객은 새로운 기능이 빠르게 들어가는 걸 신경쓴다

 

우리는 여기서 내부 품질이 왜 사용자와 고객에게 중요한지에 대한 단서를 찾을 수 있다. 내부 품질이 훌륭하다면 신규 기능 추가가 쉬워지고 따라서 더 빠르고 값싸게 가능하다. 레베카와 나는 지금까지 동일한 애플리케이션을 가지고 있을 것이다. 하지만 몇 달 후에는 레베카의 높은 내부 품질은 매주 그녀가 신규 기능을 추가할 수 있게 해주겠지만 반대로 나는 단 하나의 신규 기능을 내놓기 위해 크루프트를 쪼개려고 노력하다가 막힐 것이다. 나는 레베카의 속도를 이길 수 없으며 곧 그녀의 소프트웨어는 내 것보다 기능이 더 풍부해진다. 결국 내 모든 고객은 나의 앱을 삭제하고 그녀가 자신의 앱 가격을 올릴지라도 레베카의 앱을 선택한다.

 

 

크루프트에 관한 일반적인 비유는 기술 부채이다. 기능 추가에 추가 비용이 드는 것은 이자를 지불하는 것과 같다. 크루프트를 정리하는 것은 원금을 갚는 것과 같다. 이런 비유가 도움이 되기도 하지만 많은 이들은 실제보다 크루프트를 쉽게 측정하고 통제할 수 있다고 믿기도 한다.

 

내부 품질의 영향성을 시각화하기

 

내부 품질의 근본적인 역할은 미래의 변경 사항에 드는 비용을 낮추는 것이다. 하지만 좋은 소프트웨어를 작성하기 위해서는 단기적으로는 약간의 비용을 부과하는 추가 공수가 필요하다.

 

이것을 시각화하는 방법은 소프트웨어의 누적 기능 대비 생산 시간 (과 비용)의 점을 찍은 다음의 의사 그래프를 사용하는 것이다. 대부분의 소프트웨어 공수에서 나타나는 곡선은 이와 유사한 모양을 보일 것이다.

 

 

(대부분의 소프트웨어 시스템에서 시간이 지날수록 신규 기능을 추가하기 어려워진다. 이런 사실은 신규 기능이 나타내는데 시간이 더 걸리고 비용이 증가함을 의미한다.)

 

이것은 낮은 내부 품질로 인해 발생하는 상황이다. 초기에는 진척이 빨라지다가 시간이 지나며 신규 기능을 추가하기 어려워진다. 심지어 사소한 변경이 발생해도 프로그래머는 이해하기 어려운 상당한 영역의 코드를 이해해야 한다. 그들이 변경을 마쳤을 때도 예상치 못한 고장이 발생하고 장기간의 테스트 시간을 요구하며 수정이 필요한 결함이 발생한다.

 

높은 수준의 내부 품질에 집중하는 것은 생산성 저하를 줄이는 일이다. 실제로 몇몇 제품은 이전 작업 결과물을 활용해 신규 기능을 쉽게 만들어 낼 수 있기 때문에 개발자의 속도가 증가하는 다른 효과도 나타난다. 이런 행복한 상황은 대단히 희귀한 경우이다. 왜냐하면 그러한 일이 가능하기 위해서는 능력 있고 숙련된 팀이 필요하기 때문이다. 하지만 가끔은 볼 수 있긴 하다.

 

 

(높은 내부 품질을 가진 소프트웨어는 짧은 초기 지연을 겪는다.)

(하지만 나중에 더 빠르고 (값싸게) 소프트웨어를 전달한다.)

 

여기서 애매한 부분은 낮은 내부 품질이 높은 내부 품질의 경우보다 생산성이 더 높은 지점이 있다는 것이다. 이런 기간 동안 품질과 비용 사이의 일종의 트레이드오프가 존재한다. 물론 질문은 두 선이 교차하기 전에 이 기간이 얼마나 오래 지속될 것인가 하는 점이다.

 

이 시점에서 우리는 왜 이것이 의사 그래프(pseudo-graph)인지를 따져봐야 한다. 소프트웨어 팀이 내놓는 기능은 측정할 수단이 존재하지 않는다. 이렇게 결과물과 생산성을 따져 볼 방법이 없기 때문에 낮은 내부 품질의 결과의 (측정도 하기 어려운) 고정적인 숫자를 넣는 게 불가능하다. 결과물을 측정할 방법이 없다는 것은 전문적인 직업 사이에 매우 흔하다. 변호사나 의사의 생산성을 측정할 방법이 있는가?

 

 

내가 선이 교차하는 지점을 평가하는 방법은 내가 아는 숙련된 개발자들의 의견을 조사하는 것이다. 그리고 그들의 대답은 많은 이들을 놀라게 한다. 개발자들은 나쁜 품질의 코드가 몇 주 안에 자신들의 작업 속도를 현저하게 느려지게 한다는 걸 발견한다. 따라서 품질과 비용 사이에 적용되는 트레이드오프를 고집할 필요가 없다. 심지어 훌륭한 소프트웨어 관례에 주의만 해도 소프트웨어 공수 상의 약간의 이득을 볼 수 있다. 확실히 나는 경험을 통해 그것을 증명할 수 있다.

 

최고의 팀 조차도 크루프트를 만들어 낸다

 

많은 비개발자들은 개발팀이 부주의하고 실수를 저지르면 크루프트 같은 것이 발생한다고 생각한다. 하지만 최상의 팀 조차도 작업 중에 일부 크루프트를 만들 수 밖에 없다.

 

최고의 기술 리더 중 한 명과 이야기하던 일화를 가지고 이 지점을 설명하겠다. 그는 안팎으로 놀라운 성공을 이루었다고 생각되는 프로젝트를 막 마친 상태였다. 고객은 인도된 시스템의 기능성과 구축에 드는 시간과 비용 모두에 대해서 만족해했다.  우리 측의 인력은 그 프로젝트에서 일한 경험에 대해 긍정적이었다. 하지만 우리 기술 리더는 전체적으로 만족스러웠지만 그 시스템의 아키텍쳐가 그리 좋지 못했다고 고백했다. 나는 "어떻게 그런 일이 가능한가요? 당신의 최고의 아키텍트 중 한 명이 아닙니까?"라고 반응했다. 다음과 같은 그의 대답은 경험 많은 소프트웨어 아키텍트라면 누구나 친숙할 것이다. "우리는 훌륭한 결정을 내리긴 했어요. 하지만 인제야 그걸 어떻게 만들었어야 했는지 이해하게 되었네요."

 

소프트웨어 산업의 많은 사람은 소프트웨어 제작을 성당이나 고층 건물을 짓는 것에 비유한다. 그렇다면 왜 우리는 시니어 프로그래머에게 "아키텍트"라는 용어를 사용할까? 소프트웨어 제작은 물리적인 세상에는 알려지지 않은 불확실성의 세상에 존재하기 때문이다. 소프트웨어의 고객은 제품이 어떤 기능을 가져야 하는지에 대해 대략적으로만 파악하고 있으며 특히 소프트웨어의 초기 버전이 사용자에게 공개되면서 소프트웨어가 구축되면 약간 더 알게 된다. 소프트웨어 개발의 제작 요소인 언어, 라이브러리, 플랫폼은 매년 크게 바뀐다. 물리적인 세상에서 이와 유사한 상황은 매년 콘크리트의 기본 속성이 바뀌면서 그 건물의 절반이 이미 완성되어 있고 사람이 점유하고 있는 상황에서 사용자가 새로운 층을 추가하거나 층별 계획을 바꾸는 것에 해당한다.

 

이런 수준의 변화를 고려하면 소프트웨어 프로젝트는 항상 새로운 것을 만들어 낸다. 우리는 이전에 해결된 문제를 잘 이해한 상태로 작업을 하게 되는 상황을 거의 만나지 못한다. 당연하게도 우리는 솔루션을 만들면서 문제에 대해 잘 알게 된다. 따라서 나는 팀이 소프트웨어를 만들고 나서 또는 만드는 데 1년을 소비한 뒤에야 그 소프트웨어가 어떤 아키텍쳐를 가져야 하는지에 대해 최고로 잘 이해한다고 말하는 걸 자주 듣는다. 최고의 팀이라 해도 소프트웨어를 만드는데 크루프트를 만들어 낼 것이다.

 

차이점은 최고의 팀은 약간의 크루푸트를 만들어 내고 기능을 계속 빠르게 추가할 수 있도록 자신들이 만든 크루프트를 제거한다는 점이다. 그들은 문제를 빠르게 드러내고 버그 제거에 시간을 적게 쓰도록 자동화 테스트를 만드는 데 시간을 소비한다. 그들은 방해가 될 만큼 크루프트가 쌓이기 전에 제거하기 위해서 자주 리팩토링을 시행한다. 지속적인 통합은 팀원들이 서로 다른 의도에서 작업하기 때문에 만들어지는 크루프트를 최소화한다. 이에 대한 일반적인 비유는 부엌에서 작업 공간과 도구를 청소하는 것이다. 당신이 요리할 때 더러워지지 않을 수는 없다. 그러나 빠르게 청소하지 않으면 얼룩이 말라서 제거하기가 더 어려워진다. 또한 그 더러운 것들은 다음번 식사를 요리하는데 방해가 될 것이다.

 

고품질의 소프트웨어는 생산에 비용이 적게 든다

 

요약

 

• 내부 품질을 등한시하면 크루프트가 빠르게 쌓이게 된다
• 이러한 크루프트는 기능 개발을 지연시킨다
• 위대한 팀조차 크루프트를 만들어 낸다. 하지만 내부 품질을 높게 유지하면서 통제 가능한 상태를 유지한다
• 높은 내부 품질은 크루프트를 최소화시켜 팀이 적은 공수와 시간, 비용으로 기능을 추가할 수 있다

 

불행히도 소프트웨어 개발자는 대체로 이런 상황을 잘 설명하지 못한다. 나는 "그들은 (관리자) 시간이 오래 걸린다는 이유로 우리가 품질 좋은 코드를 작성하는 걸 허락하지 않아요"라고 말하는 개발팀과 수없이 많이 이야기했었다. 개발자에게는 적절한 전문성이 필요하다고 인정되는 경우에만 품질에 대한 관심이 허용된다. 하지만 이러한 도덕적 논의는 이러한 품질에 비용이 수반된다는 점을 암시하며 이 경우 그들의 주장이 무색하게 된다. 짜증 나는 점은 크루프트 코드로 이어지는 결과가 개발자의 삶을 더 힘들게 하고 고객에게 비용을 유발한다는 점이다. 나는 내부 품질에 관해 생각할 때 경제적인 논쟁으로만 접근해야 한다고 강조한다. 좋은 코드를 작성하는 것에 드는 시간이 실제로는 비용 감소를 의미하기 때문에 높은 내부 품질은 미래의 기능을 구현하는 비용을 감소시킨다.

 

이것이 이 기고문의 제목에 있는 질문이 왜 논점을 벗어나는지에 대한 이유이다. 높은 내부 품질을 가진 소프트웨어의 "비용"은 부정적이다. 우리 인생에서 내리는 결정 중 대부분에 쓰이는 것중 하나인 비용과 품질 사이의 일반적인 트레이드오프를 소프트웨어 내부 품질에 적용하는 건 맞지 않는다. (신중하게 작성된 사용자 경험 같은 외부 품질에는 적용된다.) 내부 품질과 비용 간의 관계는 특이하고 직관에 반하는 관계이기 때문에 대체로 받아들이기 어렵다. 하지만 소프트웨어를 최대의 효율을 가지고 개발하려면 이를 이해하는 게 중요하다.

 

EOD.