경영학과 전공자라면 반드시 들어야 하는 수업이 있다. 회계원리와 재무관리. 나는 이쪽 수업이 너무 재미 없어서 필수 과목만 최소한으로 수강했다. 비록 암기했던 것들은 다 사라졌지만 중요한 하나는 남아있다.

자산 = 부채 + 자본

기업은 소유하고 있는 경제적 자원을 관리하기 위해 재무상태표를 작성한다. 재무상태표란 간단히 말하자면 회사의 가계부라고 볼 수 있다. 다만 들어온 돈(수입)과 나간 돈(지출)만 기록하는 가계부와는 달리 재무상태표는 복식부기 방식으로 기록한다. 복식부기란 거래가 발생했을 때 상호대응 되는 두 개 항목을 동시에 기입하는 방식이다. 상태표의 왼쪽에는 자산에 해당하는 항목, 오른쪽에는 부채와 자본에 해당하는 항목을 기록한다. 그래서 항상 왼쪽의 총합과 오른쪽의 총합이 같게 유지되어야 한다. 따라서 회계적인 관점에서 보면 언제나 자산 = 부채 + 자본 이라는 등식이 성립한다.

기술 부채에 대한 생각이 바뀌다

기술 부채란 뭘까? 일명 스파게티 코드라고 부르는 구조화되어 있지 않은 코드 형태, 기능 수정이나 추가가 힘든 코드, 영향 범위를 파악하기 힘든 사이드 이펙트를 내재하고 있는 부분 등을 보면 개발자는 기술 부채가 있다고 느낀다. 이럴 때 보통 “기술 부채를 갚아야 한다”, “기술 부채가 너무 쌓였다”, “올해는 기술 부채를 좀 청산하자” 등의 표현을 사용한다. 이런 말을 종종 듣다보니 기술 부채는 무조건 없애거나 줄여야 하는 나쁜 대상으로만 인식하고 있었다.

그러던 어느날 팀원이 공유해준 블로그에서 ‘기술 부채가 발생하면서 남는 리소스를 다른 곳에 투자할 수 있다’는 문장을 봤다. 그때 회계 수업에서 배웠던 자산 = 부채 + 자본 등식이 생각났다. 부채에는 자산의 측면도 있다는걸 잊고 있었다. 그렇다면 기술 부채에도 자산의 측면이 있을까란 궁금증이 생겼다. 있다면 과연 어떤 종류의 자산일까. 그건 바로 시간이 아닐까란 생각을 했다.

부채가 무조건 나쁘기만 한 건 아니라는 마인드

현실 세계에서 부채가 없는 회사는 거의 없다. 그리고 더 중요한 사실은 부채가 없다는 것이 썩 좋기만 한 것도 아니라는 점이다. 회사에게 자산이란 생산 활동(돈 벌기)에 도움이 되는 것들을 의미한다. 자산이 많아야 생산도 많이 할 수 있다. 그래서 일반적으로 기업은 적절히 부채를 늘려 자산을 늘린다. 예를 들어 은행에서 대출을 받거나 회사채를 발행하여 현금을 확보한다. 물론 골목 가게처럼 규모가 작은 사업체는 빚이 아예 없을 수도 있다. 하지만 그런만큼 성장성도 낮다. 성장하기 위해 부채를 적절히 사용하면 좋은 것이다.

회사를 개발팀으로 치환해봐도 비슷하다. 개인 프로젝트가 아닌 이상 현실적으로 기술 부채를 만들지 않고 개발을 할 순 없다. 촉박한 마감일에 맞춰 개발을 하다보면 기술 부채가 쌓이게 되는데, 그 대신 사업적인 성과를 낼 수 있게 된다. 보통 연휴 기간에 매출이 높기 때문에 기술 부채가 생기더라도 연휴 시작 전에 출시하는 것이 좋을 것이다. 또한 확장의 시기에는 경쟁자보다 먼저 시장에 진입해 사용자를 확보하기 위해 빠르게 개발하는게 성장에 더 좋을 수 있다. 이런식으로 기술 부채를 짊어지는 대신 시간을 벌 수 있고, 그 시간으로 매출을 내거나 양적 성장을 이룰 수 있다.

