2. 개선할 부분이 있는데 어떻게 할지 어렵네요

iOS를 기반으로 사진을 편집하는 기능을 포함하는 앱을 개발하는 D의 사례를 살펴 보자. 이 분은 본인 포함 3명이 개발을 하는 팀인데, 스크럼기반으로 스프린트를 운영하면서 요구 사항들을 지속적으로 앱에 적용하고 있었다. 이미 리팩토링을 통해서 구조를 개선을 하였지만, 여전히 새로운 요구 사항에 대한 중복 코드가 늘고 유연하게 대처 안되고 비즈니스 로직 분리하여 추상화 중복 코드 제거하고 싶어 하였다. 궁극적으로는 시장 릴리즈 이후 품질 이슈나 QA 중 예상치 못한 이슈를 최소화 하시고 싶어했다.

원 포인트 세션 중에 문제를 구체화 하고 날카롭게 하는 것이 필요해 보였다. 이야기 할 수록 이상했던 부분은 어떻게 해야 할지 다 알고 계신 것이 보였다. 문제 중 하나는 Undo/Redo하면서 중복 호출되는 코드의 상세 사항으로 들어 갈 수록 이 부분을 리팩터링하면서 효율화 하고 싶다는 것을 알 수 있었다. 즉, 해야 할일에 대해서는 이미 알고 있어 보였다. 즉, 관련 부분을 추상화하고, 중복 코드도 제거하여 향후 코드 파악이쉽고, 추가 요구사항에 대응이 용이하게 하는 것이다. 하지만, "실행"하는 것이 문제였다. 여러 이야기가 있었지만 본인 포함 3명의 개발자로 신규 요구 사항을 스프린트 내에서 소화하고 이러한 부분을 함께 진행하시는 것에 부담이라는 것이다. 이러한 상황이라면 어떻게 할 수 있을까?

우리는 "작게 해볼 수 있는 것"을 찾아 보게 되었다. 작게 나누어 해볼 수 있는 방법에 대해 이야기 나누었다. 그러면서도, 제품으로 적용되어 진행 될 수 있도록 하는 것이 목표였다. 이렇게 하기 위해서 중복되더라도 작게 개선해 가는 방법에 대해서 상세하게 이야기를 나눴다. 개선해야 하는 객체들이 여러가지가 있었는데, 변경하는 도중에는 개선한 것과 개선하지 않은 객체들이 중복해서 존재하지만 개선이 되어 가는 방법에 대해서 이야기 나누었다. 이렇게 하기 위해서 이 작게 나뉜 리팩터링 작업을 스크럼의 백로그(Backlog)로 만드는 방법에 대해서 이야기 나누었다. 그러기 위해서, 이해 관계자(Stakeholder)와 이를 공유하는 것도 이야기 나누었다. 이러한 논의를 통해 D는 좀 더 자신감을 얻었다. 

상품화 된 소프트웨어 제품을 개선하는 것에 대해서 "달려가는 기차의 바퀴를 바꾸는 일"이라는 비유를 들은 적이 있다. 상황의 어려움도 있지만, 문제와 관련된 다양한 리스크가 많기 때문 일 것이다. 이를 위해서는 우리가 리스크에 대한 걱정을 줄이는 것이 중요하다. 이 부분을 통해 자신감이 높아지는데 도움이 되기 때문이다. 또한, 이렇게 우리가 걱정되는 것이 있다면 작게 시도해 보고 실패하고 계속해서 시도하면서 우리가 개선하는 것에 대해서 학습하는 것이 효과적이다. 수백kg에 해당하는 펀치를 한번에 받아 내는 것 보다는 수백g의 작은 펀치를 여러 번 나눠 맞는 것이 끝까지 살아 남는데는 더 나은 선택이기 때문이다.