커밋부터 배포에 이르는 길고 험난한 여정

고친 내용을 프로덕션에 배포하는 일이 아주 길고 고통스럽습니다. 배포 팀은 보통 한 달에 한 번 정도, 금요일 저녁이나 토요일 밤에 프로덕션 배포를 합니다. 메리는 SaaS(Software-as-a-Service, 서비스로서의 소프트웨어) 애플리케이션의 최근 트렌드는 지속적 배포(continuous deployment)라는 사실에 주목합니다. 평일 업무 시간 중에 몇 번이고 원하는 횟수만큼 변경분을 배포하게 해준다는 기술이죠. 실제로 아마존 닷컴은 2011년, 사용자에게 아무 영향을 끼치지 않고도 11.6초마다 한 번씩 변경분을 프로덕션에 배포했습니다! FTGO 애플리케이션을 한 달에 2회 이상 프로덕션에 배포한다는 것은 상상조차 힘든 일이죠. 지속적 배포를 도입하는 것도 사실상 불가능합니다.

FTGO는 부분적으로 애자일을 도입했고 기술 팀을 여러 소그룹으로 나누어 2주짜리 스프린트를 진행합니다. 그러나 완성된 코드가 프로덕션에서 실행되기 전까지는 길고 험난한 여정을 거쳐야 하며, 여러 개발자가 같은 코드베이스에 소스 커밋을 하다 보니 종종 릴리스할 수 없을 때도 있습니다. 기능 브랜치(feature branch)로 이 문제를 해결하면 되겠다 싶었지만 결국 아주 길고 고통스러운 소스 병합(merge) 단계가 개발자를 괴롭혔죠. 그래서 한 팀이 스프린트를 마치면 곧바로 길고 긴 테스트 및 코드 안정화 기간이 필요합니다.

테스트 시간이 너무 긴 것도 변경분을 프로덕션에 반영하는 데 시간이 많이 걸리는 요인입니다. 코드베이스가 너무 복잡하여 변경 영향도가 제대로 파악이 안 되므로 개발자는 CI(Continuous Integration, 지속적 통합) 서버에서 전체 테스트 스위트를 한 번씩 돌려 보아야 합니다. 물론 사람이 손으로 직접 테스트해야 하는 영역도 있습니다. 테스트가 실패하면 원인을 찾고 조치하는 데 시간이 많이 걸리므로 테스트 한 사이클을 완료하는 데만 2~3일이나 걸립니다.