엔지니어링 팀을 위한 기술 부채 협상 케이스(Technical Debt Negotiation Case)

Description

엔지니어링은 '기술 부채 스프린트'를 계속 요청하지만 비즈니스 임팩트를 설명하지 못하고, 리더십은 '지금은 안 돼'를 반복합니다. 이 프롬프트는 기술 부채를 비즈니스 언어 — 출시 속도, 사고 리스크, 기회비용 — 로 번역하는 데이터 기반 케이스를 만들어, 양쪽이 현실적인 상환 계획에 합의할 수 있게 합니다.

엔지니어링과 비즈니스 리더십 모두가 지지할, {{product_name}}의 기술 부채(technical debt)를 다루는 설득력 있는 비즈니스 케이스를 만들어주세요.

## 컨텍스트
- 제품: {{product_name}}
- 엔지니어링 팀 규모: {{team_size}}
- 현재 스프린트 벨로시티 트렌드: {{velocity_trend}} (안정, 하락, 변동성)
- 엔지니어링이 식별한 상위 기술 부채 항목: {{debt_items}}
- 기술 부채로 인한 최근 사고 또는 지연: {{recent_incidents}}
- 다가오는 제품 우선순위: {{upcoming_priorities}}

## 1단계: 행동하지 않을 때의 비용 정량화
각 주요 기술 부채 항목에 대해:
1. 이 이슈를 우회하는 데 스프린트당 엔지니어링 시간이 얼마나 쓰이는가? (시간/스프린트)
2. 지난 6개월간 몇 개의 사고나 버그를 일으켰는가?
3. 이 부채로 어떤 기능이 막히거나 느려지는가?
4. 다루지 않을 때 큰 실패 리스크는? (확률 × 임팩트)

"세금률(tax rate)" 계산: 각 스프린트의 몇 %가 신규 기능 개발 대신 부채 관련 작업으로 소비되는가?

## 2단계: 비즈니스 임팩트로 번역
1. 벨로시티 세금: "이 3개 부채 항목 때문에 잠재 벨로시티의 X%로 출시 중"
2. 사고 리스크: "이 [item]을 다루지 않으면 다음 분기 Z 심각도 장애 가능성이 Y%"
3. 기회비용: "[item]을 다루면 [feature]이 잠금 해제되고, 추정 임팩트는 [metric]"
4. 채용 임팩트: "기술 부채가 신규 엔지니어 적응 시간을 N주 늘리고 있음"

## 3단계: 계획 제안
1. 부채 항목 우선순위: 비즈니스 임팩트, 수정 노력, 지연 리스크 기준
2. 배분 모델 제안: 스프린트 용량의 X%를 부채 상환에 전담
3. 어느 항목이 언제 다뤄질지 보여주는 3 스프린트 로드맵 작성
4. 각 항목에 측정 가능한 결과 정의 (예: "배포 빈도가 주간에서 일간으로 증가")
5. 기능 작업과 함께 점진적으로 다룰 수 있는 부채 항목 식별

## 4단계: 요청 프레이밍
- 한 페이지 경영진 요약: 문제, 비용, 계획, 예상 ROI
- 예상 반론 답변 준비: "나중에 할 수 없나?", "도움이 될지 어떻게 알지?", "어떤 기능을 미뤄야 하나?"
- 30일 파일럿 제안: 한 팀 용량의 20%를 부채 상환에 전담하고 벨로시티 임팩트 측정

Customize This Prompt