자동화했더니 일이 줄지 않고 설명서가 늘어났습니다

자동화했더니 일이 줄지 않고 설명서가 늘어났습니다

automation-increased-documentation

소개

자동화는 언제나 아름다운 약속으로 시작합니다. 반복 작업을 줄이고, 실수를 줄이고, 시간을 아끼고, 사람은 더 중요한 일에 집중하게 해 준다고 말합니다. 말만 들으면 사무실 한쪽에서 조용히 박수가 나올 것 같습니다. 그런데 막상 자동화를 만들고 나면 이상한 일이 생깁니다. 클릭은 줄었는데 설명서가 늘어납니다. 버튼 하나로 실행되는 기능을 만들었더니, 그 버튼이 무엇을 하는지 설명하는 문서가 다섯 장 생깁니다.

처음에는 "이제 이 작업은 자동으로 됩니다"라고 자신 있게 말합니다. 며칠 뒤 누군가 묻습니다. "실패하면 어떻게 되나요?" "누가 다시 실행하나요?" "어떤 로그를 봐야 하나요?" "권한은 누가 갖고 있나요?" "담당자가 휴가면 누가 압니까?" 그 순간 자동화는 단순한 스크립트가 아니라 작은 운영 시스템이 됩니다. 그리고 운영 시스템에는 설명서가 필요합니다.

이 글에서는 자동화가 왜 일을 줄이는 동시에 문서와 운영 부담을 늘릴 수 있는지, 자동화를 만들기 전에 무엇을 정리해야 하는지, 자동화 이후에 어떤 설명서가 필요한지 살펴보겠습니다. 자동화를 하지 말자는 이야기가 아닙니다. 오히려 잘하기 위해 필요한 이야기입니다. 자동화는 훌륭한 도구지만, 설명할 수 없는 자동화는 언젠가 사람을 다시 수동 작업으로 돌려보냅니다. 그것도 약간 억울한 표정으로 말입니다.

자동화는 작업을 없애는 것이 아니라 형태를 바꿉니다

자동화의 가장 큰 오해는 일이 완전히 사라진다고 생각하는 것입니다. 실제로는 반복 실행 작업이 줄어드는 대신 설계, 모니터링, 예외 처리, 권한 관리, 문서화, 유지보수 작업이 생깁니다. 예전에는 사람이 매일 체크리스트를 보고 실행했다면, 이제는 시스템이 실행합니다. 대신 사람은 시스템이 제대로 실행되는지 확인해야 합니다.

예를 들어 매일 아침 보고서를 만드는 작업을 자동화했다고 해 보겠습니다. 보고서 생성 버튼을 누르는 일은 사라졌습니다. 하지만 스케줄러가 제 시간에 실행되는지, 데이터 소스가 비어 있으면 어떻게 되는지, 보고서가 잘못 만들어졌을 때 누가 알림을 받는지, 수신자 목록이 바뀌면 어디를 수정해야 하는지 정해야 합니다. 손으로 하던 일이 시스템 관리로 이동한 것입니다.

좋은 자동화는 일을 없애는 것이 아니라, 사람이 해야 할 일을 더 명확하게 바꿉니다.

이 차이를 이해하지 못하면 자동화 이후에 당황합니다. "분명 일을 줄이려고 만들었는데 왜 더 바빠졌지?"라는 생각이 듭니다. 사실 자동화는 반복 노동을 줄였지만, 그 반복 노동을 책임지는 작은 시스템을 하나 만든 것입니다. 시스템은 설명이 필요하고, 설명은 문서가 됩니다.

설명서가 늘어나는 이유

자동화 후 설명서가 늘어나는 이유는 간단합니다. 사람의 머릿속에 있던 판단이 시스템 안으로 들어가기 때문입니다. 수동 작업에서는 담당자가 상황에 따라 판단했습니다. 파일이 늦게 도착하면 조금 기다리고, 데이터가 이상하면 담당자에게 물어보고, 오류가 나면 경험으로 우회했습니다. 자동화는 이런 암묵지를 명시적으로 바꿔야 합니다.

자동화 문서가 필요한 대표적인 이유는 다음과 같습니다.

문서가 필요한 지점	이유	없으면 생기는 문제
목적	이 자동화가 어떤 문제를 해결하는지 설명해야 합니다.	나중에 왜 만들었는지 아무도 모를 수 있습니다.
입력과 출력	어떤 데이터를 받아 무엇을 만드는지 알아야 합니다.	잘못된 입력으로 엉뚱한 결과가 생길 수 있습니다.
실행 조건	언제 실행되고 어떤 조건에서 멈추는지 필요합니다.	중복 실행, 누락 실행, 타이밍 문제가 생깁니다.
실패 대응	실패했을 때 누가 무엇을 해야 하는지 정해야 합니다.	오류는 났는데 아무도 책임지지 않는 상황이 됩니다.
권한	누가 실행하고 수정할 수 있는지 정리해야 합니다.	보안 문제나 운영 혼선이 생길 수 있습니다.
변경 이력	언제 무엇이 바뀌었는지 알아야 합니다.	문제가 생겼을 때 원인 추적이 어려워집니다.

