13. 기술 부채 관리하기

빨리, 잘하기

위 그림은 마틴 파울러의 블로그 설계체력가설(Design Stamina Hypothesis)에 나오는 그림이다.

가로축은 시간의 흐름을 나타내고, 세로축은 누적 기능 개수를 나타낸다.

no design(설계가 좋지 않은 경우)의 경우는 설계 수익선(design payoff line)까지는 빠르게 기능을 추가해 가지만 그 이후는 속도가 둔화된다.

good design(좋은 설계를 가진 경우)의 경우는 설계 수익선 전까지는 no design에 비해 기능 추가 속도가 떨어지지만, no design과 달리 설계 수익선을 지난 후에도 지속적으로 속도가 유지된다.

위 그림을 토대로 기술부채를 정의해 보면, 기술부채라는 것은 

"일정을 위해 품질을 의도적으로 희생시키는 것"

이다. 즉 좋은 품질을 늘 유지할 만한 역량이 있지만 일정을 의해서 일정 기간 품질을 양보하는 것이다.

왜 좋은 설계를 유지할 역량이 있지만 일정을 위해 양보해야 하는 경우가 있을까?

좋은 설계를 가진 것이 늘 생산성이 좋다면 우리는 부채에 대해서 고민하지 않아도 될 것이다. 하지만 설계 수익선 이전에는 no design이 더 빠르다는 것이 문제가 된다. 우리가 생각한 기능, 서비스 등이 시장에서의 통하는지, 의도한 바와 같이 의미 있는 기능인지 알아보기 위해서 빨리 구현하고, 사용자의 피드백을 받아봐야 한다. BM(Business Model)을 검증해 봐야 한다는 것이다. VUCA로 대변되는 지금과 같은 변동성의 시대에 초기의 계획대로 꾸준히 가기보다는 빠르게 가능성을 확인하고, 검증이 되면 제대로 가는 것이 성공할 확률이 높기 때문이다.

우리가 경쟁자보다 늦게 서비스를 만들면 경쟁자에게 밀릴 것은 자명하다. 그런데 우리가 빠르게 우리의 BM이 의미 있다는 것을 증명했는데 서비스화하고 이후 발생하는 다양한 요구사항 변경에 빠르고 효과적으로 대응하지 못한다면 이 또한 패인이 될 것이다. 우리의 경쟁자는 우리가 어렵게 검증한 BM을 검증 과정 없이 빠르게 높은 설계 수준으로 서비스화할 수 있을 것이다. 특히 그들의 플랫폼 역량이 뛰어나다면 더욱 그럴 것이다.

그래서 우리는 부채를 지더라도 빠르게 BM을 검증하고, 검증된 후에는 미루지 말고 부채를 관리해 가며 서비스화해야 하는 것이다.

여기서 어려운 점은 

설계 수익선을 지났다는 것을 알기 어렵다

는 것이다. 속도에 계속해서 몰입하다가 보면 어느 순간 설계 수익선을 훌쩍 지나쳐서 기술부채가 너무 많이 쌓여서 부채 상환이 불가한 상황에 빠질 수 있다. 

아키텍처의 부족은 너무 늦었을 때만 측정할 수 있다.

위 글은 Rober C. Martin의 "소프트웨어 장인 정신 이야기"에서 나오는 내용으로 기억하는데, 매우 공감되는 의견이다. 아키텍처 문제는 발견은 가능하나 너무 늦게 발견된다는 것이다. 난 이런 현상을 췌장암에 비유한다. 췌장암은 발견되었을 때는 이미 치료 불가한 상태라고 들었기 때문에 췌장암 비율을 자주 사용한다.

결국 설계 수익선을 인지하고 그때에 부채를 해결하려고 시도하고, 해결할 수 있는 역량이 중요하다. 그래서 필요한 또 한 가지 역량은 

빠르게 구현하고 설계 수익선을 지난 후에 높은 품질을 갖도록 개선(부채 상환)할 수 있는 역량이 있어야 한다

는 것이다.

개발자인 우리에게 필요한 것은 미리 변화를 예측하고 대비하는 것이 아니라, 변화가 필요한 상황(설계 수익선)을 인지하고, 요구되는 변경을 빠르고 효과적으로 대응(기술부채 상환)하는 것이다.