지금 얼마의 빚이 있나요?
"지금 돌아가게는 만들 수 있는데 나중에 문제 될 수도 있는데 괜찮아요?"
"지금은 괜찮은데 사이드 임팩트가 얼마나 있을지 잘 모르겠네요"
개발자의 입에서 위에 두 문장이 나왔다면
미래에 일어날 기술 부채를 알고 일을 진행하겠다는 말일 확률이 높다.
개발자가 생각하는 기술의 부채, PM이 관리하는 제품의 부채를 이해하고 관리하는 것도
좋은 제품을 만드는 것에 중요한 요소라고 생각한다.
기술의 부채? 제품의 부채?
기술 부채는 기능을 빠르게 배포 후 개선을 선택하거나 비즈니스를 위한 단기 목표 달성을 할 때 코드나 구조적 품질을 떨어뜨릴 때 발생하는 문제를 말한다.
더 풀어서 말하면.
지금은 맞을 수도 있지만, 미래에는 틀릴 수도 있고 나중에는 더 고치기 힘들어질 수도 있다.
이번엔 조금 더 개발자의 언어로 말하면.
코드가 엉켜있어 미래에 기능을 확장하거나 구조적인 한계로 부채를 해결하지 않고 일을 계속 진행한다면, 기능이 덕지덕지 붙어 시스템 안정성을 해치고 최악의 경우 그 기능을 만든 사람만 이 코드를 건들 수 있는 상황까지 갈 수도 있다.
제품의 부채도 비슷하다.
개발자는 코드로, PM은 제품 관리자로써 기능을 빠르게 배포하기 위해 포기했던 사용자의 UX와
비즈니스적으로 필요해서 기능을 만들었지만 그게 오히려 일반적인 제품 확장에 걸림돌이 되고 있는 상황 등을 제품의 부채라고 한다.
PM의 역할
스프린트 내에서 개발자가 지불하는 기술 부채를 이해하고 문제가 뭔지 정확하게 알고 있어야 한다.
그리고 개발 파트 별로 쌓여 있는 기술 부채와 제품 부채가 무엇인지 파악하는 것도 중요하다.
당연하지만 모든 부채를 한 번에 해결하기는 어렵다.
따라서, 우선순위를 설정해 가장 큰 영향을 주는 부채, 또는 부채를 해결했을 때 가장 빠르게 제품팀이 학습할 수 있는 순위 대로 차례대로 해결하는 게 중요하다.
그리고 이런 부채를 해결할 땐 디자인 스프린트를 진행하며 서로의 문제를 논의하고 해결 방안을 찾는 과정에서 개발 단계의 리스크와 비즈니스 목표 간의 균형을 맞출 수 있어 자주 이용하는 방법이다.
개발 부채와 제품의 부채를 PM은 관리해야 하며,
그 부채를 정확하게 파악하고 부채가 너무 커지지 않도록 백로그나 로드맵으로 우선순위를 설정해야 한다.
부채 관리는 일회성 작업이 아니라 지속적으로 들여다봐야 하는 일이다.
개발자들이 부채를 편하게 말할 수 있도록 끌어내야 하고, 투명한 회고를 통해 새로운 부채가 발생하는 원인을 정확하게 파악하고 기존 부채 해결의 진행 상황을 팀과 파트에 공유해야 한다.
개발자가
"지금 돌아가게는 만들 수 있는데 나중에 문제 될 수도 있는데 괜찮아요?"라고 한다면
"지금 빚을 좀 내더라도 기능을 개발하고 기능이 안정화되면 이 이슈는 더 큰 문제를 발생하기 전에 기술 부채를 해결하고 가시죠!"라고 말하며 오늘도 우당탕탕 제품을 만드는 중이다.
