매스프레소 팀블로그 - Medium

피쳐플래그, 다크런칭, 테스트코드, QA, 출시까지
안녕하세요, 콴다 프론트엔드 챕터의 Hanul 입니다.
저희 콴다 프론트엔드 챕터에서는 22년 6월부터 모노레포와 Trunk Based Development (이하 TBD) 전략을 도입하여 약 1년간 운영해 왔습니다. 이번 글에서는 저희가 1년간 해당 전략을 어떻게 사용했는지, 그리고 전략을 사용하면서 발생했던 이슈들과 해결 방법에 대해 공유해 드리려 합니다.
요약
프론트엔드 프로젝트들을 모노레포로 이전하며 TBD 전략을 도입했습니다.
TBD 전략을 이용하기 위해 피쳐플래그를 활용한 다크 런칭 기법을 도입하여, 하나의 코드베이스가 여러 버전으로 동작하고 테스트될 수 있게 처리했습니다.
개발자들의 작업이 서로의 리팩토링이나 배포에 병목이 되는 일이 거의 없어졌습니다.
TBD에 대해
TBD는 어떤 전략인가요?
TBD가 익숙하지 않으신 분들을 위해 간단하게 짚고 넘어가면, 이 전략은 모든 개발자가 Trunk라고 부르는 하나의 브랜치에서 개발하는 전략입니다.
가령 유명한 git-flow에서는 master , develop , feature , release , hotfix 이렇게 5개 이상의 브랜치를 관리하며, 많은 회사에서 적어도 master/ develop/ feature 세 개의 브랜치를 운영하는 반면, TBD는 단 하나의 브랜치만 이용하며, 개발자들도 이 브랜치 하나만 바라보며 개발합니다.
TBD의 핵심은 Trunk 브랜치가 항상 배포 가능한 상태라는 것입니다. 아마도 많은 개발자분이 코드 내부적인 병목에 의해 배포나 개발을 진행하지 못하는 경험을 해 보셨을 텐데요, 가령 개발자들 사이에서 이런 대화들이 오가곤 합니다.
“🙋 우리 문구 잘못된 거 있다고 이슈가 들어와서 빠르게 고치고 배포 나가야 할 것 같은데, develop 브랜치 master에 머지해서 프로덕션 배포해도 될까요?”
“🙅‍♂️아.. 지금 develop에 머지해둔거에서 갑자기 이슈 발견돼서 해결하고 있어요. 조금 걸릴 것 같은데 일단 체리픽으로 처리해 주실 수 있나요?
“🙍(으 체리픽 하기 싫은데..) 네 알겠습니다. 해결되면 노티 부탁드려요
또는 이런 대화도 있습니다.
“🙋 저희 lint 규칙 중에 simple-import-sort 를 쓰면 어떨까요? 지금 임포트문들이 너무 지저분해서 이거 쓰면 개선될 것 같아요”
“🙆‍♀️ 좋아요! 그런데 그거 반영하면 엄청 큰 체인지가 생기는 거죠? 지금 마이페이지 개편 작업 중인 feature/mypage-base 브랜치에 5000줄짜리 변경사항이 있어서, 컨플릭 안 나려면 이거 머지하고 배포나가고 나서 적용하는 게 좋을 것 같아요!
“🙍(힝..) 네 알겠습니다. 그때 진행해요
아마 이 글을 읽으시는 분들도 한번쯤 이와 비슷한 걸 겪어보셨을 것 같습니다. TBD는 이런 문제들을 해결해줍니다. 메인 브랜치가 항상 배포 가능한 상태로 유지되므로 배포 병목이 생기지 않고, 브랜치를 하나만 사용하기에 어떤 대규모 리팩토링이든 다른 작업과 병목 없이 처리할 수 있습니다. 장점이 너무 마법같이 느껴지는데요, 당연히 이런 이점을 챙기기 위해 지어야 하는 책임들도 있습니다. 이 부분은 조금 이따 설명해 드릴게요 :)
TBD에 대한 더 자세한 설명은 TBD의 교과서와도 같은 trunkbaseddevelopment.com 문서나, 구글 클라우드의 DevOps 테크: 트렁크 기반 개발 문서를 참고해 보시는 걸 추천드립니다.
왜 TBD를 이용하기로 결정했나요?
저희의 이전 아티클 팀워크 향상을 위한 모노레포 시스템 구축 에도 작성되어 있듯이, 여러 사람이 함께 관리해야 하는 거대 레포지토리인 만큼 서로의 개발 사항이 각 파트의 배포에 병목이 되는 일이 없어야 했습니다. 따라서 하나의 브랜치가 항상 배포 가능한 상태로 유지되는 TBD 전략을 배포 전략으로 선택했습니다.
TBD 도입하기
브랜치 이름
Trunk 브랜치는 Trunk 의 역할을 하는 것이지, 브랜치의 이름이 Trunk 여야 하는 것은 물론 아닙니다. 저희는 GitHub 가 디폴트로 권장하는 main 을 브랜치 이름으로 정했습니다. 이하로는 이 Trunk 역할을 하는 브랜치를 main 이라고 하겠습니다.
정말 main에 직접 푸시하나요?
TBD의 기본 철학은 모든 개발자가 하나의 브랜치에 직접 푸시하는 것입니다. 하지만 저희는 feature 브랜치까지는 이용하기로 했는데요, 브랜치에 직접 푸시하게 되면 해당 커밋에 대한 코드 리뷰를 하기가 어려워지기 때문입니다. 대신 브랜치를 main에서 최대 한 번만 분기하고 PR한 다음 squash merge하는 것으로 약속했습니다. squash merge를 하면 모든 변경사항이 하나의 커밋으로 합쳐져서 main에 들어가므로 main에 커밋을 직접 푸시한 것과 완전히 동일한 효과를 낼 수 있습니다.
피쳐플래그
브랜치가 하나인데 항상 배포 가능한 상태라는 건 이해하기 힘든 상황입니다. 이번 출시에 나가야 하는 2만줄짜리 변경사항이 있는데, 그럼 그 2만 줄을 하나의 커밋으로 해내야 하나? QA는 또 어떻게 하지? 등등의 고민거리가 생깁니다. 이를 해결해주는 게 바로 피쳐플래그를 통한 다크 런칭 기법입니다.
피쳐플래그는 사실 TBD에서만 이용되는 기법은 아닙니다. 브랜칭 전략과 무관하게, 점진적 배포나 AB 테스트 등을 위해서도 사용되는 방식입니다. 이 방식을 이용하면 새로 개발한 코드가 프로덕션에 올라가지만, 피쳐플래그로 인해 막혀 있어 사용자에게 영향을 주지는 않습니다.
코드로 보는 게 가장 이해하기 편하겠죠? 아래와 같은 기능을 구현한다고 가정해 보겠습니다.
기존: 버튼을 클릭하면 유저 정보가 팝업으로 보인다
변경: 버튼을 클릭하면 유저 상세 페이지로 이동한다
유저 상세 페이지는 분명 꽤 많은 개발이 들어가야 하는 기능이므로 소규모 작업들로 나눠야 하고, 하나의 커밋으로 개발할 수 없습니다. 따라서 피쳐플래그를 통한 다크런칭 기법을 적용해야 합니다. 버튼을 클릭했을 때 플래그에 따라 기존 동작 또는 변경된 동작을 하도록 구현할 수 있습니다.
const handleClick = () => {
  if (IS_USER_DETAIL_IN_PAGE_FEATURE) {
    navigate(`/users/${userId}`); // 다크 런칭 처리되어 유저에게 영향을 주지 않는 로직
  } else {
    setUserDetailPopupUserID(userId); // 유저가 실제로 타는 로직
  }
}
return (
  <button onClick={handleClick}>
    상세 내용 조회
  </button>
);
피쳐플래그는 url 파라미터 / 쿠키 / 헤더 / 로컬스토리지 / 환경변수 등 다양한 방식으로 처리될 수 있습니다.
가령 next.js 웹뷰로 되어 있는 프로젝트라면, 네이티브 클라이언트에서 feature=user-detail-in-page 와 같은 쿼리파라미터를 붙여서 웹뷰를 띄워주는 방식으로 처리하는 게 좋을 수 있습니다. create-react-app 으로 만들어진 SPA 형태의 내부 어드민이라면, localStorage에 flags 라는 키값으로 ["user-detail-in-page"] 와 같은 값을 세팅하는 것이 더 편할 수도 있습니다. 아니면, 아예 피쳐플래그 여부를 서버에서 받아오는 게 좋을 수도 있습니다.
“사용자가 localStorage 값을 변경해서 접속하면 배포 전의 ui를 확인할 수도 있는 것 아닌가요?” 라는 궁금증이 생길 수 있습니다. 그런 경우를 대비해서, 저희는 운영환경이면 항상 플래그가 꺼지도록 추가적인 로직을 처리해 줬습니다. 가령 아래와 같은 형태입니다.
export const isUserDetailInPageFeature = () => {
  if (process.env.APP_ENV === 'prod') return false; // 운영환경이면 항상 플래그를 끈다
  const flags = JSON.parse(localStorage.getItem('flags'));
  return flags.includes('user-detail-in-page');
}
이해를 돕기 위해 코드를 간소화했지만, 저희 실제 코드에는 피쳐플래그를 관리하는 모듈과 피쳐플래그를 주입받는 모듈이 분리되어 있습니다. 콴다 프론트엔드 챕터에서는 클린 아키텍처를 활용하고 있기 때문에 피쳐플래그가 어떤 형태로 들어오고 변경되든 비슷한 코드베이스에서 최소한의 코드량으로 구현해낼 수 있습니다. 이에 대한 자세한 이야기는 다음 글에서 다뤄볼게요 :)
다크 런칭에 대한 더 자세한 이야기는 구글 클라우드의 DevOps 프로세스: 소규모 배치 작업 문서를 읽어보시는 것도 추천드립니다.
테스트코드
이렇게 피쳐플래그를 적용할 때 처음에는 “어플리케이션이 이렇게 동작해야 한다"에 대한 config 와 유사하다고 생각하여 환경변수를 피쳐플래그로 이용했었었는데, 지금은 환경변수를 피쳐플래그로 이용하지 않고 있습니다. 이번에는 그 이야기를 드려보려 합니다.
콴다 프론트엔드 챕터에서는 cypress 와 cucumber를 이용한 사용자 행동 기반 통합 테스트와 jest 를 이용한 단위 테스트를 진행하고 있습니다. 통합 테스트를 할 때에는, 아래의 자동화 테스트가 필요했습니다.
플래그가 켜진 어플리케이션은 버튼을 눌렀을 때 A 기능이 동작한다, 플래그가 꺼진 어플리케이션은 버튼을 눌렀을 때 B 기능이 동작한다
즉 플래그가 켜진 버전과 플래그가 꺼진 버전을 모두 테스트해야 합니다. 이때 환경변수를 플래그로 이용했다면, 환경변수의 값을 변경하며 테스트를 해야 하는 것입니다. 환경변수의 값은 번들파일에 하드코딩되기에 이 값을 변경하려면 빌드를 다시 돌려줘야 하고, 이렇게 처리하면 CI시간도 3분 정도가 더 소요될뿐더러 피쳐플래그를 추가하고 제거하는 스크립트를 만들어야 했기에 매우 번거롭고 관리하기 힘들어졌습니다. next.js 의 경우 publicRuntimeConfig 를사용하면 빌드는 다시 할 필요 없이 yarn start 만 다시 해줘도 되었지만, 이 역시도 관리하기 힘들다는 이슈는 해결하지 못했습니다.
조금 더 편한 방법은 피쳐플래그에 환경변수 대신 동적인 값인 url 파라미터나 쿠키, localStorage 등을 이용하는 것입니다. 이렇게 할 경우 빌드도, start도 다시 할 필요 없이 테스트코드로만 훨씬 깔끔하게 피쳐플래그를 테스트할 수 있었습니다.
위 BDD 테스트코드의 11번 줄에서, 플래그가 켜진 상태에서 테스트한다고 선언합니다.
그리고 이 로직을 통해 cypress가 실제로 localStorage 를 조작하여 플래그를 주입합니다. 이렇게 하면 한 번의 yarn start와 한 번의 cypress run만으로 테스트를 수행할 수 있습니다.
이런 시행착오를 거친 끝에 지금은 테스트 CI의 편의성을 위해 환경변수를 피쳐플래그로 활용하는 것을 지양하고 있습니다.
TBD 이용하기
개발부터 QA, 출시까지의 흐름
그럼, 이제부터 저희 콴다팀에서 어떻게 일하고 있는지 과정을 공유드려보려 합니다. 저희는 크게 운영환경과 개발환경 두 개의 환경을 운영하고 있고, 개발자들은 각자의 로컬환경에서 개발을 하고 있습니다. 로컬환경에서 개발을 하고 -> 개발이 완료되면 개발환경에서 QA를 하고 -> 필요하다면 운영환경에서도 QA를 거친 다음 -> 유저에게 출시합니다.
또한, 배포는 브랜치와 무관하게 태그 푸시 기반 배포로 이루어집니다. main 브랜치에 변경사항이 수시로 머지되기에 브랜치 머지를 기준으로 배포를 하게 되면 불필요하게 너무 많은 배포가 이루어질 수 있으며, 반대로 main에 머지해야만 배포가 되므로 배포 자유도가 떨어지기 때문입니다.
개발팀으로 피쳐가 들어오면, 먼저 해당 피쳐의 개발에 피쳐플래그와 다크런칭 전략을 사용할지 말지 결정합니다. 피쳐플래그를 세팅하고 처리하는 것 또한 분명히 개발이 들어가야 하는 작업이기에 너무 작거나 소소한 작업에 피쳐플래그를 적용하는 것은 오히려 피로해지고 생산성을 떨어트릴 수 있습니다.
문구 변경, 작은 버그 수정, 핫픽스 등 일반적으로 1개의 PR로 처리될 수 있는 경우, 피쳐플래그와 다크런칭을 적용하지 않습니다.
신규 기능, ui 개편 등 일반적으로 여러 개의 PR과 긴 개발 기간이 소요될 경우, 피쳐플래그를 적용합니다.
먼저 피쳐플래그를 적용하지 않은 경우에는 아래와 같이 움직입니다.
main 에서 브랜치를 분기하고 작업합니다.
작업이 완료되면, 팀원들에게 노티를 준 다음 해당 브랜치의 코드를 개발환경에 배포합니다.
개발환경에서 1시간 이내의 시간 동안 간단하게 QA를 거친 다음, 브랜치를 main에 squash merge합니다.
main에 머지된 변경사항을 운영환경에 배포합니다.
피쳐플래그를 적용하지 않았을 때에는 이렇게 일반적인 플로우와 크게 다르지 않습니다.
반대로 피쳐플래그를 적용한 경우에는 아래와 같습니다.
main에서 브랜치를 분기하여 피쳐플래그를 셋업하고 main에 머지합니다. 이때 플래그는 localStorage, 환경변수, url 등 여러 방법이 될 수 있고, 이들을 동시에 이용할 수도 있습니다.
기능을 소규모 작업들로 나누고, 해당 작업들을 계속 main에서 분기하여 다크런칭 상태로 개발하고 main에 다시 squash merge합니다.
개발환경에서 플래그를 켜서 기능이 보이게 한 다음, QA를 진행합니다.
운영환경에서도 QA가 필요하다면, url 등을 통해 유저는 모르고 콴다팀 내부적으로만 알고 있는 피쳐플래그를 켜서 QA를 진행합니다.
배포해도 되겠다고 판단되면 운영환경에서도 전체 유저에게 피쳐플래그를 켜서 기능을 오픈합니다.
마지막으로, 다크런칭을 위한 분기문들과 피쳐플래그 관련 세팅들을 제거합니다.
기능을 오픈한 다음에 추가적으로 해줘야 하는 작업이 생겼음을 알 수 있습니다.
위와 같은 프로세스에서 가장 중요한 점은 아래와 같습니다.
모두가 같은 코드베이스에서 작업했다.
main 브랜치는 항상 운영환경에 배포 가능한 상태였다.
위와 같은 특징 덕분에, 만약 프로덕션에 이슈가 발견되어 핫픽스가 나가야 하는 상황이었다면 - 현재 그 프로젝트에 누가 무슨 기능을 개발하고 있든 / 무슨 리팩토링을 진행하고 있든 아무 병목 없이, 아무것도 고려할 필요도 없이 필요한 변경사항을 main에 머지한 다음 운영환경에 배포하면 될 것입니다.
그 외의 장단점들
미처 위에서 작성하지 못했던 TBD의 또 다른 장단점들도 있습니다.
먼저 PR의 단위가 주로 10~100줄 정도로 작아졌기 때문에 코드 리뷰의 부담이 크게 줄었고, 동기적인 코드 리뷰가 가능해졌습니다.
또한 프로젝트 전역에 적용되는 대규모 마이너 리팩토링을 적용하기가 훨씬 수월해졌습니다. 가령 팀원들간의 합의에 의해 prettier 설정의 printWidth 가 80에서 100으로 늘어났을 때, 아직 머지되지 않은 피쳐브랜치에 3000줄짜리 변경사항이 머지를 기다리고 있다면 prettier 설정을 변경한 다음 감당할 수 없는 컨플릭을 해결해야 하거나, 해당 변경사항이 머지될 때까지 설정을 변경할 수 없었을 것입니다. 하지만 TBD에서는 모두가 같은 코드베이스 위에서 작업하기에 대규모 변경을 편하게 적용할 수 있었습니다. 이는 TBD에서는 작업을 소규모 배치 작업들로 나뉘어 짧게 개발되고 수시로 머지되기에 어느 개발자의 로컬 코드도 main과 크게 다르지 않은 덕분입니다.
반대로 단점도 있었는데요, 작업들이 소규모 작업들로 쪼개지다 보니 PR이 뭘 구현하기 위한 것인지, 그 기능을 구현하기 위해 이 PR의 변경사항이 무슨 역할을 하는지 한눈에 파악하기는 조금 어려워졌습니다. 이 부분은 GitHub 의 milestone 과 project 기능을 통해 해소할 수 있었습니다.
끝으로
팀워크 향상과 생산성을 위해 모노레포를 도입했고, 모노레포를 관리하기 위해 TBD를 도입했고, 1년간 모노레포에서 TBD를 사용하며 TBD의 많은 장점들을 느낄 수 있었습니다. 단 한 번도 배포나 개발 병목이 일어나지 않았고, 소통 비용을 크게 줄여줬으며, 더 이상 커밋을 체리픽하고 리베이스하는 등의 번거로운 작업을 하지 않아도 되게 되었습니다.
물론 모든 기술이 그렇듯이 TBD 역시 만능은 아닙니다. 피쳐플래그로 얼마나 잘 막아뒀든, 아무튼 “QA를 거쳐 검증되지 않은 코드가 프로덕션에 배포될 수 있다” 라는 점에서 안정성이 엄청나게 중요한 도메인들에서는 이 전략을 사용하기 어려울 수 있습니다. 또한 TBD는 버전 관리의 피로함을 해결해주는 대신 피쳐플래그 사용이 사실상 강제되므로 코드 관리에 피로함을 주곤 합니다.
콴다 프론트엔드 챕터에서는 1년간 TBD 전략을 만족하면서 이용했고, 앞으로도 이 전략을 이용할 예정입니다. 개발자들의 코드 변경사항이 서로의 개발과 배포를 병목시키는 경험을 해 보셨다면 TBD를 한번 시도해보시는 건 어떨까요?
🌏글로벌 Top 교육 앱 QANDA(콴다)를 함께 만들어 갈 Frontend개발자들을 기다리고 있습니다!
🖥️콴다 팀의 개발 문화가 궁금하다면? ➡️ Inside QANDA: 최고의 글로벌 교육 서비스를 개발한다는 것
🕹️콴다 Frontend Team은 채용 중 입니다!➡️ 공고 확인하기
프론트엔드 모노레포 TBD로 관리하기 was originally published in 콴다 팀블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

프론트엔드 모노레포 TBD로 관리하기

댓글