Page 20 -

예컨대 지속적 배포 시스템을 갖춘 회사에서는 누군가 버그를 찾았을 때
수정사항을 구현하고, 제품에 배포한 후 제대로 작동하는지 확인하는 절차

를 전부 앉은자리에서 한 번에 할 수 있다. 전통적인 배포 프로세스에서는
이 세 단계를 진행하는 데 며칠 또는 몇 주가 걸린다. 자신이 수정한 코드

가 다른 더 큰 변경사항들과 함께 그 주 배포에 패키징될 때까지 기다렸다

가, 다른 여러 교차 변경사항과 같이 수정 내용을 검증해야 하기 때문이다.
훨씬 더 많은 맥락 전환과 정신적 간접 비용이 든다.

또는 프로덕션 데이터베이스 테이블을 한 스키마에서 다른 스키마로 마
이그레이션해야 하는 상황을 가정해보자. 사용 중 live인 스키마를 변경하는

표준 프로세스는 다음과 같다.

1. 새 스키마 만들기
2. 기존 스키마와 새 스키마 양쪽 모두에 데이터를 작성하는 코드 배포

하기

3. 기존 스키마에서 새 스키마로 기존 데이터 복사하기

4. 새 스키마에서 데이터를 읽어 들이는 코드 배포하기

5. 기존 스키마에 데이터를 작성하는 코드 삭제하기

각 변경사항은 간단하더라도 이런 변경사항이 차례대로 4~5번 배포에
걸쳐서 일어나야 한다. 각 배포에 일주일이 걸린다면 이 과정은 상당히 수

고로울 수 있다. 지속적 배포에서는 한 개발자가 몇 시간 내에 4~5번의 배

포를 통해 마이그레이션을 진행할 수 있으므로 몇 주 동안 고민할 필요가
없다.

변경사항이 더 작은 작업 단위로 이루어지면 문제를 발견하고 디버깅하
는 것도 쉬워진다. 버그가 발견될 때, 또는 배포의 영향으로 성능 지표나

092

이펙티브엔지니어_07.indd 92 2022-06-14 오후 3:57:32