Close

트렁크 기반 개발

이 버전 관리 방식이 DevOps 팀 간에 흔히 사용되는 이유를 알아보세요.

Kev Zettler 얼굴 사진
Kev Zettler

풀스택 웹 개발자


트렁크 기반 개발은 개발자가 잦은 소규모 업데이트를 핵심 “트렁크”나 메인 브랜치에 병합하는 버전 제어 관리 방식입니다. 병합 및 통합 단계가 간소화되므로 CI/CD를 달성하고 소프트웨어 제공 및 조직 성과를 높일 수 있습니다.

소프트웨어 개발 초기에 프로그래머에게 최신 버전 관리 시스템은 그저 사치였습니다. 그보다는 변경 사항을 추적하고 필요한 경우 되돌릴 수 있도록 두 버전의 소프트웨어를 동시에 개발했습니다. 시간이 지나면서 이 과정은 노동 집약적이고 비용이 많이 들고 비효율적인 것으로 드러났습니다.

버전 관리 시스템이 발전하면서 다양한 개발 스타일이 등장하여 프로그래머가 더 쉽게 버그를 찾고 동료와 병렬로 코딩하고 릴리스 케이던스를 앞당기도록 지원했습니다. 오늘날 대부분의 프로그래머는 Gitflow와 트렁크 기반 개발이라는 두 가지 개발 모델 중 하나를 활용하여 고품질 소프트웨어를 제공합니다.

처음 대중화된 Gitflow는 특정한 개인만 메인 코드 변경을 승인할 수 있는 더 엄격한 개발 모델입니다. 코드 품질이 유지되고 버그 수가 최소화됩니다. 트렁크 기반 개발은 모든 개발자가 메인 코드에 액세스할 수 있기 때문에 더 개방적인 모델입니다. 이렇게 하면 팀이 빠르게 반복하고 CI/CD를 구현할 수 있습니다.

트렁크 기반 개발이란 무엇입니까?


트렁크 기반 개발은 개발자가 잦은 소규모 업데이트를 핵심 “트렁크”나 메인 브랜치에 병합하는 버전 제어 관리 방식입니다. 병합 및 통합 단계를 간소화하기 때문에 DevOps 팀의 일반적인 관행이며 DevOps 수명 주기의 일부입니다. 실제로 트렁크 기반 개발은 CI/CD의 필수 관행입니다. 개발자는 다른 수명이 긴 기능 브랜치 전략보다 몇 개의 소규모 커밋이 있는 수명이 짧은 브랜치를 만들 수 있습니다. 코드베이스가 복잡해지고 팀 규모가 커질수록 트렁크 기반 개발은 프로덕션 릴리스의 흐름을 유지할 수 있습니다.

Gitflow 및 트렁크 기반 개발 비교


Gitflow는 수명이 긴 기능 브랜치와 여러 기본 브랜치를 사용하는 대체 Git 브랜칭 모델입니다. Gitflow는 트렁크 기반 개발보다 브랜치 수명이 길고 커밋도 더 많습니다. 이 모델에서 개발자는 기능 브랜치를 만들고 기능이 완료될 때까지 메인 트렁크 브랜치에 병합하는 작업을 지연합니다. 이렇게 수명이 긴 기능 브랜치는 병합할 때 더 많은 공동 작업이 필요하며 트렁크 브랜치에서 벗어나고 업데이트 충돌 문제가 발생할 위험이 더 높습니다.

솔루션 보기

Open DevOps로 소프트웨어를 구축 및 운영

관련 자료

지속적 통합을 달성하는 방법

또한 Gitflow는 개발, 핫픽스, 기능, 릴리스에 대한 기본 브랜치 라인을 따로 두고 있습니다. 이들 브랜치 간에 커밋을 병합하는 전략은 여러 가지가 있습니다. 저글링하고 관리해야 할 부분이 많기 때문에 추가 계획 세션과 팀의 검토가 필요한 경우가 많습니다.

트렁크 기반 개발은 수정 및 릴리스의 소스인 메인 브랜치에 초점을 맞추기 때문에 훨씬 더 단순합니다. 트렁크 기반 개발에서는 메인 브랜치가 항상 안정적이고 문제 없이 바로 배포할 수 있는 것으로 가정합니다.

트렁크 기반 개발의 이점


트렁크 기반 개발은 지속적 통합을 위한 필수 관행이 되었습니다. 빌드 및 테스트 프로세스가 자동화되어 있지만 개발자가 공유 브랜치에 자주 통합되지 않는 격리되고 오래된 기능 브랜치에서 작업하는 경우 지속적 통합은 잠재력을 완전히 활용하지 못합니다.

