사례 연구

지금부터 중간 규모 조직과 이 조직의 주력 제품 예로 기술 부채가 조직에 미치는 영향을 이해해 보자. 이 제품은 12년간 꾸준히 시장에서 자리를 지켜 냈으며, 여러 해 동안 동일 제품을 사용하는 충성 고객으로 구성된 틈새 시장이 있다.

시장 압력 때문에 제품을 만든 조직은 제품의 향상된 버전을 개발하기로 결정한다. 조직은 최대한 빨리 제품을 출시하여 경쟁자와 동등한 위치에 서기를 원한다. 조직 성장에서 이 프로젝트가 대단히 중요하다고 판단한 조직은 경험이 많은 소프트웨어 아키텍트 팀을 외부에서 불러와 향상된 소프트웨어 설계를 맡긴다.

아키텍트 팀은 제품을 이해하려고 기존 아키텍처와 설계를 연구하다 소프트웨어를 괴롭히는 심각한 문제가 있음을 발견한다. 가장 먼저 파악한 심각한 문제는 오랫동안 유지보수를 하는 과정에서 발생한 엄청난 기술 부채다. 소프트웨어는 한 덩어리로 뭉친 설계 형태다. 소프트웨어가 클라이언트와 서버라는 두 가지 논리적인 구성 요소를 포함하고 있음에도 (적절한 매개변수를 사용하여) 클라이언트 또는 서버로 동작하게 변경 중인 단일 코드를 기반으로 유지한다. 클라이언트와 서버 사이의 관심사를 제대로 분리하지 않아서 아키텍트들이 소프트웨어 동작 방식을 이해하기가 대단히 어렵다. 이런 상황에서 소프트웨어 변경을 시도할 때 발생하는 불확실성과 위험성을 상상하기는 그리 어렵지 않다.

아키텍트들은 소프트웨어를 확장하여 새로운 기능을 지원하기 전에, 먼저 기술 부채부터 청산할 필요가 있음을 깨닫는다. 따라서 아키텍트들은 몇 가지 코드 분석기를 수행하고, 적절한 척도를 생성한다. 이런 척도를 기반으로 기존 소프트웨어를 리팩토링할 계획을 수립하고 관리층에 보고한다. 하지만 리팩토링 아이디어에 저항하는 세력이 있다. 관리자들은 변경이 미칠 영향에 큰 우려를 표명한다. 그리고 리팩토링이 기존 코드를 망가뜨릴 뿐만 아니라 소프트웨어의 궁극적인 출시에 지연을 초래할까 봐 두려워한다. 관리자들은 개발 팀에 문제를 떠넘긴다. 개발 팀은 기존 코드 기반을 확장하는 데 어려움이 있음을 인식한 듯 보인다. 하지만 놀랍게도 개발 팀은 장수하는 프로젝트에서 품질 문제를 뭔가 자연스러운 것으로 받아들이는 듯한 분위기다. 이 문제를 추가로 조사하려고 할 때 아키텍트들은 개발 팀이 기술 부채 개념과 기술 부채가 소프트웨어에 미치는 영향을 눈치채지 못했음을 발견한다. 실제로 몇몇 개발자는 어떤 리팩토링을 프로젝트에 적용해야 하는지 질문하기도 했다. 개발자들이 기술 부채와 기술 부채의 영향력을 인식했다면, 주기적으로 기술 부채를 감시하고 해소하는 조치를 내렸을 것이다.

관리자들은 리팩토링이 필요하다는 제안에 또 다른 우려를 보인다. 원래 개발자들의 60% 이상이 프로젝트를 그만두어 현재는 새로 고용된 사람들이 이를 대신하고 있음을 알게 된 것이다. 이 때문에 관리자들은 새로운 신입들이 12살 먹은 코드 기반을 건드리는 결정에 결사 반대다. 기존 코드 기반이 지난 10년 동안 성공적으로 동작했으므로, 관리자들은 기존 코드를 재구성하는 과정에 두려움을 느낀다.

따라서 아키텍트들은 개발 팀과 의사소통을 시작하여 기술 부채의 부정적인 영향을 알리기 시작한다. 얼마 지나지 않아서 여러 팀원이 소프트웨어를 괴롭히는 문제의 이면에 숨은 원인을 인식했으며, 소프트웨어를 확장하기 전에 리팩토링해야 할 필수적인 요구가 있음을 확신하게 되었다. 서서히 팀은 리팩토링 찬성파와 반대파로 나뉘기 시작한다. 반대파는 리팩토링 자체를 반대하지는 않지만, 현재 버전의 리팩토링에 초점을 맞추기 원하지 않는다. 그리고 찬성파는 먼저 몇 가지 리팩토링과 구조조정 없이는 향후 개발이 어려우며, 오류를 유발할 것이라고 주장한다.

결국 버전별로 시차를 두어 리팩토링을 시작하기로 결정한다. 현재 버전에서는 시스템의 중요한 부문만 리팩토링하기로 한다. 또 새로운 기능 개발 과정에서 건드릴 필요가 있는 다수의 코드를 구조조정하도록 개발자들을 독려한다. 이론적으로는 훌륭한 전략이며 성공할 것처럼 보인다.

하지만 누적된 기술 부채의 범위는 상당히 저평가되었다. 설계는 결합력이 아주 높다. 구성 요소를 위한 인터페이스는 정의하지 않았다. 구성 요소를 맡은 담당자가 여럿이었고, 관심사도 분리하지 않은 채 남아 있었다. 여러 장소에서 코드는 캡슐화에 구멍이 났다. 거의 모든 리팩토링이 어렵고 오류를 유발하고 좌절감을 주고 있음을 쉽게 상상할 수 있을 것이다. 이런 상황에서 리팩토링은 악몽과도 같다. 팀은 전체 소프트웨어를 처음부터 다시 작성하는 편이 더 나을지도 모른다고 느끼기 시작한다.

마침내 제대로 계획된 전략임에도 제품 출시 과정에서 상당한 지연이 발생했다. 실제로 향후 버전에서 지연을 줄이려고 이번 버전에서는 새로운 기능을 많이 축소했다. 하지만 새로운 기능을 많이 축소했음에도 제품을 시장에 출시한 시기는 원래 계획보다 6개월이나 늦었다! 고객들은 만족스럽지 않았지만, 그 대신 몇 달 안에 확장된 기능 집합을 포함한 신형 버전 출시를 약속받았다. 이런 약속이 가능한 이유는 현재 버전에서 수행한 리팩토링이 향후 버전에서 쉽게 확장할 수 있는 설계로 자리 잡았기 때문이다. 다시 말해, 부채의 일부를 상환했기에(그렇지 않으면 프로젝트는 기술 파산으로 이어질 수 있었다) 향후 제품을 확장할 수 있는 초석을 쌓을 수 있었다.