자동화 폐기 결정 — 40시간 투자를 버리고 수동으로 돌아간 이유
2026년 1월, 보고서 자동화를 완전히 중단했습니다. 40시간을 들여 만든 스크립트를 삭제하고 다시 손으로 보고서를 쓰기 시작했어요. 주변에서는 "그래도 언젠간 이득 아니냐"고 물었죠. 아니었습니다. 손익분기 30개월이라는 계산의 결론은 "더 정확히 측정하자"가 아니라 "이 자동화를 죽이고 수동으로 돌아가라" 였거든요.
40시간은 이미 지불된 비용 — 매몰비용 오류에 빠지지 마라
2025년 9월, Google Analytics API를 긁어 슬랙에 주간 보고서를 보내는 워크플로우를 만들었어요. 개발에 40시간이 들었습니다. 매주 수작업 2시간을 아끼면 월 8시간 절감이니 5개월이면 본전이라고 계산했죠.
그런데 실제로는 달랐어요. 유지보수에 매월 2시간, 디버깅에 매월 2시간이 추가로 들었거든요. API가 바뀌면서 3개월마다 8시간씩 수정 작업도 생겼고요. 순절감은 월 1.33시간으로 쪼그라들었고, 손익분기는 30개월로 늘어났습니다.
여기서 많은 사람이 "이미 40시간을 투자했으니 계속 써야 손해를 만회한다"고 생각해요. 이게 매몰비용 오류예요. 40시간은 이미 지불된 비용이고, 되돌릴 수 없습니다. 앞으로의 판단은 "지금부터 30개월간 감시·수정에 200시간을 더 쏟아서, 겨우 개발비 40시간을 되찾을 것인가"만 봐야 하죠.
저는 이 계산을 하고 나서 폐기를 결정했어요. 30개월 뒤에 겨우 본전인 구조였거든요. 지금 죽이고 그 시간을 다른 데 쓰는 편이 나았죠.
폐기 후 실제로 무슨 일이 일어났나요?
2026년 1월부터 보고서를 다시 손으로 작성했습니다. 처음엔 퇴보처럼 느껴졌어요. 그런데 막상 해보니 주당 2시간, 즉 월 8시간이면 충분했어요. 시간 총량만 보면 자동화가 월 1.33시간 앞섭니다. 문제는 그 1.33시간을 얻기 위해 월 6.67시간의 감시·수정 잡무를 계속 떠안아야 한다는 거예요. 1.33시간을 벌려고 6.67시간을 관리에 쓰는 구조죠.
더 큰 차이는 유연성이었습니다. 고객사가 보고서 형식 변경을 요청했을 때, 손으로 작성하면 5분 만에 반영됐어요. 자동화였다면 스크립트 수정에 2시간은 걸렸을 거예요. API 변경 걱정 없이 잠을 잘 수 있게 된 것도 예상 밖 이득이었죠.
The automation paradox: doing busywork to save time 라는 HN 스레드에서 본 경험담이 딱 맞았어요. "시간을 아끼려 만든 자동화가 감시·수정이라는 새 잡무를 만든다"는 내용이었거든요. 폐기하니까 그 잡무가 사라진 거예요.
대조 사례 — 살려둘 만한 자동화는 어떤 것인가요?
모든 자동화를 죽인 건 아니에요. 같은 시기에 만든 이메일 템플릿 자동화는 지금도 쓰고 있습니다. 개발에 12시간 들었고, 월 4시간을 절감하거든요. 유지보수는 거의 없어요. 손익분기는 3개월이었고, 지금까지 1년 넘게 쓰면서 48시간을 아꼈죠.
차이는 외부 의존성이었어요. 보고서 자동화는 Google Analytics API에 묶여 있었고, API가 바뀔 때마다 스크립트를 고쳐야 했습니다. 이메일 템플릿은 Notion 데이터베이스만 읽어서, 의존성이 거의 없었어요.
폐기 진단을 정리하면 이렇습니다.
| 자동화 | 개발 공수 | 월 순절감 | 손익분기 | 결정 |
|---|---|---|---|---|
| 보고서 | 40시간 | 1.33시간 | 30개월 | 폐기 |
| 이메일 템플릿 | 12시간 | 4시간 | 3개월 | 유지 |
Paul Graham은 Startups = Growth에서 측정하지 않으면 성장도 없다고 했죠. 폐기 결정도 마찬가지예요. 측정하지 않으면 죽일 것과 살릴 것을 구분할 수 없습니다.
자동화 폐기를 망설이는 이유는 무엇일까요?
"그래도 언젠간 이득 아닌가요?" — 맞아요. 하지만 30개월을 기다리는 동안의 기회비용을 계산해야 합니다. 그 유지보수 시간으로 손익분기 3개월짜리 자동화를 10개 만들 수 있어요. 30개월 후 이득보다 지금 당장의 이득이 큽니다.
"이미 만든 시간이 아까운데요?" — 아까운 건 이미 쓴 40시간이 아니라, 앞으로 낭비할 200시간이에요.
"수동으로 돌아가는 건 퇴보 아닌가요?" — 아니에요. 선택지를 회복하는 거예요. 자동화에 묶여 API 변경에 끌려다니는 것보다, 필요할 때만 손으로 하는 게 훨씬 유연했습니다. 유지보수 잡무까지 합치면 수동이 총 시간 면에서 큰 차이가 없었고, 유연성은 훨씬 높았으니 오히려 진보였죠.
폐기 기준선 — 남은 손익분기 12개월 넘으면 죽여라
폐기 결정은 간단해요. 남은 손익분기가 12개월을 넘으면 죽입니다. 1년 뒤의 이득보다 지금 당장 시간을 회복하는 게 낫거든요.
제가 쓰는 폐기 진단은 3단계예요.
- 순절감 계산: 실제 절감 - (유지보수 + 디버깅 + 감시)
- 남은 손익분기: (개발 공수 - 이미 회수한 시간) ÷ 순절감
- 12개월 넘으면 폐기, 6개월 미만이면 유지, 6~12개월은 3개월 후 재진단
2026년 2월부터는 모든 자동화에 3개월마다 이 진단을 적용하고 있어요. Notion API 연동은 손익분기가 8개월로 나와서 유지 중이고, CSV 변환 스크립트는 18개월이 나와서 폐기했습니다.
당신의 자동화 중 죽여야 할 것은 무엇인가요? 이미 투입한 시간은 판단 기준이 아닙니다. 지금부터의 유지보수 vs 지금부터의 절감만 보세요.
자주 묻는 질문
Q. 자동화를 언제 폐기해야 하나요?
A. 남은 손익분기가 12개월을 넘으면 폐기를 고려하세요. 제 경우엔 30개월짜리를 죽였고, 3개월짜리는 유지했습니다. 3개월마다 재진단하면 정확해요.
Q. 폐기 후 수동으로 돌아가면 퇴보 아닌가요?
A. 제 경험으론 퇴보가 아니었어요. 자동화가 시간 총량으론 월 1.33시간 앞섰지만, 그걸 위해 월 6.67시간 관리 잡무를 떠안아야 했거든요. 유연성도 회복됐고요.
Q. 매몰비용은 정말 무시해야 하나요?
A. 네. 폐기 판단은 앞으로의 유지보수 vs 절감만 보면 됩니다.
Q. 폐기 결정을 번복한 적은 없나요?
A. 한 번 있었어요. 슬랙 알림 봇을 죽였다가 3개월 후 다시 만들었습니다. 그때는 외부 의존성이 없어서 유지보수가 거의 안 들더라고요. 폐기도 영구적일 필요는 없어요.
Q. 자동화를 살릴지 죽일지 판단하는 기준선은?
A. 남은 손익분기 12개월, 외부 의존성 유무, 유지보수 빈도 3가지를 봅니다. 셋 중 하나라도 나쁘면 폐기 후보예요. 제 경우엔 API 의존성이 높은 것들이 대부분 폐기 대상이었습니다.