자동화는 추가하는 순간에는 편리해 보입니다.
수동 작업을 하나 줄이고, 알림을 하나 늘리고, 다른 AI에게 판단을 위임합니다. 개별적인 개선은 작더라도, 쌓이다 보면 많은 처리를 사람의 손에서 떼어낼 수 있습니다.
반면에 자동화에는 계속 움직이게 하기 위한 작업도 증가합니다.
인증 업데이트, 사양 변경에 대한 추종, 실패 시 조사, 중복 실행 방지, 기록 정리. 이러한 것들이 너무 많아지면, 자동화를 관리하는 데 시간을 사용하는 상태가 됩니다.
이 눈에 잘 띄지 않는 부담을 여기서는 관리 부채(Maintenance Debt)라고 부릅니다.
관리 부채는 '노력의 총량'이 아니다
절차가 많기만 하다면, 바로 부채라고 할 수 없습니다.
매번 같은 방법으로 확인할 수 있고, 실패해도 원인과 재개 지점을 알 수 있다면, 그 절차는 안정적인 운영의 일부입니다.
반대로, 하나의 처리라도 담당자의 기억이 없으면 고칠 수 없고, 결과가 맞는지 확인할 수 없으며, 재실행하면 이중 처리가 되는 상태라면 관리 부채는 커집니다.
봐야 할 것은 작업 수가 아니라, 변화나 실패가 발생했을 때 필요하게 되는 '판단'입니다.
추가하기 전에 네 가지 부담을 측정하라
새로운 자동화를 추가하기 전에, 최소한 다음 네 가지를 나누어 확인해야 합니다.
| 부담 | 확인할 것 |
|---|
| 유지 | 인증, API, 입력 형식 등 변화를 추적하는 대상은 몇 개가 있는가 |
| ... | |
| 네 가지 중 하나라도 답변이 모호하다면, 만들기 전에 확인 방법을 정해야 합니다. | |
모든 것을 상세한 사양서로 만들 필요는 없습니다. 대상을, 완료 조건, 중지 조건, Evidence(증거), 재개 지점을 알 수 있다면, 그것이 첫 번째 판단 자료가 됩니다.
줄인 시간만으로 효과를 결정하지 마라
자동화의 효과는 '한 번당 몇 분이 줄었는지'만으로 평가하면 편향됩니다.
예를 들어, 한 번에 5분 걸리던 작업을 자동화했더라도, 월 1회 인증 만료로 1시간을 조사한다면, 줄인 시간의 상당 부분을 잃습니다. 게다가 결과가 불명확할 때마다 사람이 전 건을 확인해야 한다면, 심리적인 부담도 남게 됩니다.
간단한 비교로는 다음 수식으로 생각할 수 있습니다.
정지 효과 = 줄어든 반복 작업 - 유지·검증·복구·인계의 부담
여기서 수치를 정밀하게 도출하는 것이 목적이 아닙니다.
자동화의 '만드는 가치'뿐만 아니라, '유지할 조건'을 같은 표에 올리는 것이 중요합니다.
이용 빈도와 영향 범위를 조합하라
모든 수동 작업을 자동화할 필요는 없습니다.
우선순위가 높은 것은, 빈도가 높고, 판단이 정형화될 수 있으며, 실패해도 영향을 제한할 수 있는 작업입니다.
| 빈도 | 실패 시 영향 | 방침 |
|---|
| 높음 | 작음 | 작게 자동화하고, 실행 후에 재확인(Readback)한다 |
| ... | | |
| 빈도가 낮고, 판단이 매번 바뀌는 작업에서는, 훌륭한 자동화를 만드는 것보다 짧은 체크리스트가 부담을 줄 때가 있습니다. | | |
연결을 늘리기 전에, 기존 흐름을 줄여라
관리 부채는 기능의 수보다는 '연결'의 수로 증가하는 경우가 많습니다.
하나의 처리를 다른 AI, 외부 서비스, 표, 알림처 등으로 연결할 때마다, 식별자(identifier), 권한, 형식, 상태를 주고받아야 합니다.
따라서 새로운 연결을 추가하기 전에, 기존 흐름에서 생략할 수 있는 것을 찾습니다.
- 같은 정보를 여러 장소에 전사하고 있지는 않은가?
- 사람이 확인하는 항목을 작용 후의 Readback으로 대체할 수 없는가?
- 비슷한 알림이 여러 경로로 오고 있지 않은가?
- 오래된 초안이나 기록을 정본(master copy)에 대한 참조로 대체할 수 없는가?
- 상시 감시가 아니라, 정해진 간격의 확인만으로 충분하지 않은가?
처리를 늘리지 않고 연결을 하나 줄일 수 있다면, 미래의 확인 지점도 하나 줄어듭니다.
자동화하지 않는 판단도 기록하라
보류한 이유를 남기지 않으면, 나중에 같은 안건이 나타났을 때 처음부터 재검토하게 됩니다.
'이용 빈도가 낮음', '공개 작업은 사람의 판단에 남김', '현재 무료 사용량으로는 유지 불가'와 같이 조건과 이유를 짧게 기록합니다.
그리고 재검토할 조건을 덧붙입니다.
- 월 실행 횟수가 일정 수를 초과하면 재평가한다
- 안전한 Readback 수단이 생기면 재평가한다
- 예산과 지속 이용의 근거가 갖춰지면 재평가한다
보류는 실패가 아닙니다. 관리 부채를 늘리지 않기 위한 설계 판단입니다.
줄인 시간을 다음 가치로 돌려라
자동화의 목적은 관리 화면을 늘리는 것이 아닙니다.
좋아하는 개발이나 검증에 쓸 수 있는 시간을 되찾고, 얻은 지견을 공유하며, 다른 사람들의 좋은 실천에서 배울 여백을 만드는 것입니다.
무료로 공개할 수 있는 지견은 먼저 공유하고, 재활용하기 쉬운 완성품이나 지속적인 가치에는 필요한 사람이 자발적으로 대가를 지불할 수 있는 형태로 준비합니다. 그 여력으로 또 다른 사람의 지식이나 기술을 배웁니다.
이 순환이 계속되면, 자동화는 작업을 빼앗는 도구가 아니라, 서로의 수준을 높이는 시간을 만들어내는 기반이 됩니다.
새로운 자동화 하나를 추가하기 전에, 유지(Maintenance), 검증(Verification), 복구(Recovery), 그리고 인계(Handover)의 네 가지 항목을 나열하고, 그 결과로 남는 순수 효과가 있는지 확인하는 것부터 시작할 수 있습니다.
관련 기사
토론
