기술 부채: 빠르게 만들되, 6개월 뒤 무너지지 않는 법

코드베이스가 어느 순간부터 느껴지기 시작합니다. 새 기능을 추가할 때마다 예상보다 두 배 오래 걸립니다. 버그 하나를 고치면 다른 곳에서 또 터집니다. 처음에는 3일이면 됐을 작업이 이제는 2주가 걸립니다. 이것이 기술 부채가 쌓인 코드베이스의 증상입니다. 그리고 인디 파운더라면 누구나 이 단계를 통과합니다.

기술 부채는 대출입니다, 갚지 않으면 파산합니다

기술 부채라는 개념은 1992년 워드 커닝햄이 처음 이야기했습니다. 비유는 단순합니다. 지금 빠르게 코드를 짜는 대신, 나중에 더 많은 시간을 들여 정리해야 한다는 것입니다. 빠른 코드는 대출이고, 미래의 리팩토링이 상환입니다.

대출 자체는 나쁜 것이 아닙니다. 문제는 이자를 모르는 척하는 것입니다. 은행 대출처럼 기술 부채에도 이자가 붙습니다. 갚지 않으면 복리로 불어납니다. 어느 순간 원금보다 이자가 많아지고, 새 기능 하나 추가하는 것보다 기존 코드를 이해하는 데 더 많은 시간이 걸리는 지점이 옵니다.

MVP는 반드시 빚을 져야 합니다, 그게 MVP입니다

역설적이게도, 초기 제품에서 기술 부채를 아예 만들지 않으려는 것은 더 큰 실수입니다. PMF(제품-시장 적합성)를 찾기 전에 완벽한 코드를 쓰는 것은 방향도 모르는 채 고속도로를 닦는 것과 같습니다.

MVP 단계에서 기술 부채를 두려워하면 어떤 일이 일어납니까? 런칭이 늦어집니다. 시장 피드백이 늦어집니다. 경쟁자가 먼저 치고 나갑니다. 최악의 경우, 아무도 원하지 않는 제품을 완벽하게 만듭니다.

아무도 쓰지 않는 완벽한 코드보다, 100명이 쓰는 지저분한 코드가 낫습니다. PMF 전에는 속도가 품질보다 중요합니다. 단, 그 빚을 반드시 갚겠다는 계획이 있을 때만입니다.

PMF 전과 후, 리팩토링 타이밍이 전부입니다

기술 부채 관리에서 가장 중요한 판단은 "언제 갚느냐"입니다. 타이밍을 잘못 잡으면 불필요한 일을 합니다.

• PMF 전 (검증 단계) — 속도가 최우선입니다. 복사-붙여넣기도 괜찮습니다. 하드코딩도 괜찮습니다. 지금 짠 코드를 6개월 뒤 전부 버릴 수도 있습니다. 완벽한 아키텍처를 설계하는 데 시간을 쓰지 마세요.
• PMF 직후 (성장 직전) — 리팩토링의 최적 타이밍입니다. 방향이 확정됐고, 사용자가 생겼고, 본격적인 기능 추가가 시작되기 전입니다. 지금 투자한 시간이 앞으로의 모든 개발 속도를 높입니다.
• 성장 단계 (PMF 이후) — 새 기능 추가와 부채 상환을 병행해야 합니다. 기능 개발 시간의 20%를 리팩토링에 씁니다. 이것이 보이스카우트 원칙입니다. 코드를 건드릴 때마다 발견한 것보다 조금씩 더 깨끗하게 남깁니다.

1인 개발자가 지금 당장 할 수 있는 실전 부채 관리법

혼자 개발하는 인디 파운더에게 "코드 리뷰를 강화하세요"라거나 "테스트 커버리지 80%를 목표로 하세요"라는 말은 현실적이지 않습니다. 팀도 없고, 시간도 없습니다. 그렇다면 무엇을 해야 합니까?

