빌드

예전에는 개발자가 자기 노트북에서 명령어 몇 개를 손으로 쳐서 결과물을 만들고 그 파일을 서버에 올렸습니다. 문제는 노트북마다 사정이 달랐다는 데 있습니다. 누구는 언어 버전이 한 단계 높았고, 누구는 반년 전에 받아 둔 라이브러리를 그대로 쓰고 있었고, 누구는 자기만 고쳐 둔 설정 파일이 폴더에 남아 있었습니다. 같은 코드에서 서로 다른 결과물이 나왔고, 어느 것이 서버에 올라갔는지는 올린 사람만 알았습니다.

그래서 장애가 나면 회의가 늘 같은 자리에서 멈췄습니다. "제 컴퓨터에서는 되는데요" 하는 말이 나오면 더 따질 방법이 없었습니다. 실제로 돌아간 결과물이 어떤 코드로 만들어졌는지 아무도 적어 두지 않았으니, 재현할 수 없는 고장을 두고 추측만 오갔습니다.

빌드는 이 과정을 사람 손에서 떼어 내 기계가 늘 같은 자리에서 같은 순서로 하게 만들면서 이름을 얻었습니다. 어느 노트북이 아니라 정해진 서버 한 곳에서, 저장소에 올라온 코드만 가지고, 매번 처음부터 다시 만듭니다. 그러면 결과물 하나마다 어떤 커밋에서 나왔는지가 남고, 고장을 그 커밋으로 되짚어 갈 수 있습니다.

빌드 구간은 소스 코드를 받아 배포할 수 있는 결과물 한 덩어리를 내놓는 구간입니다. 파이프라인이 여러 구간을 순서대로 엮어 둔 자동 흐름이라면, 빌드는 그 흐름의 첫 번째 칸입니다. 뒤에 붙는 테스트도 배포도 여기서 나온 덩어리를 가지고 일합니다.

안에서 벌어지는 일은 대개 네 단계입니다.

1. 의존성 내려받기 — 남이 만들어 둔 라이브러리를 목록에 적힌 버전 그대로 받아 옵니다. 버전을 정확히 적어 두지 않으면 어제 빌드와 오늘 빌드가 다른 라이브러리를 쓰게 됩니다.
2. 변환 — 사람이 쓴 문법을 실행 환경이 아는 형태로 바꿉니다. 타입을 적어 둔 코드에서 타입 표기를 걷어 내거나, 최신 문법을 옛 브라우저도 아는 문법으로 낮추는 일이 여기서 일어납니다.
3. 묶기 — 흩어진 파일을 배포하기 좋은 단위로 합치고 군더더기를 걷어 냅니다. 화면 쪽 코드라면 번들러가 이 일을 맡습니다.
4. 이름 붙이기 — 나온 덩어리에 버전과 커밋 번호를 박아 둡니다. 나중에 "지금 운영에 떠 있는 게 어느 코드냐" 를 답하는 근거가 이 이름입니다.

이 구간에는 사람이 끼어들지 않습니다. 코드가 올라오면 저절로 시작해 끝까지 혼자 돕니다. 걸리는 시간은 작은 서비스면 1분 안쪽, 파일이 수만 개인 저장소면 20분을 넘기도 합니다. 그래서 한 번 받아 둔 라이브러리를 다음 빌드에서 다시 쓰게 해 시간을 줄입니다.

실패하면 그 자리에서 멈춥니다. 문법이 틀렸거나 없는 함수를 불렀거나 라이브러리를 못 받아 오면 빌드가 깨지고, 테스트는 시작조차 하지 않습니다. 가장 싸고 빠른 검사가 여기 있습니다.

빌드가 끝났다고 다음 칸이 열리지는 않습니다. 보통 세 가지를 확인한 뒤에 테스트 구간으로 넘어갑니다.

