락인은 기술 문제가 아니라 조직 결정의 결과다

1️⃣ 락인은 언제 생기는가 (기술 말고 조직 신호)

다음이 보이면 이미 시작입니다.

• 벤더 선택을 POC 이전에 계약으로 결정
• “일단 이걸로 가자” → Exit 전략 없음
• 운영·재무·법무가 기술 결정을 대체
• 전환 비용을 비용이 아니라 손실로 인식

👉 이건 스택 문제가 아니라 거버넌스 문제입니다.

---

2️⃣ 기술은 핑계가 된다

현장에서 흔한 변명들:

• “이 기술은 대체 불가”
• “마이그레이션 리스크 큼”
• “다들 이걸 쓴다”
• “우리 인력이 이거밖에 못함”

팩트:

• 대체 불가는 거의 없음
• 리스크는 초기에 안 만들면 작음
• 표준을 버린 건 선택
• 인력 종속은 교육·채용 미스

---

3️⃣ 락인을 만드는 진짜 원인 4가지

원인설명

계약 구조	해지·전환 비용 과도
KPI	단기 성과 위주
책임 회피	“바꿨다 망하면 내 책임”
기술 의사결정권	엔지니어 부재

👉 기술팀이 결정권이 없을수록 락인은 심해집니다.

---

4️⃣ 락인을 막는 조직적 장치 (기술보다 중요)

• Exit 문서: “이걸 버릴 때 절차/비용”
• 표준 인터페이스: 내부 도메인과 벤더 분리
• 전환 예산: ‘바꿀 수 있음’을 예산에 반영
• 이중화 기간: 겹쳐 쓰는 기간을 인정

이게 없으면 어떤 스택을 써도 락인됩니다.

---

5️⃣ 좋은 조직의 질문

“이 결정을 2년 뒤 다른 팀이 이어받아도 탈출 가능한가?”

YES → 건강
NO → 기술과 무관하게 이미 락인

---

6️⃣ 한 줄 정리

락인은 코드에 박히는 게 아니라, 회의록에 먼저 박힌다.
기술은 그 결정을 충실히 실행할 뿐입니다.