자동화는 친절한 직원처럼 보이지만, 사실은 매우 엄격한 직원입니다. 입력이 조금 달라도 알아서 눈치껏 처리하지 않습니다. 예외 상황을 알려 주지 않으면 멈추거나, 더 무섭게는 틀린 결과를 조용히 만들어 냅니다. 이때 설명서는 자동화에게 주는 업무 지시서이자, 사람에게 주는 생존 지도입니다.

자동화 전에 먼저 써야 할 설명

많은 사람이 자동화 코드를 먼저 만들고 문서를 나중에 씁니다. 현실적으로 그럴 때가 많습니다. 하지만 최소한의 설명은 자동화 전에 작성하는 편이 좋습니다. 자동화 전에 문서를 쓰면 요구사항이 정리되고, 자동화 범위가 선명해지며, 만들지 않아도 되는 기능을 줄일 수 있습니다.

자동화 전에 다음 질문에 답해 보세요.

1. 이 작업은 얼마나 자주 반복되나요?
2. 현재 수동 작업에서 가장 시간이 많이 드는 단계는 무엇인가요?
3. 실수하기 쉬운 단계는 어디인가요?
4. 자동화해도 사람이 꼭 확인해야 하는 부분은 무엇인가요?
5. 실패했을 때 업무 영향은 어느 정도인가요?
6. 누가 소유하고 누가 수정할 수 있어야 하나요?
7. 자동화를 끄거나 되돌리는 방법이 필요한가요?

이 질문에 답하다 보면 자동화할 가치가 있는지 더 분명해집니다. 자동화는 재미있습니다. 특히 개발자에게는 반복 작업을 보면 손이 근질거리는 순간이 있습니다. 하지만 모든 반복 작업이 자동화 대상은 아닙니다. 한 달에 한 번 하는 5분짜리 작업을 자동화하려고 3일을 쓰면, 자동화가 아니라 취미 활동에 가까워질 수 있습니다. 취미도 좋지만, 팀 일정표는 취미를 잘 이해하지 못합니다.

자동화 후 꼭 필요한 문서 다섯 가지

자동화가 실제 업무에 들어갔다면 최소한 다섯 가지 문서가 필요합니다. 길고 화려한 문서가 아니어도 됩니다. 중요한 것은 누군가가 담당자 없이도 기본 상황을 이해할 수 있어야 한다는 점입니다.

첫째, 한 장짜리 개요 문서

자동화의 목적, 담당자, 실행 위치, 입력 데이터, 출력 결과, 관련 시스템을 한 장으로 정리합니다. 이 문서는 새로 온 팀원이 가장 먼저 보는 문서입니다. "이 자동화는 무엇인가요?"라는 질문에 답해야 합니다.

둘째, 실행 방법 문서

자동화가 언제 어떻게 실행되는지 적습니다. 스케줄 기반인지, 버튼 실행인지, 이벤트 기반인지, 수동 재실행이 가능한지 설명합니다. 실행 권한과 필요한 환경 변수도 함께 적어야 합니다.

셋째, 실패 대응 문서

가장 중요합니다. 실패했을 때 어떤 로그를 보고, 어떤 알림을 확인하고, 누가 대응하며, 다시 실행해도 되는지 정리합니다. 자동화가 실패했는데 대응 문서가 없으면, 사람들은 결국 채팅방에서 "이거 아시는 분?"을 외치게 됩니다. 이 문장은 모든 운영팀의 작은 비상벨입니다.

넷째, 변경 이력 문서

자동화는 한 번 만들고 끝나지 않습니다. 데이터 구조가 바뀌고, API가 바뀌고, 업무 규칙이 바뀝니다. 언제 무엇이 바뀌었는지 남겨야 문제 발생 시 원인을 찾기 쉽습니다.

다섯째, 종료 또는 되돌리기 문서

자동화가 잘못 실행되었을 때 멈추는 방법, 이전 수동 절차로 되돌리는 방법, 잘못 생성된 결과를 정리하는 방법을 적습니다. 자동화는 켜는 법만큼 끄는 법도 중요합니다. 꺼지지 않는 자동화는 편리한 도구가 아니라 야근 예약 시스템이 될 수 있습니다.

자동화 문서 체크리스트

