아티팩트

배포가 사람 손으로 이뤄지던 시절에는 개발자가 자기 노트북에서 코드를 실행 가능한 형태로 바꾼 뒤 그 결과를 서버에 직접 올렸습니다. 문제는 올릴 때마다 물건을 새로 만들었다는 데 있었습니다. 시험용 서버에 올릴 때 한 번 만들고, 며칠 뒤 진짜 서버에 올릴 때 또 한 번 만들었습니다. 두 번 다 같은 코드에서 출발했으니 같은 물건이 나온다고 여겼는데 실제로는 그렇지 않았습니다. 외부에서 가져다 쓰는 라이브러리가 그사이 새 버전을 냈거나, 만든 사람의 컴퓨터에 깔린 도구 버전이 달랐기 때문입니다.

페이지덱도 같은 자리에서 한 번 걸렸습니다. 태오가 시험용 서버에서 사흘을 들여 결제 화면을 검증하고 이상 없다고 확인한 뒤, 목요일 저녁에 진짜 서버로 올렸더니 결제창이 열리지 않았습니다. 코드는 한 줄도 달라지지 않았습니다. 목요일에 다시 만드는 과정에서 날짜 처리 라이브러리가 최신 버전으로 딸려 들어왔고, 그 버전에서 함수 하나의 동작이 바뀌어 있었습니다. 검증한 물건과 올라간 물건이 다른 물건이었던 것입니다.

아티팩트는 이 구멍을 막으려고 생긴 개념입니다. 코드가 아니라 만들어진 결과물 자체를 하나의 물건으로 보고, 이름을 붙여 보관한 뒤 그 물건을 여기저기 옮겨 씁니다. 한 번 만들어 여러 곳에 올린다는 원칙이 여기서 나옵니다. 검사한 것과 올라간 것이 같다는 보장을 코드가 아니라 물건 단위로 만든 셈입니다.

한 덩어리 안에는 그 소프트웨어가 낯선 서버에서 혼자 돌아가는 데 필요한 것이 들어갑니다. 네 가지입니다.

1. 실행할 수 있는 형태로 바뀐 본체입니다. 웹이라면 브라우저가 읽을 수 있게 합쳐 놓은 파일 묶음이고, 서버 프로그램이라면 실행 파일이나 컨테이너 이미지입니다. 컨테이너는 실행에 필요한 것을 통째로 싸서 어느 서버에서든 같게 돌게 만든 단위입니다.
2. 화면에 필요한 자료입니다. 이미지, 글꼴, 스타일 파일처럼 코드는 아니지만 없으면 화면이 깨지는 것들입니다.
3. 외부에서 가져다 쓰는 라이브러리입니다. 이때 버전을 고정해 함께 담습니다. 목록만 담고 서버에서 그때그때 내려받게 두면 앞의 결제창 사고가 그대로 재현됩니다.
4. 이 물건이 무엇인지 적은 꼬리표입니다. 버전 번호, 만들어진 시각, 어느 코드 변경에서 나왔는지를 가리키는 식별자가 들어갑니다. 장애가 났을 때 지금 돌아가는 것이 어느 코드인지 되짚는 통로가 이 꼬리표입니다. 번호는 대개 시맨틱 버저닝을 따라 세 자리로 붙입니다.

들어가지 않는 것도 정해져 있습니다. 환경 변수와 시크릿 관리 대상인 값은 안에 넣지 않습니다. 환경 변수는 실행되는 곳마다 다르게 꽂아 주는 설정 값이고, 시크릿은 그중 새면 안 되는 결제 키나 데이터베이스 비밀번호입니다. 이런 값을 물건 안에 넣어 버리면 시험용과 운영용 아티팩트가 서로 다른 물건이 되어, 한 번 만들어 여러 곳에 올린다는 원칙이 무너집니다. 값은 물건 밖에 두고 실행되는 순간에 주입합니다.

