이 글은 Trunk Based Development vs feature-based development의 번역본입니다. 문맥에 따라 약간의 의역이 있을 수 있으니 더 정확한 정보는 원문을 참고해주세요.
개요
여러분이 만약 소프트웨어 프로젝트의 유일한 개발자라면 여러분의 취향에 맞게 코드를 작성하고 수정할 수 있습니다. 팀 단위의 프로젝트를 한다면 표준화된 가이드라인을 따라야하며, 팀원과의 조율도 필요합니다. 표준화된 가이드라인과 이를 준수하는 일은 성공적인 팀 단위 소프트웨어 프로젝트에 꼭 필요합니다.
이 필요를 충족시키기 위해 전 세계의 엔지니어링 팀들이 많은 개발 워크 플로우를 고민했습니다. 오늘날엔 많은 팀들이 코드와 버전 관리를 위해 깃을 사용합니다. 깃에 기반한 가장 인기 있는 개발 워크 플로우로는 트렁크 기반 개발과 기능 기반 개발이 있습니다. 페이스북, 구글, 넷플릭스 그리고 많은 테크 기반 기업들은 이 워크 플로우들을 사용하고 있습니다.
이 포스트에선 어떤 워크 플로우가 여러분의 팀에 도움이 되는 지에 초점을 맞춰 트렁크 기반과 기능 기반 개발을 알아보려고 합니다.
트렁크 기반 개발이란? (trunk-based development)
트렁크 기반 개발은 개발 팀들 사이에서 가장 인기 있는 프레임워크들 중 하나입니다. 이 워크 플로우 내에선 하나의 브랜치가 메인으로 간주됩니다. 이 브랜치엔 배포가능한 코드들만 포함합니다.
개발자는 메인 브랜치에 변경 사항을 바로 푸쉬할 수 있습니다. 하지만 만약 며칠 정도 시간이 걸리는 코딩을 한다면 메인 브랜치로부터 새로운 브랜치를 생성한 다음에 그 브랜치에 변경 사항을 적용하고 개발이 완료되었을 때 메인 브랜치에 머지할 수 있습니다.
동료 개발자들은 머지 전에 반드시 회사 가이드라인을 기반으로 한 코드 리뷰를 해야 합니다. 이렇게 새로운 브랜치를 딸 때 가장 중요한 점은 짧은 수명입니다. 보통 이틀에서 삼일 이내 정도의 수명을 가지고 있습니다.
트렁크 기반 워크 플로우에선 메인 브랜치가 언제나 프로덕션 배포를 완료한 상태여야 합니다. 결함이 있는 코드는 전체 빌드를 실패시킬 수 있으며, 개발 기록을 복잡하게 만듭니다. 다시 말하자면, 팀에서는 메인 브랜치에 푸쉬를 보내기 전에 변경 사항에 대해서 철저히 코드를 테스트 해야합니다. 짧은 개발 사이클과 테스트 자동화를 통해 팀은 빌드 실패 시 빠르게 결함을 발견하고 처리하면서 리스크를 줄여나갈 수 있습니다.
트렁크 기반 워크 플로우에는 팀에 유능한 개발자들이 필요합니다. 신입이나 이 기반에 대해 잘 모르는 구성원들은 프로젝트에 참여하기 이전에 워크 플로우에 대한 충분한 이해가 필요합니다.
기능 기반 개발이란? (feature-based development)
기능 기반 워크플로우 (또는 깃 플로우)는 소프트웨어 엔지니어링에서 고전적인 접근 방법입니다. 개별 기능을 개발하는 것이 기능 기반 워크 플로우의 핵심입니다. 트렁크 기반 워크플로우와 근본적으로 다른 점 중 하나는 이 워크 플로우 내에서는 절대로 메인 브랜치에 코드를 푸쉬하지 않습니다.
기능을 개발하기 전에 개발자는 "기능 브랜치"를 생성하고 그 브랜치에 모든 코드 변경을 만듭니다. 개발자는 기능 개발을 완료하고 나면 메인 브랜치로 PR(Pull Request)를 보냅니다. 회사 정책에 따라서 코드가 메인 브랜치에 머지되기 코드 리뷰가 있을 수 있습니다. 가장 중요한 것은 기능 기반 워크플로우 안에선 개발자들은 절대로 메인 브랜치에 코드를 바로 푸쉬하면 안됩니다.
피처 기반 워크플로우의 이점은 수백명의 개발자들이 언제나 수백개의 개별 기능을 만들 수 있는 점입니다. 기능 개발을 잘게 쪼개어 여러번 PR을 날려서 다른 사람과의 코드 충돌을 막을 수 있습니다.
기능 기반 워크 플로우는 미숙하거나 시니어가 없는 팀에서 선호합니다. 그 이유는 프로덕션 코드를 망가뜨릴 염려 없이 기능을 만들 수 있기 때문입니다. 테크 리드, QA나 다른 개발팀 멤버가 각각의 MR(merge request)에 대해서 빌드를 테스트할 수 있습니다.
기능 기반 개발을 관리하는 것은 꽤나 까다롭습니다. 특히 여러개의 PR이 메인 브랜치에 머지되기 위해 쌓여 있는 경우가 그렇습니다. 팀 리더나 시니어 소프트웨어 엔지니어는 이 PR들을 빠르게 리뷰하고 머지해야 합니다. 이러한 상황은 충돌을 일으켜 옛날 PR을 반영해서 다시 개발 해야하는 개발자에게 실망감을 안겨줄 수 있습니다. 이렇게 밀린 머지는 배포 주기를 길게 만들고 빌드 실패가 일어날 경우 빠르게 처리할 수 없게 됩니다. 따라서 제품 혁신과는 점점 멀어지게 됩니다.
CI/CD에서 트렁크 기반 워크플로우의 중요성
트렁크 기반 워크플로우의 가장 좋은 점은 CI(Continuous Integrateion)/CD(Continuous Delivery) 서비스들과 같이 사용하기 좋은 것입니다. 메인 브랜치에 커밋을 보낼 때 마다 자동화된 테스트가 변경 사항이 메인 브랜치에 영향을 주지 않는 지 확인합니다(CI의 일부). 그리고 모든 테스트를 성공적으로 마치면, 파이프라인을 통해 QA팀이 스테이징 브랜치에서 볼 수 있도록 배포할 수 있습니다.
QA의 피드백을 기반으로 릴리즈 매니저(새로운 릴리즈 생성 담당자)가 메인 브랜치를 릴리즈 브랜치에 푸쉬함으로써 배포를 진행합니다. 릴리즈 매니저는 가장 최신 릴리즈를 프로덕션 환경에 배포합니다.
이러한 종류의 워크플로우는 각 릴리즈가 고유하기 때문에 릴리즈 분기가 변경되지 않도록 합니다. 만약 프로덕션 이슈가 생길 경우 릴리즈에서 버그를 수정하기도 합니다.
새로운 릴리즈를 생성한 다음에 개바리능 메인 브랜치에 코드를 푸쉬함으로써 다음 릴리즈를 준비합니다. 시간이 지나면 오래된 릴리지는 무효하게 되고, 팀에서는 해당하는 릴리즈 브랜치를 안전하게 삭제할 수 있습니다.
대부분의 팀에서는 CI를 빌드나 테스트를 위해 사용합니다. 트렁크 기반 워크플로우는 CI/CD 시스템과 궁합이 잘 맞습니다. 이 워크플로우는 빠른 통합을 가능하게 하고 코드를 항상 배포 가능한 상태로 유지합니다.
기능 기반 개발은 반대로, 긴 개발 사이클을 가지고 있고 복잡한 통합을 해야합니다. 새로운 기능이 동작하는 지 확인하기 위해 상당한 양의 시간을 리뷰에서 사용해야 합니다.
트렁크 기반 개발을 프로젝트에서 사용하는 방법
많은 애플리케이션에 트렁크 기반 개발은 좋지만, 예외가 있습니다. 만약 새로운 프로젝트가 MVP(Minimum Value of Product)이거나 POC(proof of concept)에 있는 경우 트렁크 기반 워크 플로우를 사용해도 좋습니다.
팀에 있는 개발자들이 다른 사람의 리뷰나 PR이 머지되길 기다릴 필요없이 바로 코드를 푸쉬합니다. 여기서 필요한 사항은 팀에 있는 노련한 개발자들이 메인 브랜치에 빌드 패일이 나는 커밋을 절대로 넣으면 안된다는 점입니다. 아니면 더 나은 방법으로 자동화된 CI/CD 기능을 이용해서 배포 이전에 새로운 코드를 자동으로 체크하는 것입니다.
트렁크 기반 개발을 하기로 했다면 그것을 선택한 이유에 확신을 가져야 합니다. 하지만 어떠한 상황에선 여러분과 여러분의 팀이 기능 기반 워크플로우를 원할 수 있습니다.
예를 들어 가끔 여러분이 다양한 소프트웨어 버전을 유지해야 합니다. 이러한 상황에선 트렁크 기반의 워크플로우에선 이를 구현하기가 어렵습니다. 리눅스 커널은 이 상황에 대한 대표적인 예입니다. 리눅스 커널은 기능 기반 개발을 하며 긴 수명의 릴리즈 브랜치를 가고 있습니다. 리눅스 커널의 기능 기반 개발은 가장 좋은 솔루션 입니다. 왜냐하면 유저들이 각각 배포된 리눅스 커널을 몇 년, 심지어는 몇 십년을 사용하기 때문입니다.
트렁크 기반 개발을 프로젝트 내에서 하려면 아래 항목들이 필요합니다.
- 깃헙과 같은 버전 관리 온라인 서비스
- 메인(트렁크) 브랜치, 스테이징 브랜치, 프로덕션 브랜치를 세팅합니다. 개발진들은 그들의 코드를 메인 브랜치에 푸쉬하고 릴리즈 매니저는 메인 브랜치를 스테이징이나 프로덕션 브랜치에 머지해서 새로운 릴리즈를 생성합니다.
- CI 시스템 : 릴리즈로 반영되기 전 새로운 변경에 대해서 테스트를 합니다.
- CD 시스템 : 스테이징이나 프로덕션 환경에서 빌드하고 배포합니다.
어느 조직에서 트렁크 기반 개발을 구현하던 간에 견고한 데브옵션 시스템은 괴앙히 중요합니다. 제품을 사용하는 사용자가 늘어날수록, 더 많은 기능 요청과 오류 신고가 생겨날 것입니다. 이러한 알림들은 개발자들을 바쁘게 합니다. 따라서 릴리즈를 준비하기 이전에 새로운 변화에 대한 테스트가 필요합니다.
참고로 자동화 테스트와 배포 파이프라인을 위해 좋은 CI/CD 적용을 확인해 보세요.
정리
트렁크 기반 과 기능 기반 개발 워크플로우는 둘 다 장점과 단점을 가지고 있습니다. 팀을 위한 최고의 방법은 그 팀의 선호도와 경험 그리고 팀의 워크플로우와 전체적인 일치 수준에 따라 다릅니다. CI를 잘 적용한 팀에게는 트렁크 기반 모델이 빠른 통합과 피드백을 가능하게 하고 긴 개발 주기로 인해 시간이 오래 소요되는 머지 충돌도 제거할 수 있습니다.
여러분의 팀에서 어떤 개발 워크플로우를 선택하던 간에 소프트웨어를 만드는데에 CI/CD 시스템은 테스팅과 빌드에 도움이 됩니다.
