먼저 답부터. 기술부채는 진짜 '빚'이 맞다. 지금 빨리 내보내려고 대충 짜둔 코드가, 나중에 시간을 들여 갚아야 하는 빚이다. 안 갚고 미루면 이자가 붙는다. 처음엔 5분이면 고치던 게 반년 뒤엔 사흘이 걸린다.
왜 하필 '빚'이라는 단어를 쓰는지는 이렇게 그려보면 정확하다.
급하게 문을 연 가게를 떠올려보자. 오픈 날짜를 맞추려고 전선을 천장에 임시로 늘어뜨려 둔다. 당장은 불도 들어오고 냉장고도 돌아간다. 아무 문제 없어 보인다. 그런데 장사가 잘돼서 기계를 하나 더 놓으려는 순간, 그 임시 전선이 발목을 잡는다. 새 콘센트를 꽂을 자리가 없고, 잘못 건드리면 가게 전체가 정전된다. 결국 하루 영업을 접고 배선을 처음부터 다시 깐다.
코드도 똑같다. 빨리 출시하려고 '일단 되게' 짜둔 부분은, 기능을 새로 붙일 때마다 조금씩 더 위험해진다. 여기서 헷갈리기 쉬운 게 '기술부채'와 '리팩토링'의 차이다. 둘은 원인과 처방의 관계다. 기술부채는 쌓여 있는 문제, 즉 빚 자체이고, 리팩토링은 그 빚을 갚는 작업이다. 겉으로 보이는 화면은 하나도 안 바뀐다. 그래서 개발자가 "리팩토링이 필요하다"고 말하면, 갚아야 할 빚이 눈에 보이기 시작했다는 신호로 들으면 된다.
그런데 빚이라고 다 같은 빚은 아니다. PM이 알아야 할 가장 중요한 구분이 여기 있다. 기술부채에는 '일부러 진 빚'과 '모르고 진 빚'이 있다.
오픈 날짜를 사려고 의도적으로 지는 빚이 있다. "이번 분기 안에 출시하는 값어치가 이 임시 코드의 위험보다 크니까, 지금은 빚을 내고 다음 분기에 갚자"는 판단이다. 이건 잘못이 아니라 전략이다. 반대로 몰라서, 급해서, 아무도 안 챙겨서 어쩌다 쌓이는 빚이 있다. 이쪽은 이자율이 훨씬 높고, 나중엔 누가 왜 그렇게 짰는지조차 아무도 모른다. 그래서 개발자가 "기술부채가 있다"고 할 때 PM이 던질 질문은 "왜 이렇게 됐어요"가 아니라 "이거 일부러 진 거예요, 아니면 쌓인 거예요?"다. "일부러 졌고 갚을 계획도 있다"와 "어쩌다 이렇게 됐다"는 완전히 다른 상황이고, 손 쓰는 방법도 달라야 한다.
기술부채 예시를 몇 개만 들면 감이 온다. 급해서 같은 코드를 여러 화면에 복사해 붙인 것, 나중에 고치려고 값을 잠깐 고정해둔 것(하드코딩), 테스트를 안 짜고 넘어간 기능, 몇 년째 안 올린 낡은 라이브러리. 하나하나는 사소해 보인다. 문제는 이것들이 서로 얽히면서 개발자조차 '건드리기 무서운 구역'을 만든다는 데 있다. 그 구역이 넓어질수록 새 기능 하나 붙이는 속도가 느려진다.
여기서 가장 흔한 반응이 "지금 잘 돌아가는데 뭐가 문제예요?"다. 개발하던 시절 나도 이 말을 수없이 들었다. 틀린 말은 아니다. 지금은 돌아간다. 다만 '지금'까지만 그렇다. 임시 배선은 언젠가 반드시 한 번은 뜯게 되어 있고, 늦게 뜯을수록 더 크게 뜯는다. 그 차액이 이자다.
그럼 눈에 안 보이는 이 빚을 PM은 무엇으로 가늠할까. 기술부채는 회계 장부처럼 딱 떨어지는 숫자로 안 찍힌다. 하지만 개발자는 감각으로 안다. "이 부분은 건드리기 무섭다", "여기 손대면 어디서 터질지 모른다" 같은 말이 바로 그 감각이다. PM이 할 일은 그 감각을 대화로 끌어내 숫자로 바꾸는 것이다. 가장 쉬운 건 속도 변화다. "반년 전엔 이 정도 기능이 사흘이었는데 지금은 며칠 걸려요?"를 물으면, 그 늘어난 날짜가 곧 이자다. 다음은 범위다. "전체 코드에서 손대기 겁나는 구역이 대략 몇 할쯤 돼요?"라고 물으면 개발자는 의외로 구체적인 답을 준다. 같은 자리에서 버그가 자꾸 재발하는지, 새로 합류한 사람이 그 코드를 이해하는 데 며칠이 걸리는지도 좋은 신호다. 코드 복잡도를 자동으로 점수 매기는 측정 도구가 따로 있긴 하지만, PM에게는 이 네 가지 질문이 더 빠르고 정확하다. 완벽한 숫자는 어차피 없다. 중요한 건 "건드리기 무섭다"는 느낌을 "사흘짜리가 일주일이 됐다"는 문장으로 바꾸는 일이다. 그래야 협상 테이블에 근거로 올릴 수 있다.
현장에서 이 빚은 아주 조용히 불어난다. 일정이 빠듯해져서 이번에 담을 항목을 쳐내는 회의를 떠올려보자. 새 기능은 사업팀이 지키고, 버그 수정은 사용자가 지킨다. 그런데 리팩토링은 화면에 아무것도 안 보이니 지켜줄 사람이 없다. 그래서 일정 협상 테이블에서 가장 먼저 잘려나가는 항목은 늘 리팩토링이다. 한두 번은 괜찮다. 문제는 매번 잘린다는 것이다. 반년 동안 리팩토링이 한 번도 살아남지 못한 팀은, 어느 순간 기능 하나 붙이는 데 두 배의 시간을 쓰게 된다. 그 테이블에서 리팩토링을 한 번이라도 지켜주는 사람이 PM이라면, 팀의 반년 뒤가 달라진다.
그러니 개발자가 리팩토링 이야기를 꺼내면, "그건 나중에 하죠" 대신 이렇게 물어보는 게 낫다. "지금 안 갚으면 반년 뒤엔 얼마나 더 커지나요?" 이 한 문장이 미뤄둔 빚의 이자를 눈에 보이게 만든다. 개발자는 그제야 "지금은 이틀인데 반년 뒤엔 일주일입니다" 같은 숫자를 꺼낸다. 그 숫자가 있어야 위에 올릴 근거도 생긴다.
솔직히 기술부채는 완전히 0으로 만들 수 없다. 아무리 좋은 팀도 마감 앞에서는 임시 배선을 늘어뜨린다. 갚는 팀과 미루는 팀이 갈릴 뿐이다. 그러니 "부채가 있다"는 말 자체에 놀랄 필요는 없다. 정작 놀라야 할 때는, 개발자가 그 이야기를 더 이상 꺼내지 않는 순간이다.
개발자의 이런 말들을 한 마디씩 통역해본 이야기를 책으로 묶어 세상에 꺼냈습니다.