자동화 문서를 작성할 때는 아래 체크리스트를 사용해 보세요. 모든 항목이 필요하지 않을 수 있지만, 업무에 영향을 주는 자동화라면 대부분 확인하는 편이 좋습니다.

항목	확인 질문	작성 팁
소유자	누가 이 자동화를 책임지나요?	개인 이름보다 팀이나 역할도 함께 적습니다.
실행 주기	언제 실행되고 얼마나 자주 실행되나요?	시간대와 휴일 예외를 함께 적습니다.
입력 데이터	무엇을 받아서 처리하나요?	데이터 위치, 형식, 필수 컬럼을 적습니다.
출력 결과	무엇을 만들고 어디에 저장하나요?	결과 파일, 데이터베이스, 알림 대상을 명확히 합니다.
실패 알림	실패하면 누가 어떻게 알게 되나요?	이메일, 채팅, 모니터링 알림을 구체적으로 적습니다.
재실행 기준	다시 실행해도 안전한가요?	중복 처리, 덮어쓰기, 롤백 조건을 적습니다.
보안	어떤 권한과 비밀 값이 필요한가요?	토큰과 비밀번호는 문서에 직접 쓰지 않습니다.

문서가 길어지는 것이 싫다면 짧게라도 핵심을 적으세요. 문서의 목적은 멋진 산문이 아닙니다. 문제가 생겼을 때 사람을 덜 당황하게 만드는 것입니다. 자동화 문서는 비상구 표지판과 비슷합니다. 평소에는 눈에 잘 안 들어오지만, 필요할 때 없으면 갑자기 매우 중요해집니다.

자동화가 실패할 때 진짜 비용이 드러납니다

자동화의 가치는 성공할 때보다 실패할 때 더 정확히 드러납니다. 성공하는 자동화는 조용합니다. 정해진 시간에 실행되고, 결과를 만들고, 알림을 보냅니다. 사람들은 존재를 잊습니다. 좋은 자동화의 최고 칭찬은 "그거 아직도 돌아가고 있었어요?"일지도 모릅니다.

하지만 실패하면 이야기가 달라집니다. 누가 담당자인지 모르면 시간이 지연됩니다. 로그 위치를 모르면 원인 분석이 늦어집니다. 재실행 기준이 없으면 같은 작업을 두 번 처리할 수 있습니다. 잘못된 결과가 외부로 나가면 더 큰 문제가 됩니다. 자동화의 숨은 비용은 대부분 실패 상황에서 나타납니다.

그래서 자동화 설계에는 실패 시나리오가 포함되어야 합니다. 성공 흐름만 보고 자동화를 만들면 절반만 만든 것입니다. 실패했을 때 멈출지, 재시도할지, 알림을 보낼지, 사람이 승인할지 정해야 합니다. 특히 결제, 고객 알림, 데이터 삭제, 권한 변경처럼 영향이 큰 작업은 더욱 조심해야 합니다.

설명서가 늘어난다고 자동화가 실패한 것은 아닙니다

자동화 후 문서가 늘어나면 "우리가 잘못한 건가?"라는 생각이 들 수 있습니다. 꼭 그렇지는 않습니다. 오히려 중요한 자동화일수록 문서가 필요합니다. 문서가 늘었다는 것은 암묵적인 업무 지식이 드러났다는 뜻일 수 있습니다. 예전에는 특정 담당자만 알고 있던 절차가 이제 팀 전체가 볼 수 있는 형태가 된 것입니다.

물론 문서가 불필요하게 길어지는 것은 문제입니다. 자동화 설명서가 너무 복잡해서 자동화보다 설명서를 이해하는 시간이 더 오래 걸리면 다시 봐야 합니다. 좋은 문서는 길이가 아니라 구조가 중요합니다. 개요, 실행 방법, 실패 대응, 변경 이력, 되돌리기 방법이 분리되어 있으면 필요한 정보를 빨리 찾을 수 있습니다.

자동화 문서의 목표는 모든 것을 자세히 쓰는 것이 아니라, 필요한 사람이 필요한 순간에 다음 행동을 알게 하는 것입니다.

주니어 개발자가 자동화를 배울 때 가져야 할 태도

주니어 개발자에게 자동화는 좋은 성장 기회입니다. 반복 작업을 관찰하고, 규칙을 찾아내고, 스크립트나 워크플로우로 바꾸는 과정에서 시스템 사고를 배울 수 있습니다. 하지만 자동화 코드를 만드는 것만으로는 충분하지 않습니다. 그 자동화가 업무 안에서 어떻게 쓰이고, 누가 의존하고, 실패하면 어떤 영향을 주는지 이해해야 합니다.

