Page 21 -
P. 21
사업 지표가 떨어질 때, 배포를 일주일에 1번 한다면 지난 한 주간 이루어
진 수백 가지 변경사항을 검토하면서 문제 원인을 알아내야 할 것이다. 지
속적 배포를 사용하는 회사라면 대개 지난 몇 시간 이내에 배포된 적은 양
의 코드를 확인해서 간단히 문제를 알아낼 수 있다.
변경사항이 점진적으로 배포된다고 해서 큰 기능을 만들 수 없다거나 사
용자에게 절반만 완성된 기능을 선보이는 것은 아니다. 큰 기능은 기능이
전부 완성될 때까지 비활성화해 두고 설정 플래그를 통해 특수한 상황에서
만 허용하도록 한다. 또는 같은 설정 플래그로 기능이 완성될 때까지 내부
팀원, 베타 사용자, 프로덕션 트래픽 일부에게만 선택적으로 기능을 활성
화하기도 한다. 실제로는 변경사항이 마스터 코드 저장소에 점진적으로 병
합된다는 뜻이기도 하다. 그러면 배포 주기가 길 때 커다란 새 코드 덩어리
를 간신히 통합하고 제대로 작동하게 만드는 과정에서 발생하는 강도 높은
조정과 ‘병합 지옥’을 피할 수 있다. 3
점진적인 소규모 변경에 집중하면 전통적인 배포 프로세스에서는 가능하
지 않았던 새로운 개발 기법의 문이 열린다. 제품에 관해 토론하면서 특정
기능을 계속 유지해야 할지 논쟁이 벌어졌다고 가정해보자. 사람들의 의견
이나 사내 정치에 따라 기능의 중요성이 정해지게 두거나 다음 출시 주기를
기다려 사용 데이터를 모으지 않아도, 구현하려는 인터랙션을 기록하여 배
포한 후 몇 분 내에 유입되는 초기 데이터를 확인할 수 있다. 또는 웹 페이
지 중에 성능 회귀를 보이는 페이지가 있다고 가정해보자. 회귀 버그를 찾
으려 코드를 훑어보지 않아도 몇 분 동안 변경사항을 배포하고 로깅을 활성
화하면 시간이 소비되는 위치를 실시간으로 파악할 수 있다.
빠른 개발 주기 반복의 중요성은 쿼라의 우리 팀만 강조하는 것이 아니
5
6
4
7
다. 엣시 Etsy , IMVU , 웰스프론트 Wealthfront , 깃허브 Github 를 비롯해 다른
4장 반복 속도에 투자하라 093
이펙티브엔지니어_07.indd 93 2022-06-14 오후 3:57:32