1. 빌드 명령이 성공으로 끝났는가. 기계는 성공과 실패를 숫자 하나로 알리고, 0 이 아니면 파이프라인이 그 자리에서 멈춥니다. 경고까지 실패로 볼지는 팀이 정합니다. 린터가 잡아 준 규칙 위반을 경고로 두면 아무도 안 고치니 실패로 올려 두는 팀이 많습니다.
2. 결과물이 실제로 나왔고 보관소에 올라갔는가. 만든 덩어리를 빌드 서버 안에만 두면 그 서버가 다음 작업으로 넘어가는 순간 사라집니다. 아티팩트 저장소에 올려 두어야 테스트와 배포가 같은 물건을 꺼내 씁니다.
3. 같은 코드에서 같은 결과가 나오는가. 어제 만든 것과 오늘 만든 것이 다르면 테스트를 통과한 물건과 서버에 올라간 물건이 달라질 수 있습니다. 라이브러리 버전을 잠가 두고 빌드 때 시각이나 무작위 값을 끼워 넣지 않으면 대체로 지켜집니다.

셋이 다 맞으면 이 덩어리를 환경마다 옮겨 가며 확인합니다. 개발·스테이징·운영처럼 목적이 다른 실행 공간이 환경인데, 환경이 바뀐다고 새로 빌드하지는 않습니다. 새로 만들면 검사를 통과한 물건과 다른 물건이 운영에 올라갑니다. 환경 사이의 차이는 결과물이 아니라 환경 변수로 냅니다. 같은 덩어리를 두고 스테이징에서는 시험용 결제 서버 주소를, 운영에서는 진짜 주소를 꽂아 주는 식입니다.

"빌드 깨졌어요. 지금 올린 커밋부터 보셔야 할 것 같아요."

방금 합쳐진 코드 때문에 파이프라인이 첫 칸에서 멈췄으니 뒤에 줄 선 작업이 전부 대기 중이라는 뜻입니다.

"그거 빌드는 통과했는데 테스트에서 걸렸어요."

문법과 의존성은 맞았지만 동작이 기대와 달랐다는 말이라, 고칠 곳이 설정이 아니라 로직 쪽이라는 신호입니다.

"빌드 시간이 18분이라 한 번 돌리고 커피 마시고 와요."

농담처럼 들리지만 피드백이 늦다는 불만이고, 캐시를 걸거나 검사를 나눠 돌리자는 제안이 뒤따릅니다.

페이지덱에서는 태오가 코드를 합칠 때마다 빌드가 저절로 돕니다. 화면 상단에 초록색이면 통과, 빨간색이면 실패가 뜨고, 실패하면 합친 사람에게 바로 알림이 갑니다. 규칙은 하나입니다. 빨간불을 켜 둔 채로 퇴근하지 않습니다. 빌드가 깨져 있는 동안에는 다른 사람의 코드도 검사를 못 받기 때문입니다.

지현은 일정 때문에 이 화면을 봅니다. 빌드가 자주 깨진 주에는 릴리스 날짜를 당기지 않습니다. 깨진 횟수가 늘었다는 건 합치기 전에 각자 확인하는 절차가 헐거워졌다는 뜻이기 때문입니다.

빌드 성공을 코드가 맞다는 뜻으로 읽는 경우가 가장 많습니다. 초록불이 떴으니 괜찮다고 보는 것인데, 사실 확인된 것은 기계가 이 코드를 실행 가능한 형태로 옮길 수 있었다는 사실 하나뿐입니다. 로그인 버튼을 눌렀을 때 엉뚱한 화면으로 가는 코드도 문법만 맞으면 빌드는 멀쩡히 통과합니다. 그대로 믿고 넘기면 테스트를 건너뛰는 습관이 붙고, 결국 고객이 첫 번째 검사자가 됩니다.

내 노트북에서 만든 결과물을 그대로 올려도 된다고 생각하는 것도 같은 뿌리의 오해입니다. 어차피 같은 코드에서 같은 명령을 돌렸으니 결과도 같으리라고 보기 쉽습니다. 하지만 노트북에는 저장소에 올리지 않은 파일과 개인 설정이 남아 있어서, 그렇게 만든 덩어리는 누구도 다시 만들어 낼 수 없습니다. 장애가 났을 때 되짚을 코드가 없고, 되돌릴 이전 결과물도 남아 있지 않습니다.