“기술 부채”가 아니라 그저 “엉망인 상태”다

개발팀이 기술 부채라고 부르는 문제 대부분은 미래 비용을 알고 선택한 부채가 아니라, 미숙한 작업·취향 차이·예상하지 못한 복잡성이 뒤섞인 엉망인 상태에 가까움 금융 부채는 계약 시점에 규모·비용·조건을 알 수 있지만 기술적 결정의 비용은 대개 나중에 드러나므로, 부채 은유가 전제하는 비용 예측 가능성과 맞지 않음 성능을 나중에 개선할 계획으로 단순한 SQL 구조를 택하는 선택은 부채일 수 있지만, 느리고 불안정한 테스트처럼 개발 속도조차 높이지 못하는 문제는 기술 부족이나 부주의에 해당함 AWS Lambda 기반 이벤트 주도 시스템처럼 확장성을 기대한 선택이 추적과 계측의 어려움으로 돌아오는 경우는, 비용을 알고 진 빚이 아니라 경험의 경계에서 발생한 예상 밖의 결과임 소프트웨어를 집이나 작업 공간처럼 지속적으로 청소·정리·재구성해야 하는 대상으로 보면, 문제를 무책임한 차입으로 오해하지 않고 현재 필요한 유지보수로 다룰 수 있음 “기술 부채”가 만드는 잘못된 인상 개발자끼리는 기술 부채라는 표현을 쓰더라도, 비개발 직군과 대화할 때는 피하는 편이 나음 실제로는 미래 비용을 감수한 의도적 선택보다 단순한 엉망인 상태(mess) 를 가리키는 경우가 많음 비개발자는 이를 개발자가 일을 제대로 하지 못했거나 이전 팀의 방식을 마음에 들어 하지 않을 때 쓰는 말로 받아들일 수 있음 미리 알지 못했던 문제까지 기술 부채라고 부르면, 조건을 읽지 않고 빚을 낸 사람처럼 보여 진지하지 않은 인상을 줌 이전에 소개한 기술 부채를 다루는 방법에서도 이 은유에 관한 긴 문제 제기를 도입부에서 덜어내야 했음 금융 부채와 기술적 결정의 차이 기업에는 적정한 부채 규모가 있으며, 그 수준이 반드시 0일 필요는 없음 부채가 너무 적으면 더 비싼 자본인 지분에 지나치게 의존할 수 있음 충분히 차입하지 않으면 가능한 만큼 빠르게 성장하지 못하고, 현재 활용할 수 없는 미래에 돈을 남겨두게 됨 금융 부채는 차입할 때 금액과 비용을 정확히 알며, 모든 조건이 문서에 담김 실수로 금융 부채를 떠안거나 처음 접한 종류라는 이유로 비용이 갑자기 예상보다 커지는 일은 없음 따라서 기술 부채라는 표현이 성립하려면 결정 당시부터 비용과 상환 작업을 이해하고 있어야 함 실제 부채에 가까운 의도적 선택 StoryTime의 초기 SQL 쿼리는 성능보다 코드 가독성을 우선해, 대체로 쿼리 하나를 assign 하나에 대응하도록 구성함 쿼리와 사용자가 늘어나면 ...