트렁크 기반 개발은 코드 통합의 마찰을 완화합니다. 개발자가 새 작업을 마치면 새 코드를 메인 브랜치에 병합해야 합니다. 하지만 성공적으로 빌드할 수 있다는 것을 확인하기 전까지는 트럭에 변경 사항을 병합하지 말아야 합니다. 이 단계에서 새 작업이 시작된 이후에 수정이 이루어지면 충돌이 발생할 수 있습니다. 특히 개발 팀이 성장하고 코드베이스가 확장되면서 충돌은 점점 더 복잡해집니다. 개발자가 소스 브랜치에서 벗어난 별도의 브랜치를 만들고 다른 개발자가 겹치는 코드를 동시에 병합할 때 발생합니다. 다행히 트렁크 기반 개발 모델로 이 충돌을 줄일 수 있습니다.

지속적인 코드 통합이 가능

트렁크 기반 개발 모델에는 커밋이 꾸준히 메인 브랜치로 흐르는 리포지토리가 있습니다. 이 커밋 스트림에 자동 테스트 스위트와 코드 검사 모니터링을 추가하면 지속적 통합이 가능합니다. 새 코드가 트렁크에 병합되면 자동 통합과 코드 검사 테스트가 실행되어 코드 품질을 검증합니다.

지속적인 코드 검토를 보장

트렁크 기반 개발의 빠르고 작은 커밋으로 코드 검토 프로세스의 효율성을 높여줍니다. 브랜치가 작으면 개발자가 작은 변경 사항을 빠르게 확인하고 검토할 수 있습니다. 검토자가 코드 페이지를 읽거나 코드 변경의 넓은 영역을 수동으로 검사하는 수명이 긴 기능 브랜치보다 훨씬 더 쉽습니다.

연속 프로덕션 코드 릴리스 사용

팀은 매일 메인 브랜치에 자주 병합해야 합니다. 트렁크 기반 개발은 트렁크 브랜치를 어떤 커밋에서든 배포할 준비가 되었다는 뜻인 “초록색”으로 유지하기 위해 노력합니다. 자동 테스트, 코드 검사, 코드 검토 덕분에 트렁크 기반 개발 프로젝트에는 언제든지 프로덕션에 배포할 수 있다는 보장이 있습니다. 이것은 프로덕션에 자주 배포하고 일일 프로덕션 릴리스의 추가 목표를 설정할 수 있는 애질리티를 팀에 제공합니다.

트렁크 기반 개발 및 CI/CD

CI/CD의 인기가 높아지면서 브랜칭 모델이 개선되고 최적화되어 트렁크 기반 개발이 떠올랐습니다. 이제 트렁크 기반 개발은 지속적 통합의 요구 사항이 되었습니다. 지속적 통합으로 개발자는 트렁크 기반 개발을 각 커밋 후 실행되는 자동 테스트와 함께 수행합니다. 그러면 프로젝트가 항상 작동하도록 보장됩니다.

트렁크 기반 개발 모범 사례


트렁크 기반 개발을 통해 팀이 코드를 빠르고 일관되게 릴리스할 수 있습니다. 팀의 주기를 다듬고 최적화된 릴리스 일정을 수립할 수 있는 연습 및 관행의 목록은 다음과 같습니다.

소규모 배치로 개발

트렁크 기반 개발은 빠른 리듬에 따라 코드를 프로덕션에 전달합니다. 트렁크 기반 개발이 음악이었다면 짧고 간결한 음표가 연속으로 이어지는 빠른 스타카토이고 리포지토리 커밋이 음표일 것입니다. 커밋과 브랜치를 작게 유지하면 병합 및 배포의 속도를 더 높일 수 있습니다.

커밋 몇 개를 약간만 변경하거나 코드 몇 줄을 수정하면 인지 오버헤드가 최소화됩니다. 제한된 코드 영역을 검토할 때 거대한 변경 사항보다 팀이 의미 있는 대화를 나누고 빠른 결정을 내리는 것이 훨씬 쉽습니다.

기능 플래그

기능 플래그는 개발자가 비활성 코드 경로에 새 변경 사항을 래핑하고 나중에 활성화할 수 있도록 하여 트렁크 기반 개발을 훌륭하게 보완합니다. 이렇게 하면 개발자가 별도의 리포지토리 기능 브랜치를 만드는 과정을 생략하고 그 대신 기능 플래그 경로 내 메인 브랜치에 새 기능 코드를 직접 커밋할 수 있습니다.

기능 플래그는 소규모 배치 업데이트를 직접적으로 유도합니다. 기능 브랜치를 만들고 전체 사양을 구축하기 위해 기다리는 대신, 개발자는 기능 플래그를 도입하고 플래그 내에 기능 사양을 구축하는 새 트렁크 커밋을 푸시하는 트렁크 커밋을 만들 수 있습니다.

종합적인 자동 테스트 구현

