Seedling
자동화 시스템 vs 거버넌스 부담 — 숨은 trade-off
자동화는 사람 부담을 줄이려는 의도지만, 보안·품질 검증·운영 의지 같은 거버넌스 요구가 증가하면 net 부담은 늘 수 있다.
- #workflow
- #automation
- #governance
- #tradeoff
직관
"자동화하면 일이 줄어든다." — 보통 맞다. 하지만 항상은 아니다.
반례
이번에 일일 콘텐츠 자동 추출 시스템 PoC를 4 페르소나(SWE·법무·콘텐츠·운영 사용자)로 평가했더니, 자동화가 만드는 거버넌스 부담이 본 작업보다 클 수 있다는 결론이 나왔다.
| 영역 | 자동화 전 (수동) | 자동화 후 |
|---|---|---|
| 작성 | 매일 30분 | 매일 0분 (자동) |
| 보안 검토 | N/A | false positive 컨펌, redaction 룰 튜닝 |
| 품질 검토 | N/A | AI 톤 오염 감시, 1인칭 톤 보호 |
| 시스템 운영 | N/A | cron·hook 유지, 사고 시 incident response |
| 합계 | 30분 | 30분 이상 가능 |
함의 — 자동화 전 자문할 세 가지
- 자동화가 만드는 거버넌스 일이 자동화하는 실작업보다 작은가?
- 거버넌스 일은 누가 책임지는가? (자동화의 보안 사고 = 결국 사람이 수습)
- 사고 1건의 비용 vs 자동화의 시간 절감 누적 가치를 비교했는가?
이번 PoC에서는 법무 검토자가 "현 PLAN 상태로 publish 절대 금지, 4주 dry-run 필요"라고 단호하게 못박았다. 자동화 1주 작업 vs 4주 dry-run 운영 — 시간 절감 가설이 깨진다.
운영 사용자의 BLOCKING
내가 가장 두려운 건 검토 부담이 아니라 회사 정보 유출 1건이다. 자동화 수준을 높일수록 이 리스크가 비선형으로 커진다. 익명화 필터의 false negative rate를 어떻게 측정·신뢰할지가 진짜 blocker. 이게 해결 안 되면 차라리 시스템을 안 만드는 게 낫다.
이건 SRE·법무·콘텐츠 전략가 누구도 짚지 못한 BLOCKING이었다. 본인 페르소나로 자기 평가했을 때만 나오는 솔직한 신호.
자동화는 일을 줄이는 게 아니라
일의 종류를 바꾼다.
수동 작성 → 거버넌스 운영. 둘 중 어느 쪽이 자신에게 더 sustainable한지가 결정 기준이지, "자동화 = 무조건 이득"은 아니다.
후속(2026-06): 이 PoC의 보수적 결론은 이후 주간 봇이 "자동 초안 작성 + PR 게이트"로 전환되며 일부 뒤집혔다. 핵심 명제는 그대로다 — 거버넌스는 사라지지 않고 "공개 전 사람이 PR을 보는 게이트" 형태로 남았다.
함정
- 자동화 인프라 자체가 essential complexity인 줄 알지만 대부분 accidental complexity다 (Brooks).
- 자동화의 ROI 측정에는 사고 risk-adjusted 비용을 포함해야 한다 — 빈도 × 회복 비용.
- "자동화하면 미래에 시간 절약" 같은 미래 가치는 할인율을 빼고 계산하기 쉽다.
관련
/notes/dispatch-routing-pattern — 자동 라우팅이 만드는 거버넌스 부담을 dispatch 패턴 관점에서 본 사례 /notes/one-way-two-way-door — 자동화는 보통 one-way door, 거버넌스 설계 전 의사결정 방향 확인 /notes/self-persona-evaluation — 같은 PoC에서 본인 페르소나가 짚은 솔직한 BLOCKING /notes/coderabbit-cubic-double-review — 자동 리뷰 도구가 만드는 거버넌스 부담의 한 사례 /cases/automation-poc-design — 거버넌스 부담을 평가한 자동화 PoC 케이스 /logs#2026-06-08-writing-bot-reversal — 이 보수적 결론을 2주 운영 후 자동 초안+PR 게이트로 전환한 후속