기술 부채의 공포
개발자들은 본능적으로 기술 부채에 공포를 가집니다. 무서운 것, 절대 있으면 안되는 것, 존재만으로 소름 끼치는 것.
우리가 처음 경제나 금융에 대해 배울 때 "빚은 나쁜 것"이라고 배우는 것과 똑같습니다. "빚"을 바라보는 관점을 "앞으로 갚아야 할 나의 책임"이라고 생각하는거죠.
로버트 기요사키의 책 "부자 아빠 가난한 아빠"에서 일관되게 주는 메시지 중 하나는 "빚을 나를 짓누르는 것이 아니라 내 자산을 더 크게 만들 수 있는 레버리지로 활용하라"라는 겁니다.
저는 이 책 내용 전체에 동의하지는 않습니다만, 저 관점만큼은 굉장히 현명하다고 생각합니다.
우리가 은행 등에서 돈을 빌리면, 원금 뿐만이 아니라 이자가 붙습니다. 이자의 부담에 짓눌려 빨리 갚아버리고 싶은 마음이 가득해집니다.
하지만 조금 바라보는 시선을 바꿔 봅시다. "나가는 이자"보다 "벌어들이는 돈"이 더 많다면 어떨까요?
예컨데, 은행 대출 이자가 5%인데, 10% 특별 예금이 있다면? 세금을 제외한다면 5%가 무조건 이득일 겁니다. 이런게 바로 레버리지입니다.
기술 분야도 똑같습니다. 이 순간에는 "빚"을 지지만 "더 큰 이익을 기대할 수 있는 것"이 기술 부채입니다.
어떻게 해도 기술 부채는 생긴다.
놀랍게도 언제든 기술 부채는 생깁니다. 검증된 아키택쳐, 최신의 기술 등도 시간이 흐르면 레거시가 됩니다.
2000년대 초반을 기억합니다. 객체지향이라는 말이 뜬구름 잡던 시기였어요. 함수만 제대로 작성해도 박수받던 시절이었습니다. 그게 그 시기의 검증된 아키택쳐였고 최신 기술이었거든요.
2025년 현재는 이미 객체지향을 넘어 함수형 프로그래밍이 언어 안에 내장되어 있습니다. 20년 전 생소했던 MVC는 지금은 못다루는 이가 없죠.
모든 것은 레거시가 됩니다. 우리가 어제 만들었던 코드도요.
그러니까 너무 최신에 집착하지 마세요. 검증된 아키택쳐 패턴을 따르는 건 훌륭하지만, 이 아키택쳐가 "왜" 이런 구조를 택했는지 생각해보지 않는다면 그저 패스트 팔로워가 될 뿐입니다.
부채 비율 조정하기
기술 부채가 불가피하다는 것을 인정하고 나면 이제 우리는 기술 부채를 어디까지 짊어질 것인가를 결정해야 합니다.
저는 이 기준을 시간 대비 어느 수준까지 확장성 있는 구조를 가져갈 것인가.로 생각합니다.
예컨데 "모두 하드코딩"으로 간다면 전혀 확장성이 없는 구조일 겁니다. 반대로 최대한 플렉서블한 구조로 간다면 확장성은 생기지만 코드를 작성하는 데 아주 오래 걸리겠죠.
대부분의 숙련된 개발자들은 이를 본능적으로 압니다. 그래서 프로젝트 기간이 정해지면 도출해 내야 하는 결과를 가지고 역산을 시작하죠. 이정도 기간이면 이정도의 코드를 만들 수 있겠구나..라고 머리속으로 계산하는 거에요.
물론 아몰랑 개발자들 중에서는 기간이 충분함에도 확장성은 전혀 없는 구조로 개발하시는 분들도 있습니다.
그래서 대부분의 숙련자들은 특별한 외부 요인이 없는 이상 대부분 개발 일정을 맞춰 냅니다.
시간이 많이 부족하다면 일부 코드를 하드코딩하고, 아주 조금의 엣지 케이스만 생겨도 오류가 나긴 하지만 해피 케이스에서는 아주 잘 작동하는 코드를 만들어내요.
반면 시간이 아주 많다면 수많은 엣지케이스들을 문제 없이 처리하고 데이터 기반으로 동작하는 코드를 만들어내고요.
이 중간 어딘가의 균형을 잡는 것이 사실 가장 어렵습니다. 어디까지 기술 부채를 쌓아갈 것인가.
비개발 직군들은 이런 점을 잘 이해하지 못하실 수도 있습니다. "잘 동작하면 됐지 머."라고 치부하기 쉬워요.
하지만 개발자들이 굳이 하드코딩해도 되는데 데이터 기반 코드 조각을 만드는 건, 추후 어떤 변경이 생겼을 때 가능한 빨리 변경을 적용하기 위해서거든요.
무엇이 중요한가.
이제 부채 비율을 조정해야 한다는 걸 알았다면 구체적인 사례로 한 번 생각해 보죠.
비즈니스의 근간을 지탱하는 코어 로직은 중요합니다. 이해하기 쉬운 예로 쇼핑몰에서는 상품을 보여주고, 결제를 하는 부분이 가장 중요할 꺼에요. 쇼핑몰의 존재 목적 자체가 "상품의 판매"니까요.
이런 이유로 코어 로직은 최대한 하드코딩을 줄이고 테스트 케이스를 많이 만들고 여러 엣지 케이스에 대응하려고 애씁니다.
반면 "관리자"페이지는 어떨까요? 대부분의 관리자 페이지는 거의 바뀌지 않습니다. CRUD만 잘 되도 특별한 문제가 없어요. 간혹 오류가 나도 그런가보다 하고 우회로를 찾을 수도 있습니다. 정 안되면 데이터베이스에서 직접 데이터를 조작할 수도 있죠.
파이썬의 Django 프레임워크를 한 번 생각해 보면 쉽습니다. Django 자체도 잘 작성된 프레임워크기는 하지만, 이 프레임워크가 가장 사람들에게 어필했던 부분은 "관리자" 기능을 자동으로 만들어준다는 거였습니다. 데이터베이스 툴의 기본적인 기능을 웹에서 테이블 스키마만 가지고 만들어주거든요.
위 두 케이스는 극명하게 특성이 갈리기 때문에 사실 별 문제가 없습니다. 코어 로직은 기술 부채를 가능한 줄일 것, 거의 변하지 않는 페이지는 하드코딩하거나 자동으로 생성되어도 상관없음.
문제는 그 중간 어디쯤입니다. 실제로 기술 부채를 어디까지 짊어지고 가야 하는가에 대해서 경험적 판단을 해야 하거든요.
예컨데 위의 쇼핑몰의 경우를 생각해 봅시다. "할인" 이벤트는 코어 로직일까요? 아닐까요?
당연히 둘 다 아닙니다.
일반적으로 할인은 기간을 정해서 하는 거고, 대상도 신규 고객, 단골..등 여러 분야로 나누어지거든요. 따라서 "거의 안 변하는" 케이스는 아니에요.
코어 로직인가? 를 물어봤을때도 애매합니다. 할인을 주기적으로 하기는 하는데, 그 내용이 계속 바뀌어요. 개발의 세계에서는 아주 사소한 거 하나만 바뀌어도 그냥 새로 개발이기 때문에 코어 로직이라고 분류하기도 어렵죠.
이 때 우리는 할인 빈도와 반복성, 그리고 우리에게 주어진 기간을 가지고 계산을 해 봐야 하는 겁니다. 어찌 보면 일회성 코드에 가까운 구조를 가져갈 지, 다음에도 할인율과 기간만 바꾸면 또 쓸 수 있게 만들지.. 등을 따져보는거죠.
어떤 기능이 중요해요? 라고 물었을 때 "모두 다요."라는 답변이 나온다면 경계해야 합니다.
"모두 다"라는 건 사실 "그 어떤 것도 중요하지 않다."와 동의어니까요. 또한 비즈니스를 설계하는 사람이 우선 순위에 대한 개념 없이 설계를 했다는 뜻이기도 합니다.
무작정 엉망으로 만들라는 뜻이 아니다.
당연히 무작정 엉망으로 만들면 안됩니다.
하드코딩 정도는 사실 애교입니다. 아키택쳐가 무너지면 나중에 그 무엇도 손댈 수 없어서 새로 만들기 신공을 발휘해야 합니다.
2010년대까지의 PHP가 그랬습니다. 모든 파일이 서로를 참고하고 있어서 한군데를 고치면 기능 백개가 영향을 받고는 했어요. 누군가가 확실히 구조를 알고 있으면 별 문제가 없는데, 그 담당자가 퇴사하면 하늘에 붕 떠버리는 거에요.
그렇다고 훌륭한 아키택쳐를 만들어야 한다며 몇 달씩 고민하고 있는 것도 그닥 추천하고 싶지는 않습니다.
개발에 어느 정도 자신감이 붙은 분들이 가끔 우리만의 성을 세우겠다며 스프링 프레임워크 위에 새로운 기술 스택을 쌓는 것도 봤는데, 그러지 맙시다. 이건 개인의 취미생활이거나 큰 솔루션 회사의 미래 먹거리일 수는 있어도, 당장 내일 출시해야 하는데 언제까지 아키택쳐를 고민하고 있을 수는 없습니다.
진짜 기술 부채는 무엇인가.
진짜 기술 부채는 "지금의 판단이 추후 나의 발목을 잡는 것"입니다. 아 몰랑 퇴사하면 그만이야.
스타트업처럼 자신의 서비스를 파는 회사의 경우 자기가 작성한 코드를 나중에 자기가 또 수정해야 합니다. 그래서 더욱 기술 부채를 안 지려고 애쓰는 경향이 있죠.
개발자들은 코드를 보고 "누가 이따위로 짰어?" 라고 욕하다가 git 로그를 보고는 "아 내가 그랬구나?" 라고 현타가 오는 경우가 많아요. 이렇게 현타를 몇 번 쎄게 맞고 나면 코드 작성에 더 긴 시간을 들이게 되죠.
자, 우리 현실적으로 생각해 봅시다. "발목을 잡는 추후"라는 게 대체 언제쯤일까요? 다음달? 반년 뒤? 일년뒤? 십년뒤?
저의 기준은 이렇습니다.
일년 내에 나에게 부메랑이 날아올 것 같으면 기술 부채를 지면 안됩니다. 이건 레버리지를 일으키기 전에 구덩이에 빠져버리는 꼴이거든요.
일년에서 삼년 사이라면, 프로젝트 기간이 조금 늘어나더라도 혹은 야근을 해서 내 건강과 코드의 품질을 바꿔야 한다 하더라도 빡빡하게 코드를 작성해야 합니다.
삼년 정도라면 그냥 저냥 괜찮습니다. 조금 신경써서 작성하기는 하지만 출시 일정에는 무리가 없는 레벨에서 코드를 짜요.
오년 이상이라면 조금 고민해봐야 합니다. 오년 후면 보통 세상이 바뀝니다. 내가 아무리 잘 작성해도 내 코드는 엄청난 레거시가 되어 있을 테니까요.
비즈니스 타이밍과 기술 부채의 트레이드오프
기술 부채는 종종 '투자 유치 전까지', '경쟁사보다 한 달 먼저 출시하기 위해'와 같이 명확한 비즈니스 목표를 위한 담보 대출과 같습니다.
"이번 스프린트에서 이 기능을 출시하면 기술 부채가 쌓이지만, 우리 회사의 생존 확률은 올라간다" 이런 식이에요.
하지만 사람과 불확식성을 갈아서 비즈니스 임팩트만 무한대로 높일 수는 없습니다. 이자는 끊임 없이 붙고 있거든요.
빚을 갚아야 할 때
비슷한 기능을 만드는 데, 이전에는 일주일이 걸렸는데 지금은 한 달이 걸린다면? 이제는 빚을 갚아야 할 시간입니다.
신규 기능 추가를 멈추고, 기존 코드베이스를 정리하세요. 빚을 갚고, 기록하고, 갓 만든 시스템처럼 통일성을 유지하세요.
경영진 입장에서는 "아무것도 안 바뀌었는데 개발자들만 호들갑 떠는 시간"이라고 생각하실 수도 있습니다만, 사실 그런거 아닙니다.
자동차가 잘 굴러가려면 기름도 넣어야 하지만, 주기적으로 타이어가 터지지는 않았는지, 엔진에 문제가 없는지 체크해야 하는 것과 똑같습니다. 때로는 워셔액도 갈아주고 에어컨 필터도 바꾸자고요.
경영진 설득하기
경영진에게 기술 부채를 설명할 땐 추상적인 단어 대신 돈과 시간으로 번역해야 합니다.
"A안으로 가면 이번 주에 출시 가능하지만, 다음 분기에 2주간의 추가 작업이 필요합니다. B안은 3주 걸리지만 추가 작업은 없습니다"처럼 명확한 비용 청구서를 제시하세요.
선택은 경영진이 하도록 하되, 각 선택지가 미래에 어떤 청구서로 돌아올지 알려주는 것이 시니어 개발자의 역할입니다.
