운영 자동화는 어디서 시작해야 할까

자동화 워크플로우 시리즈 1/8

운영 자동화를 시작할 때 가장 먼저 떠올리는 것은 도구다.

폼을 만들까, 스프레드시트를 쓸까, 관리자 페이지를 만들까, 자동화 스크립트를 붙일까, 아니면 처음부터 데이터베이스와 백엔드를 갖춘 시스템을 만들까.

하지만 자동화는 도구에서 시작하면 자주 실패한다.

먼저 봐야 할 것은 업무 흐름이다.

누가 입력하고, 누가 확인하고, 어떤 기준으로 상태가 바뀌고, 결과가 누구에게 공개되는지부터 정리해야 한다. 그다음에야 어떤 도구가 충분한지 판단할 수 있다.

문제 상황

신청을 받고, 내부에서 확인하고, 일정이나 결과를 공개하는 업무가 있었다.

처음부터 완전한 백오피스 시스템을 만들 수도 있었다. 로그인, 신청 화면, 관리자 화면, 상태 관리, 데이터베이스, 알림, 공개 페이지를 모두 직접 구현하는 방식이다.

하지만 실제 업무를 살펴보면 이미 쓰고 있는 도구가 있었다.

• 외부 사용자는 폼으로 신청한다.
• 내부 운영자는 스프레드시트에서 데이터를 확인한다.
• 일부 처리는 스크립트로 자동화할 수 있다.
• 공개 화면은 가공된 데이터만 보여주면 된다.

이 상황에서 중요한 질문은 "새 시스템을 만들 것인가"가 아니었다.

"이미 굴러가는 업무 흐름 중 어디를 시스템화할 것인가"였다.

자동화 대상을 화면이 아니라 흐름으로 보기

운영 자동화의 단위는 화면이 아니다. 흐름이다.

예를 들어 신청 관리 업무는 다음 흐름으로 나눌 수 있다.

외부 사용자 입력
-> 원천 데이터 저장
-> 내부 운영자 검토
-> 자동 처리 또는 상태 변경
-> 공개용 데이터 생성
-> 외부 사용자 조회

이렇게 흐름으로 보면 각 단계의 성격이 달라진다.

입력 단계는 사용자가 익숙한 도구가 중요하다.

검토 단계는 운영자가 빠르게 수정하고 확인할 수 있어야 한다.

공개 단계는 개인정보나 내부 판단 정보가 제거되어야 한다.

동기화 단계는 실패했을 때 다시 실행할 수 있어야 한다.

각 단계가 요구하는 것이 다르기 때문에 하나의 도구로 모든 것을 해결하려고 하면 복잡해진다.

먼저 그려야 할 질문들

자동화 전에 다음 질문을 적어본다.

• 입력자는 누구인가
• 입력 빈도는 어느 정도인가
• 입력 데이터는 사람이 검토해야 하는가
• 원천 데이터는 어디에 두는가
• 상태 변경은 누가 하는가
• 자동으로 처리할 수 있는 부분은 어디인가
• 결과는 누구에게 공개되는가
• 공개 데이터에서 제거해야 할 정보는 무엇인가
• 실패했을 때 누가 어떻게 복구하는가

이 질문에 답하지 않은 상태에서 도구를 고르면, 나중에 도구에 업무를 억지로 맞추게 된다.

모든 것을 새로 만들 필요는 없다

개발자는 새 시스템을 만들고 싶어질 때가 많다.

하지만 운영 자동화에서는 기존 도구를 잘 연결하는 것이 더 좋은 선택일 수 있다.

Google Forms는 입력을 받는 데 충분할 수 있다.

Google Sheets는 사람이 검토하고 수정하는 원천 데이터 저장소로 충분할 수 있다.

Apps Script는 스프레드시트 주변의 업무 로직을 처리하기에 충분할 수 있다.

AWS Lambda와 S3는 가공된 데이터를 외부 화면에 제공하기에 충분할 수 있다.

중요한 것은 각 도구가 맡을 책임을 좁히는 것이다.

폼은 입력만 받는다.

스프레드시트는 원천 데이터와 운영 검토를 맡는다.

스크립트는 상태 변경과 동기화를 맡는다.

AWS는 공개 화면과 캐시된 데이터를 제공한다.

이렇게 나누면 작은 도구들의 조합으로도 안정적인 운영 흐름을 만들 수 있다.

자동화할 것과 남겨둘 것

모든 단계를 자동화해야 좋은 것은 아니다.

운영 업무에는 사람이 판단해야 하는 단계가 있다. 신청 내용이 유효한지, 예외 상황이 있는지, 공개 전에 확인해야 할 정보가 있는지 같은 부분이다.

이런 단계까지 억지로 자동화하면 오히려 위험하다.

자동화하기 좋은 것은 반복적이고 규칙이 분명한 일이다.

• 폼 제출 데이터를 시트에 기록하기
• 특정 상태의 데이터를 모아 JSON으로 변환하기
• 공개용 데이터에서 민감한 필드를 제거하기
• 최신 데이터를 storage에 업로드하기
• 월별 스냅샷을 남기기
• 화면에서 읽기 좋은 API 응답으로 가공하기

사람이 남아야 하는 것은 판단과 예외 처리다.

자동화는 사람을 없애는 것이 아니라, 사람이 판단해야 할 곳에 집중하게 만드는 것이다.

실패 경로를 먼저 생각하기

자동화 흐름을 설계할 때는 정상 흐름만 그리면 부족하다.

반드시 실패 경로를 함께 생각해야 한다.

• 폼 제출은 되었지만 스크립트가 실패하면 어떻게 되는가
• 스프레드시트 데이터는 맞는데 AWS 동기화가 실패하면 어떻게 되는가
• S3에는 새 파일이 올라갔는데 CDN 캐시 때문에 이전 데이터가 보이면 어떻게 하는가
• 공개용 JSON 생성 중 민감한 필드가 제거되지 않으면 어떻게 막는가
• 운영자가 수동으로 다시 동기화할 수 있는가

작은 자동화일수록 복구 경로가 중요하다.

전용 모니터링 시스템이 없을 수 있고, 담당자가 항상 보고 있지 않을 수 있기 때문이다.

자동화 흐름 예시

일반화하면 다음 구조가 된다.

 

이 구조에서 핵심은 Source of Truth를 명확히 하는 것이다.

원천 데이터는 스프레드시트다.

Object storage에 저장된 JSON은 화면 제공을 위한 캐시다.

공개 페이지는 원천 데이터를 직접 보지 않고, 가공된 공개용 데이터를 본다.

이 구분이 있어야 운영 중 잘못된 곳을 수정하지 않는다.

정리

운영 자동화는 도구 선택에서 시작하지 않는다.

먼저 업무 흐름을 그려야 한다.

누가 입력하고, 어디에 저장되고, 누가 판단하고, 무엇이 공개되고, 실패하면 어떻게 복구하는지 정리해야 한다.

그다음에야 폼, 스프레드시트, 스크립트, Lambda, S3 같은 도구를 적절히 배치할 수 있다.

자동화는 큰 시스템을 만드는 일이 아니다.

반복되는 업무 흐름을 안전하게 연결하는 일이다.

함께 볼 GitHub 저장소

• workflow-automation-samples