도구 도입 전에 '빼기 비용'을 먼저 계산한다
새 도구를 넣기 전, 1년 후 제거할 때 드는 비용을 먼저 적어보는 습관
도구는 넣을 때가 아니라 뺄 때 비싸다
팀에 도구를 붙이는 건 쉽다. Slack 연동 하나, .env 에 키 하나, README 한 줄. 그게 전부처럼 보인다.
막상 1년 뒤 그 도구를 빼려 하면 다르다.
- 그 도구 포맷으로 export된 데이터 3만 건
- 그 도구 webhook에 의존하는 자동화 스크립트 7개
- 그 도구 알림 채널을 ‘공식 채널’로 인식하고 있는 팀원 12명
- 그 도구 전용 권한 그룹이 IAM 에 박혀 있는 것
이걸 다 추적하고, 옮기고, 검증하고, 공지하는 데 실제로 며칠이 사라진다. 최근 사내 모니터링 도구 하나를 교체하면서 예상보다 두 배 걸렸다. 도구 자체 마이그레이션보다 “그 도구인 줄 모르고 붙어 있던 것들” 정리가 발목을 잡았다.
도입 전에 ‘제거 체크리스트’를 먼저 쓴다
지금은 도구 도입 전에 한 장짜리 메모를 먼저 작성한다. 제목은 항상 같다: “이걸 1년 뒤에 끄면 무슨 일이 일어나나.”
항목은 단순하다.
[ ] 이 도구가 생산하는 데이터 포맷은? export 경로는?
[ ] 다른 시스템이 이 도구의 API / webhook 에 의존하게 되나?
[ ] 이 도구 없이는 안 되는 운영 루틴이 생기나?
[ ] 권한/계정이 이 도구 중심으로 묶이나?
[ ] 팀이 이 도구를 '표준'으로 인식하게 되나?항목 중 두 개 이상 체크되면 — 도입 비용 외에 ‘제거 비용’을 별도로 추정한다. 추정 단위는 거창하지 않다. “제거할 때 엔지니어 몇 명이 며칠 투입되나” 그게 전부다.
보통은 이 계산만으로 결정이 달라지지는 않는다. 그래도 적어두면 나중에 덜 놀란다. 그리고 팀장이 “이거 왜 아직 안 빠졌어?” 할 때 그 메모가 답이 된다.
도구 lifecycle 을 처음부터 설계에 넣는다
막상 해보면 도구 하나가 조직 안에 뿌리내리는 속도는 생각보다 훨씬 빠르다. 처음엔 “써보는 것”으로 시작한다. 두 달 뒤엔 온보딩 문서에 들어가 있다. 여섯 달 뒤엔 신규 입사자가 그게 원래부터 있던 줄 안다.
그래서 도입 시점에 lifecycle 을 명시한다.
# 도구: [이름]
도입일: 2026-03
검토 주기: 6개월
담당자: mings
제거 조건: 월 활성 사용자 < 3명 OR 유지비 > $X/월이게 없으면 도구는 그냥 남는다. 아무도 안 쓰지만 아무도 끄지 않는다. 계정은 살아 있고, 비용은 청구된다. 팀은 이게 뭔지도 기억 못 하면서 “혹시 몰라서” 살려둔다.
지난 분기 결산에서 그런 도구가 정확히 세 개 나왔다. 셋 다 ‘잠깐 써보자’로 들어왔고, 담당자가 없었고, 제거 조건을 정한 적이 없었다. 세 개 합쳐서 월 $180. 숫자 자체는 작지만, 그 이유로 아무도 결정을 안 했다는 게 문제였다.
다음 한 가지
다음 도구 도입 제안이 오면, 승인 전에 ‘제거 메모’ 한 장을 먼저 달라고 요청한다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.