(플래닝 포커 카드 때문에 구입했던) 스크럼과 XP를 읽고 있다. (김창준님의 추천사 참고). 내적 품질과 외적 품질에 대한 이야기가 나오는데, 지난주까지 했던 아르바이트가 떠올랐다. VBA와 관련된 일이었는데, 그 코드의 내적 품질은 안드로메다였다. 하지만, 고객은 내적 품질이 중요하다는 것을 잘 이해하지 못한다. 이 책에는 내적 품질에 대한 이야기가 나온다.

< 왜 품질은 협상의 대상이 아닌가? >

앞의 삼각형에서 나는 의도적으로 네 번째 변수라 할 수 있는 품질을 포함시키지 않았다.

외적 품질은 시스템을 사용하는 사람들이 인식하는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스는 낮은 외적 품질의 예라고 할 수 있다.

내적 품질은 대개 사용자들에게는 직접 드러나지 않지만 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는 것을 지칭한다. 시스템 설계의 일관성, 테스트 커버리지, 코드의 가독성, 리팩터링 같은 것과 관련이 있다.

일반적으로 내적 품질이 높은 시스템이라 하더라도 외적 품질이 낮을 수 있다. 하지만 내적 품질이 낮은 시스템에서 높은 외적 품질을 기대하기란 힘들다. 부실한 기초 위에 멋진 건물을 짓기란 어려운 법이다.

나는 외적 품질을 범위(scope)의 한 부분이라고 본다. 예를 들자면, 우선은 다소 불편하면서 느린 사용자 인터페이스라 하더라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이, 경우에 따라서는 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있기 때문이다. 나는 이와 같은 트레이드오프를 제품 책임자에게 맡겨둔다. 범위를 결정하는 것이 바로 그의 책임이기 때문이다.

반면, 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야말로 팀이 책임져야 할 사항이며, 이것은 두말할 필요 없이 그냥 협상의 대상이 아니다. 절대로.

자, 그럼 어떤 것이 내적 품질에 관한 문제인지 혹은 외적 품질에 관한 문제인지 어떻게 구분할 수 있을까?

제품 책임자가 이렇게 말한다 치자. “여러분, 좋습니다. 저는 여러분이 스토리 점수를 6점이라고 추정한 것을 존중합니다. 하지만, 제 생각에는 여러분이 마음만 먹는다면 분명히 절반의 시간을 쓰면서 임시방편이라도 해결책을 내놓을 수 있을 것 같은데요.”

아하! 지금 제품 책임자는 내적 품질을 변수로 사용할 생각이다. 내가 그걸 어떻게 알았을까? 그는 지금 범위를 줄이는 ‘비용을 치를’ 의사는 없으면서, 우리에게는 스토리의 추정치를 낮춰 잡으라고 얘기하고 있기 때문이다. ‘임시방편’이라는 말을 들으면 여러분 머리 속에는 경고 장치가 울려야 한다.

그럼 우리가 이것을 허락하지 않는 이유는 무얼까?

개인적인 경험에 비추어봤을 때, 내적 품질을 희생하는 것은 거의 언제나 최악의 발상이었다. 시간을 잠시 버는 것은 단기적, 장기적으로 발생하게 되는 비용에 비하면 보잘것 없는 것이다. 코드 베이스가 오염되는 걸 허락하게 되면 나중에 품질을 되돌려 놓기란 매우 어렵다.

대신에 나는 범위 쪽으로 논의를 전개시킨다. “이 기능을 일찍 마무리하는 것이 중요하다고 하니, 좀 더 빠르게 구현할 수 있도록 범위를 줄이면 어떨까요? 오류 처리를 단순화하고, ‘고급 오류 처리’라는 별개의 스토리를 만들어 나중에 구현하도록 할 수 있겠군요. 혹은 이 스토리 구현에 집중할 수 있도록 다른 스토리의 우선순위를 낮추는 것은 어떤가요?”

제품 책임자가 내적 품질은 협상의 대상이 아니라는 점을 이해하고 나면, 보통은 그 대신에 다른 변수들을 조작하는 데 능숙해진다.

- 스크럼과 XP 中에서…

다시 돌아와서, 대부분의 비 기술자가 그렇듯이, 그 아르바이트의 사장님은 내적 품질의 중요성을 피부로 느끼지는 못하고 있었다. “응. 중요한 것 같긴 한데, 다음에”라는 대답은 대부분의 고객의 답변과 같지 않을까 싶다. 내게 코드 전체를 rewriting할 시간이 있었다면, 당연히, 훨씬 더 적극적으로 설득을 해보았겠지만.

고객들은 그렇다 치고, 정말로 놀라운 것은, “일단 돌아만 가면 되지 뭘”이라고 생각하는 프로그래머들도 굉장히 많다는 사실이다. 무너질 것을 뻔히 알면서 모래 위에 성을 쌓는다. 고객을 설득하는 것은 개발자가 인지한 후에나 가능하다. 제발 좀 인식했으면 좋겠다. 학교 과제처럼, 한번 실행하고 두번 다시 유지보수 하지 않는 소프트웨어가 아니라면, 내적 품질은 논의의 대상이 될 수 없다. 협상의 대상이 아니다. 절대로.

-- 이상한 나라의 종텐.