기술 부채 (Technical Debt)

기술 부채(Technical Debt)는 소프트웨어의 설계·구현 상태 때문에 이후 변경에 추가로 드는 비용을 부채에 빗댄 개념입니다. 당장의 기능은 작동해도 구조를 이해하거나 수정하는 데 더 많은 노력이 들 수 있습니다. 부채를 줄이는 작업과 그대로 둔 채 변경할 때의 부담을 비교하며, 모든 버그나 미완성 기능을 같은 뜻으로 묶지는 않습니다.

변경할 때 드러나는 추가 비용

마틴 파울러의 기술 부채 해설은 내부 품질의 결함 때문에 기능을 추가하는 데 드는 여분의 노력을 부채의 이자로 설명합니다. 화면에서 오류가 보이지 않아도 여러 모듈이 서로 얽혀 작은 수정의 영향을 찾기 어렵다면 변경 비용이 늘어납니다. 반대로 코드가 오래됐다는 이유만으로 부채의 크기를 판단하기는 어렵습니다. 실제로 어떤 변경을 얼마나 어렵게 만드는지가 설명에 포함돼야 합니다.

같은 입력 검증이 여러 API에 복사돼 있다면 규칙을 바꿀 때 각 위치를 찾아 고쳐야 합니다. 한 곳을 빠뜨리면 서로 다른 결과가 나오므로 확인 범위도 넓어집니다. 공통 처리로 정리하는 데 드는 작업은 부채를 줄이는 비용에 해당합니다. 이 사례는 비용 구조를 설명하는 예시이며, 중복 코드의 줄 수만으로 실제 작업 시간을 계산한 결과는 아닙니다.

기술 부채는 금융 대출과 같은 고정 계산식을 갖지 않습니다. 파울러는 변경하지 않는 코드에서는 이자에 해당하는 추가 노력이 발생하지 않을 수 있다고 설명합니다. 앞으로 자주 바꿀 부분과 안정적으로 유지할 부분의 우선순위가 달라지는 이유입니다. 코드의 복잡성, 변경 빈도, 장애 위험을 함께 보아야 개선 작업의 목적이 구체적으로 드러납니다.

의도한 선택과 뒤늦게 발견한 문제

파울러의 기술 부채 사분면은 부채가 의도적이었는지와 신중한 선택이었는지를 서로 다른 축으로 다룹니다. 출시 시한 때문에 한계를 알고 단순한 설계를 택한 경우와, 설계 경험이 부족해 문제를 인식하지 못한 경우를 구별하는 방식입니다. 의도했다는 사실만으로 선택이 적절해지는 것은 아니며, 예상한 이익과 이후 부담을 설명할 수 있어야 합니다.

개발을 진행하면서 도메인을 더 잘 이해해 처음 설계의 부족함을 발견하는 경우도 있습니다. 당시 정보로는 합리적이었던 구조가 새 요구사항에는 맞지 않을 수 있다는 뜻입니다. 이런 변화까지 처음 작성자의 실수로만 다루면 어떤 지식이 새로 생겼는지 놓칩니다. 사분면은 책임을 붙이는 등급표보다 문제의 발생 경로와 대응을 이야기하는 도구로 읽는 편이 맞습니다.

버그는 기대한 동작과 실제 동작이 어긋나는 문제이고, 기술 부채는 이후 변경에 드는 부담을 설명합니다. 두 현상은 함께 나타날 수 있지만 같은 분류는 아닙니다. 아직 만들지 않은 기능도 그 자체만으로 부채가 되지는 않습니다. 기능을 늦춘 결과 우회 코드가 쌓이고 향후 변경을 어렵게 만든다면, 그 구체적인 구조와 비용을 따로 기록할 수 있습니다.

개선 범위와 우선순위의 판단

기술 부채 해설의 점진적 개선 논의는 자주 변경하는 영역에서 조금씩 구조를 개선하는 접근을 제시합니다. 전체를 다시 쓰는 일과 필요한 부분을 정리하는 일은 비용과 위험이 다릅니다. 새 기능을 추가하면서 관련된 중복을 줄이고 경계를 명확하게 하면 그다음 수정의 확인 범위를 좁힐 수 있습니다. 개선 중에도 기존 호출자가 기대한 동작이 유지되는지는 별도의 검증 대상입니다.

작업 기록에는 ‘구조가 좋지 않음’보다 구체적인 영향을 적는 것이 유용합니다. 어떤 API 규칙을 바꿀 때 어느 파일들을 함께 수정하는지, SDK 변경이 어떤 호출자에 영향을 주는지, 테스트하기 어려운 이유가 무엇인지가 그 내용입니다. AI 코딩 도구로 코드를 빠르게 만들었더라도 같은 기준을 적용합니다. 생성 속도와 다음 변경의 비용은 서로 다른 관측입니다.

상환 비용과 기대 절감액은 대개 추정치이므로 측정 결과처럼 단정하지 않습니다. 개선 전후에 실제 변경 시간, 실패 원인, 검증 범위가 어떻게 달라졌는지 기록하면 다음 판단의 근거가 됩니다. 새로운 추상 계층을 추가한 것이 오히려 이해 비용을 높일 수도 있습니다. 정리한 코드의 양보다 앞으로 필요한 변경을 수행하는 데 어떤 부담이 줄었는지 확인하는 방식이 적합합니다.