기술부채로 저글링하기

3 min read

나는 한동안 ‘깨끗한 코드’라는 단어에 사로잡혀 살았다. 2–3년 차 즈음이었던가. 개발자로서 이제 막 어느 정도 손에 익었다는 자신감이 생기던 시기였다. 프레임워크를 자유자재로 다루고, 동료들의 코드 리뷰에도 목소리를 낼 수 있게 된 무렵이었다. 그때 내 머릿속을 지배하던 것은 언제나 더 깔끔하고, 더 정교하고, 더 완전한 코드였다.

작은 변수명 하나에도 집착했고, 로직이 조금만 중복되어도 불편했다. 설계가 단단하지 않으면 프로젝트 전체가 불안하게 느껴졌다. 밤을 새워서라도 구조를 정리해야 마음이 놓였다. 테스트 코드가 부족하면 마음이 무너져 내렸고, 주석이 덜 달리면 프로페셔널하지 못한 것 같았다. 깨끗한 코드야말로 개발자의 자존심이자 존재 이유라고 굳게 믿었다.

그런데 그 집착이 만들어낸 결과는 내가 예상하던 것과 달랐다.

시간은 늘 부족했다. 기능 하나를 내놓는 데도 몇 배의 시간이 걸렸다. 완벽을 위해 설계와 리팩터링에 매달리는 동안 마감은 멀리 달아났고, 팀은 언제나 일정에 쫓겼다. 애써 가다듬은 코드도 몇 달 지나면 다시 뜯어고쳐졌다. 사용자 요구가 바뀌었거나, 비즈니스 방향이 변했거나, 기술 스택 자체가 교체되었기 때문이다.

내가 쏟아부은 시간은 고스란히 코드에 묻혔지만, 정작 시장에서는 아무것도 배우지 못했다. 제품은 사용자 손에 닿지 않았으니 피드백이 들어올 리 없었다. 코드의 완결성에 매달린 결과는 결국 아무도 쓰지 않는 아름다운 폐허였다.

그때 깨달았다. 기술부채 없는 개발은 가능할 수 있어도, 공허하다.

기술부채를 피하려는 태도는 곧 속도를 잃게 만든다.

내가 그랬다. 기능 하나를 추가하면서도 나는 늘 “앞으로 필요할지도 모를 것들”을 상상했다. 모든 확장성, 모든 예외 상황을 대비한 코드를 짜려 했다. 지금 당장 필요한 것은 단순한 CRUD였지만, 그 위에 복잡한 아키텍처를 얹었다.

그 사이 시간은 흘렀고, 제품은 늦게 나왔다. 사용자는 기다려주지 않았다. 경쟁자는 불완전한 기능이라도 내놓아 먼저 피드백을 받았다. 시장은 속도를 가진 팀의 편이었다. 완벽을 좇던 나는 항상 뒤처졌다. 속도를 잃은 개발은 결국 학습까지 잃는다.


우리는 흔히 주식이나 예금에 단 한 푼도 투자하지 않고, 현금으로만 돈을 쥐고 있는 사람을 경제적으로 어리석다고 말한다. 현금은 가만히 있는 동안 가치가 줄어든다. 인플레이션이 그것을 잠식하고, 투자 기회를 놓친 대가는 결국 손실로 돌아온다. 눈앞의 안전을 지키는 듯 보이지만, 장기적으로는 더 큰 위험을 떠안는 셈이다.

이제 시선을 개발 현장으로 돌려 보자. 기술부채를 한 톨도 지지 않으려는 주니어 개발자가 있다. 그는 늘 깨끗한 코드를 원한다. 모든 기능은 처음부터 완전해야 하고, 설계는 흠결이 없어야 하며, 테스트는 빈틈이 없어야 한다. 얼핏 모범적이고 성실해 보이지만, 실제로는 “현금만 쥐고 있는 투자자”와 같다.

코드의 세계에도 인플레이션이 존재한다. 시장은 끊임없이 변하고, 기술 스택은 수시로 바뀐다. 지금 완벽해 보이는 코드도 몇 달 뒤면 다시 뜯어고쳐야 한다. 그 사이 제품은 사용자 손에 닿지 않고, 피드백은 늦게 도착한다. 결국 얻는 것은 안정이 아니라 뒤처짐이다.

기술부채로 저글링하기

시간이 지나면서 나는 기술부채를 다르게 보기 시작했다.
기술부채는 단순히 피해야 할 짐이 아니라, 전략적으로 선택할 수 있는 자원이었다.

  • 부채는 제품을 더 빨리 시장에 닿게 한다.

  • 부채는 불확실한 기능을 저렴하게 실험하게 한다.

  • 부채는 시행착오를 늘려 조직의 학습 속도를 높인다.

결국 문제는 기술부채 그 자체가 아니었다. 문제는 기술부채를 기록하지 않고, 관리하지 않고, 무작정 방치하는 태도였다.


내가 택한 방법은 단순했다.

우선 기술부채를 가시화하기로 했다. 코드와 작업을 “부채”라는 이름으로 불러내는 것부터 시작했다.

  • 장부화: 이슈 트래커에 “부채” 태그를 달고, 코드 리뷰 때마다 “이 부분은 부채로 남겨둘 수 있는가?”라는 질문을 던졌다.

  • 우선순위: 당장 갚아야 할 부채와 나중에 갚아도 되는 부채를 구분했다. 사용자 경험을 직접 해치는 문제는 빠르게 손봤고, 구조적인 개선은 여유가 생길 때 밀어두었다.

  • 상환 루프: 기능 개발 주기 사이사이에 작은 리팩터링을 넣었다. 거대한 개선 작업 대신, 틈틈이 작은 부채를 갚아 나갔다.

  • 문화: 코드 리뷰 때 부채를 이야기하는 문화를 만들었다. 부채를 감추지 않고, 선택적으로 감수하는 태도를 장려했다.

이 과정을 거치면서 나는 처음으로 부채와 공존하는 법을 배웠다. 무작정 도망치거나 부정하는 대신, 인정하고 관리하는 법을 알게 되었다.

기술부채 없는 개발은 공허하다. 속도를 잃고, 학습을 늦추며, LEAN하지 못하다.
중요한 것은 부채를 짓지 않는 것이 아니다. 어떤 부채를 언제, 어디서, 어떻게 짊어질지 결정하는 일이다.
기술부채 주도 개발론은 결국 현명한 빚쟁이가 되는 법이다.

부채는 짐이 아니라 성장의 자원이다. 두려움 없이 선택하고 관리할 때, 부채는 우리를 무겁게 하지 않는다. 오히려 더 빠르게 배우고, 더 멀리 나아가게 만든다.

완벽을 지키려다 속도를 놓치던 시절이 있었다. 이제는 다르다. 약간의 부채를 끌어안더라도, 나는 더 빨리 나아가고 더 많이 배우는 길을 택한다. 빚을 두려워하지 않는 순간, 길은 오히려 넓어진다.

언젠가 뒤돌아보면, 내 개발 인생을 지탱한 것은 완벽한 코드가 아니라 현명하게 감수했던 빚들일 것이다. 깨끗함의 신앙에서 시작해, 빚을 자원으로 보는 자각으로 나아가는 길. 그것이 내가 얻은 가장 값진 배움이다.