기술 부채를 갚자고 설득하는 법 — PM과의 협상 실전

게시일: 2025년 9월 5일 · 13분 읽기

기술 부채 갚자고 2주 달라고 했다가 거절당한 경험이 수십 번이다

기술 부채를 갚으려면 PM을 설득해야 한다. "코드를 정리하고 싶어요"라는 말로는 충분하지 않다. 비즈니스 언어로 말해야 한다.

수십 번의 실패와 성공을 거쳐 배운 "기술 부채 협상 가이드"다.

왜 "기술 부채를 갚아야 한다"는 말이 작동하지 않는가

PM 입장에서 들리는 것:

"나는 코드를 정리하고 싶고, 새로운 기능을 추가하는 것보다 그것이 더 중요해요"

PM이 듣는 것:

"현재 실패한 기능 중에 덜 중요한 것을 미루고 싶어요"

차이가 크다.

실패한 협상 기억

3년 전:

나: "이 코드는 정말 엉망이에요. 기술 부채가 너무 많아서 새 기능을 추가하기 어렬어요. 2주 시간을 주실래요?"

PM: "새 기능이 3개 기다리고 있는데요?"

나: "하지만 지금 정리하지 않으면..."

PM: "일단 기능부터 해주시고, 나중에 시간이 있으면..."

결과: 거절

이건 감정적 호소일 뿐이다.

성공한 협상 방식

1단계: 기술 부채를 정량화한다

안 좋은 설명: "레거시 코드가 너무 많아요"
좋은 설명: "현재 DB 마이그레이션에 4주가 예상되지만,
           리팩터링을 하면 2주로 단축될 수 있어요"

시간을 구체적으로 제시해야 한다.

2단계: 비즈니스 임팩트를 프레이밍한다

안 좋은: "코드 품질이 저하되고 있어요"
좋은: "현재 버그 수정에 월 20시간이 걸리는데,
      리팩터링으로 월 8시간으로 줄일 수 있어요.
      그러면 새 기능 개발 시간이 월 12시간 증가해요"

기술 용어가 아니라 시간/비용/속도로 말해야 한다.

3단계: 증분적 접근을 제안한다

안 좋은: "한 달을 달라고 하면 모두 정리할게요"
좋은: "스프린트마다 해당 기능의 레거시 코드 20%씩 정리하면서
      진행하면 어떨까요? 그래서 6주면 충분할 거 같아요"

한 번에 하지 말고, 스프린트에 분산시키자.

실제로 작동한 협상

1년 전:

나: "장바구니 기능을 추가하는 데 예상 3주가 걸리는데요,
     현재 코드 구조 때문이에요"

PM: "그럼 리팩터링하면 얼마나 단축되죠?"

나: "구조를 개선하면 1주 반으로 단축되고,
    다음 결제 기능도 2주 → 1주로 단축될 거 같아요"

PM: "그러면 투자 대비 리턴이 있겠네요"

나: "네, 그래서 장바구니 작업을 시작하기 전에
    3일만 리팩터링을 하고 싶은데요"

PM: "좋아요, 시작하세요"

결과: 승인

어떤 달라진가?

• 구체적 숫자 (3주 vs 1주 반)
• 미래 기능까지 영향 (결제 기능도 빨라짐)
• 비즈니스 용어 (투자 대비 리턴)
• 작은 요청 (2주가 아니라 3일)

"20% 규칙" 제안

가장 현실적인 접근: 각 스프린트의 20%는 기술 부채 상환에 쓴다.

제안서:
"현재 속도: 주 200 포인트 기능 추가
제안: 주 160 포인트 기능 추가 + 주 40 포인트 기술 부채 상환

결과:
- 6주 후: 기술 부채 240 포인트 감소
- 이후 개발 속도 향상으로 주 210-220 포인트 가능"

이것이 가장 현실적이고 합리적인 제안이다.

기술 부채의 종류별 우선순위

모든 기술 부채를 갚을 수는 없다. 우선순위를 정하자:

1순위: 개발 속도를 저하시키는 부채

• 구식 프레임워크
• 혼란스러운 폴더 구조
• 의존성 문제

2순위: 버그를 일으키는 부채

• 에러 처리 빠진 부분
• 엣지 케이스 미처리
• 모호한 데이터 모델

3순위: 유지보수성 부채

• 문서 부족
• 테스트 부족
• 복잡한 로직

1순위부터 설득하자. 3순위는 나중이다.

PM과의 신뢰 구축

한 번 "기술 부채 개선"을 약속하고 성과를 내면, PM은 믿게 된다.

첫 번째 제안:

약속: "3일간 테스트를 추가하면,
      버그 리포트가 50% 줄어들 거 같아요"

결과: 실제로 1주일 후 버그 20% 감소

이 한 번의 성공이 다음의 신뢰를 만든다.

실패에서 배운 것

실패 1: "나중에 반드시 효과가 있을 거다"

이건 작동하지 않는다. 구체적 데이터가 필요하다.

실패 2: 너무 긴 프로젝트

"2개월 리팩터링"은 PM이 들어주지 않는다. "2주" 단위로 나누자.

실패 3: 기술 용어 남용

"기술적 부채", "리팩터링", "코드 냄새" 같은 말은 PM이 모른다. "개발 속도가 느려져요", "버그가 많아져요", "새 기능 추가가 어려워요"라고 말하자.

결론

기술 부채를 갚으려면, 엔지니어링 언어가 아니라 비즈니스 언어로 말해야 한다.

"코드가 복잡하다" → "새 기능 추가가 2배 시간이 걸린다"
"리팩터링하고 싶다" → "2주면 버그 50% 줄일 수 있다"
"기술 부채가 심하다" → "지금 안 하면 3개월 후 개발이 멈춘다"

숫자와 명확한 이득만이 PM을 설득한다.