기술 부채

Technical Debt

쉽게 말하면

기술 부채는 급해서 택한 지름길이 나중에 이자까지 붙어 돌아오는 빚이에요. 지저분한 코드 때문에 고칠 때마다 더 드는 시간이 이자고, 언젠가 제대로 고치는 비용이 원금이에요.

비유가 깨지는 곳 빚이 늘 나쁜 건 아니에요. 출시 시점을 맞추려고 일부러 지는 부채는 합리적일 수 있지만, 언제 어떻게 갚을지 계획이 있어야 하고 한 번에 크게보다 조금씩 갚는 편이 안전해요.

지금 지름길을 택한 대가로 나중에 갚아야 할 비용을 빚에 빗댄 말. 워드 커닝햄(Ward Cunningham)이 1992년에 처음 썼다. 원금은 언젠가 제대로 고치는 비용이고, 이자는 지저분한 코드 때문에 매번 더 드는 개발 시간이다.

의도적인 부채는 합리적일 수 있다. 출시 시점을 맞추거나 프로토타입으로 시장을 확인할 때다. 다만 언제 어떻게 갚을지 계획이 있어야 한다
자동 테스트를 생략하는 것이 대표적인 예다. 출시는 성공하지만 이후 변경할 때마다 예상치 못한 버그가 생긴다
갚는 방법은 리팩터링, 빠진 테스트 추가, 설계 개선이다. 한 번에 크게 갚기보다 기능을 만들 때마다 조금씩 갚는 편이 위험이 작다(보이스카우트 규칙, 정리(Tidying))
심플 디자인 강의의 말로는, 리팩터링할 시간이 없는 게 아니라 리팩터링을 안 해서 시간이 없는 것이다

이자가 쌓이고 있다는 신호

코드를 이해하는 사람이 줄어드는 문제는 인지 부채라는 이름으로 따로 다룬다. 왜 구조에 투자하는지의 경제학은 구조와 동작, 옵션의 가치에 있다.

인지 부하
작업 기억이 한 번에 처리해야 하는 양. 문제 자체의 복잡함과 표현 방식에서 오는 복잡함으로 나뉜다.
섣부른 최적화
"섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.
필요 낭비 (Type 1 무다)
부가가치를 만들지는 않지만 지금은 없앨 수 없는 일. 도요타 생산 방식(Toyota Production System)에서 나온 린(Lean) 사고는 활동을 부가가치 활동(Value-Added), 순수 낭비(Type 2 무다), 필요 낭비(Type 1 무다)로 나눈다. 소프트웨어 개발에서는 프로덕션 코드를 쓰는 일을 빼면 대부분이 둘 중 하나의 낭비다.
코드 냄새
당장 버그는 아니지만 이해나 변경 비용을 높이는 구조적 신호. 리팩터링을 언제 시작하고 멈출지에 정확한 공식은 없어서, 냄새라는 어휘로 직관을 공유한다.
AI 시대 엔지니어의 역할 변화
AI가 코딩을 맡으면서 개발의 무게가 기획·검증·학습으로 옮겨 가고, 병목은 리뷰와 결정으로 이동한다.

보기 옵션

글자 크기 100%자간 0.00줄 간격 1.7