싸게 빨리 만든 코드, 기술 부채 줄이는 3가지 요구

기술 부채는 잘 만드는 대신 빠르게 만드는 쪽을 택했을 때 나중에 쌓이는 재작업 빚입니다. 개발팀만의 문제로 보이지만 외주로 서비스를 맡긴 발주자에게도 그대로 돌아옵니다. 2차 개발 견적이 갑자기 뛰거나 간단한 수정이 며칠씩 걸리는 형태로 청구되기 때문입니다. 이 글은 기술 부채가 무엇인지 비유로 풀고 그 부채가 쌓였다는 신호와 발주 단계에서 미리 줄이는 세 가지 방법을 정리합니다.

핵심 요약

• 기술 부채는 급하게 짠 코드가 남긴 빚입니다. 당장은 빨라 보여도 이자가 붙어 나중에 더 비싸집니다.
• 발주자에게는 2차 개발 견적 상승과 잦은 오류, 느린 수정 속도로 청구됩니다.
• 수정할 때마다 예상보다 오래 걸리거나 한 곳을 고치면 다른 곳이 깨지면 부채가 쌓였다는 신호입니다.
• 발주 단계에서 인수인계 문서와 소스코드 소유, 테스트와 코드 점검을 요구하면 부채를 크게 줄입니다.
• 싸게 빨리만 앞세운 견적은 그 자체가 미래의 청구서입니다. 계약 전에 확인해야 할 대목입니다.

기술 부채가 무슨 뜻인가

기술 부채라는 말은 1992년 워드 커닝햄이 처음 썼습니다. 아사나는 이를 가장 효율적인 방법 대신 가장 빠른 방법을 택해 생기는 추가 재작업의 대가라고 설명합니다. 카드빚에 빗대면 이해가 쉽습니다. 급할 때 카드로 먼저 결제하면 당장은 편하지만 나중에 원금에 이자까지 갚아야 합니다. 코드도 마찬가지입니다. 마감에 쫓겨 대충 이어 붙인 부분은 당장은 돌아가지만 시간이 지날수록 손보기 어려워지고 그만큼 이자가 붙습니다.

부채가 전부 나쁜 것은 아닙니다. 마틴 파울러는 기술 부채를 의도한 것과 의도하지 않은 것으로 나눕니다. 일정을 맞추려고 알면서도 빠른 길을 택하는 계획된 부채가 있고 경험이 부족해 자기도 모르게 쌓는 부채가 있습니다. 문제는 방치입니다. 어느 쪽이든 갚지 않고 두면 눈덩이처럼 불어납니다. 아사나는 90일이 지나도 해결하지 않은 부채는 심각하게 다루라고 권합니다. 발주자에게는 오픈이 끝이 아니라 미뤄 둔 숙제를 언제 손볼지 계획에 넣어 두라는 얘기입니다. 반년 뒤에 몰아서 갚으려 하면 이자가 그만큼 불어 있습니다.

왜 비개발자 발주자에게도 돌아오나

외주로 만든 서비스를 몇 달 뒤 이어받아 손보다 보면, 처음 만든 방식에 따라 난이도가 하늘과 땅 차이인 경우가 있습니다. 문서 하나 없이 급하게 만든 서비스는 버튼 색 하나 바꾸는 데도 코드를 한참 헤매야 합니다. 이 시간은 고스란히 유지보수 비용과 2차 개발 견적으로 발주자에게 청구됩니다.

싸게 빨리 만든 결과가 나중에 더 비싸지는 이유가 여기 있습니다. 처음 견적이 낮았던 건 품질을 아꼈기 때문인 경우가 많고 그 아낀 만큼이 부채로 남습니다. 몇 달 뒤 기능을 하나 더 붙이려는데 견적이 처음 제작비에 맞먹게 나온다면, 십중팔구 그 사이 쌓인 부채를 갚는 비용이 섞여 있습니다. 발주자가 코드를 직접 볼 일은 없어도, 그 상태는 견적서와 수정 속도로 반드시 드러납니다.

여기서 한 가지 구분이 도움이 됩니다. 일정에 맞추려고 미리 합의하고 남긴 부채와, 아무도 모르게 쌓인 부채는 성격이 다릅니다. 앞의 것은 나중에 어디를 손볼지 알고 남긴 것이라 갚기 쉽지만 뒤의 것은 어디에 문제가 있는지조차 몰라 더 위험합니다. 그래서 발주자가 챙길 일은 부채를 아예 없애는 게 아닙니다. 어디를 아껴 값을 낮췄는지 처음부터 드러나게 하면 됩니다. 무엇을 미뤘는지 알고 있으면 그건 관리할 수 있는 빚이 됩니다.

