지속적 통합

여러 사람이 한 제품을 고치면 각자의 작업본이 조금씩 벌어집니다. 예전에는 이 벌어진 것을 마지막에 한 번 합쳤습니다. 기능마다 브랜치를 하나씩 따서 몇 주씩 따로 작업하다가, 출시 직전에 모아 머지하는 방식입니다.

합치는 날이 문제였습니다. 3주 동안 다섯 명이 같은 파일을 각자 고쳐 놨으면, 합치는 순간 어느 쪽이 맞는지 기계가 판단하지 못하고 사람에게 물어 옵니다. 물어 오는 자리가 수백 군데면 하루가 아니라 사흘이 걸리고, 그 사흘 동안 아무도 새 코드를 쓰지 못합니다. 더 나쁜 건 합치고 나서 처음 돌려 본 순간입니다. 각자 자기 브랜치에서는 잘 돌던 것이 합쳐 놓으니 안 돌고, 원인이 다섯 명의 3주치 변경 어딘가에 있습니다.

페이지덱 초기에도 출시 전 주가 매번 이랬습니다. 태오가 "합치는 데만 이틀 잡아 주세요" 라고 말하는 것이 당연했고, 그 이틀은 아무 기능도 늘지 않는 시간이었습니다. 심지어 합치다 꼬이면 며칠 전 작업을 버리고 다시 하는 일도 있었습니다.

지속적 통합은 합치는 일을 미루지 않고 잘게 나눠 버리는 쪽을 택합니다. 3주에 한 번 큰 덩어리를 합치는 대신 하루에 한 번 이상 작은 조각을 합치면, 충돌이 생겨도 어제 이후의 변경 안에서만 찾으면 됩니다. 합치는 비용은 미룬 기간의 제곱으로 늘어나고, 그래서 자주 합치는 쪽이 매번 더 쉽습니다.

합치는 행위 하나마다 자동 검사를 붙이는 것이 전부입니다. 실무에서는 네 단계로 돕니다.

1. 작업을 하루 안에 합칠 수 있는 크기로 자릅니다. 기능 하나를 통째로 끝낸 뒤 합치려 하면 다시 몇 주짜리 브랜치가 됩니다. 화면 하나, 함수 하나 단위로 자르고 완성되지 않은 부분은 아직 켜지지 않는 상태로 둡니다.
2. 공용 줄기 기준으로 최신 코드를 받아 자기 변경을 올립니다. 이때 동료가 읽어 보는 코드 리뷰를 거칩니다. 리뷰 대상이 하루치라 30분이면 끝나는데, 3주치면 리뷰어가 대충 훑고 승인합니다.
3. 파이프라인이 자동으로 빌드하고 테스트를 돌립니다. 함수나 모듈 하나를 떼어 확인하는 단위 테스트가 이 자리의 주력이고, 실행 시간이 길어지면 사람이 기다리지 않게 되므로 10분 안팎으로 유지합니다.
4. 실패하면 그 사람이 그 자리에서 고칩니다. 공용 줄기가 깨진 채로 있으면 그 뒤에 합치는 사람 전부가 남의 실패를 물려받으므로, 고치는 일이 새 작업보다 앞섭니다. 20분 안에 못 고치면 방금 올린 변경을 되돌리고 다시 준비합니다.

합치는 간격을 짧게 유지하려고 브랜치를 오래 두지 않는 방식을 함께 쓰는 팀이 많습니다. 트렁크 기반 개발이 그 방식이고, 이름이 다를 뿐 1번 단계를 규칙으로 못 박은 것입니다.

여러 명이 같은 코드를 고치는 상황이면 규모와 무관하게 값을 합니다. 혼자 만드는 제품에서는 합칠 상대가 없어 효과가 작지만, 그때도 자동 테스트가 도는 것 자체는 남습니다. 뒤의 단계인 지속적 전달이나 지속적 배포로 가려는 팀이라면 이 단계가 서 있지 않은 채로는 올라설 수 없습니다. 검사 없이 자동으로 내보내는 것은 자동화가 아니라 방치입니다.

지키지 못하면 도입해도 효과가 없는 조건이 셋 있습니다.

1. 테스트가 믿을 만해야 합니다. 같은 코드에서 성공과 실패를 오가는 플레이키 테스트가 섞이면 팀이 빨간불을 보고도 다시 돌려 보기 시작하고, 그때부터 검사 결과는 아무것도 뜻하지 않습니다.
2. 검사가 빨라야 합니다. 한 번 도는 데 40분이 걸리면 사람들은 결과를 기다리지 않고 다음 일로 넘어가고, 실패를 발견하는 시점이 다시 다음 날로 밀립니다.
3. 빨간불에 멈추는 합의가 있어야 합니다. 깨진 채로 계속 합치기로 하면 며칠 만에 무엇이 원래 깨져 있던 것인지 아무도 모르게 됩니다.

도입한다고 저절로 좋아지지 않는 것도 분명히 해 둡니다. 이 방식은 깨진 곳을 빨리 알려 줄 뿐 코드 품질을 올려 주지 않습니다. 테스트가 확인하지 않는 영역은 초록불이 떠도 그대로 남아 있습니다.

"지금 빌드 깨져 있어요. 고칠 때까지 머지 잠깐만 멈춰 주세요."

공용 줄기가 깨진 상태라 그 위에 쌓으면 원인이 섞인다는 뜻입니다.

"이건 CI 통과하면 바로 합치겠습니다."

사람 승인은 끝났고 자동 검사 결과만 기다린다는 말입니다.

"브랜치를 2주째 들고 계신데 중간에 한 번 합치시죠."

합치는 비용이 커지기 전에 나눠 내자는 제안입니다.

페이지덱은 이 방식을 켜면서 규칙을 하나만 정했습니다. 오후 여섯 시에 공용 줄기가 초록불이어야 한다는 것입니다. 처음 한 달은 하루에도 몇 번씩 빨간불이 떴고, 그때마다 태오가 누가 올린 것인지 찾아다녔습니다. 그러자 사람들이 올리기 전에 자기 컴퓨터에서 테스트를 먼저 돌리기 시작했고, 두 달 뒤에는 빨간불이 주에 두어 번으로 줄었습니다.

더 크게 달라진 건 회의였습니다. 예전에는 출시 2주 전에 "합치는 데 얼마나 걸릴까요" 를 논의했는데, 지금은 그 질문 자체가 없습니다. 이미 합쳐져 있기 때문입니다. 지현이 일정을 잡을 때 통합에 며칠을 얹어 두지 않아도 되면서 출시 예정일의 오차도 함께 줄었습니다.

도구를 켜면 끝난다고 생각하는 경우가 가장 많습니다. 설정 파일 하나를 올리면 검사가 자동으로 도는 것이 맞으니 그렇게 보입니다. 하지만 이 방식의 내용은 도구가 아니라 하루에 한 번 이상 합친다는 습관입니다. 3주짜리 브랜치를 그대로 두고 검사만 자동으로 돌리면, 합치는 날의 충돌은 예전 그대로이고 달라지는 건 그 브랜치 안에서 테스트가 돈다는 것뿐입니다.

CI 라는 약자를 검사 도구 이름으로 읽는 오해도 흔합니다. "CI 돌려 주세요" 처럼 쓰이니 자연스럽습니다. 그래서 "우리는 CI 를 쓴다" 는 말이 "우리는 자주 합친다" 가 아니라 "우리는 빌드 서버가 있다" 는 뜻으로 오가고, 정작 브랜치가 몇 주씩 살아 있는 상태는 문제로 인식되지 않은 채 남습니다.