스크럼 환경에서의 효율적인 릴리스 전략
일반적으로 스크럼 팀에서는 스프린트 종료 후 즉시 릴리스가 이루어질 것이라고 예상합니다. 이는 성공적인 데모 발표 직후에 고객에게 결과물을 전달하는 것을 의미합니다. 하지만 저는 이러한 기대가 어떻게 당연하게 여겨지는지 항상 의문을 품어왔습니다. 특히 릴리스 전에 완료해야 할 다양한 활동들을 고려했을 때 더욱 그렇습니다.
- 스프린트 내 모든 스토리 개발 및 완료: 일부 스토리는 더 빨리 완료될 수 있지만, 대부분의 경우 스프린트 종료 직전에 완료됩니다. 데모 발표 후에도 릴리스를 위한 추가 작업이 필요할 수 있습니다.
- 스프린트 콘텐츠에 대한 철저한 테스트: 프로덕션 환경에 배포하기 전에 코드의 안정성을 확인하기 위한 테스트가 필수적입니다.
- 버그 식별 및 수정: 릴리스 전에 발견된 버그를 제때 수정해야 합니다.
- 배포 파이프라인 최신화 및 안정성 확보: 최신 콘텐츠로 업데이트하고, 파이프라인 자체의 안정적인 실행을 보장해야 합니다.
- 전체 환경에서의 파이프라인 실행: 코드 및 데이터 측면에서 모든 환경이 최신 상태인지 확인해야 합니다.
- 릴리스 노트 작성 및 고객과의 소통: 릴리스의 영향과 후속 변경 사항에 대해 고객과 정확하게 소통해야 합니다.
- 병렬 스크럼 팀과의 협업: 종속성이 있는 경우 다른 팀과 동기화하여 모든 콘텐츠가 동시에 릴리스되도록 해야 합니다.
- 스크럼 이벤트 참석: 현재 스프린트뿐만 아니라 다음 스프린트를 위한 준비(예: 스토리 개선 세션)도 중요합니다.
2주 스프린트를 가정해 봅시다. 릴리스 활동 자체도 시간과 인력을 필요로 하며, 동시에 다음 스프린트 시작이 바로 눈앞에 다가와 있습니다. 이렇게 보면 매 스프린트마다 릴리스를 기대하는 것이 당연한 것인지 다시 생각하게 됩니다.
릴리스 콘텐츠 처리의 어려움
만약 스프린트 내 모든 프로세스가 자동화되어 있다면, 각 스프린트 종료 시점에 “방아쇠를 당겨” 최신 코드를 바로 배포할 수 있을 것입니다. 하지만 현실적으로 스크럼 팀은 이러한 완벽한 상태를 경험하기 어렵습니다. 일부 소규모 기업에서는 가능할지 모르지만, 일반적으로 스크럼 팀은 릴리스 프로세스에 많은 시간과 노력을 쏟아야 합니다. 이는 다음 스프린트에도 영향을 미치며, 릴리스는 팀원 누구도 쉽게 감당하고 싶어 하지 않는 스트레스 요인이 됩니다.
이러한 문제점을 해결하기 위해 저는 릴리스 처리의 대안적인 접근법을 찾아냈습니다.
핵심 아이디어는 매 두 번째 스프린트를 릴리스 스프린트로 지정하는 것입니다. 아래에서 자세히 살펴보겠습니다.
다음 릴리스를 위한 별도의 코드 버전 관리
이 접근 방식은 Git 저장소에서 별도의 브랜치를 활용하는 것에 기반합니다. 물론 다양한 방법이 있을 수 있지만, 이 글에서는 간결하게 핵심을 설명하겠습니다.
진행 중인 개발 작업에 미치는 영향을 최소화하기 위해, 다음 릴리스 콘텐츠를 별도의 ‘릴리스 브랜치’로 분리하는 것이 중요합니다. 이렇게 하면 다음과 같은 이점을 얻을 수 있습니다.
- 개발팀은 중단 없이 작업을 계속하고 메인 브랜치에 새로운 스토리를 병합할 수 있습니다.
- 릴리스 콘텐츠가 예상치 못한 코드 변경으로 인해 영향을 받을 위험이 없습니다.
- 테스트 활동은 격리된 환경에서 수행할 수 있으며, 필요한 변경 사항만 반영할 수 있습니다.
- 릴리스 파이프라인은 릴리스 브랜치의 콘텐츠만 배포하므로, 릴리스되는 콘텐츠에 대한 완벽한 제어가 가능합니다.
결론적으로, 다음 릴리스 콘텐츠를 안전하게 분리하여 안정적인 상태로 만들 수 있습니다.
반복적인 릴리스를 위한 시간 계획
매 스프린트 종료 후 릴리스를 진행하려는 계획은 현실적으로 불가능하다는 것을 깨달았습니다. 최소한 다음과 같은 부정적인 영향을 피할 수 없었습니다.
- 다음 스프린트 개발 콘텐츠에 대한 간섭
- 릴리스 콘텐츠의 안정성 확보 어려움
- 필수 테스트 활동에 대한 부담
따라서 목표를 매 두 번째 스프린트 종료 시점에 릴리스를 실행하는 것으로 변경했습니다. 이는 다음과 같은 의미를 갖습니다.
- 릴리스는 항상 이전 두 스프린트의 스토리를 포함합니다. 현재 스프린트의 콘텐츠는 다음 릴리스에 포함됩니다.
- 테스트 활동과 버그 수정을 위한 충분한 시간이 확보됩니다.
- 릴리스 담당자는 릴리스 관련 정보(테스트 케이스, 릴리스 정보 등)를 수집할 충분한 시간을 갖습니다. 이를 통해 나머지 개발팀은 새로운 스토리를 계속 작업할 수 있습니다.
- 버그가 발견될 경우, 릴리스 담당자는 해당 개발자와 신속하게 협력하여 문제를 해결하고 현재 스프린트 작업으로 복귀할 수 있습니다. 이를 위해 팀 역량의 일정 부분을 버그 수정에 할당해야 합니다.
사용자가 최신 스프린트 콘텐츠를 바로 이용할 수 없는 것은 사실이지만, 시간이 지나면 이 문제는 사라집니다. 어쨌든 매 두 번째 스프린트마다 두 개의 스프린트 콘텐츠가 제공되기 때문입니다.
이러한 접근법은 빠른 배포와 스크럼 활동에 대한 방해를 최소화하는 절충안이라고 할 수 있습니다.
릴리스 배포 실행
테스트, 버그 수정, 파이프라인 준비가 성공적으로 완료되면, 프로덕션 파이프라인을 실행하고 릴리스를 완료하는 것은 비교적 간단한 과정입니다. 독립된 브랜치에서 배포가 이루어지기 때문에 눈에 띄지 않게 조용히 진행될 수 있습니다.
이를 위해서는 견고하고 자동화된 DevOps 파이프라인이 필수적입니다. 이 파이프라인은 개발, 샌드박스, 테스트, QA, 성능 환경 등 모든 하위 수준 환경에 배포하는 데 사용됩니다. 클릭 한 번으로 모든 환경에 솔루션을 배포할 수 있어야 합니다.
릴리스는 고통스럽거나 스트레스가 되는 일이 되어서는 안 됩니다. 대신, 아무도 눈치채지 못한다면 성공적인 릴리스라고 할 수 있습니다.
릴리스 브랜치를 개발 브랜치에 병합
릴리스 브랜치에는 테스트 기간 동안 구현된 특수한 수정 사항이 포함되어 있습니다. 다음 릴리스에서도 수정 사항이 유지되도록 하려면 이 콘텐츠를 개발 브랜치에 병합해야 합니다.
이 시점에서 최신 릴리스 브랜치는 즉시 재배포 가능한 비상 프로덕션 코드의 역할을 합니다. 프로덕션 배포 직후 긴급한 문제가 발생하면 이 브랜치를 사용하여 수정 사항을 빠르게 적용할 수 있습니다. 이 브랜치는 아직 출시되지 않은 새로운 콘텐츠가 없는 현재 프로덕션 코드의 정확한 사본입니다.
새로운 테스트 기간이 시작되면 이전 릴리스 브랜치를 삭제하고 현재 개발 브랜치에서 복사본을 생성하여 새로운 릴리스 브랜치로 대체할 수 있습니다.
정기적인 릴리스 설정
이제 릴리스에 접근하는 탄탄한 프로세스가 완성되었습니다. 중요한 것은 매 두 번째 스프린트마다 이 프로세스를 정기적으로 유지하는 것입니다.
정기적인 릴리스는 다음과 같은 이유로 더 쉽게 달성할 수 있습니다.
- 릴리스 간격이 짧으면 프로덕션에 배포할 새로운 콘텐츠가 많지 않습니다. 증분은 작고 안정적입니다.
- 새로운 콘텐츠가 적으면 테스트 활동과 테스트 케이스 생성 부담이 줄어듭니다. 커뮤니케이션, 합의 요청, 이해 관계자와의 협업도 줄어듭니다.
- 팀은 이 주기에 익숙해지고 자연스럽게 일상 업무의 일부가 됩니다.
- 개발 및 테스트 환경은 종종 데이터를 새로 고칩니다. 이는 각 테스트 주기에 필요하며, 별도의 활동이 아닌 이미 확립된 프로세스의 일부가 됩니다. 이러한 변화는 팀 분위기에 긍정적인 영향을 미칩니다.
결론
이 글에서는 스크럼 라이프사이클에 대한 이전 게시물을 마무리하며, 실생활에서 효과가 입증된 내용을 공유했습니다.
많은 팀이 애자일 방식으로 시작하지만, 처음에는 많은 시행착오를 겪습니다. 그러다 점차 변화하고 개선을 거듭합니다. 이 글이 이러한 변화를 더 빠르게 수행하는 데 도움이 되기를 바랍니다.
이러한 릴리스 접근 방식이 유일한 해결책은 아니며, 완벽하지도 않습니다. 하지만 이 접근법은 단순하면서도 유연하다는 것을 증명했습니다. 혼란스럽고 예측 불가능한 스프린트에서 벗어나 신뢰할 수 있고 계획 가능한 정기적인 릴리스를 제공할 수 있도록 도와줍니다. 복잡한 방법론이 필요한 것이 아니라, 간단한 규칙과 계획을 따르려는 의지만 있으면 충분합니다.