기술 부채
급하게 만든 부분이 나중에 이자를 붙여 청구되는 거예요. 기능 추가가 점점 오래 걸리고 견적이 갑자기 뛰는 이유가 대개 여기예요.
쉽게 말하면
주문이 몰린 날, 들어온 재료 상자를 창고에 넣을 시간이 없어서 주방 통로에 그대로 쌓아 뒀어요. 그날은 이게 정답이에요. 상자 정리하다 손님을 놓치는 게 더 큰 손해니까요. 문제는 다음 주예요. 소금 한 통 꺼내려고 상자를 세 번 옮기고, 새로 온 직원은 뭐가 어디 있는지 몰라 매번 물어봐요. 상자를 쌓은 건 한 번인데, 값은 그 뒤로 매일 나가요. 급하게 만든 코드도 정확히 이렇게 굴러가요.
이걸 부채, 즉 빚이라고 부르는 이유는 하나예요. 이자가 붙기 때문이에요. 원금은 급하게 지나간 그 하루고, 이자는 그 뒤로 무언가를 고칠 때마다 더 나가는 시간이에요.
가격을 한 번 올리려면 네 곳을 찾아 고치고, 하나를 빠뜨렸는지 확인할 방법이 없어요. 요청은 한 줄인데 일은 다섯 가지예요.
같은 요청이 한곳 고치기로 끝나요. 손이 덜 가는 게 아니라, 앞서 그만큼 손을 써 뒀던 거예요.
그래서 기술 부채는 잘못이 아니라 결정이에요. 오픈 날짜를 지키려고 일부러 지는 빚도 있어요. 이 문서가 다루는 건 빚을 안 지는 방법이 아니라, 지금 이자가 얼마나 나가고 있는지 사장님이 읽는 방법이에요.
왜 견적이 갑자기 뛰나
사장님이 이 단어를 처음 만나는 자리는 대개 견적서예요. 반년 전에 반나절이던 요청이 이번엔 며칠로 오면 이유를 알 수 없어요. 그 차이의 대부분은 고치는 시간이 아니라 찾고 확인하는 시간이에요.
| 같은 한 줄 요청 | 부채가 적을 때 하는 일 | 부채가 쌓였을 때 하는 일 |
|---|---|---|
| 가격을 올려 주세요 | 가격을 관리하는 한곳을 고쳐요 | 가격이 적힌 곳을 전부 찾고, 빠뜨린 곳이 없는지 화면을 하나씩 열어 봐요 |
| 할인 규칙을 하나 추가해 주세요 | 규칙이 모여 있는 자리에 한 줄 더해요 | 결제·장바구니·주문서에 각각 흩어진 계산을 세 번 고치고, 세 곳의 금액이 같은지 대조해요 |
| 이 버튼 문구만 바꿔 주세요 | 그 화면 하나만 손대요 | 같은 화면을 복사해 만든 페이지가 몇 개인지 세고, 어디까지 바꿀지 먼저 정해요 |
| 결제 수단을 하나 더 붙여 주세요 | 결제를 다루는 자리에 하나 더 꽂아요 | 옛 결제 처리와 새 결제 처리가 뒤섞이지 않게, 기존 흐름을 먼저 정리해요 |
| 이 화면을 고쳐 주세요 | 고치고 자동 점검을 돌려요 | 고친 뒤 다른 데가 안 깨졌는지 사람이 눌러서 확인해요. 이 확인이 고치는 시간보다 길어요 |
오른쪽 칸을 보면 공통점이 하나 보여요. 찾기와 확인하기예요. 이 둘은 결과 화면에 안 나타나요. 그래서 사장님 눈에는 "아무것도 안 바뀌었는데 값이 올랐다"로 보여요.
장면 1 · 외주 개발자가 견적을 설명하며 말했다
“이 부분은 손대면 다른 데가 같이 흔들려서, 넉넉하게 잡았어요.”
듣고 물러설 말이 아니고, 화낼 말도 아니에요. 되물을 문장이 정해져 있어요. "같이 흔들리는 데가 어디인지 목록으로 주실 수 있나요." 목록이 나오면 그건 진짜 부채고, 사장님은 그 목록으로 다음 결정을 해요. 목록을 못 주면 아직 파악이 안 된 상태라는 뜻이고, 그때 물을 건 금액이 아니라 "파악하는 데 얼마나 걸리나요"예요.
요청 크기와 견적 크기를 같이 적어 두세요
부채는 눈에 안 보이지만 추세는 보여요. 요청을 맡길 때마다 "요청 한 줄 · 받은 견적 · 실제 걸린 시간" 세 칸을 메모에 남기세요. 같은 크기 요청의 시간이 계속 늘어나면 그게 이자가 늘고 있다는 유일한 증거예요. 숫자 없이 하는 이 대화는 늘 감정 싸움이 돼요.
부채가 쌓이는 자리
부채는 코드 전체에 골고루 쌓이지 않아요. 자리가 정해져 있어요. 사장님이 코드를 못 봐도 증상으로는 알 수 있는 다섯 군데예요.
| 쌓이는 자리 | 어떻게 쌓이나 | 사장님이 알아채는 순간 |
|---|---|---|
| 같은 값이 여러 곳에 적혀 있는 것 | 화면을 급히 만들 때마다 가격·전화번호·영업시간을 그 자리에 직접 적어 넣어요 | 하나를 고쳤는데 다른 화면에는 옛 값이 그대로 남아 있을 때 |
| 복사해서 만든 화면 | 비슷한 페이지가 필요할 때 통째로 복사하는 게 가장 빨라요 | "이 문구 전체에서 바꿔 주세요"가 유난히 오래 걸릴 때 |
| 점검 장치가 없는 것 | 만드는 데 급해서 자동 확인을 안 붙였어요 | 고칠 때마다 엉뚱한 곳이 깨져서 손님이 먼저 알려 줄 때 |
| 오래된 남의 부품 | 만들 때 가져다 쓴 부품이 몇 년째 그대로예요 | 보안 경고 메일이 오거나, 새 기능을 붙이려는데 부품이 못 받쳐 줄 때 |
| 적어 두지 않은 결정 | "이건 이렇게 하기로 했다"가 사람 머리에만 있어요 | 만든 사람이 바뀐 뒤 아무도 이유를 모를 때. 이 부채가 가장 비싸요 |
마지막 줄이 사장님에게 가장 위험해요. 앞의 넷은 돈으로 갚을 수 있는데, 다섯째는 아는 사람이 떠나면 갚을 방법이 사라져요. 설명서 파일과 변경 기록이 이 자리를 막아 주는 가장 싼 장치예요.
괜찮은 부채와 나쁜 부채
모든 부채를 갚으려 들면 그게 또 다른 낭비예요. 팔릴지 모르는 기능을 완벽하게 만드는 건 부채를 안 지는 게 아니라 현금을 먼저 태우는 것이에요. 가르는 기준은 딱 하나예요. 갚을 날과 갚을 방법이 적혀 있는가.
몇 달 뒤에는 무엇이 임시였는지 아무도 못 가려요. 그때부터는 전부를 의심하며 손대야 해서, 작은 요청까지 값이 올라요.
같은 지름길인데 되돌릴 수 있어요. 손님이 안 쓰는 기능이면 그 부채는 갚을 필요 없이 그냥 지워도 되고, 그게 이득이에요.
오픈 전에는 일부러 빚을 져요
가장 작게 만들어 보기 단계에서 부채를 피하려 하면 오픈이 늦어져요. 이때는 빚을 지는 게 맞는 결정이에요. 다만 조건이 하나 붙어요. 어디를 급히 했는지 그날 적어 두는 것. 이 메모 한 줄이 괜찮은 부채와 나쁜 부채를 가르는 전부예요.
확인해 보세요
오픈이 다음 주인데, 할인 계산을 세 화면에 각각 적어 넣는 방식으로 급히 만들자고 해요. 지금 사장님이 할 말은?
얼마나 갚을지 정하는 법
갚는 작업 자체는 개발자나 AI가 해요. 사장님이 쥐고 있어야 하는 건 어디를 갚고 어디를 그냥 두는가예요. 여섯 걸음이면 정해져요.
- 1최근 요청 세 개의 걸린 시간을 적어요. 부채는 느낌으로 논쟁하면 결론이 안 나요. 시간이 늘어난 요청이 어느 쪽이었는지부터 봐요.
- 2다음 석 달에 손댈 곳을 하나만 꼽아요. 앞으로 안 건드릴 자리의 부채는 이자를 물지 않아요. 지저분해도 그대로 두는 게 이득이에요.
- 3그 자리만 정리 대상으로 지정해요. "전부 정리"는 견적이 안 나오고 끝도 안 나요. 자리를 좁히면 값이 계산돼요.
- 4기능 요청과 정리 작업을 다른 줄로 받아요. 한 줄로 뭉치면 무엇 때문에 오래 걸렸는지 다음에도 못 알아요. 견적서에서 줄을 나눠 달라고 하세요.
- 5정리 전후 화면이 같은지 확인할 방법을 정해요. 정리 작업은 기능이 안 바뀌는 게 정상이에요. 그래서 "바뀐 게 없다"를 증명할 방법이 곧 품질 검사예요.
- 6다 갚지 말고 멈춰요. 지금 이자가 나가는 자리만 갚고 손을 떼요. 남은 건 다음에 그 자리를 다시 손댈 때 갚아요.
정리만 하는 배포는 따로 보내요
안을 정리하는 작업과 새 기능을 같은 배포에 섞으면, 문제가 생겼을 때 원인을 못 가려요. 이전 버전으로 돌리기도 어려워져요. 정리는 그것만 따로 내보내고, 내보낸 뒤 며칠은 손님 문의를 유심히 보세요.
직접 해보기
두 번째 걸음을 오늘 해 두세요
여섯 걸음 중 사장님만 할 수 있는 게 두 번째예요. 다음 석 달에 손댈 곳 한 군데. 주문 화면인지, 예약인지, 상품 목록인지 정하는 건 장사 계획을 아는 사람만 할 수 있어요. 스튜디오에서 만드는 중인 것이 있으면 그 화면부터 열어 보고 한 군데를 꼽아 보세요.
스튜디오 열기AI에게 그대로 말하는 문장
직접 만드는 중이면 아래 문장을 그대로 옮겨 쓰면 돼요. 전문어를 몰라도 돼요. 핵심은 결과 화면은 그대로 두라고 못 박는 것이에요. 그 말이 없으면 정리하다가 기능이 같이 바뀌어요.
| 내 상황 | 그대로 보낼 문장 |
|---|---|
| 가격을 여러 곳에서 고쳐야 해요 | "가격이 적힌 곳을 전부 찾아서 한곳에서 관리하게 바꿔 주세요. 화면에 보이는 결과는 지금과 똑같아야 해요." |
| 고칠 때마다 다른 데가 깨져요 | "이 기능을 고치면 같이 영향받는 곳을 목록으로 먼저 알려 주세요. 보고 나서 진행할지 정할게요." |
| 안을 정리해 달라고 하고 싶어요 | "기능은 그대로 두고 안쪽만 정리해 주세요. 정리 전과 후에 화면이 같은지 확인하는 방법도 같이 알려 주세요." |
| 지금은 급하게 막아야 해요 | "지금은 빠른 방법으로 막아 주세요. 대신 나중에 제대로 고칠 때 무엇을 해야 하는지 메모로 남겨 주세요." |
| 왜 오래 걸리는지 모르겠어요 | "이 요청에서 오래 걸리는 부분이 어디인지, 찾는 시간과 고치는 시간과 확인하는 시간으로 나눠 알려 주세요." |
| 무엇부터 갚아야 할지 모르겠어요 | "앞으로 자주 고칠 것 같은 부분부터 정리 순서를 매겨 주세요. 이유도 한 줄씩 붙여 주세요." |
자주 묻는 것
- Q. AI로 만들면 이런 게 안 생기지 않나요?
- 생겨요. 오히려 빨리 만들어지는 만큼 빨리 쌓여요. 화면을 열 개 만드는 데 하루가 안 걸리면, 같은 값이 열 곳에 적히는 것도 하루면 되니까요. 달라진 점은 갚는 값이에요. 정리 작업을 AI에게 맡기는 건 사람에게 맡기는 것보다 싸요. 대신 정리 뒤에 화면이 그대로인지 확인하는 건 사람이 해야 해요.
- Q. 개발자가 "전부 다 뜯어야 한다"고 해요. 믿어도 되나요?
- 믿을지 말지가 아니라 두 안을 받는 게 답이에요. "지금 요청만 해내는 방법도 하나 알려 주세요. 그 방법의 값과 위험도 같이요." 두 안을 나란히 놓으면 판단이 사장님 손으로 돌아와요. 전부 뜯는 안 하나만 오는 건 견적이 아니라 통보예요. 업체 비교 관점으로 한 번 더 받아 보는 것도 방법이에요.
- Q. 부채가 얼마 쌓였는지 숫자로 알 수 있나요?
- 정확한 숫자는 없어요. 대신 관찰 셋이면 충분해요. 같은 크기 요청의 소요 시간이 늘고 있는지, 고친 뒤 다른 곳이 깨지는 일이 잦아지는지, "그건 아무도 몰라요"라는 말이 나오는지예요. 셋 중 둘이면 갚을 자리를 정할 때예요.
- Q. 아직 손님이 없어요. 신경 써야 하나요?
- 안 써도 돼요. 손님이 없을 때가 부채가 가장 싼 시기예요. 잃을 기록도 없고 멈춰도 항의할 사람이 없으니, 오히려 구조를 크게 갈아엎을 수 있는 유일한 때예요. 무거워지는 건 실제 주문과 결제 기록이 들어온 다음이에요.
- Q. 정리 작업을 손님에게 어떻게 설명하죠?
- 설명 안 해도 돼요. 눈에 보이는 변화가 없는 게 정상이에요. 다만 정리한 날은 변경 기록에 "내부 정리" 한 줄만 남기세요. 며칠 뒤 이상이 생겼을 때 원인을 되짚는 유일한 실마리가 그 한 줄이에요.
- Q. 매번 급하게 만드는 습관을 어떻게 멈추나요?
- 멈추지 않아도 돼요. 장사에는 급한 날이 계속 오니까요. 대신 규칙 하나만 지키세요. 급하게 만든 날, 그 자리에 한 줄 적기. 이 한 줄이 있으면 나중에 무엇이 임시였는지 알아낼 수 있고, 없으면 전부를 의심하며 손대야 해요.
하나 더
반년 전 반나절이던 문구 수정 요청이 이번엔 이틀로 견적이 왔어요. 가장 먼저 물을 말은?
직접 해보기
관리 습관과 붙여서 보세요
이 문서는 안쪽이 무거워지는 이야기고, 밖에서 보이는 것을 다시 맞추는 이야기는 따로 있어요. 둘을 같은 달력에 붙여 두면 한 번에 끝나요. 관리 문서의 월 점검 순서를 읽고, 거기에 "요청 걸린 시간 적기" 한 줄만 더해 보세요.
만든 뒤 관리하기 읽기더 깊이 (안 읽어도 괜찮아요)
이자의 정체는 확인 시간이에요 · 부채가 쌓인 코드에서 오래 걸리는 건 타이핑이 아니에요. 고친 뒤 다른 데가 안 깨졌는지 확인하는 일이에요. 같은 값이 네 곳에 적혀 있으면 확인할 곳도 네 곳이고, 자동 점검이 없으면 그 네 곳을 사람이 눌러 봐야 해요. 그래서 점검 기본을 붙이는 것이 부채를 갚는 가장 값싼 방법이에요. 코드를 예쁘게 만드는 게 아니라, 확인을 기계에 넘기는 거예요.
왜 정리 작업은 따로 견적이 오나 · 정리 작업은 끝나도 화면이 그대로예요. 사장님 눈에 결과가 없으니 승인받기가 어렵고, 그래서 개발자들은 기능 요청 안에 슬쩍 끼워 넣는 관행이 생겼어요. 이게 서로에게 나빠요. 사장님은 값이 왜 올랐는지 모르고, 개발자는 정리했다고 말할 자리가 없어요. 줄을 나눠 받는 편이 양쪽에 낫고, 나눠 놓으면 이번 달에 정리를 미룰지 사장님이 고를 수 있어요. 이 작업을 부르는 이름이 정리하기예요.
부채를 0으로 만들면 안 되는 이유 · 부채가 0인 상태는 존재하지 않고, 가까이 가려는 노력에도 값이 나가요. 아직 팔릴지 모르는 기능을 완벽한 구조로 만들면, 그 기능을 지울 때 그 공이 같이 사라져요. 그래서 판단 기준은 깨끗함이 아니라 다시 손댈 확률이에요. 자주 고칠 자리는 미리 정리하고, 한 번 만들고 안 볼 자리는 지저분한 채로 두는 게 맞아요. 이걸 뒤집어 하는 것이 초보가 가장 많이 하는 낭비예요.
남의 부품도 부채예요 · 가져다 쓴 부품을 몇 년 안 올리면, 나중에 한 번에 올릴 때 여러 세대를 건너뛰게 돼요. 그때는 부품 사용법 자체가 바뀌어 있어서, 올리는 작업이 새로 만드는 작업만큼 커져요. 보안 경고가 왔을 때 급히 올려야 하는데 못 올리는 상황이 여기서 나와요. 남이 만든 부품은 조금씩 자주 올리는 편이 항상 싸요.
이것만 기억하세요
- ·급하게 만든 하루가 원금이고, 그 뒤 고칠 때마다 더 나가는 시간이 이자예요
- ·견적이 뛴 이유의 대부분은 고치는 시간이 아니라 찾고 확인하는 시간이에요
- ·지름길 자체가 나쁜 게 아니에요. 어디를 급히 했는지 그날 적어 두면 갚을 수 있는 부채가 돼요
- ·앞으로 안 건드릴 자리는 지저분한 채로 두세요. 다시 손댈 자리만 갚는 게 이득이에요
- ·기능 요청과 정리 작업은 견적서에서 줄을 나눠 받고, 정리는 따로 배포해요