• 기술 부채 목록을 만드세요 — 코드를 짤 때 "나중에 고쳐야 하는데"라고 생각하는 순간, TODO 주석을 달고 별도 문서에 기록합니다. 머릿속에 두면 잊어버립니다. 기록하면 언젠가 갚을 수 있습니다.
• 스프린트의 20%를 부채 상환에 씁니다 — 1주일에 하루는 새 기능 대신 기존 코드를 정리합니다. 처음엔 아깝게 느껴지지만, 6개월 뒤 나머지 80%의 개발 속도가 두 배가 됩니다.
• 가장 자주 건드리는 파일부터 정리합니다 — 전체를 다 정리하려고 하면 아무것도 못합니다. 지난 한 달 동안 가장 많이 수정한 파일 5개를 먼저 리팩토링합니다. 실질적인 효과가 가장 큽니다.
• 핵심 경로에만 테스트를 씁니다 — 100% 테스트 커버리지는 스타트업에게 사치입니다. 결제, 인증, 핵심 비즈니스 로직. 이 세 가지만 테스트해도 치명적인 버그의 80%를 막을 수 있습니다.

"완벽한 코드"를 추구하는 것도 기술 부채입니다

기술 부채를 두려워한 나머지 반대 방향으로 달려가는 경우도 있습니다. 오버 엔지니어링입니다. 사용자가 10명인데 마이크로서비스 아키텍처를 설계하는 것. 기능이 5개인데 플러그인 시스템을 구축하는 것. 이것도 부채입니다.

오버 엔지니어링은 두 가지 측면에서 해롭습니다. 지금 당장 개발 속도가 느려집니다. 그리고 나중에 방향이 바뀌었을 때 버려야 하는 코드가 더 많아집니다. YAGNI 원칙을 기억하세요. "You Aren't Gonna Need It." 지금 필요하지 않은 것은 만들지 마세요.

지금 필요한 것만 만드세요. 단, 나중에 필요한 것을 추가할 수 있도록 구조는 열어두세요. 이것이 인디 파운더가 지켜야 할 코드 철학입니다.

문서화와 코드 주석, 혼자 개발할 때 더 중요합니다

1인 개발자는 "내가 짠 코드니까 당연히 알겠지"라고 생각합니다. 6개월 뒤에는 다릅니다. 당신은 낯선 사람이 짠 코드를 보게 됩니다. 미래의 당신을 위해 지금 문서를 씁니다.

거창하게 생각할 필요 없습니다. 함수 하나에 왜 이렇게 짰는지 한 줄 주석을 답니다. API 엔드포인트에 입출력 예시를 붙입니다. 복잡한 비즈니스 로직은 결정의 이유를 기록합니다. 이 작업이 1인 팀의 온보딩 문서가 되고, 나중에 팀원을 뽑았을 때 인수인계 자료가 됩니다.

기술 부채를 방치한 제품의 끝은 하나입니다

기술 부채를 전혀 갚지 않으면 어떻게 됩니까? 제품이 멈춥니다. 새 기능 추가가 불가능해지는 시점이 옵니다. 버그 하나를 고치면 세 개가 새로 생깁니다. 결국 선택지는 두 가지입니다. 처음부터 다시 만들거나, 서비스를 종료하거나입니다. 두 경우 모두 비용이 엄청납니다.

한국 스타트업 씬에서도 비슷한 패턴이 반복됩니다. 초기에 빠르게 만들어 성장했지만, 코드베이스가 무거워져 개발 속도가 떨어지고, 경쟁자가 더 빠르게 치고 올라오는 경우입니다. 기술 부채는 단순한 코드 문제가 아닙니다. 비즈니스 속도의 문제입니다.

빠르게 만드세요. 빚을 지는 것을 두려워하지 마세요. 단, 이자가 쌓이기 전에 갚는 습관을 만드세요. 매주 하루, 새 기능 대신 기존 코드를 청소합니다. 그 하루가 제품의 수명을 수년 늘립니다.