스파게티 코드를 보면 찌푸려졌었고 어떻게든 빨리 없애야하는 나쁘기만한 존재라고 생각했다. 하지만 자산의 측면도 있다고 생각하니 적절한 관리감독이 필요한 대상으로 인식하기 시작했다. 다만 남이 진 부채를 내가 대신 상환하고 있는 느낌이 들 때도 있다. 또 그러나 내가 만든 기술 부채도 다른 누군가가 갚고 있겠지.

기술 부채는 어떻게 관리해야 하지?

“측정할 수 없는 것은 관리할 수 없다” - 피터 드러커

그렇다고 무작정 기술 부채를 늘리기만 할 수도 없다. 기술 부채를 갚지 않고 늘리기만 하면 팀 전체의 개발 속도가 느려지고 좀비처럼 되살아나는 버그로 인해 사용자와 개발자 모두 고통 받게 된다. 개발 생산성이 낮아지면 결국 사업도 부정적인 영향을 받는다. 다만 금융 부채와 기술 부채의 가장 큰 차이점은 기술 부채는 세는 단위가 없기 때문에 정확한 양을 알 수 없다는 점일 것이다. 근데 피터 드러커는 측정할 수 없는 것은 관리할 수 없다고 했다. 기술 부채를 관리하고 싶다면 어떻게든 수치로 나타내야 한다.

엉클밥은 애자일 포인트를 제시했다. 개발 업무별로 각각 예상되는 투입 리소스에 따라 포인트를 부여하고, 개발팀이 총 몇 포인트만큼의 일을 완료하는지 스프린트 단위로 그 추이를 보는 것이다. 스프린트마다 쌓는 포인트가 점점 줄기 시작하면 기술 부채로 인해 개발 속도가 느려지는 것이므로 코드 리팩토링을 해서 기술 부채를 청산해야할 타이밍이라고 한다. 애자일 포인트는 기술 부채로 인해 야기되는 개발 속도 저하를 추적하는 간접적인 지표인 것 같다. 좀 더 직접적으로는 코드 정적 분석을 통해 도출하는 지표들도 있다. 반복되는 코드가 얼마나 많은지, 클래스/프레임워크 간의 디펜던시가 얼마나 복잡한지 등등. 어떤 것을 쓰든 정답은 없으므로 아마도 상황에 맞게, 팀에 맞게 써야하지 않을까 싶다. 아직 관련 경험이 부족하여 상상만 할 뿐이다.

경영 ≈ 개발

기술 부채에 대해 부정적인 말만 듣다보니 무작정 안좋은 것이라고만 생각했었는데 기술 부채를 회계적인 부채랑 비교해보니 조금 다르게 바라보게 됐다. 또한 기업을 경영하는 것과 개발 팀을 운영하는 것이 비슷한 점이 많아 보인다. 부채 없이 사업을 할 순 없지만 부채가 너무 많이 쌓여서 상환하지 못하면 파산한다. 마찬가지로 기술 부채 없는 개발팀은 존재하지 않지만, 제대로 관리하지 못하면 주저 앉는다. 버그 투성이 프로그램 때문에 사용자가 고통받을 수도 있고 사용자가(또는 지친 개발자마저) 아예 떠나버릴 수도 있다. 도저히 부채 청산이 안되면 코드를 전부 버리고 아예 처음부터 다시 개발해야 할 수도 있다. 결국 경영이든 개발이든 부채를 잘 관리해서 조직에 유익한 방향으로 활용하는 것이 중요하다는 생각이 든다.

이 글의 초안을 읽어준 조소현, 김결에게 고마움을 전합니다.