기술적 부채의 블랙홀 탈출하기

기존 소프트웨어 프로그램에는 기능 개발, 알파, 베타 및 GM(골든 마스터)과 같은 단계별 개발 접근 방식이 있습니다.

각 릴리스는 새로운 기능을 만드는 단계로 시작되며, 이상적인 상황의 경우 마지막 릴리스의 남아 있는 이슈는 해결됩니다. 하지만 솔직히 말해 그런 경우는 거의 발생하지 않습니다. 각 기능이 구현되어 테스트할 준비가 되면 개발 주기는 "알파" 단계에 도달합니다. 충분히 많은 버그가 수정되어 고객 피드백을 받을 수 있는 상태가 되면 베타 단계가 됩니다. 팀은 베타 단계에 도달하는 데 필요한 만큼 충분한 양의 버그를 수정하기 위해 바쁘게 일하지만 새로운 버그가 나타납니다. 버그 하나를 수정하면 두 개가 더 나타나는 두더지 잡기 게임 같은 만성적인 사례입니다. 마지막으로, 열린 버그가 없으면 릴리스는 골든 마스터 마일스톤 단계에 도달합니다. 보통 알려진 이슈를 수정하고 나머지 이슈는 다음 릴리스로 연기하면 "열린 버그 없음"이라는 상태를 달성하게 됩니다.

수정해야 할 버그를 계속 미루는 것은 소프트웨어를 만드는 데 위험한 방법입니다. 버그의 개수가 증가함에 따라, 버그를 해결하는 것은 점점 더 어려워져 기술적 부채의 악순환에 빠지게 됩니다. 설상가상으로, 버그를 중심으로 코딩하면 개발 속도가 느려지기 때문에 일정에 맞추지 못하게 됩니다. 한편, 고객은 수정되지 않은 결함으로 인해 상당한 피해를 보며 실제로 그 중 일부 고객은 떠날 것입니다.

어딘가에 더 좋은 방법이 있을 겁니다.

애자일은 팀이 릴리스를 거듭하면서도 일관적인 수준의 품질을 유지할 수 있도록, 반복적인 개발 접근 방식에 품질을 적용합니다. 기능이 기준을 충족하지 않으면 제공되지 않습니다. 믿기 어려우십니까? 한 가지 비결은 "완료"의 의미를 정의하거나 다시 정의하는 것입니다.

기존 팀의 경우, "완료"란 QA를 시작하기에 충분하다는 의미였습니다. 이 정의의 문제점은 릴리스 주기 초반에 버그가 발생하고 계속하여 발생한다는 것입니다. 따라서 QA 팀이 개입할 때쯤에는 제품에 여러 결함이 쌓여 있습니다. 그러나 애자일 팀에서 정의하는 "완료"란 릴리스 준비가 된 상태입니다. 즉, 개발자는 현재 항목이 실제로 고객의 손에 들어갈 때까지 다음 스토리 또는 기능으로 넘어가지 않습니다. 개발자는 속도를 높이기 위해 기능 브랜치 워크플로, 자동화된 테스트 및 개발 주기 전반에 걸친 지속적 통합과 같은 기술을 사용합니다.

코드 베이스의 메인 브랜치는 항상 제공할 준비가 되어 있어야 합니다. 이것이 최우선 순위입니다. 따라서 새로운 기능은 기능 자체에 대한 코드 및 코드에 대한 자동화된 테스트가 포함된 작업 브랜치에서 시작됩니다. 기능이 다 만들어지고 자동화된 테스트가 통과하면 브랜치를 메인에 병합할 수 있습니다. 품질 기준은 항상 높게 고정되어 있으므로 기술 부채를 제어할 수 있습니다.

많은 조직에서 이는 문화적으로 큰 변화입니다. 애자일을 사용하면 조직은 일정에서 벗어나 높은 품질의 입증 가능한 소프트웨어에 중점을 두게 됩니다. 제품 소유자는 품질을 저해하는 대신 릴리스의 범위를 좁혀, 팀이 가장 가치 있는 작업에 먼저 집중하도록 권한이 부여됩니다.

왜냐하면 버그가 오래될수록 수정하기 더 어려워지기 때문입니다.