자동화를 만들 때는 스스로에게 질문해 보세요. "내가 휴가 중이어도 이 자동화가 유지될 수 있을까?" 이 질문은 꽤 강력합니다. 내가 없으면 아무도 실행 방법을 모르는 자동화는 팀 자산이 아니라 개인 비밀 장치가 됩니다. 개발자는 신비로운 장치를 만드는 마법사가 아니라, 다른 사람이 이해할 수 있는 시스템을 만드는 사람이어야 합니다.

또한 작은 자동화부터 시작하는 것이 좋습니다. 처음부터 핵심 업무 전체를 자동화하려고 하면 위험합니다. 영향이 작고 되돌리기 쉬운 작업부터 시작해 보세요. 성공 흐름과 실패 흐름을 문서로 남기고, 팀원에게 설명해 보고, 실제로 유지보수 가능한지 확인합니다. 자동화는 코드 실력뿐 아니라 설명 능력도 함께 키워 줍니다.

자동화를 만들기 전 마지막 질문

자동화 버튼을 만들기 전, 또는 스케줄러를 등록하기 전에는 다음 질문을 꼭 확인해 보세요.

1. 이 작업은 충분히 자주 반복되나요?
2. 자동화하지 않았을 때의 비용은 무엇인가요?
3. 자동화했을 때 새로 생기는 유지보수 비용은 무엇인가요?
4. 실패하면 어떤 업무나 사용자가 영향을 받나요?
5. 실패 알림과 담당자는 정해져 있나요?
6. 재실행해도 안전한 구조인가요?
7. 설명서를 읽은 다른 사람이 운영할 수 있나요?

이 질문에 답하면 자동화의 범위가 더 현실적으로 바뀝니다. 때로는 전체 자동화보다 반자동화가 더 좋은 선택일 수 있습니다. 예를 들어 데이터 수집은 자동으로 하되, 외부 발송은 사람이 승인하게 할 수 있습니다. 모든 것을 자동으로 처리하는 것보다 중요한 지점에 사람의 확인을 남기는 편이 안전할 때도 많습니다.

자주 묻는 질문

자동화하면 정말 일이 줄어드나요?

반복 실행 작업은 줄어들 수 있습니다. 하지만 설계, 모니터링, 예외 처리, 문서화, 유지보수 작업이 새로 생깁니다. 자동화의 효과를 보려면 줄어드는 일과 새로 생기는 일을 함께 계산해야 합니다.

작은 자동화에도 문서가 필요한가요?

업무에 영향을 준다면 짧게라도 필요합니다. 최소한 목적, 실행 방법, 실패했을 때 확인할 곳, 담당자는 적어 두는 것이 좋습니다. 개인 실험용이라면 간단한 메모로 충분할 수 있습니다.

자동화 문서는 얼마나 자세해야 하나요?

담당자가 없어도 다음 사람이 기본 운영을 할 수 있을 정도면 좋습니다. 모든 구현 세부사항을 설명하기보다 입력, 출력, 실행 조건, 실패 대응, 되돌리기 방법을 중심으로 작성하세요.

자동화가 너무 복잡해지면 어떻게 해야 하나요?

자동화 범위를 줄이거나 단계를 나누는 것이 좋습니다. 모든 것을 한 번에 처리하려고 하지 말고, 사람이 확인해야 하는 지점과 시스템이 처리할 지점을 분리하세요. 복잡한 자동화는 작은 자동화 여러 개와 명확한 문서로 나누는 편이 유지보수에 유리합니다.

마무리

자동화는 일을 줄여 주는 강력한 방법입니다. 하지만 자동화가 모든 일을 사라지게 하지는 않습니다. 반복 클릭은 줄어들 수 있지만, 설명서와 운영 책임은 늘어날 수 있습니다. 이것은 자동화의 실패가 아니라 자동화가 실제 업무 안으로 들어왔다는 신호일 수 있습니다.

좋은 자동화는 코드만으로 완성되지 않습니다. 목적, 실행 조건, 입력과 출력, 실패 대응, 권한, 변경 이력, 되돌리기 방법이 함께 정리되어야 합니다. 그래야 담당자가 바뀌어도, 문제가 생겨도, 팀이 자동화를 계속 믿고 사용할 수 있습니다.

다음에 자동화를 만들고 싶어질 때 잠깐 멈춰 보세요. "이 작업을 자동화하면 어떤 설명서가 필요할까?" 이 질문에 답할 수 있다면 자동화는 더 오래 살아남습니다. 그리고 언젠가 누군가 그 설명서를 읽고 조용히 감사할지도 모릅니다. 물론 직접 말해 주지는 않을 수 있습니다. 개발팀의 감사는 종종 장애가 나지 않는 형태로 표현됩니다.