파이프라인

배포가 손기술이던 시절이 있었습니다. 순서를 적어 둔 문서가 있고 사람이 그 스무 줄을 위에서부터 따라가며 명령을 하나씩 실행했습니다. 문서가 있으니 괜찮아 보이지만, 스무 줄 중 한 줄을 빼먹었을 때 그 사실을 알려 주는 것은 아무것도 없었습니다.

그래서 사고가 같은 모양으로 반복됐습니다. 금요일 오후에 배포하다가 설정 값 하나를 옛 값으로 둔 채 올려 결제가 30분 멈추는 식입니다. 원인을 찾는 데 20분이 걸리고, 무엇을 어느 순서로 했는지 물으면 기억에 의존한 답이 나옵니다. 기록이 사람 머릿속에만 있었습니다.

배포할 수 있는 사람이 한두 명으로 묶이는 문제도 같이 붙었습니다. 문서에 적히지 않은 요령을 아는 사람만 끝까지 갈 수 있으니, 그 사람이 휴가를 가면 그 주에는 아무것도 나가지 않습니다. 파이프라인은 이 순서를 기계가 읽는 파일로 옮겨 적어, 사람이 하던 일을 기계가 같은 순서로 반복하게 만든 것입니다.

사람이 순서대로 하던 일을 기계가 매번 같은 순서로 돌립니다. 흔히 다섯 단계로 짭니다.

1. 코드를 받아옵니다. 저장소의 어느 가지에 어떤 변경이 올라왔는지로 시작하고, 어느 시점의 코드인지가 기록에 남습니다.
2. 실행할 수 있는 형태로 만듭니다. 소스 코드를 결과물로 바꾸는 과정을 빌드라 하고, 그 결과로 나온 배포용 산출물을 아티팩트라 합니다. 여기서 만든 아티팩트 하나를 뒤 단계가 전부 그대로 씁니다. 단계마다 다시 빌드하면 같은 코드에서 다른 결과물이 나옵니다.
3. 검사를 돌립니다. 자동 테스트와 코드 규칙 검사가 여기 들어가고, 실패하면 흐름이 멈춰 뒤 단계로 넘어가지 않습니다. 이 멈춤이 파이프라인이 실제로 하는 일의 절반입니다.
4. 환경에 올립니다. 개발·스테이징·운영처럼 목적이 다른 실행 공간이 환경이고, 보통 스테이징에 먼저 올려 확인한 뒤 운영으로 갑니다. 환경마다 달라야 하는 값은 환경 변수로 주입하고, 그중 키와 비밀번호처럼 노출되면 안 되는 것은 시크릿 관리 쪽에 따로 보관합니다.
5. 올린 뒤를 확인합니다. 응답이 정상인지 몇 분 지켜보고 이상하면 앞 버전으로 되돌립니다.

얻는 것은 넷입니다. 순서가 매번 같고, 누가 언제 무엇을 올렸는지가 기록에 남고, 적히지 않은 요령이 없으니 누구나 배포할 수 있고, 실패했을 때 어느 단계에서 멈췄는지가 화면에 나옵니다.

대가는 시간입니다. 처음 만드는 데 며칠이 들고, 더 큰 비용은 한 번 도는 시간입니다. 10분을 넘기면 사람들이 병합을 미루기 시작하고, 미룬 변경이 쌓이면 한 번에 합쳐지면서 원래 없애려던 위험이 되돌아옵니다.

대안은 셋이고, 자동화를 어디까지 하느냐로 갈립니다.

첫째는 명령 하나로 묶은 배포 스크립트입니다. 스무 줄짜리 문서를 파일 하나로 옮겨 적고 사람이 그 파일을 실행합니다. 순서가 빠질 일은 사라지고 만드는 데 반나절이면 됩니다. 남는 문제는 기록과 권한입니다. 누가 언제 돌렸는지가 남지 않고, 실행할 수 있는 사람이 노트북에 열쇠를 들고 있는 사람으로 정해집니다.

둘째는 플랫폼에 맡기는 것입니다. 개발·배포 환경을 빌려 주는 서비스를 쓰면 저장소를 연결하는 것만으로 기본 흐름이 붙어 옵니다. 직접 짤 일이 없어 빠르지만 우리만의 검사를 끼우기 어렵고, 정해 둔 방식 밖으로 나가면 막힙니다.

셋째는 단계를 줄이는 것입니다. 검사를 빼고 빌드와 배포만 남기면 한 번 도는 시간이 3분으로 줄어듭니다. 맞는 구간은 실제로 있습니다. 사용자가 없는 초기 제품에서는 깨진 것을 빨리 고치는 편이 미리 막는 것보다 쌉니다. 다만 사용자가 생긴 뒤에도 그대로 두면, 검사를 빼서 아낀 7분이 장애 한 번에 다 날아갑니다.

배포가 한 달에 한 번이고 만드는 사람이 둘인 팀에서는 첫째로 충분한 경우가 많습니다. 파이프라인을 짜고 돌보는 시간이 아직 얻는 것보다 큰 구간입니다.

"파이프라인이 3단계에서 멈췄어요. 테스트 두 개가 깨졌습니다."

어디서 멈췄는지가 특정돼 있으니 그 자리만 보면 된다는 말입니다.

"한 번 도는 데 18분이에요. 사람들이 병합을 미루기 시작했습니다."

흐름이 느려 원래 목적이 깨지고 있다는 지적입니다.

"스테이징에는 올라갔는데 운영은 수동 승인이에요."

마지막 한 걸음만 사람이 누르는 구조라는 뜻입니다.

페이지덱은 태오가 만든 파이프라인을 씁니다. 다섯 단계이고 한 번 도는 데 7분입니다. 예전에는 태오만 배포할 수 있었는데, 지금은 코드를 합치면 스테이징까지 자동으로 가고 운영으로 올리는 버튼은 누구나 누를 수 있습니다.

한 번은 이 시간이 22분까지 늘어났습니다. 지현이 사람들의 병합 시점을 확인해 보니 오후에 몰려 있었습니다. 아침에 합치면 오전을 기다려야 해서 미룬 것입니다. 태오가 테스트를 두 갈래로 나눠 빠른 쪽만 병합 시점에 돌리게 고쳐 8분으로 되돌렸습니다.

파이프라인이 있으면 배포가 안전해진다고 읽는 경우가 가장 많습니다. 자동으로 검사하고 자동으로 올리니 사람이 실수할 자리가 없어 보입니다. 하지만 이 흐름이 보장하는 것은 순서가 같다는 것뿐이고, 무엇을 검사할지는 사람이 적어 둔 대로입니다. 테스트가 세 개뿐인 파이프라인은 세 개만 확인하고 초록불을 켭니다. 초록불을 안전으로 읽기 시작한 팀은 배포 뒤에 아무도 화면을 열어 보지 않게 되고, 그래서 장애를 사용자 문의로 처음 알게 됩니다.

단계를 많이 넣을수록 좋다고 보는 시각도 자주 나옵니다. 검사가 많으면 걸러지는 것도 많다는 계산은 맞습니다. 문제는 그 계산에 시간이 빠져 있다는 것입니다. 단계를 열 개로 늘려 40분이 걸리면 사람들은 파이프라인이 도는 동안 다른 일을 시작하고, 실패 알림을 두 시간 뒤에 봅니다. 그때는 이미 다른 변경을 세 개 더 얹어 놓아서 무엇이 원인인지 다시 찾아야 합니다. 검사를 빠른 것과 느린 것으로 나눠, 병합 시점에는 빠른 쪽만 돌리고 느린 쪽은 밤에 몰아 돌리는 편이 대개 낫습니다.