1. 철수 비용 시뮬레이션
매몰비용은 경영 판단을 흐립니다.
전통적 fixed-bid 계약에서 프로젝트를 중단했을 때의 손실과 유연한 DaaS/Staff Augmentation 모델을 비교합니다.
누적 비용 비교
슬라이더를 움직여 철수(취소)를 결정하는 월을 변경하세요.
전통적 리스크 (fixed-bid)
해지 위약금 및 중간 산출물 매입 의무가 자주 적용되어 매몰비용 노출을 극대화합니다.
DaaS 리스크 (유연 계약)
수행된 작업에 대해서만 지불합니다. 언제든 중단할 수 있어 피해가 커지기 전에 철수 결정을 내릴 수 있습니다.
언제든 취소할 수 있는 능력은 공급사가 높은 품질을 유지하도록 동기부여합니다.
2. vendor lock-in과 "투명성"의 구조
lock-in에 대한 두려움은 내부를 볼 수 없어서 생깁니다.
블랙박스를 방지하고 자율적 통제를 회복하는 요소를 비교합니다.
블랙박스 개발
상세 스펙은 공급사 머릿속에만 있습니다
-
✕
모호한 코드 소유권
커스텀 프레임워크와 라이브러리는 다른 팀의 인수를 어렵게 합니다.
-
✕
문서 부족
작동하는 제품은 받지만 그 뒤의 "왜"는 받지 못합니다.
-
✕
인적 의존
핵심 인력이 떠나면 시스템이 멈출 수 있습니다.
화이트박스 개발
언제든 인계할 수 있게 시스템을 준비합니다
-
✓
표준 기술 선택
대체 가능한 옵션을 유지하기 위해 널리 쓰이는 언어와 프레임워크를 선택합니다.
-
✓
항상 GitHub 등에서 공유
고객 저장소에 매일 커밋하여 진행 상황과 품질을 실시간으로 보여줍니다.
-
✓
출구 전략을 처음부터 정의
첫날부터 internalization/transition 계획을 설계합니다.
파트너 선택 평가 축 (Risk Radar)
파트너 선택 시 가격만이 아니라 아래 다섯 축을 평가하여 되돌릴 수 있는지 측정하세요.
- 투명성: 정보 접근성
- 표준 기술: 기술 스택의 보편성
- 계약 유연성: 취소 용이성
- 문서화: 기록된 설계 의도
- 자립 지원: internalization 지원 의지
3. 의존에서 벗어나기: 출구 전략
계약 lock-in에서 가치 기반 관계로 전환하세요.
필요 시 원활한 철수와 인계를 위한 로드맵을 정의합니다.
Step 01 자산 소유권 확보
소스 코드, 디자인 데이터, 문서의 IP가 고객 소유인지 확인합니다.
고객이 저장소(GitHub 등)를 만들고 공급사를 초대합니다.
Step 02 지식을 개인에 묶지 않기
회의록뿐 아니라 코드 주석과 ADR도 문서화합니다.
"왜"의 맥락을 남겨 인계 비용을 최소화합니다.
Step 03 오버랩 기간
internalization 또는 공급사 변경 시 1-2개월의 오버랩을 허용합니다.
pair programming과 code review로 작업 수준에서 권한을 이전합니다.
Goal 완전한 독립
외부 파트너 없이 시스템이 계속 운영되는 상태.
이는 리스크 관리의 최종 목표 — 건강한 개발 자세입니다.