만드는 쪽은 사람이 아니라 기계입니다. 태오가 고친 코드를 공용 가지에 합치면 파이프라인의 빌드 단계가 자동으로 물건을 만들고, 통과한 물건을 저장소에 올려 둡니다. 사람이 자기 컴퓨터에서 만들어 올리는 경로가 하나라도 열려 있으면 그 경로로 나간 물건만 검사를 건너뛰게 되므로, 만드는 자리를 한 곳으로 묶는 것이 이 방식의 전제입니다.

꺼내 쓰는 쪽은 넷입니다.

1. 배포 단계가 가장 먼저 씁니다. 시험용 환경에 올릴 때도, 운영 환경에 올릴 때도 저장소에서 같은 물건을 꺼냅니다.
2. 검수하는 사람이 씁니다. 지현이 시험용 서버에서 확인한 화면이 곧 다음 주에 고객이 볼 화면이라는 말이 이 지점에서 성립합니다.
3. 장애를 처리하는 사람이 씁니다. 롤백은 코드를 되돌려 다시 만드는 일이 아니라 어제 쓰던 물건을 저장소에서 꺼내 다시 올리는 일입니다. 만드는 과정이 빠지니 몇 분 안에 끝납니다.
4. 보안을 점검하는 사람이 씁니다. 어떤 라이브러리가 어느 버전으로 들어갔는지가 물건 안에 적혀 있어, 취약점이 알려졌을 때 영향받는 버전을 추려 낼 수 있습니다.

그래서 아티팩트는 배포가 끝났다고 버리지 않고 버전마다 쌓아 둡니다. 보관 기간은 팀이 정하는데, 되돌아갈 수 있어야 하는 기간보다는 길게 잡습니다.

"시험용에서 검증한 아티팩트 그대로 운영에 올리는 거 맞죠?"

중간에 다시 만들지 않았는지 확인하는 말입니다.

"지금 돌아가는 게 몇 번이에요? 아티팩트 꼬리표에 커밋 남아 있죠?"

장애가 난 서버에 올라간 물건이 어느 코드인지 되짚는 질문입니다.

"롤백은 어제 아티팩트 다시 올리면 됩니다. 5분이면 끝나요."

되돌릴 물건이 저장소에 남아 있다는 뜻입니다.

페이지덱에서는 태오가 코드를 합치는 순간부터 사람 손이 닿지 않습니다. 기계가 물건을 만들어 저장소에 번호를 붙여 넣고, 시험용 서버가 그 번호를 꺼내 올립니다. 지현이 화면을 확인하고 나가도 좋다고 하면 운영 서버가 같은 번호를 꺼냅니다. 회의에서 "1.4.2 나갔어요" 라는 말이 오갈 때 그 번호는 코드의 이름이 아니라 물건의 이름입니다.

같은 코드면 언제 만들어도 같은 물건이 나온다고 여기는 경우가 가장 많습니다. 코드가 원본이고 만드는 과정은 기계가 하는 단순 변환이니 그렇게 보이기 쉽습니다. 하지만 그 과정은 외부 라이브러리와 도구를 그 시점에 끌어다 쓰기 때문에 시점이 다르면 재료가 달라집니다. 이 차이를 믿지 않으면 환경마다 새로 만드는 습관이 남고, 시험용에서 멀쩡하던 기능이 운영에서만 깨지는 사고가 몇 달에 한 번씩 되풀이됩니다.

배포가 끝나면 지워도 된다고 여기는 것도 흔합니다. 이미 서버에 올라갔으니 원본은 쓸모가 없어 보이고, 저장 공간도 아낄 수 있을 것 같습니다. 하지만 되돌려야 하는 순간은 늘 예고 없이 오고, 그때 저장소가 비어 있으면 코드를 다시 만드는 것부터 시작해야 합니다. 5분이면 끝날 복구가 30분으로 늘어나고, 다시 만든 물건이 어제 돌던 그 물건이라는 보장도 사라집니다.