자동화

사람이 손으로 하던 일을 기계가 대신 수행하게 만드는 것입니다. 절차를 사람 머릿속이 아니라 기계가 읽을 수 있는 형태로 적어 둡니다. 그러면 같은 일이 사람 손을 안 거치고 되풀이됩니다.

상세

은행 앱에 "매달 25일, 집주인에게 월세 50만 원" 이라고 한 줄 적어 걸어 둡니다. 그 뒤로는 25일이 올 때마다 은행 기계가 그 줄대로 돈을 보냅니다. 월세가 오르면 돈을 손으로 보내는 대신 걸어 둔 그 한 줄을 고칩니다.

자동화는 사람이 손으로 하던 절차를 사람 밖에 적어 두고, 그 적힌 것을 기계가 대신 수행하게 만드는 일입니다. 두 가지가 같이 있어야 자동화라고 부릅니다. 절차가 사람의 기억이 아니라 파일이나 코드처럼 읽을 수 있는 것으로 나와 있어야 합니다. 그리고 그 적힌 것을 실행하는 쪽이 사람이 아니어야 합니다.

대상은 되풀이되는 절차입니다. 무엇을 원하는지 정하는 일은 그대로 사람에게 남습니다. 사람은 어떤 결과에 이르러야 하는지를 적습니다. 기계는 거기 이르는 단계를 밟습니다. 그래서 자동화는 사람을 빼는 일이 아니라 사람이 손대는 자리를 옮기는 일입니다. 옮겨간 자리에서 무엇이 달라지는지는 아래 대가 절이 받습니다.

배경

같은 절차를 사람이 되풀이하면 매번 같게 되지 않습니다. 순서 하나를 건너뛰거나 값을 다르게 넣습니다. 절차를 아는 사람이 자리에 없으면 그날은 아무도 그 일을 못 합니다. 다루는 대상이 열 개에서 천 개로 늘면 사람 수를 그만큼 늘려야 합니다.

그래서 필요했던 것은 절차를 사람 밖에 적어 두는 일입니다. 무엇을 어떤 순서로 하는지가 글로 남아 있으면 누가 하든 같은 순서를 밟습니다. 여기서 한 걸음 더 나갈 수 있습니다. 그 적힌 것을 사람이 읽고 따라 하는 대신, 기계가 읽고 실행하게 하는 것입니다.

절차를 기계가 읽는 형태로 적어 두고 기계가 그것을 수행하게 만드는 일. 이것을 자동화라고 부릅니다. 그래서 자동화의 첫 산출물은 대개 도는 프로그램이 아니라 절차를 적은 파일입니다.

예시

GNU Make

빌드를 자동화합니다. 규칙 한 벌을 적어 두면 무엇이 바뀌었을 때 무엇을 다시 만들지 기계가 정합니다. GNU Make 매뉴얼은 규칙의 모양을 이렇게 적습니다.

target … : prerequisites …
        recipe
        …

목표(target)는 보통 프로그램이 만들어 내는 파일 이름입니다. 실행 파일이나 오브젝트 파일이 그 예입니다. 목표는 clean 처럼 수행할 동작의 이름일 수도 있습니다. 전제(prerequisite)는 목표를 만드는 데 입력으로 쓰이는 파일입니다. 레시피(recipe)는 make 가 수행하는 동작입니다. 명령을 여러 줄 담을 수 있습니다. 매뉴얼은 레시피의 모든 줄 앞에 탭 문자를 넣어야 한다고 못 박습니다. 다른 문자를 쓰고 싶으면 .RECIPEPREFIX 변수를 바꾸라고 적습니다.

매뉴얼의 예제에서 목표는 실행 파일 edit 과 오브젝트 파일 main.o · kbd.o 입니다. 전제는 main.c · defs.h 같은 파일입니다. 레시피는 cc -c main.c · cc -c kbd.c 입니다. 각 .o 파일은 목표이면서 동시에 전제입니다. 목표가 파일일 때는 전제 가운데 하나라도 바뀌면 다시 컴파일하거나 다시 링크해야 합니다. 스스로 만들어지는 전제가 있으면 그것부터 먼저 갱신해야 합니다.

GitHub Actions

저장소에 일어난 일을 계기로 작업 한 벌을 돌립니다. 공식 퀵스타트의 데모 워크플로는 이런 모양입니다.

