Technical Debt는 은유가 아니다. 그것이 당신의 Migration이 실패한 이유다.

발행: 5일 전 (2026년 1월 14일 오후 06:30 GMT+9)

6 min read

원문: Dev.to

Source: Dev.to

최근에 Dave Farley의 Managing Technical Debt 가이드를 읽었습니다. 이 글은 부채를 단순히 개발자의 불만이 아니라 비즈니스 위험으로 다루기 때문에 반드시 읽어야 합니다.

Farley의 개념에 대한 나의 생각

Farley는 “Bit Rot”—소프트웨어가 시간이 지나면서 퇴화한다는 개념에 대해 이야기합니다. 코드는 물리적으로 녹지는 않지만, 방치하면 부패합니다.

다섯 코스 식사를 만들지만 팬을 씻지도 않고 조리대를 닦지도 않으면, 결국 더 이상 요리할 수 없게 됩니다. 혼란에 마비됩니다.

실제로 팀은 종종 다음과 같은 일을 합니다.

결과: 15년 된 모놀리스가 비싼 EC2 인스턴스에서 실행되고, 모든 보안 패치가 관련 없는 모듈을 깨뜨릴 위험을 가집니다.

나의 규칙: 코드를 발견한 것보다 더 나은 상태로 남기지 않으면, 이미 부패하고 있는 것입니다.

Java 세계에서 우리는 스파게티 코드를 피하는 법을 배웠지만, 이제는 “Spaghetti Infrastructure” 를 보게 됩니다.

이 구성 부채는 코드 부채보다 더 나쁠 수 있습니다. 왜냐하면 단일 기능이 아니라 전체 환경을 무너뜨릴 수 있기 때문입니다.

개발자가 AWS 콘솔에서 인프라 설정을 수동으로 변경하는 것을 발견하면 문제가 됩니다. 제가 순수주의자라서가 아니라, 그 수동 변경이 다음에 배포 파이프라인을 실행하는 사람에게는 시한폭탄이 되기 때문입니다.

Copilot이나 ChatGPT 같은 도구는 놀랍지만, 그 영향은 팀의 규율에 달려 있습니다.

AI가 만든 보일러플레이트가 가득한 풀 리퀘스트를 보는 경우가 많습니다. 작성자는 이를 면밀히 읽지 않은 것이 명확합니다.

기억하세요: “Bit Rot”은 방치에서 옵니다. AI 코드를 무자비하게 리팩터링하고 테스트하지 않고 생성하면 방치를 10배 가속화합니다. “코딩을 더 빠르게” 하는 것이 아니라 레거시 코드를 자동으로 만드는 것입니다.

AI가 만든 코드를 술에 취한 인턴이 작성한 코드처럼 두 배로 검토하세요.

“테스트는 나중에 작성하자.”
아니요, 절대 안 됩니다. 기능이 배포된 뒤에 유닛 테스트를 뒤늦게 채워 넣는 팀을 본 적이 없습니다.

테스트 부채는 속도를 죽입니다. 신뢰할 수 있고 빠른 자동화 테스트 스위트(수동 QA가 아니라)가 없으면 팀은 코드를 변경하는 것을 두려워합니다. 두려움은 리팩터링을 멈추게 하고, 비트 부패를 가속화하는 악순환을 만듭니다.