레거시 코드 작업을 하는 경우 어느 정도의 기술적 부채를 물려받았을 가능성이 있습니다. 다음과 같은 주제는 기존의 기술적 부채를 관리하고 팀이 새로운 기능 개발과 같은 재미있는 작업에 집중하도록 도와줍니다.

개발자와 제품 관리자는 어떤 것이 기술적 부채로 간주되는지에 대해 동의하지 않을 때도 있습니다. 그래서 여기에서 확실히 정리해 드리겠습니다.

여기에는 제공 기한을 맞추기 위한 모든 기술적 지름길도 포함됩니다.

개발 팀에서는 아키텍처 작업을 기술적 부채로 간주하려는 유혹에 빠질 수 있습니다. 변경 사항의 특성(예: 지름길을 "실제" 솔루션으로 대체하는 것 아니면 모놀리식 코드 베이스를 마이크로서비스로 분할하는 것)에 따라 기술적 부채가 맞을 수도 있고 아닐 수도 있습니다. 반면, 제품 관리 팀에서는 버그나 느린 성능을 해결하는 것보다 새로운 기능을 만드는 것이 더 시급하다고 생각하는 경우가 많습니다. 어느 한 쪽이 상대방의 의견에 지치게 되도록 하지 않으려면 기술적 부채, 코드 베이스의 이상적인 아키텍처 변경 사항 및 새로운 기능 간의 차이점을 모두가 이해해야 합니다. 개발 팀과 제품 관리 팀 간의 명확한 커뮤니케이션은 백로그 우선 순위를 정하고 코드 베이스를 발전시키는 데 중요합니다.

원래의 사용자 스토리에 별도의 테스트 작업을 추가하여 "완료"의 정의를 바꾸려는 마음을 떨쳐내세요. 별도의 테스트 작업은 연기되기 너무 쉽고 기술적 부채만 유발합니다. 테스트가 원래 스토리 또는 버그 수정의 일부로서 이루어지지 않으면 원래 스토리 또는 버그 수정은 완료된 것이 아닙니다. 프로그램에서 "완료"의 정의를 엄격하게 유지하고 완전히 자동화된 테스트가 포함되도록 하세요. 수동 테스트와 버그가 많은 코드 베이스는 팀의 애질리티를 떨어뜨리는 가장 큰 요소입니다.

누군가 소프트웨어에서 버그를 발견하면 시간을 들여 이를 입증하는 자동화된 테스트를 추가하세요. 버그가 수정되면 테스트를 다시 실행하여 통과하는지 확인하세요. 이는 애자일 개발에서 품질을 유지하기 위한 유서 깊은 방법론인 테스트 중심 개발의 핵심 요소입니다.

기술적 부채를 관리하는 방법에 대한 팀의 철학(그리고 팀의 이해 관계자의 철학)을 바꾸기란 쉽지 않습니다. 비즈니스 요구 사항으로 인해 시장에 더 빨리 출시하려고 개발 시간을 단축하는 경우가 있습니다. 이를 염두에 두고, 기술적 부채를 관리하는 데 대한 몇 가지 작업 항목을 요약해 보겠습니다.

• 제품 소유자에게 기술적 부채의 실제 비용에 대한 정보를 제공하세요. 기존의 기술적 부채를 해결해야 하는 향후 스토리에 대해 스토리 포인트 값이 정확한지 확인하세요.
• 아키텍처를 모듈화하고 애플리케이션의 새 컴포넌트 또는 라이브러리의 기술적 부채에 대해 확고한 입장을 취하세요. 팀과 비즈니스가 이러한 새로운 컴포넌트의 애질리티를 깨닫게 되면 자연스레 이러한 관행을 코드의 다른 부분으로도 확장하고 싶어 할 것입니다.
• 자동화된 테스트를 작성하세요! 버그를 방지는 데 자동화된 테스트와 지속적 통합보다 효과적인 것은 없습니다. 새 버그가 발견되면 새 테스트를 작성하여 재현한 다음 이슈를 수정하세요. 이 버그가 다시 나타나면 자동화된 테스트가 고객보다 먼저 버그를 발견할 것입니다.

기술적 부채는 모든 소프트웨어 팀의 현실이라는 것을 기억하세요. 기술적 부채를 완전히 피할 수 있는 소프트웨어 팀은 없으며, 통제 불능 상태가 되지 않도록 하는 것이 중요합니다.