on: [push]
jobs:
  explore-github-actions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

on: [push] 가 언제 도는지를 정합니다. 푸시가 일어나면 워크플로가 걸립니다. jobs: 아래가 무엇을 하는지입니다. runs-on: ubuntu-latest 는 이 작업이 깃허브가 호스팅하는 러너에서 돈다는 뜻입니다. actions/checkout@v6 은 저장소 코드를 그 러너로 내려받는 단계입니다. 데모 워크플로는 이어서 자기를 부른 이벤트 이름과 러너의 운영체제와 브랜치 이름을 찍어 봅니다.

Ansible

기계 여러 대를 한꺼번에 다룹니다. Ansible 공식 문서는 스스로를 이렇게 소개합니다. 복잡도를 줄이고 어디서나 도는 오픈소스 자동화라고 적습니다. 이것을 쓰면 사실상 어떤 작업이든 자동화할 수 있다고 적습니다.

할 일은 플레이북이라는 파일에 적습니다.

- name: my first play
  hosts: myhosts
  tasks:
    - name: ping my hosts
      ansible.builtin.ping:
    - name: print message
      ansible.builtin.debug:
        msg: hello world

hosts: 가 어느 기계에 적용할지입니다. tasks: 아래가 그 기계에서 할 일입니다. 이 파일은 ansible-playbook -i inventory.ini playbook.yaml 로 실행합니다. 각 기계에 하나씩 접속해 명령을 치는 일은 사람이 하지 않습니다. 사람이 하는 일은 이 파일을 적는 것까지입니다.

Kubernetes 컨트롤러

앞의 셋에는 사람이 명령을 걸거나 코드를 밀어 넣는 순간이 있습니다. 그 순간마저 없는 자리도 있습니다. 쿠버네티스 공식 문서는 컨트롤러를 제어 루프라고 적습니다. 로봇공학과 자동화에서 제어 루프는 시스템의 상태를 조절하는, 끝나지 않는 루프입니다. 쿠버네티스에서 컨트롤러는 클러스터의 상태를 지켜보다가 필요한 곳에 변경을 만들거나 요청합니다. 컨트롤러 하나하나가 현재 상태를 원하는 상태에 가깝게 옮기려고 합니다.

flowchart TD
    A[원하는 상태] --> C{다른가}
    B[현재 상태] --> C
    C -->|다르다| D[변경을 만들거나 요청]
    D --> B
    C -->|같다| B

원하는 상태를 한 번 적어 두면 그 뒤로는 이 루프가 계속 돕니다. 사람이 다시 부를 계기를 만들어 주지 않아도 됩니다.

대가

규모를 타는 실수

구글 사이트 신뢰성 엔지니어링 책은 자동화를 다루는 장에서 자기들이 겪은 사고를 적습니다. 구글은 여러 코로케이션 시설에 기계를 둡니다. 그 기계는 들어오는 연결 대부분을 받아 처리하거나 자체 콘텐츠 전송 네트워크의 캐시로 씁니다. 랙을 들여놓고 걷어내는 일은 대부분 자동화되어 있습니다. 걷어내는 절차에는 랙 안 모든 기계의 디스크 내용을 통째로 덮어쓰는 단계가 있습니다. 그 단계를 그들은 diskerase 라고 부릅니다.

어느 날 한 랙을 걷어내던 자동화가 실패했습니다. 실패한 시점은 diskerase 단계를 성공으로 마친 뒤였습니다. 원인을 보려고 절차를 처음부터 다시 돌렸습니다. 이번 회차에서 자동화는 아직 지워야 할 기계의 집합이 비어 있다고 판정했습니다. 그 판정은 맞았습니다. 그런데 그 빈 집합이 특별한 값으로 쓰이고 있었습니다. 뜻은 "전부" 였습니다. 자동화는 모든 코로케이션 시설의 기계를 거의 전부 diskerase 로 보냈습니다. 몇 분 만에 콘텐츠 전송 네트워크의 모든 기계에서 디스크가 지워졌습니다. 그 기계들은 사용자 연결을 더 받지 못했습니다.

