소프트웨어를 자주 릴리스할 때의 이점과 그 이유를 설명하며, 조직이나 오픈 소스 프로젝트에서 더 빈번한 릴리스를 설득할 때 쓸 수 있는 논리를 제시한다.
일찍, 자주 릴리스하라
이 글은 소프트웨어 프로젝트에서 잦은 릴리스의 장점을 요약한다. 회사나 기여 중인 오픈 소스 프로젝트 등에서 더 자주 릴리스하자고 다른 사람을 설득하려 한다면 도움이 될 것이다.
자주 릴리스하면 소프트웨어 최종 사용자가 더 부드럽게 마이그레이션할 수 있다.
예를 들어, 현재 소프트웨어 버전이 "1.0"이고 앞으로 도입하려는 호환성 깨지는 변경(A와 B)이 두 가지 있다고 하자. 다음의 두 가지 릴리스 전략을 비교해 보자.
* 버전 1.0
* 최초 릴리스
* 버전 2.0
* 호환성 깨지는 변경: A
* 버전 3.0
* 호환성 깨지는 변경: B
* 버전 1.0
* 최초 릴리스
* 버전 2.0
* 호환성 깨지는 변경: A
* 호환성 깨지는 변경: B
첫 번째 전략은 최종 사용자 입장에서 더 낫다. 두 번의 더 작은 단계로 업그레이드할 선택지가 있기 때문이다. 즉, 1.0에서 2.0으로 먼저 올리고, 이후에 2.0에서 3.0으로 업그레이드할 수 있다.
두 전략 모두에서 사용자는 처음부터 전체 업그레이드 비용을 감당할 의향이 있다면 곧바로 최신 릴리스로 건너뛸 수도 있다. 그러나 더 자주 릴리스하면 업그레이드 비용을 더 작은 할부로 나눠 갚을 수 있는 선택지를 제공한다. 비유하자면, 같은 높이라도 절벽을 타는 것보다 계단을 올라가는 편이 훨씬 쉽다.
특히 한 번의 릴리스에 너무 많은 호환성 깨지는 변경을 묶어 버리면 다수의 사용자가 업그레이드를 거부하는 최악의 상황을 피해야 한다. 교과서적인 사례가 Python 2에서 3으로의 전환이다. 여러 번의 릴리스에 걸쳐 나눴어야 할 변경을 한 번에 묶으면서 커뮤니티의 큰 부분이 업그레이드를 거부했다.
자주 릴리스한다면 특정 기능을 기다리느라 릴리스를 지연할 필요가 없다. 준비가 덜 됐다면 다음 릴리스로 미루면 된다. 어차피 자주 릴리스한다면 다음 릴리스가 코앞이기 때문이다.
반대로 릴리스를 드물게 한다면 다음과 같은 악순환에 자주 빠진다:
아마 테스트가 부족하거나 코드 리뷰에서 해소되지 않은 우려가 남아 있을 수 있다
기능 X를 기다렸다가 머지해야 할까? X는 일주일만 더 투자하면 준비될 수 있지만 다음 릴리스는 한참 뒤(3개월?)일 수 있다.
중요 기능 X를 기다리느라 릴리스를 미루기로 한다
그러자 또 다른 중요한 기능 Y도 릴리스 전에 끼워 넣어 달라고 한다
… 릴리스가 더 늦어진다
지금 아니면 다음 릴리스까지 오래 기다려야 한다는 두려움 때문에(그럴 만한 이유가 있어) 새 기능들이 계속 끼어든다
결국엔 릴리스를 내긴 하지만, 이런 과정이 반복될수록 릴리스 주기는 점점 길어지고 문제가 악화된다. 릴리스를 드물게 할수록 마감 전에 막판 변경을 끼워 넣으려는 유인이 커지고 그만큼 릴리스는 더 늦어진다. 더 나쁜 건, 릴리스마다 기다리는 시간이 길어질수록 품질을 희생해서라도 일단 내보내라는 압박이 커진다는 점이다.
엄격하고 빈번한 릴리스 일정을 지키면 미완성 기능을 항상 안전하게 다음 릴리스로 미룰 수 있어 이런 악순환을 막을 수 있다.
드문 "빅뱅"식 릴리스는 마감 전에 개발자들에게 과도한 노동 시간으로 몰아붙이는 압박을 만든다. 이는 오픈 소스 프로젝트처럼 개발자가 보수를 받지 않는 경우에도 발생할 수 있다. 다른 사람들의 릴리스를 발목 잡고 있다는 동료 압력이, 평소라면 하지 않았을 비건강한 일정으로 일하게 만들 수 있다.
자주 릴리스한다고 해서 유급 개발자가 야근과 주말 근무를 완전히 피할 수 있다고 주장하려는 건 아니다. 다만 최소한 경영진이 임박한 릴리스 마감을 핑계로 초과근무를 정당화하기는 어려워진다.
릴리스는 방향을 수정할 기회다. 어떤 기능을 사용자 손에 쥐어주기 전까지 사용자 반응을 알 수 없기 때문이다. 기능을 구현했는데 다음 릴리스가 3개월 후라면, 그 3개월 동안은 그 기능이 정말로 사용자가 원하던 것인지 알 수 없다.
더 나쁜 경우도 있다. 첫 구현이 사용자가 원하는 것을 못 했다면, 다음 개선 버전을 사용자 손에 쥐여주기까지 다시 3개월을 기다려야 한다. 이렇게 느린 피드백 루프는 졸렬한 제품 설계로 이어지는 지름길이다.
빠른 릴리스 사이클은 평소 수동으로 하던 릴리스 관련 프로세스(예: 지속적 통합)를 자동화하고 가속하도록 강제한다. 예를 들면 다음과 같다:
이러한 자동화는 장기적으로 기능 개발에 더 많은 시간을 쓰고, 최종 사용자에게 전달하는 데는 더 적은 시간을 쓰게 해 준다는 뜻이다.
더 자주 릴리스하는 일이 공짜는 아니다. 앞서 말했듯 빈번한 릴리스를 가능하게 하려면 자동화에 투자해야 한다.
하지만 이 글을 읽는 사람들이 드문 릴리스의 징후가 스멀스멀 나타날 때 그것을 알아차리고 선제적으로 대응하여, 릴리스 빈도를 높이는 데 투자하자고 주변을 설득할 수 있기를 바란다.