릴리스 엔지니어링

소스 코드를 사용자가 쓸 수 있는 물건으로 만들어 내보내는 일을 하나의 일로 맡는 자리입니다. 빌드하고 묶고 라벨을 붙여 내보내는 과정 전체가 여기 들어옵니다. 무엇을 하는 일이냐는 물음의 답이 한 문장이 아니라 목록으로 열립니다.

쉽고 빠른 이해

이 구역이 무엇을 다루나 — 소스 코드가 사용자가 쓸 수 있는 물건이 되기까지의 전 과정입니다. 빌드하고 묶고 라벨을 붙이는 일부터, 그 패키지를 어떤 단계를 거쳐 내보낼지 정하는 일까지 들어갑니다. 이게 있어야 하는 이유도 뚜렷합니다 — 믿을 수 있는 서비스를 굴리려면 믿을 수 있는 릴리스 과정이 있어야 하기 때문입니다.

왜 한 문장 정의가 안 서나 — 정의의 주어가 한 문서 안에서도 바뀝니다. 같은 문서가 첫 문단에서는 이것을 「분야」라 부르고, 한 문단 뒤에서는 다시 「직무」라 부릅니다. 그래서 답이 한 문장으로 닫히지 않고 브랜치 전략, 테스트, 패키징, 배포, 설정 관리 같은 목록으로 열립니다.

안에서 무엇으로 갈리나 — 이 이름이 사람이 맡는 자리를 가리키는지, 소스에서 릴리스를 만들어 내놓는 과정을 가리키는지가 갈립니다. 한쪽은 배포와 롤백 전략까지 이 안에 넣고, 다른 쪽은 완성된 산출물을 만들어 내놓는 데까지로 좁혀 봅니다. 그래서 소스부터 배포까지 함께 가리키고 싶을 때 이 이름을 쓰고, 만든 산출물 자체만 가리키고 싶을 때는 더 좁은 이름을 씁니다.

상세

Google SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) Book 8장은 릴리스 엔지니어링을 소프트웨어 엔지니어링의 비교적 새롭고 빠르게 자라는 분야라고 적습니다. 소프트웨어를 빌드하고 전달하는 일로 간결히 기술할 수 있다고 덧붙입니다. 이 한 줄은 무엇인지를 끝내는 정의가 아니라 어디쯤인지를 가리키는 위치 지정입니다. 무엇을 하는지는 만든 패키지를 보면 드러납니다. 패키지에는 dev·canary·production 같은 라벨이 붙어, 그 패키지가 지금 릴리스 과정의 어느 단계에 있는지를 보여줍니다. 이 중 canary 는 새 버전으로 만든 작업 몇 개만 운영 환경에 먼저 돌려 살피는 라벨을 가리킵니다.

같은 절이 이어서 릴리스 엔지니어가 무엇을 아는 사람인지 적습니다. 전문가 수준까지는 아니더라도 탄탄하게 이해하는 것들이 있다고 적습니다. 그리고 여러 영역에 걸친 깊은 지식을 함께 갖는다고 적습니다.

Google 은 이것을 자기 회사의 특정 직무라고 못 박습니다. 릴리스 엔지니어가 제품 개발 쪽 소프트웨어 엔지니어 및 SRE 담당자와 함께 소프트웨어를 릴리스하는 데 필요한 모든 단계를 정의한다고 적습니다. 소스 코드 저장소에 소프트웨어를 어떻게 보관하는지부터 시작합니다. 컴파일을 위한 빌드 규칙이 그 다음입니다. 테스트와 패키징과 배포를 어떻게 수행하는지까지 이어집니다.

이 구역이 무엇을 요구하는지도 같은 장이 적어 둡니다. 믿을 수 있는 서비스를 굴리려면 믿을 수 있는 릴리스 과정이 필요하다고 적습니다. SRE 는 자기가 쓰는 바이너리와 설정이 재현 가능하고 자동화된 방식으로 빌드되었음을 알아야 한다고 적습니다. 그래야 릴리스가 되풀이 가능해지고 하나뿐인 눈송이가 되지 않는다는 것입니다 — 손으로 하나하나 매만져 놓아서 다시는 똑같이 못 만드는 상태를 말합니다. 관련 항목의 「스노플레이크 서버」가 이 상태를 가리키는 다른 이름입니다. 릴리스 과정의 어느 면을 바꾸든 그 변경은 우연이 아니라 의도로 일어나야 한다고 적습니다. 그리고 SRE 가 소스 코드에서 배포까지 이 과정을 신경 쓴다고 덧붙입니다.

한 문장 정의가 왜 안 서는지는 정의의 주어를 보면 드러납니다. 같은 문서 안에서도 첫 문단은 「분야」이고 한 문단 뒤에서는 「직무」입니다. 둘 다 사람이 그 안에서 일하는 구역을 가리키는 말입니다. 그래서 답이 한 문장으로 닫히지 않고 이 구역에서 마주치는 것들의 목록으로 열립니다. 같은 장의 구성 자체가 그 목록입니다. 브랜치 전략, 밀폐 빌드, 테스트, 패키징, 배포, 설정 관리가 각각 다른 절로 나뉘어 있습니다.

경계

패키지에 라벨을 붙이는 데까지