그 장의 사이드바 제목이 이것을 한 줄로 적습니다. "Automation: Enabling Failure at Scale." 자동화는 맞는 일을 규모로 합니다. 틀린 일도 같은 규모로 합니다. 책은 자기 데이터센터에서 사용자를 계속 받을 수 있었다고 적습니다. 몇 분 뒤 밖에서 보이는 영향은 지연이 조금 늘어난 정도였다고 적습니다. 용량 계획을 해 둔 덕이라고 적습니다. 자기들이 아는 한 문제를 알아챈 사용자는 거의 없었다고 덧붙입니다.

멀어지는 운영자

같은 장은 다른 대가를 하나 더 적습니다. 자동화는 시간이 갈수록 나날의 일을 더 많이 덮어 갑니다. 그럴수록 사람 운영자는 시스템과 직접 닿는 자리에서 점점 물러납니다. 그러면 결국 자동화가 실패하는 상황이 옵니다. 그때 사람은 시스템을 제대로 다루지 못합니다. 손을 놓고 있었으므로 반응이 굳었습니다. 시스템이 무엇을 하고 있어야 하는지에 대한 머릿속 그림도 실제와 어긋나 있습니다.

같은 장은 신뢰성이 근본 기능이라고 적습니다. 자율적이고 회복력 있는 동작은 그 신뢰성을 얻는 한 가지 방법이라고 덧붙입니다.

자동화라는 또 하나의 물건

자동화 단계들은 저마다 값어치가 있습니다. 자동화 플랫폼 자체도 값어치가 있습니다. 다만 같은 장은 이상적인 세계라면 바깥에 둔 자동화가 필요 없을 것이라고 적습니다. 밖에 붙인 자동화는 시스템 자체가 아니라 그 바깥에 따로 둔 물건입니다.

일관성과의 맞바꿈

무엇을 내주는지만 보면 한쪽만 봅니다. 무엇을 얻는지도 같은 장에 적혀 있습니다. 사람 한 사람 또는 여럿이 수백 번 수행하는 동작은 매번 같은 방식으로 되지 않습니다. 아무리 마음을 먹어도 기계만큼 일관된 사람은 거의 없다고 책은 적습니다. 이 피할 수 없는 일관성의 부족이 실수와 누락과 데이터 품질 문제와 신뢰성 문제로 이어집니다. 범위가 분명하고 알려진 절차를 수행하는 영역에서는 일관성이 여러 면에서 자동화의 으뜸가는 값어치라고 적습니다.

플랫폼은 실수를 한자리에 모읍니다. 코드에서 고친 버그는 그 자리에서 한 번에 영원히 고쳐집니다. 같은 절차를 사람 여럿이 수행할 때와 다른 점입니다. 뒤집으면 잘못도 한자리에 모입니다. 빈 집합의 뜻을 정한 자리는 하나였습니다. 그 하나가 모든 시설에 걸렸습니다.

관련 항목

자동화가 거치는 배포 파이프라인의 단계

빌드 · 지속적 통합 · 지속적 배포 · 배포 · 롤백 · 단계적 출시 · 커밋에서 배포까지

자동화가 흔히 적용되는 운영 작업

코드형 인프라 · 오케스트레이션 · 스케줄링 · 백업과 복구 · QA와 테스트

자동화를 실제로 구현하는 도구

GNU Make · GitHub Actions · Ansible · Kubernetes

절차를 적어 두는 파일 형식

파이프라인 · 워크플로 · 플레이북 · 선언형 설정

적어 둔 절차를 돌리는 실행 장치

러너 · 크론 · 제어 루프 · 컨트롤러

자동화를 지켜보는 관측 수단

모니터링 · 알림 · 관측성 · 계측

자동화를 재는 지표

배포 빈도 · 변경 리드 타임 · 변경 실패율 · 서비스 수준 목표

자동화가 깨질 때 뒤따르는 대응 절차

사고 대응 · 런북 · 폭발 반경 · 사후 분석

자동화가 지키거나 잃는 성질

멱등성 · 일관성 · 신뢰성 · 고가용성 · 회복력

자동화가 핵심 관행인 상위 실무 분야

데브옵스 · 플랫폼 엔지니어링 · SRE · 릴리스 엔지니어링 · 머신러닝

자동화 사례가 다루는 시스템과 환경 요소

클러스터 · 네트워크 · 캐싱 · 디스크 · CDN(Content Delivery Network, 콘텐츠 전송 네트워크) · 지연 · 운영체제 · 브랜치