기술 부채, 언제 갚고 언제 미룰까요 | SaaS 4종 운영 기준 3가지
자체 SaaS 4종(D:VALUEUP·Likepro·Globing·Linkmix)을 함께 운영하며 기술 부채를 언제 갚고 언제 미룰지 판단하는 기준과, 롯데백화점 프로젝트에서 임시방편이 커졌던 실제 사례를 정리했어요.
기술 부채(technical debt, 당장 편한 선택이 나중에 이자처럼 불어나는 비용)는 한 번에 갚는 빚이 아니라 매번 다시 판단해야 하는 빚이에요. 자체 SaaS 4종을 함께 운영하며 저희가 쓰는 기준은 두 가지예요 — 이 코드를 얼마나 자주 건드리는지, 문제가 터지면 몇 개 서비스까지 번지는지. 두 축이 모두 높으면 지금 갚고, 둘 다 낮으면 미뤄도 괜찮아요. 실제로 미뤘다가 커진 사례와 서비스 4개 중 어디부터 손댈지 정하는 기준까지 정리했어요.
“이 부분은 일단 이렇게만 처리하고, 다음에 제대로 고치죠.” 마감이 코앞이면 이 말이 자연스럽게 나와요. 문제는 그 ‘다음’이 좀처럼 오지 않는다는 거예요. 저희도 자체 SaaS 4종을 함께 운영하면서 이 문장을 셀 수 없이 들었고, 그중 상당수는 여전히 ‘나중’으로 남아 있어요. 오늘은 그 ‘나중’을 언제 진짜로 처리하고 언제 계속 미뤄도 되는지, 저희가 세운 판단 기준을 풀어볼게요.
1. 기술 부채는 왜 ‘나중에 한 번에’ 갚을 수 없을까요
개발팀이라면 다들 비슷한 캘린더를 그려봤을 거예요. “이번 배포 끝나면 리팩토링(구조를 다시 정리하는 작업) 주간을 잡자.” 그런데 배포는 끝나지 않아요. 새 기능 요청이 들어오고, 다른 서비스에서 문의가 오고, 그 사이 ‘리팩토링 주간’은 계속 뒤로 밀려요.
저희가 4개 서비스를 함께 운영하며 알게 된 건, 부채를 ‘몰아서 갚는다’는 계획 자체가 현실적이지 않다는 점이에요. 급한 일은 항상 계획에 없던 순서로 들어오거든요. 그래서 저희는 접근을 바꿨어요. 따로 시간을 빼서 갚는 대신, 코드를 어차피 건드릴 일이 생길 때마다 그 자리만 조금씩 정리하는 쪽으로요.
2. SaaS 4종을 함께 운영하며 부채가 쌓이는 세 지점
D:VALUEUP·Likepro·Globing·Linkmix, 네 서비스를 같이 굴리다 보니 부채가 쌓이는 자리가 반복적으로 눈에 띄었어요.
- 여러 서비스가 함께 쓰는 공통 모듈 — 로그인·알림처럼 서비스 전부가 걸쳐 있는 코드는 한 서비스 사정에 맞춰 급하게 손대기가 특히 위험해요. 나머지 서비스가 함께 흔들리거든요.
- 급한 마감에 맞춰 넣은 예외 처리 — “이 조건일 때만 이렇게 처리하자”는 임시 분기가 정식 로직인 것처럼 그대로 남는 경우예요.
- 오래된 라이브러리 버전 — 당장은 잘 돌아가니 미루다가, 보안 업데이트나 외부 API 스펙 변경 시점에 한꺼번에 발목이 잡혀요.
세 지점의 공통점은 하나예요. 만들 때는 문제가 안 보인다는 것. 부채는 늘 다음 사람이, 혹은 다음 요청이 왔을 때 그 값을 치르게 돼요.
3. ‘지금 갚을 빚’과 ‘미뤄도 되는 빚’을 가르는 두 가지 질문
저희가 실제로 던지는 질문은 두 가지예요.
- 이 코드를 얼마나 자주 건드리나요? 한 달에 몇 번씩 손대는 코드라면, 그때마다 부채의 이자를 내는 셈이에요.
- 문제가 터지면 몇 개 서비스까지 번지나요? 서비스 하나에만 갇힌 문제인지, 공통 모듈이라 4개 서비스 전체가 흔들릴 문제인지를 갈라요.
두 질문에 모두 ‘예’라면 — 자주 건드리는데 파급 범위까지 넓다면 — 그건 지금 갚아야 할 빚이에요. 반대로 어쩌다 한 번 건드리고 문제가 나도 한 서비스에서 끝난다면, 굳이 지금 자원을 쓰지 않아요. 이 두 축으로만 걸러도 우선순위 논쟁의 절반은 정리돼요.
4. 서비스 4개 중 어디부터 갚을지 정하는 기준
질문 두 가지로 ‘지금 갚을 빚’이 여러 서비스에서 동시에 나오면, 그다음은 순서 문제예요. 저희는 세 가지를 더 봐요.
첫째, 그 서비스가 지금 얼마나 쓰이고 있는가예요. 저희 SaaS 4종은 누적 가입 60만 명이 넘게 이용해왔는데, 사용자가 많은 서비스일수록 같은 부채라도 문제가 터졌을 때 영향이 커요. 둘째, 다른 서비스가 그 모듈에 얼마나 의존하는지예요. 의존하는 서비스가 많을수록 순서를 당겨요. 셋째, 이번 분기 로드맵과 겹치는지예요. 어차피 그 영역을 새로 손댈 계획이라면, 부채를 먼저 정리하고 그 위에 새 기능을 얹는 편이 두 번 일하지 않아요.
세 기준이 부딪히면 결국 사용자 규모를 우선해요. 자원이 한정된 팀에서는 “누가 더 많이 쓰는가”가 가장 공정한 저울이거든요.
5. 미뤘던 부채가 실제로 커진 사례 — 롯데백화점 푸드홀
저희가 캐논코리아와 컨소시엄으로 함께 수행한 롯데백화점 수원 푸드홀 실시간 혼잡도 관리 시스템에서 실제로 겪은 일이에요. 관리자 페이지에서 등록한 광고가 매장 사이니지에서 끊기는 현상이 있었는데, 처음엔 JavaFX로 구현돼 있던 부분이었어요. 문제를 근본적으로 해결하려면 그 자리를 C#으로 다시 구현해야 했어요.
이 경우는 임시로 넘길 수 있는 지점이 아니었어요. 매장 곳곳의 사이니지가 걸린 문제라 파급 범위가 넓었고, 실시간 운영 중인 시스템이라 자주 부딪히는 구간이었거든요. 앞서 말한 두 가지 질문 — 자주 건드리는가, 파급이 넓은가 — 에 둘 다 ‘예’였던 사례예요. 그래서 재구현을 미루지 않고 바로 처리했고, 그 판단 덕분에 사이니지는 안정적으로 운영에 들어갔어요.
운영 중에 이런 판단이 필요한 시스템을 준비 중이시라면, 착수 전에 비슷한 구조의 위험 지점부터 함께 짚어볼 수 있어요 →
6. 기술 부채 관리가 외주 업체를 고를 때 신호가 되는 이유
발주 미팅에서 “기술 부채를 어떻게 관리하시나요”라고 묻는 발주자는 많지 않아요. 그런데 이 질문 하나가 개발사가 납품 이후를 얼마나 생각하고 있는지를 꽤 정확히 드러내요.
납품하고 끝나는 계약을 주로 해온 개발사는 대개 “일단 요구사항대로 완성해서 넘겨드립니다”는 답을 해요. 틀린 답은 아니지만, 그 안에 임시로 처리한 부분이 얼마나 남아 있는지는 알려주지 않아요. 반대로 운영을 직접 해본 개발사는 “임시로 처리한 부분은 문서로 남기고, 다음 개발 단계에서 우선 검토합니다” 같은 구체적인 대답을 해요. 유지보수 요율과 SLA 기준을 물어볼 때와 마찬가지로, 질문에 얼마나 구체적으로 답하는지가 판단 기준이 돼요.
7. 원칙이 없을 때 SaaS와 외주 프로젝트 모두에서 생기는 문제
기준 없이 부채를 쌓아두면 두 가지 문제가 반복돼요. 하나는 작은 수정 하나에도 예상보다 시간이 오래 걸리는 것이에요. 코드를 고치기 전에 “이걸 건드리면 어디까지 영향이 가는지”부터 파악해야 하니까요. 다른 하나는 담당자가 바뀔 때 드러나요. 임시로 처리한 이유가 문서로 남아 있지 않으면, 다음 담당자는 그 코드를 지우지도 못하고 건드리지도 못한 채 떠안게 돼요.
이건 자체 SaaS만의 문제가 아니에요. 외주로 시스템을 발주한 기업도, 개발사를 바꾸거나 유지보수를 다른 곳에 맡기는 순간 똑같은 상황을 만나요. 결국 기술 부채를 판단하는 기준은 직접 운영해본 조직만 실전에서 다듬을 수 있는 감각이에요.
8. 자주 묻는 질문
기술 부채는 그냥 나중에 한꺼번에 고치면 안 되나요?
가능은 하지만 그 ‘나중’이 실제로 오는 경우가 드물어요. 급한 일이 항상 먼저 들어오기 때문이에요. 저희는 부채를 모아뒀다가 한 번에 갚기보다, 코드를 건드릴 일이 생길 때마다 그 부분만 조금씩 정리하는 쪽을 원칙으로 삼아요.
외주로 만든 시스템에도 기술 부채가 쌓이나요?
쌓여요. 오히려 운영을 넘겨받는 쪽과 개발한 쪽이 다르면 부채가 어디에 있는지조차 파악이 안 되는 경우가 많아요. 인수인계 문서에 ‘임시로 처리한 부분’ 목록이 따로 있는지 확인해보시는 게 좋아요.
기술 부채 관리 계획을 개발사에 어떻게 요청하면 되나요?
착수 전에 “임시로 처리한 부분은 어떻게 기록하고, 언제 다시 검토하나요”라고 물어보시면 돼요. 이 질문에 구체적으로 답하는 개발사일수록 납품 이후 운영까지 고려해 설계한다고 보시면 돼요.
9. 마무리 — 부채는 없애는 게 아니라 다루는 거예요
기술 부채를 완전히 없앨 수 있는 팀은 없어요. 마감은 늘 있고, 처음부터 흠 없는 구조로 짜는 것도 현실적이지 않으니까요. 어떤 부채를 지금 갚고 어떤 부채를 미뤄도 되는지, 그 판단 기준을 갖고 있느냐가 관건이에요.
저희는 10년 이상 50개가 넘는 프로젝트를 진행하면서, 동시에 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과 함께한 프로젝트에서도 오늘 정리한 두 가지 질문을 그대로 썼고요. 납품 후에도 계속 굴러가야 하는 시스템을 준비 중이시라면, 기술 부채를 어떻게 관리할지도 착수 단계부터 함께 이야기해볼 수 있어요.
함께 보면 좋은 글이에요.