CI/CD를 달성하려는 최신 소프트웨어 프로젝트라면 자동 테스트가 필요합니다. 릴리스 파이프라인의 여러 단계에서 실행되는 자동 테스트에는 여러 유형이 있습니다. 단기적인 실행 단위 및 통합 테스트는 개발 중이고 코드 병합 시 실행됩니다. 더 오래 실행되는 풀스택 엔드 투 엔드 테스트는 전체 스테이징이나 프로덕션 환경에 대해 이후 파이프라인 단계에서 실행됩니다.

자동 테스트는 개발자가 새 커밋을 병합할 때 소규모 배치 리듬을 유지하여 트렁크 기반 개발을 지원합니다. 자동 테스트 스위트는 코드에 문제가 있는지 검토한 후 자동으로 승인 또는 거부합니다. 이렇게 하면 개발자가 빠르게 커밋을 만들고 자동화된 테스트를 통해 실행하여 새로운 문제가 생기는지 확인할 수 있습니다.

비동기식 코드 검토 수행

트렁크 기반 개발에서는 코드 검토를 즉시 수행해야 하며 나중에 검토하기 위해 비동기식 시스템에 넣으면 안 됩니다. 자동 테스트는 선제적 코드 검토 계층을 제공합니다. 개발자가 팀원의 풀리퀘스트를 검토할 준비가 되면 먼저 자동 테스트가 통과되었고 코드 검사가 증가했는지 확인할 수 있습니다. 이렇게 하면 새 코드가 특정 사양을 충족한다는 확신을 검토자에게 줄 수 있습니다. 그러면 검토자는 최적화에 집중할 수 있습니다.

애플리케이션의 코드 리포지토리에 3개 이하의 활성 브랜치

브랜치가 병합되면 삭제하는 것이 모범 사례입니다. 아쉽게도 활성 브랜치가 많은 리포지토리에는 일부 부작용이 있습니다. 팀이 활성 브랜치를 살펴보고 어떤 작업이 진행 중인지 확인하는 것은 유용할 수 있지만 오래된 비활성 브랜치가 남아 있으면 이 이점을 누리기는 어렵습니다. 일부 개발자는 원격 브랜치를 많이 로드할 때 다루기가 어려워질 수도 있는 Git 사용자 인터페이스를 사용합니다.

적어도 하루에 한 번은 브랜치를 트렁크에 병합

성과가 높은 트렁크 기반 개발 팀은 오픈 브랜치와 병합할 준비가 된 브랜치를 적어도 매일 닫고 합병해야 합니다. 이렇게 하면 리듬을 유지할 수 있고 릴리스 추적의 케이던스를 설정합니다. 그러면 팀은 하루가 끝날 때 메인 트렁크를 릴리스 커밋으로 태그할 수 있는데 매일 애자일 릴리스 증분을 생성한다는 유익한 부수 효과가 있습니다.

코드 정지 횟수 및 통합 단계 감소

애자일 CI/CD 팀은 통합 단계에서 계획된 코드 정지나 일시 중지가 필요하지 않지만 조직에서는 다른 이유로 필요할 수도 있습니다. CI/CD의 “지속적”이란 업데이트가 계속 진행되고 있다는 뜻입니다. 트렁크 기반 개발 팀은 코드 정지를 피하고 릴리스 파이프라인이 멈추지 않도록 적절히 계획을 세워야 합니다.

빠르게 빌드하고 즉시 실행

빠른 릴리스 간격을 유지하려면 빌드 및 테스트 실행 시간을 최적화해야 합니다. 비용이 많이 드는 정적 계산을 피하려면 CI/CD 빌드 도구는 알맞은 경우 캐싱 레이어를 사용해야 합니다. 타사 서비스에 적합한 스텁을 사용하도록 테스트를 최적화해야 합니다.

결론...


트렁크 기반 개발은 단순화된 Git 브랜칭 전략을 사용하여 소프트웨어 출시 주기를 설정하고 유지하기 때문에 현재 고성능 엔지니어링 팀의 표준입니다. 게다가 트렁크 기반 개발을 통해 엔지니어링 팀은 최종 사용자에게 소프트웨어를 제공하는 방법을 더 유연하게 제어할 수 있습니다.

Atlassian의 Bitbucket에는 트렁크 기반 개발을 지원하는 CI/CD 기능이 내장되어 있습니다. 지금 사용해 보세요.

Kev Zettler
Kev Zettler

Kev는 선임 풀스택 웹 개발자이자 계속하여 신규 기업을 만들고 있는 사업가로 애자일 방법론을 활용한 제품 및 팀 구축 부문에서 십여 년의 경력을 보유하고 있습니다. DevOps, 암호화폐 및 VR/AR 부문 등 새롭게 부상하는 오픈소스 기술에 대한 열정적인 기여자, 저자이자 교육자이기도 합니다. 여가 시간에는 인디 게임 개발 모임에 참여합니다.


이 문서 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

블로그 읽기

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up