기술 부채가 쌓였다는 신호

코드를 못 봐도 발주자가 알아챌 수 있는 신호가 있습니다. 아래 다섯 가지 중 두어 개가 겹친다면 부채를 한번 점검해 볼 만합니다.

겉으로 보이는 신호	속에서 벌어지는 일
간단한 수정이 매번 예상보다 오래 걸린다	코드가 얽혀 한 줄 고치기 어렵다
한 곳을 고치면 다른 화면이 깨진다	기능끼리 얽혀 영향 범위가 넓다
담당 개발자 아니면 아무도 못 만진다	문서가 없어 지식이 한 사람에 묶였다
업체를 바꾸기 어렵다	인수인계 자료가 부족하다
접속자가 늘면 느려지거나 오류가 잦다	급하게 만들어 확장을 고려 못 했다

이런 신호는 서비스가 커질수록 더 자주, 더 비싸게 나타납니다. 처음엔 사소해 보여도 기능을 하나씩 얹을 때마다 얽힌 부분이 같이 흔들리기 때문입니다. 반대로 신호가 거의 없다면, 겉보기엔 비슷해도 속을 정리하며 만든 서비스입니다.

발주 단계에서 부채를 줄이는 3가지 요구

기술 부채는 완성된 뒤에 없애기보다 처음 발주할 때 덜 쌓이게 하는 편이 훨씬 쌉니다. 계약 전에 다음 세 가지를 요구하면 됩니다.

1. 인수인계 문서와 소스코드 원본을 모두 받기로 명시합니다. 화면 구성과 데이터 구조, 계정 정보를 문서로 남기면 나중에 누가 이어받아도 헤매지 않습니다.
2. 테스트와 코드 점검을 범위에 넣습니다. 오류를 자동으로 걸러 주는 최소한의 장치와 코드 리뷰가 있으면, 한 곳을 고쳐 다른 곳이 깨지는 일이 줄어듭니다.
3. 싸게 빨리 대신 나중 비용까지 물어봅니다. 업체에 "이 견적은 어디를 아껴 낮춘 것이고, 나중에 기능을 붙일 때 그 부분이 발목을 잡지 않나요?"라고 확인하면 숨은 부채가 드러납니다.

세 가지 모두 특별한 기술 지식 없이 발주자가 계약서와 대화로 챙길 수 있습니다. 흔한 오해 하나를 짚자면, 비싸게 만들면 부채가 없다는 생각입니다. 금액보다 문서와 점검 과정을 남겼는지가 부채를 가릅니다. 요즘은 인공지능으로 코드를 빠르게 뽑는 경우도 늘었는데, 검토 없이 그대로 쓰면 눈에 안 보이는 부채가 오히려 빨리 쌓입니다. 빠르게 만드는 도구가 좋아질수록, 만든 결과를 누가 어떻게 점검했는지가 더 중요해지는 셈입니다. 계약서에 문서와 점검 항목이 한 줄이라도 들어가 있는지부터 확인하시길 권합니다.

가상 예시로 보는 차이

같은 예약 사이트를 두 업체에 맡겼다고 해 보겠습니다. 한 곳은 문서와 테스트를 빼고 최저가로 두 주 만에 열어 줍니다. 다른 곳은 조금 더 받고 인수인계 문서와 기본 점검을 넣어 삼 주에 엽니다. 반년 뒤 결제 기능을 붙이려 할 때, 앞 업체 서비스는 구조를 파악하는 데만 며칠이 들어 견적이 뜁니다. 뒤 업체 서비스는 문서를 보고 바로 작업에 들어가 비용이 훨씬 적게 나옵니다. 처음 아낀 금액을 2차에서 되돌려주는 셈입니다. 두 업체의 첫 견적만 보면 앞이 싸 보이지만 서비스를 오래 쓸수록 총비용은 뒤가 낮아지는 경우가 많습니다. 그래서 견적을 비교할 때는 제작비 한 줄이 아니라 이 서비스를 일이 년 굴리며 손볼 때까지의 비용을 그려 보는 편이 정확합니다. 발주 전 준비를 더 챙기고 싶다면 외주 준비 체크리스트와 홈페이지 개발 업체 고르는 법을 함께 참고하고 문서와 점검을 계약에 담아 만들려면 홈페이지 제작 단계에서 미리 조율하시면 됩니다.