빌드해서 패키지에 라벨을 붙이는 데까지만 하면 이 구역인가. 그것도 이 구역입니다. 다만 거기가 이 구역의 끝은 아닙니다.

근거는 SRE Book 8장의 패키징 대목입니다. 패키지에 이름이 붙는다고 적습니다. 고유한 해시로 버전이 매겨진다고 적습니다. 진위를 보장하려고 서명한다고 적습니다. 그 위에 라벨을 붙일 수 있다고 적습니다. 라벨은 그 패키지가 릴리스 과정 어디에 있는지를 가리킵니다. 앞서 든 dev·canary·production 이 그 라벨의 예입니다. 기존 라벨을 새 패키지에 붙이면 그 라벨은 옛 패키지에서 새 패키지로 자동으로 옮겨 간다고 적습니다.

라벨은 과정 안의 위치를 가리키는 표지입니다. 과정이 거기서 끝났다는 표시가 아닙니다.

같은 장은 배포를 패키징과 다른 절에 따로 둡니다. 단순한 배포를 직접 구동하는 데는 Rapid 가 흔히 쓰인다고 적습니다. 새로 빌드한 패키지로 운영 중인 작업을 갱신해 배포를 구동하는 도구입니다. 더 복잡한 배포에는 Sisyphus 를 쓴다고 적습니다. SRE 가 만든 범용 롤아웃 자동화 프레임워크라고 적습니다. 롤아웃은 하나 이상의 개별 작업으로 이루어진 한 단위의 일을 가리킵니다.

선은 그래서 이렇습니다. 빌드하고 묶고 라벨을 붙이는 일은 이 구역 안입니다. 그 패키지를 어떤 단계를 거쳐 내보낼지 정하는 일도 이 구역 안입니다. 그 내보내기를 굴리는 자동화 프레임워크를 만든 쪽은 SRE 라고 같은 장이 적습니다. 그래서 소스에서 시작해 배포까지 함께 가리키고 싶을 때 이 이름을 씁니다. 만든 패키지 자체나 그 안의 한 단계만 가리키고 싶을 때는 빌드나 패키지처럼 더 좁은 이름을 씁니다.

이견

이 이름이 사람이 맡는 자리를 가리키는지, 아니면 소스에서 릴리스를 만들어 내놓는 과정을 가리키는지가 진영마다 갈립니다.

Google SRE Book 8장은 이것을 Google 안의 특정 직무라고 적습니다. 릴리스 엔지니어라는 사람이 따로 있고 그 사람이 릴리스의 단계를 정의한다는 것입니다. 그 이름 안에 무엇이 들어가는지도 같은 장이 적어 둡니다. 릴리스 과정이 사업 요구를 채우도록 릴리스 엔지니어와 SRE 가 함께 전략을 만든다고 적습니다. 변경을 카나리로 내보내는 전략, 서비스를 끊지 않고 새 릴리스를 밀어 넣는 전략, 문제를 드러낸 기능을 되돌리는 전략입니다. 실제로 도는 것을 바꾸는 자리까지 이 이름 안에 들어옵니다.

워털루대학교의 Shane McIntosh 는 이것을 직무가 아니라 과정으로 정의합니다. 그는 자기 연구실을 소개하는 글에서 소프트웨어 저장소 발굴과 빌드 엔지니어링 연구실을 이끈다고 적습니다. 그리고 자기 연구 분야인 릴리스 엔지니어링을 소스로부터 소프트웨어 시스템의 릴리스를 조립하고 검증하고 전달하는 과정이라고 적습니다. 주어가 사람이나 팀이 아닙니다. 이 이름이 가리키는 것은 그 과정 자체입니다. 전달이 어디서 끝나는지는 그 글이 적지 않습니다.

어느 쪽이 맞는지는 여기서 판정하지 않습니다. 한쪽은 이 이름을 사람이 맡는 직무로 두고 배포까지 그 안에 넣습니다. 다른 쪽은 소스에서 릴리스를 만들어 내놓는 과정의 이름으로 씁니다.

관련 항목

릴리스 과정을 이루는 구성 요소

소스 코드 관리 · 버전관리 · 메인라인 · 브랜치 전략 · 체리픽 · 빌드 · 밀폐 빌드 · 빌드 아티팩트 · 패키지 · 컨테이너 이미지 · 버전 번호 · 시맨틱 버저닝 · 깃 태그 · 릴리스 노트 · 체인지로그

내보내는 방식

지속적 통합 · 지속적 전달 · 지속적 배포 · 배포 · 점진적 롤아웃 · 카나리 배포 · 단계적 출시 · 기능 플래그 · 롤백 · 핫픽스

재현을 지키는 장치

설정 관리 · 코드형 인프라 · 재현 가능한 빌드 · 아티팩트 저장소 · 패키지 서명 · 소프트웨어 공급망 보안

릴리스 과정을 재는 지표

배포 빈도 · 변경 리드 타임 · 변경 실패율 · 배포 실패 복구 시간 · 배포 재작업률

릴리스 과정에서 자주 나는 오류·장애

의존성 지옥 · 버전 잠금 · 스노플레이크 서버 · 코드 프리즈

헷갈리는 이웃 분야

SRE · 플랫폼 엔지니어링 · QA와 테스트(Quality Assurance, 품질보증) · 데브옵스 · 커밋에서 배포까지